Stephen Hemminger wrote:
> On Tue, 29 Jan 2008 03:46:08 +0300
> Michael Tokarev <[EMAIL PROTECTED]> wrote:
[]
>> There are 2 drivers for 8139-based NICs. For really different two kinds
>> of hardware, which both uses the same PCI identifiers. Both drivers
>> "
Frederik Himpe wrote:
> Linux 2.6.24 kernel gives the following messages when udev coldplugging
> loads the driver for my NIC:
>
> 8139too :00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip
> 8139too :00:0b.0: Use the "8139cp" driver for improved performance and
> stability.
Herbert Xu wrote:
> On Tue, Jan 23, 2007 at 02:10:39PM +0300, Michael Tokarev wrote:
>> Well, but why getsockname() didn't just return ENOTCONN?
>
> It's perfectly valid to have a local port number without being connected.
Er. You're right - I was confusing
Herbert Xu wrote:
> dean gaudet <[EMAIL PROTECTED]> wrote:
>> in the test program below the getsockname result on a TCP socket changes
>> across a write which produces EPIPE... here's a fragment of the strace:
>>
>> getsockname(3, {sa_family=AF_INET, sin_port=htons(37636),
>> sin_addr=inet_addr("
Jarek Poplawski wrote:
> On Fri, Jan 19, 2007 at 03:08:20PM +0100, Jarek Poplawski wrote:
> ...
>> You are welcome! But you probably didn't read this with
>> attention: if it works, you should thank mainly to that
>> other guy...
>>
>> Btw. I can't remember I've seen such ferocious testing
>> ever!
Patrick McHardy wrote:
> Jarek Poplawski wrote:
>> Here is my patch proposal. If I'm not totally wrong,
>> there is a possibility that, during collapsing, empty
>> skb with FIN is added to "normal" packet and changes
>> its ip_summed field to CHECKSUM_NONE.
>>
>> diff -Nurp linux-2.6.19-/net/ipv4/t
Jarek Poplawski wrote:
> On 17-01-2007 15:12, Michael Tokarev wrote:
[]
>> Here's another sample, which may be more useful. I've seen quite
>> alot of very similar stuff while running tcpdump.
>>
>> http://www.corpit.ru/mjt/bad-cksum-session3-dmp.bin
>&g
Herbert Xu wrote:
> On Tue, Jan 16, 2007 at 11:08:51AM +0300, Michael Tokarev wrote:
>> Ok. Here's another trace, from that remote network that triggers
>> this thing more-or-less reliable (every 2nd transfer at least) --
>> http://www.corpit.ru/mjt/bh-bad-cksum-dmp
Patrick McHardy wrote:
> Herbert Xu wrote:
[]
>> Since you're certain that this is being seen on the wire, one
>> possibility is that we've got a bug somewhere that's zeroing
>> skb->ip_summed on a packet with a partial checksum.
>>
>> One potential spot where this could happen is netfilter.
>> Pat
Herbert Xu wrote:
> On Tue, Jan 16, 2007 at 02:27:39PM +1100, Herbert Xu wrote:
>> I'm sorry but this dump does NOT look like it was taken from an
>> intermediate box. I verified two bad checksums (chosen randomly)
>> and they were both correct but partial checksums. This means that
>> this dump
Herbert Xu wrote:
> On Mon, Jan 15, 2007 at 04:34:41PM +0300, Michael Tokarev wrote:
[]
>> So I guess the problem is not related to hw checksumming offloading.
>
> Nope, it just means that 8139too doesn't provide ethtool handlers to
> disable checksum offloading.
>
&
Eric Dumazet wrote:
> Michael Tokarev a e'crit :
>>
>> Any idea how to force sending FIN-with-data?
>
> int flag_on = 1;
> setsockopt(fd, SOL_TCP, TCP_CORK, &flag_on, sizeof(int));
> send(fd, data, datalen, 0);
> close(fd);
That produces two packets - one
Michael Tokarev wrote:
[]
> And another thing I noticed. Right now I'm experimenting with another
> machine, running 2.6.17(.13) - it also shows similar behavior with bad
> csums, but MUCH rarer than this 2.6.19. Like this:
>
> 16:29:32.490976 IP (tos 0x60, ttl 48, id 14
Herbert Xu wrote:
> Michael Tokarev <[EMAIL PROTECTED]> wrote:
>> Note there's no funny/interesting hardware involved, like network cards with
>> tcp checksumming offload capabilities (this is plain dumb 8139 card).
>
> The 8139 card might be dumb, but the driver
A long time ago, in kernel-2.4 days, I noticed that
airo module (for various aironet etc cards) can't
handle interface renames (at that time, the kernel
crashed after `ip link set eth1 name xxx' command
and some packets going to/from the interface).
The problem seems to be that the driver uses som
Andrew Morton wrote:
> On Thu, 19 Oct 2006 01:46:47 +0900
> Akinobu Mita <[EMAIL PROTECTED]> wrote:
>
>> Use bitrev8 for bmac, mace, macmace, macsonic, and skfp drivers.
>>
[]
>> ===
>> --- work-fault-inject.orig/drivers/net/Kconfig
>
Rick Jones wrote:
> 2) develop some style
>>> of register description definition type of text file, maybe XML, maybe
>>> INI style or something stored in /etc/ethtool as .conf or
>>> something like that. This way, ethtool doesn't have to be
>>> changed/updated/patched/likely-bug-added for every si
Patrick McHardy wrote:
> --- a/include/linux/rtnetlink.h
> +++ b/include/linux/rtnetlink.h
> +static inline u32 rtm_get_table(struct rtattr **rta, u8 table)
> +{
> + return RTA_GET_U32(rta[RTA_TABLE-1]);
> +rtattr_failure:
> + return table;
> +}
> +
What's that ? ;)
/mjt
-
To unsubscrib
David Miller wrote:
> From: Michael Tokarev <[EMAIL PROTECTED]>
[]
>>> - Use u32 for routing table IDs everywhere inside the kernel
>> Just out of curiocity: why current limit of 2^31 isn't sufficient?
>> Or am I missing the point?
>
> The current lim
Patrick McHardy wrote:
> These are the updated patches (against net-2.6.19) to increase the number
> of possible routing tables to 2^32. They basically consist of four parts:
>
> - Use u32 for routing table IDs everywhere inside the kernel
Just out of curiocity: why current limit of 2^31 isn't su
On Wednesday 09 August 2006 09:53, David Miller wrote:
[]
> - mult = ((u64)ip_rt_gc_interval) << long_log2(hmask + 1);
> + mult = ((u64)(hmask + 1)) << (u64)ip_rt_gc_interval;
Hmm.. shift *by* a 64-bit number?
/mjt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
Albert Lee wrote:
[]
> (I am curious to have some performance comparison of
> qla3xxx + open iscsi v.s. qla4xxx + on board TOE/iscsi.)
On wich card? I've been told that IPS4010 for example
isn't supported by qla3xxx.
BTW, I found qla4xxx (on IPS4010) performs noticeable
worse than open-iscsi sta
Andrew Vasquez wrote:
> On Thu, 20 Jul 2006, Ron Mercer wrote:
>
>> qla3xxx driver does not support ISP4010.
>
> Exactly... The qla3xxx driver supports the NIC function only.
...which is provided by ISP4010 card, as appears on PCI bus:
04:04.0 Ethernet controller: QLogic Corp. QLA3010 Network
By the way, should it work with ISP4010 controllers?
Those "expose" network interface card "subdevice" too,
but aren't listed in pci_device_table of the driver,
and after adding the device ID to the driver, it still
does not quite work (I tried, just out of curiosity) -
the NIC on ISP4010 is - it s
Robert Schulze wrote:
> Hi,
>
> Dan Williams schrieb:
>> This message will only happen if the card hangs up and stops responding
>> to commands anyway, so we don't necessarily care about making the
>> message decipherable to anyone other than developers.
>
> Well, I get this message each time I i
Patrick McHardy wrote:
[]
> He patched his kernel with the IMQ device, which is known to cause all
> kinds of weird problems.
Wich problems? Known to whom?
I was considering using imq for our needs (not done yet), and from the
FAQ at http://www.linuximq.net/faq.html (item #3, "Is it stable?") it
Ingo Oeser wrote:
> Hi Meelis,
>
>> Unfortunatlety, 2.6.15 does not boot on this machine so I'm locked out
>> remotely at the moment.
>
> Here it my paranoid boot setup:
>
> 1. Use "lilo -R new-kernel", to boot a kernel only
> once and reboot the default kernel next time.
>
> 2. Force rebo
Christoph Hellwig wrote:
Currently all network protocols need to call dev_ioctl as the default
fallback in their ioctl implementations. This patch adds a fallback
to dev_ioctl to sock_ioctl if the protocol returned -ENOIOCTLCMD.
This way all the procotol ioctl handlers can be simplified and we d
I'm not sure if this is the right list for such a questions..
But still.
Recently we tried to set up an IPSEC tunnel in a branch office
of a large company, using linux (currently 2.6.14). The endpoint
is running some Cisco PIX device. Everything's fine, using any
userspace tools available, excep
29 matches
Mail list logo
