* RE: [2.6 patch] net/sunrpc/xdr.c: remove xdr_decode_string()
From: Lever, Charles @ 2005-11-24 6:56 UTC (permalink / raw)
To: Neil Brown, Adrian Bunk
Cc: David Miller, trond.myklebust, linux-kernel, nfs, netdev
> On Wednesday November 23, bunk@stusta.de wrote:
> > On Wed, Nov 23, 2005 at 04:31:14AM -0800, Lever, Charles wrote:
> > > so i don't remember why you are removing
> xdr_decode_string. are we sure
> > > that no-one will need this functionality in the future?
> it is harmless
> > > to remove today, but i wonder if someone is just going to
> add it back
> > > sometime.
> >
> > It's unused and you said:
> > the only harmless change i see below is removing
> xdr_decode_string().
> >
>
> As 'xdr_decode_string' (sometimes) modifies the buffer that it is
> decoding, I don't think it's usage should be encouraged. If it is no
> longer in use, then I fully support and encourage removing it.
actually this is a good point. since it is unused, it is an untested
path as we continue to evolve the code base.
^ permalink raw reply
* Re: 2.6.15-rc2-mm1
From: Harald Welte @ 2005-11-24 9:04 UTC (permalink / raw)
To: Andrew Morton; +Cc: Michal Piotrowski, linux-kernel, netdev
In-Reply-To: <20051123112218.73f68926.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]
On Wed, Nov 23, 2005 at 11:22:18AM -0800, Andrew Morton wrote:
> Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> >
> > Debug: sleeping function called from invalid context at
> > include/asm/semaphore.h:123
> > in_atomic():1, irqs_disabled():0
> > [<c0103be6>] dump_stack+0x17/0x19
> > [<c011a0c3>] __might_sleep+0x9c/0xae
> > [<fd9a090d>] translate_table+0x147/0xc14 [ip_tables]
> > [<fd9a2b2a>] ipt_register_table+0x93/0x20d [ip_tables]
> > [<f98fe027>] init+0x27/0x9e [iptable_filter]
> > [<c01376d0>] sys_init_module+0xd7/0x26c
> > [<c0102cc7>] sysenter_past_esp+0x54/0x75
> > ---------------------------
> > | preempt count: 00000001 ]
> > | 1 level deep critical section nesting:
> > ----------------------------------------
> > .. [<fd9a2aca>] .... ipt_register_table+0x33/0x20d [ip_tables]
> > .....[<f98fe027>] .. ( <= init+0x27/0x9e [iptable_filter])
> >
>
> ipt_register_table() does get_cpu() then calls translate_table(), and
> somewhere under translate_table() we do something which sleeps, only I'm not
> sure what it is - netfilter likes to hide things in unexpected places.
I'll investigate this. the get_cpu() scheme was introduced as a fix for
a different (less serious) problem.
You'll get a reply until later today.
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Mouse issues in -mm
From: Marc Koschewski @ 2005-11-24 9:40 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Frank Sorenson, Andrew Morton, Marc Koschewski, linux-kernel,
Harald Welte, netdev
In-Reply-To: <200511232226.44459.dtor_core@ameritech.net>
* Dmitry Torokhov <dtor_core@ameritech.net> [2005-11-23 22:26:43 -0500]:
> On Wednesday 23 November 2005 21:06, Frank Sorenson wrote:
> > Andrew Morton wrote:
> > > Marc Koschewski <marc@osknowledge.org> wrote:
> > >>Just booted into 2.6.15-rc2-mm1. The 'mouse problem' (as reported earlier) still
> > >>persists,
> > >
> > > You'l probably need to re-report the mouse problem if the previous report
> > > didn't get any action.
> >
> > I'm not certain whether this is the same 'mouse problem', but I'll
> > report the mouse problems I've been seeing. In the past several -mm
> > kernels, my touchpad has initially worked at boot, but 'tapping' has
> > stopped working at some point later (with no obvious kernel messages).
> >
> > I've experienced this problem at least with 2.6.15-rc1-mm2 and
> > 2.6.15-rc2-mm1, and reverting
> > input-attempt-to-re-synchronize-mouse-every-5-seconds.patch gives a
> > kernel without the touchpad problems.
> >
>
> What kind of touchpad do you have? Could you post your
> /pros/bus/input/devices please?
Mine is like this:
I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/class/input/input0
H: Handlers=kbd event0
B: EV=120013
B: KEY=4 2000000 3802078 f840d001 f2ffffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7
I: Bus=0010 Vendor=001f Product=0001 Version=0100
N: Name="PC Speaker"
P: Phys=isa0061/input0
S: Sysfs=/class/input/input1
H: Handlers=kbd event1
B: EV=40001
B: SND=6
I: Bus=0011 Vendor=0002 Product=0005 Version=0000
N: Name="ImPS/2 Generic Wheel Mouse"
P: Phys=isa0060/serio1/input0
S: Sysfs=/class/input/input2
H: Handlers=event2 mouse0
B: EV=7
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=103
I don't know why my touchpad is not listed. I have one and it perfectly
works with X (same pointer as the mouse which is a Microsoft USB Wheel Mouse'
attached to PS/2 using an appropriate adapter.
Marc
^ permalink raw reply
* Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: Catalin Marinas @ 2005-11-24 10:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Adrian Bunk, saw, linux-kernel, netdev, David S. Miller
In-Reply-To: <20051123222410.GN15449@flint.arm.linux.org.uk>
Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Wed, Nov 23, 2005 at 10:15:48PM +0000, Russell King wrote:
>> Well, I've run 2.6.15-rc2 on what I think was the ARM platform which
>> exhibited the problem, but it doesn't show up.
>
> The test was merely a "did it successfully BOOTP" because I can't
> get it to mount and run /sbin/init from the jffs2 rootfs which
> 2.5.70 was perfectly happy to earlier today. However, the
> failure point seemed to be when NFS tried to use the card.
If you you are referring to the ARM Integrator/AP platform, I tested
it earlier this year, with a 2.6.12 kernel, and the e100.c driver
seemed to be OK with an NFS-mounted root filesystem and the IP address
got via kernel DHCP. I had problems getting the eepro100.c driver to
work though, but I didn't dig any further since e100.c seemed OK.
I'll give it another try early next week with 2.6.15-rc2 and let you
know whether I see any problems.
--
Catalin
^ permalink raw reply
* Re: [RFC] [PATCH 1/3] ioat: DMA subsystem
From: Christoph Hellwig @ 2005-11-24 11:48 UTC (permalink / raw)
To: Andrew Grover; +Cc: netdev, linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <Pine.LNX.4.44.0511231207410.32487-100000@isotope.jf.intel.com>
> +++ b/drivers/dma/cb_list.h
> @@ -0,0 +1,12 @@
> +/* Extra macros that build on <linux/list.h> */
> +#ifndef CB_LIST_H
> +#define CB_LIST_H
> +
> +#include <linux/list.h>
> +
> +/* Provide some safty to list_add, which I find easy to swap the arguments to */
> +
> +#define list_add_entry(pos, head, member) list_add(&pos->member, head)
> +#define list_add_entry_tail(pos, head, member) list_add_tail(&pos->member, head)
these macros seem rather useless. if you disagree please submit a patch to
<linux/list.h> - if it gets accepted fine, else just remove this usage.
> + struct dma_chan *chan = container_of(cd, struct dma_chan, class_dev);
What about a
#define to_dma_chan(cdev) \
container_of(cd, struct dma_chan, cdev)
helper as we have in many subsystems?
> +static void
> +dma_class_release(struct class_device *cd)
> +{
> + /* do something */
> +}
umm, yeah.. :)
> +static struct dma_chan *
> +dma_client_chan_alloc(struct dma_client *client)
> +{
> + struct dma_device *device;
> + struct dma_chan *chan;
> +
> + BUG_ON(!client);
> +
> + /* Find a channel, any DMA engine will do */
> + list_for_each_entry(device, &dma_device_list, global_node) {
> + list_for_each_entry(chan, &device->channels, device_node) {
> + if (chan->client)
> + continue;
couldn't you use the normal device model list for this?
> +static void
> +dma_client_chan_free(struct dma_chan *chan)
> +{
> + BUG_ON(!chan);
> +
> + chan->device->device_free_chan_resources(chan);
you'll get the oops here anyway, no need for the BUG_ON
> + chan = list_entry(client->channels.next, struct dma_chan, client_node);
please shorten the line length to fit 80 column terminals.
> +static int __init dma_bus_init(void)
> +{
> + int cpu;
> +
> + dma_wait_wq = create_workqueue("dmapoll");
> + for_each_online_cpu(cpu) {
> + init_completion(&per_cpu(kick_dma_poll, cpu));
you either need to make this for_each_possible_cpu or add a hotplug
cpu notifier. the first is probably a lot easier :)
^ permalink raw reply
* Re: [RFC] [PATCH 1/3] ioat: DMA subsystem
From: Ingo Oeser @ 2005-11-24 15:00 UTC (permalink / raw)
To: Jeff Garzik
Cc: Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <4384F0C4.1090209@pobox.com>
Hi,
Jeff Garzik wrote:
> explanation of this function would be nice. remember to answer "how?"
> and "why?", not "what?".
Wasn't it the other way around?
Citing linux/Documentation/CodingStyle, section 7 "Comments":
"Generally, you want your comments to tell WHAT your code does, not HOW."
HOW and WHY should be obvious by the source code, unless
the sources are a mess.
Regards
Ingo Oeser
^ permalink raw reply
* Re: [RFC] [PATCH 1/3] ioat: DMA subsystem
From: Jeff Garzik @ 2005-11-24 15:04 UTC (permalink / raw)
To: Ingo Oeser
Cc: Andrew Grover, netdev, linux-kernel, john.ronciak,
christopher.leech
In-Reply-To: <200511241600.50046.netdev@axxeo.de>
On Thu, Nov 24, 2005 at 04:00:50PM +0100, Ingo Oeser wrote:
> Hi,
>
> Jeff Garzik wrote:
> > explanation of this function would be nice. remember to answer "how?"
> > and "why?", not "what?".
>
> Wasn't it the other way around?
> Citing linux/Documentation/CodingStyle, section 7 "Comments":
>
> "Generally, you want your comments to tell WHAT your code does, not HOW."
>
> HOW and WHY should be obvious by the source code, unless
> the sources are a mess.
Yes, good point, thanks for the correction.
Jeff
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Avi Kivity @ 2005-11-24 15:24 UTC (permalink / raw)
To: Andi Kleen
Cc: Benjamin LaHaise, Jeff Garzik, Andrew Grover, netdev,
linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <20051124065037.GZ20775@brahms.suse.de>
Andi Kleen wrote:
>>Don't forget that there are benefits of not polluting the cache with the
>>traffic for the incoming skbs.
>>
>>
>
>Is that a general benefit outside benchmarks? I would expect
>most real programs to actually do something with the data
>- and that usually involves needing it in cache.
>
>
>
As an example, an NFS server reads some data pages using iSCSI and sends
them using NFS/TCP (or vice versa).
>>In the I/O AT case it might make sense to do a few prefetch()es of the
>>userland data on the return-to-userspace code path.
>>
>>
>
>Some prefetches for user space might be a good idea yes
>
>
>
As long as they can be turned off. Not all usespace applications want to
touch the data immediately.
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Andi Kleen @ 2005-11-24 15:29 UTC (permalink / raw)
To: Avi Kivity
Cc: Andi Kleen, Benjamin LaHaise, Jeff Garzik, Andrew Grover, netdev,
linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <4385DB32.7010605@argo.co.il>
On Thu, Nov 24, 2005 at 05:24:34PM +0200, Avi Kivity wrote:
> Andi Kleen wrote:
>
> >>Don't forget that there are benefits of not polluting the cache with the
> >>traffic for the incoming skbs.
> >>
> >>
> >
> >Is that a general benefit outside benchmarks? I would expect
> >most real programs to actually do something with the data
> >- and that usually involves needing it in cache.
> >
> >
> >
> As an example, an NFS server reads some data pages using iSCSI and sends
> them using NFS/TCP (or vice versa).
For TX this can be done zero copy using a sendfile like setup.
For RX it may help - but my point was that most applications
are not structured in this simple way.
> >>In the I/O AT case it might make sense to do a few prefetch()es of the
> >>userland data on the return-to-userspace code path.
> >>
> >>
> >
> >Some prefetches for user space might be a good idea yes
> >
> >
> >
> As long as they can be turned off. Not all usespace applications want to
> touch the data immediately.
Perhaps. And lots of others might. Of course the simple
network benchmarks don't so the number on them look good.
Just pointing out that it's not clear it will always be a big help.
-Andi
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Avi Kivity @ 2005-11-24 15:35 UTC (permalink / raw)
To: Andi Kleen
Cc: Benjamin LaHaise, Jeff Garzik, Andrew Grover, netdev,
linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <20051124152924.GB5921@wotan.suse.de>
Andi Kleen wrote:
>>>
>>>
>>As an example, an NFS server reads some data pages using iSCSI and sends
>>them using NFS/TCP (or vice versa).
>>
>>
>
>For TX this can be done zero copy using a sendfile like setup.
>
>
Yes, or with aio send for anonymous memory.
>For RX it may help - but my point was that most applications
>are not structured in this simple way.
>
>
>
Agreed. But those that do care, care very much. The data mover
applications, simply because they don't touch the data, expect very high
bandwidth.
>>As long as they can be turned off. Not all usespace applications want to
>>touch the data immediately.
>>
>>
>
>Perhaps. And lots of others might. Of course the simple
>network benchmarks don't so the number on them look good.
>
>
>
There are very real non-benchmark applications that want this.
>Just pointing out that it's not clear it will always be a big help.
>
>
>
Agree it should default to in-cache.
^ permalink raw reply
* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Andi Kleen @ 2005-11-24 15:37 UTC (permalink / raw)
To: Avi Kivity
Cc: Andi Kleen, Benjamin LaHaise, Jeff Garzik, Andrew Grover, netdev,
linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <4385DDBE.3040208@argo.co.il>
> >Just pointing out that it's not clear it will always be a big help.
> >
> >
> >
> Agree it should default to in-cache.
This would mean no DMA engine by default.
Clearly there needs to be some heuristic to decide by default. We'll see how
effective it will be in the end.
-Andi
^ permalink raw reply
* [PATCH] ibm_emac: fix graceful stop timeout handling
From: Eugene Surovegin @ 2005-11-24 22:48 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
This patch fixes graceful stop timeout handling in PPC4xx EMAC driver.
Currently, when we stop TX/RX channels we just do some number of loops
without relying on actual spent time. This has finally bitten me on
one of our systems (heavy network traffic during start up, RX channel
is stopped several times to configure multicast list).
Graceful channel stop can take up to 1 frame time, so I've added
device specific timeout counter which depends on current link speed
and calls to udelay() to really wait required amount of time before
giving up.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
drivers/net/ibm_emac/ibm_emac_core.c | 38 ++++++++++++++++++++++++++--------
drivers/net/ibm_emac/ibm_emac_core.h | 2 ++
2 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index eb7d694..1da8a66 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -65,7 +65,7 @@
*/
#define DRV_NAME "emac"
-#define DRV_VERSION "3.53"
+#define DRV_VERSION "3.54"
#define DRV_DESC "PPC 4xx OCP EMAC driver"
MODULE_DESCRIPTION(DRV_DESC);
@@ -158,6 +158,14 @@ static inline void emac_report_timeout_e
#define PHY_POLL_LINK_ON HZ
#define PHY_POLL_LINK_OFF (HZ / 5)
+/* Graceful stop timeouts in us.
+ * We should allow up to 1 frame time (full-duplex, ignoring collisions)
+ */
+#define STOP_TIMEOUT_10 1230
+#define STOP_TIMEOUT_100 124
+#define STOP_TIMEOUT_1000 13
+#define STOP_TIMEOUT_1000_JUMBO 73
+
/* Please, keep in sync with struct ibm_emac_stats/ibm_emac_error_stats */
static const char emac_stats_keys[EMAC_ETHTOOL_STATS_COUNT][ETH_GSTRING_LEN] = {
"rx_packets", "rx_bytes", "tx_packets", "tx_bytes", "rx_packets_csum",
@@ -222,10 +230,12 @@ static void emac_tx_disable(struct ocp_e
r = in_be32(&p->mr0);
if (r & EMAC_MR0_TXE) {
- int n = 300;
+ int n = dev->stop_timeout;
out_be32(&p->mr0, r & ~EMAC_MR0_TXE);
- while (!(in_be32(&p->mr0) & EMAC_MR0_TXI) && n)
+ while (!(in_be32(&p->mr0) & EMAC_MR0_TXI) && n) {
+ udelay(1);
--n;
+ }
if (unlikely(!n))
emac_report_timeout_error(dev, "TX disable timeout");
}
@@ -248,9 +258,11 @@ static void emac_rx_enable(struct ocp_en
if (!(r & EMAC_MR0_RXE)) {
if (unlikely(!(r & EMAC_MR0_RXI))) {
/* Wait if previous async disable is still in progress */
- int n = 100;
- while (!(r = in_be32(&p->mr0) & EMAC_MR0_RXI) && n)
+ int n = dev->stop_timeout;
+ while (!(r = in_be32(&p->mr0) & EMAC_MR0_RXI) && n) {
+ udelay(1);
--n;
+ }
if (unlikely(!n))
emac_report_timeout_error(dev,
"RX disable timeout");
@@ -273,10 +285,12 @@ static void emac_rx_disable(struct ocp_e
r = in_be32(&p->mr0);
if (r & EMAC_MR0_RXE) {
- int n = 300;
+ int n = dev->stop_timeout;
out_be32(&p->mr0, r & ~EMAC_MR0_RXE);
- while (!(in_be32(&p->mr0) & EMAC_MR0_RXI) && n)
+ while (!(in_be32(&p->mr0) & EMAC_MR0_RXI) && n) {
+ udelay(1);
--n;
+ }
if (unlikely(!n))
emac_report_timeout_error(dev, "RX disable timeout");
}
@@ -395,6 +409,7 @@ static int emac_configure(struct ocp_ene
r = EMAC_MR1_BASE(emac_opb_mhz()) | EMAC_MR1_VLE | EMAC_MR1_IST;
if (dev->phy.duplex == DUPLEX_FULL)
r |= EMAC_MR1_FDE;
+ dev->stop_timeout = STOP_TIMEOUT_10;
switch (dev->phy.speed) {
case SPEED_1000:
if (emac_phy_gpcs(dev->phy.mode)) {
@@ -409,12 +424,16 @@ static int emac_configure(struct ocp_ene
r |= EMAC_MR1_MF_1000;
r |= EMAC_MR1_RFS_16K;
gige = 1;
-
- if (dev->ndev->mtu > ETH_DATA_LEN)
+
+ if (dev->ndev->mtu > ETH_DATA_LEN) {
r |= EMAC_MR1_JPSM;
+ dev->stop_timeout = STOP_TIMEOUT_1000_JUMBO;
+ } else
+ dev->stop_timeout = STOP_TIMEOUT_1000;
break;
case SPEED_100:
r |= EMAC_MR1_MF_100;
+ dev->stop_timeout = STOP_TIMEOUT_100;
/* Fall through */
default:
r |= EMAC_MR1_RFS_4K;
@@ -2048,6 +2067,7 @@ static int __init emac_probe(struct ocp_
dev->phy.duplex = DUPLEX_FULL;
dev->phy.autoneg = AUTONEG_DISABLE;
dev->phy.pause = dev->phy.asym_pause = 0;
+ dev->stop_timeout = STOP_TIMEOUT_100;
init_timer(&dev->link_timer);
dev->link_timer.function = emac_link_timer;
dev->link_timer.data = (unsigned long)dev;
diff --git a/drivers/net/ibm_emac/ibm_emac_core.h b/drivers/net/ibm_emac/ibm_emac_core.h
index e9b44d0..911abba 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.h
+++ b/drivers/net/ibm_emac/ibm_emac_core.h
@@ -189,6 +189,8 @@ struct ocp_enet_private {
struct timer_list link_timer;
int reset_failed;
+ int stop_timeout; /* in us */
+
struct ibm_emac_error_stats estats;
struct net_device_stats nstats;
^ permalink raw reply related
* ipw2200 in 2.6.15-rc2-git4 warns about improper NETDEV_TX_BUSY retcode
From: Alessandro Suardi @ 2005-11-24 23:38 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: netdev
Dell Latitude D610, FC4 base distro, kernel is:
[asuardi@sandman ~]$ cat /proc/version
Linux version 2.6.15-rc2-git4 (asuardi@sandman) (gcc version 4.0.1
20050727 (Red Hat 4.0.1-5)) #2 Fri Nov 25 00:15:46 CET 2005
Onboard wireless card as detected by kernel is:
ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8
and I placed the 2.4 firmware from sourceforge.net in /lib/firmware.
ifup eth1 yields this message:
eth1: NETDEV_TX_BUSY returned; driver should report queue full via
ieee_device->is_queue_full.
I'm connected to my wireless DSL router while typing this mail
so it obviously isn't fatal...
Thanks,
--alessandro
"So much can happen by accident
No rhyme, no reason - no one's innocent"
(Steve Wynn - "Under The Weather")
^ permalink raw reply
* Re: ipw2200 in 2.6.15-rc2-git4 warns about improper NETDEV_TX_BUSY retcode
From: Zhu Yi @ 2005-11-25 3:23 UTC (permalink / raw)
To: Alessandro Suardi; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <5a4c581d0511241538s496adee9s249cd038501545c9@mail.gmail.com>
On Fri, 2005-11-25 at 00:38 +0100, Alessandro Suardi wrote:
> Dell Latitude D610, FC4 base distro, kernel is:
>
> [asuardi@sandman ~]$ cat /proc/version
> Linux version 2.6.15-rc2-git4 (asuardi@sandman) (gcc version 4.0.1
> 20050727 (Red Hat 4.0.1-5)) #2 Fri Nov 25 00:15:46 CET 2005
>
> Onboard wireless card as detected by kernel is:
> ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8
>
> and I placed the 2.4 firmware from sourceforge.net in /lib/firmware.
>
> ifup eth1 yields this message:
>
> eth1: NETDEV_TX_BUSY returned; driver should report queue full via
> ieee_device->is_queue_full.
Please use the patch here. It will be push to upstream very soon.
http://bughost.org/bugzilla/show_bug.cgi?id=808
Thanks,
-yi
^ permalink raw reply
* Re: ipw2200 in 2.6.15-rc2-git4 warns about improper NETDEV_TX_BUSY retcode
From: Alessandro Suardi @ 2005-11-25 10:59 UTC (permalink / raw)
To: Zhu Yi; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <1132889013.24413.5.camel@debian.sh.intel.com>
On 11/25/05, Zhu Yi <yi.zhu@intel.com> wrote:
> On Fri, 2005-11-25 at 00:38 +0100, Alessandro Suardi wrote:
> > Dell Latitude D610, FC4 base distro, kernel is:
> >
> > [asuardi@sandman ~]$ cat /proc/version
> > Linux version 2.6.15-rc2-git4 (asuardi@sandman) (gcc version 4.0.1
> > 20050727 (Red Hat 4.0.1-5)) #2 Fri Nov 25 00:15:46 CET 2005
> >
> > Onboard wireless card as detected by kernel is:
> > ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8
> >
> > and I placed the 2.4 firmware from sourceforge.net in /lib/firmware.
> >
> > ifup eth1 yields this message:
> >
> > eth1: NETDEV_TX_BUSY returned; driver should report queue full via
> > ieee_device->is_queue_full.
>
> Please use the patch here. It will be push to upstream very soon.
> http://bughost.org/bugzilla/show_bug.cgi?id=808
The offsets of the patch are off by several hundred lines,
however the patch itself works fine. Thanks !
--alessandro
"So much can happen by accident
No rhyme, no reason - no one's innocent"
(Steve Wynn - "Under The Weather")
^ permalink raw reply
* [PATCH] netfilter : zap get_cpu()/put_cpu() calls from ip_tables
From: Eric Dumazet @ 2005-11-25 11:23 UTC (permalink / raw)
To: David S. Miller, Harald Welte, kaber
Cc: Andrew Morton, netdev, netfilter-devel
In-Reply-To: <4331CFA7.50104@cosmosbay.com>
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
The 'ip_tables: NUMA-aware allocation' patch
(http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.16.git;a=commit;h=6d1273850cac8db77c462caaa145b813d93adc55)
introduced a problem with get_cpu()/put_cpu()
The problem is that get_cpu() disables preemption and the thread is not
allowed to sleep.
As the intent was only to give a hint, relax the enforcement and switch to a
hint : If the current thread is preempted and migrated to another cpu, this is
not a problem. Most of the time, thread wont be migrated anyway.
This patch removes get_cpu()/put_cpu() pairs and uses raw_smp_processor_id()
were appropriate.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: zap_getput_cpu.patch --]
[-- Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH (resent with the attachment !)] netfilter : zap get_cpu()/put_cpu() calls from ip_tables
From: Eric Dumazet @ 2005-11-25 11:28 UTC (permalink / raw)
To: David S. Miller, Harald Welte, kaber, Andrew Morton
Cc: netdev, netfilter-devel
In-Reply-To: <4386F440.5020505@cosmosbay.com>
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
The 'ip_tables: NUMA-aware allocation' patch
(http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.16.git;a=commit;h=6d1273850cac8db77c462caaa145b813d93adc55)
introduced a problem with get_cpu()/put_cpu()
The problem is that get_cpu() disables preemption and the thread is not
allowed to sleep.
As the intent was only to give a hint, relax the enforcement and switch to a
hint : If the current thread is preempted and migrated to another cpu, this is
not a problem. Most of the time, thread wont be migrated anyway.
This patch removes get_cpu()/put_cpu() pairs and uses raw_smp_processor_id()
were appropriate.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: zap_getput_cpu.patch --]
[-- Type: text/plain, Size: 9865 bytes --]
--- net-2.6.16-orig/net/ipv4/netfilter/ip_tables.c 2005-11-25 10:24:02.000000000 +0100
+++ net-2.6.16/net/ipv4/netfilter/ip_tables.c 2005-11-25 11:44:40.000000000 +0100
@@ -988,11 +988,14 @@
{
unsigned int cpu;
unsigned int i;
- unsigned int curcpu = get_cpu();
+ unsigned int curcpu;
/* Instead of clearing (by a previous call to memset())
* the counters and using adds, we set the counters
- * with data used by current CPU */
+ * with data used by 'current' CPU
+ * We dont care about preemption here.
+ */
+ curcpu = raw_smp_processor_id();
i = 0;
IPT_ENTRY_ITERATE(t->entries[curcpu],
@@ -1011,7 +1014,6 @@
counters,
&i);
}
- put_cpu();
}
static int
@@ -1029,7 +1031,7 @@
(other than comefrom, which userspace doesn't care
about). */
countersize = sizeof(struct ipt_counters) * table->private->number;
- counters = vmalloc(countersize);
+ counters = vmalloc_node(countersize, numa_node_id());
if (counters == NULL)
return -ENOMEM;
@@ -1039,8 +1041,11 @@
get_counters(table->private, counters);
write_unlock_bh(&table->lock);
- /* choose the copy that is on our node/cpu, ... */
- loc_cpu_entry = table->private->entries[get_cpu()];
+ /* choose the copy that is on our node/cpu, ...
+ * This choice is lazy (because current thread is
+ * allowed to migrate to another cpu)
+ */
+ loc_cpu_entry = table->private->entries[raw_smp_processor_id()];
/* ... then copy entire thing ... */
if (copy_to_user(userptr, loc_cpu_entry, total_size) != 0) {
ret = -EFAULT;
@@ -1091,7 +1096,6 @@
}
free_counters:
- put_cpu();
vfree(counters);
return ret;
}
@@ -1189,7 +1193,7 @@
return -ENOMEM;
/* choose the copy that is our node/cpu */
- loc_cpu_entry = newinfo->entries[get_cpu()];
+ loc_cpu_entry = newinfo->entries[raw_smp_processor_id()];
if (copy_from_user(loc_cpu_entry, user + sizeof(tmp),
tmp.size) != 0) {
ret = -EFAULT;
@@ -1242,9 +1246,8 @@
/* Get the old counters. */
get_counters(oldinfo, counters);
/* Decrease module usage counts and free resource */
- loc_cpu_old_entry = oldinfo->entries[smp_processor_id()];
+ loc_cpu_old_entry = oldinfo->entries[raw_smp_processor_id()];
IPT_ENTRY_ITERATE(loc_cpu_old_entry, oldinfo->size, cleanup_entry,NULL);
- put_cpu();
free_table_info(oldinfo);
if (copy_to_user(tmp.counters, counters,
sizeof(struct ipt_counters) * tmp.num_counters) != 0)
@@ -1261,7 +1264,6 @@
free_newinfo_counters:
vfree(counters);
free_newinfo:
- put_cpu();
free_table_info(newinfo);
return ret;
}
@@ -1303,7 +1305,7 @@
if (len != sizeof(tmp) + tmp.num_counters*sizeof(struct ipt_counters))
return -EINVAL;
- paddc = vmalloc(len);
+ paddc = vmalloc_node(len, numa_node_id());
if (!paddc)
return -ENOMEM;
@@ -1326,7 +1328,7 @@
i = 0;
/* Choose the copy that is on our node */
- loc_cpu_entry = t->private->entries[smp_processor_id()];
+ loc_cpu_entry = t->private->entries[raw_smp_processor_id()];
IPT_ENTRY_ITERATE(loc_cpu_entry,
t->private->size,
add_counter_to_entry,
@@ -1525,8 +1527,10 @@
if (!newinfo)
return -ENOMEM;
- /* choose the copy on our node/cpu */
- loc_cpu_entry = newinfo->entries[get_cpu()];
+ /* choose the copy on our node/cpu
+ * but dont care of preemption
+ */
+ loc_cpu_entry = newinfo->entries[raw_smp_processor_id()];
memcpy(loc_cpu_entry, repl->entries, repl->size);
ret = translate_table(table->name, table->valid_hooks,
@@ -1534,7 +1538,6 @@
repl->num_entries,
repl->hook_entry,
repl->underflow);
- put_cpu();
if (ret != 0) {
free_table_info(newinfo);
return ret;
@@ -1584,10 +1587,9 @@
up(&ipt_mutex);
/* Decrease module usage counts and free resources */
- loc_cpu_entry = table->private->entries[get_cpu()];
+ loc_cpu_entry = table->private->entries[raw_smp_processor_id()];
IPT_ENTRY_ITERATE(loc_cpu_entry, table->private->size,
cleanup_entry, NULL);
- put_cpu();
free_table_info(table->private);
}
--- net-2.6.16-orig/net/ipv6/netfilter/ip6_tables.c 2005-11-25 10:24:02.000000000 +0100
+++ net-2.6.16/net/ipv6/netfilter/ip6_tables.c 2005-11-25 11:23:03.000000000 +0100
@@ -1074,11 +1074,14 @@
{
unsigned int cpu;
unsigned int i;
- unsigned int curcpu = get_cpu();
+ unsigned int curcpu;
/* Instead of clearing (by a previous call to memset())
* the counters and using adds, we set the counters
- * with data used by current CPU */
+ * with data used by 'current' CPU
+ * We dont care about preemption here.
+ */
+ curcpu = raw_smp_processor_id();
i = 0;
IP6T_ENTRY_ITERATE(t->entries[curcpu],
@@ -1097,7 +1100,6 @@
counters,
&i);
}
- put_cpu();
}
static int
@@ -1126,7 +1128,7 @@
write_unlock_bh(&table->lock);
/* choose the copy that is on ourc node/cpu */
- loc_cpu_entry = table->private->entries[get_cpu()];
+ loc_cpu_entry = table->private->entries[raw_smp_processor_id()];
if (copy_to_user(userptr, loc_cpu_entry, total_size) != 0) {
ret = -EFAULT;
goto free_counters;
@@ -1176,7 +1178,6 @@
}
free_counters:
- put_cpu();
vfree(counters);
return ret;
}
@@ -1271,7 +1272,7 @@
return -ENOMEM;
/* choose the copy that is on our node/cpu */
- loc_cpu_entry = newinfo->entries[get_cpu()];
+ loc_cpu_entry = newinfo->entries[raw_smp_processor_id()];
if (copy_from_user(loc_cpu_entry, user + sizeof(tmp),
tmp.size) != 0) {
ret = -EFAULT;
@@ -1324,9 +1325,8 @@
/* Get the old counters. */
get_counters(oldinfo, counters);
/* Decrease module usage counts and free resource */
- loc_cpu_old_entry = oldinfo->entries[smp_processor_id()];
+ loc_cpu_old_entry = oldinfo->entries[raw_smp_processor_id()];
IP6T_ENTRY_ITERATE(loc_cpu_old_entry, oldinfo->size, cleanup_entry,NULL);
- put_cpu();
free_table_info(oldinfo);
if (copy_to_user(tmp.counters, counters,
sizeof(struct ip6t_counters) * tmp.num_counters) != 0)
@@ -1343,7 +1343,6 @@
free_newinfo_counters:
vfree(counters);
free_newinfo:
- put_cpu();
free_table_info(newinfo);
return ret;
}
@@ -1609,7 +1608,7 @@
return -ENOMEM;
/* choose the copy on our node/cpu */
- loc_cpu_entry = newinfo->entries[get_cpu()];
+ loc_cpu_entry = newinfo->entries[raw_smp_processor_id()];
memcpy(loc_cpu_entry, repl->entries, repl->size);
ret = translate_table(table->name, table->valid_hooks,
@@ -1617,7 +1616,6 @@
repl->num_entries,
repl->hook_entry,
repl->underflow);
- put_cpu();
if (ret != 0) {
free_table_info(newinfo);
return ret;
@@ -1667,10 +1665,9 @@
up(&ip6t_mutex);
/* Decrease module usage counts and free resources */
- loc_cpu_entry = table->private->entries[get_cpu()];
+ loc_cpu_entry = table->private->entries[raw_smp_processor_id()];
IP6T_ENTRY_ITERATE(loc_cpu_entry, table->private->size,
cleanup_entry, NULL);
- put_cpu();
free_table_info(table->private);
}
--- net-2.6.16-orig/net/ipv4/netfilter/arp_tables.c 2005-11-25 10:24:02.000000000 +0100
+++ net-2.6.16/net/ipv4/netfilter/arp_tables.c 2005-11-25 11:15:50.000000000 +0100
@@ -814,11 +814,14 @@
{
unsigned int cpu;
unsigned int i;
- unsigned int curcpu = get_cpu();
+ unsigned int curcpu;
/* Instead of clearing (by a previous call to memset())
* the counters and using adds, we set the counters
- * with data used by current CPU */
+ * with data used by 'current' CPU
+ * We dont care about preemption here.
+ */
+ curcpu = raw_smp_processor_id();
i = 0;
ARPT_ENTRY_ITERATE(t->entries[curcpu],
@@ -837,7 +840,6 @@
counters,
&i);
}
- put_cpu();
}
static int copy_entries_to_user(unsigned int total_size,
@@ -865,7 +867,7 @@
get_counters(table->private, counters);
write_unlock_bh(&table->lock);
- loc_cpu_entry = table->private->entries[get_cpu()];
+ loc_cpu_entry = table->private->entries[raw_smp_processor_id()];
/* ... then copy entire thing ... */
if (copy_to_user(userptr, loc_cpu_entry, total_size) != 0) {
ret = -EFAULT;
@@ -898,7 +900,6 @@
}
free_counters:
- put_cpu();
vfree(counters);
return ret;
}
@@ -996,7 +997,7 @@
return -ENOMEM;
/* choose the copy that is on our node/cpu */
- loc_cpu_entry = newinfo->entries[get_cpu()];
+ loc_cpu_entry = newinfo->entries[raw_smp_processor_id()];
if (copy_from_user(loc_cpu_entry, user + sizeof(tmp),
tmp.size) != 0) {
ret = -EFAULT;
@@ -1049,9 +1050,9 @@
/* Get the old counters. */
get_counters(oldinfo, counters);
/* Decrease module usage counts and free resource */
- loc_cpu_old_entry = oldinfo->entries[smp_processor_id()];
+ loc_cpu_old_entry = oldinfo->entries[raw_smp_processor_id()];
ARPT_ENTRY_ITERATE(loc_cpu_old_entry, oldinfo->size, cleanup_entry,NULL);
- put_cpu();
+
free_table_info(oldinfo);
if (copy_to_user(tmp.counters, counters,
sizeof(struct arpt_counters) * tmp.num_counters) != 0)
@@ -1068,7 +1069,6 @@
free_newinfo_counters:
vfree(counters);
free_newinfo:
- put_cpu();
free_table_info(newinfo);
return ret;
}
@@ -1295,7 +1295,7 @@
}
/* choose the copy on our node/cpu */
- loc_cpu_entry = newinfo->entries[get_cpu()];
+ loc_cpu_entry = newinfo->entries[raw_smp_processor_id()];
memcpy(loc_cpu_entry, repl->entries, repl->size);
ret = translate_table(table->name, table->valid_hooks,
@@ -1303,7 +1303,6 @@
repl->num_entries,
repl->hook_entry,
repl->underflow);
- put_cpu();
duprintf("arpt_register_table: translate table gives %d\n", ret);
if (ret != 0) {
free_table_info(newinfo);
@@ -1354,10 +1353,9 @@
up(&arpt_mutex);
/* Decrease module usage counts and free resources */
- loc_cpu_entry = table->private->entries[get_cpu()];
+ loc_cpu_entry = table->private->entries[raw_smp_processor_id()];
ARPT_ENTRY_ITERATE(loc_cpu_entry, table->private->size,
cleanup_entry, NULL);
- put_cpu();
free_table_info(table->private);
}
^ permalink raw reply
* Re: ipw2200 in 2.6.15-rc2-git4 warns about improper NETDEV_TX_BUSY retcode
From: Kasper Sandberg @ 2005-11-25 13:17 UTC (permalink / raw)
To: Alessandro Suardi; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <5a4c581d0511241538s496adee9s249cd038501545c9@mail.gmail.com>
mine does something different, it keep saying something about firmware
error, and that it restarts, however it holds the connection fine.
On Fri, 2005-11-25 at 00:38 +0100, Alessandro Suardi wrote:
> Dell Latitude D610, FC4 base distro, kernel is:
>
> [asuardi@sandman ~]$ cat /proc/version
> Linux version 2.6.15-rc2-git4 (asuardi@sandman) (gcc version 4.0.1
> 20050727 (Red Hat 4.0.1-5)) #2 Fri Nov 25 00:15:46 CET 2005
>
> Onboard wireless card as detected by kernel is:
> ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8
>
> and I placed the 2.4 firmware from sourceforge.net in /lib/firmware.
>
> ifup eth1 yields this message:
>
> eth1: NETDEV_TX_BUSY returned; driver should report queue full via
> ieee_device->is_queue_full.
>
>
> I'm connected to my wireless DSL router while typing this mail
> so it obviously isn't fatal...
>
>
> Thanks,
>
> --alessandro
>
> "So much can happen by accident
> No rhyme, no reason - no one's innocent"
>
> (Steve Wynn - "Under The Weather")
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: ipw2200 in 2.6.15-rc2-git4 warns about improper NETDEV_TX_BUSY retcode
From: Alejandro Bonilla Beeche @ 2005-11-25 16:33 UTC (permalink / raw)
To: Alessandro Suardi
Cc: Linux Kernel Mailing List, netdev, James Ketrenos, yi.zhu
In-Reply-To: <5a4c581d0511241538s496adee9s249cd038501545c9@mail.gmail.com>
Alessandro Suardi wrote:
>Dell Latitude D610, FC4 base distro, kernel is:
>
>[asuardi@sandman ~]$ cat /proc/version
>Linux version 2.6.15-rc2-git4 (asuardi@sandman) (gcc version 4.0.1
>20050727 (Red Hat 4.0.1-5)) #2 Fri Nov 25 00:15:46 CET 2005
>
>Onboard wireless card as detected by kernel is:
>ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8
>
> and I placed the 2.4 firmware from sourceforge.net in /lib/firmware.
>
>ifup eth1 yields this message:
>
>eth1: NETDEV_TX_BUSY returned; driver should report queue full via
>ieee_device->is_queue_full.
>
>
There is bug 808 at bughost.org for the IPW2200 project.
I have asked the patch to be merged but I dunno why it hasn't been
pushed up.
.Alejandro
>
>I'm connected to my wireless DSL router while typing this mail
> so it obviously isn't fatal...
>
>
>Thanks,
>
>--alessandro
>
>
^ permalink raw reply
* Re: [PATCH (resent with the attachment !)] netfilter : zap get_cpu()/put_cpu() calls from ip_tables
From: Patrick McHardy @ 2005-11-25 18:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: Harald Welte, Andrew Morton, netfilter-devel, David S. Miller,
netdev
In-Reply-To: <4386F56F.7020205@cosmosbay.com>
Eric Dumazet wrote:
> The 'ip_tables: NUMA-aware allocation' patch
> (http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.16.git;a=commit;h=6d1273850cac8db77c462caaa145b813d93adc55)
>
> introduced a problem with get_cpu()/put_cpu()
>
> The problem is that get_cpu() disables preemption and the thread is not
> allowed to sleep.
>
> As the intent was only to give a hint, relax the enforcement and switch
> to a hint : If the current thread is preempted and migrated to another
> cpu, this is not a problem. Most of the time, thread wont be migrated
> anyway.
>
> This patch removes get_cpu()/put_cpu() pairs and uses
> raw_smp_processor_id() were appropriate.
Looks good, thanks. I'm going to test it and pass it on to Dave if it
works.
^ permalink raw reply
* Re: Mouse issues in -mm
From: Dmitry Torokhov @ 2005-11-25 22:31 UTC (permalink / raw)
To: Frank Sorenson
Cc: Andrew Morton, Marc Koschewski, linux-kernel, Harald Welte,
netdev
In-Reply-To: <43855A50.80808@tuxrocks.com>
On Thursday 24 November 2005 01:14, Frank Sorenson wrote:
> Note: I believe this issue may also be related to the mouse protocol
> extension. I typically run with 'psmouse.proto=exps' on the kernel
> command line, and the psmouse resync patch seems to break tapping in
> that mode.
So the resync patch - is it only tapping that is broken or you also
loosing the touchpad completely?
> However, booting without proto=exps seems to continue to
> work, even with the resync patch (though the touchpad is unusably
> sensitive--hence the use of exps in the first place).
Without the parameter your touchpad is using native ALPS protocol and
resync is disabled for it. You may have better liuck with toucpad
sensitivity using synaptics X driver.
--
Dmitry
^ permalink raw reply
* VIA "Velocity" test report - VLAN reception not working
From: linux @ 2005-11-26 0:40 UTC (permalink / raw)
To: alan; +Cc: linux, netdev
Okay this is a little late for your May '04 test request, but
I just got one of these (Zyxel GN670-T brand) to upgrade a server.
(PII+440BX motherboard, getting a bit dated, but working very reliably)
0000:00:09.0 0200: 1106:3119 (rev 11)
Subsystem: 187e:3302
Flags: bus master, 66MHz, medium devsel, latency 48, IRQ 9
I/O ports at d000 [size=256]
Memory at e1800000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
ethtool output:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: Not reported
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: puag
Wake-on: g
Current message level: 0x00000002 (2)
Link detected: no
Kernel 2.6.15-rc2, monolithic. Only local patch is PPSkit-lite, which
really shouldn't have any effect. No idea about that "Link detected: no"
line; I'm ssh- ed in over it right now.
Anyway, I can send and receive untagged packets just fine, but I can't
seem to receive tagged packets. A Tulip-based 100baseT card plugged
into another port on the same switch gets everything. (I also swapped
ports to confirm.)
I saw a bunch of VLAN filtering stuff in the driver that I didn't
really follow, so perhaps the problem's there.
(I confess I didn't choose super-carefully. It was advertised as having
Linux support and VLAN support and was reasonably cheap. I didn't
actually know the chipset until it arrived. And yes, I *am* asking the
vendor for support, but I expect that'll take a while.)
Here are some simultaneous TCPdumps of the two cards both
plugged into tagged ports (vlan 2 only) on the same switch.
First, the Velocity card:
18:47:43.612697 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0101 080a 00ad
18:47:45.615858 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0101 080a 00ad
18:47:47.615340 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0101 080a 015e
18:47:49.615663 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0000 0000 0000
18:47:51.619371 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0101 080a 015d
18:47:53.621815 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0101 080a 015e
18:47:55.623634 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0101 080a 015e
Then, the Tulip card:
18:47:44.253702 vlan 2, p 0, IP 192.35.100.29.45877 > 192.35.100.1.53: 26928+ A? home25.netscape.com.horizon.com. (49)
0x0000: 0002 0800 4500 004d 0daa 4000 ff11 2590
0x0010: c023 641d c023 6401 b335 0035 0039 9b66
0x0020: 6930 0100 0001 0000 0000 0000 0668 6f6d
0x0030: 6532 3508 6e65 7473 6361 7065 0363 6f6d
0x0040: 0768 6f72 697a 6f6e 0363 6f6d 0000 0100
0x0050: 01
18:47:44.264620 vlan 2, p 0, IP 192.35.100.29.45878 > 192.35.100.1.53: 21460+ A? loghost.horizon.com. (37)
0x0000: 0002 0800 4500 0041 0dab 4000 ff11 259b
0x0010: c023 641d c023 6401 b336 0035 002d 97a2
0x0020: 53d4 0100 0001 0000 0000 0000 076c 6f67
0x0030: 686f 7374 0768 6f72 697a 6f6e 0363 6f6d
0x0040: 0000 0100 01
18:47:44.418660 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:44.462252 vlan 2, p 0, IP 192.35.100.23.36769 > 192.35.100.1.53: 4757+ A? inc.horizon.com. (33)
0x0000: 0002 0800 4500 003d 0f62 4000 ff11 23ee
0x0010: c023 6417 c023 6401 8fa1 0035 0029 dd6f
0x0020: 1295 0100 0001 0000 0000 0000 0369 6e63
0x0030: 0768 6f72 697a 6f6e 0363 6f6d 0000 0100
0x0040: 01
18:47:44.764354 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40257, length 64
0x0000: 0002 0800 4500 0054 9d40 4000 4001 551d
0x0010: c023 6403 c023 6401 0800 0b0d df4e 9d41
0x0020: a0a2 8743 0000 0000 7ea9 0b00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:44.839288 vlan 2, p 0, IP 192.35.100.36.40967 > 192.35.100.1.53: 40979+ A? mirror.csit.fsu.edu. (37)
0x0000: 0002 0800 4500 0041 227d 4000 ff11 10c2
0x0010: c023 6424 c023 6401 a007 0035 002d 73e5
0x0020: a013 0100 0001 0000 0000 0000 066d 6972
0x0030: 726f 7204 6373 6974 0366 7375 0365 6475
0x0040: 0000 0100 01
18:47:45.049258 vlan 2, p 0, arp who-has 192.35.100.139 tell 192.35.100.234
0x0000: 0002 0806 0001 0800 0604 0001 0080 c8b9
0x0010: c1d5 c023 64ea 0000 0000 0000 c023 648b
18:47:45.264333 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40258, length 64
0x0000: 0002 0800 4500 0054 9d41 4000 4001 551c
0x0010: c023 6403 c023 6401 0800 39ad df4e 9d42
0x0020: a1a2 8743 0000 0000 5608 0400 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:45.418585 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:45.628260 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8019 0000
0x0020: 1400 0200 0f00 0000 0101 080a 00ad
18:47:45.780328 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40259, length 64
0x0000: 0002 0800 4500 0054 9d42 4000 4001 551b
0x0010: c023 6403 c023 6401 0800 9bcc df4e 9d43
0x0020: a1a2 8743 0000 0000 ece7 0b00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:46.049345 vlan 2, p 0, arp who-has 192.35.100.139 tell 192.35.100.234
0x0000: 0002 0806 0001 0800 0604 0001 0080 c8b9
0x0010: c1d5 c023 64ea 0000 0000 0000 c023 648b
18:47:46.215070 vlan 2, p 0, IP 192.35.100.39.723 > 192.35.100.1.111: UDP, length 56
0x0000: 0002 0800 4500 0054 7d0a 4000 ff11 b61e
0x0010: c023 6427 c023 6401 02d3 006f 0040 c42e
0x0020: 4385 9ea7 0000 0000 0000 0002 0001 86a0
0x0030: 0000 0002 0000 0003 0000 0000 0000 0000
0x0040: 0000 0000 0000 0000 0001 86a4 0000 0002
0x0050: 0000 0011 0000 0000
18:47:46.280315 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40260, length 64
0x0000: 0002 0800 4500 0054 9d43 4000 4001 551a
0x0010: c023 6403 c023 6401 0800 ca6c df4e 9d44
0x0020: a2a2 8743 0000 0000 c446 0400 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:46.418594 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:46.796311 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40261, length 64
0x0000: 0002 0800 4500 0054 9d44 4000 4001 5519
0x0010: c023 6403 c023 6401 0800 2c8c df4e 9d45
0x0020: a2a2 8743 0000 0000 5a26 0c00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:47.049424 vlan 2, p 0, arp who-has 192.35.100.139 tell 192.35.100.234
0x0000: 0002 0806 0001 0800 0604 0001 0080 c8b9
0x0010: c1d5 c023 64ea 0000 0000 0000 c023 648b
18:47:47.296299 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40262, length 64
0x0000: 0002 0800 4500 0054 9d45 4000 4001 5518
0x0010: c023 6403 c023 6401 0800 5b2c df4e 9d46
0x0020: a3a2 8743 0000 0000 3285 0400 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:47.412369 vlan 2, p 0, IP 192.35.100.23.727 > 192.35.100.1.111: UDP, length 56
0x0000: 0002 0800 4500 0054 0f63 4000 ff11 23d6
0x0010: c023 6417 c023 6401 02d7 006f 0040 e607
0x0020: 4382 7cdd 0000 0000 0000 0002 0001 86a0
0x0030: 0000 0002 0000 0003 0000 0000 0000 0000
0x0040: 0000 0000 0000 0000 0001 86a4 0000 0002
0x0050: 0000 0011 0000 0000
18:47:47.418592 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:47.452763 vlan 2, p 0, IP 192.35.100.23.36770 > 198.69.104.3.53: 10818+ A? xave0. (23)
0x0000: 0002 0800 4500 0033 0911 4000 ff11 2025
0x0010: c023 6417 c645 6803 8fa2 0035 001f 23f3
0x0020: 2a42 0100 0001 0000 0000 0000 0578 6176
0x0030: 6530 0000 0100 01
18:47:47.627380 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8019 0000
0x0020: 1400 0200 0f00 0000 0101 080a 015e
18:47:47.812301 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40263, length 64
0x0000: 0002 0800 4500 0054 9d46 4000 4001 5517
0x0010: c023 6403 c023 6401 0800 bd4b df4e 9d47
0x0020: a3a2 8743 0000 0000 c864 0c00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:48.306211 vlan 2, p 0, arp who-has 192.35.100.1 tell 192.35.100.43
0x0000: 0002 0806 0001 0800 0604 0001 00e0 18cf
0x0010: e42f c023 642b 0000 0000 0000 c023 6401
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:48.306279 vlan 2, p 0, arp reply 192.35.100.1 is-at 00:80:c8:b9:c1:d5
0x0000: 0002 0806 0001 0800 0604 0002 0080 c8b9
0x0010: c1d5 c023 6401 00e0 18cf e42f c023 642b
18:47:48.312271 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40264, length 64
0x0000: 0002 0800 4500 0054 9d47 4000 4001 5516
0x0010: c023 6403 c023 6401 0800 eaeb df4e 9d48
0x0020: a4a2 8743 0000 0000 a1c3 0400 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:48.828276 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40265, length 64
0x0000: 0002 0800 4500 0054 9d48 4000 4001 5515
0x0010: c023 6403 c023 6401 0800 4e0b df4e 9d49
0x0020: a4a2 8743 0000 0000 36a3 0c00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:49.263637 vlan 2, p 0, IP 192.35.100.29.45879 > 192.35.100.1.53: 21460+ A? loghost.horizon.com. (37)
0x0000: 0002 0800 4500 0041 0dac 4000 ff11 259a
0x0010: c023 641d c023 6401 b337 0035 002d 97a1
0x0020: 53d4 0100 0001 0000 0000 0000 076c 6f67
0x0030: 686f 7374 0768 6f72 697a 6f6e 0363 6f6d
0x0040: 0000 0100 01
18:47:49.328257 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40266, length 64
0x0000: 0002 0800 4500 0054 9d49 4000 4001 5514
0x0010: c023 6403 c023 6401 0800 7dab df4e 9d4a
0x0020: a5a2 8743 0000 0000 0d02 0500 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:49.628255 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8019 0000
0x0020: 1400 0200 0f00 0000 0000 0000 0000
18:47:49.829323 vlan 2, p 0, IP 192.35.100.36.40968 > 192.35.100.1.53: 32418+ A? sunfreeware.mirrors.tds.net.horizon.com. (57)
0x0000: 0002 0800 4500 0055 227e 4000 ff11 10ad
0x0010: c023 6424 c023 6401 a008 0035 0041 757e
0x0020: 7ea2 0100 0001 0000 0000 0000 0b73 756e
0x0030: 6672 6565 7761 7265 076d 6972 726f 7273
0x0040: 0374 6473 036e 6574 0768 6f72 697a 6f6e
0x0050: 0363 6f6d 0000 0100 01
18:47:49.844258 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40267, length 64
0x0000: 0002 0800 4500 0054 9d4a 4000 4001 5513
0x0010: c023 6403 c023 6401 0800 deca df4e 9d4b
0x0020: a5a2 8743 0000 0000 a4e1 0c00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:49.994730 vlan 2, p 0, IP 192.35.100.28.41057 > 192.35.100.1.53: 41451+ A? bimini. (24)
0x0000: 0002 0800 4500 0034 758e 4000 ff11 bdc5
0x0010: c023 641c c023 6401 a061 0035 0020 3186
0x0020: a1eb 0100 0001 0000 0000 0000 0662 696d
0x0030: 696e 6900 0001 0001
18:47:50.344249 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40268, length 64
0x0000: 0002 0800 4500 0054 9d4b 4000 4001 5512
0x0010: c023 6403 c023 6401 0800 086b df4e 9d4c
0x0020: a6a2 8743 0000 0000 8140 0500 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:50.463048 vlan 2, p 0, IP 192.35.100.23.36771 > 198.69.104.19.53: 4757+ A? inc.horizon.com. (33)
0x0000: 0002 0800 4500 003d f58a 4000 ff11 3391
0x0010: c023 6417 c645 6813 8fa3 0035 0029 d339
0x0020: 1295 0100 0001 0000 0000 0000 0369 6e63
0x0030: 0768 6f72 697a 6f6e 0363 6f6d 0000 0100
0x0040: 01
18:47:50.860237 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40269, length 64
0x0000: 0002 0800 4500 0054 9d4c 4000 4001 5511
0x0010: c023 6403 c023 6401 0800 6f8a df4e 9d4d
0x0020: a6a2 8743 0000 0000 1220 0d00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:51.138682 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:51.211846 vlan 2, p 0, IP 192.35.100.23.734 > 192.35.100.1.2049: S 3636096760:3636096760(0) win 8760 <mss 1460>
0x0000: 0002 0800 4500 002c 0f64 4000 ff06 2408
0x0010: c023 6417 c023 6401 02de 0801 d8ba 6ef8
0x0020: 0000 0000 6002 2238 dafc 0000 0204 05b4
0x0030: 5555
18:47:51.360222 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40270, length 64
0x0000: 0002 0800 4500 0054 9d4d 4000 4001 5510
0x0010: c023 6403 c023 6401 0800 9e2a df4e 9d4e
0x0020: a7a2 8743 0000 0000 ea7e 0500 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:51.631385 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8019 0000
0x0020: 1400 0200 0f00 0000 0000 0000 0000
18:47:51.876222 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40271, length 64
0x0000: 0002 0800 4500 0054 9d4e 4000 4001 550f
0x0010: c023 6403 c023 6401 0800 014a df4e 9d4f
0x0020: a7a2 8743 0000 0000 7f5e 0d00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:52.138545 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:52.376207 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40272, length 64
0x0000: 0002 0800 4500 0054 9d4f 4000 4001 550e
0x0010: c023 6403 c023 6401 0800 2eea df4e 9d50
0x0020: a8a2 8743 0000 0000 58bd 0500 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:52.449501 vlan 2, p 0, IP 192.35.100.86.933 > 192.35.100.1.2049: S 3199884626:3199884626(0) win 8760 <mss 1460>
0x0000: 0002 0800 4500 002c d816 4000 ff06 5b16
0x0010: c023 6456 c023 6401 03a5 0801 beba 5d52
0x0020: 0000 0000 6002 2238 059d 0000 0204 05b4
0x0030: 5555
18:47:52.829061 vlan 2, p 0, IP 192.35.100.32.265061 > 192.35.100.1.2049: 104 getattr fh Unknown/010000020009000440ED2B00DF7741008B4F2400DA774100724F240000000000
0x0000: 0002 0800 4500 0084 e550 0000 ff11 8daf
0x0010: c023 6420 c023 6401 03fb 0801 0070 0000
0x0020: 0004 0b65 0000 0000 0000 0002 0001 86a3
0x0030: 0000 0002 0000 0001 0000 0001 0000 0020
0x0040: 4387 a2a8 0000 0006 6261 6c72 6f67 0000
0x0050: 0000 0000 0000 0000 0000 0001 0000 0000
0x0060: 0000 0000 0000 0000 0100 0002 0009 0004
0x0070: 40ed 2b00 df77 4100 8b4f 2400 da77 4100
0x0080: 724f 2400 0000 0000
18:47:52.849002 vlan 2, p 0, IP 192.35.100.32.265062 > 192.35.100.1.2049: 132 getattr fh Unknown/010000020009000440ED2B0004261D0055782400AD251D00A676240000000000
0x0000: 0002 0800 4500 00a0 e551 0000 ff11 8d92
0x0010: c023 6420 c023 6401 03fc 0801 008c 0000
0x0020: 0004 0b66 0000 0000 0000 0002 0001 86a3
0x0030: 0000 0002 0000 0001 0000 0001 0000 003c
0x0040: 4387 a2a8 0000 0006 6261 6c72 6f67 5b6d
0x0050: 0000 009e 0000 000b 0000 0008 0000 000b
0x0060: 0000 000a 0000 000c 0000 000e 0000 000f
0x0070: 0000 003c 0000 0014 0000 0018 0000 0000
0x0080: 0000 0000 0100 0002 0009 0004 40ed 2b00
0x0090: 0426 1d00 5578 2400 ad25 1d00 a676 2400
0x00a0: 0000 0000
18:47:52.892204 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40273, length 64
0x0000: 0002 0800 4500 0054 9d50 4000 4001 550d
0x0010: c023 6403 c023 6401 0800 9209 df4e 9d51
0x0020: a8a2 8743 0000 0000 ed9c 0d00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:53.076199 vlan 2, p 0, IP 192.35.100.3.123 > 192.35.100.1.123: NTPv4, Client, length 48
0x0000: 0002 0800 4510 004c 5084 4000 4011 a1c1
0x0010: c023 6403 c023 6401 007b 007b 0038 710f
0x0020: 6302 04ec 0000 000f 0000 050f c023 6401
0x0030: c732 1eb8 166c c1ca 0000 0000 0000 0000
0x0040: 0000 0000 0000 0000 c732 2129 137d fa00
18:47:53.138525 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:53.392190 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40274, length 64
0x0000: 0002 0800 4500 0054 9d51 4000 4001 550c
0x0010: c023 6403 c023 6401 0800 c0a9 df4e 9d52
0x0020: a9a2 8743 0000 0000 c5fb 0500 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:53.452379 vlan 2, p 0, IP 192.35.100.23.36772 > 192.35.100.1.53: 10818+ A? xave0. (23)
0x0000: 0002 0800 4500 0033 0f65 4000 ff11 23f5
0x0010: c023 6417 c023 6401 8fa4 0035 001f 2e15
0x0020: 2a42 0100 0001 0000 0000 0000 0578 6176
0x0030: 6530 0000 0100 01
18:47:53.542795 vlan 2, p 0, IP 192.35.100.30.53148 > 192.35.100.1.661: UDP, length 92
0x0000: 0002 0800 4500 0078 2e79 4000 ff11 0495
0x0010: c023 641e c023 6401 cf9c 0295 0064 f084
0x0020: 4381 bb7b 0000 0000 0000 0002 0001 86a4
0x0030: 0000 0002 0000 0003 0000 0000 0000 0000
0x0040: 0000 0000 0000 0000 0000 000b 686f 7269
0x0050: 7a6f 6e2e 636f 6d00 0000 000d 7061 7373
0x0060: 7764 2e62 796e 616d 6500 0000 0000 000a
0x0070: 7275 6e64 6c32 6265 616d 0000
18:47:53.571691 vlan 2, p 0, IP 192.35.100.30.53149 > 192.35.100.1.111: UDP, length 64
0x0000: 0002 0800 4500 005c 2e7a 4000 ff11 04b0
0x0010: c023 641e c023 6401 cf9d 006f 0048 5c16
0x0020: 4381 549a 0000 0000 0000 0002 0001 86a0
0x0030: 0000 0003 0000 0003 0000 0000 0000 0000
0x0040: 0000 0000 0000 0000 0001 86a4 0000 0002
0x0050: 0000 0003 7564 7000 0000 0000 0000 0000
18:47:53.574510 vlan 2, p 0, IP 192.35.100.30.53150 > 192.35.100.1.661: UDP, length 88
0x0000: 0002 0800 4500 0074 2e7b 4000 ff11 0497
0x0010: c023 641e c023 6401 cf9e 0295 0060 f79d
0x0020: 4381 0cb2 0000 0000 0000 0002 0001 86a4
0x0030: 0000 0002 0000 0003 0000 0000 0000 0000
0x0040: 0000 0000 0000 0000 0000 000b 686f 7269
0x0050: 7a6f 6e2e 636f 6d00 0000 000d 7061 7373
0x0060: 7764 2e62 796e 616d 6500 0000 0000 0008
0x0070: 7365 6e64 6d61 696c
18:47:53.634245 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8019 0000
0x0020: 1400 0200 0f00 0000 0101 080a 00ad
18:47:53.908188 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40275, length 64
0x0000: 0002 0800 4500 0054 9d52 4000 4001 550b
0x0010: c023 6403 c023 6401 0800 21c9 df4e 9d53
0x0020: a9a2 8743 0000 0000 5cdb 0d00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:54.138621 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
Thanks a lot for any suggestions!
^ permalink raw reply
* In Confindence/Shara
From: Kwasha Shara @ 2005-11-26 6:23 UTC (permalink / raw)
To: netdev
Hello dear,
I am Miss Shara Kwasha. It is my desire to contact you on honesty and sincerity to assist me in transferring the sum of $2,350,000 inherited from my father late Mr. Kwasha. I am motivated in contacting you and hope to gradually build trust, relationship and confidence in you as i get to know you better.
So please i want to know if you will be of assistance but first i want to get to know you better. I am willing to offer you $235,000 usd for your effort input after the successful transfer of this money to your account overseas.
Indicate your interest towards assisting me by sending your phone # and address so that i can communicate with you at any time. I will be waiting for your response.
Thanks
Shara
^ permalink raw reply
* [PATCH 2.4] sis900: come alive after temporary memory shortage
From: Vasily Averin @ 2005-11-26 9:23 UTC (permalink / raw)
To: Marcelo Tosatti, linux-kernel
Cc: Konstantin Khorenko, netdev, Daniele Venzano
[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]
Hello Marcelo,
I would like to inform you that unfortunately the committed patch is wrong
http://www.kernel.org/git/?p=linux/kernel/git/marcelo/linux-2.4.git;a=commit;h=ecf3337f76eaa94c5a771308d184dc248b74b725
+ int rx_work_limit =
+ (sis_priv->dirty_rx - sis_priv->cur_rx) % NUM_RX_DESC;
when dirty_rx = cur_rx it computes limit=0, but should be NUM_RX_DESC
Could you please drop the wrong patch and use a new one based on the version
approved by Daniele Venzano and Jeff Garzik
http://www.kernel.org/git/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff_plain;h=7380a78a973a8109c13cb0e47617c456b6f6e1f5;hp=b2795f596932286ef12dc08857960d654f577405
Thank you,
Vasily Averin
SWSoft Linux kernel Team
sis900: come alive after temporary memory shortage
1) Forgotten counter incrementation in sis900_rx() in case
it doesn't get memory for skb, that leads to whole interface failure.
Problem is accompanied with messages:
eth0: Memory squeeze,deferring packet.
eth0: NULL pointer encountered in Rx ring, skipping
2) If counter cur_rx overflows and there'll be temporary memory problems
buffer can't be recreated later, when memory IS available.
3) Limit the work in handler to prevent the endless packets processing
if new packets are generated faster then handled.
Signed-off-by: Konstantin Khorenko <khorenko@sw.ru>
Signed-off-by: Vasily Averin <vvs@sw.ru>
---
[-- Attachment #2: diff-drv-sis900-20051126 --]
[-- Type: text/plain, Size: 1973 bytes --]
--- a/drivers/net/sis900.c 2005-11-26 10:54:33.000000000 +0300
+++ b/drivers/net/sis900.c 2005-11-26 11:30:17.000000000 +0300
@@ -1613,15 +1613,20 @@ static int sis900_rx(struct net_device *
long ioaddr = net_dev->base_addr;
unsigned int entry = sis_priv->cur_rx % NUM_RX_DESC;
u32 rx_status = sis_priv->rx_ring[entry].cmdsts;
+ int rx_work_limit;
if (sis900_debug > 3)
printk(KERN_INFO "sis900_rx, cur_rx:%4.4d, dirty_rx:%4.4d "
"status:0x%8.8x\n",
sis_priv->cur_rx, sis_priv->dirty_rx, rx_status);
+ rx_work_limit = sis_priv->dirty_rx + NUM_RX_DESC - sis_priv->cur_rx;
while (rx_status & OWN) {
unsigned int rx_size;
+ if (--rx_work_limit < 0)
+ break;
+
rx_size = (rx_status & DSIZE) - CRC_SIZE;
if (rx_status & (ABORT|OVERRUN|TOOLONG|RUNT|RXISERR|CRCERR|FAERR)) {
@@ -1648,9 +1653,11 @@ static int sis900_rx(struct net_device *
some unknow bugs, it is possible that
we are working on NULL sk_buff :-( */
if (sis_priv->rx_skbuff[entry] == NULL) {
- printk(KERN_INFO "%s: NULL pointer "
- "encountered in Rx ring, skipping\n",
- net_dev->name);
+ printk(KERN_WARNING "%s: NULL pointer "
+ "encountered in Rx ring\n"
+ "cur_rx:%4.4d, dirty_rx:%4.4d\n",
+ net_dev->name, sis_priv->cur_rx,
+ sis_priv->dirty_rx);
break;
}
@@ -1688,6 +1695,7 @@ static int sis900_rx(struct net_device *
sis_priv->rx_ring[entry].cmdsts = 0;
sis_priv->rx_ring[entry].bufptr = 0;
sis_priv->stats.rx_dropped++;
+ sis_priv->cur_rx++;
break;
}
skb->dev = net_dev;
@@ -1705,7 +1713,7 @@ static int sis900_rx(struct net_device *
/* refill the Rx buffer, what if the rate of refilling is slower than
consuming ?? */
- for (;sis_priv->cur_rx - sis_priv->dirty_rx > 0; sis_priv->dirty_rx++) {
+ for (; sis_priv->cur_rx != sis_priv->dirty_rx; sis_priv->dirty_rx++) {
struct sk_buff *skb;
entry = sis_priv->dirty_rx % NUM_RX_DESC;
^ permalink raw reply
* Re: [PATCH 2.4] sis900: come alive after temporary memory shortage
From: Marcelo Tosatti @ 2005-11-27 8:35 UTC (permalink / raw)
To: Vasily Averin; +Cc: linux-kernel, Konstantin Khorenko, netdev, Daniele Venzano
In-Reply-To: <438829AF.8060101@sw.ru>
On Sat, Nov 26, 2005 at 12:23:59PM +0300, Vasily Averin wrote:
> Hello Marcelo,
>
> I would like to inform you that unfortunately the committed patch is wrong
> http://www.kernel.org/git/?p=linux/kernel/git/marcelo/linux-2.4.git;a=commit;h=ecf3337f76eaa94c5a771308d184dc248b74b725
>
> + int rx_work_limit =
> + (sis_priv->dirty_rx - sis_priv->cur_rx) % NUM_RX_DESC;
>
> when dirty_rx = cur_rx it computes limit=0, but should be NUM_RX_DESC
>
> Could you please drop the wrong patch and use a new one based on the version
> approved by Daniele Venzano and Jeff Garzik
> http://www.kernel.org/git/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff_plain;h=7380a78a973a8109c13cb0e47617c456b6f6e1f5;hp=b2795f596932286ef12dc08857960d654f577405
Will do - thanks Vasily.
^ 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