* Re: handing cloned frames to netif_rx()?
From: Herbert Xu @ 2008-01-11 23:01 UTC (permalink / raw)
To: Johannes Berg
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
ron.rindjunsky-ral2JQCrhuEAvxtiuMwx3w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1200092285.3528.5.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
On Fri, Jan 11, 2008 at 11:58:05PM +0100, Johannes Berg wrote:
>
> Ok. Yes, we will of course adhere to that, but I was wondering whether
> maybe the net stack assumes somewhere that a packet it got from the
> driver can be written to w/o copying.
All parts of the rx stack support clone handling because they can always
run after another handler (e.g., AF_PACKET) which may have cloned the
packet.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: handing cloned frames to netif_rx()?
From: Johannes Berg @ 2008-01-11 23:04 UTC (permalink / raw)
To: Herbert Xu
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
ron.rindjunsky-ral2JQCrhuEAvxtiuMwx3w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20080111230105.GA32656-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
On Sat, 2008-01-12 at 10:01 +1100, Herbert Xu wrote:
> On Fri, Jan 11, 2008 at 11:58:05PM +0100, Johannes Berg wrote:
> >
> > Ok. Yes, we will of course adhere to that, but I was wondering whether
> > maybe the net stack assumes somewhere that a packet it got from the
> > driver can be written to w/o copying.
>
> All parts of the rx stack support clone handling because they can always
> run after another handler (e.g., AF_PACKET) which may have cloned the
> packet.
Great, thanks for confirming, we'll do that then.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
From: Rafael J. Wysocki @ 2008-01-11 23:10 UTC (permalink / raw)
To: supersud501
Cc: Stephen Hemminger, Andrew Morton, netdev, linux-acpi,
bugme-daemon
In-Reply-To: <4787EB69.9060900@yahoo.de>
On Friday, 11 of January 2008, supersud501 wrote:
>
> Rafael J. Wysocki wrote:
> >> http://bugzilla.kernel.org/show_bug.cgi?id=9721
> allright, didn't see that before, sorry, here are the results:
>
> kernel 2.6.23.12 acpi=off: when shutting down the system doesn't
> poweroff (of course), but pressing the powerbutton does the trick. and
> wake on lan: WORKS
>
> kernel 2.6.24-rc7 acpi=off: computer doesn't power off, either (so
> acpi=off works), but wol still DOESN'T work :(
>
> so no acpi-problem?
No, I don't think it's an ACPI problem.
Since it seems to be 100% reproducible, it would be very helpful if you could
use git-bisect to identify the offending commit.
^ permalink raw reply
* Re: e1000 performance issue in 4 simultaneous links
From: David Miller @ 2008-01-12 1:41 UTC (permalink / raw)
To: benny+usenet; +Cc: netdev
In-Reply-To: <m3ir20ipoz.fsf@ursa.amorsen.dk>
From: Benny Amorsen <benny+usenet@amorsen.dk>
Date: Fri, 11 Jan 2008 12:09:32 +0100
> David Miller <davem@davemloft.net> writes:
>
> > No IRQ balancing should be done at all for networking device
> > interrupts, with zero exceptions. It destroys performance.
>
> Does irqbalanced need to be taught about this?
The userland one already does.
It's only the in-kernel IRQ load balancing for these (presumably
powerpc) platforms that is broken.
^ permalink raw reply
* Re: [PATCH 001/001] ipv4: enable use of 240/4 address space
From: David Miller @ 2008-01-12 1:48 UTC (permalink / raw)
To: yoshfuji; +Cc: andi, vaf, netdev, linux-kernel
In-Reply-To: <20080111.214120.129309556.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST)
> There is no positive consesus on this draft
> at the intarea meeting in Vancouver, right?
>
> We cannot / should not enable that space until we have reached
> a consensus on it.
This is so incredibly incorrect.
There is consensus on making network stacks able to use this
address space. And that is all that the patch does.
The consensus is only missing on whether to make the address
space public or private.
This is also clearly spelled out in the draft.
It is important to get as large of a head start on this as
possible because of how long it takes to deploy something
like this.
^ permalink raw reply
* Re: [PATCH 001/001] ipv4: enable use of 240/4 address space
From: David Miller @ 2008-01-12 1:49 UTC (permalink / raw)
To: vaf; +Cc: andi, netdev, linux-kernel
In-Reply-To: <20080111172915.GA6199@cisco.com>
From: Vince Fuller <vaf@cisco.com>
Date: Fri, 11 Jan 2008 09:29:15 -0800
> I leave it up to you, the developers, to decide if you want to use these
> patches.
Vince, please just ignore these turkeys who are dismissing
your patch and respin it against current sources as I asked
of you.
I'll apply it, immediately, because it is the only correct
course of action.
Thanks a lot.
^ permalink raw reply
* Re: questions on NAPI processing latency and dropped network packets
From: David Miller @ 2008-01-12 1:53 UTC (permalink / raw)
To: cfriesen; +Cc: netdev, linux-kernel
In-Reply-To: <4787844E.4020107@nortel.com>
From: "Chris Friesen" <cfriesen@nortel.com>
Date: Fri, 11 Jan 2008 08:59:26 -0600
> I'd love to work on newer kernels, but we have a commitment to our
> customers to support multiple releases for a significant amount of time.
And by asking here for people to dig into it for you, you are asking
people for free help providing that support.
That's why there is such negative backlash to asking questions about
such ancient kernel here, you're asking us to do your work, for free.
^ permalink raw reply
* Re: iproute2: removing primary address removes secondaries
From: David Miller @ 2008-01-12 1:59 UTC (permalink / raw)
To: madduck; +Cc: netdev
In-Reply-To: <20080111163155.GA17637@piper.oerlikon.madduck.net>
echo "1" >/proc/sys/net/ipv4/conf/all/promote_secondaries
^ permalink raw reply
* Re: [PATCH 2.6.23+] ingress classify to [nf]mark
From: jamal @ 2008-01-12 3:03 UTC (permalink / raw)
To: mahatma; +Cc: netdev
In-Reply-To: <4787D49E.6080906@bspu.unibel.by>
On Fri, 2008-11-01 at 18:42 -0200, Dzianis Kahanovich wrote:
> About script example:
> While I compose filter, I check flag ($TC_INDEX2MARK), tells me are patch
> applied or no. If no - I use usual "-j MARK --set-mark", else I use classid to
> change mark. All in ingress only. For example:
> tc filter add dev eth0 parent ffff: protocol ip u32 ... action ipt -j MARK 0x10
> are cname to:
> tc filter add dev eth0 parent ffff: protocol ip u32 ... flowid :10
I thought you were doing something like this (to achieve your policy):
----------
major=1
minor=12
mark=`expr $major + $minor`
#
tc qdisc add dev XXX ingress
tc filter add dev XXX parent ffff: protocol ip prio 5 \
u32 blah bleh \
flowid $major:$minor action \
ipt -j mark --set-mark $mark
---------------
> - it use less code/modules and, in many cases, may be single/main goal to
> ingress usage - pre-marking packets.
That is true and you would also have one less line in your policy; as an
example in above the line "ipt -j mark --set-mark $mark" would be
unnecessary; however, all the other lines in the policy setting _will be
necessary_. And this + the fact there are many other values/shapes the
default policy could take is essentially whats bothering me.
In any case, scanning the current code it seems mark is no longer
considered a netfilter-only metadatum - so it may not be semantically as
obscene as i felt earlier; Can you pick something simpler for policy?
example set the mark to whatever tc_index gets set?
If you still could write the metadata action, we could use it to
override mark, tc_index etc in addition.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 001/001] ipv4: enable use of 240/4 address space
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2008-01-12 5:12 UTC (permalink / raw)
To: davem; +Cc: andi, vaf, netdev, linux-kernel, yoshfuji
In-Reply-To: <20080111.174857.258424243.davem@davemloft.net>
In article <20080111.174857.258424243.davem@davemloft.net> (at Fri, 11 Jan 2008 17:48:57 -0800 (PST)), David Miller <davem@davemloft.net> says:
> From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
> Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST)
>
> > There is no positive consesus on this draft
> > at the intarea meeting in Vancouver, right?
> >
> > We cannot / should not enable that space until we have reached
> > a consensus on it.
>
> This is so incredibly incorrect.
>
> There is consensus on making network stacks able to use this
> address space. And that is all that the patch does.
No, we did never make consensus on it.
> The consensus is only missing on whether to make the address
> space public or private.
>
> This is also clearly spelled out in the draft.
>
> It is important to get as large of a head start on this as
> possible because of how long it takes to deploy something
> like this.
Okay, though I am afraid this space will not be used widely,
we should be ready for it.
I'll make some more comments on the patch itself from
another point view.
--yoshfuji
^ permalink raw reply
* Re: e1000 performance issue in 4 simultaneous links
From: Denys Fedoryshchenko @ 2008-01-12 5:13 UTC (permalink / raw)
To: David Miller, benny+usenet; +Cc: netdev
In-Reply-To: <20080111.174109.57502326.davem@davemloft.net>
Sorry. that i interfere in this subject.
Do you recommend CONFIG_IRQBALANCE to be enabled?
If it is enabled - irq's not jumping nonstop over processors. softirqd
changing this behavior.
If it is disabled, irq's distributed over each processor, and in loaded
systems it seems harmful.
I work a little yesterday with server with CONFIG_IRQBALANCE=no, 160kpps load.
It was packetloss-ing, till i set smp_affinity.
Maybe it is useful to put more info in Kconfig, since it is very important
for performance option.
On Fri, 11 Jan 2008 17:41:09 -0800 (PST), David Miller wrote
> From: Benny Amorsen <benny usenet@amorsen.dk>
> Date: Fri, 11 Jan 2008 12:09:32 0100
>
> > David Miller <davem@davemloft.net> writes:
> >
> > > No IRQ balancing should be done at all for networking device
> > > interrupts, with zero exceptions. It destroys performance.
> >
> > Does irqbalanced need to be taught about this?
>
> The userland one already does.
>
> It's only the in-kernel IRQ load balancing for these (presumably
> powerpc) platforms that is broken.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* Re: questions on NAPI processing latency and dropped network packets
From: Ray Lee @ 2008-01-12 5:37 UTC (permalink / raw)
To: Chris Friesen; +Cc: netdev, linux-kernel
In-Reply-To: <478654C3.60806@nortel.com>
On Jan 10, 2008 9:24 AM, Chris Friesen <cfriesen@nortel.com> wrote:
> After a recent userspace app change, we've started seeing packets being
> dropped by the ethernet hardware (e1000, NAPI is enabled). The
> error/dropped/fifo counts are going up in ethtool:
(These are perhaps too obvious, but I didn't see the questions or
answers in the thread.)
Can you reproduce it with a simple userspace cpu hog? (Two, really,
one per cpu.)
Can you reproduce it with the newer e1000?
Can you reproduce it with git head?
If the answer to the first one is yes, the last no, then bisect until
you get a kernel that doesn't show the problem. Backport the fix,
unless the fix happens to be CFS. However, I suspect that your
userpace app is just starving the system from time to time.
^ permalink raw reply
* Re: [PATCH 001/001] ipv4: enable use of 240/4 address space
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2008-01-12 5:47 UTC (permalink / raw)
To: vaf; +Cc: netdev, linux-kernel, yoshfuji, davem
In-Reply-To: <20080108011057.GA21168@cisco.com>
Hello.
In article <20080108011057.GA21168@cisco.com> (at Mon, 7 Jan 2008 17:10:57 -0800), Vince Fuller <vaf@cisco.com> says:
> #define IN_MULTICAST_NET 0xF0000000
>
> +#define IN_CLASSE(a) ((((long int) (a)) & 0xf0000000) == 0xf0000000)
> +#define IN_CLASSE_NET 0xffffff00
> +#define IN_CLASSE_NSHIFT 8
> +#define IN_CLASSE_HOST (0xffffffff & ~IN_CLASSE_NET)
> +
> +/*
> + * these are no longer used
> #define IN_EXPERIMENTAL(a) ((((long int) (a)) & 0xf0000000) == 0xf0000000)
> #define IN_BADCLASS(a) IN_EXPERIMENTAL((a))
> +*/
Please do not remove this, but have these instead:
#define IN_EXPERIMENTAL(a) IN_CLASSE((a))
#define IN_BADCASS(a) IN_CLASSE((a))
And, I think it is good to remove BADCLASS() (inside
#ifdef __KERNEL__ .. #endif) because we do not have its users
any longer, right?
Regards,
--yoshfuji
^ permalink raw reply
* Netconf at conf.au 2008?
From: Andy Johnson @ 2008-01-12 6:52 UTC (permalink / raw)
To: netdev
Hello,
I saw somewhere (maybe in this mailing list a while ago) that there
might be a Linux Kernel Developers' Netconf conference at conf.au
2008.
Does anyone here know if such a thing is planned ?
Regards,
Andy
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
From: Stefan Roese @ 2008-01-12 7:26 UTC (permalink / raw)
To: benh; +Cc: Eugene Surovegin, netdev, linuxppc-dev
In-Reply-To: <1200089457.6896.65.camel@pasglop>
On Friday 11 January 2008, Benjamin Herrenschmidt wrote:
> On Fri, 2008-01-11 at 09:48 -0800, Eugene Surovegin wrote:
> > On Sat, Jan 05, 2008 at 01:38:17PM +0100, Stefan Roese wrote:
> > > On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
> > > > On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote:
> > > > > Performance tests done by AMCC have shown that 256 buffer increase
> > > > > the performance of the Linux EMAC driver. So let's update the
> > > > > default values to match this setup.
> > > > >
> > > > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > > > ---
> > > >
> > > > Do we have the numbers ? Did they also measure latency ?
> > >
> > > I hoped this question would not come. ;) No, unfortunately I don't have
> > > any numbers. Just the recommendation from AMCC to always use 256
> > > buffers.
> >
> > This cannot be true for all chips. Default numbers I selected weren't
> > random. In particular, 256 for Tx doesn't make a lot of sense for 405.
> > You just gonna waste memory.
This may be the case with the "old" 405 PPC's. But with the new ones coming
out right now, like the up to 666MHz 405EX with GBit support, 256 could be an
improvement. I still owe you figures though. Will try to do some testing in a
short while.
> > I'd be quite reluctant to follow such advices from AMCC without actual
> > details.
>
> I think we can make defaults based on other config options nowadays. Not
> very nice but we could do things like
>
> default 128 if PPC_40x
> default 256
>
> Or even more detailed.
We shouldn't make it too complicated. We can always select different settings
in the defconfig file. My thinking here is to better wast a little memory
with a potential performance improvement. Just me 0.02$
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
From: Benjamin Herrenschmidt @ 2008-01-12 7:57 UTC (permalink / raw)
To: Stefan Roese; +Cc: Eugene Surovegin, netdev, linuxppc-dev
In-Reply-To: <200801120826.53091.sr@denx.de>
On Sat, 2008-01-12 at 08:26 +0100, Stefan Roese wrote:
>
> We shouldn't make it too complicated. We can always select different
> settings
> in the defconfig file. My thinking here is to better wast a little
> memory
> with a potential performance improvement. Just me 0.02$
If it gets really critical, then we can move those settings to the
device-tree.
Ben.
^ permalink raw reply
* Re: e1000_clean_tx_irq: Detected Tx Unit Hang - it's bug?
From: slavon @ 2008-01-12 8:15 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev
In-Reply-To: <477E92E3.1000202@intel.com>
>> Hello all.
>> Some time in dmesg i see this:
>>
>> [16121.400422] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
>> [16121.400426] Tx Queue <0>
>> [16121.400427] TDH <28>
>> [16121.400429] TDT <28>
>> [16121.400430] next_to_use <28>
>> [16121.400431] next_to_clean <7d>
>> [16121.400433] buffer_info[next_to_clean]
>> [16121.400434] time_stamp <17b949>
>> [16121.400435] next_to_watch <7d>
>> [16121.400437] jiffies <17ba57>
>> [16121.400438] next_to_watch.status <1>
>
> might be a bug. What kernel version are you using?
Hello.
Now i try 2.6.24-rc7-git2 - its have NAPI patches that work GREAT!
Have many messages like up in dmeseg.
Also more info for You
fw ~ # ethtool -S eth0
NIC statistics:
rx_packets: 1048831452
tx_packets: 28418
rx_bytes: 644208597062
tx_bytes: 3458632
rx_broadcast: 1840
tx_broadcast: 5
rx_multicast: 0
tx_multicast: 0
rx_errors: 1663
tx_errors: 0
tx_dropped: 0
multicast: 0
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 5172
rx_frame_errors: 0
rx_no_buffer_count: 153305
rx_missed_errors: 883176
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 0
tx_single_coll_ok: 0
tx_multi_coll_ok: 0
tx_timeout_count: 0
tx_restart_queue: 0
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 10
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_long_byte_count: 644208597062
rx_csum_offload_good: 1030747822
rx_csum_offload_errors: 7086
rx_header_split: 0
alloc_rx_buff_failed: 0
tx_smbus: 0
rx_smbus: 0
dropped_smbus: 0
That my dmesg:
[ 5280.282257] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[ 5280.282264] Tx Queue <0>
[ 5280.282265] TDH <67>
[ 5280.282265] TDT <a9>
[ 5280.282266] next_to_use <a9>
[ 5280.282267] next_to_clean <fe>
[ 5280.282268] buffer_info[next_to_clean]
[ 5280.282269] time_stamp <76c86>
[ 5280.282270] next_to_watch <fe>
[ 5280.282271] jiffies <76d33>
[ 5280.282272] next_to_watch.status <1>
[ 272.396662] opreport[5752]: segfault at b7be1010 eip 080b396e esp
bfba9480 error 4
[ 2264.085353] htb: too many events !
[ 3376.658037] htb: too many events !
[ 5724.766531] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[ 5724.766533] Tx Queue <0>
[ 5724.766534] TDH <23>
[ 5724.766535] TDT <23>
[ 5724.766536] next_to_use <23>
[ 5724.766537] next_to_clean <fd>
[ 5724.766537] buffer_info[next_to_clean]
[ 5724.766538] time_stamp <50db81>
[ 5724.766539] next_to_watch <fd>
[ 5724.766540] jiffies <50e3ab>
[ 5724.766541] next_to_watch.status <1>
[ 5724.767771] htb: too many events !
[10527.197125] htb: too many events !
[11744.405451] htb: too many events !
[12925.662880] htb: too many events !
[14123.186443] htb: too many events !
[15333.652189] htb: too many events !
[16522.524045] htb: too many events !
[17722.572386] htb: too many events !
[18925.121034] htb: too many events !
[20117.689133] htb: too many events !
[20117.690436] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[20117.690438] Tx Queue <0>
[20117.690439] TDH <8>
[20117.690440] TDT <4b>
[20117.690441] next_to_use <4b>
[20117.690442] next_to_clean <a0>
[20117.690443] buffer_info[next_to_clean]
[20117.690443] time_stamp <128b414>
[20117.690444] next_to_watch <a0>
[20117.690445] jiffies <128bc3f>
[20117.690446] next_to_watch.status <1>
[21314.498859] htb: too many events !
[22192.855455] htb: too many events !
[22520.640345] htb: too many events !
[23712.083687] htb: too many events !
[24912.407418] htb: too many events !
[26128.954774] htb: too many events !
[27314.726708] htb: too many events !
[28517.307859] htb: too many events !
[28517.309179] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[28517.309181] Tx Queue <0>
[28517.309182] TDH <1a>
[28517.309183] TDT <4f>
[28517.309184] next_to_use <4f>
[28517.309185] next_to_clean <a4>
[28517.309186] buffer_info[next_to_clean]
[28517.309187] time_stamp <1a5c7c3>
[28517.309187] next_to_watch <a4>
[28517.309188] jiffies <1a5cf20>
[28517.309189] next_to_watch.status <1>
[30922.659736] htb: too many events !
[30922.661064] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[30922.661066] Tx Queue <0>
[30922.661067] TDH <51>
[30922.661068] TDT <76>
[30922.661069] next_to_use <76>
[30922.661070] next_to_clean <cb>
[30922.661071] buffer_info[next_to_clean]
[30922.661071] time_stamp <1c9ad65>
[30922.661072] next_to_watch <cb>
[30922.661073] jiffies <1c9b459>
[30922.661074] next_to_watch.status <1>
[32124.687849] htb: too many events !
[33345.636940] htb: too many events !
[34528.356531] htb: too many events !
[34528.358024] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[34528.358027] Tx Queue <0>
[34528.358028] TDH <fa>
[34528.358029] TDT <3>
[34528.358029] next_to_use <3>
[34528.358030] next_to_clean <58>
[34528.358031] buffer_info[next_to_clean]
[34528.358032] time_stamp <1ff85ab>
[34528.358033] next_to_watch <58>
[34528.358034] jiffies <1ff8d27>
[34528.358035] next_to_watch.status <1>
[35734.669698] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[35734.669700] Tx Queue <0>
[35734.669701] TDH <5f>
[35734.669702] TDT <5f>
[35734.669703] next_to_use <5f>
[35734.669704] next_to_clean <bf>
[35734.669705] buffer_info[next_to_clean]
[35734.669705] time_stamp <211994b>
[35734.669706] next_to_watch <bf>
[35734.669707] jiffies <211a017>
[35734.669708] next_to_watch.status <1>
[35734.672161] htb: too many events !
[36955.160096] htb: too many events !
[38118.346906] htb: too many events !
[39330.213684] htb: too many events !
[39330.214762] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[39330.214764] Tx Queue <0>
[39330.214765] TDH <eb>
[39330.214766] TDT <45>
[39330.214767] next_to_use <45>
[39330.214767] next_to_clean <9a>
[39330.214768] buffer_info[next_to_clean]
[39330.214769] time_stamp <2477328>
[39330.214770] next_to_watch <9a>
[39330.214771] jiffies <2477b16>
[39330.214772] next_to_watch.status <1>
[40551.898491] htb: too many events !
[40551.899264] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[40551.899266] Tx Queue <0>
[40551.899267] TDH <bf>
[40551.899268] TDT <ca>
[40551.899269] next_to_use <ca>
[40551.899269] next_to_clean <1f>
[40551.899270] buffer_info[next_to_clean]
[40551.899271] time_stamp <259c212>
[40551.899272] next_to_watch <1f>
[40551.899273] jiffies <259c91e>
[40551.899274] next_to_watch.status <1>
[41724.774002] htb: too many events !
[42920.657519] htb: too many events !
[44143.420904] htb: too many events !
[45303.157047] htb: too many events !
[46492.258329] htb: too many events !
[47694.779740] htb: too many events !
[58471.571956] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[58471.571959] Tx Queue <0>
[58471.571960] TDH <7b>
[58471.571960] TDT <7b>
[58471.571961] next_to_use <7b>
[58471.571962] next_to_clean <d0>
[58471.571963] buffer_info[next_to_clean]
[58471.571964] time_stamp <36516dd>
[58471.571965] next_to_watch <d0>
[58471.571966] jiffies <36531cc>
[58471.571967] next_to_watch.status <1>
[59669.526000] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[59669.526002] Tx Queue <0>
[59669.526003] TDH <6>
[59669.526004] TDT <1e>
[59669.526005] next_to_use <1e>
[59669.526006] next_to_clean <73>
[59669.526007] buffer_info[next_to_clean]
[59669.526008] time_stamp <37718da>
[59669.526009] next_to_watch <73>
[59669.526009] jiffies <3773434>
[59669.526010] next_to_watch.status <1>
[60865.254499] NETDEV WATCHDOG: eth0: transmit timed out
[60865.254584] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[60865.254585] Tx Queue <0>
[60865.254586] TDH <ed>
[60865.254587] TDT <ed>
[60865.254588] next_to_use <ed>
[60865.254589] next_to_clean <4c>
[60865.254590] buffer_info[next_to_clean]
[60865.254590] time_stamp <38919bb>
[60865.254591] next_to_watch <4c>
[60865.254592] jiffies <38934a2>
[60865.254593] next_to_watch.status <1>
[62064.876121] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[62064.876123] Tx Queue <0>
[62064.876124] TDH <6a>
[62064.876125] TDT <71>
[62064.876126] next_to_use <71>
[62064.876126] next_to_clean <c6>
[62064.876127] buffer_info[next_to_clean]
[62064.876128] time_stamp <39b221d>
[62064.876129] next_to_watch <c6>
[62064.876130] jiffies <39b3d07>
[62064.876131] next_to_watch.status <1>
[63261.288625] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[63261.288628] Tx Queue <0>
[63261.288629] TDH <b9>
[63261.288630] TDT <b9>
[63261.288631] next_to_use <b9>
[63261.288631] next_to_clean <e>
[63261.288632] buffer_info[next_to_clean]
[63261.288633] time_stamp <3ad1b46>
[63261.288634] next_to_watch <e>
[63261.288635] jiffies <3ad3b43>
[63261.288636] next_to_watch.status <1>
[64459.486793] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[64459.486796] Tx Queue <0>
[64459.486797] TDH <19>
[64459.486798] TDT <19>
[64459.486798] next_to_use <19>
[64459.486799] next_to_clean <ae>
[64459.486800] buffer_info[next_to_clean]
[64459.486801] time_stamp <3bf25e5>
[64459.486802] next_to_watch <ae>
[64459.486803] jiffies <3bf422f>
[64459.486804] next_to_watch.status <1>
[65663.246067] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[65663.246069] Tx Queue <0>
[65663.246070] TDH <c3>
[65663.246071] TDT <17>
[65663.246072] next_to_use <17>
[65663.246073] next_to_clean <6c>
[65663.246074] buffer_info[next_to_clean]
[65663.246075] time_stamp <3d141e5>
[65663.246076] next_to_watch <6c>
[65663.246077] jiffies <3d15cca>
[65663.246077] next_to_watch.status <1>
[66855.416474] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[66855.416477] Tx Queue <0>
[66855.416478] TDH <e5>
[66855.416479] TDT <e5>
[66855.416480] next_to_use <e5>
[66855.416480] next_to_clean <96>
[66855.416481] buffer_info[next_to_clean]
[66855.416482] time_stamp <3e333f4>
[66855.416483] next_to_watch <96>
[66855.416484] jiffies <3e35090>
[66855.416485] next_to_watch.status <1>
[68054.040533] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[68054.040536] Tx Queue <0>
[68054.040537] TDH <b2>
[68054.040538] TDT <2>
[68054.040538] next_to_use <2>
[68054.040539] next_to_clean <57>
[68054.040540] buffer_info[next_to_clean]
[68054.040541] time_stamp <3f546cd>
[68054.040542] next_to_watch <57>
[68054.040542] jiffies <3f560f6>
[68054.040543] next_to_watch.status <1>
[69260.670653] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[69260.670656] Tx Queue <0>
[69260.670657] TDH <83>
[69260.670657] TDT <e9>
[69260.670658] next_to_use <e9>
[69260.670659] next_to_clean <3e>
[69260.670660] buffer_info[next_to_clean]
[69260.670661] time_stamp <4077a70>
[69260.670662] next_to_watch <3e>
[69260.670663] jiffies <40795d1>
[69260.670663] next_to_watch.status <1>
[70450.618127] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[70450.618130] Tx Queue <0>
[70450.618131] TDH <e5>
[70450.618131] TDT <35>
[70450.618132] next_to_use <35>
[70450.618133] next_to_clean <8a>
[70450.618134] buffer_info[next_to_clean]
[70450.618135] time_stamp <4196ed3>
[70450.618136] next_to_watch <8a>
[70450.618137] jiffies <41987ab>
[70450.618137] next_to_watch.status <1>
[71648.909256] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[71648.909258] Tx Queue <0>
[71648.909259] TDH <41>
[71648.909260] TDT <42>
[71648.909261] next_to_use <42>
[71648.909262] next_to_clean <97>
[71648.909262] buffer_info[next_to_clean]
[71648.909263] time_stamp <42b8542>
[71648.909264] next_to_watch <97>
[71648.909265] jiffies <42b9fa1>
[71648.909266] next_to_watch.status <1>
[72851.697294] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[72851.697297] Tx Queue <0>
[72851.697298] TDH <30>
[72851.697298] TDT <54>
[72851.697299] next_to_use <54>
[72851.697300] next_to_clean <a9>
[72851.697301] buffer_info[next_to_clean]
[72851.697302] time_stamp <43dadd4>
[72851.697303] next_to_watch <a9>
[72851.697304] jiffies <43dc870>
[72851.697305] next_to_watch.status <1>
[75245.677954] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[75245.677957] Tx Queue <0>
[75245.677958] TDH <85>
[75245.677958] TDT <b5>
[75245.677959] next_to_use <b5>
[75245.677960] next_to_clean <a>
[75245.677961] buffer_info[next_to_clean]
[75245.677962] time_stamp <461dd97>
[75245.677963] next_to_watch <a>
[75245.677964] jiffies <461f952>
[75245.677965] next_to_watch.status <1>
[76448.839007] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[76448.839009] Tx Queue <0>
[76448.839011] TDH <18>
[76448.839012] TDT <68>
[76448.839012] next_to_use <68>
[76448.839013] next_to_clean <bd>
[76448.839014] buffer_info[next_to_clean]
[76448.839015] time_stamp <4740b7f>
[76448.839016] next_to_watch <bd>
[76448.839017] jiffies <4742788>
[76448.839018] next_to_watch.status <1>
[77641.472192] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[77641.472195] Tx Queue <0>
[77641.472197] TDH <f>
[77641.472198] TDT <6a>
[77641.472198] next_to_use <6a>
[77641.472199] next_to_clean <d7>
[77641.472200] buffer_info[next_to_clean]
[77641.472201] time_stamp <48612f3>
[77641.472202] next_to_watch <d7>
[77641.472203] jiffies <4862c1f>
[77641.472204] next_to_watch.status <1>
[78841.540399] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[78841.540401] Tx Queue <0>
[78841.540402] TDH <49>
[78841.540403] TDT <49>
[78841.540404] next_to_use <49>
[78841.540405] next_to_clean <40>
[78841.540406] buffer_info[next_to_clean]
[78841.540406] time_stamp <49832d4>
[78841.540407] next_to_watch <40>
[78841.540408] jiffies <4984da3>
[78841.540409] next_to_watch.status <1>
[80047.286824] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[80047.286827] Tx Queue <0>
[80047.286828] TDH <fc>
[80047.286829] TDT <37>
[80047.286830] next_to_use <37>
[80047.286830] next_to_clean <8c>
[80047.286831] buffer_info[next_to_clean]
[80047.286832] time_stamp <4aa66e4>
[80047.286833] next_to_watch <8c>
[80047.286834] jiffies <4aa812b>
[80047.286835] next_to_watch.status <1>
[81240.261877] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[81240.261879] Tx Queue <0>
[81240.261880] TDH <8f>
[81240.261881] TDT <be>
[81240.261882] next_to_use <be>
[81240.261883] next_to_clean <13>
[81240.261884] buffer_info[next_to_clean]
[81240.261884] time_stamp <4bc5b32>
[81240.261885] next_to_watch <13>
[81240.261886] jiffies <4bc73d9>
[81240.261887] next_to_watch.status <1>
[82440.249836] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[82440.249838] Tx Queue <0>
[82440.249839] TDH <9d>
[82440.249840] TDT <9d>
[82440.249841] next_to_use <9d>
[82440.249842] next_to_clean <f2>
[82440.249842] buffer_info[next_to_clean]
[82440.249843] time_stamp <4ce6735>
[82440.249844] next_to_watch <f2>
[82440.249845] jiffies <4ce8149>
[82440.249846] next_to_watch.status <1>
> it appears the tx
> handler was
> just sitting idle and this message might be bogus, which is one of
> the things that
> we fixed recently.
>
> Auke
>
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* What is XFRM_POLICY_LOCALOK for?
From: Ian Brown @ 2008-01-12 8:31 UTC (permalink / raw)
To: netdev
Hello,
I tried to understand what XFRM_POLICY_LOCALOK is for. (include/linux/xfrm.h)
It is defined thus:
#define XFRM_POLICY_LOCALOK 1 /* Allow user to override global policy */
is it part of flags of xfrm_userpolicy_info?? I doubt this, since we have
above flags two defines:
#define XFRM_POLICY_ALLOW 0
#define XFRM_POLICY_BLOCK 1
Moreover, both XFRM_POLICY_BLOCK and XFRM_POLICY_LOCALOK has a vlaue of 1.
I could not see any usage for XFRM_POLICY_LOCALOK in kernel code.
Regards,
Ian B
^ permalink raw reply
* Re: e1000_clean_tx_irq: Detected Tx Unit Hang - it's bug?
From: slavon @ 2008-01-12 8:48 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev
In-Reply-To: <20080112111553.hfrfyghwggcgsk0c@mail.bigtelecom.ru>
Wow! Now at another PC have this messages in dmesg:
[83646.646305] NETDEV WATCHDOG: eth0: transmit timed out
[83646.646391] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[83646.646392] Tx Queue <0>
[83646.646393] TDH <eb>
[83646.646394] TDT <eb>
[83646.646395] next_to_use <eb>
[83646.646396] next_to_clean <41>
[83646.646397] buffer_info[next_to_clean]
[83646.646398] time_stamp <4e0919c>
[83646.646399] next_to_watch <41>
[83646.646400] jiffies <4e0ab8e>
[83646.646400] next_to_watch.status <1>
[83651.683460] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps
Full Duplex, Flow Control: RX
[84849.372924] htb: too many events !
[86047.797913] htb: too many events !
PC not response some time to all packets! After
[83651.683460] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps
Full Duplex, Flow Control: RX
Its work again!
Strange
fw2 ~ # uname -a
Linux fw2 2.6.24-rc7-git2-fw #6 Fri Jan 11 11:07:42 MSK 2008 i686
Intel(R) Pentium(R) 4 CPU 3.40GHz GenuineIntel GNU/Linux
fw2 ~ # lspci
00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM
Controller/Host-Hub Interface (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated
Graphics Controller (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB
UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB
UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB
UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB
UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2
EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC
Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE
Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus
Controller (rev 02)
01:09.0 Ethernet controller: Intel Corporation 82540EM Gigabit
Ethernet Controller (rev 02)
01:0a.0 Ethernet controller: Intel Corporation 82540EM Gigabit
Ethernet Controller (rev 02)
01:0b.0 SCSI storage controller: Adaptec ASC-39320 U320 (rev 03)
01:0b.1 SCSI storage controller: Adaptec ASC-39320 U320 (rev 03)
>>> Hello all.
>>> Some time in dmesg i see this:
>>>
>>> [16121.400422] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
>>> [16121.400426] Tx Queue <0>
>>> [16121.400427] TDH <28>
>>> [16121.400429] TDT <28>
>>> [16121.400430] next_to_use <28>
>>> [16121.400431] next_to_clean <7d>
>>> [16121.400433] buffer_info[next_to_clean]
>>> [16121.400434] time_stamp <17b949>
>>> [16121.400435] next_to_watch <7d>
>>> [16121.400437] jiffies <17ba57>
>>> [16121.400438] next_to_watch.status <1>
>>
>> might be a bug. What kernel version are you using?
>
> Hello.
>
> Now i try 2.6.24-rc7-git2 - its have NAPI patches that work GREAT!
>
> Have many messages like up in dmeseg.
>
> Also more info for You
> fw ~ # ethtool -S eth0
>
> NIC statistics:
> rx_packets: 1048831452
> tx_packets: 28418
> rx_bytes: 644208597062
> tx_bytes: 3458632
> rx_broadcast: 1840
> tx_broadcast: 5
> rx_multicast: 0
> tx_multicast: 0
> rx_errors: 1663
> tx_errors: 0
> tx_dropped: 0
> multicast: 0
> collisions: 0
> rx_length_errors: 0
> rx_over_errors: 0
> rx_crc_errors: 5172
> rx_frame_errors: 0
> rx_no_buffer_count: 153305
> rx_missed_errors: 883176
> tx_aborted_errors: 0
> tx_carrier_errors: 0
> tx_fifo_errors: 0
> tx_heartbeat_errors: 0
> tx_window_errors: 0
> tx_abort_late_coll: 0
> tx_deferred_ok: 0
> tx_single_coll_ok: 0
> tx_multi_coll_ok: 0
> tx_timeout_count: 0
> tx_restart_queue: 0
> rx_long_length_errors: 0
> rx_short_length_errors: 0
> rx_align_errors: 0
> tx_tcp_seg_good: 10
> tx_tcp_seg_failed: 0
> rx_flow_control_xon: 0
> rx_flow_control_xoff: 0
> tx_flow_control_xon: 0
> tx_flow_control_xoff: 0
> rx_long_byte_count: 644208597062
> rx_csum_offload_good: 1030747822
> rx_csum_offload_errors: 7086
> rx_header_split: 0
> alloc_rx_buff_failed: 0
> tx_smbus: 0
> rx_smbus: 0
> dropped_smbus: 0
>
>
> That my dmesg:
> [ 5280.282257] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [ 5280.282264] Tx Queue <0>
> [ 5280.282265] TDH <67>
> [ 5280.282265] TDT <a9>
> [ 5280.282266] next_to_use <a9>
> [ 5280.282267] next_to_clean <fe>
> [ 5280.282268] buffer_info[next_to_clean]
> [ 5280.282269] time_stamp <76c86>
> [ 5280.282270] next_to_watch <fe>
> [ 5280.282271] jiffies <76d33>
> [ 5280.282272] next_to_watch.status <1>
> [ 272.396662] opreport[5752]: segfault at b7be1010 eip 080b396e esp
> bfba9480 error 4
> [ 2264.085353] htb: too many events !
> [ 3376.658037] htb: too many events !
> [ 5724.766531] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [ 5724.766533] Tx Queue <0>
> [ 5724.766534] TDH <23>
> [ 5724.766535] TDT <23>
> [ 5724.766536] next_to_use <23>
> [ 5724.766537] next_to_clean <fd>
> [ 5724.766537] buffer_info[next_to_clean]
> [ 5724.766538] time_stamp <50db81>
> [ 5724.766539] next_to_watch <fd>
> [ 5724.766540] jiffies <50e3ab>
> [ 5724.766541] next_to_watch.status <1>
> [ 5724.767771] htb: too many events !
> [10527.197125] htb: too many events !
> [11744.405451] htb: too many events !
> [12925.662880] htb: too many events !
> [14123.186443] htb: too many events !
> [15333.652189] htb: too many events !
> [16522.524045] htb: too many events !
> [17722.572386] htb: too many events !
> [18925.121034] htb: too many events !
> [20117.689133] htb: too many events !
> [20117.690436] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [20117.690438] Tx Queue <0>
> [20117.690439] TDH <8>
> [20117.690440] TDT <4b>
> [20117.690441] next_to_use <4b>
> [20117.690442] next_to_clean <a0>
> [20117.690443] buffer_info[next_to_clean]
> [20117.690443] time_stamp <128b414>
> [20117.690444] next_to_watch <a0>
> [20117.690445] jiffies <128bc3f>
> [20117.690446] next_to_watch.status <1>
> [21314.498859] htb: too many events !
> [22192.855455] htb: too many events !
> [22520.640345] htb: too many events !
> [23712.083687] htb: too many events !
> [24912.407418] htb: too many events !
> [26128.954774] htb: too many events !
> [27314.726708] htb: too many events !
> [28517.307859] htb: too many events !
> [28517.309179] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [28517.309181] Tx Queue <0>
> [28517.309182] TDH <1a>
> [28517.309183] TDT <4f>
> [28517.309184] next_to_use <4f>
> [28517.309185] next_to_clean <a4>
> [28517.309186] buffer_info[next_to_clean]
> [28517.309187] time_stamp <1a5c7c3>
> [28517.309187] next_to_watch <a4>
> [28517.309188] jiffies <1a5cf20>
> [28517.309189] next_to_watch.status <1>
> [30922.659736] htb: too many events !
> [30922.661064] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [30922.661066] Tx Queue <0>
> [30922.661067] TDH <51>
> [30922.661068] TDT <76>
> [30922.661069] next_to_use <76>
> [30922.661070] next_to_clean <cb>
> [30922.661071] buffer_info[next_to_clean]
> [30922.661071] time_stamp <1c9ad65>
> [30922.661072] next_to_watch <cb>
> [30922.661073] jiffies <1c9b459>
> [30922.661074] next_to_watch.status <1>
> [32124.687849] htb: too many events !
> [33345.636940] htb: too many events !
> [34528.356531] htb: too many events !
> [34528.358024] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [34528.358027] Tx Queue <0>
> [34528.358028] TDH <fa>
> [34528.358029] TDT <3>
> [34528.358029] next_to_use <3>
> [34528.358030] next_to_clean <58>
> [34528.358031] buffer_info[next_to_clean]
> [34528.358032] time_stamp <1ff85ab>
> [34528.358033] next_to_watch <58>
> [34528.358034] jiffies <1ff8d27>
> [34528.358035] next_to_watch.status <1>
> [35734.669698] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [35734.669700] Tx Queue <0>
> [35734.669701] TDH <5f>
> [35734.669702] TDT <5f>
> [35734.669703] next_to_use <5f>
> [35734.669704] next_to_clean <bf>
> [35734.669705] buffer_info[next_to_clean]
> [35734.669705] time_stamp <211994b>
> [35734.669706] next_to_watch <bf>
> [35734.669707] jiffies <211a017>
> [35734.669708] next_to_watch.status <1>
> [35734.672161] htb: too many events !
> [36955.160096] htb: too many events !
> [38118.346906] htb: too many events !
> [39330.213684] htb: too many events !
> [39330.214762] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [39330.214764] Tx Queue <0>
> [39330.214765] TDH <eb>
> [39330.214766] TDT <45>
> [39330.214767] next_to_use <45>
> [39330.214767] next_to_clean <9a>
> [39330.214768] buffer_info[next_to_clean]
> [39330.214769] time_stamp <2477328>
> [39330.214770] next_to_watch <9a>
> [39330.214771] jiffies <2477b16>
> [39330.214772] next_to_watch.status <1>
> [40551.898491] htb: too many events !
> [40551.899264] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [40551.899266] Tx Queue <0>
> [40551.899267] TDH <bf>
> [40551.899268] TDT <ca>
> [40551.899269] next_to_use <ca>
> [40551.899269] next_to_clean <1f>
> [40551.899270] buffer_info[next_to_clean]
> [40551.899271] time_stamp <259c212>
> [40551.899272] next_to_watch <1f>
> [40551.899273] jiffies <259c91e>
> [40551.899274] next_to_watch.status <1>
> [41724.774002] htb: too many events !
> [42920.657519] htb: too many events !
> [44143.420904] htb: too many events !
> [45303.157047] htb: too many events !
> [46492.258329] htb: too many events !
> [47694.779740] htb: too many events !
> [58471.571956] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [58471.571959] Tx Queue <0>
> [58471.571960] TDH <7b>
> [58471.571960] TDT <7b>
> [58471.571961] next_to_use <7b>
> [58471.571962] next_to_clean <d0>
> [58471.571963] buffer_info[next_to_clean]
> [58471.571964] time_stamp <36516dd>
> [58471.571965] next_to_watch <d0>
> [58471.571966] jiffies <36531cc>
> [58471.571967] next_to_watch.status <1>
> [59669.526000] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [59669.526002] Tx Queue <0>
> [59669.526003] TDH <6>
> [59669.526004] TDT <1e>
> [59669.526005] next_to_use <1e>
> [59669.526006] next_to_clean <73>
> [59669.526007] buffer_info[next_to_clean]
> [59669.526008] time_stamp <37718da>
> [59669.526009] next_to_watch <73>
> [59669.526009] jiffies <3773434>
> [59669.526010] next_to_watch.status <1>
> [60865.254499] NETDEV WATCHDOG: eth0: transmit timed out
> [60865.254584] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [60865.254585] Tx Queue <0>
> [60865.254586] TDH <ed>
> [60865.254587] TDT <ed>
> [60865.254588] next_to_use <ed>
> [60865.254589] next_to_clean <4c>
> [60865.254590] buffer_info[next_to_clean]
> [60865.254590] time_stamp <38919bb>
> [60865.254591] next_to_watch <4c>
> [60865.254592] jiffies <38934a2>
> [60865.254593] next_to_watch.status <1>
> [62064.876121] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [62064.876123] Tx Queue <0>
> [62064.876124] TDH <6a>
> [62064.876125] TDT <71>
> [62064.876126] next_to_use <71>
> [62064.876126] next_to_clean <c6>
> [62064.876127] buffer_info[next_to_clean]
> [62064.876128] time_stamp <39b221d>
> [62064.876129] next_to_watch <c6>
> [62064.876130] jiffies <39b3d07>
> [62064.876131] next_to_watch.status <1>
> [63261.288625] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [63261.288628] Tx Queue <0>
> [63261.288629] TDH <b9>
> [63261.288630] TDT <b9>
> [63261.288631] next_to_use <b9>
> [63261.288631] next_to_clean <e>
> [63261.288632] buffer_info[next_to_clean]
> [63261.288633] time_stamp <3ad1b46>
> [63261.288634] next_to_watch <e>
> [63261.288635] jiffies <3ad3b43>
> [63261.288636] next_to_watch.status <1>
> [64459.486793] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [64459.486796] Tx Queue <0>
> [64459.486797] TDH <19>
> [64459.486798] TDT <19>
> [64459.486798] next_to_use <19>
> [64459.486799] next_to_clean <ae>
> [64459.486800] buffer_info[next_to_clean]
> [64459.486801] time_stamp <3bf25e5>
> [64459.486802] next_to_watch <ae>
> [64459.486803] jiffies <3bf422f>
> [64459.486804] next_to_watch.status <1>
> [65663.246067] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [65663.246069] Tx Queue <0>
> [65663.246070] TDH <c3>
> [65663.246071] TDT <17>
> [65663.246072] next_to_use <17>
> [65663.246073] next_to_clean <6c>
> [65663.246074] buffer_info[next_to_clean]
> [65663.246075] time_stamp <3d141e5>
> [65663.246076] next_to_watch <6c>
> [65663.246077] jiffies <3d15cca>
> [65663.246077] next_to_watch.status <1>
> [66855.416474] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [66855.416477] Tx Queue <0>
> [66855.416478] TDH <e5>
> [66855.416479] TDT <e5>
> [66855.416480] next_to_use <e5>
> [66855.416480] next_to_clean <96>
> [66855.416481] buffer_info[next_to_clean]
> [66855.416482] time_stamp <3e333f4>
> [66855.416483] next_to_watch <96>
> [66855.416484] jiffies <3e35090>
> [66855.416485] next_to_watch.status <1>
> [68054.040533] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [68054.040536] Tx Queue <0>
> [68054.040537] TDH <b2>
> [68054.040538] TDT <2>
> [68054.040538] next_to_use <2>
> [68054.040539] next_to_clean <57>
> [68054.040540] buffer_info[next_to_clean]
> [68054.040541] time_stamp <3f546cd>
> [68054.040542] next_to_watch <57>
> [68054.040542] jiffies <3f560f6>
> [68054.040543] next_to_watch.status <1>
> [69260.670653] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [69260.670656] Tx Queue <0>
> [69260.670657] TDH <83>
> [69260.670657] TDT <e9>
> [69260.670658] next_to_use <e9>
> [69260.670659] next_to_clean <3e>
> [69260.670660] buffer_info[next_to_clean]
> [69260.670661] time_stamp <4077a70>
> [69260.670662] next_to_watch <3e>
> [69260.670663] jiffies <40795d1>
> [69260.670663] next_to_watch.status <1>
> [70450.618127] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [70450.618130] Tx Queue <0>
> [70450.618131] TDH <e5>
> [70450.618131] TDT <35>
> [70450.618132] next_to_use <35>
> [70450.618133] next_to_clean <8a>
> [70450.618134] buffer_info[next_to_clean]
> [70450.618135] time_stamp <4196ed3>
> [70450.618136] next_to_watch <8a>
> [70450.618137] jiffies <41987ab>
> [70450.618137] next_to_watch.status <1>
> [71648.909256] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [71648.909258] Tx Queue <0>
> [71648.909259] TDH <41>
> [71648.909260] TDT <42>
> [71648.909261] next_to_use <42>
> [71648.909262] next_to_clean <97>
> [71648.909262] buffer_info[next_to_clean]
> [71648.909263] time_stamp <42b8542>
> [71648.909264] next_to_watch <97>
> [71648.909265] jiffies <42b9fa1>
> [71648.909266] next_to_watch.status <1>
> [72851.697294] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [72851.697297] Tx Queue <0>
> [72851.697298] TDH <30>
> [72851.697298] TDT <54>
> [72851.697299] next_to_use <54>
> [72851.697300] next_to_clean <a9>
> [72851.697301] buffer_info[next_to_clean]
> [72851.697302] time_stamp <43dadd4>
> [72851.697303] next_to_watch <a9>
> [72851.697304] jiffies <43dc870>
> [72851.697305] next_to_watch.status <1>
> [75245.677954] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [75245.677957] Tx Queue <0>
> [75245.677958] TDH <85>
> [75245.677958] TDT <b5>
> [75245.677959] next_to_use <b5>
> [75245.677960] next_to_clean <a>
> [75245.677961] buffer_info[next_to_clean]
> [75245.677962] time_stamp <461dd97>
> [75245.677963] next_to_watch <a>
> [75245.677964] jiffies <461f952>
> [75245.677965] next_to_watch.status <1>
> [76448.839007] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [76448.839009] Tx Queue <0>
> [76448.839011] TDH <18>
> [76448.839012] TDT <68>
> [76448.839012] next_to_use <68>
> [76448.839013] next_to_clean <bd>
> [76448.839014] buffer_info[next_to_clean]
> [76448.839015] time_stamp <4740b7f>
> [76448.839016] next_to_watch <bd>
> [76448.839017] jiffies <4742788>
> [76448.839018] next_to_watch.status <1>
> [77641.472192] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [77641.472195] Tx Queue <0>
> [77641.472197] TDH <f>
> [77641.472198] TDT <6a>
> [77641.472198] next_to_use <6a>
> [77641.472199] next_to_clean <d7>
> [77641.472200] buffer_info[next_to_clean]
> [77641.472201] time_stamp <48612f3>
> [77641.472202] next_to_watch <d7>
> [77641.472203] jiffies <4862c1f>
> [77641.472204] next_to_watch.status <1>
> [78841.540399] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [78841.540401] Tx Queue <0>
> [78841.540402] TDH <49>
> [78841.540403] TDT <49>
> [78841.540404] next_to_use <49>
> [78841.540405] next_to_clean <40>
> [78841.540406] buffer_info[next_to_clean]
> [78841.540406] time_stamp <49832d4>
> [78841.540407] next_to_watch <40>
> [78841.540408] jiffies <4984da3>
> [78841.540409] next_to_watch.status <1>
> [80047.286824] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [80047.286827] Tx Queue <0>
> [80047.286828] TDH <fc>
> [80047.286829] TDT <37>
> [80047.286830] next_to_use <37>
> [80047.286830] next_to_clean <8c>
> [80047.286831] buffer_info[next_to_clean]
> [80047.286832] time_stamp <4aa66e4>
> [80047.286833] next_to_watch <8c>
> [80047.286834] jiffies <4aa812b>
> [80047.286835] next_to_watch.status <1>
> [81240.261877] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [81240.261879] Tx Queue <0>
> [81240.261880] TDH <8f>
> [81240.261881] TDT <be>
> [81240.261882] next_to_use <be>
> [81240.261883] next_to_clean <13>
> [81240.261884] buffer_info[next_to_clean]
> [81240.261884] time_stamp <4bc5b32>
> [81240.261885] next_to_watch <13>
> [81240.261886] jiffies <4bc73d9>
> [81240.261887] next_to_watch.status <1>
> [82440.249836] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [82440.249838] Tx Queue <0>
> [82440.249839] TDH <9d>
> [82440.249840] TDT <9d>
> [82440.249841] next_to_use <9d>
> [82440.249842] next_to_clean <f2>
> [82440.249842] buffer_info[next_to_clean]
> [82440.249843] time_stamp <4ce6735>
> [82440.249844] next_to_watch <f2>
> [82440.249845] jiffies <4ce8149>
> [82440.249846] next_to_watch.status <1>
>
>
>
>> it appears the tx
>> handler was
>> just sitting idle and this message might be bogus, which is one of
>> the things that
>> we fixed recently.
>>
>> Auke
>>
>>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
From: Eugene Surovegin @ 2008-01-12 9:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Stefan Roese, netdev, linuxppc-dev
In-Reply-To: <1200124644.6896.99.camel@pasglop>
On Sat, Jan 12, 2008 at 06:57:24PM +1100, Benjamin Herrenschmidt wrote:
>
> On Sat, 2008-01-12 at 08:26 +0100, Stefan Roese wrote:
> >
> > We shouldn't make it too complicated. We can always select different
> > settings
> > in the defconfig file. My thinking here is to better wast a little
> > memory
> > with a potential performance improvement. Just me 0.02$
>
> If it gets really critical, then we can move those settings to the
> device-tree.
Come on guys, it's not that critical. I guess I just don't trust a
certain company :)
--
Eugene
^ permalink raw reply
* [PATCH net-2.6.25 0/8] [NET]: More uninlining & related
From: Ilpo Järvinen @ 2008-01-12 9:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Hi Dave,
First of all, I changed output encoding of git to utf-8, so I
guess the encoding should not cause the same trouble for you.
Here are couple of more to uninline things. Pretty
straightforward except the EXPORT_SYMBOLs, I've no idea which
is the right variant (feel free to fix them while applying :-)).
Also pktgen uninlining is somewhat questionable because it's
just a testing tool so feel free to drop it if it feels
unnecessary (I could have asked first but it's just as easy to
do it this way if not easier)...
There were more dead static inlines found after inlines removed
(gcc didn't report them otherwise) than in pktgen now included,
but I'm not sure if I should send "by default" patches removing
or #if 0'ing them?
--
i.
^ permalink raw reply
* [PATCH net-2.6.25 0/8] [NET]: More uninlining & related
From: Ilpo Järvinen @ 2008-01-12 9:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Hi Dave,
First of all, I changed output encoding to utf-8, so I guess
the encoding should not cause trouble for you.
Here are couple of more to uninline things. Pretty
straightforward except the EXPORT_SYMBOLs, I've no idea which
is the right variant (feel free to fix them while applying :-)).
Also pktgen uninlining is somewhat questionable because it's
just a testing tool so feel free to drop it if it feels
unnecessary (I could have asked first but it's just as easy to
do it this way if not easier)...
There were more dead static inlines found after inlines removed
(gcc didn't report them otherwise) than in pktgen now included,
but I'm not sure if I should send "by default" patches removing
or #if 0'ing them?
--
i.
ps. I apologize that I must resend to get them to netdev as well
because git-send-email of this system (not sure if later could)
still seems to be lacking proper encoding of my name when it
decides to add it to Cc list all by itself and those 8-bit chars
in address got rejected.
^ permalink raw reply
* [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
From: Ilpo Järvinen @ 2008-01-12 9:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1200130817467-git-send-email-ilpo.jarvinen@helsinki.fi>
net/core/pktgen.c:
pktgen_stop_device | -50
pktgen_run | -105
pktgen_if_show | -37
pktgen_thread_worker | -702
4 functions changed, 894 bytes removed, diff: -894
net/core/pktgen.c:
getCurUs | +36
1 function changed, 36 bytes added, diff: +36
net/core/pktgen.o:
5 functions changed, 36 bytes added, 894 bytes removed, diff: -858
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/core/pktgen.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index ebfb126..d18fdb1 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -405,7 +405,7 @@ static inline __u64 tv_to_us(const struct timeval *tv)
return us;
}
-static inline __u64 getCurUs(void)
+static __u64 getCurUs(void)
{
struct timeval tv;
do_gettimeofday(&tv);
--
1.5.0.6
^ permalink raw reply related
* [PATCH 2/8] [TCP]: Uninline tcp_is_cwnd_limited
From: Ilpo Järvinen @ 2008-01-12 9:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <12001308171262-git-send-email-ilpo.jarvinen@helsinki.fi>
net/ipv4/tcp_cong.c:
tcp_reno_cong_avoid | -65
1 function changed, 65 bytes removed, diff: -65
net/ipv4/arp.c:
arp_ignore | -5
1 function changed, 5 bytes removed, diff: -5
net/ipv4/tcp_bic.c:
bictcp_cong_avoid | -57
1 function changed, 57 bytes removed, diff: -57
net/ipv4/tcp_cubic.c:
bictcp_cong_avoid | -61
1 function changed, 61 bytes removed, diff: -61
net/ipv4/tcp_highspeed.c:
hstcp_cong_avoid | -63
1 function changed, 63 bytes removed, diff: -63
net/ipv4/tcp_hybla.c:
hybla_cong_avoid | -85
1 function changed, 85 bytes removed, diff: -85
net/ipv4/tcp_htcp.c:
htcp_cong_avoid | -57
1 function changed, 57 bytes removed, diff: -57
net/ipv4/tcp_veno.c:
tcp_veno_cong_avoid | -52
1 function changed, 52 bytes removed, diff: -52
net/ipv4/tcp_scalable.c:
tcp_scalable_cong_avoid | -61
1 function changed, 61 bytes removed, diff: -61
net/ipv4/tcp_yeah.c:
tcp_yeah_cong_avoid | -75
1 function changed, 75 bytes removed, diff: -75
net/ipv4/tcp_illinois.c:
tcp_illinois_cong_avoid | -54
1 function changed, 54 bytes removed, diff: -54
net/dccp/ccids/ccid3.c:
ccid3_update_send_interval | -7
ccid3_hc_tx_packet_recv | +7
2 functions changed, 7 bytes added, 7 bytes removed, diff: +0
net/ipv4/tcp_cong.c:
tcp_is_cwnd_limited | +88
1 function changed, 88 bytes added, diff: +88
built-in.o:
14 functions changed, 95 bytes added, 642 bytes removed, diff: -547
...Again some gcc artifacts visible as well.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
include/net/tcp.h | 22 +---------------------
net/ipv4/tcp_cong.c | 21 +++++++++++++++++++++
2 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 306580c..7de4ea3 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -786,27 +786,7 @@ static inline u32 tcp_wnd_end(const struct tcp_sock *tp)
{
return tp->snd_una + tp->snd_wnd;
}
-
-/* RFC2861 Check whether we are limited by application or congestion window
- * This is the inverse of cwnd check in tcp_tso_should_defer
- */
-static inline int tcp_is_cwnd_limited(const struct sock *sk, u32 in_flight)
-{
- const struct tcp_sock *tp = tcp_sk(sk);
- u32 left;
-
- if (in_flight >= tp->snd_cwnd)
- return 1;
-
- if (!sk_can_gso(sk))
- return 0;
-
- left = tp->snd_cwnd - in_flight;
- if (sysctl_tcp_tso_win_divisor)
- return left * sysctl_tcp_tso_win_divisor < tp->snd_cwnd;
- else
- return left <= tcp_max_burst(tp);
-}
+extern int tcp_is_cwnd_limited(const struct sock *sk, u32 in_flight);
static inline void tcp_minshall_update(struct tcp_sock *tp, unsigned int mss,
const struct sk_buff *skb)
diff --git a/net/ipv4/tcp_cong.c b/net/ipv4/tcp_cong.c
index 4451750..3a6be23 100644
--- a/net/ipv4/tcp_cong.c
+++ b/net/ipv4/tcp_cong.c
@@ -274,6 +274,27 @@ int tcp_set_congestion_control(struct sock *sk, const char *name)
return err;
}
+/* RFC2861 Check whether we are limited by application or congestion window
+ * This is the inverse of cwnd check in tcp_tso_should_defer
+ */
+int tcp_is_cwnd_limited(const struct sock *sk, u32 in_flight)
+{
+ const struct tcp_sock *tp = tcp_sk(sk);
+ u32 left;
+
+ if (in_flight >= tp->snd_cwnd)
+ return 1;
+
+ if (!sk_can_gso(sk))
+ return 0;
+
+ left = tp->snd_cwnd - in_flight;
+ if (sysctl_tcp_tso_win_divisor)
+ return left * sysctl_tcp_tso_win_divisor < tp->snd_cwnd;
+ else
+ return left <= tcp_max_burst(tp);
+}
+EXPORT_SYMBOL_GPL(tcp_is_cwnd_limited);
/*
* Slow start is used when congestion window is less than slow start
--
1.5.0.6
^ permalink raw reply related
* [PATCH 1/8] [TCP]: Uninline tcp_set_state
From: Ilpo Järvinen @ 2008-01-12 9:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <12001308173969-git-send-email-ilpo.jarvinen@helsinki.fi>
net/ipv4/tcp.c:
tcp_close_state | -226
tcp_done | -145
tcp_close | -564
tcp_disconnect | -141
4 functions changed, 1076 bytes removed, diff: -1076
net/ipv4/tcp_input.c:
tcp_fin | -86
tcp_rcv_state_process | -164
2 functions changed, 250 bytes removed, diff: -250
net/ipv4/tcp_ipv4.c:
tcp_v4_connect | -209
1 function changed, 209 bytes removed, diff: -209
net/ipv4/arp.c:
arp_ignore | +5
1 function changed, 5 bytes added, diff: +5
net/ipv6/tcp_ipv6.c:
tcp_v6_connect | -158
1 function changed, 158 bytes removed, diff: -158
net/sunrpc/xprtsock.c:
xs_sendpages | -2
1 function changed, 2 bytes removed, diff: -2
net/dccp/ccids/ccid3.c:
ccid3_update_send_interval | +7
1 function changed, 7 bytes added, diff: +7
net/ipv4/tcp.c:
tcp_set_state | +238
1 function changed, 238 bytes added, diff: +238
built-in.o:
12 functions changed, 250 bytes added, 1695 bytes removed, diff: -1445
I've no explanation why some unrelated changes seem to occur
consistently as well (arp_ignore, ccid3_update_send_interval;
I checked the arp_ignore asm and it seems to be due to some
reordered of operation order causing some extra opcodes to be
generated). Still, the benefits are pretty obvious from the
codiff's results.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Cc: Andi Kleen <andi@firstfloor.org>
---
include/net/tcp.h | 35 +----------------------------------
net/ipv4/tcp.c | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 34 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 48081ad..306580c 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -926,40 +926,7 @@ static const char *statename[]={
"Close Wait","Last ACK","Listen","Closing"
};
#endif
-
-static inline void tcp_set_state(struct sock *sk, int state)
-{
- int oldstate = sk->sk_state;
-
- switch (state) {
- case TCP_ESTABLISHED:
- if (oldstate != TCP_ESTABLISHED)
- TCP_INC_STATS(TCP_MIB_CURRESTAB);
- break;
-
- case TCP_CLOSE:
- if (oldstate == TCP_CLOSE_WAIT || oldstate == TCP_ESTABLISHED)
- TCP_INC_STATS(TCP_MIB_ESTABRESETS);
-
- sk->sk_prot->unhash(sk);
- if (inet_csk(sk)->icsk_bind_hash &&
- !(sk->sk_userlocks & SOCK_BINDPORT_LOCK))
- inet_put_port(&tcp_hashinfo, sk);
- /* fall through */
- default:
- if (oldstate==TCP_ESTABLISHED)
- TCP_DEC_STATS(TCP_MIB_CURRESTAB);
- }
-
- /* Change state AFTER socket is unhashed to avoid closed
- * socket sitting in hash tables.
- */
- sk->sk_state = state;
-
-#ifdef STATE_TRACE
- SOCK_DEBUG(sk, "TCP sk=%p, State %s -> %s\n",sk, statename[oldstate],statename[state]);
-#endif
-}
+extern void tcp_set_state(struct sock *sk, int state);
extern void tcp_done(struct sock *sk);
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 34085e3..7d7b958 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1652,6 +1652,41 @@ recv_urg:
goto out;
}
+void tcp_set_state(struct sock *sk, int state)
+{
+ int oldstate = sk->sk_state;
+
+ switch (state) {
+ case TCP_ESTABLISHED:
+ if (oldstate != TCP_ESTABLISHED)
+ TCP_INC_STATS(TCP_MIB_CURRESTAB);
+ break;
+
+ case TCP_CLOSE:
+ if (oldstate == TCP_CLOSE_WAIT || oldstate == TCP_ESTABLISHED)
+ TCP_INC_STATS(TCP_MIB_ESTABRESETS);
+
+ sk->sk_prot->unhash(sk);
+ if (inet_csk(sk)->icsk_bind_hash &&
+ !(sk->sk_userlocks & SOCK_BINDPORT_LOCK))
+ inet_put_port(&tcp_hashinfo, sk);
+ /* fall through */
+ default:
+ if (oldstate==TCP_ESTABLISHED)
+ TCP_DEC_STATS(TCP_MIB_CURRESTAB);
+ }
+
+ /* Change state AFTER socket is unhashed to avoid closed
+ * socket sitting in hash tables.
+ */
+ sk->sk_state = state;
+
+#ifdef STATE_TRACE
+ SOCK_DEBUG(sk, "TCP sk=%p, State %s -> %s\n",sk, statename[oldstate],statename[state]);
+#endif
+}
+EXPORT_SYMBOL_GPL(tcp_set_state);
+
/*
* State processing on a close. This implements the state shift for
* sending our FIN frame. Note that we only send a FIN for some
--
1.5.0.6
^ permalink raw reply related
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