* Re: 2.6.23-rc2-mm2
From: Andrew Morton @ 2007-08-10 8:32 UTC (permalink / raw)
To: Dave Young; +Cc: linux-kernel, netdev
In-Reply-To: <a8e1da0708100118r779068i64ffdc11e452be9b@mail.gmail.com>
On Fri, 10 Aug 2007 16:18:38 +0800 "Dave Young" <hidave.darkstar@gmail.com> wrote:
> Hi,
> 2.6.23-rc2-mm2:
> config with CONFIG_NF_CONNTRACK_AMANDA=y
> boot oops:
>
> hand copyed :
> the EIP: helper_hash
>
> backtrace:
> do_basic_setup
> ...
> nf_conntrack_amanda_init
> error_code
> do_vivide_error
> ...
>
cc netdev
please send config
presumably nf_ct_helper_hsize is zero
I'd have thought that the same bug would be present in mainline - there's
nothing in git-net.patch.
(hunts around, discovers that there's a net-2.6.24 tree now. Bah)
^ permalink raw reply
* Re: 2.6.23-rc2: WARNING: at kernel/irq/resend.c:70 check_irq_resend()
From: Ingo Molnar @ 2007-08-10 8:30 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Thomas Gleixner, John Stoffel, linux-kernel, shemminger, vignaud,
marcin.slusarz, torvalds, akpm, alan, linux-net, netdev
In-Reply-To: <20070810082346.GD1764@ff.dom.local>
* Jarek Poplawski <jarkao2@o2.pl> wrote:
> > Hmm. This solution is still just pampering over the real problem.
> > The delayed disable just re-sends level interrupts unnecessarily. I
> > have a fix (needs some testing) for this, which I send out tomorrow,
> > when I'm really back from vacation.
> >
> > But suppressing the resend is not fixing the driver problem. The
> > problem can show up with spurious interrupts and with interrupts on
> > a shared PCI interrupt line at any time. It just might take weeks
> > instead of minutes.
>
> Doesn't it look like a little change of mind? [...]
what change of mind do you mean exactly?
> [...] Well, there are probably (but need more testing) two other
> solutions: _SW_RESEND and disabling without delay for levels only...
IIRC Marcin tested software-resend and it didnt fix the hang. That
strongly points in the direction of a driver bug (or a genirq bug) being
made more prominent by the genirq change - not any hardware detail such
as the APIC vector-retrigger sequence.
While we'd like to see the suspected driver bug (or any higher level
genirq bug) fixed, we'll undo the effect of the genirq change (because
it is causing a regression). We'll also add a separate, optional
irq-debugging feature that generates high-rate interrupts on any shared
irq line. (and thus artificially stresses the robustness of the driver
and the genirq layer against spurious interrupts.)
Ingo
^ permalink raw reply
* Re: 2.6.23-rc2: WARNING: at kernel/irq/resend.c:70 check_irq_resend()
From: Jarek Poplawski @ 2007-08-10 8:23 UTC (permalink / raw)
To: Thomas Gleixner
Cc: John Stoffel, linux-kernel, shemminger, vignaud, marcin.slusarz,
mingo, torvalds, akpm, alan, linux-net, netdev
In-Reply-To: <1186733140.12828.45.camel@chaos>
On Fri, Aug 10, 2007 at 10:05:40AM +0200, Thomas Gleixner wrote:
> On Thu, 2007-08-09 at 17:54 +0200, Jarek Poplawski wrote:
> > I'm not sure I don't miss anything (a little in hurry now), but this
> > warning's aim was purely diagnostical and nothing wrong is meant!
> > Unless there is something wrong... Then please try to be more explicit.
> >
> > If you prefer to not see this, there is my patch proposal somewhere
> > in this older thread:
> > Subject: [patch] genirq: temporary fix for level-triggered IRQ resend
> > Date: Wed, 8 Aug 2007 13:00:37 +0200
> >
> > On the other hand, if it works OK, it would be better to let it be
> > tested more like this...
>
> Hmm. This solution is still just pampering over the real problem. The
> delayed disable just re-sends level interrupts unnecessarily. I have a
> fix (needs some testing) for this, which I send out tomorrow, when I'm
> really back from vacation.
>
> But suppressing the resend is not fixing the driver problem. The problem
> can show up with spurious interrupts and with interrupts on a shared PCI
> interrupt line at any time. It just might take weeks instead of minutes.
Doesn't it look like a little change of mind? Well, there are probably
(but need more testing) two other solutions: _SW_RESEND and disabling
without delay for levels only...
Jarek P.
^ permalink raw reply
* Re: [PATCH] [NET] ethtool: Add LRO support
From: Jan-Bernd Themann @ 2007-08-10 7:47 UTC (permalink / raw)
To: David Miller; +Cc: auke-jan.h.kok, jeff, netdev
In-Reply-To: <20070809.150014.32064726.davem@davemloft.net>
Hi
On Friday 10 August 2007 00:00, David Miller wrote:
> From: Auke Kok <auke-jan.h.kok@intel.com>
> Date: Thu, 09 Aug 2007 09:41:17 -0700
>
> > Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
>
> I think this is definitely how we should handle LRO
> configuration instead of the ad-hoc module parameters
> current LRO drivers use now.
>
> I'll put this infrastructure into net-2.6.24, it would
> be nice if the EHEA and myri10g folks submitted conversions.
>
yes, I'll submit a patch soon
^ permalink raw reply
* Re: [patch (testing)] Re: 2.6.20->2.6.21 - networking dies after random time
From: Jean-Baptiste Vignaud @ 2007-08-10 8:15 UTC (permalink / raw)
To: jarkao2
Cc: marcin.slusarz, mingo, tglx, torvalds, linux-kernel, shemminger,
linux-net, netdev, akpm, alan
> So, we still have to wait for the exact explanation...
>
> Thanks very much Marcin!
>
> I think, there is this one possible for your testing yet?:
> Subject: [patch] genirq: temporary fix for level-triggered IRQ resend
> Date: Wed, 8 Aug 2007 13:00:37 +0200
>
> If it's not a great problem it would be interesting to try this with
> different CONFIG_HZ too e.g. you could start with 100 (I guess, you
> tested very similar thing in 2.6.23-rc2 with 1000(?) already).
>
> Jean-Baptiste: you can skip/break testing of this 'experimental'
ok
I was still testing on -rc2:
Subject: [patch] genirq: temporary fix for level-triggered IRQ resend
Date: Wed, 8 Aug 2007 13:00:37 +0200
For me after 1day 20hours, the network is still up, with more than 1To
of network traffic. HZ was 1000, i restart with HZ=100.
Jb
^ permalink raw reply
* Add 3c59x maintainer
From: Steffen Klassert @ 2007-08-10 8:14 UTC (permalink / raw)
To: Andrew Morton, Jeff Garzik; +Cc: netdev
Add 3c59x maintainer.
Signed-off-by: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
--- linux-2.6.23-rc2.orig/MAINTAINERS
+++ linux-2.6.23-rc2/MAINTAINERS
@@ -97,6 +97,12 @@ M: philb@gnu.org
L: netdev@vger.kernel.org
S: Maintained
+3C59X NETWORK DRIVER
+P: Steffen Klassert
+M: klassert@mathematik.tu-chemnitz.de
+L: netdev@vger.kernel.org
+S: Maintained
+
3CR990 NETWORK DRIVER
P: David Dillow
M: dave@thedillows.org
^ permalink raw reply
* Re: 2.6.23-rc2: WARNING: at kernel/irq/resend.c:70 check_irq_resend()
From: Thomas Gleixner @ 2007-08-10 8:05 UTC (permalink / raw)
To: Jarek Poplawski
Cc: John Stoffel, linux-kernel, shemminger, vignaud, marcin.slusarz,
mingo, torvalds, akpm, alan, linux-net, netdev
In-Reply-To: <20070809155445.GA5161@ff.dom.local>
On Thu, 2007-08-09 at 17:54 +0200, Jarek Poplawski wrote:
> I'm not sure I don't miss anything (a little in hurry now), but this
> warning's aim was purely diagnostical and nothing wrong is meant!
> Unless there is something wrong... Then please try to be more explicit.
>
> If you prefer to not see this, there is my patch proposal somewhere
> in this older thread:
> Subject: [patch] genirq: temporary fix for level-triggered IRQ resend
> Date: Wed, 8 Aug 2007 13:00:37 +0200
>
> On the other hand, if it works OK, it would be better to let it be
> tested more like this...
Hmm. This solution is still just pampering over the real problem. The
delayed disable just re-sends level interrupts unnecessarily. I have a
fix (needs some testing) for this, which I send out tomorrow, when I'm
really back from vacation.
But suppressing the resend is not fixing the driver problem. The problem
can show up with spurious interrupts and with interrupts on a shared PCI
interrupt line at any time. It just might take weeks instead of minutes.
Alan,
is there anything which can be done on the driver level ?
tglx
^ permalink raw reply
* Re: 2.6.23-rc2-mm2: possible irq lock inversion dependency detected
From: Mariusz Kozlowski @ 2007-08-10 7:59 UTC (permalink / raw)
To: Andrew Morton, netdev, Jeff Garzik; +Cc: linux-kernel
In-Reply-To: <20070809224254.11f42716.akpm@linux-foundation.org>
Hello,
Have fun :)
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
2.6.23-rc2-mm2 #1
---------------------------------------------------------
depscan.sh/5928 just changed the state of lock:
(_xmit_ETHER){-+..}, at: [<c03cb669>] dev_watchdog+0x17/0xcc
but this lock took another, soft-irq-unsafe lock in the past:
(&tp->lock){--..}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
no locks held by depscan.sh/5928.
the first lock's dependencies:
-> (_xmit_ETHER){-+..} ops: 27 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c045282a>] _spin_lock_bh+0x3a/0x47
[<c03bc0a6>] dev_set_rx_mode+0x14/0x3b
[<c03bc5af>] dev_change_flags+0x68/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c03cb669>] dev_watchdog+0x17/0xcc
[<c01224b7>] run_timer_softirq+0x14b/0x1a9
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<ffffffff>] 0xffffffff
hardirq-on-W at:
[<c01393d0>] __lock_acquire+0x73e/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c045282a>] _spin_lock_bh+0x3a/0x47
[<c03bc0a6>] dev_set_rx_mode+0x14/0x3b
[<c03bc5af>] dev_change_flags+0x68/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
}
... key at: [<c087e9e8>] netdev_xmit_lock_key+0x8/0x1c0
-> (&tp->lock){--..} ops: 44 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<de84d6e2>] rtl8139_interrupt+0x27/0x469 [8139too]
[<c0148b92>] request_irq+0xba/0x108
[<de84e52d>] rtl8139_open+0x2f/0x1e2 [8139too]
[<c03be80d>] dev_open+0x37/0x76
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
softirq-on-W at:
[<c01393f9>] __lock_acquire+0x767/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<de84d6e2>] rtl8139_interrupt+0x27/0x469 [8139too]
[<c01487ed>] free_irq+0x11b/0x146
[<de84ec90>] rtl8139_close+0x8a/0x14a [8139too]
[<c03bd5d3>] dev_close+0x57/0x74
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
hardirq-on-W at:
[<c01393d0>] __lock_acquire+0x73e/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<de84d6e2>] rtl8139_interrupt+0x27/0x469 [8139too]
[<c01487ed>] free_irq+0x11b/0x146
[<de84ec90>] rtl8139_close+0x8a/0x14a [8139too]
[<c03bd5d3>] dev_close+0x57/0x74
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
}
... key at: [<de852190>] __key.19796+0x0/0xffffd3c9 [8139too]
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<de84d275>] rtl8139_set_rx_mode+0x1e/0x166 [8139too]
[<c03bbe72>] __dev_set_rx_mode+0x24/0x85
[<c03bc0b8>] dev_set_rx_mode+0x26/0x3b
[<c03be830>] dev_open+0x5a/0x76
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
-> (&priv->lock){++..} ops: 113 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04529cc>] _spin_lock_irq+0x3b/0x48
[<ded03256>] orinoco_init+0x8f5/0xbbd [orinoco]
[<c03bdbde>] register_netdevice+0x13a/0x3f8
[<c03bdece>] register_netdev+0x32/0x3f
[<ded2c4bb>] orinoco_cs_probe+0x368/0x3df [orinoco_cs]
[<ded378d9>] pcmcia_device_probe+0xc9/0x14c [pcmcia]
[<c02f324f>] driver_probe_device+0xa6/0x198
[<c02f3492>] __driver_attach+0xa2/0xa4
[<c02f271a>] bus_for_each_dev+0x43/0x61
[<c02f30d1>] driver_attach+0x19/0x1b
[<c02f2a89>] bus_add_driver+0x7e/0x1a5
[<c02f363f>] driver_register+0x45/0x75
[<ded38560>] pcmcia_register_driver+0xdb/0x12f [pcmcia]
[<de84b024>] 0xde84b024
[<c0140a47>] sys_init_module+0xc4/0x1622
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<ded03bb4>] orinoco_interrupt+0x3f/0x1219 [orinoco]
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<ded06a99>] orinoco_get_wireless_stats+0xeb/0x140 [orinoco]
[<c042b2ba>] get_wireless_stats+0x1a/0x21
[<c042bf69>] wireless_seq_show+0x20/0x143
[<c0187357>] seq_read+0x1af/0x2b8
[<c01a1ed2>] proc_reg_read+0x57/0x78
[<c016d781>] vfs_read+0xaa/0x147
[<c016dba6>] sys_read+0x3d/0x7b
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<ded03bb4>] orinoco_interrupt+0x3f/0x1219 [orinoco]
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<ded06a99>] orinoco_get_wireless_stats+0xeb/0x140 [orinoco]
[<c042b2ba>] get_wireless_stats+0x1a/0x21
[<c042bf69>] wireless_seq_show+0x20/0x143
[<c0187357>] seq_read+0x1af/0x2b8
[<c01a1ed2>] proc_reg_read+0x57/0x78
[<c016d781>] vfs_read+0xaa/0x147
[<c016dba6>] sys_read+0x3d/0x7b
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
}
... key at: [<ded0a298>] __key.20430+0x0/0xffffc9cd [orinoco]
-> (lweventlist_lock){+...} ops: 8 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c03c78db>] linkwatch_add_event+0x10/0x31
[<c03c79ba>] linkwatch_fire_event+0x35/0x37
[<c03cb36a>] netif_carrier_off+0x19/0x20
[<ded023b5>] alloc_orinocodev+0x181/0x19c [orinoco]
[<ded2c170>] orinoco_cs_probe+0x1d/0x3df [orinoco_cs]
[<ded378d9>] pcmcia_device_probe+0xc9/0x14c [pcmcia]
[<c02f324f>] driver_probe_device+0xa6/0x198
[<c02f3492>] __driver_attach+0xa2/0xa4
[<c02f271a>] bus_for_each_dev+0x43/0x61
[<c02f30d1>] driver_attach+0x19/0x1b
[<c02f2a89>] bus_add_driver+0x7e/0x1a5
[<c02f363f>] driver_register+0x45/0x75
[<ded38560>] pcmcia_register_driver+0xdb/0x12f [pcmcia]
[<de84b024>] 0xde84b024
[<c0140a47>] sys_init_module+0xc4/0x1622
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c03c78db>] linkwatch_add_event+0x10/0x31
[<c03c79ba>] linkwatch_fire_event+0x35/0x37
[<c03cb39a>] netif_carrier_on+0x29/0x2b
[<ded04bdc>] orinoco_interrupt+0x1067/0x1219 [orinoco]
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c03706cb>] cpuidle_idle_call+0x74/0x99
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
}
... key at: [<c05e4990>] lweventlist_lock+0x10/0x20
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c03c78db>] linkwatch_add_event+0x10/0x31
[<c03c79ba>] linkwatch_fire_event+0x35/0x37
[<c03cb39a>] netif_carrier_on+0x29/0x2b
[<ded04bdc>] orinoco_interrupt+0x1067/0x1219 [orinoco]
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c03706cb>] cpuidle_idle_call+0x74/0x99
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
-> (&cwq->lock){++..} ops: 4593 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0129002>] __queue_work+0xf/0x2d
[<c012909f>] queue_work+0x57/0x90
[<c0128714>] call_usermodehelper_exec+0xce/0xe1
[<c0265385>] kobject_uevent_env+0x34d/0x449
[<c026548b>] kobject_uevent+0xa/0xf
[<c0264b69>] kset_register+0x32/0x38
[<c0264b77>] subsystem_register+0x8/0xa
[<c02f2c9a>] bus_register+0x65/0x1f3
[<c0611db6>] platform_bus_init+0x23/0x38
[<c0611e0c>] driver_init+0x1c/0x31
[<c05fc68d>] kernel_init+0x5d/0x26b
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0129002>] __queue_work+0xf/0x2d
[<c012909f>] queue_work+0x57/0x90
[<c029239a>] acpi_os_execute+0xae/0xcb
[<c02aa226>] acpi_ec_gpe_handler+0x4d/0x5e
[<c0297f51>] acpi_ev_gpe_dispatch+0x4b/0x115
[<c0298253>] acpi_ev_gpe_detect+0x9a/0xe1
[<c0296989>] acpi_ev_sci_xrupt_handler+0x15/0x1d
[<c0291aae>] acpi_irq+0xe/0x18
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0129002>] __queue_work+0xf/0x2d
[<c0129044>] delayed_work_timer_fn+0x24/0x28
[<c01224b7>] run_timer_softirq+0x14b/0x1a9
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c0128b00>] run_workqueue+0xe8/0x1f3
[<c0129648>] worker_thread+0x9a/0xf2
[<c012c04e>] kthread+0x36/0x58
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
}
... key at: [<c0657ae8>] __key.11148+0x0/0x8
-> (&q->lock){++..} ops: 74830 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04529cc>] _spin_lock_irq+0x3b/0x48
[<c044fcf5>] wait_for_completion+0x24/0xb5
[<c012c1d1>] kthread_create+0x69/0xa8
[<c0606fcc>] cpu_callback+0x48/0xa3
[<c0607043>] spawn_ksoftirqd+0x1c/0x4e
[<c05fc66c>] kernel_init+0x3c/0x26b
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0113d3b>] __wake_up+0x15/0x42
[<c02aa1ff>] acpi_ec_gpe_handler+0x26/0x5e
[<c0297f51>] acpi_ev_gpe_dispatch+0x4b/0x115
[<c0298253>] acpi_ev_gpe_detect+0x9a/0xe1
[<c0296989>] acpi_ev_sci_xrupt_handler+0x15/0x1d
[<c0291aae>] acpi_irq+0xe/0x18
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0113c7c>] complete+0x15/0x4b
[<c0129ebe>] wakeme_after_rcu+0xb/0xd
[<c012a013>] __rcu_process_callbacks+0x69/0x1cf
[<c012a18b>] rcu_process_callbacks+0x12/0x23
[<c011eda3>] tasklet_action+0x3b/0x7b
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
}
... key at: [<c0657f30>] __key.11466+0x0/0x8
-> (&rq->rq_lock_key){++..} ops: 216798 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c060664a>] init_idle+0x40/0x6d
[<c06067e0>] sched_init+0x169/0x17c
[<c05fc970>] start_kernel+0xd5/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c01157f3>] scheduler_tick+0x20/0x192
[<c0122c31>] update_process_times+0x43/0x62
[<c0134325>] tick_periodic+0x24/0x75
[<c013438e>] tick_handle_periodic+0x18/0x7a
[<c01064ae>] timer_interrupt+0xe/0x15
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c014890a>] setup_irq+0xf2/0x20d
[<c060656f>] time_init_hook+0x19/0x1b
[<c05ffcc8>] hpet_time_init+0xd/0x15
[<c05fca70>] start_kernel+0x1d5/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c0114ec2>] task_rq_lock+0x28/0x40
[<c011504c>] try_to_wake_up+0x18/0x92
[<c01150d1>] default_wake_function+0xb/0xd
[<c011284b>] __wake_up_common+0x39/0x59
[<c0113ca1>] complete+0x3a/0x4b
[<c0129ebe>] wakeme_after_rcu+0xb/0xd
[<c012a013>] __rcu_process_callbacks+0x69/0x1cf
[<c012a18b>] rcu_process_callbacks+0x12/0x23
[<c011eda3>] tasklet_action+0x3b/0x7b
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
}
... key at: [<c0635d28>] per_cpu__runqueues+0x468/0x470
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c0114ec2>] task_rq_lock+0x28/0x40
[<c011504c>] try_to_wake_up+0x18/0x92
[<c01150d1>] default_wake_function+0xb/0xd
[<c011284b>] __wake_up_common+0x39/0x59
[<c0113ca1>] complete+0x3a/0x4b
[<c012c037>] kthread+0x1f/0x58
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0113d3b>] __wake_up+0x15/0x42
[<c0128c6b>] insert_work+0x60/0x75
[<c0129012>] __queue_work+0x1f/0x2d
[<c012909f>] queue_work+0x57/0x90
[<c0128714>] call_usermodehelper_exec+0xce/0xe1
[<c0265385>] kobject_uevent_env+0x34d/0x449
[<c026548b>] kobject_uevent+0xa/0xf
[<c0264b69>] kset_register+0x32/0x38
[<c0264b77>] subsystem_register+0x8/0xa
[<c02f2c9a>] bus_register+0x65/0x1f3
[<c0611db6>] platform_bus_init+0x23/0x38
[<c0611e0c>] driver_init+0x1c/0x31
[<c05fc68d>] kernel_init+0x5d/0x26b
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c0129002>] __queue_work+0xf/0x2d
[<c012909f>] queue_work+0x57/0x90
[<c01294af>] queue_delayed_work+0x27/0x48
[<c01294f2>] schedule_delayed_work+0x22/0x26
[<c03c793c>] linkwatch_schedule_work+0x40/0x89
[<c03c79a9>] linkwatch_fire_event+0x24/0x37
[<c03cb39a>] netif_carrier_on+0x29/0x2b
[<ded04bdc>] orinoco_interrupt+0x1067/0x1219 [orinoco]
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c03706cb>] cpuidle_idle_call+0x74/0x99
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
-> (base_lock_keys + cpu){++..} ops: 69219 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c01229f6>] lock_timer_base+0x41/0x66
[<c0122ab8>] __mod_timer+0x3b/0xc5
[<c0122bea>] mod_timer+0x47/0x4b
[<c0611091>] con_init+0x24b/0x27e
[<c061075a>] console_init+0x20/0x2e
[<c05fca30>] start_kernel+0x195/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c01229f6>] lock_timer_base+0x41/0x66
[<c0122a47>] del_timer+0x2c/0x62
[<c0302a8b>] ide_intr+0x72/0x1f0
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04529cc>] _spin_lock_irq+0x3b/0x48
[<c0122395>] run_timer_softirq+0x29/0x1a9
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c014890a>] setup_irq+0xf2/0x20d
[<c060656f>] time_init_hook+0x19/0x1b
[<c05ffcc8>] hpet_time_init+0xd/0x15
[<c05fca70>] start_kernel+0x1d5/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
}
... key at: [<c0657a96>] base_lock_keys+0x0/0xa
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c01229f6>] lock_timer_base+0x41/0x66
[<c0122ab8>] __mod_timer+0x3b/0xc5
[<c0122bea>] mod_timer+0x47/0x4b
[<c03cae67>] __netdev_watchdog_up+0x37/0x50
[<c03cb390>] netif_carrier_on+0x1f/0x2b
[<ded04bdc>] orinoco_interrupt+0x1067/0x1219 [orinoco]
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c03706cb>] cpuidle_idle_call+0x74/0x99
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
-> (&list->lock#2){.+..} ops: 12 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c03b70bb>] skb_queue_tail+0x14/0x33
[<c042b67b>] wireless_send_event+0x348/0x369
[<c042b9b9>] ioctl_standard_call+0x1b2/0x34d
[<c042beae>] wext_handle_ioctl+0x35a/0x3e4
[<c03be765>] dev_ioctl+0x31e/0x325
[<c03b153c>] sock_ioctl+0xb7/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c03b716c>] skb_dequeue+0x12/0x50
[<c042b32d>] wireless_nlevent_process+0x2d/0x33
[<c011eda3>] tasklet_action+0x3b/0x7b
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<ded028e3>] orinoco_ioctl_commit+0x8e/0x10c [orinoco]
[<c042b2f0>] call_commit_handler+0x2f/0x3f
[<c042b9d2>] ioctl_standard_call+0x1cb/0x34d
[<c042beae>] wext_handle_ioctl+0x35a/0x3e4
[<c03be765>] dev_ioctl+0x31e/0x325
[<c03b153c>] sock_ioctl+0xb7/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
}
... key at: [<c0884a80>] __key.13323+0x0/0x20
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c03b70bb>] skb_queue_tail+0x14/0x33
[<c042b67b>] wireless_send_event+0x348/0x369
[<ded03b69>] orinoco_send_wevents+0x9a/0xa6 [orinoco]
[<c0128b28>] run_workqueue+0x110/0x1f3
[<c0129648>] worker_thread+0x9a/0xf2
[<c012c04e>] kthread+0x36/0x58
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
-> (&rq->rq_lock_key){++..} ops: 216798 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<c060664a>] init_idle+0x40/0x6d
[<c06067e0>] sched_init+0x169/0x17c
[<c05fc970>] start_kernel+0xd5/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-hardirq-W at:
[<c01395db>] __lock_acquire+0x949/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c01157f3>] scheduler_tick+0x20/0x192
[<c0122c31>] update_process_times+0x43/0x62
[<c0134325>] tick_periodic+0x24/0x75
[<c013438e>] tick_handle_periodic+0x18/0x7a
[<c01064ae>] timer_interrupt+0xe/0x15
[<c014814d>] handle_IRQ_event+0x28/0x59
[<c0149a1a>] handle_level_irq+0xad/0x10b
[<c01058f3>] do_IRQ+0x93/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c014890a>] setup_irq+0xf2/0x20d
[<c060656f>] time_init_hook+0x19/0x1b
[<c05ffcc8>] hpet_time_init+0xd/0x15
[<c05fca70>] start_kernel+0x1d5/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
in-softirq-W at:
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c0114ec2>] task_rq_lock+0x28/0x40
[<c011504c>] try_to_wake_up+0x18/0x92
[<c01150d1>] default_wake_function+0xb/0xd
[<c011284b>] __wake_up_common+0x39/0x59
[<c0113ca1>] complete+0x3a/0x4b
[<c0129ebe>] wakeme_after_rcu+0xb/0xd
[<c012a013>] __rcu_process_callbacks+0x69/0x1cf
[<c012a18b>] rcu_process_callbacks+0x12/0x23
[<c011eda3>] tasklet_action+0x3b/0x7b
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
[<c01025e4>] cpu_idle+0x87/0x89
[<c044f214>] rest_init+0x60/0x62
[<c05fcad5>] start_kernel+0x23a/0x2c5
[<00000000>] 0x0
[<ffffffff>] 0xffffffff
}
... key at: [<c0635d28>] per_cpu__runqueues+0x468/0x470
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c0114ec2>] task_rq_lock+0x28/0x40
[<c011504c>] try_to_wake_up+0x18/0x92
[<c01150ee>] wake_up_process+0xf/0x11
[<c011f5cc>] __tasklet_schedule+0x6d/0x6f
[<c042b697>] wireless_send_event+0x364/0x369
[<ded03b69>] orinoco_send_wevents+0x9a/0xa6 [orinoco]
[<c0128b28>] run_workqueue+0x110/0x1f3
[<c0129648>] worker_thread+0x9a/0xf2
[<c012c04e>] kthread+0x36/0x58
[<c010454b>] kernel_thread_helper+0x7/0x1c
[<ffffffff>] 0xffffffff
... acquired at:
[<c0139d2d>] __lock_acquire+0x109b/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c0452a5f>] _spin_lock_irqsave+0x3e/0x4e
[<ded03598>] orinoco_set_multicast_list+0x1b/0x5f [orinoco]
[<c03bbe72>] __dev_set_rx_mode+0x24/0x85
[<c03bc0b8>] dev_set_rx_mode+0x26/0x3b
[<c03be830>] dev_open+0x5a/0x76
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
the second lock's dependencies:
-> (&tp->lock){--..} ops: 44 {
initial-use at:
[<c0138ea9>] __lock_acquire+0x217/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<de84d6e2>] rtl8139_interrupt+0x27/0x469 [8139too]
[<c0148b92>] request_irq+0xba/0x108
[<de84e52d>] rtl8139_open+0x2f/0x1e2 [8139too]
[<c03be80d>] dev_open+0x37/0x76
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
softirq-on-W at:
[<c01393f9>] __lock_acquire+0x767/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<de84d6e2>] rtl8139_interrupt+0x27/0x469 [8139too]
[<c01487ed>] free_irq+0x11b/0x146
[<de84ec90>] rtl8139_close+0x8a/0x14a [8139too]
[<c03bd5d3>] dev_close+0x57/0x74
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
hardirq-on-W at:
[<c01393d0>] __lock_acquire+0x73e/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<de84d6e2>] rtl8139_interrupt+0x27/0x469 [8139too]
[<c01487ed>] free_irq+0x11b/0x146
[<de84ec90>] rtl8139_close+0x8a/0x14a [8139too]
[<c03bd5d3>] dev_close+0x57/0x74
[<c03bc5d5>] dev_change_flags+0x8e/0x190
[<c03fcb5c>] devinet_ioctl+0x4af/0x652
[<c03fd442>] inet_ioctl+0x56/0x71
[<c03b152a>] sock_ioctl+0xa5/0x1d4
[<c0178a52>] do_ioctl+0x22/0x71
[<c0178af6>] vfs_ioctl+0x55/0x29e
[<c0178d72>] sys_ioctl+0x33/0x69
[<c01041da>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
}
... key at: [<de852190>] __key.19796+0x0/0xffffd3c9 [8139too]
stack backtrace:
[<c0104899>] show_trace_log_lvl+0x1a/0x30
[<c0105296>] show_trace+0x12/0x14
[<c01053fe>] dump_stack+0x15/0x17
[<c0137462>] print_irq_inversion_bug+0x101/0x123
[<c0137db1>] check_usage_forwards+0x3e/0x45
[<c0137f67>] mark_lock+0x1af/0x70c
[<c0139384>] __lock_acquire+0x6f2/0x11ac
[<c0139ed7>] lock_acquire+0x99/0xb2
[<c04527e3>] _spin_lock+0x35/0x42
[<c03cb669>] dev_watchdog+0x17/0xcc
[<c01224b7>] run_timer_softirq+0x14b/0x1a9
[<c011ecc2>] __do_softirq+0x5b/0xb2
[<c011ed66>] do_softirq+0x4d/0x4f
[<c011f04b>] irq_exit+0x48/0x4a
[<c01058f8>] do_IRQ+0x98/0xd0
[<c010444e>] common_interrupt+0x2e/0x34
=======================
Clocksource tsc unstable (delta = 9372868714 ns)
Regards,
Mariusz
^ permalink raw reply
* Re: [patch (testing)] Re: 2.6.20->2.6.21 - networking dies after random time
From: Jarek Poplawski @ 2007-08-10 7:10 UTC (permalink / raw)
To: Marcin Ślusarz
Cc: Ingo Molnar, Thomas Gleixner, Linus Torvalds,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton, Alan Cox
In-Reply-To: <4bacf17f0708092333n17e0ba19jf2c769531610868d@mail.gmail.com>
On Fri, Aug 10, 2007 at 08:33:27AM +0200, Marcin Ślusarz wrote:
> 2007/8/9, Jarek Poplawski <jarkao2@o2.pl>:
...
> > diff -Nurp 2.6.23-rc1-/kernel/irq/chip.c 2.6.23-rc1/kernel/irq/chip.c
> > --- 2.6.23-rc1-/kernel/irq/chip.c 2007-07-09 01:32:17.000000000 +0200
> > +++ 2.6.23-rc1/kernel/irq/chip.c 2007-08-08 20:49:07.000000000 +0200
> > @@ -389,12 +389,19 @@ handle_fasteoi_irq(unsigned int irq, str
> > unsigned int cpu = smp_processor_id();
> > struct irqaction *action;
> > irqreturn_t action_ret;
> > + int edge = 0;
> >
...
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=351.
> eth0: Resetting the 8390 t=4295229000...<6>NETDEV WATCHDOG: eth0:
> transmit timed out
> eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=718.
> eth0: Resetting the 8390 t=4295230000...<6>NETDEV WATCHDOG: eth0:
> transmit timed out
> eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=874.
> etc...
So, we still have to wait for the exact explanation...
Thanks very much Marcin!
I think, there is this one possible for your testing yet?:
Subject: [patch] genirq: temporary fix for level-triggered IRQ resend
Date: Wed, 8 Aug 2007 13:00:37 +0200
If it's not a great problem it would be interesting to try this with
different CONFIG_HZ too e.g. you could start with 100 (I guess, you
tested very similar thing in 2.6.23-rc2 with 1000(?) already).
Jean-Baptiste: you can skip/break testing of this 'experimental'
patch, too.
Regards,
Jarek P.
^ permalink raw reply
* Fwd: bug in kernel 2.6.20.9 in ipv6 dest opt <help>
From: md ayyaz @ 2007-08-10 7:04 UTC (permalink / raw)
To: netdev
In-Reply-To: <df1706540708092335h1c8ad61dq6ed8f11e01d0190e@mail.gmail.com>
---------- Forwarded message ----------
From: md ayyaz <md.ayyaz@gmail.com>
Date: Aug 10, 2007 12:05 PM
Subject: bug in kernel 2.6.20.9 in ipv6 dest opt <help>
To: yoshfuji@linux-ipv6.org
Hi ,
i am working on mobile ipv6 protocol , so what happens whenver i pass
a ipv6 packet with destination option in it , it doesnt parse it
correctly in extension header parsing for dest option and hence
returns -1 as an error back so packet gets dropped in ip layer , along
with this if i send ipv6-ipv6 tunnel packet it shows slab corruption
in logs ,( i had put some debug messages)
please reply as soon as possible i will be greatly thankfull for the help
Aug 1 16:18:12 localhost kernel: Recived IPv6 packet with next hdr as 17 from
3ffe:0300:0068:0218:f3ff:fed9:8914:f521600001
Aug 1 16:18:12 localhost kernel: packet Len : 173 nxt Hdr : 17 skb:213
Aug 1 16:18:13 localhost kernel: Recived IPv6 packet with next hdr as 17 from
3ffe:0300:0068:0218:f3ff:fed9:8914:f521600001
Aug 1 16:18:13 localhost kernel: packet Len : 173 nxt Hdr : 17 skb:213
Aug 1 16:18:14 localhost kernel: Recived IPv6 packet with next hdr as 58 from
fe80:0000:0000:0218:f3ff:feda:83cb:f521600001
Aug 1 16:18:14 localhost kernel: packet Len : 64 nxt Hdr : 58 skb:104
Aug 1 16:18:16 localhost kernel: Recived IPv6 packet with next hdr as 58 from
fe80:0000:0000:0218:f3ff:feda:83cb:f521600001
Aug 1 16:18:16 localhost kernel: packet Len : 24 nxt Hdr : 58 skb:64
Aug 1 16:18:18 localhost kernel: Recived IPv6 packet with next hdr as 58 from
fe80:0000:0000:0218:f3ff:feda:83cb:f521600001
Aug 1 16:18:18 localhost kernel: packet Len : 64 nxt Hdr : 58 skb:104
Aug 1 16:18:21 localhost kernel: Recived IPv6 packet with next hdr as 58 from
fe80:0000:0000:0218:f3ff:feda:83cb:f521600001
Aug 1 16:18:21 localhost kernel: packet Len : 32 nxt Hdr : 58 skb:72
Aug 1 16:18:24 localhost kernel: Recived IPv6 packet with next hdr as 41 from
3ffe:0300:0068:020c:29ff:fea2:b14c:f521600001
Aug 1 16:18:24 localhost kernel: packet Len : 140 nxt Hdr : 41 skb:180
Aug 1 16:18:24 localhost kernel: Slab corruption: start=f50b1dac, len=176
Aug 1 16:18:24 localhost kernel: Redzone: 0x5a2cf071/0x5a2cf071.
Aug 1 16:18:24 localhost kernel: Last user:
[<c055d930>](kfree_skbmem+0x63/0x66)
Aug 1 16:18:24 localhost kernel: 090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6a 6b 6b 6b
Aug 1 16:18:24 localhost kernel: Single bit error detected. Probably bad
RAM.
Aug 1 16:18:24 localhost kernel: Run memtest86+ or a similar memory test
tool.
Aug 1 16:18:24 localhost kernel: Prev obj: start=f50b1cf0, len=176
Aug 1 16:18:24 localhost kernel: Redzone: 0x170fc2a5/0x170fc2a5.
Aug 1 16:18:24 localhost kernel: Last user:
[<c055e041>](__alloc_skb+0x2c/0xfd)
Aug 1 16:18:24 localhost kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Aug 1 16:18:24 localhost kernel: 010: 00 00 00 00 00 60 21 f5 00 00 00 00
00 00 00 00
Aug 1 16:18:24 localhost kernel: Next obj: start=f50b1e68, len=176
Aug 1 16:18:24 localhost kernel: Redzone: 0x170fc2a5/0x170fc2a5.
Aug 1 16:18:24 localhost kernel: Last user:
[<c055e041>](__alloc_skb+0x2c/0xfd)
Aug 1 16:18:24 localhost kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Aug 1 16:18:24 localhost kernel: 010: 00 00 00 00 00 60 21 f5 00 00 00 00
00 00 00 00
Aug 1 16:18:26 localhost kernel: Recived IPv6 packet with next hdr as 58
from fe80:0000:0000:0218:f3ff:feda:83cb:f521600001
Aug 1 16:18:26 localhost kernel: packet Len : 64 nxt Hdr : 58 skb:104
Aug 1 16:18:35 localhost kernel: Recived IPv6 packet with next hdr as 58
from fe80:0000:0000:0218:f3ff:feda:83cb:f521600001
Aug 1 16:18:35 localhost kernel: packet Len : 64 nxt Hdr : 58 skb:104
Aug 1 16:18:37 localhost kernel: Recived IPv6 packet with next hdr as 41
from 3ffe:0300:0068:020c:29ff:fea2:b14c:f521600001
Aug 1 16:18:37 localhost kernel: packet Len : 140 nxt Hdr : 41 skb:180
Aug 1 16:18:37 localhost kernel: Slab corruption: start=f50ba4dc, len=176
Aug 1 16:18:37 localhost kernel: Redzone: 0x5a2cf071/0x5a2cf071.
Aug 1 16:18:37 localhost kernel: Last user:
[<c055d930>](kfree_skbmem+0x63/0x66)
Aug 1 16:18:37 localhost kernel: 090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6a 6b 6b 6b
Aug 1 16:18:37 localhost kernel: Single bit error detected. Probably bad
RAM.
Aug 1 16:18:37 localhost kernel: Run memtest86+ or a similar memory test
tool.
Aug 1 16:18:37 localhost kernel: Prev obj: start=f50ba420, len=176
Aug 1 16:18:37 localhost kernel: Redzone: 0x170fc2a5/0x170fc2a5.
Aug 1 16:18:37 localhost kernel: Last user:
[<c055e041>](__alloc_skb+0x2c/0xfd)
Aug 1 16:18:37 localhost kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Aug 1 16:18:37 localhost kernel: 010: 00 00 00 00 00 60 21 f5 00 00 00 00
00 00 00 00
Aug 1 16:18:37 localhost kernel: Next obj: start=f50ba598, len=176
Aug 1 16:18:37 localhost kernel: Redzone: 0x170fc2a5/0x170fc2a5.
Aug 1 16:18:37 localhost kernel: Last user:
[<c055e041>](__alloc_skb+0x2c/0xfd)
Aug 1 16:18:37 localhost kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Aug 1 16:18:37 localhost kernel: 010: 00 00 00 00 00 00 f6 f7 00 00 00 00
00 00 00 00
^ permalink raw reply
* Re: net-2.6.24 GIT state
From: Ilpo Järvinen @ 2007-08-10 6:57 UTC (permalink / raw)
To: David Miller; +Cc: Netdev
In-Reply-To: <20070809.182719.99676246.davem@davemloft.net>
On Thu, 9 Aug 2007, David Miller wrote:
> I applied everything up until the SACK validator to net-2.6.24
Ok, thanks.
> Everything I hit today which had not been posted before was trivial
> fix or a reasonable small cleanup.
...Yeah, I know that but don't want to give impression that something
gets "sneaked" in...
> Why don't you just post the patches to the list one-by-one from
> now on so we can review them in parallel with merging into
> net-2.6.24?
Ok, will do. ...I thought that at some point that would be wise way
forward...
--
i.
^ permalink raw reply
* Re: [PATCH][Take2] PCI legacy I/O port free driver - Making Intel e1000 driver legacy I/O port free
From: Tomohiro Kusumi @ 2007-08-10 5:40 UTC (permalink / raw)
To: auke-jan.h.kok, cramerj, john.ronciak, jesse.brandeburg,
jeffrey.t.kirsher
Cc: gregkh, netdev, linux-kernel
In-Reply-To: <46BBF49F.6060701@jp.fujitsu.com>
Dear Auke
Sorry I sent the wrong patch.
I resubmit the patch.
Tomohiro Kusumi
Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@jp.fujitsu.com>
---
diff -Nurp linux-2.6.22.org/drivers/net/e1000/e1000.h linux-2.6.22/drivers/net/e1000/e1000.h
--- linux-2.6.22.org/drivers/net/e1000/e1000.h 2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/drivers/net/e1000/e1000.h 2007-08-10 09:56:03.000000000 +0900
@@ -342,6 +342,9 @@ struct e1000_adapter {
boolean_t quad_port_a;
unsigned long flags;
uint32_t eeprom_wol;
+
+ int use_ioport;
+ int bars;
};
enum e1000_state_t {
diff -Nurp linux-2.6.22.org/drivers/net/e1000/e1000_main.c linux-2.6.22/drivers/net/e1000/e1000_main.c
--- linux-2.6.22.org/drivers/net/e1000/e1000_main.c 2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/drivers/net/e1000/e1000_main.c 2007-08-10 14:27:41.000000000 +0900
@@ -222,6 +222,11 @@ static pci_ers_result_t e1000_io_error_d
static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev);
static void e1000_io_resume(struct pci_dev *pdev);
+static unsigned int enable_legacy_ioport_free = 0;
+module_param(enable_legacy_ioport_free, uint, 0644);
+MODULE_PARM_DESC(enable_legacy_ioport_free, "Enable legacy I/O port free (default:0)");
+static int e1000_test_legacy_ioport(struct pci_dev *pdev);
+
static struct pci_error_handlers e1000_err_handler = {
.error_detected = e1000_io_error_detected,
.slot_reset = e1000_io_slot_reset,
@@ -868,8 +873,25 @@ e1000_probe(struct pci_dev *pdev,
int i, err, pci_using_dac;
uint16_t eeprom_data = 0;
uint16_t eeprom_apme_mask = E1000_EEPROM_APME;
- if ((err = pci_enable_device(pdev)))
+ int bars = 0;
+ int use_ioport = 0;
+
+ if (enable_legacy_ioport_free) {
+ if ((use_ioport = e1000_test_legacy_ioport(pdev)) < 0) {
+ E1000_ERR("e1000_test_legacy_ioport failed, aborting\n");
+ return -1;
+ }
+ if (use_ioport)
+ bars = pci_select_bars(pdev, IORESOURCE_MEM | IORESOURCE_IO);
+ else
+ bars = pci_select_bars(pdev, IORESOURCE_MEM);
+
+ if ((err = pci_enable_device_bars(pdev, bars)))
+ return err;
+ }
+ else if ((err = pci_enable_device(pdev))) {
return err;
+ }
if (!(err = pci_set_dma_mask(pdev, DMA_64BIT_MASK)) &&
!(err = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK))) {
@@ -883,7 +905,8 @@ e1000_probe(struct pci_dev *pdev,
pci_using_dac = 0;
}
- if ((err = pci_request_regions(pdev, e1000_driver_name)))
+ if ((enable_legacy_ioport_free && (err = pci_request_selected_regions(pdev, bars, e1000_driver_name))) ||
+ (err = pci_request_regions(pdev, e1000_driver_name)))
goto err_pci_reg;
pci_set_master(pdev);
@@ -902,6 +925,10 @@ e1000_probe(struct pci_dev *pdev,
adapter->pdev = pdev;
adapter->hw.back = adapter;
adapter->msg_enable = (1 << debug) - 1;
+ if (enable_legacy_ioport_free) {
+ adapter->use_ioport = use_ioport;
+ adapter->bars = bars;
+ }
mmio_start = pci_resource_start(pdev, BAR_0);
mmio_len = pci_resource_len(pdev, BAR_0);
@@ -911,12 +938,14 @@ e1000_probe(struct pci_dev *pdev,
if (!adapter->hw.hw_addr)
goto err_ioremap;
- for (i = BAR_1; i <= BAR_5; i++) {
- if (pci_resource_len(pdev, i) == 0)
- continue;
- if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
- adapter->hw.io_base = pci_resource_start(pdev, i);
- break;
+ if (!enable_legacy_ioport_free || adapter->use_ioport) {
+ for (i = BAR_1; i <= BAR_5; i++) {
+ if (pci_resource_len(pdev, i) == 0)
+ continue;
+ if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
+ adapter->hw.io_base = pci_resource_start(pdev, i);
+ break;
+ }
}
}
@@ -1182,7 +1211,10 @@ err_sw_init:
err_ioremap:
free_netdev(netdev);
err_alloc_etherdev:
- pci_release_regions(pdev);
+ if (enable_legacy_ioport_free)
+ pci_release_selected_regions(pdev, bars);
+ else
+ pci_release_regions(pdev);
err_pci_reg:
err_dma:
pci_disable_device(pdev);
@@ -1234,7 +1266,10 @@ e1000_remove(struct pci_dev *pdev)
iounmap(adapter->hw.hw_addr);
if (adapter->hw.flash_address)
iounmap(adapter->hw.flash_address);
- pci_release_regions(pdev);
+ if (enable_legacy_ioport_free)
+ pci_release_selected_regions(pdev, adapter->bars);
+ else
+ pci_release_regions(pdev);
free_netdev(netdev);
@@ -5175,7 +5210,8 @@ e1000_resume(struct pci_dev *pdev)
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
- if ((err = pci_enable_device(pdev))) {
+ if ((enable_legacy_ioport_free && (err = pci_enable_device_bars(pdev, adapter->bars))) ||
+ (err = pci_enable_device(pdev))) {
printk(KERN_ERR "e1000: Cannot enable PCI device from suspend\n");
return err;
}
@@ -5320,4 +5356,43 @@ static void e1000_io_resume(struct pci_d
}
+/*
+ * e1000_test_legacy_ioport - see if the device uses legacy I/O port
+ * @pdev: Pointer to PCI device
+ *
+ * This function tests if the PCI device uses I/O port.
+ * If yes the function returns 1, if no the function returns 0.
+ * The function returns -1 if there is an error.
+ */
+
+static int e1000_test_legacy_ioport(struct pci_dev *pdev)
+{
+ int ret;
+ struct e1000_hw hw;
+ memset(&hw, 0, sizeof(hw));
+
+ hw.mac_type = e1000_undefined;
+ hw.device_id = pdev->device;
+ pci_read_config_byte(pdev, PCI_REVISION_ID, &hw.revision_id);
+
+ if (e1000_set_mac_type(&hw) < 0)
+ return -1;
+
+ switch (hw.mac_type) {
+ case e1000_82540:
+ case e1000_82541:
+ case e1000_82541_rev_2:
+ case e1000_82544:
+ case e1000_82545:
+ case e1000_82546:
+ ret = 1;
+ break;
+ default:
+ ret = 0;
+ break;
+ }
+
+ return ret;
+}
+
/* e1000_main.c */
^ permalink raw reply
* [PATCH][Take2] PCI legacy I/O port free driver - Making Intel e1000 driver legacy I/O port free
From: Tomohiro Kusumi @ 2007-08-10 5:16 UTC (permalink / raw)
To: auke-jan.h.kok, cramerj, john.ronciak, jesse.brandeburg,
jeffrey.t.kirsher
Cc: gregkh, netdev, linux-kernel
Dear Auke
http://lkml.org/lkml/2007/5/16/275
> I'm ok with the bottom part of the patch, but I do not like the modification of
> the pci device ID table in this way. As Arjan van der Ven previously commented
> as well, this makes it hard for future device ID's to be bound to the driver.
>
> On top of that, there is no logical correlation between the mapping and
> chipsets, so a lot of information is lost in that table. It really does not show
> which _chipsets_ support this functionality.
>
> I think if we want to work with this, we need some way of mapping the device
> ID's back to chipsets, and enable the feature on that basis.
This patches will meet your need in the way that it shows correlation
between their device IDs and the chipsets. It does not use the existing
macro INTEL_E1000_ETHERNET_DEVICE() to see whether the device uses I/O
port or not. Instead of modifying the PCI device table, I've added another
function called e1000_test_legacy_ioport() which tells you whether the PCI
device uses legacy I/O port or not by checking its chipset.
But one thing I want to say is that I am not sure about the chipsets that
require legacy I/O port. I found the following code in e1000 driver code
and it seems to be the only part that is using I/O port. So I thought
the following chipsets are the only ones using legacy I/O port.
I might be wrong, so any comments would be helpful.
drivers/net/e1000/e1000_hw.c
524 int32_t
525 e1000_reset_hw(struct e1000_hw *hw)
526 {
...
618 switch (hw->mac_type) {
619 case e1000_82544:
620 case e1000_82540:
621 case e1000_82545:
622 case e1000_82546:
623 case e1000_82541:
624 case e1000_82541_rev_2:
625 /* These controllers can't ack the 64-bit write when issuing the
626 * reset, so use IO-mapping as a workaround to issue the reset */
627 E1000_WRITE_REG_IO(hw, CTRL, (ctrl | E1000_CTRL_RST));
> I also would like this option to be non-default, IOW use legacy IO by default,
> and allow the user to specify a module load option to disable use of this feature:
I've also added the module parameter so that the user can select whether
he or she wants to enable the legacy I/O port free. The legacy I/O port free
option is non-default.
Rest of the part has not been changed since my previous patch. Any comments
would be helpful.
Tomohiro Kusumi
Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@jp.fujitsu.com>
---
diff -Nurp linux-2.6.22.org/drivers/net/e1000/e1000.h linux-2.6.22/drivers/net/e1000/e1000.h
--- linux-2.6.22.org/drivers/net/e1000/e1000.h 2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/drivers/net/e1000/e1000.h 2007-08-10 09:56:03.000000000 +0900
@@ -342,6 +342,9 @@ struct e1000_adapter {
boolean_t quad_port_a;
unsigned long flags;
uint32_t eeprom_wol;
+
+ int use_ioport;
+ int bars;
};
enum e1000_state_t {
diff -Nurp linux-2.6.22.org/drivers/net/e1000/e1000_main.c linux-2.6.22/drivers/net/e1000/e1000_main.c
--- linux-2.6.22.org/drivers/net/e1000/e1000_main.c 2007-07-09 08:32:17.000000000 +0900
+++ linux-2.6.22/drivers/net/e1000/e1000_main.c 2007-08-10 13:09:25.000000000 +0900
@@ -222,6 +222,11 @@ static pci_ers_result_t e1000_io_error_d
static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev);
static void e1000_io_resume(struct pci_dev *pdev);
+static unsigned int enable_legacy_ioport_free = 0;
+module_param(enable_legacy_ioport_free, uint, 0644);
+MODULE_PARM_DESC(enable_legacy_ioport_free, "Enable legacy I/O port free (default:0)");
+static int e1000_test_legacy_ioport(struct pci_dev *pdev);
+
static struct pci_error_handlers e1000_err_handler = {
.error_detected = e1000_io_error_detected,
.slot_reset = e1000_io_slot_reset,
@@ -868,8 +873,22 @@ e1000_probe(struct pci_dev *pdev,
int i, err, pci_using_dac;
uint16_t eeprom_data = 0;
uint16_t eeprom_apme_mask = E1000_EEPROM_APME;
- if ((err = pci_enable_device(pdev)))
+ int bars = 0;
+ int use_ioport = 0;
+
+ if (enable_legacy_ioport_free) {
+ if ((use_ioport = e1000_test_legacy_ioport(pdev)) < 0) {
+ E1000_ERR("e1000_test_legacy_ioport failed, aborting\n");
+ return -1;
+ }
+ if (use_ioport)
+ bars = pci_select_bars(pdev, IORESOURCE_MEM | IORESOURCE_IO);
+ else
+ bars = pci_select_bars(pdev, IORESOURCE_MEM);
+ }
+ else if ((err = pci_enable_device(pdev))) {
return err;
+ }
if (!(err = pci_set_dma_mask(pdev, DMA_64BIT_MASK)) &&
!(err = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK))) {
@@ -883,7 +902,8 @@ e1000_probe(struct pci_dev *pdev,
pci_using_dac = 0;
}
- if ((err = pci_request_regions(pdev, e1000_driver_name)))
+ if ((enable_legacy_ioport_free && (err = pci_request_selected_regions(pdev, bars, e1000_driver_name))) ||
+ (err = pci_request_regions(pdev, e1000_driver_name)))
goto err_pci_reg;
pci_set_master(pdev);
@@ -902,6 +922,10 @@ e1000_probe(struct pci_dev *pdev,
adapter->pdev = pdev;
adapter->hw.back = adapter;
adapter->msg_enable = (1 << debug) - 1;
+ if (enable_legacy_ioport_free) {
+ adapter->use_ioport = use_ioport;
+ adapter->bars = bars;
+ }
mmio_start = pci_resource_start(pdev, BAR_0);
mmio_len = pci_resource_len(pdev, BAR_0);
@@ -911,12 +935,14 @@ e1000_probe(struct pci_dev *pdev,
if (!adapter->hw.hw_addr)
goto err_ioremap;
- for (i = BAR_1; i <= BAR_5; i++) {
- if (pci_resource_len(pdev, i) == 0)
- continue;
- if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
- adapter->hw.io_base = pci_resource_start(pdev, i);
- break;
+ if (!enable_legacy_ioport_free || adapter->use_ioport) {
+ for (i = BAR_1; i <= BAR_5; i++) {
+ if (pci_resource_len(pdev, i) == 0)
+ continue;
+ if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
+ adapter->hw.io_base = pci_resource_start(pdev, i);
+ break;
+ }
}
}
@@ -1182,7 +1208,10 @@ err_sw_init:
err_ioremap:
free_netdev(netdev);
err_alloc_etherdev:
- pci_release_regions(pdev);
+ if (enable_legacy_ioport_free)
+ pci_release_selected_regions(pdev, bars);
+ else
+ pci_release_regions(pdev);
err_pci_reg:
err_dma:
pci_disable_device(pdev);
@@ -1234,7 +1263,10 @@ e1000_remove(struct pci_dev *pdev)
iounmap(adapter->hw.hw_addr);
if (adapter->hw.flash_address)
iounmap(adapter->hw.flash_address);
- pci_release_regions(pdev);
+ if (enable_legacy_ioport_free)
+ pci_release_selected_regions(pdev, adapter->bars);
+ else
+ pci_release_regions(pdev);
free_netdev(netdev);
@@ -5175,7 +5207,8 @@ e1000_resume(struct pci_dev *pdev)
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
- if ((err = pci_enable_device(pdev))) {
+ if ((enable_legacy_ioport_free && (err = pci_enable_device_bars(pdev, adapter->bars))) ||
+ (err = pci_enable_device(pdev))) {
printk(KERN_ERR "e1000: Cannot enable PCI device from suspend\n");
return err;
}
@@ -5320,4 +5353,43 @@ static void e1000_io_resume(struct pci_d
}
+/*
+ * e1000_test_legacy_ioport - see if the device uses legacy I/O port
+ * @pdev: Pointer to PCI device
+ *
+ * This function tests if the PCI device uses I/O port.
+ * If yes the function returns 1, if no the function returns 0.
+ * The function returns -1 if there is an error.
+ */
+
+static int e1000_test_legacy_ioport(struct pci_dev *pdev)
+{
+ int ret;
+ struct e1000_hw hw;
+ memset(&hw, 0, sizeof(hw));
+
+ hw.mac_type = e1000_undefined;
+ hw.device_id = pdev->device;
+ pci_read_config_byte(pdev, PCI_REVISION_ID, &hw.revision_id);
+
+ if (e1000_set_mac_type(&hw) < 0)
+ return -1;
+
+ switch (hw.mac_type) {
+ case e1000_82540:
+ case e1000_82541:
+ case e1000_82541_rev_2:
+ case e1000_82544:
+ case e1000_82545:
+ case e1000_82546:
+ ret = 1;
+ break;
+ default:
+ ret = 0;
+ break;
+ }
+
+ return ret;
+}
+
/* e1000_main.c */
^ permalink raw reply
* [PATCH 2.6.24]S2io: Default to IntA interrupt type when there are less than 4 CPUs in the system.
From: Sivakumar Subramani @ 2007-08-10 5:04 UTC (permalink / raw)
To: netdev, jeff; +Cc: support
- Default to IntA interrupt type when there are less than 4 CPUs in the system.
Signed-off-by: Sivakumar Subramani <sivakumar.subramani@neterion.com>
Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
---
diff -Nurp 2.0.26.2/drivers/net/s2io.c 2.0.26.3/drivers/net/s2io.c
--- 2.0.26.2/drivers/net/s2io.c 2007-08-07 13:39:45.000000000 -0700
+++ 2.0.26.3/drivers/net/s2io.c 2007-08-07 15:51:45.000000000 -0700
@@ -84,7 +84,7 @@
#include "s2io.h"
#include "s2io-regs.h"
-#define DRV_VERSION "2.0.26.2"
+#define DRV_VERSION "2.0.26.3"
/* S2io Driver name & version. */
static char s2io_driver_name[] = "Neterion";
@@ -452,7 +452,7 @@ S2IO_PARM_INT(l3l4hdr_size, 128);
/* Frequency of Rx desc syncs expressed as power of 2 */
S2IO_PARM_INT(rxsync_frequency, 3);
/* Interrupt type. Values can be 0(INTA), 2(MSI_X) */
-S2IO_PARM_INT(intr_type, 2);
+S2IO_PARM_INT(intr_type, DEF_MSI_X);
/* Large receive offload feature */
S2IO_PARM_INT(lro, 0);
/* Max pkts to be aggregated by LRO at one time. If not specified,
@@ -7671,10 +7671,11 @@ static int s2io_verify_parm(struct pci_d
if (*dev_intr_type != INTA)
napi = 0;
- if ((*dev_intr_type != INTA) && (*dev_intr_type != MSI_X)) {
+ if ((intr_type != INTA) && (intr_type != MSI_X)) {
DBG_PRINT(ERR_DBG, "s2io: Wrong intr_type requested. "
"Defaulting to INTA\n");
*dev_intr_type = INTA;
+ intr_type = INTA;
}
if ((*dev_intr_type == MSI_X) &&
@@ -7752,8 +7753,19 @@ s2io_init_nic(struct pci_dev *pdev, cons
struct mac_info *mac_control;
struct config_param *config;
int mode;
- u8 dev_intr_type = intr_type;
+ u8 dev_intr_type;
+ int no_cpus = 1;
+ no_cpus = num_online_cpus();
+ if(DEF_MSI_X == intr_type) {
+ /* Don't enable MSI-X if there are less than 4 CPUs */
+ if(no_cpus < 4)
+ intr_type = INTA;
+ else
+ intr_type = MSI_X;
+ }
+
+ dev_intr_type = intr_type;
if ((ret = s2io_verify_parm(pdev, &dev_intr_type)))
return ret;
diff -Nurp 2.0.26.2/drivers/net/s2io.h 2.0.26.3/drivers/net/s2io.h
--- 2.0.26.2/drivers/net/s2io.h 2007-08-07 13:39:45.000000000 -0700
+++ 2.0.26.3/drivers/net/s2io.h 2007-08-07 13:40:18.000000000 -0700
@@ -433,6 +433,7 @@ struct config_param {
u64 tx_intr_type;
#define INTA 0
#define MSI_X 2
+#define DEF_MSI_X 99
u8 intr_type;
u8 napi;
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: Eric W. Biederman @ 2007-08-10 2:35 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明
Cc: davem, akpm, linux-kernel, devel, adobriyan, netdev
In-Reply-To: <20070810.112915.63714468.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> writes:
> In article <m1odhg6sbv.fsf@ebiederm.dsl.xmission.com> (at Thu, 09 Aug 2007
> 20:23:16 -0600), ebiederm@xmission.com (Eric W. Biederman) says:
>
>> YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> writes:
>>
>> > Would you explain why it does not work properly
>> > for those cases?
>>
>> Mostly no appropriate strategy routine was setup to
>> report the data to the caller of sys_sysctl.
>
> I assume that default strategy have been existing for it, no?!
> Maybe, I do miss something...
I'd have to go through it case by case. But in general
unless your proc_handler is proc_dointvec the default
strategy routine which does a raw binary copy of your data
out will generally do the wrong thing.
So especially if your data is jiffies or otherwise needs
processing you don't want to use the default strategy
routine.
Until relatively recently no one was really policing the
sysctl interfaces and even now it isn't too serious.
Eric
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-08-10 2:29 UTC (permalink / raw)
To: ebiederm; +Cc: davem, akpm, linux-kernel, devel, adobriyan, netdev, yoshfuji
In-Reply-To: <m1odhg6sbv.fsf@ebiederm.dsl.xmission.com>
In article <m1odhg6sbv.fsf@ebiederm.dsl.xmission.com> (at Thu, 09 Aug 2007 20:23:16 -0600), ebiederm@xmission.com (Eric W. Biederman) says:
> YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> writes:
>
> > Would you explain why it does not work properly
> > for those cases?
>
> Mostly no appropriate strategy routine was setup to
> report the data to the caller of sys_sysctl.
I assume that default strategy have been existing for it, no?!
Maybe, I do miss something...
--yoshfuji
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: Eric W. Biederman @ 2007-08-10 2:23 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明
Cc: davem, ebiederm, akpm, linux-kernel, devel, adobriyan, netdev
In-Reply-To: <20070810.111420.29442251.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> writes:
> Would you explain why it does not work properly
> for those cases?
Mostly no appropriate strategy routine was setup to
report the data to the caller of sys_sysctl.
Eric
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-08-10 2:22 UTC (permalink / raw)
To: ebiederm; +Cc: akpm, linux-kernel, devel, adobriyan, netdev, davem, yoshfuji
In-Reply-To: <m1zm108axi.fsf_-_@ebiederm.dsl.xmission.com>
In article <m1zm108axi.fsf_-_@ebiederm.dsl.xmission.com> (at Thu, 09 Aug 2007 18:56:09 -0600), ebiederm@xmission.com (Eric W. Biederman) says:
>
> - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary
> sysctl names for a function that works with proc.
:
Well, retrans_time_ms and base_reachable_time_ms supercedes
retrans_time and base_reachable_time, we've warned for long
time for its deprecation. So, maybe, it is time to remove
the old interfaces (retrans_time and base_reachable_time)
and simplify ndisc_ifinfo_syctl_change().
--yoshfuji
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: Eric W. Biederman @ 2007-08-10 2:12 UTC (permalink / raw)
To: Andrew Morton
Cc: YOSHIFUJI Hideaki / 吉藤英明,
linux-kernel, devel, adobriyan, netdev, davem
In-Reply-To: <20070809185521.c3ab1afd.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
> But it is good to remove bad interfaces, if we possibly can.
>
> It is worth making the attempt. Does anyone know of anything which will
> break? I fed NET_NEIGH_ANYCAST_DELAY at random into
> http://www.google.com/codesearch and came up with nothing...
My current policy is that since I could only find 5 real world linux
programs that even call sys_sysctl, that if I find a broken sysctl
binary interface I'm lazy and just remove it. The only networking one
I know of is radvd.
Added to that I just pushed an autochecking sysctl patch to Andrew
that fails register_sysctl_table if the sysctl table is broken. And
all of these showed up. So some fix was needed or things would have
been even worse.
Eric
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-08-10 2:14 UTC (permalink / raw)
To: davem; +Cc: ebiederm, akpm, linux-kernel, devel, adobriyan, netdev, yoshfuji
In-Reply-To: <20070809.184921.11594412.davem@davemloft.net>
In article <20070809.184921.11594412.davem@davemloft.net> (at Thu, 09 Aug 2007 18:49:21 -0700 (PDT)), David Miller <davem@davemloft.net> says:
> From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
> Date: Fri, 10 Aug 2007 10:47:10 +0900 (JST)
>
> > I disagree. It is bad to remove existing interface.
> > Ditto for other patches.
>
> I think perhaps you misunderstand what Eric is doing.
>
> sys_sysctl() isn't working properly for these cases and it is both a
> deprecated interface and not worth the pain of adding support
> in these cases.
Would you explain why it does not work properly
for those cases?
--yoshfuji
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: Andrew Morton @ 2007-08-10 1:55 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明
Cc: ebiederm, linux-kernel, devel, adobriyan, netdev, davem
In-Reply-To: <20070810.104710.28739250.yoshfuji@linux-ipv6.org>
On Fri, 10 Aug 2007 10:47:10 +0900 (JST) YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> wrote:
> Hello.
>
> In article <m1zm108axi.fsf_-_@ebiederm.dsl.xmission.com> (at Thu, 09 Aug 2007 18:56:09 -0600), ebiederm@xmission.com (Eric W. Biederman) says:
>
> >
> > - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary
> > sysctl names for a function that works with proc.
> >
> > - In neighbour.c reorder the table to put the possibly unused entries
> > at the end so we can remove them by terminating the table early.
> >
> > - In neighbour.c kill the entries with questionable binary sysctl
> > handling behavior.
> >
> > - In neighbour.c if we don't have a strategy routine remove the
> > binary path. So we don't the default sysctl strategy routine
> > on data that is not ready for it.
> >
>
> I disagree. It is bad to remove existing interface.
But it is good to remove bad interfaces, if we possibly can.
It is worth making the attempt. Does anyone know of anything which will
break? I fed NET_NEIGH_ANYCAST_DELAY at random into
http://www.google.com/codesearch and came up with nothing...
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: David Miller @ 2007-08-10 1:49 UTC (permalink / raw)
To: yoshfuji; +Cc: ebiederm, akpm, linux-kernel, devel, adobriyan, netdev
In-Reply-To: <20070810.104710.28739250.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
Date: Fri, 10 Aug 2007 10:47:10 +0900 (JST)
> I disagree. It is bad to remove existing interface.
> Ditto for other patches.
I think perhaps you misunderstand what Eric is doing.
sys_sysctl() isn't working properly for these cases and it is both a
deprecated interface and not worth the pain of adding support
in these cases.
The fact that nobody complains that none of this stuff works
via sys_sysctl() to me proves that it is never used.
^ permalink raw reply
* Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-08-10 1:47 UTC (permalink / raw)
To: ebiederm; +Cc: akpm, linux-kernel, devel, adobriyan, netdev, davem, yoshfuji
In-Reply-To: <m1zm108axi.fsf_-_@ebiederm.dsl.xmission.com>
Hello.
In article <m1zm108axi.fsf_-_@ebiederm.dsl.xmission.com> (at Thu, 09 Aug 2007 18:56:09 -0600), ebiederm@xmission.com (Eric W. Biederman) says:
>
> - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary
> sysctl names for a function that works with proc.
>
> - In neighbour.c reorder the table to put the possibly unused entries
> at the end so we can remove them by terminating the table early.
>
> - In neighbour.c kill the entries with questionable binary sysctl
> handling behavior.
>
> - In neighbour.c if we don't have a strategy routine remove the
> binary path. So we don't the default sysctl strategy routine
> on data that is not ready for it.
>
I disagree. It is bad to remove existing interface.
Ditto for other patches.
Regards,
--yoshfuji
^ permalink raw reply
* Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
From: Paul E. McKenney @ 2007-08-10 1:28 UTC (permalink / raw)
To: Chris Snook
Cc: linux-kernel, linux-arch, torvalds, netdev, akpm, ak,
heiko.carstens, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl
In-Reply-To: <46BB69F8.5000502@redhat.com>
On Thu, Aug 09, 2007 at 03:24:40PM -0400, Chris Snook wrote:
> Paul E. McKenney wrote:
> >On Thu, Aug 09, 2007 at 02:13:52PM -0400, Chris Snook wrote:
> >>Paul E. McKenney wrote:
> >>>On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:
> >>>> If you're depending on volatile writes
> >>>>being visible to other CPUs, you're screwed either way, because the CPU
> >>>>can hold that data in cache as long as it wants before it writes it to
> >>>>memory. When this finally does happen, it will happen atomically,
> >>>>which is all that atomic_set guarantees. If you need to guarantee that
> >>>>the value is written to memory at a particular time in your execution
> >>>>sequence, you either have to read it from memory to force the compiler
> >>>>to store it first (and a volatile cast in atomic_read will suffice for
> >>>>this) or you have to use LOCK_PREFIX instructions which will invalidate
> >>>>remote cache lines containing the same variable. This patch doesn't
> >>>>change either of these cases.
> >>>The case that it -can- change is interactions with interrupt handlers.
> >>>And NMI/SMI handlers, for that matter.
> >>You have a point here, but only if you can guarantee that the interrupt
> >>handler is running on a processor sharing the cache that has the
> >>not-yet-written volatile value. That implies a strictly non-SMP
> >>architecture. At the moment, none of those have volatile in their
> >>declaration of atomic_t, so this patch can't break any of them.
> >
> >This can also happen when using per-CPU variables. And there are a
> >number of per-CPU variables that are either atomic themselves or are
> >structures containing atomic fields.
>
> Accessing per-CPU variables in this fashion reliably already requires a
> suitable smp/non-smp read/write memory barrier. I maintain that if we
> break anything with this change, it was really already broken, if less
> obviously. Can you give a real or synthetic example of legitimate code
> that could break?
My main concern is actually the lack of symmetry -- I would expect
that an atomic_set() would have the same properties as atomic_read().
It is easy and cheap to provide them with similar properties, so why not?
Debugging even a single problem would consume far more time than simply
giving them corresponding semantics.
But you asked for examples. These are synthetic, and of course legitimacy
is in the eye of the beholder.
1. Watchdog variable.
atomic_t watchdog = ATOMIC_INIT(0);
...
int i;
while (!done) {
/* Do so stuff that doesn't take more than a few us. */
/* Could do atomic increment, but throughput penalty. */
i++;
atomic_set(&watchdog, i);
}
do_something_with(&watchdog);
/* Every so often on some other CPU... */
if ((new_watchdog = atomic_read(&watchdog)) == old_watchdog)
die_horribly();
old_watchdog = new_watchdog;
If atomic_set() did not have volatile semantics, the compiler
would be within its rights optimizing it to simply get the
final value of "i" after exit from the loop. This would cause
the watchdog check to fail spuriously. Memory barriers are
not required in this case, because the CPU cannot hang onto
the value for very long -- we don't care about the exact value,
or about exact synchronization, but rather about whether or
not the value is changing.
In this (toy) example, one might replace the atomic_set() with
an atomic increment (though that might be too expensive in some
cases) or with something like:
atomic_set(&watchdog, atomic_read(&watchdog) + 1);
However, other cases might not permit this transformation,
for example, an existing heavily used API might take int rather
than atomic_t.
Some will no doubt argue that this example should use a
macro or an asm similar to the "forget()" asm put forward
elsewhere in this thread.
2. Communicating both with interrupt handler and with other CPUs.
For example, data elements that are built up in a location visible
to interrupts and NMIs, and then added as a unit to a data structure
visible to other CPUs. This more-realistic example is abbreviated
to the point of pointlessness as follows:
struct foo {
atomic_t a;
atomic_t b;
};
DEFINE_PER_CPU(struct foo *, staging) = NULL;
/* Create element in staging area. */
__get_cpu_var(staging) = kzalloc(sizeof(*p), GFP_WHATEVER);
if (__get_cpu_var(staging) == NULL)
die_horribly();
/* allocate an element of some per-CPU array, get the result in "i" */
atomic_set(__get_cpu_var(staging).a, i);
/* allocate another element of a per-CPU array, with result in "i" */
atomic_set(__get_cpu_var(staging).b, i);
rcu_assign_pointer(some_global_place, __get_cpu_var(staging));
If atomic_set() didn't have volatile semantics, then an interrupt
or NMI handler could see the atomic_set() to .a and .b out of
order due to compiler optimizations.
Remember, you -did- ask for these!!! ;-)
Thanx, Paul
^ permalink raw reply
* Re: net-2.6.24 GIT state
From: David Miller @ 2007-08-10 1:27 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0708091721030.24369@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Thu, 9 Aug 2007 17:40:07 +0300 (EEST)
> Next step:
>
> http://www.cs.helsinki.fi/u/ijjarvin/tcp-rebase/after-reorder/
>
> ...I put some effort to reorganization and there's the result, please
> _don't_ take the new SACK block-validator yet as I haven't yet put it
> under any testing (it's the only difference this reordering of patches
> seems to have introduced :-)). The first five commits touch left_out (4
> latest fix bug and "flaws" I made in the first commit), I could combine
> them into a single one if you want to.
I applied everything up until the SACK validator to net-2.6.24
Thanks for doing all of this merging work, I very much appreciate
it.
> ...Notice that part of the next step includes work that hasn't yet been
> posted to netdev at all (was from my not yet submitted wip portion of
> it). Would you prefer me to post them using the usual procedure?
Everything I hit today which had not been posted before was trivial
fix or a reasonable small cleanup.
Why don't you just post the patches to the list one-by-one from
now on so we can review them in parallel with merging into
net-2.6.24?
Thanks again Ilpo!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox