* Re: Linux 2.6.21-rc5
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-26 8:31 ` Ingo Molnar
2007-03-26 8:17 ` Ayaz Abdulla
2007-03-26 8:39 ` Ingo Molnar
2007-03-26 8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
` (18 subsequent siblings)
19 siblings, 2 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26 8:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Ayaz Abdulla, Jeff Garzik,
Adrian Bunk, Andrew Morton
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 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(+)
Index: linux/drivers/net/forcedeth.c
===================================================================
--- linux.orig/drivers/net/forcedeth.c
+++ 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 */
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Linux 2.6.21-rc5
2007-03-26 8:31 ` Ingo Molnar
@ 2007-03-26 8:17 ` Ayaz Abdulla
2007-03-26 8:39 ` Ingo Molnar
1 sibling, 0 replies; 128+ messages in thread
From: Ayaz Abdulla @ 2007-03-26 8:17 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Linux Kernel Mailing List, Jeff Garzik,
Adrian Bunk, Andrew Morton
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
Ingo Molnar wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
>>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(+)
>
> Index: linux/drivers/net/forcedeth.c
> ===================================================================
> --- linux.orig/drivers/net/forcedeth.c
> +++ 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 */
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Linux 2.6.21-rc5
2007-03-26 8:31 ` Ingo Molnar
2007-03-26 8:17 ` Ayaz Abdulla
@ 2007-03-26 8:39 ` Ingo Molnar
2007-03-26 8:58 ` [patch] forcedeth: work around NULL skb dereference crash Ingo Molnar
1 sibling, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26 8:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Ayaz Abdulla, Jeff Garzik,
Adrian Bunk, Andrew Morton
* Ingo Molnar <mingo@elte.hu> wrote:
> 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(-)
Index: linux/drivers/net/forcedeth.c
===================================================================
--- linux.orig/drivers/net/forcedeth.c
+++ 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);
}
}
^ permalink raw reply [flat|nested] 128+ messages in thread* [patch] forcedeth: work around NULL skb dereference crash
2007-03-26 8:39 ` Ingo Molnar
@ 2007-03-26 8:58 ` Ingo Molnar
2007-04-02 11:56 ` [patch] forcedeth: improve NAPI logic Ingo Molnar
0 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26 8:58 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Ayaz Abdulla, Jeff Garzik,
Adrian Bunk, Andrew Morton
* Ingo Molnar <mingo@elte.hu> wrote:
> > 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 <mingo@elte.hu>
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 <mingo@elte.hu>
---
drivers/net/forcedeth.c | 10 ++++++++++
1 file changed, 10 insertions(+)
Index: linux/drivers/net/forcedeth.c
===================================================================
--- linux.orig/drivers/net/forcedeth.c
+++ 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;
}
^ permalink raw reply [flat|nested] 128+ messages in thread* [patch] forcedeth: improve NAPI logic
2007-03-26 8:58 ` [patch] forcedeth: work around NULL skb dereference crash Ingo Molnar
@ 2007-04-02 11:56 ` Ingo Molnar
0 siblings, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-04-02 11:56 UTC (permalink / raw)
To: Ayaz Abdulla; +Cc: Linux Kernel Mailing List, Ayaz Abdulla, Andrew Morton
From: Ingo Molnar <mingo@elte.hu>
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 <mingo@elte.hu>
Index: linux/drivers/net/forcedeth.c
===================================================================
--- linux.orig/drivers/net/forcedeth.c
+++ 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);
}
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Linux 2.6.21-rc5
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
2007-03-26 8:31 ` Ingo Molnar
@ 2007-03-26 8:55 ` Thomas Gleixner
2007-03-26 12:25 ` Bob Tracy
2007-03-26 9:04 ` 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82! Ingo Molnar
` (17 subsequent siblings)
19 siblings, 1 reply; 128+ messages in thread
From: Thomas Gleixner @ 2007-03-26 8:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On Sun, 2007-03-25 at 16:08 -0700, Linus Torvalds wrote:
> 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.
Why certainly ! I caused them, so I have to fix them. There are still a
few to hunt down and I want to sort them out before 2.6.21 final.
> 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").
This fix from John Stultz is still missing:
http://lkml.org/lkml/2007/3/22/287
It's in Andrews queue already and waits to be sent to you.
tglx
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Linux 2.6.21-rc5
2007-03-26 8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
@ 2007-03-26 12:25 ` Bob Tracy
2007-03-26 12:30 ` Thomas Gleixner
0 siblings, 1 reply; 128+ messages in thread
From: Bob Tracy @ 2007-03-26 12:25 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Linus Torvalds, Linux Kernel Mailing List, johnstul
Thomas Gleixner wrote:
> This fix from John Stultz is still missing:
>
> http://lkml.org/lkml/2007/3/22/287
>
> It's in Andrews queue already and waits to be sent to you.
In summary, that fix is a workaround to allow the acpi_pm clocksource
to be selected instead of the pit clocksource, thereby allowing my
Dell laptop with the PIIX4 bug to boot. Other apic, clocksource, etc.
patches that were included in -rc5 fixed the problem that caused the
boot process to hang when the pit clocksource was selected, as I
suspected would be the case :-).
Per John's message in the above URL, while the fix is no longer needed
for allowing the laptop to boot, it's probably still "a good thing" to
allow a better clocksource to be selected.
--
-----------------------------------------------------------------------
Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Linux 2.6.21-rc5
2007-03-26 12:25 ` Bob Tracy
@ 2007-03-26 12:30 ` Thomas Gleixner
0 siblings, 0 replies; 128+ messages in thread
From: Thomas Gleixner @ 2007-03-26 12:30 UTC (permalink / raw)
To: Bob Tracy; +Cc: Linus Torvalds, Linux Kernel Mailing List, johnstul
On Mon, 2007-03-26 at 07:25 -0500, Bob Tracy wrote:
> Thomas Gleixner wrote:
> > This fix from John Stultz is still missing:
> >
> > http://lkml.org/lkml/2007/3/22/287
> >
> > It's in Andrews queue already and waits to be sent to you.
>
> In summary, that fix is a workaround to allow the acpi_pm clocksource
> to be selected instead of the pit clocksource, thereby allowing my
> Dell laptop with the PIIX4 bug to boot. Other apic, clocksource, etc.
> patches that were included in -rc5 fixed the problem that caused the
> boot process to hang when the pit clocksource was selected, as I
> suspected would be the case :-).
Ah. Ok
> Per John's message in the above URL, while the fix is no longer needed
> for allowing the laptop to boot, it's probably still "a good thing" to
> allow a better clocksource to be selected.
Yes. The read three times pmtimer is faster and more reliable than the
PIT.
tglx
^ permalink raw reply [flat|nested] 128+ messages in thread
* 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
2007-03-26 8:31 ` Ingo Molnar
2007-03-26 8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
@ 2007-03-26 9:04 ` Ingo Molnar
2007-03-26 18:12 ` Venki Pallipadi
2007-03-26 9:21 ` [PATCH] clockevents: remove bad designed sysfs support for now Thomas Gleixner
` (16 subsequent siblings)
19 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26 9:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Dave Jones, Venkatesh Pallipadi
[-- Attachment #1: Type: text/plain, Size: 39647 bytes --]
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 <venkatesh.pallipadi@intel.com>
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 netconsole=4444@10.0.1.12/eth0,4444@10.0.1.14/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 netconsole=4444@10.0.1.12/eth0,4444@10.0.1.14/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!
[-- Attachment #2: config.bz2 --]
[-- Type: application/x-bzip2, Size: 16956 bytes --]
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!
2007-03-26 9:04 ` 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82! Ingo Molnar
@ 2007-03-26 18:12 ` Venki Pallipadi
2007-03-26 19:03 ` Venki Pallipadi
0 siblings, 1 reply; 128+ messages in thread
From: Venki Pallipadi @ 2007-03-26 18:12 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Linus Torvalds, Linux Kernel Mailing List, Dave Jones
On Mar 26, 2007, at 2:04 AM, Ingo Molnar wrote:
>
> 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 <venkatesh.pallipadi@intel.com>
> 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
> [<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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!
2007-03-26 18:12 ` Venki Pallipadi
@ 2007-03-26 19:03 ` Venki Pallipadi
2007-03-27 7:11 ` Ingo Molnar
0 siblings, 1 reply; 128+ messages in thread
From: Venki Pallipadi @ 2007-03-26 19:03 UTC (permalink / raw)
To: Venki Pallipadi
Cc: Ingo Molnar, Linus Torvalds, Linux Kernel Mailing List, Dave Jones
On Mon, Mar 26, 2007 at 11:12:02AM -0700, Venki Pallipadi wrote:
>
> >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!
> >
>
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 <venkatesh.pallipadi@intel.com>
Index: new/drivers/cpufreq/cpufreq.c
===================================================================
--- new.orig/drivers/cpufreq/cpufreq.c 2007-03-22 07:43:37.000000000 -0800
+++ new/drivers/cpufreq/cpufreq.c 2007-03-26 10:07:06.000000000 -0800
@@ -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();
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82!
2007-03-26 19:03 ` Venki Pallipadi
@ 2007-03-27 7:11 ` Ingo Molnar
0 siblings, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-27 7:11 UTC (permalink / raw)
To: Venki Pallipadi; +Cc: Linus Torvalds, Linux Kernel Mailing List, Dave Jones
* Venki Pallipadi <venkatesh.pallipadi@intel.com> wrote:
> 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 <mingo@elte.hu>
Ingo
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH] clockevents: remove bad designed sysfs support for now
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
` (2 preceding siblings ...)
2007-03-26 9:04 ` 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82! Ingo Molnar
@ 2007-03-26 9:21 ` Thomas Gleixner
2007-03-26 9:25 ` Ingo Molnar
` (2 more replies)
2007-03-26 10:11 ` -rc5: e1000 resume weirdness Ingo Molnar
` (15 subsequent siblings)
19 siblings, 3 replies; 128+ messages in thread
From: Thomas Gleixner @ 2007-03-26 9:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Ingo Molnar, Greg KH, Andrew Morton
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 <tglx@linutronix.de>
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 67932ea..76212b2 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -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
^ permalink raw reply related [flat|nested] 128+ messages in thread* Re: [PATCH] clockevents: remove bad designed sysfs support for now
2007-03-26 9:21 ` [PATCH] clockevents: remove bad designed sysfs support for now Thomas Gleixner
@ 2007-03-26 9:25 ` Ingo Molnar
2007-03-26 18:57 ` Greg KH
2007-03-26 12:51 ` Pavel Machek
2007-03-27 7:08 ` [PATCH] i386: Fix bogus return value in hpet_next_event() Thomas Gleixner
2 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26 9:25 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Linus Torvalds, Linux Kernel Mailing List, Greg KH, Andrew Morton
* Thomas Gleixner <tglx@linutronix.de> wrote:
> 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 <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Ingo
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH] clockevents: remove bad designed sysfs support for now
2007-03-26 9:25 ` Ingo Molnar
@ 2007-03-26 18:57 ` Greg KH
0 siblings, 0 replies; 128+ messages in thread
From: Greg KH @ 2007-03-26 18:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Linus Torvalds, Linux Kernel Mailing List,
Andrew Morton
On Mon, Mar 26, 2007 at 11:25:05AM +0200, Ingo Molnar wrote:
>
> * Thomas Gleixner <tglx@linutronix.de> wrote:
>
> > 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 <tglx@linutronix.de>
>
> Acked-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Thanks Thomas for doing this.
greg k-h
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH] clockevents: remove bad designed sysfs support for now
2007-03-26 9:21 ` [PATCH] clockevents: remove bad designed sysfs support for now Thomas Gleixner
2007-03-26 9:25 ` Ingo Molnar
@ 2007-03-26 12:51 ` Pavel Machek
2007-03-27 7:08 ` [PATCH] i386: Fix bogus return value in hpet_next_event() Thomas Gleixner
2 siblings, 0 replies; 128+ messages in thread
From: Pavel Machek @ 2007-03-26 12:51 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Linus Torvalds, Linux Kernel Mailing List, Ingo Molnar, Greg KH,
Andrew Morton
On Mon 2007-03-26 11:21:08, Thomas Gleixner wrote:
> 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 <tglx@linutronix.de>
Thanks!
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH] i386: Fix bogus return value in hpet_next_event()
2007-03-26 9:21 ` [PATCH] clockevents: remove bad designed sysfs support for now Thomas Gleixner
2007-03-26 9:25 ` Ingo Molnar
2007-03-26 12:51 ` Pavel Machek
@ 2007-03-27 7:08 ` Thomas Gleixner
2 siblings, 0 replies; 128+ messages in thread
From: Thomas Gleixner @ 2007-03-27 7:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Ingo Molnar, Andrew Morton
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 <tglx@linutronix.de>
diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index f3ab61e..76afea6 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -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;
}
/*
^ permalink raw reply related [flat|nested] 128+ messages in thread
* -rc5: e1000 resume weirdness
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
` (3 preceding siblings ...)
2007-03-26 9:21 ` [PATCH] clockevents: remove bad designed sysfs support for now Thomas Gleixner
@ 2007-03-26 10:11 ` Ingo Molnar
2007-03-26 15:39 ` Kok, Auke
2007-03-26 15:50 ` Jesse Brandeburg
2007-03-27 1:59 ` [1/5] 2.6.21-rc5: known regressions Adrian Bunk
` (14 subsequent siblings)
19 siblings, 2 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26 10:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, auke-jan.h.kok, Adrian Bunk
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
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: -rc5: e1000 resume weirdness
2007-03-26 10:11 ` -rc5: e1000 resume weirdness Ingo Molnar
@ 2007-03-26 15:39 ` Kok, Auke
2007-03-26 15:50 ` Jesse Brandeburg
1 sibling, 0 replies; 128+ messages in thread
From: Kok, Auke @ 2007-03-26 15:39 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Linus Torvalds, Linux Kernel Mailing List, Adrian Bunk
Ingo Molnar wrote:
> 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
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 <auke-jan.h.kok@intel.com>
Free interrupts symmetrically with resume allocation to prevent
pci save/restore state from possibly failing or warning.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000/e1000_main.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 55ef148..93d41f0 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -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);
^ permalink raw reply related [flat|nested] 128+ messages in thread* Re: -rc5: e1000 resume weirdness
2007-03-26 10:11 ` -rc5: e1000 resume weirdness Ingo Molnar
2007-03-26 15:39 ` Kok, Auke
@ 2007-03-26 15:50 ` Jesse Brandeburg
2007-03-26 15:55 ` Kok, Auke
2007-03-26 17:39 ` Ingo Molnar
1 sibling, 2 replies; 128+ messages in thread
From: Jesse Brandeburg @ 2007-03-26 15:50 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Linux Kernel Mailing List, auke-jan.h.kok, Adrian Bunk
On 3/26/07, Ingo Molnar <mingo@elte.hu> wrote:
>
> 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.
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.
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: -rc5: e1000 resume weirdness
2007-03-26 15:50 ` Jesse Brandeburg
@ 2007-03-26 15:55 ` Kok, Auke
2007-03-26 17:39 ` Ingo Molnar
1 sibling, 0 replies; 128+ messages in thread
From: Kok, Auke @ 2007-03-26 15:55 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Ingo Molnar, Linus Torvalds, Linux Kernel Mailing List, Adrian Bunk
Jesse Brandeburg wrote:
> On 3/26/07, Ingo Molnar <mingo@elte.hu> wrote:
>> 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.
>
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: -rc5: e1000 resume weirdness
2007-03-26 15:50 ` Jesse Brandeburg
2007-03-26 15:55 ` Kok, Auke
@ 2007-03-26 17:39 ` Ingo Molnar
1 sibling, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-26 17:39 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Linus Torvalds, Linux Kernel Mailing List, auke-jan.h.kok, Adrian Bunk
* Jesse Brandeburg <jesse.brandeburg@gmail.com> wrote:
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* [1/5] 2.6.21-rc5: known regressions
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
` (4 preceding siblings ...)
2007-03-26 10:11 ` -rc5: e1000 resume weirdness Ingo Molnar
@ 2007-03-27 1:59 ` Adrian Bunk
2007-03-28 18:54 ` Kok, Auke
2007-03-30 12:04 ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
2007-03-27 1:59 ` Adrian Bunk
` (13 subsequent siblings)
19 siblings, 2 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27 1:59 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Oliver Pinter, Sid Boyce,
Boris Mogwitz, Eric W. Biederman, Jose Alberto Reguero,
Ingo Molnar, Jesse Brandeburg, Auke Kok, e1000-devel, jgarzik,
netdev, Ayaz Abdulla, Albert Hopkins
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 <oliver.pntr@gmail.com>
Status : unknown
Subject : kwin dies silently (sysctl related?)
References : http://lkml.org/lkml/2007/2/28/112
Submitter : Sid Boyce <g3vbv@blueyonder.co.uk>
Boris Mogwitz <boris@macbeth.rhoen.de>
Status : submitter was asked to bisect further
Subject : problem with sockets
References : http://lkml.org/lkml/2007/3/21/248
Submitter : Jose Alberto Reguero <jareguero@telefonica.net>
Status : unknown
Subject : e1000 resume weirdness
References : http://lkml.org/lkml/2007/3/26/91
Submitter : Ingo Molnar <mingo@elte.hu>
Handled-By : Jesse Brandeburg <jesse.brandeburg@gmail.com>
Auke Kok <auke-jan.h.kok@intel.com>
Status : problem is being debugged
Subject : forcedeth: sporadic under-load crashes
References : http://lkml.org/lkml/2007/3/26/63
Submitter : Ingo Molnar <mingo@elte.hu>
Handled-By : Ingo Molnar <mingo@elte.hu>
Ayaz Abdulla <aabdulla@nvidia.com>
Status : problem is being debugged
Subject : forcedeth: skb_over_panic
References : http://bugzilla.kernel.org/show_bug.cgi?id=8058
Submitter : Albert Hopkins <kernel@marduk.letterboxes.org>
Handled-By : Ayaz Abdulla <aabdulla@nvidia.com>
Patch : http://bugzilla.kernel.org/show_bug.cgi?id=8058
Status : patch available
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [1/5] 2.6.21-rc5: known regressions
2007-03-27 1:59 ` [1/5] 2.6.21-rc5: known regressions Adrian Bunk
@ 2007-03-28 18:54 ` Kok, Auke
2007-03-28 19:23 ` Ingo Molnar
2007-03-30 18:04 ` Adrian Bunk
2007-03-30 12:04 ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
1 sibling, 2 replies; 128+ messages in thread
From: Kok, Auke @ 2007-03-28 18:54 UTC (permalink / raw)
To: Adrian Bunk, Ingo Molnar
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Jesse Brandeburg, e1000-devel, jgarzik, netdev
Adrian Bunk wrote:
> Subject : e1000 resume weirdness
> References : http://lkml.org/lkml/2007/3/26/91
> Submitter : Ingo Molnar <mingo@elte.hu>
> Handled-By : Jesse Brandeburg <jesse.brandeburg@gmail.com>
> Auke Kok <auke-jan.h.kok@intel.com>
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [1/5] 2.6.21-rc5: known regressions
2007-03-28 18:54 ` Kok, Auke
@ 2007-03-28 19:23 ` Ingo Molnar
2007-03-30 18:04 ` Adrian Bunk
1 sibling, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-28 19:23 UTC (permalink / raw)
To: Kok, Auke
Cc: Adrian Bunk, Linus Torvalds, Andrew Morton,
Linux Kernel Mailing List, Jesse Brandeburg, e1000-devel,
jgarzik, netdev
* Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> Adrian Bunk wrote:
> >Subject : e1000 resume weirdness
> >References : http://lkml.org/lkml/2007/3/26/91
> >Submitter : Ingo Molnar <mingo@elte.hu>
> >Handled-By : Jesse Brandeburg <jesse.brandeburg@gmail.com>
> > Auke Kok <auke-jan.h.kok@intel.com>
> >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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [1/5] 2.6.21-rc5: known regressions
2007-03-28 18:54 ` Kok, Auke
2007-03-28 19:23 ` Ingo Molnar
@ 2007-03-30 18:04 ` Adrian Bunk
1 sibling, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 18:04 UTC (permalink / raw)
To: Kok, Auke
Cc: Ingo Molnar, Linus Torvalds, Andrew Morton,
Linux Kernel Mailing List, Jesse Brandeburg, e1000-devel,
jgarzik, netdev
On Wed, Mar 28, 2007 at 11:54:32AM -0700, Kok, Auke wrote:
> Adrian Bunk wrote:
> >Subject : e1000 resume weirdness
> >References : http://lkml.org/lkml/2007/3/26/91
> >Submitter : Ingo Molnar <mingo@elte.hu>
> >Handled-By : Jesse Brandeburg <jesse.brandeburg@gmail.com>
> > Auke Kok <auke-jan.h.kok@intel.com>
> >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.
Thanks for the update, dropped as non-regression.
> Cheers,
>
>
> Auke
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 128+ messages in thread
* [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
2007-03-27 1:59 ` [1/5] 2.6.21-rc5: known regressions Adrian Bunk
2007-03-28 18:54 ` Kok, Auke
@ 2007-03-30 12:04 ` Ingo Molnar
2007-03-30 12:06 ` [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), " Ingo Molnar
` (2 more replies)
1 sibling, 3 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-30 12:04 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, linux-kernel, Greg Kroah-Hartman
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
Index: linux/drivers/base/driver.c
===================================================================
--- linux.orig/drivers/base/driver.c
+++ 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);
}
/**
^ permalink raw reply [flat|nested] 128+ messages in thread* [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"
2007-03-30 12:04 ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
@ 2007-03-30 12:06 ` Ingo Molnar
2007-03-30 14:18 ` Greg KH
2007-03-30 14:16 ` [bug] hung bootup in various drivers, " Greg KH
2007-04-01 7:49 ` Pavel Machek
2 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-30 12:06 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, linux-kernel, Greg Kroah-Hartman
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()
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"
2007-03-30 12:06 ` [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), " Ingo Molnar
@ 2007-03-30 14:18 ` Greg KH
2007-03-30 14:25 ` Ingo Molnar
0 siblings, 1 reply; 128+ messages in thread
From: Greg KH @ 2007-03-30 14:18 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel
On Fri, Mar 30, 2007 at 02:06:57PM +0200, Ingo Molnar wrote:
>
> 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
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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"
2007-03-30 14:18 ` Greg KH
@ 2007-03-30 14:25 ` Ingo Molnar
2007-03-30 16:31 ` Vitaly Bordug
0 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-30 14:25 UTC (permalink / raw)
To: Greg KH
Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel, Vitaly Bordug
* Greg KH <gregkh@suse.de> wrote:
> > 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
>
> 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.
> It is independant from your previous question about unregistering the
> device from within module_init().
(yes - hence the different subject line, etc.)
Ingo
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"
2007-03-30 14:25 ` Ingo Molnar
@ 2007-03-30 16:31 ` Vitaly Bordug
0 siblings, 0 replies; 128+ messages in thread
From: Vitaly Bordug @ 2007-03-30 16:31 UTC (permalink / raw)
To: Ingo Molnar
Cc: Greg KH, Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel
On Fri, 30 Mar 2007 16:25:14 +0200
Ingo Molnar <mingo@elte.hu> wrote:
>
> * Greg KH <gregkh@suse.de> wrote:
>
> > > 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
> >
> > 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.
> > It is independant from your previous question about unregistering the
> > device from within module_init().
>
> (yes - hence the different subject line, etc.)
>
--
Sincerely,
Vitaly
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
2007-03-30 12:04 ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
2007-03-30 12:06 ` [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), " Ingo Molnar
@ 2007-03-30 14:16 ` Greg KH
2007-03-30 17:46 ` Ingo Molnar
2007-04-01 7:49 ` Pavel Machek
2 siblings, 1 reply; 128+ messages in thread
From: Greg KH @ 2007-03-30 14:16 UTC (permalink / raw)
To: Ingo Molnar, Kay Sievers
Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel
On Fri, Mar 30, 2007 at 02:04:16PM +0200, Ingo Molnar wrote:
>
> 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?
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
> Index: linux/drivers/base/driver.c
> ===================================================================
> --- linux.orig/drivers/base/driver.c
> +++ 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);
> }
>
> /**
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
2007-03-30 14:16 ` [bug] hung bootup in various drivers, " Greg KH
@ 2007-03-30 17:46 ` Ingo Molnar
2007-03-30 19:32 ` Greg KH
0 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-30 17:46 UTC (permalink / raw)
To: Greg KH
Cc: Kay Sievers, Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel
* Greg KH <gregkh@suse.de> wrote:
> > 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
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
2007-03-30 17:46 ` Ingo Molnar
@ 2007-03-30 19:32 ` Greg KH
2007-03-31 2:32 ` Kay Sievers
2007-03-31 16:31 ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
0 siblings, 2 replies; 128+ messages in thread
From: Greg KH @ 2007-03-30 19:32 UTC (permalink / raw)
To: Ingo Molnar
Cc: Kay Sievers, Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel
On Fri, Mar 30, 2007 at 07:46:19PM +0200, Ingo Molnar wrote:
>
> * Greg KH <gregkh@suse.de> wrote:
>
> > > 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
>
> > 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.
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
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
2007-03-30 19:32 ` Greg KH
@ 2007-03-31 2:32 ` Kay Sievers
2007-03-31 16:51 ` [patch] driver core: fix built-in drivers sysfs links Ingo Molnar
2007-03-31 16:31 ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
1 sibling, 1 reply; 128+ messages in thread
From: Kay Sievers @ 2007-03-31 2:32 UTC (permalink / raw)
To: Greg KH
Cc: Ingo Molnar, Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2608 bytes --]
On Fri, 2007-03-30 at 12:32 -0700, Greg KH wrote:
> On Fri, Mar 30, 2007 at 07:46:19PM +0200, Ingo Molnar wrote:
> >
> > * Greg KH <gregkh@suse.de> wrote:
> >
> > > > 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
> >
> > > 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.
>
> 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?
Does the attached work for you?
Thanks,
Kay
[-- Attachment #2: built-in-driver-links-fix.patch --]
[-- Type: text/x-patch, Size: 1573 bytes --]
diff --git a/include/linux/device.h b/include/linux/device.h
index caad9bb..5cf30e9 100644
--- a/include/linux/device.h
+++ b/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);
diff --git a/kernel/module.c b/kernel/module.c
index fbc51de..dcdb32b 100644
--- a/kernel/module.c
+++ b/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);
}
}
^ permalink raw reply related [flat|nested] 128+ messages in thread* [patch] driver core: fix built-in drivers sysfs links
2007-03-31 2:32 ` Kay Sievers
@ 2007-03-31 16:51 ` Ingo Molnar
0 siblings, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-31 16:51 UTC (permalink / raw)
To: Kay Sievers
Cc: Greg KH, Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel
* Kay Sievers <kay.sievers@vrfy.org> wrote:
> > 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 <kay.sievers@vrfy.org>
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 <mingo@elte.hu>
---
include/linux/device.h | 1 +
kernel/module.c | 18 ++++++++++++++----
2 files changed, 15 insertions(+), 4 deletions(-)
Index: linux/include/linux/device.h
===================================================================
--- linux.orig/include/linux/device.h
+++ 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);
Index: linux/kernel/module.c
===================================================================
--- linux.orig/kernel/module.c
+++ 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);
}
}
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
2007-03-30 19:32 ` Greg KH
2007-03-31 2:32 ` Kay Sievers
@ 2007-03-31 16:31 ` Ingo Molnar
1 sibling, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-31 16:31 UTC (permalink / raw)
To: Greg KH
Cc: Kay Sievers, Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel
* Greg KH <gregkh@suse.de> wrote:
> 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 :)
> Kay, did you ever get a chance to look into this reference counting
> issue?
i'll try Kay's patch.
Ingo
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
2007-03-30 12:04 ` [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions" Ingo Molnar
2007-03-30 12:06 ` [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), " Ingo Molnar
2007-03-30 14:16 ` [bug] hung bootup in various drivers, " Greg KH
@ 2007-04-01 7:49 ` Pavel Machek
2007-04-01 17:17 ` Linus Torvalds
2 siblings, 1 reply; 128+ messages in thread
From: Pavel Machek @ 2007-04-01 7:49 UTC (permalink / raw)
To: Ingo Molnar
Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel,
Greg Kroah-Hartman
Hi!
> @@ -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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"
2007-04-01 7:49 ` Pavel Machek
@ 2007-04-01 17:17 ` Linus Torvalds
2007-04-01 17:35 ` [patch] driver core: if built-in, do not wait in driver_unregister() Ingo Molnar
0 siblings, 1 reply; 128+ messages in thread
From: Linus Torvalds @ 2007-04-01 17:17 UTC (permalink / raw)
To: Pavel Machek
Cc: Ingo Molnar, Adrian Bunk, Andrew Morton, linux-kernel,
Greg Kroah-Hartman
On Sun, 1 Apr 2007, Pavel Machek wrote:
>
> > @@ -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(-)
diff --git a/drivers/base/driver.c b/drivers/base/driver.c
index 1214cbd..082bfde 100644
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -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);
}
/**
^ permalink raw reply related [flat|nested] 128+ messages in thread* [patch] driver core: if built-in, do not wait in driver_unregister()
2007-04-01 17:17 ` Linus Torvalds
@ 2007-04-01 17:35 ` Ingo Molnar
2007-04-02 1:47 ` Greg KH
0 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-04-01 17:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Pavel Machek, Adrian Bunk, Andrew Morton, linux-kernel,
Greg Kroah-Hartman
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 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 <torvalds@linux-foundation.org>
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 <mingo@elte.hu>
---
drivers/base/driver.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Index: linux/drivers/base/driver.c
===================================================================
--- linux.orig/drivers/base/driver.c
+++ 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);
}
/**
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [patch] driver core: if built-in, do not wait in driver_unregister()
2007-04-01 17:35 ` [patch] driver core: if built-in, do not wait in driver_unregister() Ingo Molnar
@ 2007-04-02 1:47 ` Greg KH
0 siblings, 0 replies; 128+ messages in thread
From: Greg KH @ 2007-04-02 1:47 UTC (permalink / raw)
To: Ingo Molnar, Kay Sievers
Cc: Linus Torvalds, Pavel Machek, Adrian Bunk, Andrew Morton, linux-kernel
On Sun, Apr 01, 2007 at 07:35:08PM +0200, Ingo Molnar wrote:
>
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > 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).
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
> ------------------------->
> Subject: [patch] driver core: if built-in, do not wait in driver_unregister()
> From: Linus Torvalds <torvalds@linux-foundation.org>
>
> 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 <mingo@elte.hu>
> ---
> drivers/base/driver.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> Index: linux/drivers/base/driver.c
> ===================================================================
> --- linux.orig/drivers/base/driver.c
> +++ 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);
> }
>
> /**
^ permalink raw reply [flat|nested] 128+ messages in thread
* [2/5] 2.6.21-rc5: known regressions
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
2007-03-26 8:31 ` Ingo Molnar
@ 2007-03-27 1:59 ` Adrian Bunk
2007-03-26 9:04 ` 2.6.21-rc5: maxcpus=1 crash in cpufreq: kernel BUG at drivers/cpufreq/cpufreq.c:82! Ingo Molnar
` (17 subsequent siblings)
19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27 1:59 UTC (permalink / raw)
Cc: Linux Kernel Mailing List, Ingo Molnar, Venki Pallipadi, davej,
cpufreq, Michal Jaegermann, jgarzik, linux-ide, lenb, linux-acpi,
Mathieu Bérard, Tejun Heo, Fabio Comolli, Plamen Petrov,
Laurent Riffard, Lukas Hejtmanek
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 : x86_64 SMP kernel: maxcpus=1 crash in cpufreq
References : http://lkml.org/lkml/2007/3/26/54
Submitter : Ingo Molnar <mingo@elte.hu>
Handled-By : Venki Pallipadi <venkatesh.pallipadi@intel.com>
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 <michal@ellpspace.math.ualberta.ca>
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 <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
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/linux-ide@vger.kernel.org/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 <fabio.comolli@gmail.com>
Plamen Petrov <plamen.petrov@tk.ru.acad.bg>
Laurent Riffard <laurent.riffard@free.fr>
Lukas Hejtmanek <xhejtman@mail.muni.cz>
Handled-By : Tejun Heo <htejun@gmail.com>
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 128+ messages in thread* [2/5] 2.6.21-rc5: known regressions
@ 2007-03-27 1:59 ` Adrian Bunk
0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27 1:59 UTC (permalink / raw)
Cc: Linux Kernel Mailing List, Ingo Molnar, Venki Pallipadi, davej,
cpufreq, Michal Jaegermann, jgarzik, linux-ide, lenb, linux-acpi,
Mathieu Bérard, Tejun Heo, Fabio Comolli, Plamen Petrov,
Laurent Riffard, Lukas Hejtmanek
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 : x86_64 SMP kernel: maxcpus=1 crash in cpufreq
References : http://lkml.org/lkml/2007/3/26/54
Submitter : Ingo Molnar <mingo@elte.hu>
Handled-By : Venki Pallipadi <venkatesh.pallipadi@intel.com>
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 <michal@ellpspace.math.ualberta.ca>
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 <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
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/linux-ide@vger.kernel.org/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 <fabio.comolli@gmail.com>
Plamen Petrov <plamen.petrov@tk.ru.acad.bg>
Laurent Riffard <laurent.riffard@free.fr>
Lukas Hejtmanek <xhejtman@mail.muni.cz>
Handled-By : Tejun Heo <htejun@gmail.com>
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 128+ messages in thread* [2/5] 2.6.21-rc5: known regressions
@ 2007-03-27 1:59 ` Adrian Bunk
0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27 1:59 UTC (permalink / raw)
Cc: Linux Kernel Mailing List, Ingo Molnar, Venki Pallipadi, davej,
cpufreq, Michal Jaegermann, jgarzik, linux-ide, lenb, linux-acpi,
Mathieu Bérard, Tejun Heo, Fabio Comolli, Plamen Petrov,
Laurent Riffard, Lukas Hejtmanek
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 : x86_64 SMP kernel: maxcpus=1 crash in cpufreq
References : http://lkml.org/lkml/2007/3/26/54
Submitter : Ingo Molnar <mingo@elte.hu>
Handled-By : Venki Pallipadi <venkatesh.pallipadi@intel.com>
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 <michal@ellpspace.math.ualberta.ca>
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 <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
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/linux-ide@vger.kernel.org/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 <fabio.comolli@gmail.com>
Plamen Petrov <plamen.petrov@tk.ru.acad.bg>
Laurent Riffard <laurent.riffard@free.fr>
Lukas Hejtmanek <xhejtman@mail.muni.cz>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch : http://thread.gmane.org/gmane.linux.ide/17444
Status : patch available
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [2/5] 2.6.21-rc5: known regressions
2007-03-27 1:59 ` Adrian Bunk
(?)
(?)
@ 2007-03-28 19:46 ` Laurent Riffard
2007-03-29 19:02 ` Fabio Comolli
-1 siblings, 1 reply; 128+ messages in thread
From: Laurent Riffard @ 2007-03-28 19:46 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linux Kernel Mailing List, linux-ide, Tejun Heo, Fabio Comolli,
Plamen Petrov, Lukas Hejtmanek
Le 27.03.2007 03:59, Adrian Bunk a écrit :
> This email lists some known regressions in Linus' tree compared to 2.6.20.
...
> Subject : libata: PATA UDMA/100 configured as UDMA/33
> References : http://lkml.org/lkml/2007/2/20/294
> http://www.mail-archive.com/linux-ide@vger.kernel.org/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 <fabio.comolli@gmail.com>
> Plamen Petrov <plamen.petrov@tk.ru.acad.bg>
> Laurent Riffard <laurent.riffard@free.fr>
> Lukas Hejtmanek <xhejtman@mail.muni.cz>
> Handled-By : Tejun Heo <htejun@gmail.com>
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* [3/5] 2.6.21-rc5: known regressions
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
` (6 preceding siblings ...)
2007-03-27 1:59 ` Adrian Bunk
@ 2007-03-27 1:59 ` Adrian Bunk
2007-03-27 1:59 ` Adrian Bunk
` (11 subsequent siblings)
19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27 1:59 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, CIJOML, v4l-dvb-maintainer,
Michal Piotrowski, perex, alsa-devel, Tino Keitel,
Marcelo Tosatti, Oliver Neukum, greg, linux-usb-devel
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 : Oops when changing DVB-T adapter
References : http://lkml.org/lkml/2007/3/9/212
Submitter : CIJOML <cijoml@volny.cz>
Status : unknown
Subject : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Status : unknown
Subject : USB: iPod doesn't work (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2007/3/21/320
Submitter : Tino Keitel <tino.keitel@gmx.de>
Caused-By : Marcelo Tosatti <marcelo@kvack.org>
commit 1d619f128ba911cd3e6d6ad3475f146eb92f5c27
Handled-By : Oliver Neukum <oneukum@suse.de>
Status : problem is being debuggged
^ permalink raw reply [flat|nested] 128+ messages in thread* [4/5] 2.6.21-rc5: known regressions
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-27 1:59 ` Adrian Bunk
2007-03-26 8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
` (18 subsequent siblings)
19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27 1:59 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Dave Jones, Jeremy Fitzhardinge,
Eric W. Biederman, Rafael J. Wysocki, gregkh, linux-pci, pavel,
linux-pm, Thomas Meyer, Frédéric Riss, Marcus Better,
Tobias Doerffel, Len Brown, linux-acpi, Thomas Gleixner,
Soeren Sonnenburg, jgarzik, linux-ide, Jens Axboe, Jeff Chua,
Maxim Levitsky, tigran
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 : ThinkPad X60: resume no longer works (PCI related?)
References : http://lkml.org/lkml/2007/3/13/3
Submitter : Dave Jones <davej@redhat.com>
Jeremy Fitzhardinge <jeremy@goop.org>
Caused-By : PCI merge
commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
Rafael J. Wysocki <rjw@sisk.pl>
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 <thomas@m3y3r.de>
Frédéric Riss <frederic.riss@gmail.com>
Marcus Better <marcus@better.se>
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
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 <tobias.doerffel@gmail.com>
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Len Brown <len.brown@intel.com>
Status : problem is being debugged
Subject : s2ram autowake regression (ACPI?)
References : http://lkml.org/lkml/2007/3/20/96
Submitter : Pavel Machek <pavel@ucw.cz>
Handled-By : Len Brown <lenb@kernel.org>
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 <tglx@linutronix.de>
Soeren Sonnenburg <kernel@nn7.de>
Status : unknown
Subject : suspend to disk: keypress required for power down
References : http://lkml.org/lkml/2007/3/25/78
Submitter : Thomas Meyer <thomas@m3y3r.de>
Status : unknown
Subject : resume from RAM corrupts vesafb console
References : http://lkml.org/lkml/2007/3/26/76
Submitter : Marcus Better <marcus@better.se>
Handled-By : Pavel Machek <pavel@ucw.cz>
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 <thomas@m3y3r.de>
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Eric W. Biederman <ebiederm@xmission.com>
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 <jens.axboe@oracle.com>
Jeff Chua <jeff.chua.linux@gmail.com>
Status : unknown
Subject : suspend to disk hangs (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter : Maxim Levitsky <maximlevitsky@gmail.com>
Caused-By : Rafael J. Wysocki <rjw@sisk.pl>
commit e3c7db621bed4afb8e231cb005057f2feb5db557
commit ed746e3b18f4df18afa3763155972c5835f284c5
commit 259130526c267550bc365d3015917d90667732f1
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 128+ messages in thread* [4/5] 2.6.21-rc5: known regressions
@ 2007-03-27 1:59 ` Adrian Bunk
0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27 1:59 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Dave Jones, Jeremy Fitzhardinge,
Eric W. Biederman, Rafael J. Wysocki, gregkh, linux-pci, pavel,
linux-pm, Thomas Meyer, Frédéric Riss, Marcus Better,
Tobias Doerffel, Len Brown, linux-acpi, Thomas Gleixner,
Soeren Sonnenburg, jgarzik, linux-ide, Jens Axboe, Jeff Chua,
Maxim Levitsky, tigran
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 : ThinkPad X60: resume no longer works (PCI related?)
References : http://lkml.org/lkml/2007/3/13/3
Submitter : Dave Jones <davej@redhat.com>
Jeremy Fitzhardinge <jeremy@goop.org>
Caused-By : PCI merge
commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
Rafael J. Wysocki <rjw@sisk.pl>
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 <thomas@m3y3r.de>
Frédéric Riss <frederic.riss@gmail.com>
Marcus Better <marcus@better.se>
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
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 <tobias.doerffel@gmail.com>
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Len Brown <len.brown@intel.com>
Status : problem is being debugged
Subject : s2ram autowake regression (ACPI?)
References : http://lkml.org/lkml/2007/3/20/96
Submitter : Pavel Machek <pavel@ucw.cz>
Handled-By : Len Brown <lenb@kernel.org>
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 <tglx@linutronix.de>
Soeren Sonnenburg <kernel@nn7.de>
Status : unknown
Subject : suspend to disk: keypress required for power down
References : http://lkml.org/lkml/2007/3/25/78
Submitter : Thomas Meyer <thomas@m3y3r.de>
Status : unknown
Subject : resume from RAM corrupts vesafb console
References : http://lkml.org/lkml/2007/3/26/76
Submitter : Marcus Better <marcus@better.se>
Handled-By : Pavel Machek <pavel@ucw.cz>
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 <thomas@m3y3r.de>
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Eric W. Biederman <ebiederm@xmission.com>
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 <jens.axboe@oracle.com>
Jeff Chua <jeff.chua.linux@gmail.com>
Status : unknown
Subject : suspend to disk hangs (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter : Maxim Levitsky <maximlevitsky@gmail.com>
Caused-By : Rafael J. Wysocki <rjw@sisk.pl>
commit e3c7db621bed4afb8e231cb005057f2feb5db557
commit ed746e3b18f4df18afa3763155972c5835f284c5
commit 259130526c267550bc365d3015917d90667732f1
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Patch : http://lkml.org/lkml/2007/3/23/179
Status : patch available
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [4/5] 2.6.21-rc5: known regressions
2007-03-27 1:59 ` Adrian Bunk
(?)
@ 2007-03-27 8:00 ` Marcus Better
2007-03-27 13:25 ` Eric W. Biederman
-1 siblings, 1 reply; 128+ messages in thread
From: Marcus Better @ 2007-03-27 8:00 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linux Kernel Mailing List, Eric W. Biederman, Thomas Meyer,
Frédéric Riss
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
> 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 <thomas@m3y3r.de>
> Frédéric Riss <frederic.riss@gmail.com>
> Marcus Better <marcus@better.se>
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> 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 <ebiederm@xmission.com>
Date: Thu Mar 8 13:04:57 2007 -0700
[PATCH] msi: Safer state caching.
Marcus
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [4/5] 2.6.21-rc5: known regressions
2007-03-27 8:00 ` Marcus Better
@ 2007-03-27 13:25 ` Eric W. Biederman
2007-03-27 16:53 ` Marcus Better
0 siblings, 1 reply; 128+ messages in thread
From: Eric W. Biederman @ 2007-03-27 13:25 UTC (permalink / raw)
To: Marcus Better
Cc: Adrian Bunk, Linux Kernel Mailing List, Thomas Meyer,
Frédéric Riss
Marcus Better <marcus@better.se> writes:
>> 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 <thomas@m3y3r.de>
>> Frédéric Riss <frederic.riss@gmail.com>
>> Marcus Better <marcus@better.se>
>> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>> 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 <ebiederm@xmission.com>
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [4/5] 2.6.21-rc5: known regressions
2007-03-27 1:59 ` Adrian Bunk
@ 2007-03-27 10:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2007-03-27 10:09 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Eric W. Biederman, pavel, linux-pm, Thomas Meyer,
Thomas Gleixner
On Tuesday, 27 March 2007 03:59, Adrian Bunk wrote:
> 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:
> Subject : suspend to disk: keypress required for power down
> References : http://lkml.org/lkml/2007/3/25/78
> Submitter : Thomas Meyer <thomas@m3y3r.de>
> Status : unknown
> Subject : suspend to disk: non-boot cpus are disabled again
> References : http://lkml.org/lkml/2007/3/25/78
> Submitter : Thomas Meyer <thomas@m3y3r.de>
> Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
> Eric W. Biederman <ebiederm@xmission.com>
> 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 <rjw@sisk.pl>
---
arch/x86_64/kernel/acpi/sleep.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc5/arch/x86_64/kernel/acpi/sleep.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/x86_64/kernel/acpi/sleep.c
+++ 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();
}
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [4/5] 2.6.21-rc5: known regressions
@ 2007-03-27 10:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2007-03-27 10:09 UTC (permalink / raw)
To: Adrian Bunk
Cc: Thomas Gleixner, Eric W. Biederman, Linus Torvalds,
Andrew Morton, linux-pm, Linux Kernel Mailing List, Thomas Meyer
On Tuesday, 27 March 2007 03:59, Adrian Bunk wrote:
> 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:
> Subject : suspend to disk: keypress required for power down
> References : http://lkml.org/lkml/2007/3/25/78
> Submitter : Thomas Meyer <thomas@m3y3r.de>
> Status : unknown
> Subject : suspend to disk: non-boot cpus are disabled again
> References : http://lkml.org/lkml/2007/3/25/78
> Submitter : Thomas Meyer <thomas@m3y3r.de>
> Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
> Eric W. Biederman <ebiederm@xmission.com>
> 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 <rjw@sisk.pl>
---
arch/x86_64/kernel/acpi/sleep.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc5/arch/x86_64/kernel/acpi/sleep.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/x86_64/kernel/acpi/sleep.c
+++ 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();
}
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [4/5] 2.6.21-rc5: known regressions
2007-03-27 10:09 ` Rafael J. Wysocki
@ 2007-03-27 22:29 ` Adrian Bunk
-1 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27 22:29 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Eric W. Biederman, pavel, linux-pm, Thomas Meyer,
Thomas Gleixner
On Tue, Mar 27, 2007 at 12:09:13PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, 27 March 2007 03:59, Adrian Bunk wrote:
> > 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:
>
> > Subject : suspend to disk: keypress required for power down
> > References : http://lkml.org/lkml/2007/3/25/78
> > Submitter : Thomas Meyer <thomas@m3y3r.de>
> > Status : unknown
>
> > Subject : suspend to disk: non-boot cpus are disabled again
> > References : http://lkml.org/lkml/2007/3/25/78
> > Submitter : Thomas Meyer <thomas@m3y3r.de>
> > Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
> > Eric W. Biederman <ebiederm@xmission.com>
> > 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()).
It's now in Linus' tree.
Thomas (Meyer), are there any regressions left with the latest -git tree
plus the MSI fix?
> Greetings,
> Rafael
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [4/5] 2.6.21-rc5: known regressions
@ 2007-03-27 22:29 ` Adrian Bunk
0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27 22:29 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Thomas Gleixner, Eric W. Biederman, Linus Torvalds,
Andrew Morton, linux-pm, Linux Kernel Mailing List, Thomas Meyer
On Tue, Mar 27, 2007 at 12:09:13PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, 27 March 2007 03:59, Adrian Bunk wrote:
> > 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:
>
> > Subject : suspend to disk: keypress required for power down
> > References : http://lkml.org/lkml/2007/3/25/78
> > Submitter : Thomas Meyer <thomas@m3y3r.de>
> > Status : unknown
>
> > Subject : suspend to disk: non-boot cpus are disabled again
> > References : http://lkml.org/lkml/2007/3/25/78
> > Submitter : Thomas Meyer <thomas@m3y3r.de>
> > Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
> > Eric W. Biederman <ebiederm@xmission.com>
> > 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()).
It's now in Linus' tree.
Thomas (Meyer), are there any regressions left with the latest -git tree
plus the MSI fix?
> Greetings,
> Rafael
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [4/5] 2.6.21-rc5: known regressions
2007-03-27 22:29 ` Adrian Bunk
@ 2007-03-27 22:45 ` Thomas Meyer
-1 siblings, 0 replies; 128+ messages in thread
From: Thomas Meyer @ 2007-03-27 22:45 UTC (permalink / raw)
To: Adrian Bunk
Cc: Rafael J. Wysocki, Linus Torvalds, Andrew Morton,
Linux Kernel Mailing List, Eric W. Biederman, pavel, linux-pm,
Thomas Gleixner
Adrian Bunk schrieb:
> 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.
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [4/5] 2.6.21-rc5: known regressions
2007-03-27 1:59 ` Adrian Bunk
` (2 preceding siblings ...)
(?)
@ 2007-03-28 12:19 ` Ingo Molnar
2007-03-28 12:41 ` Ingo Molnar
-1 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-28 12:19 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, linux-kernel, Eric W. Biederman,
Thomas Meyer, Frederic Riss, Marcus Better
* Adrian Bunk <bunk@stusta.de> wrote:
> 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 <thomas@m3y3r.de>
> Frédéric Riss <frederic.riss@gmail.com>
> Marcus Better <marcus@better.se>
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [4/5] 2.6.21-rc5: known regressions
2007-03-28 12:19 ` Ingo Molnar
@ 2007-03-28 12:41 ` Ingo Molnar
2007-03-28 13:03 ` Ingo Molnar
0 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-28 12:41 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, linux-kernel, Eric W. Biederman,
Thomas Meyer, Frederic Riss, Marcus Better
* Ingo Molnar <mingo@elte.hu> wrote:
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [4/5] 2.6.21-rc5: known regressions
2007-03-28 12:41 ` Ingo Molnar
@ 2007-03-28 13:03 ` Ingo Molnar
2007-03-28 13:06 ` [patch] MSI-X: fix resume crash Ingo Molnar
0 siblings, 1 reply; 128+ messages in thread
From: Ingo Molnar @ 2007-03-28 13:03 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, linux-kernel, Eric W. Biederman,
Thomas Meyer, Frederic Riss, Marcus Better
* Ingo Molnar <mingo@elte.hu> wrote:
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* [patch] MSI-X: fix resume crash
2007-03-28 13:03 ` Ingo Molnar
@ 2007-03-28 13:06 ` Ingo Molnar
2007-03-28 13:31 ` Eric W. Biederman
2007-03-29 4:30 ` Len Brown
0 siblings, 2 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-28 13:06 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, linux-kernel, Eric W. Biederman,
Thomas Meyer, Frederic Riss, Marcus Better, Len Brown
* Ingo Molnar <mingo@elte.hu> wrote:
> [...] 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 <ebiederm@xmission.com>
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 <ebiederm@xmission.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
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
===================================================================
--- linux.orig/arch/cris/arch-v32/drivers/pci/bios.c
+++ 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)
Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
===================================================================
--- linux.orig/arch/frv/mb93090-mb00/pci-vdk.c
+++ 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;
}
Index: linux/arch/i386/pci/common.c
===================================================================
--- linux.orig/arch/i386/pci/common.c
+++ 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);
}
Index: linux/arch/ia64/pci/pci.c
===================================================================
--- linux.orig/arch/ia64/pci/pci.c
+++ 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
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [patch] MSI-X: fix resume crash
2007-03-28 13:06 ` [patch] MSI-X: fix resume crash Ingo Molnar
@ 2007-03-28 13:31 ` Eric W. Biederman
2007-03-28 13:36 ` Ingo Molnar
2007-03-29 4:30 ` Len Brown
1 sibling, 1 reply; 128+ messages in thread
From: Eric W. Biederman @ 2007-03-28 13:31 UTC (permalink / raw)
To: Ingo Molnar
Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel,
Thomas Meyer, Frederic Riss, Marcus Better, Len Brown
Ingo Molnar <mingo@elte.hu> writes:
> * Ingo Molnar <mingo@elte.hu> wrote:
>
>> [...] 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" <ebiederm@xmission.com>
> ---------------------->
> Subject: [patch] MSI-X: fix resume crash
> From: Eric W. Biederman <ebiederm@xmission.com>
>
> 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 <ebiederm@xmission.com>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
> 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
> ===================================================================
> --- linux.orig/arch/cris/arch-v32/drivers/pci/bios.c
> +++ 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)
> Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
> ===================================================================
> --- linux.orig/arch/frv/mb93090-mb00/pci-vdk.c
> +++ 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;
> }
> Index: linux/arch/i386/pci/common.c
> ===================================================================
> --- linux.orig/arch/i386/pci/common.c
> +++ 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);
> }
> Index: linux/arch/ia64/pci/pci.c
> ===================================================================
> --- linux.orig/arch/ia64/pci/pci.c
> +++ 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
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [patch] MSI-X: fix resume crash
2007-03-28 13:31 ` Eric W. Biederman
@ 2007-03-28 13:36 ` Ingo Molnar
0 siblings, 0 replies; 128+ messages in thread
From: Ingo Molnar @ 2007-03-28 13:36 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel,
Thomas Meyer, Frederic Riss, Marcus Better, Len Brown, Luck,
Tony
* Eric W. Biederman <ebiederm@xmission.com> wrote:
> > 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" <ebiederm@xmission.com>
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 <ebiederm@xmission.com>
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.
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.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
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
===================================================================
--- linux.orig/arch/cris/arch-v32/drivers/pci/bios.c
+++ 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)
Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
===================================================================
--- linux.orig/arch/frv/mb93090-mb00/pci-vdk.c
+++ 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;
}
Index: linux/arch/i386/pci/common.c
===================================================================
--- linux.orig/arch/i386/pci/common.c
+++ 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);
}
Index: linux/arch/ia64/pci/pci.c
===================================================================
--- linux.orig/arch/ia64/pci/pci.c
+++ 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [patch] MSI-X: fix resume crash
2007-03-28 13:06 ` [patch] MSI-X: fix resume crash Ingo Molnar
2007-03-28 13:31 ` Eric W. Biederman
@ 2007-03-29 4:30 ` Len Brown
2007-03-29 4:57 ` Eric W. Biederman
1 sibling, 1 reply; 128+ messages in thread
From: Len Brown @ 2007-03-29 4:30 UTC (permalink / raw)
To: Ingo Molnar, luming.yu
Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, linux-kernel,
Eric W. Biederman, Thomas Meyer, Frederic Riss, Marcus Better
> 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);
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.
> 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.
> 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
> From: Eric W. Biederman <ebiederm@xmission.com>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
> 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
> ===================================================================
> --- linux.orig/arch/cris/arch-v32/drivers/pci/bios.c
> +++ 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)
> Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
> ===================================================================
> --- linux.orig/arch/frv/mb93090-mb00/pci-vdk.c
> +++ 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;
> }
> Index: linux/arch/i386/pci/common.c
> ===================================================================
> --- linux.orig/arch/i386/pci/common.c
> +++ 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);
> }
> Index: linux/arch/ia64/pci/pci.c
> ===================================================================
> --- linux.orig/arch/ia64/pci/pci.c
> +++ 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [patch] MSI-X: fix resume crash
2007-03-29 4:30 ` Len Brown
@ 2007-03-29 4:57 ` Eric W. Biederman
0 siblings, 0 replies; 128+ messages in thread
From: Eric W. Biederman @ 2007-03-29 4:57 UTC (permalink / raw)
To: Len Brown
Cc: Ingo Molnar, luming.yu, Adrian Bunk, Linus Torvalds,
Andrew Morton, linux-kernel, Thomas Meyer, Frederic Riss,
Marcus Better
Len Brown <lenb@kernel.org> writes:
>> 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);
>
> 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...
> My understanding is that Luming Yu has cobbled IA64 S4 support
> together for a future release though.
>
>> 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.
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.
>> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* [5/5] 2.6.21-rc5: known regressions
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-27 1:59 ` Adrian Bunk
2007-03-26 8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
` (18 subsequent siblings)
19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27 1:59 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Frédéric Riss, Tino Keitel,
Thomas Gleixner, John Stultz, pavel, linux-pm, Mike Harris,
Stephane Casset, Michael S. Tsirkin, Jeff Chua, Ingo Molnar,
Soeren Sonnenburg, Tejun Heo, Rafael J. Wysocki
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 : 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 <frederic.riss@gmail.com>
Tino Keitel <tino.keitel@gmx.de>
Caused-By : Thomas Gleixner <tglx@linutronix.de>
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 <atarimike@wavecable.com>
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 <sept@logidee.com>
Caused-By : John Stultz <johnstul@us.ibm.com>
commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd
Handled-By : John Stultz <johnstul@us.ibm.com>
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 <mst@mellanox.co.il>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
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 <mst@mellanox.co.il>
Jeff Chua <jeff.chua.linux@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Ingo Molnar <mingo@elte.hu>
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 <mst@mellanox.co.il>
Soeren Sonnenburg <kernel@nn7.de>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Ingo Molnar <mingo@elte.hu>
Tejun Heo <htejun@gmail.com>
Rafael J. Wysocki <rjw@sisk.pl>
Status : unknown
Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <jeff.chua.linux@gmail.com>
Status : unknown
^ permalink raw reply [flat|nested] 128+ messages in thread* [5/5] 2.6.21-rc5: known regressions
@ 2007-03-27 1:59 ` Adrian Bunk
0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-27 1:59 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Soeren Sonnenburg, Tejun Heo, Frédéric Riss, Jeff Chua,
John Stultz, Stephane Casset, Tino Keitel, linux-pm,
Linux Kernel Mailing List, Michael S. Tsirkin, Thomas Gleixner,
Ingo Molnar, Mike Harris
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 : 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 <frederic.riss@gmail.com>
Tino Keitel <tino.keitel@gmx.de>
Caused-By : Thomas Gleixner <tglx@linutronix.de>
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 <atarimike@wavecable.com>
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 <sept@logidee.com>
Caused-By : John Stultz <johnstul@us.ibm.com>
commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd
Handled-By : John Stultz <johnstul@us.ibm.com>
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 <mst@mellanox.co.il>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
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 <mst@mellanox.co.il>
Jeff Chua <jeff.chua.linux@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Ingo Molnar <mingo@elte.hu>
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 <mst@mellanox.co.il>
Soeren Sonnenburg <kernel@nn7.de>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Ingo Molnar <mingo@elte.hu>
Tejun Heo <htejun@gmail.com>
Rafael J. Wysocki <rjw@sisk.pl>
Status : unknown
Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <jeff.chua.linux@gmail.com>
Status : unknown
^ permalink raw reply [flat|nested] 128+ messages in thread
* ATA ACPI (was Re: Linux 2.6.21-rc5)
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
` (9 preceding siblings ...)
2007-03-27 1:59 ` Adrian Bunk
@ 2007-03-27 5:51 ` Jeff Garzik
2007-03-27 5:54 ` Tejun Heo
2007-03-27 17:07 ` Linus Torvalds
2007-03-27 6:17 ` Linux 2.6.21-rc5 Andrew Morton
` (8 subsequent siblings)
19 siblings, 2 replies; 128+ messages in thread
From: Jeff Garzik @ 2007-03-27 5:51 UTC (permalink / raw)
To: IDE/ATA development list
Cc: Linus Torvalds, Linux Kernel Mailing List, Alan, Tejun Heo,
Len Brown, Kristen Carlson Accardi
Linus Torvalds wrote:
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: ATA ACPI (was Re: Linux 2.6.21-rc5)
2007-03-27 5:51 ` ATA ACPI (was Re: Linux 2.6.21-rc5) Jeff Garzik
@ 2007-03-27 5:54 ` Tejun Heo
2007-03-27 21:32 ` Pavel Machek
2007-03-27 17:07 ` Linus Torvalds
1 sibling, 1 reply; 128+ messages in thread
From: Tejun Heo @ 2007-03-27 5:54 UTC (permalink / raw)
To: Jeff Garzik
Cc: IDE/ATA development list, Linus Torvalds,
Linux Kernel Mailing List, Alan, Len Brown,
Kristen Carlson Accardi
Jeff Garzik wrote:
> Linus Torvalds wrote:
>> 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... :)
I second disabling ACPI for 2.6.21.
--
tejun
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: ATA ACPI (was Re: Linux 2.6.21-rc5)
2007-03-27 5:54 ` Tejun Heo
@ 2007-03-27 21:32 ` Pavel Machek
2007-03-28 9:51 ` Tejun Heo
0 siblings, 1 reply; 128+ messages in thread
From: Pavel Machek @ 2007-03-27 21:32 UTC (permalink / raw)
To: Tejun Heo
Cc: Jeff Garzik, IDE/ATA development list, Linus Torvalds,
Linux Kernel Mailing List, Alan, Len Brown,
Kristen Carlson Accardi
Hi!
> >>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... :)
>
> 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...
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: ATA ACPI (was Re: Linux 2.6.21-rc5)
2007-03-27 21:32 ` Pavel Machek
@ 2007-03-28 9:51 ` Tejun Heo
0 siblings, 0 replies; 128+ messages in thread
From: Tejun Heo @ 2007-03-28 9:51 UTC (permalink / raw)
To: Pavel Machek
Cc: Jeff Garzik, IDE/ATA development list, Linus Torvalds,
Linux Kernel Mailing List, Alan, Len Brown,
Kristen Carlson Accardi
Pavel Machek wrote:
> Hi!
>
>>>> 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... :)
>> 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.
--
tejun
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: ATA ACPI (was Re: Linux 2.6.21-rc5)
2007-03-27 5:51 ` ATA ACPI (was Re: Linux 2.6.21-rc5) Jeff Garzik
2007-03-27 5:54 ` Tejun Heo
@ 2007-03-27 17:07 ` Linus Torvalds
2007-03-27 18:48 ` Jeff Garzik
1 sibling, 1 reply; 128+ messages in thread
From: Linus Torvalds @ 2007-03-27 17:07 UTC (permalink / raw)
To: Jeff Garzik
Cc: IDE/ATA development list, Linux Kernel Mailing List, Alan,
Tejun Heo, Len Brown, Kristen Carlson Accardi
On Tue, 27 Mar 2007, Jeff Garzik wrote:
>
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: ATA ACPI (was Re: Linux 2.6.21-rc5)
2007-03-27 17:07 ` Linus Torvalds
@ 2007-03-27 18:48 ` Jeff Garzik
0 siblings, 0 replies; 128+ messages in thread
From: Jeff Garzik @ 2007-03-27 18:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: IDE/ATA development list, Linux Kernel Mailing List, Alan,
Tejun Heo, Len Brown, Kristen Carlson Accardi
Linus Torvalds wrote:
>
> On Tue, 27 Mar 2007, Jeff Garzik wrote:
>> 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.
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Linux 2.6.21-rc5
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
` (10 preceding siblings ...)
2007-03-27 5:51 ` ATA ACPI (was Re: Linux 2.6.21-rc5) Jeff Garzik
@ 2007-03-27 6:17 ` Andrew Morton
2007-03-27 6:20 ` Greg KH
` (4 more replies)
2007-03-27 18:34 ` Michal Piotrowski
` (7 subsequent siblings)
19 siblings, 5 replies; 128+ messages in thread
From: Andrew Morton @ 2007-03-27 6:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Andi Kleen, Jaroslav Kysela,
Takashi Iwai, Ben Dooks, Greg KH, Dmitry Torokhov
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 ;)
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Linux 2.6.21-rc5
2007-03-27 6:17 ` Linux 2.6.21-rc5 Andrew Morton
@ 2007-03-27 6:20 ` Greg KH
2007-03-27 16:49 ` Jesse Barnes
2007-03-27 9:49 ` Takashi Iwai
` (3 subsequent siblings)
4 siblings, 1 reply; 128+ messages in thread
From: Greg KH @ 2007-03-27 6:20 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, Linux Kernel Mailing List, Andi Kleen,
Jaroslav Kysela, Takashi Iwai, Ben Dooks, Dmitry Torokhov
On Mon, Mar 26, 2007 at 10:17:31PM -0800, Andrew Morton wrote:
>
> 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.
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Linux 2.6.21-rc5
2007-03-27 6:20 ` Greg KH
@ 2007-03-27 16:49 ` Jesse Barnes
0 siblings, 0 replies; 128+ messages in thread
From: Jesse Barnes @ 2007-03-27 16:49 UTC (permalink / raw)
To: Greg KH
Cc: Andrew Morton, Linus Torvalds, Linux Kernel Mailing List,
Andi Kleen, Jaroslav Kysela, Takashi Iwai, Ben Dooks,
Dmitry Torokhov
On Monday, March 26, 2007 11:20 pm Greg KH wrote:
> Already in Linus's tree.
>
> > 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Linux 2.6.21-rc5
2007-03-27 6:17 ` Linux 2.6.21-rc5 Andrew Morton
2007-03-27 6:20 ` Greg KH
@ 2007-03-27 9:49 ` Takashi Iwai
2007-03-27 12:25 ` Andi Kleen
` (2 subsequent siblings)
4 siblings, 0 replies; 128+ messages in thread
From: Takashi Iwai @ 2007-03-27 9:49 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, Linux Kernel Mailing List, Andi Kleen,
Jaroslav Kysela, Ben Dooks, Greg KH, Dmitry Torokhov
At Mon, 26 Mar 2007 22:17:31 -0800,
Andrew Morton wrote:
>
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Linux 2.6.21-rc5
2007-03-27 6:17 ` Linux 2.6.21-rc5 Andrew Morton
2007-03-27 6:20 ` Greg KH
2007-03-27 9:49 ` Takashi Iwai
@ 2007-03-27 12:25 ` Andi Kleen
2007-03-27 16:33 ` Andrew Morton
2007-03-27 12:43 ` Dmitry Torokhov
2007-03-28 22:32 ` Tilman Schmidt
4 siblings, 1 reply; 128+ messages in thread
From: Andi Kleen @ 2007-03-27 12:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, Linux Kernel Mailing List, Jaroslav Kysela,
Takashi Iwai, Ben Dooks, Greg KH, Dmitry Torokhov
On Tuesday 27 March 2007 08:17, Andrew Morton wrote:
>
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Linux 2.6.21-rc5
2007-03-27 12:25 ` Andi Kleen
@ 2007-03-27 16:33 ` Andrew Morton
0 siblings, 0 replies; 128+ messages in thread
From: Andrew Morton @ 2007-03-27 16:33 UTC (permalink / raw)
To: Andi Kleen, Parag Warudkar
Cc: Linus Torvalds, Linux Kernel Mailing List, Jaroslav Kysela,
Takashi Iwai, Ben Dooks, Greg KH, Dmitry Torokhov
On Tue, 27 Mar 2007 14:25:07 +0200 Andi Kleen <ak@suse.de> wrote:
> On Tuesday 27 March 2007 08:17, Andrew Morton wrote:
> >
> > 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.
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Linux 2.6.21-rc5
2007-03-27 6:17 ` Linux 2.6.21-rc5 Andrew Morton
` (2 preceding siblings ...)
2007-03-27 12:25 ` Andi Kleen
@ 2007-03-27 12:43 ` Dmitry Torokhov
2007-03-28 22:32 ` Tilman Schmidt
4 siblings, 0 replies; 128+ messages in thread
From: Dmitry Torokhov @ 2007-03-27 12:43 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, Linux Kernel Mailing List, Andi Kleen,
Jaroslav Kysela, Takashi Iwai, Ben Dooks, Greg KH
On 3/27/07, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> 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).
--
Dmitry
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Linux 2.6.21-rc5
2007-03-27 6:17 ` Linux 2.6.21-rc5 Andrew Morton
` (3 preceding siblings ...)
2007-03-27 12:43 ` Dmitry Torokhov
@ 2007-03-28 22:32 ` Tilman Schmidt
4 siblings, 0 replies; 128+ messages in thread
From: Tilman Schmidt @ 2007-03-28 22:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Kernel Mailing List
Am 27.03.2007 08:17 schrieb 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.
[...]
> 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
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeoeffnet mindestens haltbar bis: (siehe Rueckseite)
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Linux 2.6.21-rc5
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
` (11 preceding siblings ...)
2007-03-27 6:17 ` Linux 2.6.21-rc5 Andrew Morton
@ 2007-03-27 18:34 ` Michal Piotrowski
2007-03-27 22:29 ` Pavel Machek
2007-03-27 18:53 ` Michal Piotrowski
` (6 subsequent siblings)
19 siblings, 1 reply; 128+ messages in thread
From: Michal Piotrowski @ 2007-03-27 18:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Hemminger, Jeff Garzik, Rafael J. Wysocki, Pavel Machek,
Linux Kernel Mailing List
Hi,
On 26/03/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> 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 <shemminger@linux-foundation.org>
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 <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
:040000 040000 d3d4335e6cba330b7880b4787fbe48733e69f8fc
5845b004228d811de912a55da6a7843b72f23f81 M drivers
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5/git-config2
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/)
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Linux 2.6.21-rc5
2007-03-27 18:34 ` Michal Piotrowski
@ 2007-03-27 22:29 ` Pavel Machek
2007-03-27 22:55 ` Michal Piotrowski
0 siblings, 1 reply; 128+ messages in thread
From: Pavel Machek @ 2007-03-27 22:29 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Linus Torvalds, Stephen Hemminger, Jeff Garzik,
Rafael J. Wysocki, Linux Kernel Mailing List
Hi!
> >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 <shemminger@linux-foundation.org>
> 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 <shemminger@linux-foundation.org>
> Signed-off-by: Jeff Garzik <jeff@garzik.org>
>
> :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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Linux 2.6.21-rc5
2007-03-27 22:29 ` Pavel Machek
@ 2007-03-27 22:55 ` Michal Piotrowski
0 siblings, 0 replies; 128+ messages in thread
From: Michal Piotrowski @ 2007-03-27 22:55 UTC (permalink / raw)
To: Pavel Machek
Cc: Michal Piotrowski, Linus Torvalds, Stephen Hemminger,
Jeff Garzik, Rafael J. Wysocki, Linux Kernel Mailing List
Pavel Machek napisał(a):
> Hi!
>>> 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 <shemminger@linux-foundation.org>
>> 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 <shemminger@linux-foundation.org>
>> Signed-off-by: Jeff Garzik <jeff@garzik.org>
>>
>> :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
> Pavel
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/)
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Linux 2.6.21-rc5
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
` (12 preceding siblings ...)
2007-03-27 18:34 ` Michal Piotrowski
@ 2007-03-27 18:53 ` Michal Piotrowski
2007-03-28 14:30 ` Andi Kleen
[not found] ` <20070327230024.GJ16477@stusta.de>
` (5 subsequent siblings)
19 siblings, 1 reply; 128+ messages in thread
From: Michal Piotrowski @ 2007-03-27 18:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Andrew Morton, Andi Kleen
Linus Torvalds napisał(a):
> 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
=======================
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
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/)
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Linux 2.6.21-rc5
2007-03-27 18:53 ` Michal Piotrowski
@ 2007-03-28 14:30 ` Andi Kleen
2007-03-28 14:56 ` Michal Piotrowski
2007-03-28 17:56 ` Linus Torvalds
0 siblings, 2 replies; 128+ messages in thread
From: Andi Kleen @ 2007-03-28 14:30 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Linus Torvalds, Linux Kernel Mailing List, Andrew Morton
On Tuesday 27 March 2007 20:53, Michal Piotrowski wrote:
> Linus Torvalds napisał(a):
> > 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?
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 <ak@suse.de>
Index: linux/arch/i386/kernel/nmi.c
===================================================================
--- linux.orig/arch/i386/kernel/nmi.c
+++ 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)
Index: linux/arch/x86_64/kernel/nmi.c
===================================================================
--- linux.orig/arch/x86_64/kernel/nmi.c
+++ 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)
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Linux 2.6.21-rc5
2007-03-28 14:30 ` Andi Kleen
@ 2007-03-28 14:56 ` Michal Piotrowski
2007-03-28 16:12 ` Jiri Kosina
2007-03-28 17:56 ` Linus Torvalds
1 sibling, 1 reply; 128+ messages in thread
From: Michal Piotrowski @ 2007-03-28 14:56 UTC (permalink / raw)
To: Andi Kleen
Cc: Michal Piotrowski, Linus Torvalds, Linux Kernel Mailing List,
Andrew Morton
Andi Kleen napisał(a):
> On Tuesday 27 March 2007 20:53, Michal Piotrowski wrote:
>> Linus Torvalds napisał(a):
>>> 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?
>
> 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/)
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Linux 2.6.21-rc5
2007-03-28 14:56 ` Michal Piotrowski
@ 2007-03-28 16:12 ` Jiri Kosina
2007-03-28 16:51 ` Michal Piotrowski
0 siblings, 1 reply; 128+ messages in thread
From: Jiri Kosina @ 2007-03-28 16:12 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Andi Kleen, Linus Torvalds, Linux Kernel Mailing List,
Andrew Morton, Philippe Elie
On Wed, 28 Mar 2007, Michal Piotrowski wrote:
> 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 <jkosina@suse.cz>
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 <jkosina@suse.cz>
drivers/oprofile/event_buffer.c | 5 +++--
drivers/oprofile/oprofilefs.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/oprofile/event_buffer.c b/drivers/oprofile/event_buffer.c
index 00e937e..e7fbac5 100644
--- a/drivers/oprofile/event_buffer.c
+++ b/drivers/oprofile/event_buffer.c
@@ -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;
diff --git a/drivers/oprofile/oprofilefs.c b/drivers/oprofile/oprofilefs.c
index 6e67b42..8543cb2 100644
--- a/drivers/oprofile/oprofilefs.c
+++ b/drivers/oprofile/oprofilefs.c
@@ -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;
}
^ permalink raw reply related [flat|nested] 128+ messages in thread* Re: Linux 2.6.21-rc5
2007-03-28 16:12 ` Jiri Kosina
@ 2007-03-28 16:51 ` Michal Piotrowski
0 siblings, 0 replies; 128+ messages in thread
From: Michal Piotrowski @ 2007-03-28 16:51 UTC (permalink / raw)
To: Jiri Kosina
Cc: Andi Kleen, Linus Torvalds, Linux Kernel Mailing List,
Andrew Morton, Philippe Elie
On 28/03/07, Jiri Kosina <jikos@jikos.cz> wrote:
> On Wed, 28 Mar 2007, Michal Piotrowski wrote:
>
> > 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?
>
Problem seems to be fixed. Thanks!
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/)
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Linux 2.6.21-rc5
2007-03-28 14:30 ` Andi Kleen
2007-03-28 14:56 ` Michal Piotrowski
@ 2007-03-28 17:56 ` Linus Torvalds
1 sibling, 0 replies; 128+ messages in thread
From: Linus Torvalds @ 2007-03-28 17:56 UTC (permalink / raw)
To: Andi Kleen
Cc: Michal Piotrowski, Linux Kernel Mailing List, Andrew Morton, Jiri Kosina
On Wed, 28 Mar 2007, Andi Kleen wrote:
>
> Can you test this patch please?
This patch is totally broken.
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
[parent not found: <20070327230024.GJ16477@stusta.de>]
* Re: 2.6.21-rc5: known regressions with patches
[not found] ` <20070327230024.GJ16477@stusta.de>
@ 2007-03-27 23:10 ` Rafael J. Wysocki
2007-03-28 0:50 ` Jay Cliburn
1 sibling, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2007-03-27 23:10 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Maxim Levitsky, tigran
On Wednesday, 28 March 2007 01:00, Adrian Bunk wrote:
> 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 <maximlevitsky@gmail.com>
> Caused-By : Rafael J. Wysocki <rjw@sisk.pl>
> commit e3c7db621bed4afb8e231cb005057f2feb5db557
> commit ed746e3b18f4df18afa3763155972c5835f284c5
> commit 259130526c267550bc365d3015917d90667732f1
> Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: 2.6.21-rc5: known regressions with patches
[not found] ` <20070327230024.GJ16477@stusta.de>
2007-03-27 23:10 ` 2.6.21-rc5: known regressions with patches Rafael J. Wysocki
@ 2007-03-28 0:50 ` Jay Cliburn
1 sibling, 0 replies; 128+ messages in thread
From: Jay Cliburn @ 2007-03-28 0:50 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, netdev,
Jose Alberto Reguero, Chris Snook
On Wed, 28 Mar 2007 01:00:24 +0200
Adrian Bunk <bunk@stusta.de> wrote:
> Subject : atl1 net driver: problem with sockets
> References : http://lkml.org/lkml/2007/3/21/248
> Submitter : Jose Alberto Reguero <jareguero@telefonica.net>
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* [1/4] 2.6.21-rc5: known regressions (v2)
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-30 21:32 ` Adrian Bunk
2007-03-26 8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
` (18 subsequent siblings)
19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:32 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Oliver Pinter, Ingo Molnar, Greg KH,
Kay Sievers, Michal Jaegermann, lenb, linux-acpi, jgarzik,
linux-ide, Mathieu Bérard, Tejun Heo
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 <oliver.pntr@gmail.com>
Status : unknown
Subject : hung bootup in various drivers
References : http://lkml.org/lkml/2007/3/30/68
Submitter : Ingo Molnar <mingo@elte.hu>
Handled-By : Ingo Molnar <mingo@elte.hu>
Greg KH <gregkh@suse.de>
Kay Sievers <kay.sievers@vrfy.org>
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 <michal@ellpspace.math.ualberta.ca>
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 <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 128+ messages in thread* [1/4] 2.6.21-rc5: known regressions (v2)
@ 2007-03-30 21:32 ` Adrian Bunk
0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:32 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Oliver Pinter, Ingo Molnar, Greg KH,
Kay Sievers, Michal Jaegermann, lenb, linux-acpi, jgarzik,
linux-ide, Mathieu Bérard, Tejun Heo
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 <oliver.pntr@gmail.com>
Status : unknown
Subject : hung bootup in various drivers
References : http://lkml.org/lkml/2007/3/30/68
Submitter : Ingo Molnar <mingo@elte.hu>
Handled-By : Ingo Molnar <mingo@elte.hu>
Greg KH <gregkh@suse.de>
Kay Sievers <kay.sievers@vrfy.org>
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 <michal@ellpspace.math.ualberta.ca>
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 <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch : http://lkml.org/lkml/2007/2/22/8
Status : possible patch available
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [1/4] 2.6.21-rc5: known regressions (v2)
2007-03-30 21:32 ` Adrian Bunk
(?)
@ 2007-03-30 21:38 ` Greg KH
-1 siblings, 0 replies; 128+ messages in thread
From: Greg KH @ 2007-03-30 21:38 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Oliver Pinter, Ingo Molnar, Kay Sievers, Michal Jaegermann, lenb,
linux-acpi, jgarzik, linux-ide, Mathieu B??rard, Tejun Heo
On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> Subject : hung bootup in various drivers
> References : http://lkml.org/lkml/2007/3/30/68
> Submitter : Ingo Molnar <mingo@elte.hu>
> Handled-By : Ingo Molnar <mingo@elte.hu>
> Greg KH <gregkh@suse.de>
> Kay Sievers <kay.sievers@vrfy.org>
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [1/4] 2.6.21-rc5: known regressions (v2)
2007-03-30 21:32 ` Adrian Bunk
(?)
(?)
@ 2007-03-31 0:23 ` Michal Jaegermann
2007-03-31 15:01 ` Adrian Bunk
-1 siblings, 1 reply; 128+ messages in thread
From: Michal Jaegermann @ 2007-03-31 0:23 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linux Kernel Mailing List, linux-acpi, jgarzik, linux-ide, Tejun Heo
On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
>
> 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 <michal@ellpspace.math.ualberta.ca>
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [1/4] 2.6.21-rc5: known regressions (v2)
2007-03-31 0:23 ` Michal Jaegermann
@ 2007-03-31 15:01 ` Adrian Bunk
2007-03-31 16:42 ` Michal Jaegermann
0 siblings, 1 reply; 128+ messages in thread
From: Adrian Bunk @ 2007-03-31 15:01 UTC (permalink / raw)
To: Michal Jaegermann
Cc: Linux Kernel Mailing List, linux-acpi, jgarzik, linux-ide, Tejun Heo
On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote:
> On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> >
> > 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 <michal@ellpspace.math.ualberta.ca>
> > 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
If I understand this correctly, a plain 2.6.20 kernel is already broken?
> Michal
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [1/4] 2.6.21-rc5: known regressions (v2)
2007-03-31 15:01 ` Adrian Bunk
@ 2007-03-31 16:42 ` Michal Jaegermann
0 siblings, 0 replies; 128+ messages in thread
From: Michal Jaegermann @ 2007-03-31 16:42 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linux Kernel Mailing List, linux-acpi, jgarzik, linux-ide, Tejun Heo
On Sat, Mar 31, 2007 at 05:01:23PM +0200, Adrian Bunk wrote:
> On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote:
> > On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> > >
> > > 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 <michal@ellpspace.math.ualberta.ca>
> > > 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
>
> 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
^ permalink raw reply [flat|nested] 128+ messages in thread
* [2/4] 2.6.21-rc5: known regressions (v2)
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
` (15 preceding siblings ...)
2007-03-30 21:32 ` Adrian Bunk
@ 2007-03-30 21:32 ` Adrian Bunk
2007-03-30 21:32 ` Adrian Bunk
` (2 subsequent siblings)
19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:32 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Hans-Georg Rist, perex, alsa-devel,
Michal Piotrowski, Andi Kleen, Oliver Neukum, greg,
linux-usb-devel, Marcelo Tosatti, CIJOML, v4l-dvb-maintainer,
Ingo Molnar, Ayaz Abdulla, jgarzik, netdev
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 : snd_hda_intel doesn't work with ASUS M2V mainboard
References : http://bugzilla.kernel.org/show_bug.cgi?id=8273
Submitter : Hans-Georg Rist <hg.rist@web.de>
Status : unknown
Subject : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Status : unknown
Subject : hal daemon crashes after pulling a USB serial device
References : http://www.opensubscriber.com/message/linux-usb-devel@lists.sourceforge.net/6369800.html
Submitter : Andi Kleen <ak@suse.de>
Handled-By : Oliver Neukum <oneukum@suse.de>
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 <tino.keitel@gmx.de>
Caused-By : Marcelo Tosatti <marcelo@kvack.org>
commit 1d619f128ba911cd3e6d6ad3475f146eb92f5c27
Handled-By : Oliver Neukum <oneukum@suse.de>
Status : problem is being debuggged
Subject : USB: Oops when changing DVB-T adapter
References : http://lkml.org/lkml/2007/3/9/212
Submitter : CIJOML <cijoml@volny.cz>
Status : unknown
Subject : forcedeth: sporadic under-load crashes
References : http://lkml.org/lkml/2007/3/26/63
Submitter : Ingo Molnar <mingo@elte.hu>
Handled-By : Ingo Molnar <mingo@elte.hu>
Ayaz Abdulla <aabdulla@nvidia.com>
Status : problem is being debugged
^ permalink raw reply [flat|nested] 128+ messages in thread* [3/4] 2.6.21-rc5: known regressions (v2)
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-30 21:32 ` Adrian Bunk
2007-03-26 8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
` (18 subsequent siblings)
19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:32 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Len Brown, Jeremy Fitzhardinge, tigran, Michal Piotrowski,
adaplas, Soeren Sonnenburg, Marcus Better, linux-ide, Jens Axboe,
Thomas Gleixner, Stephen Hemminger, Maxim Levitsky, Mike Harris,
Jeff Chua, netdev, gregkh, linux-pm, Linux Kernel Mailing List,
linux-acpi, Eric W. Biederman, linux-pci, jgarzik,
Tobias Doerffel
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 : ThinkPad X60: resume no longer works (PCI related?)
References : http://lkml.org/lkml/2007/3/13/3
Submitter : Dave Jones <davej@redhat.com>
Jeremy Fitzhardinge <jeremy@goop.org>
Caused-By : PCI merge
commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
Rafael J. Wysocki <rjw@sisk.pl>
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 <tobias.doerffel@gmail.com>
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Len Brown <len.brown@intel.com>
Status : problem is being debugged
Subject : SATA breakage on resume
References : http://lkml.org/lkml/2007/3/7/233
Submitter : Thomas Gleixner <tglx@linutronix.de>
Soeren Sonnenburg <kernel@nn7.de>
Status : unknown
Subject : resume from RAM corrupts vesafb console
References : http://lkml.org/lkml/2007/3/26/76
Submitter : Marcus Better <marcus@better.se>
Handled-By : Pavel Machek <pavel@ucw.cz>
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 <jens.axboe@oracle.com>
Jeff Chua <jeff.chua.linux@gmail.com>
Status : unknown
Subject : MacBook Core Duo: suspend to memory wakeup hang
References : http://bugzilla.kernel.org/show_bug.cgi?id=8272
Submitter : Mike Harris <atarimike@wavecable.com>
Status : unknown
Subject : suspend to disk hangs (skge)
References : http://lkml.org/lkml/2007/3/27/212
Submitter : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Caused-By : Stephen Hemminger <shemminger@linux-foundation.org>
commit a504e64ab42bcc27074ea37405d06833ed6e0820
Status : unknown
Subject : suspend to disk hangs (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter : Maxim Levitsky <maximlevitsky@gmail.com>
Caused-By : Rafael J. Wysocki <rjw@sisk.pl>
commit e3c7db621bed4afb8e231cb005057f2feb5db557
commit ed746e3b18f4df18afa3763155972c5835f284c5
commit 259130526c267550bc365d3015917d90667732f1
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Patch : http://lkml.org/lkml/2007/3/25/71
Status : patch available
^ permalink raw reply [flat|nested] 128+ messages in thread* [3/4] 2.6.21-rc5: known regressions (v2)
@ 2007-03-30 21:32 ` Adrian Bunk
0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:32 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Dave Jones, Jeremy Fitzhardinge,
Eric W. Biederman, Rafael J. Wysocki, pavel, linux-pm, gregkh,
linux-pci, Tobias Doerffel, Len Brown, linux-acpi,
Thomas Gleixner, Soeren Sonnenburg, jgarzik, linux-ide,
Marcus Better, adaplas, Jens Axboe, Jeff Chua, Mike Harris,
Michal Piotrowski, Stephen Hemminger, netdev, Maxim Levitsky,
tigran
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 : ThinkPad X60: resume no longer works (PCI related?)
References : http://lkml.org/lkml/2007/3/13/3
Submitter : Dave Jones <davej@redhat.com>
Jeremy Fitzhardinge <jeremy@goop.org>
Caused-By : PCI merge
commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
Rafael J. Wysocki <rjw@sisk.pl>
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 <tobias.doerffel@gmail.com>
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Len Brown <len.brown@intel.com>
Status : problem is being debugged
Subject : SATA breakage on resume
References : http://lkml.org/lkml/2007/3/7/233
Submitter : Thomas Gleixner <tglx@linutronix.de>
Soeren Sonnenburg <kernel@nn7.de>
Status : unknown
Subject : resume from RAM corrupts vesafb console
References : http://lkml.org/lkml/2007/3/26/76
Submitter : Marcus Better <marcus@better.se>
Handled-By : Pavel Machek <pavel@ucw.cz>
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 <jens.axboe@oracle.com>
Jeff Chua <jeff.chua.linux@gmail.com>
Status : unknown
Subject : MacBook Core Duo: suspend to memory wakeup hang
References : http://bugzilla.kernel.org/show_bug.cgi?id=8272
Submitter : Mike Harris <atarimike@wavecable.com>
Status : unknown
Subject : suspend to disk hangs (skge)
References : http://lkml.org/lkml/2007/3/27/212
Submitter : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Caused-By : Stephen Hemminger <shemminger@linux-foundation.org>
commit a504e64ab42bcc27074ea37405d06833ed6e0820
Status : unknown
Subject : suspend to disk hangs (microcode driver)
References : http://lkml.org/lkml/2007/3/16/126
Submitter : Maxim Levitsky <maximlevitsky@gmail.com>
Caused-By : Rafael J. Wysocki <rjw@sisk.pl>
commit e3c7db621bed4afb8e231cb005057f2feb5db557
commit ed746e3b18f4df18afa3763155972c5835f284c5
commit 259130526c267550bc365d3015917d90667732f1
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Patch : http://lkml.org/lkml/2007/3/25/71
Status : patch available
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [3/4] 2.6.21-rc5: known regressions (v2)
2007-03-30 21:32 ` Adrian Bunk
(?)
@ 2007-03-31 2:52 ` Jeff Chua
-1 siblings, 0 replies; 128+ messages in thread
From: Jeff Chua @ 2007-03-31 2:52 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Dave Jones, Jeremy Fitzhardinge, Eric W. Biederman,
Rafael J. Wysocki, pavel, linux-pm, gregkh, linux-pci,
Tobias Doerffel, Len Brown, linux-acpi, Thomas Gleixner,
Soeren Sonnenburg, jgarzik, linux-ide, Marcus Better, adaplas,
Jens Axboe, Mike Harris, Michal Piotrowski, Stephen Hemminger
On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:
> 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 <jens.axboe@oracle.com>
> Jeff Chua <jeff.chua.linux@gmail.com>
> Status : unknown
Fixed with CONFIG_NO_HZ unset and patch from Maxim
(http://lkml.org/lkml/2007/3/29/108).
Thanks,
Jeff,
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [3/4] 2.6.21-rc5: known regressions (v2)
@ 2007-03-31 2:52 ` Jeff Chua
0 siblings, 0 replies; 128+ messages in thread
From: Jeff Chua @ 2007-03-31 2:52 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Dave Jones, Jeremy Fitzhardinge, Eric W. Biederman,
Rafael J. Wysocki, pavel, linux-pm, gregkh, linux-pci,
Tobias Doerffel, Len Brown, linux-acpi, Thomas Gleixner,
Soeren Sonnenburg, jgarzik, linux-ide, Marcus Better, adaplas,
Jens Axboe, Mike Harris, Michal Piotrowski, Stephen Hemminger
On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:
> 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 <jens.axboe@oracle.com>
> Jeff Chua <jeff.chua.linux@gmail.com>
> Status : unknown
Fixed with CONFIG_NO_HZ unset and patch from Maxim
(http://lkml.org/lkml/2007/3/29/108).
Thanks,
Jeff,
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [3/4] 2.6.21-rc5: known regressions (v2)
@ 2007-03-31 2:52 ` Jeff Chua
0 siblings, 0 replies; 128+ messages in thread
From: Jeff Chua @ 2007-03-31 2:52 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Dave Jones, Jeremy Fitzhardinge, Eric W. Biederman,
Rafael J. Wysocki, pavel, linux-pm, gregkh, linux-pci,
Tobias Doerffel, Len Brown, linux-acpi, Thomas Gleixner,
Soeren Sonnenburg, jgarzik, linux-ide, Marcus Better, adaplas,
Jens Axboe, Mike Harris, Michal Piotrowski, Stephen Hemminger,
netdev, Maxim Levitsky, tigran
On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:
> 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 <jens.axboe@oracle.com>
> Jeff Chua <jeff.chua.linux@gmail.com>
> Status : unknown
Fixed with CONFIG_NO_HZ unset and patch from Maxim
(http://lkml.org/lkml/2007/3/29/108).
Thanks,
Jeff,
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [3/4] 2.6.21-rc5: known regressions (v2)
2007-03-31 2:52 ` Jeff Chua
(?)
(?)
@ 2007-03-31 3:16 ` Adrian Bunk
2007-03-31 11:08 ` Jens Axboe
-1 siblings, 1 reply; 128+ messages in thread
From: Adrian Bunk @ 2007-03-31 3:16 UTC (permalink / raw)
To: Jeff Chua
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, pavel,
linux-pm, Len Brown, linux-acpi, Jens Axboe, Maxim Levitsky
On Sat, Mar 31, 2007 at 10:52:59AM +0800, Jeff Chua wrote:
> On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:
>
> >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 <jens.axboe@oracle.com>
> > Jeff Chua <jeff.chua.linux@gmail.com>
> >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?
> Thanks,
> Jeff,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [3/4] 2.6.21-rc5: known regressions (v2)
2007-03-31 3:16 ` Adrian Bunk
@ 2007-03-31 11:08 ` Jens Axboe
0 siblings, 0 replies; 128+ messages in thread
From: Jens Axboe @ 2007-03-31 11:08 UTC (permalink / raw)
To: Adrian Bunk
Cc: Jeff Chua, Linus Torvalds, Andrew Morton,
Linux Kernel Mailing List, pavel, linux-pm, Len Brown,
linux-acpi, Maxim Levitsky
On Sat, Mar 31 2007, Adrian Bunk wrote:
> On Sat, Mar 31, 2007 at 10:52:59AM +0800, Jeff Chua wrote:
> > On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:
> >
> > >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 <jens.axboe@oracle.com>
> > > Jeff Chua <jeff.chua.linux@gmail.com>
> > >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?
Yep, it does, no problems since the last -rc.
--
Jens Axboe
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [3/4] 2.6.21-rc5: known regressions (v2)
2007-03-30 21:32 ` Adrian Bunk
@ 2007-04-01 5:39 ` Jeremy Fitzhardinge
-1 siblings, 0 replies; 128+ messages in thread
From: Jeremy Fitzhardinge @ 2007-04-01 5:39 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Dave Jones, Eric W. Biederman, Rafael J. Wysocki, pavel,
linux-pm, gregkh, Thomas Gleixner
Adrian Bunk wrote:
> Subject : ThinkPad X60: resume no longer works (PCI related?)
> References : http://lkml.org/lkml/2007/3/13/3
> Submitter : Dave Jones <davej@redhat.com>
> Jeremy Fitzhardinge <jeremy@goop.org>
> Caused-By : PCI merge
> commit 78149df6d565c36675463352d0bfe0000b02b7a7
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> Rafael J. Wysocki <rjw@sisk.pl>
> 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.
J
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [3/4] 2.6.21-rc5: known regressions (v2)
@ 2007-04-01 5:39 ` Jeremy Fitzhardinge
0 siblings, 0 replies; 128+ messages in thread
From: Jeremy Fitzhardinge @ 2007-04-01 5:39 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-pm, Thomas Gleixner, Eric W. Biederman, Andrew Morton,
gregkh, Linus Torvalds, Linux Kernel Mailing List
Adrian Bunk wrote:
> Subject : ThinkPad X60: resume no longer works (PCI related?)
> References : http://lkml.org/lkml/2007/3/13/3
> Submitter : Dave Jones <davej@redhat.com>
> Jeremy Fitzhardinge <jeremy@goop.org>
> Caused-By : PCI merge
> commit 78149df6d565c36675463352d0bfe0000b02b7a7
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> Rafael J. Wysocki <rjw@sisk.pl>
> 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.
J
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [3/4] 2.6.21-rc5: known regressions (v2)
2007-03-30 21:32 ` Adrian Bunk
@ 2007-04-13 16:32 ` Michal Piotrowski
-1 siblings, 0 replies; 128+ messages in thread
From: Michal Piotrowski @ 2007-04-13 16:32 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Rafael J. Wysocki, pavel, linux-pm, Stephen Hemminger, netdev
On 30/03/07, Adrian Bunk <bunk@stusta.de> wrote:
> Subject : suspend to disk hangs (skge)
> References : http://lkml.org/lkml/2007/3/27/212
> Submitter : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> Caused-By : Stephen Hemminger <shemminger@linux-foundation.org>
> commit a504e64ab42bcc27074ea37405d06833ed6e0820
> Status : unknown
This problem is fixed in 2.6.21-rc6-git5 (commit
692412b31ffb5df00197ea591dd635fc07506c02).
Huge thanks to Stephen.
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/)
^ permalink raw reply [flat|nested] 128+ messages in thread
* [4/4] 2.6.21-rc5: known regressions (v2)
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-30 21:49 ` Adrian Bunk
2007-03-26 8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
` (18 subsequent siblings)
19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:49 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Frédéric Riss, Tino Keitel,
Thomas Gleixner, pavel, linux-pm, Michael S. Tsirkin,
Soeren Sonnenburg, Ingo Molnar, Tejun Heo, Rafael J. Wysocki,
Jeff Chua
[ this time with a Cc... ]
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 : 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 <frederic.riss@gmail.com>
Tino Keitel <tino.keitel@gmx.de>
Caused-By : Thomas Gleixner <tglx@linutronix.de>
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 <mst@mellanox.co.il>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
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 <mst@mellanox.co.il>
Soeren Sonnenburg <kernel@nn7.de>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Ingo Molnar <mingo@elte.hu>
Tejun Heo <htejun@gmail.com>
Rafael J. Wysocki <rjw@sisk.pl>
Status : unknown
Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <jeff.chua.linux@gmail.com>
Status : unknown
^ permalink raw reply [flat|nested] 128+ messages in thread* [4/4] 2.6.21-rc5: known regressions (v2)
@ 2007-03-30 21:49 ` Adrian Bunk
0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-30 21:49 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Soeren Sonnenburg, Tejun Heo, Frédéric Riss, Jeff Chua,
Tino Keitel, linux-pm, Linux Kernel Mailing List,
Michael S. Tsirkin, Ingo Molnar, Thomas Gleixner
[ this time with a Cc... ]
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 : 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 <frederic.riss@gmail.com>
Tino Keitel <tino.keitel@gmx.de>
Caused-By : Thomas Gleixner <tglx@linutronix.de>
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 <mst@mellanox.co.il>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
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 <mst@mellanox.co.il>
Soeren Sonnenburg <kernel@nn7.de>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Ingo Molnar <mingo@elte.hu>
Tejun Heo <htejun@gmail.com>
Rafael J. Wysocki <rjw@sisk.pl>
Status : unknown
Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <jeff.chua.linux@gmail.com>
Status : unknown
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [4/4] 2.6.21-rc5: known regressions (v2)
2007-03-30 21:49 ` Adrian Bunk
@ 2007-03-31 2:41 ` Jeff Chua
-1 siblings, 0 replies; 128+ messages in thread
From: Jeff Chua @ 2007-03-31 2:41 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Frédéric Riss, Tino Keitel, Thomas Gleixner, pavel,
linux-pm, Michael S. Tsirkin, Soeren Sonnenburg, Ingo Molnar,
Tejun Heo, Rafael J. Wysocki
On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:
> Subject : suspend to disk hangs (CONFIG_NO_HZ)
> References : http://lkml.org/lkml/2007/3/25/217
> Submitter : Jeff Chua <jeff.chua.linux@gmail.com>
> Status : unknown
Still broken on.2.6.21-rc5.
Jeff.
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [4/4] 2.6.21-rc5: known regressions (v2)
@ 2007-03-31 2:41 ` Jeff Chua
0 siblings, 0 replies; 128+ messages in thread
From: Jeff Chua @ 2007-03-31 2:41 UTC (permalink / raw)
To: Adrian Bunk
Cc: Soeren Sonnenburg, Tejun Heo, Frédéric Riss,
Tino Keitel, linux-pm, Linux Kernel Mailing List, Andrew Morton,
Michael S. Tsirkin, Thomas Gleixner, Linus Torvalds, Ingo Molnar
On 3/31/07, Adrian Bunk <bunk@stusta.de> wrote:
> Subject : suspend to disk hangs (CONFIG_NO_HZ)
> References : http://lkml.org/lkml/2007/3/25/217
> Submitter : Jeff Chua <jeff.chua.linux@gmail.com>
> Status : unknown
Still broken on.2.6.21-rc5.
Jeff.
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [4/4] 2.6.21-rc5: known regressions (v2)
2007-03-30 21:49 ` Adrian Bunk
(?)
(?)
@ 2007-03-31 6:44 ` Frédéric Riss
-1 siblings, 0 replies; 128+ messages in thread
From: Frédéric Riss @ 2007-03-31 6:44 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Tino Keitel, Thomas Gleixner, pavel, linux-pm, Ingo Molnar,
Rafael J. Wysocki
Le vendredi 30 mars 2007 à 23:49 +0200, Adrian Bunk a écrit :
> 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 <frederic.riss@gmail.com>
> Tino Keitel <tino.keitel@gmx.de>
> Caused-By : Thomas Gleixner <tglx@linutronix.de>
> 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.
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [4/4] 2.6.21-rc5: known regressions (v2)
2007-03-30 21:49 ` Adrian Bunk
@ 2007-04-01 7:04 ` Michael S. Tsirkin
-1 siblings, 0 replies; 128+ messages in thread
From: Michael S. Tsirkin @ 2007-04-01 7:04 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Fr??d??ric Riss, Tino Keitel, Thomas Gleixner, pavel, linux-pm,
Soeren Sonnenburg, Ingo Molnar, Tejun Heo, Rafael J. Wysocki,
Jeff Chua, Maxim Levitsky
> 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 <mst@mellanox.co.il>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> 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
--
MST
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [4/4] 2.6.21-rc5: known regressions (v2)
@ 2007-04-01 7:04 ` Michael S. Tsirkin
0 siblings, 0 replies; 128+ messages in thread
From: Michael S. Tsirkin @ 2007-04-01 7:04 UTC (permalink / raw)
To: Adrian Bunk
Cc: Soeren Sonnenburg, Tejun Heo, Fr??d??ric Riss, Jeff Chua,
Tino Keitel, linux-pm, Linux Kernel Mailing List, Andrew Morton,
Thomas Gleixner, Linus Torvalds, Ingo Molnar, Maxim Levitsky
> 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 <mst@mellanox.co.il>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> 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
--
MST
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [4/4] 2.6.21-rc5: known regressions (v2)
2007-03-30 21:49 ` Adrian Bunk
@ 2007-04-01 20:37 ` Michael S. Tsirkin
-1 siblings, 0 replies; 128+ messages in thread
From: Michael S. Tsirkin @ 2007-04-01 20:37 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Fr??d??ric Riss, Tino Keitel, Thomas Gleixner, pavel, linux-pm,
Soeren Sonnenburg, Ingo Molnar, Tejun Heo, Rafael J. Wysocki,
Jeff Chua, maximlevitsky
> 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 <mst@mellanox.co.il>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> Status : problem is being debugged
Seems to be resolved with 399afa4fc9238fbae42116cf25a54671c0e8f56e.
Thanks Maxim!
--
MST
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [4/4] 2.6.21-rc5: known regressions (v2)
@ 2007-04-01 20:37 ` Michael S. Tsirkin
0 siblings, 0 replies; 128+ messages in thread
From: Michael S. Tsirkin @ 2007-04-01 20:37 UTC (permalink / raw)
To: Adrian Bunk
Cc: Soeren Sonnenburg, Tejun Heo, Fr??d??ric Riss, Jeff Chua,
Tino Keitel, linux-pm, Linux Kernel Mailing List, Andrew Morton,
Thomas Gleixner, Linus Torvalds, Ingo Molnar, maximlevitsky
> 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 <mst@mellanox.co.il>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> Status : problem is being debugged
Seems to be resolved with 399afa4fc9238fbae42116cf25a54671c0e8f56e.
Thanks Maxim!
--
MST
^ permalink raw reply [flat|nested] 128+ messages in thread
* 2.6.21-rc5: known regressions with patches (v2)
2007-03-25 23:08 Linux 2.6.21-rc5 Linus Torvalds
@ 2007-03-31 18:19 ` Adrian Bunk
2007-03-26 8:55 ` Linux 2.6.21-rc5 Thomas Gleixner
` (18 subsequent siblings)
19 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-31 18:19 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Robert Hancock, tigran, Tejun Heo, Maxim Levitsky, Kay Sievers,
linux-pm, Linux Kernel Mailing List, linux-ide,
Mathieu Bérard, Ingo Molnar, jgarzik
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 : hung bootup in various drivers
References : http://lkml.org/lkml/2007/3/30/68
Submitter : Ingo Molnar <mingo@elte.hu>
Handled-By : Kay Sievers <kay.sievers@vrfy.org>
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 <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
Robert Hancock <hancockr@shaw.ca>
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 <maximlevitsky@gmail.com>
Caused-By : Rafael J. Wysocki <rjw@sisk.pl>
commit e3c7db621bed4afb8e231cb005057f2feb5db557
commit ed746e3b18f4df18afa3763155972c5835f284c5
commit 259130526c267550bc365d3015917d90667732f1
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Patch : http://lkml.org/lkml/2007/3/25/71
Status : patch available
^ permalink raw reply [flat|nested] 128+ messages in thread* 2.6.21-rc5: known regressions with patches (v2)
@ 2007-03-31 18:19 ` Adrian Bunk
0 siblings, 0 replies; 128+ messages in thread
From: Adrian Bunk @ 2007-03-31 18:19 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Ingo Molnar, Kay Sievers, Greg KH,
Mathieu Bérard, Tejun Heo, Robert Hancock, jgarzik,
linux-ide, Maxim Levitsky, Rafael J. Wysocki, pavel, linux-pm,
tigran
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 : hung bootup in various drivers
References : http://lkml.org/lkml/2007/3/30/68
Submitter : Ingo Molnar <mingo@elte.hu>
Handled-By : Kay Sievers <kay.sievers@vrfy.org>
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 <Mathieu.Berard@crans.org>
Handled-By : Tejun Heo <htejun@gmail.com>
Robert Hancock <hancockr@shaw.ca>
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 <maximlevitsky@gmail.com>
Caused-By : Rafael J. Wysocki <rjw@sisk.pl>
commit e3c7db621bed4afb8e231cb005057f2feb5db557
commit ed746e3b18f4df18afa3763155972c5835f284c5
commit 259130526c267550bc365d3015917d90667732f1
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Patch : http://lkml.org/lkml/2007/3/25/71
Status : patch available
^ permalink raw reply [flat|nested] 128+ messages in thread* [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2)
2007-03-31 18:19 ` Adrian Bunk
(?)
@ 2007-04-03 4:05 ` Robert Hancock
2007-04-03 4:13 ` Tejun Heo
2007-04-04 6:09 ` Jeff Garzik
-1 siblings, 2 replies; 128+ messages in thread
From: Robert Hancock @ 2007-04-03 4:05 UTC (permalink / raw)
To: Linux Kernel Mailing List, linux-ide
Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, jgarzik
This adds some NCQ blacklist entries taken from the Silicon Image 3124/3132
Windows driver .inf files. There are some confirming reports of problems
with these drives under Linux (for example http://lkml.org/lkml/2007/3/4/178)
so let's disable NCQ on these drives.
Signed-off-by: Robert Hancock <hancockr@shaw.ca>
--- linux-2.6.21-rc5-git9/drivers/ata/libata-core.c 2007-04-02 21:03:29.000000000 -0600
+++ linux-2.6.21-rc5-git9edit/drivers/ata/libata-core.c 2007-04-02 21:26:23.000000000 -0600
@@ -3363,6 +3363,11 @@ static const struct ata_blacklist_entry
{ "Maxtor 6L250S0", "BANC1G10", ATA_HORKAGE_NONCQ },
/* NCQ hard hangs device under heavier load, needs hard power cycle */
{ "Maxtor 6B250S0", "BANC1B70", ATA_HORKAGE_NONCQ },
+ /* Blacklist entries taken from Silicon Image 3124/3132
+ Windows driver .inf file - also several Linux problem reports */
+ { "HTS541060G9SA00", "MB3OC60D", ATA_HORKAGE_NONCQ, },
+ { "HTS541080G9SA00", "MB4OC60D", ATA_HORKAGE_NONCQ, },
+ { "HTS541010G9SA00", "MBZOC60D", ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2)
2007-04-03 4:05 ` [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2) Robert Hancock
@ 2007-04-03 4:13 ` Tejun Heo
2007-04-04 6:09 ` Jeff Garzik
1 sibling, 0 replies; 128+ messages in thread
From: Tejun Heo @ 2007-04-03 4:13 UTC (permalink / raw)
To: Robert Hancock
Cc: Linux Kernel Mailing List, linux-ide, Adrian Bunk,
Linus Torvalds, Andrew Morton, jgarzik
Robert Hancock wrote:
> This adds some NCQ blacklist entries taken from the Silicon Image 3124/3132
> Windows driver .inf files. There are some confirming reports of problems
> with these drives under Linux (for example
> http://lkml.org/lkml/2007/3/4/178)
> so let's disable NCQ on these drives.
>
> Signed-off-by: Robert Hancock <hancockr@shaw.ca>
Acked-by: Tejun Heo <htejun@gmail.com>
--
tejun
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2)
2007-04-03 4:05 ` [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2) Robert Hancock
2007-04-03 4:13 ` Tejun Heo
@ 2007-04-04 6:09 ` Jeff Garzik
2007-04-04 14:26 ` Robert Hancock
1 sibling, 1 reply; 128+ messages in thread
From: Jeff Garzik @ 2007-04-04 6:09 UTC (permalink / raw)
To: Robert Hancock
Cc: Linux Kernel Mailing List, linux-ide, Adrian Bunk,
Linus Torvalds, Andrew Morton
Robert Hancock wrote:
> This adds some NCQ blacklist entries taken from the Silicon Image 3124/3132
> Windows driver .inf files. There are some confirming reports of problems
> with these drives under Linux (for example
> http://lkml.org/lkml/2007/3/4/178)
> so let's disable NCQ on these drives.
>
> Signed-off-by: Robert Hancock <hancockr@shaw.ca>
>
> --- linux-2.6.21-rc5-git9/drivers/ata/libata-core.c 2007-04-02
> 21:03:29.000000000 -0600
> +++ linux-2.6.21-rc5-git9edit/drivers/ata/libata-core.c 2007-04-02
> 21:26:23.000000000 -0600
> @@ -3363,6 +3363,11 @@ static const struct ata_blacklist_entry {
> "Maxtor 6L250S0", "BANC1G10", ATA_HORKAGE_NONCQ },
> /* NCQ hard hangs device under heavier load, needs hard power cycle */
> { "Maxtor 6B250S0", "BANC1B70", ATA_HORKAGE_NONCQ },
> + /* Blacklist entries taken from Silicon Image 3124/3132
> + Windows driver .inf file - also several Linux problem reports */
> + { "HTS541060G9SA00", "MB3OC60D", ATA_HORKAGE_NONCQ, },
> + { "HTS541080G9SA00", "MB4OC60D", ATA_HORKAGE_NONCQ, },
> + { "HTS541010G9SA00", "MBZOC60D", ATA_HORKAGE_NONCQ, },
The thread you link to seems like an irq problem, especially because it
worked in 2.6.20 and prior?
Jeff
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver (v2)
2007-04-04 6:09 ` Jeff Garzik
@ 2007-04-04 14:26 ` Robert Hancock
0 siblings, 0 replies; 128+ messages in thread
From: Robert Hancock @ 2007-04-04 14:26 UTC (permalink / raw)
To: Jeff Garzik
Cc: Linux Kernel Mailing List, linux-ide, Adrian Bunk,
Linus Torvalds, Andrew Morton
Jeff Garzik wrote:
> Robert Hancock wrote:
>> This adds some NCQ blacklist entries taken from the Silicon Image
>> 3124/3132
>> Windows driver .inf files. There are some confirming reports of problems
>> with these drives under Linux (for example
>> http://lkml.org/lkml/2007/3/4/178)
>> so let's disable NCQ on these drives.
>>
>> Signed-off-by: Robert Hancock <hancockr@shaw.ca>
>>
>> --- linux-2.6.21-rc5-git9/drivers/ata/libata-core.c 2007-04-02
>> 21:03:29.000000000 -0600
>> +++ linux-2.6.21-rc5-git9edit/drivers/ata/libata-core.c 2007-04-02
>> 21:26:23.000000000 -0600
>> @@ -3363,6 +3363,11 @@ static const struct ata_blacklist_entry {
>> "Maxtor 6L250S0", "BANC1G10", ATA_HORKAGE_NONCQ },
>> /* NCQ hard hangs device under heavier load, needs hard power
>> cycle */
>> { "Maxtor 6B250S0", "BANC1B70", ATA_HORKAGE_NONCQ },
>> + /* Blacklist entries taken from Silicon Image 3124/3132
>> + Windows driver .inf file - also several Linux problem reports */
>> + { "HTS541060G9SA00", "MB3OC60D", ATA_HORKAGE_NONCQ, },
>> + { "HTS541080G9SA00", "MB4OC60D", ATA_HORKAGE_NONCQ, },
>> + { "HTS541010G9SA00", "MBZOC60D", ATA_HORKAGE_NONCQ, },
>
> The thread you link to seems like an irq problem, especially because it
> worked in 2.6.20 and prior?
>
> Jeff
According to this post:
http://lkml.org/lkml/2007/3/9/475
with 2.6.21-rc3, it started working after the kernel disabled NCQ
because of too many errors. That seems to point away from it being an
IRQ problem, as you'd expect it to not work at all. I don't expect the
interrupts would be handled any differently between NCQ and non-NCQ
commands. However, apparently disabling ACPI also prevents the problem,
which does seem a bit odd.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
^ permalink raw reply [flat|nested] 128+ messages in thread