The latest git pull from wireless-dev (g7844a579) is calling a sleeping
function with irq's
disabled. The kernel is a UP version with preemption disabled. The dump is as
follows:
kernel: bcm43xx_d80211: Virtual interface added (type: 0x0002, ID: 4, MAC:
00:06:25:40:6f:03)
kernel: bcm43xx_d8
Seen during boot of a 2.6.18rc5-git1 based kernel.
Dave
===
[ INFO: possible circular locking dependency detected ]
2.6.17-1.2608.fc6 #1
---
swapper/0 is trying to acquire lock:
Krzysztof Halasa <[EMAIL PROTECTED]> :
[...]
> ===
> [ INFO: possible circular locking dependency detected ]
> ---
> swapper/0 is trying to acquire lock:
> (&dev->queue_lock){-+..}, at: [] dev_q
Ar Sad, 2006-09-02 am 22:14 +0200, ysgrifennodd Krzysztof Halasa:
> ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14
> ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15
>
> There is no secondary IDE connector on this motherboard, I think
> it's just disabled by BIOS.
>
>
> What I great idea. Now I just have to get every host I want to
> interoperate with to support a nonstandard configuration. The scary
> part is that if I motivate it with "Linux is too stupid to handle
> standard tunnel-mode IPsec" I might actually get away with it.
>
>
Linux
Hi,
FYI: Just enabled kernel lock testers on my old laptop machine
doing "internet services". 2.6.18-rc5, i686. All details available
on request, of course.
There is IP GRE tunnel here running over ADSL connection (USB
Thomson/Alcatel Speedtouch 330, PPP over ATM, in-kernel drivers).
Ethernet is
Hi,
Keywords: nForce PCIe, forcedeth, nForce PATA, Radeon DRM, ALC883 HDA sound
FYI: running 2.6.18-rc5 + pata-drivers on MSI mb K9N Ultra (NVidia
MCP55, PCIe, Athlon64, x86_64, no SMP, no preempt) gives the following
(all details available on request, of course):
"Nvidia board detected. Ignorin
On Sat, 2 Sep 2006, jamal wrote:
> On Sat, 2006-02-09 at 11:04 -0400, James Morris wrote:
> > On Sat, 2 Sep 2006, jamal wrote:
>
> > +
> > + spin_lock(&xfrm_state_lock);
> >
> > Shouldn't this be spin_lock_bh()?
> >
> > + spin_unlock(&xfrm_state_lock);
> > +
>
> the call is
On Sat, 2006-02-09 at 13:16 -0400, jamal wrote:
> the call is made at the moment only by pktgen (kernel threads on
> dev_queue_xmit level contending with softirqs essentially). I think
> (although havent tried) the spin_{un}lock_bh() wont work. Thoughts?
> Obviously the easy thing for me to do is
Stephen J. Bevan wrote:
H. Peter Anvin writes:
> Fair enough. However, that does beg a question: is there any sane way
> to create the pseudo-device model on top of the current model, as a
> convenience layer? That way you could get the best of both.
I assume you were using tunnel-mode I
On Sat, 2006-02-09 at 11:04 -0400, James Morris wrote:
> On Sat, 2 Sep 2006, jamal wrote:
> +
> + spin_lock(&xfrm_state_lock);
>
> Shouldn't this be spin_lock_bh()?
>
> + spin_unlock(&xfrm_state_lock);
> +
the call is made at the moment only by pktgen (kernel threads on
dev_q
H. Peter Anvin writes:
> Fair enough. However, that does beg a question: is there any sane way
> to create the pseudo-device model on top of the current model, as a
> convenience layer? That way you could get the best of both.
I assume you were using tunnel-mode IPsec and depending on exact
On Sat, 2 Sep 2006, jamal wrote:
> Against net-2.6.19
>
> signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>
+xfrm_stateonly_find(xfrm_address_t *daddr, xfrm_address_t *saddr,
+ unsigned short family, u32 reqid, u8 mode, u8 proto)
+{
+ unsigned int h = xfrm_dst_hash(daddr,
[XFRM]: Fix wildcard as tunnel source
Hashing SAs by source address breaks templates with wildcards as tunnel
source. Remove saddr from the hash key.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 19f7b6f33c0e9fbdf23a33506c2dfc0706b0c731
tree bca60eb94c50fcd66673bd87823fd38364b45b
I am getting "e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang" using
stock 2.6.17.11, 2.6.17.5 or 2.6.17.4 kernels on centos 4.3.
The server is a Tyan GS12 ( 82541GI/PI and 82547GI) and is connected to a
Netgear GS724T Gig switch. I can easily reproduce the problem by trying to
do a l
Against net-2.6.19
signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>
cheers,
jamal
Allow for searching the SAD from external data path points without
assumming L3 details. The only customer of this exposure currently
is pktgen.
---
commit 33d3060784e6aa55e30ae7d5efc491180e7f955d
tree 707017ff6
Brian Haley wrote:
> Sorry, next time I'll send them to you, or
> [EMAIL PROTECTED]
netfilter-devel is better, that way other people working on netfilter
get a chance to see it as well. I think only a handful of people on
netfilter-devel also follow netdev.
> I'll cook-up another patch for the
>
> It seems that the implementation (at code level) does not match with the
> actual behaviour. I would like to seek expertise on clarifying my
> understanding in UDP implementation so that this phenomenon can be
> explained.
How about you just add some printks or use a tool like systemtap to i
Hi,
found it.
This is the tcpdump, for your edification.
Note that many packets have "push" set for no good reason,
which generally indicates dropped packets if we're doing a bulk
transfer. But all packets that are visible in the dump reached their
destination..!
The culprit turns out to be the
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 01, 2006 at 01:55:15PM -0700, Stephen Hemminger ([EMAIL
> PROTECTED]) wrote:
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 111ff39..159fa3f 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -89,
On Fri, Sep 01, 2006 at 01:55:15PM -0700, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 111ff39..159fa3f 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -89,7 +89,7 @@ int sysctl_tcp_frto;
> int sysctl_tcp_nom
21 matches
Mail list logo
