Linux 2.6.21-rc5

Quoted 2 lines · Linus Torvalds

There's various fixes here, ranging from some architecture updates (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.

here's a new v2.6.20 -> v2.6.21 forcedeth.c regression:

in the last week or so i've been seeing sporadic under-load forcedeth.c crashes (see the full oops further below):

eth1: too many iterations (6) in nv_nic_irq.

 Unable to handle kernel NULL pointer dereference at 0000000000000088 RIP: 
 [<ffffffff80404587>] nv_tx_done+0xf4/0x1cf

this is line 1906 of drivers/net/forcedeth.c:

    np->stats.tx_bytes += np->get_tx_ctx->skb->len;

struct sk_buff's len field is at offset 88, so np->get_tx_ctx->skb is NULL. That is an 'impossible' scenario for tx descriptors here - the tx ring descriptors are always set up with a valid skb (and a valid dma address), and their completion is serialized via np->lock.

these crashes are almost instant on the .21-rc5-rt kernel, but extremely sporadic on the upstream kernel and needed very high networking loads to trigger. Today i found a good way to trigger it almost instantly on upstream kernels too: apply the debug patch attached further below and do:

echo 100 > /proc/sys/kernel/panic

that will inject 100 artificial 'too many iterations' failures and provokes a TX timeout - which TX timeout will crash. (i've used a dual-core Athlon64 system in this test)

my first quick guess was to extend np->priv locking to the whole of nv_start_xmit/nv_start_xmit_optimized - while that appeared to make the crash a bit less likely, it did not prevent it. So there must be some other, more fundamental problem be left as well. At first glance the SMP locking looks OK, so maybe the ring indices are messed up somehow and we got into a 'ring head bites the tail' scenario?

i can provide more info if needed.

Ingo

-------------->
eth1: too many iterations (6) in nv_nic_irq.

Unable to handle kernel NULL pointer dereference at 0000000000000088 RIP: 
 [<ffffffff80404587>] nv_tx_done+0xf4/0x1cf
PGD 34d03067 PUD 34d02067 PMD 0 
Oops: 0000 [1] PREEMPT SMP 
CPU 1 
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.21-rc5 #8
RIP: 0010:[<ffffffff80404587>]  [<ffffffff80404587>] nv_tx_done+0xf4/0x1cf
RSP: 0018:ffff81003ff6be40  EFLAGS: 00010206
RAX: 0000000000000000 RBX: ffff810002e26700 RCX: 0000000000000001
RDX: 0000000000000042 RSI: 000000003ef00cbe RDI: ffff81003fbeb070
RBP: ffff81003ff6be60 R08: ffff810002e26a00 R09: 0000000000000003
R10: ffff81003ff4e100 R11: ffff810001e283f8 R12: 000000003ef00cbe
R13: ffff810002e26000 R14: ffff810002e28fc0 R15: 0000000000000000
FS:  00002b6cb57f1db0(0000) GS:ffff81003ff4ad40(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000088 CR3: 0000000034c87000 CR4: 00000000000006e0
Process swapper (pid: 0, threadinfo ffff81003ff64000, task ffff81003ff4e100)
Stack:  ffff810002e26700 0000000000000032 ffffc2000001a000 ffff810002e26000
 ffff81003ff6bea0 ffffffff80406dae ffff810002e26700 ffff810002e26700
 ffff810002e26000 00000000000000ff ffffc2000001a000 ffffffff80749080
Call Trace:
 <IRQ>  [<ffffffff80406dae>] nv_nic_irq+0x76/0x261
 [<ffffffff8040961e>] nv_do_nic_poll+0x200/0x284
 [<ffffffff8040941e>] nv_do_nic_poll+0x0/0x284
 [<ffffffff80241995>] run_timer_softirq+0x167/0x1dd
 [<ffffffff8023de45>] __do_softirq+0x5b/0xc9
 [<ffffffff8020af0c>] call_softirq+0x1c/0x28
 [<ffffffff8020c2b4>] do_softirq+0x31/0x84
 [<ffffffff8023db16>] irq_exit+0x3f/0x50
 [<ffffffff802190c2>] smp_apic_timer_interrupt+0x49/0x5b
 [<ffffffff802087fb>] default_idle+0x0/0x44
 [<ffffffff8020a9b6>] apic_timer_interrupt+0x66/0x70
 <EOI>  [<ffffffff8020882a>] default_idle+0x2f/0x44
 [<ffffffff8020804c>] enter_idle+0x22/0x24
 [<ffffffff802088d0>] cpu_idle+0x91/0xd4
 [<ffffffff80218572>] start_secondary+0x2e3/0x2f5

---
 drivers/net/forcedeth.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

drivers/net/forcedeth.c +20 -0

Index: linux/drivers/net/forcedeth.c
===================================================================
@@ -2908,6 +2908,10 @@ static irqreturn_t nv_nic_irq(int foo, v
 			spin_unlock(&np->lock);
 			break;
 		}
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock(&np->lock);
 			/* disable interrupts on the nic */

@@ -3026,6 +3030,10 @@ static irqreturn_t nv_nic_irq_optimized(
 			break;
 		}
 
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock(&np->lock);
 			/* disable interrupts on the nic */

@@ -3076,6 +3084,10 @@ static irqreturn_t nv_nic_irq_tx(int foo
 			dprintk(KERN_DEBUG "%s: received irq with events 0x%x. Probably TX fail.\n",
 						dev->name, events);
 		}
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock_irqsave(&np->lock, flags);
 			/* disable interrupts on the nic */

@@ -3191,6 +3203,10 @@ static irqreturn_t nv_nic_irq_rx(int foo
 			}
 		}
 
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock_irqsave(&np->lock, flags);
 			/* disable interrupts on the nic */

@@ -3264,6 +3280,10 @@ static irqreturn_t nv_nic_irq_other(int 
 			printk(KERN_DEBUG "%s: received irq with unknown events 0x%x. Please report\n",
 						dev->name, events);
 		}
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock_irqsave(&np->lock, flags);
 			/* disable interrupts on the nic */

Ingo Molnar

2007-03-26 09:07 UTC #5 lore raw

Quoted 6 lines · Ingo Molnar

my first quick guess was to extend np->priv locking to the whole of nv_start_xmit/nv_start_xmit_optimized - while that appeared to make the crash a bit less likely, it did not prevent it. So there must be some other, more fundamental problem be left as well. At first glance the SMP locking looks OK, so maybe the ring indices are messed up somehow and we got into a 'ring head bites the tail' scenario?

to be specific, the patch below is what i tried - but it didnt completely fix the crash.

Ingo

---
 drivers/net/forcedeth.c |   15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

drivers/net/forcedeth.c +7 -8

Index: linux/drivers/net/forcedeth.c
===================================================================
@@ -1650,9 +1650,10 @@ static int nv_start_xmit(struct sk_buff 
 			   ((skb_shinfo(skb)->frags[i].size & (NV_TX2_TSO_MAX_SIZE-1)) ? 1 : 0);
 	}
 
+	spin_lock_irq(&np->lock);
+
 	empty_slots = nv_get_empty_tx_slots(np);
 	if (unlikely(empty_slots <= entries)) {
-		spin_lock_irq(&np->lock);
 		netif_stop_queue(dev);
 		np->tx_stop = 1;
 		spin_unlock_irq(&np->lock);

@@ -1718,8 +1719,6 @@ static int nv_start_xmit(struct sk_buff 
 		tx_flags_extra = skb->ip_summed == CHECKSUM_PARTIAL ?
 			 NV_TX2_CHECKSUM_L3 | NV_TX2_CHECKSUM_L4 : 0;
 
-	spin_lock_irq(&np->lock);
-
 	/* set tx flags */
 	start_tx->flaglen |= cpu_to_le32(tx_flags | tx_flags_extra);
 	np->put_tx.orig = put_tx;

@@ -1766,9 +1765,10 @@ static int nv_start_xmit_optimized(struc
 			   ((skb_shinfo(skb)->frags[i].size & (NV_TX2_TSO_MAX_SIZE-1)) ? 1 : 0);
 	}
 
+	spin_lock_irq(&np->lock);
+
 	empty_slots = nv_get_empty_tx_slots(np);
 	if (unlikely(empty_slots <= entries)) {
-		spin_lock_irq(&np->lock);
 		netif_stop_queue(dev);
 		np->tx_stop = 1;
 		spin_unlock_irq(&np->lock);

@@ -1846,8 +1846,6 @@ static int nv_start_xmit_optimized(struc
 			start_tx->txvlan = 0;
 	}
 
-	spin_lock_irq(&np->lock);
-
 	/* set tx flags */
 	start_tx->flaglen |= cpu_to_le32(tx_flags | tx_flags_extra);
 	np->put_tx.ex = put_tx;

@@ -3484,6 +3482,7 @@ static void nv_do_nic_poll(unsigned long
 	struct net_device *dev = (struct net_device *) data;
 	struct fe_priv *np = netdev_priv(dev);
 	u8 __iomem *base = get_hwbase(dev);
+	unsigned long flags;
 	u32 mask = 0;
 
 	/*

@@ -3519,7 +3518,7 @@ static void nv_do_nic_poll(unsigned long
 		printk(KERN_INFO "forcedeth: MAC in recoverable error state\n");
 		if (netif_running(dev)) {
 			netif_tx_lock_bh(dev);
-			spin_lock(&np->lock);
+			spin_lock_irqsave(&np->lock, flags);
 			/* stop engines */
 			nv_stop_rx(dev);
 			nv_stop_tx(dev);

@@ -3545,7 +3544,7 @@ static void nv_do_nic_poll(unsigned long
 			/* restart rx engine */
 			nv_start_rx(dev);
 			nv_start_tx(dev);
-			spin_unlock(&np->lock);
+			spin_unlock_irqrestore(&np->lock, flags);
 			netif_tx_unlock_bh(dev);
 		}
 	}

Ingo Molnar

2007-03-26 08:59 UTC #6 lore raw

PATCH 1/1 forcedeth: work around NULL skb dereference crash

Quoted 10 lines · Ingo Molnar

Quoted 7 lines
my first quick guess was to extend np->priv locking to the whole of nv_start_xmit/nv_start_xmit_optimized - while that appeared to make the crash a bit less likely, it did not prevent it. So there must be some other, more fundamental problem be left as well. At first glance the SMP locking looks OK, so maybe the ring indices are messed up somehow and we got into a 'ring head bites the tail' scenario?
to be specific, the patch below is what i tried - but it didnt completely fix the crash.

the patch below works the crash around. It does not seem to be a 'tx ring head bits the tail' scenario:

get_tx: 55, put_tx: 57
get_tx: 80, put_tx: 86
get_tx: 88, put_tx: 97
get_tx: 97, put_tx: 109
get_tx: 97, put_tx: 109
get_tx: 111, put_tx: 117
get_tx: 117, put_tx: 125
get_tx: 127, put_tx: 137
get_tx: 137, put_tx: 147
get_tx: 147, put_tx: 149

Ingo

------------>
From: Ingo Molnar <[email protected]>
Subject: [patch] forcedeth: work around NULL skb dereference crash

work around a NULL skb dereference crash that occurs during high load.

Signed-off-by Ingo Molnar <[email protected]>

---
 drivers/net/forcedeth.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

drivers/net/forcedeth.c +10 -0

Index: linux/drivers/net/forcedeth.c
===================================================================
@@ -1902,6 +1902,11 @@ static void nv_tx_done(struct net_device
 						np->stats.tx_carrier_errors++;
 					np->stats.tx_errors++;
 				} else {
+					if (!np->get_tx_ctx->skb) {
+						printk("get_tx: %ld, put_tx: %ld\n", np->get_tx_ctx - np->first_tx_ctx, np->put_tx_ctx - np->first_tx_ctx);
+						WARN_ON(1);
+						break;
+					}
 					np->stats.tx_packets++;
 					np->stats.tx_bytes += np->get_tx_ctx->skb->len;
 				}

@@ -1917,6 +1922,11 @@ static void nv_tx_done(struct net_device
 						np->stats.tx_carrier_errors++;
 					np->stats.tx_errors++;
 				} else {
+					if (!np->get_tx_ctx->skb) {
+						printk("get_tx: %ld, put_tx: %ld\n", np->get_tx_ctx - np->first_tx_ctx, np->put_tx_ctx - np->first_tx_ctx);
+						WARN_ON(1);
+						break;
+					}
 					np->stats.tx_packets++;
 					np->stats.tx_bytes += np->get_tx_ctx->skb->len;
 				}

Ingo Molnar

2007-04-02 11:56 UTC #7 lore raw

PATCH 1/1 forcedeth: improve NAPI logic

From: Ingo Molnar <[email protected]>
Subject: [patch] forcedeth.c: improve NAPI handler

another forcedeth.c thing: i noticed that its NAPI handler does not do tx-ring processing. The patch below implements this - tested on DESC_VER_2 hardware, with CONFIG_FORCEDETH_NAPI=y.

Signed-off-by Ingo Molnar <[email protected]>

drivers/net/forcedeth.c +8 -0

Index: linux/drivers/net/forcedeth.c
===================================================================
@@ -3118,9 +3118,17 @@ static int nv_napi_poll(struct net_devic
 	int retcode;
 
 	if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
+		spin_lock_irqsave(&np->lock, flags);
+		nv_tx_done(dev);
+		spin_unlock_irqrestore(&np->lock, flags);
+
 		pkts = nv_rx_process(dev, limit);
 		retcode = nv_alloc_rx(dev);
 	} else {
+		spin_lock_irqsave(&np->lock, flags);
+		nv_tx_done_optimized(dev, np->tx_ring_size);
+		spin_unlock_irqrestore(&np->lock, flags);
+
 		pkts = nv_rx_process_optimized(dev, limit);
 		retcode = nv_alloc_rx_optimized(dev);
 	}

Ayaz Abdulla

2007-03-26 19:31 UTC #8 lore raw

This issue might be resolved with the patch provided in the following bug report: http://bugzilla.kernel.org/show_bug.cgi?id=8058

Please try out the patch in the bug report without your patch and see if the issue reproduces.

Ayaz

Quoted 132 lines · Ingo Molnar

Quoted 1 line · Linus Torvalds

There's various fixes here, ranging from some architecture updates (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.

here's a new v2.6.20 -> v2.6.21 forcedeth.c regression:

in the last week or so i've been seeing sporadic under-load forcedeth.c crashes (see the full oops further below):

eth1: too many iterations (6) in nv_nic_irq.

 Unable to handle kernel NULL pointer dereference at 0000000000000088 RIP: 
 [<ffffffff80404587>] nv_tx_done+0xf4/0x1cf

this is line 1906 of drivers/net/forcedeth.c:

    np->stats.tx_bytes += np->get_tx_ctx->skb->len;

echo 100 > /proc/sys/kernel/panic

that will inject 100 artificial 'too many iterations' failures and provokes a TX timeout - which TX timeout will crash. (i've used a dual-core Athlon64 system in this test)

i can provide more info if needed.

Ingo

-------------->
eth1: too many iterations (6) in nv_nic_irq.

Unable to handle kernel NULL pointer dereference at 0000000000000088 RIP: 
 [<ffffffff80404587>] nv_tx_done+0xf4/0x1cf
PGD 34d03067 PUD 34d02067 PMD 0 Oops: 0000 [1] PREEMPT SMP CPU 1 Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.21-rc5 #8
RIP: 0010:[<ffffffff80404587>]  [<ffffffff80404587>] nv_tx_done+0xf4/0x1cf
RSP: 0018:ffff81003ff6be40  EFLAGS: 00010206
RAX: 0000000000000000 RBX: ffff810002e26700 RCX: 0000000000000001
RDX: 0000000000000042 RSI: 000000003ef00cbe RDI: ffff81003fbeb070
RBP: ffff81003ff6be60 R08: ffff810002e26a00 R09: 0000000000000003
R10: ffff81003ff4e100 R11: ffff810001e283f8 R12: 000000003ef00cbe
R13: ffff810002e26000 R14: ffff810002e28fc0 R15: 0000000000000000
FS:  00002b6cb57f1db0(0000) GS:ffff81003ff4ad40(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000088 CR3: 0000000034c87000 CR4: 00000000000006e0
Process swapper (pid: 0, threadinfo ffff81003ff64000, task ffff81003ff4e100)
Stack:  ffff810002e26700 0000000000000032 ffffc2000001a000 ffff810002e26000
 ffff81003ff6bea0 ffffffff80406dae ffff810002e26700 ffff810002e26700
 ffff810002e26000 00000000000000ff ffffc2000001a000 ffffffff80749080
Call Trace:
 <IRQ>  [<ffffffff80406dae>] nv_nic_irq+0x76/0x261
 [<ffffffff8040961e>] nv_do_nic_poll+0x200/0x284
 [<ffffffff8040941e>] nv_do_nic_poll+0x0/0x284
 [<ffffffff80241995>] run_timer_softirq+0x167/0x1dd
 [<ffffffff8023de45>] __do_softirq+0x5b/0xc9
 [<ffffffff8020af0c>] call_softirq+0x1c/0x28
 [<ffffffff8020c2b4>] do_softirq+0x31/0x84
 [<ffffffff8023db16>] irq_exit+0x3f/0x50
 [<ffffffff802190c2>] smp_apic_timer_interrupt+0x49/0x5b
 [<ffffffff802087fb>] default_idle+0x0/0x44
 [<ffffffff8020a9b6>] apic_timer_interrupt+0x66/0x70
 <EOI>  [<ffffffff8020882a>] default_idle+0x2f/0x44
 [<ffffffff8020804c>] enter_idle+0x22/0x24
 [<ffffffff802088d0>] cpu_idle+0x91/0xd4
 [<ffffffff80218572>] start_secondary+0x2e3/0x2f5

---
 drivers/net/forcedeth.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

Index: linux/drivers/net/forcedeth.c
===================================================================

drivers/net/forcedeth.c +20 -0

@@ -2908,6 +2908,10 @@ static irqreturn_t nv_nic_irq(int foo, v
 			spin_unlock(&np->lock);
 			break;
 		}
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock(&np->lock);
 			/* disable interrupts on the nic */

@@ -3026,6 +3030,10 @@ static irqreturn_t nv_nic_irq_optimized(
 			break;
 		}
 
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock(&np->lock);
 			/* disable interrupts on the nic */

@@ -3076,6 +3084,10 @@ static irqreturn_t nv_nic_irq_tx(int foo
 			dprintk(KERN_DEBUG "%s: received irq with events 0x%x. Probably TX fail.\n",
 						dev->name, events);
 		}
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock_irqsave(&np->lock, flags);
 			/* disable interrupts on the nic */

@@ -3191,6 +3203,10 @@ static irqreturn_t nv_nic_irq_rx(int foo
 			}
 		}
 
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock_irqsave(&np->lock, flags);
 			/* disable interrupts on the nic */

@@ -3264,6 +3280,10 @@ static irqreturn_t nv_nic_irq_other(int 
 			printk(KERN_DEBUG "%s: received irq with unknown events 0x%x. Please report\n",
 						dev->name, events);
 		}
+		if (panic_timeout > 0) {
+			panic_timeout--;
+			i = max_interrupt_work+1;
+		}
 		if (unlikely(i > max_interrupt_work)) {
 			spin_lock_irqsave(&np->lock, flags);
 			/* disable interrupts on the nic */

Ingo Molnar

2007-03-26 09:05 UTC #9 lore raw

2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!

trying to debug the forcedeth crash triggered another, new v2.6.20 -> v2.6.21 regression:

maxcpus=1 on a dual-core system crashes the x86_64 SMP kernel in lock_policy_rwsem_write() - see the crash log below. Config attached.

i suspect it could be related to this recent commit:

commit 5a01f2e8f3ac134e24144d74bb48a60236f7024d
Author: Venkatesh Pallipadi <[email protected]>
Date: Mon Feb 5 16:12:44 2007 -0800

[CPUFREQ] Rewrite lock in cpufreq to eliminate cpufreq/hotplug related issue

Ingo

---------------->
Linux version 2.6.21-rc5 (mingo@dione) (gcc version 4.0.2) #14 SMP PREEMPT Mon Mar 26 10:51:51 CEST 2007
Command line: root=/dev/hda5 earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 console=tty 3 profile=0 debug initcall_debug noapic apic=debug maxcpus=1 selinux=0 [email protected]/eth0,[email protected]/00:16:76:ab:6e:84 nmi_watchdog=2 ignore_loglevel debug_dir BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 262128) 1 entries of 3200 used
end_pfn_map = 1048576
DMI 2.3 present.
ACPI: RSDP 000F76F0, 0014 (r0 Nvidia)
ACPI: RSDT 3FFF3040, 0034 (r1 Nvidia AWRDACPI 42302E31 AWRD 0)
ACPI: FACP 3FFF30C0, 0074 (r1 Nvidia AWRDACPI 42302E31 AWRD 0)
ACPI: DSDT 3FFF3180, 6264 (r1 NVIDIA AWRDACPI 1000 MSFT 100000E)
ACPI: FACS 3FFF0000, 0040
ACPI: SRAT 3FFF9500, 00A0 (r1 AMD HAMMER 1 AMD 1)
ACPI: MCFG 3FFF9600, 003C (r1 Nvidia AWRDACPI 42302E31 AWRD 0)
ACPI: APIC 3FFF9440, 007C (r1 Nvidia AWRDACPI 42302E31 AWRD 0)
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: Node 0 PXM 0 0-a0000
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
SRAT: Node 0 PXM 0 0-40000000
Entering add_active_range(0, 0, 159) 1 entries of 3200 used
Entering add_active_range(0, 256, 262128) 1 entries of 3200 used
NUMA: Using 63 for the hash shift.
Bootmem setup node 0 0000000000000000-000000003fff0000
Zone PFN ranges:
DMA 0 -> 4096
DMA32 4096 -> 1048576
Normal 1048576 -> 1048576
early_node_map[2] active PFN ranges

    0:        0 ->      159
    0:      256 ->   262128

On node 0 totalpages: 262031
DMA zone: 56 pages used for memmap
DMA zone: 2414 pages reserved
DMA zone: 1529 pages, LIFO batch:0
DMA32 zone: 3527 pages used for memmap
DMA32 zone: 254505 pages, LIFO batch:31
Normal zone: 0 pages used for memmap
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: Skipping IOAPIC probe due to 'noapic' option.
Using ACPI for processor (LAPIC) configuration information
Intel MultiProcessor Specification v1.4
MPTABLE: OEM ID: OEM00000 MPTABLE: Product ID: PROD00000000 MPTABLE: APIC at: 0xFEE00000
I/O APIC #2 at 0xFEC00000.
Setting APIC routing to physical flat
Processors: 2
mapped APIC to ffffffffff5fd000 ( fee00000)
mapped IOAPIC to ffffffffff5fc000 (00000000fec00000)
Nosave address range: 000000000009f000 - 00000000000a0000
Nosave address range: 00000000000a0000 - 00000000000f0000
Nosave address range: 00000000000f0000 - 0000000000100000
Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 68480 bytes of per cpu data
Built 1 zonelists. Total pages: 256034
Kernel command line: root=/dev/hda5 earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 console=tty 3 profile=0 debug initcall_debug noapic apic=debug maxcpus=1 selinux=0 [email protected]/eth0,[email protected]/00:16:76:ab:6e:84 nmi_watchdog=2 ignore_loglevel debug_dir kernel profiling enabled (shift: 0)
debug: ignoring loglevel setting.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
time.c: Detected 2160.233 MHz processor.
disabling early console
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Checking aperture...
CPU 0: aperture @ 230000000 size 32 MB
Aperture too small (32 MB)
No AGP bridge found
Memory: 1009328k/1048512k available (3246k kernel code, 38796k reserved, 2130k data, 372k init)
Calibrating delay using timer specific routine.. 4321.70 BogoMIPS (lpj=2160852)
Security Framework v1.0.0 initialized
SELinux: Disabled at boot.
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0/0 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
ACPI: setting ELCR to 0200 (from 0828)
enabled ExtINT on CPU#0
Using local APIC timer interrupts.
result 13501473
Detected 13.501 MHz APIC timer.
Brought up 1 CPUs
testing NMI watchdog ... OK.
Calling initcall 0xffffffff80a30c7c: init_cpufreq_transition_notifier_list+0x0/0x14()
Calling initcall 0xffffffff80a1879f: cpufreq_tsc+0x0/0x60()
Calling initcall 0xffffffff80216f24: init_smp_flush+0x0/0x51()
Calling initcall 0xffffffff80a20bf1: init_elf32_binfmt+0x0/0x12()
Calling initcall 0xffffffff80a21c6f: sysctl_init+0x0/0x16()
Calling initcall 0xffffffff80a22299: helper_init+0x0/0x2b()
Calling initcall 0xffffffff80a22605: pm_init+0x0/0x29()
Calling initcall 0xffffffff80a2262e: pm_disk_init+0x0/0x19()
Calling initcall 0xffffffff80a22ae7: ksysfs_init+0x0/0x29()
Calling initcall 0xffffffff80a25457: filelock_init+0x0/0x31()
Calling initcall 0xffffffff80a25ec8: init_misc_binfmt+0x0/0x3c()
Calling initcall 0xffffffff80a25f04: init_script_binfmt+0x0/0x12()
Calling initcall 0xffffffff80a25f16: init_elf_binfmt+0x0/0x12()
Calling initcall 0xffffffff80a26918: debugfs_init+0x0/0x47()
Calling initcall 0xffffffff80a26e9d: securityfs_init+0x0/0x47()
Calling initcall 0xffffffff80a27e39: random32_init+0x0/0x57()
Calling initcall 0xffffffff80a30c90: cpufreq_core_init+0x0/0x76()
Calling initcall 0xffffffff80a32b06: sock_init+0x0/0x5f()
Calling initcall 0xffffffff80a3325d: netpoll_init+0x0/0x3b()
Calling initcall 0xffffffff80a334e5: netlink_proto_init+0x0/0x16a()
NET: Registered protocol family 16
Calling initcall 0xffffffff80a27d5d: kobject_uevent_init+0x0/0x3a()
Calling initcall 0xffffffff80a28142: pcibus_class_init+0x0/0x12()
Calling initcall 0xffffffff80a286ff: pci_driver_init+0x0/0x12()
Calling initcall 0xffffffff80a290d8: backlight_class_init+0x0/0x12()
Calling initcall 0xffffffff80a2ad14: dock_init+0x0/0x51()
No dock devices found.
Calling initcall 0xffffffff80a2c4c8: tty_class_init+0x0/0x2a()
Calling initcall 0xffffffff80a2cc16: vtconsole_class_init+0x0/0xba()
Calling initcall 0xffffffff80a2e000: register_node_type+0x0/0x12()
Calling initcall 0xffffffff80a18c45: mtrr_if_init+0x0/0x74()
Calling initcall 0xffffffff80a19bd2: ffh_cstate_init+0x0/0x31()
initcall at 0xffffffff80a19bd2: ffh_cstate_init+0x0/0x31(): returned with error code -1
Calling initcall 0xffffffff80a28c2a: acpi_pci_init+0x0/0x2e()
ACPI: bus type pci registered
Calling initcall 0xffffffff80a2a669: init_acpi_device_notify+0x0/0x4b()
Calling initcall 0xffffffff80a3191f: pci_access_init+0x0/0x43()
PCI: Using MMCONFIG at e0000000 - efffffff
PCI: No mmconfig possible on device 00:18
Calling initcall 0xffffffff80a18ab6: mtrr_init_finialize+0x0/0x34()
Calling initcall 0xffffffff80a1e915: topology_init+0x0/0x8d()
Calling initcall 0xffffffff80a2207f: param_sysfs_init+0x0/0x186()
Calling initcall 0xffffffff8025ce7d: pm_sysrq_init+0x0/0x1b()
Calling initcall 0xffffffff80a25b1b: init_bio+0x0/0x101()
Calling initcall 0xffffffff80a27b33: genhd_device_init+0x0/0x56()
Calling initcall 0xffffffff80a28c58: fbmem_init+0x0/0x95()
Calling initcall 0xffffffff80a2a46c: acpi_init+0x0/0x1fd()
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: Using PIC for interrupt routing
Calling initcall 0xffffffff80a2a6b4: acpi_scan_init+0x0/0x10e()
Calling initcall 0xffffffff80a2a972: acpi_ec_init+0x0/0x61()
Calling initcall 0xffffffff80a2adc3: acpi_pci_root_init+0x0/0x28()
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
0000:00:06.0: cannot adjust BAR0 (not I/O)
0000:00:06.0: cannot adjust BAR1 (not I/O)
0000:00:06.0: cannot adjust BAR2 (not I/O)
0000:00:06.0: cannot adjust BAR3 (not I/O)
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]
Calling initcall 0xffffffff80a2aed8: acpi_pci_link_init+0x0/0x48()
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
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) *0, disabled.
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) *0, disabled.
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) *0, disabled.
ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
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) *0, disabled.
ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
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<7>spurious 8259A interrupt: IRQ7.
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.
Calling initcall 0xffffffff80a2afc1: acpi_power_init+0x0/0x77()
Calling initcall 0xffffffff80a2b1b5: acpi_system_init+0x0/0xc6()
Calling initcall 0xffffffff80a2b27b: acpi_event_init+0x0/0x3f()
Calling initcall 0xffffffff80a2be66: acpi_cm_sbs_init+0x0/0x8()
Calling initcall 0xffffffff80a2be6e: pnp_init+0x0/0x20()
Linux Plug and Play Support v0.97 (c) Adam Belay
Calling initcall 0xffffffff80a2bff7: pnpacpi_init+0x0/0x6a()
pnp: PnP ACPI init
pnp: PnP ACPI: found 16 devices
Calling initcall 0xffffffff80a2c938: misc_init+0x0/0x86()
Calling initcall 0xffffffff803d7702: cn_init+0x0/0xce()
Calling initcall 0xffffffff80a2efa8: init_scsi+0x0/0x90()
SCSI subsystem initialized
Calling initcall 0xffffffff80a2f475: ata_init+0x0/0x7b()
libata version 2.20 loaded.
Calling initcall 0xffffffff80a2fa3e: init_pcmcia_cs+0x0/0x38()
Calling initcall 0xffffffff80a30182: usb_init+0x0/0x118()
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Calling initcall 0xffffffff80a30574: serio_init+0x0/0x8b()
Calling initcall 0xffffffff80a3092f: input_init+0x0/0x123()
Calling initcall 0xffffffff80a30d38: leds_init+0x0/0x2a()
Calling initcall 0xffffffff80a313de: dma_bus_init+0x0/0x2c()
Calling initcall 0xffffffff80a31962: pci_acpi_init+0x0/0xab()
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
Calling initcall 0xffffffff80a31a0d: pci_legacy_init+0x0/0x124()
Calling initcall 0xffffffff80a31ecd: pcibios_irq_init+0x0/0x494()
Calling initcall 0xffffffff80a32361: pcibios_init+0x0/0x77()
Calling initcall 0xffffffff80a32bc0: proto_init+0x0/0x34()
Calling initcall 0xffffffff80a32d13: net_dev_init+0x0/0x253()
Calling initcall 0xffffffff80a33222: wireless_nlevent_init+0x0/0x3b()
Calling initcall 0xffffffff80a33298: fib_rules_init+0x0/0x12()
Calling initcall 0xffffffff80a333ad: pktsched_init+0x0/0xa6()
Calling initcall 0xffffffff80a33465: tc_filter_init+0x0/0x40()
Calling initcall 0xffffffff80a334a5: tc_action_init+0x0/0x40()
Calling initcall 0xffffffff80a3364f: genl_init+0x0/0xad()
Calling initcall 0xffffffff80a34885: cipso_v4_init+0x0/0x6b()
Calling initcall 0xffffffff80a34c88: netlbl_init+0x0/0x75()

NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default

Calling initcall 0xffffffff80a184b7: pci_iommu_init+0x0/0x17()
Calling initcall 0xffffffff80a2237e: clocksource_done_booting+0x0/0x12()
Calling initcall 0xffffffff80a253e1<6>Time: tsc clocksource has been installed.
: init_pipe_fs+0x0/0x49()
Calling initcall 0xffffffff80a2bf72: pnp_system_init+0x0/0x12()
pnp: 00:01: ioport range 0x4000-0x407f has been reserved
pnp: 00:01: ioport range 0x4080-0x40ff has been reserved
pnp: 00:01: ioport range 0x4400-0x447f has been reserved
pnp: 00:01: ioport range 0x4480-0x44ff has been reserved
pnp: 00:01: ioport range 0x4800-0x487f has been reserved
pnp: 00:01: ioport range 0x4880-0x48ff has been reserved
pnp: 00:0e: iomem range 0xe0000000-0xefffffff has been reserved
pnp: 00:0f: iomem range 0xf0000-0xf3fff could not be reserved
pnp: 00:0f: iomem range 0xf4000-0xf7fff could not be reserved
pnp: 00:0f: iomem range 0xf8000-0xfbfff could not be reserved
pnp: 00:0f: iomem range 0xfc000-0xfffff could not be reserved
Calling initcall 0xffffffff80a2c3d0: chr_dev_init+0x0/0x88()
Calling initcall 0xffffffff80a2df90: firmware_class_init+0x0/0x70()
Calling initcall 0xffffffff80a2fa76: init_pcmcia_bus+0x0/0x7b()
Calling initcall 0xffffffff80a30d06: cpufreq_gov_performance_init+0x0/0x12()
Calling initcall 0xffffffff80a30d18: cpufreq_gov_userspace_init+0x0/0x20()
Calling initcall 0xffffffff80a31330: init_acpi_pm_clocksource+0x0/0xae()
Calling initcall 0xffffffff80a3140a<6>Time: acpi_pm clocksource has been installed.
: pcibios_assign_resources+0x0/0x8b()
PCI: Bridge: 0000:00:09.0
IO window: c000-cfff
MEM window: da000000-da0fffff
PREFETCH window: disabled.
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: b000-bfff
MEM window: d8000000-d9ffffff
PREFETCH window: d0000000-d7ffffff
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
Calling initcall 0xffffffff80a32a33: fill_mp_bus_to_cpumask+0x0/0xd3()
Calling initcall 0xffffffff80a34194: inet_init+0x0/0x42d()
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
TCP established hash table entries: 131072 (order: 9, 3145728 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
Calling initcall 0xffffffff80a15f52: populate_rootfs+0x0/0xec()
Calling initcall 0xffffffff8020d187: time_init_device+0x0/0x22()
Calling initcall 0xffffffff80a16c9e: init_timer_sysfs+0x0/0x22()
Calling initcall 0xffffffff80a16c7c: i8259A_init_sysfs+0x0/0x22()
Calling initcall 0xffffffff80a17102: vsyscall_init+0x0/0xa8()
Calling initcall 0xffffffff80a173bd: sbf_init+0x0/0xda()
Calling initcall 0xffffffff80a18210: i8237A_init_sysfs+0x0/0x22()
Calling initcall 0xffffffff80a18959: mce_init_device+0x0/0x78()
Calling initcall 0xffffffff80a18870: periodic_mcheck_init+0x0/0x27()
Calling initcall 0xffffffff80a189d1: thermal_throttle_init_device+0x0/0x9b()
Calling initcall 0xffffffff80a18a6c: threshold_init_device+0x0/0x4a()
Calling initcall 0xffffffff80a19c03: msr_init+0x0/0x100()
Calling initcall 0xffffffff80a19d03: cpuid_init+0x0/0x100()
Calling initcall 0xffffffff80a1a353: init_lapic_sysfs+0x0/0x37()
Calling initcall 0xffffffff80a1aebb: ioapic_init_sysfs+0x0/0xb3()
Calling initcall 0xffffffff80a1e717: audit_classes_init+0x0/0x8d()
Calling initcall 0xffffffff8022362d: cache_sysfs_init+0x0/0x5b()
Calling initcall 0xffffffff80a1e9a2: add_pcspkr+0x0/0x43()
Calling initcall 0xffffffff80a1ec6d: x8664_sysctl_init+0x0/0x14()
Calling initcall 0xffffffff80a208c7: aes_init+0x0/0x318()
Calling initcall 0xffffffff80a20bdf: init+0x0/0x12()
Calling initcall 0xffffffff80a20c03: ia32_binfmt_init+0x0/0x14()
Calling initcall 0xffffffff80a20c17: init_syscall32+0x0/0xba()
Calling initcall 0xffffffff80a21782: create_proc_profile+0x0/0x34f()
Calling initcall 0xffffffff80a21b59: ioresources_init+0x0/0x42()
Calling initcall 0xffffffff80a21c85: timekeeping_init_device+0x0/0x22()
Calling initcall 0xffffffff80a21dc1: uid_cache_init+0x0/0x8c()
Calling initcall 0xffffffff80a22205: init_posix_timers+0x0/0x94()
Calling initcall 0xffffffff80a222c4: init_posix_cpu_timers+0x0/0x69()
Calling initcall 0xffffffff80a2235b: latency_init+0x0/0x23()
Calling initcall 0xffffffff80a22390: init_clocksource_sysfs+0x0/0x50()
Calling initcall 0xffffffff80a22474: init_jiffies_clocksource+0x0/0x12()
Calling initcall 0xffffffff80a22486: init_timer_list_procfs+0x0/0x2f()
Calling initcall 0xffffffff80a22503: init_tstats_procfs+0x0/0x2f()
Calling initcall 0xffffffff80a22532: init+0x0/0x86()
Calling initcall 0xffffffff80253e98: init_rttest+0x0/0x14e()
Initializing RT-Tester: OK
Calling initcall 0xffffffff80a225b8: proc_dma_init+0x0/0x25()
Calling initcall 0xffffffff802552ad: percpu_modinit+0x0/0x76()
Calling initcall 0xffffffff80a225dd: kallsyms_init+0x0/0x28()
Calling initcall 0xffffffff80a226bb: snapshot_device_init+0x0/0x12()
Calling initcall 0xffffffff80a226cd: crash_notes_memory_init+0x0/0x3d()
Calling initcall 0xffffffff80a228ef: audit_init+0x0/0x121()
audit: initializing netlink socket (disabled)
audit(1174901870.063:1): initialized
Calling initcall 0xffffffff80a22a95: init_kprobes+0x0/0x52()
Calling initcall 0xffffffff80a22bd9: relay_init+0x0/0x14()
Calling initcall 0xffffffff80a22bed: utsname_sysctl_init+0x0/0x14()
Calling initcall 0xffffffff80a24017: init_per_zone_pages_min+0x0/0x41()
Calling initcall 0xffffffff80a24af6: pdflush_init+0x0/0x1a()
Calling initcall 0xffffffff80a24b3c: kswapd_init+0x0/0x72()
Calling initcall 0xffffffff80a24bae: setup_vmstat+0x0/0x19()
Calling initcall 0xffffffff80a24c0b: procswaps_init+0x0/0x25()
Calling initcall 0xffffffff80a24c63: hugetlb_init+0x0/0x69()
Total HugeTLB memory allocated, 0
Calling initcall 0xffffffff80a24dc1: init_tmpfs+0x0/0xc6()
Calling initcall 0xffffffff80a24f1a: cpucache_init+0x0/0x38()
Calling initcall 0xffffffff80a2542a: fasync_init+0x0/0x2d()
Calling initcall 0xffffffff80a25a58: aio_setup+0x0/0x69()
Calling initcall 0xffffffff80a25c96: inotify_setup+0x0/0x12()
Calling initcall 0xffffffff80a25ca8: inotify_user_setup+0x0/0xbc()
Calling initcall 0xffffffff80a25d64: eventpoll_init+0x0/0xcf()
Calling initcall 0xffffffff80a25e33: init_sys32_ioctl+0x0/0x95()
Calling initcall 0xffffffff80a25f28: init_mbcache+0x0/0x20()
Calling initcall 0xffffffff80a25f48: dquot_init+0x0/0xea()
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Calling initcall 0xffffffff80a26032: init_v2_quota_format+0x0/0x12()
Calling initcall 0xffffffff80a26044: dnotify_init+0x0/0x2d()
Calling initcall 0xffffffff80a264c9: init_devpts_fs+0x0/0x3a()
Calling initcall 0xffffffff80a26503: init_ext3_fs+0x0/0x6b()
Calling initcall 0xffffffff80a2661e: journal_init+0x0/0xbc()
Calling initcall 0xffffffff80a266da: init_ext2_fs+0x0/0x6a()
Calling initcall 0xffffffff80a26778: init_ramfs_fs+0x0/0x12()
Calling initcall 0xffffffff80a2679c: init_hugetlbfs_fs+0x0/0x7f()
Calling initcall 0xffffffff80a2681b: init_iso9660_fs+0x0/0x6e()
Calling initcall 0xffffffff80a268f4: init_nls_cp437+0x0/0x12()
Calling initcall 0xffffffff80a26906: init_nls_ascii+0x0/0x12()
Calling initcall 0xffffffff80a2695f: ipc_init+0x0/0x17()
Calling initcall 0xffffffff80a26bbf: ipc_sysctl_init+0x0/0x14()
Calling initcall 0xffffffff80a26bd3: init_mqueue_fs+0x0/0xcf()
Calling initcall 0xffffffff80a26dff: key_proc_init+0x0/0x55()
Calling initcall 0xffffffff80a26fb8: selinux_nf_ip_init+0x0/0x56()
Calling initcall 0xffffffff80a2717e: init_sel_fs+0x0/0x5d()
Calling initcall 0xffffffff80a271db: selnl_init+0x0/0x42()
Calling initcall 0xffffffff80a2721d: sel_netif_init+0x0/0x67()
Calling initcall 0xffffffff80a27284: aurule_init+0x0/0x37()
Calling initcall 0xffffffff80a272bb: crypto_algapi_init+0x0/0xd()
Calling initcall 0xffffffff80a272eb: cryptomgr_init+0x0/0x12()
Calling initcall 0xffffffff80a272fd: hmac_module_init+0x0/0x12()
Calling initcall 0xffffffff80a2730f: crypto_xcbc_module_init+0x0/0x12()
Calling initcall 0xffffffff80a27321: init+0x0/0x5a()
Calling initcall 0xffffffff80a2737b: init+0x0/0x12()
Calling initcall 0xffffffff80a2738d: init+0x0/0x12()
Calling initcall 0xffffffff80a2739f: init+0x0/0x12()
Calling initcall 0xffffffff80a273b1: init+0x0/0x12()
Calling initcall 0xffffffff80a273c3: init+0x0/0x3c()
Calling initcall 0xffffffff80a273ff: init+0x0/0x61()
Calling initcall 0xffffffff80a27460: init+0x0/0x61()
Calling initcall 0xffffffff80a274c1: crypto_ecb_module_init+0x0/0x12()
Calling initcall 0xffffffff80a274d3: crypto_cbc_module_init+0x0/0x12()
Calling initcall 0xffffffff80a274e5: crypto_module_init+0x0/0x12()
Calling initcall 0xffffffff80a274f7: init+0x0/0x3c()
Calling initcall 0xffffffff80a27533: init+0x0/0x12()
Calling initcall 0xffffffff80a27545: init+0x0/0x12()
Calling initcall 0xffffffff80a27557: init+0x0/0x3c()
Calling initcall 0xffffffff80a27593: aes_init+0x0/0x31a()
Calling initcall 0xffffffff80a278ad: init+0x0/0x12()
Calling initcall 0xffffffff80a278bf: init+0x0/0x12()
Calling initcall 0xffffffff80a278d1: arc4_init+0x0/0x12()
Calling initcall 0xffffffff80a278e3: init+0x0/0x61()
Calling initcall 0xffffffff80a27944: init+0x0/0x12()
Calling initcall 0xffffffff80a27956: init+0x0/0x12()
Calling initcall 0xffffffff80a27968: init+0x0/0x12()
Calling initcall 0xffffffff80a2797a: michael_mic_init+0x0/0x12()
Calling initcall 0xffffffff80a2798c: init+0x0/0x12()
Calling initcall 0xffffffff80a27b89: noop_init+0x0/0x12()
io scheduler noop registered
Calling initcall 0xffffffff80a27b9b: as_init+0x0/0x12()
io scheduler anticipatory registered
Calling initcall 0xffffffff80a27bad: deadline_init+0x0/0x12()
io scheduler deadline registered
Calling initcall 0xffffffff80a27bbf: cfq_init+0x0/0xa6()
io scheduler cfq registered (default)
Calling initcall 0xffffffff80a27c65: blk_trace_init+0x0/0xf8()
Calling initcall 0xffffffff80369039: pci_init+0x0/0x34()
PCI: Found disabled HT MSI Mapping on 0000:00:0b.0
PCI: Found enabled HT MSI Mapping on 0000:00:00.0
PCI: Linking AER extended capability on 0000:00:0b.0
PCI: Found disabled HT MSI Mapping on 0000:00:0c.0
PCI: Found enabled HT MSI Mapping on 0000:00:00.0
PCI: Linking AER extended capability on 0000:00:0c.0
PCI: Found disabled HT MSI Mapping on 0000:00:0d.0
PCI: Found enabled HT MSI Mapping on 0000:00:00.0
PCI: Linking AER extended capability on 0000:00:0d.0
PCI: Found disabled HT MSI Mapping on 0000:00:0e.0
PCI: Found enabled HT MSI Mapping on 0000:00:00.0
PCI: Linking AER extended capability on 0000:00:0e.0
Calling initcall 0xffffffff80a28711: pci_sysfs_init+0x0/0x3b()
Calling initcall 0xffffffff80a2874c: pci_proc_init+0x0/0x6f()
Calling initcall 0xffffffff80a287bb: pcie_portdrv_init+0x0/0x49()
PCI: Setting latency timer of device 0000:00:0b.0 to 64
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
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
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
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0e.0:pcie00]
Allocate Port Service[0000:00:0e.0:pcie03]
Calling initcall 0xffffffff80a28804: aer_service_init+0x0/0x12()
Calling initcall 0xffffffff80a28816: pci_hotplug_init+0x0/0x59()
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Calling initcall 0xffffffff80a2886f: acpiphp_init+0x0/0x51()
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
Calling initcall 0xffffffff80a28a6b: ibm_acpiphp_init+0x0/0x167()
acpiphp_ibm: ibm_find_acpi_device: Failed to get device information<3>acpiphp_ibm: ibm_find_acpi_device: Failed to get device information<3>acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed Calling initcall 0xffffffff80a28fc3: fb_console_init+0x0/0x115()
Calling initcall 0xffffffff80a2979c: vesafb_init+0x0/0x235()
Calling initcall 0xffffffff80a29d87: acpi_reserve_resources+0x0/0xf1()
Calling initcall 0xffffffff80a2a7c2: acpi_ac_init+0x0/0x45()
Calling initcall 0xffffffff80a2a807: acpi_battery_init+0x0/0x45()
Calling initcall 0xffffffff80a2a84c: acpi_button_init+0x0/0x5e()
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input1
ACPI: Power Button (CM) [PWRB]
Calling initcall 0xffffffff80a2acb6: acpi_fan_init+0x0/0x5e()
ACPI: Fan [FAN] (on)
Calling initcall 0xffffffff80a2ad65: acpi_video_init+0x0/0x5e()
Calling initcall 0xffffffff80a2aea0: irqrouter_init_sysfs+0x0/0x38()
Calling initcall 0xffffffff80a2b038: acpi_processor_init+0x0/0xdf()
Calling initcall 0xffffffff80a2b117: acpi_container_init+0x0/0x40()
Calling initcall 0xffffffff80a2b157: acpi_thermal_init+0x0/0x5e()
ACPI: Thermal Zone [THRM] (40 C)
Calling initcall 0xffffffff80a2b3ce: asus_acpi_init+0x0/0xe7()
Calling initcall 0xffffffff80a2b5c8: acpi_ibm_init+0x0/0x71b()
ibm_acpi: ec object not found
Calling initcall 0xffffffff80a2bce3: toshiba_acpi_init+0x0/0x183()
Calling initcall 0xffffffff80a2c467: rand_initialize+0x0/0x2c()
Calling initcall 0xffffffff80a2c4f2: tty_init+0x0/0x1c5()
Calling initcall 0xffffffff80a2c6b7: pty_init+0x0/0x281()
Calling initcall 0xffffffff80a2cf41: rtc_init+0x0/0x185()
Real Time Clock Driver v1.12ac
Calling initcall 0xffffffff80a2d0c6: nvram_init+0x0/0x89()
Non-volatile memory driver v1.2
Calling initcall 0xffffffff80a2d14f: agp_init+0x0/0x26()
Linux agpgart interface v0.102 (c) Dave Jones
Calling initcall 0xffffffff80a2d27f: agp_intel_init+0x0/0x29()
Calling initcall 0xffffffff80a2d2a8: agp_sis_init+0x0/0x29()
Calling initcall 0xffffffff80a2d2d1: agp_via_init+0x0/0x29()
Calling initcall 0xffffffff80a2d2fa: cn_proc_init+0x0/0x3a()
Calling initcall 0xffffffff80a2d7cf: serial8250_init+0x0/0x12c()
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
�serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Calling initcall 0xffffffff80a2d8fb: serial8250_pnp_init+0x0/0x12()
00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Calling initcall 0xffffffff80a2d90d: serial8250_pci_init+0x0/0x1b()
Calling initcall 0xffffffff803e6d69: topology_sysfs_init+0x0/0x4a()
Calling initcall 0xffffffff80a2e012: rd_init+0x0/0x1ab()
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
Calling initcall 0xffffffff80a2e1fc: e1000_init_module+0x0/0x84()
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
Calling initcall 0xffffffff80a2e280: e100_init_module+0x0/0x62()
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
Calling initcall 0xffffffff80a2e2e2: sky2_init_module+0x0/0x1b()
Calling initcall 0xffffffff80a2e34f: net_olddevs_init+0x0/0xa9()
Calling initcall 0xffffffff80a2e3f8: loopback_init+0x0/0x12()
Calling initcall 0xffffffff80a2e40a: init_nic+0x0/0x30()
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.60.
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LMAC] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:0a.0 to 64
forcedeth: using HIGHDMA
eth0: forcedeth.c: subsystem: 01043:8141 bound to 0000:00:0a.0
Calling initcall 0xffffffff80a2e43a: aec62xx_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e455: ali15x3_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e470: amd74xx_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e48b: atiixp_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e4a6: cmd64x_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e4c1: hpt34x_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e4dc: hpt366_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e4f7: it821x_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e512: pdc202xx_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e52d: pdc202new_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e548: piix_ide_init+0x0/0xc9()
Calling initcall 0xffffffff80a2e611: svwks_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e62c: siimage_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e647: sis5513_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e662: via_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2e6a0: generic_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a2edc0: ide_init+0x0/0x8f()
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: 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...
hda: MAXTOR 6L040J2, ATA DISK drive
hdb: ST380011A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
Calling initcall 0xffffffff80a2ef64: ide_generic_init+0x0/0x12()
Probing IDE interface ide1...
Calling initcall 0xffffffff80a2ef76: idedisk_init+0x0/0x12()
hda: max request size: 128KiB
hda: 78177792 sectors (40027 MB) w/1818KiB Cache, CHS=65535/16/63, UDMA(133)
hda: cache flushes supported
hda: hda1 hda2 hda3 hda4 < hda5 >
hdb: max request size: 512KiB
hdb: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hdb: cache flushes supported
hdb: hdb1 hdb2 hdb3 < hdb5 >
Calling initcall 0xffffffff80a2ef88: idefloppy_init+0x0/0x20()
ide-floppy driver 0.99.newide
Calling initcall 0xffffffff80a2f216: init_sd+0x0/0xf5()
Calling initcall 0xffffffff80a2f30b: init_sg+0x0/0x15d()
Calling initcall 0xffffffff80a2f4f0: ahci_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f50b: k2_sata_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f526: piix_init+0x0/0x2c()
Calling initcall 0xffffffff80a2f552: pdc_ata_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f56d: qs_ata_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f588: sil_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f5a3: sil24_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f5be: svia_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f5d9: vsc_sata_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f5f4: sis_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f60f: pdc_sata_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f62a: nv_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f645: uli_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f660: mv_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f67b: adma_ata_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f696: ali_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f6b1: amd_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f6cc: artop_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f6e7: atiixp_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f702: cmd64x_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f71d: cs5520_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f738: cs5530_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f753: cy82c693_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f76e: efar_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f789: hpt36x_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f7a4: hpt37x_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f7bf: hpt3x2n_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f7da: hpt3x3_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f7f5: it821x_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f810: jmicron_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f82b: netcell_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f846: ns87410_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f861: opti_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f87c: optidma_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f897: marvell_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f8b2: mpiix_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f8cd: oldpiix_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f8e8: pcmcia_init+0x0/0x12()
Calling initcall 0xffffffff80a2f8fa: pdc2027x_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f915: pdc202xx_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f930: radisys_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f94b: rz1000_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f966: sc1200_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f981: serverworks_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f99c: sil680_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f9b7: via_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f9d2: sl82c105_init+0x0/0x1b()
Calling initcall 0xffffffff80a2f9ed: sis_init+0x0/0x1b()
Calling initcall 0xffffffff80a2fa08: triflex_init+0x0/0x1b()
Calling initcall 0xffffffff80a2fa23: ata_generic_init+0x0/0x1b()
Calling initcall 0xffffffff80a2fb6d: nonstatic_sysfs_init+0x0/0x12()
Calling initcall 0xffffffff80a2fb7f: yenta_socket_init+0x0/0x1b()
Calling initcall 0xffffffff80a2fb9a: kvm_init+0x0/0x177()
Calling initcall 0xffffffff80a2fd2a: vmx_init+0x0/0x14()
kvm: no hardware support
initcall at 0xffffffff80a2fd2a: vmx_init+0x0/0x14(): returned with error code -95 Calling initcall 0xffffffff80a2fe01: svm_init+0x0/0x14()
has_svm: svm not available
kvm: no hardware support
initcall at 0xffffffff80a2fe01: svm_init+0x0/0x14(): returned with error code -95 Calling initcall 0xffffffff80a303d9: mon_init+0x0/0xa7()
Calling initcall 0xffffffff80a30544: usb_usual_init+0x0/0x30()
usbcore: registered new interface driver libusual
Calling initcall 0xffffffff80a305ff: i8042_init+0x0/0x2ff()
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
Calling initcall 0xffffffff80a308fe: serport_init+0x0/0x31()
Calling initcall 0xffffffff80a30a52: mousedev_init+0x0/0xc2()
mice: PS/2 mouse device common for all mice
Calling initcall 0xffffffff80a30b14: evdev_init+0x0/0x12()
Calling initcall 0xffffffff80a30b26: atkbd_init+0x0/0x1b()
Calling initcall 0xffffffff80a30b41: psmouse_init+0x0/0x65()
input: AT Translated Set 2 keyboard as /class/input/input2
Calling initcall 0xffffffff80a30ba6: md_init+0x0/0xd6()
Calling initcall 0xffffffff80a30d62: ledtrig_ide_init+0x0/0x1b()
Calling initcall 0xffffffff80a33050: flow_cache_init+0x0/0x19e()
Calling initcall 0xffffffff80a332aa: llc_init+0x0/0x5b()
Calling initcall 0xffffffff80a33305: snap_init+0x0/0x31()
Calling initcall 0xffffffff80a33336: rif_init+0x0/0x77()
Calling initcall 0xffffffff80a33453: blackhole_module_init+0x0/0x12()
Calling initcall 0xffffffff80a3485a: init_syncookies+0x0/0x19()
Calling initcall 0xffffffff805069c2: ipv4_netfilter_init+0x0/0x12()
Calling initcall 0xffffffff80a34873: bictcp_register+0x0/0x12()
TCP bic registered
Calling initcall 0xffffffff80a34ae0: xfrm_user_init+0x0/0x4d()
Initializing XFRM netlink socket
Calling initcall 0xffffffff80a34b2d: af_unix_init+0x0/0x6d()
NET: Registered protocol family 1
Calling initcall 0xffffffff80a34b9a: packet_init+0x0/0x5a()
NET: Registered protocol family 17
Calling initcall 0xffffffff80a34bf4: ipsec_pfkey_init+0x0/0x94()
NET: Registered protocol family 15
Calling initcall 0xffffffff80a1a408: ioapic_insert_resources+0x0/0x4f()
Calling initcall 0xffffffff80a1abf1: init_lapic_nmi_sysfs+0x0/0x38()
Calling initcall 0xffffffff8021e003: powernowk8_init+0x0/0x88()
powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ processors (version 2.00.00)
powernow-k8: BIOS error - no PSB or ACPI _PSS objects

------------[ cut here ]------------
kernel BUG at drivers/cpufreq/cpufreq.c:82!
invalid opcode: 0000 [1] PREEMPT SMP 
CPU 0 
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.21-rc5 #14
RIP: 0010:[<ffffffff804a0edd>]  [<ffffffff804a0edd>] lock_policy_rwsem_write+0x2b/0x7f
RSP: 0000:ffff81003ff31de0  EFLAGS: 00010246
RAX: 00000000ffffffff RBX: ffffffff80aa46a8 RCX: 0000000000000000
RDX: ffffffff80741080 RSI: 0000000000000202 RDI: 0000000000000001
RBP: ffff81003ff31e00 R08: ffff81003ff30000 R09: ffff810002dfdab0
R10: ffff810002dfdab0 R11: ffff810002dfdab0 R12: 0000000000000001
R13: ffffffff806cc2c0 R14: ffffffff80a37920 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffffff80741000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000f06f53 CR3: 0000000000201000 CR4: 00000000000006e0
Process swapper (pid: 1, threadinfo ffff81003ff30000, task ffff81003ff2a790)
Stack:  ffffffff806cc2c0 ffffffff80aa46a8 ffffffff80aa46a8 ffffffff806cc2c0
 ffff81003ff31e20 ffffffff804a1538 ffff810002dfdab0 ffffffff806f6a40
 ffff81003ff31e50 ffffffff803dffdf 00000000ffffffed 00000000ffffffed
Call Trace:
 [<ffffffff804a1538>] cpufreq_remove_dev+0x11/0x26
 [<ffffffff803dffdf>] sysdev_driver_unregister+0x52/0x98
 [<ffffffff804a0d3b>] cpufreq_register_driver+0x12d/0x191
 [<ffffffff8021e082>] powernowk8_init+0x7f/0x88
 [<ffffffff80a1099e>] init+0x1a8/0x2a9
 [<ffffffff8023294e>] schedule_tail+0x36/0x9a
 [<ffffffff8020ab98>] child_rip+0xa/0x12
 [<ffffffff80a107f6>] init+0x0/0x2a9
 [<ffffffff8020ab8e>] child_rip+0x0/0x12


Code: 0f 0b eb fe 4c 63 e8 48 c7 c3 a0 c1 a6 80 4a 8b 04 ed c0 7a 
RIP  [<ffffffff804a0edd>] lock_policy_rwsem_write+0x2b/0x7f
 RSP <ffff81003ff31de0>
Kernel panic - not syncing: Attempted to kill init!

Venki Pallipadi

2007-03-26 18:10 UTC #10 lore raw

Re: 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!

Quoted 48 lines · Ingo Molnar

trying to debug the forcedeth crash triggered another, new v2.6.20 -> v2.6.21 regression:
maxcpus=1 on a dual-core system crashes the x86_64 SMP kernel in lock_policy_rwsem_write() - see the crash log below. Config attached.
i suspect it could be related to this recent commit:
commit 5a01f2e8f3ac134e24144d74bb48a60236f7024d
Author: Venkatesh Pallipadi <[email protected]>
Date: Mon Feb 5 16:12:44 2007 -0800
[CPUFREQ] Rewrite lock in cpufreq to eliminate cpufreq/hotplug
related issue
Ingo
Calling initcall 0xffffffff8021e003: powernowk8_init+0x0/0x88()
powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ processors (version 2.00.00)
powernow-k8: BIOS error - no PSB or ACPI _PSS objects
------------[ cut here ]------------
kernel BUG at drivers/cpufreq/cpufreq.c:82!
invalid opcode: 0000 [1] PREEMPT SMP
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.21-rc5 #14
RIP: 0010:[<ffffffff804a0edd>]  [<ffffffff804a0edd>] lock_policy_rwsem_write+0x2b/0x7f
RSP: 0000:ffff81003ff31de0  EFLAGS: 00010246
RAX: 00000000ffffffff RBX: ffffffff80aa46a8 RCX: 0000000000000000
RDX: ffffffff80741080 RSI: 0000000000000202 RDI: 0000000000000001
RBP: ffff81003ff31e00 R08: ffff81003ff30000 R09: ffff810002dfdab0
R10: ffff810002dfdab0 R11: ffff810002dfdab0 R12: 0000000000000001
R13: ffffffff806cc2c0 R14: ffffffff80a37920 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffffff80741000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000f06f53 CR3: 0000000000201000 CR4: 00000000000006e0
Process swapper (pid: 1, threadinfo ffff81003ff30000, task ffff81003ff2a790)
Stack:  ffffffff806cc2c0 ffffffff80aa46a8 ffffffff80aa46a8 ffffffff806cc2c0
 ffff81003ff31e20 ffffffff804a1538 ffff810002dfdab0 ffffffff806f6a40
 ffff81003ff31e50 ffffffff803dffdf 00000000ffffffed 00000000ffffffed
Call Trace:
 [<ffffffff804a1538>] cpufreq_remove_dev+0x11/0x26
 [<ffffffff803dffdf>] sysdev_driver_unregister+0x52/0x98
 [<ffffffff804a0d3b>] cpufreq_register_driver+0x12d/0x191
 [<ffffffff8021e082>] powernowk8_init+0x7f/0x88
 [<ffffffff80a1099e>] init+0x1a8/0x2a9
 [<ffffffff8023294e>] schedule_tail+0x36/0x9a
 [<ffffffff8020ab98>] child_rip+0xa/0x12

Quoted 9 lines

 [<ffffffff80a107f6>] init+0x0/0x2a9
 [<ffffffff8020ab8e>] child_rip+0x0/0x12


Code: 0f 0b eb fe 4c 63 e8 48 c7 c3 a0 c1 a6 80 4a 8b 04 ed c0 7a
RIP  [<ffffffff804a0edd>] lock_policy_rwsem_write+0x2b/0x7f
 RSP <ffff81003ff31de0>
Kernel panic - not syncing: Attempted to kill init!

Looks like some error with cpufreq add_dev and remove_dev got exposed by the above patch.

The problem here is:

cpufreq_register_driver() calls sysdev_driver_register()
which in turn calls add() for the CPU already present and ignores the return value from that add(). (drivers/base/sys.c:183).
Not if that add had failed, cpufreq will not know and later a remove() is being called on the same device, which causes the BUG() condition here.

However, I am not sure at this point why this gets triggered only on numcpus=1 case and not on normal boot case.

Will dig into this a bit more and hopefully have a patch to fix this soon.

Thanks,
~Venki

Venki Pallipadi

2007-03-26 19:04 UTC #11 lore raw

Re: 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!

Quoted 41 lines · Venki Pallipadi

Quoted 41 lines

Calling initcall 0xffffffff8021e003: powernowk8_init+0x0/0x88()
powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ processors (version 2.00.00)
powernow-k8: BIOS error - no PSB or ACPI _PSS objects

------------[ cut here ]------------
kernel BUG at drivers/cpufreq/cpufreq.c:82!
invalid opcode: 0000 [1] PREEMPT SMP
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.21-rc5 #14
RIP: 0010:[<ffffffff804a0edd>]  [<ffffffff804a0edd>]  
lock_policy_rwsem_write+0x2b/0x7f
RSP: 0000:ffff81003ff31de0  EFLAGS: 00010246
RAX: 00000000ffffffff RBX: ffffffff80aa46a8 RCX: 0000000000000000
RDX: ffffffff80741080 RSI: 0000000000000202 RDI: 0000000000000001
RBP: ffff81003ff31e00 R08: ffff81003ff30000 R09: ffff810002dfdab0
R10: ffff810002dfdab0 R11: ffff810002dfdab0 R12: 0000000000000001
R13: ffffffff806cc2c0 R14: ffffffff80a37920 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffffff80741000(0000) knlGS:

0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000f06f53 CR3: 0000000000201000 CR4: 00000000000006e0 Process swapper (pid: 1, threadinfo ffff81003ff30000, task ffff81003ff2a790)

Stack:  ffffffff806cc2c0 ffffffff80aa46a8 ffffffff80aa46a8  
ffffffff806cc2c0
ffff81003ff31e20 ffffffff804a1538 ffff810002dfdab0 ffffffff806f6a40
ffff81003ff31e50 ffffffff803dffdf 00000000ffffffed 00000000ffffffed
Call Trace:
[<ffffffff804a1538>] cpufreq_remove_dev+0x11/0x26
[<ffffffff803dffdf>] sysdev_driver_unregister+0x52/0x98
[<ffffffff804a0d3b>] cpufreq_register_driver+0x12d/0x191
[<ffffffff8021e082>] powernowk8_init+0x7f/0x88
[<ffffffff80a1099e>] init+0x1a8/0x2a9
[<ffffffff8023294e>] schedule_tail+0x36/0x9a
[<ffffffff8020ab98>] child_rip+0xa/0x12
[<ffffffff80a107f6>] init+0x0/0x2a9
[<ffffffff8020ab8e>] child_rip+0x0/0x12

Quoted 6 lines

Quoted 5 lines

Code: 0f 0b eb fe 4c 63 e8 48 c7 c3 a0 c1 a6 80 4a 8b 04 ed c0 7a
RIP  [<ffffffff804a0edd>] lock_policy_rwsem_write+0x2b/0x7f
RSP <ffff81003ff31de0>
Kernel panic - not syncing: Attempted to kill init!

Ingo,

Does the patch below help?

Thanks,
Venki

Patch to resolve maxcpus=1 trigerring BUG() as reported by Ingo here

lkml subject:
"2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!"

This check added to remove_dev is symmetric to one in add_dev and handles callbacks for offline cpus cleanly.

Signed-off-by Venkatesh Pallipadi <[email protected]>

drivers/cpufreq/cpufreq.c +4 -0

Index: new/drivers/cpufreq/cpufreq.c
===================================================================
@@ -1015,6 +1015,10 @@
 {
 	unsigned int cpu = sys_dev->id;
 	int retval;
+
+	if (cpu_is_offline(cpu))
+		return 0;
+
 	if (unlikely(lock_policy_rwsem_write(cpu)))
 		BUG();

Ingo Molnar

Acked-by

2007-03-27 07:12 UTC #12 lore raw

Re: 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!

Quoted 5 lines · Venki Pallipadi

Ingo,
Does the patch below help?
Patch to resolve maxcpus=1 trigerring BUG() as reported by Ingo here

yes, it solves it, thanks!

Acked-by Ingo Molnar <[email protected]>

Ingo

Thomas Gleixner

2007-03-26 09:21 UTC #13 lore raw

PATCH 1/1 clockevents: remove bad designed sysfs support for now

In reply to Thomas Gleixner

The current sysfs support of clockevents does not obey the "only one value per file" rule.

The real fix is not 2.6.21 material. Therefor remove the sysfs support for now.

Signed-off-by Thomas Gleixner <[email protected]>

kernel/time/clockevents.c +0 ~~-69~~

index 67932ea..76212b2 100644
@@ -274,72 +274,3 @@ void clockevents_notify(unsigned long reason, void *arg)
 }
 EXPORT_SYMBOL_GPL(clockevents_notify);
 
-#ifdef CONFIG_SYSFS
-
-/**
- * clockevents_show_registered - sysfs interface for listing clockevents
- * @dev:	unused
- * @buf:	char buffer to be filled with clock events list
- *
- * Provides sysfs interface for listing registered clock event devices
- */
-static ssize_t clockevents_show_registered(struct sys_device *dev, char *buf)
-{
-	struct list_head *tmp;
-	char *p = buf;
-	int cpu;
-
-	spin_lock(&clockevents_lock);
-
-	list_for_each(tmp, &clockevent_devices) {
-		struct clock_event_device *ce;
-
-		ce = list_entry(tmp, struct clock_event_device, list);
-		p += sprintf(p, "%-20s F:%04x M:%d", ce->name,
-			     ce->features, ce->mode);
-		p += sprintf(p, " C:");
-		if (!cpus_equal(ce->cpumask, cpu_possible_map)) {
-			for_each_cpu_mask(cpu, ce->cpumask)
-				p += sprintf(p, " %d", cpu);
-		} else {
-			/*
-			 * FIXME: Add the cpu which is handling this sucker
-			 */
-		}
-		p += sprintf(p, "\n");
-	}
-
-	spin_unlock(&clockevents_lock);
-
-	return p - buf;
-}
-
-/*
- * Sysfs setup bits:
- */
-static SYSDEV_ATTR(registered, 0600,
-		   clockevents_show_registered, NULL);
-
-static struct sysdev_class clockevents_sysclass = {
-	set_kset_name("clockevents"),
-};
-
-static struct sys_device clockevents_sys_device = {
-	.id	= 0,
-	.cls	= &clockevents_sysclass,
-};
-
-static int __init clockevents_sysfs_init(void)
-{
-	int error = sysdev_class_register(&clockevents_sysclass);
-
-	if (!error)
-		error = sysdev_register(&clockevents_sys_device);
-	if (!error)
-		error = sysdev_create_file(
-				&clockevents_sys_device,
-				&attr_registered);
-	return error;
-}
-device_initcall(clockevents_sysfs_init);
-#endif

Ingo Molnar

Acked-by on v1 1/1

2007-03-26 09:25 UTC #14 lore raw

Re: [PATCH] clockevents: remove bad designed sysfs support for now

Quoted 7 lines · Thomas Gleixner

The current sysfs support of clockevents does not obey the "only one value per file" rule.
The real fix is not 2.6.21 material. Therefor remove the sysfs support for now.
Signed-off-by Thomas Gleixner <[email protected]>

Acked-by Ingo Molnar <[email protected]>

Ingo

Greg KH

Acked-by Greg Kroah-Hartman

2007-03-26 18:59 UTC #15 lore raw

Re: [PATCH] clockevents: remove bad designed sysfs support for now

Quoted 6 lines · Ingo Molnar

Quoted 3 lines · Thomas Gleixner
The current sysfs support of clockevents does not obey the "only one value per file" rule.

Quoted 6 lines

Quoted 4 lines
The real fix is not 2.6.21 material. Therefor remove the sysfs support for now.
Signed-off-by Thomas Gleixner <[email protected]>
Acked-by Ingo Molnar <[email protected]>

Acked-by Greg Kroah-Hartman <[email protected]>

Thanks Thomas for doing this.

greg k-h

Pavel Machek

2007-03-26 12:52 UTC #16 lore raw

Re: [PATCH] clockevents: remove bad designed sysfs support for now

Quoted 7 lines · Thomas Gleixner

The current sysfs support of clockevents does not obey the "only one value per file" rule.
The real fix is not 2.6.21 material. Therefor remove the sysfs support for now.
Signed-off-by Thomas Gleixner <[email protected]>

Thanks!

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Thomas Gleixner

2007-03-27 07:08 UTC #17 lore raw

PATCH 1/1 i386: Fix bogus return value in hpet_next_event()

In reply to Thomas Gleixner

The clockevents / tick management code expects an error value, when the event is already expired. hpet_next_event() returns 1 in that case.

Fix it to return the proper -ETIME error code.

Signed-off-by Thomas Gleixner <[email protected]>

arch/i386/kernel/hpet.c +1 -1

index f3ab61e..76afea6 100644
@@ -197,7 +197,7 @@ static int hpet_next_event(unsigned long delta,
 	cnt += delta;
 	hpet_writel(cnt, HPET_T0_CMP);
 
-	return ((long)(hpet_readl(HPET_COUNTER) - cnt ) > 0);
+	return ((long)(hpet_readl(HPET_COUNTER) - cnt ) > 0) ? -ETIME : 0;
 }
 
 /*

Ingo Molnar

2007-03-26 10:12 UTC #18 lore raw

-rc5: e1000 resume weirdness

hm, on a T60, after suspend/resume, i get an e1000 timeout:

e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang

  Tx Queue             <0>
  TDH                  <ec>
  TDT                  <ec>
  next_to_use          <ec>
  next_to_clean        <82>
buffer_info[next_to_clean]
  time_stamp           <fffcc3db>
  next_to_watch        <82>
  jiffies              <fffd5da0>

next_to_watch.status <1>

it works fine after that reset. The e1000 driver didnt do this before after resume the network was always available immediately. So this appears to be a relatively new regression (post-rc3 or so). high-res timers was disabled.

Ingo

Kok, Auke

2007-03-26 15:45 UTC #19 lore raw

Re: -rc5: e1000 resume weirdness

Quoted 13 lines · Ingo Molnar

hm, on a T60, after suspend/resume, i get an e1000 timeout:
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
  Tx Queue             <0>
  TDH                  <ec>
  TDT                  <ec>
  next_to_use          <ec>
  next_to_clean        <82>
buffer_info[next_to_clean]
  time_stamp           <fffcc3db>
  next_to_watch        <82>
  jiffies              <fffd5da0>

Quoted 8 lines

next_to_watch.status <1>
it works fine after that reset. The e1000 driver didnt do this before after resume the network was always available immediately. So this appears to be a relatively new regression (post-rc3 or so). high-res timers was disabled.
Ingo

THT == TDH -> this is a 'bogus' tx hang indicating that one or more parts in the TX patch is not properly enabled.

Most likely, I suspect that we haven't enabled something because the ordering of irq free/alloc was messed up and nobody cared before, but with all the pci_save_state fixes going in we hit a bump.

The reset kicks it all back up in order so it's something silly like this for sure.

The attached patch fixes that and sitting in my queue for a few days. Can you see if that works?

Auke

---
e1000: Free interrupts symmetrically with resume

From: Auke Kok <[email protected]>

Free interrupts symmetrically with resume allocation to prevent pci save/restore state from possibly failing or warning.

Signed-off-by Auke Kok <[email protected]>

---

 drivers/net/e1000/e1000_main.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

drivers/net/e1000/e1000_main.c +1 -3

index 55ef148..93d41f0 100644
@@ -5190,6 +5190,7 @@ e1000_suspend(struct pci_dev *pdev, pm_message_t state)
 	if (netif_running(netdev)) {
 		WARN_ON(test_bit(__E1000_RESETTING, &adapter->flags));
 		e1000_down(adapter);
+		e1000_free_irq(adapter);
 	}
 
 #ifdef CONFIG_PM

@@ -5257,9 +5258,6 @@ e1000_suspend(struct pci_dev *pdev, pm_message_t state)
 	if (adapter->hw.phy.type == e1000_phy_igp_3)
 		e1000_igp3_phy_powerdown_workaround_ich8lan(&adapter->hw);
 
-	if (netif_running(netdev))
-		e1000_free_irq(adapter);
-
 	/* Release control of h/w to f/w.  If f/w is AMT enabled, this
 	 * would have already happened in close and is redundant. */
 	e1000_release_hw_control(adapter);

Jesse Brandeburg

2007-03-26 15:50 UTC #20 lore raw

Re: -rc5: e1000 resume weirdness

In reply to Jesse Brandeburg

Quoted 14 lines · Ingo Molnar

hm, on a T60, after suspend/resume, i get an e1000 timeout:
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
  Tx Queue             <0>
  TDH                  <ec>
  TDT                  <ec>
  next_to_use          <ec>
  next_to_clean        <82>
buffer_info[next_to_clean]
  time_stamp           <fffcc3db>
  next_to_watch        <82>
  jiffies              <fffd5da0>

Quoted 6 lines

next_to_watch.status <1>
it works fine after that reset. The e1000 driver didnt do this before after resume the network was always available immediately. So this appears to be a relatively new regression (post-rc3 or so). high-res timers was disabled.

was there a "NETDEV WATCHDOG" message that follows this? If not it is a harmless debug print. Note the time_stamp and jiffies difference, very large, consistent with a resume. I think we need to disable the internal e1000 tx hang code that causes this debug print when we are suspending. I'll work with auke to generate a short patch.

Kok, Auke

2007-03-26 15:55 UTC #21 lore raw

Re: -rc5: e1000 resume weirdness

Quoted 21 lines · Jesse Brandeburg

Quoted 13 lines · Ingo Molnar
hm, on a T60, after suspend/resume, i get an e1000 timeout:
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
  Tx Queue             <0>
  TDH                  <ec>
  TDT                  <ec>
  next_to_use          <ec>
  next_to_clean        <82>
buffer_info[next_to_clean]
  time_stamp           <fffcc3db>
  next_to_watch        <82>
  jiffies              <fffd5da0>
Quoted 6 lines
next_to_watch.status <1>
it works fine after that reset. The e1000 driver didnt do this before after resume the network was always available immediately. So this appears to be a relatively new regression (post-rc3 or so). high-res timers was disabled.

Quoted 5 lines

was there a "NETDEV WATCHDOG" message that follows this? If not it is a harmless debug print. Note the time_stamp and jiffies difference, very large, consistent with a resume. I think we need to disable the internal e1000 tx hang code that causes this debug print when we are suspending. I'll work with auke to generate a short patch.

hmm, yeah, it appears that the patch I sent just a second ago isn't applicable in this case, since the irq handler is obviously enabled (the Link Up message proves that).

thanks to Jesse for being awake :)

Auke

Ingo Molnar

2007-03-26 17:39 UTC #22 lore raw

Re: -rc5: e1000 resume weirdness

Quoted 5 lines · Jesse Brandeburg

was there a "NETDEV WATCHDOG" message that follows this? If not it is a harmless debug print. Note the time_stamp and jiffies difference, very large, consistent with a resume. I think we need to disable the internal e1000 tx hang code that causes this debug print when we are suspending. I'll work with auke to generate a short patch.

there was no "NETDEV WATCHDOG" message. But still there was a ~30 seconds delay until i got the first few packets through the interface - while normally it's available almost instantly after resume. But ... this condition seems sporadic, i havent seen it on subsequent suspend+resume attempts.

Ingo

Adrian Bunk

2007-03-27 01:59 UTC #23 lore raw

PATCH 1/5 2.6.21-rc5: known regressions

This email lists some known regressions in Linus' tree compared to 2.6.20.

If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : crashes in KDE
References : http://bugzilla.kernel.org/show_bug.cgi?id=8157
Submitter : Oliver Pinter <[email protected]>
Status : unknown

Subject : kwin dies silently (sysctl related?)
References : http://lkml.org/lkml/2007/2/28/112
Submitter : Sid Boyce <[email protected]>
Boris Mogwitz <[email protected]>
Status : submitter was asked to bisect further

Subject : problem with sockets
References : http://lkml.org/lkml/2007/3/21/248
Submitter : Jose Alberto Reguero <[email protected]>
Status : unknown

Subject : e1000 resume weirdness
References : http://lkml.org/lkml/2007/3/26/91
Submitter : Ingo Molnar <[email protected]>

Handled-By Jesse Brandeburg <[email protected]>

Auke Kok <[email protected]>
Status : problem is being debugged

Subject : forcedeth: sporadic under-load crashes
References : http://lkml.org/lkml/2007/3/26/63
Submitter : Ingo Molnar <[email protected]>

Handled-By Ingo Molnar <[email protected]>

Ayaz Abdulla <[email protected]>
Status : problem is being debugged

Subject : forcedeth: skb_over_panic
References : http://bugzilla.kernel.org/show_bug.cgi?id=8058
Submitter : Albert Hopkins <[email protected]>

Handled-By Ayaz Abdulla <[email protected]>

Patch : http://bugzilla.kernel.org/show_bug.cgi?id=8058
Status : patch available

Kok, Auke

2007-03-28 18:54 UTC #24 lore raw

Re: [1/5] 2.6.21-rc5: known regressions

Quoted 6 lines · Adrian Bunk

Subject : e1000 resume weirdness
References : http://lkml.org/lkml/2007/3/26/91
Submitter : Ingo Molnar <[email protected]>
Handled-By Jesse Brandeburg <[email protected]>
Auke Kok <[email protected]>
Status : problem is being debugged

The issue comes from a corner case and the underlying problem is that e1000 isn't stopping tx properly. We have a fix for this pending in our tree that I'll push upstream for 2.6.22 to Jeff, but I don't think this should be a blocker and it's probably is not a regression at all, the gap has always been present.

on a side note, this is probably fixed easily by turning the adapters detect_tx_hung flag off in e1000_down, so if someone spots this reoccurring somewhat regularly, please contact me so we can debug it. I myself have a system suspend/resuming in circles for an hour now with traffic flying across without a single hit on it....

Adrian, you probably want to drop this issue from your list.

Cheers,

Auke

Ingo Molnar

2007-03-28 19:24 UTC #25 lore raw

Re: [1/5] 2.6.21-rc5: known regressions

Quoted 9 lines · Kok, Auke

Quoted 6 lines · Adrian Bunk
Subject : e1000 resume weirdness
References : http://lkml.org/lkml/2007/3/26/91
Submitter : Ingo Molnar <[email protected]>
Handled-By Jesse Brandeburg <[email protected]>
Auke Kok <[email protected]>
Status : problem is being debugged
Adrian, you probably want to drop this issue from your list.

agreed - i have done many suspend/resumes meanwhile, and this condition has not reoccured since then. (and even when it occured, it was transitionary)

Ingo

Adrian Bunk

2007-03-30 18:04 UTC #26 lore raw

Re: [1/5] 2.6.21-rc5: known regressions

In reply to Kok, Auke

Quoted 14 lines · Auke

Quoted 6 lines · Adrian Bunk
Subject : e1000 resume weirdness
References : http://lkml.org/lkml/2007/3/26/91
Submitter : Ingo Molnar <[email protected]>
Handled-By Jesse Brandeburg <[email protected]>
Auke Kok <[email protected]>
Status : problem is being debugged
The issue comes from a corner case and the underlying problem is that e1000 isn't stopping tx properly. We have a fix for this pending in our tree that I'll push upstream for 2.6.22 to Jeff, but I don't think this should be a blocker and it's probably is not a regression at all, the gap has always been present.

Quoted 7 lines

on a side note, this is probably fixed easily by turning the adapters detect_tx_hung flag off in e1000_down, so if someone spots this reoccurring somewhat regularly, please contact me so we can debug it. I myself have a system suspend/resuming in circles for an hour now with traffic flying across without a single hit on it....
Adrian, you probably want to drop this issue from your list.

Thanks for the update, dropped as non-regression.

Quoted 4 lines

Cheers,
Auke

cu
Adrian

Signature · 4 lines

       "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

Ingo Molnar

2007-03-30 12:04 UTC #27 lore raw

[bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"

i just found a new category of driver regressions in 2.6.21, doing allyesconfig bzImage bootup tests: the init methods of various drivers hangs in driver_unregister().

It is caused by this problem: the semantics of driver_unregister() [also implicitly called in pci_driver_unregister()] has apparently changed recently. If a driver does:

	pci_register_driver(&my_driver);
	...
	if (some_failure) {
		pci_unregister_driver(&my_driver);
		...
	}

it will hang the bootup in the following piece of code:

drivers/base/driver.c:

  void driver_unregister(struct device_driver * drv)
  {
         bus_remove_driver(drv);
         wait_for_completion(&drv->unloaded);

the completion is never done - because nobody removes the bus while the init is still happening, obviously. (and bootup is serialized anyway)

now, the majority of drivers does the driver unregistry from its module-cleanup function, so it's not affected by this problem. But if you apply the debug patch attached further below, and do an allyesconfig bzImage bootup, there's 3 hits already:

 BUG: at drivers/base/driver.c:187 driver_unregister()
  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
  [<c01063e2>] show_trace+0x12/0x14
  [<c01063f8>] dump_stack+0x14/0x16
  [<c063f7e6>] driver_unregister+0x3d/0x43
  [<c0488048>] pci_unregister_driver+0x10/0x5f
  [<c1b5f7c7>] slgt_init+0x9b/0x1ca
  [<c1b31a2d>] init+0x15d/0x2bd
  [<c0105bc3>] kernel_thread_helper+0x7/0x10

 BUG: at drivers/base/driver.c:187 driver_unregister()
  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
  [<c01063e2>] show_trace+0x12/0x14
  [<c01063f8>] dump_stack+0x14/0x16
  [<c063f7e6>] driver_unregister+0x3d/0x43
  [<c0488048>] pci_unregister_driver+0x10/0x5f
  [<c0619505>] init_ipmi_si+0x70a/0x738
  [<c1b31a2d>] init+0x15d/0x2bd
  [<c0105bc3>] kernel_thread_helper+0x7/0x10

 BUG: at drivers/base/driver.c:187 driver_unregister()
  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
  [<c01063e2>] show_trace+0x12/0x14
  [<c01063f8>] dump_stack+0x14/0x16
  [<c063f7e6>] driver_unregister+0x3d/0x43
  [<c0488048>] pci_unregister_driver+0x10/0x5f
  [<c1b6d2d8>] tlan_probe+0x2dd/0x30e
  [<c1b31a2d>] init+0x15d/0x2bd
  [<c0105bc3>] kernel_thread_helper+0x7/0x10

possibly more could trigger. Each of these 3 places caused an actual bootup hang on my testbox, so these are real regressions and need to be fixed.

because there are a good number of drivers that do pci_unregister_device() from their init function, and because i cannot see anything obviously wrong in doing an unregister call after a failure, i think it's driver_unregister() that needs to be fixed. Greg, what do you think?

Ingo

drivers/base/driver.c +2 -1

Index: linux/drivers/base/driver.c
===================================================================
@@ -183,7 +183,8 @@ int driver_register(struct device_driver
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	wait_for_completion(&drv->unloaded);
+	if (!drv->unloaded.done)
+		WARN_ON(1);
 }
 
 /**

Ingo Molnar

2007-03-30 12:07 UTC #28 lore raw

[bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"

there's a new type of message in allyesconfig-bzImage bootup test:

Calling initcall 0xc1b6d692: fixed_init+0x0/0x33()
Fixed PHY: Registered new driver
Device 'fixed@100:1' does not have a release() function, it is broken and must be fixed.

BUG: at drivers/base/core.c:120 device_release()
 [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
 [<c01063e2>] show_trace+0x12/0x14
 [<c01063f8>] dump_stack+0x14/0x16
 [<c063cddf>] device_release+0x7c/0x7e
 [<c0476c32>] kobject_cleanup+0x44/0x5e
 [<c0476c57>] kobject_release+0xb/0xd
 [<c04773ef>] kref_put+0x63/0x71
 [<c0476757>] kobject_put+0x14/0x16
 [<c063ceef>] put_device+0x11/0x13
 [<c063d943>] device_unregister+0x12/0x15
 [<c07337d1>] fixed_mdio_register_device+0x210/0x23b
 [<c1b6d6b0>] fixed_init+0x1e/0x33
 [<c1b31a2d>] init+0x15d/0x2bd
 [<c0105bc3>] kernel_thread_helper+0x7/0x10
 =======================
Device 'fixed@10:1' does not have a release() function, it is broken and must be fixed.
BUG: at drivers/base/core.c:120 device_release()
 [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
 [<c01063e2>] show_trace+0x12/0x14
 [<c01063f8>] dump_stack+0x14/0x16
 [<c063cddf>] device_release+0x7c/0x7e
 [<c0476c32>] kobject_cleanup+0x44/0x5e
 [<c0476c57>] kobject_release+0xb/0xd
 [<c04773ef>] kref_put+0x63/0x71
 [<c0476757>] kobject_put+0x14/0x16
 [<c063ceef>] put_device+0x11/0x13
 [<c063d943>] device_unregister+0x12/0x15
 [<c07337d1>] fixed_mdio_register_device+0x210/0x23b
 [<c1b6d6c1>] fixed_init+0x2f/0x33
 [<c1b31a2d>] init+0x15d/0x2bd
 [<c0105bc3>] kernel_thread_helper+0x7/0x10
 =======================
Calling initcall 0xc1b6d6c5: sundance_init+0x0/0x16()
Calling initcall 0xc1b6d6db: hamachi_init+0x0/0x16()

Greg KH

2007-03-30 14:20 UTC #29 lore raw

Re: [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"

Quoted 30 lines · Ingo Molnar

there's a new type of message in allyesconfig-bzImage bootup test:

Calling initcall 0xc1b6d692: fixed_init+0x0/0x33()
Fixed PHY: Registered new driver
Device 'fixed@100:1' does not have a release() function, it is broken and must be fixed.

BUG: at drivers/base/core.c:120 device_release()
 [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
 [<c01063e2>] show_trace+0x12/0x14
 [<c01063f8>] dump_stack+0x14/0x16
 [<c063cddf>] device_release+0x7c/0x7e
 [<c0476c32>] kobject_cleanup+0x44/0x5e
 [<c0476c57>] kobject_release+0xb/0xd
 [<c04773ef>] kref_put+0x63/0x71
 [<c0476757>] kobject_put+0x14/0x16
 [<c063ceef>] put_device+0x11/0x13
 [<c063d943>] device_unregister+0x12/0x15
 [<c07337d1>] fixed_mdio_register_device+0x210/0x23b
 [<c1b6d6b0>] fixed_init+0x1e/0x33
 [<c1b31a2d>] init+0x15d/0x2bd
 [<c0105bc3>] kernel_thread_helper+0x7/0x10
 =======================
Device 'fixed@10:1' does not have a release() function, it is broken and must be fixed.
BUG: at drivers/base/core.c:120 device_release()
 [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
 [<c01063e2>] show_trace+0x12/0x14
 [<c01063f8>] dump_stack+0x14/0x16
 [<c063cddf>] device_release+0x7c/0x7e
 [<c0476c32>] kobject_cleanup+0x44/0x5e
 [<c0476c57>] kobject_release+0xb/0xd

Quoted 8 lines

 [<c04773ef>] kref_put+0x63/0x71
 [<c0476757>] kobject_put+0x14/0x16
 [<c063ceef>] put_device+0x11/0x13
 [<c063d943>] device_unregister+0x12/0x15
 [<c07337d1>] fixed_mdio_register_device+0x210/0x23b
 [<c1b6d6c1>] fixed_init+0x2f/0x33
 [<c1b31a2d>] init+0x15d/0x2bd
 [<c0105bc3>] kernel_thread_helper+0x7/0x10

That means that whatever driver has fixed_mdio_register_device() in it is broken and needs to be fixed.

It is independant from your previous question about unregistering the device from within module_init().

thanks,

greg k-h

Ingo Molnar

2007-03-30 14:32 UTC #30 lore raw

Re: [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"

Quoted 17 lines · Greg KH

Quoted 16 lines

Device 'fixed@10:1' does not have a release() function, it is broken and must be fixed.

BUG: at drivers/base/core.c:120 device_release()
 [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
 [<c01063e2>] show_trace+0x12/0x14
 [<c01063f8>] dump_stack+0x14/0x16
 [<c063cddf>] device_release+0x7c/0x7e
 [<c0476c32>] kobject_cleanup+0x44/0x5e
 [<c0476c57>] kobject_release+0xb/0xd
 [<c04773ef>] kref_put+0x63/0x71
 [<c0476757>] kobject_put+0x14/0x16
 [<c063ceef>] put_device+0x11/0x13
 [<c063d943>] device_unregister+0x12/0x15
 [<c07337d1>] fixed_mdio_register_device+0x210/0x23b
 [<c1b6d6c1>] fixed_init+0x2f/0x33
 [<c1b31a2d>] init+0x15d/0x2bd
 [<c0105bc3>] kernel_thread_helper+0x7/0x10

Quoted 2 lines

That means that whatever driver has fixed_mdio_register_device() in it is broken and needs to be fixed.

that would be drivers/net/phy/fixed.c.

Quoted 2 lines

It is independant from your previous question about unregistering the device from within module_init().

(yes - hence the different subject line, etc.)

Ingo

Vitaly Bordug

2007-03-30 16:31 UTC #31 lore raw

Re: [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"

Quoted 20 lines · On Fri, 30 Mar 2007 16:25:14 +0200 Ingo Molnar <[email protected]> wrote:

Quoted 17 lines · Greg KH

Quoted 16 lines

Device 'fixed@10:1' does not have a release() function, it is broken and must be fixed.

BUG: at drivers/base/core.c:120 device_release()
 [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
 [<c01063e2>] show_trace+0x12/0x14
 [<c01063f8>] dump_stack+0x14/0x16
 [<c063cddf>] device_release+0x7c/0x7e
 [<c0476c32>] kobject_cleanup+0x44/0x5e
 [<c0476c57>] kobject_release+0xb/0xd
 [<c04773ef>] kref_put+0x63/0x71
 [<c0476757>] kobject_put+0x14/0x16
 [<c063ceef>] put_device+0x11/0x13
 [<c063d943>] device_unregister+0x12/0x15
 [<c07337d1>] fixed_mdio_register_device+0x210/0x23b
 [<c1b6d6c1>] fixed_init+0x2f/0x33
 [<c1b31a2d>] init+0x15d/0x2bd
 [<c0105bc3>] kernel_thread_helper+0x7/0x10

Quoted 5 lines

Quoted 2 lines
That means that whatever driver has fixed_mdio_register_device() in it is broken and needs to be fixed.
that would be drivers/net/phy/fixed.c.

OK, I'll look into it, thanks for pointing out.

Quoted 5 lines

Quoted 2 lines
It is independant from your previous question about unregistering the device from within module_init().
(yes - hence the different subject line, etc.)

Signature · 2 lines

Sincerely, 
Vitaly

Greg KH

2007-03-30 14:18 UTC #32 lore raw

Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"

Quoted 67 lines · Ingo Molnar

i just found a new category of driver regressions in 2.6.21, doing allyesconfig bzImage bootup tests: the init methods of various drivers hangs in driver_unregister().
It is caused by this problem: the semantics of driver_unregister() [also implicitly called in pci_driver_unregister()] has apparently changed recently. If a driver does:
	pci_register_driver(&my_driver);
	...
	if (some_failure) {
		pci_unregister_driver(&my_driver);
		...
	}
it will hang the bootup in the following piece of code:
drivers/base/driver.c:
  void driver_unregister(struct device_driver * drv)
  {
         bus_remove_driver(drv);
         wait_for_completion(&drv->unloaded);
the completion is never done - because nobody removes the bus while the init is still happening, obviously. (and bootup is serialized anyway)
now, the majority of drivers does the driver unregistry from its module-cleanup function, so it's not affected by this problem. But if you apply the debug patch attached further below, and do an allyesconfig bzImage bootup, there's 3 hits already:
 BUG: at drivers/base/driver.c:187 driver_unregister()
  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
  [<c01063e2>] show_trace+0x12/0x14
  [<c01063f8>] dump_stack+0x14/0x16
  [<c063f7e6>] driver_unregister+0x3d/0x43
  [<c0488048>] pci_unregister_driver+0x10/0x5f
  [<c1b5f7c7>] slgt_init+0x9b/0x1ca
  [<c1b31a2d>] init+0x15d/0x2bd
  [<c0105bc3>] kernel_thread_helper+0x7/0x10

 BUG: at drivers/base/driver.c:187 driver_unregister()
  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
  [<c01063e2>] show_trace+0x12/0x14
  [<c01063f8>] dump_stack+0x14/0x16
  [<c063f7e6>] driver_unregister+0x3d/0x43
  [<c0488048>] pci_unregister_driver+0x10/0x5f
  [<c0619505>] init_ipmi_si+0x70a/0x738
  [<c1b31a2d>] init+0x15d/0x2bd
  [<c0105bc3>] kernel_thread_helper+0x7/0x10

 BUG: at drivers/base/driver.c:187 driver_unregister()
  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
  [<c01063e2>] show_trace+0x12/0x14
  [<c01063f8>] dump_stack+0x14/0x16
  [<c063f7e6>] driver_unregister+0x3d/0x43
  [<c0488048>] pci_unregister_driver+0x10/0x5f
  [<c1b6d2d8>] tlan_probe+0x2dd/0x30e
  [<c1b31a2d>] init+0x15d/0x2bd
  [<c0105bc3>] kernel_thread_helper+0x7/0x10
possibly more could trigger. Each of these 3 places caused an actual bootup hang on my testbox, so these are real regressions and need to be fixed.

Quoted 5 lines

because there are a good number of drivers that do pci_unregister_device() from their init function, and because i cannot see anything obviously wrong in doing an unregister call after a failure, i think it's driver_unregister() that needs to be fixed. Greg, what do you think?

Yes, we should allow the ability to call unregister_driver from within the module_init function.

But I don't understand what is causing you to see this problem. Who is holding the reference on the struct device at this point in time? Is it the fact that userspace has some files open and it hasn't released them yet?

I don't see anything implicit in the driver_unregister() path that should not work from within the module_init() path. Kay, am I missing anything here?

(patch left below for Kay's benefit)

thanks,

greg k-h

Quoted 14 lines

Index: linux/drivers/base/driver.c
===================================================================
drivers/base/driver.c +2 -1
@@ -183,7 +183,8 @@ int driver_register(struct device_driver
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	wait_for_completion(&drv->unloaded);
+	if (!drv->unloaded.done)
+		WARN_ON(1);
 }
 
 /**

Ingo Molnar

2007-03-30 17:46 UTC #33 lore raw

Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"

Quoted 10 lines · Greg KH

Quoted 9 lines

 BUG: at drivers/base/driver.c:187 driver_unregister()
  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
  [<c01063e2>] show_trace+0x12/0x14
  [<c01063f8>] dump_stack+0x14/0x16
  [<c063f7e6>] driver_unregister+0x3d/0x43
  [<c0488048>] pci_unregister_driver+0x10/0x5f
  [<c1b5f7c7>] slgt_init+0x9b/0x1ca
  [<c1b31a2d>] init+0x15d/0x2bd
  [<c0105bc3>] kernel_thread_helper+0x7/0x10

Quoted 7 lines

Yes, we should allow the ability to call unregister_driver from within the module_init function.
But I don't understand what is causing you to see this problem. Who is holding the reference on the struct device at this point in time? Is it the fact that userspace has some files open and it hasn't released them yet?

at least in the slgt_init() case the affected codepath is trivial:

        if ((rc = pci_register_driver(&pci_driver)) < 0) {
                printk("%s pci_register_driver error=%d\n", driver_name, rc);
                return rc;
        }
        pci_registered = 1;

        if (!slgt_device_list) {
                printk("%s no devices found\n",driver_name);
                pci_unregister_driver(&pci_driver);
                return -ENODEV;

slgt_device_list is NULL because no matching PCI ID is on my system (i dont have this hardware), so the ->probe() function did not get called at all.

i.e. a pure pci_register_driver() + pci_unregister_driver() sequence seems to cause a hang. I.e. it seems to be a pure driver-base-core matter.

Ingo

Greg KH

2007-03-30 19:34 UTC #34 lore raw

Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"

Quoted 34 lines · Ingo Molnar

Quoted 10 lines · Greg KH
Quoted 9 lines
 BUG: at drivers/base/driver.c:187 driver_unregister()
  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
  [<c01063e2>] show_trace+0x12/0x14
  [<c01063f8>] dump_stack+0x14/0x16
  [<c063f7e6>] driver_unregister+0x3d/0x43
  [<c0488048>] pci_unregister_driver+0x10/0x5f
  [<c1b5f7c7>] slgt_init+0x9b/0x1ca
  [<c1b31a2d>] init+0x15d/0x2bd
  [<c0105bc3>] kernel_thread_helper+0x7/0x10
Quoted 7 lines
Yes, we should allow the ability to call unregister_driver from within the module_init function.
But I don't understand what is causing you to see this problem. Who is holding the reference on the struct device at this point in time? Is it the fact that userspace has some files open and it hasn't released them yet?
at least in the slgt_init() case the affected codepath is trivial:
        if ((rc = pci_register_driver(&pci_driver)) < 0) {
                printk("%s pci_register_driver error=%d\n", driver_name, rc);
                return rc;
        }
        pci_registered = 1;

        if (!slgt_device_list) {
                printk("%s no devices found\n",driver_name);
                pci_unregister_driver(&pci_driver);
                return -ENODEV;

Quoted 3 lines

slgt_device_list is NULL because no matching PCI ID is on my system (i dont have this hardware), so the ->probe() function did not get called at all.

Sorry, no, I realize how this could happen in the driver, I just don't see what in the driver core would be keeping this driver from having it's release function called at the unregister() time.

Something has grabbed a reference to the driver...

Oh wait, is this code a module or built into the kernel?

If it's built in, there's still a reference counting bug in the module/driver hookup logic as we really don't have a "module" yet we are still thinking we do as we represent it in /sys/module and create the linkages.

I created some horrible patches to try to track this down, as it was reported on lkml (look for "Subject: kref refcounting breakage in mainline" ) but never got it working correctly.

I bet if you build that code as a module, it will work just fine, can you try it?

Kay, did you ever get a chance to look into this reference counting issue?

thanks,

greg k-h

Kay Sievers

2007-03-31 02:32 UTC #35 lore raw

Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"

Quoted 56 lines · Greg KH

Quoted 34 lines · Ingo Molnar
Quoted 10 lines · Greg KH
Quoted 9 lines
 BUG: at drivers/base/driver.c:187 driver_unregister()
  [<c0105ff9>] show_trace_log_lvl+0x19/0x2e
  [<c01063e2>] show_trace+0x12/0x14
  [<c01063f8>] dump_stack+0x14/0x16
  [<c063f7e6>] driver_unregister+0x3d/0x43
  [<c0488048>] pci_unregister_driver+0x10/0x5f
  [<c1b5f7c7>] slgt_init+0x9b/0x1ca
  [<c1b31a2d>] init+0x15d/0x2bd
  [<c0105bc3>] kernel_thread_helper+0x7/0x10
Quoted 7 lines
Yes, we should allow the ability to call unregister_driver from within the module_init function.
But I don't understand what is causing you to see this problem. Who is holding the reference on the struct device at this point in time? Is it the fact that userspace has some files open and it hasn't released them yet?
at least in the slgt_init() case the affected codepath is trivial:
        if ((rc = pci_register_driver(&pci_driver)) < 0) {
                printk("%s pci_register_driver error=%d\n", driver_name, rc);
                return rc;
        }
        pci_registered = 1;

        if (!slgt_device_list) {
                printk("%s no devices found\n",driver_name);
                pci_unregister_driver(&pci_driver);
                return -ENODEV;
Quoted 3 lines
slgt_device_list is NULL because no matching PCI ID is on my system (i dont have this hardware), so the ->probe() function did not get called at all.
Sorry, no, I realize how this could happen in the driver, I just don't see what in the driver core would be keeping this driver from having it's release function called at the unregister() time.
Something has grabbed a reference to the driver...
Oh wait, is this code a module or built into the kernel?
If it's built in, there's still a reference counting bug in the module/driver hookup logic as we really don't have a "module" yet we are still thinking we do as we represent it in /sys/module and create the linkages.
I created some horrible patches to try to track this down, as it was reported on lkml (look for "Subject: kref refcounting breakage in mainline" ) but never got it working correctly.

Quoted 5 lines

I bet if you build that code as a module, it will work just fine, can you try it?
Kay, did you ever get a chance to look into this reference counting issue?

Does the attached work for you?

Thanks,
Kay

include/linux/device.h +1 -0

index caad9bb..5cf30e9 100644
@@ -128,6 +128,7 @@ struct device_driver {
 
 	struct module		* owner;
 	const char 		* mod_name;	/* used for built-in modules */
+	struct module_kobject	* mkobj;
 
 	int	(*probe)	(struct device * dev);
 	int	(*remove)	(struct device * dev);

kernel/module.c +14 -4

index fbc51de..dcdb32b 100644
@@ -2384,8 +2384,13 @@ void module_add_driver(struct module *mo
 
 		/* Lookup built-in module entry in /sys/modules */
 		mkobj = kset_find_obj(&module_subsys.kset, drv->mod_name);
-		if (mkobj)
+		if (mkobj) {
 			mk = container_of(mkobj, struct module_kobject, kobj);
+			/* remember our module structure */
+			drv->mkobj = mk;
+			/* kset_find_obj took a reference */
+			kobject_put(mkobj);
+		}
 	}
 
 	if (!mk)

@@ -2405,17 +2410,22 @@ EXPORT_SYMBOL(module_add_driver);
 
 void module_remove_driver(struct device_driver *drv)
 {
+	struct module_kobject *mk = NULL;
 	char *driver_name;
 
 	if (!drv)
 		return;
 
 	sysfs_remove_link(&drv->kobj, "module");
-	if (drv->owner && drv->owner->mkobj.drivers_dir) {
+
+	if (drv->owner)
+		mk = &drv->owner->mkobj;
+	else if (drv->mkobj)
+		mk = drv->mkobj;
+	if (mk && mk->drivers_dir) {
 		driver_name = make_driver_name(drv);
 		if (driver_name) {
-			sysfs_remove_link(drv->owner->mkobj.drivers_dir,
-					  driver_name);
+			sysfs_remove_link(mk->drivers_dir, driver_name);
 			kfree(driver_name);
 		}
 	}

Ingo Molnar

2007-03-31 16:51 UTC #36 lore raw

PATCH 1/1 driver core: fix built-in drivers sysfs links

Quoted 7 lines · Kay Sievers

Quoted 5 lines
I bet if you build that code as a module, it will work just fine, can you try it?
Kay, did you ever get a chance to look into this reference counting issue?
Does the attached work for you?

yeah, this fixed the hangs!

please push it to Andrew and Linus, we want this in v2.6.21. See the full patch below, with proper headers, etc.

Ingo

--------------------->
From: Kay Sievers <[email protected]>
Subject: [patch] driver core: fix built-in drivers sysfs links

built-in drivers had broken sysfs links that caused bootup hangs for certain driver unregistry sequences.

Signed-off-by Ingo Molnar <[email protected]>

---
 include/linux/device.h |    1 +
 kernel/module.c        |   18 ++++++++++++++----
 2 files changed, 15 insertions(+), 4 deletions(-)

include/linux/device.h +1 -0

Index: linux/include/linux/device.h
===================================================================
@@ -128,6 +128,7 @@ struct device_driver {
 
 	struct module		* owner;
 	const char 		* mod_name;	/* used for built-in modules */
+	struct module_kobject	* mkobj;
 
 	int	(*probe)	(struct device * dev);
 	int	(*remove)	(struct device * dev);

kernel/module.c +14 -4

Index: linux/kernel/module.c
===================================================================
@@ -2384,8 +2384,13 @@ void module_add_driver(struct module *mo
 
 		/* Lookup built-in module entry in /sys/modules */
 		mkobj = kset_find_obj(&module_subsys.kset, drv->mod_name);
-		if (mkobj)
+		if (mkobj) {
 			mk = container_of(mkobj, struct module_kobject, kobj);
+			/* remember our module structure */
+			drv->mkobj = mk;
+			/* kset_find_obj took a reference */
+			kobject_put(mkobj);
+		}
 	}
 
 	if (!mk)

@@ -2405,17 +2410,22 @@ EXPORT_SYMBOL(module_add_driver);
 
 void module_remove_driver(struct device_driver *drv)
 {
+	struct module_kobject *mk = NULL;
 	char *driver_name;
 
 	if (!drv)
 		return;
 
 	sysfs_remove_link(&drv->kobj, "module");
-	if (drv->owner && drv->owner->mkobj.drivers_dir) {
+
+	if (drv->owner)
+		mk = &drv->owner->mkobj;
+	else if (drv->mkobj)
+		mk = drv->mkobj;
+	if (mk && mk->drivers_dir) {
 		driver_name = make_driver_name(drv);
 		if (driver_name) {
-			sysfs_remove_link(drv->owner->mkobj.drivers_dir,
-					  driver_name);
+			sysfs_remove_link(mk->drivers_dir, driver_name);
 			kfree(driver_name);
 		}
 	}

Ingo Molnar

2007-03-31 16:32 UTC #37 lore raw

Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"

In reply to Greg KH

Quoted 8 lines · Greg KH

Something has grabbed a reference to the driver...
Oh wait, is this code a module or built into the kernel?
If it's built in, there's still a reference counting bug in the module/driver hookup logic as we really don't have a "module" yet we are still thinking we do as we represent it in /sys/module and create the linkages.

yes - an allyesconfig bzImage kernel is definitely massively built in :)

Quoted 2 lines

Kay, did you ever get a chance to look into this reference counting issue?

i'll try Kay's patch.

Ingo

Pavel Machek

2007-04-01 15:25 UTC #38 lore raw

Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"

Hi!

drivers/base/driver.c int driver_register(struct device_driver · line 188

Quoted 8 lines

drivers/base/driver.c +2 -1

@@ -183,7 +183,8 @@ int driver_register(struct device_driver
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	wait_for_completion(&drv->unloaded);
+	if (!drv->unloaded.done)
+		WARN_ON(1);
 }

WARN_ON(!done)?

Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Linus Torvalds

author

2007-04-01 17:20 UTC #39 lore raw

Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"

Quoted 11 lines · Pavel Machek

Review int driver_register(struct device_driver · line 188

Quoted 9 lines

(quoted diff) +2 -1

@@ -183,7 +183,8 @@ int driver_register(struct device_driver
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	wait_for_completion(&drv->unloaded);
+	if (!drv->unloaded.done)
+		WARN_ON(1);
 }

WARN_ON(!done)?

I think the whole "wait_for_completion()" is just broken.

We asked to *unregister* the driver, not to wait for users.

I would suggest that for 2.6.21, the minimal fix is actually something like the appended. Comments? Ingo, does this fix things for you?

In general, I think the whole "wait for locks" or "wait for users" is almost always a sign of a much bigger bug in reference counting. Modules are special, though, since module code/data doesn't really get reference counted. But doing it for built-in stuff when you don't need to really just sounds *wrong*.

Linus

---
 drivers/base/driver.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

drivers/base/driver.c +8 -1

index 1214cbd..082bfde 100644
@@ -183,7 +183,14 @@ int driver_register(struct device_driver * drv)
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	wait_for_completion(&drv->unloaded);
+	/*
+	 * If the driver is a module, we are probably in
+	 * the module unload path, and we want to wait
+	 * for everything to unload before we can actually
+	 * finish the unload.
+	 */
+	if (drv->owner)
+		wait_for_completion(&drv->unloaded);
 }
 
 /**

Ingo Molnar

2007-04-01 17:35 UTC #40 lore raw

PATCH 1/1 driver core: if built-in, do not wait in driver_unregister()

Quoted 2 lines · Linus Torvalds

I would suggest that for 2.6.21, the minimal fix is actually something like the appended. Comments? Ingo, does this fix things for you?

yeah - it does the trick: i just booted the .config in question and your patch works fine and the bootup does not hang in slgt_init() anymore:

Calling initcall 0xc1e78d86: slgt_init+0x0/0x1ee() SyncLink GT $Revision: 4.36 $
SyncLink GT no devices found
initcall 0xc1e78d86: slgt_init+0x0/0x1ee() returned -19 Calling initcall 0xc1e78f74: n_hdlc_init+0x0/0x9c() HDLC line discipline: version $Revision: 4.8 $, maxframe=4096 N_HDLC line discipline registered.
initcall 0xc1e78f74: n_hdlc_init+0x0/0x9c() returned 0

thanks! Find below the full patch with metadata filled in (no other changes).

Ingo

------------------------->
Subject: [patch] driver core: if built-in, do not wait in driver_unregister()
From: Linus Torvalds <[email protected]>

built-in drivers suffered bootup hangs with certain driver unregistry sequences, due to sysfs breakage.

do the minimal fix for v2.6.21: only wait if the driver is a module.

Signed-off-by Ingo Molnar <[email protected]>

---
 drivers/base/driver.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

drivers/base/driver.c +8 -1

Index: linux/drivers/base/driver.c
===================================================================
@@ -183,7 +183,14 @@ int driver_register(struct device_driver
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	wait_for_completion(&drv->unloaded);
+	/*
+	 * If the driver is a module, we are probably in
+	 * the module unload path, and we want to wait
+	 * for everything to unload before we can actually
+	 * finish the unload.
+	 */
+	if (drv->owner)
+		wait_for_completion(&drv->unloaded);
 }
 
 /**

Greg KH

2007-04-02 03:03 UTC #41 lore raw

Re: [patch] driver core: if built-in, do not wait in driver_unregister()

Quoted 18 lines · Ingo Molnar

Quoted 2 lines · Linus Torvalds
I would suggest that for 2.6.21, the minimal fix is actually something like the appended. Comments? Ingo, does this fix things for you?
yeah - it does the trick: i just booted the .config in question and your patch works fine and the bootup does not hang in slgt_init() anymore:
Calling initcall 0xc1e78d86: slgt_init+0x0/0x1ee() SyncLink GT $Revision: 4.36 $
SyncLink GT no devices found
initcall 0xc1e78d86: slgt_init+0x0/0x1ee() returned -19 Calling initcall 0xc1e78f74: n_hdlc_init+0x0/0x9c() HDLC line discipline: version $Revision: 4.8 $, maxframe=4096 N_HDLC line discipline registered.
initcall 0xc1e78f74: n_hdlc_init+0x0/0x9c() returned 0

Quoted 2 lines

thanks! Find below the full patch with metadata filled in (no other changes).

No, I think this will catch the "hang" but look in sysfs in /sys/modules/ for the module directory for the module that "failed" to be loaded. I think you will see some dangling files there that are incorrect, and might oops if you cat from them (don't remember).

Kay's patch is correct and fixes the reference count issue properly, this one just papers over it by ignoring the fact that the driver is never released and cleaned up in memory.

(patch included below so Kay can verify this...)

thanks,

greg k-h

Quoted 34 lines

------------------------->
Subject: [patch] driver core: if built-in, do not wait in driver_unregister()
From: Linus Torvalds <[email protected]>
built-in drivers suffered bootup hangs with certain driver unregistry sequences, due to sysfs breakage.
do the minimal fix for v2.6.21: only wait if the driver is a module.
Signed-off-by Ingo Molnar <[email protected]>
---
 drivers/base/driver.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)
Index: linux/drivers/base/driver.c
===================================================================
drivers/base/driver.c +8 -1
@@ -183,7 +183,14 @@ int driver_register(struct device_driver
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	wait_for_completion(&drv->unloaded);
+	/*
+	 * If the driver is a module, we are probably in
+	 * the module unload path, and we want to wait
+	 * for everything to unload before we can actually
+	 * finish the unload.
+	 */
+	if (drv->owner)
+		wait_for_completion(&drv->unloaded);
 }
 
 /**

Adrian Bunk

2007-03-27 01:59 UTC #42 lore raw

PATCH 2/5 2.6.21-rc5: known regressions

This email lists some known regressions in Linus' tree compared to 2.6.20.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : x86_64 SMP kernel: maxcpus=1 crash in cpufreq
References : http://lkml.org/lkml/2007/3/26/54
Submitter : Ingo Molnar <[email protected]>

Handled-By Venki Pallipadi <[email protected]>

Status : problem is being debugged

Subject : kernels fail to boot with drives on ATIIXP controller
(ACPI/IRQ related)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621

             http://lkml.org/lkml/2007/3/4/257

Submitter : Michal Jaegermann <[email protected]>
Status : unknown

Subject : NCQ problem with ahci and Hitachi drive (ACPI related)
References : http://lkml.org/lkml/2007/3/4/178

             http://lkml.org/lkml/2007/3/9/475
             http://lkml.org/lkml/2007/2/22/8

Submitter : Mathieu Bérard <[email protected]>

Patch : http://lkml.org/lkml/2007/2/22/8
Status : possible patch available

Subject : libata: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294

             http://www.mail-archive.com/[email protected]/msg04115.html
             http://bugzilla.kernel.org/show_bug.cgi?id=8133
             http://bugzilla.kernel.org/show_bug.cgi?id=8164
             http://lkml.org/lkml/2007/3/21/330

Submitter : Fabio Comolli <[email protected]>
Plamen Petrov <[email protected]> Laurent Riffard <[email protected]> Lukas Hejtmanek <[email protected]>

Patch : http://thread.gmane.org/gmane.linux.ide/17444
Status : patch available

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

Laurent Riffard

2007-03-28 19:46 UTC #43 lore raw

Re: [2/5] 2.6.21-rc5: known regressions

Quoted 1 line · Adrian Bunk

This email lists some known regressions in Linus' tree compared to 2.6.20.

...

Quoted 6 lines

Subject : libata: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294

             http://www.mail-archive.com/[email protected]/msg04115.html
             http://bugzilla.kernel.org/show_bug.cgi?id=8133
             http://bugzilla.kernel.org/show_bug.cgi?id=8164
             http://lkml.org/lkml/2007/3/21/330

Quoted 7 lines

Submitter : Fabio Comolli <[email protected]>
Plamen Petrov <[email protected]> Laurent Riffard <[email protected]> Lukas Hejtmanek <[email protected]>
Handled-By Tejun Heo <[email protected]>
Patch : http://thread.gmane.org/gmane.linux.ide/17444
Status : patch available

pata-via case is fixed for me in 2.6.21-rc5-mm2 (was already fixed in 2.6.21-rc4-mm1).

thanks
~~
laurent

Fabio Comolli

2007-03-29 19:02 UTC #44 lore raw

Re: [2/5] 2.6.21-rc5: known regressions

Hi.

Quoted 16 lines

Quoted 1 line
This email lists some known regressions in Linus' tree compared to 2.6.20.
...
Quoted 6 lines
Subject : libata: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294
             http://www.mail-archive.com/[email protected]/msg04115.html
             http://bugzilla.kernel.org/show_bug.cgi?id=8133
             http://bugzilla.kernel.org/show_bug.cgi?id=8164
             http://lkml.org/lkml/2007/3/21/330
Quoted 7 lines
Submitter : Fabio Comolli <[email protected]>
Plamen Petrov <[email protected]> Laurent Riffard <[email protected]> Lukas Hejtmanek <[email protected]>
Handled-By Tejun Heo <[email protected]>
Patch : http://thread.gmane.org/gmane.linux.ide/17444
Status : patch available

Fixed for me (ata_piix) with today's GIT (Tejun's patch got applied). Regards,
Fabio

Adrian Bunk

2007-03-27 01:59 UTC #45 lore raw

PATCH 3/5 2.6.21-rc5: known regressions

This email lists some known regressions in Linus' tree compared to 2.6.20.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : Oops when changing DVB-T adapter
References : http://lkml.org/lkml/2007/3/9/212
Submitter : CIJOML <[email protected]>
Status : unknown

Subject : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter : Michal Piotrowski <[email protected]>
Status : unknown

Subject : USB: iPod doesn't work (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2007/3/21/320
Submitter : Tino Keitel <[email protected]>

Caused-By Marcelo Tosatti <[email protected]>

             commit 1d619f128ba911cd3e6d6ad3475f146eb92f5c27

Handled-By Oliver Neukum <[email protected]>

Status : problem is being debuggged

Adrian Bunk

2007-03-27 01:59 UTC #46 lore raw

PATCH 4/5 2.6.21-rc5: known regressions

This email lists some known regressions in Linus' tree compared to 2.6.20.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : ThinkPad X60: resume no longer works (PCI related?)
References : http://lkml.org/lkml/2007/3/13/3
Submitter : Dave Jones <[email protected]>
Jeremy Fitzhardinge <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]>
Status : problem is being debugged

Subject : second suspend to disk in a row results in an oops (MSI)
References : http://lkml.org/lkml/2007/3/17/43

             http://lkml.org/lkml/2007/3/22/150
             http://lkml.org/lkml/2007/3/26/205
             http://lkml.org/lkml/2007/3/26/76

Submitter : Thomas Meyer <[email protected]>
Frédéric Riss <[email protected]> Marcus Better <[email protected]>

Handled-By Eric W. Biederman <[email protected]>

Patch : http://lkml.org/lkml/2007/3/24/136
Status : patch was suggested

Subject : Suspend to RAM doesn't work anymore (ACPI?)
References : http://lkml.org/lkml/2007/3/19/128

             http://bugzilla.kernel.org/show_bug.cgi?id=8247

Submitter : Tobias Doerffel <[email protected]>

Len Brown <[email protected]>
Status : problem is being debugged

Subject : s2ram autowake regression (ACPI?)
References : http://lkml.org/lkml/2007/3/20/96
Submitter : Pavel Machek <[email protected]>

Handled-By Len Brown <[email protected]>

Status : submitter was asked to test a patch

Subject : SATA breakage on resume
References : http://lkml.org/lkml/2007/3/7/233
Submitter : Thomas Gleixner <[email protected]>
Soeren Sonnenburg <[email protected]>
Status : unknown

Subject : suspend to disk: keypress required for power down
References : http://lkml.org/lkml/2007/3/25/78
Submitter : Thomas Meyer <[email protected]>
Status : unknown

Subject : resume from RAM corrupts vesafb console
References : http://lkml.org/lkml/2007/3/26/76
Submitter : Marcus Better <[email protected]>

Handled-By Pavel Machek <[email protected]>

Status : problem is being debugged

Subject : suspend to disk: non-boot cpus are disabled again
References : http://lkml.org/lkml/2007/3/25/78
Submitter : Thomas Meyer <[email protected]>

Eric W. Biederman <[email protected]>
Status : problem is being debugged

Subject : ThinkPad doesn't resume from suspend to RAM
References : http://lkml.org/lkml/2007/2/27/80

             http://lkml.org/lkml/2007/2/28/348

Submitter : Jens Axboe <[email protected]>
Jeff Chua <[email protected]>
Status : unknown

Subject : suspend to disk hangs (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter : Maxim Levitsky <[email protected]>

Caused-By Rafael J. Wysocki <[email protected]>

             commit e3c7db621bed4afb8e231cb005057f2feb5db557
             commit ed746e3b18f4df18afa3763155972c5835f284c5
             commit 259130526c267550bc365d3015917d90667732f1

[1] http://permalink.gmane.org/gmane.linux.kernel/509299

Patch : http://lkml.org/lkml/2007/3/23/179
Status : patch available

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

Marcus Better

2007-03-27 08:00 UTC #47 lore raw

Re: [4/5] 2.6.21-rc5: known regressions

Quoted 11 lines

Subject : second suspend to disk in a row results in an oops (MSI)
References : http://lkml.org/lkml/2007/3/17/43
             http://lkml.org/lkml/2007/3/22/150
             http://lkml.org/lkml/2007/3/26/205
             http://lkml.org/lkml/2007/3/26/76
Submitter : Thomas Meyer <[email protected]>
Frédéric Riss <[email protected]> Marcus Better <[email protected]>
Handled-By Eric W. Biederman <[email protected]>
Patch : http://lkml.org/lkml/2007/3/24/136
Status : patch was suggested

For the sake of completeness, my bisection resulted in this:

392ee1e6dd901db6c4504617476f6442ed91f72d is first bad commit commit 392ee1e6dd901db6c4504617476f6442ed91f72d

Author: Eric W. Biederman <[email protected]>
Date:   Thu Mar 8 13:04:57 2007 -0700

[PATCH] msi: Safer state caching.

Marcus

Eric W. Biederman

2007-03-27 13:30 UTC #48 lore raw

Re: [4/5] 2.6.21-rc5: known regressions

Quoted 12 lines · Marcus Better

Quoted 11 lines
Subject : second suspend to disk in a row results in an oops (MSI)
References : http://lkml.org/lkml/2007/3/17/43
             http://lkml.org/lkml/2007/3/22/150
             http://lkml.org/lkml/2007/3/26/205
             http://lkml.org/lkml/2007/3/26/76
Submitter : Thomas Meyer <[email protected]>
Frédéric Riss <[email protected]> Marcus Better <[email protected]>
Handled-By Eric W. Biederman <[email protected]>
Patch : http://lkml.org/lkml/2007/3/24/136
Status : patch was suggested

Quoted 8 lines

For the sake of completeness, my bisection resulted in this:
392ee1e6dd901db6c4504617476f6442ed91f72d is first bad commit commit 392ee1e6dd901db6c4504617476f6442ed91f72d
Author: Eric W. Biederman <[email protected]>
Date:   Thu Mar 8 13:04:57 2007 -0700
[PATCH] msi: Safer state caching.

Right. However if this is what Thomas was seeing the problem turned out to be an issue with pci_enable_device changing the irq number. It just happens that now the code cares, so the bug is found.

Marcus any chance I could see an oops? Or you could try the patch I previously posted when debugging this with Thomas.

I'm going to clean that patch up and send it along in hopes that it helps anyway and see where we land.

Eric

Marcus Better

2007-03-27 16:53 UTC #49 lore raw

Re: [4/5] 2.6.21-rc5: known regressions

Quoted 3 lines · Eric W. Biederman

Quoted 1 line
Quoted 1 line
Patch : http://lkml.org/lkml/2007/3/24/136
Marcus any chance I could see an oops?

I didn't see anything, it froze with the yellow "Linux!" sign. Any idea how to get a oops?

Quoted 2 lines

Or you could try the patch I
previously posted when debugging this with Thomas.

Do you mean the one referenced above? I tried it [1] and it works.

Marcus

Eric W. Biederman

2007-03-27 20:51 UTC #50 lore raw

Re: [4/5] 2.6.21-rc5: known regressions

Quoted 6 lines · Marcus Better

Quoted 3 lines · Eric W. Biederman
Quoted 1 line
Quoted 1 line
Patch : http://lkml.org/lkml/2007/3/24/136
Marcus any chance I could see an oops?

Quoted 7 lines

I didn't see anything, it froze with the yellow "Linux!" sign. Any idea how to get a oops?
Quoted 2 lines
Or you could try the patch I
previously posted when debugging this with Thomas.
Do you mean the one referenced above? I tried it [1] and it works.

Yes. Sorry for being redundant. Having the bisect results after the confirmation that the patch worked threw me.

Eric

Rafael J. Wysocki

2007-03-27 10:06 UTC #51 lore raw

Re: [4/5] 2.6.21-rc5: known regressions

Quoted 8 lines · Adrian Bunk

This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.

I think the following two:

Quoted 11 lines

Subject : suspend to disk: keypress required for power down
References : http://lkml.org/lkml/2007/3/25/78
Submitter : Thomas Meyer <[email protected]>
Status : unknown
Subject : suspend to disk: non-boot cpus are disabled again
References : http://lkml.org/lkml/2007/3/25/78
Submitter : Thomas Meyer <[email protected]>
Handled-By Rafael J. Wysocki <[email protected]>
Eric W. Biederman <[email protected]>
Status : problem is being debugged

are related to the same issue.

The problem is that we call disable_nonboot_cpus() in swsusp before powering down the system in order to avoid triggering the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() and this doesn't work well on Thomas' system.

Since the problem has been introduced by commit 94985134b7b46848267ed6b734320db01c974e72
(swsusp: disable nonboot CPUs before entering platform suspend), I think it's better to revert this commit and remove the the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() (appended is a patch that removes the WARN_ON()).

Greetings,
Rafael

---
Remove the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping(), which triggers every time during the suspend to disk in the platform mode, as the potential problem it is related to doesn't seem to occur in practice.

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 arch/x86_64/kernel/acpi/sleep.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

arch/x86_64/kernel/acpi/sleep.c +3 -1

Index: linux-2.6.21-rc5/arch/x86_64/kernel/acpi/sleep.c
===================================================================
@@ -66,8 +66,10 @@ static void init_low_mapping(void)
 {
 	pgd_t *slot0 = pgd_offset(current->mm, 0UL);
 	low_ptr = *slot0;
+	/* FIXME: We're playing with the current task's page tables here, which
+	 * is potentially dangerous on SMP systems.
+	 */
 	set_pgd(slot0, *pgd_offset(current->mm, PAGE_OFFSET));
-	WARN_ON(num_online_cpus() != 1);
 	local_flush_tlb();
 }

Adrian Bunk

2007-03-27 22:29 UTC #52 lore raw

Re: [4/5] 2.6.21-rc5: known regressions

Quoted 31 lines · Rafael J. Wysocki

Quoted 8 lines · Adrian Bunk
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
I think the following two:
Quoted 11 lines
Subject : suspend to disk: keypress required for power down
References : http://lkml.org/lkml/2007/3/25/78
Submitter : Thomas Meyer <[email protected]>
Status : unknown
Subject : suspend to disk: non-boot cpus are disabled again
References : http://lkml.org/lkml/2007/3/25/78
Submitter : Thomas Meyer <[email protected]>
Handled-By Rafael J. Wysocki <[email protected]>
Eric W. Biederman <[email protected]>
Status : problem is being debugged
are related to the same issue.
The problem is that we call disable_nonboot_cpus() in swsusp before powering down the system in order to avoid triggering the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() and this doesn't work well on Thomas' system.

Quoted 6 lines

Since the problem has been introduced by commit 94985134b7b46848267ed6b734320db01c974e72
(swsusp: disable nonboot CPUs before entering platform suspend), I think it's better to revert this commit and remove the the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping() (appended is a patch that removes the WARN_ON()).

It's now in Linus' tree.

Thomas (Meyer), are there any regressions left with the latest -git tree plus the MSI fix?

Quoted 3 lines

Greetings,
Rafael
...

cu
Adrian

Signature · 4 lines

       "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

Thomas Meyer

2007-03-27 22:45 UTC #53 lore raw

Re: [4/5] 2.6.21-rc5: known regressions

Quoted 5 lines · Adrian Bunk

It's now in Linus' tree.
Thomas (Meyer), are there any regressions left with the latest -git tree plus the MSI fix?

No, not for me.

Ingo Molnar

2007-03-28 12:20 UTC #54 lore raw

Re: [4/5] 2.6.21-rc5: known regressions

Quoted 11 lines · Adrian Bunk

Subject : second suspend to disk in a row results in an oops (MSI)
References : http://lkml.org/lkml/2007/3/17/43
             http://lkml.org/lkml/2007/3/22/150
             http://lkml.org/lkml/2007/3/26/205
             http://lkml.org/lkml/2007/3/26/76
Submitter : Thomas Meyer <[email protected]>
Frédéric Riss <[email protected]> Marcus Better <[email protected]>
Handled-By Eric W. Biederman <[email protected]>
Patch : http://lkml.org/lkml/2007/3/24/136
Status : patch was suggested

i can reproduce a crash on the second suspend-to-ram, on a T60. I get a crash here:

#ifdef CONFIG_PM
static void __pci_restore_msi_state(struct pci_dev *dev)

 {
         int pos;
         u16 control;
         struct msi_desc *entry;

         if (!dev->msi_enabled)
                 return;

         entry = get_irq_msi(dev->irq);
         pos = entry->msi_attrib.pos; <-------- crash on NULL dereference

i.e. 'entry' is NULL after get_irq_msi(). (i can see the crash only on the VGA screen so no dump of it available. Can write down more info if it's helpful.)

I have tried Eric's patch above but now i always get a hang after "system 00:00: resuming", already upon the first suspend-resume. Not even the NMI watchdog can get the system out of that hang.

Ingo

Ingo Molnar

2007-03-28 12:42 UTC #55 lore raw

Re: [4/5] 2.6.21-rc5: known regressions

Quoted 11 lines · Ingo Molnar

         entry = get_irq_msi(dev->irq);
         pos = entry->msi_attrib.pos; <-------- crash on NULL dereference
i.e. 'entry' is NULL after get_irq_msi(). (i can see the crash only on the VGA screen so no dump of it available. Can write down more info if it's helpful.)
I have tried Eric's patch above but now i always get a hang after "system 00:00: resuming", already upon the first suspend-resume. Not even the NMI watchdog can get the system out of that hang.

find below the PM log of a successful suspend/resume cycle. (I've marked the place that hangs with '[hard hang]')

Ingo

---------------->
PM: Preparing system for mem sleep
Stopping tasks ... done.
psmouse serio2: suspend
psmouse serio1: suspend
atkbd serio0: suspend
i8042 i8042: suspend
sd 0:0:0:0: suspend
ide 0.0: suspend
serial8250 serial8250: suspend
platform vesafb.0: suspend
pci_express 0000:00:1c.3:pcie03: suspend
pci_express 0000:00:1c.3:pcie02: suspend
pci_express 0000:00:1c.3:pcie00: suspend
pci_express 0000:00:1c.2:pcie03: suspend
pci_express 0000:00:1c.2:pcie02: suspend
pci_express 0000:00:1c.2:pcie00: suspend
pci_express 0000:00:1c.1:pcie03: suspend
pci_express 0000:00:1c.1:pcie02: suspend
pci_express 0000:00:1c.1:pcie00: suspend
pci_express 0000:00:1c.0:pcie03: suspend
pci_express 0000:00:1c.0:pcie02: suspend
pci_express 0000:00:1c.0:pcie00: suspend
platform pcspkr: suspend
pnp 00:0a: suspend
i8042 aux 00:09: suspend
i8042 kbd 00:08: suspend
pnp 00:07: suspend
pnp 00:06: suspend
pnp 00:05: suspend
pnp 00:04: suspend
pnp 00:03: suspend
system 00:02: suspend
pnp 00:01: suspend
system 00:00: suspend
yenta_cardbus 0000:15:00.0: suspend
pci 0000:03:00.0: suspend
e1000 0000:02:00.0: suspend
pci 0000:03:00.0: resuming
yenta_cardbus 0000:15:00.0: resuming
PM: Writing back config space on device 0000:15:00.0 at offset f (was 34001ff, writing 5c0010b)
PM: Writing back config space on device 0000:15:00.0 at offset e (was 0, writing 94fc)
PM: Writing back config space on device 0000:15:00.0 at offset d (was 0, writing 9400)
PM: Writing back config space on device 0000:15:00.0 at offset c (was 0, writing 90fc)
PM: Writing back config space on device 0000:15:00.0 at offset b (was 0, writing 9000)
PM: Writing back config space on device 0000:15:00.0 at offset a (was 0, writing 8bfff000)
PM: Writing back config space on device 0000:15:00.0 at offset 9 (was 0, writing 88000000)
PM: Writing back config space on device 0000:15:00.0 at offset 8 (was 0, writing e3fff000)
PM: Writing back config space on device 0000:15:00.0 at offset 7 (was 0, writing e0000000)
PM: Writing back config space on device 0000:15:00.0 at offset 6 (was 0, writing b0171615)
PM: Writing back config space on device 0000:15:00.0 at offset 4 (was 0, writing e4300000)
PM: Writing back config space on device 0000:15:00.0 at offset 3 (was 20000, writing 2a820)
PM: Writing back config space on device 0000:15:00.0 at offset 1 (was 2100000, writing 2100007) system 00:00: resuming <-------------- [ hard hang ]
pnp 00:01: resuming
system 00:02: resuming
pnp 00:03: resuming
pnp 00:04: resuming
pnp 00:05: resuming
pnp 00:06: resuming
pnp 00:07: resuming
i8042 kbd 00:08: resuming
i8042 aux 00:09: resuming
pnp 00:0a: resuming
platform pcspkr: resuming
pci_express 0000:00:1c.0:pcie00: resuming
pci_express 0000:00:1c.0:pcie02: resuming
pci_express 0000:00:1c.0:pcie03: resuming
pci_express 0000:00:1c.1:pcie00: resuming
pci_express 0000:00:1c.1:pcie02: resuming
pci_express 0000:00:1c.1:pcie03: resuming
pci_express 0000:00:1c.2:pcie00: resuming
pci_express 0000:00:1c.2:pcie02: resuming
pci_express 0000:00:1c.2:pcie03: resuming
pci_express 0000:00:1c.3:pcie00: resuming
pci_express 0000:00:1c.3:pcie02: resuming
pci_express 0000:00:1c.3:pcie03: resuming
platform vesafb.0: resuming
serial8250 serial8250: resuming
ide 0.0: resuming
sd 0:0:0:0: resuming
i8042 i8042: resuming
atkbd serio0: resuming
psmouse serio1: resuming
ata2: SATA link down (SStatus 0 SControl 0)
ata3: SATA link down (SStatus 0 SControl 0)
ata4: SATA link down (SStatus 0 SControl 0)
psmouse serio2: resuming
ata1: waiting for device to spin up (7 secs)
Restarting tasks ... done.
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/100
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
PM: Preparing system for mem sleep

Ingo Molnar

2007-03-28 13:04 UTC #56 lore raw

Re: [4/5] 2.6.21-rc5: known regressions

Quoted 7 lines · Ingo Molnar

PM: Writing back config space on device 0000:15:00.0 at offset 4 (was 0, writing e4300000)
PM: Writing back config space on device 0000:15:00.0 at offset 3 (was 20000, writing 2a820)
PM: Writing back config space on device 0000:15:00.0 at offset 1 (was 2100000, writing 2100007) system 00:00: resuming <-------------- [ hard hang ]
pnp 00:01: resuming
system 00:02: resuming
pnp 00:03: resuming

ok, this was a red herring: the hard hang was an effect of netconsole combined with CONFIG_DISABLE_CONSOLE_SUSPEND. Disabling netconsole solved it. I'll now re-test Eric's MSI patch.

Ingo

Ingo Molnar

2007-03-28 13:08 UTC #57 lore raw

PATCH 1/1 MSI-X: fix resume crash

Quoted 1 line · Ingo Molnar

[...] I'll now re-test Eric's MSI patch.

Eric's patch seems to have done the trick on my T60: i've done 10 suspend+resumes and each worked fine. I've tidied up the description part of Eric's patch a bit for upstream application - find it below.

Ingo

---------------------->
Subject: [patch] MSI-X: fix resume crash
From: Eric W. Biederman <[email protected]>

I think the right solution is to simply make pci_enable_device just flip enable bits and move the rest of the work someplace else.

However a thorough cleanup is a little extreme for this point in the release cycle, so I think a quick hack that makes the code not stomp the irq when msi irq's are enabled should be the first fix. Then we can later make the code not change the irqs at all.

Tony, Len the way pci_disable_device is being used in a suspend/resume path by a few drivers is completely incompatible with the way irqs are allocated on ia64. In particular people the following sequence occurs in several drivers.

probe:
pci_enable_device(pdev);
request_irq(pdev->irq);
suspend:
pci_disable_device(pdev);
resume:
pci_enable_device(pdev);
remove:
free_irq(pdev->irq);
pci_disable_device(pdev);

What I'm proposing we do is move the irq allocation code out of pci_enable_device and the irq freeing code out of pci_disable_device in the future. If we move ia64 to a model where the irq number equal the gsi like we have for x86_64 and are in the middle of for i386 that should be pretty straight forward. It would even be relatively simple to delay vector allocation in that context until request_irq, if we needed the delayed allocation benefit. Do you two have any problems with moving in that direction?

If fixing the arch code is unacceptable for some reason I'm not aware of we need to audit the 10-20 drivers that call pci_disable_device in their suspend/resume processing and ensure that they have freed all of the irqs before that point. Given that I have bug reports on the msi path I know that isn't true.

From: Eric W. Biederman <[email protected]>

Signed-off-by Ingo Molnar <[email protected]>

---
 arch/cris/arch-v32/drivers/pci/bios.c |    4 +++-
 arch/frv/mb93090-mb00/pci-vdk.c       |    3 ++-
 arch/i386/pci/common.c                |    6 ++++--
 arch/ia64/pci/pci.c                   |    8 ++++++--
 4 files changed, 15 insertions(+), 6 deletions(-)

arch/cris/arch-v32/drivers/pci/bios.c +3 -1

Index: linux/arch/cris/arch-v32/drivers/pci/bios.c
===================================================================
@@ -100,7 +100,9 @@ int pcibios_enable_device(struct pci_dev
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
 
-	return pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		pcibios_enable_irq(dev);
+	return 0;
 }
 
 int pcibios_assign_resources(void)

arch/frv/mb93090-mb00/pci-vdk.c +2 -1

Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
===================================================================
@@ -466,6 +466,7 @@ int pcibios_enable_device(struct pci_dev
 
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
-	pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		pcibios_enable_irq(dev);
 	return 0;
 }

arch/i386/pci/common.c +4 -2

Index: linux/arch/i386/pci/common.c
===================================================================
@@ -434,11 +434,13 @@ int pcibios_enable_device(struct pci_dev
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
 
-	return pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		return pcibios_enable_irq(dev);
+	return 0;
 }
 
 void pcibios_disable_device (struct pci_dev *dev)
 {
-	if (pcibios_disable_irq)
+	if (!dev->msi_enabled && pcibios_disable_irq)
 		pcibios_disable_irq(dev);
 }

arch/ia64/pci/pci.c +6 -2

Index: linux/arch/ia64/pci/pci.c
===================================================================
@@ -557,14 +557,18 @@ pcibios_enable_device (struct pci_dev *d
 	if (ret < 0)
 		return ret;
 
-	return acpi_pci_irq_enable(dev);
+	if (!dev->msi_enabled)
+		return acpi_pci_irq_enable(dev);
+	return 0;
 }
 
 void
 pcibios_disable_device (struct pci_dev *dev)
 {
 	BUG_ON(atomic_read(&dev->enable_cnt));
-	acpi_pci_irq_disable(dev);
+	if (!dev->msi_enabled)
+		acpi_pci_irq_disable(dev);
+	return 0;
 }
 
 void

Eric W. Biederman

2007-03-28 13:35 UTC #58 lore raw

Re: [patch] MSI-X: fix resume crash

Quoted 7 lines · Ingo Molnar

Quoted 1 line · Ingo Molnar
[...] I'll now re-test Eric's MSI patch.
Eric's patch seems to have done the trick on my T60: i've done 10 suspend+resumes and each worked fine. I've tidied up the description part of Eric's patch a bit for upstream application - find it below.

Thanks. Tidying up the description has been on my todo list for the last little bit but I just haven't gotten there.

I've gotten at least Tony's sign off on the architectural direction so there is nothing to prevent this patch from going in. Unless Linus or someone wants a more thorough patch this late in the release cycle.

Signed-off-by "Eric W. Biederman" <[email protected]>

Quoted 125 lines

---------------------->
Subject: [patch] MSI-X: fix resume crash
From: Eric W. Biederman <[email protected]>
I think the right solution is to simply make pci_enable_device just flip enable bits and move the rest of the work someplace else.
However a thorough cleanup is a little extreme for this point in the release cycle, so I think a quick hack that makes the code not stomp the irq when msi irq's are enabled should be the first fix. Then we can later make the code not change the irqs at all.
Tony, Len the way pci_disable_device is being used in a suspend/resume path by a few drivers is completely incompatible with the way irqs are allocated on ia64. In particular people the following sequence occurs in several drivers.
probe:
pci_enable_device(pdev);
request_irq(pdev->irq);
suspend:
pci_disable_device(pdev);
resume:
pci_enable_device(pdev);
remove:
free_irq(pdev->irq);
pci_disable_device(pdev);
What I'm proposing we do is move the irq allocation code out of pci_enable_device and the irq freeing code out of pci_disable_device in the future. If we move ia64 to a model where the irq number equal the gsi like we have for x86_64 and are in the middle of for i386 that should be pretty straight forward. It would even be relatively simple to delay vector allocation in that context until request_irq, if we needed the delayed allocation benefit. Do you two have any problems with moving in that direction?
If fixing the arch code is unacceptable for some reason I'm not aware of we need to audit the 10-20 drivers that call pci_disable_device in their suspend/resume processing and ensure that they have freed all of the irqs before that point. Given that I have bug reports on the msi path I know that isn't true.
From: Eric W. Biederman <[email protected]>
Signed-off-by Ingo Molnar <[email protected]>
---
 arch/cris/arch-v32/drivers/pci/bios.c |    4 +++-
 arch/frv/mb93090-mb00/pci-vdk.c       |    3 ++-
 arch/i386/pci/common.c                |    6 ++++--
 arch/ia64/pci/pci.c                   |    8 ++++++--
 4 files changed, 15 insertions(+), 6 deletions(-)
Index: linux/arch/cris/arch-v32/drivers/pci/bios.c
===================================================================
arch/cris/arch-v32/drivers/pci/bios.c +3 -1
@@ -100,7 +100,9 @@ int pcibios_enable_device(struct pci_dev
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
 
-	return pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		pcibios_enable_irq(dev);
+	return 0;
 }
 
 int pcibios_assign_resources(void)
Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
===================================================================
arch/frv/mb93090-mb00/pci-vdk.c +2 -1
@@ -466,6 +466,7 @@ int pcibios_enable_device(struct pci_dev
 
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
-	pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		pcibios_enable_irq(dev);
 	return 0;
 }
Index: linux/arch/i386/pci/common.c
===================================================================
arch/i386/pci/common.c +4 -2
@@ -434,11 +434,13 @@ int pcibios_enable_device(struct pci_dev
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
 
-	return pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		return pcibios_enable_irq(dev);
+	return 0;
 }
 
 void pcibios_disable_device (struct pci_dev *dev)
 {
-	if (pcibios_disable_irq)
+	if (!dev->msi_enabled && pcibios_disable_irq)
 		pcibios_disable_irq(dev);
 }
Index: linux/arch/ia64/pci/pci.c
===================================================================
arch/ia64/pci/pci.c +6 -2
@@ -557,14 +557,18 @@ pcibios_enable_device (struct pci_dev *d
 	if (ret < 0)
 		return ret;
 
-	return acpi_pci_irq_enable(dev);
+	if (!dev->msi_enabled)
+		return acpi_pci_irq_enable(dev);
+	return 0;
 }
 
 void
 pcibios_disable_device (struct pci_dev *dev)
 {
 	BUG_ON(atomic_read(&dev->enable_cnt));
-	acpi_pci_irq_disable(dev);
+	if (!dev->msi_enabled)
+		acpi_pci_irq_disable(dev);
+	return 0;
 }
 
 void

Ingo Molnar

2007-03-28 13:38 UTC #59 lore raw

Re: [patch] MSI-X: fix resume crash

Quoted 4 lines · Eric W. Biederman

Quoted 3 lines
Eric's patch seems to have done the trick on my T60: i've done 10 suspend+resumes and each worked fine. I've tidied up the description part of Eric's patch a bit for upstream application - find it below.

Quoted 8 lines

Thanks. Tidying up the description has been on my todo list for the last little bit but I just haven't gotten there.
I've gotten at least Tony's sign off on the architectural direction so there is nothing to prevent this patch from going in. Unless Linus or someone wants a more thorough patch this late in the release cycle.
Signed-off-by "Eric W. Biederman" <[email protected]>

i've updated the patch below with your sign-off, and trimmed the description to the relevant bits, for easy upstream application.

Ingo

------------->
Subject: [patch] MSI-X: fix resume crash
From: Eric W. Biederman <[email protected]>

So I think the right solution is to simply make pci_enable_device just flip enable bits and move the rest of the work someplace else.

Signed-off-by Eric W. Biederman <[email protected]>

Signed-off-by Ingo Molnar <[email protected]>

---
 arch/cris/arch-v32/drivers/pci/bios.c |    4 +++-
 arch/frv/mb93090-mb00/pci-vdk.c       |    3 ++-
 arch/i386/pci/common.c                |    6 ++++--
 arch/ia64/pci/pci.c                   |    8 ++++++--
 4 files changed, 15 insertions(+), 6 deletions(-)

arch/cris/arch-v32/drivers/pci/bios.c +3 -1

Index: linux/arch/cris/arch-v32/drivers/pci/bios.c
===================================================================
@@ -100,7 +100,9 @@ int pcibios_enable_device(struct pci_dev
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
 
-	return pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		pcibios_enable_irq(dev);
+	return 0;
 }
 
 int pcibios_assign_resources(void)

arch/frv/mb93090-mb00/pci-vdk.c +2 -1

Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
===================================================================
@@ -466,6 +466,7 @@ int pcibios_enable_device(struct pci_dev
 
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
-	pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		pcibios_enable_irq(dev);
 	return 0;
 }

arch/i386/pci/common.c +4 -2

Index: linux/arch/i386/pci/common.c
===================================================================
@@ -434,11 +434,13 @@ int pcibios_enable_device(struct pci_dev
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
 
-	return pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		return pcibios_enable_irq(dev);
+	return 0;
 }
 
 void pcibios_disable_device (struct pci_dev *dev)
 {
-	if (pcibios_disable_irq)
+	if (!dev->msi_enabled && pcibios_disable_irq)
 		pcibios_disable_irq(dev);
 }

arch/ia64/pci/pci.c +6 -2

Index: linux/arch/ia64/pci/pci.c
===================================================================
@@ -557,14 +557,18 @@ pcibios_enable_device (struct pci_dev *d
 	if (ret < 0)
 		return ret;
 
-	return acpi_pci_irq_enable(dev);
+	if (!dev->msi_enabled)
+		return acpi_pci_irq_enable(dev);
+	return 0;
 }
 
 void
 pcibios_disable_device (struct pci_dev *dev)
 {
 	BUG_ON(atomic_read(&dev->enable_cnt));
-	acpi_pci_irq_disable(dev);
+	if (!dev->msi_enabled)
+		acpi_pci_irq_disable(dev);
+	return 0;
 }
 
 void

Len Brown

reviewer

2007-03-29 04:38 UTC #60 lore raw

Re: [patch] MSI-X: fix resume crash

Quoted 5 lines

Tony, Len the way pci_disable_device is being used in a suspend/resume path by a few drivers is completely incompatible with the way irqs are allocated on ia64. In particular people the following sequence occurs in several drivers.

Quoted 10 lines

probe:
pci_enable_device(pdev);
request_irq(pdev->irq);
suspend:
pci_disable_device(pdev);
resume:
pci_enable_device(pdev);
remove:
free_irq(pdev->irq);
pci_disable_device(pdev);

There are no IA64 machines that support system suspend/resume today -- so you have 0 chance of breaking the IA64 suspend/resume installed base.

My understanding is that Luming Yu has cobbled IA64 S4 support together for a future release though.

Quoted 8 lines

What I'm proposing we do is move the irq allocation code out of pci_enable_device and the irq freeing code out of pci_disable_device in the future. If we move ia64 to a model where the irq number equal the gsi like we have for x86_64 and are in the middle of for i386 that should be pretty straight forward. It would even be relatively simple to delay vector allocation in that context until request_irq, if we needed the delayed allocation benefit. Do you two have any problems with moving in that direction?

I think consistency here would be _wonderful_.
Of course the beauty of having identity GSI=IRQ and a /proc/interrupts that tells you what IOAPIC pin you are using become moot with MSI -- but hey, showing the IRQ number rather than the vector number is consistent and makes sense.

Quoted 5 lines

If fixing the arch code is unacceptable for some reason I'm not aware of we need to audit the 10-20 drivers that call pci_disable_device in their suspend/resume processing and ensure that they have freed all of the irqs before that point. Given that I have bug reports on the msi path I know that isn't true.

I think the suspend/resume interrupt logic needs some serious attention. We've had several schemes for suspend/resume of interrupts, several changes in strategy, and right now I think we are inconsistent, and frankly, I'm amazed it works at all.

-Len

Quoted 88 lines

From: Eric W. Biederman <[email protected]>
Signed-off-by Ingo Molnar <[email protected]>
---
 arch/cris/arch-v32/drivers/pci/bios.c |    4 +++-
 arch/frv/mb93090-mb00/pci-vdk.c       |    3 ++-
 arch/i386/pci/common.c                |    6 ++++--
 arch/ia64/pci/pci.c                   |    8 ++++++--
 4 files changed, 15 insertions(+), 6 deletions(-)
Index: linux/arch/cris/arch-v32/drivers/pci/bios.c
===================================================================
arch/cris/arch-v32/drivers/pci/bios.c +3 -1
@@ -100,7 +100,9 @@ int pcibios_enable_device(struct pci_dev
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
 
-	return pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		pcibios_enable_irq(dev);
+	return 0;
 }
 
 int pcibios_assign_resources(void)
Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
===================================================================
arch/frv/mb93090-mb00/pci-vdk.c +2 -1
@@ -466,6 +466,7 @@ int pcibios_enable_device(struct pci_dev
 
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
-	pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		pcibios_enable_irq(dev);
 	return 0;
 }
Index: linux/arch/i386/pci/common.c
===================================================================
arch/i386/pci/common.c +4 -2
@@ -434,11 +434,13 @@ int pcibios_enable_device(struct pci_dev
 	if ((err = pcibios_enable_resources(dev, mask)) < 0)
 		return err;
 
-	return pcibios_enable_irq(dev);
+	if (!dev->msi_enabled)
+		return pcibios_enable_irq(dev);
+	return 0;
 }
 
 void pcibios_disable_device (struct pci_dev *dev)
 {
-	if (pcibios_disable_irq)
+	if (!dev->msi_enabled && pcibios_disable_irq)
 		pcibios_disable_irq(dev);
 }
Index: linux/arch/ia64/pci/pci.c
===================================================================
arch/ia64/pci/pci.c +6 -3
@@ -557,14 +557,18 @@ pcibios_enable_device (struct pci_dev *d
 	if (ret < 0)
 		return ret;
 
-	return acpi_pci_irq_enable(dev);
+	if (!dev->msi_enabled)
+		return acpi_pci_irq_enable(dev);
+	return 0;
 }
 
 void
 pcibios_disable_device (struct pci_dev *dev)
 {
 	BUG_ON(atomic_read(&dev->enable_cnt));
-	acpi_pci_irq_disable(dev);
+	if (!dev->msi_enabled)
+		acpi_pci_irq_disable(dev);
+	return 0;
 }
 
 void
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Eric W. Biederman

2007-03-29 05:04 UTC #61 lore raw

Re: [patch] MSI-X: fix resume crash

Quoted 16 lines · Len Brown

Quoted 5 lines
Tony, Len the way pci_disable_device is being used in a suspend/resume path by a few drivers is completely incompatible with the way irqs are allocated on ia64. In particular people the following sequence occurs in several drivers.
Quoted 10 lines
probe:
pci_enable_device(pdev);
request_irq(pdev->irq);
suspend:
pci_disable_device(pdev);
resume:
pci_enable_device(pdev);
remove:
free_irq(pdev->irq);
pci_disable_device(pdev);

Quoted 2 lines

There are no IA64 machines that support system suspend/resume today -- so you have 0 chance of breaking the IA64 suspend/resume installed base.

Ok. So that is why the inconsistency persists...

Quoted 12 lines

My understanding is that Luming Yu has cobbled IA64 S4 support together for a future release though.
Quoted 8 lines
What I'm proposing we do is move the irq allocation code out of pci_enable_device and the irq freeing code out of pci_disable_device in the future. If we move ia64 to a model where the irq number equal the gsi like we have for x86_64 and are in the middle of for i386 that should be pretty straight forward. It would even be relatively simple to delay vector allocation in that context until request_irq, if we needed the delayed allocation benefit. Do you two have any problems with moving in that direction?

Quoted 5 lines

I think consistency here would be _wonderful_.
Of course the beauty of having identity GSI=IRQ and a /proc/interrupts that tells you what IOAPIC pin you are using become moot with MSI -- but hey, showing the IRQ number rather than the vector number is consistent and makes sense.

Yes. It also allows for bigger machines. And I can get a consistent number out of MSI if we allocate irq numbers in a sufficiently non-sparse way. Something like bus|device|func|irq which is 8+5+3+12 or 28 bits... I'll never get there though if i keep unearthing this long standing bugs.

Quoted 10 lines

Quoted 5 lines
If fixing the arch code is unacceptable for some reason I'm not aware of we need to audit the 10-20 drivers that call pci_disable_device in their suspend/resume processing and ensure that they have freed all of the irqs before that point. Given that I have bug reports on the msi path I know that isn't true.
I think the suspend/resume interrupt logic needs some serious attention. We've had several schemes for suspend/resume of interrupts, several changes in strategy, and right now I think we are inconsistent, and frankly, I'm amazed it works at all.

What I have been doing lately is to aim at consistency in how a function is called (and thus how it is expected to be used) and how it is actually implemented. When I have a choice I try to pick a forgiving implementation so that driver writers don't have to follow a magic correct path for things to work correctly.

Removing the irq assignment from pci_enable_device is something that matches implementation with use.

As for the rest it seems reasonable to me to allow an irq to be held requested over suspend/resume and to save and restore apic and msi capability state. Especially since irq numbers are a kernel abstraction we should be able to do with them what we need to.

Honestly the whole suspend/resume thing is beyond me at this point I'm laptop free... But I do know how to make code consistent with itself.

Eric

Adrian Bunk

2007-03-27 01:59 UTC #62 lore raw

PATCH 5/5 2.6.21-rc5: known regressions

This email lists some known regressions in Linus' tree compared to 2.6.20.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : MacMini doesn't come out of suspend to ram (i386 clockevents)
(CONFIG_HPET_TIMER)
References : http://lkml.org/lkml/2007/3/21/374
Submitter : Frédéric Riss <[email protected]>
Tino Keitel <[email protected]>

Caused-By Thomas Gleixner <[email protected]>

             commit e9e2cdb412412326c4827fc78ba27f410d837e6e

Status : unknown

Subject : MacBook Core Duo: suspend to disk hangs
References : http://bugzilla.kernel.org/show_bug.cgi?id=8224
Submitter : Mike Harris <[email protected]>
Status : unknown

Subject : Dynticks and High resolution Timer hang boot during IDE detection
workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/7/504
Submitter : Stephane Casset <[email protected]>

Caused-By John Stultz <[email protected]>

             commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd

Handled-By John Stultz <[email protected]>

Patch : http://lkml.org/lkml/2007/3/22/287
Status : workaround-patch available

Subject : after resume: X hangs after drawing a couple of windows
workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/8/117

             http://lkml.org/lkml/2007/3/25/20
             http://lkml.org/lkml/2007/3/26/151

Submitter : Michael S. Tsirkin <[email protected]>

Status : problem is being debugged

Subject : first disk access after resume takes several minutes
resume from RAM broken
'date' does not advance after resume from RAM (CONFIG_HPET_TIMER)
References : http://lkml.org/lkml/2007/3/8/117

             http://lkml.org/lkml/2007/3/25/20
             http://lkml.org/lkml/2007/3/26/18

Submitter : Michael S. Tsirkin <[email protected]>
Jeff Chua <[email protected]>

Ingo Molnar <[email protected]>
Status : problem is being debugged

Subject : system doesn't come out of suspend (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <[email protected]>
Soeren Sonnenburg <[email protected]>

Ingo Molnar <[email protected]>
Tejun Heo <[email protected]>
Rafael J. Wysocki <[email protected]>
Status : unknown

Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <[email protected]>
Status : unknown

Jeff Garzik

2007-03-27 05:51 UTC #63 lore raw

ATA ACPI (was Re: Linux 2.6.21-rc5)

Quoted 11 lines · Linus Torvalds

There's various fixes here, ranging from some architecture updates (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
And random one-liners.
But probably more important, and likely much more visible to most people is the fixes for the fallout from the hrtimers and no-HZ changes, and some of the ACPI regressions.
Those timer changes ended up much more painful than anybody wished for, but big thanks to Thomas Gleixner for being on it like a weasel on a dead rat, and the regression list has kept shrinking.
So if you have reported a regression in the 2.6.21-rc series, please check 2.6.21-rc5, and update your report as appropriate (whether fixed or "still problems with xyzzy").
Linus

[just got back from vacation, or would have sent this earlier]

FWIW, I'm still leaning towards disabling libata ACPI support by default for 2.6.21.

Upstream has Alan's fix for the worst PATA problems, but for different reasons, I think PATA ACPI and SATA ACPI support in libata does not feel quite ready for prime time in 2.6.21.

Scream now, or hold your peace until 2.6.22... :)

Jeff

Tejun Heo

2007-03-27 05:54 UTC #64 lore raw

Re: ATA ACPI (was Re: Linux 2.6.21-rc5)

Quoted 14 lines · Jeff Garzik

Quoted 11 lines · Linus Torvalds
There's various fixes here, ranging from some architecture updates (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
And random one-liners.
But probably more important, and likely much more visible to most people is the fixes for the fallout from the hrtimers and no-HZ changes, and some of the ACPI regressions.
Those timer changes ended up much more painful than anybody wished for, but big thanks to Thomas Gleixner for being on it like a weasel on a dead rat, and the regression list has kept shrinking.
So if you have reported a regression in the 2.6.21-rc series, please check 2.6.21-rc5, and update your report as appropriate (whether fixed or "still problems with xyzzy").
Linus

Quoted 7 lines

[just got back from vacation, or would have sent this earlier]
FWIW, I'm still leaning towards disabling libata ACPI support by default for 2.6.21.
Upstream has Alan's fix for the worst PATA problems, but for different reasons, I think PATA ACPI and SATA ACPI support in libata does not feel quite ready for prime time in 2.6.21.
Scream now, or hold your peace until 2.6.22... :)

I second disabling ACPI for 2.6.21.

Signature · 1 line

tejun

Pavel Machek

2007-03-28 09:47 UTC #65 lore raw

Re: ATA ACPI (was Re: Linux 2.6.21-rc5)

Hi!

Quoted 11 lines

Quoted 11 lines
Quoted 4 lines
So if you have reported a regression in the 2.6.21-rc series, please check 2.6.21-rc5, and update your report as appropriate (whether fixed or "still problems with xyzzy").
[just got back from vacation, or would have sent this earlier]
FWIW, I'm still leaning towards disabling libata ACPI support by default for 2.6.21.

Quoted 8 lines

Quoted 6 lines
Upstream has Alan's fix for the worst PATA problems, but for different reasons, I think PATA ACPI and SATA ACPI support in libata does not feel quite ready for prime time in 2.6.21.
Scream now, or hold your peace until 2.6.22... :)
I second disabling ACPI for 2.6.21.

Ugh.. does that mean we'll have 'regression reports' as in 'it worked ok in -rc5, broken in final?

Well, suspend is currently so broken that we'll be flooded by reports, anyway, but.... could we get at least define in code so that we can tell users to flip it?

Or maybe it is enough to make libata dependend on EXPERIMETAL? ...making it dependend on BROKEN should be definitely enough...

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Tejun Heo

2007-03-28 09:51 UTC #66 lore raw

Re: ATA ACPI (was Re: Linux 2.6.21-rc5)

Quoted 18 lines · Pavel Machek

Hi!
Quoted 16 lines
Quoted 16 lines
Quoted 4 lines
So if you have reported a regression in the 2.6.21-rc series, please check 2.6.21-rc5, and update your report as appropriate (whether fixed or "still problems with xyzzy").
[just got back from vacation, or would have sent this earlier]
FWIW, I'm still leaning towards disabling libata ACPI support by default for 2.6.21.
Upstream has Alan's fix for the worst PATA problems, but for different reasons, I think PATA ACPI and SATA ACPI support in libata does not feel quite ready for prime time in 2.6.21.
Scream now, or hold your peace until 2.6.22... :)

Quoted 8 lines

Quoted 1 line
I second disabling ACPI for 2.6.21.
Ugh.. does that mean we'll have 'regression reports' as in 'it worked ok in -rc5, broken in final?
Well, suspend is currently so broken that we'll be flooded by reports, anyway, but.... could we get at least define in code so that we can tell users to flip it?

Just the default value for libata.noacpi is changed to 1, so user can easily reenable it by passing boot/module parameter.

Signature · 1 line

tejun

Linus Torvalds

author

2007-03-27 17:09 UTC #67 lore raw

Re: ATA ACPI (was Re: Linux 2.6.21-rc5)

In reply to Jeff Garzik

Quoted 3 lines · Jeff Garzik

FWIW, I'm still leaning towards disabling libata ACPI support by default for 2.6.21.

Hey, I'm not going to argue against anything that says "disable ACPI". Of *course* it should be disabled if there aren't thousands of machines that are in user hands that actually need it (and none that regress).

Anybody want to send me a patch?

Linus

Jeff Garzik

2007-03-27 18:48 UTC #68 lore raw

Re: ATA ACPI (was Re: Linux 2.6.21-rc5)

Quoted 6 lines · Linus Torvalds

Quoted 2 lines · Jeff Garzik
FWIW, I'm still leaning towards disabling libata ACPI support by default for 2.6.21.
Hey, I'm not going to argue against anything that says "disable ACPI". Of *course* it should be disabled if there aren't thousands of machines that are in user hands that actually need it (and none that regress).

It's required to access data at all (BIOS-supplied password [un]locks disk), in a small minority of configurations. It's strongly suggested for reliable suspend/resume, particularly on laptops, where libata ACPI support fixes some suspend/resume problems.

Some BIOSen also want to apply drive+board-specific errata workarounds.
That's OK, but ideally we should know about those in the kernel.

"none that regress" is the problem though. Buggy tables, unexercised ACPI code paths, and in a few cases unexpected post-ACPI drive/controller behavior expose regressions.

Quoted 1 line

Anybody want to send me a patch?

Since everybody is OK with my plan, I'll send one today along with the rest of the post-vacation 2.6.21-rc bug fixes.

Jeff

Andrew Morton

2007-03-27 06:17 UTC #69 lore raw

I have a few fixes here which belong to subsystem trees, which were missed by the maintainers and which we probably want to get into 2.6.21.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/make-aout-executables-work-again.patch

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/revert-ac97-fix-microphone-and-line_in-selection-logic.patch

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/drivers-mfd-sm501c-fix-an-off-by-one.patch

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/pci-set-pci=bfsort-for-poweredge-r900.patch

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/fix-sudden-warps-in-mousedev.patch

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/fix-sysfs-rom-file-creation-for-bios-rom-shadows.patch

Maintainers are cc'ed. Please promptly ack, nack or otherwise quack, else I'll be making my own decisions ;)

Greg KH

2007-03-27 06:20 UTC #70 lore raw

Quoted 6 lines · Andrew Morton

I have a few fixes here which belong to subsystem trees, which were missed by the maintainers and which we probably want to get into 2.6.21.
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/pci-set-pci=bfsort-for-poweredge-r900.patch

Already in Linus's tree.

Quoted 1 line

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/fix-sysfs-rom-file-creation-for-bios-rom-shadows.patch

I'd prefer to wait until 2.6.22 for this one, I've had too many odd reports of problems in this area, and since no one has reported this issue, it's not a real rush at all.

thanks,

greg k-h

Jesse Barnes

2007-03-27 16:49 UTC #71 lore raw

Quoted 9 lines · Greg KH

Already in Linus's tree.
Quoted 3 lines
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2 1-rc5/2.6.21-rc5-mm2/broken-out/fix-sysfs-rom-file-creation-for-bios -rom-shadows.patch
I'd prefer to wait until 2.6.22 for this one, I've had too many odd reports of problems in this area, and since no one has reported this issue, it's not a real rush at all.

Yeah, I don't think this one is critical. These files aren't in heavy use yet, so fixing this in 2.6.22 should be ok. I've only heard one complaint about this bug so far, and that was caused by some code still in development.

Jesse

Takashi Iwai

2007-03-27 09:49 UTC #72 lore raw

At Mon, 26 Mar 2007 22:17:31 -0800,

Quoted 2 lines · Andrew Morton

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/revert-ac97-fix-microphone-and-line_in-selection-logic.patch

The better fix is already in rc5, so please drop this one from your tree.

c26a8de23a4417f556250c4c099b048b26c430be [ALSA] ac97 - fix AD shared shared jack control logic

thanks,

Takashi

Andi Kleen

2007-03-27 12:25 UTC #73 lore raw

Quoted 6 lines · Andrew Morton

I have a few fixes here which belong to subsystem trees, which were missed by the maintainers and which we probably want to get into 2.6.21.
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/make-aout-executables-work-again.patch

This is already fixed in a different way.

-Andi

Andrew Morton

2007-03-27 16:33 UTC #74 lore raw

Quoted 10 lines · On Tue, 27 Mar 2007 14:25:07 +0200 Andi Kleen <[email protected]> wrote:

Quoted 6 lines · Andrew Morton
I have a few fixes here which belong to subsystem trees, which were missed by the maintainers and which we probably want to get into 2.6.21.
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/make-aout-executables-work-again.patch
This is already fixed in a different way.

oh yeah. Did that fix make it into 2.6.20.x?

I think we decided that make-aout-executables-work-again.patch might still be a desirable thing to have, but I don't recall the reasoning for that.

Anyway, if it doesn't fix a bug it is nowhere near a high-priority patch for that seething bugfest which we like to call a kernel, so I'll drop it.

Dmitry Torokhov

2007-03-27 12:43 UTC #75 lore raw

Quoted 6 lines · Andrew Morton

I have a few fixes here which belong to subsystem trees, which were missed by the maintainers and which we probably want to get into 2.6.21.
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/fix-sudden-warps-in-mousedev.patch

Slightly different fix is already in input tree. I'd perfer waiting for 2.6.22 as this only affects touchpads when not using synaptics X driver (which most distributions use by default).

Signature · 1 line

Dmitry

Tilman Schmidt

2007-03-28 22:30 UTC #76 lore raw

Am 27.03.2007 08:17 schrieb Andrew Morton:

Quoted 2 lines

I have a few fixes here which belong to subsystem trees, which were missed by the maintainers and which we probably want to get into 2.6.21.

[...]

Quoted 2 lines

Maintainers are cc'ed. Please promptly ack, nack or otherwise quack, else I'll be making my own decisions ;)

[CC list trimmed]

It's not on that list, but would you mind slipping drivers-isdn-gigaset-mark-some-static-data-as-const-v2.patch into 2.6.21 too? It's largely trivial but I'd like to get it out of the door.

Thanks,
Tilman

Signature · 4 lines

Tilman Schmidt                          E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeoeffnet mindestens haltbar bis: (siehe Rueckseite)

Michal Piotrowski

2007-03-27 18:34 UTC #77 lore raw

http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/git-config2

Hi,

Quoted 4 lines · Linus Torvalds

There's various fixes here, ranging from some architecture updates (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.

Suspend to disk doesn't work for me with this patch. It hangs after
PM: Preparing devices for restore.
Suspending console(s)
during resuming.

a504e64ab42bcc27074ea37405d06833ed6e0820 is first bad commit commit a504e64ab42bcc27074ea37405d06833ed6e0820

Author: Stephen Hemminger <[email protected]>
Date:   Fri Feb 2 08:22:53 2007 -0800

skge: WOL support

Add WOL support for Yukon chipsets in skge device.

Signed-off-by Stephen Hemminger <[email protected]>

Signed-off-by Jeff Garzik <[email protected]>

:040000 040000 d3d4335e6cba330b7880b4787fbe48733e69f8fc
5845b004228d811de912a55da6a7843b72f23f81 M drivers

Regards,
Michal

Signature · 5 lines

Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

Pavel Machek

2007-03-27 22:29 UTC #78 lore raw

Hi!

Quoted 18 lines

Quoted 3 lines
There's various fixes here, ranging from some architecture updates (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
Suspend to disk doesn't work for me with this patch. It hangs after
PM: Preparing devices for restore.
Suspending console(s)
during resuming.
a504e64ab42bcc27074ea37405d06833ed6e0820 is first bad commit commit a504e64ab42bcc27074ea37405d06833ed6e0820
Author: Stephen Hemminger <[email protected]>
Date:   Fri Feb 2 08:22:53 2007 -0800
skge: WOL support
Add WOL support for Yukon chipsets in skge device.

Quoted 7 lines

Signed-off-by Stephen Hemminger <[email protected]>
Signed-off-by Jeff Garzik <[email protected]>
:040000 040000 d3d4335e6cba330b7880b4787fbe48733e69f8fc
5845b004228d811de912a55da6a7843b72f23f81 M drivers
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/git-config2

Do you use skge as your network device?
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Michal Piotrowski

2007-03-27 22:55 UTC #79 lore raw

Pavel Machek napisał(a):

Quoted 21 lines

Hi!
Quoted 20 lines
Quoted 3 lines
There's various fixes here, ranging from some architecture updates (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
Suspend to disk doesn't work for me with this patch. It hangs after
PM: Preparing devices for restore.
Suspending console(s)
during resuming.
a504e64ab42bcc27074ea37405d06833ed6e0820 is first bad commit commit a504e64ab42bcc27074ea37405d06833ed6e0820
Author: Stephen Hemminger <[email protected]>
Date:   Fri Feb 2 08:22:53 2007 -0800
skge: WOL support
Add WOL support for Yukon chipsets in skge device.
Signed-off-by Stephen Hemminger <[email protected]>
Signed-off-by Jeff Garzik <[email protected]>

Quoted 6 lines

Quoted 4 lines
:040000 040000 d3d4335e6cba330b7880b4787fbe48733e69f8fc
5845b004228d811de912a55da6a7843b72f23f81 M drivers
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/git-config2
Do you use skge as your network device?

Yes, I have a Marvell based onboard NIC.

02:05.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12)
Subsystem: ASUSTeK Computer Inc. A7V600/P4P800/K8V motherboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (5750ns min, 7750ns max), Cache Line Size: 16 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at f7ffc000 (32-bit, non-prefetchable) [size=16K]
Region 1: I/O ports at e800 [size=256]
Capabilities: [48] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data

Quoted 1 line

Pavel

Regards,
Michal

Signature · 5 lines

Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

Michal Piotrowski

2007-03-27 18:53 UTC #80 lore raw

http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/git-config2
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/git-dmesg

Linus Torvalds napisał(a):

Quoted 5 lines

There's various fixes here, ranging from some architecture updates (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
And random one-liners.

I found this in mm snapshot
http://www.ussg.iu.edu/hypermail/linux/kernel/0703.2/1367.html
it's in mainline too.

Andi, any progress with this bug?

BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245
caller is avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<c0105039>] show_trace_log_lvl+0x1a/0x2f
 [<c0105720>] show_trace+0x12/0x14
 [<c01057d2>] dump_stack+0x16/0x18
 [<c01f911e>] debug_smp_processor_id+0xa2/0xb4
 [<c0115832>] avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<fdca69b5>] nmi_create_files+0x2a/0x10e [oprofile]
 [<fdca5f4e>] oprofile_create_files+0xe6/0xec [oprofile]
 [<fdca6153>] oprofilefs_fill_super+0x78/0x7e [oprofile]
 [<c0173516>] get_sb_single+0x46/0x8c
 [<fdca608b>] oprofilefs_get_sb+0x1c/0x1e [oprofile]
 [<c0173406>] vfs_kern_mount+0x81/0xf1
 [<c01734be>] do_kern_mount+0x30/0x42
 [<c0185be9>] do_mount+0x601/0x678
 [<c0185ccf>] sys_mount+0x6f/0xa4
 [<c0104060>] syscall_call+0x7/0xb
 =======================
BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245
caller is avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<c0105039>] show_trace_log_lvl+0x1a/0x2f
 [<c0105720>] show_trace+0x12/0x14
 [<c01057d2>] dump_stack+0x16/0x18
 [<c01f911e>] debug_smp_processor_id+0xa2/0xb4
 [<c0115832>] avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<fdca69b5>] nmi_create_files+0x2a/0x10e [oprofile]
 [<fdca5f4e>] oprofile_create_files+0xe6/0xec [oprofile]
 [<fdca6153>] oprofilefs_fill_super+0x78/0x7e [oprofile]
 [<c0173516>] get_sb_single+0x46/0x8c
 [<fdca608b>] oprofilefs_get_sb+0x1c/0x1e [oprofile]
 [<c0173406>] vfs_kern_mount+0x81/0xf1
 [<c01734be>] do_kern_mount+0x30/0x42
 [<c0185be9>] do_mount+0x601/0x678
 [<c0185ccf>] sys_mount+0x6f/0xa4
 [<c0104060>] syscall_call+0x7/0xb
 =======================
BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245
caller is avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<c0105039>] show_trace_log_lvl+0x1a/0x2f
 [<c0105720>] show_trace+0x12/0x14
 [<c01057d2>] dump_stack+0x16/0x18
 [<c01f911e>] debug_smp_processor_id+0xa2/0xb4
 [<c0115832>] avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<fdca69b5>] nmi_create_files+0x2a/0x10e [oprofile]
 [<fdca5f4e>] oprofile_create_files+0xe6/0xec [oprofile]
 [<fdca6153>] oprofilefs_fill_super+0x78/0x7e [oprofile]
 [<c0173516>] get_sb_single+0x46/0x8c
 [<fdca608b>] oprofilefs_get_sb+0x1c/0x1e [oprofile]
 [<c0173406>] vfs_kern_mount+0x81/0xf1
 [<c01734be>] do_kern_mount+0x30/0x42
 [<c0185be9>] do_mount+0x601/0x678
 [<c0185ccf>] sys_mount+0x6f/0xa4
 [<c0104060>] syscall_call+0x7/0xb
 =======================
BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245
caller is avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<c0105039>] show_trace_log_lvl+0x1a/0x2f
 [<c0105720>] show_trace+0x12/0x14
 [<c01057d2>] dump_stack+0x16/0x18
 [<c01f911e>] debug_smp_processor_id+0xa2/0xb4
 [<c0115832>] avail_to_resrv_perfctr_nmi_bit+0x1a/0x32
 [<fdca69b5>] nmi_create_files+0x2a/0x10e [oprofile]
 [<fdca5f4e>] oprofile_create_files+0xe6/0xec [oprofile]
 [<fdca6153>] oprofilefs_fill_super+0x78/0x7e [oprofile]
 [<c0173516>] get_sb_single+0x46/0x8c
 [<fdca608b>] oprofilefs_get_sb+0x1c/0x1e [oprofile]
 [<c0173406>] vfs_kern_mount+0x81/0xf1
 [<c01734be>] do_kern_mount+0x30/0x42
 [<c0185be9>] do_mount+0x601/0x678
 [<c0185ccf>] sys_mount+0x6f/0xa4
 [<c0104060>] syscall_call+0x7/0xb
 =======================

SELinux: initialized (dev oprofilefs, type oprofilefs), uses genfs_contexts

=================================
[ INFO: inconsistent lock state ]
2.6.21-rc5-gd4590940-dirty #128
---------------------------------
inconsistent {hardirq-on-W} -> {in-hardirq-W} usage. firefox-bin/3542 [HC1[1]:SC0[0]:HE0:SE1] takes:
(oprofilefs_lock){+-..}, at: [<fdca6b6a>] nmi_cpu_setup+0x15/0x4f [oprofile]
{hardirq-on-W} state was registered at:

  [<c013d338>] __lock_acquire+0x442/0xba1
  [<c013daff>] lock_acquire+0x68/0x82
  [<c031a947>] _spin_lock+0x35/0x42
  [<fdca6343>] oprofilefs_ulong_from_user+0x4e/0x74 [oprofile]
  [<fdca6393>] ulong_write_file+0x2a/0x38 [oprofile]
  [<c0171d13>] vfs_write+0xaf/0x138
  [<c01722dd>] sys_write+0x3d/0x61
  [<c0104060>] syscall_call+0x7/0xb
  [<ffffffff>] 0xffffffff
irq event stamp: 50464270
hardirqs last  enabled at (50464269): [<c0104189>] syscall_exit_work+0x11/0x26
hardirqs last disabled at (50464270): [<c0104ae9>] call_function_interrupt+0x29/0x38
softirqs last  enabled at (50462522): [<c012653b>] __do_softirq+0xe4/0xea
softirqs last disabled at (50462515): [<c01069b5>] do_softirq+0x64/0xd1

other info that might help us debug this:
no locks held by firefox-bin/3542.

stack backtrace:
 [<c0105039>] show_trace_log_lvl+0x1a/0x2f
 [<c0105720>] show_trace+0x12/0x14
 [<c01057d2>] dump_stack+0x16/0x18
 [<c013bd13>] print_usage_bug+0x140/0x14a
 [<c013c51e>] mark_lock+0xa1/0x40b
 [<c013d2a9>] __lock_acquire+0x3b3/0xba1
 [<c013daff>] lock_acquire+0x68/0x82
 [<c031a947>] _spin_lock+0x35/0x42
 [<fdca6b6a>] nmi_cpu_setup+0x15/0x4f [oprofile]
 [<c0112a61>] smp_call_function_interrupt+0x3a/0x56
 [<c0104af3>] call_function_interrupt+0x33/0x38
 =======================

Regards,
Michal

Signature · 5 lines

Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

Andi Kleen

2007-03-28 14:31 UTC #81 lore raw

Quoted 4 lines · Michal Piotrowski

Linus Torvalds napisał(a):
Quoted 3 lines
There's various fixes here, ranging from some architecture updates (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.

Quoted 8 lines

Quoted 2 lines
And random one-liners.
I found this in mm snapshot
http://www.ussg.iu.edu/hypermail/linux/kernel/0703.2/1367.html
it's in mainline too.
Andi, any progress with this bug?

Can you test this patch please?

-Andi

i386/x86-64: Convert nmi reservation to be global

It doesn't make much sense to have this per CPU, because all the services using NMIs run on all CPUs. So make it global.

This also fixes a warning about unprotected use of smp_processor_id on preemptible kernels.

Signed-off-by Andi Kleen <[email protected]>

arch/i386/kernel/nmi.c +8 -8

Index: linux/arch/i386/kernel/nmi.c
===================================================================
@@ -41,8 +41,8 @@ int nmi_watchdog_enabled;
  *   different subsystems this reservation system just tries to coordinate
  *   things a little
  */
-static DEFINE_PER_CPU(unsigned long, perfctr_nmi_owner);
-static DEFINE_PER_CPU(unsigned long, evntsel_nmi_owner[3]);
+static unsigned long perfctr_nmi_owner;
+static unsigned long evntsel_nmi_owner[3];
 
 static cpumask_t backtrace_mask = CPU_MASK_NONE;

@@ -124,7 +124,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsig
 {
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	return (!test_bit(counter, &__get_cpu_var(perfctr_nmi_owner)));
+	return (!test_bit(counter, &perfctr_nmi_owner));
 }
 
 /* checks the an msr for availability */

@@ -135,7 +135,7 @@ int avail_to_resrv_perfctr_nmi(unsigned 
 	counter = nmi_perfctr_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	return (!test_bit(counter, &__get_cpu_var(perfctr_nmi_owner)));
+	return (!test_bit(counter, &perfctr_nmi_owner));
 }
 
 int reserve_perfctr_nmi(unsigned int msr)

@@ -145,7 +145,7 @@ int reserve_perfctr_nmi(unsigned int msr
 	counter = nmi_perfctr_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	if (!test_and_set_bit(counter, &__get_cpu_var(perfctr_nmi_owner)))
+	if (!test_and_set_bit(counter, &perfctr_nmi_owner))
 		return 1;
 	return 0;
 }

@@ -157,7 +157,7 @@ void release_perfctr_nmi(unsigned int ms
 	counter = nmi_perfctr_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	clear_bit(counter, &__get_cpu_var(perfctr_nmi_owner));
+	clear_bit(counter, &perfctr_nmi_owner);
 }
 
 int reserve_evntsel_nmi(unsigned int msr)

@@ -167,7 +167,7 @@ int reserve_evntsel_nmi(unsigned int msr
 	counter = nmi_evntsel_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	if (!test_and_set_bit(counter, &__get_cpu_var(evntsel_nmi_owner)[0]))
+	if (!test_and_set_bit(counter, &evntsel_nmi_owner[0]))
 		return 1;
 	return 0;
 }

@@ -179,7 +179,7 @@ void release_evntsel_nmi(unsigned int ms
 	counter = nmi_evntsel_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	clear_bit(counter, &__get_cpu_var(evntsel_nmi_owner)[0]);
+	clear_bit(counter, &evntsel_nmi_owner[0]);
 }
 
 static __cpuinit inline int nmi_known_cpu(void)

arch/x86_64/kernel/nmi.c +8 -8

Index: linux/arch/x86_64/kernel/nmi.c
===================================================================
@@ -39,8 +39,8 @@ int panic_on_unrecovered_nmi;
  *   different subsystems this reservation system just tries to coordinate
  *   things a little
  */
-static DEFINE_PER_CPU(unsigned, perfctr_nmi_owner);
-static DEFINE_PER_CPU(unsigned, evntsel_nmi_owner[2]);
+static unsigned perfctr_nmi_owner;
+static unsigned evntsel_nmi_owner[2];
 
 static cpumask_t backtrace_mask = CPU_MASK_NONE;

@@ -110,7 +110,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsig
 {
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	return (!test_bit(counter, &__get_cpu_var(perfctr_nmi_owner)));
+	return (!test_bit(counter, &perfctr_nmi_owner));
 }
 
 /* checks the an msr for availability */

@@ -121,7 +121,7 @@ int avail_to_resrv_perfctr_nmi(unsigned 
 	counter = nmi_perfctr_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	return (!test_bit(counter, &__get_cpu_var(perfctr_nmi_owner)));
+	return (!test_bit(counter, &perfctr_nmi_owner));
 }
 
 int reserve_perfctr_nmi(unsigned int msr)

@@ -131,7 +131,7 @@ int reserve_perfctr_nmi(unsigned int msr
 	counter = nmi_perfctr_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	if (!test_and_set_bit(counter, &__get_cpu_var(perfctr_nmi_owner)))
+	if (!test_and_set_bit(counter, &perfctr_nmi_owner))
 		return 1;
 	return 0;
 }

@@ -143,7 +143,7 @@ void release_perfctr_nmi(unsigned int ms
 	counter = nmi_perfctr_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	clear_bit(counter, &__get_cpu_var(perfctr_nmi_owner));
+	clear_bit(counter, &perfctr_nmi_owner);
 }
 
 int reserve_evntsel_nmi(unsigned int msr)

@@ -153,7 +153,7 @@ int reserve_evntsel_nmi(unsigned int msr
 	counter = nmi_evntsel_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	if (!test_and_set_bit(counter, &__get_cpu_var(evntsel_nmi_owner)))
+	if (!test_and_set_bit(counter, &evntsel_nmi_owner))
 		return 1;
 	return 0;
 }

@@ -165,7 +165,7 @@ void release_evntsel_nmi(unsigned int ms
 	counter = nmi_evntsel_msr_to_bit(msr);
 	BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-	clear_bit(counter, &__get_cpu_var(evntsel_nmi_owner));
+	clear_bit(counter, &evntsel_nmi_owner);
 }
 
 static __cpuinit inline int nmi_known_cpu(void)

Michal Piotrowski

2007-03-28 14:56 UTC #82 lore raw

Andi Kleen napisał(a):

Quoted 7 lines · Michal Piotrowski

Quoted 6 lines
Linus Torvalds napisał(a):
Quoted 5 lines
There's various fixes here, ranging from some architecture updates (ia64, ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
And random one-liners.

Quoted 8 lines

Quoted 5 lines
I found this in mm snapshot
http://www.ussg.iu.edu/hypermail/linux/kernel/0703.2/1367.html
it's in mainline too.
Andi, any progress with this bug?
Can you test this patch please?

BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245

is fixed, thanks.

but I still get this

[  208.523901] =================================
[  208.529739] [ INFO: inconsistent lock state ]
[  208.534087] 2.6.21-rc5-g28defbea-dirty #131
[  208.538260] ---------------------------------
[  208.542611] inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
[  208.548600] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[  208.553553]  (oprofilefs_lock){+-..}, at: [<fdc85b6a>] nmi_cpu_setup+0x15/0x4f [oprofile]
[  208.561800] {hardirq-on-W} state was registered at:
[  208.566665]   [<c013dba4>] __lock_acquire+0x442/0xba1
[  208.571765]   [<c013e36b>] lock_acquire+0x68/0x82
[  208.576519]   [<c031bb37>] _spin_lock+0x35/0x42
[  208.581102]   [<fdc85343>] oprofilefs_ulong_from_user+0x4e/0x74 [oprofile]
[  208.588026]   [<fdc85393>] ulong_write_file+0x2a/0x38 [oprofile]
[  208.594084]   [<c0172693>] vfs_write+0xaf/0x138
[  208.598658]   [<c0172c5d>] sys_write+0x3d/0x61
[  208.603171]   [<c0104060>] syscall_call+0x7/0xb
[  208.607751]   [<ffffffff>] 0xffffffff
[  208.611478] irq event stamp: 575782
[  208.614960] hardirqs last  enabled at (575781): [<c0102ac2>] default_idle+0x3e/0x59
[  208.622645] hardirqs last disabled at (575782): [<c0104ae9>] call_function_interrupt+0x29/0x38
[  208.631281] softirqs last  enabled at (575768): [<c0126537>] __do_softirq+0xe4/0xea
[  208.638965] softirqs last disabled at (575759): [<c01069b5>] do_softirq+0x64/0xd1
[  208.646478]
[  208.646479] other info that might help us debug this:
[  208.653003] no locks held by swapper/0.
[  208.656832]
[  208.656833] stack backtrace:
[  208.661199]  [<c0105039>] show_trace_log_lvl+0x1a/0x2f
[  208.666350]  [<c0105720>] show_trace+0x12/0x14
[  208.670811]  [<c01057d2>] dump_stack+0x16/0x18
[  208.675272]  [<c013c57f>] print_usage_bug+0x140/0x14a
[  208.680336]  [<c013cd8a>] mark_lock+0xa1/0x40b
[  208.684796]  [<c013db15>] __lock_acquire+0x3b3/0xba1
[  208.689775]  [<c013e36b>] lock_acquire+0x68/0x82
[  208.694410]  [<c031bb37>] _spin_lock+0x35/0x42
[  208.698869]  [<fdc85b6a>] nmi_cpu_setup+0x15/0x4f [oprofile]
[  208.704540]  [<c0112a61>] smp_call_function_interrupt+0x3a/0x56
[  208.710470]  [<c0104af3>] call_function_interrupt+0x33/0x38
[  208.716053]  [<c01023b8>] cpu_idle+0xb6/0xeb
[  208.720342]  [<c0113bb0>] start_secondary+0x333/0x33b
[  208.725407]  [<00000000>] 0x0
[  208.728397]  =======================

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

Jiri Kosina

2007-03-28 16:13 UTC #83 lore raw

Quoted 9 lines · Michal Piotrowski

BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245 
is fixed, thanks.
but I still get this
[  208.523901] =================================
[  208.529739] [ INFO: inconsistent lock state ]
[  208.534087] 2.6.21-rc5-g28defbea-dirty #131
[  208.538260] ---------------------------------
[  208.542611] inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
[  208.548600] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:

Perhaps something like the one below?

From: Jiri Kosina <[email protected]>

oprofile: fix potential deadlock on oprofilefs_lock

nmi_cpu_setup() is called from hardirq context and acquires oprofilefs_lock. alloc_event_buffer() and oprofilefs_ulong_from_user() acquire this lock without disabling irqs, which could deadlock.

Signed-off-by Jiri Kosina <[email protected]>

 drivers/oprofile/event_buffer.c |    5 +++--
 drivers/oprofile/oprofilefs.c   |    5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

drivers/oprofile/event_buffer.c +3 -2

index 00e937e..e7fbac5 100644
@@ -70,11 +70,12 @@ void wake_up_buffer_waiter(void)
 int alloc_event_buffer(void)
 {
 	int err = -ENOMEM;
+	unsigned long flags;
 
-	spin_lock(&oprofilefs_lock);
+	spin_lock_irqsave(&oprofilefs_lock, flags);
 	buffer_size = fs_buffer_size;
 	buffer_watershed = fs_buffer_watershed;
-	spin_unlock(&oprofilefs_lock);
+	spin_unlock_irqrestore(&oprofilefs_lock, flags);
  
 	if (buffer_watershed >= buffer_size)
 		return -EINVAL;

drivers/oprofile/oprofilefs.c +3 -2

index 6e67b42..8543cb2 100644
@@ -65,6 +65,7 @@ ssize_t oprofilefs_ulong_to_user(unsigned long val, char __user * buf, size_t co
 int oprofilefs_ulong_from_user(unsigned long * val, char const __user * buf, size_t count)
 {
 	char tmpbuf[TMPBUFSIZE];
+	unsigned long flags;
 
 	if (!count)
 		return 0;

@@ -77,9 +78,9 @@ int oprofilefs_ulong_from_user(unsigned long * val, char const __user * buf, siz
 	if (copy_from_user(tmpbuf, buf, count))
 		return -EFAULT;
 
-	spin_lock(&oprofilefs_lock);
+	spin_lock_irqsave(&oprofilefs_lock, flags);
 	*val = simple_strtoul(tmpbuf, NULL, 0);
-	spin_unlock(&oprofilefs_lock);
+	spin_unlock_irqrestore(&oprofilefs_lock, flags);
 	return 0;
 }

Michal Piotrowski

2007-03-28 16:52 UTC #84 lore raw

Quoted 12 lines · Jiri Kosina

Quoted 9 lines · Michal Piotrowski

BUG: using smp_processor_id() in preemptible [00000001] code: mount/7245
is fixed, thanks.
but I still get this
[  208.523901] =================================
[  208.529739] [ INFO: inconsistent lock state ]
[  208.534087] 2.6.21-rc5-g28defbea-dirty #131
[  208.538260] ---------------------------------
[  208.542611] inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
[  208.548600] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:

Quoted 2 lines

Perhaps something like the one below?

Problem seems to be fixed. Thanks!

Regards,
Michal

Signature · 5 lines

Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

Linus Torvalds

author

2007-03-28 17:56 UTC #85 lore raw

In reply to Andi Kleen

Quoted 2 lines · Andi Kleen

Can you test this patch please?

This patch is totally broken.

Quoted 4 lines

i386/x86-64: Convert nmi reservation to be global
It doesn't make much sense to have this per CPU, because all the services using NMIs run on all CPUs. So make it global.

NO!

If you do this, then you must make all *callers* be global too. But they aren't. Right now all callers do per-CPU setup!

See for example enable_lapic_nmi_watchdog():

	on_each_cpu(setup_apic_nmi_watchdog, NULL, 0, 1);

where "setup_apic_nmi_watchdog()" will call "setup_k7_watchdog()", which in turn will do a per-CPU reservation of the perfctl for the watchdog.

So I agree in that it probably doesn't make sense to have NMI/perfctl reservation per-CPU, but you can't just change the reservation and ignore all the *users* of that reservation that assumed that it was per-CPU.

Is that code insane? Probably. But it probably also works. After your patch, one CPU will be able to reserve the NMI/perfctl thing (fine so far) but then all the other CPU's that try to do it will fail.

Linus

A message that is not in the archive (sent off-list or not yet received): [email protected]

Rafael J. Wysocki

2007-03-27 23:07 UTC #87 lore raw

Re: 2.6.21-rc5: known regressions with patches

Quoted 13 lines · Adrian Bunk

This email lists some known regressions in Linus' tree compared to 2.6.20 with patches available.
If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : suspend to disk hangs (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter : Maxim Levitsky <[email protected]>

Quoted 7 lines

Caused-By Rafael J. Wysocki <[email protected]>
             commit e3c7db621bed4afb8e231cb005057f2feb5db557
             commit ed746e3b18f4df18afa3763155972c5835f284c5
             commit 259130526c267550bc365d3015917d90667732f1
Handled-By Rafael J. Wysocki <[email protected]>
Patch : http://lkml.org/lkml/2007/3/23/179
Status : patch available

Updated patch is available at http://lkml.org/lkml/2007/3/25/71

Greetings,
Rafael

Jay Cliburn

2007-03-28 00:51 UTC #88 lore raw

Re: 2.6.21-rc5: known regressions with patches

In reply to a message not in the archive

Quoted 5 lines · On Wed, 28 Mar 2007 01:00:24 +0200 Adrian Bunk <[email protected]> wrote:

Subject : atl1 net driver: problem with sockets
References : http://lkml.org/lkml/2007/3/21/248
Submitter : Jose Alberto Reguero <[email protected]>
Patch : http://marc.info/?l=linux-netdev&m=117502041808665&w=2
Status : patch available

Patch submitted to netdev. http://lkml.org/lkml/2007/3/27/321

Best,
Jay

Adrian Bunk

2007-03-30 21:32 UTC #89 lore raw

PATCH 1/4 2.6.21-rc5: known regressions (v2)

This email lists some known regressions in Linus' tree compared to 2.6.20.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : crashes in KDE
References : http://bugzilla.kernel.org/show_bug.cgi?id=8157
Submitter : Oliver Pinter <[email protected]>
Status : unknown

Subject : hung bootup in various drivers
References : http://lkml.org/lkml/2007/3/30/68
Submitter : Ingo Molnar <[email protected]>

Handled-By Ingo Molnar <[email protected]>

Greg KH <[email protected]>
Kay Sievers <[email protected]>
Status : problem is being discussed

Subject : kernels fail to boot with drives on ATIIXP controller
(ACPI/IRQ related)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621

             http://lkml.org/lkml/2007/3/4/257

Submitter : Michal Jaegermann <[email protected]>
Status : unknown

Subject : NCQ problem with ahci and Hitachi drive
References : http://lkml.org/lkml/2007/3/4/178

             http://lkml.org/lkml/2007/3/9/475
             http://lkml.org/lkml/2007/2/22/8

Submitter : Mathieu Bérard <[email protected]>

Patch : http://lkml.org/lkml/2007/2/22/8
Status : possible patch available

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

Greg KH

2007-03-30 21:38 UTC #90 lore raw

Re: [1/4] 2.6.21-rc5: known regressions (v2)

Quoted 7 lines · Adrian Bunk

Subject : hung bootup in various drivers
References : http://lkml.org/lkml/2007/3/30/68
Submitter : Ingo Molnar <[email protected]>
Handled-By Ingo Molnar <[email protected]>
Greg KH <[email protected]>
Kay Sievers <[email protected]>
Status : problem is being discussed

Note, this should probably read:
hung bootup for drivers built into the kernel, that fail their module_init() call.

A much smaller minority of cases :)

thanks,

greg k-h

Michal Jaegermann

2007-03-31 00:23 UTC #91 lore raw

Re: [1/4] 2.6.21-rc5: known regressions (v2)

Quoted 7 lines · Adrian Bunk

Subject : kernels fail to boot with drives on ATIIXP controller
(ACPI/IRQ related)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
             http://lkml.org/lkml/2007/3/4/257
Submitter : Michal Jaegermann <[email protected]>
Status : unknown

I have now even better one with pata_via. A kernel, which for all practical purposes is 2.6.21-rc5, not only refuses to boot (and I cannot find some option combination which would allow me to do so anyway) but simply refuses to read _any_ data from a media. This included a partitioning information.

Earlier kernel on the same hardware boots without raising any fuss.

Details are collected as
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234650

Michal

Adrian Bunk

2007-03-31 15:01 UTC #92 lore raw

Re: [1/4] 2.6.21-rc5: known regressions (v2)

Quoted 15 lines · Michal Jaegermann

Quoted 7 lines · Adrian Bunk
Subject : kernels fail to boot with drives on ATIIXP controller
(ACPI/IRQ related)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
             http://lkml.org/lkml/2007/3/4/257
Submitter : Michal Jaegermann <[email protected]>
Status : unknown
I have now even better one with pata_via. A kernel, which for all practical purposes is 2.6.21-rc5, not only refuses to boot (and I cannot find some option combination which would allow me to do so anyway) but simply refuses to read _any_ data from a media. This included a partitioning information.

Quoted 4 lines

Earlier kernel on the same hardware boots without raising any fuss.
Details are collected as
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234650

If I understand this correctly, a plain 2.6.20 kernel is already broken?

Quoted 1 line

Michal

cu
Adrian

Signature · 4 lines

       "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

Michal Jaegermann

2007-03-31 16:42 UTC #93 lore raw

Re: [1/4] 2.6.21-rc5: known regressions (v2)

Quoted 16 lines · Adrian Bunk

Quoted 15 lines · Michal Jaegermann
Quoted 7 lines · Adrian Bunk
Subject : kernels fail to boot with drives on ATIIXP controller
(ACPI/IRQ related)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621
             http://lkml.org/lkml/2007/3/4/257
Submitter : Michal Jaegermann <[email protected]>
Status : unknown
I have now even better one with pata_via. A kernel, which for all practical purposes is 2.6.21-rc5, not only refuses to boot (and I cannot find some option combination which would allow me to do so anyway) but simply refuses to read _any_ data from a media. This included a partitioning information.

Quoted 6 lines

Quoted 4 lines
Earlier kernel on the same hardware boots without raising any fuss.
Details are collected as
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234650
If I understand this correctly, a plain 2.6.20 kernel is already broken?

You mean that a quoted report talks about 2.6.20-1.3025.fc7 kernel? These are vagaries of kernel version numbering in Fedora. Changelogs are not that clear but it appears that 2.6.19-1.2911.6.4.fc6 will be actually closer to 2.6.20. That kernel from a bug report is really, for all intents and purposes, 2.6.21-rc5 (if I am not misreading something).

I am afraid that I do not have at this moment an easy to way to check "plain" 2.6.20 on the hardware in question. It appears that the essential difference is that a working kernel is using and old IDE driver, and sees the drive - in this case - as /dev/hdc, while the current one tries to go through libata and chockes uncontrollably.

Michal

Adrian Bunk

2007-03-30 21:32 UTC #94 lore raw

PATCH 2/4 2.6.21-rc5: known regressions (v2)

This email lists some known regressions in Linus' tree compared to 2.6.20.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : snd_hda_intel doesn't work with ASUS M2V mainboard
References : http://bugzilla.kernel.org/show_bug.cgi?id=8273
Submitter : Hans-Georg Rist <[email protected]>
Status : unknown

Subject : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter : Michal Piotrowski <[email protected]>
Status : unknown

Subject : hal daemon crashes after pulling a USB serial device
References : http://www.opensubscriber.com/message/[email protected]/6369800.html
Submitter : Andi Kleen <[email protected]>

Handled-By Oliver Neukum <[email protected]>

Status : problem is being debugged

Subject : USB: iPod doesn't work (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2007/3/21/320
Submitter : Tino Keitel <[email protected]>

Caused-By Marcelo Tosatti <[email protected]>

             commit 1d619f128ba911cd3e6d6ad3475f146eb92f5c27

Handled-By Oliver Neukum <[email protected]>

Status : problem is being debuggged

Subject : USB: Oops when changing DVB-T adapter
References : http://lkml.org/lkml/2007/3/9/212
Submitter : CIJOML <[email protected]>
Status : unknown

Subject : forcedeth: sporadic under-load crashes
References : http://lkml.org/lkml/2007/3/26/63
Submitter : Ingo Molnar <[email protected]>

Handled-By Ingo Molnar <[email protected]>

Ayaz Abdulla <[email protected]>
Status : problem is being debugged

Adrian Bunk

2007-03-30 21:32 UTC #95 lore raw

PATCH 3/4 2.6.21-rc5: known regressions (v2)

This email lists some known regressions in Linus' tree compared to 2.6.20.

Due to the huge amount of recipients, please trim the Cc when answering.

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]>
Status : problem is being debugged

Subject : Suspend to RAM doesn't work anymore (ACPI?)
References : http://lkml.org/lkml/2007/3/19/128

             http://bugzilla.kernel.org/show_bug.cgi?id=8247

Submitter : Tobias Doerffel <[email protected]>

Len Brown <[email protected]>
Status : problem is being debugged

Subject : SATA breakage on resume
References : http://lkml.org/lkml/2007/3/7/233
Submitter : Thomas Gleixner <[email protected]>
Soeren Sonnenburg <[email protected]>
Status : unknown

Subject : resume from RAM corrupts vesafb console
References : http://lkml.org/lkml/2007/3/26/76
Submitter : Marcus Better <[email protected]>

Handled-By Pavel Machek <[email protected]>

Status : problem is being debugged

Subject : ThinkPad doesn't resume from suspend to RAM
References : http://lkml.org/lkml/2007/2/27/80

             http://lkml.org/lkml/2007/2/28/348

Submitter : Jens Axboe <[email protected]>
Jeff Chua <[email protected]>
Status : unknown

Subject : MacBook Core Duo: suspend to memory wakeup hang
References : http://bugzilla.kernel.org/show_bug.cgi?id=8272
Submitter : Mike Harris <[email protected]>
Status : unknown

Subject : suspend to disk hangs (skge)
References : http://lkml.org/lkml/2007/3/27/212
Submitter : Michal Piotrowski <[email protected]>

Caused-By Stephen Hemminger <[email protected]>

             commit a504e64ab42bcc27074ea37405d06833ed6e0820

Status : unknown

Subject : suspend to disk hangs (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter : Maxim Levitsky <[email protected]>

Caused-By Rafael J. Wysocki <[email protected]>

             commit e3c7db621bed4afb8e231cb005057f2feb5db557
             commit ed746e3b18f4df18afa3763155972c5835f284c5
             commit 259130526c267550bc365d3015917d90667732f1

Patch : http://lkml.org/lkml/2007/3/25/71
Status : patch available

Jeff Chua

2007-03-31 02:52 UTC #96 lore raw

Re: [3/4] 2.6.21-rc5: known regressions (v2)

Quoted 6 lines · Adrian Bunk

Subject : ThinkPad doesn't resume from suspend to RAM
References : http://lkml.org/lkml/2007/2/27/80
             http://lkml.org/lkml/2007/2/28/348
Submitter : Jens Axboe <[email protected]>
Jeff Chua <[email protected]>
Status : unknown

Fixed with CONFIG_NO_HZ unset and patch from Maxim
(http://lkml.org/lkml/2007/3/29/108).

Thanks,
Jeff,

Adrian Bunk

2007-03-31 03:16 UTC #97 lore raw

Re: [3/4] 2.6.21-rc5: known regressions (v2)

Quoted 11 lines · Jeff Chua

Quoted 6 lines · Adrian Bunk
Subject : ThinkPad doesn't resume from suspend to RAM
References : http://lkml.org/lkml/2007/2/27/80
            http://lkml.org/lkml/2007/2/28/348
Submitter : Jens Axboe <[email protected]>
Jeff Chua <[email protected]>
Status : unknown
Fixed with CONFIG_NO_HZ unset and patch from Maxim
(http://lkml.org/lkml/2007/3/29/108).

Thanks for this information.

Jens, does suspend to RAM also work for you with the latest -git?

Quoted 2 lines

Thanks,
Jeff,

cu
Adrian

Signature · 4 lines

       "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

Jens Axboe

2007-03-31 11:08 UTC #98 lore raw

Re: [3/4] 2.6.21-rc5: known regressions (v2)

Quoted 10 lines · Adrian Bunk

Quoted 9 lines · Jeff Chua
Quoted 6 lines · Adrian Bunk
Subject : ThinkPad doesn't resume from suspend to RAM
References : http://lkml.org/lkml/2007/2/27/80
            http://lkml.org/lkml/2007/2/28/348
Submitter : Jens Axboe <[email protected]>
Jeff Chua <[email protected]>
Status : unknown

Quoted 6 lines

Quoted 2 lines
Fixed with CONFIG_NO_HZ unset and patch from Maxim
(http://lkml.org/lkml/2007/3/29/108).
Thanks for this information.
Jens, does suspend to RAM also work for you with the latest -git?

Yep, it does, no problems since the last -rc.

Signature · 1 line

Jens Axboe

Jeremy Fitzhardinge

2007-04-01 05:39 UTC #99 lore raw

Re: [3/4] 2.6.21-rc5: known regressions (v2)

Quoted 10 lines · Adrian Bunk

Subject : ThinkPad X60: resume no longer works (PCI related?)
References : http://lkml.org/lkml/2007/3/13/3
Submitter : Dave Jones <[email protected]>
Jeremy Fitzhardinge <[email protected]>
Caused-By : PCI merge
             commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By Eric W. Biederman <[email protected]>
Rafael J. Wysocki <[email protected]>
Status : problem is being debugged

I know this is currently a subject of discussion on lkml, but I wanted to confirm that booting with "hpet=disable" fixes this, and resume works for me. It ends up using acpi_pm as the clocksource.

Michal Piotrowski

2007-04-13 16:32 UTC #100 lore raw

Re: [3/4] 2.6.21-rc5: known regressions (v2)

Quoted 6 lines · Adrian Bunk

Subject : suspend to disk hangs (skge)
References : http://lkml.org/lkml/2007/3/27/212
Submitter : Michal Piotrowski <[email protected]>
Caused-By Stephen Hemminger <[email protected]>
             commit a504e64ab42bcc27074ea37405d06833ed6e0820
Status : unknown

This problem is fixed in 2.6.21-rc6-git5 (commit
692412b31ffb5df00197ea591dd635fc07506c02).

Huge thanks to Stephen.

Regards,
Michal

Signature · 5 lines

Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

Adrian Bunk

2007-03-30 21:49 UTC #101 lore raw

PATCH 4/4 2.6.21-rc5: known regressions (v2)

[ this time with a Cc... ]

This email lists some known regressions in Linus' tree compared to 2.6.20.

Due to the huge amount of recipients, please trim the Cc when answering.

Caused-By Thomas Gleixner <[email protected]>

             commit e9e2cdb412412326c4827fc78ba27f410d837e6e

Status : unknown

Subject : after resume: X hangs after drawing a couple of windows
workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/8/117

             http://lkml.org/lkml/2007/3/25/20
             http://lkml.org/lkml/2007/3/26/151

Submitter : Michael S. Tsirkin <[email protected]>

Status : problem is being debugged

Subject : system doesn't come out of suspend (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <[email protected]>
Soeren Sonnenburg <[email protected]>

Ingo Molnar <[email protected]>
Tejun Heo <[email protected]>
Rafael J. Wysocki <[email protected]>
Status : unknown

Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <[email protected]>
Status : unknown

Jeff Chua

2007-03-31 02:41 UTC #102 lore raw

Re: [4/4] 2.6.21-rc5: known regressions (v2)

Quoted 4 lines · Adrian Bunk

Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <[email protected]>
Status : unknown

Still broken on.2.6.21-rc5.

Jeff.

Frédéric Riss

2007-03-31 06:44 UTC #103 lore raw

Re: [4/4] 2.6.21-rc5: known regressions (v2)

Quoted 8 lines · Adrian Bunk

Subject : MacMini doesn't come out of suspend to ram (i386 clockevents)
(CONFIG_HPET_TIMER)
References : http://lkml.org/lkml/2007/3/21/374
Submitter : Frédéric Riss <[email protected]>
Tino Keitel <[email protected]>
Caused-By Thomas Gleixner <[email protected]>
             commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Status : unknown

This one has been fixed by 399afa4fc9238fbae42116cf25a54671c0e8f56e. Suspend to ram now works with HPET enabled (and regardless of the NO_HZ setting).

Thanks!

Fred.

Michael S. Tsirkin

2007-04-01 07:04 UTC #104 lore raw

Re: [4/4] 2.6.21-rc5: known regressions (v2)

Quoted 8 lines

Subject : after resume: X hangs after drawing a couple of windows
workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/8/117
             http://lkml.org/lkml/2007/3/25/20
             http://lkml.org/lkml/2007/3/26/151
Submitter : Michael S. Tsirkin <[email protected]>
Handled-By Thomas Gleixner <[email protected]>
Status : problem is being debugged

Adrian,
the bug was found by Maxim Levitsky and
the following patch appears to have fixed the problem:
http://lkml.org/lkml/2007/3/28/104

the right way to fix it is still being discussed:
http://lkml.org/lkml/2007/3/28/182

Signature · 1 line

MST

Michael S. Tsirkin

2007-04-01 20:37 UTC #105 lore raw

Re: [4/4] 2.6.21-rc5: known regressions (v2)

Quoted 8 lines

Subject : after resume: X hangs after drawing a couple of windows
workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/8/117
             http://lkml.org/lkml/2007/3/25/20
             http://lkml.org/lkml/2007/3/26/151
Submitter : Michael S. Tsirkin <[email protected]>
Handled-By Thomas Gleixner <[email protected]>
Status : problem is being debugged

Seems to be resolved with 399afa4fc9238fbae42116cf25a54671c0e8f56e. Thanks Maxim!

Signature · 1 line

MST

Adrian Bunk

2007-03-31 18:19 UTC #106 lore raw

2.6.21-rc5: known regressions with patches (v2)

This email lists some known regressions in Linus' tree compared to 2.6.20 with patches available.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : hung bootup in various drivers
References : http://lkml.org/lkml/2007/3/30/68
Submitter : Ingo Molnar <[email protected]>

Handled-By Kay Sievers <[email protected]>

Patch : http://lkml.org/lkml/2007/3/30/323
Status : patch available

Subject : NCQ problem with ahci and Hitachi drive
References : http://lkml.org/lkml/2007/3/4/178

             http://lkml.org/lkml/2007/3/9/475
             http://lkml.org/lkml/2007/2/22/8

Submitter : Mathieu Bérard <[email protected]>

Robert Hancock <[email protected]>
Patch : http://lkml.org/lkml/2007/2/22/8
Status : possible patch available

Subject : suspend to disk hangs (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter : Maxim Levitsky <[email protected]>

Caused-By Rafael J. Wysocki <[email protected]>

             commit e3c7db621bed4afb8e231cb005057f2feb5db557
             commit ed746e3b18f4df18afa3763155972c5835f284c5
             commit 259130526c267550bc365d3015917d90667732f1