* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-13 11:45 ` Maciej Rutecki
2006-08-13 19:11 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-13 23:58 ` 2.6.18-rc4-mm1 Dmitry Torokhov
2006-08-13 12:24 ` 2.6.18-rc4-mm1 Michal Piotrowski
` (28 subsequent siblings)
29 siblings, 2 replies; 192+ messages in thread
From: Maciej Rutecki @ 2006-08-13 11:45 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
Andrew Morton napisał(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
I have problem with my keyboard. I have no error in dmesg and syslog,
but it doesn't work. I read google and try "i8042.nomux", but it didn't
help.
I enclose dmesg with "i8042.debug=1" option and my config.
Maybe I forgot something in config?
Greetings
--
Maciej Rutecki <maciej.rutecki@gmail.com>
http://www.unixy.pl
JID: bc547@jabber.gda.pl
[-- Attachment #2: config-2.6.18-rc4-mm1.gz --]
[-- Type: application/x-gzip, Size: 14622 bytes --]
[-- Attachment #3: dmesg.gz --]
[-- Type: application/x-gzip, Size: 9598 bytes --]
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-13 11:45 ` 2.6.18-rc4-mm1 Maciej Rutecki
@ 2006-08-13 19:11 ` Andrew Morton
2006-08-13 22:44 ` 2.6.18-rc4-mm1 Ben Buxton
2022-08-14 8:42 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-13 23:58 ` 2.6.18-rc4-mm1 Dmitry Torokhov
1 sibling, 2 replies; 192+ messages in thread
From: Andrew Morton @ 2006-08-13 19:11 UTC (permalink / raw)
To: Maciej Rutecki; +Cc: linux-kernel, Dmitry Torokhov
Please always do reply-to-all.
On Sun, 13 Aug 2006 13:45:35 +0200
Maciej Rutecki <maciej.rutecki@gmail.com> wrote:
> Andrew Morton napisał(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> I have problem with my keyboard. I have no error in dmesg and syslog,
> but it doesn't work. I read google and try "i8042.nomux", but it didn't
> help.
>
> I enclose dmesg with "i8042.debug=1" option and my config.
>
> Maybe I forgot something in config?
>
Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
reversion patch, on top of rc4-mm1, thanks.
diff -puN drivers/input/serio/i8042.c~revert-i8042-get-rid-of-polling-timer-v4 drivers/input/serio/i8042.c
--- a/drivers/input/serio/i8042.c~revert-i8042-get-rid-of-polling-timer-v4
+++ a/drivers/input/serio/i8042.c
@@ -90,24 +90,46 @@ static DEFINE_SPINLOCK(i8042_lock);
struct i8042_port {
struct serio *serio;
int irq;
+ unsigned char disable;
+ unsigned char irqen;
unsigned char exists;
signed char mux;
+ char name[8];
};
#define I8042_KBD_PORT_NO 0
#define I8042_AUX_PORT_NO 1
#define I8042_MUX_PORT_NO 2
#define I8042_NUM_PORTS (I8042_NUM_MUX_PORTS + 2)
-
-static struct i8042_port i8042_ports[I8042_NUM_PORTS];
+static struct i8042_port i8042_ports[I8042_NUM_PORTS] = {
+ {
+ .disable = I8042_CTR_KBDDIS,
+ .irqen = I8042_CTR_KBDINT,
+ .mux = -1,
+ .name = "KBD",
+ },
+ {
+ .disable = I8042_CTR_AUXDIS,
+ .irqen = I8042_CTR_AUXINT,
+ .mux = -1,
+ .name = "AUX",
+ }
+};
static unsigned char i8042_initial_ctr;
static unsigned char i8042_ctr;
+static unsigned char i8042_mux_open;
static unsigned char i8042_mux_present;
-static unsigned char i8042_kbd_irq_registered;
-static unsigned char i8042_aux_irq_registered;
+static struct timer_list i8042_timer;
static struct platform_device *i8042_platform_device;
+
+/*
+ * Shared IRQ's require a device pointer, but this driver doesn't support
+ * multiple devices
+ */
+#define i8042_request_irq_cookie (&i8042_timer)
+
static irqreturn_t i8042_interrupt(int irq, void *dev_id, struct pt_regs *regs);
/*
@@ -119,7 +141,6 @@ static irqreturn_t i8042_interrupt(int i
static int i8042_wait_read(void)
{
int i = 0;
-
while ((~i8042_read_status() & I8042_STR_OBF) && (i < I8042_CTL_TIMEOUT)) {
udelay(50);
i++;
@@ -130,7 +151,6 @@ static int i8042_wait_read(void)
static int i8042_wait_write(void)
{
int i = 0;
-
while ((i8042_read_status() & I8042_STR_IBF) && (i < I8042_CTL_TIMEOUT)) {
udelay(50);
i++;
@@ -172,57 +192,48 @@ static int i8042_flush(void)
* encoded in bits 8-11 of the command number.
*/
-static int __i8042_command(unsigned char *param, int command)
+static int i8042_command(unsigned char *param, int command)
{
- int i, error;
+ unsigned long flags;
+ int i, retval, auxerr = 0;
if (i8042_noloop && command == I8042_CMD_AUX_LOOP)
return -1;
- error = i8042_wait_write();
- if (error)
- return error;
+ spin_lock_irqsave(&i8042_lock, flags);
+
+ if ((retval = i8042_wait_write()))
+ goto out;
dbg("%02x -> i8042 (command)", command & 0xff);
i8042_write_command(command & 0xff);
for (i = 0; i < ((command >> 12) & 0xf); i++) {
- error = i8042_wait_write();
- if (error)
- return error;
+ if ((retval = i8042_wait_write()))
+ goto out;
dbg("%02x -> i8042 (parameter)", param[i]);
i8042_write_data(param[i]);
}
for (i = 0; i < ((command >> 8) & 0xf); i++) {
- error = i8042_wait_read();
- if (error) {
- dbg(" -- i8042 (timeout)");
- return error;
- }
+ if ((retval = i8042_wait_read()))
+ goto out;
if (command == I8042_CMD_AUX_LOOP &&
!(i8042_read_status() & I8042_STR_AUXDATA)) {
- dbg(" -- i8042 (auxerr)");
- return -1;
+ retval = auxerr = -1;
+ goto out;
}
param[i] = i8042_read_data();
dbg("%02x <- i8042 (return)", param[i]);
}
- return 0;
-}
-
-static int i8042_command(unsigned char *param, int command)
-{
- unsigned long flags;
- int retval;
+ if (retval)
+ dbg(" -- i8042 (%s)", auxerr ? "auxerr" : "timeout");
- spin_lock_irqsave(&i8042_lock, flags);
- retval = __i8042_command(param, command);
+ out:
spin_unlock_irqrestore(&i8042_lock, flags);
-
return retval;
}
@@ -237,7 +248,7 @@ static int i8042_kbd_write(struct serio
spin_lock_irqsave(&i8042_lock, flags);
- if (!(retval = i8042_wait_write())) {
+ if(!(retval = i8042_wait_write())) {
dbg("%02x -> i8042 (kbd-data)", c);
i8042_write_data(c);
}
@@ -276,6 +287,100 @@ static int i8042_aux_write(struct serio
}
/*
+ * i8042_activate_port() enables port on a chip.
+ */
+
+static int i8042_activate_port(struct i8042_port *port)
+{
+ if (!port->serio)
+ return -1;
+
+ i8042_flush();
+
+ /*
+ * Enable port again here because it is disabled if we are
+ * resuming (normally it is enabled already).
+ */
+ i8042_ctr &= ~port->disable;
+
+ i8042_ctr |= port->irqen;
+
+ if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
+ i8042_ctr &= ~port->irqen;
+ return -1;
+ }
+
+ return 0;
+}
+
+
+/*
+ * i8042_open() is called when a port is open by the higher layer.
+ * It allocates the interrupt and calls i8042_enable_port.
+ */
+
+static int i8042_open(struct serio *serio)
+{
+ struct i8042_port *port = serio->port_data;
+
+ if (port->mux != -1)
+ if (i8042_mux_open++)
+ return 0;
+
+ if (request_irq(port->irq, i8042_interrupt,
+ IRQF_SHARED, "i8042", i8042_request_irq_cookie)) {
+ printk(KERN_ERR "i8042.c: Can't get irq %d for %s, unregistering the port.\n", port->irq, port->name);
+ goto irq_fail;
+ }
+
+ if (i8042_activate_port(port)) {
+ printk(KERN_ERR "i8042.c: Can't activate %s, unregistering the port\n", port->name);
+ goto activate_fail;
+ }
+
+ i8042_interrupt(0, NULL, NULL);
+
+ return 0;
+
+ activate_fail:
+ free_irq(port->irq, i8042_request_irq_cookie);
+
+ irq_fail:
+ serio_unregister_port_delayed(serio);
+
+ return -1;
+}
+
+/*
+ * i8042_close() frees the interrupt, so that it can possibly be used
+ * by another driver. We never know - if the user doesn't have a mouse,
+ * the BIOS could have used the AUX interrupt for PCI.
+ */
+
+static void i8042_close(struct serio *serio)
+{
+ struct i8042_port *port = serio->port_data;
+
+ if (port->mux != -1)
+ if (--i8042_mux_open)
+ return;
+
+ i8042_ctr &= ~port->irqen;
+
+ if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
+ printk(KERN_WARNING "i8042.c: Can't write CTR while closing %s.\n", port->name);
+/*
+ * We still want to continue and free IRQ so if more data keeps coming in
+ * kernel will just ignore the irq.
+ */
+ }
+
+ free_irq(port->irq, i8042_request_irq_cookie);
+
+ i8042_flush();
+}
+
+/*
* i8042_start() is called by serio core when port is about to finish
* registering. It will mark port as existing so i8042_interrupt can
* start sending data through it.
@@ -318,6 +423,8 @@ static irqreturn_t i8042_interrupt(int i
unsigned int port_no;
int ret;
+ mod_timer(&i8042_timer, jiffies + I8042_POLL_PERIOD);
+
spin_lock_irqsave(&i8042_lock, flags);
str = i8042_read_status();
if (unlikely(~str & I8042_STR_OBF)) {
@@ -373,8 +480,8 @@ static irqreturn_t i8042_interrupt(int i
port = &i8042_ports[port_no];
- dbg("%02x <- i8042 (interrupt, %d, %d%s%s)",
- data, port_no, irq,
+ dbg("%02x <- i8042 (interrupt, %s, %d%s%s)",
+ data, port->name, irq,
dfl & SERIO_PARITY ? ", bad parity" : "",
dfl & SERIO_TIMEOUT ? ", timeout" : "");
@@ -387,58 +494,6 @@ static irqreturn_t i8042_interrupt(int i
}
/*
- * i8042_enable_kbd_port enables keybaord port on chip
- */
-
-static int i8042_enable_kbd_port(void)
-{
- i8042_ctr &= ~I8042_CTR_KBDDIS;
- i8042_ctr |= I8042_CTR_KBDINT;
-
- if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
- printk(KERN_ERR "i8042.c: Failed to enable KBD port.\n");
- return -EIO;
- }
-
- return 0;
-}
-
-/*
- * i8042_enable_aux_port enables AUX (mouse) port on chip
- */
-
-static int i8042_enable_aux_port(void)
-{
- i8042_ctr &= ~I8042_CTR_AUXDIS;
- i8042_ctr |= I8042_CTR_AUXINT;
-
- if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
- printk(KERN_ERR "i8042.c: Failed to enable AUX port.\n");
- return -EIO;
- }
-
- return 0;
-}
-
-/*
- * i8042_enable_mux_ports enables 4 individual AUX ports after
- * the controller has been switched into Multiplexed mode
- */
-
-static int i8042_enable_mux_ports(void)
-{
- unsigned char param;
- int i;
-
- for (i = 0; i < I8042_NUM_MUX_PORTS; i++) {
- i8042_command(¶m, I8042_CMD_MUX_PFX + i);
- i8042_command(¶m, I8042_CMD_AUX_ENABLE);
- }
-
- return i8042_enable_aux_port();
-}
-
-/*
* i8042_set_mux_mode checks whether the controller has an active
* multiplexor and puts the chip into Multiplexed (1) or Legacy (0) mode.
*/
@@ -455,7 +510,8 @@ static int i8042_set_mux_mode(unsigned i
/*
* Internal loopback test - send three bytes, they should come back from the
- * mouse interface, the last should be version.
+ * mouse interface, the last should be version. Note that we negate mouseport
+ * command responses for the i8042_check_aux() routine.
*/
param = 0xf0;
@@ -474,67 +530,67 @@ static int i8042_set_mux_mode(unsigned i
return 0;
}
-/*
- * i8042_check_mux() checks whether the controller supports the PS/2 Active
- * Multiplexing specification by Synaptics, Phoenix, Insyde and
- * LCS/Telegraphics.
- */
-
-static int __devinit i8042_check_mux(void)
-{
- unsigned char mux_version;
-
- if (i8042_set_mux_mode(1, &mux_version))
- return -1;
/*
- * Workaround for interference with USB Legacy emulation
- * that causes a v10.12 MUX to be found.
+ * i8042_enable_mux_ports enables 4 individual AUX ports after
+ * the controller has been switched into Multiplexed mode
*/
- if (mux_version == 0xAC)
- return -1;
-
- printk(KERN_INFO "i8042.c: Detected active multiplexing controller, rev %d.%d.\n",
- (mux_version >> 4) & 0xf, mux_version & 0xf);
+static int i8042_enable_mux_ports(void)
+{
+ unsigned char param;
+ int i;
/*
* Disable all muxed ports by disabling AUX.
*/
+
i8042_ctr |= I8042_CTR_AUXDIS;
i8042_ctr &= ~I8042_CTR_AUXINT;
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
printk(KERN_ERR "i8042.c: Failed to disable AUX port, can't use MUX.\n");
- return -EIO;
+ return -1;
}
- i8042_mux_present = 1;
+/*
+ * Enable all muxed ports.
+ */
+
+ for (i = 0; i < I8042_NUM_MUX_PORTS; i++) {
+ i8042_command(¶m, I8042_CMD_MUX_PFX + i);
+ i8042_command(¶m, I8042_CMD_AUX_ENABLE);
+ }
return 0;
}
+
/*
- * The following is used to test AUX IRQ delivery.
+ * i8042_check_mux() checks whether the controller supports the PS/2 Active
+ * Multiplexing specification by Synaptics, Phoenix, Insyde and
+ * LCS/Telegraphics.
*/
-static struct completion i8042_aux_irq_delivered __devinitdata;
-static int i8042_irq_being_tested __devinitdata;
-static irqreturn_t __devinit i8042_aux_test_irq(int irq, void *dev_id, struct pt_regs *regs)
+static int __devinit i8042_check_mux(void)
{
- unsigned long flags;
- unsigned char str, data;
+ unsigned char mux_version;
- spin_lock_irqsave(&i8042_lock, flags);
- str = i8042_read_status();
- if (str & I8042_STR_OBF) {
- data = i8042_read_data();
- if (i8042_irq_being_tested &&
- data == 0xa5 && (str & I8042_STR_AUXDATA))
- complete(&i8042_aux_irq_delivered);
- }
- spin_unlock_irqrestore(&i8042_lock, flags);
+ if (i8042_set_mux_mode(1, &mux_version))
+ return -1;
- return IRQ_HANDLED;
+ /* Workaround for interference with USB Legacy emulation */
+ /* that causes a v10.12 MUX to be found. */
+ if (mux_version == 0xAC)
+ return -1;
+
+ printk(KERN_INFO "i8042.c: Detected active multiplexing controller, rev %d.%d.\n",
+ (mux_version >> 4) & 0xf, mux_version & 0xf);
+
+ if (i8042_enable_mux_ports())
+ return -1;
+
+ i8042_mux_present = 1;
+ return 0;
}
@@ -545,10 +601,18 @@ static irqreturn_t __devinit i8042_aux_t
static int __devinit i8042_check_aux(void)
{
- int retval = -1;
- int irq_registered = 0;
- unsigned long flags;
unsigned char param;
+ static int i8042_check_aux_cookie;
+
+/*
+ * Check if AUX irq is available. If it isn't, then there is no point
+ * in trying to detect AUX presence.
+ */
+
+ if (request_irq(i8042_ports[I8042_AUX_PORT_NO].irq, i8042_interrupt,
+ IRQF_SHARED, "i8042", &i8042_check_aux_cookie))
+ return -1;
+ free_irq(i8042_ports[I8042_AUX_PORT_NO].irq, &i8042_check_aux_cookie);
/*
* Get rid of bytes in the queue.
@@ -573,9 +637,9 @@ static int __devinit i8042_check_aux(voi
* AUX ports, we test for this only when the LOOP command failed.
*/
- if (i8042_command(¶m, I8042_CMD_AUX_TEST) ||
- (param && param != 0xfa && param != 0xff))
- return -1;
+ if (i8042_command(¶m, I8042_CMD_AUX_TEST)
+ || (param && param != 0xfa && param != 0xff))
+ return -1;
}
/*
@@ -595,74 +659,54 @@ static int __devinit i8042_check_aux(voi
return -1;
/*
- * Test AUX IRQ delivery to make sure BIOS did not grab the IRQ and
- * used it for a PCI card or somethig else.
- */
-
- if (i8042_noloop) {
-/*
- * Without LOOP command we can't test AUX IRQ delivery. Assume the port
- * is working and hope we are right.
+ * Disable the interface.
*/
- retval = 0;
- goto out;
- }
-
- if (request_irq(I8042_AUX_IRQ, i8042_aux_test_irq, IRQF_SHARED,
- "i8042", i8042_platform_device))
- goto out;
-
- irq_registered = 1;
- if (i8042_enable_aux_port())
- goto out;
-
- spin_lock_irqsave(&i8042_lock, flags);
-
- init_completion(&i8042_aux_irq_delivered);
- i8042_irq_being_tested = 1;
-
- param = 0xa5;
- retval = __i8042_command(¶m, I8042_CMD_AUX_LOOP & 0xf0ff);
-
- spin_unlock_irqrestore(&i8042_lock, flags);
+ i8042_ctr |= I8042_CTR_AUXDIS;
+ i8042_ctr &= ~I8042_CTR_AUXINT;
- if (retval)
- goto out;
+ if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR))
+ return -1;
- if (wait_for_completion_timeout(&i8042_aux_irq_delivered,
- msecs_to_jiffies(250)) == 0)
- retval = -1;
+ return 0;
+}
- out:
/*
- * Disable the interface.
+ * i8042_port_register() marks the device as existing,
+ * registers it, and reports to the user.
*/
- i8042_ctr |= I8042_CTR_AUXDIS;
- i8042_ctr &= ~I8042_CTR_AUXINT;
+static int __devinit i8042_port_register(struct i8042_port *port)
+{
+ i8042_ctr &= ~port->disable;
- if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR))
- retval = -1;
+ if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
+ printk(KERN_WARNING "i8042.c: Can't write CTR while registering.\n");
+ kfree(port->serio);
+ port->serio = NULL;
+ i8042_ctr |= port->disable;
+ return -EIO;
+ }
- if (irq_registered)
- free_irq(I8042_AUX_IRQ, i8042_platform_device);
+ printk(KERN_INFO "serio: i8042 %s port at %#lx,%#lx irq %d\n",
+ port->name,
+ (unsigned long) I8042_DATA_REG,
+ (unsigned long) I8042_COMMAND_REG,
+ port->irq);
- return retval;
+ serio_register_port(port->serio);
+
+ return 0;
}
-static int i8042_controller_check(void)
-{
- if (i8042_flush() == I8042_BUFFER_SIZE) {
- printk(KERN_ERR "i8042.c: No controller found.\n");
- return -ENODEV;
- }
- return 0;
+static void i8042_timer_func(unsigned long data)
+{
+ i8042_interrupt(0, NULL, NULL);
}
-static int i8042_controller_selftest(void)
+static int i8042_ctl_test(void)
{
unsigned char param;
@@ -671,13 +715,13 @@ static int i8042_controller_selftest(voi
if (i8042_command(¶m, I8042_CMD_CTL_TEST)) {
printk(KERN_ERR "i8042.c: i8042 controller self test timeout.\n");
- return -ENODEV;
+ return -1;
}
if (param != I8042_RET_CTL_TEST) {
printk(KERN_ERR "i8042.c: i8042 controller selftest failed. (%#x != %#x)\n",
param, I8042_RET_CTL_TEST);
- return -EIO;
+ return -1;
}
return 0;
@@ -694,12 +738,25 @@ static int i8042_controller_init(void)
unsigned long flags;
/*
+ * Test the i8042. We need to know if it thinks it's working correctly
+ * before doing anything else.
+ */
+
+ if (i8042_flush() == I8042_BUFFER_SIZE) {
+ printk(KERN_ERR "i8042.c: No controller found.\n");
+ return -1;
+ }
+
+ if (i8042_ctl_test())
+ return -1;
+
+/*
* Save the CTR for restoral on unload / reboot.
*/
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_RCTR)) {
printk(KERN_ERR "i8042.c: Can't read CTR while initializing i8042.\n");
- return -EIO;
+ return -1;
}
i8042_initial_ctr = i8042_ctr;
@@ -725,10 +782,8 @@ static int i8042_controller_init(void)
spin_unlock_irqrestore(&i8042_lock, flags);
/*
- ** If the chip is configured into nontranslated mode by the BIOS, don't
- ** bother enabling translating and be happy.
- * If we were in xlate mode before (that means we are resuming)
- * restore it.
+ * If the chip is configured into nontranslated mode by the BIOS, don't
+ * bother enabling translating and be happy.
*/
if (~i8042_ctr & I8042_CTR_XLATE)
@@ -750,7 +805,7 @@ static int i8042_controller_init(void)
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
printk(KERN_ERR "i8042.c: Can't write CTR while initializing i8042.\n");
- return -EIO;
+ return -1;
}
return 0;
@@ -758,31 +813,30 @@ static int i8042_controller_init(void)
/*
- * Reset the controller and reset CRT to the original value set by BIOS.
+ * Reset the controller.
*/
-
static void i8042_controller_reset(void)
{
- i8042_flush();
-
/*
- * Disable MUX mode if present.
+ * Reset the controller if requested.
*/
- if (i8042_mux_present)
- i8042_set_mux_mode(0, NULL);
+ i8042_ctl_test();
/*
- * Reset the controller if requested.
+ * Disable MUX mode if present.
*/
- i8042_controller_selftest();
+ if (i8042_mux_present)
+ i8042_set_mux_mode(0, NULL);
/*
* Restore the original control register setting.
*/
- if (i8042_command(&i8042_initial_ctr, I8042_CMD_CTL_WCTR))
+ i8042_ctr = i8042_initial_ctr;
+
+ if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR))
printk(KERN_WARNING "i8042.c: Can't restore CTR.\n");
}
@@ -796,12 +850,14 @@ static void i8042_controller_cleanup(voi
{
int i;
+ i8042_flush();
+
/*
* Reset anything that is connected to the ports.
*/
for (i = 0; i < I8042_NUM_PORTS; i++)
- if (i8042_ports[i].serio)
+ if (i8042_ports[i].exists)
serio_cleanup(i8042_ports[i].serio);
i8042_controller_reset();
@@ -857,7 +913,8 @@ static long i8042_panic_blink(long count
static int i8042_suspend(struct platform_device *dev, pm_message_t state)
{
- i8042_controller_cleanup();
+ del_timer_sync(&i8042_timer);
+ i8042_controller_reset();
return 0;
}
@@ -869,39 +926,33 @@ static int i8042_suspend(struct platform
static int i8042_resume(struct platform_device *dev)
{
- int error;
-
- error = i8042_controller_check();
- if (error)
- return error;
-
- error = i8042_controller_selftest();
- if (error)
- return error;
+ int i;
-/*
- * Restore pre-resume CTR value and disable all ports
- */
+ if (i8042_ctl_test())
+ return -1;
- i8042_ctr |= I8042_CTR_AUXDIS | I8042_CTR_KBDDIS;
- i8042_ctr &= ~(I8042_CTR_AUXINT | I8042_CTR_KBDINT);
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
- printk(KERN_ERR "i8042: Can't write CTR to resume\n");
- return -EIO;
+ printk(KERN_ERR "i8042: Can't write CTR\n");
+ return -1;
}
- if (i8042_mux_present) {
+ if (i8042_mux_present)
if (i8042_set_mux_mode(1, NULL) || i8042_enable_mux_ports())
- printk(KERN_WARNING
- "i8042: failed to resume active multiplexor, "
- "mouse won't work.\n");
- } else if (i8042_ports[I8042_AUX_PORT_NO].serio)
- i8042_enable_aux_port();
+ printk(KERN_WARNING "i8042: failed to resume active multiplexor, mouse won't work.\n");
- if (i8042_ports[I8042_KBD_PORT_NO].serio)
- i8042_enable_kbd_port();
+/*
+ * Activate all ports.
+ */
- i8042_interrupt(0, NULL, NULL);
+ for (i = 0; i < I8042_NUM_PORTS; i++)
+ i8042_activate_port(&i8042_ports[i]);
+
+/*
+ * Restart timer (for polling "stuck" data)
+ */
+ mod_timer(&i8042_timer, jiffies + I8042_POLL_PERIOD);
+
+ panic_blink = i8042_panic_blink;
return 0;
}
@@ -927,24 +978,24 @@ static int __devinit i8042_create_kbd_po
serio->id.type = i8042_direct ? SERIO_8042 : SERIO_8042_XL;
serio->write = i8042_dumbkbd ? NULL : i8042_kbd_write;
+ serio->open = i8042_open;
+ serio->close = i8042_close;
serio->start = i8042_start;
serio->stop = i8042_stop;
serio->port_data = port;
serio->dev.parent = &i8042_platform_device->dev;
- strlcpy(serio->name, "i8042 KBD port", sizeof(serio->name));
+ strlcpy(serio->name, "i8042 Kbd Port", sizeof(serio->name));
strlcpy(serio->phys, I8042_KBD_PHYS_DESC, sizeof(serio->phys));
port->serio = serio;
- port->irq = I8042_KBD_IRQ;
- return 0;
+ return i8042_port_register(port);
}
-static int __devinit i8042_create_aux_port(int idx)
+static int __devinit i8042_create_aux_port(void)
{
struct serio *serio;
- int port_no = idx < 0 ? I8042_AUX_PORT_NO : I8042_MUX_PORT_NO + idx;
- struct i8042_port *port = &i8042_ports[port_no];
+ struct i8042_port *port = &i8042_ports[I8042_AUX_PORT_NO];
serio = kzalloc(sizeof(struct serio), GFP_KERNEL);
if (!serio)
@@ -952,191 +1003,111 @@ static int __devinit i8042_create_aux_po
serio->id.type = SERIO_8042;
serio->write = i8042_aux_write;
+ serio->open = i8042_open;
+ serio->close = i8042_close;
serio->start = i8042_start;
serio->stop = i8042_stop;
serio->port_data = port;
serio->dev.parent = &i8042_platform_device->dev;
- if (idx < 0) {
- strlcpy(serio->name, "i8042 AUX port", sizeof(serio->name));
- strlcpy(serio->phys, I8042_AUX_PHYS_DESC, sizeof(serio->phys));
- } else {
- snprintf(serio->name, sizeof(serio->name), "i8042 AUX%d port", idx);
- snprintf(serio->phys, sizeof(serio->phys), I8042_MUX_PHYS_DESC, idx + 1);
- }
+ strlcpy(serio->name, "i8042 Aux Port", sizeof(serio->name));
+ strlcpy(serio->phys, I8042_AUX_PHYS_DESC, sizeof(serio->phys));
port->serio = serio;
- port->mux = idx;
- port->irq = I8042_AUX_IRQ;
- return 0;
-}
-
-static void __devinit i8042_free_kbd_port(void)
-{
- kfree(i8042_ports[I8042_KBD_PORT_NO].serio);
- i8042_ports[I8042_KBD_PORT_NO].serio = NULL;
+ return i8042_port_register(port);
}
-static void __devinit i8042_free_aux_ports(void)
+static int __devinit i8042_create_mux_port(int index)
{
- int i;
-
- for (i = I8042_AUX_PORT_NO; i < I8042_NUM_PORTS; i++) {
- kfree(i8042_ports[i].serio);
- i8042_ports[i].serio = NULL;
- }
-}
+ struct serio *serio;
+ struct i8042_port *port = &i8042_ports[I8042_MUX_PORT_NO + index];
-static void __devinit i8042_register_ports(void)
-{
- int i;
+ serio = kzalloc(sizeof(struct serio), GFP_KERNEL);
+ if (!serio)
+ return -ENOMEM;
- for (i = 0; i < I8042_NUM_PORTS; i++) {
- if (i8042_ports[i].serio) {
- printk(KERN_INFO "serio: %s at %#lx,%#lx irq %d\n",
- i8042_ports[i].serio->name,
- (unsigned long) I8042_DATA_REG,
- (unsigned long) I8042_COMMAND_REG,
- i8042_ports[i].irq);
- serio_register_port(i8042_ports[i].serio);
- }
- }
-}
+ serio->id.type = SERIO_8042;
+ serio->write = i8042_aux_write;
+ serio->open = i8042_open;
+ serio->close = i8042_close;
+ serio->start = i8042_start;
+ serio->stop = i8042_stop;
+ serio->port_data = port;
+ serio->dev.parent = &i8042_platform_device->dev;
+ snprintf(serio->name, sizeof(serio->name), "i8042 Aux-%d Port", index);
+ snprintf(serio->phys, sizeof(serio->phys), I8042_MUX_PHYS_DESC, index + 1);
-static void __devinit i8042_unregister_ports(void)
-{
- int i;
+ *port = i8042_ports[I8042_AUX_PORT_NO];
+ port->exists = 0;
+ snprintf(port->name, sizeof(port->name), "AUX%d", index);
+ port->mux = index;
+ port->serio = serio;
- for (i = 0; i < I8042_NUM_PORTS; i++) {
- if (i8042_ports[i].serio) {
- serio_unregister_port(i8042_ports[i].serio);
- i8042_ports[i].serio = NULL;
- }
- }
+ return i8042_port_register(port);
}
-static void i8042_free_irqs(void)
+static int __devinit i8042_probe(struct platform_device *dev)
{
- if (i8042_aux_irq_registered)
- free_irq(I8042_AUX_IRQ, i8042_platform_device);
- if (i8042_kbd_irq_registered)
- free_irq(I8042_KBD_IRQ, i8042_platform_device);
-
- i8042_aux_irq_registered = i8042_kbd_irq_registered = 0;
-}
+ int i, have_ports = 0;
+ int err;
-static int __devinit i8042_setup_aux(void)
-{
- int (*aux_enable)(void);
- int error;
- int i;
+ init_timer(&i8042_timer);
+ i8042_timer.function = i8042_timer_func;
- if (i8042_check_aux())
+ if (i8042_controller_init())
return -ENODEV;
- if (i8042_nomux || i8042_check_mux()) {
- error = i8042_create_aux_port(-1);
- if (error)
- goto err_free_ports;
- aux_enable = i8042_enable_aux_port;
- } else {
- for (i = 0; i < I8042_NUM_MUX_PORTS; i++) {
- error = i8042_create_aux_port(i);
- if (error)
- goto err_free_ports;
+ if (!i8042_noaux && !i8042_check_aux()) {
+ if (!i8042_nomux && !i8042_check_mux()) {
+ for (i = 0; i < I8042_NUM_MUX_PORTS; i++) {
+ err = i8042_create_mux_port(i);
+ if (err)
+ goto err_unregister_ports;
+ }
+ } else {
+ err = i8042_create_aux_port();
+ if (err)
+ goto err_unregister_ports;
}
- aux_enable = i8042_enable_mux_ports;
- }
-
- error = request_irq(I8042_AUX_IRQ, i8042_interrupt, IRQF_SHARED,
- "i8042", i8042_platform_device);
- if (error)
- goto err_free_ports;
-
- if (aux_enable())
- goto err_free_irq;
-
- i8042_aux_irq_registered = 1;
- return 0;
-
- err_free_irq:
- free_irq(I8042_AUX_IRQ, i8042_platform_device);
- err_free_ports:
- i8042_free_aux_ports();
- return error;
-}
-
-static int __devinit i8042_setup_kbd(void)
-{
- int error;
-
- error = i8042_create_kbd_port();
- if (error)
- return error;
-
- error = request_irq(I8042_KBD_IRQ, i8042_interrupt, IRQF_SHARED,
- "i8042", i8042_platform_device);
- if (error)
- goto err_free_port;
-
- error = i8042_enable_kbd_port();
- if (error)
- goto err_free_irq;
-
- i8042_kbd_irq_registered = 1;
- return 0;
-
- err_free_irq:
- free_irq(I8042_KBD_IRQ, i8042_platform_device);
- err_free_port:
- i8042_free_kbd_port();
- return error;
-}
-
-static int __devinit i8042_probe(struct platform_device *dev)
-{
- int error;
-
- error = i8042_controller_selftest();
- if (error)
- return error;
-
- error = i8042_controller_init();
- if (error)
- return error;
-
- if (!i8042_noaux) {
- error = i8042_setup_aux();
- if (error && error != -ENODEV && error != -EBUSY)
- goto out_fail;
+ have_ports = 1;
}
if (!i8042_nokbd) {
- error = i8042_setup_kbd();
- if (error)
- goto out_fail;
+ err = i8042_create_kbd_port();
+ if (err)
+ goto err_unregister_ports;
+ have_ports = 1;
}
-/*
- * Ok, everything is ready, let's register all serio ports
- */
- i8042_register_ports();
+ if (!have_ports) {
+ err = -ENODEV;
+ goto err_controller_cleanup;
+ }
+ mod_timer(&i8042_timer, jiffies + I8042_POLL_PERIOD);
return 0;
- out_fail:
- i8042_free_aux_ports(); /* in case KBD failed but AUX not */
- i8042_free_irqs();
- i8042_controller_reset();
+ err_unregister_ports:
+ for (i = 0; i < I8042_NUM_PORTS; i++)
+ if (i8042_ports[i].serio)
+ serio_unregister_port(i8042_ports[i].serio);
+ err_controller_cleanup:
+ i8042_controller_cleanup();
- return error;
+ return err;
}
static int __devexit i8042_remove(struct platform_device *dev)
{
- i8042_unregister_ports();
- i8042_free_irqs();
- i8042_controller_reset();
+ int i;
+
+ i8042_controller_cleanup();
+
+ for (i = 0; i < I8042_NUM_PORTS; i++)
+ if (i8042_ports[i].exists)
+ serio_unregister_port(i8042_ports[i].serio);
+
+ del_timer_sync(&i8042_timer);
return 0;
}
@@ -1163,9 +1134,8 @@ static int __init i8042_init(void)
if (err)
return err;
- err = i8042_controller_check();
- if (err)
- goto err_platform_exit;
+ i8042_ports[I8042_AUX_PORT_NO].irq = I8042_AUX_IRQ;
+ i8042_ports[I8042_KBD_PORT_NO].irq = I8042_KBD_IRQ;
err = platform_driver_register(&i8042_driver);
if (err)
@@ -1181,8 +1151,6 @@ static int __init i8042_init(void)
if (err)
goto err_free_device;
- panic_blink = i8042_panic_blink;
-
return 0;
err_free_device:
@@ -1199,6 +1167,7 @@ static void __exit i8042_exit(void)
{
platform_device_unregister(i8042_platform_device);
platform_driver_unregister(&i8042_driver);
+
i8042_platform_exit();
panic_blink = NULL;
diff -puN drivers/input/serio/i8042.h~revert-i8042-get-rid-of-polling-timer-v4 drivers/input/serio/i8042.h
--- a/drivers/input/serio/i8042.h~revert-i8042-get-rid-of-polling-timer-v4
+++ a/drivers/input/serio/i8042.h
@@ -37,6 +37,15 @@
#define I8042_CTL_TIMEOUT 10000
/*
+ * When the device isn't opened and it's interrupts aren't used, we poll it at
+ * regular intervals to see if any characters arrived. If yes, we can start
+ * probing for any mouse / keyboard connected. This is the period of the
+ * polling.
+ */
+
+#define I8042_POLL_PERIOD HZ/20
+
+/*
* Status register bits.
*/
_
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-13 19:11 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-13 22:44 ` Ben Buxton
2006-08-13 22:58 ` 2.6.18-rc4-mm1 Michal Piotrowski
` (2 more replies)
2022-08-14 8:42 ` 2.6.18-rc4-mm1 Maciej Rutecki
1 sibling, 3 replies; 192+ messages in thread
From: Ben Buxton @ 2006-08-13 22:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: Maciej Rutecki, linux-kernel, Dmitry Torokhov
Andrew Morton <akpm@osdl.org> uttered the following thing:
> On Sun, 13 Aug 2006 13:45:35 +0200
> Maciej Rutecki <maciej.rutecki@gmail.com> wrote:
>
> > Andrew Morton napisa??(a):
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >
> > I have problem with my keyboard. I have no error in dmesg and syslog,
> > but it doesn't work. I read google and try "i8042.nomux", but it didn't
> > help.
> >
> > I enclose dmesg with "i8042.debug=1" option and my config.
> >
> > Maybe I forgot something in config?
> >
>
>
> Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> reversion patch, on top of rc4-mm1, thanks.
Acking the same issue. Applied the revert patch and my keyboard now
works. Also, it turns out that my keyboard is now the only thing that
failed to resume from S3 on my HP Nc6400, but adding "irqpoll" has fixed
that for now.
Also, to two other things I spotted with cpufreq. Running
speedstep-centrino on a Core Duo T2400 (1.83GHz) I see the
"cpuinfo_max_freq" is 1833000, but "scaling_max_freq" is fixed at 1333000,
regardless of the governor, and I cannot change it.
Also, whenever I echo anything to "scaling_governor", I get the
following kernel message:
[ 734.156000] BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug()
[ 734.156000] [<c013c3ec>] lock_cpu_hotplug+0x7c/0x90
[ 734.156000] [<c01327f4>] __create_workqueue+0x44/0x140
[ 734.156000] [<c02dcf7b>] mutex_lock+0xb/0x20
[ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310
[cpufreq_ondemand]
[ 734.156000] [<c012f6a5>] notifier_call_chain+0x25/0x40
[ 734.156000] [<c0274b06>] __cpufreq_governor+0x46/0xe0
[ 734.156000] [<c0274c84>] __cpufreq_set_policy+0xe4/0x130
[ 734.156000] [<c0275ae4>] store_scaling_governor+0xd4/0x210
[ 734.160000] [<c02756a0>] handle_update+0x0/0x10
[ 734.160000] [<c01e2000>] kobject_get+0x0/0x20
[ 734.160000] [<c0275a10>] store_scaling_governor+0x0/0x210
[ 734.160000] [<c027521d>] store+0x3d/0x60
[ 734.160000] [<c01a2e0c>] sysfs_write_file+0x9c/0xf0
[ 734.160000] [<c016a8c6>] vfs_write+0xa6/0x160
[ 734.160000] [<c01a2d70>] sysfs_write_file+0x0/0xf0
[ 734.160000] [<c016b001>] sys_write+0x41/0x70
[ 734.160000] [<c0103115>] sysenter_past_esp+0x56/0x79
It seems that scaling still works, but this message is a bit unnerving.
BB
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-13 22:44 ` 2.6.18-rc4-mm1 Ben Buxton
@ 2006-08-13 22:58 ` Michal Piotrowski
2006-08-13 23:25 ` 2.6.18-rc4-mm1 Dave Jones
2006-08-14 0:00 ` 2.6.18-rc4-mm1 Dmitry Torokhov
2 siblings, 0 replies; 192+ messages in thread
From: Michal Piotrowski @ 2006-08-13 22:58 UTC (permalink / raw)
To: Ben Buxton; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel, Dmitry Torokhov
On 14/08/06, Ben Buxton <kernel@bb.cactii.net> wrote:
> Andrew Morton <akpm@osdl.org> uttered the following thing:
> > On Sun, 13 Aug 2006 13:45:35 +0200
> > Maciej Rutecki <maciej.rutecki@gmail.com> wrote:
> >
> > > Andrew Morton napisa??(a):
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> > >
> > > I have problem with my keyboard. I have no error in dmesg and syslog,
> > > but it doesn't work. I read google and try "i8042.nomux", but it didn't
> > > help.
> > >
> > > I enclose dmesg with "i8042.debug=1" option and my config.
> > >
> > > Maybe I forgot something in config?
> > >
> >
> >
> > Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> > reversion patch, on top of rc4-mm1, thanks.
>
> Acking the same issue. Applied the revert patch and my keyboard now
> works. Also, it turns out that my keyboard is now the only thing that
> failed to resume from S3 on my HP Nc6400, but adding "irqpoll" has fixed
> that for now.
>
> Also, to two other things I spotted with cpufreq. Running
> speedstep-centrino on a Core Duo T2400 (1.83GHz) I see the
> "cpuinfo_max_freq" is 1833000, but "scaling_max_freq" is fixed at 1333000,
> regardless of the governor, and I cannot change it.
>
> Also, whenever I echo anything to "scaling_governor", I get the
> following kernel message:
>
> [ 734.156000] BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug()
> [ 734.156000] [<c013c3ec>] lock_cpu_hotplug+0x7c/0x90
> [ 734.156000] [<c01327f4>] __create_workqueue+0x44/0x140
> [ 734.156000] [<c02dcf7b>] mutex_lock+0xb/0x20
> [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310
> [cpufreq_ondemand]
> [ 734.156000] [<c012f6a5>] notifier_call_chain+0x25/0x40
> [ 734.156000] [<c0274b06>] __cpufreq_governor+0x46/0xe0
> [ 734.156000] [<c0274c84>] __cpufreq_set_policy+0xe4/0x130
> [ 734.156000] [<c0275ae4>] store_scaling_governor+0xd4/0x210
> [ 734.160000] [<c02756a0>] handle_update+0x0/0x10
> [ 734.160000] [<c01e2000>] kobject_get+0x0/0x20
> [ 734.160000] [<c0275a10>] store_scaling_governor+0x0/0x210
> [ 734.160000] [<c027521d>] store+0x3d/0x60
> [ 734.160000] [<c01a2e0c>] sysfs_write_file+0x9c/0xf0
> [ 734.160000] [<c016a8c6>] vfs_write+0xa6/0x160
> [ 734.160000] [<c01a2d70>] sysfs_write_file+0x0/0xf0
> [ 734.160000] [<c016b001>] sys_write+0x41/0x70
> [ 734.160000] [<c0103115>] sysenter_past_esp+0x56/0x79
>
> It seems that scaling still works, but this message is a bit unnerving.
It's known bug.
>
> BB
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 22:44 ` 2.6.18-rc4-mm1 Ben Buxton
2006-08-13 22:58 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-13 23:25 ` Dave Jones
2006-08-14 11:55 ` 2.6.18-rc4-mm1 Ben Buxton
2006-08-14 0:00 ` 2.6.18-rc4-mm1 Dmitry Torokhov
2 siblings, 1 reply; 192+ messages in thread
From: Dave Jones @ 2006-08-13 23:25 UTC (permalink / raw)
To: Ben Buxton; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel, Dmitry Torokhov
On Mon, Aug 14, 2006 at 12:44:13AM +0200, Ben Buxton wrote:
> Also, whenever I echo anything to "scaling_governor", I get the
> following kernel message:
>
> [ 734.156000] BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug()
> [ 734.156000] [<c013c3ec>] lock_cpu_hotplug+0x7c/0x90
> [ 734.156000] [<c01327f4>] __create_workqueue+0x44/0x140
> [ 734.156000] [<c02dcf7b>] mutex_lock+0xb/0x20
> [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310 [cpufreq_ondemand]
This makes no sense at all, because in -mm __create_workqueue doesn't
call lock_cpu_hotplug().
Are you sure this was from a tree with -mm1 applied ?
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 23:25 ` 2.6.18-rc4-mm1 Dave Jones
@ 2006-08-14 11:55 ` Ben Buxton
2006-08-14 20:20 ` 2.6.18-rc4-mm1 Dave Jones
0 siblings, 1 reply; 192+ messages in thread
From: Ben Buxton @ 2006-08-14 11:55 UTC (permalink / raw)
To: Dave Jones, Andrew Morton, Maciej Rutecki, linux-kernel
Dave Jones <davej@redhat.com> uttered the following thing:
> On Mon, Aug 14, 2006 at 12:44:13AM +0200, Ben Buxton wrote:
>
> > Also, whenever I echo anything to "scaling_governor", I get the
> > following kernel message:
> >
> > [ 734.156000] BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug()
> > [ 734.156000] [<c013c3ec>] lock_cpu_hotplug+0x7c/0x90
> > [ 734.156000] [<c01327f4>] __create_workqueue+0x44/0x140
> > [ 734.156000] [<c02dcf7b>] mutex_lock+0xb/0x20
> > [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310 [cpufreq_ondemand]
>
> This makes no sense at all, because in -mm __create_workqueue doesn't
> call lock_cpu_hotplug().
>
> Are you sure this was from a tree with -mm1 applied ?
Definitely 2.6.18-rc4-mm1, and I've done a clean rebuild + removal of
all modules under /lib/modules beforehand.
BB
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 11:55 ` 2.6.18-rc4-mm1 Ben Buxton
@ 2006-08-14 20:20 ` Dave Jones
2006-08-14 21:13 ` 2.6.18-rc4-mm1 Ben B
2006-08-14 21:46 ` 2.6.18-rc4-mm1 Andrew Morton
0 siblings, 2 replies; 192+ messages in thread
From: Dave Jones @ 2006-08-14 20:20 UTC (permalink / raw)
To: Ben Buxton; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
On Mon, Aug 14, 2006 at 01:55:56PM +0200, Ben Buxton wrote:
> > > Also, whenever I echo anything to "scaling_governor", I get the
> > > following kernel message:
> > >
> > > [ 734.156000] BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug()
> > > [ 734.156000] [<c013c3ec>] lock_cpu_hotplug+0x7c/0x90
> > > [ 734.156000] [<c01327f4>] __create_workqueue+0x44/0x140
> > > [ 734.156000] [<c02dcf7b>] mutex_lock+0xb/0x20
> > > [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310 [cpufreq_ondemand]
> >
> > This makes no sense at all, because in -mm __create_workqueue doesn't
> > call lock_cpu_hotplug().
> >
> > Are you sure this was from a tree with -mm1 applied ?
>
> Definitely 2.6.18-rc4-mm1, and I've done a clean rebuild + removal of
> all modules under /lib/modules beforehand.
It's a real mystery. Andrew ?
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 20:20 ` 2.6.18-rc4-mm1 Dave Jones
@ 2006-08-14 21:13 ` Ben B
2006-08-14 21:22 ` 2.6.18-rc4-mm1 Dave Jones
2006-08-14 21:46 ` 2.6.18-rc4-mm1 Andrew Morton
1 sibling, 1 reply; 192+ messages in thread
From: Ben B @ 2006-08-14 21:13 UTC (permalink / raw)
To: Dave Jones, Andrew Morton, Maciej Rutecki, linux-kernel
Dave Jones <davej@redhat.com> uttered the following thing:
> > > > [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310 [cpufreq_ondemand]
> > >
> > > This makes no sense at all, because in -mm __create_workqueue doesn't
> > > call lock_cpu_hotplug().
> > >
> > > Are you sure this was from a tree with -mm1 applied ?
> >
> > Definitely 2.6.18-rc4-mm1, and I've done a clean rebuild + removal of
> > all modules under /lib/modules beforehand.
>
> It's a real mystery. Andrew ?
This seems to be specific to the ondemand governor - I just tried with
conservative, and alternating it with performance, with no problems, but
as soon as I loaded ondemand, the message appeared. It seems to fire off
the message as soon as I either set the governor to ondemand, or revert
it from ondemand to something else. But going from, eg performance to
conservative, wont give the message, even with ondemand loaded.
I wonder if this might also be related to my 1.83GHz cpu only being set
to a maximum of 1.33GHz via cpufreq? cpuinfo_max_freq is correct, but
scaling_max_freq is wrong. Though doing "cat cpuinfo_max_freq >
scaling_max_freq" has fixed it up, it should be correct already.
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2400 @ 1.83GHz
stepping : 8
cpu MHz : 1000.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni
monitor
vmx est tm2 xtpr
bogomips : 3667.27
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2400 @ 1.83GHz
stepping : 8
cpu MHz : 1333.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni
monitor
vmx est tm2 xtpr
bogomips : 3657.79
Ben
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 21:13 ` 2.6.18-rc4-mm1 Ben B
@ 2006-08-14 21:22 ` Dave Jones
0 siblings, 0 replies; 192+ messages in thread
From: Dave Jones @ 2006-08-14 21:22 UTC (permalink / raw)
To: Ben B; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
On Mon, Aug 14, 2006 at 11:13:38PM +0200, Ben B wrote:
> Dave Jones <davej@redhat.com> uttered the following thing:
> > > > > [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310 [cpufreq_ondemand]
> > > >
> > > > This makes no sense at all, because in -mm __create_workqueue doesn't
> > > > call lock_cpu_hotplug().
> > > >
> > > > Are you sure this was from a tree with -mm1 applied ?
> > >
> > > Definitely 2.6.18-rc4-mm1, and I've done a clean rebuild + removal of
> > > all modules under /lib/modules beforehand.
> >
> > It's a real mystery. Andrew ?
>
> This seems to be specific to the ondemand governor - I just tried with
> conservative, and alternating it with performance, with no problems, but
> as soon as I loaded ondemand, the message appeared. It seems to fire off
> the message as soon as I either set the governor to ondemand, or revert
> it from ondemand to something else. But going from, eg performance to
> conservative, wont give the message, even with ondemand loaded.
on-demand is unique in the sense that its the only governor that
creates a workqueue.
> I wonder if this might also be related to my 1.83GHz cpu only being set
> to a maximum of 1.33GHz via cpufreq? cpuinfo_max_freq is correct, but
> scaling_max_freq is wrong. Though doing "cat cpuinfo_max_freq >
> scaling_max_freq" has fixed it up, it should be correct already.
That's come up a lot lately. I'm still of the opinion that something
changed in acpi that's the explanation for this.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 20:20 ` 2.6.18-rc4-mm1 Dave Jones
2006-08-14 21:13 ` 2.6.18-rc4-mm1 Ben B
@ 2006-08-14 21:46 ` Andrew Morton
1 sibling, 0 replies; 192+ messages in thread
From: Andrew Morton @ 2006-08-14 21:46 UTC (permalink / raw)
To: Dave Jones; +Cc: Ben Buxton, Maciej Rutecki, linux-kernel
On Mon, 14 Aug 2006 16:20:04 -0400
Dave Jones <davej@redhat.com> wrote:
> On Mon, Aug 14, 2006 at 01:55:56PM +0200, Ben Buxton wrote:
>
> > > > Also, whenever I echo anything to "scaling_governor", I get the
> > > > following kernel message:
> > > >
> > > > [ 734.156000] BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug()
> > > > [ 734.156000] [<c013c3ec>] lock_cpu_hotplug+0x7c/0x90
> > > > [ 734.156000] [<c01327f4>] __create_workqueue+0x44/0x140
> > > > [ 734.156000] [<c02dcf7b>] mutex_lock+0xb/0x20
> > > > [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310 [cpufreq_ondemand]
> > >
> > > This makes no sense at all, because in -mm __create_workqueue doesn't
> > > call lock_cpu_hotplug().
> > >
> > > Are you sure this was from a tree with -mm1 applied ?
> >
> > Definitely 2.6.18-rc4-mm1, and I've done a clean rebuild + removal of
> > all modules under /lib/modules beforehand.
>
> It's a real mystery. Andrew ?
>
I'm suspecting it's just stack gunk. If Ben could send some more such
traces that'd clear things up. Also, turning on CONFIG_UNWIND_INFO,
CONFIG_STACK_UNWIND and perhaps CONFIG_FRAME_POINTER might give us a
cleaner backtrace.
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 22:44 ` 2.6.18-rc4-mm1 Ben Buxton
2006-08-13 22:58 ` 2.6.18-rc4-mm1 Michal Piotrowski
2006-08-13 23:25 ` 2.6.18-rc4-mm1 Dave Jones
@ 2006-08-14 0:00 ` Dmitry Torokhov
2006-08-14 12:03 ` 2.6.18-rc4-mm1 Ben B
2 siblings, 1 reply; 192+ messages in thread
From: Dmitry Torokhov @ 2006-08-14 0:00 UTC (permalink / raw)
To: Ben Buxton; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
On Sunday 13 August 2006 18:44, Ben Buxton wrote:
> > Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> > reversion patch, on top of rc4-mm1, thanks.
>
> Acking the same issue. Applied the revert patch and my keyboard now
> works. Also, it turns out that my keyboard is now the only thing that
> failed to resume from S3 on my HP Nc6400, but adding "irqpoll" has fixed
> that for now.
>
Can I please have dmesg of booting unpatched -rc4-mm1 with i8042.debug=1?
--
Dmitry
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 0:00 ` 2.6.18-rc4-mm1 Dmitry Torokhov
@ 2006-08-14 12:03 ` Ben B
2006-08-14 13:45 ` 2.6.18-rc4-mm1 Dmitry Torokhov
0 siblings, 1 reply; 192+ messages in thread
From: Ben B @ 2006-08-14 12:03 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
Dmitry Torokhov <dtor@insightbb.com> uttered the following thing:
> On Sunday 13 August 2006 18:44, Ben Buxton wrote:
> > > Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> > > reversion patch, on top of rc4-mm1, thanks.
> >
> > Acking the same issue. Applied the revert patch and my keyboard now
> > works. Also, it turns out that my keyboard is now the only thing that
> > failed to resume from S3 on my HP Nc6400, but adding "irqpoll" has fixed
> > that for now.
> >
>
> Can I please have dmesg of booting unpatched -rc4-mm1 with i8042.debug=1?
I've got masses of these messages - about 100-200 per second filling my
logs. It seems that they came through as such a rate that the dmesg
buffer emptied of everything else before syslogd started.
Aug 14 12:53:23 gromit kernel: [ 23.070229] drivers/input/serio/i8042.c: Interrupt 1, without any data [4669]
Aug 14 12:53:23 gromit kernel: [ 23.070249] drivers/input/serio/i8042.c: Interrupt 12, without any data [4669]
Aug 14 12:53:23 gromit kernel: [ 23.074223] drivers/input/serio/i8042.c: Interrupt 1, without any data [4670]
Aug 14 12:53:23 gromit kernel: [ 23.074243] drivers/input/serio/i8042.c: Interrupt 12, without any data [4670]
Aug 14 12:53:23 gromit kernel: [ 23.078216] drivers/input/serio/i8042.c: Interrupt 1, without any data [4671]
Aug 14 12:53:23 gromit kernel: [ 23.078237] drivers/input/serio/i8042.c: Interrupt 12, without any data [4671]
Aug 14 12:53:23 gromit kernel: [ 23.082210] drivers/input/serio/i8042.c: Interrupt 1, without any data [4672]
I can try to get a full boot log later when I get home.
The interrupt counts don't actually seem to increase, I checked
/proc/interrupts several times in a row and there's no change to the
8042 interrupt counts:
root@gromit:~# cat /proc/interrupts
CPU0 CPU1
0: 66050 0 IO-APIC-edge timer
1: 10 0 IO-APIC-edge i8042
8: 3 0 IO-APIC-edge rtc
9: 10 0 IO-APIC-level acpi
12: 1796 0 IO-APIC-edge i8042
14: 92 0 IO-APIC-edge libata
15: 0 0 IO-APIC-edge libata
58: 1527 5427 PCI-MSI libata
66: 20 0 IO-APIC-level sdhci:slot0, uhci_hcd:usb2
74: 22513 0 IO-APIC-level uhci_hcd:usb1, ehci_hcd:usb5
82: 1366 0 PCI-MSI eth0
177: 13870 0 IO-APIC-level HDA Intel, i915@pci:0000:00:02.0
193: 0 0 IO-APIC-level uhci_hcd:usb4
201: 30 0 IO-APIC-level yenta, uhci_hcd:usb3
NMI: 0 0
LOC: 65373 65374
ERR: 0
MIS: 6
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-14 12:03 ` 2.6.18-rc4-mm1 Ben B
@ 2006-08-14 13:45 ` Dmitry Torokhov
2006-08-14 21:44 ` 2.6.18-rc4-mm1 Ben B
0 siblings, 1 reply; 192+ messages in thread
From: Dmitry Torokhov @ 2006-08-14 13:45 UTC (permalink / raw)
To: Ben B; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
On 8/14/06, Ben B <kernel@bb.cactii.net> wrote:
> Dmitry Torokhov <dtor@insightbb.com> uttered the following thing:
> > On Sunday 13 August 2006 18:44, Ben Buxton wrote:
> > > > Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> > > > reversion patch, on top of rc4-mm1, thanks.
> > >
> > > Acking the same issue. Applied the revert patch and my keyboard now
> > > works. Also, it turns out that my keyboard is now the only thing that
> > > failed to resume from S3 on my HP Nc6400, but adding "irqpoll" has fixed
> > > that for now.
> > >
> >
> > Can I please have dmesg of booting unpatched -rc4-mm1 with i8042.debug=1?
>
> I've got masses of these messages - about 100-200 per second filling my
> logs. It seems that they came through as such a rate that the dmesg
> buffer emptied of everything else before syslogd started.
>
> Aug 14 12:53:23 gromit kernel: [ 23.070229] drivers/input/serio/i8042.c: Interrupt 1, without any data [4669]
> Aug 14 12:53:23 gromit kernel: [ 23.070249] drivers/input/serio/i8042.c: Interrupt 12, without any data [4669]
> Aug 14 12:53:23 gromit kernel: [ 23.074223] drivers/input/serio/i8042.c: Interrupt 1, without any data [4670]
> Aug 14 12:53:23 gromit kernel: [ 23.074243] drivers/input/serio/i8042.c: Interrupt 12, without any data [4670]
> Aug 14 12:53:23 gromit kernel: [ 23.078216] drivers/input/serio/i8042.c: Interrupt 1, without any data [4671]
> Aug 14 12:53:23 gromit kernel: [ 23.078237] drivers/input/serio/i8042.c: Interrupt 12, without any data [4671]
> Aug 14 12:53:23 gromit kernel: [ 23.082210] drivers/input/serio/i8042.c: Interrupt 1, without any data [4672]
>
> I can try to get a full boot log later when I get home.
>
Please.
> The interrupt counts don't actually seem to increase, I checked
> /proc/interrupts several times in a row and there's no change to the
> 8042 interrupt counts:
>
> root@gromit:~# cat /proc/interrupts
> CPU0 CPU1
> 0: 66050 0 IO-APIC-edge timer
> 1: 10 0 IO-APIC-edge i8042
> 8: 3 0 IO-APIC-edge rtc
> 9: 10 0 IO-APIC-level acpi
> 12: 1796 0 IO-APIC-edge i8042
^^^^^^^
It loos like it does (on AUX port)
--
Dmitry
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-14 13:45 ` 2.6.18-rc4-mm1 Dmitry Torokhov
@ 2006-08-14 21:44 ` Ben B
2006-08-15 2:23 ` 2.6.18-rc4-mm1 Dmitry Torokhov
0 siblings, 1 reply; 192+ messages in thread
From: Ben B @ 2006-08-14 21:44 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
Dmitry Torokhov <dmitry.torokhov@gmail.com> uttered the following thing:
> On 8/14/06, Ben B <kernel@bb.cactii.net> wrote:
> >I can try to get a full boot log later when I get home.
> >
>
> Please.
It was impossible to get. I set the 'init' kernel option to a dedicated
script to dump dmesg, but even that went way past the messages.
It seems however that I managed to get everything a-ok now, I just
booted with 'i8042.noaux=1' and that seemed to have resolved everything.
This lappy is proving a challenge to get perfect (but I'm getting
there!)
> > 9: 10 0 IO-APIC-level acpi
> > 12: 1796 0 IO-APIC-edge i8042
> ^^^^^^^
>
> It loos like it does (on AUX port)
Fyi, that didn't increment further no matter how much i battered the
kbd or wiggled the touchpad/stick.
Cheers,
BB
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 21:44 ` 2.6.18-rc4-mm1 Ben B
@ 2006-08-15 2:23 ` Dmitry Torokhov
0 siblings, 0 replies; 192+ messages in thread
From: Dmitry Torokhov @ 2006-08-15 2:23 UTC (permalink / raw)
To: Ben B; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
On Monday 14 August 2006 17:44, Ben B wrote:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> uttered the following thing:
> > On 8/14/06, Ben B <kernel@bb.cactii.net> wrote:
> > >I can try to get a full boot log later when I get home.
> > >
> >
> > Please.
>
> It was impossible to get. I set the 'init' kernel option to a dedicated
> script to dump dmesg, but even that went way past the messages.
>
Could you please try increasing the buffer size (using log_buf_len=xxx
option). 131072 shoudl work I think.
Also please try the patch below. Thanks!
--
Dmitry
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---
drivers/input/serio/i8042.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletion(-)
Index: work/drivers/input/serio/i8042.c
===================================================================
--- work.orig/drivers/input/serio/i8042.c
+++ work/drivers/input/serio/i8042.c
@@ -631,8 +631,14 @@ static int __devinit i8042_check_aux(voi
goto out;
if (wait_for_completion_timeout(&i8042_aux_irq_delivered,
- msecs_to_jiffies(250)) == 0)
+ msecs_to_jiffies(250)) == 0) {
+/*
+ * AUX IRQ was never delivered so we need to flush the controller to
+ * get rid of the byte we put there; otherwise keyboard may not work.
+ */
+ i8042_flush();
retval = -1;
+ }
out:
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 19:11 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-13 22:44 ` 2.6.18-rc4-mm1 Ben Buxton
@ 2022-08-14 8:42 ` Maciej Rutecki
2006-08-14 9:12 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
` (2 more replies)
1 sibling, 3 replies; 192+ messages in thread
From: Maciej Rutecki @ 2022-08-14 8:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Dmitry Torokhov
[-- Attachment #1: Type: text/plain, Size: 744 bytes --]
Andrew Morton napisał(a):
> Please always do reply-to-all.
>
Sorry.
>
>
> Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> reversion patch, on top of rc4-mm1, thanks.
>
>
Thanks for help.
I try this patch, keyboard works, but I have other problem. When I try:
echo "standby" > /sys/power/state
system goes to standby, but keyboard stop working and CMOS clock was
corrupted (randomize date and time e.g. Fri Feb 18 2028 13:57:43). So I
must reset computer.
I enclose dmesg with i8042.debug=1 option, config, lsmod and fragment of
syslog, when I tried standby.
Greetings
--
Maciej Rutecki <maciej.rutecki@gmail.com>
http://www.unixy.pl
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
[-- Attachment #2: config-2.6.18-rc4-mm1.gz --]
[-- Type: application/x-gzip, Size: 14622 bytes --]
[-- Attachment #3: dmesg.gz --]
[-- Type: application/x-gzip, Size: 9956 bytes --]
[-- Attachment #4: lsmod_output.txt.gz --]
[-- Type: application/x-gzip, Size: 817 bytes --]
[-- Attachment #5: syslog.gz --]
[-- Type: application/x-gzip, Size: 2717 bytes --]
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2022-08-14 8:42 ` 2.6.18-rc4-mm1 Maciej Rutecki
@ 2006-08-14 9:12 ` Rafael J. Wysocki
2006-08-14 11:35 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-15 0:27 ` Linux Kernel Developer opening Eric Radman
2006-08-17 12:22 ` 2.6.18-rc4-mm1 Andreas Mohr
2 siblings, 1 reply; 192+ messages in thread
From: Rafael J. Wysocki @ 2006-08-14 9:12 UTC (permalink / raw)
To: Maciej Rutecki; +Cc: Andrew Morton, linux-kernel, Dmitry Torokhov
On Sunday 14 August 2022 10:42, Maciej Rutecki wrote:
> Andrew Morton napisał(a):
> > Please always do reply-to-all.
> >
>
> Sorry.
>
> >
> >
> > Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> > reversion patch, on top of rc4-mm1, thanks.
> >
> >
>
> Thanks for help.
>
> I try this patch, keyboard works, but I have other problem. When I try:
>
> echo "standby" > /sys/power/state
>
> system goes to standby, but keyboard stop working and CMOS clock was
> corrupted (randomize date and time e.g. Fri Feb 18 2028 13:57:43). So I
> must reset computer.
To fix the CMOS clock problem please try to unset CONFIG_PM_TRACE .
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 9:12 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
@ 2006-08-14 11:35 ` Maciej Rutecki
0 siblings, 0 replies; 192+ messages in thread
From: Maciej Rutecki @ 2006-08-14 11:35 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Andrew Morton, linux-kernel, Dmitry Torokhov
Rafael J. Wysocki napisał(a):
> On Sunday 14 August 2022 10:42, Maciej Rutecki wrote:
>>
>> I try this patch, keyboard works, but I have other problem. When I try:
>>
>> echo "standby" > /sys/power/state
>>
>> system goes to standby, but keyboard stop working and CMOS clock was
>> corrupted (randomize date and time e.g. Fri Feb 18 2028 13:57:43). So I
>> must reset computer.
>
> To fix the CMOS clock problem please try to unset CONFIG_PM_TRACE .
Thanks for help, CMOS clock works correct now. But still is problem with
keyboard after standby.
Greetings
--
Maciej Rutecki <maciej.rutecki@gmail.com>
http://www.unixy.pl
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 192+ messages in thread
* Linux Kernel Developer opening
2022-08-14 8:42 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-14 9:12 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
@ 2006-08-15 0:27 ` Eric Radman
2006-08-17 12:22 ` 2.6.18-rc4-mm1 Andreas Mohr
2 siblings, 0 replies; 192+ messages in thread
From: Eric Radman @ 2006-08-15 0:27 UTC (permalink / raw)
To: Maciej Rutecki, Andrew Morton; +Cc: linux-kernel
Has anyone seen this listing?
go to www.hotjobs.com and search
on the keyword 51506Linux
--- Maciej Rutecki <maciej.rutecki@gmail.com> wrote:
> Andrew Morton napisał(a):
> > Please always do reply-to-all.
> >
>
> Sorry.
>
> >
> >
> > Could be i8042-get-rid-of-polling-timer-v4.patch.
> Please try the below
> > reversion patch, on top of rc4-mm1, thanks.
> >
> >
>
> Thanks for help.
>
> I try this patch, keyboard works, but I have other
> problem. When I try:
>
> echo "standby" > /sys/power/state
>
> system goes to standby, but keyboard stop working
> and CMOS clock was
> corrupted (randomize date and time e.g. Fri Feb 18
> 2028 13:57:43). So I
> must reset computer.
>
> I enclose dmesg with i8042.debug=1 option, config,
> lsmod and fragment of
> syslog, when I tried standby.
>
> Greetings
> --
> Maciej Rutecki <maciej.rutecki@gmail.com>
> http://www.unixy.pl
> LTG - Linux Testers Group
> (http://www.stardust.webpages.pl/ltg/wiki/)
>
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2022-08-14 8:42 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-14 9:12 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
2006-08-15 0:27 ` Linux Kernel Developer opening Eric Radman
@ 2006-08-17 12:22 ` Andreas Mohr
2006-08-18 10:30 ` 2.6.18-rc4-mm1 Andy Whitcroft
2 siblings, 1 reply; 192+ messages in thread
From: Andreas Mohr @ 2006-08-17 12:22 UTC (permalink / raw)
To: Maciej Rutecki; +Cc: Andrew Morton, linux-kernel, Dmitry Torokhov
Hi,
On Sun, Aug 14, 2022 at 10:42:18AM +0200, Maciej Rutecki wrote:
> Andrew Morton napisa??(a):
> > Please always do reply-to-all.
> >
>
> Sorry.
>
> >
> >
> > Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> > reversion patch, on top of rc4-mm1, thanks.
> >
> >
>
> Thanks for help.
>
> I try this patch, keyboard works, but I have other problem. When I try:
>
> echo "standby" > /sys/power/state
>
> system goes to standby, but keyboard stop working and CMOS clock was
> corrupted (randomize date and time e.g. Fri Feb 18 2028 13:57:43). So I
> must reset computer.
Thou shalt Not enable no dangerous CMOS corrupting suspend debugging configs ;)
No idea whether "corrupting" the CMOS content with suspend debugging data
has any influence on the keyboard resume, though, but it could easily have.
Andreas Mohr
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-17 12:22 ` 2.6.18-rc4-mm1 Andreas Mohr
@ 2006-08-18 10:30 ` Andy Whitcroft
0 siblings, 0 replies; 192+ messages in thread
From: Andy Whitcroft @ 2006-08-18 10:30 UTC (permalink / raw)
To: Andreas Mohr; +Cc: Maciej Rutecki, Andrew Morton, linux-kernel, Dmitry Torokhov
Andreas Mohr wrote:
> Hi,
>
> On Sun, Aug 14, 2022 at 10:42:18AM +0200, Maciej Rutecki wrote:
>> Andrew Morton napisa??(a):
>>> Please always do reply-to-all.
>>>
>> Sorry.
>>
>>>
>>> Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
>>> reversion patch, on top of rc4-mm1, thanks.
>>>
>>>
>> Thanks for help.
>>
>> I try this patch, keyboard works, but I have other problem. When I try:
>>
>> echo "standby" > /sys/power/state
>>
>> system goes to standby, but keyboard stop working and CMOS clock was
>> corrupted (randomize date and time e.g. Fri Feb 18 2028 13:57:43). So I
>> must reset computer.
>
> Thou shalt Not enable no dangerous CMOS corrupting suspend debugging configs ;)
>
> No idea whether "corrupting" the CMOS content with suspend debugging data
> has any influence on the keyboard resume, though, but it could easily have.
If my memory is working correctly, the CMOS and keyboard etc are all out
there on that primative (XC?) bus, off a sort of ISA spur, off the first
PCI bus? So they may be 'near' in address terms.
Anyone got one of those old diagrams?
-apw
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 11:45 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-13 19:11 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-13 23:58 ` Dmitry Torokhov
[not found] ` <d120d5000608140643tddd9ce4o986560740ef5dbd7@mail.gmail.com>
1 sibling, 1 reply; 192+ messages in thread
From: Dmitry Torokhov @ 2006-08-13 23:58 UTC (permalink / raw)
To: Maciej Rutecki; +Cc: linux-kernel
On Sunday 13 August 2006 07:45, Maciej Rutecki wrote:
> Andrew Morton napisał(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> I have problem with my keyboard. I have no error in dmesg and syslog,
> but it doesn't work. I read google and try "i8042.nomux", but it didn't
> help.
>
> I enclose dmesg with "i8042.debug=1" option and my config.
>
> Maybe I forgot something in config?
>
You have keyboard configured as a module in your .config but I do not
see it trying to attach to the keyboard serio port. Make sure the module
is loaded.
--
Dmitry
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
2006-08-13 11:45 ` 2.6.18-rc4-mm1 Maciej Rutecki
@ 2006-08-13 12:24 ` Michal Piotrowski
2006-08-14 6:36 ` 2.6.18-rc4-mm1 Reuben Farrelly
2006-08-13 12:43 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
` (27 subsequent siblings)
29 siblings, 1 reply; 192+ messages in thread
From: Michal Piotrowski @ 2006-08-13 12:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: Ingo Molnar, Arjan van de Ven, linux-kernel
On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> - Warning: all the Serial ATA Kconfig options have been renamed. If you
> blindly run `make oldconfig' you won't have any disks.
>
MAX_STACK_TRACE_ENTRIES too low!
What does it mean?
BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.
[<c0103e41>] dump_trace+0x70/0x176
[<c0103fc1>] show_trace_log_lvl+0x12/0x22
[<c0103fde>] show_trace+0xd/0xf
[<c01040b0>] dump_stack+0x17/0x19
[<c0138f30>] save_trace+0xce/0xd7
[<c0139370>] add_lock_to_list+0x22/0x39
[<c0139b3c>] check_prev_add+0x139/0x1b4
[<c0139c04>] check_prevs_add+0x4d/0xaf
[<c013b646>] __lock_acquire+0x8a1/0x93c
[<c013bd4c>] lock_acquire+0x6f/0x8f
[<c03033e8>] _spin_lock_irq+0x29/0x35
[<c01ed022>] __make_request+0x68/0x413
[<c01ed6a7>] generic_make_request+0x273/0x2a4
[<c01ed802>] submit_bio+0x12a/0x132
[<c017b6f6>] submit_bh+0x10e/0x12e
[<c0179fd3>] __block_write_full_page+0x231/0x326
[<c017b567>] block_write_full_page+0xd7/0xdf
[<c017e17a>] blkdev_writepage+0xf/0x11
[<c0199d92>] mpage_writepages+0x1b6/0x324
[<c017f3ee>] generic_writepages+0xa/0xc
[<c015b6b5>] do_writepages+0x23/0x36
[<c019871c>] __sync_single_inode+0x7b/0x199
[<c01989ac>] __writeback_single_inode+0x172/0x17a
[<c0198b50>] generic_sync_sb_inodes+0x19c/0x242
[<c0198c13>] sync_sb_inodes+0x1d/0x20
[<c0198c8e>] writeback_inodes+0x78/0xae
[<c015b52b>] wb_kupdate+0x7c/0xdd
[<c015bf14>] __pdflush+0xcc/0x163
[<c015bfdd>] pdflush+0x32/0x34
[<c01347a9>] kthread+0x82/0xaa
[<c0303dfd>] kernel_thread_helper+0x5/0xb
[<c0103fc1>] show_trace_log_lvl+0x12/0x22
[<c0103fde>] show_trace+0xd/0xf
[<c01040b0>] dump_stack+0x17/0x19
[<c0138f30>] save_trace+0xce/0xd7
[<c0139370>] add_lock_to_list+0x22/0x39
[<c0139b3c>] check_prev_add+0x139/0x1b4
[<c0139c04>] check_prevs_add+0x4d/0xaf
[<c013b646>] __lock_acquire+0x8a1/0x93c
[<c013bd4c>] lock_acquire+0x6f/0x8f
[<c03033e8>] _spin_lock_irq+0x29/0x35
[<c01ed022>] __make_request+0x68/0x413
[<c01ed6a7>] generic_make_request+0x273/0x2a4
[<c01ed802>] submit_bio+0x12a/0x132
[<c017b6f6>] submit_bh+0x10e/0x12e
[<c0179fd3>] __block_write_full_page+0x231/0x326
[<c017b567>] block_write_full_page+0xd7/0xdf
[<c017e17a>] blkdev_writepage+0xf/0x11
[<c0199d92>] mpage_writepages+0x1b6/0x324
[<c017f3ee>] generic_writepages+0xa/0xc
[<c015b6b5>] do_writepages+0x23/0x36
[<c019871c>] __sync_single_inode+0x7b/0x199
[<c01989ac>] __writeback_single_inode+0x172/0x17a
[<c0198b50>] generic_sync_sb_inodes+0x19c/0x242
[<c0198c13>] sync_sb_inodes+0x1d/0x20
[<c0198c8e>] writeback_inodes+0x78/0xae
[<c015b52b>] wb_kupdate+0x7c/0xdd
[<c015bf14>] __pdflush+0xcc/0x163
[<c015bfdd>] pdflush+0x32/0x34
[<c01347a9>] kthread+0x82/0xaa
[<c0303dfd>] kernel_thread_helper+0x5/0xb
=======================
config & dmesg http://www.stardust.webpages.pl/files/mm/2.6.18-rc4-mm1/frontline/
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-13 12:24 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 6:36 ` Reuben Farrelly
2006-08-14 9:06 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
0 siblings, 1 reply; 192+ messages in thread
From: Reuben Farrelly @ 2006-08-14 6:36 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Ingo Molnar, Arjan van de Ven, linux-kernel, Andrew Morton
On 14/08/2006 12:24 a.m., Michal Piotrowski wrote:
> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>>
>>
>> - Warning: all the Serial ATA Kconfig options have been renamed. If you
>> blindly run `make oldconfig' you won't have any disks.
>>
>
> MAX_STACK_TRACE_ENTRIES too low!
>
> What does it mean?
>
> BUG: MAX_STACK_TRACE_ENTRIES too low!
> turning off the locking correctness validator.
> [<c0103e41>] dump_trace+0x70/0x176
> [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> [<c0103fde>] show_trace+0xd/0xf
> [<c01040b0>] dump_stack+0x17/0x19
> [<c0138f30>] save_trace+0xce/0xd7
> [<c0139370>] add_lock_to_list+0x22/0x39
> [<c0139b3c>] check_prev_add+0x139/0x1b4
> [<c0139c04>] check_prevs_add+0x4d/0xaf
> [<c013b646>] __lock_acquire+0x8a1/0x93c
> [<c013bd4c>] lock_acquire+0x6f/0x8f
> [<c03033e8>] _spin_lock_irq+0x29/0x35
> [<c01ed022>] __make_request+0x68/0x413
> [<c01ed6a7>] generic_make_request+0x273/0x2a4
> [<c01ed802>] submit_bio+0x12a/0x132
> [<c017b6f6>] submit_bh+0x10e/0x12e
> [<c0179fd3>] __block_write_full_page+0x231/0x326
> [<c017b567>] block_write_full_page+0xd7/0xdf
> [<c017e17a>] blkdev_writepage+0xf/0x11
> [<c0199d92>] mpage_writepages+0x1b6/0x324
> [<c017f3ee>] generic_writepages+0xa/0xc
> [<c015b6b5>] do_writepages+0x23/0x36
> [<c019871c>] __sync_single_inode+0x7b/0x199
> [<c01989ac>] __writeback_single_inode+0x172/0x17a
> [<c0198b50>] generic_sync_sb_inodes+0x19c/0x242
> [<c0198c13>] sync_sb_inodes+0x1d/0x20
> [<c0198c8e>] writeback_inodes+0x78/0xae
> [<c015b52b>] wb_kupdate+0x7c/0xdd
> [<c015bf14>] __pdflush+0xcc/0x163
> [<c015bfdd>] pdflush+0x32/0x34
> [<c01347a9>] kthread+0x82/0xaa
> [<c0303dfd>] kernel_thread_helper+0x5/0xb
> [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> [<c0103fde>] show_trace+0xd/0xf
> [<c01040b0>] dump_stack+0x17/0x19
> [<c0138f30>] save_trace+0xce/0xd7
> [<c0139370>] add_lock_to_list+0x22/0x39
> [<c0139b3c>] check_prev_add+0x139/0x1b4
> [<c0139c04>] check_prevs_add+0x4d/0xaf
> [<c013b646>] __lock_acquire+0x8a1/0x93c
> [<c013bd4c>] lock_acquire+0x6f/0x8f
> [<c03033e8>] _spin_lock_irq+0x29/0x35
> [<c01ed022>] __make_request+0x68/0x413
> [<c01ed6a7>] generic_make_request+0x273/0x2a4
> [<c01ed802>] submit_bio+0x12a/0x132
> [<c017b6f6>] submit_bh+0x10e/0x12e
> [<c0179fd3>] __block_write_full_page+0x231/0x326
> [<c017b567>] block_write_full_page+0xd7/0xdf
> [<c017e17a>] blkdev_writepage+0xf/0x11
> [<c0199d92>] mpage_writepages+0x1b6/0x324
> [<c017f3ee>] generic_writepages+0xa/0xc
> [<c015b6b5>] do_writepages+0x23/0x36
> [<c019871c>] __sync_single_inode+0x7b/0x199
> [<c01989ac>] __writeback_single_inode+0x172/0x17a
> [<c0198b50>] generic_sync_sb_inodes+0x19c/0x242
> [<c0198c13>] sync_sb_inodes+0x1d/0x20
> [<c0198c8e>] writeback_inodes+0x78/0xae
> [<c015b52b>] wb_kupdate+0x7c/0xdd
> [<c015bf14>] __pdflush+0xcc/0x163
> [<c015bfdd>] pdflush+0x32/0x34
> [<c01347a9>] kthread+0x82/0xaa
> [<c0303dfd>] kernel_thread_helper+0x5/0xb
> =======================
>
> config & dmesg
> http://www.stardust.webpages.pl/files/mm/2.6.18-rc4-mm1/frontline/
>
> Regards,
> Michal
Seeing this message here as well, which I guess is the same thing even though
the trace is a bit different.
IPv6 over IPv4 tunneling driver
eth0: no IPv6 routers present
BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.
Call Trace:
[<ffffffff8026cdfe>] dump_trace+0xbe/0x3a0
[<ffffffff8026d11c>] show_trace+0x3c/0x55
[<ffffffff8026d14a>] dump_stack+0x15/0x1b
[<ffffffff8029bec6>] save_trace+0xd6/0xe3
[<ffffffff8029bf55>] add_lock_to_list+0x82/0xab
[<ffffffff8029e720>] __lock_acquire+0xad0/0xc78
[<ffffffff8029e917>] lock_acquire+0x4f/0x78
[<ffffffff80268698>] _spin_lock+0x25/0x34
[<ffffffff803ff699>] ata_scsi_queuecmd+0x39/0x16a
[<ffffffff803e7fb7>] scsi_dispatch_cmd+0x1f7/0x250
[<ffffffff803ecbd6>] scsi_request_fn+0x296/0x380
[<ffffffff8035f7b2>] __generic_unplug_device+0x28/0x2f
[<ffffffff8025ea4b>] generic_unplug_device+0x25/0x38
[<ffffffff80261a4b>] blk_backing_dev_unplug+0x16/0x1b
[<ffffffff80215aa9>] sync_buffer+0x39/0x42
[<ffffffff80266951>] __wait_on_bit+0x45/0x79
[<ffffffff802669f4>] out_of_line_wait_on_bit+0x6f/0x8b
[<ffffffff8024c49a>] __wait_on_buffer+0x20/0x22
[<ffffffff8023c790>] sync_dirty_buffer+0x90/0xd0
[<ffffffff803329e9>] journal_update_superblock+0x89/0xd6
[<ffffffff80330e01>] cleanup_journal_tail+0x121/0x132
[<ffffffff80330eec>] log_do_checkpoint+0x1c/0x47b
[<ffffffff803314ae>] __log_wait_for_space+0x9a/0xc0
[<ffffffff8032d84b>] start_this_handle+0x1fb/0x46a
[<ffffffff8032db95>] journal_start+0xdb/0x116
[<ffffffff80325a4a>] ext3_journal_start_sb+0x4a/0x4c
[<ffffffff8032067e>] ext3_dirty_inode+0x31/0x93
[<ffffffff802140fe>] __mark_inode_dirty+0x2e/0x19f
[<ffffffff8020bd2c>] touch_atime+0x9c/0xa3
[<ffffffff80222464>] generic_file_mmap+0x39/0x4f
[<ffffffff8020e5e5>] do_mmap_pgoff+0x4b5/0x7b5
[<ffffffff802241a1>] sys_mmap+0x94/0xcf
[<ffffffff802625fe>] system_call+0x7e/0x83
[<00002b03387e4e0a>]
[<ffffffff8029bec6>] save_trace+0xd6/0xe3
[<ffffffff8029bf55>] add_lock_to_list+0x82/0xab
[<ffffffff8029e720>] __lock_acquire+0xad0/0xc78
[<ffffffff803e7841>] scsi_done+0x0/0x24
[<ffffffff8029e917>] lock_acquire+0x4f/0x78
[<ffffffff803ff699>] ata_scsi_queuecmd+0x39/0x16a
[<ffffffff80268698>] _spin_lock+0x25/0x34
[<ffffffff803ff699>] ata_scsi_queuecmd+0x39/0x16a
[<ffffffff803e7fb7>] scsi_dispatch_cmd+0x1f7/0x250
[<ffffffff803ecbd6>] scsi_request_fn+0x296/0x380
[<ffffffff8035f7b2>] __generic_unplug_device+0x28/0x2f
[<ffffffff8025ea4b>] generic_unplug_device+0x25/0x38
[<ffffffff80261a4b>] blk_backing_dev_unplug+0x16/0x1b
[<ffffffff80215aa9>] sync_buffer+0x39/0x42
[<ffffffff80266951>] __wait_on_bit+0x45/0x79
[<ffffffff80215a70>] sync_buffer+0x0/0x42
[<ffffffff80215a70>] sync_buffer+0x0/0x42
[<ffffffff802669f4>] out_of_line_wait_on_bit+0x6f/0x8b
[<ffffffff80298270>] wake_bit_function+0x0/0x31
[<ffffffff8024c49a>] __wait_on_buffer+0x20/0x22
[<ffffffff8023c790>] sync_dirty_buffer+0x90/0xd0
[<ffffffff803329e9>] journal_update_superblock+0x89/0xd6
[<ffffffff80330e01>] cleanup_journal_tail+0x121/0x132
[<ffffffff80330eec>] log_do_checkpoint+0x1c/0x47b
[<ffffffff8029dc25>] check_noncircular+0x95/0xc0
[<ffffffff8029dc25>] check_noncircular+0x95/0xc0
[<ffffffff8029dc25>] check_noncircular+0x95/0xc0
[<ffffffff8029cf5d>] find_usage_backwards+0x7a/0xa1
[<ffffffff8029d91c>] check_usage+0x35/0x2a9
[<ffffffff8029e67d>] __lock_acquire+0xa2d/0xc78
[<ffffffff803314ae>] __log_wait_for_space+0x9a/0xc0
[<ffffffff8032d84b>] start_this_handle+0x1fb/0x46a
[<ffffffff8020a649>] kmem_cache_alloc+0xb9/0xd0
[<ffffffff8032db95>] journal_start+0xdb/0x116
[<ffffffff80325a4a>] ext3_journal_start_sb+0x4a/0x4c
[<ffffffff8032067e>] ext3_dirty_inode+0x31/0x93
[<ffffffff802140fe>] __mark_inode_dirty+0x2e/0x19f
[<ffffffff80222421>] dbg_redzone1+0x1d/0x27
[<ffffffff8020bd2c>] touch_atime+0x9c/0xa3
[<ffffffff80222464>] generic_file_mmap+0x39/0x4f
[<ffffffff8020e5e5>] do_mmap_pgoff+0x4b5/0x7b5
[<ffffffff8026899f>] _spin_unlock_irq+0x2b/0x33
[<ffffffff802241a1>] sys_mmap+0x94/0xcf
[<ffffffff802625fe>] system_call+0x7e/0x83
Can someone take a look at this too, please?
Reuben
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 6:36 ` 2.6.18-rc4-mm1 Reuben Farrelly
@ 2006-08-14 9:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 192+ messages in thread
From: Rafael J. Wysocki @ 2006-08-14 9:06 UTC (permalink / raw)
To: Reuben Farrelly
Cc: Michal Piotrowski, Ingo Molnar, Arjan van de Ven, linux-kernel,
Andrew Morton
On Monday 14 August 2006 08:36, Reuben Farrelly wrote:
> On 14/08/2006 12:24 a.m., Michal Piotrowski wrote:
> > On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
> >>
> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >>
> >>
> >> - Warning: all the Serial ATA Kconfig options have been renamed. If you
> >> blindly run `make oldconfig' you won't have any disks.
> >>
> >
> > MAX_STACK_TRACE_ENTRIES too low!
> >
> > What does it mean?
> >
> > BUG: MAX_STACK_TRACE_ENTRIES too low!
> > turning off the locking correctness validator.
> > [<c0103e41>] dump_trace+0x70/0x176
> > [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> > [<c0103fde>] show_trace+0xd/0xf
> > [<c01040b0>] dump_stack+0x17/0x19
> > [<c0138f30>] save_trace+0xce/0xd7
> > [<c0139370>] add_lock_to_list+0x22/0x39
> > [<c0139b3c>] check_prev_add+0x139/0x1b4
> > [<c0139c04>] check_prevs_add+0x4d/0xaf
> > [<c013b646>] __lock_acquire+0x8a1/0x93c
> > [<c013bd4c>] lock_acquire+0x6f/0x8f
> > [<c03033e8>] _spin_lock_irq+0x29/0x35
> > [<c01ed022>] __make_request+0x68/0x413
> > [<c01ed6a7>] generic_make_request+0x273/0x2a4
> > [<c01ed802>] submit_bio+0x12a/0x132
> > [<c017b6f6>] submit_bh+0x10e/0x12e
> > [<c0179fd3>] __block_write_full_page+0x231/0x326
> > [<c017b567>] block_write_full_page+0xd7/0xdf
> > [<c017e17a>] blkdev_writepage+0xf/0x11
> > [<c0199d92>] mpage_writepages+0x1b6/0x324
> > [<c017f3ee>] generic_writepages+0xa/0xc
> > [<c015b6b5>] do_writepages+0x23/0x36
> > [<c019871c>] __sync_single_inode+0x7b/0x199
> > [<c01989ac>] __writeback_single_inode+0x172/0x17a
> > [<c0198b50>] generic_sync_sb_inodes+0x19c/0x242
> > [<c0198c13>] sync_sb_inodes+0x1d/0x20
> > [<c0198c8e>] writeback_inodes+0x78/0xae
> > [<c015b52b>] wb_kupdate+0x7c/0xdd
> > [<c015bf14>] __pdflush+0xcc/0x163
> > [<c015bfdd>] pdflush+0x32/0x34
> > [<c01347a9>] kthread+0x82/0xaa
> > [<c0303dfd>] kernel_thread_helper+0x5/0xb
> > [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> > [<c0103fde>] show_trace+0xd/0xf
> > [<c01040b0>] dump_stack+0x17/0x19
> > [<c0138f30>] save_trace+0xce/0xd7
> > [<c0139370>] add_lock_to_list+0x22/0x39
> > [<c0139b3c>] check_prev_add+0x139/0x1b4
> > [<c0139c04>] check_prevs_add+0x4d/0xaf
> > [<c013b646>] __lock_acquire+0x8a1/0x93c
> > [<c013bd4c>] lock_acquire+0x6f/0x8f
> > [<c03033e8>] _spin_lock_irq+0x29/0x35
> > [<c01ed022>] __make_request+0x68/0x413
> > [<c01ed6a7>] generic_make_request+0x273/0x2a4
> > [<c01ed802>] submit_bio+0x12a/0x132
> > [<c017b6f6>] submit_bh+0x10e/0x12e
> > [<c0179fd3>] __block_write_full_page+0x231/0x326
> > [<c017b567>] block_write_full_page+0xd7/0xdf
> > [<c017e17a>] blkdev_writepage+0xf/0x11
> > [<c0199d92>] mpage_writepages+0x1b6/0x324
> > [<c017f3ee>] generic_writepages+0xa/0xc
> > [<c015b6b5>] do_writepages+0x23/0x36
> > [<c019871c>] __sync_single_inode+0x7b/0x199
> > [<c01989ac>] __writeback_single_inode+0x172/0x17a
> > [<c0198b50>] generic_sync_sb_inodes+0x19c/0x242
> > [<c0198c13>] sync_sb_inodes+0x1d/0x20
> > [<c0198c8e>] writeback_inodes+0x78/0xae
> > [<c015b52b>] wb_kupdate+0x7c/0xdd
> > [<c015bf14>] __pdflush+0xcc/0x163
> > [<c015bfdd>] pdflush+0x32/0x34
> > [<c01347a9>] kthread+0x82/0xaa
> > [<c0303dfd>] kernel_thread_helper+0x5/0xb
> > =======================
> >
> > config & dmesg
> > http://www.stardust.webpages.pl/files/mm/2.6.18-rc4-mm1/frontline/
> >
> > Regards,
> > Michal
>
> Seeing this message here as well, which I guess is the same thing even though
> the trace is a bit different.
I'm seeing these too, on x86_64:
PM: Adding info for No Bus:vcs7
PM: Adding info for No Bus:vcsa7
hdb: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.
Call Trace:
[<ffffffff8020b0d9>] dump_trace+0x99/0x3b0
[<ffffffff8020b433>] show_trace+0x43/0x60
[<ffffffff8020b735>] dump_stack+0x15/0x20
[<ffffffff802484d6>] save_trace+0xd6/0xf0
[<ffffffff80248601>] add_lock_to_list+0x91/0xc0
[<ffffffff8024a861>] __lock_acquire+0xb01/0xd30
[<ffffffff8024ae2b>] lock_acquire+0x8b/0xc0
[<ffffffff8047259f>] _spin_lock+0x2f/0x40
[<ffffffff802889a2>] cache_alloc_refill+0xa2/0x7f0
[<ffffffff802888a7>] kmem_cache_alloc+0x77/0xd0
[<ffffffff804349ce>] inet_twsk_alloc+0x2e/0x140
[<ffffffff8044a404>] tcp_time_wait+0x64/0x350
[<ffffffff8043ba5e>] tcp_fin+0xde/0x1f0
[<ffffffff8043efa5>] tcp_data_queue+0x2c5/0xbf0
[<ffffffff804405b8>] tcp_rcv_state_process+0xce8/0xd80
[<ffffffff804486f4>] tcp_v4_do_rcv+0x334/0x390
[<ffffffff804496e7>] tcp_v4_rcv+0x8f7/0x960
[<ffffffff8042c44a>] ip_local_deliver+0x19a/0x250
[<ffffffff8042c9a4>] ip_rcv+0x4a4/0x4f0
[<ffffffff8040ded4>] netif_receive_skb+0x314/0x370
[<ffffffff8813b1cf>] :skge:skge_poll+0x43f/0x570
[<ffffffff8040c25a>] net_rx_action+0xba/0x1f0
[<ffffffff80232e40>] __do_softirq+0x70/0xf0
[<ffffffff8020aa7c>] call_softirq+0x1c/0x30
[<ffffffff8020cbcd>] do_softirq+0x3d/0xb0
[<ffffffff80232c9e>] irq_exit+0x4e/0x60
[<ffffffff8020cd75>] do_IRQ+0x135/0x140
[<ffffffff8020a266>] ret_from_intr+0x0/0xf
[<ffffffff802083b2>] default_idle+0x42/0x80
[<ffffffff80208445>] cpu_idle+0x55/0xa0
[<ffffffff8020703a>] rest_init+0x3a/0x40
[<ffffffff8090d81f>] start_kernel+0x24f/0x260
[<ffffffff8090d15f>] _sinittext+0x15f/0x170
<IRQ> [<ffffffff802484d6>] save_trace+0xd6/0xf0
[<ffffffff80248601>] add_lock_to_list+0x91/0xc0
[<ffffffff8024a861>] __lock_acquire+0xb01/0xd30
[<ffffffff8024aed9>] mark_held_locks+0x79/0xa0
[<ffffffff802889a2>] cache_alloc_refill+0xa2/0x7f0
[<ffffffff8024ae2b>] lock_acquire+0x8b/0xc0
[<ffffffff802889a2>] cache_alloc_refill+0xa2/0x7f0
[<ffffffff804349ce>] inet_twsk_alloc+0x2e/0x140
[<ffffffff8047259f>] _spin_lock+0x2f/0x40
[<ffffffff802889a2>] cache_alloc_refill+0xa2/0x7f0
[<ffffffff80287fbf>] check_poison_obj+0x2f/0x1e0
[<ffffffff8028715d>] dbg_redzone1+0x1d/0x30
[<ffffffff804349ce>] inet_twsk_alloc+0x2e/0x140
[<ffffffff802888a7>] kmem_cache_alloc+0x77/0xd0
[<ffffffff804349ce>] inet_twsk_alloc+0x2e/0x140
[<ffffffff8044a404>] tcp_time_wait+0x64/0x350
[<ffffffff8043ba5e>] tcp_fin+0xde/0x1f0
[<ffffffff8043efa5>] tcp_data_queue+0x2c5/0xbf0
[<ffffffff8023723b>] mod_timer+0x2b/0x30
[<ffffffff804405b8>] tcp_rcv_state_process+0xce8/0xd80
[<ffffffff804486f4>] tcp_v4_do_rcv+0x334/0x390
[<ffffffff80449280>] tcp_v4_rcv+0x490/0x960
[<ffffffff804496e7>] tcp_v4_rcv+0x8f7/0x960
[<ffffffff8042c44a>] ip_local_deliver+0x19a/0x250
[<ffffffff8042c9a4>] ip_rcv+0x4a4/0x4f0
[<ffffffff80407797>] kfree_skb+0x27/0x30
[<ffffffff88297634>] :af_packet:packet_rcv_spkt+0x184/0x1a0
[<ffffffff8040ded4>] netif_receive_skb+0x314/0x370
[<ffffffff8813b1cf>] :skge:skge_poll+0x43f/0x570
[<ffffffff8040c25a>] net_rx_action+0xba/0x1f0
[<ffffffff80232e40>] __do_softirq+0x70/0xf0
[<ffffffff8020aa7c>] call_softirq+0x1c/0x30
[<ffffffff8020cbcd>] do_softirq+0x3d/0xb0
[<ffffffff80232c9e>] irq_exit+0x4e/0x60
[<ffffffff8020cd75>] do_IRQ+0x135/0x140
[<ffffffff80208370>] default_idle+0x0/0x80
[<ffffffff8020a266>] ret_from_intr+0x0/0xf
<EOI> [<ffffffff802083b0>] default_idle+0x40/0x80
[<ffffffff802083b2>] default_idle+0x42/0x80
[<ffffffff80208445>] cpu_idle+0x55/0xa0
[<ffffffff8020703a>] rest_init+0x3a/0x40
[<ffffffff8090d81f>] start_kernel+0x24f/0x260
[<ffffffff8090d15f>] _sinittext+0x15f/0x170
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
2006-08-13 11:45 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-13 12:24 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-13 12:43 ` Rafael J. Wysocki
2006-08-13 14:32 ` [patch] fix posix timer errors Frederik Deweerdt
` (26 subsequent siblings)
29 siblings, 0 replies; 192+ messages in thread
From: Rafael J. Wysocki @ 2006-08-13 12:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sunday 13 August 2006 10:24, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> - Warning: all the Serial ATA Kconfig options have been renamed. If you
> blindly run `make oldconfig' you won't have any disks.
Something like the appended patch is needed for the SATA/PATA options to show
up in the menu.
Greetings,
Rafael
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/ata/Kconfig | 8 ++++++++
1 files changed, 8 insertions(+)
Index: linux-2.6.18-rc4-mm1/drivers/ata/Kconfig
===================================================================
--- linux-2.6.18-rc4-mm1.orig/drivers/ata/Kconfig
+++ linux-2.6.18-rc4-mm1/drivers/ata/Kconfig
@@ -1,3 +1,9 @@
+#
+# SATA/PATA driver configuration
+#
+
+menu "Serial and Parallel ATA (SATA/PATA) drivers"
+ depends on SCSI
config ATA
tristate "ATA device support"
@@ -481,3 +487,5 @@ config PATA_WINBOND
If unsure, say N.
+endmenu
+
^ permalink raw reply [flat|nested] 192+ messages in thread* [patch] fix posix timer errors
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (2 preceding siblings ...)
2006-08-13 12:43 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
@ 2006-08-13 14:32 ` Frederik Deweerdt
2006-08-13 17:23 ` Andrew Morton
2006-08-13 15:30 ` [-mm patch] arch/i386/mm/ioremap.c must #include <asm/cacheflush.h> Adrian Bunk
` (25 subsequent siblings)
29 siblings, 1 reply; 192+ messages in thread
From: Frederik Deweerdt @ 2006-08-13 14:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, toyoa
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
Hi,
posix-timers-fix-clock_nanosleep-doesnt-return-the-remaining-time-in-compatibility-mode.patch
declares two functions with the wrong return type.
Also, posix-timers-fix-the-flags-handling-in-posix_cpu_nsleep.patch uses
'=' instead of '=='.
The attached patch fix both issues.
Regards,
Frederik
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 1fc1ea2..479b16b 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -1477,7 +1477,7 @@ int posix_cpu_nsleep(const clockid_t whi
error = do_cpu_nanosleep(which_clock, flags, rqtp, &it);
- if (error = -ERESTART_RESTARTBLOCK) {
+ if (error == -ERESTART_RESTARTBLOCK) {
if (flags & TIMER_ABSTIME)
return -ERESTARTNOHAND;
@@ -1511,7 +1511,7 @@ long posix_cpu_nsleep_restart(struct res
restart_block->fn = do_no_restart_syscall;
error = do_cpu_nanosleep(which_clock, TIMER_ABSTIME, &t, &it);
- if (error = -ERESTART_RESTARTBLOCK) {
+ if (error == -ERESTART_RESTARTBLOCK) {
/*
* Report back to the user the time still remaining.
*/
@@ -1553,7 +1553,7 @@ static int process_cpu_nsleep(const cloc
{
return posix_cpu_nsleep(PROCESS_CLOCK, flags, rqtp, rmtp);
}
-static int process_cpu_nsleep_restart(struct restart_block *restart_block)
+static long process_cpu_nsleep_restart(struct restart_block *restart_block)
{
return -EINVAL;
}
@@ -1577,7 +1577,7 @@ static int thread_cpu_nsleep(const clock
{
return -EINVAL;
}
-static int thread_cpu_nsleep_restart(struct restart_block *restart_block)
+static long thread_cpu_nsleep_restart(struct restart_block *restart_block)
{
return -EINVAL;
}
^ permalink raw reply related [flat|nested] 192+ messages in thread* Re: [patch] fix posix timer errors
2006-08-13 14:32 ` [patch] fix posix timer errors Frederik Deweerdt
@ 2006-08-13 17:23 ` Andrew Morton
0 siblings, 0 replies; 192+ messages in thread
From: Andrew Morton @ 2006-08-13 17:23 UTC (permalink / raw)
To: Frederik Deweerdt; +Cc: linux-kernel, toyoa
On Sun, 13 Aug 2006 16:32:00 +0200
Frederik Deweerdt <deweerdt@free.fr> wrote:
> On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >
> Hi,
>
> posix-timers-fix-clock_nanosleep-doesnt-return-the-remaining-time-in-compatibility-mode.patch
> declares two functions with the wrong return type.
>
> Also, posix-timers-fix-the-flags-handling-in-posix_cpu_nsleep.patch uses
> '=' instead of '=='.
>
> The attached patch fix both issues.
>
Thanks.
>
> diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
> index 1fc1ea2..479b16b 100644
> --- a/kernel/posix-cpu-timers.c
> +++ b/kernel/posix-cpu-timers.c
> @@ -1477,7 +1477,7 @@ int posix_cpu_nsleep(const clockid_t whi
>
> error = do_cpu_nanosleep(which_clock, flags, rqtp, &it);
>
> - if (error = -ERESTART_RESTARTBLOCK) {
> + if (error == -ERESTART_RESTARTBLOCK) {
>
> if (flags & TIMER_ABSTIME)
> return -ERESTARTNOHAND;
> @@ -1511,7 +1511,7 @@ long posix_cpu_nsleep_restart(struct res
> restart_block->fn = do_no_restart_syscall;
> error = do_cpu_nanosleep(which_clock, TIMER_ABSTIME, &t, &it);
>
> - if (error = -ERESTART_RESTARTBLOCK) {
> + if (error == -ERESTART_RESTARTBLOCK) {
This is the sort of thing which should have been caught in testing, but it
wasn't, which raises questions about how well-tested the rest of it is?
Plus it will have generated compiler warnings.
^ permalink raw reply [flat|nested] 192+ messages in thread
* [-mm patch] arch/i386/mm/ioremap.c must #include <asm/cacheflush.h>
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (3 preceding siblings ...)
2006-08-13 14:32 ` [patch] fix posix timer errors Frederik Deweerdt
@ 2006-08-13 15:30 ` Adrian Bunk
2006-08-13 15:30 ` 2.6.18-rc4-mm1: drivers/video/sis/ compile error Adrian Bunk
` (24 subsequent siblings)
29 siblings, 0 replies; 192+ messages in thread
From: Adrian Bunk @ 2006-08-13 15:30 UTC (permalink / raw)
To: Andrew Morton, Haavard Skinnemoen; +Cc: linux-kernel
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc3-mm2:
>...
> +generic-ioremap_page_range-i386-conversion.patch
>...
> Code consolidation
This gives the following compile error with
-Werror-implicit-function-declaration:
<-- snip -->
...
CC arch/i386/mm/ioremap.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/arch/i386/mm/ioremap.c:
In function ‘ioremap_nocache’:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/arch/i386/mm/ioremap.c:142:
error: implicit declaration of function ‘change_page_attr’
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/arch/i386/mm/ioremap.c:146:
error: implicit declaration of function ‘global_flush_tlb’
<-- snip -->
If anyone with CONFIG_X86_PAE=y experiences runtime stack corruption,
the patch below might help.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.18-rc4-mm1/arch/i386/mm/ioremap.c.old 2006-08-13 12:49:18.000000000 +0200
+++ linux-2.6.18-rc4-mm1/arch/i386/mm/ioremap.c 2006-08-13 12:49:40.000000000 +0200
@@ -14,6 +14,7 @@
#include <linux/module.h>
#include <linux/io.h>
#include <asm/fixmap.h>
+#include <asm/cacheflush.h>
#include <asm/tlbflush.h>
#include <asm/pgtable.h>
^ permalink raw reply [flat|nested] 192+ messages in thread* 2.6.18-rc4-mm1: drivers/video/sis/ compile error
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (4 preceding siblings ...)
2006-08-13 15:30 ` [-mm patch] arch/i386/mm/ioremap.c must #include <asm/cacheflush.h> Adrian Bunk
@ 2006-08-13 15:30 ` Adrian Bunk
2006-08-13 16:29 ` Michal Piotrowski
2006-08-13 17:38 ` 2.6.18-rc4-mm1 Laurent Riffard
` (23 subsequent siblings)
29 siblings, 1 reply; 192+ messages in thread
From: Adrian Bunk @ 2006-08-13 15:30 UTC (permalink / raw)
To: Andrew Morton, Michal Piotrowski
Cc: linux-kernel, Antonino A. Daplas, Thomas Winischhofer
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc3-mm2:
>...
> +drivers-video-sis-sis_mainh-removal-of-old.patch
>...
> fbdev updates
>...
This patch removes too much:
<-- snip -->
...
CC drivers/video/sis/sis_main.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:
In function ‘sisfb_setdefaultparms’:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:91:
error: ‘sisfb_mode_idx’ undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:91:
error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:91:
error: for each function it appears in.)
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:
In function ‘sisfb_search_vesamode’:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:129:
error: ‘sisfb_mode_idx’ undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:
In function ‘sisfb_search_mode’:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:172:
error: ‘sisfb_mode_idx’ undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:
In function ‘sisfb_probe’:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:5813:
error: ‘sisfb_mode_idx’ undeclared (first use in this function)
make[4]: *** [drivers/video/sis/sis_main.o] Error 1
<-- snip -->
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1: drivers/video/sis/ compile error
2006-08-13 15:30 ` 2.6.18-rc4-mm1: drivers/video/sis/ compile error Adrian Bunk
@ 2006-08-13 16:29 ` Michal Piotrowski
2006-08-13 16:40 ` Adrian Bunk
0 siblings, 1 reply; 192+ messages in thread
From: Michal Piotrowski @ 2006-08-13 16:29 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, linux-kernel, Antonino A. Daplas,
Thomas Winischhofer
On 13/08/06, Adrian Bunk <bunk@stusta.de> wrote:
> On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc3-mm2:
> >...
> > +drivers-video-sis-sis_mainh-removal-of-old.patch
> >...
> > fbdev updates
> >...
>
> This patch removes too much:
>
> <-- snip -->
>
> ...
> CC drivers/video/sis/sis_main.o
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:
> In function 'sisfb_setdefaultparms':
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:91:
> error: 'sisfb_mode_idx' undeclared (first use in this function)
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:91:
> error: (Each undeclared identifier is reported only once
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:91:
> error: for each function it appears in.)
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:
> In function 'sisfb_search_vesamode':
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:129:
> error: 'sisfb_mode_idx' undeclared (first use in this function)
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:
> In function 'sisfb_search_mode':
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:172:
> error: 'sisfb_mode_idx' undeclared (first use in this function)
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:
> In function 'sisfb_probe':
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm1/drivers/video/sis/sis_main.c:5813:
> error: 'sisfb_mode_idx' undeclared (first use in this function)
> make[4]: *** [drivers/video/sis/sis_main.o] Error 1
I'll take a closer look at this. I have tested this with allyesconfig
on 2006-08-08-00-59 mm snapshot, but now it doesn't build when
CONFIG_FB_SIS=y (CONFIG_FB_SIS=m builds fine for me).
Thanks for pointing that out.
>
> <-- snip -->
>
> cu
> Adrian
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1: drivers/video/sis/ compile error
2006-08-13 16:29 ` Michal Piotrowski
@ 2006-08-13 16:40 ` Adrian Bunk
2006-08-13 17:20 ` Michal Piotrowski
0 siblings, 1 reply; 192+ messages in thread
From: Adrian Bunk @ 2006-08-13 16:40 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Andrew Morton, linux-kernel, Antonino A. Daplas,
Thomas Winischhofer
On Sun, Aug 13, 2006 at 06:29:46PM +0200, Michal Piotrowski wrote:
> On 13/08/06, Adrian Bunk <bunk@stusta.de> wrote:
> >On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
> >>...
> >> Changes since 2.6.18-rc3-mm2:
> >>...
> >> +drivers-video-sis-sis_mainh-removal-of-old.patch
> >>...
> >> fbdev updates
> >>...
> >
> >This patch removes too much:
> >...
>
> I'll take a closer look at this. I have tested this with allyesconfig
> on 2006-08-08-00-59 mm snapshot, but now it doesn't build when
> CONFIG_FB_SIS=y (CONFIG_FB_SIS=m builds fine for me).
>
> Thanks for pointing that out.
The problem is here:
<-- snip -->
...
#ifdef MODULE
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)
-static int sisfb_mode_idx = -1;
-#else
-static int sisfb_mode_idx = MODE_INDEX_NONE; /* Don't use a mode by default if we are a module */
-#endif
-#else
static int sisfb_mode_idx = -1; /* Use a default mode if we are inside the kernel */
#endif
...
<-- snip -->
It's easy to see that you removed too much (or too few, since the
#ifdef MODULE can be removed - there's also a similar no longer
required #ifdef MODULE in sis_main.c).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1: drivers/video/sis/ compile error
2006-08-13 16:40 ` Adrian Bunk
@ 2006-08-13 17:20 ` Michal Piotrowski
0 siblings, 0 replies; 192+ messages in thread
From: Michal Piotrowski @ 2006-08-13 17:20 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, linux-kernel, Antonino A. Daplas,
Thomas Winischhofer
Adrian Bunk wrote:
> On Sun, Aug 13, 2006 at 06:29:46PM +0200, Michal Piotrowski wrote:
>> On 13/08/06, Adrian Bunk <bunk@stusta.de> wrote:
>>> On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>>>> ...
>>>> Changes since 2.6.18-rc3-mm2:
>>>> ...
>>>> +drivers-video-sis-sis_mainh-removal-of-old.patch
>>>> ...
>>>> fbdev updates
>>>> ...
>>> This patch removes too much:
>>> ...
>> I'll take a closer look at this. I have tested this with allyesconfig
>> on 2006-08-08-00-59 mm snapshot,
Not as well as I should.
>> but now it doesn't build when
>> CONFIG_FB_SIS=y (CONFIG_FB_SIS=m builds fine for me).
>>
>> Thanks for pointing that out.
>
> The problem is here:
>
> <-- snip -->
>
> ...
> #ifdef MODULE
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)
> -static int sisfb_mode_idx = -1;
> -#else
> -static int sisfb_mode_idx = MODE_INDEX_NONE; /* Don't use a mode by default if we are a module */
> -#endif
> -#else
> static int sisfb_mode_idx = -1; /* Use a default mode if we are inside the kernel */
> #endif
> ...
>
> <-- snip -->
>
> It's easy to see that you removed too much (or too few, since the
> #ifdef MODULE can be removed - there's also a similar no longer
> required #ifdef MODULE in sis_main.c).
Thanks for your help.
This patch should fix this problem. Tested with CONFIG_FB_SIS=y and CONFIG_FB_SIS=m.
>
> cu
> Adrian
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
Signed-off-by: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
diff -uprN -X linux-mm/Documentation/dontdiff linux-mm-clean/drivers/video/sis/sis_main.c linux-mm/drivers/video/sis/sis_main.c
--- linux-mm-clean/drivers/video/sis/sis_main.c 2006-08-13 19:12:46.000000000 +0200
+++ linux-mm/drivers/video/sis/sis_main.c 2006-08-13 18:58:49.000000000 +0200
@@ -83,13 +83,7 @@ sisfb_setdefaultparms(void)
sisfb_max = -1;
sisfb_userom = -1;
sisfb_useoem = -1;
-#ifdef MODULE
- /* Module: "None" for 2.4, default mode for 2.5+ */
- sisfb_mode_idx = -1;
-#else
- /* Static: Default mode */
sisfb_mode_idx = -1;
-#endif
sisfb_parm_rate = -1;
sisfb_crt1off = 0;
sisfb_forcecrt1 = -1;
diff -uprN -X linux-mm/Documentation/dontdiff linux-mm-clean/drivers/video/sis/sis_main.h linux-mm/drivers/video/sis/sis_main.h
--- linux-mm-clean/drivers/video/sis/sis_main.h 2006-08-13 19:12:46.000000000 +0200
+++ linux-mm/drivers/video/sis/sis_main.h 2006-08-13 19:06:43.000000000 +0200
@@ -67,9 +67,7 @@ static int sisfb_ypan = -1;
static int sisfb_max = -1;
static int sisfb_userom = 1;
static int sisfb_useoem = -1;
-#ifdef MODULE
static int sisfb_mode_idx = -1; /* Use a default mode if we are inside the kernel */
-#endif
static int sisfb_parm_rate = -1;
static int sisfb_crt1off = 0;
static int sisfb_forcecrt1 = -1;
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (5 preceding siblings ...)
2006-08-13 15:30 ` 2.6.18-rc4-mm1: drivers/video/sis/ compile error Adrian Bunk
@ 2006-08-13 17:38 ` Laurent Riffard
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
` (22 subsequent siblings)
29 siblings, 0 replies; 192+ messages in thread
From: Laurent Riffard @ 2006-08-13 17:38 UTC (permalink / raw)
To: Andrew Morton, Kernel development list
[-- Attachment #1: Type: text/plain, Size: 2638 bytes --]
Le 13.08.2006 10:24, Andrew Morton a écrit :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> - Warning: all the Serial ATA Kconfig options have been renamed. If you
> blindly run `make oldconfig' you won't have any disks.
>
Tried pata_via : it could not identify my DVD drive (LG HL-DT-ST DVDRAM GSA-4165B):
Here is an excerpt from dmesg:
libata version 2.00 loaded.
pata_via 0000:00:04.1: version 0.1.13
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xD800 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xD808 irq 15
scsi0 : pata_via
input: AT Translated Set 2 keyboard as /class/input/input0
ata1.00: ATA-5, max UDMA/100, 78165360 sectors: LBA
ata1.00: ata1: dev 0 multi count 16
ata1.01: ATA-7, max UDMA/133, 160086528 sectors: LBA
ata1.01: ata1: dev 1 multi count 16
ata1.00: configured for UDMA/100
ata1.01: configured for UDMA/100
scsi1 : pata_via
input: ImExPS/2 Generic Explorer Mouse as /class/input/input1
ata2.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0) <======= here
ata2.01: ATAPI, max MWDMA2, CDB intr
ata2.01: configured for MWDMA2
scsi 0:0:0:0: Direct access ATA ST340016A 3.75 PQ: 0 ANSI: 5
scsi 0:0:1:0: Direct access ATA Maxtor 6Y080L0 YAR4 PQ: 0 ANSI: 5
scsi 1:0:1:0: CD/DVD E-IDE CD-950E/AKU A4Q PQ: 0 ANSI: 5
And here is an except from dmesg-2.6.18-rc3-mm2 with via via82cxxx driver:
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci0000:00:04.1
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
input: AT Translated Set 2 keyboard as /class/input/input0
input: ImExPS/2 Generic Explorer Mouse as /class/input/input1
hda: ST340016A, ATA DISK drive
hdb: Maxtor 6Y080L0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes not supported
hda: hda1 hda2 hda3 < hda5 hda6 hda7 > hda4
hdb: max request size: 128KiB
hdb: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hdb: cache flushes supported
hdb: hdb1 hdb2 < hdb5 hdb6 hdb7 hdb8 hdb9 >
Probing IDE interface ide1...
hdc: HL-DT-ST DVDRAM GSA-4165B, ATAPI CD/DVD-ROM drive
hdd: CD-950E/AKU, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
Full dmesg attached.
~~
laurent
[-- Attachment #2: dmesg-2.6.18-rc4-mm1 --]
[-- Type: text/plain, Size: 25252 bytes --]
Linux version 2.6.18-rc4-mm1 (laurent@antares.localdomain) (gcc version 4.1.1 20060724 (prerelease) (4.1.1-3mdk)) #91 Sun Aug 13 12:14:47 CEST 2006
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 000000000009fc00 end: 000000000009fc00 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000000009fc00 size: 0000000000000400 end: 00000000000a0000 type: 2
copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2
copy_e820_map() start: 0000000000100000 size: 000000001feec000 end: 000000001ffec000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000001ffec000 size: 0000000000003000 end: 000000001ffef000 type: 3
copy_e820_map() start: 000000001ffef000 size: 0000000000010000 end: 000000001ffff000 type: 2
copy_e820_map() start: 000000001ffff000 size: 0000000000001000 end: 0000000020000000 type: 4
copy_e820_map() start: 00000000ffff0000 size: 0000000000010000 end: 0000000100000000 type: 2
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001ffec000 (usable)
BIOS-e820: 000000001ffec000 - 000000001ffef000 (ACPI data)
BIOS-e820: 000000001ffef000 - 000000001ffff000 (reserved)
BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
On node 0 totalpages: 131052
DMA zone: 4096 pages, LIFO batch:0
Normal zone: 126956 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v000 ASUS ) @ 0x000f6a80
ACPI: RSDT (v001 ASUS A7V133-C 0x30303031 MSFT 0x31313031) @ 0x1ffec000
ACPI: FADT (v001 ASUS A7V133-C 0x30303031 MSFT 0x31313031) @ 0x1ffec080
ACPI: BOOT (v001 ASUS A7V133-C 0x30303031 MSFT 0x31313031) @ 0x1ffec040
ACPI: DSDT (v001 ASUS A7V133-C 0x00001000 MSFT 0x0100000b) @ 0x00000000
ACPI: PM-Timer IO Port: 0xe408
Allocating PCI resources starting at 30000000 (gap: 20000000:dfff0000)
Detected 1410.372 MHz processor.
Built 1 zonelists. Total pages: 131052
Kernel command line: root=/dev/vglinux1/lvroot video=vesafb:ywrap,mtrr splash=silent resume=/dev/hdb6 netconsole=@192.163.0.3/,@192.168.0.1/00:0E:9B:91:ED:72
netconsole: local port 6665
netconsole: local IP 192.163.0.3
netconsole: interface eth0
netconsole: remote port 6666
netconsole: remote IP 192.168.0.1
netconsole: remote ethernet address 00:0e:9b:91:ed:72
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (01407000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour VGA+ 80x25
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024
... MAX_LOCKDEP_ENTRIES: 8192
... MAX_LOCKDEP_CHAINS: 8192
... CHAINHASH_SIZE: 4096
memory used by lock dependency info: 904 kB
per task-struct memory footprint: 1200 bytes
------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
| spin |wlock |rlock |mutex | wsem | rsem |
--------------------------------------------------------------------------
A-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-B-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok |
A-B-B-C-C-D-D-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-C-D-B-D-D-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-C-D-B-C-D-A deadlock: ok | ok | ok | ok | ok | ok |
double unlock: ok | ok | ok | ok | ok | ok |
initialize held: ok | ok | ok | ok | ok | ok |
bad unlock order: ok | ok | ok | ok | ok | ok |
--------------------------------------------------------------------------
recursive read-lock: | ok | | ok |
recursive read-lock #2: | ok | | ok |
mixed read-write-lock: | ok | | ok |
mixed write-read-lock: | ok | | ok |
--------------------------------------------------------------------------
hard-irqs-on + irq-safe-A/12: ok | ok | ok |
soft-irqs-on + irq-safe-A/12: ok | ok | ok |
hard-irqs-on + irq-safe-A/21: ok | ok | ok |
soft-irqs-on + irq-safe-A/21: ok | ok | ok |
sirq-safe-A => hirqs-on/12: ok | ok | ok |
sirq-safe-A => hirqs-on/21: ok | ok | ok |
hard-safe-A + irqs-on/12: ok | ok | ok |
soft-safe-A + irqs-on/12: ok | ok | ok |
hard-safe-A + irqs-on/21: ok | ok | ok |
soft-safe-A + irqs-on/21: ok | ok | ok |
hard-safe-A + unsafe-B #1/123: ok | ok | ok |
soft-safe-A + unsafe-B #1/123: ok | ok | ok |
hard-safe-A + unsafe-B #1/132: ok | ok | ok |
soft-safe-A + unsafe-B #1/132: ok | ok | ok |
hard-safe-A + unsafe-B #1/213: ok | ok | ok |
soft-safe-A + unsafe-B #1/213: ok | ok | ok |
hard-safe-A + unsafe-B #1/231: ok | ok | ok |
soft-safe-A + unsafe-B #1/231: ok | ok | ok |
hard-safe-A + unsafe-B #1/312: ok | ok | ok |
soft-safe-A + unsafe-B #1/312: ok | ok | ok |
hard-safe-A + unsafe-B #1/321: ok | ok | ok |
soft-safe-A + unsafe-B #1/321: ok | ok | ok |
hard-safe-A + unsafe-B #2/123: ok | ok | ok |
soft-safe-A + unsafe-B #2/123: ok | ok | ok |
hard-safe-A + unsafe-B #2/132: ok | ok | ok |
soft-safe-A + unsafe-B #2/132: ok | ok | ok |
hard-safe-A + unsafe-B #2/213: ok | ok | ok |
soft-safe-A + unsafe-B #2/213: ok | ok | ok |
hard-safe-A + unsafe-B #2/231: ok | ok | ok |
soft-safe-A + unsafe-B #2/231: ok | ok | ok |
hard-safe-A + unsafe-B #2/312: ok | ok | ok |
soft-safe-A + unsafe-B #2/312: ok | ok | ok |
hard-safe-A + unsafe-B #2/321: ok | ok | ok |
soft-safe-A + unsafe-B #2/321: ok | ok | ok |
hard-irq lock-inversion/123: ok | ok | ok |
soft-irq lock-inversion/123: ok | ok | ok |
hard-irq lock-inversion/132: ok | ok | ok |
soft-irq lock-inversion/132: ok | ok | ok |
hard-irq lock-inversion/213: ok | ok | ok |
soft-irq lock-inversion/213: ok | ok | ok |
hard-irq lock-inversion/231: ok | ok | ok |
soft-irq lock-inversion/231: ok | ok | ok |
hard-irq lock-inversion/312: ok | ok | ok |
soft-irq lock-inversion/312: ok | ok | ok |
hard-irq lock-inversion/321: ok | ok | ok |
soft-irq lock-inversion/321: ok | ok | ok |
hard-irq read-recursion/123: ok |
soft-irq read-recursion/123: ok |
hard-irq read-recursion/132: ok |
soft-irq read-recursion/132: ok |
hard-irq read-recursion/213: ok |
soft-irq read-recursion/213: ok |
hard-irq read-recursion/231: ok |
soft-irq read-recursion/231: ok |
hard-irq read-recursion/312: ok |
soft-irq read-recursion/312: ok |
hard-irq read-recursion/321: ok |
soft-irq read-recursion/321: ok |
-------------------------------------------------------
Good, all 218 testcases passed! |
---------------------------------
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 514020k/524208k available (1613k kernel code, 9564k reserved, 1194k data, 160k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xfffb7000 - 0xfffff000 ( 288 kB)
vmalloc : 0xe0800000 - 0xfffb5000 ( 503 MB)
lowmem : 0xc0000000 - 0xdffec000 ( 511 MB)
.init : 0xc03c2000 - 0xc03ea000 ( 160 kB)
.data : 0xc029374e - 0xc03be1f8 (1194 kB)
.text : 0xc0100000 - 0xc029374e (1613 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 2824.46 BogoMIPS (lpj=5648933)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383f9ff c1cbf9ff 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0383f9ff c1cbf9ff 00000000 00000420 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(TM) XP 1600+ stepping 02
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
tbxface-0107 [01] load_tables : ACPI Tables successfully acquired
Parsing all Control Methods:
Table [DSDT](id 0005) - 356 Objects with 38 Devices 115 Methods 24 Regions
ACPI Namespace successfully loaded at root c0572630
ACPI: setting ELCR to 0200 (from 0c20)
evxfevnt-0089 [02] enable : Transition to ACPI mode successful
checking if image is initramfs... it is
Freeing initrd memory: 398k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1
Setting up standard PCI resources
evgpeblk-0951 [04] ev_create_gpe_block : GPE 00 to 0F [_GPE] 2 regs on int 0x9
evgpeblk-1048 [03] ev_initialize_gpe_bloc: Found 4 Wake, Enabled 0 Runtime GPEs in this block
Completing Region/Field/Buffer/Package initialization:.......................................................
Initialized 23/24 Regions 2/2 Fields 19/19 Buffers 11/14 Packages (365 nodes)
Initializing Device/Processor/Thermal objects by executing _INI methods:
Executed 0 _INI methods requiring 0 _STA executions (examined 41 objects)
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI quirk: region e200-e27f claimed by vt82c686 HW-mon
PCI quirk: region e800-e80f claimed by vt82c686 SMB
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
PCI: Bridge: 0000:00:01.0
IO window: disabled.
MEM window: c6000000-c7efffff
PREFETCH window: c7f00000-cfffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 7, 655360 bytes)
TCP bind hash table entries: 8192 (order: 6, 360448 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
Simple Boot Flag at 0x3a set to 0x1
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Applying VIA southbridge workaround.
PCI: Disabling Via external APIC routing
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 16 throttling states)
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker
http://www.scyld.com/network/ne2k-pci.html
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
eth0: RealTek RTL-8029 found at 0xa400, IRQ 10, 00:40:95:46:6E:2D.
netconsole: device eth0 not up yet, forcing it
netconsole: carrier detect appears untrustworthy, waiting 4 seconds
=================================
[ INFO: inconsistent lock state ]
2.6.18-rc4-mm1 #91
---------------------------------
inconsistent {in-softirq-W} -> {softirq-on-W} usage.
swapper/1 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&dev->_xmit_lock){-+..}, at: [<c025353f>] netpoll_send_skb+0x6b/0xdb
{in-softirq-W} state was registered at:
[<c012c793>] __lock_acquire+0x3e1/0x9aa
[<c012d021>] lock_acquire+0x60/0x80
[<c0292638>] _spin_lock+0x19/0x28
[<c02550f6>] dev_watchdog+0x11/0xaf
[<c011da6d>] run_timer_softirq+0xed/0x145
[<c011a8e4>] __do_softirq+0x46/0x9c
[<c011a964>] do_softirq+0x2a/0x42
[<c011acda>] irq_exit+0x31/0x33
[<c0104f39>] do_IRQ+0x97/0xa6
[<c0103699>] common_interrupt+0x25/0x2c
[<c0101aa5>] cpu_idle+0x3c/0x51
[<c0100553>] rest_init+0x1e/0x23
[<c03c26cd>] start_kernel+0x2e2/0x2e4
[<c0100199>] 0xc0100199
[<ffffffff>] 0xffffffff
irq event stamp: 623920
hardirqs last enabled at (623919): [<c0292900>] _spin_unlock_irqrestore+0x36/0x3c
hardirqs last disabled at (623920): [<c0292951>] _spin_lock_irqsave+0xf/0x32
softirqs last enabled at (623880): [<c024bb29>] dev_mc_upload+0x36/0x3a
softirqs last disabled at (623876): [<c0292652>] _spin_lock_bh+0xb/0x2d
other info that might help us debug this:
1 lock held by swapper/1:
#0: (&dev->_xmit_lock){-+..}, at: [<c025353f>] netpoll_send_skb+0x6b/0xdb
stack backtrace:
[<c0103894>] show_trace_log_lvl+0x12/0x25
[<c0103975>] show_trace+0xd/0x10
[<c01040aa>] dump_stack+0x19/0x1b
[<c012b6b9>] print_usage_bug+0x1d1/0x1de
[<c012bbc9>] mark_lock+0x22d/0x349
[<c012bd2c>] mark_held_locks+0x47/0x65
[<c012be39>] trace_hardirqs_on+0xef/0x119
[<c0223eaa>] ei_start_xmit+0x258/0x27e
[<c025355d>] netpoll_send_skb+0x89/0xdb
[<c0254201>] netpoll_send_udp+0x1fd/0x208
[<c0224070>] write_msg+0x42/0x6a
[<c0116823>] __call_console_drivers+0x3b/0x48
[<c0116884>] _call_console_drivers+0x54/0x58
[<c0116a46>] release_console_sem+0x122/0x1ed
[<c0116da7>] register_console+0x190/0x197
[<c022401a>] init_netconsole+0x4e/0x62
[<c01003b4>] init+0x88/0x209
[<c0292be1>] kernel_thread_helper+0x5/0xb
=======================
netconsole: network logging started
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
TCP bic registered
NET: Registered protocol family 1
Using IPI Shortcut mode
ACPI: (supports S0 S1 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
Freeing unused kernel memory: 160k freed
Write protecting the kernel read-only data: 712k
Time: tsc clocksource has been installed.
Time: acpi_pm clocksource has been installed.
SCSI subsystem initialized
libata version 2.00 loaded.
pata_via 0000:00:04.1: version 0.1.13
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xD800 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xD808 irq 15
scsi0 : pata_via
input: AT Translated Set 2 keyboard as /class/input/input0
ata1.00: ATA-5, max UDMA/100, 78165360 sectors: LBA
ata1.00: ata1: dev 0 multi count 16
ata1.01: ATA-7, max UDMA/133, 160086528 sectors: LBA
ata1.01: ata1: dev 1 multi count 16
ata1.00: configured for UDMA/100
ata1.01: configured for UDMA/100
scsi1 : pata_via
input: ImExPS/2 Generic Explorer Mouse as /class/input/input1
ata2.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
ata2.01: ATAPI, max MWDMA2, CDB intr
ata2.01: configured for MWDMA2
scsi 0:0:0:0: Direct access ATA ST340016A 3.75 PQ: 0 ANSI: 5
scsi 0:0:1:0: Direct access ATA Maxtor 6Y080L0 YAR4 PQ: 0 ANSI: 5
scsi 1:0:1:0: CD/DVD E-IDE CD-950E/AKU A4Q PQ: 0 ANSI: 5
SCSI device sda: 78165360 512-byte hdwr sectors (40021 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 78165360 512-byte hdwr sectors (40021 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3 < sda5 sda6 sda7 > sda4
sd 0:0:0:0: Attached scsi disk sda
SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 sdb9 >
sd 0:0:1:0: Attached scsi disk sdb
sr0: scsi3-mmc drive: 0x/48x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:1:0: Attached scsi CD-ROM sr0
device-mapper: ioctl: 4.8.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:04.2[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
uhci_hcd 0000:00:04.2: UHCI Host Controller
uhci_hcd 0000:00:04.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:04.2: irq 5, io base 0x0000d400
usb usb1: new device found, idVendor=0000, idProduct=0000
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: UHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.18-rc4-mm1 uhci_hcd
usb usb1: SerialNumber: 0000:00:04.2
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
warning: process `sleep' used the obsolete sysctl system call
ACPI: PCI Interrupt 0000:00:04.3[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
uhci_hcd 0000:00:04.3: UHCI Host Controller
uhci_hcd 0000:00:04.3: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:04.3: irq 5, io base 0x0000d000
usb usb2: new device found, idVendor=0000, idProduct=0000
usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.18-rc4-mm1 uhci_hcd
usb usb2: SerialNumber: 0000:00:04.3
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
usb 1-2: new low speed USB device using uhci_hcd and address 2
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[5] MMIO=[c5800000-c58007ff] Max Packet=[2048] IR/IT contexts=[8/8]
usb 1-2: new device found, idVendor=044f, idProduct=b303
usb 1-2: new device strings: Mfr=4, Product=30, SerialNumber=0
usb 1-2: Product: FireStorm Dual Analog 2
usb 1-2: Manufacturer: THRUSTMASTER
usb 1-2: configuration #1 chosen from 1 choice
ohci1394: fw-host0: Running dma failed because Node ID is not valid
input: THRUSTMASTER FireStorm Dual Analog 2 as /class/input/input2
input: USB HID v1.10 Gamepad [THRUSTMASTER FireStorm Dual Analog 2] on usb-0000:00:04.2-2
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
warning: process `date' used the obsolete sysctl system call
ohci1394: fw-host0: AT dma reset ctx=0, aborting transmission
ieee1394: Current remote IRM is not 1394a-2000 compliant, resetting...
input: PC Speaker as /class/input/input3
parport_pc: VIA 686A/8231 detected
parport_pc: probing current configuration
parport_pc: Current parallel port base: 0x378
parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]
parport0: Printer, HEWLETT-PACKARD DESKJET 710C
parport_pc: VIA parallel port: io=0x378, irq=7
ieee1394: Host added: ID:BUS[0-00:1023] GUID[00308d0120e085ca]
lp0: using parport0 (interrupt-driven).
Real Time Clock Driver v1.12ac
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
agpgart: AGP aperture is 256M @ 0xd0000000
Using specific hotkey driver
EXT3 FS on dm-4, internal journal
Adding 64220k swap on /dev/sda5. Priority:2 extents:1 across:64220k
ReiserFS: dm-1: found reiserfs format "3.6" with standard journal
ReiserFS: dm-1: using ordered data mode
reiserfs: using flush barriers
ReiserFS: dm-1: journal params: device dm-1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-1: checking transaction log (dm-1)
ReiserFS: dm-1: Using r5 hash to sort names
ReiserFS: dm-6: found reiserfs format "3.6" with standard journal
ReiserFS: dm-6: using ordered data mode
reiserfs: using flush barriers
ReiserFS: dm-6: journal params: device dm-6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-6: checking transaction log (dm-6)
ReiserFS: dm-6: Using r5 hash to sort names
Loading Reiser4. See www.namesys.com for a description of Reiser4.
ps_hash_table: 32 buckets
d_cursor_hash_table: 256 buckets
z_hash_table: 8192 buckets
z_hash_table: 8192 buckets
j_hash_table: 16384 buckets
loading reiser4 bitmap......done (34 jiffies)
d_cursor_hash_table: 256 buckets
z_hash_table: 8192 buckets
z_hash_table: 8192 buckets
j_hash_table: 16384 buckets
loading reiser4 bitmap......done (33 jiffies)
ReiserFS: sda7: found reiserfs format "3.6" with standard journal
ReiserFS: sda7: using ordered data mode
reiserfs: using flush barriers
ReiserFS: sda7: journal params: device sda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda7: checking transaction log (sda7)
ReiserFS: sda7: Using r5 hash to sort names
ReiserFS: dm-0: found reiserfs format "3.6" with standard journal
ReiserFS: dm-0: using ordered data mode
reiserfs: using flush barriers
ReiserFS: dm-0: journal params: device dm-0, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-0: checking transaction log (dm-0)
ReiserFS: dm-0: Using r5 hash to sort names
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on dm-2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
loop: loaded (max 8 devices)
warning: process `ls' used the obsolete sysctl system call
warning: process `prcsys' used the obsolete sysctl system call
warning: process `prcsys' used the obsolete sysctl system call
Using specific hotkey driver
ACPI: PCI Interrupt 0000:00:0d.0[A] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
NET: Registered protocol family 17
ReiserFS: dm-5: found reiserfs format "3.6" with standard journal
ReiserFS: dm-5: using ordered data mode
reiserfs: using flush barriers
ReiserFS: dm-5: journal params: device dm-5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-5: checking transaction log (dm-5)
ReiserFS: dm-5: Using r5 hash to sort names
UDF-fs: No VRS found
attempt to access beyond end of device
sda3: rw=0, want=68, limit=2
attempt to access beyond end of device
sda3: rw=0, want=1252, limit=2
attempt to access beyond end of device
sda3: rw=0, want=1028, limit=2
UDF-fs: No partition found (1)
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sda3.
UDF-fs: No partition found (1)
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sda6.
UDF-fs: No VRS found
attempt to access beyond end of device
sdb2: rw=0, want=68, limit=2
attempt to access beyond end of device
sdb2: rw=0, want=1252, limit=2
attempt to access beyond end of device
sdb2: rw=0, want=1028, limit=2
UDF-fs: No partition found (1)
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sdb2.
UDF-fs: No VRS found
attempt to access beyond end of device
sdb2: rw=0, want=68, limit=2
attempt to access beyond end of device
sdb2: rw=0, want=1252, limit=2
attempt to access beyond end of device
sdb2: rw=0, want=1028, limit=2
UDF-fs: No partition found (1)
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sdb2.
UDF-fs: No VRS found
UDF-fs: No VRS found
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sdb6.
UDF-fs: No VRS found
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sdb7.
UDF-fs: No partition found (1)
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sdb8.
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (6 preceding siblings ...)
2006-08-13 17:38 ` 2.6.18-rc4-mm1 Laurent Riffard
@ 2006-08-13 20:39 ` Andrew Morton
2006-08-14 7:58 ` 2.6.18-rc4-mm1 David Howells
` (4 more replies)
2006-08-13 21:00 ` [-mm patch] make drivers/cpufreq/cpufreq_ondemand.c:powersave_bias_target() static Adrian Bunk
` (21 subsequent siblings)
29 siblings, 5 replies; 192+ messages in thread
From: Andrew Morton @ 2006-08-13 20:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Trond Myklebust, David Howells, Ian Kent
On Sun, 13 Aug 2006 01:24:54 -0700
Andrew Morton <akpm@osdl.org> wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
This kernel breaks autofs /net handling. Bisection shows that the bug is
introduced by git-nfs.patch.
sony:/home/akpm> showmount -e bix
Export list for bix:
/ *
/usr/src *
/mnt/export *
sony:/home/akpm> ls -l /net/bix
total 1025280
drwxr-xr-x 3 root root 4096 Apr 10 03:19 bin
drwxr-xr-x 2 root root 4096 Mar 10 2004 boot
drwxr-xr-x 23 root root 118784 Jun 26 00:48 dev
drwxr-xr-x 98 root root 8192 Aug 13 04:03 etc
drwxr-xr-x 7 root root 4096 Apr 1 2004 home
drwxr-xr-x 2 root root 4096 Oct 7 2003 initrd
drwxr-xr-x 10 root root 4096 Apr 10 03:19 lib
drwx------ 2 root root 16384 Mar 10 2004 lost+found
drwxr-xr-x 2 root root 4096 Sep 8 2003 misc
?--------- ? ? ? ? ? /net/bix/mnt
?--------- ? ? ? ? ? /net/bix/usr
drwxrwxrwx 8 root root 4096 Jul 10 02:50 opt
drwxr-xr-x 2 root root 4096 Mar 10 2004 proc
drwxr-xr-x 20 root root 4096 Aug 7 16:39 root
drwxr-xr-x 2 root root 57344 Apr 24 2004 rpms
drwxr-xr-x 2 root root 8192 Apr 10 03:19 sbin
-rw-r--r-- 1 root root 1048576000 Mar 12 2004 swap
drwxr-xr-x 2 root root 4096 Mar 12 2004 sys
drwxr-xr-x 3 root root 4096 Mar 10 2004 tftpboot
drwxrwxrwt 14 root root 16384 Aug 13 13:29 tmp
drwxr-xr-x 27 root root 4096 Mar 10 2004 var
sony:/home/akpm> ls -l /net/bix/usr
ls: /net/bix/usr: No such file or directory
sony:/home/akpm> mount
/dev/sda6 on / type ext3 (rw,noatime)
/dev/proc on /proc type proc (rw)
/dev/sys on /sys type sysfs (rw)
/dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/shm on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
automount(pid1757) on /net type autofs (rw,fd=5,pgrp=1757,minproto=2,maxproto=4)
bix:/ on /net/bix type nfs (rw,nosuid,nodev,hard,intr,tcp,addr=192.168.2.33)
distro is fairly-up-to-date FC5.
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-14 7:58 ` David Howells
2006-08-14 8:06 ` 2.6.18-rc4-mm1 Ian Kent
` (3 subsequent siblings)
4 siblings, 0 replies; 192+ messages in thread
From: David Howells @ 2006-08-14 7:58 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Trond Myklebust, David Howells, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> This kernel breaks autofs /net handling. Bisection shows that the bug is
> introduced by git-nfs.patch.
What's your autofs setup? What gets mounted on /net/bix? Is it "bix:/"?
David
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-14 7:58 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-14 8:06 ` Ian Kent
2006-08-14 9:32 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 18:32 ` 2.6.18-rc4-mm1 David Howells
` (2 subsequent siblings)
4 siblings, 1 reply; 192+ messages in thread
From: Ian Kent @ 2006-08-14 8:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Trond Myklebust, David Howells
Hi Andrew,
I'm having trouble duplicating this.
Is there any more info. about this I'm missing?
[raven@raven ~]$ /usr/sbin/showmount -e budgie
Export list for budgie:
/ *
/usr/src *
[raven@raven ~]$
[raven@raven ~]$ cd /net/budgie
[raven@raven budgie]$ ls -l
total 116
drwxrwxrwx 10 root root 4096 Jul 15 13:23 autofs
drwxr-xr-x 2 root root 4096 Oct 31 2004 bin
drwxr-xr-x 2 root root 4096 Jan 5 2005 boot
drwxr-xr-x 2 root root 4096 Oct 19 2003 cdrom
drwxr-xr-x 11 root root 24576 Aug 14 08:48 dev
drwxr-xr-x 65 root root 8192 Aug 14 08:49 etc
drwxr-xr-x 2 root root 4096 Oct 19 2003 floppy
drwxrwsr-x 5 root ftp 4096 Apr 3 19:42 home
drwxr-xr-x 2 root root 4096 Oct 19 2003 initrd
lrwxrwxrwx 1 root root 28 Oct 31 2004 initrd.img ->
boot/initrd.img-2.4.27-1-386
lrwxrwxrwx 1 root root 29 Oct 19 2003 initrd.img.old
-> /boot/initrd.img-2.4.18-1-386
drwxr-xr-x 7 root root 4096 Oct 30 2005 lib
drwx------ 2 root root 16384 Oct 19 2003 lost+found
drwxr-xr-x 5 root root 4096 Dec 19 2004 mnt
drwxr-xr-x 2 root root 4096 Oct 19 2003 opt
drwxr-xr-x 2 root root 4096 Feb 8 2002 proc
drwxr-xr-x 7 root root 4096 Oct 30 2005 root
drwxr-xr-x 2 root root 4096 Oct 30 2005 sbin
drwxr-xr-x 2 root root 4096 Oct 14 2004 sys
drwxrwxrwt 4 root root 4096 Aug 14 12:49 tmp
drwxr-xr-x 12 root root 4096 Oct 31 2004 usr
drwxr-xr-x 15 root root 4096 Oct 31 2004 var
lrwxrwxrwx 1 root root 25 Oct 31 2004 vmlinuz ->
boot/vmlinuz-2.4.27-1-386
lrwxrwxrwx 1 root root 25 Oct 19 2003 vmlinuz.old ->
boot/vmlinuz-2.4.18-1-386
[raven@raven budgie]$
[raven@raven budgie]$ cd usr/src
[raven@raven src]$ ls -l
total 49660
drwxr-xr-x 5 root root 4096 Dec 25 2004 kernel-headers-2.4.27-1
drwxr-xr-x 3 root root 4096 Dec 26 2004
kernel-headers-2.4.27-1-386
-rw-r--r-- 1 root root 4685364 Dec 25 2004
kernel-headers-2.4.27-1-386_1_i386.deb
-rw-r--r-- 1 root root 11270432 Dec 26 2004
kernel-image-2.4.27-1-386_1_i386.deb
drwxr-xr-x 3 root root 4096 Dec 19 2004 kernel-patches
drwxr-xr-x 16 root root 4096 Dec 26 2004 kernel-source-2.4.27
-rw-r--r-- 1 root root 30980829 Dec 1 2004
kernel-source-2.4.27.tar.bz2
drwx------ 2 root root 16384 Dec 19 2004 lost+found
-rw-r--r-- 1 root root 145984 Dec 26 2004
madwifi-module-2.4.27-1-386_20041216-1-onoe+1_i386.deb
-rw-r--r-- 1 root root 1692484 Dec 26 2004
madwifi-source_20041216_all.deb
-rw-r--r-- 1 root root 1680344 Dec 16 2004 madwifi.tar.gz
-rw-r--r-- 1 root root 14828 Dec 26 2004
madwifi-tools_20041216_i386.deb
drwxr-xr-x 4 root root 4096 Dec 16 2004 modules
-rw-r--r-- 1 root root 55752 Dec 26 2004
ndiswrapper-modules-2.4.27-1-386_0.11-1+1_i386.deb
-rw-r--r-- 1 root root 84130 Dec 26 2004
ndiswrapper-source_0.11-1_i386.deb
-rw-r--r-- 1 root root 76469 Nov 8 2004 ndiswrapper-source.tar.bz2
-rw-r--r-- 1 root root 20086 Dec 26 2004
ndiswrapper-utils_0.11-1_i386.deb
On Sun, 2006-08-13 at 13:39 -0700, Andrew Morton wrote:
> On Sun, 13 Aug 2006 01:24:54 -0700
> Andrew Morton <akpm@osdl.org> wrote:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> This kernel breaks autofs /net handling. Bisection shows that the bug is
> introduced by git-nfs.patch.
>
>
> sony:/home/akpm> showmount -e bix
> Export list for bix:
> / *
> /usr/src *
> /mnt/export *
> sony:/home/akpm> ls -l /net/bix
> total 1025280
> drwxr-xr-x 3 root root 4096 Apr 10 03:19 bin
> drwxr-xr-x 2 root root 4096 Mar 10 2004 boot
> drwxr-xr-x 23 root root 118784 Jun 26 00:48 dev
> drwxr-xr-x 98 root root 8192 Aug 13 04:03 etc
> drwxr-xr-x 7 root root 4096 Apr 1 2004 home
> drwxr-xr-x 2 root root 4096 Oct 7 2003 initrd
> drwxr-xr-x 10 root root 4096 Apr 10 03:19 lib
> drwx------ 2 root root 16384 Mar 10 2004 lost+found
> drwxr-xr-x 2 root root 4096 Sep 8 2003 misc
> ?--------- ? ? ? ? ? /net/bix/mnt
> ?--------- ? ? ? ? ? /net/bix/usr
> drwxrwxrwx 8 root root 4096 Jul 10 02:50 opt
> drwxr-xr-x 2 root root 4096 Mar 10 2004 proc
> drwxr-xr-x 20 root root 4096 Aug 7 16:39 root
> drwxr-xr-x 2 root root 57344 Apr 24 2004 rpms
> drwxr-xr-x 2 root root 8192 Apr 10 03:19 sbin
> -rw-r--r-- 1 root root 1048576000 Mar 12 2004 swap
> drwxr-xr-x 2 root root 4096 Mar 12 2004 sys
> drwxr-xr-x 3 root root 4096 Mar 10 2004 tftpboot
> drwxrwxrwt 14 root root 16384 Aug 13 13:29 tmp
> drwxr-xr-x 27 root root 4096 Mar 10 2004 var
> sony:/home/akpm> ls -l /net/bix/usr
> ls: /net/bix/usr: No such file or directory
> sony:/home/akpm> mount
> /dev/sda6 on / type ext3 (rw,noatime)
> /dev/proc on /proc type proc (rw)
> /dev/sys on /sys type sysfs (rw)
> /dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620)
> /dev/shm on /dev/shm type tmpfs (rw)
> none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
> sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
> automount(pid1757) on /net type autofs (rw,fd=5,pgrp=1757,minproto=2,maxproto=4)
> bix:/ on /net/bix type nfs (rw,nosuid,nodev,hard,intr,tcp,addr=192.168.2.33)
>
>
> distro is fairly-up-to-date FC5.
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-14 8:06 ` 2.6.18-rc4-mm1 Ian Kent
@ 2006-08-14 9:32 ` David Howells
2006-08-14 17:16 ` 2.6.18-rc4-mm1 Andrew Morton
0 siblings, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-14 9:32 UTC (permalink / raw)
To: Ian Kent; +Cc: Andrew Morton, linux-kernel, Trond Myklebust, David Howells
Ian Kent <raven@themaw.net> wrote:
> I'm having trouble duplicating this.
> Is there any more info. about this I'm missing?
Works fine for me also.
Andrew, can you do the following:
cat /proc/fs/nfsfs/*
And can you try mounting "bix:/" manually to see if that exhibits the same
problem? It'd be useful to know if autofs is actually having an effect.
Also, can you do a module list and check that it's autofs4 that's being used,
and not autofs. It would be handy if we could rule out an adverse interaction
between nfs and autofs4.
> Bisection shows that the bug is introduced by git-nfs.patch.
But what does it actually show? Do you know where the bug is then? (I don't
know exactly how bisection works).
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 9:32 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-14 17:16 ` Andrew Morton
2006-08-14 18:12 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 1 reply; 192+ messages in thread
From: Andrew Morton @ 2006-08-14 17:16 UTC (permalink / raw)
To: David Howells; +Cc: Ian Kent, linux-kernel, Trond Myklebust
On Mon, 14 Aug 2006 10:32:10 +0100
David Howells <dhowells@redhat.com> wrote:
> Ian Kent <raven@themaw.net> wrote:
>
> > I'm having trouble duplicating this.
> > Is there any more info. about this I'm missing?
>
> Works fine for me also.
>
> Andrew, can you do the following:
>
> cat /proc/fs/nfsfs/*
sony:/home/akpm> cat /proc/fs/nfsfs/*
NV SERVER PORT USE HOSTNAME
NV SERVER PORT DEV FSID FSC
sony:/home/akpm> ls -l /net/bix
total 1025280
drwxr-xr-x 3 root root 4096 Apr 10 03:19 bin
drwxr-xr-x 2 root root 4096 Mar 10 2004 boot
drwxr-xr-x 23 root root 118784 Jun 26 00:48 dev
drwxr-xr-x 98 root root 8192 Aug 14 04:03 etc
drwxr-xr-x 7 root root 4096 Apr 1 2004 home
drwxr-xr-x 2 root root 4096 Oct 7 2003 initrd
drwxr-xr-x 10 root root 4096 Apr 10 03:19 lib
drwx------ 2 root root 16384 Mar 10 2004 lost+found
drwxr-xr-x 2 root root 4096 Sep 8 2003 misc
?--------- ? ? ? ? ? /net/bix/mnt
?--------- ? ? ? ? ? /net/bix/usr
drwxrwxrwx 8 root root 4096 Jul 10 02:50 opt
drwxr-xr-x 2 root root 4096 Mar 10 2004 proc
drwxr-xr-x 20 root root 4096 Aug 7 16:39 root
drwxr-xr-x 2 root root 57344 Apr 24 2004 rpms
drwxr-xr-x 2 root root 8192 Apr 10 03:19 sbin
-rw-r--r-- 1 root root 1048576000 Mar 12 2004 swap
drwxr-xr-x 2 root root 4096 Mar 12 2004 sys
drwxr-xr-x 3 root root 4096 Mar 10 2004 tftpboot
drwxrwxrwt 14 root root 16384 Aug 14 09:57 tmp
drwxr-xr-x 27 root root 4096 Mar 10 2004 var
sony:/home/akpm> cat /proc/fs/nfsfs/*
NV SERVER PORT USE HOSTNAME
v3 c0a80221 801 1 bix
NV SERVER PORT DEV FSID FSC
v3 c0a80221 801 0:21 802:0 no
> And can you try mounting "bix:/" manually to see if that exhibits the same
> problem?
sony:/home/akpm# mount bix:/ /mnt/bix
sony:/home/akpm# ls -l /mnt/bix
total 1025288
drwxr-xr-x 3 root root 4096 Apr 10 03:19 bin
drwxr-xr-x 2 root root 4096 Mar 10 2004 boot
drwxr-xr-x 23 root root 118784 Jun 26 00:48 dev
drwxr-xr-x 98 root root 8192 Aug 14 04:03 etc
drwxr-xr-x 7 root root 4096 Apr 1 2004 home
drwxr-xr-x 2 root root 4096 Oct 7 2003 initrd
drwxr-xr-x 10 root root 4096 Apr 10 03:19 lib
drwx------ 2 root root 16384 Mar 10 2004 lost+found
drwxr-xr-x 2 root root 4096 Sep 8 2003 misc
drwxr-xr-x 19 root root 4096 Jul 3 15:29 mnt
drwxrwxrwx 8 root root 4096 Jul 10 02:50 opt
drwxr-xr-x 2 root root 4096 Mar 10 2004 proc
drwxr-xr-x 20 root root 4096 Aug 7 16:39 root
drwxr-xr-x 2 root root 57344 Apr 24 2004 rpms
drwxr-xr-x 2 root root 8192 Apr 10 03:19 sbin
-rw-r--r-- 1 root root 1048576000 Mar 12 2004 swap
drwxr-xr-x 2 root root 4096 Mar 12 2004 sys
drwxr-xr-x 3 root root 4096 Mar 10 2004 tftpboot
drwxrwxrwt 14 root root 16384 Aug 14 09:57 tmp
drwxr-xr-x 17 root root 4096 Mar 22 2005 usr
drwxr-xr-x 27 root root 4096 Mar 10 2004 var
sony:/home/akpm# mount bix:/usr/src /mnt/bix/usr/src
sony:/home/akpm# ls -l /mnt/bix
total 1025288
drwxr-xr-x 3 root root 4096 Apr 10 03:19 bin
drwxr-xr-x 2 root root 4096 Mar 10 2004 boot
drwxr-xr-x 23 root root 118784 Jun 26 00:48 dev
drwxr-xr-x 98 root root 8192 Aug 14 04:03 etc
drwxr-xr-x 7 root root 4096 Apr 1 2004 home
drwxr-xr-x 2 root root 4096 Oct 7 2003 initrd
drwxr-xr-x 10 root root 4096 Apr 10 03:19 lib
drwx------ 2 root root 16384 Mar 10 2004 lost+found
drwxr-xr-x 2 root root 4096 Sep 8 2003 misc
drwxr-xr-x 19 root root 4096 Jul 3 15:29 mnt
drwxrwxrwx 8 root root 4096 Jul 10 02:50 opt
drwxr-xr-x 2 root root 4096 Mar 10 2004 proc
drwxr-xr-x 20 root root 4096 Aug 7 16:39 root
drwxr-xr-x 2 root root 57344 Apr 24 2004 rpms
drwxr-xr-x 2 root root 8192 Apr 10 03:19 sbin
-rw-r--r-- 1 root root 1048576000 Mar 12 2004 swap
drwxr-xr-x 2 root root 4096 Mar 12 2004 sys
drwxr-xr-x 3 root root 4096 Mar 10 2004 tftpboot
drwxrwxrwt 14 root root 16384 Aug 14 09:57 tmp
drwxr-xr-x 17 root root 4096 Mar 22 2005 usr
drwxr-xr-x 27 root root 4096 Mar 10 2004 var
sony:/home/akpm# ls -l /mnt/bix/usr/src
total 1049780
drwxr-xr-x 21 akpm akpm 4096 Jun 17 16:02 24
lrwxrwxrwx 1 akpm akpm 5 Jan 23 2006 25 -> devel
drwxr-xr-x 27 akpm akpm 4096 May 20 01:44 25-alpha
...
> It'd be useful to know if autofs is actually having an effect.
Everything seems OK doing it by hand.
> Also, can you do a module list and check that it's autofs4 that's being used,
> and not autofs.
sony:/home/akpm# lsmod|grep auto
autofs4 20228 1
> It would be handy if we could rule out an adverse interaction
> between nfs and autofs4.
I'd say that's exactly what it is.
> > Bisection shows that the bug is introduced by git-nfs.patch.
>
> But what does it actually show? Do you know where the bug is then? (I don't
> know exactly how bisection works).
>
I mean: bisection searching through the rc4-mm1 patch pile indicates that:
everything up to but not including git-nfs.patch: OK
add git-nfs.patch to the above: fails.
The server is running 2.6.17-rc1-mm3, if that matters. (It shouldn't:
git-nfs.patch has changed the client's behaviour).
And, as I said, this machine is running stock mostly-up-to-date FC5.
sony:/home/akpm> rpm -q autofs
autofs-4.1.4-29
sony:/home/akpm> rpm -V autofs
sony:/home/akpm>
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 17:16 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-14 18:12 ` David Howells
2006-08-14 18:17 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 18:24 ` 2.6.18-rc4-mm1 Andrew Morton
0 siblings, 2 replies; 192+ messages in thread
From: David Howells @ 2006-08-14 18:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, Ian Kent, linux-kernel, Trond Myklebust
Andrew Morton <akpm@osdl.org> wrote:
> ?--------- ? ? ? ? ? /net/bix/mnt
> ?--------- ? ? ? ? ? /net/bix/usr
Do /mnt and /usr have other things mounted on them on bix? Can you dump fstab
on bix?
If so, it's possible that the server-mountpoint-crossing automounter internal
to NFS doesn't like working with autofs.
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 18:12 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-14 18:17 ` David Howells
2006-08-14 18:24 ` 2.6.18-rc4-mm1 Andrew Morton
1 sibling, 0 replies; 192+ messages in thread
From: David Howells @ 2006-08-14 18:17 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, Ian Kent, linux-kernel, Trond Myklebust
David Howells <dhowells@redhat.com> wrote:
> Do /mnt and /usr have other things mounted on them on bix? Can you dump fstab
> on bix?
I don't mean fstab, I mean /proc/mounts.
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 18:12 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 18:17 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-14 18:24 ` Andrew Morton
1 sibling, 0 replies; 192+ messages in thread
From: Andrew Morton @ 2006-08-14 18:24 UTC (permalink / raw)
To: David Howells; +Cc: Ian Kent, linux-kernel, Trond Myklebust
On Mon, 14 Aug 2006 19:12:23 +0100
David Howells <dhowells@redhat.com> wrote:
> Andrew Morton <akpm@osdl.org> wrote:
>
> > ?--------- ? ? ? ? ? /net/bix/mnt
> > ?--------- ? ? ? ? ? /net/bix/usr
>
> Do /mnt and /usr have other things mounted on them on bix?
nope.
> Can you dump fstab
> on bix?
bix:/home/akpm> cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,noatime,data=ordered 0 0
/proc /proc proc rw 0 0
none /dev/pts devpts rw 0 0
/dev/sda1 /boot ext3 rw,data=ordered 0 0
none /dev/shm tmpfs rw 0 0
/dev/sdb1 /usr/src ext3 rw,noatime,data=ordered 0 0
none /sys sysfs rw 0 0
/dev/sdb2 /mnt/export ext3 rw,noatime,data=ordered 0 0
nodev /dev/oprofile oprofilefs rw 0 0
> If so, it's possible that the server-mountpoint-crossing automounter internal
> to NFS doesn't like working with autofs.
I'd say it's something like that. Odd thing is, /mnt and /usr don't have
anything mounted on them. But they do have a local partition mounted on
subdirectories within them: /mnt/export and /usr/src.
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-14 7:58 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 8:06 ` 2.6.18-rc4-mm1 Ian Kent
@ 2006-08-14 18:32 ` David Howells
2006-08-14 21:31 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-14 22:49 ` 2.6.18-rc4-mm1 Trond Myklebust
2006-08-16 15:15 ` [PATCH] NFS: Revalidate on readdir referring to null dentry David Howells
4 siblings, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-14 18:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Trond Myklebust, David Howells, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> sony:/home/akpm> showmount -e bix
> Export list for bix:
> / *
> /usr/src *
> /mnt/export *
What's in your /etc/exports file?
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 18:32 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-14 21:31 ` Andrew Morton
2006-08-15 9:51 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 1 reply; 192+ messages in thread
From: Andrew Morton @ 2006-08-14 21:31 UTC (permalink / raw)
To: David Howells; +Cc: linux-kernel, Trond Myklebust, Ian Kent
On Mon, 14 Aug 2006 19:32:19 +0100
David Howells <dhowells@redhat.com> wrote:
> Andrew Morton <akpm@osdl.org> wrote:
>
> > sony:/home/akpm> showmount -e bix
> > Export list for bix:
> > / *
> > /usr/src *
> > /mnt/export *
>
> What's in your /etc/exports file?
>
bix:/home/akpm> cat /etc/exports
/ *(rw,async)
/usr/src *(rw,async)
/mnt/export *(rw,async)
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 21:31 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-15 9:51 ` David Howells
2006-08-15 13:50 ` 2.6.18-rc4-mm1 Andrew Morton
0 siblings, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-15 9:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, linux-kernel, Trond Myklebust, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> bix:/home/akpm> cat /etc/exports
> / *(rw,async)
> /usr/src *(rw,async)
> /mnt/export *(rw,async)
Hmmm... I still can't reproduce it.
What happens if you change your /etc/exports file to:
/ *(rw,async,fsid=0)
/usr/src *(rw,async,nohide)
/mnt/export *(rw,async,nohide)
Also, does removing the "/mnt/export" line from /etc/exports mean that the
/mnt reappears in the directory listing?
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 9:51 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-15 13:50 ` Andrew Morton
2006-08-15 14:47 ` 2.6.18-rc4-mm1 David Howells
2006-08-15 17:29 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 2 replies; 192+ messages in thread
From: Andrew Morton @ 2006-08-15 13:50 UTC (permalink / raw)
To: David Howells; +Cc: linux-kernel, Trond Myklebust, Ian Kent
On Tue, 15 Aug 2006 10:51:53 +0100
David Howells <dhowells@redhat.com> wrote:
> Andrew Morton <akpm@osdl.org> wrote:
>
> > bix:/home/akpm> cat /etc/exports
> > / *(rw,async)
> > /usr/src *(rw,async)
> > /mnt/export *(rw,async)
>
> Hmmm... I still can't reproduce it.
http://www.zip.com.au/~akpm/linux/patches/stuff/config-sony
> What happens if you change your /etc/exports file to:
>
> / *(rw,async,fsid=0)
> /usr/src *(rw,async,nohide)
> /mnt/export *(rw,async,nohide)
unchanged.
> Also, does removing the "/mnt/export" line from /etc/exports mean that the
> /mnt reappears in the directory listing?
>
That makes /mnt go away:
sony:/home/akpm> l /net/bix
total 1025284
drwxr-xr-x 3 root root 4096 Apr 10 03:19 bin
drwxr-xr-x 2 root root 4096 Mar 10 2004 boot
drwxr-xr-x 23 root root 118784 Jun 26 00:48 dev
drwxr-xr-x 98 root root 8192 Aug 15 06:46 etc
drwxr-xr-x 7 root root 4096 Apr 1 2004 home
drwxr-xr-x 2 root root 4096 Oct 7 2003 initrd
drwxr-xr-x 10 root root 4096 Apr 10 03:19 lib
drwx------ 2 root root 16384 Mar 10 2004 lost+found
drwxr-xr-x 2 root root 4096 Sep 8 2003 misc
drwxr-xr-x 19 root root 4096 Jul 3 15:29 mnt
?--------- ? ? ? ? ? /net/bix/usr
drwxrwxrwx 8 root root 4096 Jul 10 02:50 opt
drwxr-xr-x 2 root root 4096 Mar 10 2004 proc
drwxr-xr-x 20 root root 4096 Aug 7 16:39 root
drwxr-xr-x 2 root root 57344 Apr 24 2004 rpms
drwxr-xr-x 2 root root 8192 Apr 10 03:19 sbin
-rw-r--r-- 1 root root 1048576000 Mar 12 2004 swap
drwxr-xr-x 2 root root 4096 Mar 12 2004 sys
drwxr-xr-x 3 root root 4096 Mar 10 2004 tftpboot
drwxrwxrwt 14 root root 16384 Aug 15 06:42 tmp
drwxr-xr-x 27 root root 4096 Mar 10 2004 var
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 13:50 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-15 14:47 ` David Howells
2006-08-15 16:15 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 17:29 ` 2.6.18-rc4-mm1 David Howells
1 sibling, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-15 14:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, linux-kernel, Trond Myklebust, Ian Kent
> http://www.zip.com.au/~akpm/linux/patches/stuff/config-sony
Is this pure 2.6.18-rc4-mm1? This configuration has unsatisfied config
options. I was wondering if you had some other patches too.
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 13:50 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 14:47 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-15 17:29 ` David Howells
2006-08-15 17:48 ` 2.6.18-rc4-mm1 Andrew Morton
1 sibling, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-15 17:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, linux-kernel, Trond Myklebust, Ian Kent
Next thing to try: Can you do the following:
echo $((0x0200)) >/proc/sys/sunrpc/nfs_debug
ls -l /net/bix
umount /net/bix
That should print some information about the client and server setup procedure
into the kernel dmesg log which can then be captured.
If you follow that up with:
echo $((0x0201)) >/proc/sys/sunrpc/nfs_debug
ls -l /net/bix
umount /net/bix
That'll dump information from the VFS interaction also. It'll be a lot more
information, and it might overrun your dmesg buffer, hence why I'm asking you
to do the client-only debugging separately.
Then do:
echo 0 >/proc/sys/sunrpc/nfs_debug
to turn off debugging again.
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 17:29 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-15 17:48 ` Andrew Morton
2006-08-15 18:35 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 1 reply; 192+ messages in thread
From: Andrew Morton @ 2006-08-15 17:48 UTC (permalink / raw)
To: David Howells; +Cc: linux-kernel, Trond Myklebust, Ian Kent
On Tue, 15 Aug 2006 18:29:58 +0100
David Howells <dhowells@redhat.com> wrote:
>
> Next thing to try: Can you do the following:
>
> echo $((0x0200)) >/proc/sys/sunrpc/nfs_debug
> ls -l /net/bix
> umount /net/bix
>
> That should print some information about the client and server setup procedure
> into the kernel dmesg log which can then be captured.
SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
--> nfs_init_server()
--> nfs_get_client(bix,192.168.2.33:264,3)
--> nfs_get_client() = ea22d000 [new]
<-- nfs_init_server() = 0 [new ea22d000]
--> nfs_probe_fsinfo()
<-- nfs_probe_fsinfo() = 0
Server FSID: 802:0
SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
--> nfs_free_server()
--> nfs_put_client({1})
--> nfs_free_client(3)
<-- nfs_free_client()
<-- nfs_free_server()
> If you follow that up with:
>
> echo $((0x0201)) >/proc/sys/sunrpc/nfs_debug
> ls -l /net/bix
> umount /net/bix
>
> That'll dump information from the VFS interaction also. It'll be a lot more
> information, and it might overrun your dmesg buffer, hence why I'm asking you
> to do the client-only debugging separately.
--> nfs_init_server()
--> nfs_get_client(bix,192.168.2.33:264,3)
--> nfs_get_client() = ebabd400 [new]
<-- nfs_init_server() = 0 [new ebabd400]
--> nfs_probe_fsinfo()
<-- nfs_probe_fsinfo() = 0
Server FSID: 802:0
NFS: nfs_fhget(0:15/0 ct=1)
NFS: nfs_fhget(0:15/2 ct=1)
SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
NFS: nfs_update_inode(0:15/2 ct=1 info=0x6)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: permission(0:15/2), mask=0x1, res=0
NFS: lookup(/usr)
NFS: permission(0:15/2), mask=0x3, res=0
NFS: dentry_delete(/usr, 0)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: permission(0:15/2), mask=0x1, res=0
NFS: lookup(/mnt)
NFS: permission(0:15/2), mask=0x3, res=0
NFS: dentry_delete(/mnt, 0)
NFS: nfs_update_inode(0:15/2 ct=1 info=0x6)
NFS: permission(0:15/2), mask=0x4, res=0
NFS: opendir(0:15/2)
NFS: readdir(/) starting at cookie 0
NFS: nfs_fhget(0:15/11 ct=1)
NFS: dentry_delete(/lost+found, 0)
NFS: nfs_fhget(0:15/65537 ct=1)
NFS: dentry_delete(/dev, 0)
NFS: dentry_delete(/usr, 8)
NFS: nfs_fhget(0:15/196609 ct=1)
NFS: dentry_delete(/var, 0)
NFS: nfs_fhget(0:15/245761 ct=1)
NFS: dentry_delete(/tmp, 0)
NFS: nfs_fhget(0:15/262145 ct=1)
NFS: dentry_delete(/etc, 0)
NFS: nfs_fhget(0:15/327681 ct=1)
NFS: dentry_delete(/root, 0)
NFS: nfs_fhget(0:15/753665 ct=1)
NFS: dentry_delete(/lib, 0)
NFS: nfs_fhget(0:15/851969 ct=1)
NFS: dentry_delete(/bin, 0)
NFS: nfs_fhget(0:15/983041 ct=1)
NFS: dentry_delete(/home, 0)
NFS: nfs_fhget(0:15/999425 ct=1)
NFS: dentry_delete(/initrd, 0)
NFS: dentry_delete(/mnt, 8)
NFS: nfs_fhget(0:15/1048577 ct=1)
NFS: dentry_delete(/opt, 0)
NFS: nfs_fhget(0:15/1064961 ct=1)
NFS: dentry_delete(/sbin, 0)
NFS: nfs_fhget(0:15/13811717 ct=1)
NFS: dentry_delete(/misc, 0)
NFS: nfs_fhget(0:15/12877854 ct=1)
NFS: dentry_delete(/.automount, 0)
NFS: nfs_fhget(0:15/9207876 ct=1)
NFS: dentry_delete(/tftpboot, 0)
NFS: nfs_fhget(0:15/12 ct=1)
NFS: dentry_delete(/.autofsck, 0)
NFS: nfs_fhget(0:15/49430 ct=1)
NFS: dentry_delete(/swap, 0)
NFS: nfs_fhget(0:15/13435097 ct=1)
NFS: dentry_delete(/rpms, 0)
NFS: nfs_fhget(0:15/14 ct=1)
NFS: dentry_delete(/.fonts.cache-1, 0)
NFS: readdir(/) returns 0
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/lost+found, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: lookup(/boot)
NFS: nfs_update_inode(0:15/2 ct=1 info=0x6)
NFS: nfs_fhget(0:15/32769 ct=1)
NFS: dentry_delete(/boot, 0)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/dev, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: lookup(/proc)
NFS: nfs_fhget(0:15/131073 ct=1)
NFS: dentry_delete(/proc, 0)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/usr, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/var, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/tmp, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/etc, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/root, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/lib, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/bin, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/home, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/initrd, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/mnt, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/opt, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/sbin, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/misc, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/tftpboot, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: lookup(/sys)
NFS: nfs_fhget(0:15/17842177 ct=1)
NFS: dentry_delete(/sys, 0)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/swap, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/rpms, 8)
NFS: readdir(/) starting at cookie 26
NFS: readdir(/) returns 0
--> nfs_free_server()
--> nfs_put_client({1})
--> nfs_free_client(3)
<-- nfs_free_client()
<-- nfs_free_server()
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-15 17:48 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-15 18:35 ` David Howells
2006-08-15 18:49 ` 2.6.18-rc4-mm1 Andrew Morton
0 siblings, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-15 18:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, linux-kernel, Trond Myklebust, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> NFS: nfs_fhget(0:15/0 ct=1)
That's the dummy root dentry (attached to s_root) which we don't actually use
for anything.
> NFS: nfs_fhget(0:15/2 ct=1)
That's the actual root of the subtree for this mount (inode 2).
> SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
I wonder if this is something to do with it. I run my testbox with SELinux
disabled since it won't boot if it's turned on (udev takes so long to run that
it gets backgrounded and then fsck tries to run, but can't find any blockdev
files). Can you try turning SELinux off (booting with selinux=0 on the kernel
command line might do it).
> NFS: nfs_update_inode(0:15/2 ct=1 info=0x6)
Update the root inode from attributes with NFS_ATTR_FATTR_V3|NFS_ATTR_FATTR.
> NFS: permission(0:15/2), mask=0x1, res=0
> NFS: permission(0:15/2), mask=0x1, res=0
Check MAY_EXEC on root. It all looks reasonable to this point.
> NFS: lookup(/usr)
But _why_? This is very strange. We shouldn't be looking at bix:/usr yet
because we haven't read the directory and we can't know it exists yet.
Also, why isn't there a call to nfs_fhget() for bix:/usr?
> NFS: permission(0:15/2), mask=0x3, res=0
Though it appears we do have permission to write and exec the directory (I
assume that mask=0x3 -> MAY_WRITE|MAY_EXEC), though *why* we'd be trying to do
that, I don't know.
> NFS: dentry_delete(/usr, 0)
> NFS: permission(0:15/2), mask=0x1, res=0
> NFS: permission(0:15/2), mask=0x1, res=0
Again, check MAY_EXEC on the root dir.
> NFS: lookup(/mnt)
And again: _why_? We shouldn't know about bix:/mnt either.
> NFS: permission(0:15/2), mask=0x3, res=0
Again we're asking for MAY_WRITE permission as well as MAY_EXEC.
> NFS: dentry_delete(/mnt, 0)
> NFS: nfs_update_inode(0:15/2 ct=1 info=0x6)
> NFS: permission(0:15/2), mask=0x4, res=0
Check we have MAY_READ on the root dir.
> NFS: opendir(0:15/2)
And open it for reading.
> NFS: readdir(/) starting at cookie 0
Okay... read some entries from the directory.
> NFS: nfs_fhget(0:15/11 ct=1)
> NFS: dentry_delete(/lost+found, 0)
> NFS: nfs_fhget(0:15/65537 ct=1)
> NFS: dentry_delete(/dev, 0)
Go through the first two, which looks fine.
> NFS: dentry_delete(/usr, 8)
And then we read bix:/usr, but don't call nfs_fhget() - which is should be
reasonable since we fetched it earlier. Note that the dentry specifies
DCACHE_REFERENCED in d_flags.
> NFS: nfs_fhget(0:15/196609 ct=1)
> NFS: dentry_delete(/var, 0)
And this looks fine.
> ...
> NFS: permission(0:15/2), mask=0x1, res=0
> NFS: dentry_delete(/usr, 8)
Then we come to stat bix:/usr, and this looks fine.
On the basis of nfs_lookup() apparently not calling nfs_fhget() for the first
lookup of /usr, can you stick a printk() at the end of nfs_lookup() (in
fs/nfs/dir.c), just before the return-statement so that it prints out the
return value. And can you make nfs_lookup() print nd->flags on entry?
I'm wondering if autofs4 is trying to create a couple of directories in the
NFS share, though I can't think why it would. Uncommenting:
/* #define DEBUG */
in fs/autofs4/autofs_i.h might also be informative.
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 18:35 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-15 18:49 ` Andrew Morton
2006-08-15 19:20 ` 2.6.18-rc4-mm1 David Howells
2006-08-16 9:34 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 2 replies; 192+ messages in thread
From: Andrew Morton @ 2006-08-15 18:49 UTC (permalink / raw)
To: David Howells; +Cc: linux-kernel, Trond Myklebust, Ian Kent
On Tue, 15 Aug 2006 19:35:20 +0100
David Howells <dhowells@redhat.com> wrote:
> > SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
>
> I wonder if this is something to do with it.
`echo 0 > /selinux/enforce' "fixes" it.
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 18:49 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-15 19:20 ` David Howells
2006-08-16 9:34 ` 2.6.18-rc4-mm1 David Howells
1 sibling, 0 replies; 192+ messages in thread
From: David Howells @ 2006-08-15 19:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, linux-kernel, Trond Myklebust, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> > > SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
> >
> > I wonder if this is something to do with it.
>
> `echo 0 > /selinux/enforce' "fixes" it.
Interesting.........................
Looks like a need to find myself a new testbox - one that can cope with both
SELinux *and* udev.
I wonder what SELinux is doing...
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 18:49 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 19:20 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-16 9:34 ` David Howells
2006-08-16 10:00 ` 2.6.18-rc4-mm1 David Howells
2006-08-16 12:36 ` 2.6.18-rc4-mm1 Ian Kent
1 sibling, 2 replies; 192+ messages in thread
From: David Howells @ 2006-08-16 9:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, linux-kernel, Trond Myklebust, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> > > SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
> >
> > I wonder if this is something to do with it.
>
> `echo 0 > /selinux/enforce' "fixes" it.
Aha!!!!
[root@andromeda ~]# ls -l /net/trash
total 87
drwxr-xr-x 2 root root 3072 Aug 10 04:10 bin/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 boot/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 dev/
drwxr-xr-x 133 root root 10240 Aug 16 10:01 etc/
drwxr-xr-x 2 root root 1024 Jul 12 09:48 home/
drwxr-xr-x 12 root root 7168 Aug 10 04:10 lib/
drwxrwsr-x 2 root cambridge 1024 Aug 1 20:41 local/
drwx------ 2 root root 12288 Aug 1 16:12 lost+found/
drwxr-xr-x 2 root root 1024 Jul 12 09:48 media/
drwxr-xr-x 2 root root 1024 Jul 24 14:17 misc/
dr-xr-xr-x 2 root root 1024 Aug 3 09:35 net/
dr-xr-xr-x 2 root root 1024 Aug 9 16:27 netopt/
?--------- ? ? ? ? ? /net/trash/mnt
?--------- ? ? ? ? ? /net/trash/usr
drwxr-xr-x 2 root root 1024 Jul 12 09:48 opt/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 proc/
dr-xr-xr-x 2 root root 1024 Aug 3 09:26 project/
drwxr-x--- 4 root root 1024 Aug 16 09:59 root/
drwxr-xr-x 2 root root 11264 Aug 10 04:10 sbin/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 selinux/
drwxr-xr-x 2 root root 1024 Jul 12 09:48 srv/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 sys/
drwxr-xr-x 3 root root 1024 Aug 1 20:27 tftpboot/
drwxrwxrwt 4 root root 3072 Aug 16 09:46 tmp/
drwxr-xr-x 29 root root 1024 Aug 1 19:56 var/
drwxr-xr-x 2 root root 1024 Aug 9 11:35 warthog/
Look familiar?
Requires: autofs4, nfs and SELinux in enforcing mode.
Check your audit logs. I knew auditing had to be good for something...
| pid 3500: autofs4_lookup: name = trash
| pid 3500: autofs4_lookup: pid = 3500, pgrp = 3500, catatonic = 0, oz_mode = 0
| pid 3500: try_to_fill_dentry: dentry=c0887354 trash ino=00000000
| pid 3500: try_to_fill_dentry: waiting for mount name=trash
| pid 3500: autofs4_wait: new wait id = 0x00000003, name = trash, nfy=1
|
| pid 3500: autofs4_notify_daemon: wait id = 0x00000003, name = trash, type=0
| audit(1155719601.431:214): avc: denied { read } for pid=3503 comm="showmount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
| audit(1155719601.483:215): avc: denied { name_bind } for pid=3503 comm="showmount" src=712 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=udp_socket
| audit(1155719601.543:216): avc: denied { read } for pid=3501 comm="automount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
| audit(1155719601.567:217): avc: denied { name_bind } for pid=3501 comm="automount" src=710 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=udp_socket
| pid 3501: autofs4_dir_mkdir: dentry c0887354, creating trash
| audit(1155719601.627:218): avc: denied { read } for pid=3507 comm="mount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:mount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
Autofs magic up to this point.
| --> nfs_init_server()
| --> nfs_get_client(trash,172.16.18.103:264,3)
| --> nfs_get_client() = c0703800 [new]
| SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
| <-- nfs_init_server() = 0 [new c0703800]
That created and initialised an NFS common client and FSID-specific client
struct (struct nfs_server).
| --> nfs_probe_fsinfo()
| <-- nfs_probe_fsinfo() = 0
| Server FSID: 303:0
Determine the FSID.
| NFS: nfs_fhget(0:18/0 ct=1)
Get the dummy root (s_root).
| NFS: nfs_fhget(0:18/2 ct=1)
Get the actual root (inode 2).
| SELinux: initialized (dev 0:18, type nfs), uses genfs_contexts
And that's the NFS superblock set up.
| pid 3507: autofs4_dentry_release: releasing c0c13514
| pid 3507: autofs4_lookup: name = trash:
| pid 3507: autofs4_lookup: pid = 3507, pgrp = 3207, catatonic = 0, oz_mode = 1
| audit(1155719601.775:219): avc: denied { read } for pid=3501 comm="automount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
| audit(1155719601.799:220): avc: denied { name_bind } for pid=3501 comm="automount" src=713 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=udp_socket
| NFS: nfs_update_inode(0:18/2 ct=1 info=0x6)
| NFS: permission(0:18/2), mask=0x1, res=0
Looks reasonable up to here.
| NFS: permission(0:18/2), mask=0x1, res=0
| NFS: lookup(/usr)
| NFS: permission(0:18/2), mask=0x3, res=0
| audit(1155719601.839:221): avc: denied { write } for pid=3501 comm="automount" name="" dev=0:18 ino=2 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
| NFS: dentry_delete(/usr, 0)
| audit(1155719601.867:222): avc: denied { read } for pid=3501 comm="automount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
| audit(1155719601.891:223): avc: denied { name_bind } for pid=3501 comm="automount" src=715 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=udp_socket
It seems that the automounter is attempting to do things to /usr.
| NFS: permission(0:18/2), mask=0x1, res=0
| NFS: permission(0:18/2), mask=0x1, res=0
| NFS: lookup(/mnt)
| NFS: permission(0:18/2), mask=0x3, res=0
| audit(1155719601.927:224): avc: denied { write } for pid=3501 comm="automount" name="" dev=0:18 ino=2 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
| NFS: dentry_delete(/mnt, 0)
And /mnt.
| pid 3207: autofs4_root_ioctl: cmd = 0x00009360, arg = 0x00000003, sbi = c54beaa0, pgrp = 3207
| pid 3500: try_to_fill_dentry: mount done status=0
| NFS: nfs_update_inode(0:18/2 ct=1 info=0x6)
| NFS: permission(0:18/2), mask=0x4, res=0
| NFS: opendir(0:18/2)
| NFS: readdir(/) starting at cookie 0
| NFS: nfs_update_inode(0:18/2 ct=1 info=0x6)
| NFS: nfs_fhget(0:18/2502657 ct=1)
| NFS: dentry_delete(/local, 0)
| NFS: nfs_fhget(0:18/10770433 ct=1)
| NFS: dentry_delete(/srv, 0)
| NFS: nfs_fhget(0:18/11 ct=1)
| NFS: dentry_delete(/lost+found, 0)
| NFS: nfs_fhget(0:18/10317825 ct=1)
| NFS: dentry_delete(/tmp, 0)
| NFS: nfs_fhget(0:18/2541569 ct=1)
| NFS: dentry_delete(/bin, 0)
| NFS: nfs_fhget(0:18/7063553 ct=1)
| NFS: dentry_delete(/media, 0)
| NFS: nfs_fhget(0:18/2594817 ct=1)
| NFS: dentry_delete(/lib, 0)
| NFS: nfs_fhget(0:18/10704897 ct=1)
| NFS: dentry_delete(/var, 0)
| NFS: dentry_delete(/usr, 8)
| NFS: dentry_delete(/mnt, 8)
And then it proceeds as normal, barring the fack that the dentried for
trash:/usr and trash:/mnt already exist.
Putting SELinux into permissive mode, I see:
: pid 3376: autofs4_lookup: name = trash
: pid 3376: autofs4_lookup: pid = 3376, pgrp = 3376, catatonic = 0, oz_mode = 0
: pid 3376: try_to_fill_dentry: dentry=c56874b4 trash ino=00000000
: pid 3376: try_to_fill_dentry: waiting for mount name=trash
: pid 3376: autofs4_wait: new wait id = 0x00000001, name = trash, nfy=1
:
: pid 3376: autofs4_notify_daemon: wait id = 0x00000001, name = trash, type=0
: pid 3377: autofs4_dir_mkdir: dentry c56874b4, creating trash
: audit(1155719382.989:183): avc: denied { read } for pid=3383 comm="mount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:mount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
: --> nfs_init_server()
: --> nfs_get_client(trash,172.16.18.103:264,3)
: --> nfs_get_client() = c752e000 [new]
: SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
: <-- nfs_init_server() = 0 [new c752e000]
: --> nfs_probe_fsinfo()
: <-- nfs_probe_fsinfo() = 0
: Server FSID: 303:0
: NFS: nfs_fhget(0:18/0 ct=1)
: NFS: nfs_fhget(0:18/2 ct=1)
: SELinux: initialized (dev 0:18, type nfs), uses genfs_contexts
: pid 3383: autofs4_lookup: name = trash:
: pid 3383: autofs4_lookup: pid = 3383, pgrp = 3207, catatonic = 0, oz_mode = 1
: NFS: nfs_update_inode(0:18/2 ct=1 info=0x6)
: NFS: permission(0:18/2), mask=0x1, res=0
Looks okay up to here.
: NFS: permission(0:18/2), mask=0x1, res=0
: NFS: lookup(/usr)
: NFS: permission(0:18/2), mask=0x3, res=0
: audit(1155719383.149:184): avc: denied { write } for pid=3377 comm="automount" name="" dev=0:18 ino=2 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
: audit(1155719383.165:185): avc: denied { add_name } for pid=3377 comm="automount" name="usr" scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
: audit(1155719383.181:186): avc: denied { create } for pid=3377 comm="automount" name="usr" scontext=root:system_r:automount_t:s0 tcontext=root:object_r:nfs_t:s0 tclass=dir
: NFS: mkdir(0:18/2), usr
What is going on here?????????????????????????????????????????????????????
stracing the automount daemon, I see:
[pid 3803] mkdir("/net", 0555) = -1 EEXIST (File exists)
[pid 3803] stat64("/net", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
[pid 3803] mkdir("/net/trash", 0555) = -1 EEXIST (File exists)
[pid 3803] stat64("/net/trash", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 3803] mkdir("/net/trash/usr", 0555) = -1 EACCES (Permission denied)
I think that would be the problem. Ian?
David
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-16 9:34 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-16 10:00 ` David Howells
2006-08-16 12:23 ` 2.6.18-rc4-mm1 David Howells
2006-08-16 12:36 ` 2.6.18-rc4-mm1 Ian Kent
1 sibling, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-16 10:00 UTC (permalink / raw)
To: Ian Kent; +Cc: Andrew Morton, linux-kernel, Trond Myklebust, David Howells
Hi Ian,
I think this is probably a problem with the automounter daemon.
What I think happens is this:
(1) I've got an NFS server (trash) with the following configuration:
[root@trash dhowells]# cat /etc/exports
/ *(rw,async)
/usr/src *(rw,async)
/mnt/export *(rw,async)
(2) I do "ls -l" on the client to use the automounter to view the root NFS
share on the machine.
(3) The automounter makes /net/trash and mounts trash:/ on it.
(4) The automount daemon asks the server what other shares it has available.
(5) For each share, the automounter attempts to create the directories on
which to mount it:
SHARE DIRECTORIES TO BE CREATED
======================= =============================================
trash:/usr/src /net/trash/usr, /net/trash/usr/src
trash:/mnt/exports /net/trash/mnt, /net/trash/mnt/exports
(6) The automount daemon issued mkdir() syscalls to create these directories,
_despite_ the fact that it is doing so in a mounted filesystem.
(7) SELinux prohibits the mkdir() syscall by refusing write permission on the
directory.
(8) An unconstructed dentry is left, which causes the "?---------" lines to
appear in the ls -l listing.
With the new internal automounting code in NFS, the automounter shouldn't
attempt to do step (4) onwards for submounts as the NFS filesystem itself will
take care of that.
And, in my opinion, it shouldn't be attempting to create directories on the
server.
However, (8) might well represent a bug in NFS.
David
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-16 10:00 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-16 12:23 ` David Howells
2006-08-16 12:58 ` 2.6.18-rc4-mm1 Ian Kent
0 siblings, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-16 12:23 UTC (permalink / raw)
To: David Howells; +Cc: Ian Kent, Andrew Morton, linux-kernel, Trond Myklebust
David Howells <dhowells@redhat.com> wrote:
> ...
> (8) An unconstructed dentry is left, which causes the "?---------" lines to
> appear in the ls -l listing.
> ...
> However, (8) might well represent a bug in NFS.
I've done some investigation into this:
The automount point before mounting has one security label and another after
mounting:
[root@andromeda ~]# ls -Zd /net/trash
dr-xr-xr-x root root system_u:object_r:autofs_t /net/trash/
[root@andromeda ~]# ls -l /net/trash
total 87
drwxr-xr-x 2 root root 3072 Aug 10 04:10 bin/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 boot/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 dev/
drwxr-xr-x 133 root root 10240 Aug 16 12:36 etc/
drwxr-xr-x 2 root root 1024 Jul 12 09:48 home/
drwxr-xr-x 12 root root 7168 Aug 10 04:10 lib/
drwxrwsr-x 2 root cambridge 1024 Aug 1 20:41 local/
drwx------ 2 root root 12288 Aug 1 16:12 lost+found/
drwxr-xr-x 2 root root 1024 Jul 12 09:48 media/
drwxr-xr-x 2 root root 1024 Jul 24 14:17 misc/
dr-xr-xr-x 2 root root 1024 Aug 3 09:35 net/
dr-xr-xr-x 2 root root 1024 Aug 9 16:27 netopt/
?--------- ? ? ? ? ? /net/trash/mnt
?--------- ? ? ? ? ? /net/trash/usr
drwxr-xr-x 2 root root 1024 Jul 12 09:48 opt/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 proc/
dr-xr-xr-x 2 root root 1024 Aug 3 09:26 project/
drwxr-x--- 7 root root 1024 Aug 16 11:49 root/
drwxr-xr-x 2 root root 11264 Aug 10 04:10 sbin/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 selinux/
drwxr-xr-x 2 root root 1024 Jul 12 09:48 srv/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 sys/
drwxr-xr-x 3 root root 1024 Aug 1 20:27 tftpboot/
drwxrwxrwt 4 root root 3072 Aug 16 11:49 tmp/
drwxr-xr-x 29 root root 1024 Aug 1 19:56 var/
drwxr-xr-x 2 root root 1024 Aug 9 11:35 warthog/
[root@andromeda ~]# ls -Zd /net/trash
drwxr-xr-x root root system_u:object_r:nfs_t /net/trash/
Automount daemons all have the automount_t label:
[root@andromeda ~]# ps -Zaux | grep automount
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.6/FAQ
root:system_r:automount_t root ... /usr/sbin/automount --timeout=60
root:system_r:automount_t root ... /usr/sbin/automount --timeout=60
root:system_r:automount_t root ... /usr/sbin/automount --timeout=60
root:system_r:automount_t root ... /usr/sbin/automount --timeout=60
I added this patch to instrument nfs_lookup():
--- fs/nfs/dir.c.orig 2006-08-14 09:08:28.000000000 +0100
+++ fs/nfs/dir.c 2006-08-16 12:49:20.000000000 +0100
@@ -890,6 +890,10 @@ static struct dentry *nfs_lookup(struct
struct nfs_fh fhandle;
struct nfs_fattr fattr;
+ printk("-->nfs_lookup(%s,%s,{%x,%x,%x})\n",
+ dentry->d_parent->d_name.name, dentry->d_name.name,
+ nd->flags, nd->intent.open.flags, nd->intent.open.create_mode);
+
dfprintk(VFS, "NFS: lookup(%s/%s)\n",
dentry->d_parent->d_name.name, dentry->d_name.name);
nfs_inc_stats(dir, NFSIOS_VFSLOOKUP);
@@ -904,8 +908,10 @@ static struct dentry *nfs_lookup(struct
lock_kernel();
/* If we're doing an exclusive create, optimize away the lookup */
- if (nfs_is_exclusive_create(dir, nd))
+ if (nfs_is_exclusive_create(dir, nd)) {
+ printk("exlusive_create\n");
goto no_entry;
+ }
error = NFS_PROTO(dir)->lookup(dir, &dentry->d_name, &fhandle, &fattr);
if (error == -ENOENT)
@@ -933,6 +939,7 @@ no_entry:
out_unlock:
unlock_kernel();
out:
+ printk("<--nfs_lookup() = %p\n", res);
return res;
}
And saw the following appear in the kernel log around the problem bit for
trash:/usr:
| ...
| SELinux: initialized (dev 0:18, type nfs), uses genfs_contexts
| audit(1155729189.533:468): avc: denied { read } for pid=6472 comm="automount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
| audit(1155729189.557:469): avc: denied { name_bind } for pid=6472 comm="automount" src=716 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=udp_socket
Not sure what's going on here. The automounter tried to do bind a socket to a
reserved port perhaps and was denied.
| NFS: nfs_update_inode(0:18/2 ct=1 info=0x6)
| NFS: permission(0:18/2), mask=0x1, res=0
sys_mkdirat() calls do_path_lookup(), which checks MAY_EXEC on the dir.
| NFS: permission(0:18/2), mask=0x1, res=0
lookup_create() is called. This calls __lookup_hash(), which checks MAY_EXEC
on the dir.
| -->nfs_lookup(,usr,{200,80,44e3069a})
__lookup_hash() then looks up the new dentry with intent to create:
VARIABLE VALUE
=============================== ===============================
nd->flags LOOKUP_CREATE
nd->intent.open.flags O_EXCL
nd->intent.open.create_mode weird value, even in octal
This means that nfs_lookup() considers this to be "an exclusive create" of
this node, and dispenses with the LOOKUP RPC call to the server.
| NFS: lookup(/usr)
| exlusive_create
Just to confirm that the lookup is skipped.
| <--nfs_lookup() = 00000000
We return the dentry we were given, but don't return an error. The dentry we
were given is left negative (on the assumption it's about to be created), but
does get attached to the directory.
| NFS: permission(0:18/2), mask=0x3, res=0
vfs_mkdir() calls may_create() which checks that the directory has MAY_WRITE
and MAY_EXEC permissions. This firstly calls nfs_permission, which grants
permission.
| audit(1155729189.605:470): avc: denied { write } for pid=6472 comm="automount" name="" dev=0:18 ino=2 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
And secondly calls security_inode_permission() though which SELinux which
_denies_ permission.
| NFS: dentry_delete(/usr, 0)
vfs_mkdir() returns -ENOACCES to sys_mkdirat() which releases its hold on the
dentry, but leaves the negative dentry attached to the directory.
The negative dentry wouldn't normally be a problem, even though it's attached
to its parent directory... except for the small matter that it's subsequently
listed in a directory read operation.
However, the dcache still retains the negative dentry. I'm not sure how to
deal with this. I think nfs_lookup() _must_ contact the server and prefill
the dentry if it can. Trond?
David
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-16 12:23 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-16 12:58 ` Ian Kent
2006-08-16 13:20 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 1 reply; 192+ messages in thread
From: Ian Kent @ 2006-08-16 12:58 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, linux-kernel, Trond Myklebust
On Wed, 2006-08-16 at 13:23 +0100, David Howells wrote:
> And saw the following appear in the kernel log around the problem bit for
> trash:/usr:
>
> | ...
> | SELinux: initialized (dev 0:18, type nfs), uses genfs_contexts
> | audit(1155729189.533:468): avc: denied { read } for pid=6472 comm="automount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
> | audit(1155729189.557:469): avc: denied { name_bind } for pid=6472 comm="automount" src=716 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=udp_socket
>
> Not sure what's going on here. The automounter tried to do bind a socket to a
> reserved port perhaps and was denied.
Possibly an RPC ping.
That's about the only thing I do that does net connects.
>
> | NFS: nfs_update_inode(0:18/2 ct=1 info=0x6)
> | NFS: permission(0:18/2), mask=0x1, res=0
>
> sys_mkdirat() calls do_path_lookup(), which checks MAY_EXEC on the dir.
>
> | NFS: permission(0:18/2), mask=0x1, res=0
>
> lookup_create() is called. This calls __lookup_hash(), which checks MAY_EXEC
> on the dir.
>
> | -->nfs_lookup(,usr,{200,80,44e3069a})
>
> __lookup_hash() then looks up the new dentry with intent to create:
>
> VARIABLE VALUE
> =============================== ===============================
> nd->flags LOOKUP_CREATE
> nd->intent.open.flags O_EXCL
> nd->intent.open.create_mode weird value, even in octal
I'm fairly sure there's a race in autofs for the create case. I've tried
to work a solution in the past but haven't been successful yet. In any
case autofs should not allow anyone else besides the daemon to do
anything in the autofs fs. It's been a while but I think this case leads
to a deadlock.
>
> This means that nfs_lookup() considers this to be "an exclusive create" of
> this node, and dispenses with the LOOKUP RPC call to the server.
>
> | NFS: lookup(/usr)
> | exlusive_create
>
> Just to confirm that the lookup is skipped.
>
> | <--nfs_lookup() = 00000000
>
> We return the dentry we were given, but don't return an error. The dentry we
> were given is left negative (on the assumption it's about to be created), but
> does get attached to the directory.
>
> | NFS: permission(0:18/2), mask=0x3, res=0
>
> vfs_mkdir() calls may_create() which checks that the directory has MAY_WRITE
> and MAY_EXEC permissions. This firstly calls nfs_permission, which grants
> permission.
>
> | audit(1155729189.605:470): avc: denied { write } for pid=6472 comm="automount" name="" dev=0:18 ino=2 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
>
> And secondly calls security_inode_permission() though which SELinux which
> _denies_ permission.
>
> | NFS: dentry_delete(/usr, 0)
>
> vfs_mkdir() returns -ENOACCES to sys_mkdirat() which releases its hold on the
> dentry, but leaves the negative dentry attached to the directory.
>
>
> The negative dentry wouldn't normally be a problem, even though it's attached
> to its parent directory... except for the small matter that it's subsequently
> listed in a directory read operation.
Surely this dentry should also be unhashed at some point.
Wouldn't that be a sensible result of the failed operation?
It wouldn't then show up in a listing and the fs should normally be able
to deal with these.
Ian
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-16 12:58 ` 2.6.18-rc4-mm1 Ian Kent
@ 2006-08-16 13:20 ` David Howells
0 siblings, 0 replies; 192+ messages in thread
From: David Howells @ 2006-08-16 13:20 UTC (permalink / raw)
To: Ian Kent; +Cc: David Howells, Andrew Morton, linux-kernel, Trond Myklebust
Ian Kent <raven@themaw.net> wrote:
> > The negative dentry wouldn't normally be a problem, even though it's
> > attached to its parent directory... except for the small matter that it's
> > subsequently listed in a directory read operation.
>
> Surely this dentry should also be unhashed at some point.
> Wouldn't that be a sensible result of the failed operation?
Why? The lookup op succeeded, so obviously there wasn't anything there,
right?
Note that nfs_lookup_revalidate() doesn't cause the dentry to be revalidated
because the mtime on the parent directory hasn't changed.
I'm considering having nfs_readdir_lookup() mark a negative dentry it
encounters as named in a directory listing for explicit revalidation, but I
can't call nfs_mark_for_revalidate() since I don't have an inode.
I think I'll need to add a dentry flag for this purpose.
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-16 9:34 ` 2.6.18-rc4-mm1 David Howells
2006-08-16 10:00 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-16 12:36 ` Ian Kent
1 sibling, 0 replies; 192+ messages in thread
From: Ian Kent @ 2006-08-16 12:36 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, linux-kernel, Trond Myklebust
On Wed, 2006-08-16 at 10:34 +0100, David Howells wrote:
> Andrew Morton <akpm@osdl.org> wrote:
>
....
> What is going on here?????????????????????????????????????????????????????
>
> stracing the automount daemon, I see:
>
> [pid 3803] mkdir("/net", 0555) = -1 EEXIST (File exists)
> [pid 3803] stat64("/net", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> [pid 3803] mkdir("/net/trash", 0555) = -1 EEXIST (File exists)
> [pid 3803] stat64("/net/trash", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
> [pid 3803] mkdir("/net/trash/usr", 0555) = -1 EACCES (Permission denied)
>
> I think that would be the problem. Ian?
I guess, but it's also possible that multi-entry mounts similar to those
generated by the auto.net script need mount point directories created.
The same code is used for all.
I guess that I could check if the fs is autofs4 and only mount the
mounts for directories that exist, as I do in v5. However, people may
have come to rely on this so it would be a regression, for v4 at least.
Thoughts?
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
` (2 preceding siblings ...)
2006-08-14 18:32 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-14 22:49 ` Trond Myklebust
2006-08-14 23:51 ` 2.6.18-rc4-mm1 Andrew Morton
` (2 more replies)
2006-08-16 15:15 ` [PATCH] NFS: Revalidate on readdir referring to null dentry David Howells
4 siblings, 3 replies; 192+ messages in thread
From: Trond Myklebust @ 2006-08-14 22:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, David Howells, Ian Kent
On Sun, 2006-08-13 at 13:39 -0700, Andrew Morton wrote:
> On Sun, 13 Aug 2006 01:24:54 -0700
> Andrew Morton <akpm@osdl.org> wrote:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> This kernel breaks autofs /net handling. Bisection shows that the bug is
> introduced by git-nfs.patch.
Could you try pulling afresh from the NFS git tree? I've fixed up a
couple of issues in which rpc_pipefs was corrupting the dcache, as well
as a few dentry leaks that were introduced by David's
nfs_alloc_client().
Cheers,
Trond
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-14 22:49 ` 2.6.18-rc4-mm1 Trond Myklebust
@ 2006-08-14 23:51 ` Andrew Morton
2006-08-15 16:39 ` 2.6.18-rc4-mm1 David Howells
2006-08-15 16:55 ` 2.6.18-rc4-mm1 David Howells
2 siblings, 0 replies; 192+ messages in thread
From: Andrew Morton @ 2006-08-14 23:51 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-kernel, David Howells, Ian Kent
On Mon, 14 Aug 2006 18:49:27 -0400
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> On Sun, 2006-08-13 at 13:39 -0700, Andrew Morton wrote:
> > On Sun, 13 Aug 2006 01:24:54 -0700
> > Andrew Morton <akpm@osdl.org> wrote:
> >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >
> > This kernel breaks autofs /net handling. Bisection shows that the bug is
> > introduced by git-nfs.patch.
>
> Could you try pulling afresh from the NFS git tree?
Did that - there is no change.
> I've fixed up a
> couple of issues in which rpc_pipefs was corrupting the dcache, as well
> as a few dentry leaks that were introduced by David's
> nfs_alloc_client().
I tested just bare 2.6.18-rc4+git-nfs.patch to eliminate any -mm unknowns.
The problem remains.
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 22:49 ` 2.6.18-rc4-mm1 Trond Myklebust
2006-08-14 23:51 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-15 16:39 ` David Howells
2006-08-15 16:55 ` 2.6.18-rc4-mm1 David Howells
2 siblings, 0 replies; 192+ messages in thread
From: David Howells @ 2006-08-15 16:39 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Andrew Morton, linux-kernel, David Howells, Ian Kent
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> as well as a few dentry leaks that were introduced by David's
> nfs_alloc_client().
I'm really quite surprised that I haven't seen these bugs.
Acked-By: David Howells <dhowells@redhat.com>
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 22:49 ` 2.6.18-rc4-mm1 Trond Myklebust
2006-08-14 23:51 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 16:39 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-15 16:55 ` David Howells
2006-08-15 17:13 ` 2.6.18-rc4-mm1 Trond Myklebust
2 siblings, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-15 16:55 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Andrew Morton, linux-kernel, David Howells, Ian Kent
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> Could you try pulling afresh from the NFS git tree? I've fixed up a couple
> of issues in which rpc_pipefs was corrupting the dcache,
Which patches hold those fixes? I'm seeing:
BUG: atomic counter underflow at:
[<c01d5b05>] _atomic_dec_and_lock+0x1d/0x30
[<c0169bd3>] dput+0x22/0x145
[<c8a2f726>] rpc_destroy_client+0xd9/0xee [sunrpc]
[<c8a2f89e>] rpc_shutdown_client+0xea/0xf1 [sunrpc]
[<c8a2f89e>] rpc_shutdown_client+0xea/0xf1 [sunrpc]
[<c886d842>] nfs_free_client+0x95/0xdd [nfs]
[<c886db38>] nfs_free_server+0xa9/0xd9 [nfs]
[<c8873fae>] nfs_kill_super+0xc/0x14 [nfs]
[<c015c033>] deactivate_super+0x4a/0x5d
[<c016df3e>] sys_umount+0x1d3/0x1f1
[<c016ac98>] destroy_inode+0x36/0x45
[<c0169bd3>] dput+0x22/0x145
[<c0157889>] __fput+0x146/0x170
[<c016cf48>] mntput_no_expire+0x11/0x59
[<c016df73>] sys_oldumount+0x17/0x1a
[<c0102b3f>] syscall_call+0x7/0xb
=======================
And I'm wondering if that's due to that problem.
I've applied the patch to fix the resource counting that's at the head of your
git tree.
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 16:55 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-15 17:13 ` Trond Myklebust
2006-08-15 17:22 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 1 reply; 192+ messages in thread
From: Trond Myklebust @ 2006-08-15 17:13 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, linux-kernel, Ian Kent
[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]
On Tue, 2006-08-15 at 17:55 +0100, David Howells wrote:
> Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> > Could you try pulling afresh from the NFS git tree? I've fixed up a couple
> > of issues in which rpc_pipefs was corrupting the dcache,
>
> Which patches hold those fixes? I'm seeing:
>
> BUG: atomic counter underflow at:
> [<c01d5b05>] _atomic_dec_and_lock+0x1d/0x30
> [<c0169bd3>] dput+0x22/0x145
> [<c8a2f726>] rpc_destroy_client+0xd9/0xee [sunrpc]
> [<c8a2f89e>] rpc_shutdown_client+0xea/0xf1 [sunrpc]
> [<c8a2f89e>] rpc_shutdown_client+0xea/0xf1 [sunrpc]
> [<c886d842>] nfs_free_client+0x95/0xdd [nfs]
> [<c886db38>] nfs_free_server+0xa9/0xd9 [nfs]
> [<c8873fae>] nfs_kill_super+0xc/0x14 [nfs]
> [<c015c033>] deactivate_super+0x4a/0x5d
> [<c016df3e>] sys_umount+0x1d3/0x1f1
> [<c016ac98>] destroy_inode+0x36/0x45
> [<c0169bd3>] dput+0x22/0x145
> [<c0157889>] __fput+0x146/0x170
> [<c016cf48>] mntput_no_expire+0x11/0x59
> [<c016df73>] sys_oldumount+0x17/0x1a
> [<c0102b3f>] syscall_call+0x7/0xb
> =======================
>
> And I'm wondering if that's due to that problem.
>
> I've applied the patch to fix the resource counting that's at the head of your
> git tree.
See attached mail. Alex confirmed that it fixes the corruption problems
he is seeing.
Cheers,
Trond
[-- Attachment #2: Attached message - Re: [PATCHv3] sunrpc/auth_gss: NULL pointer deref in gss_pipe_release() --]
[-- Type: message/rfc822, Size: 3868 bytes --]
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Alex Polvi <polvi@google.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCHv3] sunrpc/auth_gss: NULL pointer deref in gss_pipe_release()
Date: Mon, 14 Aug 2006 18:46:39 -0400
Message-ID: <1155595592.5656.22.camel@localhost>
On Mon, 2006-08-14 at 16:34 -0400, Alex Polvi wrote:
> On 8/14/06, Alex Polvi <polvi@google.com> wrote:
> > Here is another fix. It is quite silly, but clnt->cl_auth is set to
> > NULL in rpc_destroy_client(), then eventually referenced in
> > gss_release_pipe() via rpc_rmdir(). Simply removing the clnt->cl_auth
> > = NULL from clnt.c fixes the issue. I'm still trying to understand the
> > subsystem, but it seems like rpc_rmdir is being correctly called to
> > clean up because of the weirdness with umount -l and the nfs server
> > being turned on and off. Does that seem correct? Or is this still just
> > covering up some other part of the code being sloppy cleaning up?
>
> Also, I just want to make it clear that I do not think this is the
> proper fix. It is just pointing out that we intentionally set cl_auth
> to NULL, then reference it.
OK. I think I've finally managed to clean up the various interactions
with rpc_pipefs. I've uploaded a series of patches on the NFS client
website. See
http://client.linux-nfs.org/Linux-2.6.x/2.6.18-rc4/
The relevant patches are
linux-2.6.18-006-fix_rpc_unlink.dif:
From: Trond Myklebust <Trond.Myklebust@netapp.com>
SUNRPC: make rpc_unlink() take a dentry argument instead of a
path
Signe-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
linux-2.6.18-007-fix_rpc_rmdir.dif:
From: Trond Myklebust <Trond.Myklebust@netapp.com>
NFS: clean up rpc_rmdir
Make it take a dentry argument instead of a path
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
linux-2.6.18-008-fix_rpc_unlink_rmdir_2.dif:
From: Trond Myklebust <Trond.Myklebust@netapp.com>
SUNRPC: rpc_unlink() must check for unhashed dentries
A prior call to rpc_depopulate() by rpc_rmdir() on the parent
directory may have already called simple_unlink() on this entry.
Add the same check to rpc_rmdir(). Also remove a redundant call
to rpc_close_pipes() in rpc_rmdir.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
linux-2.6.18-009-fix_rpc_unlink_rmdir_3.dif:
From: Trond Myklebust <Trond.Myklebust@netapp.com>
SUNRPC: Fix dentry refcounting issues with users of rpc_pipefs
rpc_unlink() and rpc_rmdir() will dput the dentry reference for
you.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
----
In addition, there is one patch that is needed in order to fix up a
related issue in the function nfs_alloc_client(), which was introduced
by David Howells' NFS superblock sharing patches.
Cheers,
Trond
^ permalink raw reply [flat|nested] 192+ messages in thread
* [PATCH] NFS: Revalidate on readdir referring to null dentry
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
` (3 preceding siblings ...)
2006-08-14 22:49 ` 2.6.18-rc4-mm1 Trond Myklebust
@ 2006-08-16 15:15 ` David Howells
2006-08-16 15:49 ` Trond Myklebust
4 siblings, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-16 15:15 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, Trond Myklebust, aviro, David Howells, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> This kernel breaks autofs /net handling. Bisection shows that the bug is
> introduced by git-nfs.patch.
Does this patch fix your problem?
David
---
NFS: Revalidate on readdir referring to null dentry
From: David Howells <dhowells@redhat.com>
Have nfs_readdir_lookup() force dentry revalidation when it comes across a
name specified by a READDIR RPC call that corresponds to a negative dentry in
the dcache.
This can be caused by an optimisation in nfs_lookup() that causes a dentry to
be incorrectly left as negative when mkdir() or similar is aborted by SELinux
mid-procedure.
This can be triggered by mounting through autofs4 a server:/ NFS share for
which there are other exports available on that server. SELinux also has to
be turned on in enforcing mode to abort mid-flow the mkdir operation performed
by autofs4.
The problematic sequence of events is this:
(1) nfs_lookup() is called by sys_mkdirat() -> lookup_create() ->
__lookup_hash() with intent to create exclusively set in the nameidata:
nd->flags == LOOKUP_CREATE
nd->intent.open.flags == O_EXCL
(2) nfs_lookup() has an optimisation to avoid going to the server in this
case, presumably since the nfs_mkdir() op or whatever will deal with the
conflict.
(3) nfs_lookup() returns successfully, leaving the dentry in a negative state,
but attached to the parent directory.
(4) sys_mkdirat() calls vfs_mkdir() which calls may_create(). may_create()
checks that the directory has MAY_WRITE and MAY_EXEC permissions.
(5) may_create() calls nfs_permission(), which grants permission.
(6) may_create() calls security_inode_permission(), which calls SELinux, which
then _DENIES_ permission.
(7) may_create() fails, and vfs_mkdir() then fails and sys_mkdirat() then
fails (as does sys_mkdir).
_However_, the new dentry is left in the negative state, with no
consultation of the server.
(8) The parent directory is listed, and the name of the new dentry is
returned.
(9) stat on the new dentry fails (because it's negative), and "ls -l" returns
"?---------" as the file type and mode.
This fix makes step (8) cause a revalidation to occur on the dentry at the
start of step (9).
Signed-Off-By: David Howells <dhowells@redhat.com>
---
fs/nfs/dir.c | 16 +++++++++++++++-
include/linux/dcache.h | 5 +++++
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index e746ed1..901b382 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -745,6 +745,13 @@ static int nfs_lookup_revalidate(struct
nfs_inc_stats(dir, NFSIOS_DENTRYREVALIDATE);
inode = dentry->d_inode;
+ if (dentry->d_flags & DCACHE_NEED_REVALIDATE) {
+ spin_lock(&dentry->d_lock);
+ dentry->d_flags &= ~DCACHE_NEED_REVALIDATE;
+ spin_unlock(&dentry->d_lock);
+ goto out_bad;
+ }
+
if (!inode) {
if (nfs_neg_need_reval(dir, dentry, nd))
goto out_bad;
@@ -1105,8 +1112,15 @@ static struct dentry *nfs_readdir_lookup
}
name.hash = full_name_hash(name.name, name.len);
dentry = d_lookup(parent, &name);
- if (dentry != NULL)
+ if (dentry != NULL) {
+ /* negative dentries must be reconsidered */
+ if (!IS_ERR(dentry) && !dentry->d_inode) {
+ spin_lock(&dentry->d_lock);
+ dentry->d_flags |= DCACHE_NEED_REVALIDATE;
+ spin_unlock(&dentry->d_lock);
+ }
return dentry;
+ }
if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR))
return NULL;
/* Note: caller is already holding the dir->i_mutex! */
diff --git a/include/linux/dcache.h b/include/linux/dcache.h
index 63f64a9..c401a7d 100644
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -176,6 +176,11 @@ #define DCACHE_UNHASHED 0x0010
#define DCACHE_INOTIFY_PARENT_WATCHED 0x0020 /* Parent inode is watched */
+#define DCACHE_NEED_REVALIDATE 0x0040
+ /* Dentry needs revalidation by filesystem. Set by NFS, for example,
+ * when we see in a directory listing a file for which we have a
+ * negative dentry */
+
extern spinlock_t dcache_lock;
/**
^ permalink raw reply related [flat|nested] 192+ messages in thread* Re: [PATCH] NFS: Revalidate on readdir referring to null dentry
2006-08-16 15:15 ` [PATCH] NFS: Revalidate on readdir referring to null dentry David Howells
@ 2006-08-16 15:49 ` Trond Myklebust
2006-08-16 16:15 ` [PATCH] NFS: Replace null dentries that appear in readdir's list David Howells
0 siblings, 1 reply; 192+ messages in thread
From: Trond Myklebust @ 2006-08-16 15:49 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, linux-kernel, aviro, Ian Kent
On Wed, 2006-08-16 at 16:15 +0100, David Howells wrote:
> Andrew Morton <akpm@osdl.org> wrote:
>
> > This kernel breaks autofs /net handling. Bisection shows that the bug is
> > introduced by git-nfs.patch.
>
> Does this patch fix your problem?
>
> David
> ---
> NFS: Revalidate on readdir referring to null dentry
>
> From: David Howells <dhowells@redhat.com>
>
> Have nfs_readdir_lookup() force dentry revalidation when it comes across a
> name specified by a READDIR RPC call that corresponds to a negative dentry in
> the dcache.
>
> This can be caused by an optimisation in nfs_lookup() that causes a dentry to
> be incorrectly left as negative when mkdir() or similar is aborted by SELinux
> mid-procedure.
>
> This can be triggered by mounting through autofs4 a server:/ NFS share for
> which there are other exports available on that server. SELinux also has to
> be turned on in enforcing mode to abort mid-flow the mkdir operation performed
> by autofs4.
>
> The problematic sequence of events is this:
>
> (1) nfs_lookup() is called by sys_mkdirat() -> lookup_create() ->
> __lookup_hash() with intent to create exclusively set in the nameidata:
>
> nd->flags == LOOKUP_CREATE
> nd->intent.open.flags == O_EXCL
>
> (2) nfs_lookup() has an optimisation to avoid going to the server in this
> case, presumably since the nfs_mkdir() op or whatever will deal with the
> conflict.
>
> (3) nfs_lookup() returns successfully, leaving the dentry in a negative state,
> but attached to the parent directory.
>
> (4) sys_mkdirat() calls vfs_mkdir() which calls may_create(). may_create()
> checks that the directory has MAY_WRITE and MAY_EXEC permissions.
>
> (5) may_create() calls nfs_permission(), which grants permission.
>
> (6) may_create() calls security_inode_permission(), which calls SELinux, which
> then _DENIES_ permission.
>
> (7) may_create() fails, and vfs_mkdir() then fails and sys_mkdirat() then
> fails (as does sys_mkdir).
>
> _However_, the new dentry is left in the negative state, with no
> consultation of the server.
>
> (8) The parent directory is listed, and the name of the new dentry is
> returned.
>
> (9) stat on the new dentry fails (because it's negative), and "ls -l" returns
> "?---------" as the file type and mode.
>
> This fix makes step (8) cause a revalidation to occur on the dentry at the
> start of step (9).
>
> Signed-Off-By: David Howells <dhowells@redhat.com>
> ---
>
> fs/nfs/dir.c | 16 +++++++++++++++-
> include/linux/dcache.h | 5 +++++
> 2 files changed, 20 insertions(+), 1 deletions(-)
>
> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> index e746ed1..901b382 100644
> --- a/fs/nfs/dir.c
> +++ b/fs/nfs/dir.c
> @@ -745,6 +745,13 @@ static int nfs_lookup_revalidate(struct
> nfs_inc_stats(dir, NFSIOS_DENTRYREVALIDATE);
> inode = dentry->d_inode;
>
> + if (dentry->d_flags & DCACHE_NEED_REVALIDATE) {
This flag is redundant. There already exist methods for determining if a
dentry needs revalidation by means of the nfs_*_verifier() functions. If
you want to force a dentry lookup upon next revalidation, then add
something like
void nfs_dentry_force_revalidate(struct inode *dir, struct dentry *dentry)
{
nfs_set_verifier(dentry, nfs_save_change_attribute(dir) - 1);
}
Better still, in the case of a negative dentry: just call d_drop().
Cheers,
Trond
> + spin_lock(&dentry->d_lock);
> + dentry->d_flags &= ~DCACHE_NEED_REVALIDATE;
> + spin_unlock(&dentry->d_lock);
> + goto out_bad;
> + }
> +
> if (!inode) {
> if (nfs_neg_need_reval(dir, dentry, nd))
> goto out_bad;
> @@ -1105,8 +1112,15 @@ static struct dentry *nfs_readdir_lookup
> }
> name.hash = full_name_hash(name.name, name.len);
> dentry = d_lookup(parent, &name);
> - if (dentry != NULL)
> + if (dentry != NULL) {
> + /* negative dentries must be reconsidered */
> + if (!IS_ERR(dentry) && !dentry->d_inode) {
> + spin_lock(&dentry->d_lock);
> + dentry->d_flags |= DCACHE_NEED_REVALIDATE;
> + spin_unlock(&dentry->d_lock);
> + }
> return dentry;
> + }
> if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR))
> return NULL;
> /* Note: caller is already holding the dir->i_mutex! */
> diff --git a/include/linux/dcache.h b/include/linux/dcache.h
> index 63f64a9..c401a7d 100644
> --- a/include/linux/dcache.h
> +++ b/include/linux/dcache.h
> @@ -176,6 +176,11 @@ #define DCACHE_UNHASHED 0x0010
>
> #define DCACHE_INOTIFY_PARENT_WATCHED 0x0020 /* Parent inode is watched */
>
> +#define DCACHE_NEED_REVALIDATE 0x0040
> + /* Dentry needs revalidation by filesystem. Set by NFS, for example,
> + * when we see in a directory listing a file for which we have a
> + * negative dentry */
> +
> extern spinlock_t dcache_lock;
>
> /**
^ permalink raw reply [flat|nested] 192+ messages in thread* [PATCH] NFS: Replace null dentries that appear in readdir's list
2006-08-16 15:49 ` Trond Myklebust
@ 2006-08-16 16:15 ` David Howells
2006-08-16 16:35 ` Trond Myklebust
` (5 more replies)
0 siblings, 6 replies; 192+ messages in thread
From: David Howells @ 2006-08-16 16:15 UTC (permalink / raw)
To: Andrew Morton, Trond Myklebust
Cc: David Howells, linux-kernel, aviro, Ian Kent
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> Better still, in the case of a negative dentry: just call d_drop().
How about this then?
David
---
NFS: Replace null dentries that appear in readdir's list
From: David Howells <dhowells@redhat.com>
Have nfs_readdir_lookup() drop and replace any null dentry when it
that gets listed by a READDIR RPC call.
This can be caused by an optimisation in nfs_lookup() that causes a dentry to
be incorrectly left as negative when mkdir() or similar is aborted by SELinux
mid-procedure.
This can be triggered by mounting through autofs4 a server:/ NFS share for
which there are other exports available on that server. SELinux also has to
be turned on in enforcing mode to abort mid-flow the mkdir operation performed
by autofs4.
The problematic sequence of events is this:
(1) nfs_lookup() is called by sys_mkdirat() -> lookup_create() ->
__lookup_hash() with intent to create exclusively set in the nameidata:
nd->flags == LOOKUP_CREATE
nd->intent.open.flags == O_EXCL
(2) nfs_lookup() has an optimisation to avoid going to the server in this
case, presumably since the nfs_mkdir() op or whatever will deal with the
conflict.
(3) nfs_lookup() returns successfully, leaving the dentry in a negative state,
but attached to the parent directory.
(4) sys_mkdirat() calls vfs_mkdir() which calls may_create(). may_create()
checks that the directory has MAY_WRITE and MAY_EXEC permissions.
(5) may_create() calls nfs_permission(), which grants permission.
(6) may_create() calls security_inode_permission(), which calls SELinux, which
then _DENIES_ permission.
(7) may_create() fails, and vfs_mkdir() then fails and sys_mkdirat() then
fails (as does sys_mkdir).
_However_, the new dentry is left in the negative state, with no
consultation of the server.
(8) The parent directory is listed, and the name of the new dentry is
returned.
(9) stat on the new dentry fails (because it's negative), and "ls -l" returns
"?---------" as the file type and mode.
This fix makes step (8) replace the dentry looked up in steps (1) - (3).
Signed-Off-By: David Howells <dhowells@redhat.com>
---
fs/nfs/dir.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index e746ed1..bb8b5f0 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1105,8 +1105,13 @@ static struct dentry *nfs_readdir_lookup
}
name.hash = full_name_hash(name.name, name.len);
dentry = d_lookup(parent, &name);
- if (dentry != NULL)
- return dentry;
+ if (dentry != NULL) {
+ /* negative dentries must be reconsidered */
+ if (!IS_ERR(dentry) && !dentry->d_inode)
+ d_drop(dentry);
+ else
+ return dentry;
+ }
if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR))
return NULL;
/* Note: caller is already holding the dir->i_mutex! */
^ permalink raw reply related [flat|nested] 192+ messages in thread* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list
2006-08-16 16:15 ` [PATCH] NFS: Replace null dentries that appear in readdir's list David Howells
@ 2006-08-16 16:35 ` Trond Myklebust
2006-08-17 5:12 ` Ian Kent
` (4 subsequent siblings)
5 siblings, 0 replies; 192+ messages in thread
From: Trond Myklebust @ 2006-08-16 16:35 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, linux-kernel, aviro, Ian Kent
On Wed, 2006-08-16 at 17:15 +0100, David Howells wrote:
> Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> > Better still, in the case of a negative dentry: just call d_drop().
>
> How about this then?
Yup. That would do it.
Cheers,
Trond
> David
> ---
> NFS: Replace null dentries that appear in readdir's list
>
> From: David Howells <dhowells@redhat.com>
>
> Have nfs_readdir_lookup() drop and replace any null dentry when it
> that gets listed by a READDIR RPC call.
>
> This can be caused by an optimisation in nfs_lookup() that causes a dentry to
> be incorrectly left as negative when mkdir() or similar is aborted by SELinux
> mid-procedure.
>
> This can be triggered by mounting through autofs4 a server:/ NFS share for
> which there are other exports available on that server. SELinux also has to
> be turned on in enforcing mode to abort mid-flow the mkdir operation performed
> by autofs4.
>
> The problematic sequence of events is this:
>
> (1) nfs_lookup() is called by sys_mkdirat() -> lookup_create() ->
> __lookup_hash() with intent to create exclusively set in the nameidata:
>
> nd->flags == LOOKUP_CREATE
> nd->intent.open.flags == O_EXCL
>
> (2) nfs_lookup() has an optimisation to avoid going to the server in this
> case, presumably since the nfs_mkdir() op or whatever will deal with the
> conflict.
>
> (3) nfs_lookup() returns successfully, leaving the dentry in a negative state,
> but attached to the parent directory.
>
> (4) sys_mkdirat() calls vfs_mkdir() which calls may_create(). may_create()
> checks that the directory has MAY_WRITE and MAY_EXEC permissions.
>
> (5) may_create() calls nfs_permission(), which grants permission.
>
> (6) may_create() calls security_inode_permission(), which calls SELinux, which
> then _DENIES_ permission.
>
> (7) may_create() fails, and vfs_mkdir() then fails and sys_mkdirat() then
> fails (as does sys_mkdir).
>
> _However_, the new dentry is left in the negative state, with no
> consultation of the server.
>
> (8) The parent directory is listed, and the name of the new dentry is
> returned.
>
> (9) stat on the new dentry fails (because it's negative), and "ls -l" returns
> "?---------" as the file type and mode.
>
> This fix makes step (8) replace the dentry looked up in steps (1) - (3).
>
> Signed-Off-By: David Howells <dhowells@redhat.com>
> ---
>
> fs/nfs/dir.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> index e746ed1..bb8b5f0 100644
> --- a/fs/nfs/dir.c
> +++ b/fs/nfs/dir.c
> @@ -1105,8 +1105,13 @@ static struct dentry *nfs_readdir_lookup
> }
> name.hash = full_name_hash(name.name, name.len);
> dentry = d_lookup(parent, &name);
> - if (dentry != NULL)
> - return dentry;
> + if (dentry != NULL) {
> + /* negative dentries must be reconsidered */
> + if (!IS_ERR(dentry) && !dentry->d_inode)
> + d_drop(dentry);
> + else
> + return dentry;
> + }
> if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR))
> return NULL;
> /* Note: caller is already holding the dir->i_mutex! */
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list
2006-08-16 16:15 ` [PATCH] NFS: Replace null dentries that appear in readdir's list David Howells
2006-08-16 16:35 ` Trond Myklebust
@ 2006-08-17 5:12 ` Ian Kent
2006-08-17 7:42 ` Andrew Morton
` (3 subsequent siblings)
5 siblings, 0 replies; 192+ messages in thread
From: Ian Kent @ 2006-08-17 5:12 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, Trond Myklebust, linux-kernel, aviro
On Wed, 2006-08-16 at 17:15 +0100, David Howells wrote:
> Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> > Better still, in the case of a negative dentry: just call d_drop().
Yes, unhashing the dentry will make it invisible but I thought your
point was that the server hadn't actually been contacted when I
suggested it before. Is that a concern?
>
> How about this then?
>
> David
> ---
> NFS: Replace null dentries that appear in readdir's list
>
> From: David Howells <dhowells@redhat.com>
>
> Have nfs_readdir_lookup() drop and replace any null dentry when it
> that gets listed by a READDIR RPC call.
>
> This can be caused by an optimisation in nfs_lookup() that causes a dentry to
> be incorrectly left as negative when mkdir() or similar is aborted by SELinux
> mid-procedure.
>
> This can be triggered by mounting through autofs4 a server:/ NFS share for
> which there are other exports available on that server. SELinux also has to
> be turned on in enforcing mode to abort mid-flow the mkdir operation performed
> by autofs4.
>
> The problematic sequence of events is this:
>
> (1) nfs_lookup() is called by sys_mkdirat() -> lookup_create() ->
> __lookup_hash() with intent to create exclusively set in the nameidata:
>
> nd->flags == LOOKUP_CREATE
> nd->intent.open.flags == O_EXCL
>
> (2) nfs_lookup() has an optimisation to avoid going to the server in this
> case, presumably since the nfs_mkdir() op or whatever will deal with the
> conflict.
>
> (3) nfs_lookup() returns successfully, leaving the dentry in a negative state,
> but attached to the parent directory.
>
> (4) sys_mkdirat() calls vfs_mkdir() which calls may_create(). may_create()
> checks that the directory has MAY_WRITE and MAY_EXEC permissions.
>
> (5) may_create() calls nfs_permission(), which grants permission.
>
> (6) may_create() calls security_inode_permission(), which calls SELinux, which
> then _DENIES_ permission.
>
> (7) may_create() fails, and vfs_mkdir() then fails and sys_mkdirat() then
> fails (as does sys_mkdir).
>
> _However_, the new dentry is left in the negative state, with no
> consultation of the server.
>
> (8) The parent directory is listed, and the name of the new dentry is
> returned.
>
> (9) stat on the new dentry fails (because it's negative), and "ls -l" returns
> "?---------" as the file type and mode.
>
> This fix makes step (8) replace the dentry looked up in steps (1) - (3).
>
> Signed-Off-By: David Howells <dhowells@redhat.com>
> ---
>
> fs/nfs/dir.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> index e746ed1..bb8b5f0 100644
> --- a/fs/nfs/dir.c
> +++ b/fs/nfs/dir.c
> @@ -1105,8 +1105,13 @@ static struct dentry *nfs_readdir_lookup
> }
> name.hash = full_name_hash(name.name, name.len);
> dentry = d_lookup(parent, &name);
> - if (dentry != NULL)
> - return dentry;
> + if (dentry != NULL) {
> + /* negative dentries must be reconsidered */
> + if (!IS_ERR(dentry) && !dentry->d_inode)
> + d_drop(dentry);
> + else
> + return dentry;
> + }
> if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR))
> return NULL;
> /* Note: caller is already holding the dir->i_mutex! */
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list
2006-08-16 16:15 ` [PATCH] NFS: Replace null dentries that appear in readdir's list David Howells
2006-08-16 16:35 ` Trond Myklebust
2006-08-17 5:12 ` Ian Kent
@ 2006-08-17 7:42 ` Andrew Morton
2006-08-17 12:13 ` David Howells
` (2 more replies)
2006-08-18 0:47 ` Ian Kent
` (2 subsequent siblings)
5 siblings, 3 replies; 192+ messages in thread
From: Andrew Morton @ 2006-08-17 7:42 UTC (permalink / raw)
To: David Howells; +Cc: Trond Myklebust, linux-kernel, aviro, Ian Kent
On Wed, 16 Aug 2006 17:15:59 +0100
David Howells <dhowells@redhat.com> wrote:
>
> Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> > Better still, in the case of a negative dentry: just call d_drop().
>
> How about this then?
>
> David
> ---
> NFS: Replace null dentries that appear in readdir's list
>
> From: David Howells <dhowells@redhat.com>
>
> Have nfs_readdir_lookup() drop and replace any null dentry when it
> that gets listed by a READDIR RPC call.
>
> This can be caused by an optimisation in nfs_lookup() that causes a dentry to
> be incorrectly left as negative when mkdir() or similar is aborted by SELinux
> mid-procedure.
>
> This can be triggered by mounting through autofs4 a server:/ NFS share for
> which there are other exports available on that server. SELinux also has to
> be turned on in enforcing mode to abort mid-flow the mkdir operation performed
> by autofs4.
>
> The problematic sequence of events is this:
>
> (1) nfs_lookup() is called by sys_mkdirat() -> lookup_create() ->
> __lookup_hash() with intent to create exclusively set in the nameidata:
>
> nd->flags == LOOKUP_CREATE
> nd->intent.open.flags == O_EXCL
>
> (2) nfs_lookup() has an optimisation to avoid going to the server in this
> case, presumably since the nfs_mkdir() op or whatever will deal with the
> conflict.
>
> (3) nfs_lookup() returns successfully, leaving the dentry in a negative state,
> but attached to the parent directory.
>
> (4) sys_mkdirat() calls vfs_mkdir() which calls may_create(). may_create()
> checks that the directory has MAY_WRITE and MAY_EXEC permissions.
>
> (5) may_create() calls nfs_permission(), which grants permission.
>
> (6) may_create() calls security_inode_permission(), which calls SELinux, which
> then _DENIES_ permission.
>
> (7) may_create() fails, and vfs_mkdir() then fails and sys_mkdirat() then
> fails (as does sys_mkdir).
>
> _However_, the new dentry is left in the negative state, with no
> consultation of the server.
>
> (8) The parent directory is listed, and the name of the new dentry is
> returned.
>
> (9) stat on the new dentry fails (because it's negative), and "ls -l" returns
> "?---------" as the file type and mode.
>
> This fix makes step (8) replace the dentry looked up in steps (1) - (3).
>
> Signed-Off-By: David Howells <dhowells@redhat.com>
> ---
>
> fs/nfs/dir.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> index e746ed1..bb8b5f0 100644
> --- a/fs/nfs/dir.c
> +++ b/fs/nfs/dir.c
> @@ -1105,8 +1105,13 @@ static struct dentry *nfs_readdir_lookup
> }
> name.hash = full_name_hash(name.name, name.len);
> dentry = d_lookup(parent, &name);
> - if (dentry != NULL)
> - return dentry;
> + if (dentry != NULL) {
> + /* negative dentries must be reconsidered */
> + if (!IS_ERR(dentry) && !dentry->d_inode)
> + d_drop(dentry);
> + else
> + return dentry;
> + }
> if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR))
> return NULL;
> /* Note: caller is already holding the dir->i_mutex! */
That fixes the bad dentries, but...
sony:/home/akpm> ls -l /net/bix
total 1025288
drwxr-xr-x 3 root root 4096 Apr 10 03:19 bin
drwxr-xr-x 2 root root 4096 Mar 10 2004 boot
drwxr-xr-x 23 root root 118784 Jun 26 00:48 dev
drwxr-xr-x 98 root root 8192 Aug 16 04:03 etc
drwxr-xr-x 7 root root 4096 Apr 1 2004 home
drwxr-xr-x 2 root root 4096 Oct 7 2003 initrd
drwxr-xr-x 10 root root 4096 Apr 10 03:19 lib
drwx------ 2 root root 16384 Mar 10 2004 lost+found
drwxr-xr-x 2 root root 4096 Sep 8 2003 misc
drwxr-xr-x 19 root root 4096 Jul 3 15:29 mnt
drwxrwxrwx 8 root root 4096 Jul 10 02:50 opt
drwxr-xr-x 2 root root 4096 Mar 10 2004 proc
drwxr-xr-x 20 root root 4096 Aug 7 16:39 root
drwxr-xr-x 2 root root 57344 Apr 24 2004 rpms
drwxr-xr-x 2 root root 8192 Apr 10 03:19 sbin
-rw-r--r-- 1 root root 1048576000 Mar 12 2004 swap
drwxr-xr-x 2 root root 4096 Mar 12 2004 sys
drwxr-xr-x 3 root root 4096 Mar 10 2004 tftpboot
drwxrwxrwt 14 root root 16384 Aug 17 00:38 tmp
drwxr-xr-x 17 root root 4096 Mar 22 2005 usr
drwxr-xr-x 27 root root 4096 Mar 10 2004 var
sony:/home/akpm> sudo umount bix:/
sony:/home/akpm> dmesg|tail -n 1
VFS: Busy inodes after unmount of 0:15. Self-destruct in 5 seconds. Have a nice day...
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list
2006-08-17 7:42 ` Andrew Morton
@ 2006-08-17 12:13 ` David Howells
2006-08-17 12:33 ` David Howells
2006-08-18 9:09 ` David Howells
2006-08-17 13:24 ` David Howells
2006-08-17 13:45 ` David Howells
2 siblings, 2 replies; 192+ messages in thread
From: David Howells @ 2006-08-17 12:13 UTC (permalink / raw)
To: Andrew Morton
Cc: David Howells, Trond Myklebust, linux-kernel, aviro, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> VFS: Busy inodes after unmount of 0:15. Self-destruct in 5 seconds. Have a
> nice day...
Sigh.
Guess what? I don't see that...
After you've done the "ls -l", can you run:
cat /proc/mounts
cat /proc/fs/nfsfs/*
Before unmounting, and then can you run:
cat /proc/fs/nfsfs/*
Again afterwards?
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list
2006-08-17 12:13 ` David Howells
@ 2006-08-17 12:33 ` David Howells
2006-08-18 9:09 ` David Howells
1 sibling, 0 replies; 192+ messages in thread
From: David Howells @ 2006-08-17 12:33 UTC (permalink / raw)
To: Andrew Morton
Cc: David Howells, Trond Myklebust, linux-kernel, aviro, Ian Kent
David Howells <dhowells@redhat.com> wrote:
> Andrew Morton <akpm@osdl.org> wrote:
>
> > VFS: Busy inodes after unmount of 0:15. Self-destruct in 5 seconds. Have a
> > nice day...
Also, what patches do you have applied? Just the NFS patches or all the -mm
patches?
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list
2006-08-17 12:13 ` David Howells
2006-08-17 12:33 ` David Howells
@ 2006-08-18 9:09 ` David Howells
1 sibling, 0 replies; 192+ messages in thread
From: David Howells @ 2006-08-18 9:09 UTC (permalink / raw)
To: Andrew Morton
Cc: David Howells, Trond Myklebust, linux-kernel, aviro, Ian Kent
David Howells <dhowells@redhat.com> wrote:
> > VFS: Busy inodes after unmount of 0:15. Self-destruct in 5 seconds. Have a
> > nice day...
>
> Sigh.
>
> Guess what? I don't see that...
I wonder... I think I forgot to turn SELinux enforcing back on when testing
it. Now that I do that, I see:
BUG: Dentry c5294c08{i=0,n=mnt} still in use (1) [unmount of nfs 0:14]
------------[ cut here ]------------
kernel BUG at fs/dcache.c:611!
I think Ian's right, I think I've forgotten a dput(), though why you see the
busy inodes message and not the above bug, I'm not sure.
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list
2006-08-17 7:42 ` Andrew Morton
2006-08-17 12:13 ` David Howells
@ 2006-08-17 13:24 ` David Howells
2006-08-17 13:45 ` David Howells
2 siblings, 0 replies; 192+ messages in thread
From: David Howells @ 2006-08-17 13:24 UTC (permalink / raw)
To: Andrew Morton
Cc: David Howells, Trond Myklebust, linux-kernel, aviro, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> VFS: Busy inodes after unmount of 0:15. Self-destruct in 5 seconds. Have a
> nice day...
Does the same happen with the first patch I sent you (see attached)? I know
Trond doesn't like it, but it would be a useful data point if you could try
it.
David
---
NFS: Revalidate on readdir referring to null dentry
From: David Howells <dhowells@redhat.com>
Have nfs_readdir_lookup() force dentry revalidation when it comes across a
name specified by a READDIR RPC call that corresponds to a negative dentry in
the dcache.
This can be caused by an optimisation in nfs_lookup() that causes a dentry to
be incorrectly left as negative when mkdir() or similar is aborted by SELinux
mid-procedure.
This can be triggered by mounting through autofs4 a server:/ NFS share for
which there are other exports available on that server. SELinux also has to
be turned on in enforcing mode to abort mid-flow the mkdir operation performed
by autofs4.
The problematic sequence of events is this:
(1) nfs_lookup() is called by sys_mkdirat() -> lookup_create() ->
__lookup_hash() with intent to create exclusively set in the nameidata:
nd->flags == LOOKUP_CREATE
nd->intent.open.flags == O_EXCL
(2) nfs_lookup() has an optimisation to avoid going to the server in this
case, presumably since the nfs_mkdir() op or whatever will deal with the
conflict.
(3) nfs_lookup() returns successfully, leaving the dentry in a negative state,
but attached to the parent directory.
(4) sys_mkdirat() calls vfs_mkdir() which calls may_create(). may_create()
checks that the directory has MAY_WRITE and MAY_EXEC permissions.
(5) may_create() calls nfs_permission(), which grants permission.
(6) may_create() calls security_inode_permission(), which calls SELinux, which
then _DENIES_ permission.
(7) may_create() fails, and vfs_mkdir() then fails and sys_mkdirat() then
fails (as does sys_mkdir).
_However_, the new dentry is left in the negative state, with no
consultation of the server.
(8) The parent directory is listed, and the name of the new dentry is
returned.
(9) stat on the new dentry fails (because it's negative), and "ls -l" returns
"?---------" as the file type and mode.
This fix makes step (8) cause a revalidation to occur on the dentry at the
start of step (9).
Signed-Off-By: David Howells <dhowells@redhat.com>
---
fs/nfs/dir.c | 16 +++++++++++++++-
include/linux/dcache.h | 5 +++++
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index e746ed1..901b382 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -745,6 +745,13 @@ static int nfs_lookup_revalidate(struct
nfs_inc_stats(dir, NFSIOS_DENTRYREVALIDATE);
inode = dentry->d_inode;
+ if (dentry->d_flags & DCACHE_NEED_REVALIDATE) {
+ spin_lock(&dentry->d_lock);
+ dentry->d_flags &= ~DCACHE_NEED_REVALIDATE;
+ spin_unlock(&dentry->d_lock);
+ goto out_bad;
+ }
+
if (!inode) {
if (nfs_neg_need_reval(dir, dentry, nd))
goto out_bad;
@@ -1105,8 +1112,15 @@ static struct dentry *nfs_readdir_lookup
}
name.hash = full_name_hash(name.name, name.len);
dentry = d_lookup(parent, &name);
- if (dentry != NULL)
+ if (dentry != NULL) {
+ /* negative dentries must be reconsidered */
+ if (!IS_ERR(dentry) && !dentry->d_inode) {
+ spin_lock(&dentry->d_lock);
+ dentry->d_flags |= DCACHE_NEED_REVALIDATE;
+ spin_unlock(&dentry->d_lock);
+ }
return dentry;
+ }
if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR))
return NULL;
/* Note: caller is already holding the dir->i_mutex! */
diff --git a/include/linux/dcache.h b/include/linux/dcache.h
index 63f64a9..c401a7d 100644
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -176,6 +176,11 @@ #define DCACHE_UNHASHED 0x0010
#define DCACHE_INOTIFY_PARENT_WATCHED 0x0020 /* Parent inode is watched */
+#define DCACHE_NEED_REVALIDATE 0x0040
+ /* Dentry needs revalidation by filesystem. Set by NFS, for example,
+ * when we see in a directory listing a file for which we have a
+ * negative dentry */
+
extern spinlock_t dcache_lock;
/**
^ permalink raw reply related [flat|nested] 192+ messages in thread* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list
2006-08-17 7:42 ` Andrew Morton
2006-08-17 12:13 ` David Howells
2006-08-17 13:24 ` David Howells
@ 2006-08-17 13:45 ` David Howells
2 siblings, 0 replies; 192+ messages in thread
From: David Howells @ 2006-08-17 13:45 UTC (permalink / raw)
To: Andrew Morton
Cc: David Howells, Trond Myklebust, linux-kernel, aviro, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> VFS: Busy inodes after unmount of 0:15. Self-destruct in 5 seconds. Have a
> nice day...
And can you apply this patch as well please? It should give more information
about the problem.
David
---
VFS: Print more detail on "Busy inode after unmount" messages
From: David Howells <dhowells@redhat.com>
Print more detail on "Busy inode after unmount" messages.
Signed-Off-By: David Howells <dhowells@redhat.com>
---
fs/super.c | 34 +++++++++++++++++++++++++++++-----
1 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/fs/super.c b/fs/super.c
index 3bf8e5f..ed853c4 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -219,6 +219,33 @@ static int grab_super(struct super_block
return 0;
}
+static void super_still_busy(struct super_block *sb)
+{
+ struct dentry *dentry;
+ struct inode *inode;
+ int limit;
+
+ printk("VFS: Busy inodes after unmount of %s. "
+ "Self-destruct in 5 seconds. Have a nice day...\n",
+ sb->s_id);
+
+ limit = 24;
+ list_for_each_entry(inode, &sb->s_inodes, i_sb_list) {
+ printk(KERN_ERR "- inode %p{ino=%lx,c=#%d}\n",
+ inode, inode->i_ino, atomic_read(&inode->i_count));
+ if (--limit <= 0)
+ return;
+
+ list_for_each_entry(dentry, &inode->i_dentry, d_alias) {
+ printk(KERN_ERR " - dentry %p{'%s',c=#%d}\n",
+ dentry, dentry->d_name.name,
+ atomic_read(&inode->i_count));
+ if (--limit <= 0)
+ return;
+ }
+ }
+}
+
/**
* generic_shutdown_super - common helper for ->kill_sb()
* @sb: superblock to kill
@@ -252,11 +279,8 @@ void generic_shutdown_super(struct super
sop->put_super(sb);
/* Forget any remaining inodes */
- if (invalidate_inodes(sb)) {
- printk("VFS: Busy inodes after unmount of %s. "
- "Self-destruct in 5 seconds. Have a nice day...\n",
- sb->s_id);
- }
+ if (unlikely(invalidate_inodes(sb)))
+ super_still_busy(sb);
unlock_kernel();
unlock_super(sb);
^ permalink raw reply related [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list
2006-08-16 16:15 ` [PATCH] NFS: Replace null dentries that appear in readdir's list David Howells
` (2 preceding siblings ...)
2006-08-17 7:42 ` Andrew Morton
@ 2006-08-18 0:47 ` Ian Kent
2006-08-18 9:21 ` David Howells
2006-08-18 0:58 ` Ian Kent
2006-08-18 9:38 ` [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2] David Howells
5 siblings, 1 reply; 192+ messages in thread
From: Ian Kent @ 2006-08-18 0:47 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, Trond Myklebust, linux-kernel, aviro
On Wed, 2006-08-16 at 17:15 +0100, David Howells wrote:
> fs/nfs/dir.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> index e746ed1..bb8b5f0 100644
> --- a/fs/nfs/dir.c
> +++ b/fs/nfs/dir.c
> @@ -1105,8 +1105,13 @@ static struct dentry *nfs_readdir_lookup
> }
> name.hash = full_name_hash(name.name, name.len);
> dentry = d_lookup(parent, &name);
> - if (dentry != NULL)
> - return dentry;
> + if (dentry != NULL) {
> + /* negative dentries must be reconsidered */
> + if (!IS_ERR(dentry) && !dentry->d_inode)
> + d_drop(dentry);
Don't we need to return something like NULL here also?
> + else
> + return dentry;
> + }
> if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR))
> return NULL;
> /* Note: caller is already holding the dir->i_mutex! */
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list
2006-08-18 0:47 ` Ian Kent
@ 2006-08-18 9:21 ` David Howells
0 siblings, 0 replies; 192+ messages in thread
From: David Howells @ 2006-08-18 9:21 UTC (permalink / raw)
To: Ian Kent; +Cc: David Howells, Andrew Morton, Trond Myklebust, linux-kernel,
aviro
Ian Kent <raven@themaw.net> wrote:
> Don't we need to return something like NULL here also?
Shouldn't do. It should be reasonable to just continue into the rest of the
function - after all, after calling d_drop() we don't have a dentry any
more[*]...
[*] Lack of a dput() not withstanding.
I'm wondering if I actually need to discard the negative dentry I already have
since I then proceed to allocate a new one.
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list
2006-08-16 16:15 ` [PATCH] NFS: Replace null dentries that appear in readdir's list David Howells
` (3 preceding siblings ...)
2006-08-18 0:47 ` Ian Kent
@ 2006-08-18 0:58 ` Ian Kent
2006-08-18 1:05 ` Ian Kent
2006-08-18 9:38 ` [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2] David Howells
5 siblings, 1 reply; 192+ messages in thread
From: Ian Kent @ 2006-08-18 0:58 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, Trond Myklebust, linux-kernel, aviro
On Wed, 2006-08-16 at 17:15 +0100, David Howells wrote:
> fs/nfs/dir.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> index e746ed1..bb8b5f0 100644
> --- a/fs/nfs/dir.c
> +++ b/fs/nfs/dir.c
> @@ -1105,8 +1105,13 @@ static struct dentry *nfs_readdir_lookup
> }
> name.hash = full_name_hash(name.name, name.len);
> dentry = d_lookup(parent, &name);
And there's no dput for this gotten dentry.
> - if (dentry != NULL)
> - return dentry;
> + if (dentry != NULL) {
> + /* negative dentries must be reconsidered */
> + if (!IS_ERR(dentry) && !dentry->d_inode)
> + d_drop(dentry);
> + else
> + return dentry;
> + }
> if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR))
> return NULL;
> /* Note: caller is already holding the dir->i_mutex! */
Sorry I didn't look at this more closely earlier.
Just looking at this function alone it looks to me like it is
essentially part of a dentry instantiation which would mean a negative
dentry is perfectly valid at the point above.
Ian
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list
2006-08-18 0:58 ` Ian Kent
@ 2006-08-18 1:05 ` Ian Kent
0 siblings, 0 replies; 192+ messages in thread
From: Ian Kent @ 2006-08-18 1:05 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, Trond Myklebust, linux-kernel, aviro
On Fri, 2006-08-18 at 08:58 +0800, Ian Kent wrote:
> Sorry I didn't look at this more closely earlier.
>
> Just looking at this function alone it looks to me like it is
> essentially part of a dentry instantiation which would mean a negative
> dentry is perfectly valid at the point above.
I looked again, scratch this comment.
Ian
^ permalink raw reply [flat|nested] 192+ messages in thread
* [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]
2006-08-16 16:15 ` [PATCH] NFS: Replace null dentries that appear in readdir's list David Howells
` (4 preceding siblings ...)
2006-08-18 0:58 ` Ian Kent
@ 2006-08-18 9:38 ` David Howells
2006-08-19 16:48 ` Andrew Morton
5 siblings, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-18 9:38 UTC (permalink / raw)
To: David Howells
Cc: Andrew Morton, Trond Myklebust, linux-kernel, aviro, Ian Kent
David Howells <dhowells@redhat.com> wrote:
> Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> > Better still, in the case of a negative dentry: just call d_drop().
>
> How about this then?
Or, rather, this. Have to remember to discard the old dentry if we don't need
it any more, but since we now have a suitable negative dentry, we can always
instantiate it, and save on an allocation.
I don't think this can race because the parent directory's i_mutex is held by
vfs_readdir() for the duration.
David
---
NFS: Replace null dentries that appear in readdir's list [try #2]
From: David Howells <dhowells@redhat.com>
Have nfs_readdir_lookup() drop and replace any null dentry when it
that gets listed by a READDIR RPC call.
This can be caused by an optimisation in nfs_lookup() that causes a dentry to
be incorrectly left as negative when mkdir() or similar is aborted by SELinux
mid-procedure.
This can be triggered by mounting through autofs4 a server:/ NFS share for
which there are other exports available on that server. SELinux also has to
be turned on in enforcing mode to abort mid-flow the mkdir operation performed
by autofs4.
The problematic sequence of events is this:
(1) nfs_lookup() is called by sys_mkdirat() -> lookup_create() ->
__lookup_hash() with intent to create exclusively set in the nameidata:
nd->flags == LOOKUP_CREATE
nd->intent.open.flags == O_EXCL
(2) nfs_lookup() has an optimisation to avoid going to the server in this
case, presumably since the nfs_mkdir() op or whatever will deal with the
conflict.
(3) nfs_lookup() returns successfully, leaving the dentry in a negative state,
but attached to the parent directory.
(4) sys_mkdirat() calls vfs_mkdir() which calls may_create(). may_create()
checks that the directory has MAY_WRITE and MAY_EXEC permissions.
(5) may_create() calls nfs_permission(), which grants permission.
(6) may_create() calls security_inode_permission(), which calls SELinux, which
then _DENIES_ permission.
(7) may_create() fails, and vfs_mkdir() then fails and sys_mkdirat() then
fails (as does sys_mkdir).
_However_, the new dentry is left in the negative state, with no
consultation of the server.
(8) The parent directory is listed, and the name of the new dentry is
returned.
(9) stat on the new dentry fails (because it's negative), and "ls -l" returns
"?---------" as the file type and mode.
This fix makes step (8) replace the dentry looked up in steps (1) - (3).
Signed-Off-By: David Howells <dhowells@redhat.com>
---
fs/nfs/dir.c | 27 ++++++++++++++++++++-------
1 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index e746ed1..3c5e2ed 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1105,14 +1105,27 @@ static struct dentry *nfs_readdir_lookup
}
name.hash = full_name_hash(name.name, name.len);
dentry = d_lookup(parent, &name);
- if (dentry != NULL)
- return dentry;
- if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR))
- return NULL;
- /* Note: caller is already holding the dir->i_mutex! */
- dentry = d_alloc(parent, &name);
- if (dentry == NULL)
+ if (dentry != NULL) {
+ if (IS_ERR(dentry) || dentry->d_inode)
+ return dentry;
+
+ /* this negative dentry matched a dirent obtained from readdir
+ * and so needs reconsideration */
+ d_drop(dentry);
+
+ if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR)) {
+ dput(dentry);
+ return NULL;
+ }
+ } else if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR)) {
return NULL;
+ } else {
+ /* Note: caller is already holding the dir->i_mutex! */
+ dentry = d_alloc(parent, &name);
+ if (dentry == NULL)
+ return NULL;
+ }
+
dentry->d_op = NFS_PROTO(dir)->dentry_ops;
inode = nfs_fhget(dentry->d_sb, entry->fh, entry->fattr);
if (IS_ERR(inode)) {
^ permalink raw reply related [flat|nested] 192+ messages in thread* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]
2006-08-18 9:38 ` [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2] David Howells
@ 2006-08-19 16:48 ` Andrew Morton
2006-08-20 13:15 ` David Howells
0 siblings, 1 reply; 192+ messages in thread
From: Andrew Morton @ 2006-08-19 16:48 UTC (permalink / raw)
To: David Howells; +Cc: Trond Myklebust, linux-kernel, aviro, Ian Kent
On Fri, 18 Aug 2006 10:38:44 +0100
David Howells <dhowells@redhat.com> wrote:
> NFS: Replace null dentries that appear in readdir's list [try #2]
>
> From: David Howells <dhowells@redhat.com>
>
> Have nfs_readdir_lookup() drop and replace any null dentry when it
> that gets listed by a READDIR RPC call.
>
> This can be caused by an optimisation in nfs_lookup() that causes a dentry to
> be incorrectly left as negative when mkdir() or similar is aborted by SELinux
> mid-procedure.
>
> This can be triggered by mounting through autofs4 a server:/ NFS share for
> which there are other exports available on that server. SELinux also has to
> be turned on in enforcing mode to abort mid-flow the mkdir operation performed
> by autofs4.
>
> The problematic sequence of events is this:
>
> (1) nfs_lookup() is called by sys_mkdirat() -> lookup_create() ->
> __lookup_hash() with intent to create exclusively set in the nameidata:
>
> nd->flags == LOOKUP_CREATE
> nd->intent.open.flags == O_EXCL
>
> (2) nfs_lookup() has an optimisation to avoid going to the server in this
> case, presumably since the nfs_mkdir() op or whatever will deal with the
> conflict.
>
> (3) nfs_lookup() returns successfully, leaving the dentry in a negative state,
> but attached to the parent directory.
>
> (4) sys_mkdirat() calls vfs_mkdir() which calls may_create(). may_create()
> checks that the directory has MAY_WRITE and MAY_EXEC permissions.
>
> (5) may_create() calls nfs_permission(), which grants permission.
>
> (6) may_create() calls security_inode_permission(), which calls SELinux, which
> then _DENIES_ permission.
>
> (7) may_create() fails, and vfs_mkdir() then fails and sys_mkdirat() then
> fails (as does sys_mkdir).
>
> _However_, the new dentry is left in the negative state, with no
> consultation of the server.
>
> (8) The parent directory is listed, and the name of the new dentry is
> returned.
>
> (9) stat on the new dentry fails (because it's negative), and "ls -l" returns
> "?---------" as the file type and mode.
>
> This fix makes step (8) replace the dentry looked up in steps (1) - (3).
>
The funny-looking dentries in /net/bix have gone away.
But `ls -l /net/bix/usr/src' doesn't mount bix:/usr/src.
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]
2006-08-19 16:48 ` Andrew Morton
@ 2006-08-20 13:15 ` David Howells
2006-08-20 14:25 ` Ian Kent
0 siblings, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-20 13:15 UTC (permalink / raw)
To: Andrew Morton
Cc: David Howells, Trond Myklebust, linux-kernel, aviro, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> The funny-looking dentries in /net/bix have gone away.
>
> But `ls -l /net/bix/usr/src' doesn't mount bix:/usr/src.
Yes, that I believe is due to the automounter program combined with that
optimisation in the NFS client code. *readdir* fixes the falsely negative
dentry, but only if you _do_ a readdir of the parent directory, and only then
if you read enough of the directory to locate the dodgy dentry.
This is normally only a problem if SELinux aborts the mkdir operation between
calling the filesystem's lookup() op and the filesystem's mkdir() op, if the
filesystem is written - as NFS is - to assume the the lookup() op _will_ be
followed by a call to the mkdir() op whatever happens. Unfortunately, with
SELinux sticking its foot in the way, this no longer holds true, and the
initial lookup _must_ properly instantiate the dentry it is given - and that
means it must query the server in such a case.
That said, that will likely prevent autofs from being able to create arbitrary
directories if the underlying security constraints don't let it.
There is another problem with autofs arbitrarily creating directory dentries
in this manner: the automount program doesn't know whether the directory it is
creating corresponds to a directory on the server - or whether it corresponds
to a symbolic link... The server _must_ be queried.
So, I think:
(1) I have to change my patch again, and that I have to make nfs_lookup()
unconditionally query the server (comments Trond?), and
(2) Ian has to patch the automounter to not attempt to mount undermounts
automatically - with the new in-NFS-client automounting code, this should
be unnecessary, except for when the an intervening directory is
inaccessible, and I'm not sure what you can do about that (Ian? Trond?)
David
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]
2006-08-20 13:15 ` David Howells
@ 2006-08-20 14:25 ` Ian Kent
2006-08-21 9:42 ` David Howells
0 siblings, 1 reply; 192+ messages in thread
From: Ian Kent @ 2006-08-20 14:25 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, Trond Myklebust, linux-kernel, aviro
On Sun, 20 Aug 2006, David Howells wrote:
> Andrew Morton <akpm@osdl.org> wrote:
>
> > The funny-looking dentries in /net/bix have gone away.
> >
> > But `ls -l /net/bix/usr/src' doesn't mount bix:/usr/src.
>
> Yes, that I believe is due to the automounter program combined with that
> optimisation in the NFS client code. *readdir* fixes the falsely negative
> dentry, but only if you _do_ a readdir of the parent directory, and only then
> if you read enough of the directory to locate the dodgy dentry.
>
> This is normally only a problem if SELinux aborts the mkdir operation between
> calling the filesystem's lookup() op and the filesystem's mkdir() op, if the
> filesystem is written - as NFS is - to assume the the lookup() op _will_ be
> followed by a call to the mkdir() op whatever happens. Unfortunately, with
> SELinux sticking its foot in the way, this no longer holds true, and the
> initial lookup _must_ properly instantiate the dentry it is given - and that
> means it must query the server in such a case.
>
> That said, that will likely prevent autofs from being able to create arbitrary
> directories if the underlying security constraints don't let it.
>
> There is another problem with autofs arbitrarily creating directory dentries
> in this manner: the automount program doesn't know whether the directory it is
> creating corresponds to a directory on the server - or whether it corresponds
> to a symbolic link... The server _must_ be queried.
>
> So, I think:
>
> (1) I have to change my patch again, and that I have to make nfs_lookup()
> unconditionally query the server (comments Trond?), and
>
> (2) Ian has to patch the automounter to not attempt to mount undermounts
> automatically - with the new in-NFS-client automounting code, this should
> be unnecessary, except for when the an intervening directory is
> inaccessible, and I'm not sure what you can do about that (Ian? Trond?)
I guess I knew this would with the nfs v4 mounting.
I don't have a server with v4 nested type mounts handy. How can I tell,
from the output of the exports list, what I should leave alone?
Ian
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]
2006-08-20 14:25 ` Ian Kent
@ 2006-08-21 9:42 ` David Howells
2006-08-21 11:35 ` Ian Kent
0 siblings, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-21 9:42 UTC (permalink / raw)
To: Ian Kent; +Cc: David Howells, Andrew Morton, Trond Myklebust, linux-kernel,
aviro
Ian Kent <raven@themaw.net> wrote:
> I guess I knew this would with the nfs v4 mounting.
And NFS2 and NFS3. You just need a server that has two levels of export, one
under the other, for example:
[/etc/exports]
/ *(rw,async,fsid=0)
/usr/src *(rw,async,nohide)
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]
2006-08-21 9:42 ` David Howells
@ 2006-08-21 11:35 ` Ian Kent
2006-08-21 12:16 ` David Howells
0 siblings, 1 reply; 192+ messages in thread
From: Ian Kent @ 2006-08-21 11:35 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, Trond Myklebust, linux-kernel, aviro
On Mon, 21 Aug 2006, David Howells wrote:
> Ian Kent <raven@themaw.net> wrote:
>
> > I guess I knew this would with the nfs v4 mounting.
>
> And NFS2 and NFS3. You just need a server that has two levels of export, one
> under the other, for example:
>
> [/etc/exports]
> / *(rw,async,fsid=0)
> /usr/src *(rw,async,nohide)
That makes it a bit hard as the /net functionality that Andrew is using is
meant to mount all exports from the given server. In v4 that are mounted
and umounted as a unit to deal with the nesting.
Ian
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]
2006-08-21 11:35 ` Ian Kent
@ 2006-08-21 12:16 ` David Howells
2006-08-21 13:33 ` Ian Kent
0 siblings, 1 reply; 192+ messages in thread
From: David Howells @ 2006-08-21 12:16 UTC (permalink / raw)
To: Ian Kent; +Cc: David Howells, Andrew Morton, Trond Myklebust, linux-kernel,
aviro
Ian Kent <raven@themaw.net> wrote:
> That makes it a bit hard as the /net functionality that Andrew is using is
> meant to mount all exports from the given server.
But does it _matter_ that the thing is mounted or dismounted as a unit? And
if so, why?
> In v4 that are mounted and umounted as a unit to deal with the nesting.
Why does the automounter daemon have to do the mounting of submounts? What's
wrong with having the kernel do it? The one problem with having the kernel do
it that I can see, is that the kernel doesn't update /etc/mtab.
Note that rather than manually mounting the submounts, you could just open and
close those directories as that should cause them to automount - though the
xdev mountpoints will expire and become automatically unmounted after a
certain period.
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]
2006-08-21 12:16 ` David Howells
@ 2006-08-21 13:33 ` Ian Kent
2006-08-21 15:17 ` David Howells
0 siblings, 1 reply; 192+ messages in thread
From: Ian Kent @ 2006-08-21 13:33 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, Trond Myklebust, linux-kernel, aviro
On Mon, 21 Aug 2006, David Howells wrote:
> Ian Kent <raven@themaw.net> wrote:
>
> > That makes it a bit hard as the /net functionality that Andrew is using is
> > meant to mount all exports from the given server.
>
> But does it _matter_ that the thing is mounted or dismounted as a unit? And
> if so, why?
Yes with autofs version 4, because of the nesting of mounts which also
introduces issues with expiration. Its basically due to the dependencies
and the relatively simple minded way they are handled.
In version 5 they are mounted and umounted on demand.
>
> > In v4 that are mounted and umounted as a unit to deal with the nesting.
>
> Why does the automounter daemon have to do the mounting of submounts? What's
> wrong with having the kernel do it? The one problem with having the kernel do
> it that I can see, is that the kernel doesn't update /etc/mtab.
v2 and v3 won't do the expire, will they?
Not updating the mtab will be a problem for me also and possibly for
users that expect to see mounts in it.
The "/net" functionality is a standard, expected automounter function.
>
>
> Note that rather than manually mounting the submounts, you could just open and
> close those directories as that should cause them to automount - though the
> xdev mountpoints will expire and become automatically unmounted after a
> certain period.
The xdev (assume you mean NFSv4 submounts) mounts will be the area I need
to work on, for sure.
I don't quite understand the "open will cause the automount" for NFS
version < 4. The automounter calls mount(8) when it gets a packet from the
autofs[4] kernel module due to an access.
I expect that I won't have to do much at all for xdev mounts except to be
able to recoginize them and their owners so I can leave them alone. The
expire function might be a bit interesting.
Ian
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]
2006-08-21 13:33 ` Ian Kent
@ 2006-08-21 15:17 ` David Howells
2006-08-22 2:04 ` Ian Kent
2006-08-22 3:29 ` Ian Kent
0 siblings, 2 replies; 192+ messages in thread
From: David Howells @ 2006-08-21 15:17 UTC (permalink / raw)
To: Ian Kent; +Cc: David Howells, Andrew Morton, Trond Myklebust, linux-kernel,
aviro
Ian Kent <raven@themaw.net> wrote:
> > But does it _matter_ that the thing is mounted or dismounted as a unit? And
> > if so, why?
>
> Yes with autofs version 4, because of the nesting of mounts which also
> introduces issues with expiration.
The NFS client's automounting facilities handle automatic expiration and
implicit recursive unmounting of xdev submounts.
For example, on my test machine:
[root@andromeda ~]# /root/mount warthog:/ /warthog -o fsc
[root@andromeda ~]# ls /warthog/warthog
[root@andromeda ~]# cat /proc/mounts
...
warthog:/ /warthog nfs rw,vers=3,rsize=32768,wsize=32768,hard,fsc,proto=tcp,timeo=600,retrans=2,sec=sys,addr=warthog 0 0
warthog:/warthog /warthog/warthog nfs rw,vers=3,rsize=32768,wsize=32768,hard,fsc,proto=tcp,timeo=600,retrans=2,sec=sys,addr=warthog 0 0
[root@andromeda ~]# umount /warthog/
[root@andromeda ~]#
The "ls" command caused the client to mount warthog:/warthog off of the server
onto /warthog/warthog automatically. I was then able to just unmount
/warthog, which took away /warthog/warthog also without me having to do
anything special.
> In version 5 they are mounted and umounted on demand.
This should now be left to the NFS client.
The NFS client now views each set of files with the same FSID as a separate
collection of files, and accords each set its own superblock. The superblocks
thus created are automounted by the follow_link() op on the directory that's
at the point of FSID-change.
Note! This works for NFS2, NFS3 and NFS4. NFS4 has an extra facility by
which mounts can cross servers, but that uses more or less the same mechanism.
> > > In v4 that are mounted and umounted as a unit to deal with the nesting.
> >
> > Why does the automounter daemon have to do the mounting of submounts?
> > What's wrong with having the kernel do it? The one problem with having
> > the kernel do it that I can see, is that the kernel doesn't update
> > /etc/mtab.
>
> v2 and v3 won't do the expire, will they?
Yes. Automounting and auto-expiration both.
> Not updating the mtab will be a problem for me also and possibly for
> users that expect to see mounts in it.
ln -sf /proc/mounts /etc/mtab
> The "/net" functionality is a standard, expected automounter function.
Whilst that may be true, it doesn't prohibit working with the NFS clients
automounting capabilities.
> > Note that rather than manually mounting the submounts, you could just open
> > and close those directories as that should cause them to automount -
> > though the xdev mountpoints will expire and become automatically unmounted
> > after a certain period.
>
> The xdev (assume you mean NFSv4 submounts) mounts will be the area I need
> to work on, for sure.
I mean NFSv2, NFSv3 and NFSv4 submounts that cross FSID, but remain on the
same server.
> I don't quite understand the "open will cause the automount" for NFS
> version < 4.
Opening the directory will cause its follow_link() op to be invoked, which
will cause an automount if one hasn't already happened. Obviously, if the
automount has taken place, the lower directory won't be seen for the follow to
take place.
> The automounter calls mount(8) when it gets a packet from the
> autofs[4] kernel module due to an access.
The automounter must mount the root of any tree, yes; but xdev subtrees should
now be left to the NFS client to mount, which can be triggered by stat'ing the
mountpoint - admittedly, if you can reach it without a security error.
If you do get a security error, and attempt to build the directories anyway,
you run the risk of constructing a false image of the remote share as you
can't tell symlinks from directories, and run the risk of creating invalid
dentries locally because you can't determine the attributes of the remote
object.
> I expect that I won't have to do much at all for xdev mounts except to be
> able to recoginize them and their owners so I can leave them alone. The
> expire function might be a bit interesting.
They're self-expiring. And, as I mentioned above, you only need to unmount
the root to dispose of the entire tree.
David
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]
2006-08-21 15:17 ` David Howells
@ 2006-08-22 2:04 ` Ian Kent
2006-08-22 3:29 ` Ian Kent
1 sibling, 0 replies; 192+ messages in thread
From: Ian Kent @ 2006-08-22 2:04 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, Trond Myklebust, linux-kernel, aviro
On Mon, 21 Aug 2006, David Howells wrote:
OK. I think I get it now.
Thanks for your patience.
> Ian Kent <raven@themaw.net> wrote:
>
> > > But does it _matter_ that the thing is mounted or dismounted as a unit? And
> > > if so, why?
> >
> > Yes with autofs version 4, because of the nesting of mounts which also
> > introduces issues with expiration.
>
> The NFS client's automounting facilities handle automatic expiration and
> implicit recursive unmounting of xdev submounts.
Very cool.
I guess I'm not concerned about what the expire timeout is for such trees
either as it's not my problem.
I'll have to play around with these a bit to work out how I can recognize
them in the export list. Hopefully it will be straight forward.
>
> This should now be left to the NFS client.
Yep.
>
> > Not updating the mtab will be a problem for me also and possibly for
> > users that expect to see mounts in it.
>
> ln -sf /proc/mounts /etc/mtab
>
> > The "/net" functionality is a standard, expected automounter function.
>
> Whilst that may be true, it doesn't prohibit working with the NFS clients
> automounting capabilities.
Yep.
Again, not my problem if I treat fsid filesets as the automount unit.
>
> > > Note that rather than manually mounting the submounts, you could just open
> > > and close those directories as that should cause them to automount -
> > > though the xdev mountpoints will expire and become automatically unmounted
> > > after a certain period.
> >
> > The xdev (assume you mean NFSv4 submounts) mounts will be the area I need
> > to work on, for sure.
>
> I mean NFSv2, NFSv3 and NFSv4 submounts that cross FSID, but remain on the
> same server.
>
> > I don't quite understand the "open will cause the automount" for NFS
> > version < 4.
>
> Opening the directory will cause its follow_link() op to be invoked, which
> will cause an automount if one hasn't already happened. Obviously, if the
> automount has taken place, the lower directory won't be seen for the follow to
> take place.
Yep. But also not my problem as user activity will make this happen
automagically.
>
> > The automounter calls mount(8) when it gets a packet from the
> > autofs[4] kernel module due to an access.
>
> The automounter must mount the root of any tree, yes; but xdev subtrees should
> now be left to the NFS client to mount, which can be triggered by stat'ing the
> mountpoint - admittedly, if you can reach it without a security error.
>
> If you do get a security error, and attempt to build the directories anyway,
> you run the risk of constructing a false image of the remote share as you
> can't tell symlinks from directories, and run the risk of creating invalid
> dentries locally because you can't determine the attributes of the remote
> object.
Yep. No use in stepping on NFSs toes when he just wants to make my life
easier for me.
Ian
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]
2006-08-21 15:17 ` David Howells
2006-08-22 2:04 ` Ian Kent
@ 2006-08-22 3:29 ` Ian Kent
2006-08-22 4:10 ` Trond Myklebust
1 sibling, 1 reply; 192+ messages in thread
From: Ian Kent @ 2006-08-22 3:29 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, Trond Myklebust, linux-kernel, aviro
On Mon, 21 Aug 2006, David Howells wrote:
>
> The NFS client's automounting facilities handle automatic expiration and
> implicit recursive unmounting of xdev submounts.
>
> For example, on my test machine:
>
> [root@andromeda ~]# /root/mount warthog:/ /warthog -o fsc
> [root@andromeda ~]# ls /warthog/warthog
> [root@andromeda ~]# cat /proc/mounts
> ...
> warthog:/ /warthog nfs rw,vers=3,rsize=32768,wsize=32768,hard,fsc,proto=tcp,timeo=600,retrans=2,sec=sys,addr=warthog 0 0
> warthog:/warthog /warthog/warthog nfs rw,vers=3,rsize=32768,wsize=32768,hard,fsc,proto=tcp,timeo=600,retrans=2,sec=sys,addr=warthog 0 0
> [root@andromeda ~]# umount /warthog/
> [root@andromeda ~]#
>
> The "ls" command caused the client to mount warthog:/warthog off of the server
> onto /warthog/warthog automatically. I was then able to just unmount
> /warthog, which took away /warthog/warthog also without me having to do
> anything special.
>
This is going to be fun after all.
There isn't any way to tell a nohide from a non-nohide mount from the
expots list.
There are inconsistencies with the contents of /proc/mounts between OS
versions (perhaps kernel version).
There is no way to tell a nohide mounted filesystem from the output of
/proc/mounts if it does happen to appear in it.
*sigh*
Ian
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [PATCH] NFS: Replace null dentries that appear in readdir's list [try #2]
2006-08-22 3:29 ` Ian Kent
@ 2006-08-22 4:10 ` Trond Myklebust
0 siblings, 0 replies; 192+ messages in thread
From: Trond Myklebust @ 2006-08-22 4:10 UTC (permalink / raw)
To: Ian Kent; +Cc: David Howells, Andrew Morton, linux-kernel, aviro
On Tue, 2006-08-22 at 11:29 +0800, Ian Kent wrote:
> There isn't any way to tell a nohide from a non-nohide mount from the
> expots list.
Why do you care? NFS shouldn't be barfing if you try to mount the
filesystem yourself. If it does, then it is broken.
> There are inconsistencies with the contents of /proc/mounts between OS
> versions (perhaps kernel version).
Huh? The NFS output for /proc/mounts hasn't changed.
> There is no way to tell a nohide mounted filesystem from the output of
> /proc/mounts if it does happen to appear in it.
Why do you care?
Trond
^ permalink raw reply [flat|nested] 192+ messages in thread
* [-mm patch] make drivers/cpufreq/cpufreq_ondemand.c:powersave_bias_target() static
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (7 preceding siblings ...)
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-13 21:00 ` Adrian Bunk
2006-08-13 21:00 ` [-mm patch] make drivers/hwmon/hdaps.c:transform_axes() static Adrian Bunk
` (20 subsequent siblings)
29 siblings, 0 replies; 192+ messages in thread
From: Adrian Bunk @ 2006-08-13 21:00 UTC (permalink / raw)
To: Andrew Morton, Alexey Starikovskiy, davej; +Cc: linux-kernel, cpufreq
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc3-mm2:
>...
> git-cpufreq.patch
>...
> git trees
>...
This patch makes the needlessly global powersave_bias_target() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.18-rc4-mm1/drivers/cpufreq/cpufreq_ondemand.c.old 2006-08-13 17:40:48.000000000 +0200
+++ linux-2.6.18-rc4-mm1/drivers/cpufreq/cpufreq_ondemand.c 2006-08-13 17:40:59.000000000 +0200
@@ -105,8 +105,9 @@
* Returns the freq_hi to be used right now and will set freq_hi_jiffies,
* freq_lo, and freq_lo_jiffies in percpu area for averaging freqs.
*/
-unsigned int powersave_bias_target(struct cpufreq_policy *policy,
- unsigned int freq_next, unsigned int relation)
+static unsigned int powersave_bias_target(struct cpufreq_policy *policy,
+ unsigned int freq_next,
+ unsigned int relation)
{
unsigned int freq_req, freq_reduc, freq_avg;
unsigned int freq_hi, freq_lo;
^ permalink raw reply [flat|nested] 192+ messages in thread* [-mm patch] make drivers/hwmon/hdaps.c:transform_axes() static
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (8 preceding siblings ...)
2006-08-13 21:00 ` [-mm patch] make drivers/cpufreq/cpufreq_ondemand.c:powersave_bias_target() static Adrian Bunk
@ 2006-08-13 21:00 ` Adrian Bunk
2006-08-13 22:56 ` Shem Multinymous
2006-08-13 21:00 ` [-mm patch] drivers/media/dvb/frontends/: make 4 functions static Adrian Bunk
` (19 subsequent siblings)
29 siblings, 1 reply; 192+ messages in thread
From: Adrian Bunk @ 2006-08-13 21:00 UTC (permalink / raw)
To: Andrew Morton, Shem Multinymous; +Cc: linux-kernel, khali, lm-sensors
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc3-mm2:
>...
> +hdaps-unify-and-cache-hdaps-readouts.patch
>...
> HDAPS driver updates
transform_axes() isn't a good name for a global function.
Thankfully, it can simply made static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.18-rc4-mm1/drivers/hwmon/hdaps.c.old 2006-08-13 17:45:34.000000000 +0200
+++ linux-2.6.18-rc4-mm1/drivers/hwmon/hdaps.c 2006-08-13 17:45:50.000000000 +0200
@@ -85,7 +85,7 @@
static u64 last_mouse_jiffies = INITIAL_JIFFIES;
/* Some models require an axis transformation to the standard reprsentation */
-void transform_axes(int *x, int *y)
+static void transform_axes(int *x, int *y)
{
if (hdaps_invert) {
*x = -*x;
^ permalink raw reply [flat|nested] 192+ messages in thread* [-mm patch] drivers/media/dvb/frontends/: make 4 functions static
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (9 preceding siblings ...)
2006-08-13 21:00 ` [-mm patch] make drivers/hwmon/hdaps.c:transform_axes() static Adrian Bunk
@ 2006-08-13 21:00 ` Adrian Bunk
2006-08-13 21:00 ` [-mm patch] drivers/char/drm/: cleanups Adrian Bunk
` (18 subsequent siblings)
29 siblings, 0 replies; 192+ messages in thread
From: Adrian Bunk @ 2006-08-13 21:00 UTC (permalink / raw)
To: Andrew Morton, v4l-dvb-maintainer; +Cc: linux-kernel
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc3-mm2:
>...
> git-dvb.patch
>...
> git trees
>...
This patch makes four needlessly global functions static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/media/dvb/frontends/stv0299.c | 2 +-
drivers/media/dvb/frontends/tda10021.c | 2 +-
drivers/media/dvb/frontends/tda1004x.c | 2 +-
drivers/media/dvb/frontends/zl10353.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
--- linux-2.6.18-rc4-mm1/drivers/media/dvb/frontends/stv0299.c.old 2006-08-13 17:56:46.000000000 +0200
+++ linux-2.6.18-rc4-mm1/drivers/media/dvb/frontends/stv0299.c 2006-08-13 17:56:56.000000000 +0200
@@ -92,7 +92,7 @@
return (ret != 1) ? -EREMOTEIO : 0;
}
-int stv0299_write(struct dvb_frontend* fe, u8 *buf, int len)
+static int stv0299_write(struct dvb_frontend* fe, u8 *buf, int len)
{
struct stv0299_state* state = fe->demodulator_priv;
--- linux-2.6.18-rc4-mm1/drivers/media/dvb/frontends/tda10021.c.old 2006-08-13 17:57:25.000000000 +0200
+++ linux-2.6.18-rc4-mm1/drivers/media/dvb/frontends/tda10021.c 2006-08-13 17:57:44.000000000 +0200
@@ -201,7 +201,7 @@
return 0;
}
-int tda10021_write(struct dvb_frontend* fe, u8 *buf, int len)
+static int tda10021_write(struct dvb_frontend* fe, u8 *buf, int len)
{
struct tda10021_state* state = fe->demodulator_priv;
--- linux-2.6.18-rc4-mm1/drivers/media/dvb/frontends/tda1004x.c.old 2006-08-13 17:58:23.000000000 +0200
+++ linux-2.6.18-rc4-mm1/drivers/media/dvb/frontends/tda1004x.c 2006-08-13 17:58:51.000000000 +0200
@@ -579,7 +579,7 @@
return -1;
}
-int tda1004x_write(struct dvb_frontend* fe, u8 *buf, int len)
+static int tda1004x_write(struct dvb_frontend* fe, u8 *buf, int len)
{
struct tda1004x_state* state = fe->demodulator_priv;
--- linux-2.6.18-rc4-mm1/drivers/media/dvb/frontends/zl10353.c.old 2006-08-13 17:59:09.000000000 +0200
+++ linux-2.6.18-rc4-mm1/drivers/media/dvb/frontends/zl10353.c 2006-08-13 17:59:35.000000000 +0200
@@ -54,7 +54,7 @@
return 0;
}
-int zl10353_write(struct dvb_frontend *fe, u8 *ibuf, int ilen)
+static int zl10353_write(struct dvb_frontend *fe, u8 *ibuf, int ilen)
{
int err, i;
for (i = 0; i < ilen - 1; i++)
^ permalink raw reply [flat|nested] 192+ messages in thread* [-mm patch] drivers/char/drm/: cleanups
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (10 preceding siblings ...)
2006-08-13 21:00 ` [-mm patch] drivers/media/dvb/frontends/: make 4 functions static Adrian Bunk
@ 2006-08-13 21:00 ` Adrian Bunk
2006-08-13 21:00 ` [-mm patch] kernel/time/ntp.c: possible cleanups Adrian Bunk
` (17 subsequent siblings)
29 siblings, 0 replies; 192+ messages in thread
From: Adrian Bunk @ 2006-08-13 21:00 UTC (permalink / raw)
To: Andrew Morton, airlied; +Cc: linux-kernel, dri-devel
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc3-mm2:
>...
> git-drm.patch
>...
> git trees
>...
This patch contains the following cleanups:
- make 3 needlessly global functions static
- sis_mm.c: fix compile warnings with CONFIG_FB_SIS=y
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/char/drm/drm_bufs.c | 4 ++--
drivers/char/drm/drm_sman.c | 2 +-
drivers/char/drm/sis_mm.c | 12 +++++++-----
3 files changed, 10 insertions(+), 8 deletions(-)
--- linux-2.6.18-rc4-mm1/drivers/char/drm/drm_bufs.c.old 2006-08-13 17:31:20.000000000 +0200
+++ linux-2.6.18-rc4-mm1/drivers/char/drm/drm_bufs.c 2006-08-13 17:31:32.000000000 +0200
@@ -62,14 +62,14 @@
}
}
return NULL;
}
-int drm_map_handle(drm_device_t *dev, drm_hash_item_t *hash,
- unsigned long user_token, int hashed_handle)
+static int drm_map_handle(drm_device_t *dev, drm_hash_item_t *hash,
+ unsigned long user_token, int hashed_handle)
{
int use_hashed_handle;
#if (BITS_PER_LONG == 64)
use_hashed_handle = ((user_token & 0xFFFFFFFF00000000UL) || hashed_handle);
#elif (BITS_PER_LONG == 32)
use_hashed_handle = hashed_handle;
--- linux-2.6.18-rc4-mm1/drivers/char/drm/drm_sman.c.old 2006-08-13 17:33:04.000000000 +0200
+++ linux-2.6.18-rc4-mm1/drivers/char/drm/drm_sman.c 2006-08-13 17:33:12.000000000 +0200
@@ -111,13 +111,13 @@
{
drm_mm_t *mm = (drm_mm_t *) private;
drm_mm_takedown(mm);
drm_free(mm, sizeof(*mm), DRM_MEM_MM);
}
-unsigned long drm_sman_mm_offset(void *private, void *ref)
+static unsigned long drm_sman_mm_offset(void *private, void *ref)
{
drm_mm_node_t *node = (drm_mm_node_t *) ref;
return node->start;
}
int
--- linux-2.6.18-rc4-mm1/drivers/char/drm/sis_mm.c.old 2006-08-13 17:33:27.000000000 +0200
+++ linux-2.6.18-rc4-mm1/drivers/char/drm/sis_mm.c 2006-08-13 18:47:14.000000000 +0200
@@ -37,15 +37,12 @@
#include <video/sisfb.h>
#define VIDEO_TYPE 0
#define AGP_TYPE 1
-#define SIS_MM_ALIGN_SHIFT 4
-#define SIS_MM_ALIGN_MASK ( (1 << SIS_MM_ALIGN_SHIFT) - 1)
-
#if defined(CONFIG_FB_SIS)
/* fb management via fb device */
#define SIS_MM_ALIGN_SHIFT 0
#define SIS_MM_ALIGN_MASK 0
@@ -69,18 +66,23 @@
static void sis_sman_mm_destroy(void *private)
{
;
}
-unsigned long sis_sman_mm_offset(void *private, void *ref)
+static unsigned long sis_sman_mm_offset(void *private, void *ref)
{
return ~((unsigned long)ref);
}
-#endif
+#else /* CONFIG_FB_SIS */
+
+#define SIS_MM_ALIGN_SHIFT 4
+#define SIS_MM_ALIGN_MASK ( (1 << SIS_MM_ALIGN_SHIFT) - 1)
+
+#endif /* CONFIG_FB_SIS */
static int sis_fb_init(DRM_IOCTL_ARGS)
{
DRM_DEVICE;
drm_sis_private_t *dev_priv = dev->dev_private;
drm_sis_fb_t fb;
^ permalink raw reply [flat|nested] 192+ messages in thread* [-mm patch] kernel/time/ntp.c: possible cleanups
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (11 preceding siblings ...)
2006-08-13 21:00 ` [-mm patch] drivers/char/drm/: cleanups Adrian Bunk
@ 2006-08-13 21:00 ` Adrian Bunk
2006-08-13 21:01 ` [-mm patch] cleanup drivers/ata/Kconfig Adrian Bunk
` (16 subsequent siblings)
29 siblings, 0 replies; 192+ messages in thread
From: Adrian Bunk @ 2006-08-13 21:00 UTC (permalink / raw)
To: Andrew Morton, Roman Zippel; +Cc: linux-kernel, john stultz
This patch contains the following possible cleanups:
- make the following needlessly global function static:
- ntp_update_frequency()
- make the following needlessly global variables static:
- time_state
- time_offset
- time_constant
- time_reftime
- remove the following read-only global variable:
- time_precision
Please review which of these changes do make sense and which do conflict
with pending patches.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
include/linux/timex.h | 6 ------
kernel/time/ntp.c | 39 +++++++++++++++++++--------------------
2 files changed, 19 insertions(+), 26 deletions(-)
--- linux-2.6.18-rc4-mm1/include/linux/timex.h.old 2006-08-13 18:20:36.000000000 +0200
+++ linux-2.6.18-rc4-mm1/include/linux/timex.h 2006-08-13 18:23:24.000000000 +0200
@@ -197,21 +197,15 @@
/*
* phase-lock loop variables
*/
-extern int time_state; /* clock status */
extern int time_status; /* clock synchronization status bits */
-extern long time_offset; /* time adjustment (us) */
-extern long time_constant; /* pll time constant */
-extern long time_precision; /* clock precision (us) */
extern long time_maxerror; /* maximum error */
extern long time_esterror; /* estimated error */
extern long time_freq; /* frequency offset (scaled ppm) */
-extern long time_reftime; /* time at last adjustment (s) */
extern long time_adjust; /* The amount of adjtime left */
extern void ntp_clear(void);
-extern void ntp_update_frequency(void);
/**
* ntp_synced - Returns 1 if the NTP status is not UNSYNC
--- linux-2.6.18-rc4-mm1/kernel/time/ntp.c.old 2006-08-13 18:18:58.000000000 +0200
+++ linux-2.6.18-rc4-mm1/kernel/time/ntp.c 2006-08-13 18:23:33.000000000 +0200
@@ -30,17 +30,30 @@
* phase-lock loop variables
*/
/* TIME_ERROR prevents overwriting the CMOS clock */
-int time_state = TIME_OK; /* clock synchronization status */
+static int time_state = TIME_OK; /* clock synchronization status */
int time_status = STA_UNSYNC; /* clock status bits */
-long time_offset; /* time adjustment (ns) */
-long time_constant = 2; /* pll time constant */
-long time_precision = 1; /* clock precision (us) */
+static long time_offset; /* time adjustment (ns) */
+static long time_constant = 2; /* pll time constant */
long time_maxerror = NTP_PHASE_LIMIT; /* maximum error (us) */
long time_esterror = NTP_PHASE_LIMIT; /* estimated error (us) */
long time_freq; /* frequency offset (scaled ppm)*/
-long time_reftime; /* time at last adjustment (s) */
+static long time_reftime; /* time at last adjustment (s) */
long time_adjust;
+#define CLOCK_TICK_OVERFLOW (LATCH * HZ - CLOCK_TICK_RATE)
+#define CLOCK_TICK_ADJUST (((s64)CLOCK_TICK_OVERFLOW * NSEC_PER_SEC) / CLOCK_TICK_RATE)
+
+static void ntp_update_frequency(void)
+{
+ tick_length_base = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ) << TICK_LENGTH_SHIFT;
+ tick_length_base += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT;
+ tick_length_base += (s64)time_freq << (TICK_LENGTH_SHIFT - SHIFT_NSEC);
+
+ do_div(tick_length_base, HZ);
+
+ tick_nsec = tick_length_base >> TICK_LENGTH_SHIFT;
+}
+
/**
* ntp_clear - Clears the NTP state variables
*
@@ -59,20 +72,6 @@
time_offset = 0;
}
-#define CLOCK_TICK_OVERFLOW (LATCH * HZ - CLOCK_TICK_RATE)
-#define CLOCK_TICK_ADJUST (((s64)CLOCK_TICK_OVERFLOW * NSEC_PER_SEC) / CLOCK_TICK_RATE)
-
-void ntp_update_frequency(void)
-{
- tick_length_base = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ) << TICK_LENGTH_SHIFT;
- tick_length_base += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT;
- tick_length_base += (s64)time_freq << (TICK_LENGTH_SHIFT - SHIFT_NSEC);
-
- do_div(tick_length_base, HZ);
-
- tick_nsec = tick_length_base >> TICK_LENGTH_SHIFT;
-}
-
/*
* this routine handles the overflow of the microsecond field
*
@@ -330,7 +329,7 @@
txc->esterror = time_esterror;
txc->status = time_status;
txc->constant = time_constant;
- txc->precision = time_precision;
+ txc->precision = 1;
txc->tolerance = MAXFREQ;
txc->tick = tick_usec;
^ permalink raw reply [flat|nested] 192+ messages in thread* [-mm patch] cleanup drivers/ata/Kconfig
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (12 preceding siblings ...)
2006-08-13 21:00 ` [-mm patch] kernel/time/ntp.c: possible cleanups Adrian Bunk
@ 2006-08-13 21:01 ` Adrian Bunk
2006-08-13 22:46 ` Alan Cox
` (2 more replies)
2006-08-13 21:01 ` [-mm patch] net/decnet/: cleanups Adrian Bunk
` (15 subsequent siblings)
29 siblings, 3 replies; 192+ messages in thread
From: Adrian Bunk @ 2006-08-13 21:01 UTC (permalink / raw)
To: Andrew Morton, jgarzik, Alan Cox; +Cc: linux-kernel, linux-ide
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc3-mm2:
>...
> git-libata-all.patch
>...
> git trees
>...
This patch contains the following cleanups:
- create a menu for ATA
- replace the dependencies on ATA with an "if ATA"
as a side effect, this fixes a menu breakage due to SATA_INTEL_COMBINED
- fix a typo in the PATA_OPTIDMA prompt
- let ATA selet SCSI instead of depending on SCSI
this should make it easier for users to enable ATA (similar to USB_STORAGE)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
One issue I noticed while creating this patch is that for the following
options the dependency and the prompt don't agree whether the option
is EXPERIMENTAL:
- SATA_SX4
- PATA_AMD
- PATA_HPT3X3
- PATA_SC1200
drivers/ata/Kconfig | 117 ++++++++++++++++++++++----------------------
1 file changed, 61 insertions(+), 56 deletions(-)
--- linux-2.6.18-rc4-mm1/drivers/ata/Kconfig.old 2006-08-13 20:32:42.000000000 +0200
+++ linux-2.6.18-rc4-mm1/drivers/ata/Kconfig 2006-08-13 20:55:16.000000000 +0200
@@ -1,483 +1,488 @@
+menu "ATA device support"
config ATA
tristate "ATA device support"
- depends on SCSI
+ select SCSI
---help---
If you want to use a ATA hard disk, ATA tape drive, ATA CD-ROM or
any other ATA device under Linux, say Y and make sure that you know
the name of your ATA host adapter (the card inside your computer
that "speaks" the ATA protocol, also called ATA controller),
because you will be asked for it.
+if ATA
+
config SATA_AHCI
tristate "AHCI SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for AHCI Serial ATA.
If unsure, say N.
config SATA_SVW
tristate "ServerWorks Frodo / Apple K2 SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Broadcom/Serverworks/Apple K2
SATA support.
If unsure, say N.
config ATA_PIIX
tristate "Intel PIIX/ICH SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for ICH5/6/7/8 Serial ATA.
If PATA support was enabled previously, this enables
support for select Intel PIIX/ICH PATA host controllers.
If unsure, say N.
config SATA_MV
tristate "Marvell SATA support (HIGHLY EXPERIMENTAL)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the Marvell Serial ATA family.
Currently supports 88SX[56]0[48][01] chips.
If unsure, say N.
config SATA_NV
tristate "NVIDIA SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for NVIDIA Serial ATA.
If unsure, say N.
config PDC_ADMA
tristate "Pacific Digital ADMA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Pacific Digital ADMA controllers
If unsure, say N.
config SATA_QSTOR
tristate "Pacific Digital SATA QStor support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Pacific Digital Serial ATA QStor.
If unsure, say N.
config SATA_PROMISE
tristate "Promise SATA TX2/TX4 support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Promise Serial ATA TX2/TX4.
If unsure, say N.
config SATA_SX4
tristate "Promise SATA SX4 support"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for Promise Serial ATA SX4.
If unsure, say N.
config SATA_SIL
tristate "Silicon Image SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Silicon Image Serial ATA.
If unsure, say N.
config SATA_SIL24
tristate "Silicon Image 3124/3132 SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Silicon Image 3124/3132 Serial ATA.
If unsure, say N.
config SATA_SIS
tristate "SiS 964/180 SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for SiS Serial ATA 964/180.
If unsure, say N.
config SATA_ULI
tristate "ULi Electronics SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for ULi Electronics SATA.
If unsure, say N.
config SATA_VIA
tristate "VIA SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for VIA Serial ATA.
If unsure, say N.
config SATA_VITESSE
tristate "VITESSE VSC-7174 / INTEL 31244 SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Vitesse VSC7174 and Intel 31244 Serial ATA.
If unsure, say N.
config SATA_INTEL_COMBINED
bool
depends on IDE=y && !BLK_DEV_IDE_SATA && (SATA_AHCI || ATA_PIIX)
default y
config PATA_ALI
tristate "ALi PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the ALi ATA interfaces
found on the many ALi chipsets.
If unsure, say N.
config PATA_AMD
tristate "AMD/NVidia PATA support (Experimental)"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for the AMD and NVidia PATA
interfaces found on the chipsets for Athlon/Athlon64.
If unsure, say N.
config PATA_ARTOP
tristate "ARTOP 6210/6260 PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for ARTOP PATA controllers.
If unsure, say N.
config PATA_ATIIXP
tristate "ATI PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the ATI ATA interfaces
found on the many ATI chipsets.
If unsure, say N.
config PATA_CMD64X
tristate "CMD64x PATA support (Very Experimental)"
- depends on ATA && PCI&& EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the CMD64x series chips
except for the CMD640.
If unsure, say N.
config PATA_CS5520
tristate "CS5510/5520 PATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for the Cyrix 5510/5520
companion chip used with the MediaGX/Geode processor family.
If unsure, say N.
config PATA_CS5530
tristate "CS5530 PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the Cyrix/NatSemi/AMD CS5530
companion chip used with the MediaGX/Geode processor family.
If unsure, say N.
config PATA_CS5535
tristate "CS5535 PATA support (Experimental)"
- depends on ATA && PCI && X86 && !X86_64 && EXPERIMENTAL
+ depends on PCI && X86 && !X86_64 && EXPERIMENTAL
help
This option enables support for the NatSemi/AMD CS5535
companion chip used with the Geode processor family.
If unsure, say N.
config PATA_CYPRESS
tristate "Cypress CY82C693 PATA support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the Cypress/Contaq CY82C693
chipset found in some Alpha systems
If unsure, say N.
config PATA_EFAR
tristate "EFAR SLC90E66 support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for the EFAR SLC90E66
IDE controller found on some older machines.
If unsure, say N.
config ATA_GENERIC
tristate "Generic ATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for generic BIOS configured
ATA controllers via the new ATA layer
If unsure, say N.
config PATA_HPT366
tristate "HPT 366/368 PATA support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the HPT 366 and 368
PATA controllers via the new ATA layer.
If unsure, say N.
config PATA_HPT37X
tristate "HPT 370/370A/371/372/374/302 PATA support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the majority of the later HPT
PATA controllers via the new ATA layer.
If unsure, say N.
config PATA_HPT3X2N
tristate "HPT 372N/302N PATA support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the N variant HPT PATA
controllers via the new ATA layer
If unsure, say N.
config PATA_HPT3X3
tristate "HPT 343/363 PATA support (Experimental)"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for the HPT 343/363
PATA controllers via the new ATA layer
If unsure, say N.
config PATA_ISAPNP
tristate "ISA Plug and Play PATA support (Very Experimental)"
- depends on ATA && EXPERIMENTAL && ISAPNP
+ depends on EXPERIMENTAL && ISAPNP
help
This option enables support for ISA plug & play ATA
controllers such as those found on old soundcards.
If unsure, say N.
config PATA_IT8172
tristate "IT8172 PATA support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the ITE 8172 PATA controller
via the new ATA layer.
If unsure, say N.
config PATA_IT821X
tristate "IT821x PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the ITE 8211 and 8212
PATA controllers via the new ATA layer, including RAID
mode.
If unsure, say N.
config ATA_JMICRON
tristate "JMicron non-AHCI support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for Jmicron ATA controllers
ports running in non-AHCI mode. Where possible you should
set the configuration for AHCI to get better performance
config PATA_LEGACY
tristate "Legacy ISA PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for ISA/VLB bus legacy PATA
ports and allows them to be accessed via the new ATA layer.
If unsure, say N.
config PATA_TRIFLEX
tristate "Compaq Triflex PATA support"
- depends on ATA && PCI
+ depends on PCI
help
Enable support for the Compaq 'Triflex' IDE controller as found
on many Compaq Pentium-Pro systems, via the new ATA layer.
If unsure, say N.
config PATA_MPIIX
tristate "Intel PATA MPIIX support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for MPIIX PATA support.
If unsure, say N.
config PATA_OLDPIIX
tristate "Intel PATA old PIIX support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for old(?) PIIX PATA support.
If unsure, say N.
config PATA_NETCELL
tristate "NETCELL Revolution RAID support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for the Netcell Revolution RAID
PATA controller.
If unsure, say N.
config PATA_NS87410
tristate "Nat Semi NS87410 PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the National Semiconductor
NS87410 PCI-IDE controller.
If unsure, say N.
config PATA_OPTI
tristate "OPTI621/6215 PATA support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables full PIO support for the early Opti ATA
controllers found on some old motherboards.
If unsure, say N.
config PATA_OPTIDMA
- tristate "OPTI FireStar PATA support (Veyr Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ tristate "OPTI FireStar PATA support (Very Experimental)"
+ depends on PCI && EXPERIMENTAL
help
This option enables DMA/PIO support for the later OPTi
controllers found on some old motherboards and in some
latops
If unsure, say N.
config PATA_PCMCIA
tristate "PCMCIA PATA support"
- depends on ATA && PCMCIA
+ depends on PCMCIA
help
This option enables support for PCMCIA ATA interfaces, including
compact flash card adapters via the new ATA layer.
If unsure, say N.
config PATA_PDC_OLD
tristate "Older Promise PATA controller support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the Promise 20246, 20262, 20263,
20265 and 20267 adapters.
If unsure, say N.
config PATA_QDI
tristate "QDI VLB PATA support"
- depends on ATA
help
Support for QDI 6500 and 6580 PATA controllers on VESA local bus.
config PATA_RADISYS
tristate "RADISYS 82600 PATA support (Very experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the RADISYS 82600
PATA controllers via the new ATA layer
If unsure, say N.
config PATA_RZ1000
tristate "PC Tech RZ1000 PATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables basic support for the PC Tech RZ1000/1
PATA controllers via the new ATA layer
If unsure, say N.
config PATA_SC1200
tristate "SC1200 PATA support (Raving Lunatic)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the NatSemi/AMD SC1200 SoC
companion chip used with the Geode processor family.
If unsure, say N.
config PATA_SERVERWORKS
tristate "SERVERWORKS OSB4/CSB5/CSB6/HT1000 PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the Serverworks OSB4/CSB5/CSB6 and
HT1000 PATA controllers, via the new ATA layer.
If unsure, say N.
config PATA_PDC2027X
tristate "Promise PATA 2027x support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Promise PATA pdc20268 to pdc20277 host adapters.
If unsure, say N.
config PATA_SIL680
tristate "CMD / Silicon Image 680 PATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for CMD / Silicon Image 680 PATA.
If unsure, say N.
config PATA_SIS
tristate "SiS PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for SiS PATA controllers
If unsure, say N.
config PATA_VIA
tristate "VIA PATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for the VIA PATA interfaces
found on the many VIA chipsets.
If unsure, say N.
config PATA_WINBOND
tristate "Winbond SL82C105 PATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for SL82C105 PATA devices found in the
Netwinder and some other systems
If unsure, say N.
+endif # ATA
+
+endmenu # "ATA device support"
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: [-mm patch] cleanup drivers/ata/Kconfig
2006-08-13 21:01 ` [-mm patch] cleanup drivers/ata/Kconfig Adrian Bunk
@ 2006-08-13 22:46 ` Alan Cox
2006-08-14 22:12 ` Adrian Bunk
2006-08-14 18:28 ` Jeff Garzik
2006-08-15 7:51 ` [-mm " Greg KH
2 siblings, 1 reply; 192+ messages in thread
From: Alan Cox @ 2006-08-13 22:46 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, jgarzik, linux-kernel, linux-ide
Ar Sul, 2006-08-13 am 23:01 +0200, ysgrifennodd Adrian Bunk:
> One issue I noticed while creating this patch is that for the following
> options the dependency and the prompt don't agree whether the option
> is EXPERIMENTAL:
> - SATA_SX4
> - PATA_AMD
> - PATA_HPT3X3
> - PATA_SC1200
HPT3x3, SC1200 are experimental
AMD is not intended to be any more.
Thanks for spotting these.
> config ATA_JMICRON
> tristate "JMicron non-AHCI support (Experimental)"
> - depends on ATA && PCI && EXPERIMENTAL
> + depends on PCI && EXPERIMENTAL
> help
> This option enables support for Jmicron ATA controllers
> ports running in non-AHCI mode. Where possible you should
> set the configuration for AHCI to get better performance
Actually I should mark this as non-experimental too but I'll do that and
push it the proper path.
> config PATA_LEGACY
> tristate "Legacy ISA PATA support (Experimental)"
> - depends on ATA && PCI && EXPERIMENTAL
> + depends on PCI && EXPERIMENTAL
My fault I suspect - shouldn't have been && PCI originally
Acked-by: Alan Cox <alan@redhat.com>
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [-mm patch] cleanup drivers/ata/Kconfig
2006-08-13 22:46 ` Alan Cox
@ 2006-08-14 22:12 ` Adrian Bunk
0 siblings, 0 replies; 192+ messages in thread
From: Adrian Bunk @ 2006-08-14 22:12 UTC (permalink / raw)
To: Alan Cox; +Cc: Andrew Morton, jgarzik, linux-kernel, linux-ide
On Sun, Aug 13, 2006 at 11:46:19PM +0100, Alan Cox wrote:
> Ar Sul, 2006-08-13 am 23:01 +0200, ysgrifennodd Adrian Bunk:
> > One issue I noticed while creating this patch is that for the following
> > options the dependency and the prompt don't agree whether the option
> > is EXPERIMENTAL:
> > - SATA_SX4
> > - PATA_AMD
> > - PATA_HPT3X3
> > - PATA_SC1200
>
> HPT3x3, SC1200 are experimental
> AMD is not intended to be any more.
>
> Thanks for spotting these.
>...
What's with SATA_SX4?
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [-mm patch] cleanup drivers/ata/Kconfig
2006-08-13 21:01 ` [-mm patch] cleanup drivers/ata/Kconfig Adrian Bunk
2006-08-13 22:46 ` Alan Cox
@ 2006-08-14 18:28 ` Jeff Garzik
2006-08-14 22:33 ` [libata " Adrian Bunk
2006-08-15 7:51 ` [-mm " Greg KH
2 siblings, 1 reply; 192+ messages in thread
From: Jeff Garzik @ 2006-08-14 18:28 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, Alan Cox, linux-kernel, linux-ide
Adrian Bunk wrote:
> On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>> ...
>> Changes since 2.6.18-rc3-mm2:
>> ...
>> git-libata-all.patch
>> ...
>> git trees
>> ...
>
> This patch contains the following cleanups:
> - create a menu for ATA
> - replace the dependencies on ATA with an "if ATA"
> as a side effect, this fixes a menu breakage due to SATA_INTEL_COMBINED
> - fix a typo in the PATA_OPTIDMA prompt
> - let ATA selet SCSI instead of depending on SCSI
> this should make it easier for users to enable ATA (similar to USB_STORAGE)
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
There have been a bunch of more-important changes to this file. Please
wait until Andrew pulls from me, and resend.
Thanks,
Jeff
^ permalink raw reply [flat|nested] 192+ messages in thread
* [libata patch] cleanup drivers/ata/Kconfig
2006-08-14 18:28 ` Jeff Garzik
@ 2006-08-14 22:33 ` Adrian Bunk
0 siblings, 0 replies; 192+ messages in thread
From: Adrian Bunk @ 2006-08-14 22:33 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, Alan Cox, linux-kernel, linux-ide
On Mon, Aug 14, 2006 at 02:28:12PM -0400, Jeff Garzik wrote:
> Adrian Bunk wrote:
> >On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
> >>...
> >>Changes since 2.6.18-rc3-mm2:
> >>...
> >> git-libata-all.patch
> >>...
> >> git trees
> >>...
> >
> >This patch contains the following cleanups:
> >- create a menu for ATA
> >- replace the dependencies on ATA with an "if ATA"
> > as a side effect, this fixes a menu breakage due to SATA_INTEL_COMBINED
> >- fix a typo in the PATA_OPTIDMA prompt
> >- let ATA selet SCSI instead of depending on SCSI
> > this should make it easier for users to enable ATA (similar to
> > USB_STORAGE)
> >
> >Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> There have been a bunch of more-important changes to this file. Please
> wait until Andrew pulls from me, and resend.
Below is a rediff against libata-dev.git#ALL (not including Alans
additional suggestions that will be in another patch).
> Thanks,
>
> Jeff
cu
Adrian
<-- snip -->
This patch contains the following cleanups:
- replace the dependencies on ATA with an "if ATA"
as a side effect, this fixes a menu breakage due to SATA_INTEL_COMBINED
- fix a typo in the PATA_OPTIDMA prompt
- let ATA selet SCSI instead of depending on SCSI
this should make it easier for users to enable ATA (similar to USB_STORAGE)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/ata/Kconfig | 115 ++++++++++++++++++++++----------------------
1 file changed, 58 insertions(+), 57 deletions(-)
--- libata-dev/drivers/ata/Kconfig.old 2006-08-15 00:23:28.000000000 +0200
+++ libata-dev/drivers/ata/Kconfig 2006-08-15 00:28:02.000000000 +0200
@@ -1,483 +1,484 @@
#
# SATA/PATA driver configuration
#
menu "Serial ATA (prod) and Parallel ATA (experimental) drivers"
- depends on SCSI
config ATA
tristate "ATA device support"
- depends on SCSI
+ select SCSI
---help---
If you want to use a ATA hard disk, ATA tape drive, ATA CD-ROM or
any other ATA device under Linux, say Y and make sure that you know
the name of your ATA host adapter (the card inside your computer
that "speaks" the ATA protocol, also called ATA controller),
because you will be asked for it.
+if ATA
+
config SATA_AHCI
tristate "AHCI SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for AHCI Serial ATA.
If unsure, say N.
config SATA_SVW
tristate "ServerWorks Frodo / Apple K2 SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Broadcom/Serverworks/Apple K2
SATA support.
If unsure, say N.
config ATA_PIIX
tristate "Intel PIIX/ICH SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for ICH5/6/7/8 Serial ATA.
If PATA support was enabled previously, this enables
support for select Intel PIIX/ICH PATA host controllers.
If unsure, say N.
config SATA_MV
tristate "Marvell SATA support (HIGHLY EXPERIMENTAL)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the Marvell Serial ATA family.
Currently supports 88SX[56]0[48][01] chips.
If unsure, say N.
config SATA_NV
tristate "NVIDIA SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for NVIDIA Serial ATA.
If unsure, say N.
config PDC_ADMA
tristate "Pacific Digital ADMA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Pacific Digital ADMA controllers
If unsure, say N.
config SATA_QSTOR
tristate "Pacific Digital SATA QStor support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Pacific Digital Serial ATA QStor.
If unsure, say N.
config SATA_PROMISE
tristate "Promise SATA TX2/TX4 support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Promise Serial ATA TX2/TX4.
If unsure, say N.
config SATA_SX4
tristate "Promise SATA SX4 support"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for Promise Serial ATA SX4.
If unsure, say N.
config SATA_SIL
tristate "Silicon Image SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Silicon Image Serial ATA.
If unsure, say N.
config SATA_SIL24
tristate "Silicon Image 3124/3132 SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Silicon Image 3124/3132 Serial ATA.
If unsure, say N.
config SATA_SIS
tristate "SiS 964/180 SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for SiS Serial ATA 964/180.
If unsure, say N.
config SATA_ULI
tristate "ULi Electronics SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for ULi Electronics SATA.
If unsure, say N.
config SATA_VIA
tristate "VIA SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for VIA Serial ATA.
If unsure, say N.
config SATA_VITESSE
tristate "VITESSE VSC-7174 / INTEL 31244 SATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Vitesse VSC7174 and Intel 31244 Serial ATA.
If unsure, say N.
config SATA_INTEL_COMBINED
bool
depends on IDE=y && !BLK_DEV_IDE_SATA && (SATA_AHCI || ATA_PIIX)
default y
config PATA_ALI
tristate "ALi PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the ALi ATA interfaces
found on the many ALi chipsets.
If unsure, say N.
config PATA_AMD
tristate "AMD/NVidia PATA support (Experimental)"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for the AMD and NVidia PATA
interfaces found on the chipsets for Athlon/Athlon64.
If unsure, say N.
config PATA_ARTOP
tristate "ARTOP 6210/6260 PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for ARTOP PATA controllers.
If unsure, say N.
config PATA_ATIIXP
tristate "ATI PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the ATI ATA interfaces
found on the many ATI chipsets.
If unsure, say N.
config PATA_CMD64X
tristate "CMD64x PATA support (Very Experimental)"
- depends on ATA && PCI&& EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the CMD64x series chips
except for the CMD640.
If unsure, say N.
config PATA_CS5520
tristate "CS5510/5520 PATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for the Cyrix 5510/5520
companion chip used with the MediaGX/Geode processor family.
If unsure, say N.
config PATA_CS5530
tristate "CS5530 PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the Cyrix/NatSemi/AMD CS5530
companion chip used with the MediaGX/Geode processor family.
If unsure, say N.
config PATA_CS5535
tristate "CS5535 PATA support (Experimental)"
- depends on ATA && PCI && X86 && !X86_64 && EXPERIMENTAL
+ depends on PCI && X86 && !X86_64 && EXPERIMENTAL
help
This option enables support for the NatSemi/AMD CS5535
companion chip used with the Geode processor family.
If unsure, say N.
config PATA_CYPRESS
tristate "Cypress CY82C693 PATA support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the Cypress/Contaq CY82C693
chipset found in some Alpha systems
If unsure, say N.
config PATA_EFAR
tristate "EFAR SLC90E66 support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for the EFAR SLC90E66
IDE controller found on some older machines.
If unsure, say N.
config ATA_GENERIC
tristate "Generic ATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for generic BIOS configured
ATA controllers via the new ATA layer
If unsure, say N.
config PATA_HPT366
tristate "HPT 366/368 PATA support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the HPT 366 and 368
PATA controllers via the new ATA layer.
If unsure, say N.
config PATA_HPT37X
tristate "HPT 370/370A/371/372/374/302 PATA support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the majority of the later HPT
PATA controllers via the new ATA layer.
If unsure, say N.
config PATA_HPT3X2N
tristate "HPT 372N/302N PATA support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the N variant HPT PATA
controllers via the new ATA layer
If unsure, say N.
config PATA_HPT3X3
tristate "HPT 343/363 PATA support (Experimental)"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for the HPT 343/363
PATA controllers via the new ATA layer
If unsure, say N.
config PATA_ISAPNP
tristate "ISA Plug and Play PATA support (Very Experimental)"
- depends on ATA && EXPERIMENTAL && ISAPNP
+ depends on EXPERIMENTAL && ISAPNP
help
This option enables support for ISA plug & play ATA
controllers such as those found on old soundcards.
If unsure, say N.
config PATA_IT8172
tristate "IT8172 PATA support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the ITE 8172 PATA controller
via the new ATA layer.
If unsure, say N.
config PATA_IT821X
tristate "IT821x PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the ITE 8211 and 8212
PATA controllers via the new ATA layer, including RAID
mode.
If unsure, say N.
config PATA_LEGACY
tristate "Legacy ISA PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for ISA/VLB bus legacy PATA
ports and allows them to be accessed via the new ATA layer.
If unsure, say N.
config PATA_TRIFLEX
tristate "Compaq Triflex PATA support"
- depends on ATA && PCI
+ depends on PCI
help
Enable support for the Compaq 'Triflex' IDE controller as found
on many Compaq Pentium-Pro systems, via the new ATA layer.
If unsure, say N.
config PATA_MPIIX
tristate "Intel PATA MPIIX support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for MPIIX PATA support.
If unsure, say N.
config PATA_OLDPIIX
tristate "Intel PATA old PIIX support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for old(?) PIIX PATA support.
If unsure, say N.
config PATA_NETCELL
tristate "NETCELL Revolution RAID support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for the Netcell Revolution RAID
PATA controller.
If unsure, say N.
config PATA_NS87410
tristate "Nat Semi NS87410 PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the National Semiconductor
NS87410 PCI-IDE controller.
If unsure, say N.
config PATA_OPTI
tristate "OPTI621/6215 PATA support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables full PIO support for the early Opti ATA
controllers found on some old motherboards.
If unsure, say N.
config PATA_OPTIDMA
- tristate "OPTI FireStar PATA support (Veyr Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ tristate "OPTI FireStar PATA support (Very Experimental)"
+ depends on PCI && EXPERIMENTAL
help
This option enables DMA/PIO support for the later OPTi
controllers found on some old motherboards and in some
latops
If unsure, say N.
config PATA_PCMCIA
tristate "PCMCIA PATA support"
- depends on ATA && PCMCIA
+ depends on PCMCIA
help
This option enables support for PCMCIA ATA interfaces, including
compact flash card adapters via the new ATA layer.
If unsure, say N.
config PATA_PDC_OLD
tristate "Older Promise PATA controller support (Very Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the Promise 20246, 20262, 20263,
20265 and 20267 adapters.
If unsure, say N.
config PATA_QDI
tristate "QDI VLB PATA support"
- depends on ATA
help
Support for QDI 6500 and 6580 PATA controllers on VESA local bus.
config PATA_RADISYS
tristate "RADISYS 82600 PATA support (Very experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the RADISYS 82600
PATA controllers via the new ATA layer
If unsure, say N.
config PATA_RZ1000
tristate "PC Tech RZ1000 PATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables basic support for the PC Tech RZ1000/1
PATA controllers via the new ATA layer
If unsure, say N.
config PATA_SC1200
tristate "SC1200 PATA support (Raving Lunatic)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the NatSemi/AMD SC1200 SoC
companion chip used with the Geode processor family.
If unsure, say N.
config PATA_SERVERWORKS
tristate "SERVERWORKS OSB4/CSB5/CSB6/HT1000 PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for the Serverworks OSB4/CSB5/CSB6 and
HT1000 PATA controllers, via the new ATA layer.
If unsure, say N.
config PATA_PDC2027X
tristate "Promise PATA 2027x support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for Promise PATA pdc20268 to pdc20277 host adapters.
If unsure, say N.
config PATA_SIL680
tristate "CMD / Silicon Image 680 PATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for CMD / Silicon Image 680 PATA.
If unsure, say N.
config PATA_SIS
tristate "SiS PATA support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for SiS PATA controllers
If unsure, say N.
config PATA_VIA
tristate "VIA PATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for the VIA PATA interfaces
found on the many VIA chipsets.
If unsure, say N.
config PATA_WINBOND
tristate "Winbond SL82C105 PATA support"
- depends on ATA && PCI
+ depends on PCI
help
This option enables support for SL82C105 PATA devices found in the
Netwinder and some other systems
If unsure, say N.
-endmenu
+endif # ATA
+endmenu # "ATA drivers"
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [-mm patch] cleanup drivers/ata/Kconfig
2006-08-13 21:01 ` [-mm patch] cleanup drivers/ata/Kconfig Adrian Bunk
2006-08-13 22:46 ` Alan Cox
2006-08-14 18:28 ` Jeff Garzik
@ 2006-08-15 7:51 ` Greg KH
2006-08-15 9:39 ` Adrian Bunk
2 siblings, 1 reply; 192+ messages in thread
From: Greg KH @ 2006-08-15 7:51 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, jgarzik, Alan Cox, linux-kernel, linux-ide
On Sun, Aug 13, 2006 at 11:01:06PM +0200, Adrian Bunk wrote:
> On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc3-mm2:
> >...
> > git-libata-all.patch
> >...
> > git trees
> >...
>
> This patch contains the following cleanups:
> - create a menu for ATA
> - replace the dependencies on ATA with an "if ATA"
Why do this? Are we going to be doing this for all subsystems?
It seems like a bit of unnecessary churn to me...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [-mm patch] cleanup drivers/ata/Kconfig
2006-08-15 7:51 ` [-mm " Greg KH
@ 2006-08-15 9:39 ` Adrian Bunk
0 siblings, 0 replies; 192+ messages in thread
From: Adrian Bunk @ 2006-08-15 9:39 UTC (permalink / raw)
To: Greg KH; +Cc: Andrew Morton, jgarzik, Alan Cox, linux-kernel, linux-ide
On Tue, Aug 15, 2006 at 12:51:44AM -0700, Greg KH wrote:
> On Sun, Aug 13, 2006 at 11:01:06PM +0200, Adrian Bunk wrote:
> > On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.18-rc3-mm2:
> > >...
> > > git-libata-all.patch
> > >...
> > > git trees
> > >...
> >
> > This patch contains the following cleanups:
> > - create a menu for ATA
> > - replace the dependencies on ATA with an "if ATA"
>
> Why do this? Are we going to be doing this for all subsystems?
>
> It seems like a bit of unnecessary churn to me...
The following two are exactly equivalent:
<-- snip -->
tristate BAR1 "bar1"
depends on FOO
tristate BAR2 "bar2"
depends on FOO
<-- snip -->
if FOO
tristate BAR1 "bar1"
tristate BAR2 "bar2"
endif
<-- snip -->
I'd say the latter is a bit better, but there's no reason to convert all
subsystems since the two forms are equivalent.
In this case, I was looking for a way to fix the breakage of the ATA
menu indentation due to SATA_INTEL_COMBINED, and this is the solution I
did choose.
> thanks,
>
> greg k-h
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 192+ messages in thread
* [-mm patch] net/decnet/: cleanups
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (13 preceding siblings ...)
2006-08-13 21:01 ` [-mm patch] cleanup drivers/ata/Kconfig Adrian Bunk
@ 2006-08-13 21:01 ` Adrian Bunk
2006-08-13 21:01 ` [-mm patch] net/ipv6/ip6_fib.c: make code static Adrian Bunk
` (14 subsequent siblings)
29 siblings, 0 replies; 192+ messages in thread
From: Adrian Bunk @ 2006-08-13 21:01 UTC (permalink / raw)
To: Andrew Morton, davem, patrick; +Cc: linux-kernel, netdev, linux-decnet-user
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc3-mm2:
>...
> git-net.patch
>...
> git trees
>...
This patch contains the following cleanups:
- make the following needlessly global functions static:
- dn_fib.c: dn_fib_sync_down()
- dn_fib.c: dn_fib_sync_up()
- dn_rules.c: dn_fib_rule_action()
- remove the following unneeded prototype:
- dn_fib.c: dn_cache_dump()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
include/net/dn_fib.h | 3 ---
net/decnet/dn_fib.c | 9 +++++----
net/decnet/dn_rules.c | 4 ++--
3 files changed, 7 insertions(+), 9 deletions(-)
--- linux-2.6.18-rc4-mm1/include/net/dn_fib.h.old 2006-08-13 20:18:58.000000000 +0200
+++ linux-2.6.18-rc4-mm1/include/net/dn_fib.h 2006-08-13 20:19:08.000000000 +0200
@@ -131,9 +131,6 @@
extern void dn_fib_flush(void);
extern void dn_fib_select_multipath(const struct flowi *fl,
struct dn_fib_res *res);
-extern int dn_fib_sync_down(__le16 local, struct net_device *dev,
- int force);
-extern int dn_fib_sync_up(struct net_device *dev);
/*
* dn_tables.c
--- linux-2.6.18-rc4-mm1/net/decnet/dn_fib.c.old 2006-08-13 20:20:05.000000000 +0200
+++ linux-2.6.18-rc4-mm1/net/decnet/dn_fib.c 2006-08-13 20:22:40.000000000 +0200
@@ -55,8 +55,6 @@
#define endfor_nexthops(fi) }
-extern int dn_cache_dump(struct sk_buff *skb, struct netlink_callback *cb);
-
static DEFINE_SPINLOCK(dn_fib_multipath_lock);
static struct dn_fib_info *dn_fib_info_list;
static DEFINE_SPINLOCK(dn_fib_info_lock);
@@ -80,6 +78,9 @@
[RTN_XRESOLVE] = { .error = -EINVAL, .scope = RT_SCOPE_NOWHERE },
};
+static int dn_fib_sync_down(__le16 local, struct net_device *dev, int force);
+static int dn_fib_sync_up(struct net_device *dev);
+
void dn_fib_free_info(struct dn_fib_info *fi)
{
if (fi->fib_dead == 0) {
@@ -651,7 +652,7 @@
return NOTIFY_DONE;
}
-int dn_fib_sync_down(__le16 local, struct net_device *dev, int force)
+static int dn_fib_sync_down(__le16 local, struct net_device *dev, int force)
{
int ret = 0;
int scope = RT_SCOPE_NOWHERE;
@@ -695,7 +696,7 @@
}
-int dn_fib_sync_up(struct net_device *dev)
+static int dn_fib_sync_up(struct net_device *dev)
{
int ret = 0;
--- linux-2.6.18-rc4-mm1/net/decnet/dn_rules.c.old 2006-08-13 20:22:45.000000000 +0200
+++ linux-2.6.18-rc4-mm1/net/decnet/dn_rules.c 2006-08-13 20:23:02.000000000 +0200
@@ -75,8 +75,8 @@
return err;
}
-int dn_fib_rule_action(struct fib_rule *rule, struct flowi *flp, int flags,
- struct fib_lookup_arg *arg)
+static int dn_fib_rule_action(struct fib_rule *rule, struct flowi *flp,
+ int flags, struct fib_lookup_arg *arg)
{
int err = -EAGAIN;
struct dn_fib_table *tbl;
^ permalink raw reply [flat|nested] 192+ messages in thread* [-mm patch] net/ipv6/ip6_fib.c: make code static
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (14 preceding siblings ...)
2006-08-13 21:01 ` [-mm patch] net/decnet/: cleanups Adrian Bunk
@ 2006-08-13 21:01 ` Adrian Bunk
2006-08-13 21:01 ` [-mm patch] Kconfig: move CRYPTO to the "Cryptographic options" menu Adrian Bunk
` (13 subsequent siblings)
29 siblings, 0 replies; 192+ messages in thread
From: Adrian Bunk @ 2006-08-13 21:01 UTC (permalink / raw)
To: Andrew Morton, davem; +Cc: linux-kernel, netdev
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc3-mm2:
>...
> git-net.patch
>...
> git trees
>...
This patch makes the following needlessly global code static:
- fib6_walker_lock
- struct fib6_walker_list
- fib6_walk_continue()
- fib6_walk()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
include/net/ip6_fib.h | 25 -------------------------
net/ipv6/ip6_fib.c | 29 ++++++++++++++++++++++++-----
2 files changed, 24 insertions(+), 30 deletions(-)
--- linux-2.6.18-rc4-mm1/include/net/ip6_fib.h.old 2006-08-13 20:25:29.000000000 +0200
+++ linux-2.6.18-rc4-mm1/include/net/ip6_fib.h 2006-08-13 20:29:34.000000000 +0200
@@ -92,28 +92,6 @@
void *args;
};
-extern struct fib6_walker_t fib6_walker_list;
-extern rwlock_t fib6_walker_lock;
-
-static inline void fib6_walker_link(struct fib6_walker_t *w)
-{
- write_lock_bh(&fib6_walker_lock);
- w->next = fib6_walker_list.next;
- w->prev = &fib6_walker_list;
- w->next->prev = w;
- w->prev->next = w;
- write_unlock_bh(&fib6_walker_lock);
-}
-
-static inline void fib6_walker_unlink(struct fib6_walker_t *w)
-{
- write_lock_bh(&fib6_walker_lock);
- w->next->prev = w->prev;
- w->prev->next = w->next;
- w->prev = w->next = w;
- write_unlock_bh(&fib6_walker_lock);
-}
-
struct rt6_statistics {
__u32 fib_nodes;
__u32 fib_route_nodes;
@@ -195,9 +173,6 @@
extern void fib6_clean_all(int (*func)(struct rt6_info *, void *arg),
int prune, void *arg);
-extern int fib6_walk(struct fib6_walker_t *w);
-extern int fib6_walk_continue(struct fib6_walker_t *w);
-
extern int fib6_add(struct fib6_node *root,
struct rt6_info *rt,
struct nlmsghdr *nlh,
--- linux-2.6.18-rc4-mm1/net/ipv6/ip6_fib.c.old 2006-08-13 20:26:04.000000000 +0200
+++ linux-2.6.18-rc4-mm1/net/ipv6/ip6_fib.c 2006-08-13 20:29:35.000000000 +0200
@@ -69,8 +69,7 @@
void *arg;
};
-DEFINE_RWLOCK(fib6_walker_lock);
-
+static DEFINE_RWLOCK(fib6_walker_lock);
#ifdef CONFIG_IPV6_SUBTREES
#define FWS_INIT FWS_S
@@ -82,6 +81,8 @@
static void fib6_prune_clones(struct fib6_node *fn, struct rt6_info *rt);
static struct fib6_node * fib6_repair_tree(struct fib6_node *fn);
+static int fib6_walk(struct fib6_walker_t *w);
+static int fib6_walk_continue(struct fib6_walker_t *w);
/*
* A routing update causes an increase of the serial number on the
@@ -94,13 +95,31 @@
static DEFINE_TIMER(ip6_fib_timer, fib6_run_gc, 0, 0);
-struct fib6_walker_t fib6_walker_list = {
+static struct fib6_walker_t fib6_walker_list = {
.prev = &fib6_walker_list,
.next = &fib6_walker_list,
};
#define FOR_WALKERS(w) for ((w)=fib6_walker_list.next; (w) != &fib6_walker_list; (w)=(w)->next)
+static inline void fib6_walker_link(struct fib6_walker_t *w)
+{
+ write_lock_bh(&fib6_walker_lock);
+ w->next = fib6_walker_list.next;
+ w->prev = &fib6_walker_list;
+ w->next->prev = w;
+ w->prev->next = w;
+ write_unlock_bh(&fib6_walker_lock);
+}
+
+static inline void fib6_walker_unlink(struct fib6_walker_t *w)
+{
+ write_lock_bh(&fib6_walker_lock);
+ w->next->prev = w->prev;
+ w->prev->next = w->next;
+ w->prev = w->next = w;
+ write_unlock_bh(&fib6_walker_lock);
+}
static __inline__ u32 fib6_new_sernum(void)
{
u32 n = ++rt_sernum;
@@ -1173,7 +1192,7 @@
* <0 -> walk is terminated by an error.
*/
-int fib6_walk_continue(struct fib6_walker_t *w)
+static int fib6_walk_continue(struct fib6_walker_t *w)
{
struct fib6_node *fn, *pn;
@@ -1247,7 +1266,7 @@
}
}
-int fib6_walk(struct fib6_walker_t *w)
+static int fib6_walk(struct fib6_walker_t *w)
{
int res;
^ permalink raw reply [flat|nested] 192+ messages in thread* [-mm patch] Kconfig: move CRYPTO to the "Cryptographic options" menu
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (15 preceding siblings ...)
2006-08-13 21:01 ` [-mm patch] net/ipv6/ip6_fib.c: make code static Adrian Bunk
@ 2006-08-13 21:01 ` Adrian Bunk
2006-08-13 22:40 ` Herbert Xu
2006-08-13 23:01 ` 2.6.18-rc4-mm1: ATI SB600 SATA drivers: modpost errors Adrian Bunk
` (12 subsequent siblings)
29 siblings, 1 reply; 192+ messages in thread
From: Adrian Bunk @ 2006-08-13 21:01 UTC (permalink / raw)
To: Andrew Morton, herbert, davem; +Cc: linux-kernel, linux-crypto
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc3-mm2:
>...
> git-cpufreq.patch
>...
> git trees
>...
This patch moves the CRYPTO option to the "Cryptographic options" menu
(it was the only option directly in the toplevel menu).
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
crypto/Kconfig | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- linux-2.6.18-rc4-mm1/crypto/Kconfig.old 2006-08-13 21:13:38.000000000 +0200
+++ linux-2.6.18-rc4-mm1/crypto/Kconfig 2006-08-13 21:14:24.000000000 +0200
@@ -2,6 +2,8 @@
# Cryptographic API Configuration
#
+menu "Cryptographic options"
+
config CRYPTO
bool "Cryptographic API"
help
@@ -9,8 +11,6 @@
if CRYPTO
-menu "Cryptographic options"
-
config CRYPTO_LOWAPI
tristate
@@ -402,6 +402,6 @@
source "drivers/crypto/Kconfig"
-endmenu
+endif # if CRYPTO
-endif # if CRYPTO
+endmenu
^ permalink raw reply [flat|nested] 192+ messages in thread* 2.6.18-rc4-mm1: ATI SB600 SATA drivers: modpost errors
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (16 preceding siblings ...)
2006-08-13 21:01 ` [-mm patch] Kconfig: move CRYPTO to the "Cryptographic options" menu Adrian Bunk
@ 2006-08-13 23:01 ` Adrian Bunk
2006-08-14 7:00 ` [patch -mm] s390: remove HIGHMEM dependencies Heiko Carstens
` (11 subsequent siblings)
29 siblings, 0 replies; 192+ messages in thread
From: Adrian Bunk @ 2006-08-13 23:01 UTC (permalink / raw)
To: Andrew Morton, Anatoli Antonovitch
Cc: linux-kernel, Jeff Garzik, Alan Cox, linux-ide, rusty, sam
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc3-mm2:
>...
> +ahci-ati-sb600-sata-support-for-various-modes.patch
> +atiixp-ati-sb600-ide-support-for-various-modes.patch
>...
> Misc patches
>...
<-- snip -->
...
MODPOST 1955 modules
WARNING: Can't handle masks in drivers/ata/ahci:FFFF05
WARNING: Can't handle masks in drivers/ide/pci/atiixp:FFFF05
...
<-- snip -->
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
^ permalink raw reply [flat|nested] 192+ messages in thread* [patch -mm] s390: remove HIGHMEM dependencies
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (17 preceding siblings ...)
2006-08-13 23:01 ` 2.6.18-rc4-mm1: ATI SB600 SATA drivers: modpost errors Adrian Bunk
@ 2006-08-14 7:00 ` Heiko Carstens
2006-08-14 14:13 ` Christoph Lameter
2006-08-14 14:02 ` 2.6.18-rc4-mm1 Michal Piotrowski
` (10 subsequent siblings)
29 siblings, 1 reply; 192+ messages in thread
From: Heiko Carstens @ 2006-08-14 7:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: Martin Schwidefsky, Christoph Lameter, linux-kernel
From: Heiko Carstens <heiko.carstens@de.ibm.com>
s390 doesn't support CONFIG_HIGHMEM. Anything that depends on it would be
dead code.
Cc: Christoph Lameter <clameter@engr.sgi.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
Probably should be merged with
reduce-max_nr_zones-remove-display-of-counters-for-unconfigured-zones-s390-fix.patch
arch/s390/appldata/appldata_mem.c | 3 ---
1 files changed, 3 deletions(-)
Index: linux-2.6.18-rc4-mm1/arch/s390/appldata/appldata_mem.c
===================================================================
--- linux-2.6.18-rc4-mm1.orig/arch/s390/appldata/appldata_mem.c 2006-08-14 08:35:16.000000000 +0200
+++ linux-2.6.18-rc4-mm1/arch/s390/appldata/appldata_mem.c 2006-08-14 08:36:18.000000000 +0200
@@ -118,9 +118,6 @@
mem_data->pswpin = ev[PSWPIN];
mem_data->pswpout = ev[PSWPOUT];
mem_data->pgalloc = ev[PGALLOC_NORMAL] + ev[PGALLOC_DMA];
-#ifdef CONFIG_HIGHMEM
- mem_data->pgalloc += ev[PGALLOC_HIGH];
-#endif
mem_data->pgfault = ev[PGFAULT];
mem_data->pgmajfault = ev[PGMAJFAULT];
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (18 preceding siblings ...)
2006-08-14 7:00 ` [patch -mm] s390: remove HIGHMEM dependencies Heiko Carstens
@ 2006-08-14 14:02 ` Michal Piotrowski
2006-08-14 18:19 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-14 14:38 ` 2.6.18-rc4-mm1: eth0: trigger_send() called with the transmitter busy Laurent Riffard
` (9 subsequent siblings)
29 siblings, 1 reply; 192+ messages in thread
From: Michal Piotrowski @ 2006-08-14 14:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
paging request at virtual address fffeffbf
Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
Aug 14 15:35:10 ltg01-fedora kernel: c013d539
Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
/devices/platform/i2c-9191/9191-0290/temp2_input
Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
edstep_lib binfmt_misc thermal processor fan container evdev
snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
tainted VLI
Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
ecx: d3a1dfa2 edx: fffeffbf
Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
ebp: f4896f64 esp: f4896f40
Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
ti=f4896000 task=f3d180f0 task.ti=f4896000)
Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
00000001 0808c044 7fffffff bf8f35b0 f4896fb4
Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
00000000 bf8f3528 00000000 f4896fa8 00000000
Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 15:35:11 ltg01-fedora kernel: =======================
Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
Aug 14 15:35:11 ltg01-fedora kernel: <6>note: firefox-bin[2210]
exited with preempt_count 1
Aug 14 15:35:11 ltg01-fedora kernel: BUG: sleeping function called
from invalid context at /usr/src/linux-mm/mm/slab.c:2989
Aug 14 15:35:11 ltg01-fedora kernel: in_atomic():1, irqs_disabled():1
Aug 14 15:35:11 ltg01-fedora kernel: [<c0103e41>] dump_trace+0x70/0x176
Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fde>] show_trace+0xd/0xf
Aug 14 15:35:11 ltg01-fedora kernel: [<c01040b0>] dump_stack+0x17/0x19
Aug 14 15:35:11 ltg01-fedora kernel: [<c011ec0c>] __might_sleep+0x92/0x9a
Aug 14 15:35:11 ltg01-fedora kernel: [<c01731ba>] kmem_cache_zalloc+0x27/0xe7
Aug 14 15:35:11 ltg01-fedora kernel: [<c0154b73>]
taskstats_exit_alloc+0x30/0x6e
Aug 14 15:35:11 ltg01-fedora kernel: [<c012455e>] do_exit+0x1a3/0x5cd
Aug 14 15:35:11 ltg01-fedora kernel: [<c0104515>] die+0x1e8/0x1f0
Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
Aug 14 15:35:11 ltg01-fedora kernel: [<c013d539>] futex_wake+0x9c/0xcb
Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
Aug 14 15:35:12 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
Aug 14 15:35:12 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 15:35:12 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
Aug 14 15:35:12 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 15:35:12 ltg01-fedora kernel: [<c0103fde>] show_trace+0xd/0xf
Aug 14 15:35:12 ltg01-fedora kernel: [<c01040b0>] dump_stack+0x17/0x19
Aug 14 15:35:12 ltg01-fedora kernel: [<c011ec0c>] __might_sleep+0x92/0x9a
Aug 14 15:35:12 ltg01-fedora kernel: [<c01731ba>] kmem_cache_zalloc+0x27/0xe7
Aug 14 15:35:12 ltg01-fedora kernel: [<c0154b73>]
taskstats_exit_alloc+0x30/0x6e
Aug 14 15:35:12 ltg01-fedora kernel: [<c012455e>] do_exit+0x1a3/0x5cd
Aug 14 15:35:12 ltg01-fedora kernel: [<c0104515>] die+0x1e8/0x1f0
Aug 14 15:35:12 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
Aug 14 15:35:12 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
Aug 14 15:35:12 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
Aug 14 15:35:12 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
Aug 14 15:35:12 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 15:35:12 ltg01-fedora kernel: =======================
Aug 14 15:35:20 ltg01-fedora kernel: BUG: soft lockup detected on CPU#0!
Aug 14 15:35:20 ltg01-fedora kernel: [<c0103e41>] dump_trace+0x70/0x176
Aug 14 15:35:20 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 15:35:20 ltg01-fedora kernel: [<c0103fde>] show_trace+0xd/0xf
Aug 14 15:35:20 ltg01-fedora kernel: [<c01040b0>] dump_stack+0x17/0x19
Aug 14 15:35:20 ltg01-fedora kernel: [<c0150ff3>] softlockup_tick+0xca/0xde
Aug 14 15:35:20 ltg01-fedora kernel: [<c012ad52>] run_local_timers+0x12/0x14
Aug 14 15:35:20 ltg01-fedora kernel: [<c012abaa>]
update_process_times+0x40/0x65
Aug 14 15:35:20 ltg01-fedora kernel: [<c0113989>]
smp_apic_timer_interrupt+0x6d/0x75
Aug 14 15:35:20 ltg01-fedora kernel: [<c0103c5a>]
apic_timer_interrupt+0x2a/0x30
Aug 14 15:35:20 ltg01-fedora kernel: [<c01f81c3>] delay_tsc+0xe/0x17
Aug 14 15:35:20 ltg01-fedora kernel: [<c01f8200>] __delay+0x9/0xb
Aug 14 15:35:20 ltg01-fedora kernel: [<c0204aed>] __spin_lock_debug+0x46/0x94
Aug 14 15:35:20 ltg01-fedora kernel: [<c0204be3>] _raw_spin_lock+0xa8/0xbe
Aug 14 15:35:20 ltg01-fedora kernel: [<c030359c>] _spin_lock+0x2a/0x2f
Aug 14 15:35:20 ltg01-fedora kernel: [<c013d4f3>] futex_wake+0x56/0xcb
Aug 14 15:35:20 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
Aug 14 15:35:20 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
Aug 14 15:35:20 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 15:35:20 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
Aug 14 15:35:20 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 15:35:20 ltg01-fedora kernel: [<c0103fde>] show_trace+0xd/0xf
Aug 14 15:35:21 ltg01-fedora kernel: [<c01040b0>] dump_stack+0x17/0x19
Aug 14 15:35:21 ltg01-fedora kernel: [<c0150ff3>] softlockup_tick+0xca/0xde
Aug 14 15:35:21 ltg01-fedora kernel: [<c012ad52>] run_local_timers+0x12/0x14
Aug 14 15:35:21 ltg01-fedora kernel: [<c012abaa>]
update_process_times+0x40/0x65
Aug 14 15:35:21 ltg01-fedora kernel: [<c0113989>]
smp_apic_timer_interrupt+0x6d/0x75
Aug 14 15:35:21 ltg01-fedora kernel: [<c0103c5a>]
apic_timer_interrupt+0x2a/0x30
Aug 14 15:35:21 ltg01-fedora kernel: [<c01f8200>] __delay+0x9/0xb
Aug 14 15:35:21 ltg01-fedora kernel: [<c0204aed>] __spin_lock_debug+0x46/0x94
Aug 14 15:35:21 ltg01-fedora kernel: [<c0204be3>] _raw_spin_lock+0xa8/0xbe
Aug 14 15:35:21 ltg01-fedora kernel: [<c030359c>] _spin_lock+0x2a/0x2f
Aug 14 15:35:21 ltg01-fedora kernel: [<c013d4f3>] futex_wake+0x56/0xcb
Aug 14 15:35:21 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
Aug 14 15:35:21 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
Aug 14 15:35:21 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 15:35:21 ltg01-fedora kernel: =======================
0xc013d539 is in futex_wake (/usr/src/linux-mm/kernel/futex.c:671).
666
667 hb = hash_futex(&key);
668 spin_lock(&hb->lock);
669 head = &hb->chain;
670
671 list_for_each_entry_safe(this, next, head, list) {
672 if (match_futex (&this->key, &key)) {
673 if (this->pi_state) {
674 ret = -EINVAL;
675 break;
Here is a config file
http://www.stardust.webpages.pl/files/mm/2.6.18-rc4-mm1/frontline/mm-config
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-14 14:02 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 18:19 ` Andrew Morton
2006-08-14 19:01 ` 2.6.18-rc4-mm1 Michal Piotrowski
0 siblings, 1 reply; 192+ messages in thread
From: Andrew Morton @ 2006-08-14 18:19 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: linux-kernel, john stultz, Thomas Gleixner, Ingo Molnar
On Mon, 14 Aug 2006 16:02:52 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >
>
> Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
> paging request at virtual address fffeffbf
> Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
> Aug 14 15:35:10 ltg01-fedora kernel: c013d539
> Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
> Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
> Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
> Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
> /devices/platform/i2c-9191/9191-0290/temp2_input
> Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
> hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
> iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
> edstep_lib binfmt_misc thermal processor fan container evdev
> snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
> e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
> Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
> Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
> tainted VLI
> Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
> Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
> Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
> ecx: d3a1dfa2 edx: fffeffbf
> Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
> ebp: f4896f64 esp: f4896f40
> Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
> Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
> ti=f4896000 task=f3d180f0 task.ti=f4896000)
> Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
> f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
> Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
> 00000001 0808c044 7fffffff bf8f35b0 f4896fb4
> Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
> 00000000 bf8f3528 00000000 f4896fa8 00000000
> Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
> Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
> Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
> Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
> Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> Aug 14 15:35:11 ltg01-fedora kernel: =======================
> Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
> ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
> 16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
> 89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
> Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
> futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
This is worrisome. Is it reproducible? If so, reverting
futex_handle_fault-always-fails.patch and retesting would be useful.
(please kill the wordwrapping in your email client, btw).
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 18:19 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-14 19:01 ` Michal Piotrowski
2006-08-14 19:20 ` 2.6.18-rc4-mm1 john stultz
0 siblings, 1 reply; 192+ messages in thread
From: Michal Piotrowski @ 2006-08-14 19:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, john stultz, Thomas Gleixner, Ingo Molnar
Andrew Morton wrote:
> On Mon, 14 Aug 2006 16:02:52 +0200
> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
>> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>>>
>> Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
>> paging request at virtual address fffeffbf
>> Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
>> Aug 14 15:35:10 ltg01-fedora kernel: c013d539
>> Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
>> Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
>> Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
>> Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
>> Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
>> /devices/platform/i2c-9191/9191-0290/temp2_input
>> Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
>> hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
>> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
>> iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
>> edstep_lib binfmt_misc thermal processor fan container evdev
>> snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
>> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
>> snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
>> e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
>> Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
>> Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
>> tainted VLI
>> Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
>> Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
>> Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
>> ecx: d3a1dfa2 edx: fffeffbf
>> Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
>> ebp: f4896f64 esp: f4896f40
>> Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
>> Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
>> ti=f4896000 task=f3d180f0 task.ti=f4896000)
>> Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
>> f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
>> Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
>> 00000001 0808c044 7fffffff bf8f35b0 f4896fb4
>> Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
>> 00000000 bf8f3528 00000000 f4896fa8 00000000
>> Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
>> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
>> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
>> Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
>> Aug 14 15:35:11 ltg01-fedora kernel: =======================
>> Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
>> ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
>> 16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
>> 89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
>> Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
>> futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
>
> This is worrisome. Is it reproducible?
I don't know how to reproduce it, but it happened second time today.
> If so, reverting
> futex_handle_fault-always-fails.patch and retesting would be useful.
I reverted this patch.
>
> (please kill the wordwrapping in your email client, btw).
>
>
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 19:01 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 19:20 ` john stultz
2006-08-14 19:27 ` 2.6.18-rc4-mm1 Michal Piotrowski
0 siblings, 1 reply; 192+ messages in thread
From: john stultz @ 2006-08-14 19:20 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Andrew Morton, linux-kernel, Thomas Gleixner, Ingo Molnar,
Dinakar Guniguntala
On Mon, 2006-08-14 at 21:01 +0200, Michal Piotrowski wrote:
> Andrew Morton wrote:
> > On Mon, 14 Aug 2006 16:02:52 +0200
> > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> >> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >>>
> >> Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
> >> paging request at virtual address fffeffbf
> >> Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
> >> Aug 14 15:35:10 ltg01-fedora kernel: c013d539
> >> Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
> >> Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
> >> Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
> >> Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> >> Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
> >> /devices/platform/i2c-9191/9191-0290/temp2_input
> >> Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
> >> hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> >> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
> >> iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
> >> edstep_lib binfmt_misc thermal processor fan container evdev
> >> snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
> >> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> >> snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
> >> e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
> >> Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
> >> Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
> >> tainted VLI
> >> Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
> >> Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
> >> Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
> >> ecx: d3a1dfa2 edx: fffeffbf
> >> Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
> >> ebp: f4896f64 esp: f4896f40
> >> Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
> >> Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
> >> ti=f4896000 task=f3d180f0 task.ti=f4896000)
> >> Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
> >> f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
> >> Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
> >> 00000001 0808c044 7fffffff bf8f35b0 f4896fb4
> >> Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
> >> 00000000 bf8f3528 00000000 f4896fa8 00000000
> >> Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
> >> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> >> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> >> Aug 14 15:35:11 ltg01-fedora kernel: =======================
> >> Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
> >> ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
> >> 16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
> >> 89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
> >> Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
> >> futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
> >
> > This is worrisome. Is it reproducible?
>
> I don't know how to reproduce it, but it happened second time today.
>
> > If so, reverting
> > futex_handle_fault-always-fails.patch and retesting would be useful.
>
> I reverted this patch.
Just to be clear, the issue has shown itself without the patch? Or is
that not the case?
thanks
-john
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 19:20 ` 2.6.18-rc4-mm1 john stultz
@ 2006-08-14 19:27 ` Michal Piotrowski
2006-08-14 19:44 ` 2.6.18-rc4-mm1 john stultz
0 siblings, 1 reply; 192+ messages in thread
From: Michal Piotrowski @ 2006-08-14 19:27 UTC (permalink / raw)
To: john stultz
Cc: Andrew Morton, linux-kernel, Thomas Gleixner, Ingo Molnar,
Dinakar Guniguntala
On 14/08/06, john stultz <johnstul@us.ibm.com> wrote:
> On Mon, 2006-08-14 at 21:01 +0200, Michal Piotrowski wrote:
> > Andrew Morton wrote:
> > > On Mon, 14 Aug 2006 16:02:52 +0200
> > > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> > >> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
> > >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> > >>>
> > >> Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
> > >> paging request at virtual address fffeffbf
> > >> Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
> > >> Aug 14 15:35:10 ltg01-fedora kernel: c013d539
> > >> Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
> > >> Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
> > >> Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
> > >> Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> > >> Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
> > >> /devices/platform/i2c-9191/9191-0290/temp2_input
> > >> Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
> > >> hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> > >> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
> > >> iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
> > >> edstep_lib binfmt_misc thermal processor fan container evdev
> > >> snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
> > >> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> > >> snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
> > >> e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
> > >> Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
> > >> Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
> > >> tainted VLI
> > >> Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
> > >> Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
> > >> Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
> > >> ecx: d3a1dfa2 edx: fffeffbf
> > >> Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
> > >> ebp: f4896f64 esp: f4896f40
> > >> Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
> > >> Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
> > >> ti=f4896000 task=f3d180f0 task.ti=f4896000)
> > >> Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
> > >> f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
> > >> Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
> > >> 00000001 0808c044 7fffffff bf8f35b0 f4896fb4
> > >> Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
> > >> 00000000 bf8f3528 00000000 f4896fa8 00000000
> > >> Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
> > >> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> > >> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> > >> Aug 14 15:35:11 ltg01-fedora kernel: =======================
> > >> Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
> > >> ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
> > >> 16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
> > >> 89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
> > >> Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
> > >> futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
> > >
> > > This is worrisome. Is it reproducible?
> >
> > I don't know how to reproduce it, but it happened second time today.
> >
> > > If so, reverting
> > > futex_handle_fault-always-fails.patch and retesting would be useful.
> >
> > I reverted this patch.
>
> Just to be clear, the issue has shown itself without the patch?
No, it hasn't.
> Or is
> that not the case?
In current -mm only futex_handle_fault-always-fails.patch changes
kernel/futex.c, so IMHO it's very probable that there is something
wrong with this patch.
>
> thanks
> -john
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 19:27 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 19:44 ` john stultz
2006-08-14 20:48 ` 2.6.18-rc4-mm1 Michal Piotrowski
0 siblings, 1 reply; 192+ messages in thread
From: john stultz @ 2006-08-14 19:44 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Andrew Morton, linux-kernel, Thomas Gleixner, Ingo Molnar,
Dinakar Guniguntala
On Mon, 2006-08-14 at 21:27 +0200, Michal Piotrowski wrote:
> On 14/08/06, john stultz <johnstul@us.ibm.com> wrote:
> > On Mon, 2006-08-14 at 21:01 +0200, Michal Piotrowski wrote:
> > > Andrew Morton wrote:
> > > > On Mon, 14 Aug 2006 16:02:52 +0200
> > > > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> > > >> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
> > > >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> > > >>>
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
> > > >> paging request at virtual address fffeffbf
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: c013d539
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
> > > >> /devices/platform/i2c-9191/9191-0290/temp2_input
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
> > > >> hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> > > >> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
> > > >> iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
> > > >> edstep_lib binfmt_misc thermal processor fan container evdev
> > > >> snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
> > > >> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> > > >> snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
> > > >> e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
> > > >> tainted VLI
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
> > > >> ecx: d3a1dfa2 edx: fffeffbf
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
> > > >> ebp: f4896f64 esp: f4896f40
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
> > > >> ti=f4896000 task=f3d180f0 task.ti=f4896000)
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
> > > >> f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
> > > >> 00000001 0808c044 7fffffff bf8f35b0 f4896fb4
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
> > > >> 00000000 bf8f3528 00000000 f4896fa8 00000000
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: =======================
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
> > > >> ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
> > > >> 16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
> > > >> 89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
> > > >> futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
> > > >
> > > > This is worrisome. Is it reproducible?
> > >
> > > I don't know how to reproduce it, but it happened second time today.
> > >
> > > > If so, reverting
> > > > futex_handle_fault-always-fails.patch and retesting would be useful.
> > >
> > > I reverted this patch.
> >
> > Just to be clear, the issue has shown itself without the patch?
>
> No, it hasn't.
Thanks for the clarification.
> > Or is
> > that not the case?
>
> In current -mm only futex_handle_fault-always-fails.patch changes
> kernel/futex.c, so IMHO it's very probable that there is something
> wrong with this patch.
Yea, I'd believe that. I'm newish to the futex code, and as I said w/
the patch I'm not 100% sure its the right fix, but it does resolve an
issue we found.
I'll take another look to see if I futzed something up or if the fix is
just incomplete, although some more familiar eyes with the code would
probably help here.
thanks
-john
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 19:44 ` 2.6.18-rc4-mm1 john stultz
@ 2006-08-14 20:48 ` Michal Piotrowski
2006-08-14 20:56 ` 2.6.18-rc4-mm1 Dave Jones
0 siblings, 1 reply; 192+ messages in thread
From: Michal Piotrowski @ 2006-08-14 20:48 UTC (permalink / raw)
To: john stultz
Cc: Andrew Morton, linux-kernel, Thomas Gleixner, Ingo Molnar,
Dinakar Guniguntala, Dave Jones
john stultz wrote:
> On Mon, 2006-08-14 at 21:27 +0200, Michal Piotrowski wrote:
>> On 14/08/06, john stultz <johnstul@us.ibm.com> wrote:
>>> On Mon, 2006-08-14 at 21:01 +0200, Michal Piotrowski wrote:
>>>> Andrew Morton wrote:
>>>>> On Mon, 14 Aug 2006 16:02:52 +0200
>>>>> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>>>>>> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
>>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>>>>>>>
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
>>>>>> paging request at virtual address fffeffbf
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: c013d539
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
>>>>>> /devices/platform/i2c-9191/9191-0290/temp2_input
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
>>>>>> hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
>>>>>> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
>>>>>> iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
>>>>>> edstep_lib binfmt_misc thermal processor fan container evdev
>>>>>> snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
>>>>>> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
>>>>>> snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
>>>>>> e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
>>>>>> tainted VLI
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
>>>>>> ecx: d3a1dfa2 edx: fffeffbf
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
>>>>>> ebp: f4896f64 esp: f4896f40
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
>>>>>> ti=f4896000 task=f3d180f0 task.ti=f4896000)
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
>>>>>> f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
>>>>>> 00000001 0808c044 7fffffff bf8f35b0 f4896fb4
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
>>>>>> 00000000 bf8f3528 00000000 f4896fa8 00000000
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: =======================
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
>>>>>> ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
>>>>>> 16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
>>>>>> 89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
>>>>>> futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
>>>>> This is worrisome. Is it reproducible?
>>>> I don't know how to reproduce it, but it happened second time today.
>>>>
>>>>> If so, reverting
>>>>> futex_handle_fault-always-fails.patch and retesting would be useful.
>>>> I reverted this patch.
>>> Just to be clear, the issue has shown itself without the patch?
>> No, it hasn't.
>
> Thanks for the clarification.
>
>>> Or is
>>> that not the case?
>> In current -mm only futex_handle_fault-always-fails.patch changes
>> kernel/futex.c, so IMHO it's very probable that there is something
>> wrong with this patch.
>
> Yea, I'd believe that. I'm newish to the futex code, and as I said w/
> the patch I'm not 100% sure its the right fix, but it does resolve an
> issue we found.
>
> I'll take another look to see if I futzed something up or if the fix is
> just incomplete, although some more familiar eyes with the code would
> probably help here.
>
Hmmm... It looks a bit different without futex_handle_fault-always-fails.patch
Aug 14 22:30:09 ltg01-fedora kernel: general protection fault: 0000 [#1]
Aug 14 22:30:09 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
Aug 14 22:30:09 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
Aug 14 22:30:09 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
edstep_lib binfmt_misc thermal processor fan container evdev snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm sk98lin skge snd_timer snd soundcore snd_pag
e_alloc ide_cd i2c_i801 intel_agp agpgart cdrom rtc unix
Aug 14 22:30:09 ltg01-fedora kernel: CPU: 0
Aug 14 22:30:09 ltg01-fedora kernel: EIP: 0060:[<c0205249>] Not tainted VLI
Aug 14 22:30:09 ltg01-fedora kernel: EFLAGS: 00010246 (2.6.18-rc4-mm1 #101)
Aug 14 22:30:09 ltg01-fedora kernel: EIP is at __list_add+0x3d/0x7a
Aug 14 22:30:09 ltg01-fedora kernel: eax: 00000000 ebx: c0670a80 ecx: c038d4dc edx: 00000000
Aug 14 22:30:09 ltg01-fedora kernel: esi: ffffffff edi: f50ebee8 ebp: f50ebed0 esp: f50ebec4
Aug 14 22:30:09 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
Aug 14 22:30:09 ltg01-fedora kernel: Process thunderbird-bin (pid: 2288, ti=f50eb000 task=c75b9260 task.ti=f50eb000)
Aug 14 22:30:09 ltg01-fedora kernel: Stack: f50ebee8 080e7dc0 c0670a60 f50ebf64 c013de71 00000001 c75b9260 0000ea6b
Aug 14 22:30:10 ltg01-fedora kernel: 00000001 f50ebf20 c013adf0 00000001 00000000 dead4ead ffffffff ffffffff
Aug 14 22:30:10 ltg01-fedora kernel: c75b9260 00000000 00000000 f50ebf10 f50ebf10 c0670a60 080e7000 f3e65c94
Aug 14 22:30:10 ltg01-fedora kernel: Call Trace:
Aug 14 22:30:10 ltg01-fedora kernel: [<c013de71>] futex_wait+0x15c/0x220
Aug 14 22:30:10 ltg01-fedora kernel: [<c013ed17>] do_futex+0x33/0x92
Aug 14 22:30:10 ltg01-fedora kernel: [<c013ee6b>] sys_futex+0xf5/0x101
Aug 14 22:30:10 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 22:30:10 ltg01-fedora kernel: [<b7f12410>] 0xb7f12410
Aug 14 22:30:10 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 22:30:10 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
Aug 14 22:30:10 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
Aug 14 22:30:10 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
Aug 14 22:30:10 ltg01-fedora kernel: [<c0104c9f>] do_general_protection+0x1d1/0x1d9
Aug 14 22:30:10 ltg01-fedora kernel: [<c0303b89>] error_code+0x39/0x40
Aug 14 22:30:10 ltg01-fedora kernel: [<c013de71>] futex_wait+0x15c/0x220
Aug 14 22:30:10 ltg01-fedora kernel: [<c013ed17>] do_futex+0x33/0x92
Aug 14 22:30:10 ltg01-fedora kernel: [<c013ee6b>] sys_futex+0xf5/0x101
Aug 14 22:30:10 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 22:30:10 ltg01-fedora kernel: =======================
Aug 14 22:30:10 ltg01-fedora kernel: Code: cb 39 71 04 0f 95 c2 e8 12 0f 00 00 85 c0 74 19 ff 73 04 56 68 a1 89 33 c0 e8 97
ce f1 ff 0f 0b 1a 00 7e 89 33 c0 83 c4 0c 31 d2 <39> 1e b8 f8 d4 38 c0 0f 95 c2 e8 e4 0e 00 00 85 c0 74 18 ff 36
Aug 14 22:30:10 ltg01-fedora kernel: EIP: [<c0205249>] __list_add+0x3d/0x7a SS:ESP 0068:f50ebec4
Aug 14 22:30:10 ltg01-fedora kernel: <6>note: thunderbird-bin[2288] exited with preempt_count 1
Aug 14 22:30:10 ltg01-fedora kernel: BUG: sleeping function called from invalid context at /usr/src/linux-mm/mm/slab.c:2989
Aug 14 22:30:10 ltg01-fedora kernel: in_atomic():1, irqs_disabled():0
Aug 14 22:30:10 ltg01-fedora kernel: [<c0103e41>] dump_trace+0x70/0x176
Aug 14 22:30:10 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 22:30:10 ltg01-fedora kernel: [<c0103fde>] show_trace+0xd/0xf
Aug 14 22:30:10 ltg01-fedora kernel: [<c01040b0>] dump_stack+0x17/0x19
Aug 14 22:30:10 ltg01-fedora kernel: [<c011ec0c>] __might_sleep+0x92/0x9a
Aug 14 22:30:10 ltg01-fedora kernel: [<c017319e>] kmem_cache_zalloc+0x27/0xe7
Aug 14 22:30:11 ltg01-fedora kernel: [<c0154b57>] taskstats_exit_alloc+0x30/0x6e
Aug 14 22:30:11 ltg01-fedora kernel: [<c012455e>] do_exit+0x1a3/0x5cd
Aug 14 22:30:11 ltg01-fedora kernel: [<c0104515>] die+0x1e8/0x1f0
Aug 14 22:30:11 ltg01-fedora kernel: [<c0104c9f>] do_general_protection+0x1d1/0x1d9
Aug 14 22:30:11 ltg01-fedora kernel: [<c0303b89>] error_code+0x39/0x40
Aug 14 22:30:11 ltg01-fedora kernel: [<c0205249>] __list_add+0x3d/0x7a
Aug 14 22:30:11 ltg01-fedora kernel: [<c013de71>] futex_wait+0x15c/0x220
Aug 14 22:30:11 ltg01-fedora kernel: [<c013ed17>] do_futex+0x33/0x92
Aug 14 22:30:11 ltg01-fedora kernel: [<c013ee6b>] sys_futex+0xf5/0x101
Aug 14 22:30:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 22:30:11 ltg01-fedora kernel: [<b7f12410>] 0xb7f12410
Aug 14 22:30:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 22:30:11 ltg01-fedora kernel: [<c0103fde>] show_trace+0xd/0xf
Aug 14 22:30:11 ltg01-fedora kernel: [<c01040b0>] dump_stack+0x17/0x19
Aug 14 22:30:11 ltg01-fedora kernel: [<c011ec0c>] __might_sleep+0x92/0x9a
Aug 14 22:30:11 ltg01-fedora kernel: [<c017319e>] kmem_cache_zalloc+0x27/0xe7
Aug 14 22:30:11 ltg01-fedora kernel: [<c0154b57>] taskstats_exit_alloc+0x30/0x6e
Aug 14 22:30:11 ltg01-fedora kernel: [<c012455e>] do_exit+0x1a3/0x5cd
Aug 14 22:30:11 ltg01-fedora kernel: [<c0104515>] die+0x1e8/0x1f0
Aug 14 22:30:11 ltg01-fedora kernel: [<c0104c9f>] do_general_protection+0x1d1/0x1d9
Aug 14 22:30:11 ltg01-fedora kernel: [<c0303b89>] error_code+0x39/0x40
Aug 14 22:30:11 ltg01-fedora kernel: [<c013de71>] futex_wait+0x15c/0x220
Aug 14 22:30:11 ltg01-fedora kernel: [<c013ed17>] do_futex+0x33/0x92
Aug 14 22:30:11 ltg01-fedora kernel: [<c013ee6b>] sys_futex+0xf5/0x101
Aug 14 22:30:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 22:30:11 ltg01-fedora kernel: =======================
0xc0205249 is in __list_add (/usr/src/linux-mm/lib/list_debug.c:28).
23 if (unlikely(next->prev != prev)) {
24 printk("list_add corruption. next->prev should be %p, but was %p\n",
25 prev, next->prev);
26 BUG();
27 }
28 if (unlikely(prev->next != next)) {
29 printk("list_add corruption. prev->next should be %p, but was %p\n",
30 next, prev->next);
31 BUG();
32 }
I'll revert debug-variants-of-linked-list-macros.patch
> thanks
> -john
>
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-14 20:48 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 20:56 ` Dave Jones
2006-08-14 21:13 ` 2.6.18-rc4-mm1 Michal Piotrowski
0 siblings, 1 reply; 192+ messages in thread
From: Dave Jones @ 2006-08-14 20:56 UTC (permalink / raw)
To: Michal Piotrowski
Cc: john stultz, Andrew Morton, linux-kernel, Thomas Gleixner,
Ingo Molnar, Dinakar Guniguntala
On Mon, Aug 14, 2006 at 10:48:58PM +0200, Michal Piotrowski wrote:
>
> Hmmm... It looks a bit different without futex_handle_fault-always-fails.patch
>
> Aug 14 22:30:09 ltg01-fedora kernel: general protection fault: 0000 [#1]
> Aug 14 22:30:09 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> Aug 14 22:30:09 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
> Aug 14 22:30:09 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
> edstep_lib binfmt_misc thermal processor fan container evdev snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm sk98lin skge snd_timer snd soundcore snd_pag
> e_alloc ide_cd i2c_i801 intel_agp agpgart cdrom rtc unix
> Aug 14 22:30:09 ltg01-fedora kernel: CPU: 0
> Aug 14 22:30:09 ltg01-fedora kernel: EIP: 0060:[<c0205249>] Not tainted VLI
> Aug 14 22:30:09 ltg01-fedora kernel: EFLAGS: 00010246 (2.6.18-rc4-mm1 #101)
> Aug 14 22:30:09 ltg01-fedora kernel: EIP is at __list_add+0x3d/0x7a
...
> 0xc0205249 is in __list_add (/usr/src/linux-mm/lib/list_debug.c:28).
> 23 if (unlikely(next->prev != prev)) {
> 24 printk("list_add corruption. next->prev should be %p, but was %p\n",
> 25 prev, next->prev);
> 26 BUG();
> 27 }
> 28 if (unlikely(prev->next != next)) {
> 29 printk("list_add corruption. prev->next should be %p, but was %p\n",
> 30 next, prev->next);
> 31 BUG();
> 32 }
>
> I'll revert debug-variants-of-linked-list-macros.patch
__list_add will still be dereferencing prev->next, so you should see exactly
the same gpf. Note that you're not triggering the BUG()'s here, you're hitting
some other fault just walking the list.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-14 20:56 ` 2.6.18-rc4-mm1 Dave Jones
@ 2006-08-14 21:13 ` Michal Piotrowski
2006-08-14 21:20 ` 2.6.18-rc4-mm1 Dave Jones
0 siblings, 1 reply; 192+ messages in thread
From: Michal Piotrowski @ 2006-08-14 21:13 UTC (permalink / raw)
To: Dave Jones, Michal Piotrowski, john stultz, Andrew Morton,
linux-kernel, Thomas Gleixner, Ingo Molnar, Dinakar Guniguntala
On 14/08/06, Dave Jones <davej@redhat.com> wrote:
> On Mon, Aug 14, 2006 at 10:48:58PM +0200, Michal Piotrowski wrote:
> >
> > Hmmm... It looks a bit different without futex_handle_fault-always-fails.patch
> >
> > Aug 14 22:30:09 ltg01-fedora kernel: general protection fault: 0000 [#1]
> > Aug 14 22:30:09 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> > Aug 14 22:30:09 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
> > Aug 14 22:30:09 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> > _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
> > edstep_lib binfmt_misc thermal processor fan container evdev snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
> > oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm sk98lin skge snd_timer snd soundcore snd_pag
> > e_alloc ide_cd i2c_i801 intel_agp agpgart cdrom rtc unix
> > Aug 14 22:30:09 ltg01-fedora kernel: CPU: 0
> > Aug 14 22:30:09 ltg01-fedora kernel: EIP: 0060:[<c0205249>] Not tainted VLI
> > Aug 14 22:30:09 ltg01-fedora kernel: EFLAGS: 00010246 (2.6.18-rc4-mm1 #101)
> > Aug 14 22:30:09 ltg01-fedora kernel: EIP is at __list_add+0x3d/0x7a
>
> ...
>
> > 0xc0205249 is in __list_add (/usr/src/linux-mm/lib/list_debug.c:28).
> > 23 if (unlikely(next->prev != prev)) {
> > 24 printk("list_add corruption. next->prev should be %p, but was %p\n",
> > 25 prev, next->prev);
> > 26 BUG();
> > 27 }
> > 28 if (unlikely(prev->next != next)) {
> > 29 printk("list_add corruption. prev->next should be %p, but was %p\n",
> > 30 next, prev->next);
> > 31 BUG();
> > 32 }
> >
> > I'll revert debug-variants-of-linked-list-macros.patch
>
> __list_add will still be dereferencing prev->next, so you should see exactly
> the same gpf. Note that you're not triggering the BUG()'s here, you're hitting
> some other fault just walking the list.
How can I debug this?
>
> Dave
>
> --
> http://www.codemonkey.org.uk
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-14 21:13 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 21:20 ` Dave Jones
2006-08-14 22:08 ` 2.6.18-rc4-mm1 Michal Piotrowski
0 siblings, 1 reply; 192+ messages in thread
From: Dave Jones @ 2006-08-14 21:20 UTC (permalink / raw)
To: Michal Piotrowski
Cc: john stultz, Andrew Morton, linux-kernel, Thomas Gleixner,
Ingo Molnar, Dinakar Guniguntala
On Mon, Aug 14, 2006 at 11:13:14PM +0200, Michal Piotrowski wrote:
> On 14/08/06, Dave Jones <davej@redhat.com> wrote:
> > > Aug 14 22:30:09 ltg01-fedora kernel: general protection fault: 0000 [#1]
> > > Aug 14 22:30:09 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> > > Aug 14 22:30:09 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
> > > Aug 14 22:30:09 ltg01-fedora kernel: CPU: 0
> > > Aug 14 22:30:09 ltg01-fedora kernel: EIP: 0060:[<c0205249>] Not tainted VLI
> > > Aug 14 22:30:09 ltg01-fedora kernel: EFLAGS: 00010246 (2.6.18-rc4-mm1 #101)
> > > Aug 14 22:30:09 ltg01-fedora kernel: EIP is at __list_add+0x3d/0x7a
> > > Aug 14 22:30:09 ltg01-fedora kernel: eax: 00000000 ebx: c0670a80 ecx: c038d4dc edx: 00000000
> > > Aug 14 22:30:09 ltg01-fedora kernel: esi: ffffffff edi: f50ebee8 ebp: f50ebed0 esp: f50ebec4
> >
> > __list_add will still be dereferencing prev->next, so you should see exactly
> > the same gpf. Note that you're not triggering the BUG()'s here, you're hitting
> > some other fault just walking the list.
>
> How can I debug this?
Not sure. I'm somewhat puzzled.
Disassembling the Code: of your oops shows that we were trying to dereference esi,
which was -1 for some bizarre reason. (my objdump really hated disassembling that
function, but I think thats my tools rather than breakage in the oops).
Question is how did that list member get to be -1 ?
One pie-in-the-sky possibility is that we've corrupted memory recently, and
this link-list manipulation just stumbled across it. Note that the last file
opened before we blew up was reading i2c. Can you try and reproduce this
(if you can reproduce it at all) without the sensors stuff loaded ?
It's a long-shot, but without further clues, I'm stabbing in the dark.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 21:20 ` 2.6.18-rc4-mm1 Dave Jones
@ 2006-08-14 22:08 ` Michal Piotrowski
0 siblings, 0 replies; 192+ messages in thread
From: Michal Piotrowski @ 2006-08-14 22:08 UTC (permalink / raw)
To: Dave Jones, Michal Piotrowski, john stultz, Andrew Morton,
linux-kernel, Thomas Gleixner, Ingo Molnar, Dinakar Guniguntala
Dave Jones wrote:
> On Mon, Aug 14, 2006 at 11:13:14PM +0200, Michal Piotrowski wrote:
> > On 14/08/06, Dave Jones <davej@redhat.com> wrote:
> > > > Aug 14 22:30:09 ltg01-fedora kernel: general protection fault: 0000 [#1]
> > > > Aug 14 22:30:09 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> > > > Aug 14 22:30:09 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
> > > > Aug 14 22:30:09 ltg01-fedora kernel: CPU: 0
> > > > Aug 14 22:30:09 ltg01-fedora kernel: EIP: 0060:[<c0205249>] Not tainted VLI
> > > > Aug 14 22:30:09 ltg01-fedora kernel: EFLAGS: 00010246 (2.6.18-rc4-mm1 #101)
> > > > Aug 14 22:30:09 ltg01-fedora kernel: EIP is at __list_add+0x3d/0x7a
> > > > Aug 14 22:30:09 ltg01-fedora kernel: eax: 00000000 ebx: c0670a80 ecx: c038d4dc edx: 00000000
> > > > Aug 14 22:30:09 ltg01-fedora kernel: esi: ffffffff edi: f50ebee8 ebp: f50ebed0 esp: f50ebec4
> > >
> > > __list_add will still be dereferencing prev->next, so you should see exactly
> > > the same gpf. Note that you're not triggering the BUG()'s here, you're hitting
> > > some other fault just walking the list.
> >
> > How can I debug this?
>
> Not sure. I'm somewhat puzzled.
> Disassembling the Code: of your oops shows that we were trying to dereference esi,
> which was -1 for some bizarre reason. (my objdump really hated disassembling that
> function, but I think thats my tools rather than breakage in the oops).
>
> Question is how did that list member get to be -1 ?
> One pie-in-the-sky possibility is that we've corrupted memory recently, and
> this link-list manipulation just stumbled across it. Note that the last file
> opened before we blew up was reading i2c.
Or cpufreq
Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
Aug 14 15:39:12 ltg01-fedora kernel: last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_setspeed
Aug 14 22:30:09 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
I haven't seen this bug on previous (2006-08-08) mm snapshot. Here are new i2c patches
apple-motion-sensor-driver-kconfig-fix.patch
kill-include-linux-configh.patch - it's my patch, I'm testing it for tree days.
Aug 14 15:35:11 ltg01-fedora kernel: <6>note: firefox-bin[2210] exited with preempt_count 1
Aug 14 15:39:13 ltg01-fedora kernel: <6>note: sendmail[1719] exited with preempt_count 1
Aug 14 22:30:10 ltg01-fedora kernel: <6>note: thunderbird-bin[2288] exited with preempt_count 1
Is it possible that this is a problem with net stack?
Binary search will take ages - I don't know how to reproduce this bug.
> Can you try and reproduce this
> (if you can reproduce it at all) without the sensors stuff loaded ?
>
> It's a long-shot, but without further clues, I'm stabbing in the dark.
>
> Dave
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1: eth0: trigger_send() called with the transmitter busy
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (19 preceding siblings ...)
2006-08-14 14:02 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 14:38 ` Laurent Riffard
2006-08-14 16:50 ` Andrew Morton
2006-08-14 15:11 ` [-mm PATCH] ioremap: fixed MIPS build error Yoichi Yuasa
` (8 subsequent siblings)
29 siblings, 1 reply; 192+ messages in thread
From: Laurent Riffard @ 2006-08-14 14:38 UTC (permalink / raw)
To: Andrew Morton, Kernel development list, netdev
[-- Attachment #1: Type: text/plain, Size: 656 bytes --]
Le 13.08.2006 10:24, Andrew Morton a écrit :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
Hello,
This morning, while trying to suspend to disk, my box started to loop
displaying the following message:
eth0: trigger_send() called with the transmitter busy.
Here is the scenario. I booted 2.6.18-rc4-mm1 with this command line:
root=/dev/vglinux1/lvroot video=vesafb:ywrap,mtrr splash=silent resume=/dev/hdb7 netconsole=@192.163.0.3/,@192.168.0.1/00:0E:9B:91:ED:72 init 1
Then I issued:
# echo 6 > /proc/sys/kernel/printk
# echo disk > /sys/power/state
I attached my .config and a dmesg output.
~~
laurent
[-- Attachment #2: dmesg-before-suspend --]
[-- Type: text/plain, Size: 23133 bytes --]
Linux version 2.6.18-rc4-mm1 (laurent@antares.localdomain) (gcc version 4.1.1 20060724 (prerelease) (4.1.1-3mdk)) #92 Sun Aug 13 18:43:54 CEST 2006
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 000000000009fc00 end: 000000000009fc00 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000000009fc00 size: 0000000000000400 end: 00000000000a0000 type: 2
copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2
copy_e820_map() start: 0000000000100000 size: 000000001feec000 end: 000000001ffec000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000001ffec000 size: 0000000000003000 end: 000000001ffef000 type: 3
copy_e820_map() start: 000000001ffef000 size: 0000000000010000 end: 000000001ffff000 type: 2
copy_e820_map() start: 000000001ffff000 size: 0000000000001000 end: 0000000020000000 type: 4
copy_e820_map() start: 00000000ffff0000 size: 0000000000010000 end: 0000000100000000 type: 2
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001ffec000 (usable)
BIOS-e820: 000000001ffec000 - 000000001ffef000 (ACPI data)
BIOS-e820: 000000001ffef000 - 000000001ffff000 (reserved)
BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
On node 0 totalpages: 131052
DMA zone: 4096 pages, LIFO batch:0
Normal zone: 126956 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v000 ASUS ) @ 0x000f6a80
ACPI: RSDT (v001 ASUS A7V133-C 0x30303031 MSFT 0x31313031) @ 0x1ffec000
ACPI: FADT (v001 ASUS A7V133-C 0x30303031 MSFT 0x31313031) @ 0x1ffec080
ACPI: BOOT (v001 ASUS A7V133-C 0x30303031 MSFT 0x31313031) @ 0x1ffec040
ACPI: DSDT (v001 ASUS A7V133-C 0x00001000 MSFT 0x0100000b) @ 0x00000000
ACPI: PM-Timer IO Port: 0xe408
Allocating PCI resources starting at 30000000 (gap: 20000000:dfff0000)
Detected 1410.226 MHz processor.
Built 1 zonelists. Total pages: 131052
Kernel command line: root=/dev/vglinux1/lvroot video=vesafb:ywrap,mtrr splash=silent resume=/dev/hdb7 netconsole=@192.163.0.3/,@192.168.0.1/00:0E:9B:91:ED:72 init 1
netconsole: local port 6665
netconsole: local IP 192.163.0.3
netconsole: interface eth0
netconsole: remote port 6666
netconsole: remote IP 192.168.0.1
netconsole: remote ethernet address 00:0e:9b:91:ed:72
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (01407000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour VGA+ 80x25
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024
... MAX_LOCKDEP_ENTRIES: 8192
... MAX_LOCKDEP_CHAINS: 8192
... CHAINHASH_SIZE: 4096
memory used by lock dependency info: 904 kB
per task-struct memory footprint: 1200 bytes
------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
| spin |wlock |rlock |mutex | wsem | rsem |
--------------------------------------------------------------------------
A-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-B-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok |
A-B-B-C-C-D-D-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-C-D-B-D-D-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-C-D-B-C-D-A deadlock: ok | ok | ok | ok | ok | ok |
double unlock: ok | ok | ok | ok | ok | ok |
initialize held: ok | ok | ok | ok | ok | ok |
bad unlock order: ok | ok | ok | ok | ok | ok |
--------------------------------------------------------------------------
recursive read-lock: | ok | | ok |
recursive read-lock #2: | ok | | ok |
mixed read-write-lock: | ok | | ok |
mixed write-read-lock: | ok | | ok |
--------------------------------------------------------------------------
hard-irqs-on + irq-safe-A/12: ok | ok | ok |
soft-irqs-on + irq-safe-A/12: ok | ok | ok |
hard-irqs-on + irq-safe-A/21: ok | ok | ok |
soft-irqs-on + irq-safe-A/21: ok | ok | ok |
sirq-safe-A => hirqs-on/12: ok | ok | ok |
sirq-safe-A => hirqs-on/21: ok | ok | ok |
hard-safe-A + irqs-on/12: ok | ok | ok |
soft-safe-A + irqs-on/12: ok | ok | ok |
hard-safe-A + irqs-on/21: ok | ok | ok |
soft-safe-A + irqs-on/21: ok | ok | ok |
hard-safe-A + unsafe-B #1/123: ok | ok | ok |
soft-safe-A + unsafe-B #1/123: ok | ok | ok |
hard-safe-A + unsafe-B #1/132: ok | ok | ok |
soft-safe-A + unsafe-B #1/132: ok | ok | ok |
hard-safe-A + unsafe-B #1/213: ok | ok | ok |
soft-safe-A + unsafe-B #1/213: ok | ok | ok |
hard-safe-A + unsafe-B #1/231: ok | ok | ok |
soft-safe-A + unsafe-B #1/231: ok | ok | ok |
hard-safe-A + unsafe-B #1/312: ok | ok | ok |
soft-safe-A + unsafe-B #1/312: ok | ok | ok |
hard-safe-A + unsafe-B #1/321: ok | ok | ok |
soft-safe-A + unsafe-B #1/321: ok | ok | ok |
hard-safe-A + unsafe-B #2/123: ok | ok | ok |
soft-safe-A + unsafe-B #2/123: ok | ok | ok |
hard-safe-A + unsafe-B #2/132: ok | ok | ok |
soft-safe-A + unsafe-B #2/132: ok | ok | ok |
hard-safe-A + unsafe-B #2/213: ok | ok | ok |
soft-safe-A + unsafe-B #2/213: ok | ok | ok |
hard-safe-A + unsafe-B #2/231: ok | ok | ok |
soft-safe-A + unsafe-B #2/231: ok | ok | ok |
hard-safe-A + unsafe-B #2/312: ok | ok | ok |
soft-safe-A + unsafe-B #2/312: ok | ok | ok |
hard-safe-A + unsafe-B #2/321: ok | ok | ok |
soft-safe-A + unsafe-B #2/321: ok | ok | ok |
hard-irq lock-inversion/123: ok | ok | ok |
soft-irq lock-inversion/123: ok | ok | ok |
hard-irq lock-inversion/132: ok | ok | ok |
soft-irq lock-inversion/132: ok | ok | ok |
hard-irq lock-inversion/213: ok | ok | ok |
soft-irq lock-inversion/213: ok | ok | ok |
hard-irq lock-inversion/231: ok | ok | ok |
soft-irq lock-inversion/231: ok | ok | ok |
hard-irq lock-inversion/312: ok | ok | ok |
soft-irq lock-inversion/312: ok | ok | ok |
hard-irq lock-inversion/321: ok | ok | ok |
soft-irq lock-inversion/321: ok | ok | ok |
hard-irq read-recursion/123: ok |
soft-irq read-recursion/123: ok |
hard-irq read-recursion/132: ok |
soft-irq read-recursion/132: ok |
hard-irq read-recursion/213: ok |
soft-irq read-recursion/213: ok |
hard-irq read-recursion/231: ok |
soft-irq read-recursion/231: ok |
hard-irq read-recursion/312: ok |
soft-irq read-recursion/312: ok |
hard-irq read-recursion/321: ok |
soft-irq read-recursion/321: ok |
-------------------------------------------------------
Good, all 218 testcases passed! |
---------------------------------
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 514148k/524208k available (1613k kernel code, 9428k reserved, 1194k data, 160k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xfffb7000 - 0xfffff000 ( 288 kB)
vmalloc : 0xe0800000 - 0xfffb5000 ( 503 MB)
lowmem : 0xc0000000 - 0xdffec000 ( 511 MB)
.init : 0xc03c2000 - 0xc03ea000 ( 160 kB)
.data : 0xc029375e - 0xc03be1f8 (1194 kB)
.text : 0xc0100000 - 0xc029375e (1613 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 2824.43 BogoMIPS (lpj=5648874)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383f9ff c1cbf9ff 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0383f9ff c1cbf9ff 00000000 00000420 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(TM) XP 1600+ stepping 02
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
tbxface-0107 [01] load_tables : ACPI Tables successfully acquired
Parsing all Control Methods:
Table [DSDT](id 0005) - 356 Objects with 38 Devices 115 Methods 24 Regions
ACPI Namespace successfully loaded at root c0572630
ACPI: setting ELCR to 0200 (from 0c20)
evxfevnt-0089 [02] enable : Transition to ACPI mode successful
checking if image is initramfs... it is
Freeing initrd memory: 262k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1
Setting up standard PCI resources
evgpeblk-0951 [04] ev_create_gpe_block : GPE 00 to 0F [_GPE] 2 regs on int 0x9
evgpeblk-1048 [03] ev_initialize_gpe_bloc: Found 4 Wake, Enabled 0 Runtime GPEs in this block
Completing Region/Field/Buffer/Package initialization:.......................................................
Initialized 23/24 Regions 2/2 Fields 19/19 Buffers 11/14 Packages (365 nodes)
Initializing Device/Processor/Thermal objects by executing _INI methods:
Executed 0 _INI methods requiring 0 _STA executions (examined 41 objects)
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI quirk: region e200-e27f claimed by vt82c686 HW-mon
PCI quirk: region e800-e80f claimed by vt82c686 SMB
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
PCI: Bridge: 0000:00:01.0
IO window: disabled.
MEM window: c6000000-c7efffff
PREFETCH window: c7f00000-cfffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 7, 655360 bytes)
TCP bind hash table entries: 8192 (order: 6, 360448 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
Simple Boot Flag at 0x3a set to 0x1
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Applying VIA southbridge workaround.
PCI: Disabling Via external APIC routing
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 16 throttling states)
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker
http://www.scyld.com/network/ne2k-pci.html
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
eth0: RealTek RTL-8029 found at 0xa400, IRQ 10, 00:40:95:46:6E:2D.
netconsole: device eth0 not up yet, forcing it
netconsole: carrier detect appears untrustworthy, waiting 4 seconds
=================================
[ INFO: inconsistent lock state ]
2.6.18-rc4-mm1 #92
---------------------------------
inconsistent {in-softirq-W} -> {softirq-on-W} usage.
swapper/1 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&dev->_xmit_lock){-+..}, at: [<c025354f>] netpoll_send_skb+0x6b/0xdb
{in-softirq-W} state was registered at:
[<c012c7a7>] __lock_acquire+0x3e1/0x9aa
[<c012d035>] lock_acquire+0x60/0x80
[<c0292648>] _spin_lock+0x19/0x28
[<c0255106>] dev_watchdog+0x11/0xaf
[<c011da6d>] run_timer_softirq+0xed/0x145
[<c011a8e4>] __do_softirq+0x46/0x9c
[<c011a964>] do_softirq+0x2a/0x42
[<c011acda>] irq_exit+0x31/0x33
[<c0104f39>] do_IRQ+0x97/0xa6
[<c0103699>] common_interrupt+0x25/0x2c
[<c0101aa5>] cpu_idle+0x3c/0x51
[<c0100553>] rest_init+0x1e/0x23
[<c03c26cd>] start_kernel+0x2e2/0x2e4
[<c0100199>] 0xc0100199
[<ffffffff>] 0xffffffff
irq event stamp: 619236
hardirqs last enabled at (619235): [<c0292910>] _spin_unlock_irqrestore+0x36/0x3c
hardirqs last disabled at (619236): [<c0292961>] _spin_lock_irqsave+0xf/0x32
softirqs last enabled at (619196): [<c024bb39>] dev_mc_upload+0x36/0x3a
softirqs last disabled at (619192): [<c0292662>] _spin_lock_bh+0xb/0x2d
other info that might help us debug this:
1 lock held by swapper/1:
#0: (&dev->_xmit_lock){-+..}, at: [<c025354f>] netpoll_send_skb+0x6b/0xdb
stack backtrace:
[<c0103894>] show_trace_log_lvl+0x12/0x25
[<c0103975>] show_trace+0xd/0x10
[<c01040aa>] dump_stack+0x19/0x1b
[<c012b6cd>] print_usage_bug+0x1d1/0x1de
[<c012bbdd>] mark_lock+0x22d/0x349
[<c012bd40>] mark_held_locks+0x47/0x65
[<c012be4d>] trace_hardirqs_on+0xef/0x119
[<c0223eba>] ei_start_xmit+0x258/0x27e
[<c025356d>] netpoll_send_skb+0x89/0xdb
[<c0254211>] netpoll_send_udp+0x1fd/0x208
[<c0224080>] write_msg+0x42/0x6a
[<c0116823>] __call_console_drivers+0x3b/0x48
[<c0116884>] _call_console_drivers+0x54/0x58
[<c0116a46>] release_console_sem+0x122/0x1ed
[<c0116da7>] register_console+0x190/0x197
[<c022402a>] init_netconsole+0x4e/0x62
[<c01003b4>] init+0x88/0x209
[<c0292bf1>] kernel_thread_helper+0x5/0xb
=======================
netconsole: network logging started
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
TCP bic registered
NET: Registered protocol family 1
Using IPI Shortcut mode
ACPI: (supports S0 S1 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
Freeing unused kernel memory: 160k freed
Time: tsc clocksource has been installed.
Write protecting the kernel read-only data: 712k
VP_IDE: IDE controller at PCI slot 0000:00:04.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci0000:00:04.1
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
Time: acpi_pm clocksource has been installed.
input: AT Translated Set 2 keyboard as /class/input/input0
input: ImExPS/2 Generic Explorer Mouse as /class/input/input1
hda: ST340016A, ATA DISK drive
hdb: Maxtor 6Y080L0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes not supported
hda: hda1 hda2 hda3 < hda5 hda6 hda7 > hda4
hdb: max request size: 128KiB
hdb: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hdb: cache flushes supported
hdb: hdb1 hdb2 < hdb5 hdb6 hdb7 hdb8 hdb9 >
Probing IDE interface ide1...
hdc: HL-DT-ST DVDRAM GSA-4165B, ATAPI CD/DVD-ROM drive
hdd: CD-950E/AKU, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
device-mapper: ioctl: 4.8.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:04.2[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
uhci_hcd 0000:00:04.2: UHCI Host Controller
uhci_hcd 0000:00:04.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:04.2: irq 5, io base 0x0000d400
usb usb1: new device found, idVendor=0000, idProduct=0000
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: UHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.18-rc4-mm1 uhci_hcd
usb usb1: SerialNumber: 0000:00:04.2
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:04.3[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
uhci_hcd 0000:00:04.3: UHCI Host Controller
uhci_hcd 0000:00:04.3: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:04.3: irq 5, io base 0x0000d000
usb usb2: new device found, idVendor=0000, idProduct=0000
usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.18-rc4-mm1 uhci_hcd
usb usb2: SerialNumber: 0000:00:04.3
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
warning: process `sleep' used the obsolete sysctl system call
ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[5] MMIO=[c5800000-c58007ff] Max Packet=[2048] IR/IT contexts=[8/8]
usb 1-2: new low speed USB device using uhci_hcd and address 2
usb 1-2: new device found, idVendor=044f, idProduct=b303
usb 1-2: new device strings: Mfr=4, Product=30, SerialNumber=0
usb 1-2: Product: FireStorm Dual Analog 2
usb 1-2: Manufacturer: THRUSTMASTER
usb 1-2: configuration #1 chosen from 1 choice
ohci1394: fw-host0: Running dma failed because Node ID is not valid
input: THRUSTMASTER FireStorm Dual Analog 2 as /class/input/input2
input: USB HID v1.10 Gamepad [THRUSTMASTER FireStorm Dual Analog 2] on usb-0000:00:04.2-2
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
ohci1394: fw-host0: AT dma reset ctx=0, aborting transmission
ieee1394: Current remote IRM is not 1394a-2000 compliant, resetting...
ieee1394: Host added: ID:BUS[0-00:1023] GUID[00308d0120e085ca]
warning: process `date' used the obsolete sysctl system call
input: PC Speaker as /class/input/input3
parport_pc: VIA 686A/8231 detected
parport_pc: probing current configuration
parport_pc: Current parallel port base: 0x378
parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]
parport0: Printer, HEWLETT-PACKARD DESKJET 710C
parport_pc: VIA parallel port: io=0x378, irq=7
lp0: using parport0 (interrupt-driven).
Real Time Clock Driver v1.12ac
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
agpgart: AGP aperture is 256M @ 0xd0000000
Using specific hotkey driver
EXT3 FS on dm-4, internal journal
Adding 1048568k swap on /dev/vglinux1/lvswap. Priority:2 extents:1 across:1048568k
JBD: barrier-based sync failed on dm-4 - disabling barriers
ReiserFS: dm-1: found reiserfs format "3.6" with standard journal
ReiserFS: dm-1: using ordered data mode
reiserfs: using flush barriers
ReiserFS: dm-1: journal params: device dm-1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-1: checking transaction log (dm-1)
ReiserFS: dm-1: replayed 77 transactions in 4 seconds
reiserfs: disabling flush barriers on dm-1
ReiserFS: dm-1: Using r5 hash to sort names
ReiserFS: dm-6: found reiserfs format "3.6" with standard journal
ReiserFS: dm-6: using ordered data mode
reiserfs: using flush barriers
ReiserFS: dm-6: journal params: device dm-6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-6: checking transaction log (dm-6)
ReiserFS: dm-6: replayed 449 transactions in 6 seconds
reiserfs: disabling flush barriers on dm-6
ReiserFS: dm-6: Using r5 hash to sort names
Loading Reiser4. See www.namesys.com for a description of Reiser4.
ps_hash_table: 32 buckets
d_cursor_hash_table: 256 buckets
z_hash_table: 8192 buckets
z_hash_table: 8192 buckets
j_hash_table: 16384 buckets
loading reiser4 bitmap......done (44 jiffies)
d_cursor_hash_table: 256 buckets
z_hash_table: 8192 buckets
z_hash_table: 8192 buckets
j_hash_table: 16384 buckets
loading reiser4 bitmap......done (31 jiffies)
ReiserFS: hda7: found reiserfs format "3.6" with standard journal
ReiserFS: hda7: using ordered data mode
reiserfs: using flush barriers
ReiserFS: hda7: journal params: device hda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda7: checking transaction log (hda7)
reiserfs: disabling flush barriers on hda7
ReiserFS: hda7: Using r5 hash to sort names
ReiserFS: dm-0: found reiserfs format "3.6" with standard journal
ReiserFS: dm-0: using ordered data mode
reiserfs: using flush barriers
ReiserFS: dm-0: journal params: device dm-0, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-0: checking transaction log (dm-0)
reiserfs: disabling flush barriers on dm-0
ReiserFS: dm-0: Using r5 hash to sort names
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
loop: loaded (max 8 devices)
hdc: ATAPI CD-ROM drive, 0kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdd: ATAPI CD-ROM drive, 0kB Cache, DMA
hda: cache flushes not supported
warning: process `ls' used the obsolete sysctl system call
warning: process `prcsys' used the obsolete sysctl system call
warning: process `sleep' used the obsolete sysctl system call
JBD: barrier-based sync failed on dm-2 - disabling barriers
Adding 795208k swap on /dev/hdb7. Priority:2 extents:1 across:795208k
Adding 795208k swap on /dev/hdb7. Priority:2 extents:1 across:795208k
Adding 1048568k swap on /dev/vglinux1/lvswap. Priority:2 extents:1 across:1048568k
[-- Attachment #3: config-2.6.18-rc4-mm1 --]
[-- Type: text/plain, Size: 46267 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.18-rc4-mm1
# Sun Aug 13 18:38:13 2006
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SWAP_PREFETCH=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
CONFIG_SYSCTL=y
CONFIG_SYSCTL_SYSCALL=y
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_UID16=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_RT_MUTEXES=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
#
# Processor type and features
#
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=m
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_X86_REBOOTFIXUPS=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
# CONFIG_X86_CPUID is not set
#
# Firmware Drivers
#
CONFIG_EDD=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_3G_OPT is not set
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ADAPTIVE_READAHEAD=y
# CONFIG_READAHEAD_ALLOW_OVERHEADS is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_REGPARM=y
CONFIG_SECCOMP=y
# CONFIG_SECCOMP_DISABLE_TSC is not set
# CONFIG_VGA_NOPROBE is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_KEXEC=y
CONFIG_PHYSICAL_START=0x100000
# CONFIG_COMPAT_VDSO is not set
#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION="/dev/hdb6"
#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_SLEEP_PROC_SLEEP is not set
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_HOTKEY=m
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_ATLAS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_SONY is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_MULTITHREAD_PROBE is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=m
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK is not set
# CONFIG_NETFILTER_XTABLES is not set
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
# CONFIG_IP_NF_NETBIOS_NS is not set
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
# CONFIG_IP_NF_PPTP is not set
# CONFIG_IP_NF_H323 is not set
# CONFIG_IP_NF_SIP is not set
CONFIG_IP_NF_QUEUE=m
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_EMATCH is not set
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_ESTIMATOR=y
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
CONFIG_WIRELESS_EXT=y
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_SYS_HYPERVISOR is not set
#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
#
# Plug and Play support
#
# CONFIG_PNP is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_UB=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_BLK_DEV_INITRD=y
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_IDE_MAX_HWIFS=2
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=m
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=m
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=m
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set
#
# Serial and Parallel ATA (SATA/PATA) drivers
#
CONFIG_ATA=m
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=m
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT8172 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_ATA_JMICRON is not set
# CONFIG_PATA_LEGACY is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_QDI is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
CONFIG_PATA_VIA=m
# CONFIG_PATA_WINBOND is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_RAID5_RESHAPE=y
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=m
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=m
#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
CONFIG_IEEE1394_OUI_DB=y
# CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set
# CONFIG_IEEE1394_EXPORT_FULL_API is not set
#
# Device Drivers
#
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=m
#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
# CONFIG_IEEE1394_SBP2 is not set
# CONFIG_IEEE1394_ETH1394 is not set
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# PHY device support
#
# CONFIG_PHYLIB is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=y
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
# CONFIG_NET_WIRELESS_RTNETLINK is not set
#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
# CONFIG_ARLAN is not set
# CONFIG_WAVELAN is not set
#
# Wireless 802.11b ISA/PCI cards support
#
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set
#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
CONFIG_PRISM54=m
# CONFIG_USB_ZD1201 is not set
# CONFIG_HOSTAP is not set
# CONFIG_ACX is not set
CONFIG_NET_WIRELESS=y
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
# CONFIG_PPP_MPPE is not set
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
CONFIG_SLHC=m
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_DB9 is not set
# CONFIG_JOYSTICK_GAMECON is not set
# CONFIG_JOYSTICK_TURBOGRAFX is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_UINPUT is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
CONFIG_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_FM801 is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=m
# CONFIG_SERIAL_8250_PCI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=m
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_VIA=m
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=m
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_ISA=m
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
#
# Dallas's 1-wire bus
#
#
# Hardware Monitoring support
#
CONFIG_HWMON=y
CONFIG_HWMON_VID=m
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
CONFIG_SENSORS_LM80=m
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
CONFIG_SENSORS_VIA686A=m
# CONFIG_SENSORS_VT8231 is not set
CONFIG_SENSORS_W83781D=m
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Misc devices
#
# CONFIG_IBM_ASM is not set
#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
# CONFIG_VIDEO_V4L1 is not set
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y
#
# Video Capture Adapters
#
#
# Video Capture Adapters
#
# CONFIG_VIDEO_ADV_DEBUG is not set
# CONFIG_VIDEO_VIVI is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
#
# Encoders and Decoders
#
# CONFIG_VIDEO_MSP3400 is not set
# CONFIG_VIDEO_CS53L32A is not set
# CONFIG_VIDEO_TLV320AIC23B is not set
# CONFIG_VIDEO_WM8775 is not set
# CONFIG_VIDEO_WM8739 is not set
# CONFIG_VIDEO_CX2341X is not set
# CONFIG_VIDEO_CX25840 is not set
# CONFIG_VIDEO_SAA711X is not set
# CONFIG_VIDEO_SAA7127 is not set
# CONFIG_VIDEO_UPD64031A is not set
# CONFIG_VIDEO_UPD64083 is not set
#
# V4L USB devices
#
# CONFIG_VIDEO_PVRUSB2 is not set
#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set
# CONFIG_USB_DSBR is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
# CONFIG_USB_DABUSB is not set
#
# Graphics support
#
CONFIG_FIRMWARE_EDID=y
CONFIG_FB=y
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
CONFIG_FB_NVIDIA=m
CONFIG_FB_NVIDIA_I2C=y
CONFIG_FB_RIVA=m
CONFIG_FB_RIVA_I2C=y
# CONFIG_FB_RIVA_DEBUG is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
#
# Logo configuration
#
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Sound
#
CONFIG_SOUND=m
#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
#
# Generic devices
#
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_AC97_BUS=m
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
# CONFIG_SND_AC97_POWER_SAVE is not set
#
# ISA devices
#
# CONFIG_SND_ADLIB is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_MIRO is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set
#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
CONFIG_SND_ENS1371=m
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_HDA_INTEL is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_SUSPEND=y
CONFIG_USB_MULTITHREAD_PROBE=y
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set
#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_TOUCHSCREEN is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_ATI_REMOTE2 is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_MON is not set
#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_GOTEMP is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TEST is not set
#
# USB DSL modem support
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# LED devices
#
# CONFIG_NEW_LEDS is not set
#
# LED drivers
#
#
# LED Triggers
#
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
CONFIG_EDAC=m
#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=m
CONFIG_EDAC_AMD76X=m
# CONFIG_EDAC_E7XXX is not set
# CONFIG_EDAC_E752X is not set
# CONFIG_EDAC_I82875P is not set
# CONFIG_EDAC_I82860 is not set
# CONFIG_EDAC_K8 is not set
# CONFIG_EDAC_R82600 is not set
CONFIG_EDAC_POLL=y
#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set
#
# DMA Engine support
#
CONFIG_DMA_ENGINE=y
#
# DMA Clients
#
CONFIG_NET_DMA=y
#
# DMA Devices
#
# CONFIG_INTEL_IOATDMA is not set
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY is not set
CONFIG_EXT2_FS_XIP=y
CONFIG_FS_XIP=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISER4_FS=m
CONFIG_REISER4_DEBUG=y
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set
#
# Caches
#
# CONFIG_FSCACHE is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=850
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=m
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
# CONFIG_CIFS_STATS2 is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m
#
# Distributed Lock Manager
#
#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_RWSEMS=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_PAGE_OWNER is not set
CONFIG_DEBUG_FS=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
CONFIG_FRAME_POINTER=y
CONFIG_UNWIND_INFO=y
# CONFIG_STACK_UNWIND is not set
# CONFIG_PROFILE_LIKELY is not set
CONFIG_FORCED_INLINING=y
# CONFIG_DEBUG_SYNCHRO_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
#
# Page alloc debug is incompatible with Software Suspend on i386
#
CONFIG_DEBUG_RODATA=y
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
CONFIG_CRYPTO=y
#
# Cryptographic options
#
CONFIG_CRYPTO_LOWAPI=y
CONFIG_CRYPTO_MANAGER=m
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
# CONFIG_CRYPTO_TWOFISH is not set
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_586=m
# CONFIG_CRYPTO_SERPENT is not set
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_TEST is not set
#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_CRYPTO_DEV_GEODE is not set
#
# Library routines
#
CONFIG_CRC_CCITT=m
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_PLIST=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1: eth0: trigger_send() called with the transmitter busy
2006-08-14 14:38 ` 2.6.18-rc4-mm1: eth0: trigger_send() called with the transmitter busy Laurent Riffard
@ 2006-08-14 16:50 ` Andrew Morton
2006-08-14 17:47 ` Laurent Riffard
0 siblings, 1 reply; 192+ messages in thread
From: Andrew Morton @ 2006-08-14 16:50 UTC (permalink / raw)
To: Laurent Riffard; +Cc: Kernel development list, netdev
On Mon, 14 Aug 2006 16:38:47 +0200
Laurent Riffard <laurent.riffard@free.fr> wrote:
> Le 13.08.2006 10:24, Andrew Morton a __crit :
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> Hello,
>
> This morning, while trying to suspend to disk, my box started to loop
> displaying the following message:
> eth0: trigger_send() called with the transmitter busy.
>
> Here is the scenario. I booted 2.6.18-rc4-mm1 with this command line:
> root=/dev/vglinux1/lvroot video=vesafb:ywrap,mtrr splash=silent resume=/dev/hdb7 netconsole=@192.163.0.3/,@192.168.0.1/00:0E:9B:91:ED:72 init 1
>
> Then I issued:
> # echo 6 > /proc/sys/kernel/printk
> # echo disk > /sys/power/state
ne2k isn't <ahem> the most actively-maintained driver.
But most (I think all) net drivers have problems during suspend when
netconsole is active. Does disabling netconsole help?
Did this operation work OK in earlier kernels, with netconsole enabled?
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1: eth0: trigger_send() called with the transmitter busy
2006-08-14 16:50 ` Andrew Morton
@ 2006-08-14 17:47 ` Laurent Riffard
2006-08-14 20:06 ` Laurent Riffard
0 siblings, 1 reply; 192+ messages in thread
From: Laurent Riffard @ 2006-08-14 17:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: Kernel development list, netdev
Le 14.08.2006 18:50, Andrew Morton a écrit :
> On Mon, 14 Aug 2006 16:38:47 +0200
> Laurent Riffard <laurent.riffard@free.fr> wrote:
>
>> Le 13.08.2006 10:24, Andrew Morton a __crit :
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>> Hello,
>>
>> This morning, while trying to suspend to disk, my box started to loop
>> displaying the following message:
>> eth0: trigger_send() called with the transmitter busy.
>>
>> Here is the scenario. I booted 2.6.18-rc4-mm1 with this command line:
>> root=/dev/vglinux1/lvroot video=vesafb:ywrap,mtrr splash=silent resume=/dev/hdb7 netconsole=@192.163.0.3/,@192.168.0.1/00:0E:9B:91:ED:72 init 1
>>
>> Then I issued:
>> # echo 6 > /proc/sys/kernel/printk
>> # echo disk > /sys/power/state
>
> ne2k isn't <ahem> the most actively-maintained driver.
>
> But most (I think all) net drivers have problems during suspend when
> netconsole is active. Does disabling netconsole help?
Yes it does.
> Did this operation work OK in earlier kernels, with netconsole enabled?
It's the first time I see such a message. I can't speak for 2.6.18-rc3-mm2
because it could not suspend at all (did hang right after
"echo disk > /sys/power/state"), but it worked in earlier kernels.
I'll try with plain 2.6.18-rc4.
--
laurent
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1: eth0: trigger_send() called with the transmitter busy
2006-08-14 17:47 ` Laurent Riffard
@ 2006-08-14 20:06 ` Laurent Riffard
2006-08-14 21:25 ` Rafael J. Wysocki
0 siblings, 1 reply; 192+ messages in thread
From: Laurent Riffard @ 2006-08-14 20:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: Kernel development list, netdev
Le 14.08.2006 19:47, Laurent Riffard a écrit :
> Le 14.08.2006 18:50, Andrew Morton a écrit :
>> On Mon, 14 Aug 2006 16:38:47 +0200
>> Laurent Riffard <laurent.riffard@free.fr> wrote:
>>
>>> Le 13.08.2006 10:24, Andrew Morton a __crit :
>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>>> Hello,
>>>
>>> This morning, while trying to suspend to disk, my box started to loop
>>> displaying the following message:
>>> eth0: trigger_send() called with the transmitter busy.
>>>
>>> Here is the scenario. I booted 2.6.18-rc4-mm1 with this command line:
>>> root=/dev/vglinux1/lvroot video=vesafb:ywrap,mtrr splash=silent resume=/dev/hdb7 netconsole=@192.163.0.3/,@192.168.0.1/00:0E:9B:91:ED:72 init 1
>>>
>>> Then I issued:
>>> # echo 6 > /proc/sys/kernel/printk
>>> # echo disk > /sys/power/state
>> ne2k isn't <ahem> the most actively-maintained driver.
>>
>> But most (I think all) net drivers have problems during suspend when
>> netconsole is active. Does disabling netconsole help?
>
> Yes it does.
>
>> Did this operation work OK in earlier kernels, with netconsole enabled?
>
> It's the first time I see such a message. I can't speak for 2.6.18-rc3-mm2
> because it could not suspend at all (did hang right after
> "echo disk > /sys/power/state"), but it worked in earlier kernels.
>
> I'll try with plain 2.6.18-rc4.
Same problem with 2.6.18-rc4. I'll try earlier -rc kernel tomorrow.
--
laurent
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1: eth0: trigger_send() called with the transmitter busy
2006-08-14 20:06 ` Laurent Riffard
@ 2006-08-14 21:25 ` Rafael J. Wysocki
2006-08-14 23:01 ` Laurent Riffard
0 siblings, 1 reply; 192+ messages in thread
From: Rafael J. Wysocki @ 2006-08-14 21:25 UTC (permalink / raw)
To: Laurent Riffard; +Cc: Andrew Morton, Kernel development list, netdev
On Monday 14 August 2006 22:06, Laurent Riffard wrote:
> Le 14.08.2006 19:47, Laurent Riffard a écrit :
> > Le 14.08.2006 18:50, Andrew Morton a écrit :
> >> On Mon, 14 Aug 2006 16:38:47 +0200
> >> Laurent Riffard <laurent.riffard@free.fr> wrote:
> >>
> >>> Le 13.08.2006 10:24, Andrew Morton a __crit :
> >>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >>> Hello,
> >>>
> >>> This morning, while trying to suspend to disk, my box started to loop
> >>> displaying the following message:
> >>> eth0: trigger_send() called with the transmitter busy.
> >>>
> >>> Here is the scenario. I booted 2.6.18-rc4-mm1 with this command line:
> >>> root=/dev/vglinux1/lvroot video=vesafb:ywrap,mtrr splash=silent resume=/dev/hdb7 netconsole=@192.163.0.3/,@192.168.0.1/00:0E:9B:91:ED:72 init 1
> >>>
> >>> Then I issued:
> >>> # echo 6 > /proc/sys/kernel/printk
> >>> # echo disk > /sys/power/state
> >> ne2k isn't <ahem> the most actively-maintained driver.
> >>
> >> But most (I think all) net drivers have problems during suspend when
> >> netconsole is active. Does disabling netconsole help?
> >
> > Yes it does.
> >
> >> Did this operation work OK in earlier kernels, with netconsole enabled?
> >
> > It's the first time I see such a message. I can't speak for 2.6.18-rc3-mm2
> > because it could not suspend at all (did hang right after
> > "echo disk > /sys/power/state"), but it worked in earlier kernels.
> >
> > I'll try with plain 2.6.18-rc4.
>
> Same problem with 2.6.18-rc4.
I think something like this will help (untested):
kernel/power/disk.c | 7 +++++++
1 files changed, 7 insertions(+)
Index: linux-2.6.18-rc4-mm1/kernel/power/disk.c
===================================================================
--- linux-2.6.18-rc4-mm1.orig/kernel/power/disk.c
+++ linux-2.6.18-rc4-mm1/kernel/power/disk.c
@@ -119,8 +119,10 @@ int pm_suspend_disk(void)
if (error)
return error;
+ suspend_console();
error = device_suspend(PMSG_FREEZE);
if (error) {
+ resume_console();
printk("Some devices failed to suspend\n");
unprepare_processes();
return error;
@@ -133,6 +135,7 @@ int pm_suspend_disk(void)
if (in_suspend) {
device_resume();
+ resume_console();
pr_debug("PM: writing image.\n");
error = swsusp_write();
if (!error)
@@ -148,6 +151,7 @@ int pm_suspend_disk(void)
swsusp_free();
Done:
device_resume();
+ resume_console();
unprepare_processes();
return error;
}
@@ -212,7 +216,9 @@ static int software_resume(void)
pr_debug("PM: Preparing devices for restore.\n");
+ suspend_console();
if ((error = device_suspend(PMSG_PRETHAW))) {
+ resume_console();
printk("Some devices failed to suspend\n");
swsusp_free();
goto Thaw;
@@ -224,6 +230,7 @@ static int software_resume(void)
swsusp_resume();
pr_debug("PM: Restore failed, recovering.n");
device_resume();
+ resume_console();
Thaw:
unprepare_processes();
Done:
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1: eth0: trigger_send() called with the transmitter busy
2006-08-14 21:25 ` Rafael J. Wysocki
@ 2006-08-14 23:01 ` Laurent Riffard
2006-08-15 10:10 ` Rafael J. Wysocki
0 siblings, 1 reply; 192+ messages in thread
From: Laurent Riffard @ 2006-08-14 23:01 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Andrew Morton, Kernel development list, netdev
Le 14.08.2006 23:25, Rafael J. Wysocki a écrit :
> On Monday 14 August 2006 22:06, Laurent Riffard wrote:
>> Le 14.08.2006 19:47, Laurent Riffard a écrit :
>>> Le 14.08.2006 18:50, Andrew Morton a écrit :
>>>> On Mon, 14 Aug 2006 16:38:47 +0200
>>>> Laurent Riffard <laurent.riffard@free.fr> wrote:
>>>>
>>>>> Le 13.08.2006 10:24, Andrew Morton a __crit :
>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>>>>> Hello,
>>>>>
>>>>> This morning, while trying to suspend to disk, my box started to loop
>>>>> displaying the following message:
>>>>> eth0: trigger_send() called with the transmitter busy.
>>>>>
>>>>> Here is the scenario. I booted 2.6.18-rc4-mm1 with this command line:
>>>>> root=/dev/vglinux1/lvroot video=vesafb:ywrap,mtrr splash=silent resume=/dev/hdb7 netconsole=@192.163.0.3/,@192.168.0.1/00:0E:9B:91:ED:72 init 1
>>>>>
>>>>> Then I issued:
>>>>> # echo 6 > /proc/sys/kernel/printk
>>>>> # echo disk > /sys/power/state
>>>> ne2k isn't <ahem> the most actively-maintained driver.
>>>>
>>>> But most (I think all) net drivers have problems during suspend when
>>>> netconsole is active. Does disabling netconsole help?
>>> Yes it does.
>>>
>>>> Did this operation work OK in earlier kernels, with netconsole enabled?
>>> It's the first time I see such a message. I can't speak for 2.6.18-rc3-mm2
>>> because it could not suspend at all (did hang right after
>>> "echo disk > /sys/power/state"), but it worked in earlier kernels.
>>>
>>> I'll try with plain 2.6.18-rc4.
>> Same problem with 2.6.18-rc4.
>
> I think something like this will help (untested):
Well, sort of: it sometimes works, which is better than not. I tried
about 10 times and it sometimes hangs after 'shrinking memory' or whilst
writing to the swap device. The message "eth0: trigger_send() called
with the transmitter busy" didn't appear anymore.
Note that I always have had a warning sowhere in acpi_pci_link_set during suspend:
BUG: sleeping function called from invalid context at include/asm/semaphore.h:99
I'm under the impression your patch is a workaround for my network problem.
Or must really netconsole be stopped during device_suspend ?
> kernel/power/disk.c | 7 +++++++
> 1 files changed, 7 insertions(+)
>
> Index: linux-2.6.18-rc4-mm1/kernel/power/disk.c
> ===================================================================
> --- linux-2.6.18-rc4-mm1.orig/kernel/power/disk.c
> +++ linux-2.6.18-rc4-mm1/kernel/power/disk.c
> @@ -119,8 +119,10 @@ int pm_suspend_disk(void)
> if (error)
> return error;
>
> + suspend_console();
> error = device_suspend(PMSG_FREEZE);
> if (error) {
> + resume_console();
> printk("Some devices failed to suspend\n");
> unprepare_processes();
> return error;
> @@ -133,6 +135,7 @@ int pm_suspend_disk(void)
>
> if (in_suspend) {
> device_resume();
> + resume_console();
> pr_debug("PM: writing image.\n");
> error = swsusp_write();
> if (!error)
> @@ -148,6 +151,7 @@ int pm_suspend_disk(void)
> swsusp_free();
> Done:
> device_resume();
> + resume_console();
> unprepare_processes();
> return error;
> }
> @@ -212,7 +216,9 @@ static int software_resume(void)
>
> pr_debug("PM: Preparing devices for restore.\n");
>
> + suspend_console();
> if ((error = device_suspend(PMSG_PRETHAW))) {
> + resume_console();
> printk("Some devices failed to suspend\n");
> swsusp_free();
> goto Thaw;
> @@ -224,6 +230,7 @@ static int software_resume(void)
> swsusp_resume();
> pr_debug("PM: Restore failed, recovering.n");
> device_resume();
> + resume_console();
> Thaw:
> unprepare_processes();
> Done:
BTW, it doesn't apply cleanly:
CC kernel/power/disk.o
kernel/power/disk.c: In function 'pm_suspend_disk':
kernel/power/disk.c:122: warning: implicit declaration of function 'suspend_console'
kernel/power/disk.c:125: warning: implicit declaration of function 'resume_console'
--
laurent
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1: eth0: trigger_send() called with the transmitter busy
2006-08-14 23:01 ` Laurent Riffard
@ 2006-08-15 10:10 ` Rafael J. Wysocki
2006-08-15 15:38 ` Laurent Riffard
0 siblings, 1 reply; 192+ messages in thread
From: Rafael J. Wysocki @ 2006-08-15 10:10 UTC (permalink / raw)
To: Laurent Riffard; +Cc: Andrew Morton, Kernel development list, netdev
On Tuesday 15 August 2006 01:01, Laurent Riffard wrote:
> Le 14.08.2006 23:25, Rafael J. Wysocki a écrit :
> > On Monday 14 August 2006 22:06, Laurent Riffard wrote:
> >> Le 14.08.2006 19:47, Laurent Riffard a écrit :
> >>> Le 14.08.2006 18:50, Andrew Morton a écrit :
> >>>> On Mon, 14 Aug 2006 16:38:47 +0200
> >>>> Laurent Riffard <laurent.riffard@free.fr> wrote:
> >>>>
> >>>>> Le 13.08.2006 10:24, Andrew Morton a __crit :
> >>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >>>>> Hello,
> >>>>>
> >>>>> This morning, while trying to suspend to disk, my box started to loop
> >>>>> displaying the following message:
> >>>>> eth0: trigger_send() called with the transmitter busy.
> >>>>>
> >>>>> Here is the scenario. I booted 2.6.18-rc4-mm1 with this command line:
> >>>>> root=/dev/vglinux1/lvroot video=vesafb:ywrap,mtrr splash=silent resume=/dev/hdb7 netconsole=@192.163.0.3/,@192.168.0.1/00:0E:9B:91:ED:72 init 1
> >>>>>
> >>>>> Then I issued:
> >>>>> # echo 6 > /proc/sys/kernel/printk
> >>>>> # echo disk > /sys/power/state
> >>>> ne2k isn't <ahem> the most actively-maintained driver.
> >>>>
> >>>> But most (I think all) net drivers have problems during suspend when
> >>>> netconsole is active. Does disabling netconsole help?
> >>> Yes it does.
> >>>
> >>>> Did this operation work OK in earlier kernels, with netconsole enabled?
> >>> It's the first time I see such a message. I can't speak for 2.6.18-rc3-mm2
> >>> because it could not suspend at all (did hang right after
> >>> "echo disk > /sys/power/state"), but it worked in earlier kernels.
> >>>
> >>> I'll try with plain 2.6.18-rc4.
> >> Same problem with 2.6.18-rc4.
> >
> > I think something like this will help (untested):
>
> Well, sort of: it sometimes works, which is better than not. I tried
> about 10 times and it sometimes hangs after 'shrinking memory' or whilst
> writing to the swap device.
Hm, suspicious ...
The swap partition is not on an LVM, is it?
> The message "eth0: trigger_send() called with the transmitter busy" didn't
> appear anymore.
This is the one the patch was meant to get rid of.
> Note that I always have had a warning sowhere in acpi_pci_link_set during suspend:
> BUG: sleeping function called from invalid context at include/asm/semaphore.h:99
Bad. If that's 100% reproducible, could you please try to nail it down?
Please revert the "suspend_console" patch before doing this, because it turns
down all consoles altogether during the suspend. You can also use the patch
and instructions at
http://marc.theaimsgroup.com/?l=linux-acpi&m=115506915023030&q=raw
to debug device drivers' suspend/resume without really suspending.
> I'm under the impression your patch is a workaround for my network problem.
> Or must really netconsole be stopped during device_suspend ?
Yes, it must. For now, the consoles are suspend-unfriendly, so to speak. ;-)
> > kernel/power/disk.c | 7 +++++++
> > 1 files changed, 7 insertions(+)
> >
> > Index: linux-2.6.18-rc4-mm1/kernel/power/disk.c
> > ===================================================================
> > --- linux-2.6.18-rc4-mm1.orig/kernel/power/disk.c
> > +++ linux-2.6.18-rc4-mm1/kernel/power/disk.c
> > @@ -119,8 +119,10 @@ int pm_suspend_disk(void)
> > if (error)
> > return error;
> >
> > + suspend_console();
> > error = device_suspend(PMSG_FREEZE);
> > if (error) {
> > + resume_console();
> > printk("Some devices failed to suspend\n");
> > unprepare_processes();
> > return error;
> > @@ -133,6 +135,7 @@ int pm_suspend_disk(void)
> >
> > if (in_suspend) {
> > device_resume();
> > + resume_console();
> > pr_debug("PM: writing image.\n");
> > error = swsusp_write();
> > if (!error)
> > @@ -148,6 +151,7 @@ int pm_suspend_disk(void)
> > swsusp_free();
> > Done:
> > device_resume();
> > + resume_console();
> > unprepare_processes();
> > return error;
> > }
> > @@ -212,7 +216,9 @@ static int software_resume(void)
> >
> > pr_debug("PM: Preparing devices for restore.\n");
> >
> > + suspend_console();
> > if ((error = device_suspend(PMSG_PRETHAW))) {
> > + resume_console();
> > printk("Some devices failed to suspend\n");
> > swsusp_free();
> > goto Thaw;
> > @@ -224,6 +230,7 @@ static int software_resume(void)
> > swsusp_resume();
> > pr_debug("PM: Restore failed, recovering.n");
> > device_resume();
> > + resume_console();
> > Thaw:
> > unprepare_processes();
> > Done:
>
> BTW, it doesn't apply cleanly:
>
> CC kernel/power/disk.o
> kernel/power/disk.c: In function 'pm_suspend_disk':
> kernel/power/disk.c:122: warning: implicit declaration of function 'suspend_console'
> kernel/power/disk.c:125: warning: implicit declaration of function 'resume_console'
Thanks. I think I'll prepare a bigger patch to add turning off the consoles
with a config switch to disable this.
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1: eth0: trigger_send() called with the transmitter busy
2006-08-15 10:10 ` Rafael J. Wysocki
@ 2006-08-15 15:38 ` Laurent Riffard
2006-08-15 16:39 ` Rafael J. Wysocki
0 siblings, 1 reply; 192+ messages in thread
From: Laurent Riffard @ 2006-08-15 15:38 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Andrew Morton, Kernel development list, netdev
Le 15.08.2006 12:10, Rafael J. Wysocki a écrit :
> On Tuesday 15 August 2006 01:01, Laurent Riffard wrote:
>> Le 14.08.2006 23:25, Rafael J. Wysocki a écrit :
>>> On Monday 14 August 2006 22:06, Laurent Riffard wrote:
>>>> Le 14.08.2006 19:47, Laurent Riffard a écrit :
>>>>> Le 14.08.2006 18:50, Andrew Morton a écrit :
>>>>>> On Mon, 14 Aug 2006 16:38:47 +0200
>>>>>> Laurent Riffard <laurent.riffard@free.fr> wrote:
>>>>>>
>>>>>>> Le 13.08.2006 10:24, Andrew Morton a __crit :
>>>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>>>>>>> Hello,
>>>>>>>
>>>>>>> This morning, while trying to suspend to disk, my box started to loop
>>>>>>> displaying the following message:
>>>>>>> eth0: trigger_send() called with the transmitter busy.
>>>>>>>
>>>>>>> Here is the scenario. I booted 2.6.18-rc4-mm1 with this command line:
>>>>>>> root=/dev/vglinux1/lvroot video=vesafb:ywrap,mtrr splash=silent resume=/dev/hdb7 netconsole=@192.163.0.3/,@192.168.0.1/00:0E:9B:91:ED:72 init 1
>>>>>>>
>>>>>>> Then I issued:
>>>>>>> # echo 6 > /proc/sys/kernel/printk
>>>>>>> # echo disk > /sys/power/state
>>>>>> ne2k isn't <ahem> the most actively-maintained driver.
>>>>>>
>>>>>> But most (I think all) net drivers have problems during suspend when
>>>>>> netconsole is active. Does disabling netconsole help?
>>>>> Yes it does.
>>>>>
>>>>>> Did this operation work OK in earlier kernels, with netconsole enabled?
>>>>> It's the first time I see such a message. I can't speak for 2.6.18-rc3-mm2
>>>>> because it could not suspend at all (did hang right after
>>>>> "echo disk > /sys/power/state"), but it worked in earlier kernels.
>>>>>
>>>>> I'll try with plain 2.6.18-rc4.
>>>> Same problem with 2.6.18-rc4.
>>> I think something like this will help (untested):
>> Well, sort of: it sometimes works, which is better than not. I tried
>> about 10 times and it sometimes hangs after 'shrinking memory' or whilst
>> writing to the swap device.
>
> Hm, suspicious ...
>
> The swap partition is not on an LVM, is it?
>
>> The message "eth0: trigger_send() called with the transmitter busy" didn't
>> appear anymore.
>
> This is the one the patch was meant to get rid of.
>
>> Note that I always have had a warning sowhere in acpi_pci_link_set during suspend:
>> BUG: sleeping function called from invalid context at include/asm/semaphore.h:99
> Bad. If that's 100% reproducible, could you please try to nail it down?
I wasn't clear: I always had this "BUG: sleeping function called ...." since one year
or more. It never prevents from suspending. Do you want me to track down what cause
this message? Here is a more complete trace:
Stopping tasks: ================|
Shrinking memory... ^H-^H\^Hdone (10908 pages freed)
Suspending device sound
Suspending device agpgart
Suspending device rtc
Suspending device 00308d0120e085ca
Suspending device usbdev1.2
Suspending device usbdev1.2_ep81
Suspending device 1-2:1.0
Suspending device usbdev1.2_ep00
Suspending device 1-2
Suspending device fw-host0
Suspending device usbdev2.1
Suspending device usbdev2.1_ep81
Suspending device usbdev1.1
Suspending device usbdev1.1_ep81
Suspending device 2-0:1.0
Suspending device usbdev2.1_ep00
Suspending device usb2
Suspending device 1-0:1.0
Suspending device usbdev1.1_ep00
Suspending device usb1
Suspending device device-mapper
Suspending device 1.1
Suspending device 1.0
Suspending device ide1
Suspending device 0.1
Suspending device 0.0
Suspending device ide0
Suspending device psaux
Suspending device serio1
Suspending device serio0
Suspending device i8042
Suspending device isa
Suspending device vcsa
Suspending device vcs
Suspending device vc
Suspending device vesafb.0
Suspending device snapshot
Suspending device misc
Suspending device pcspkr
Suspending device 0000:01:00.0
Suspending device 0000:00:0d.0
Suspending device 0000:00:0b.0
ACPI: PCI interrupt for device 0000:00:0b.0 disabled
Suspending device 0000:00:09.0
Suspending device 0000:00:04.4
Suspending device 0000:00:04.3
ACPI: PCI interrupt for device 0000:00:04.3 disabled
Suspending device 0000:00:04.2
ACPI: PCI interrupt for device 0000:00:04.2 disabled
Suspending device 0000:00:04.1
Suspending device 0000:00:04.0
Suspending device 0000:00:01.0
Suspending device 0000:00:00.0
pci_set_power_state(): 0000:00:00.0: state=3, current state=5
Suspending device pci0000:00
Suspending device acpi
Suspending device vtcon0
Suspending device vtconsole
Suspending device virtual
Suspending device platform
swsusp: Need to copy 60817 pages
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
BUG: sleeping function called from invalid context at include/asm/semaphore.h:99
in_atomic():0, irqs_disabled():1
[<c0103894>] show_trace_log_lvl+0x12/0x25
[<c0103975>] show_trace+0xd/0x10
[<c01040aa>] dump_stack+0x19/0x1b
[<c0112ef9>] __might_sleep+0x8d/0x95
[<c01daf53>] acpi_os_wait_semaphore+0x93/0x158
[<c01ffb9d>] acpi_ut_acquire_mutex+0x69/0xd4
[<c01f3231>] acpi_ns_get_node+0x8e/0x112
[<c01f259a>] acpi_ns_evaluate+0x62/0x258
[<c01f8aa1>] acpi_rs_set_srs_method_data+0xf1/0x125
[<c01f8341>] acpi_set_current_resources+0x8b/0xb0
[<c0204ca5>] acpi_pci_link_set+0x10e/0x1e0
[<c0204dc2>] irqrouter_resume+0x4b/0x62
[<c021d04a>] __sysdev_resume+0x14/0x57
[<c021d1c0>] sysdev_resume+0x19/0x4b
[<c0221bf9>] device_power_up+0x8/0xf
[<c0134271>] swsusp_suspend+0x51/0x78
[<c013466a>] pm_suspend_disk+0x51/0xe2
[<c01337d0>] enter_state+0x52/0x164
[<c0133968>] state_store+0x86/0x9c
[<c01831b8>] subsys_attr_store+0x20/0x25
[<c01832c8>] sysfs_write_file+0xaa/0xcf
[<c015472c>] vfs_write+0x8c/0x138
[<c0154c44>] sys_write+0x3b/0x60
[<c0102c2d>] sysenter_past_esp+0x56/0x8d
=======================
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:04.2[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
PCI: VIA IRQ fixup for 0000:00:04.2, from 12 to 5
usb usb1: root hub lost power or was reset
ACPI: PCI Interrupt 0000:00:04.3[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
PCI: VIA IRQ fixup for 0000:00:04.3, from 12 to 5
usb usb2: root hub lost power or was reset
PM: Writing back config space on device 0000:00:09.0 at offset f (was 180c010c, writing 180c0105)
PM: Writing back config space on device 0000:00:0b.0 at offset 1 (was 2000000, writing 2000003)
ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
PM: Writing back config space on device 0000:00:0d.0 at offset f (was 800c010c, writing 800c0105)
PM: Writing back config space on device 0000:00:0d.0 at offset 1 (was 4100005, writing 34100000)
Restarting tasks... done
usb 1-2: USB disconnect, address 2
> Please revert the "suspend_console" patch before doing this, because it turns
> down all consoles altogether during the suspend. You can also use the patch
> and instructions at
>
> http://marc.theaimsgroup.com/?l=linux-acpi&m=115506915023030&q=raw
>
> to debug device drivers' suspend/resume without really suspending.
>
>> I'm under the impression your patch is a workaround for my network problem.
>> Or must really netconsole be stopped during device_suspend ?
>
> Yes, it must. For now, the consoles are suspend-unfriendly, so to speak. ;-)
>
I think I found something related to netconsole and your patch
"suspend_console/resume_console". I was booting to runlevel 1 and I was using
this script to suspend:
<=== script begin ===>
#!/bin/sh
# don't want to {fsck *and* reboot} if something goes wrong
mount -oremount,ro /
# enable write caching on HD
hdparm -W1 /dev/hd[ab]
echo 6 > /proc/sys/kernel/printk
sleep 2
echo disk > /sys/power/state
<=== script end ===>
The important point is the "sleep 2" line. If it is present, I can suspend the box.
Remove the "sleep command" and it will hang after displaying:
Stopping tasks: =====================|
Shrinking memory... done (0 pages freed)
If netconsole is disabled (ie not called from command line), I do not need this
"sleep", suspend always works.
--
laurent
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1: eth0: trigger_send() called with the transmitter busy
2006-08-15 15:38 ` Laurent Riffard
@ 2006-08-15 16:39 ` Rafael J. Wysocki
0 siblings, 0 replies; 192+ messages in thread
From: Rafael J. Wysocki @ 2006-08-15 16:39 UTC (permalink / raw)
To: Laurent Riffard
Cc: Andrew Morton, Kernel development list, netdev, Linux ACPI
On Tuesday 15 August 2006 17:38, Laurent Riffard wrote:
>
> Le 15.08.2006 12:10, Rafael J. Wysocki a écrit :
> > On Tuesday 15 August 2006 01:01, Laurent Riffard wrote:
> >> Le 14.08.2006 23:25, Rafael J. Wysocki a écrit :
> >>> On Monday 14 August 2006 22:06, Laurent Riffard wrote:
> >>>> Le 14.08.2006 19:47, Laurent Riffard a écrit :
> >>>>> Le 14.08.2006 18:50, Andrew Morton a écrit :
> >>>>>> On Mon, 14 Aug 2006 16:38:47 +0200
> >>>>>> Laurent Riffard <laurent.riffard@free.fr> wrote:
]--snip--[
> >> Note that I always have had a warning sowhere in acpi_pci_link_set during suspend:
> >> BUG: sleeping function called from invalid context at include/asm/semaphore.h:99
> > Bad. If that's 100% reproducible, could you please try to nail it down?
>
> I wasn't clear: I always had this "BUG: sleeping function called ...." since one year
> or more. It never prevents from suspending. Do you want me to track down what cause
> this message?
Something like that, more or less, but the trace below shows this. ;-)
It doesn't seem to be harmful, though.
> Here is a more complete trace:
>
> Stopping tasks: ================|
> Shrinking memory... ^H-^H\^Hdone (10908 pages freed)
]--snip--[
> Suspending device platform
> swsusp: Need to copy 60817 pages
> Intel machine check architecture supported.
> Intel machine check reporting enabled on CPU#0.
> BUG: sleeping function called from invalid context at include/asm/semaphore.h:99
> in_atomic():0, irqs_disabled():1
> [<c0103894>] show_trace_log_lvl+0x12/0x25
> [<c0103975>] show_trace+0xd/0x10
> [<c01040aa>] dump_stack+0x19/0x1b
> [<c0112ef9>] __might_sleep+0x8d/0x95
> [<c01daf53>] acpi_os_wait_semaphore+0x93/0x158
> [<c01ffb9d>] acpi_ut_acquire_mutex+0x69/0xd4
> [<c01f3231>] acpi_ns_get_node+0x8e/0x112
> [<c01f259a>] acpi_ns_evaluate+0x62/0x258
> [<c01f8aa1>] acpi_rs_set_srs_method_data+0xf1/0x125
> [<c01f8341>] acpi_set_current_resources+0x8b/0xb0
> [<c0204ca5>] acpi_pci_link_set+0x10e/0x1e0
> [<c0204dc2>] irqrouter_resume+0x4b/0x62
Here we go. linux-acpi added to the Cc list.
> [<c021d04a>] __sysdev_resume+0x14/0x57
> [<c021d1c0>] sysdev_resume+0x19/0x4b
> [<c0221bf9>] device_power_up+0x8/0xf
> [<c0134271>] swsusp_suspend+0x51/0x78
> [<c013466a>] pm_suspend_disk+0x51/0xe2
> [<c01337d0>] enter_state+0x52/0x164
> [<c0133968>] state_store+0x86/0x9c
> [<c01831b8>] subsys_attr_store+0x20/0x25
> [<c01832c8>] sysfs_write_file+0xaa/0xcf
> [<c015472c>] vfs_write+0x8c/0x138
> [<c0154c44>] sys_write+0x3b/0x60
> [<c0102c2d>] sysenter_past_esp+0x56/0x8d
> =======================
]--snip--[
> >> Or must really netconsole be stopped during device_suspend ?
> >
> > Yes, it must. For now, the consoles are suspend-unfriendly, so to speak. ;-)
> >
>
> I think I found something related to netconsole and your patch
> "suspend_console/resume_console". I was booting to runlevel 1 and I was using
> this script to suspend:
>
> <=== script begin ===>
> #!/bin/sh
> # don't want to {fsck *and* reboot} if something goes wrong
> mount -oremount,ro /
> # enable write caching on HD
> hdparm -W1 /dev/hd[ab]
> echo 6 > /proc/sys/kernel/printk
> sleep 2
> echo disk > /sys/power/state
> <=== script end ===>
>
> The important point is the "sleep 2" line. If it is present, I can suspend the box.
> Remove the "sleep command" and it will hang after displaying:
> Stopping tasks: =====================|
> Shrinking memory... done (0 pages freed)
>
> If netconsole is disabled (ie not called from command line), I do not need this
> "sleep", suspend always works.
It behaves like that with the "suspend_console/resume_console" patch or
without it?
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
^ permalink raw reply [flat|nested] 192+ messages in thread
* [-mm PATCH] ioremap: fixed MIPS build error
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (20 preceding siblings ...)
2006-08-14 14:38 ` 2.6.18-rc4-mm1: eth0: trigger_send() called with the transmitter busy Laurent Riffard
@ 2006-08-14 15:11 ` Yoichi Yuasa
2006-08-14 17:54 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
` (7 subsequent siblings)
29 siblings, 0 replies; 192+ messages in thread
From: Yoichi Yuasa @ 2006-08-14 15:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: yoichi_yuasa, linux-kernel
Hi Andrew,
This patch has fixed following build error.
This error occurred in relation to generic-ioremap_page_range-mips-conversion.patch
CC arch/mips/mm/ioremap.o
arch/mips/mm/ioremap.c: In function `__ioremap':
arch/mips/mm/ioremap.c:58: error: `high_memory' undeclared (first use in this function)
arch/mips/mm/ioremap.c:58: error: (Each undeclared identifier is reported only once
arch/mips/mm/ioremap.c:58: error: for each function it appears in.)
arch/mips/mm/ioremap.c:65: error: `mem_map' undeclared (first use in this function)
arch/mips/mm/ioremap.c:65: error: increment of pointer to unknown structure
arch/mips/mm/ioremap.c:65: error: arithmetic on pointer to an incomplete type
arch/mips/mm/ioremap.c:66: warning: implicit declaration of function `PageReserved'
make[1]: *** [arch/mips/mm/ioremap.o] Error 1
make: *** [arch/mips/mm] Error 2
diff -pruN -X linux-2.6.18-rc4-mm1/Documentation/dontdiff linux-2.6.18-rc4-mm1-orig/arch/mips/mm/ioremap.c linux-2.6.18-rc4-mm1/arch/mips/mm/ioremap.c
--- linux-2.6.18-rc4-mm1-orig/arch/mips/mm/ioremap.c 2006-08-14 15:36:38.910018250 +0900
+++ linux-2.6.18-rc4-mm1/arch/mips/mm/ioremap.c 2006-08-14 23:30:48.321004750 +0900
@@ -6,6 +6,7 @@
* (C) Copyright 1995 1996 Linus Torvalds
* (C) Copyright 2001, 2002 Ralf Baechle
*/
+#include <linux/mm.h>
#include <linux/module.h>
#include <asm/addrspace.h>
#include <asm/byteorder.h>
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (21 preceding siblings ...)
2006-08-14 15:11 ` [-mm PATCH] ioremap: fixed MIPS build error Yoichi Yuasa
@ 2006-08-14 17:54 ` Rafael J. Wysocki
2006-08-14 18:15 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 14:07 ` 2.6.18-rc4-mm1 Atsushi Nemoto
2006-08-15 13:25 ` 2.6.18-rc4-mm1 BUG, drm related Frederik Deweerdt
` (6 subsequent siblings)
29 siblings, 2 replies; 192+ messages in thread
From: Rafael J. Wysocki @ 2006-08-14 17:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sunday 13 August 2006 10:24, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
This patch:
simplify-update_times-avoid-jiffies-jiffies_64-aliasing-problem.patch
makes my x86_64 SMP box (dual-core Athlon 64 on an ULi-based AsRock mobo) run
_very_ slow (it would take tens of minutes to boot the box if I were as
patient as to wait for that).
Strangely enough, on a non-SMP box I have tested it on it works just fine.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1
2006-08-14 17:54 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
@ 2006-08-14 18:15 ` Andrew Morton
2006-08-15 14:07 ` 2.6.18-rc4-mm1 Atsushi Nemoto
1 sibling, 0 replies; 192+ messages in thread
From: Andrew Morton @ 2006-08-14 18:15 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-kernel, Atsushi Nemoto
On Mon, 14 Aug 2006 19:54:29 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> On Sunday 13 August 2006 10:24, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >
>
> This patch:
>
> simplify-update_times-avoid-jiffies-jiffies_64-aliasing-problem.patch
>
> makes my x86_64 SMP box (dual-core Athlon 64 on an ULi-based AsRock mobo) run
> _very_ slow (it would take tens of minutes to boot the box if I were as
> patient as to wait for that).
>
> Strangely enough, on a non-SMP box I have tested it on it works just fine.
>
Thanks. I dropped a reversion patch into
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/hot-fixes/
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 17:54 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
2006-08-14 18:15 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-15 14:07 ` Atsushi Nemoto
2006-08-15 17:14 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
1 sibling, 1 reply; 192+ messages in thread
From: Atsushi Nemoto @ 2006-08-15 14:07 UTC (permalink / raw)
To: rjw; +Cc: akpm, linux-kernel
On Mon, 14 Aug 2006 19:54:29 +0200, "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> simplify-update_times-avoid-jiffies-jiffies_64-aliasing-problem.patch
>
> makes my x86_64 SMP box (dual-core Athlon 64 on an ULi-based AsRock mobo) run
> _very_ slow (it would take tens of minutes to boot the box if I were as
> patient as to wait for that).
>
> Strangely enough, on a non-SMP box I have tested it on it works just fine.
Oh, my fault.
Could you retry with this patch?
diff -urp linux-2.6.18-rc4-mm1.org/arch/x86_64/kernel/time.c linux-2.6.18-rc4-mm1/arch/x86_64/kernel/time.c
--- linux-2.6.18-rc4-mm1.org/arch/x86_64/kernel/time.c 2006-08-13 22:59:27.000000000 +0900
+++ linux-2.6.18-rc4-mm1/arch/x86_64/kernel/time.c 2006-08-15 23:01:55.631372704 +0900
@@ -417,6 +417,8 @@ void main_timer_handler(struct pt_regs *
if (lost > 0)
handle_lost_ticks(lost, regs);
+ else
+ lost = 0;
/*
* Do the timer stuff.
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 14:07 ` 2.6.18-rc4-mm1 Atsushi Nemoto
@ 2006-08-15 17:14 ` Rafael J. Wysocki
0 siblings, 0 replies; 192+ messages in thread
From: Rafael J. Wysocki @ 2006-08-15 17:14 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: akpm, linux-kernel
On Tuesday 15 August 2006 16:07, Atsushi Nemoto wrote:
> On Mon, 14 Aug 2006 19:54:29 +0200, "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > simplify-update_times-avoid-jiffies-jiffies_64-aliasing-problem.patch
> >
> > makes my x86_64 SMP box (dual-core Athlon 64 on an ULi-based AsRock mobo) run
> > _very_ slow (it would take tens of minutes to boot the box if I were as
> > patient as to wait for that).
> >
> > Strangely enough, on a non-SMP box I have tested it on it works just fine.
>
> Oh, my fault.
>
> Could you retry with this patch?
Yes, the patch helps.
Thanks,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
^ permalink raw reply [flat|nested] 192+ messages in thread
* 2.6.18-rc4-mm1 BUG, drm related
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (22 preceding siblings ...)
2006-08-14 17:54 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
@ 2006-08-15 13:25 ` Frederik Deweerdt
2006-08-15 14:16 ` Andrew Morton
2006-08-19 23:08 ` 2.6.18-rc4-mm1 BUG, drm relatedy Frederik Deweerdt
2006-08-16 9:41 ` 2.6.18-rc4-mm1 -- new depancy on curses development Andy Whitcroft
` (5 subsequent siblings)
29 siblings, 2 replies; 192+ messages in thread
From: Frederik Deweerdt @ 2006-08-15 13:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, airlied
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
Hi,
There are two BUGs with 2.6.18-rc4-mm1 that seem related to (I did the
bisection[1]):
git-drm.patch
drm-build-fix.patch
drm-build-fixes-2.patch
allow-drm-detection-of-new-via-chipsets.patch
git-drm-build-fix.patch
Here's one of the BUGs (the second one is on the web site below).
[ 40.276000] [drm:drm_unlock] *ERROR* Process 8914 using kernel context 0
[ 41.024000] BUG: unable to handle kernel paging request at virtual address 6e756f73
[ 41.024000] printing eip:
[ 41.024000] c01b5771
[ 41.024000] *pde = 00000000
[ 41.024000] Oops: 0000 [#1]
[ 41.024000] 8K_STACKS PREEMPT
[ 41.024000] last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0/bInterfaceProtocol
[ 41.024000] Modules linked in: snd_seq snd_seq_device ohci_hcd parport_pc parport pcspkr ipw2200 yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd uhci_hcd usbcore cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_centrino freq_table processor ac battery i915 drm tg3 joydev tsdev
[ 41.024000] CPU: 0
[ 41.024000] EIP: 0060:[<c01b5771>] Not tainted VLI
[ 41.024000] EFLAGS: 00210246 (2.6.18-rc4-mm1-def01 #1)
[ 41.024000] EIP is at sysfs_lookup+0x65/0xb0
[ 41.024000] eax: f3161e40 ebx: f316842c ecx: f73f6280 edx: f316842c
[ 41.024000] esi: 6e756f73 edi: f3161ec4 ebp: f6c35dfc esp: f6c35de0
[ 41.024000] ds: 007b es: 007b ss: 0068
[ 41.024000] Process modprobe (pid: 8952, ti=f6c34000 task=f7d17550 task.ti=f6c34000)
[ 41.024000] Stack: f316842c f3161e94 f31684bc 00000000 fffffff4 f73f72ec f3161e40 f6c35e1c
[ 41.024000] c0184d42 f73f72ec f3161e40 00000000 ffffffff c03a6656 12fd28db f6c35e4c
[ 41.024000] c0184e02 f6c35e30 f3161ee8 00000000 12fd28db 00000005 c03a6651 c038230e
[ 41.024000] Call Trace:
[ 41.024000] [<c0184d42>] __lookup_hash+0x9d/0xcc
[ 41.024000] [<c0184e02>] lookup_one_len+0x71/0x86
[ 41.024000] [<c01b51da>] create_dir+0x43/0x23f
[ 41.024000] [<c01b53fc>] sysfs_create_subdir+0x26/0x28
[ 41.024000] [<c01b6c56>] sysfs_create_group+0x77/0x97
[ 41.024000] [<c02903af>] dpm_sysfs_add+0x1e/0x20
[ 41.024000] [<c028f6b3>] device_pm_add+0x64/0x89
[ 41.024000] [<c028930a>] device_add+0x1d9/0x380
[ 41.024000] [<c02894cb>] device_register+0x1a/0x20
[ 41.024000] [<c0289811>] device_create+0xaa/0xc4
[ 41.024000] [<f8a0c472>] snd_register_device+0xcf/0x104 [snd]
[ 41.024000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
[ 41.024000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
[ 41.024000] [<c014186c>] sys_init_module+0x163/0x221
[ 41.024000] [<c0103135>] sysenter_past_esp+0x56/0x8d
[ 41.024000] [<b7fb0410>] 0xb7fb0410
[ 41.024000] [<c0104017>] show_trace_log_lvl+0x2f/0x45
[ 41.024000] [<c01040ee>] show_stack_log_lvl+0x98/0xb2
[ 41.024000] [<c0104351>] show_registers+0x1eb/0x289
[ 41.024000] [<c0104587>] die+0x134/0x241
[ 41.024000] [<c0385e80>] do_page_fault+0x395/0x620
[ 41.024000] [<c0384401>] error_code+0x39/0x40
[ 41.024000] [<c0184d42>] __lookup_hash+0x9d/0xcc
[ 41.024000] [<c0184e02>] lookup_one_len+0x71/0x86
[ 41.024000] [<c01b51da>] create_dir+0x43/0x23f
[ 41.024000] [<c01b53fc>] sysfs_create_subdir+0x26/0x28
[ 41.024000] [<c01b6c56>] sysfs_create_group+0x77/0x97
[ 41.024000] [<c02903af>] dpm_sysfs_add+0x1e/0x20
[ 41.024000] [<c028f6b3>] device_pm_add+0x64/0x89
[ 41.024000] [<c028930a>] device_add+0x1d9/0x380
[ 41.024000] [<c02894cb>] device_register+0x1a/0x20
[ 41.024000] [<c0289811>] device_create+0xaa/0xc4
[ 41.024000] [<f8a0c472>] snd_register_device+0xcf/0x104 [snd]
[ 41.024000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
[ 41.024000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
[ 41.024000] [<c014186c>] sys_init_module+0x163/0x221
[ 41.024000] [<c0103135>] sysenter_past_esp+0x56/0x8d
[ 41.024000] =======================
[ 41.024000] Code: 42 fc 89 c3 8b 40 04 0f 18 00 90 3b 55 ec 75 e6 8b 45 f0 83 c4 10 5b 5e 5f 5d c3 89 1c 24 e8 27 e9 ff ff 89 c6 8b 45 0c 8b 78 48 <ac> ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 bd f6
[ 41.024000] EIP: [<c01b5771>] sysfs_lookup+0x65/0xb0 SS:ESP 0068:f6c35de0
[ 41.024000]
There's only one BUG at each boot, and both alternate for no particular
reason.
The lspci, dmesg and .config can be found at:
http://fdeweerdt.free.fr/drm_bug/
Any ideas for further investigation?
Thanks,
Frederik
[1] Andrew, could it be possible to put the 'mm.patch' at the very end
or at the very beginning of the patches? It is misleading to have the
kernel change it's name in the middle of a bisection :).
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 BUG, drm related
2006-08-15 13:25 ` 2.6.18-rc4-mm1 BUG, drm related Frederik Deweerdt
@ 2006-08-15 14:16 ` Andrew Morton
2006-08-15 17:37 ` Frederik Deweerdt
2006-08-19 23:08 ` 2.6.18-rc4-mm1 BUG, drm relatedy Frederik Deweerdt
1 sibling, 1 reply; 192+ messages in thread
From: Andrew Morton @ 2006-08-15 14:16 UTC (permalink / raw)
To: Frederik Deweerdt; +Cc: linux-kernel, airlied, Jaroslav Kysela, Takashi Iwai
On Tue, 15 Aug 2006 13:25:56 +0000
Frederik Deweerdt <deweerdt@free.fr> wrote:
> On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >
> Hi,
>
> There are two BUGs with 2.6.18-rc4-mm1 that seem related to (I did the
> bisection[1]):
> git-drm.patch
> drm-build-fix.patch
> drm-build-fixes-2.patch
> allow-drm-detection-of-new-via-chipsets.patch
> git-drm-build-fix.patch
>
> Here's one of the BUGs (the second one is on the web site below).
> [ 40.276000] [drm:drm_unlock] *ERROR* Process 8914 using kernel context 0
I guess the above is a non-fatal DRM warning.
The below is an ALSA oops.
> [ 41.024000] BUG: unable to handle kernel paging request at virtual address 6e756f73
> [ 41.024000] printing eip:
> [ 41.024000] c01b5771
> [ 41.024000] *pde = 00000000
> [ 41.024000] Oops: 0000 [#1]
> [ 41.024000] 8K_STACKS PREEMPT
> [ 41.024000] last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0/bInterfaceProtocol
> [ 41.024000] Modules linked in: snd_seq snd_seq_device ohci_hcd parport_pc parport pcspkr ipw2200 yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd uhci_hcd usbcore cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_centrino freq_table processor ac battery i915 drm tg3 joydev tsdev
> [ 41.024000] CPU: 0
> [ 41.024000] EIP: 0060:[<c01b5771>] Not tainted VLI
> [ 41.024000] EFLAGS: 00210246 (2.6.18-rc4-mm1-def01 #1)
> [ 41.024000] EIP is at sysfs_lookup+0x65/0xb0
> [ 41.024000] eax: f3161e40 ebx: f316842c ecx: f73f6280 edx: f316842c
> [ 41.024000] esi: 6e756f73 edi: f3161ec4 ebp: f6c35dfc esp: f6c35de0
> [ 41.024000] ds: 007b es: 007b ss: 0068
> [ 41.024000] Process modprobe (pid: 8952, ti=f6c34000 task=f7d17550 task.ti=f6c34000)
> [ 41.024000] Stack: f316842c f3161e94 f31684bc 00000000 fffffff4 f73f72ec f3161e40 f6c35e1c
> [ 41.024000] c0184d42 f73f72ec f3161e40 00000000 ffffffff c03a6656 12fd28db f6c35e4c
> [ 41.024000] c0184e02 f6c35e30 f3161ee8 00000000 12fd28db 00000005 c03a6651 c038230e
> [ 41.024000] Call Trace:
> [ 41.024000] [<c0184d42>] __lookup_hash+0x9d/0xcc
> [ 41.024000] [<c0184e02>] lookup_one_len+0x71/0x86
> [ 41.024000] [<c01b51da>] create_dir+0x43/0x23f
> [ 41.024000] [<c01b53fc>] sysfs_create_subdir+0x26/0x28
> [ 41.024000] [<c01b6c56>] sysfs_create_group+0x77/0x97
> [ 41.024000] [<c02903af>] dpm_sysfs_add+0x1e/0x20
> [ 41.024000] [<c028f6b3>] device_pm_add+0x64/0x89
> [ 41.024000] [<c028930a>] device_add+0x1d9/0x380
> [ 41.024000] [<c02894cb>] device_register+0x1a/0x20
> [ 41.024000] [<c0289811>] device_create+0xaa/0xc4
> [ 41.024000] [<f8a0c472>] snd_register_device+0xcf/0x104 [snd]
> [ 41.024000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> [ 41.024000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> [ 41.024000] [<c014186c>] sys_init_module+0x163/0x221
> [ 41.024000] [<c0103135>] sysenter_past_esp+0x56/0x8d
> [ 41.024000] [<b7fb0410>] 0xb7fb0410
> [ 41.024000] [<c0104017>] show_trace_log_lvl+0x2f/0x45
> [ 41.024000] [<c01040ee>] show_stack_log_lvl+0x98/0xb2
> [ 41.024000] [<c0104351>] show_registers+0x1eb/0x289
> [ 41.024000] [<c0104587>] die+0x134/0x241
> [ 41.024000] [<c0385e80>] do_page_fault+0x395/0x620
> [ 41.024000] [<c0384401>] error_code+0x39/0x40
> [ 41.024000] [<c0184d42>] __lookup_hash+0x9d/0xcc
> [ 41.024000] [<c0184e02>] lookup_one_len+0x71/0x86
> [ 41.024000] [<c01b51da>] create_dir+0x43/0x23f
> [ 41.024000] [<c01b53fc>] sysfs_create_subdir+0x26/0x28
> [ 41.024000] [<c01b6c56>] sysfs_create_group+0x77/0x97
> [ 41.024000] [<c02903af>] dpm_sysfs_add+0x1e/0x20
> [ 41.024000] [<c028f6b3>] device_pm_add+0x64/0x89
> [ 41.024000] [<c028930a>] device_add+0x1d9/0x380
> [ 41.024000] [<c02894cb>] device_register+0x1a/0x20
> [ 41.024000] [<c0289811>] device_create+0xaa/0xc4
> [ 41.024000] [<f8a0c472>] snd_register_device+0xcf/0x104 [snd]
> [ 41.024000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> [ 41.024000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> [ 41.024000] [<c014186c>] sys_init_module+0x163/0x221
> [ 41.024000] [<c0103135>] sysenter_past_esp+0x56/0x8d
> [ 41.024000] =======================
> [ 41.024000] Code: 42 fc 89 c3 8b 40 04 0f 18 00 90 3b 55 ec 75 e6 8b 45 f0 83 c4 10 5b 5e 5f 5d c3 89 1c 24 e8 27 e9 ff ff 89 c6 8b 45 0c 8b 78 48 <ac> ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 bd f6
> [ 41.024000] EIP: [<c01b5771>] sysfs_lookup+0x65/0xb0 SS:ESP 0068:f6c35de0
> [ 41.024000]
>
>
> There's only one BUG at each boot, and both alternate for no particular
> reason.
>
> The lspci, dmesg and .config can be found at:
> http://fdeweerdt.free.fr/drm_bug/
>
> Any ideas for further investigation?
>
> Thanks,
> Frederik
>
> [1] Andrew, could it be possible to put the 'mm.patch' at the very end
> or at the very beginning of the patches? It is misleading to have the
> kernel change it's name in the middle of a bisection :).
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 BUG, drm related
2006-08-15 14:16 ` Andrew Morton
@ 2006-08-15 17:37 ` Frederik Deweerdt
2006-08-15 16:21 ` Andrew Morton
0 siblings, 1 reply; 192+ messages in thread
From: Frederik Deweerdt @ 2006-08-15 17:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, airlied, Jaroslav Kysela, Takashi Iwai
On Tue, Aug 15, 2006 at 07:16:32AM -0700, Andrew Morton wrote:
> On Tue, 15 Aug 2006 13:25:56 +0000
> Frederik Deweerdt <deweerdt@free.fr> wrote:
>
> > On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> > >
> > Hi,
> >
> > There are two BUGs with 2.6.18-rc4-mm1 that seem related to (I did the
> > bisection[1]):
> > git-drm.patch
> > drm-build-fix.patch
> > drm-build-fixes-2.patch
> > allow-drm-detection-of-new-via-chipsets.patch
> > git-drm-build-fix.patch
> >
> > Here's one of the BUGs (the second one is on the web site below).
> > [ 40.276000] [drm:drm_unlock] *ERROR* Process 8914 using kernel context 0
>
> I guess the above is a non-fatal DRM warning.
>
> The below is an ALSA oops.
Hmm, that's what I thought at first, but consider the second BUG (as I
said, both BUGs, the ALSA one and that one appear alternatively):
[ 35.600000] [drm:drm_unlock] *ERROR* Process 8835 using kernel context 0
[ 36.328000] BUG: unable to handle kernel paging request at virtual address 746c6139
[ 36.328000] printing eip:
[ 36.328000] c01fcf39
[ 36.328000] *pde = 00000000
[ 36.328000] Oops: 0000 [#1]
[ 36.328000] PREEMPT
[ 36.328000] last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0/bInterfaceProtocol
[ 36.328000] Modules linked in: snd_seq snd_seq_device ohci_hcd parport_pc parport pcspkr ipw2200 yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd uhci_hcd usbcore cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_centrino freq_table processor ac battery i915 drm tg3 tsdev joydev
[ 36.328000] CPU: 0
[ 36.328000] EIP: 0060:[<c01fcf39>] Not tainted VLI
[ 36.328000] EFLAGS: 00010297 (2.6.18-rc4-def01 #12)
[ 36.328000] EIP is at vsnprintf+0x2da/0x4f9
[ 36.328000] eax: 746c6139 ebx: 0000000a ecx: 746c6139 edx: fffffffe
[ 36.328000] esi: f75fa28c edi: 00000000 ebp: f3701ebc esp: f3701e80
[ 36.328000] ds: 007b es: 007b ss: 0068
[ 36.328000] Process modprobe (pid: 8872, ti=f3700000 task=f7189540 task.ti=f3700000)
[ 36.328000] Stack: f75fa283 f75fb000 00000002 00000000 0000000a fffffffb 00000000 00000000
[ 36.328000] ffffffff ffffffff ffffffff f75fb000 f7129240 f8a1f980 f7129240 f3701ed8
[ 36.328000] c01948a4 f75fa28c 00000d74 c039b84c f3701eec c039ad97 f3701efc c013fd08
[ 36.328000] Call Trace:
[ 36.328000] [<c01948a4>] seq_printf+0x32/0x55
[ 36.328000] [<c013fd08>] print_unload_info+0x6f/0xe9
[ 36.328000] [<c0142073>] m_show+0x4b/0xb5
[ 36.328000] [<c019440f>] seq_read+0x248/0x2ee
[ 36.328000] [<c0171bef>] vfs_read+0x1c1/0x1c6
[ 36.328000] [<c0171f0a>] sys_read+0x4b/0x75
[ 36.328000] [<c0103139>] sysenter_past_esp+0x56/0x8d
[ 36.328000] [<b7fb7410>] 0xb7fb7410
[ 36.328000] [<c0104205>] show_stack_log_lvl+0x98/0xb2
[ 36.328000] [<c0104434>] show_registers+0x1b7/0x22f
[ 36.328000] [<c010460a>] die+0x11e/0x226
[ 36.328000] [<c0379dc2>] do_page_fault+0x38c/0x616
[ 36.328000] [<c0103cad>] error_code+0x39/0x40
[ 36.328000] [<c01948a4>] seq_printf+0x32/0x55
[ 36.328000] [<c013fd08>] print_unload_info+0x6f/0xe9
[ 36.328000] [<c0142073>] m_show+0x4b/0xb5
[ 36.328000] [<c019440f>] seq_read+0x248/0x2ee
[ 36.328000] [<c0171bef>] vfs_read+0x1c1/0x1c6
[ 36.328000] [<c0171f0a>] sys_read+0x4b/0x75
[ 36.328000] [<c0103139>] sysenter_past_esp+0x56/0x8d
[ 36.328000] Code: fd ff ff 83 cf 40 bb 10 00 00 00 eb 88 8b 45 14 83 45 14 04 8b 55 e8 8b 08 b8 e4 81 3a c0 81 f9 ff 0f 00 00 0f 46 c8 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 83 e7 10 89 c3 0f 85
[ 36.328000] EIP: [<c01fcf39>] vsnprintf+0x2da/0x4f9 SS:ESP 0068:f3701e80
Please notice how the BUG comes right after the drm warning.
Regards,
Frederik
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 BUG, drm related
2006-08-15 17:37 ` Frederik Deweerdt
@ 2006-08-15 16:21 ` Andrew Morton
2006-08-18 11:11 ` oops while loading snd-seq-oss (was: Re: 2.6.18-rc4-mm1 BUG, drm related) Frederik Deweerdt
0 siblings, 1 reply; 192+ messages in thread
From: Andrew Morton @ 2006-08-15 16:21 UTC (permalink / raw)
To: Frederik Deweerdt; +Cc: linux-kernel, airlied, Jaroslav Kysela, Takashi Iwai
On Tue, 15 Aug 2006 17:37:26 +0000
Frederik Deweerdt <deweerdt@free.fr> wrote:
> On Tue, Aug 15, 2006 at 07:16:32AM -0700, Andrew Morton wrote:
> > On Tue, 15 Aug 2006 13:25:56 +0000
> > Frederik Deweerdt <deweerdt@free.fr> wrote:
> >
> > > On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> > > >
> > > Hi,
> > >
> > > There are two BUGs with 2.6.18-rc4-mm1 that seem related to (I did the
> > > bisection[1]):
> > > git-drm.patch
> > > drm-build-fix.patch
> > > drm-build-fixes-2.patch
> > > allow-drm-detection-of-new-via-chipsets.patch
> > > git-drm-build-fix.patch
> > >
> > > Here's one of the BUGs (the second one is on the web site below).
> > > [ 40.276000] [drm:drm_unlock] *ERROR* Process 8914 using kernel context 0
> >
> > I guess the above is a non-fatal DRM warning.
> >
> > The below is an ALSA oops.
> Hmm, that's what I thought at first, but consider the second BUG (as I
> said, both BUGs, the ALSA one and that one appear alternatively):
> [ 35.600000] [drm:drm_unlock] *ERROR* Process 8835 using kernel context 0
> [ 36.328000] BUG: unable to handle kernel paging request at virtual address 746c6139
0.7 seconds is a loooong time.
> [ 36.328000] printing eip:
> [ 36.328000] c01fcf39
> [ 36.328000] *pde = 00000000
> [ 36.328000] Oops: 0000 [#1]
> [ 36.328000] PREEMPT
> [ 36.328000] last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0/bInterfaceProtocol
> [ 36.328000] Modules linked in: snd_seq snd_seq_device ohci_hcd parport_pc parport pcspkr ipw2200 yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd uhci_hcd usbcore cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_centrino freq_table processor ac battery i915 drm tg3 tsdev joydev
> [ 36.328000] CPU: 0
> [ 36.328000] EIP: 0060:[<c01fcf39>] Not tainted VLI
> [ 36.328000] EFLAGS: 00010297 (2.6.18-rc4-def01 #12)
> [ 36.328000] EIP is at vsnprintf+0x2da/0x4f9
> [ 36.328000] eax: 746c6139 ebx: 0000000a ecx: 746c6139 edx: fffffffe
> [ 36.328000] esi: f75fa28c edi: 00000000 ebp: f3701ebc esp: f3701e80
> [ 36.328000] ds: 007b es: 007b ss: 0068
> [ 36.328000] Process modprobe (pid: 8872, ti=f3700000 task=f7189540 task.ti=f3700000)
> [ 36.328000] Stack: f75fa283 f75fb000 00000002 00000000 0000000a fffffffb 00000000 00000000
> [ 36.328000] ffffffff ffffffff ffffffff f75fb000 f7129240 f8a1f980 f7129240 f3701ed8
> [ 36.328000] c01948a4 f75fa28c 00000d74 c039b84c f3701eec c039ad97 f3701efc c013fd08
> [ 36.328000] Call Trace:
> [ 36.328000] [<c01948a4>] seq_printf+0x32/0x55
> [ 36.328000] [<c013fd08>] print_unload_info+0x6f/0xe9
> [ 36.328000] [<c0142073>] m_show+0x4b/0xb5
> [ 36.328000] [<c019440f>] seq_read+0x248/0x2ee
> [ 36.328000] [<c0171bef>] vfs_read+0x1c1/0x1c6
> [ 36.328000] [<c0171f0a>] sys_read+0x4b/0x75
> [ 36.328000] [<c0103139>] sysenter_past_esp+0x56/0x8d
> [ 36.328000] [<b7fb7410>] 0xb7fb7410
> [ 36.328000] [<c0104205>] show_stack_log_lvl+0x98/0xb2
> [ 36.328000] [<c0104434>] show_registers+0x1b7/0x22f
> [ 36.328000] [<c010460a>] die+0x11e/0x226
> [ 36.328000] [<c0379dc2>] do_page_fault+0x38c/0x616
> [ 36.328000] [<c0103cad>] error_code+0x39/0x40
> [ 36.328000] [<c01948a4>] seq_printf+0x32/0x55
> [ 36.328000] [<c013fd08>] print_unload_info+0x6f/0xe9
> [ 36.328000] [<c0142073>] m_show+0x4b/0xb5
> [ 36.328000] [<c019440f>] seq_read+0x248/0x2ee
> [ 36.328000] [<c0171bef>] vfs_read+0x1c1/0x1c6
> [ 36.328000] [<c0171f0a>] sys_read+0x4b/0x75
> [ 36.328000] [<c0103139>] sysenter_past_esp+0x56/0x8d
> [ 36.328000] Code: fd ff ff 83 cf 40 bb 10 00 00 00 eb 88 8b 45 14 83 45 14 04 8b 55 e8 8b 08 b8 e4 81 3a c0 81 f9 ff 0f 00 00 0f 46 c8 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 83 e7 10 89 c3 0f 85
> [ 36.328000] EIP: [<c01fcf39>] vsnprintf+0x2da/0x4f9 SS:ESP 0068:f3701e80
>
> Please notice how the BUG comes right after the drm warning.
Coincidence, I'd say.
This one looks like something horrid happened in the module dependency
chain. Heaven knows. Using ascii `tle9' as a pointer?
CONFIG_DEBUG_PAGEALLOC might tell us more.
^ permalink raw reply [flat|nested] 192+ messages in thread
* oops while loading snd-seq-oss (was: Re: 2.6.18-rc4-mm1 BUG, drm related)
2006-08-15 16:21 ` Andrew Morton
@ 2006-08-18 11:11 ` Frederik Deweerdt
2006-08-18 15:52 ` Andrew Morton
0 siblings, 1 reply; 192+ messages in thread
From: Frederik Deweerdt @ 2006-08-18 11:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, airlied, Jaroslav Kysela, Takashi Iwai
On Tue, Aug 15, 2006 at 09:21:46AM -0700, Andrew Morton wrote:
> On Tue, 15 Aug 2006 17:37:26 +0000
> Frederik Deweerdt <deweerdt@free.fr> wrote:
>
> > On Tue, Aug 15, 2006 at 07:16:32AM -0700, Andrew Morton wrote:
> > > On Tue, 15 Aug 2006 13:25:56 +0000
> > > Frederik Deweerdt <deweerdt@free.fr> wrote:
> > >
> > > > On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
> > > > >
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> > > > >
> > > > Hi,
> > > >
> > > > There are two BUGs with 2.6.18-rc4-mm1 that seem related to (I did the
> > > > bisection[1]):
> > > > git-drm.patch
> > > > drm-build-fix.patch
> > > > drm-build-fixes-2.patch
> > > > allow-drm-detection-of-new-via-chipsets.patch
> > > > git-drm-build-fix.patch
> > > >
> > > > Here's one of the BUGs (the second one is on the web site below).
> > > > [ 40.276000] [drm:drm_unlock] *ERROR* Process 8914 using kernel context 0
> > >
> > > I guess the above is a non-fatal DRM warning.
> > >
> > > The below is an ALSA oops.
> > Hmm, that's what I thought at first, but consider the second BUG (as I
> > said, both BUGs, the ALSA one and that one appear alternatively):
> > [ 35.600000] [drm:drm_unlock] *ERROR* Process 8835 using kernel context 0
> > [ 36.328000] BUG: unable to handle kernel paging request at virtual address 746c6139
>
> 0.7 seconds is a loooong time.
Ok, I think I've been blinded by the coincidence :) This may be a
combination of driver changes and a ALSA bug.
>
> > [ 36.328000] printing eip:
> > [ 36.328000] c01fcf39
> > [ 36.328000] *pde = 00000000
> > [ 36.328000] Oops: 0000 [#1]
> > [ 36.328000] PREEMPT
> > [ 36.328000] last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0/bInterfaceProtocol
> > [ 36.328000] Modules linked in: snd_seq snd_seq_device ohci_hcd parport_pc parport pcspkr ipw2200 yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd uhci_hcd usbcore cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_centrino freq_table processor ac battery i915 drm tg3 tsdev joydev
> > [ 36.328000] CPU: 0
> > [ 36.328000] EIP: 0060:[<c01fcf39>] Not tainted VLI
> > [ 36.328000] EFLAGS: 00010297 (2.6.18-rc4-def01 #12)
> > [ 36.328000] EIP is at vsnprintf+0x2da/0x4f9
> > [ 36.328000] eax: 746c6139 ebx: 0000000a ecx: 746c6139 edx: fffffffe
> > [ 36.328000] esi: f75fa28c edi: 00000000 ebp: f3701ebc esp: f3701e80
> > [ 36.328000] ds: 007b es: 007b ss: 0068
> > [ 36.328000] Process modprobe (pid: 8872, ti=f3700000 task=f7189540 task.ti=f3700000)
> > [ 36.328000] Stack: f75fa283 f75fb000 00000002 00000000 0000000a fffffffb 00000000 00000000
> > [ 36.328000] ffffffff ffffffff ffffffff f75fb000 f7129240 f8a1f980 f7129240 f3701ed8
> > [ 36.328000] c01948a4 f75fa28c 00000d74 c039b84c f3701eec c039ad97 f3701efc c013fd08
> > [ 36.328000] Call Trace:
> > [ 36.328000] [<c01948a4>] seq_printf+0x32/0x55
> > [ 36.328000] [<c013fd08>] print_unload_info+0x6f/0xe9
> > [ 36.328000] [<c0142073>] m_show+0x4b/0xb5
> > [ 36.328000] [<c019440f>] seq_read+0x248/0x2ee
> > [ 36.328000] [<c0171bef>] vfs_read+0x1c1/0x1c6
> > [ 36.328000] [<c0171f0a>] sys_read+0x4b/0x75
> > [ 36.328000] [<c0103139>] sysenter_past_esp+0x56/0x8d
> > [ 36.328000] [<b7fb7410>] 0xb7fb7410
> > [ 36.328000] [<c0104205>] show_stack_log_lvl+0x98/0xb2
> > [ 36.328000] [<c0104434>] show_registers+0x1b7/0x22f
> > [ 36.328000] [<c010460a>] die+0x11e/0x226
> > [ 36.328000] [<c0379dc2>] do_page_fault+0x38c/0x616
> > [ 36.328000] [<c0103cad>] error_code+0x39/0x40
> > [ 36.328000] [<c01948a4>] seq_printf+0x32/0x55
> > [ 36.328000] [<c013fd08>] print_unload_info+0x6f/0xe9
> > [ 36.328000] [<c0142073>] m_show+0x4b/0xb5
> > [ 36.328000] [<c019440f>] seq_read+0x248/0x2ee
> > [ 36.328000] [<c0171bef>] vfs_read+0x1c1/0x1c6
> > [ 36.328000] [<c0171f0a>] sys_read+0x4b/0x75
> > [ 36.328000] [<c0103139>] sysenter_past_esp+0x56/0x8d
> > [ 36.328000] Code: fd ff ff 83 cf 40 bb 10 00 00 00 eb 88 8b 45 14 83 45 14 04 8b 55 e8 8b 08 b8 e4 81 3a c0 81 f9 ff 0f 00 00 0f 46 c8 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 83 e7 10 89 c3 0f 85
> > [ 36.328000] EIP: [<c01fcf39>] vsnprintf+0x2da/0x4f9 SS:ESP 0068:f3701e80
> >
> > Please notice how the BUG comes right after the drm warning.
>
> Coincidence, I'd say.
>
> This one looks like something horrid happened in the module dependency
> chain. Heaven knows. Using ascii `tle9' as a pointer?
Maybe both BUGs have the same cause, but there must be some kind of race
that makes one appear before the other?
>
> CONFIG_DEBUG_PAGEALLOC might tell us more.
I've tried enabling it, at it appears that we catch an earlier error:
[ 34.988000] [drm:drm_unlock] *ERROR* Process 8826 using kernel context 0
[ 35.644000] BUG: unable to handle kernel paging request at virtual address 00716573
[ 35.644000] printing eip:
[ 35.644000] c01aeacb
[ 35.644000] *pde = 00000000
[ 35.644000] Oops: 0000 [#1]
[ 35.644000] PREEMPT DEBUG_PAGEALLOC
[ 35.644000] last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0/bInterfaceProtocol
[ 35.644000] Modules linked in: snd_seq snd_seq_device ohci_hcd parport_pc parport pcspkr ipw2200 yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd uhci_hcd usbcore cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_centrino freq_table processor ac battery i915 drm tg3 joydev tsdev
[ 35.644000] CPU: 0
[ 35.644000] EIP: 0060:[<c01aeacb>] Not tainted VLI
[ 35.644000] EFLAGS: 00210246 (2.6.18-rc4-def01 #18)
[ 35.644000] EIP is at sysfs_dirent_exist+0x4b/0x70
[ 35.644000] eax: 00716573 ebx: f36f263c ecx: f71962a0 edx: f36f263c
[ 35.644000] esi: 00716573 edi: c03b4177 ebp: f711fe90 esp: f711fe7c
[ 35.644000] ds: 007b es: 007b ss: 0068
[ 35.644000] Process modprobe (pid: 8864, ti=f711e000 task=c193b540 task.ti=f711e000)
[ 35.644000] Stack: f36f263c f36f26a0 f36bf120 c03b4177 ffffffef f711feb0 c01afb95 f36f2694
[ 35.644000] c03b4177 f7ba4108 00000000 f7ba4000 f7ba4108 f711fed8 c027ece1 f7ba4108
[ 35.644000] f74b5d08 c03b4177 f7ba416c f7ba4000 f71962a0 f7ba4000 f7ba4108 f711ff08
[ 35.644000] Call Trace:
[ 35.644000] [<c01afb95>] sysfs_create_link+0x4d/0xa2
[ 35.644000] [<c027ece1>] device_add_class_symlinks+0xb0/0x14d
[ 35.644000] [<c027eff1>] device_add+0x1a0/0x37e
[ 35.644000] [<c027f1e9>] device_register+0x1a/0x20
[ 35.644000] [<c027f52f>] device_create+0xaa/0xc4
[ 35.644000] [<f8a0e472>] snd_register_device+0xcf/0x104 [snd]
[ 35.644000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
[ 35.644000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
[ 35.644000] [<c0141ab9>] sys_init_module+0x163/0x221
[ 35.644000] [<c0103139>] sysenter_past_esp+0x56/0x8d
[ 35.644000] [<b7fcd410>] 0xb7fcd410
[ 35.644000] [<c0104205>] show_stack_log_lvl+0x98/0xb2
[ 35.644000] [<c0104434>] show_registers+0x1b7/0x22f
[ 35.644000] [<c0104616>] die+0x12a/0x232
[ 35.644000] [<c0377042>] do_page_fault+0x38c/0x616
[ 35.644000] [<c0103cad>] error_code+0x39/0x40
[ 35.644000] [<c01afb95>] sysfs_create_link+0x4d/0xa2
[ 35.644000] [<c027ece1>] device_add_class_symlinks+0xb0/0x14d
[ 35.644000] [<c027eff1>] device_add+0x1a0/0x37e
[ 35.644000] [<c027f1e9>] device_register+0x1a/0x20
[ 35.644000] [<c027f52f>] device_create+0xaa/0xc4
[ 35.644000] [<f8a0e472>] snd_register_device+0xcf/0x104 [snd]
[ 35.644000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
[ 35.644000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
[ 35.644000] [<c0141ab9>] sys_init_module+0x163/0x221
[ 35.644000] [<c0103139>] sysenter_past_esp+0x56/0x8d
[ 35.644000] Code: f0 eb 12 8b 53 04 8d 42 fc 89 c3 8b 40 04 0f 18 00 90 3b 55 f0 74 2f 8b 43 14 85 c0 74 e5 89 1c 24 e8 39 f0 ff ff 8b 7d 0c 89 c6 <ac> ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 c4 b8
[ 35.644000] EIP: [<c01aeacb>] sysfs_dirent_exist+0x4b/0x70 SS:ESP 0068:f711fe7c
[ 35.644000]
It looks like %eax is in fact a sort of "seq" string, but I couldn't
figure out why we ended with this pointer :(
There are two facts that might be of interest and that I didn't notice at first:
- modprobe segfaults while loading snd-seq-oss
- if, after getting the oops, I issue a 'find /sys', the process gets
stuck at /sys/class/sound. SysRq+t shows the following stack trace:
[ 132.428000] find D C0372E43 6800 8934 8930 (NOTLB)
[ 132.428000] f3105e34 c053271c 00000001 c0372e43 00000000 f3105f14 00000000 00000000
[ 132.428000] 00000000 dce2a7ac 00000014 00121eac 00000000 f7562000 c19fd664 00000000
[ 132.428000] dd0d9200 00000014 c19fd540 00000000 00000000 00000002 f7788898 00200246
[ 132.428000] Call Trace:
[ 132.428000] [<c0373e12>] __mutex_lock_slowpath+0xcc/0x29b
[ 132.428000] [<c0373d36>] mutex_lock+0x24/0x2a
[ 132.428000] [<c01af57a>] sysfs_dir_open+0x25/0x63
[ 132.428000] [<c016df8a>] __dentry_open+0x19d/0x290
[ 132.428000] [<c016e1a8>] nameidata_to_filp+0x38/0x52
[ 132.428000] [<c016e0cc>] do_filp_open+0x4f/0x56
[ 132.428000] [<c016e432>] do_sys_open+0x60/0x10a
[ 132.428000] [<c016e503>] sys_open+0x27/0x29
[ 132.428000] [<c0103139>] sysenter_past_esp+0x56/0x8d
[ 132.428000] [<b7f3b410>] 0xb7f3b410
[ 132.428000] [<c0373e12>] __mutex_lock_slowpath+0xcc/0x29b
[ 132.428000] [<c0373d36>] mutex_lock+0x24/0x2a
[ 132.428000] [<c01af57a>] sysfs_dir_open+0x25/0x63
[ 132.428000] [<c016df8a>] __dentry_open+0x19d/0x290
[ 132.428000] [<c016e1a8>] nameidata_to_filp+0x38/0x52
[ 132.428000] [<c016e0cc>] do_filp_open+0x4f/0x56
[ 132.428000] [<c016e432>] do_sys_open+0x60/0x10a
[ 132.428000] [<c016e503>] sys_open+0x27/0x29
[ 132.428000] [<c0103139>] sysenter_past_esp+0x56/0x8d
Thanks,
Frederik
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: oops while loading snd-seq-oss (was: Re: 2.6.18-rc4-mm1 BUG, drm related)
2006-08-18 11:11 ` oops while loading snd-seq-oss (was: Re: 2.6.18-rc4-mm1 BUG, drm related) Frederik Deweerdt
@ 2006-08-18 15:52 ` Andrew Morton
2006-08-18 15:58 ` Takashi Iwai
2006-08-18 18:45 ` Frederik Deweerdt
0 siblings, 2 replies; 192+ messages in thread
From: Andrew Morton @ 2006-08-18 15:52 UTC (permalink / raw)
To: Frederik Deweerdt; +Cc: linux-kernel, airlied, Jaroslav Kysela, Takashi Iwai
On Fri, 18 Aug 2006 11:11:18 +0000
Frederik Deweerdt <deweerdt@free.fr> wrote:
> > CONFIG_DEBUG_PAGEALLOC might tell us more.
> I've tried enabling it, at it appears that we catch an earlier error:
> [ 34.988000] [drm:drm_unlock] *ERROR* Process 8826 using kernel context 0
> [ 35.644000] BUG: unable to handle kernel paging request at virtual address 00716573
> [ 35.644000] printing eip:
> [ 35.644000] c01aeacb
> [ 35.644000] *pde = 00000000
> [ 35.644000] Oops: 0000 [#1]
> [ 35.644000] PREEMPT DEBUG_PAGEALLOC
> [ 35.644000] last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0/bInterfaceProtocol
> [ 35.644000] Modules linked in: snd_seq snd_seq_device ohci_hcd parport_pc parport pcspkr ipw2200 yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd uhci_hcd usbcore cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_centrino freq_table processor ac battery i915 drm tg3 joydev tsdev
> [ 35.644000] CPU: 0
> [ 35.644000] EIP: 0060:[<c01aeacb>] Not tainted VLI
> [ 35.644000] EFLAGS: 00210246 (2.6.18-rc4-def01 #18)
> [ 35.644000] EIP is at sysfs_dirent_exist+0x4b/0x70
> [ 35.644000] eax: 00716573 ebx: f36f263c ecx: f71962a0 edx: f36f263c
> [ 35.644000] esi: 00716573 edi: c03b4177 ebp: f711fe90 esp: f711fe7c
> [ 35.644000] ds: 007b es: 007b ss: 0068
> [ 35.644000] Process modprobe (pid: 8864, ti=f711e000 task=c193b540 task.ti=f711e000)
> [ 35.644000] Stack: f36f263c f36f26a0 f36bf120 c03b4177 ffffffef f711feb0 c01afb95 f36f2694
> [ 35.644000] c03b4177 f7ba4108 00000000 f7ba4000 f7ba4108 f711fed8 c027ece1 f7ba4108
> [ 35.644000] f74b5d08 c03b4177 f7ba416c f7ba4000 f71962a0 f7ba4000 f7ba4108 f711ff08
> [ 35.644000] Call Trace:
> [ 35.644000] [<c01afb95>] sysfs_create_link+0x4d/0xa2
> [ 35.644000] [<c027ece1>] device_add_class_symlinks+0xb0/0x14d
> [ 35.644000] [<c027eff1>] device_add+0x1a0/0x37e
> [ 35.644000] [<c027f1e9>] device_register+0x1a/0x20
> [ 35.644000] [<c027f52f>] device_create+0xaa/0xc4
> [ 35.644000] [<f8a0e472>] snd_register_device+0xcf/0x104 [snd]
> [ 35.644000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> [ 35.644000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> [ 35.644000] [<c0141ab9>] sys_init_module+0x163/0x221
> [ 35.644000] [<c0103139>] sysenter_past_esp+0x56/0x8d
> [ 35.644000] [<b7fcd410>] 0xb7fcd410
> [ 35.644000] [<c0104205>] show_stack_log_lvl+0x98/0xb2
> [ 35.644000] [<c0104434>] show_registers+0x1b7/0x22f
> [ 35.644000] [<c0104616>] die+0x12a/0x232
> [ 35.644000] [<c0377042>] do_page_fault+0x38c/0x616
> [ 35.644000] [<c0103cad>] error_code+0x39/0x40
> [ 35.644000] [<c01afb95>] sysfs_create_link+0x4d/0xa2
> [ 35.644000] [<c027ece1>] device_add_class_symlinks+0xb0/0x14d
> [ 35.644000] [<c027eff1>] device_add+0x1a0/0x37e
> [ 35.644000] [<c027f1e9>] device_register+0x1a/0x20
> [ 35.644000] [<c027f52f>] device_create+0xaa/0xc4
> [ 35.644000] [<f8a0e472>] snd_register_device+0xcf/0x104 [snd]
> [ 35.644000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> [ 35.644000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> [ 35.644000] [<c0141ab9>] sys_init_module+0x163/0x221
> [ 35.644000] [<c0103139>] sysenter_past_esp+0x56/0x8d
> [ 35.644000] Code: f0 eb 12 8b 53 04 8d 42 fc 89 c3 8b 40 04 0f 18 00 90 3b 55 f0 74 2f 8b 43 14 85 c0 74 e5 89 1c 24 e8 39 f0 ff ff 8b 7d 0c 89 c6 <ac> ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 c4 b8
> [ 35.644000] EIP: [<c01aeacb>] sysfs_dirent_exist+0x4b/0x70 SS:ESP 0068:f711fe7c
> [ 35.644000]
> It looks like %eax is in fact a sort of "seq" string, but I couldn't
> figure out why we ended with this pointer :(
These sorts of crashes down in sysfs often are hard to diagnose. What did
the driver do to cause this? Dunno. But it continues to look like an ALSA
thing.
If you had CONFIG_PCI_MULTITHREAD_PROBE enabled, please try disabling it.
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: oops while loading snd-seq-oss (was: Re: 2.6.18-rc4-mm1 BUG, drm related)
2006-08-18 15:52 ` Andrew Morton
@ 2006-08-18 15:58 ` Takashi Iwai
2006-08-18 18:44 ` Frederik Deweerdt
2006-08-18 18:45 ` Frederik Deweerdt
1 sibling, 1 reply; 192+ messages in thread
From: Takashi Iwai @ 2006-08-18 15:58 UTC (permalink / raw)
To: Andrew Morton; +Cc: Frederik Deweerdt, linux-kernel, airlied, Jaroslav Kysela
At Fri, 18 Aug 2006 08:52:20 -0700,
Andrew Morton wrote:
>
> On Fri, 18 Aug 2006 11:11:18 +0000
> Frederik Deweerdt <deweerdt@free.fr> wrote:
>
> > > CONFIG_DEBUG_PAGEALLOC might tell us more.
> > I've tried enabling it, at it appears that we catch an earlier error:
> > [ 34.988000] [drm:drm_unlock] *ERROR* Process 8826 using kernel context 0
> > [ 35.644000] BUG: unable to handle kernel paging request at virtual address 00716573
> > [ 35.644000] printing eip:
> > [ 35.644000] c01aeacb
> > [ 35.644000] *pde = 00000000
> > [ 35.644000] Oops: 0000 [#1]
> > [ 35.644000] PREEMPT DEBUG_PAGEALLOC
> > [ 35.644000] last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0/bInterfaceProtocol
> > [ 35.644000] Modules linked in: snd_seq snd_seq_device ohci_hcd parport_pc parport pcspkr ipw2200 yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd uhci_hcd usbcore cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_centrino freq_table processor ac battery i915 drm tg3 joydev tsdev
> > [ 35.644000] CPU: 0
> > [ 35.644000] EIP: 0060:[<c01aeacb>] Not tainted VLI
> > [ 35.644000] EFLAGS: 00210246 (2.6.18-rc4-def01 #18)
> > [ 35.644000] EIP is at sysfs_dirent_exist+0x4b/0x70
> > [ 35.644000] eax: 00716573 ebx: f36f263c ecx: f71962a0 edx: f36f263c
> > [ 35.644000] esi: 00716573 edi: c03b4177 ebp: f711fe90 esp: f711fe7c
> > [ 35.644000] ds: 007b es: 007b ss: 0068
> > [ 35.644000] Process modprobe (pid: 8864, ti=f711e000 task=c193b540 task.ti=f711e000)
> > [ 35.644000] Stack: f36f263c f36f26a0 f36bf120 c03b4177 ffffffef f711feb0 c01afb95 f36f2694
> > [ 35.644000] c03b4177 f7ba4108 00000000 f7ba4000 f7ba4108 f711fed8 c027ece1 f7ba4108
> > [ 35.644000] f74b5d08 c03b4177 f7ba416c f7ba4000 f71962a0 f7ba4000 f7ba4108 f711ff08
> > [ 35.644000] Call Trace:
> > [ 35.644000] [<c01afb95>] sysfs_create_link+0x4d/0xa2
> > [ 35.644000] [<c027ece1>] device_add_class_symlinks+0xb0/0x14d
> > [ 35.644000] [<c027eff1>] device_add+0x1a0/0x37e
> > [ 35.644000] [<c027f1e9>] device_register+0x1a/0x20
> > [ 35.644000] [<c027f52f>] device_create+0xaa/0xc4
> > [ 35.644000] [<f8a0e472>] snd_register_device+0xcf/0x104 [snd]
> > [ 35.644000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> > [ 35.644000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> > [ 35.644000] [<c0141ab9>] sys_init_module+0x163/0x221
> > [ 35.644000] [<c0103139>] sysenter_past_esp+0x56/0x8d
> > [ 35.644000] [<b7fcd410>] 0xb7fcd410
> > [ 35.644000] [<c0104205>] show_stack_log_lvl+0x98/0xb2
> > [ 35.644000] [<c0104434>] show_registers+0x1b7/0x22f
> > [ 35.644000] [<c0104616>] die+0x12a/0x232
> > [ 35.644000] [<c0377042>] do_page_fault+0x38c/0x616
> > [ 35.644000] [<c0103cad>] error_code+0x39/0x40
> > [ 35.644000] [<c01afb95>] sysfs_create_link+0x4d/0xa2
> > [ 35.644000] [<c027ece1>] device_add_class_symlinks+0xb0/0x14d
> > [ 35.644000] [<c027eff1>] device_add+0x1a0/0x37e
> > [ 35.644000] [<c027f1e9>] device_register+0x1a/0x20
> > [ 35.644000] [<c027f52f>] device_create+0xaa/0xc4
> > [ 35.644000] [<f8a0e472>] snd_register_device+0xcf/0x104 [snd]
> > [ 35.644000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> > [ 35.644000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> > [ 35.644000] [<c0141ab9>] sys_init_module+0x163/0x221
> > [ 35.644000] [<c0103139>] sysenter_past_esp+0x56/0x8d
> > [ 35.644000] Code: f0 eb 12 8b 53 04 8d 42 fc 89 c3 8b 40 04 0f 18 00 90 3b 55 f0 74 2f 8b 43 14 85 c0 74 e5 89 1c 24 e8 39 f0 ff ff 8b 7d 0c 89 c6 <ac> ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 c4 b8
> > [ 35.644000] EIP: [<c01aeacb>] sysfs_dirent_exist+0x4b/0x70 SS:ESP 0068:f711fe7c
> > [ 35.644000]
> > It looks like %eax is in fact a sort of "seq" string, but I couldn't
> > figure out why we ended with this pointer :(
>
> These sorts of crashes down in sysfs often are hard to diagnose. What did
> the driver do to cause this? Dunno. But it continues to look like an ALSA
> thing.
Yep, but it's hard to figure out without a crystal ball...
> If you had CONFIG_PCI_MULTITHREAD_PROBE enabled, please try disabling it.
If the oops occurs at the manual loading of snd-seq-oss module, this
options would be hardly related. But, it's worth to try.
Frederik, what hardware are you using? Is it emu10k1?
I'm wondering how is the order of module/driver initialization.
Does this bug happens if you load snd-seq manually before snd-seq-oss?
Last but not least, is the oops avoided when you disable alsa-git
patch?
Takashi
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: oops while loading snd-seq-oss (was: Re: 2.6.18-rc4-mm1 BUG, drm related)
2006-08-18 15:58 ` Takashi Iwai
@ 2006-08-18 18:44 ` Frederik Deweerdt
2006-08-18 19:43 ` Frederik Deweerdt
0 siblings, 1 reply; 192+ messages in thread
From: Frederik Deweerdt @ 2006-08-18 18:44 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Andrew Morton, linux-kernel, airlied, Jaroslav Kysela
On Fri, Aug 18, 2006 at 05:58:18PM +0200, Takashi Iwai wrote:
> At Fri, 18 Aug 2006 08:52:20 -0700,
> Andrew Morton wrote:
> >
> > On Fri, 18 Aug 2006 11:11:18 +0000
> > Frederik Deweerdt <deweerdt@free.fr> wrote:
> >
> > > > CONFIG_DEBUG_PAGEALLOC might tell us more.
> > > I've tried enabling it, at it appears that we catch an earlier error:
> > > [ 34.988000] [drm:drm_unlock] *ERROR* Process 8826 using kernel context 0
> > > [ 35.644000] BUG: unable to handle kernel paging request at virtual address 00716573
> > > [ 35.644000] printing eip:
> > > [ 35.644000] c01aeacb
> > > [ 35.644000] *pde = 00000000
> > > [ 35.644000] Oops: 0000 [#1]
> > > [ 35.644000] PREEMPT DEBUG_PAGEALLOC
> > > [ 35.644000] last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0/bInterfaceProtocol
> > > [ 35.644000] Modules linked in: snd_seq snd_seq_device ohci_hcd parport_pc parport pcspkr ipw2200 yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd uhci_hcd usbcore cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_centrino freq_table processor ac battery i915 drm tg3 joydev tsdev
> > > [ 35.644000] CPU: 0
> > > [ 35.644000] EIP: 0060:[<c01aeacb>] Not tainted VLI
> > > [ 35.644000] EFLAGS: 00210246 (2.6.18-rc4-def01 #18)
> > > [ 35.644000] EIP is at sysfs_dirent_exist+0x4b/0x70
> > > [ 35.644000] eax: 00716573 ebx: f36f263c ecx: f71962a0 edx: f36f263c
> > > [ 35.644000] esi: 00716573 edi: c03b4177 ebp: f711fe90 esp: f711fe7c
> > > [ 35.644000] ds: 007b es: 007b ss: 0068
> > > [ 35.644000] Process modprobe (pid: 8864, ti=f711e000 task=c193b540 task.ti=f711e000)
> > > [ 35.644000] Stack: f36f263c f36f26a0 f36bf120 c03b4177 ffffffef f711feb0 c01afb95 f36f2694
> > > [ 35.644000] c03b4177 f7ba4108 00000000 f7ba4000 f7ba4108 f711fed8 c027ece1 f7ba4108
> > > [ 35.644000] f74b5d08 c03b4177 f7ba416c f7ba4000 f71962a0 f7ba4000 f7ba4108 f711ff08
> > > [ 35.644000] Call Trace:
> > > [ 35.644000] [<c01afb95>] sysfs_create_link+0x4d/0xa2
> > > [ 35.644000] [<c027ece1>] device_add_class_symlinks+0xb0/0x14d
> > > [ 35.644000] [<c027eff1>] device_add+0x1a0/0x37e
> > > [ 35.644000] [<c027f1e9>] device_register+0x1a/0x20
> > > [ 35.644000] [<c027f52f>] device_create+0xaa/0xc4
> > > [ 35.644000] [<f8a0e472>] snd_register_device+0xcf/0x104 [snd]
> > > [ 35.644000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> > > [ 35.644000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> > > [ 35.644000] [<c0141ab9>] sys_init_module+0x163/0x221
> > > [ 35.644000] [<c0103139>] sysenter_past_esp+0x56/0x8d
> > > [ 35.644000] [<b7fcd410>] 0xb7fcd410
> > > [ 35.644000] [<c0104205>] show_stack_log_lvl+0x98/0xb2
> > > [ 35.644000] [<c0104434>] show_registers+0x1b7/0x22f
> > > [ 35.644000] [<c0104616>] die+0x12a/0x232
> > > [ 35.644000] [<c0377042>] do_page_fault+0x38c/0x616
> > > [ 35.644000] [<c0103cad>] error_code+0x39/0x40
> > > [ 35.644000] [<c01afb95>] sysfs_create_link+0x4d/0xa2
> > > [ 35.644000] [<c027ece1>] device_add_class_symlinks+0xb0/0x14d
> > > [ 35.644000] [<c027eff1>] device_add+0x1a0/0x37e
> > > [ 35.644000] [<c027f1e9>] device_register+0x1a/0x20
> > > [ 35.644000] [<c027f52f>] device_create+0xaa/0xc4
> > > [ 35.644000] [<f8a0e472>] snd_register_device+0xcf/0x104 [snd]
> > > [ 35.644000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> > > [ 35.644000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> > > [ 35.644000] [<c0141ab9>] sys_init_module+0x163/0x221
> > > [ 35.644000] [<c0103139>] sysenter_past_esp+0x56/0x8d
> > > [ 35.644000] Code: f0 eb 12 8b 53 04 8d 42 fc 89 c3 8b 40 04 0f 18 00 90 3b 55 f0 74 2f 8b 43 14 85 c0 74 e5 89 1c 24 e8 39 f0 ff ff 8b 7d 0c 89 c6 <ac> ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 c4 b8
> > > [ 35.644000] EIP: [<c01aeacb>] sysfs_dirent_exist+0x4b/0x70 SS:ESP 0068:f711fe7c
> > > [ 35.644000]
> > > It looks like %eax is in fact a sort of "seq" string, but I couldn't
> > > figure out why we ended with this pointer :(
> >
> > If you had CONFIG_PCI_MULTITHREAD_PROBE enabled, please try disabling it.
It's not set
>
> If the oops occurs at the manual loading of snd-seq-oss module, this
> options would be hardly related. But, it's worth to try.
>
> Frederik, what hardware are you using? Is it emu10k1?
You'll find the lspci output, dmesg, .config at
http://fdeweerdt.free.fr/drm_bug/, I mentioned it previously on the
thread, but at that time I thought it was related with drm (I must have
messed up with my bisection) so you weren't CC'd, sorry.
Anyway, the relevant line in the lspci is:
00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
Which uses the snd_intel8x0 module.
> I'm wondering how is the order of module/driver initialization.
> Does this bug happens if you load snd-seq manually before snd-seq-oss?
I'll try and send you the results asap.
>
> Last but not least, is the oops avoided when you disable alsa-git
> patch?
Ditto.
Thanks,
Frederik
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: oops while loading snd-seq-oss (was: Re: 2.6.18-rc4-mm1 BUG, drm related)
2006-08-18 18:44 ` Frederik Deweerdt
@ 2006-08-18 19:43 ` Frederik Deweerdt
0 siblings, 0 replies; 192+ messages in thread
From: Frederik Deweerdt @ 2006-08-18 19:43 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Andrew Morton, linux-kernel, airlied, Jaroslav Kysela
On Fri, Aug 18, 2006 at 06:44:11PM +0000, Frederik Deweerdt wrote:
> On Fri, Aug 18, 2006 at 05:58:18PM +0200, Takashi Iwai wrote:
> > At Fri, 18 Aug 2006 08:52:20 -0700,
> > Andrew Morton wrote:
> > >
> > Frederik, what hardware are you using? Is it emu10k1?
> You'll find the lspci output, dmesg, .config at
> http://fdeweerdt.free.fr/drm_bug/, I mentioned it previously on the
> thread, but at that time I thought it was related with drm (I must have
> messed up with my bisection) so you weren't CC'd, sorry.
>
Err, turns up I maybe was right with the bisection. I think that the
drm patches mess my box in some way that it makes ALSA fail: I was
trying to load the modules by hand as you suggested, but the machine
rebooted instantaneously.
As I was about to retry, it occured to me that maybe this drm had
something to do after all and I tried shutting down the X server _before_
loading the ALSA modules: box freeze.
Now, the box is behaving OK (no oopses) with the DRI line commented in
the xorg.conf file. I'll try to narrow down which part of the DRM update
is causing such a strange behaviour. Sorry for the noise Takashi.
Regards,
Frederik
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: oops while loading snd-seq-oss (was: Re: 2.6.18-rc4-mm1 BUG, drm related)
2006-08-18 15:52 ` Andrew Morton
2006-08-18 15:58 ` Takashi Iwai
@ 2006-08-18 18:45 ` Frederik Deweerdt
1 sibling, 0 replies; 192+ messages in thread
From: Frederik Deweerdt @ 2006-08-18 18:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, airlied, Jaroslav Kysela, Takashi Iwai
On Fri, Aug 18, 2006 at 08:52:20AM -0700, Andrew Morton wrote:
> On Fri, 18 Aug 2006 11:11:18 +0000
> Frederik Deweerdt <deweerdt@free.fr> wrote:
>
> > > CONFIG_DEBUG_PAGEALLOC might tell us more.
> > I've tried enabling it, at it appears that we catch an earlier error:
> > [ 34.988000] [drm:drm_unlock] *ERROR* Process 8826 using kernel context 0
> > [ 35.644000] BUG: unable to handle kernel paging request at virtual address 00716573
> > [ 35.644000] printing eip:
> > [ 35.644000] c01aeacb
> > [ 35.644000] *pde = 00000000
> > [ 35.644000] Oops: 0000 [#1]
> > [ 35.644000] PREEMPT DEBUG_PAGEALLOC
> > [ 35.644000] last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0/bInterfaceProtocol
> > [ 35.644000] Modules linked in: snd_seq snd_seq_device ohci_hcd parport_pc parport pcspkr ipw2200 yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd uhci_hcd usbcore cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_centrino freq_table processor ac battery i915 drm tg3 joydev tsdev
> > [ 35.644000] CPU: 0
> > [ 35.644000] EIP: 0060:[<c01aeacb>] Not tainted VLI
> > [ 35.644000] EFLAGS: 00210246 (2.6.18-rc4-def01 #18)
> > [ 35.644000] EIP is at sysfs_dirent_exist+0x4b/0x70
> > [ 35.644000] eax: 00716573 ebx: f36f263c ecx: f71962a0 edx: f36f263c
> > [ 35.644000] esi: 00716573 edi: c03b4177 ebp: f711fe90 esp: f711fe7c
> > [ 35.644000] ds: 007b es: 007b ss: 0068
> > [ 35.644000] Process modprobe (pid: 8864, ti=f711e000 task=c193b540 task.ti=f711e000)
> > [ 35.644000] Stack: f36f263c f36f26a0 f36bf120 c03b4177 ffffffef f711feb0 c01afb95 f36f2694
> > [ 35.644000] c03b4177 f7ba4108 00000000 f7ba4000 f7ba4108 f711fed8 c027ece1 f7ba4108
> > [ 35.644000] f74b5d08 c03b4177 f7ba416c f7ba4000 f71962a0 f7ba4000 f7ba4108 f711ff08
> > [ 35.644000] Call Trace:
> > [ 35.644000] [<c01afb95>] sysfs_create_link+0x4d/0xa2
> > [ 35.644000] [<c027ece1>] device_add_class_symlinks+0xb0/0x14d
> > [ 35.644000] [<c027eff1>] device_add+0x1a0/0x37e
> > [ 35.644000] [<c027f1e9>] device_register+0x1a/0x20
> > [ 35.644000] [<c027f52f>] device_create+0xaa/0xc4
> > [ 35.644000] [<f8a0e472>] snd_register_device+0xcf/0x104 [snd]
> > [ 35.644000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> > [ 35.644000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> > [ 35.644000] [<c0141ab9>] sys_init_module+0x163/0x221
> > [ 35.644000] [<c0103139>] sysenter_past_esp+0x56/0x8d
> > [ 35.644000] [<b7fcd410>] 0xb7fcd410
> > [ 35.644000] [<c0104205>] show_stack_log_lvl+0x98/0xb2
> > [ 35.644000] [<c0104434>] show_registers+0x1b7/0x22f
> > [ 35.644000] [<c0104616>] die+0x12a/0x232
> > [ 35.644000] [<c0377042>] do_page_fault+0x38c/0x616
> > [ 35.644000] [<c0103cad>] error_code+0x39/0x40
> > [ 35.644000] [<c01afb95>] sysfs_create_link+0x4d/0xa2
> > [ 35.644000] [<c027ece1>] device_add_class_symlinks+0xb0/0x14d
> > [ 35.644000] [<c027eff1>] device_add+0x1a0/0x37e
> > [ 35.644000] [<c027f1e9>] device_register+0x1a/0x20
> > [ 35.644000] [<c027f52f>] device_create+0xaa/0xc4
> > [ 35.644000] [<f8a0e472>] snd_register_device+0xcf/0x104 [snd]
> > [ 35.644000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> > [ 35.644000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> > [ 35.644000] [<c0141ab9>] sys_init_module+0x163/0x221
> > [ 35.644000] [<c0103139>] sysenter_past_esp+0x56/0x8d
> > [ 35.644000] Code: f0 eb 12 8b 53 04 8d 42 fc 89 c3 8b 40 04 0f 18 00 90 3b 55 f0 74 2f 8b 43 14 85 c0 74 e5 89 1c 24 e8 39 f0 ff ff 8b 7d 0c 89 c6 <ac> ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 c4 b8
> > [ 35.644000] EIP: [<c01aeacb>] sysfs_dirent_exist+0x4b/0x70 SS:ESP 0068:f711fe7c
> > [ 35.644000]
> > It looks like %eax is in fact a sort of "seq" string, but I couldn't
> > figure out why we ended with this pointer :(
>
> These sorts of crashes down in sysfs often are hard to diagnose. What did
> the driver do to cause this? Dunno. But it continues to look like an ALSA
> thing.
>
> If you had CONFIG_PCI_MULTITHREAD_PROBE enabled, please try disabling it.
It wasn't set...
Thanks,
Frederik
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 BUG, drm relatedy
2006-08-15 13:25 ` 2.6.18-rc4-mm1 BUG, drm related Frederik Deweerdt
2006-08-15 14:16 ` Andrew Morton
@ 2006-08-19 23:08 ` Frederik Deweerdt
2006-08-21 11:24 ` Dave Airlie
1 sibling, 1 reply; 192+ messages in thread
From: Frederik Deweerdt @ 2006-08-19 23:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, airlied
On Tue, Aug 15, 2006 at 01:25:56PM +0000, Frederik Deweerdt wrote:
> On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >
> Hi,
>
> There are two BUGs with 2.6.18-rc4-mm1 that seem related to (I did the
> bisection[1]):
> git-drm.patch
> drm-build-fix.patch
> drm-build-fixes-2.patch
> allow-drm-detection-of-new-via-chipsets.patch
> git-drm-build-fix.patch
>
> Here's one of the BUGs (the second one is on the web site below).
> [ 40.276000] [drm:drm_unlock] *ERROR* Process 8914 using kernel context 0
> [ 41.024000] BUG: unable to handle kernel paging request at virtual address 6e756f73
> [ 41.024000] printing eip:
> [ 41.024000] c01b5771
> [ 41.024000] *pde = 00000000
> [ 41.024000] Oops: 0000 [#1]
> [ 41.024000] 8K_STACKS PREEMPT
> [ 41.024000] last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0/bInterfaceProtocol
> [ 41.024000] Modules linked in: snd_seq snd_seq_device ohci_hcd parport_pc parport pcspkr ipw2200 yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd uhci_hcd usbcore cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_centrino freq_table processor ac battery i915 drm tg3 joydev tsdev
> [ 41.024000] CPU: 0
> [ 41.024000] EIP: 0060:[<c01b5771>] Not tainted VLI
> [ 41.024000] EFLAGS: 00210246 (2.6.18-rc4-mm1-def01 #1)
> [ 41.024000] EIP is at sysfs_lookup+0x65/0xb0
> [ 41.024000] eax: f3161e40 ebx: f316842c ecx: f73f6280 edx: f316842c
> [ 41.024000] esi: 6e756f73 edi: f3161ec4 ebp: f6c35dfc esp: f6c35de0
> [ 41.024000] ds: 007b es: 007b ss: 0068
> [ 41.024000] Process modprobe (pid: 8952, ti=f6c34000 task=f7d17550 task.ti=f6c34000)
> [ 41.024000] Stack: f316842c f3161e94 f31684bc 00000000 fffffff4 f73f72ec f3161e40 f6c35e1c
> [ 41.024000] c0184d42 f73f72ec f3161e40 00000000 ffffffff c03a6656 12fd28db f6c35e4c
> [ 41.024000] c0184e02 f6c35e30 f3161ee8 00000000 12fd28db 00000005 c03a6651 c038230e
> [ 41.024000] Call Trace:
> [ 41.024000] [<c0184d42>] __lookup_hash+0x9d/0xcc
> [ 41.024000] [<c0184e02>] lookup_one_len+0x71/0x86
> [ 41.024000] [<c01b51da>] create_dir+0x43/0x23f
> [ 41.024000] [<c01b53fc>] sysfs_create_subdir+0x26/0x28
> [ 41.024000] [<c01b6c56>] sysfs_create_group+0x77/0x97
> [ 41.024000] [<c02903af>] dpm_sysfs_add+0x1e/0x20
> [ 41.024000] [<c028f6b3>] device_pm_add+0x64/0x89
> [ 41.024000] [<c028930a>] device_add+0x1d9/0x380
> [ 41.024000] [<c02894cb>] device_register+0x1a/0x20
> [ 41.024000] [<c0289811>] device_create+0xaa/0xc4
> [ 41.024000] [<f8a0c472>] snd_register_device+0xcf/0x104 [snd]
> [ 41.024000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> [ 41.024000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> [ 41.024000] [<c014186c>] sys_init_module+0x163/0x221
> [ 41.024000] [<c0103135>] sysenter_past_esp+0x56/0x8d
> [ 41.024000] [<b7fb0410>] 0xb7fb0410
> [ 41.024000] [<c0104017>] show_trace_log_lvl+0x2f/0x45
> [ 41.024000] [<c01040ee>] show_stack_log_lvl+0x98/0xb2
> [ 41.024000] [<c0104351>] show_registers+0x1eb/0x289
> [ 41.024000] [<c0104587>] die+0x134/0x241
> [ 41.024000] [<c0385e80>] do_page_fault+0x395/0x620
> [ 41.024000] [<c0384401>] error_code+0x39/0x40
> [ 41.024000] [<c0184d42>] __lookup_hash+0x9d/0xcc
> [ 41.024000] [<c0184e02>] lookup_one_len+0x71/0x86
> [ 41.024000] [<c01b51da>] create_dir+0x43/0x23f
> [ 41.024000] [<c01b53fc>] sysfs_create_subdir+0x26/0x28
> [ 41.024000] [<c01b6c56>] sysfs_create_group+0x77/0x97
> [ 41.024000] [<c02903af>] dpm_sysfs_add+0x1e/0x20
> [ 41.024000] [<c028f6b3>] device_pm_add+0x64/0x89
> [ 41.024000] [<c028930a>] device_add+0x1d9/0x380
> [ 41.024000] [<c02894cb>] device_register+0x1a/0x20
> [ 41.024000] [<c0289811>] device_create+0xaa/0xc4
> [ 41.024000] [<f8a0c472>] snd_register_device+0xcf/0x104 [snd]
> [ 41.024000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> [ 41.024000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> [ 41.024000] [<c014186c>] sys_init_module+0x163/0x221
> [ 41.024000] [<c0103135>] sysenter_past_esp+0x56/0x8d
> [ 41.024000] =======================
> [ 41.024000] Code: 42 fc 89 c3 8b 40 04 0f 18 00 90 3b 55 ec 75 e6 8b 45 f0 83 c4 10 5b 5e 5f 5d c3 89 1c 24 e8 27 e9 ff ff 89 c6 8b 45 0c 8b 78 48 <ac> ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 bd f6
> [ 41.024000] EIP: [<c01b5771>] sysfs_lookup+0x65/0xb0 SS:ESP 0068:f6c35de0
> [ 41.024000]
>
>
Hi Andrew,
I think that this definitely qualifies as a drm bug. Here are the tests
that I did and that make me think so:
- Removing the line 'Load "dri"' from xorg.conf makes the oops
disappear.
- The bisection I performed indicates that the problem comes from the
following set of patches:
git-drm.patch
drm-build-fix.patch
drm-build-fixes-2.patch
allow-drm-detection-of-new-via-chipsets.patch
git-drm-build-fix.patch
- Appliying the attached patch makes the oops disapear too.
Now, I don't know the drm code, and I'm not able to explain why the fix
works... Any ideas?
Regards,
Frederik
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
diff --git a/drivers/char/drm/drm_lock.c b/drivers/char/drm/drm_lock.c
index f9e4530..a9e01b7 100644
--- a/drivers/char/drm/drm_lock.c
+++ b/drivers/char/drm/drm_lock.c
@@ -65,12 +65,6 @@ int drm_lock(struct inode *inode, struct
if (copy_from_user(&lock, (drm_lock_t __user *) arg, sizeof(lock)))
return -EFAULT;
- if (lock.context == DRM_KERNEL_CONTEXT) {
- DRM_ERROR("Process %d using kernel context %d\n",
- current->pid, lock.context);
- return -EINVAL;
- }
-
DRM_DEBUG("%d (pid %d) requests lock (0x%08x), flags = 0x%08x\n",
lock.context, current->pid,
dev->lock.hw_lock->lock, lock.flags);
^ permalink raw reply related [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 BUG, drm relatedy
2006-08-19 23:08 ` 2.6.18-rc4-mm1 BUG, drm relatedy Frederik Deweerdt
@ 2006-08-21 11:24 ` Dave Airlie
2006-08-21 14:08 ` Frederik Deweerdt
0 siblings, 1 reply; 192+ messages in thread
From: Dave Airlie @ 2006-08-21 11:24 UTC (permalink / raw)
To: Frederik Deweerdt; +Cc: Andrew Morton, linux-kernel
>> [ 40.276000] [drm:drm_unlock] *ERROR* Process 8914 using kernel context 0
Can you send me an lspci -v (or have you already??)
I've been busy lately so having trouble following this stuff in a timely
manner, I think this is an error path which the userpsace code doesn't
clean up properly, your patch is most definitely not correct..
if I had to guess I'd say you have an AGP machine + card but no AGP
support driver loaded...
Dave.
>> [ 41.024000] BUG: unable to handle kernel paging request at virtual address 6e756f73
>> [ 41.024000] printing eip:
>> [ 41.024000] c01b5771
>> [ 41.024000] *pde = 00000000
>> [ 41.024000] Oops: 0000 [#1]
>> [ 41.024000] 8K_STACKS PREEMPT
>> [ 41.024000] last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0/bInterfaceProtocol
>> [ 41.024000] Modules linked in: snd_seq snd_seq_device ohci_hcd parport_pc parport pcspkr ipw2200 yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd uhci_hcd usbcore cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_centrino freq_table processor ac battery i915 drm tg3 joydev tsdev
>> [ 41.024000] CPU: 0
>> [ 41.024000] EIP: 0060:[<c01b5771>] Not tainted VLI
>> [ 41.024000] EFLAGS: 00210246 (2.6.18-rc4-mm1-def01 #1)
>> [ 41.024000] EIP is at sysfs_lookup+0x65/0xb0
>> [ 41.024000] eax: f3161e40 ebx: f316842c ecx: f73f6280 edx: f316842c
>> [ 41.024000] esi: 6e756f73 edi: f3161ec4 ebp: f6c35dfc esp: f6c35de0
>> [ 41.024000] ds: 007b es: 007b ss: 0068
>> [ 41.024000] Process modprobe (pid: 8952, ti=f6c34000 task=f7d17550 task.ti=f6c34000)
>> [ 41.024000] Stack: f316842c f3161e94 f31684bc 00000000 fffffff4 f73f72ec f3161e40 f6c35e1c
>> [ 41.024000] c0184d42 f73f72ec f3161e40 00000000 ffffffff c03a6656 12fd28db f6c35e4c
>> [ 41.024000] c0184e02 f6c35e30 f3161ee8 00000000 12fd28db 00000005 c03a6651 c038230e
>> [ 41.024000] Call Trace:
>> [ 41.024000] [<c0184d42>] __lookup_hash+0x9d/0xcc
>> [ 41.024000] [<c0184e02>] lookup_one_len+0x71/0x86
>> [ 41.024000] [<c01b51da>] create_dir+0x43/0x23f
>> [ 41.024000] [<c01b53fc>] sysfs_create_subdir+0x26/0x28
>> [ 41.024000] [<c01b6c56>] sysfs_create_group+0x77/0x97
>> [ 41.024000] [<c02903af>] dpm_sysfs_add+0x1e/0x20
>> [ 41.024000] [<c028f6b3>] device_pm_add+0x64/0x89
>> [ 41.024000] [<c028930a>] device_add+0x1d9/0x380
>> [ 41.024000] [<c02894cb>] device_register+0x1a/0x20
>> [ 41.024000] [<c0289811>] device_create+0xaa/0xc4
>> [ 41.024000] [<f8a0c472>] snd_register_device+0xcf/0x104 [snd]
>> [ 41.024000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
>> [ 41.024000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
>> [ 41.024000] [<c014186c>] sys_init_module+0x163/0x221
>> [ 41.024000] [<c0103135>] sysenter_past_esp+0x56/0x8d
>> [ 41.024000] [<b7fb0410>] 0xb7fb0410
>> [ 41.024000] [<c0104017>] show_trace_log_lvl+0x2f/0x45
>> [ 41.024000] [<c01040ee>] show_stack_log_lvl+0x98/0xb2
>> [ 41.024000] [<c0104351>] show_registers+0x1eb/0x289
>> [ 41.024000] [<c0104587>] die+0x134/0x241
>> [ 41.024000] [<c0385e80>] do_page_fault+0x395/0x620
>> [ 41.024000] [<c0384401>] error_code+0x39/0x40
>> [ 41.024000] [<c0184d42>] __lookup_hash+0x9d/0xcc
>> [ 41.024000] [<c0184e02>] lookup_one_len+0x71/0x86
>> [ 41.024000] [<c01b51da>] create_dir+0x43/0x23f
>> [ 41.024000] [<c01b53fc>] sysfs_create_subdir+0x26/0x28
>> [ 41.024000] [<c01b6c56>] sysfs_create_group+0x77/0x97
>> [ 41.024000] [<c02903af>] dpm_sysfs_add+0x1e/0x20
>> [ 41.024000] [<c028f6b3>] device_pm_add+0x64/0x89
>> [ 41.024000] [<c028930a>] device_add+0x1d9/0x380
>> [ 41.024000] [<c02894cb>] device_register+0x1a/0x20
>> [ 41.024000] [<c0289811>] device_create+0xaa/0xc4
>> [ 41.024000] [<f8a0c472>] snd_register_device+0xcf/0x104 [snd]
>> [ 41.024000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
>> [ 41.024000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
>> [ 41.024000] [<c014186c>] sys_init_module+0x163/0x221
>> [ 41.024000] [<c0103135>] sysenter_past_esp+0x56/0x8d
>> [ 41.024000] =======================
>> [ 41.024000] Code: 42 fc 89 c3 8b 40 04 0f 18 00 90 3b 55 ec 75 e6 8b 45 f0 83 c4 10 5b 5e 5f 5d c3 89 1c 24 e8 27 e9 ff ff 89 c6 8b 45 0c 8b 78 48 <ac> ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 bd f6
>> [ 41.024000] EIP: [<c01b5771>] sysfs_lookup+0x65/0xb0 SS:ESP 0068:f6c35de0
>> [ 41.024000]
>>
>>
> Hi Andrew,
>
> I think that this definitely qualifies as a drm bug. Here are the tests
> that I did and that make me think so:
> - Removing the line 'Load "dri"' from xorg.conf makes the oops
> disappear.
> - The bisection I performed indicates that the problem comes from the
> following set of patches:
> git-drm.patch
> drm-build-fix.patch
> drm-build-fixes-2.patch
> allow-drm-detection-of-new-via-chipsets.patch
> git-drm-build-fix.patch
> - Appliying the attached patch makes the oops disapear too.
>
> Now, I don't know the drm code, and I'm not able to explain why the fix
> works... Any ideas?
>
> Regards,
> Frederik
>
> Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
> diff --git a/drivers/char/drm/drm_lock.c b/drivers/char/drm/drm_lock.c
> index f9e4530..a9e01b7 100644
> --- a/drivers/char/drm/drm_lock.c
> +++ b/drivers/char/drm/drm_lock.c
> @@ -65,12 +65,6 @@ int drm_lock(struct inode *inode, struct
> if (copy_from_user(&lock, (drm_lock_t __user *) arg, sizeof(lock)))
> return -EFAULT;
>
> - if (lock.context == DRM_KERNEL_CONTEXT) {
> - DRM_ERROR("Process %d using kernel context %d\n",
> - current->pid, lock.context);
> - return -EINVAL;
> - }
> -
> DRM_DEBUG("%d (pid %d) requests lock (0x%08x), flags = 0x%08x\n",
> lock.context, current->pid,
> dev->lock.hw_lock->lock, lock.flags);
>
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 BUG, drm relatedy
2006-08-21 11:24 ` Dave Airlie
@ 2006-08-21 14:08 ` Frederik Deweerdt
2006-08-21 23:48 ` Dave Airlie
0 siblings, 1 reply; 192+ messages in thread
From: Frederik Deweerdt @ 2006-08-21 14:08 UTC (permalink / raw)
To: Dave Airlie; +Cc: Andrew Morton, linux-kernel
On Mon, Aug 21, 2006 at 12:24:51PM +0100, Dave Airlie wrote:
>
> >>[ 40.276000] [drm:drm_unlock] *ERROR* Process 8914 using kernel context 0
>
> Can you send me an lspci -v (or have you already??)
The lspci output is available at http://fdeweerdt.free.fr/drm_bug,
along with the .config, and dmesg.
>
> I've been busy lately so having trouble following this stuff in a timely manner, I think this is an error path which the
> userpsace code doesn't clean up properly, your patch is most definitely not correct..
I see. So this is most likely X's having trouble with the EFAULT on
unlock? I've gone through the 2.6.18-rc4-mm1 patches, and I couldn't
relate the updates and that new drm_unlock() error message. Any idea?
>
> if I had to guess I'd say you have an AGP machine + card but no AGP support driver loaded...
I've got CONFIG_AGP=y and CONFIG_AGP_INTEL=y, do I need some more
options? What's strange is that this worked perfectly with
2.6.18-rc3-mm2...
Thanks,
Frederik
>
> Dave.
>
>
> >>[ 41.024000] BUG: unable to handle kernel paging request at virtual address 6e756f73
> >>[ 41.024000] printing eip:
> >>[ 41.024000] c01b5771
> >>[ 41.024000] *pde = 00000000
> >>[ 41.024000] Oops: 0000 [#1]
> >>[ 41.024000] 8K_STACKS PREEMPT
> >>[ 41.024000] last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb5/5-0:1.0/bInterfaceProtocol
> >>[ 41.024000] Modules linked in: snd_seq snd_seq_device ohci_hcd parport_pc parport pcspkr ipw2200 yenta_socket
> >>rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd
> >>uhci_hcd usbcore cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_centrino freq_table
> >>processor ac battery i915 drm tg3 joydev tsdev
> >>[ 41.024000] CPU: 0
> >>[ 41.024000] EIP: 0060:[<c01b5771>] Not tainted VLI
> >>[ 41.024000] EFLAGS: 00210246 (2.6.18-rc4-mm1-def01 #1)
> >>[ 41.024000] EIP is at sysfs_lookup+0x65/0xb0
> >>[ 41.024000] eax: f3161e40 ebx: f316842c ecx: f73f6280 edx: f316842c
> >>[ 41.024000] esi: 6e756f73 edi: f3161ec4 ebp: f6c35dfc esp: f6c35de0
> >>[ 41.024000] ds: 007b es: 007b ss: 0068
> >>[ 41.024000] Process modprobe (pid: 8952, ti=f6c34000 task=f7d17550 task.ti=f6c34000)
> >>[ 41.024000] Stack: f316842c f3161e94 f31684bc 00000000 fffffff4 f73f72ec f3161e40 f6c35e1c
> >>[ 41.024000] c0184d42 f73f72ec f3161e40 00000000 ffffffff c03a6656 12fd28db f6c35e4c
> >>[ 41.024000] c0184e02 f6c35e30 f3161ee8 00000000 12fd28db 00000005 c03a6651 c038230e
> >>[ 41.024000] Call Trace:
> >>[ 41.024000] [<c0184d42>] __lookup_hash+0x9d/0xcc
> >>[ 41.024000] [<c0184e02>] lookup_one_len+0x71/0x86
> >>[ 41.024000] [<c01b51da>] create_dir+0x43/0x23f
> >>[ 41.024000] [<c01b53fc>] sysfs_create_subdir+0x26/0x28
> >>[ 41.024000] [<c01b6c56>] sysfs_create_group+0x77/0x97
> >>[ 41.024000] [<c02903af>] dpm_sysfs_add+0x1e/0x20
> >>[ 41.024000] [<c028f6b3>] device_pm_add+0x64/0x89
> >>[ 41.024000] [<c028930a>] device_add+0x1d9/0x380
> >>[ 41.024000] [<c02894cb>] device_register+0x1a/0x20
> >>[ 41.024000] [<c0289811>] device_create+0xaa/0xc4
> >>[ 41.024000] [<f8a0c472>] snd_register_device+0xcf/0x104 [snd]
> >>[ 41.024000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> >>[ 41.024000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> >>[ 41.024000] [<c014186c>] sys_init_module+0x163/0x221
> >>[ 41.024000] [<c0103135>] sysenter_past_esp+0x56/0x8d
> >>[ 41.024000] [<b7fb0410>] 0xb7fb0410
> >>[ 41.024000] [<c0104017>] show_trace_log_lvl+0x2f/0x45
> >>[ 41.024000] [<c01040ee>] show_stack_log_lvl+0x98/0xb2
> >>[ 41.024000] [<c0104351>] show_registers+0x1eb/0x289
> >>[ 41.024000] [<c0104587>] die+0x134/0x241
> >>[ 41.024000] [<c0385e80>] do_page_fault+0x395/0x620
> >>[ 41.024000] [<c0384401>] error_code+0x39/0x40
> >>[ 41.024000] [<c0184d42>] __lookup_hash+0x9d/0xcc
> >>[ 41.024000] [<c0184e02>] lookup_one_len+0x71/0x86
> >>[ 41.024000] [<c01b51da>] create_dir+0x43/0x23f
> >>[ 41.024000] [<c01b53fc>] sysfs_create_subdir+0x26/0x28
> >>[ 41.024000] [<c01b6c56>] sysfs_create_group+0x77/0x97
> >>[ 41.024000] [<c02903af>] dpm_sysfs_add+0x1e/0x20
> >>[ 41.024000] [<c028f6b3>] device_pm_add+0x64/0x89
> >>[ 41.024000] [<c028930a>] device_add+0x1d9/0x380
> >>[ 41.024000] [<c02894cb>] device_register+0x1a/0x20
> >>[ 41.024000] [<c0289811>] device_create+0xaa/0xc4
> >>[ 41.024000] [<f8a0c472>] snd_register_device+0xcf/0x104 [snd]
> >>[ 41.024000] [<f8abd0c2>] snd_sequencer_device_init+0x4e/0x7c [snd_seq]
> >>[ 41.024000] [<f8abd02f>] alsa_seq_init+0x2f/0x51 [snd_seq]
> >>[ 41.024000] [<c014186c>] sys_init_module+0x163/0x221
> >>[ 41.024000] [<c0103135>] sysenter_past_esp+0x56/0x8d
> >>[ 41.024000] =======================
> >>[ 41.024000] Code: 42 fc 89 c3 8b 40 04 0f 18 00 90 3b 55 ec 75 e6 8b 45 f0 83 c4 10 5b 5e 5f 5d c3 89 1c 24 e8 27 e9 ff ff
> >>89 c6 8b 45 0c 8b 78 48 <ac> ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 bd f6
> >>[ 41.024000] EIP: [<c01b5771>] sysfs_lookup+0x65/0xb0 SS:ESP 0068:f6c35de0
> >>[ 41.024000]
> >>
> >>
> >Hi Andrew,
> >
> >I think that this definitely qualifies as a drm bug. Here are the tests
> >that I did and that make me think so:
> >- Removing the line 'Load "dri"' from xorg.conf makes the oops
> > disappear.
> >- The bisection I performed indicates that the problem comes from the
> > following set of patches:
> > git-drm.patch
> > drm-build-fix.patch
> > drm-build-fixes-2.patch
> > allow-drm-detection-of-new-via-chipsets.patch
> > git-drm-build-fix.patch
> >- Appliying the attached patch makes the oops disapear too.
> >
> >Now, I don't know the drm code, and I'm not able to explain why the fix
> >works... Any ideas?
> >
> >Regards,
> >Frederik
> >
> >Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
> >diff --git a/drivers/char/drm/drm_lock.c b/drivers/char/drm/drm_lock.c
> >index f9e4530..a9e01b7 100644
> >--- a/drivers/char/drm/drm_lock.c
> >+++ b/drivers/char/drm/drm_lock.c
> >@@ -65,12 +65,6 @@ int drm_lock(struct inode *inode, struct
> > if (copy_from_user(&lock, (drm_lock_t __user *) arg, sizeof(lock)))
> > return -EFAULT;
> >
> >- if (lock.context == DRM_KERNEL_CONTEXT) {
> >- DRM_ERROR("Process %d using kernel context %d\n",
> >- current->pid, lock.context);
> >- return -EINVAL;
> >- }
> >-
> > DRM_DEBUG("%d (pid %d) requests lock (0x%08x), flags = 0x%08x\n",
> > lock.context, current->pid,
> > dev->lock.hw_lock->lock, lock.flags);
> >
>
> --
> David Airlie, Software Engineer
> http://www.skynet.ie/~airlied / airlied at skynet.ie
> Linux kernel - DRI, VAX / pam_smb / ILUG
>
>
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 BUG, drm relatedy
2006-08-21 14:08 ` Frederik Deweerdt
@ 2006-08-21 23:48 ` Dave Airlie
0 siblings, 0 replies; 192+ messages in thread
From: Dave Airlie @ 2006-08-21 23:48 UTC (permalink / raw)
To: Frederik Deweerdt; +Cc: Andrew Morton, linux-kernel
>> I've been busy lately so having trouble following this stuff in a timely manner, I think this is an error path which the
>> userpsace code doesn't clean up properly, your patch is most definitely not correct..
> I see. So this is most likely X's having trouble with the EFAULT on
> unlock? I've gone through the 2.6.18-rc4-mm1 patches, and I couldn't
> relate the updates and that new drm_unlock() error message. Any idea?
>>
>> if I had to guess I'd say you have an AGP machine + card but no AGP support driver loaded...
> I've got CONFIG_AGP=y and CONFIG_AGP_INTEL=y, do I need some more
> options? What's strange is that this worked perfectly with
> 2.6.18-rc3-mm2...
Can you startup without X, do
echo 1 > /sys/modules/drm/parameters/debug
start X, and send me the dmesg output up to the oops?
Don't cc the list as I suspect it will be quite large..
Dave.
^ permalink raw reply [flat|nested] 192+ messages in thread
* 2.6.18-rc4-mm1 -- new depancy on curses development
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (23 preceding siblings ...)
2006-08-15 13:25 ` 2.6.18-rc4-mm1 BUG, drm related Frederik Deweerdt
@ 2006-08-16 9:41 ` Andy Whitcroft
2006-08-16 10:35 ` Andy Whitcroft
2006-08-16 18:33 ` Sam Ravnborg
2006-08-16 11:44 ` 2.6.18-rc4-mm1 BUG null pointer deref while saving a file Helge Hafting
` (4 subsequent siblings)
29 siblings, 2 replies; 192+ messages in thread
From: Andy Whitcroft @ 2006-08-16 9:41 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Andrew Morton, linux-kernel
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> git-lxdialog.patch
This tree seems to change the Makefile dependancies in the kconfig
subdirectory such that a plain compile of the kernel leads to an attempt
to build the menuconfig targets. This in turn adds a new dependancy on
the curses development libraries.
08/15/06-05:23:09 building kernel - make -j4 vmlinux
HOSTCC scripts/kconfig/lxdialog/checklist.o
In file included from scripts/kconfig/lxdialog/checklist.c:24:
scripts/kconfig/lxdialog/dialog.h:31:20: error: curses.h:
No such file or directory
This seems to come from this rather innocent sounding change in that tree:
commit 9238251dddc15b52656e70b74dffe56193d01215
Author: Sam Ravnborg <sam@mars.ravnborg.org>
Date: Mon Jul 24 21:40:46 2006 +0200
kconfig/lxdialog: refactor color support
which also seems to change the Makefile about, specifically bringing the
sub Makefile into the top level one.
[...]
- $(Q)$(MAKE) $(build)=scripts/kconfig/lxdialog
[...]
+# lxdialog stuff
+check-lxdialog := $(srctree)/$(src)/lxdialog/check-lxdialog.sh
[...]
Sam?
-apw
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 -- new depancy on curses development
2006-08-16 9:41 ` 2.6.18-rc4-mm1 -- new depancy on curses development Andy Whitcroft
@ 2006-08-16 10:35 ` Andy Whitcroft
2006-08-16 18:33 ` Sam Ravnborg
1 sibling, 0 replies; 192+ messages in thread
From: Andy Whitcroft @ 2006-08-16 10:35 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Sam Ravnborg, Andrew Morton, linux-kernel
[/me updates the CC: to Sam's real email.]
Andy Whitcroft wrote:
> Andrew Morton wrote:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>>
>
>> git-lxdialog.patch
>
> This tree seems to change the Makefile dependancies in the kconfig
> subdirectory such that a plain compile of the kernel leads to an attempt
> to build the menuconfig targets. This in turn adds a new dependancy on
> the curses development libraries.
>
> 08/15/06-05:23:09 building kernel - make -j4 vmlinux
> HOSTCC scripts/kconfig/lxdialog/checklist.o
> In file included from scripts/kconfig/lxdialog/checklist.c:24:
> scripts/kconfig/lxdialog/dialog.h:31:20: error: curses.h:
> No such file or directory
>
> This seems to come from this rather innocent sounding change in that tree:
>
> commit 9238251dddc15b52656e70b74dffe56193d01215
> Author: Sam Ravnborg <sam@mars.ravnborg.org>
> Date: Mon Jul 24 21:40:46 2006 +0200
>
> kconfig/lxdialog: refactor color support
>
Ok, reading the patch as if its git output isn't a good plan. The
changeset appears to be this one:
commit 49140e7b29bb1fcc195efef3e1c54c144dd2eff7
Author: Sam Ravnborg <sam@mars.ravnborg.org>
Date: Thu Jul 27 22:10:27 2006 +0200
kconfig/menuconfig: lxdialog is now built-in
> which also seems to change the Makefile about, specifically bringing the
> sub Makefile into the top level one.
>
> [...]
> - $(Q)$(MAKE) $(build)=scripts/kconfig/lxdialog
> [...]
> +# lxdialog stuff
> +check-lxdialog := $(srctree)/$(src)/lxdialog/check-lxdialog.sh
> [...]
>
> Sam?
>
> -apw
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 -- new depancy on curses development
2006-08-16 9:41 ` 2.6.18-rc4-mm1 -- new depancy on curses development Andy Whitcroft
2006-08-16 10:35 ` Andy Whitcroft
@ 2006-08-16 18:33 ` Sam Ravnborg
2006-08-16 19:26 ` Andy Whitcroft
1 sibling, 1 reply; 192+ messages in thread
From: Sam Ravnborg @ 2006-08-16 18:33 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andrew Morton, linux-kernel
On Wed, Aug 16, 2006 at 10:41:59AM +0100, Andy Whitcroft wrote:
> Andrew Morton wrote:
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> > git-lxdialog.patch
>
> This tree seems to change the Makefile dependancies in the kconfig
> subdirectory such that a plain compile of the kernel leads to an attempt
> to build the menuconfig targets. This in turn adds a new dependancy on
> the curses development libraries.
What I see is that "make defconfig" builds _all_ *config targets -
strange...
Hmmm, why does git pick up my hostname (mars)? Have I configured
somethign wrong (not in git but my gentoo system)?
Sam
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 -- new depancy on curses development
2006-08-16 18:33 ` Sam Ravnborg
@ 2006-08-16 19:26 ` Andy Whitcroft
0 siblings, 0 replies; 192+ messages in thread
From: Andy Whitcroft @ 2006-08-16 19:26 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Andrew Morton, linux-kernel
Sam Ravnborg wrote:
> On Wed, Aug 16, 2006 at 10:41:59AM +0100, Andy Whitcroft wrote:
>> Andrew Morton wrote:
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>>> git-lxdialog.patch
>> This tree seems to change the Makefile dependancies in the kconfig
>> subdirectory such that a plain compile of the kernel leads to an attempt
>> to build the menuconfig targets. This in turn adds a new dependancy on
>> the curses development libraries.
> What I see is that "make defconfig" builds _all_ *config targets -
> strange...
Well it could be trying to build them all for me too, but as I don't
have curses development libraries it would fail at that point. I don't
think we want it to build the ones its not using. Thats daft :).
> Hmmm, why does git pick up my hostname (mars)? Have I configured
> somethign wrong (not in git but my gentoo system)?
I had to configure my local git repo:
git repo-config user.name 'Foo Bar'
git repo-config user.email 'foo@bar.org'
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 BUG null pointer deref while saving a file
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (24 preceding siblings ...)
2006-08-16 9:41 ` 2.6.18-rc4-mm1 -- new depancy on curses development Andy Whitcroft
@ 2006-08-16 11:44 ` Helge Hafting
2006-08-16 14:28 ` Dave Kleikamp
2006-08-17 22:10 ` 2.6.18-rc4-mm1 Spurious ACK/NAK on isa0060/serio0, 2.6.18-rc2 is fine Helge Hafting
` (3 subsequent siblings)
29 siblings, 1 reply; 192+ messages in thread
From: Helge Hafting @ 2006-08-16 11:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Aug 16 13:20:30 hh kernel: BUG: unable to handle kernel NULL pointer
dereference at virtual address 00000000
Aug 16 13:20:30 hh kernel: printing eip:
Aug 16 13:20:30 hh kernel: c0468863
Aug 16 13:20:30 hh kernel: *pde = 00000000
Aug 16 13:20:30 hh kernel: Oops: 0002 [#1]
Aug 16 13:20:30 hh kernel: 4K_STACKS
Aug 16 13:20:30 hh kernel: last sysfs file:
/devices/platform/i2c-9191/9191-0290/in0_input
Aug 16 13:20:30 hh kernel: CPU: 0
Aug 16 13:20:30 hh kernel: EIP: 0060:[<c0468863>] Not tainted VLI
Aug 16 13:20:30 hh kernel: EFLAGS: 00010002 (2.6.18-rc4-mm1 #7)
Aug 16 13:20:30 hh kernel: EIP is at __down+0x5c/0xed
Aug 16 13:20:30 hh kernel: eax: 00000000 ebx: d462e7e4 ecx:
c14e7e40 edx: dde06f0c
Aug 16 13:20:30 hh kernel: esi: 00000286 edi: c3365550 ebp:
d462e7ec esp: dde06efc
Aug 16 13:20:30 hh kernel: ds: 007b es: 007b ss: 0068
Aug 16 13:20:30 hh kernel: Process lyx (pid: 9353, ti=dde06000
task=c3365550 task.ti=dde06000)
Aug 16 13:20:30 hh kernel: Stack: dde06f0c 00000001 c3365550 c0116941
d462e7ec 00000000 00000008 d851a9a8
Aug 16 13:20:30 hh kernel: d462e7c0 d32a1200 c0466bc7 c14e7e40
dde06000 c01ed987 00000008 00000000
Aug 16 13:20:30 hh kernel: 00000000 00000000 d7a31c00 caf9be0c
00000000 00001dbb d462e7e4 00000008
Aug 16 13:20:30 hh kernel: Call Trace:
Aug 16 13:20:30 hh kernel: [<c0466bc7>] __down_failed+0x7/0xc
Aug 16 13:20:30 hh kernel: DWARF2 unwinder stuck at __down_failed+0x7/0xc
Aug 16 13:20:31 hh kernel: Leftover inexact backtrace:
Aug 16 13:20:31 hh kernel: [<c01ed987>] .text.lock.file+0x54/0x9d
Aug 16 13:20:31 hh kernel: [<c01516bd>] __fput+0xb2/0x163
Aug 16 13:20:31 hh kernel: [<c014ee9d>] filp_close+0x3e/0x62
Aug 16 13:20:31 hh kernel: [<c0150168>] sys_close+0x5c/0x6b
Aug 16 13:20:31 hh kernel: [<c01028c9>] sysenter_past_esp+0x56/0x79
Aug 16 13:20:31 hh kernel: =======================
Aug 16 13:20:31 hh kernel: Code: 0c 41 69 11 c0 c7 07 02 00 00 00 9c 5e
fa 83 4c 24 04 01 8d 6b 08 8b 45 04 8d 54 24 10 89 14 24 89 55 04 89 6c
24 10 89 44 24 14 <89> 10 8b 43 04 8d 50 01 89 53 04 01 03 0f 98 c0 84
c0 74 26 c7
Aug 16 13:20:31 hh kernel: EIP: [<c0468863>] __down+0x5c/0xed SS:ESP
0068:dde06efc
The lyx process is a word processor. I did a save, the window
disappeared, and this was logged.
Helge Hafting
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 BUG null pointer deref while saving a file
2006-08-16 11:44 ` 2.6.18-rc4-mm1 BUG null pointer deref while saving a file Helge Hafting
@ 2006-08-16 14:28 ` Dave Kleikamp
2006-08-18 8:24 ` Helge Hafting
0 siblings, 1 reply; 192+ messages in thread
From: Dave Kleikamp @ 2006-08-16 14:28 UTC (permalink / raw)
To: Helge Hafting; +Cc: Andrew Morton, linux-kernel
On Wed, 2006-08-16 at 13:44 +0200, Helge Hafting wrote:
> Aug 16 13:20:30 hh kernel: BUG: unable to handle kernel NULL pointer
> dereference at virtual address 00000000
> Aug 16 13:20:30 hh kernel: printing eip:
> Aug 16 13:20:30 hh kernel: c0468863
> Aug 16 13:20:30 hh kernel: *pde = 00000000
> Aug 16 13:20:30 hh kernel: Oops: 0002 [#1]
> Aug 16 13:20:30 hh kernel: 4K_STACKS
> Aug 16 13:20:30 hh kernel: last sysfs file:
> /devices/platform/i2c-9191/9191-0290/in0_input
> Aug 16 13:20:30 hh kernel: CPU: 0
> Aug 16 13:20:30 hh kernel: EIP: 0060:[<c0468863>] Not tainted VLI
> Aug 16 13:20:30 hh kernel: EFLAGS: 00010002 (2.6.18-rc4-mm1 #7)
> Aug 16 13:20:30 hh kernel: EIP is at __down+0x5c/0xed
> Aug 16 13:20:30 hh kernel: eax: 00000000 ebx: d462e7e4 ecx:
> c14e7e40 edx: dde06f0c
> Aug 16 13:20:30 hh kernel: esi: 00000286 edi: c3365550 ebp:
> d462e7ec esp: dde06efc
> Aug 16 13:20:30 hh kernel: ds: 007b es: 007b ss: 0068
> Aug 16 13:20:30 hh kernel: Process lyx (pid: 9353, ti=dde06000
> task=c3365550 task.ti=dde06000)
> Aug 16 13:20:30 hh kernel: Stack: dde06f0c 00000001 c3365550 c0116941
> d462e7ec 00000000 00000008 d851a9a8
> Aug 16 13:20:30 hh kernel: d462e7c0 d32a1200 c0466bc7 c14e7e40
> dde06000 c01ed987 00000008 00000000
> Aug 16 13:20:30 hh kernel: 00000000 00000000 d7a31c00 caf9be0c
> 00000000 00001dbb d462e7e4 00000008
> Aug 16 13:20:30 hh kernel: Call Trace:
> Aug 16 13:20:30 hh kernel: [<c0466bc7>] __down_failed+0x7/0xc
> Aug 16 13:20:30 hh kernel: DWARF2 unwinder stuck at __down_failed+0x7/0xc
> Aug 16 13:20:31 hh kernel: Leftover inexact backtrace:
> Aug 16 13:20:31 hh kernel: [<c01ed987>] .text.lock.file+0x54/0x9d
> Aug 16 13:20:31 hh kernel: [<c01516bd>] __fput+0xb2/0x163
> Aug 16 13:20:31 hh kernel: [<c014ee9d>] filp_close+0x3e/0x62
> Aug 16 13:20:31 hh kernel: [<c0150168>] sys_close+0x5c/0x6b
> Aug 16 13:20:31 hh kernel: [<c01028c9>] sysenter_past_esp+0x56/0x79
By any chance would you be using cifs? This looks just like the bug
that is fixed by this patch:
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff;h=e466e4876bf39474e15d0572f2204578137ae7f5
> Aug 16 13:20:31 hh kernel: =======================
> Aug 16 13:20:31 hh kernel: Code: 0c 41 69 11 c0 c7 07 02 00 00 00 9c 5e
> fa 83 4c 24 04 01 8d 6b 08 8b 45 04 8d 54 24 10 89 14 24 89 55 04 89 6c
> 24 10 89 44 24 14 <89> 10 8b 43 04 8d 50 01 89 53 04 01 03 0f 98 c0 84
> c0 74 26 c7
> Aug 16 13:20:31 hh kernel: EIP: [<c0468863>] __down+0x5c/0xed SS:ESP
> 0068:dde06efc
>
> The lyx process is a word processor. I did a save, the window
> disappeared, and this was logged.
>
> Helge Hafting
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 BUG null pointer deref while saving a file
2006-08-16 14:28 ` Dave Kleikamp
@ 2006-08-18 8:24 ` Helge Hafting
2006-08-18 12:20 ` Dave Kleikamp
0 siblings, 1 reply; 192+ messages in thread
From: Helge Hafting @ 2006-08-18 8:24 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: Andrew Morton, linux-kernel
Dave Kleikamp wrote:
> On Wed, 2006-08-16 at 13:44 +0200, Helge Hafting wrote:
>
>> Aug 16 13:20:30 hh kernel: BUG: unable to handle kernel NULL pointer
>> dereference at virtual address 00000000
>> Aug 16 13:20:30 hh kernel: printing eip:
>> Aug 16 13:20:30 hh kernel: c0468863
>> Aug 16 13:20:30 hh kernel: *pde = 00000000
>> Aug 16 13:20:30 hh kernel: Oops: 0002 [#1]
>> Aug 16 13:20:30 hh kernel: 4K_STACKS
>> Aug 16 13:20:30 hh kernel: last sysfs file:
>> /devices/platform/i2c-9191/9191-0290/in0_input
>> Aug 16 13:20:30 hh kernel: CPU: 0
>> Aug 16 13:20:30 hh kernel: EIP: 0060:[<c0468863>] Not tainted VLI
>> Aug 16 13:20:30 hh kernel: EFLAGS: 00010002 (2.6.18-rc4-mm1 #7)
>> Aug 16 13:20:30 hh kernel: EIP is at __down+0x5c/0xed
>> Aug 16 13:20:30 hh kernel: eax: 00000000 ebx: d462e7e4 ecx:
>> c14e7e40 edx: dde06f0c
>> Aug 16 13:20:30 hh kernel: esi: 00000286 edi: c3365550 ebp:
>> d462e7ec esp: dde06efc
>> Aug 16 13:20:30 hh kernel: ds: 007b es: 007b ss: 0068
>> Aug 16 13:20:30 hh kernel: Process lyx (pid: 9353, ti=dde06000
>> task=c3365550 task.ti=dde06000)
>> Aug 16 13:20:30 hh kernel: Stack: dde06f0c 00000001 c3365550 c0116941
>> d462e7ec 00000000 00000008 d851a9a8
>> Aug 16 13:20:30 hh kernel: d462e7c0 d32a1200 c0466bc7 c14e7e40
>> dde06000 c01ed987 00000008 00000000
>> Aug 16 13:20:30 hh kernel: 00000000 00000000 d7a31c00 caf9be0c
>> 00000000 00001dbb d462e7e4 00000008
>> Aug 16 13:20:30 hh kernel: Call Trace:
>> Aug 16 13:20:30 hh kernel: [<c0466bc7>] __down_failed+0x7/0xc
>> Aug 16 13:20:30 hh kernel: DWARF2 unwinder stuck at __down_failed+0x7/0xc
>> Aug 16 13:20:31 hh kernel: Leftover inexact backtrace:
>> Aug 16 13:20:31 hh kernel: [<c01ed987>] .text.lock.file+0x54/0x9d
>> Aug 16 13:20:31 hh kernel: [<c01516bd>] __fput+0xb2/0x163
>> Aug 16 13:20:31 hh kernel: [<c014ee9d>] filp_close+0x3e/0x62
>> Aug 16 13:20:31 hh kernel: [<c0150168>] sys_close+0x5c/0x6b
>> Aug 16 13:20:31 hh kernel: [<c01028c9>] sysenter_past_esp+0x56/0x79
>>
>
> By any chance would you be using cifs? This looks just like the bug
> that is fixed by this patch:
> http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff;h=e466e4876bf39474e15d0572f2204578137ae7f5
>
Yes, this is on cifs. I should have mentioned that. Is this patch going
in anyway, or should I test it? I don't know a way of reproducing
the problem.
Helge Hafting
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 BUG null pointer deref while saving a file
2006-08-18 8:24 ` Helge Hafting
@ 2006-08-18 12:20 ` Dave Kleikamp
0 siblings, 0 replies; 192+ messages in thread
From: Dave Kleikamp @ 2006-08-18 12:20 UTC (permalink / raw)
To: Helge Hafting; +Cc: Andrew Morton, linux-kernel, Steve French
On Fri, 2006-08-18 at 10:24 +0200, Helge Hafting wrote:
> Dave Kleikamp wrote:
> > On Wed, 2006-08-16 at 13:44 +0200, Helge Hafting wrote:
> >> Aug 16 13:20:30 hh kernel: Call Trace:
> >> Aug 16 13:20:30 hh kernel: [<c0466bc7>] __down_failed+0x7/0xc
> >> Aug 16 13:20:30 hh kernel: DWARF2 unwinder stuck at __down_failed+0x7/0xc
> >> Aug 16 13:20:31 hh kernel: Leftover inexact backtrace:
> >> Aug 16 13:20:31 hh kernel: [<c01ed987>] .text.lock.file+0x54/0x9d
> >> Aug 16 13:20:31 hh kernel: [<c01516bd>] __fput+0xb2/0x163
> >> Aug 16 13:20:31 hh kernel: [<c014ee9d>] filp_close+0x3e/0x62
> >> Aug 16 13:20:31 hh kernel: [<c0150168>] sys_close+0x5c/0x6b
> >> Aug 16 13:20:31 hh kernel: [<c01028c9>] sysenter_past_esp+0x56/0x79
> >>
> >
> > By any chance would you be using cifs? This looks just like the bug
> > that is fixed by this patch:
> > http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff;h=e466e4876bf39474e15d0572f2204578137ae7f5
> >
> Yes, this is on cifs. I should have mentioned that. Is this patch going
> in anyway, or should I test it? I don't know a way of reproducing
> the problem.
This git tree is automatically pulled into the -mm build, so it will be
in the next -mm build. The patch causing the problem isn't in mainline
yet, so there is no rush to fix it there.
Shaggy
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 Spurious ACK/NAK on isa0060/serio0, 2.6.18-rc2 is fine
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (25 preceding siblings ...)
2006-08-16 11:44 ` 2.6.18-rc4-mm1 BUG null pointer deref while saving a file Helge Hafting
@ 2006-08-17 22:10 ` Helge Hafting
2006-08-17 22:34 ` Helge Hafting
2006-08-17 22:44 ` 2.6.18-rc4-mm1 - time moving at 3x speed! Helge Hafting
` (2 subsequent siblings)
29 siblings, 1 reply; 192+ messages in thread
From: Helge Hafting @ 2006-08-17 22:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
So I tried 2.6.18-rc4-mm1 on my opteron. (Running 64-bit)
The kernel did not boot, but went into an infinite loop of
Spurious ACK on isa0060/serio0
over and over. I have two keyboards, one attached the usual
way and another attached where a mouse usually goes.
This works fine with 2.6.18-rc2, but no longer now.
One keyboard is dead, and on the other, two of the
leds blink on and off.
Unplugging a keyboard changes the repeating message to
Spurious NAK ... instead.
Unplugging both keyboards stops the nonsense, but then - no keyboard.
This kernel also fails to mount root, a fact that is hard to see as
the stupid messages quickly scroll everything else away.
That might be something simple like the changed ATA config
or multithreaded pci probe.
There just cannot be any program "trying to access hw directly",
I don't get the root fs so I don't even have init running.
Helge Hafting
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 Spurious ACK/NAK on isa0060/serio0, 2.6.18-rc2 is fine
2006-08-17 22:10 ` 2.6.18-rc4-mm1 Spurious ACK/NAK on isa0060/serio0, 2.6.18-rc2 is fine Helge Hafting
@ 2006-08-17 22:34 ` Helge Hafting
2006-08-18 21:56 ` Greg KH
0 siblings, 1 reply; 192+ messages in thread
From: Helge Hafting @ 2006-08-17 22:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Fri, Aug 18, 2006 at 12:10:52AM +0200, Helge Hafting wrote:
> So I tried 2.6.18-rc4-mm1 on my opteron. (Running 64-bit)
>
> The kernel did not boot, but went into an infinite loop of
>
> Spurious ACK on isa0060/serio0
> over and over. I have two keyboards, one attached the usual
> way and another attached where a mouse usually goes.
> This works fine with 2.6.18-rc2, but no longer now.
> One keyboard is dead, and on the other, two of the
> leds blink on and off.
>
> Unplugging a keyboard changes the repeating message to
> Spurious NAK ... instead.
>
> Unplugging both keyboards stops the nonsense, but then - no keyboard.
>
> This kernel also fails to mount root, a fact that is hard to see as
> the stupid messages quickly scroll everything else away.
> That might be something simple like the changed ATA config
> or multithreaded pci probe.
>
> There just cannot be any program "trying to access hw directly",
> I don't get the root fs so I don't even have init running.
>
I got rid of the multithreaded PCI probe - and the root fs was
recognised again (I have both SATA and SCSI, perhaps they
were probed in wrong order)
Curiously enough, the keyboard trouble went away too. Odd.
Now posting from a working 2.6.18-rc4-mm1 (With the jiffies hotfix)
Helge Hafting
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 Spurious ACK/NAK on isa0060/serio0, 2.6.18-rc2 is fine
2006-08-17 22:34 ` Helge Hafting
@ 2006-08-18 21:56 ` Greg KH
2006-08-19 11:00 ` Helge Hafting
0 siblings, 1 reply; 192+ messages in thread
From: Greg KH @ 2006-08-18 21:56 UTC (permalink / raw)
To: Helge Hafting; +Cc: Andrew Morton, linux-kernel
On Fri, Aug 18, 2006 at 12:34:34AM +0200, Helge Hafting wrote:
> On Fri, Aug 18, 2006 at 12:10:52AM +0200, Helge Hafting wrote:
> > So I tried 2.6.18-rc4-mm1 on my opteron. (Running 64-bit)
> >
> > The kernel did not boot, but went into an infinite loop of
> >
> > Spurious ACK on isa0060/serio0
> > over and over. I have two keyboards, one attached the usual
> > way and another attached where a mouse usually goes.
> > This works fine with 2.6.18-rc2, but no longer now.
> > One keyboard is dead, and on the other, two of the
> > leds blink on and off.
> >
> > Unplugging a keyboard changes the repeating message to
> > Spurious NAK ... instead.
> >
> > Unplugging both keyboards stops the nonsense, but then - no keyboard.
> >
> > This kernel also fails to mount root, a fact that is hard to see as
> > the stupid messages quickly scroll everything else away.
> > That might be something simple like the changed ATA config
> > or multithreaded pci probe.
> >
> > There just cannot be any program "trying to access hw directly",
> > I don't get the root fs so I don't even have init running.
> >
> I got rid of the multithreaded PCI probe - and the root fs was
> recognised again (I have both SATA and SCSI, perhaps they
> were probed in wrong order)
Are you using the ata_piix driver by chance for your root partition? If
so, the multi-thread stuff will not work unless you use the hack below.
> Curiously enough, the keyboard trouble went away too. Odd.
> Now posting from a working 2.6.18-rc4-mm1 (With the jiffies hotfix)
The keyboard stuff is very odd, your keyboard should not be on the PCI
bus :(
thanks,
greg k-h
--------------
From: Greg Kroah-Hartman <gregkh@suse.de>
Subject: Driver: multi-threaded hacks
- Fix "issue" with ata_piix doing multi-threaded boot
Use at your own risk.
---
drivers/scsi/ata_piix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- gregkh-2.6.orig/drivers/scsi/ata_piix.c
+++ gregkh-2.6/drivers/scsi/ata_piix.c
@@ -945,7 +945,7 @@ static int __init piix_init(void)
if (rc)
return rc;
- in_module_init = 0;
+// in_module_init = 0; multi-threaded probe doesn't like this...
DPRINTK("done\n");
return 0;
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 Spurious ACK/NAK on isa0060/serio0, 2.6.18-rc2 is fine
2006-08-18 21:56 ` Greg KH
@ 2006-08-19 11:00 ` Helge Hafting
0 siblings, 0 replies; 192+ messages in thread
From: Helge Hafting @ 2006-08-19 11:00 UTC (permalink / raw)
To: Greg KH; +Cc: Andrew Morton, linux-kernel
On Fri, Aug 18, 2006 at 02:56:44PM -0700, Greg KH wrote:
> On Fri, Aug 18, 2006 at 12:34:34AM +0200, Helge Hafting wrote:
> > On Fri, Aug 18, 2006 at 12:10:52AM +0200, Helge Hafting wrote:
> > > So I tried 2.6.18-rc4-mm1 on my opteron. (Running 64-bit)
> > >
> > > The kernel did not boot, but went into an infinite loop of
> > >
> > > Spurious ACK on isa0060/serio0
> > > over and over. I have two keyboards, one attached the usual
> > > way and another attached where a mouse usually goes.
> > > This works fine with 2.6.18-rc2, but no longer now.
> > > One keyboard is dead, and on the other, two of the
> > > leds blink on and off.
> > >
> > > Unplugging a keyboard changes the repeating message to
> > > Spurious NAK ... instead.
> > >
> > > Unplugging both keyboards stops the nonsense, but then - no keyboard.
> > >
> > > This kernel also fails to mount root, a fact that is hard to see as
> > > the stupid messages quickly scroll everything else away.
> > > That might be something simple like the changed ATA config
> > > or multithreaded pci probe.
> > >
> > > There just cannot be any program "trying to access hw directly",
> > > I don't get the root fs so I don't even have init running.
> > >
> > I got rid of the multithreaded PCI probe - and the root fs was
> > recognised again (I have both SATA and SCSI, perhaps they
> > were probed in wrong order)
>
> Are you using the ata_piix driver by chance for your root partition? If
> so, the multi-thread stuff will not work unless you use the hack below.
>
No, the root is on via sata.
> > Curiously enough, the keyboard trouble went away too. Odd.
> > Now posting from a working 2.6.18-rc4-mm1 (With the jiffies hotfix)
>
> The keyboard stuff is very odd, your keyboard should not be on the PCI
> bus :(
No, it is almost ordinary. Almost, for I have another keyboard
still connected to the ps2 mouse port, I used to have a two-user setup.
I don't have any pci cards with keyboards connected.
Helge Hafting
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 - time moving at 3x speed!
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (26 preceding siblings ...)
2006-08-17 22:10 ` 2.6.18-rc4-mm1 Spurious ACK/NAK on isa0060/serio0, 2.6.18-rc2 is fine Helge Hafting
@ 2006-08-17 22:44 ` Helge Hafting
2006-08-17 23:15 ` john stultz
2006-08-19 23:16 ` [mm patch] drm, minor fixes Frederik Deweerdt
2006-08-20 14:48 ` [PATCH -mm] agp.h: constify struct agp_bridge_data::version Alexey Dobriyan
29 siblings, 1 reply; 192+ messages in thread
From: Helge Hafting @ 2006-08-17 22:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
I got 2.6.18-rc4-mm1 going, and it appears that system
moves at about 3x normal speed. A software clock need 3
seconds to advance 10 seconds, for example.
Everything else seems faster too, the keyboard autorepeat,
delay loops in games, and so on.
Guess I could live with this, if it'd also compile
3x faster. :-/
This is a x86-64 kernel, with the jiffies hotfix applied.
Helge Hafting
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 - time moving at 3x speed!
2006-08-17 22:44 ` 2.6.18-rc4-mm1 - time moving at 3x speed! Helge Hafting
@ 2006-08-17 23:15 ` john stultz
2006-08-18 8:18 ` Helge Hafting
2006-08-18 9:34 ` Andi Kleen
0 siblings, 2 replies; 192+ messages in thread
From: john stultz @ 2006-08-17 23:15 UTC (permalink / raw)
To: Helge Hafting; +Cc: Andi Kleen, Andrew Morton, linux-kernel
On Fri, 2006-08-18 at 00:44 +0200, Helge Hafting wrote:
> I got 2.6.18-rc4-mm1 going, and it appears that system
> moves at about 3x normal speed. A software clock need 3
> seconds to advance 10 seconds, for example.
>
> Everything else seems faster too, the keyboard autorepeat,
> delay loops in games, and so on.
>
> Guess I could live with this, if it'd also compile
> 3x faster. :-/
>
> This is a x86-64 kernel, with the jiffies hotfix applied.
Sounds like the same issue Gregorie Favre is dealing with.
Please send full dmesg output.
Does 2.6.18-rc4, or 2.6.18-rc3-mm2 have this issue?
thanks
-john
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 - time moving at 3x speed!
2006-08-17 23:15 ` john stultz
@ 2006-08-18 8:18 ` Helge Hafting
2006-08-18 9:34 ` Andi Kleen
1 sibling, 0 replies; 192+ messages in thread
From: Helge Hafting @ 2006-08-18 8:18 UTC (permalink / raw)
To: john stultz; +Cc: Helge Hafting, Andi Kleen, Andrew Morton, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
john stultz wrote:
> On Fri, 2006-08-18 at 00:44 +0200, Helge Hafting wrote:
>
>> I got 2.6.18-rc4-mm1 going, and it appears that system
>> moves at about 3x normal speed. A software clock need 3
>> seconds to advance 10 seconds, for example.
>>
>> Everything else seems faster too, the keyboard autorepeat,
>> delay loops in games, and so on.
>>
>> Guess I could live with this, if it'd also compile
>> 3x faster. :-/
>>
>> This is a x86-64 kernel, with the jiffies hotfix applied.
>>
>
> Sounds like the same issue Gregorie Favre is dealing with.
>
> Please send full dmesg output.
>
> Does 2.6.18-rc4, or 2.6.18-rc3-mm2 have this issue?
>
I don't yet know, the previous kernel was 2.6.18-rc2 and it
did not have this problem. I can try those kernels though.
The speed variations are not consistent, the clock is very uneven.
For example, the seconds displayed by the clock in icewm
does not only advance too fast, but sometimes by two seconds
at a time. I.e. icewm wakes up after its 1-second timer expired (too fast)
and then "time" has moved another second forward. No load
is necessary to see this.
The dmesg is attached.
Helge Hafting
[-- Attachment #2: dmesg.timingerrors --]
[-- Type: text/plain, Size: 24745 bytes --]
Linux version 2.6.18-rc4-mm1 (helge@tenkende-august.homelinux.net) (gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)) #4 Fri Aug 18 01:19:30 CEST 2006
Command line: auto BOOT_IMAGE=2.6.18rc4mm1 root=831
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001fee0000 (usable)
BIOS-e820: 000000001fee0000 - 000000001fee3000 (ACPI NVS)
BIOS-e820: 000000001fee3000 - 000000001fef0000 (ACPI data)
BIOS-e820: 000000001fef0000 - 000000001ff00000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
DMI 2.3 present.
ACPI: RSDP (v000 VIAK8 ) @ 0x00000000000f6980
ACPI: RSDT (v001 VIAK8 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000001fee3000
ACPI: FADT (v001 VIAK8 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000001fee3040
ACPI: MADT (v001 VIAK8 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000001fee7b40
ACPI: DSDT (v001 VIAK8 AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x0000000000000000
On node 0 totalpages: 127070
DMA zone: 2114 pages, LIFO batch:0
DMA32 zone: 124956 pages, LIFO batch:31
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Nosave address range: 000000000009d000 - 000000000009e000
Nosave address range: 000000000009e000 - 00000000000a0000
Nosave address range: 00000000000a0000 - 00000000000f0000
Nosave address range: 00000000000f0000 - 0000000000100000
Allocating PCI resources starting at 20000000 (gap: 1ff00000:ded00000)
Built 1 zonelists. Total pages: 127070
Kernel command line: auto BOOT_IMAGE=2.6.18rc4mm1 root=831
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 16384 bytes)
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 1804.124 MHz processor.
Console: colour VGA+ 80x50
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Checking aperture...
CPU 0: aperture @ d8000000 size 128 MB
Memory: 507120k/523136k available (4043k kernel code, 15284k reserved, 2461k data, 252k init)
Calibrating delay using timer specific routine.. 3610.65 BogoMIPS (lpj=1805325)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: AMD Opteron(tm) Processor 244 stepping 0a
ACPI: Core revision 20060707
Using local APIC timer interrupts.
result 12528646
Detected 12.528 MHz APIC timer.
testing NMI watchdog ... OK.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:00:08.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 10 *11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 6 7 *10 11 12)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 *11 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 11 12) *5
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 6 7 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 6 7 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [ALKA] (IRQs 20) *0, disabled.
ACPI: PCI Interrupt Link [ALKB] (IRQs 21) *0, disabled.
ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *0, disabled.
ACPI: PCI Interrupt Link [ALKD] (IRQs 23) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 13 devices
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
agpgart: Detected AGP bridge 0
agpgart: AGP aperture is 128M @ 0xd8000000
PCI-DMA: Disabling IOMMU.
pnp: 00:02: ioport range 0x4000-0x407f could not be reserved
pnp: 00:02: ioport range 0x5000-0x500f has been reserved
PCI: Bridge: 0000:00:01.0
IO window: disabled.
MEM window: f2000000-f4ffffff
PREFETCH window: f0000000-f1ffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 3, 32768 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
matroxfb: Matrox G550 detected
matroxfb: Legacy BIOS is for F2E9:0012, while this device is 102B:2527
matroxfb: Your Matrox device does not have BIOS
PInS memtype = 4
matroxfb: cannot determine memory size
matroxfb: probe of 0000:01:00.0 failed with error -1
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Fan [FAN] (on)
ACPI: Getting cpuindex for acpiid 0x1
ACPI: Thermal Zone [THRM] (40 C)
lp: driver loaded but no devices found
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.101 (c) Dave Jones
[drm] Initialized drm 1.0.1 20051102
[drm] Initialized mga 3.2.1 20051102 on minor 0
Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
Hangcheck: Using monotonic_clock().
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
lp0: using parport0 (interrupt-driven).
floppy0: no floppy controllers found
loop: loaded (max 8 devices)
tg3.c:v3.65 (August 07, 2006)
ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 16 (level, low) -> IRQ 16
eth0: Tigon3 [partno(BCM95705A50) rev 3003 PHY(5705)] (PCI:33MHz:32-bit) 10/100/1000BaseT Ethernet 00:0c:76:ac:93:90
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[0] TSOcap[1]
eth0: dma_rwctrl[763f0000] dma_mask[64-bit]
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP MPPE Compression module registered
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:0f.1
ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 20
ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 20
ACPI: PCI Interrupt 0000:00:0f.1[A] -> Link [ALKA] -> GSI 20 (level, low) -> IRQ 20
PCI: VIA IRQ fixup for 0000:00:0f.1, from 255 to 4
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
ide0: BM-DMA at 0xb400-0xb407, BIOS settings: hda:DMA, hdb:pio
Probing IDE interface ide0...
hda: PLEXTOR DVDR PX-712A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 8192kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ACPI: PCI Interrupt 0000:00:05.0[A] -> GSI 16 (level, low) -> IRQ 16
sym0: <895> rev 0x1 at pci 0000:00:05.0 irq 16
sym0: Tekram NVRAM, ID 7, Fast-40, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.3
scsi 0:0:0:0: Direct access FUJITSU MAS3184NP 0104 PQ: 0 ANSI: 3
target0:0:0: tagged command queuing enabled, command queue depth 16.
target0:0:0: Beginning Domain Validation
target0:0:0: asynchronous
target0:0:0: wide asynchronous
target0:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
target0:0:0: Domain Validation skipping write tests
target0:0:0: Ending Domain Validation
target0:0:1: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
scsi 0:0:1:0: Direct access IBM DDYS-T09170N S96H PQ: 0 ANSI: 3
target0:0:1: tagged command queuing enabled, command queue depth 16.
target0:0:1: Beginning Domain Validation
target0:0:1: asynchronous
target0:0:1: wide asynchronous
target0:0:1: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
target0:0:1: Domain Validation skipping write tests
target0:0:1: Ending Domain Validation
scsi 0:0:6:0: Direct access IBM IC35L018UWD210-0 S5BS PQ: 0 ANSI: 3
target0:0:6: tagged command queuing enabled, command queue depth 16.
target0:0:6: Beginning Domain Validation
target0:0:6: asynchronous
target0:0:6: wide asynchronous
target0:0:6: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
target0:0:6: Domain Validation skipping write tests
target0:0:6: Ending Domain Validation
SCSI device sda: 35890512 512-byte hdwr sectors (18376 MB)
sda: Write Protect is off
sda: Mode Sense: b3 00 00 08
SCSI device sda: drive cache: write back
SCSI device sda: 35890512 512-byte hdwr sectors (18376 MB)
sda: Write Protect is off
sda: Mode Sense: b3 00 00 08
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 >
sd 0:0:0:0: Attached scsi disk sda
SCSI device sdb: 17916240 512-byte hdwr sectors (9173 MB)
sdb: Write Protect is off
sdb: Mode Sense: cb 00 00 08
SCSI device sdb: drive cache: write back
SCSI device sdb: 17916240 512-byte hdwr sectors (9173 MB)
sdb: Write Protect is off
sdb: Mode Sense: cb 00 00 08
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2 < sdb5 sdb6 >
sd 0:0:1:0: Attached scsi disk sdb
SCSI device sdc: 35843670 512-byte hdwr sectors (18352 MB)
sdc: Write Protect is off
sdc: Mode Sense: cb 00 00 08
SCSI device sdc: drive cache: write back
SCSI device sdc: 35843670 512-byte hdwr sectors (18352 MB)
sdc: Write Protect is off
sdc: Mode Sense: cb 00 00 08
SCSI device sdc: drive cache: write back
sdc: sdc1 sdc2 sdc3
sd 0:0:6:0: Attached scsi disk sdc
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:1:0: Attached scsi generic sg1 type 0
sd 0:0:6:0: Attached scsi generic sg2 type 0
libata version 2.00 loaded.
sata_via 0000:00:0f.0: version 2.0
ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20 (level, low) -> IRQ 20
PCI: VIA IRQ fixup for 0000:00:0f.0, from 10 to 4
sata_via 0000:00:0f.0: routed to hard irq line 4
ata1: SATA max UDMA/133 cmd 0x9C00 ctl 0xA002 bmdma 0xAC00 irq 20
ata2: SATA max UDMA/133 cmd 0xA400 ctl 0xA802 bmdma 0xAC08 irq 20
scsi1 : sata_via
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: ATA-7, max UDMA/133, 398297088 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
scsi2 : sata_via
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata2.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48
ata2.00: ata2: dev 0 multi count 16
ata2.00: configured for UDMA/133
scsi 1:0:0:0: Direct access ATA Maxtor 6B200M0 BANC PQ: 0 ANSI: 5
SCSI device sdd: 398297088 512-byte hdwr sectors (203928 MB)
sdd: Write Protect is off
sdd: Mode Sense: 00 3a 00 00
SCSI device sdd: drive cache: write back
SCSI device sdd: 398297088 512-byte hdwr sectors (203928 MB)
sdd: Write Protect is off
sdd: Mode Sense: 00 3a 00 00
SCSI device sdd: drive cache: write back
sdd: sdd1 sdd2
sd 1:0:0:0: Attached scsi disk sdd
sd 1:0:0:0: Attached scsi generic sg3 type 0
scsi 2:0:0:0: Direct access ATA WDC WD2000JD-00H 08.0 PQ: 0 ANSI: 5
SCSI device sde: 390721968 512-byte hdwr sectors (200050 MB)
sde: Write Protect is off
sde: Mode Sense: 00 3a 00 00
SCSI device sde: drive cache: write back
SCSI device sde: 390721968 512-byte hdwr sectors (200050 MB)
sde: Write Protect is off
sde: Mode Sense: 00 3a 00 00
SCSI device sde: drive cache: write back
sde: sde1 sde2
sd 2:0:0:0: Attached scsi disk sde
sd 2:0:0:0: Attached scsi generic sg4 type 0
usbmon: debugfs is not available
ACPI: PCI Interrupt Link [ALKB] BIOS reported IRQ 0, using IRQ 21
ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 21
ACPI: PCI Interrupt 0000:00:10.4[C] -> Link [ALKB] -> GSI 21 (level, low) -> IRQ 21
PCI: VIA IRQ fixup for 0000:00:10.4, from 11 to 5
ehci_hcd 0000:00:10.4: EHCI Host Controller
ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:10.4: irq 21, io mem 0xf6033000
ehci_hcd 0000:00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
USB Universal Host Controller Interface driver v3.0
usb usb1: new device found, idVendor=0000, idProduct=0000
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.18-rc4-mm1 ehci_hcd
usb usb1: SerialNumber: 0000:00:10.4
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [ALKB] -> GSI 21 (level, low) -> IRQ 21
PCI: VIA IRQ fixup for 0000:00:10.0, from 11 to 5
uhci_hcd 0000:00:10.0: UHCI Host Controller
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:10.0: irq 21, io base 0x0000b800
ACPI: PCI Interrupt 0000:00:10.1[A] -> Link [ALKB] -> GSI 21 (level, low) -> IRQ 21
PCI: VIA IRQ fixup for 0000:00:10.1, from 11 to 5
uhci_hcd 0000:00:10.1: UHCI Host Controller
usb usb2: new device found, idVendor=0000, idProduct=0000
usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.18-rc4-mm1 uhci_hcd
usb usb2: SerialNumber: 0000:00:10.0
usb usb1: configuration #1 chosen from 1 choice
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:10.1: irq 21, io base 0x0000bc00
ACPI: PCI Interrupt 0000:00:10.2[B] -> Link [ALKB] -> GSI 21 (level, low) -> IRQ 21
PCI: VIA IRQ fixup for 0000:00:10.2, from 10 to 5
uhci_hcd 0000:00:10.2: UHCI Host Controller
usb usb3: new device found, idVendor=0000, idProduct=0000
usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: UHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.18-rc4-mm1 uhci_hcd
usb usb3: SerialNumber: 0000:00:10.1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:10.2: irq 21, io base 0x0000c000
usb usb4: new device found, idVendor=0000, idProduct=0000
usb usb4: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: UHCI Host Controller
usb usb4: Manufacturer: Linux 2.6.18-rc4-mm1 uhci_hcd
usb usb4: SerialNumber: 0000:00:10.2
usb usb2: configuration #1 chosen from 1 choice
usbcore: registered new interface driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usb usb3: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb usb4: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
usbcore: registered new interface driver libusual
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
usbcore: registered new interface driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for PocketPC PDA
drivers/usb/serial/ipaq.c: USB PocketPC PDA driver v0.5
usbcore: registered new interface driver ipaq
drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303
usbcore: registered new interface driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
input: AT Translated Set 2 keyboard as /class/input/input0
input: AT Raw Set 2 keyboard as /class/input/input1
i2c_adapter i2c-0: detect fail: address match, 0x2f
usb 1-1: new high speed USB device using ehci_hcd and address 2
usb 1-1: new device found, idVendor=04b8, idProduct=0007
usb 1-1: new device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: USB2.0 Printer (Hi-speed)
usb 1-1: Manufacturer: EPSON
usb 1-1: SerialNumber: HL0170501241619570
usb 1-1: configuration #1 chosen from 1 choice
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x04B8 pid 0x0007
usb 1-3: new high speed USB device using ehci_hcd and address 3
pc87360: PC8736x not detected, module not inserted.
md: raid1 personality registered for level 1
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
EDAC MC: Ver: 2.0.1 Aug 18 2006
EDAC MC0: Giving out device to k8_edac Athlon64/Opteron: DEV 0000:00:18.2
sdhci: Secure Digital Host Controller Interface driver, 0.12
sdhci: Copyright(c) Pierre Ossman
wbsd: Winbond W83L51xD SD/MMC card interface driver, 1.6
wbsd: Copyright(c) Pierre Ossman
Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).
ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 17 (level, low) -> IRQ 17
gameport: Trident 4DWave is pci0000:00:06.0/gameport0, speed 1885kHz
ALSA device list:
#0: Trident TRID4DWAVENX PCI Audio at 0x9400, irq 17
oprofile: using NMI interrupt.
Netfilter messages via NETLINK v0.30.
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
ip_conntrack version 2.4 (2043 buckets, 16344 max) - 288 bytes per conntrack
ip_tables: (C) 2000-2006 Netfilter Core Team
joydump: ,------------------ START ----------------.
joydump: | Dumping: pci0000:00:06.0/gameport0 |
joydump: | Speed: 1885 kHz |
joydump: >------------------ DATA -----------------<
joydump: | index: 0 delta: 0 us data: 11111111 |
joydump: `------------------- END -----------------'
usb 1-3: new device found, idVendor=10df, idProduct=0500
usb 1-3: new device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-3: Product:
usb 1-3: Manufacturer: USB2.0
usb 1-3: SerialNumber: 041000001C22
usb 1-3: configuration #1 chosen from 1 choice
scsi3 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
ClusterIP Version 0.8 loaded successfully
TCP bic registered
TCP cubic registered
TCP westwood registered
TCP highspeed registered
TCP hybla registered
TCP htcp registered
TCP vegas registered
TCP veno registered
TCP scalable registered
TCP lp registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
ip6_tables: (C) 2000-2006 Netfilter Core Team
NET: Registered protocol family 17
NET: Registered protocol family 15
CCID: Registered CCID 3 (ccid3)
CCID: Registered CCID 2 (ccid2)
SCTP: Hash tables configured (established 16384 bind 16384)
powernow-k8: Found 1 AMD Opteron(tm) Processor 244 processors (version 2.00.00)
powernow-k8: BIOS error - no PSB or ACPI _PSS objects
BIOS EDD facility v0.16 2004-Jun-25, 4 devices found
md: Autodetecting RAID arrays.
md: autorun ...
md: considering sde2 ...
md: adding sde2 ...
md: adding sdd2 ...
md: sdc1 has different UUID to sde2
md: sdb5 has different UUID to sde2
md: sdb1 has different UUID to sde2
md: sda5 has different UUID to sde2
md: sda2 has different UUID to sde2
md: created md2
md: bind<sdd2>
md: bind<sde2>
md: running: <sde2><sdd2>
raid1: raid set md2 active with 2 out of 2 mirrors
md2: bitmap initialized from disk: read 12/12 pages, set 1 bits, status: 0
created bitmap (177 pages) for device md2
md: considering sdc1 ...
md: adding sdc1 ...
md: adding sdb5 ...
md: sdb1 has different UUID to sdc1
md: adding sda5 ...
md: sda2 has different UUID to sdc1
md: created md3
md: bind<sda5>
md: bind<sdb5>
md: export_rdev(sdc1)
md: running: <sdb5><sda5>
raid1: raid set md3 active with 2 out of 2 mirrors
md: considering sdb1 ...
md: adding sdb1 ...
md: adding sda2 ...
md: created md0
md: bind<sda2>
md: bind<sdb1>
md: running: <sdb1><sda2>
raid1: raid set md0 active with 2 out of 2 mirrors
md: ... autorun DONE.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 252k freed
usb 4-1: new full speed USB device using uhci_hcd and address 2
usb 4-1: new device found, idVendor=04b8, idProduct=010b
usb 4-1: new device strings: Mfr=1, Product=2, SerialNumber=0
usb 4-1: Product: Perfection1240
usb 4-1: Manufacturer: EPSON
usb 4-1: configuration #1 chosen from 1 choice
usb 4-2: new low speed USB device using uhci_hcd and address 3
usb 4-2: new device found, idVendor=09da, idProduct=001a
usb 4-2: new device strings: Mfr=1, Product=2, SerialNumber=0
usb 4-2: Product: RF USB Mouse
usb 4-2: Manufacturer: A4Tech
usb 4-2: configuration #1 chosen from 1 choice
input: A4Tech RF USB Mouse as /class/input/input2
input: USB HID v1.10 Mouse [A4Tech RF USB Mouse] on usb-0000:00:10.2-2
warning: process `touch' used the removed sysctl system call
warning: process `touch' used the removed sysctl system call
warning: process `touch' used the removed sysctl system call
warning: process `alsactl' used the removed sysctl system call
warning: process `touch' used the removed sysctl system call
scsi 3:0:0:0: Direct access USB2.0 HS-CF 1.64 PQ: 0 ANSI: 0
sd 3:0:0:0: Attached scsi removable disk sdf
sd 3:0:0:0: Attached scsi generic sg5 type 0
scsi 3:0:0:1: Direct access USB2.0 HS-MS 1.64 PQ: 0 ANSI: 0
sd 3:0:0:1: Attached scsi removable disk sdg
sd 3:0:0:1: Attached scsi generic sg6 type 0
scsi 3:0:0:2: Direct access USB2.0 HS-SM 1.64 PQ: 0 ANSI: 0
sd 3:0:0:2: Attached scsi removable disk sdh
sd 3:0:0:2: Attached scsi generic sg7 type 0
scsi 3:0:0:3: Direct access USB2.0 HS-SD/MMC 1.64 PQ: 0 ANSI: 0
sd 3:0:0:3: Attached scsi removable disk sdi
sd 3:0:0:3: Attached scsi generic sg8 type 0
usb-storage: device scan complete
loadkeys[2148]: segfault at 00000000000005a0 rip 00002ae93bf56dc9 rsp 00007fff6ee83bb8 error 4
Adding 1000424k swap on /dev/sda6. Priority:1 extents:1 across:1000424k
EXT3 FS on sdd1, internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS on md3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda8, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on md2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on md0, internal journal
EXT3-fs: mounted filesystem with journal data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with writeback data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
PM: Writing back config space on device 0000:00:0b.0 at offset b (was 165314e4, writing 13001462)
PM: Writing back config space on device 0000:00:0b.0 at offset 3 (was 0, writing 2008)
PM: Writing back config space on device 0000:00:0b.0 at offset 2 (was 2000000, writing 2000003)
PM: Writing back config space on device 0000:00:0b.0 at offset 1 (was 2b00000, writing 2b00006)
ADDRCONF(NETDEV_UP): eth0: link is not ready
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
eth0: no IPv6 routers present
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 - time moving at 3x speed!
2006-08-17 23:15 ` john stultz
2006-08-18 8:18 ` Helge Hafting
@ 2006-08-18 9:34 ` Andi Kleen
2006-08-18 9:30 ` Helge Hafting
1 sibling, 1 reply; 192+ messages in thread
From: Andi Kleen @ 2006-08-18 9:34 UTC (permalink / raw)
To: john stultz; +Cc: Helge Hafting, Andrew Morton, linux-kernel
On Friday 18 August 2006 01:15, john stultz wrote:
> On Fri, 2006-08-18 at 00:44 +0200, Helge Hafting wrote:
> > I got 2.6.18-rc4-mm1 going, and it appears that system
> > moves at about 3x normal speed. A software clock need 3
> > seconds to advance 10 seconds, for example.
> >
> > Everything else seems faster too, the keyboard autorepeat,
> > delay loops in games, and so on.
> >
> > Guess I could live with this, if it'd also compile
> > 3x faster. :-/
> >
> > This is a x86-64 kernel, with the jiffies hotfix applied.
>
> Sounds like the same issue Gregorie Favre is dealing with.
>
> Please send full dmesg output.
>
> Does 2.6.18-rc4, or 2.6.18-rc3-mm2 have this issue
FWIW i looked through the x86-64 patch changes between
rc3-mm2 and rc4-mm1 and I can't find anything that would be remotely
related to the timer.
If it's confirmed to have regressed in this time it would require a binary
search to track down I think.
-Andi
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 - time moving at 3x speed!
2006-08-18 9:34 ` Andi Kleen
@ 2006-08-18 9:30 ` Helge Hafting
2006-08-18 10:55 ` Andi Kleen
0 siblings, 1 reply; 192+ messages in thread
From: Helge Hafting @ 2006-08-18 9:30 UTC (permalink / raw)
To: Andi Kleen; +Cc: john stultz, Helge Hafting, Andrew Morton, linux-kernel
Andi Kleen wrote:
> On Friday 18 August 2006 01:15, john stultz wrote:
>
>> On Fri, 2006-08-18 at 00:44 +0200, Helge Hafting wrote:
>>
>>> I got 2.6.18-rc4-mm1 going, and it appears that system
>>> moves at about 3x normal speed. A software clock need 3
>>> seconds to advance 10 seconds, for example.
>>>
>>> Everything else seems faster too, the keyboard autorepeat,
>>> delay loops in games, and so on.
>>>
>>> Guess I could live with this, if it'd also compile
>>> 3x faster. :-/
>>>
>>> This is a x86-64 kernel, with the jiffies hotfix applied.
>>>
>> Sounds like the same issue Gregorie Favre is dealing with.
>>
>> Please send full dmesg output.
>>
>> Does 2.6.18-rc4, or 2.6.18-rc3-mm2 have this issue
>>
>
> FWIW i looked through the x86-64 patch changes between
> rc3-mm2 and rc4-mm1 and I can't find anything that would be remotely
> related to the timer.
>
> If it's confirmed to have regressed in this time it would require a binary
> search to track down I think.
>
I have narrowed it down. 2.6.18-rc4 does not have the 3x time
problem, while mm1 have it. mm1 without the hotfix jiffies
patch is just as bad.
Helge Hafting
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 - time moving at 3x speed!
2006-08-18 9:30 ` Helge Hafting
@ 2006-08-18 10:55 ` Andi Kleen
2006-08-18 10:01 ` Helge Hafting
2006-08-19 10:50 ` 2.6.18-rc4-mm1 - time moving at 3x speed, bisect finished Helge Hafting
0 siblings, 2 replies; 192+ messages in thread
From: Andi Kleen @ 2006-08-18 10:55 UTC (permalink / raw)
To: Helge Hafting; +Cc: john stultz, Helge Hafting, Andrew Morton, linux-kernel
> I have narrowed it down. 2.6.18-rc4 does not have the 3x time
> problem, while mm1 have it. mm1 without the hotfix jiffies
> patch is just as bad.
Can you narrow it down to a specific patch in -mm?
-Andi
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 - time moving at 3x speed!
2006-08-18 10:55 ` Andi Kleen
@ 2006-08-18 10:01 ` Helge Hafting
2006-08-18 10:24 ` Rafael J. Wysocki
` (2 more replies)
2006-08-19 10:50 ` 2.6.18-rc4-mm1 - time moving at 3x speed, bisect finished Helge Hafting
1 sibling, 3 replies; 192+ messages in thread
From: Helge Hafting @ 2006-08-18 10:01 UTC (permalink / raw)
To: Andi Kleen; +Cc: john stultz, Helge Hafting, Andrew Morton, linux-kernel
Andi Kleen wrote:
>> I have narrowed it down. 2.6.18-rc4 does not have the 3x time
>> problem, while mm1 have it. mm1 without the hotfix jiffies
>> patch is just as bad.
>>
>
> Can you narrow it down to a specific patch in -mm?
>
How do I do that? Is -mm available through git somehow,
or is there some other clever way?
Helge Hafting
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 - time moving at 3x speed!
2006-08-18 10:01 ` Helge Hafting
@ 2006-08-18 10:24 ` Rafael J. Wysocki
2006-08-18 11:21 ` Andi Kleen
2006-08-18 22:23 ` Randy.Dunlap
2 siblings, 0 replies; 192+ messages in thread
From: Rafael J. Wysocki @ 2006-08-18 10:24 UTC (permalink / raw)
To: Helge Hafting
Cc: Andi Kleen, john stultz, Helge Hafting, Andrew Morton,
linux-kernel
Hi,
On Friday 18 August 2006 12:01, Helge Hafting wrote:
> Andi Kleen wrote:
> >> I have narrowed it down. 2.6.18-rc4 does not have the 3x time
> >> problem, while mm1 have it. mm1 without the hotfix jiffies
> >> patch is just as bad.
> >>
> >
> > Can you narrow it down to a specific patch in -mm?
> >
> How do I do that? Is -mm available through git somehow,
> or is there some other clever way?
You can download the broken-out version of the -mm and use quilt.
Quick start:
- unpack the tarball in a directory containing vanilla 2.6.18-rc4 sources,
- rename 'broken-out' to 'patches'
- use 'quilt push n' to apply the next n patches,
- use 'quilt pop n' to revert the last n patches applied,
- 'quilt applied | wc' gives you the number of patches currently applied,
- 'quilt top' returns the name of the last patch applied.
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 - time moving at 3x speed!
2006-08-18 10:01 ` Helge Hafting
2006-08-18 10:24 ` Rafael J. Wysocki
@ 2006-08-18 11:21 ` Andi Kleen
2006-08-18 22:23 ` Randy.Dunlap
2 siblings, 0 replies; 192+ messages in thread
From: Andi Kleen @ 2006-08-18 11:21 UTC (permalink / raw)
To: Helge Hafting; +Cc: john stultz, Helge Hafting, Andrew Morton, linux-kernel
On Friday 18 August 2006 12:01, Helge Hafting wrote:
> Andi Kleen wrote:
> >> I have narrowed it down. 2.6.18-rc4 does not have the 3x time
> >> problem, while mm1 have it. mm1 without the hotfix jiffies
> >> patch is just as bad.
> >
> > Can you narrow it down to a specific patch in -mm?
>
> How do I do that? Is -mm available through git somehow,
> or is there some other clever way?
Get the patches directory from the ftp server and put it into the
source tree as "patches". Install quilt.
Then select a middle patch from the series file. I would start it
on the boundaries of the various groups Andrew comments first.
Then
quilt push middle-patch
compile/test
if works select new middle in partition below, otherwise above.
repeat until you narrow it down to a single patch.
If the partition is below you have to use quilt pop ... instead of quilt push
Sometimes patches don't compile on their own, but in this case
treating them as groups is ok.
Also when you hit the last patch double check it really changes
the problem by retesting with it applied again.
-Andi
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 - time moving at 3x speed!
2006-08-18 10:01 ` Helge Hafting
2006-08-18 10:24 ` Rafael J. Wysocki
2006-08-18 11:21 ` Andi Kleen
@ 2006-08-18 22:23 ` Randy.Dunlap
2 siblings, 0 replies; 192+ messages in thread
From: Randy.Dunlap @ 2006-08-18 22:23 UTC (permalink / raw)
To: Helge Hafting
Cc: Andi Kleen, john stultz, Helge Hafting, Andrew Morton,
linux-kernel
On Fri, 18 Aug 2006 12:01:00 +0200 Helge Hafting wrote:
> Andi Kleen wrote:
> >> I have narrowed it down. 2.6.18-rc4 does not have the 3x time
> >> problem, while mm1 have it. mm1 without the hotfix jiffies
> >> patch is just as bad.
> >>
> >
> > Can you narrow it down to a specific patch in -mm?
> >
> How do I do that? Is -mm available through git somehow,
> or is there some other clever way?
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
---
~Randy
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 - time moving at 3x speed, bisect finished
2006-08-18 10:55 ` Andi Kleen
2006-08-18 10:01 ` Helge Hafting
@ 2006-08-19 10:50 ` Helge Hafting
2006-08-20 17:06 ` Roman Zippel
1 sibling, 1 reply; 192+ messages in thread
From: Helge Hafting @ 2006-08-19 10:50 UTC (permalink / raw)
To: Andi Kleen; +Cc: Helge Hafting, john stultz, Andrew Morton, linux-kernel
On Fri, Aug 18, 2006 at 12:55:46PM +0200, Andi Kleen wrote:
>
> > I have narrowed it down. 2.6.18-rc4 does not have the 3x time
> > problem, while mm1 have it. mm1 without the hotfix jiffies
> > patch is just as bad.
>
> Can you narrow it down to a specific patch in -mm?
>
The guilty patch is:
ntp-add-ntp_update_frequency.patch
Up to and including the previous patch,
wich is ntp-move-all-the-ntp-related-code-to-ntpc-fix.patch,
everything is fine. But apply this one, and
time moves at 3x speed. This makes games interesting,
and the keyboard autorepeat awesome. :-)
The patch found seems reasonable, it is
definitely time-related.
Thanks to all who sent a tutorial on quilt bisection!
Helge Hafting
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: 2.6.18-rc4-mm1 - time moving at 3x speed, bisect finished
2006-08-19 10:50 ` 2.6.18-rc4-mm1 - time moving at 3x speed, bisect finished Helge Hafting
@ 2006-08-20 17:06 ` Roman Zippel
2006-08-20 17:51 ` thunder7
0 siblings, 1 reply; 192+ messages in thread
From: Roman Zippel @ 2006-08-20 17:06 UTC (permalink / raw)
To: Helge Hafting
Cc: Andi Kleen, Helge Hafting, john stultz, Andrew Morton,
linux-kernel, thunder7
Hi,
On Sat, 19 Aug 2006, Helge Hafting wrote:
> > Can you narrow it down to a specific patch in -mm?
> >
> The guilty patch is:
> ntp-add-ntp_update_frequency.patch
That's really weird, I don't really have an idea why it should go wrong
there, could you please try the patch below and send me the kernel output?
Thanks.
bye, Roman
---
kernel/time/ntp.c | 9 +++++++++
1 file changed, 9 insertions(+)
Index: linux-2.6-mm/kernel/time/ntp.c
===================================================================
--- linux-2.6-mm.orig/kernel/time/ntp.c
+++ linux-2.6-mm/kernel/time/ntp.c
@@ -46,12 +46,21 @@ long time_adjust;
static void ntp_update_frequency(void)
{
tick_length_base = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ) << TICK_LENGTH_SHIFT;
+ printk("%Lx,", tick_length_base);
tick_length_base += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT;
+ printk("%Lx,", tick_length_base);
tick_length_base += (s64)time_freq << (TICK_LENGTH_SHIFT - SHIFT_NSEC);
+ printk("%Lx,", tick_length_base);
do_div(tick_length_base, HZ);
+ printk("%Lx\n", tick_length_base);
tick_nsec = tick_length_base >> TICK_LENGTH_SHIFT;
+ printk("u: %u.%06u, %ld.%04lu\n",
+ (u32)(tick_length_base >> TICK_LENGTH_SHIFT),
+ (u32)(((tick_length_base & ((1ll << TICK_LENGTH_SHIFT) - 1)) * 1000000) >> TICK_LENGTH_SHIFT),
+ time_offset >> SHIFT_UPDATE,
+ ((time_offset & ((1 << SHIFT_UPDATE) - 1)) * 1000) >> SHIFT_UPDATE);
}
/**
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 - time moving at 3x speed, bisect finished
2006-08-20 17:06 ` Roman Zippel
@ 2006-08-20 17:51 ` thunder7
2006-08-20 19:24 ` Roman Zippel
0 siblings, 1 reply; 192+ messages in thread
From: thunder7 @ 2006-08-20 17:51 UTC (permalink / raw)
To: Roman Zippel
Cc: Helge Hafting, Andi Kleen, john stultz, Andrew Morton,
linux-kernel, thunder7
From: Roman Zippel <zippel@linux-m68k.org>
Date: Sun, Aug 20, 2006 at 07:06:21PM +0200
> Hi,
>
> On Sat, 19 Aug 2006, Helge Hafting wrote:
>
> > > Can you narrow it down to a specific patch in -mm?
> > >
> > The guilty patch is:
> > ntp-add-ntp_update_frequency.patch
>
> That's really weird, I don't really have an idea why it should go wrong
> there, could you please try the patch below and send me the kernel output?
> Thanks.
>
The interesting part:
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
Kind regards,
Jurriaan
Full dmesg:
Linux version 2.6.18-rc4-mm2 (jurriaan@middle) (gcc version 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)) #3 Sun Aug 20 19:43:39 CEST 2006
Command line: root=/dev/md2 video=nvidiafb:1600x1200-32@85 atkbd.softrepeat=1
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009c800 (usable)
BIOS-e820: 000000000009c800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000bfff0000 (usable)
BIOS-e820: 00000000bfff0000 - 00000000bfff3000 (ACPI NVS)
BIOS-e820: 00000000bfff3000 - 00000000c0000000 (ACPI data)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
DMI 2.3 present.
ACPI: RSDP (v000 Nvidia ) @ 0x00000000000f7d30
ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x00000000bfff3040
ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x00000000bfff30c0
ACPI: SSDT (v001 PTLTD POWERNOW 0x00000001 LTP 0x00000001) @ 0x00000000bfff9900
ACPI: SRAT (v001 AMD HAMMER 0x00000001 AMD 0x00000001) @ 0x00000000bfff9a40
ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x00000000bfff9b40
ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x00000000bfff9840
ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x0000000000000000
On node 0 totalpages: 1028777
DMA zone: 2177 pages, LIFO batch:0
DMA32 zone: 768040 pages, LIFO batch:31
Normal zone: 258560 pages, LIFO batch:31
Nvidia board detected. Ignoring ACPI timer override.
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:7 APIC version 16
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
ACPI: IRQ9 used by override.
ACPI: IRQ14 used by override.
ACPI: IRQ15 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Nosave address range: 000000000009c000 - 000000000009d000
Nosave address range: 000000000009d000 - 00000000000a0000
Nosave address range: 00000000000a0000 - 00000000000f0000
Nosave address range: 00000000000f0000 - 0000000000100000
Nosave address range: 00000000bfff0000 - 00000000bfff3000
Nosave address range: 00000000bfff3000 - 00000000c0000000
Nosave address range: 00000000c0000000 - 00000000e0000000
Nosave address range: 00000000e0000000 - 00000000f0000000
Nosave address range: 00000000f0000000 - 00000000fec00000
Nosave address range: 00000000fec00000 - 0000000100000000
Allocating PCI resources starting at c2000000 (gap: c0000000:20000000)
Built 1 zonelists. Total pages: 1028777
Kernel command line: root=/dev/md2 video=nvidiafb:1600x1200-32@85 atkbd.softrepeat=1
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
u: 3538559.870999, 0.0000
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 2211.364 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Checking aperture...
CPU 0: aperture @ 8000000 size 32 MB
Aperture too small (32 MB)
No AGP bridge found
Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 8000000
Memory: 4042988k/5242880k available (3762k kernel code, 150536k reserved, 2309k data, 232k init)
Calibrating delay using timer specific routine.. 4423.94 BogoMIPS (lpj=2211970)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: AMD Athlon(tm) 64 Processor 3700+ stepping 01
ACPI: Core revision 20060707
Using local APIC timer interrupts.
result 12564570
Detected 12.564 MHz APIC timer.
testing NMI watchdog ... OK.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using MMCONFIG at e0000000
PCI: No mmconfig possible on device 00:18
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI: Transparent bridge - 0000:00:09.0
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs *3 4 5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs *3 4 5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LMAC] (IRQs *3 4 5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 *7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 *7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSID] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LPCA] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled.
ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled.
ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled.
ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled.
ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled.
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ 8000000 size 65536 KB
PCI-DMA: using GART IOMMU.
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
ieee1394: Initialized config rom entry `ip1394'
ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19
ACPI: PCI Interrupt 0000:05:08.2[B] -> Link [APC4] -> GSI 19 (level, low) -> IRQ 19
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19] MMIO=[d900e000-d900e7ff] Max Packet=[2048] IR/IT contexts=[4/8]
ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
ACPI: PCI Interrupt 0000:05:0b.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 16
ohci1394: fw-host1: OHCI-1394 1.1 (PCI): IRQ=[16] MMIO=[d900d000-d900d7ff] Max Packet=[2048] IR/IT contexts=[4/8]
PCI: Bridge: 0000:00:09.0
IO window: 6000-afff
MEM window: d8000000-d9ffffff
PREFETCH window: da100000-da1fffff
PCI: Bridge: 0000:00:0b.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:0c.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:0d.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:0e.0
IO window: disabled.
MEM window: d0000000-d7ffffff
PREFETCH window: c0000000-cfffffff
PCI: Setting latency timer of device 0000:00:09.0 to 64
PCI: Setting latency timer of device 0000:00:0b.0 to 64
PCI: Setting latency timer of device 0000:00:0c.0 to 64
PCI: Setting latency timer of device 0000:00:0d.0 to 64
PCI: Setting latency timer of device 0000:00:0e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 524288 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 524288 bind 65536)
TCP reno registered
Coda Kernel/Venus communications, v6.0.0, coda@cs.cmu.edu
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.27 [Flags: R/O].
io scheduler noop registered
io scheduler cfq registered (default)
PCI: Linking AER extended capability on 0000:00:0b.0
PCI: Linking AER extended capability on 0000:00:0c.0
PCI: Linking AER extended capability on 0000:00:0d.0
PCI: Linking AER extended capability on 0000:00:0e.0
PCI: Setting latency timer of device 0000:00:0b.0 to 64
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0b.0:pcie00]
Allocate Port Service[0000:00:0b.0:pcie03]
PCI: Setting latency timer of device 0000:00:0c.0 to 64
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0c.0:pcie00]
Allocate Port Service[0000:00:0c.0:pcie03]
PCI: Setting latency timer of device 0000:00:0d.0 to 64
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0d.0:pcie00]
Allocate Port Service[0000:00:0d.0:pcie03]
PCI: Setting latency timer of device 0000:00:0e.0 to 64
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0e.0:pcie00]
Allocate Port Service[0000:00:0e.0:pcie03]
ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18
nvidiafb: Device ID: 10de0141
nvidiafb: CRTC0 analog found
nvidiafb: CRTC1 analog found
i2c_adapter i2c-0: unable to read EDID block.
ohci1394: fw-host0: Running dma failed because Node ID is not valid
i2c_adapter i2c-0: unable to read EDID block.
i2c_adapter i2c-0: unable to read EDID block.
nvidiafb: EDID found from BUS2
nvidiafb: CRTC 0 appears to have a CRT attached
nvidiafb: Using CRT on CRTC 0
nvidiafb: MTRR set to ON
Console: switching to colour frame buffer device 160x66
nvidiafb: PCI nVidia NV14 framebuffer (64MB @ 0xC0000000)
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
Using specific hotkey driver
lp: driver loaded but no devices found
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.101 (c) Dave Jones
Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
Hangcheck: Using monotonic_clock().
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
ACPI: PCI Interrupt 0000:05:0c.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17
skge 1.6 addr 0xd9008000 irq 17 chip Yukon-Lite rev 9
skge eth0: addr 00:15:f2:20:e6:69
Marvell 88E1101: Registered new driver
Davicom DM9161E: Registered new driver
Davicom DM9131: Registered new driver
Cicada Cis8204: Registered new driver
Cicada Cis8201: Registered new driver
LXT970: Registered new driver
LXT971: Registered new driver
QS6612: Registered new driver
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.57.
ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 23 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:0a.0 to 64
forcedeth: using HIGHDMA
ohci1394: fw-host0: AT dma reset ctx=0, aborting transmission
ieee1394: Current remote IRM is not 1394a-2000 compliant, resetting...
eth1: forcedeth.c: subsystem: 01043:8141 bound to 0000:00:0a.0
Linux Tulip driver version 1.1.14 (May 6, 2006)
ACPI: PCI Interrupt 0000:05:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17
tulip0: MII transceiver #1 config 3100 status 7829 advertising 01e1.
eth2: Lite-On 82c168 PNIC rev 32 at 0000000000018800, 00:A0:CC:21:89:0C, IRQ 17.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0
NFORCE-CK804: chipset revision 242
NFORCE-CK804: not 100% native mode: will probe irqs later
NFORCE-CK804: BIOS didn't set cable bits correctly. Enabling workaround.
NFORCE-CK804: 0000:00:06.0 (rev f2) UDMA133 controller
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
ieee1394: Host added: ID:BUS[0-01:1023] GUID[00023c014100f4bf]
hda: WDC WD2000JB-32EVA0, ATA DISK drive
ieee1394: Host added: ID:BUS[1-00:1023] GUID[0011d80000738f5d]
hdb: _NEC DVD_RW ND-3540A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: WDC WD2000JB-00FUA0, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
HPT374: IDE controller at PCI slot 0000:05:06.0
ACPI: PCI Interrupt 0000:05:06.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 16
HPT374: chipset revision 7
HPT374: DPLL base: 48 MHz, f_CNT: 149, assuming 33 MHz PCI
HPT374: using 66 MHz DPLL clock
HPT374: 100% native mode on irq 16
ide2: BM-DMA at 0x7000-0x7007, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0x7008-0x700f, BIOS settings: hdg:pio, hdh:pio
ACPI: PCI Interrupt 0000:05:06.1[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 16
HPT374: no clock data saved by BIOS
HPT374: DPLL base: 48 MHz, f_CNT: 121, assuming 33 MHz PCI
HPT374: using 66 MHz DPLL clock
ide4: BM-DMA at 0x8400-0x8407, BIOS settings: hdi:DMA, hdj:pio
ide5: BM-DMA at 0x8408-0x840f, BIOS settings: hdk:pio, hdl:pio
Probing IDE interface ide2...
hde: WDC WD2500JB-00FUA0, ATA DISK drive
ide2 at 0x6000-0x6007,0x6402 on irq 16
Probing IDE interface ide3...
Probing IDE interface ide4...
hdi: ST3300831A, ATA DISK drive
ide4 at 0x7400-0x7407,0x7802 on irq 16
Probing IDE interface ide5...
Probing IDE interface ide3...
Probing IDE interface ide5...
hda: max request size: 512KiB
hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, UDMA(100)
hda: cache flushes supported
hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 >
hdc: max request size: 512KiB
hdc: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, UDMA(100)
hdc: cache flushes supported
hdc: hdc1 hdc2 < hdc5 hdc6 hdc7 hdc8 hdc9 >
hde: max request size: 512KiB
hde: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, UDMA(100)
hde: cache flushes supported
hde: hde1
hdi: max request size: 512KiB
hdi: 586072368 sectors (300069 MB) w/8192KiB Cache, CHS=36481/255/63, UDMA(100)
hdi: cache flushes supported
hdi: hdi1
hdb: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
RocketRAID 3xxx SATA Controller driver v1.0 (060426)
libata version 2.00 loaded.
sata_sil 0000:05:0a.0: version 2.0
ACPI: PCI Interrupt 0000:05:0a.0[A] -> Link [APC4] -> GSI 19 (level, low) -> IRQ 19
sata_sil 0000:05:0a.0: Applying R_ERR on DMA activate FIS errata fix
ata1: SATA max UDMA/100 cmd 0xFFFFC200100BA080 ctl 0xFFFFC200100BA08A bmdma 0xFFFFC200100BA000 irq 19
ata2: SATA max UDMA/100 cmd 0xFFFFC200100BA0C0 ctl 0xFFFFC200100BA0CA bmdma 0xFFFFC200100BA008 irq 19
ata3: SATA max UDMA/100 cmd 0xFFFFC200100BA280 ctl 0xFFFFC200100BA28A bmdma 0xFFFFC200100BA200 irq 19
ata4: SATA max UDMA/100 cmd 0xFFFFC200100BA2C0 ctl 0xFFFFC200100BA2CA bmdma 0xFFFFC200100BA208 irq 19
scsi0 : sata_sil
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/100
scsi1 : sata_sil
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata2.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32)
ata2.00: ata2: dev 0 multi count 16
ata2.00: configured for UDMA/100
scsi2 : sata_sil
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata3.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32)
ata3.00: ata3: dev 0 multi count 16
ata3.00: configured for UDMA/100
scsi3 : sata_sil
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata4.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32)
ata4.00: ata4: dev 0 multi count 16
ata4.00: configured for UDMA/100
Vendor: ATA Model: ST3250823AS Rev: 3.03
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
Vendor: ATA Model: ST3250823AS Rev: 3.03
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
sd 1:0:0:0: Attached scsi generic sg1 type 0
Vendor: ATA Model: ST3250823AS Rev: 3.03
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdc: 488397168 512-byte hdwr sectors (250059 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
Losing some ticks... checking if CPU frequency changed.
SCSI device sdc: 488397168 512-byte hdwr sectors (250059 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
sdc: sdc1
sd 2:0:0:0: Attached scsi disk sdc
sd 2:0:0:0: Attached scsi generic sg2 type 0
Vendor: ATA Model: ST3250823AS Rev: 3.02
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdd: 488397168 512-byte hdwr sectors (250059 MB)
sdd: Write Protect is off
sdd: Mode Sense: 00 3a 00 00
SCSI device sdd: drive cache: write back
SCSI device sdd: 488397168 512-byte hdwr sectors (250059 MB)
sdd: Write Protect is off
sdd: Mode Sense: 00 3a 00 00
SCSI device sdd: drive cache: write back
sdd: sdd1
sd 3:0:0:0: Attached scsi disk sdd
sd 3:0:0:0: Attached scsi generic sg3 type 0
sata_nv 0000:00:07.0: version 2.0
ACPI: PCI Interrupt Link [APSI] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 22 (level, low) -> IRQ 22
PCI: Setting latency timer of device 0000:00:07.0 to 64
ata5: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xD800 irq 22
ata6: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xD808 irq 22
scsi4 : sata_nv
ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata5.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 0/32)
ata5.00: ata5: dev 0 multi count 1
ata5.00: configured for UDMA/133
scsi5 : sata_nv
ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata6.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32)
ata6.00: ata6: dev 0 multi count 1
ata6.00: configured for UDMA/133
Vendor: ATA Model: ST3300622AS Rev: 3.AA
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sde: 586072368 512-byte hdwr sectors (300069 MB)
sde: Write Protect is off
sde: Mode Sense: 00 3a 00 00
SCSI device sde: drive cache: write back
SCSI device sde: 586072368 512-byte hdwr sectors (300069 MB)
sde: Write Protect is off
sde: Mode Sense: 00 3a 00 00
SCSI device sde: drive cache: write back
sde: sde1 sde2
sd 4:0:0:0: Attached scsi disk sde
sd 4:0:0:0: Attached scsi generic sg4 type 0
Vendor: ATA Model: ST3250823AS Rev: 3.03
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdf: 488397168 512-byte hdwr sectors (250059 MB)
sdf: Write Protect is off
sdf: Mode Sense: 00 3a 00 00
SCSI device sdf: drive cache: write back
SCSI device sdf: 488397168 512-byte hdwr sectors (250059 MB)
sdf: Write Protect is off
sdf: Mode Sense: 00 3a 00 00
SCSI device sdf: drive cache: write back
sdf: sdf1
sd 5:0:0:0: Attached scsi disk sdf
sd 5:0:0:0: Attached scsi generic sg5 type 0
ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 21
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APSJ] -> GSI 21 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:08.0 to 64
ata7: SATA max UDMA/133 cmd 0x9E0 ctl 0xBE2 bmdma 0xC400 irq 21
ata8: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 21
scsi6 : sata_nv
ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata7.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 0/32)
ata7.00: ata7: dev 0 multi count 1
ata7.00: configured for UDMA/133
scsi7 : sata_nv
ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata8.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32)
ata8.00: ata8: dev 0 multi count 1
ata8.00: configured for UDMA/133
Vendor: ATA Model: ST3300622AS Rev: 3.AA
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdg: 586072368 512-byte hdwr sectors (300069 MB)
sdg: Write Protect is off
sdg: Mode Sense: 00 3a 00 00
SCSI device sdg: drive cache: write back
SCSI device sdg: 586072368 512-byte hdwr sectors (300069 MB)
sdg: Write Protect is off
sdg: Mode Sense: 00 3a 00 00
SCSI device sdg: drive cache: write back
sdg: sdg1 sdg2
sd 6:0:0:0: Attached scsi disk sdg
sd 6:0:0:0: Attached scsi generic sg6 type 0
Vendor: ATA Model: ST3250823AS Rev: 3.03
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdh: 488397168 512-byte hdwr sectors (250059 MB)
sdh: Write Protect is off
sdh: Mode Sense: 00 3a 00 00
SCSI device sdh: drive cache: write back
SCSI device sdh: 488397168 512-byte hdwr sectors (250059 MB)
sdh: Write Protect is off
sdh: Mode Sense: 00 3a 00 00
SCSI device sdh: drive cache: write back
sdh: sdh1
sd 7:0:0:0: Attached scsi disk sdh
sd 7:0:0:0: Attached scsi generic sg7 type 0
pata_hpt37x: BIOS has not set timing clocks.
hpt37x: HPT374: Bus clock 33MHz.
PCI: Unable to reserve I/O region #1:8@7400 for device 0000:05:06.1
pata_hpt37x: probe of 0000:05:06.1 failed with error -16
video1394: Installed video1394 module
ieee1394: raw1394: /dev/raw1394 device initialized
ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)
ieee1394: sbp2: Try serialize_io=0 for better performance
ACPI: PCI Interrupt Link [APCL] enabled at IRQ 20
ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 20 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:02.1 to 64
ehci_hcd 0000:00:02.1: EHCI Host Controller
ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:02.1: debug port 1
PCI: cache line size of 64 is not supported by device 0000:00:02.1
ehci_hcd 0000:00:02.1: irq 20, io mem 0xfeb00000
ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: new device found, idVendor=0000, idProduct=0000
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.18-rc4-mm2 ehci_hcd
usb usb1: SerialNumber: 0000:00:02.1
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 10 ports detected
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI Interrupt Link [APCF] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 23 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:02.0: irq 23, io mem 0xda004000
usb usb2: new device found, idVendor=0000, idProduct=0000
usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.18-rc4-mm2 ohci_hcd
usb usb2: SerialNumber: 0000:00:02.0
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 10 ports detected
usbcore: registered new interface driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
input: PC Speaker as /class/input/input0
input: AT Translated Set 2 keyboard as /class/input/input1
i2c /dev entries driver
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
raid6: int64x1 2066 MB/s
raid6: int64x2 2785 MB/s
raid6: int64x4 2683 MB/s
raid6: int64x8 1800 MB/s
raid6: sse2x1 2269 MB/s
raid6: sse2x2 3285 MB/s
raid6: sse2x4 3824 MB/s
raid6: using algorithm sse2x4 (3824 MB/s)
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
raid5: automatically using best checksumming function: generic_sse
generic_sse: 7064.000 MB/sec
raid5: using function: generic_sse (7064.000 MB/sec)
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
NET: Registered protocol family 8
NET: Registered protocol family 20
powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3700+ processors (version 2.00.00)
powernow-k8: 0 : fid 0x2 (1000 MHz), vid 0x12
powernow-k8: 1 : fid 0xa (1800 MHz), vid 0xa
powernow-k8: 2 : fid 0xc (2000 MHz), vid 0x8
powernow-k8: 3 : fid 0xe (2200 MHz), vid 0x6
ACPI: (supports S0 S1 S3 S4 S5)
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
logips2pp: Detected unknown logitech mouse model 1
input: ImPS/2 Logitech Wheel Mouse as /class/input/input2
md: Autodetecting RAID arrays.
md: autorun ...
md: considering sdh1 ...
md: adding sdh1 ...
md: adding sdg1 ...
md: adding sdf1 ...
md: adding sde1 ...
md: adding sdd1 ...
md: adding sdc1 ...
md: adding sdb1 ...
md: adding sda1 ...
md: hdc9 has different UUID to sdh1
md: hdc8 has different UUID to sdh1
md: hdc7 has different UUID to sdh1
md: hdc6 has different UUID to sdh1
md: hdc5 has different UUID to sdh1
md: hda9 has different UUID to sdh1
md: hda8 has different UUID to sdh1
md: hda7 has different UUID to sdh1
md: hda6 has different UUID to sdh1
md: hda5 has different UUID to sdh1
md: created md0
md: bind<sda1>
md: bind<sdb1>
md: bind<sdc1>
md: bind<sdd1>
md: bind<sde1>
md: bind<sdf1>
md: bind<sdg1>
md: bind<sdh1>
md: running: <sdh1><sdg1><sdf1><sde1><sdd1><sdc1><sdb1><sda1>
raid5: device sdh1 operational as raid disk 1
raid5: device sdg1 operational as raid disk 0
raid5: device sdf1 operational as raid disk 5
raid5: device sde1 operational as raid disk 6
raid5: device sdd1 operational as raid disk 7
raid5: device sdc1 operational as raid disk 3
raid5: device sdb1 operational as raid disk 2
raid5: device sda1 operational as raid disk 4
raid5: allocated 8462kB for md0
raid5: raid level 6 set md0 active with 8 out of 8 devices, algorithm 2
RAID5 conf printout:
--- rd:8 wd:8
disk 0, o:1, dev:sdg1
disk 1, o:1, dev:sdh1
disk 2, o:1, dev:sdb1
disk 3, o:1, dev:sdc1
disk 4, o:1, dev:sda1
disk 5, o:1, dev:sdf1
disk 6, o:1, dev:sde1
disk 7, o:1, dev:sdd1
md0: bitmap initialized from disk: read 15/15 pages, set 1 bits, status: 0
created bitmap (233 pages) for device md0
md: considering hdc9 ...
md: adding hdc9 ...
md: hdc8 has different UUID to hdc9
md: hdc7 has different UUID to hdc9
md: hdc6 has different UUID to hdc9
md: hdc5 has different UUID to hdc9
md: adding hda9 ...
md: hda8 has different UUID to hdc9
md: hda7 has different UUID to hdc9
md: hda6 has different UUID to hdc9
md: hda5 has different UUID to hdc9
md: created md4
md: bind<hda9>
md: bind<hdc9>
md: running: <hdc9><hda9>
raid1: raid set md4 active with 2 out of 2 mirrors
md4: bitmap initialized from disk: read 10/10 pages, set 3 bits, status: 0
created bitmap (156 pages) for device md4
md: considering hdc8 ...
md: adding hdc8 ...
md: hdc7 has different UUID to hdc8
md: hdc6 has different UUID to hdc8
md: hdc5 has different UUID to hdc8
md: adding hda8 ...
md: hda7 has different UUID to hdc8
md: hda6 has different UUID to hdc8
md: hda5 has different UUID to hdc8
md: created md3
md: bind<hda8>
md: bind<hdc8>
md: running: <hdc8><hda8>
raid1: raid set md3 active with 2 out of 2 mirrors
md3: bitmap initialized from disk: read 8/8 pages, set 5 bits, status: 0
created bitmap (123 pages) for device md3
md: considering hdc7 ...
md: adding hdc7 ...
md: hdc6 has different UUID to hdc7
md: hdc5 has different UUID to hdc7
md: adding hda7 ...
md: hda6 has different UUID to hdc7
md: hda5 has different UUID to hdc7
md: created md2
md: bind<hda7>
md: bind<hdc7>
md: running: <hdc7><hda7>
raid1: raid set md2 active with 2 out of 2 mirrors
md2: bitmap initialized from disk: read 8/8 pages, set 87 bits, status: 0
created bitmap (123 pages) for device md2
md: considering hdc6 ...
md: adding hdc6 ...
md: hdc5 has different UUID to hdc6
md: adding hda6 ...
md: hda5 has different UUID to hdc6
md: created md1
md: bind<hda6>
md: bind<hdc6>
md: running: <hdc6><hda6>
raid1: raid set md1 active with 2 out of 2 mirrors
md1: bitmap initialized from disk: read 12/12 pages, set 54 bits, status: 0
created bitmap (184 pages) for device md1
md: considering hdc5 ...
md: adding hdc5 ...
md: adding hda5 ...
md: created md5
md: bind<hda5>
md: bind<hdc5>
md: running: <hdc5><hda5>
raid1: raid set md5 active with 2 out of 2 mirrors
md5: bitmap initialized from disk: read 9/9 pages, set 0 bits, status: 0
created bitmap (129 pages) for device md5
md: ... autorun DONE.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 232k freed
hdb: Speed warnings UDMA 3/4/5 is not functional.
Adding 4200888k swap on /dev/md5. Priority:-1 extents:1 across:4200888k
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on md2, internal journal
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
u: 3538559.870999, 0.0000
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
u: 3538559.870999, 0.0000
i2c_adapter i2c-3: nForce2 SMBus adapter at 0x4c00
i2c_adapter i2c-4: nForce2 SMBus adapter at 0x4c40
it87: Found IT8712F chip at 0x290, revision 7
it87-isa 9191-0290: Detected broken BIOS defaults, disabling PWM interface
ACPI: PCI Interrupt 0000:05:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18
Installing spdif_bug patch: Audigy 2 ZS [2001]
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
u: 3538559.870999, 0.0000
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on md1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on md3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ReiserFS: md4: found reiserfs format "3.6" with standard journal
ReiserFS: md4: using ordered data mode
reiserfs: using flush barriers
ReiserFS: md4: journal params: device md4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: md4: checking transaction log (md4)
ReiserFS: md4: Using r5 hash to sort names
kjournald starting. Commit interval 5 seconds
EXT3 FS on md0, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ReiserFS: hde1: found reiserfs format "3.6" with standard journal
ReiserFS: hde1: using ordered data mode
reiserfs: using flush barriers
ReiserFS: hde1: journal params: device hde1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hde1: checking transaction log (hde1)
ReiserFS: hde1: Using r5 hash to sort names
ReiserFS: sde2: found reiserfs format "3.6" with standard journal
ReiserFS: sde2: using ordered data mode
reiserfs: using flush barriers
ReiserFS: sde2: journal params: device sde2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sde2: checking transaction log (sde2)
ReiserFS: sde2: Using r5 hash to sort names
ReiserFS: sdg2: found reiserfs format "3.6" with standard journal
ReiserFS: sdg2: using ordered data mode
reiserfs: using flush barriers
ReiserFS: sdg2: journal params: device sdg2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sdg2: checking transaction log (sdg2)
ReiserFS: sdg2: Using r5 hash to sort names
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdi1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ip_tables: (C) 2000-2006 Netfilter Core Team
switch: Setting full-duplex based on MII#1 link partner capability of cde1.
ip_conntrack version 2.4 (8192 buckets, 65536 max) - 304 bytes per conntrack
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
u: 3538559.870999, 0.0000
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
u: 3538559.870999, 0.0000
switch: no IPv6 routers present
adsl: no IPv6 routers present
--
"I see!" said the blind man as he picked up his hammer and saw.
Debian (Unstable) GNU/Linux 2.6.18-rc4-mm2 4423 bogomips load 0.39
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 - time moving at 3x speed, bisect finished
2006-08-20 17:51 ` thunder7
@ 2006-08-20 19:24 ` Roman Zippel
2006-08-20 19:42 ` thunder7
0 siblings, 1 reply; 192+ messages in thread
From: Roman Zippel @ 2006-08-20 19:24 UTC (permalink / raw)
To: thunder7
Cc: Helge Hafting, Andi Kleen, john stultz, Andrew Morton,
linux-kernel
Hi,
On Sun, 20 Aug 2006, thunder7@xs4all.nl wrote:
> The interesting part:
>
> 3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
> 3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
> 3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
> 3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
> 3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
> 3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
Thanks for testing, it's a silly sign problem. gcc turned the divide into
an unsigned one.
bye, Roman
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
---
kernel/time/ntp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6-mm/kernel/time/ntp.c
===================================================================
--- linux-2.6-mm.orig/kernel/time/ntp.c
+++ linux-2.6-mm/kernel/time/ntp.c
@@ -41,7 +41,7 @@ static long time_reftime; /* time at la
long time_adjust;
#define CLOCK_TICK_OVERFLOW (LATCH * HZ - CLOCK_TICK_RATE)
-#define CLOCK_TICK_ADJUST (((s64)CLOCK_TICK_OVERFLOW * NSEC_PER_SEC) / CLOCK_TICK_RATE)
+#define CLOCK_TICK_ADJUST (((s64)CLOCK_TICK_OVERFLOW * NSEC_PER_SEC) / (s64)CLOCK_TICK_RATE)
static void ntp_update_frequency(void)
{
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 - time moving at 3x speed, bisect finished
2006-08-20 19:24 ` Roman Zippel
@ 2006-08-20 19:42 ` thunder7
2006-08-20 21:47 ` 2.6.18-rc4-mm1 - time moving at 3x speed, fix confirmed Helge Hafting
0 siblings, 1 reply; 192+ messages in thread
From: thunder7 @ 2006-08-20 19:42 UTC (permalink / raw)
To: Roman Zippel
Cc: thunder7, Helge Hafting, Andi Kleen, john stultz, Andrew Morton,
linux-kernel
From: Roman Zippel <zippel@linux-m68k.org>
Date: Sun, Aug 20, 2006 at 09:24:05PM +0200
>
> Thanks for testing, it's a silly sign problem. gcc turned the divide into
> an unsigned one.
>
> bye, Roman
>
> Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
>
> ---
> kernel/time/ntp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6-mm/kernel/time/ntp.c
> ===================================================================
> --- linux-2.6-mm.orig/kernel/time/ntp.c
> +++ linux-2.6-mm/kernel/time/ntp.c
> @@ -41,7 +41,7 @@ static long time_reftime; /* time at la
> long time_adjust;
>
> #define CLOCK_TICK_OVERFLOW (LATCH * HZ - CLOCK_TICK_RATE)
> -#define CLOCK_TICK_ADJUST (((s64)CLOCK_TICK_OVERFLOW * NSEC_PER_SEC) / CLOCK_TICK_RATE)
> +#define CLOCK_TICK_ADJUST (((s64)CLOCK_TICK_OVERFLOW * NSEC_PER_SEC) / (s64)CLOCK_TICK_RATE)
>
> static void ntp_update_frequency(void)
> {
>
This fixes my problems. Might I suggest this for the hot-fixes/
directory of 2.6.18-rc4-mm2?
Kind regards,
Jurriaan
--
Borg-Cola: Not the choice of The Next Generation.
Debian (Unstable) GNU/Linux 2.6.18-rc4-mm2 4423 bogomips load 0.57
^ permalink raw reply [flat|nested] 192+ messages in thread* Re: 2.6.18-rc4-mm1 - time moving at 3x speed, fix confirmed
2006-08-20 19:42 ` thunder7
@ 2006-08-20 21:47 ` Helge Hafting
0 siblings, 0 replies; 192+ messages in thread
From: Helge Hafting @ 2006-08-20 21:47 UTC (permalink / raw)
To: thunder7; +Cc: Roman Zippel, Andi Kleen, john stultz, Andrew Morton,
linux-kernel
On Sun, Aug 20, 2006 at 09:42:44PM +0200, thunder7@xs4all.nl wrote:
> From: Roman Zippel <zippel@linux-m68k.org>
> Date: Sun, Aug 20, 2006 at 09:24:05PM +0200
> >
> > Thanks for testing, it's a silly sign problem. gcc turned the divide into
> > an unsigned one.
> >
> > bye, Roman
> >
> > Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
I can confirm that 2.6.18-rc4-mm2 with this fix keeps time correctly.
2.6.18-rc4-mm2 without it has the 3x time problem, and
produce the following debug output:
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
u: 3538559.870999, 0.0000
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 1804.120 MHz processor.
.
.
.
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
u: 3538559.870999, 0.0000
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
u: 3538559.870999, 0.0000
3b9aca0000000000,d2ea237f00000000,d2ea237f00000000,35fe7fdef9db22
u: 3538559.870999, 0.0000
Helge Hafting
^ permalink raw reply [flat|nested] 192+ messages in thread
* [mm patch] drm, minor fixes
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (27 preceding siblings ...)
2006-08-17 22:44 ` 2.6.18-rc4-mm1 - time moving at 3x speed! Helge Hafting
@ 2006-08-19 23:16 ` Frederik Deweerdt
2006-08-20 9:37 ` Arjan van de Ven
2006-08-20 14:48 ` [PATCH -mm] agp.h: constify struct agp_bridge_data::version Alexey Dobriyan
29 siblings, 1 reply; 192+ messages in thread
From: Frederik Deweerdt @ 2006-08-19 23:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, airlied
On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
Hi Andrew,
The following patch adds minor fixes to the drm code:
- fix return values that are wrong (return E* instead of return -E*)
- replaces an argument to a sizeof in drm_setversion to match the actual
variable name
- handle drm_set_busid() return value in drm_setversion
Regards,
Frederik
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
diff --git a/drivers/char/drm/i915_dma.c b/drivers/char/drm/i915_dma.c
index d932f80..f9615b5 100644
--- a/drivers/char/drm/i915_dma.c
+++ b/drivers/char/drm/i915_dma.c
@@ -391,7 +391,7 @@ static int i915_emit_box(drm_device_t *
RING_LOCALS;
if (DRM_COPY_FROM_USER_UNCHECKED(&box, &boxes[i], sizeof(box))) {
- return EFAULT;
+ return DRM_ERR(EFAULT);
}
if (box.y2 <= box.y1 || box.x2 <= box.x1 || box.y2 <= 0 || box.x2 <= 0) {
diff --git a/drivers/char/drm/drm_ioctl.c b/drivers/char/drm/drm_ioctl.c
index e158998..a93832f 100644
--- a/drivers/char/drm/drm_ioctl.c
+++ b/drivers/char/drm/drm_ioctl.c
@@ -141,12 +141,12 @@ static int drm_set_busid(drm_device_t *
int len;
if (dev->unique != NULL)
- return EBUSY;
+ return -EBUSY;
dev->unique_len = 40;
dev->unique = drm_alloc(dev->unique_len + 1, DRM_MEM_DRIVER);
if (dev->unique == NULL)
- return ENOMEM;
+ return -ENOMEM;
len = snprintf(dev->unique, dev->unique_len, "pci:%04x:%02x:%02x.%d",
drm_get_pci_domain(dev), dev->pdev->bus->number,
@@ -160,7 +160,7 @@ static int drm_set_busid(drm_device_t *
drm_alloc(strlen(dev->driver->pci_driver.name) + dev->unique_len +
2, DRM_MEM_DRIVER);
if (dev->devname == NULL)
- return ENOMEM;
+ return -ENOMEM;
sprintf(dev->devname, "%s@%s", dev->driver->pci_driver.name,
dev->unique);
@@ -342,20 +342,22 @@ int drm_setversion(DRM_IOCTL_ARGS)
retv.drm_dd_major = dev->driver->major;
retv.drm_dd_minor = dev->driver->minor;
- if (copy_to_user(argp, &retv, sizeof(sv)))
+ if (copy_to_user(argp, &retv, sizeof(retv)))
return -EFAULT;
if (sv.drm_di_major != -1) {
if (sv.drm_di_major != DRM_IF_MAJOR ||
sv.drm_di_minor < 0 || sv.drm_di_minor > DRM_IF_MINOR)
- return EINVAL;
+ return -EINVAL;
if_version = DRM_IF_VERSION(sv.drm_di_major, sv.drm_di_minor);
dev->if_version = max(if_version, dev->if_version);
if (sv.drm_di_minor >= 1) {
/*
* Version 1.1 includes tying of DRM to specific device
*/
- drm_set_busid(dev);
+ int ret = drm_set_busid(dev);
+ if (ret)
+ return ret;
}
}
@@ -363,7 +365,7 @@ int drm_setversion(DRM_IOCTL_ARGS)
if (sv.drm_dd_major != dev->driver->major ||
sv.drm_dd_minor < 0
|| sv.drm_dd_minor > dev->driver->minor)
- return EINVAL;
+ return -EINVAL;
if (dev->driver->set_version)
dev->driver->set_version(dev, &sv);
^ permalink raw reply related [flat|nested] 192+ messages in thread* Re: [mm patch] drm, minor fixes
2006-08-19 23:16 ` [mm patch] drm, minor fixes Frederik Deweerdt
@ 2006-08-20 9:37 ` Arjan van de Ven
2006-08-20 12:17 ` Frederik Deweerdt
0 siblings, 1 reply; 192+ messages in thread
From: Arjan van de Ven @ 2006-08-20 9:37 UTC (permalink / raw)
To: Frederik Deweerdt; +Cc: Andrew Morton, linux-kernel, airlied
On Sat, 2006-08-19 at 23:16 +0000, Frederik Deweerdt wrote:
> On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >
> Hi Andrew,
>
> The following patch adds minor fixes to the drm code:
> - fix return values that are wrong (return E* instead of return -E*)
are you sure the callers of these don't wrap it inside a DRM_ERR()
macro ?
-
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [mm patch] drm, minor fixes
2006-08-20 9:37 ` Arjan van de Ven
@ 2006-08-20 12:17 ` Frederik Deweerdt
2006-08-21 11:22 ` Dave Airlie
0 siblings, 1 reply; 192+ messages in thread
From: Frederik Deweerdt @ 2006-08-20 12:17 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Andrew Morton, linux-kernel, airlied
On Sun, Aug 20, 2006 at 11:37:06AM +0200, Arjan van de Ven wrote:
> On Sat, 2006-08-19 at 23:16 +0000, Frederik Deweerdt wrote:
> > On Sun, Aug 13, 2006 at 01:24:54AM -0700, Andrew Morton wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> > >
> > Hi Andrew,
> >
> > The following patch adds minor fixes to the drm code:
> > - fix return values that are wrong (return E* instead of return -E*)
>
> are you sure the callers of these don't wrap it inside a DRM_ERR()
> macro ?
I changed the values when:
- I've checked what seemed right, getting back to the system call.
drm_ioctl(), through a call to func().
That's the case for:
- the EFAULT value in i915_emit_box
- two EINVAL values in drm_setversion
- the return value wasn't used. That was the case for
drm_set_busid return values, I felt having returned values negative
from the start was more consistent.
Is there a particular change that looked suspicious to you?
Thanks,
Frederik
^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [mm patch] drm, minor fixes
2006-08-20 12:17 ` Frederik Deweerdt
@ 2006-08-21 11:22 ` Dave Airlie
0 siblings, 0 replies; 192+ messages in thread
From: Dave Airlie @ 2006-08-21 11:22 UTC (permalink / raw)
To: Frederik Deweerdt; +Cc: Arjan van de Ven, Andrew Morton, linux-kernel
>>
>> are you sure the callers of these don't wrap it inside a DRM_ERR()
>> macro ?
> I changed the values when:
> - I've checked what seemed right, getting back to the system call.
> drm_ioctl(), through a call to func().
> That's the case for:
> - the EFAULT value in i915_emit_box
> - two EINVAL values in drm_setversion
> - the return value wasn't used. That was the case for
> drm_set_busid return values, I felt having returned values negative
> from the start was more consistent.
>
> Is there a particular change that looked suspicious to you?
These are all actual bugs , however I doubt any of the codepaths are
causing a major problem, a lot of those code paths are for older X
systems or not very likely hit, I'll pull the fixes into the DRM tree
now... the i915 one is a worry I must give out the TG/Intel folks :-)
Thanks,
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
^ permalink raw reply [flat|nested] 192+ messages in thread
* [PATCH -mm] agp.h: constify struct agp_bridge_data::version
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (28 preceding siblings ...)
2006-08-19 23:16 ` [mm patch] drm, minor fixes Frederik Deweerdt
@ 2006-08-20 14:48 ` Alexey Dobriyan
29 siblings, 0 replies; 192+ messages in thread
From: Alexey Dobriyan @ 2006-08-20 14:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Dave Jones
drivers/char/agp/backend.c: In function `agp_backend_initialize':
drivers/char/agp/backend.c:141: warning: assignment discards qualifiers from pointer target type
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/char/agp/agp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/char/agp/agp.h
+++ b/drivers/char/agp/agp.h
@@ -117,7 +117,7 @@ struct agp_bridge_driver {
};
struct agp_bridge_data {
- struct agp_version *version;
+ const struct agp_version *version;
struct agp_bridge_driver *driver;
struct vm_operations_struct *vm_ops;
void *previous_size;
^ permalink raw reply [flat|nested] 192+ messages in thread
