headers
Auke Kok | 1 Jun 2006 01:30
Favicon
Gravatar

Re: DPRINTKs in e1000 code (2.6.x kernels)


On Wed, 31 May 2006 14:31:05 +0530, Amit K Arora <aarora <at> in.ibm.com> wrote:
> Hello,
> 
> I am wondering why this patch "e1000: Remove PM warning DPRINTKs
> breaking 2.4.x kernels"
> (http://www.mail-archive.com/netdev <at> vger.kernel.org/msg10803.html) was
> meant only for 2.4 kernels, and _not_ for 2.6 kernels.

this code was removed from our generic driver first which is available for 2.4 kernels as well. we try to keep
the in-kernel 2.4 and 2.6-driver as close to the general module because we spend a lot of time testing that
particular driver.

The removal from the 2.6 kernel has two motivations:
- sync with the standalone tarball driver on e1000.sf.net
- pci subsystem smartness should take care of warning on those operations

> These DPRINTKs in e1000_suspend() are currently resulting in following
> messages while rebooting a system (2.6 kernel) which has e1000 adapter:
> 
> 	Shutting down MD Raid
>     	done
> 	Stopping udevd:                                                      
> 	done
> 	proc umounted
> 	The system will be halted immediately.
> 	md: stopping all md devices.
> 	e1000: eth3: e1000_suspend: Error enabling D3 wake	<<==
> 	e1000: eth3: e1000_suspend: Error enabling D3 cold wake	<<==
> 	Power down.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jesse Brandeburg | 1 Jun 2006 02:04
Picon
Gravatar

2.6.17-rc5-mm1 lockdep output

well, when running e1000 through some code paths on FC4 +
2.6.17-rc5-mm1 + ingo's latest rollup patch, with this lockdep debug
option enabled I got this:

e1000: eth1: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex

======================================
[ BUG: bad unlock ordering detected! ]
--------------------------------------
mDNSResponder/2361 is trying to release lock (&in_dev->mc_list_lock) at:
 [<ffffffff81233f5a>] ip_mc_add_src+0x85/0x1f8
but the next lock to release is:
 (&im->lock){-+..}, at: [<ffffffff81233f52>] ip_mc_add_src+0x7d/0x1f8

other info that might help us debug this:
2 locks held by mDNSResponder/2361:
 #0:  (rtnl_mutex){--..}, at: [<ffffffff81253741>] mutex_lock+0x27/0x2c
 #1:  (&in_dev->mc_list_lock){-.-?}, at: [<ffffffff81233f14>]
ip_mc_add_src+0x3f/0x1f8

stack backtrace:

Call Trace:
  [<ffffffff8100a8c0>] show_trace+0xa4/0x204
        [<ffffffff8100ac32>] dump_stack+0x15/0x17
[<ffffffff8104495b>] lockdep_release+0x197/0x329
        [<ffffffff81254e45>] _read_unlock+0x1c/0x28
        [<ffffffff81233f5a>] ip_mc_add_src+0x85/0x1f8
        [<ffffffff812342f5>] ip_mc_inc_group+0x1b5/0x220
        [<ffffffff8123493e>] ip_mc_join_group+0xcf/0xf3
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Miller | 1 Jun 2006 02:09
Favicon

Re: netif_tx_disable and lockless TX

From: "Michael Chan" <mchan <at> broadcom.com>
Date: Wed, 31 May 2006 14:20:29 -0700

> David, So do we want to fix this issue as proposed by Herbert to replace
> tx_lock with xmit_lock? It seems quite straightforward to do. For this
> change to work, netpoll also needs to be fixed up a bit to check for
> LLTX before getting the xmit_lock.

Oh yes, netpoll needs changes, thanks for noticing that.

That's why I had the idea to make xmit_lock a pointer, so
that things like that netpoll case could be transparent.

I think this netpoll wrinkle means we also have to make
sure to set the xmit_lock_owner across the board.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 19 comments |
headers
Herbert Xu | 1 Jun 2006 02:25
Picon
Picon

Re: netif_tx_disable and lockless TX

On Wed, May 31, 2006 at 05:09:08PM -0700, David Miller wrote:
> From: "Michael Chan" <mchan <at> broadcom.com>
> Date: Wed, 31 May 2006 14:20:29 -0700
> 
> > David, So do we want to fix this issue as proposed by Herbert to replace
> > tx_lock with xmit_lock? It seems quite straightforward to do. For this
> > change to work, netpoll also needs to be fixed up a bit to check for
> > LLTX before getting the xmit_lock.
> 
> Oh yes, netpoll needs changes, thanks for noticing that.

Why does it need to change? The idea is to take the LLTX flag off tg3
after the conversion to xmit_lock.

> I think this netpoll wrinkle means we also have to make
> sure to set the xmit_lock_owner across the board.

You're right.  In fact this can deadlock today for those drivers that
already make use of xmit_lock without setting the owner.  So I suppose
something like net_xmit_lock to obtain xmit_lock is called for.

Cheers,
--

-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 18 comments |
headers
Michael Chan | 1 Jun 2006 01:01
Favicon

Re: netif_tx_disable and lockless TX

On Thu, 2006-06-01 at 10:25 +1000, Herbert Xu wrote:
> On Wed, May 31, 2006 at 05:09:08PM -0700, David Miller wrote:
> > From: "Michael Chan" <mchan <at> broadcom.com>
> > Date: Wed, 31 May 2006 14:20:29 -0700
> > 
> > > David, So do we want to fix this issue as proposed by Herbert to replace
> > > tx_lock with xmit_lock? It seems quite straightforward to do. For this
> > > change to work, netpoll also needs to be fixed up a bit to check for
> > > LLTX before getting the xmit_lock.
> > 
> > Oh yes, netpoll needs changes, thanks for noticing that.
> 
> Why does it need to change? The idea is to take the LLTX flag off tg3
> after the conversion to xmit_lock.

Oh, I thought your idea was to keep the LLTX and just replace tx_lock
with xmit_lock in tg3. But I suppose we can also clear LLTX, remove the
tx_lock in hard_start_xmit and convert the rest to avoid changing
netpoll.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 3 comments |
headers
Herbert Xu | 1 Jun 2006 02:42
Picon
Picon

Re: netif_tx_disable and lockless TX

On Wed, May 31, 2006 at 04:01:06PM -0700, Michael Chan wrote:
> 
> Oh, I thought your idea was to keep the LLTX and just replace tx_lock
> with xmit_lock in tg3. But I suppose we can also clear LLTX, remove the
> tx_lock in hard_start_xmit and convert the rest to avoid changing
> netpoll.

That's what I meant.  This has the advantage that things like AF_PACKET
won't see duplicate packets.

Cheers,
--

-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Michael Chan | 1 Jun 2006 02:27
Favicon

Re: netif_tx_disable and lockless TX

On Thu, 2006-06-01 at 10:42 +1000, Herbert Xu wrote:
> On Wed, May 31, 2006 at 04:01:06PM -0700, Michael Chan wrote:
> > 
> > Oh, I thought your idea was to keep the LLTX and just replace tx_lock
> > with xmit_lock in tg3. But I suppose we can also clear LLTX, remove the
> > tx_lock in hard_start_xmit and convert the rest to avoid changing
> > netpoll.
> 
> That's what I meant.  This has the advantage that things like AF_PACKET
> won't see duplicate packets.

Now that I think about it some more, we can eliminate most of the
tx_lock in tg3 without converting to xmit_lock. In most places, we get
the tx_lock after we call netif_tx_disable(), etc, and quiesce the chip.
So the tx_lock or xmit_lock is really not necessary in most places. The
tp->lock is sufficient after we stop everything.

The only few remaining places where we need it is around
netif_stop_queue/netif_wake_queue in hard_start_xmit and tx completion.
We can either keep the tx_lock or convert to xmit_lock and either way
makes little difference because these are not in the normal fast path.
If we keep the tx_lock, it will be just like BNX2.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Herbert Xu | 1 Jun 2006 04:27
Picon
Picon

Re: netif_tx_disable and lockless TX

On Wed, May 31, 2006 at 05:27:53PM -0700, Michael Chan wrote:
> 
> Now that I think about it some more, we can eliminate most of the
> tx_lock in tg3 without converting to xmit_lock. In most places, we get
> the tx_lock after we call netif_tx_disable(), etc, and quiesce the chip.
> So the tx_lock or xmit_lock is really not necessary in most places. The
> tp->lock is sufficient after we stop everything.

Sounds good.

> The only few remaining places where we need it is around
> netif_stop_queue/netif_wake_queue in hard_start_xmit and tx completion.
> We can either keep the tx_lock or convert to xmit_lock and either way
> makes little difference because these are not in the normal fast path.
> If we keep the tx_lock, it will be just like BNX2.

Now that I look at it the BNX2 method looks perfect.

Cheers,
--

-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Herbert Xu | 1 Jun 2006 04:56
Picon
Picon

Re: TCP connection hang problem with 2.6.16.16, e1000.

On Wed, May 31, 2006 at 04:45:36PM +0000, Ben Greear wrote:
>
> May 31 08:07:00 xeon-dt kernel: irqbalance: page allocation failure. order:1, mode:0x20
> May 31 08:07:00 xeon-dt kernel:  [<78147393>] __alloc_pages+0x1d8/0x2b8
> May 31 08:07:00 xeon-dt kernel:  [<7815c525>] kmem_getpages+0x2f/0x8c
> May 31 08:07:00 xeon-dt kernel:  [<7815d297>] cache_grow+0xb1/0x14e
> May 31 08:07:00 xeon-dt kernel:  [<7815d48e>] cache_alloc_refill+0x15a/0x206
> May 31 08:07:00 xeon-dt kernel:  [<7815d7c5>] __kmalloc+0x68/0x80
> May 31 08:07:00 xeon-dt kernel:  [<782b3ba2>] __alloc_skb+0x4c/0xf6
> May 31 08:07:00 xeon-dt kernel:  [<782e63af>] tcp_collapse+0xe9/0x34e

We specifically calculate the packet size here to avoid a 2-page
allocation, yet we still do.  This is the bug.

[NET]: Fix SKB_MAX_ORDER calculation

The calculation in SKB_MAX_ORDER is incorrect in that it can cause
an overflow across a page boundary which is what it's meant to prevent.
In particular, the header length (X) should not be lumped together with
skb_shared_info.  The latter needs to be aligned properly while the header
has no choice but to sit in front of wherever the payload is.

Therefore the correct calculation is to take away the aligned size of
skb_shared_info, and then subtract the header length.  The resulting
quantity L satisfies the following inequality:

	SKB_DATA_ALIGN(L + X) + sizeof(struct skb_shared_info) <= PAGE_SIZE

This is the quantity used by alloc_skb to do the actual allocation.
(Continue reading)

Permalink | Reply | 0 comments |
headers
varun | 1 Jun 2006 08:03

netfilter reg problem

Hi all,

            I have a setup where iam using iptables. I have squid 
running on my statem. Now the scenario is that this sytem is my router. 
I have eth0 connected to LAN, eth1 to Wan 1 and eth2 to Wan2. In the 
same box i also have a propratery FW which has Load Balancing feature.  
Now my intention is i start iptables first so that it registers with 
netfilter hook first.
So policy is like this
      iptables -t nat -D PREROUTING -i eth0 -p tcp -j REDIRECT --to-port 
8080
 In the port 8080 i have squid running.
 As far as filtering of iptables is concerned it is allow all.

     So my basic FW functionality is concerned it is taken care by My 
Propratery FW. It will do  the natting for both wan interfaces in Load 
balance.

  Now what i expect is that iptables will get all the packets first and 
then packet will go to my firewall and might get dropped if ACL matches 
else it is success. Once success i expect the packet to be redirected to 
port 8080 where squid can take control.

 Now my problem is that even though iptables is registered first when i 
log the packets using iptables for the above rule i find that no packets 
are comming to iptables there by no packets are going to proxy. I get 
only some multicast packets.

 From lan iam able to browse well and all my traffic is going tru my FW 
rather that first through iptables. Why?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane