* Re: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
From: Benjamin Herrenschmidt @ 2011-10-09 7:21 UTC (permalink / raw)
To: Eli Cohen
Cc: Thadeu Lima de Souza Cascardo, Yevgeny Petrilin,
netdev@vger.kernel.org, Eli Cohen, linuxppc-dev
In-Reply-To: <20111005081502.GB2681@mtldesk30>
On Wed, 2011-10-05 at 10:15 +0200, Eli Cohen wrote:
> On Tue, Oct 04, 2011 at 05:26:20PM -0300, Thadeu Lima de Souza Cascardo wrote:
>
> I believe we have an endianess problem here. The source buffer is in
> big endian - in x86 archs, it will rich the pci device unswapped since
> both x86 and pci are little endian. In ppc, it wil be swapped by the
> chipset
^^^^^^^ ugh ?
> so it will reach the device in little endian which is wrong.
> So, in mlx4_bf_copy, you could loop over the buffer and swap32 the all
> the dwords before the call to __iowrite64_copy. Of course which should
> fix this in an arch independent manner. Let me know this works for
> you.
That's generally the wrong way to handle endian (to swap32 a whole
buffer).
But I need to know more about the structure of those descriptors etc...
to judge properly.
Cheers,
Ben.
> > On Tue, Oct 04, 2011 at 08:02:12AM +0200, Benjamin Herrenschmidt wrote:
> > > On Mon, 2011-10-03 at 17:53 -0300, Thadeu Lima de Souza Cascardo wrote:
> > >
> > > .../...
> > >
> > > > > Can you also send me the output of ethtool -i?
> > > > > It seems that there is a problem with write combining on Power processors, we will check this issue.
> > > > >
> > > > > Yevgeny
> > > >
> > > > Hello, Yevgeny.
> > > >
> > > > You will find the output of ethtool -i below.
> > > >
> > > > I am copying Ben and powerpc list, in case this is an issue with Power
> > > > processors. They can provide us some more insight into this.
> > >
> > > May I get some background please ? :-)
> > >
> > > I'm not aware of a specific issue with write combining but I'd need to
> > > know more about what you are doing and the code to do it to comment on
> > > whether it should work or not.
> > >
> > > Cheers,
> > > Ben.
> > >
> > >
> >
> > Hello, Ben.
> >
> > Sorry for that. I am testing mlx4_en driver on a POWER. Yevgeny has
> > added blue frame support, that does not require writing to the device
> > memory to indicate a new packet (the doorbell register as it is called).
> >
> > Well, the ring is getting full with no interrupt or packets transmitted.
> > I simply added a write to the doorbell register and it works for me.
> > Yevgeny says this is not the right fix, claiming there is a problem with
> > write combining on POWER. The code uses memory barriers, so I don't know
> > why there is any problem.
> >
> > I am posting the code here to show better what the situation is.
> > Yevgeny can tell more about the device and the driver.
> >
> > The code below is the driver as of now, including a diff with what I
> > changed and had resulted OK for me. Before the blue frame support, the
> > only code executed was the else part. I can't tell much what the device
> > should be seeing and doing after the blue frame part of the code is
> > executed. But it does send the packet if I write to the doorbell
> > register.
> >
> > Yevgeny, can you tell us what the device should be doing and why you
> > think this is a problem on POWER? Is it possible that this is simply a
> > problem with the firmware version?
> >
> > Thanks,
> > Cascardo.
> >
> > ---
> > if (ring->bf_enabled && desc_size <= MAX_BF && !bounce &&
> > !vlan_tag) {
> > *(u32 *) (&tx_desc->ctrl.vlan_tag) |=
> > ring->doorbell_qpn;
> > op_own |= htonl((bf_index & 0xffff) << 8);
> > /* Ensure new descirptor hits memory
> > * before setting ownership of this descriptor to HW */
> > wmb();
> > tx_desc->ctrl.owner_opcode = op_own;
> >
> > wmb();
> >
> > mlx4_bf_copy(ring->bf.reg + ring->bf.offset, (unsigned
> > long *) &tx_desc->ctrl,
> > desc_size);
> >
> > wmb();
> >
> > ring->bf.offset ^= ring->bf.buf_size;
> > } else {
> > /* Ensure new descirptor hits memory
> > * before setting ownership of this descriptor to HW */
> > wmb();
> > tx_desc->ctrl.owner_opcode = op_own;
> > - wmb();
> > - writel(ring->doorbell_qpn, ring->bf.uar->map +
> > MLX4_SEND_DOORBELL);
> > }
> >
> > + wmb();
> > + writel(ring->doorbell_qpn, ring->bf.uar->map +
> > MLX4_SEND_DOORBELL);
> > +
> > ---
^ permalink raw reply
* Re: [PATCH] mlx4_en: fix transmit of packages when blue frame is enabled
From: Benjamin Herrenschmidt @ 2011-10-09 7:19 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: netdev@vger.kernel.org, Eli Cohen, eli@dev.mellanox.co.il,
linuxppc-dev, Yevgeny Petrilin
In-Reply-To: <20111004202620.GA3455@oc1711230544.ibm.com>
On Tue, 2011-10-04 at 17:26 -0300, Thadeu Lima de Souza Cascardo wrote:
> if (ring->bf_enabled && desc_size <= MAX_BF && !bounce &&
> !vlan_tag) {
> *(u32 *) (&tx_desc->ctrl.vlan_tag) |=
> ring->doorbell_qpn;
Could this have endianness problems ?
> op_own |= htonl((bf_index & 0xffff) << 8);
Probably better to use cpu_to_be/lexx() here. Also make sure your
descriptors are defined with the appropriate __beXX or __leXX types
so sparse can tell you when you get this wrong
> /* Ensure new descirptor hits memory
> * before setting ownership of this descriptor to HW */
> wmb();
> tx_desc->ctrl.owner_opcode = op_own;
> wmb();
>
> mlx4_bf_copy(ring->bf.reg + ring->bf.offset, (unsigned
> long *) &tx_desc->ctrl,
> desc_size);
What does the above do ?
> wmb();
>
> ring->bf.offset ^= ring->bf.buf_size;
Is this HW visible ? It's a bit odd, are you doing double bufferring and
trying to flip a bit ? If it's HW visible, is endian correct ?
} else {
> /* Ensure new descirptor hits memory
> * before setting ownership of this descriptor to HW */
> wmb();
> tx_desc->ctrl.owner_opcode = op_own;
> - wmb();
> - writel(ring->doorbell_qpn, ring->bf.uar->map +
> MLX4_SEND_DOORBELL);
> }
>
> + wmb();
> + writel(ring->doorbell_qpn, ring->bf.uar->map +
> MLX4_SEND_DOORBELL);
> +
> ---
Cheers,
Ben.
^ permalink raw reply
* raw ethenet socket question
From: Ronny Meeus @ 2011-10-08 20:20 UTC (permalink / raw)
To: netdev
Hello
I'm doing some tests on a raw Ethernet socket and I observe some
strange behavior.
My system is a FreeScale P4040, running Linux 2.6.36.4 compiled for
SMP mode but only 1 core activated.
[ 0.000000] Using P4080 DS machine description
[ 0.000000] Memory CAM mapping: 256/256/256 Mb, residual: 1248Mb
[ 0.000000] Linux version 2.6.36.4 (meeusr@devws108) (gcc version
4.4.6 (Buildroot 2011.08-hgc574811c3fc5) ) #1 SMP Sat Oct 8 20:40:40
CEST 2011
I basically have one of the Ethernet ports in a loopmode, which means
that all packets sent to the port will be received on the same port.
I want to check the amount of packets I can send/receive on my board,
so there a large loop to send/receive packets (see code below).
To stress the system a bit more, I send a number of packets before I
start to receive packets.
If I send 10 or less packets at a time, I do not see issues (see for
(j=0;j<10;j++)), but if I send for example 16 packets before starting
to receive, I always see packet loss.
For example if I send 1000 times 16 packets, I only receive 12000
packets, if I send 1000 times 20 packets, I receive 16000 packets.
I also checked the ifconfig statistics and the counters for Rx and Tx
are always identical and equal to the amount of packets that were
sent. So it looks like the packets are getting lost in the linux
kernel of in my test application.
Can somebody explain this behavior?
Is there a fixed amount of Ethernet packets that are queue in a socket?
Test code:
for (i=0;i<packets_to_send;i++)
{
fd_set readset;
struct timeval tv;
FD_ZERO(&readset);
FD_SET(eth_sock,&readset);
for (j=0;j<10;j++)
{
if (sendto(eth_sock,packet,packet_size, 0,(struct
sockaddr*)eth_dest, sizeof(struct sockaddr_ll)) > 0)
packet_count++;
}
tv.tv_sec = 0;
tv.tv_usec = 500;
while (select(eth_sock+1,&readset,0,0,&tv) == 1) {
int len = recvfrom(eth_sock,recvdata,sizeof(recvdata),0,NULL,NULL);
if (len>0) rcv_count++;
tv.tv_usec = 500;
}
printf("packet sent: %10ld packets received:
%10ld\r",packet_count,rcv_count);
}
This is how I create my socket:
int create_raw_eth_socket(void)
{
int eth_sock;
eth_dest.sll_family = PF_PACKET;
eth_dest.sll_protocol = htons(ETH_P_ALL);
eth_dest.sll_ifindex = itf_ifindex;
eth_dest.sll_hatype = ARPHRD_ETHER;
eth_dest.sll_pkttype = PACKET_OTHERHOST;
eth_dest.sll_halen = ETH_ALEN;
eth_sock = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
bind(eth_sock,(struct sockaddr*)ð_dest,sizeof(eth_dest));
return eth_sock;
}
Regards,
Ronny
^ permalink raw reply
* Re: [BUG] igb : rtnl assert on resume
From: Eric Dumazet @ 2011-10-08 20:16 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: David Miller, netdev
In-Reply-To: <1318102192.5276.27.camel@edumazet-laptop>
Le samedi 08 octobre 2011 à 21:29 +0200, Eric Dumazet a écrit :
> Le samedi 08 octobre 2011 à 11:26 -0700, Jeff Kirsher a écrit :
>
> > Any chance you can pull my net-next tree Eric to verify if the issue
> > still exists?
>
> Sure, I'll do that.
>
Same error with your changes as well.
No hurry, maybe the RTNL assert can be relaxed.
^ permalink raw reply
* Re: [net-next 02/11] igb: Use node specific allocations for the q_vectors and rings
From: David Miller @ 2011-10-08 19:51 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: alexander.h.duyck, netdev, gospo, sassmann
In-Reply-To: <1318056461-19562-3-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 7 Oct 2011 23:47:32 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change is meant to update the ring and vector allocations so that they
> are per node instead of allocating everything on the node that
> ifconfig/modprobe is called on. By doing this we can cut down
> significantly on cross node traffic.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
adapter->node seems superfluous.
It's always "-1" when we enter the allocation functions, and we
always restore it to it's original value upon exit from such
functions.
Just get rid of it and use a local variable in these functions
to keep track of the current allocation node.
Also, what ensures that MSI-X interrupts are targetted to a cpu
on the the node where you've made these allocations? I was
pretty sure Ben Hutchings added infrastructure that's usable
to ensure this, but I can't see where you're using it.
^ permalink raw reply
* Re: [BUG] igb : rtnl assert on resume
From: Eric Dumazet @ 2011-10-08 19:29 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: David Miller, netdev
In-Reply-To: <1318098396.23688.169.camel@jtkirshe-mobl>
Le samedi 08 octobre 2011 à 11:26 -0700, Jeff Kirsher a écrit :
> Any chance you can pull my net-next tree Eric to verify if the issue
> still exists?
Sure, I'll do that.
In the meantime, I upgraded my (slow, old) machine to ubuntu 11.11, and
reproduced the problem on their 3.0.something kernel.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
>
> I currently have 11 igb patches on that tree (which I recently
> submitted) that are not in Dave's tree yet.
>
> There have been a number of cleanup's recently, so while this is not
> expected, I am not surprised at the same time since I am in the middle
> of the update to igb.
>
> We have not seen this on my local tree (which has the 11 patches plus
> 4-5 more patches for igb). Almost all of them are
> cleanup's/re-organizing of igb, so nothing specific to the issue you
> have seen.
Thanks
^ permalink raw reply
* Re: e100 + VLANs?
From: Jeff Kirsher @ 2011-10-08 18:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Michael Tokarev, netdev
In-Reply-To: <1318091046.5276.22.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]
On 10/08/2011 09:24 AM, Eric Dumazet wrote:
> Le samedi 08 octobre 2011 à 14:08 +0400, Michael Tokarev a écrit :
>> > Yesterday I tried to use 802.1Q VLAN tagging with an (oldish)
>> > e100-driven network card, identified by lspci like this:
>> >
>> > 00:12.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 02)
>> >
>> > Just to discover that it does not quite work: packets of
>> > size 1497+ bytes gets lost.
>> >
>> > This appears to be a classical problems in this case -
>> > something forgot to allocate extra 4 bytes for the
>> > packets.
>> >
>> > There's at least one bugreport from 2008 (!) about this
>> > very issue: http://bugs.centos.org/view.php?id=2719
>> > which is still open.
>> >
>> > The kernel I tried this on was 2.6.32, I checked git log
>> > for drivers/net/e100.c - there was no changes up to
>> > current version which may be related to this issue.
>> >
>> > The question: is this a driver problem or hardware? If
>> > it's the driver, can it be fixed? And if it's hardware,
>> > can the driver notify the user somehow - like, by refusing
>> > to enable VLAN (sub)devices maybe?
>> >
>> > Yesterday it was actually a bit more complicated for me,
>> > since the card in question was used to connect to our
>> > ISP, and they use fixed MAC address per port, so I had
>> > to find another NIC which is a) able to work with VLAN
>> > tags properly, and b) is able to change its mac address.
>> > Lucky I had a VIA RhineIII which does both :)
>> >
> Since you have two cards (and probably two machines), maybe you could
> try to track if the problem is a bad transmit or a bad receive ?
>
> tcpdump on both machines, and ping -s 2000 from both sides...
>
> e100 driver seems VLAN enabled at a first glance.
Eric is correct, that e100 does support VLANs.
In addition to Eric's suggestion, can you also provide all the output of
lspci -vvv for the network card?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply
* Re: [BUG] igb : rtnl assert on resume
From: Jeff Kirsher @ 2011-10-08 18:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1318096284.5276.25.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]
On Sat, 2011-10-08 at 10:51 -0700, Eric Dumazet wrote:
> Hi guys
>
> Not sure if its a regression (it seems linux-3.0 probably should trigger
> same trace) but I caught this on latest net-next when suspend/resume
> cycle was done :
>
> [ 5279.891512] RTNL: assertion failed at net/core/dev.c (1665)
> [ 5279.891515] Pid: 2785, comm: kworker/u:9 Not tainted 3.1.0-rc9+ #81
> [ 5279.891517] Call Trace:
> [ 5279.891523] [<ffffffff814802ec>] netif_set_real_num_tx_queues+0x1ac/0x1c0
> [ 5279.891540] [<ffffffffa00244d1>] igb_init_interrupt_scheme+0x151/0x4b0 [igb]
> [ 5279.891546] [<ffffffffa002984d>] igb_resume+0x9d/0x160 [igb]
> [ 5279.891550] [<ffffffff812e0b91>] pci_legacy_resume+0x41/0x60
> [ 5279.891552] [<ffffffff812e17c0>] pci_pm_resume+0x90/0xd0
> [ 5279.891555] [<ffffffff813896b7>] pm_op+0xe7/0x1c0
> [ 5279.891558] [<ffffffff81389ba7>] device_resume+0xf7/0x1b0
> [ 5279.891561] [<ffffffff8108a520>] ? async_schedule+0x20/0x20
> [ 5279.891564] [<ffffffff81389c81>] async_resume+0x21/0x50
> [ 5279.891566] [<ffffffff8108a59f>] async_run_entry_fn+0x7f/0x180
> [ 5279.891569] [<ffffffff8107ca73>] process_one_work+0x123/0x480
> [ 5279.891572] [<ffffffff8107d638>] ? manage_workers.isra.30+0x1e8/0x230
> [ 5279.891574] [<ffffffff8107d7de>] worker_thread+0x15e/0x360
> [ 5279.891576] [<ffffffff8107d680>] ? manage_workers.isra.30+0x230/0x230
> [ 5279.891579] [<ffffffff8108225c>] kthread+0x8c/0xa0
> [ 5279.891583] [<ffffffff8157fc74>] kernel_thread_helper+0x4/0x10
> [ 5279.891586] [<ffffffff810821d0>] ? flush_kthread_worker+0xa0/0xa0
> [ 5279.891588] [<ffffffff8157fc70>] ? gs_change+0x13/0x13
>
> Thanks
Any chance you can pull my net-next tree Eric to verify if the issue
still exists?
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
I currently have 11 igb patches on that tree (which I recently
submitted) that are not in Dave's tree yet.
There have been a number of cleanup's recently, so while this is not
expected, I am not surprised at the same time since I am in the middle
of the update to igb.
We have not seen this on my local tree (which has the 11 patches plus
4-5 more patches for igb). Almost all of them are
cleanup's/re-organizing of igb, so nothing specific to the issue you
have seen.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [BUG] igb : rtnl assert on resume
From: Eric Dumazet @ 2011-10-08 17:51 UTC (permalink / raw)
To: Kirsher, Jeffrey T, David Miller; +Cc: netdev
Hi guys
Not sure if its a regression (it seems linux-3.0 probably should trigger
same trace) but I caught this on latest net-next when suspend/resume
cycle was done :
[ 5279.891512] RTNL: assertion failed at net/core/dev.c (1665)
[ 5279.891515] Pid: 2785, comm: kworker/u:9 Not tainted 3.1.0-rc9+ #81
[ 5279.891517] Call Trace:
[ 5279.891523] [<ffffffff814802ec>] netif_set_real_num_tx_queues+0x1ac/0x1c0
[ 5279.891540] [<ffffffffa00244d1>] igb_init_interrupt_scheme+0x151/0x4b0 [igb]
[ 5279.891546] [<ffffffffa002984d>] igb_resume+0x9d/0x160 [igb]
[ 5279.891550] [<ffffffff812e0b91>] pci_legacy_resume+0x41/0x60
[ 5279.891552] [<ffffffff812e17c0>] pci_pm_resume+0x90/0xd0
[ 5279.891555] [<ffffffff813896b7>] pm_op+0xe7/0x1c0
[ 5279.891558] [<ffffffff81389ba7>] device_resume+0xf7/0x1b0
[ 5279.891561] [<ffffffff8108a520>] ? async_schedule+0x20/0x20
[ 5279.891564] [<ffffffff81389c81>] async_resume+0x21/0x50
[ 5279.891566] [<ffffffff8108a59f>] async_run_entry_fn+0x7f/0x180
[ 5279.891569] [<ffffffff8107ca73>] process_one_work+0x123/0x480
[ 5279.891572] [<ffffffff8107d638>] ? manage_workers.isra.30+0x1e8/0x230
[ 5279.891574] [<ffffffff8107d7de>] worker_thread+0x15e/0x360
[ 5279.891576] [<ffffffff8107d680>] ? manage_workers.isra.30+0x230/0x230
[ 5279.891579] [<ffffffff8108225c>] kthread+0x8c/0xa0
[ 5279.891583] [<ffffffff8157fc74>] kernel_thread_helper+0x4/0x10
[ 5279.891586] [<ffffffff810821d0>] ? flush_kthread_worker+0xa0/0xa0
[ 5279.891588] [<ffffffff8157fc70>] ? gs_change+0x13/0x13
Thanks
^ permalink raw reply
* Re: e100 + VLANs?
From: Eric Dumazet @ 2011-10-08 16:24 UTC (permalink / raw)
To: Michael Tokarev; +Cc: netdev
In-Reply-To: <4E90212D.8030009@msgid.tls.msk.ru>
Le samedi 08 octobre 2011 à 14:08 +0400, Michael Tokarev a écrit :
> Yesterday I tried to use 802.1Q VLAN tagging with an (oldish)
> e100-driven network card, identified by lspci like this:
>
> 00:12.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 02)
>
> Just to discover that it does not quite work: packets of
> size 1497+ bytes gets lost.
>
> This appears to be a classical problems in this case -
> something forgot to allocate extra 4 bytes for the
> packets.
>
> There's at least one bugreport from 2008 (!) about this
> very issue: http://bugs.centos.org/view.php?id=2719
> which is still open.
>
> The kernel I tried this on was 2.6.32, I checked git log
> for drivers/net/e100.c - there was no changes up to
> current version which may be related to this issue.
>
> The question: is this a driver problem or hardware? If
> it's the driver, can it be fixed? And if it's hardware,
> can the driver notify the user somehow - like, by refusing
> to enable VLAN (sub)devices maybe?
>
> Yesterday it was actually a bit more complicated for me,
> since the card in question was used to connect to our
> ISP, and they use fixed MAC address per port, so I had
> to find another NIC which is a) able to work with VLAN
> tags properly, and b) is able to change its mac address.
> Lucky I had a VIA RhineIII which does both :)
>
Since you have two cards (and probably two machines), maybe you could
try to track if the problem is a bad transmit or a bad receive ?
tcpdump on both machines, and ping -s 2000 from both sides...
e100 driver seems VLAN enabled at a first glance.
^ permalink raw reply
* 群发软件+买家搜索机+最新广交会买家、海关数据,B2B询盘买家500万。
From: 仅10元每天 @ 2011-10-08 16:09 UTC (permalink / raw)
To: nessen, net, netamieya, netdev, nethashem, netmarkc, netrangr,
nette
群发软件+买家搜索机+109届广交会买家、展会买家、海关数据,B2B询盘买家500万。
一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)：
1，2011春季109届广交会买家数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，最新全球买家库,共451660条数据。
3，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。
4，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。
5，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。
6，60.8万条最新国外B2B买家询盘。
7，2009年海关提单数据piers版数据 1千万。
8，群发软件，群发软件的部署与安装。
共 500万个买家，每个均有Email.
保证每天都有买家回复。
保证每天都有买家回复。
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
诚信为本，如果不信任本人,可以走淘宝交易,收货验证后再付款,这是对您最好的保障了。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
广交会买家按产品类别分类，分为以下几类：
1 办公设备
2 编织及藤铁工艺品
3 玻璃
4 餐厨用具
5 车辆
6 大型机械及设备
7 电子电气
8 电子消费品
9 纺织
10 服装
11 个人护理
12 工程机械
13 工具
14 化工
15 计算机及通讯
16 家居用品
17 家居装饰
18 家具
19 家用电器
20 建筑及装饰材料
21 节日用品
22 礼品及赠品
23 摩托车
24 汽车配件
25 食品
26 陶瓷
27 铁石
28 玩具
29 卫浴
30 五金
31 小型机械
32 鞋
33 休闲用品
34 医疗
35 浴室产品
36 园林
37 照明产品
38 钟表眼镜
39 自行车
40 包
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
^ permalink raw reply
* Re: SOMAXCONN = 128, but max defaults to 2048
From: Olaf van der Spek @ 2011-10-08 12:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1318077339.5276.17.camel@edumazet-laptop>
On Sat, Oct 8, 2011 at 2:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le samedi 08 octobre 2011 à 13:51 +0200, Olaf van der Spek a écrit :
>> Is the name of SOMAXCONN wrong and is it actually defining the default?
>> Would there be a disadvantage to defining SOMAXCONN as INT_MAX and
>> letting the kernel control the actual max?
>>
>
> You mean : remove somaxconn tunable ?
No, I mean basically removing the compile-time value and only using
the run-time value (from the kernel).
> accept()/listen() is not bound to TCP only.
What else is that value used for?
> We had a recent discussion on the matter lately, but Hagen Paul Pfeifer
> did not polish his patches enough :
>
> http://lists.openwall.net/netdev/2011/03/20/3
Isn't it a single-line change?
Olaf
^ permalink raw reply
* Re: SOMAXCONN = 128, but max defaults to 2048
From: Eric Dumazet @ 2011-10-08 12:35 UTC (permalink / raw)
To: Olaf van der Spek; +Cc: netdev
In-Reply-To: <CAGVGHmt1OVOj0NSEo3qHCh1CR10eZTNjxuUh_mB6sXxcx5gKmA@mail.gmail.com>
Le samedi 08 octobre 2011 à 13:51 +0200, Olaf van der Spek a écrit :
> Hi,
>
> SOMAXCONN is defined as 128, but the max
> ("/proc/sys/net/ipv4/tcp_max_syn_backlog") appears to be 2048 by
> default.
It depends on memory size and TCP hash table size :
dmesg | grep "TCP established hash table entries"
-> TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
sysctl_max_syn_backlog = max(128, cnt / 256);
cnt = 524288
cnt/256 -> 2048
> Is the name of SOMAXCONN wrong and is it actually defining the default?
> Would there be a disadvantage to defining SOMAXCONN as INT_MAX and
> letting the kernel control the actual max?
>
You mean : remove somaxconn tunable ?
accept()/listen() is not bound to TCP only.
But yes, 128 default is a bit old today, given that Apache uses a
listen(fd, 511) default value itself...
I routinely set net.core.somaxconn to 1024 on my servers.
We had a recent discussion on the matter lately, but Hagen Paul Pfeifer
did not polish his patches enough :
http://lists.openwall.net/netdev/2011/03/20/3
FreeBSD has a separate mechanism for not yet established sockets, called
syncache, that allows a low somaxconn per listener.
The socket queue holds only fully established (but not yet accept()ed)
sockets, while syncache holds all the SYN_RECV ones.
^ permalink raw reply
* SOMAXCONN = 128, but max defaults to 2048
From: Olaf van der Spek @ 2011-10-08 11:51 UTC (permalink / raw)
To: netdev
Hi,
SOMAXCONN is defined as 128, but the max
("/proc/sys/net/ipv4/tcp_max_syn_backlog") appears to be 2048 by
default.
Is the name of SOMAXCONN wrong and is it actually defining the default?
Would there be a disadvantage to defining SOMAXCONN as INT_MAX and
letting the kernel control the actual max?
Greetings,
Olaf
^ permalink raw reply
* Re: [RFC] net: remove erroneous sk null assignment in timestamping
From: Richard Cochran @ 2011-10-08 10:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Johannes Berg, David Miller, netdev
In-Reply-To: <1318064238.5276.2.camel@edumazet-laptop>
On Sat, Oct 08, 2011 at 10:57:18AM +0200, Eric Dumazet wrote:
> Le samedi 08 octobre 2011 à 10:16 +0200, Johannes Berg a écrit :
>
> > I'm not terribly familiar with struct sock. Looking at it, I'm a bit
> > confused by skb_orphan() -- it doesn't put the sock reference. So are
> > sockets not refcounted for skbs in this way? They seem to use
> > sock_wfree() which does a bit more than this it seems, and I don't see
> > it using sk_refcnt anywhere so I'm a bit confused now.
Me, too.
> Check following commit changelog to get some information on this.
Thanks, Eric, that does help explain.
> We use this sock_hold()/sock_put() so that sock freeing
> is delayed until all tx packets are completed.
>
> As we also update sk_wmem_alloc, we could offset sk_wmem_alloc
> by one unit at init time, until sk_free() is called.
> Once sk_free() is called, we atomic_dec_and_test(sk_wmem_alloc)
> to decrement initial offset and atomicaly check if any packets
> are in flight.
>
> skb_set_owner_w() doesnt call sock_hold() anymore
So, if I understand, then I can solve my particular problem by doing:
* skb_clone_tx_timestamp
clone = skb_clone(skb, GFP_ATOMIC);
skb_set_owner_w(clone, sk)
// instead of
// clone->sk = sk;
phydev->drv->txtstamp(phydev, clone, type);
* skb_complete_tx_timestamp
serr->ee.ee_errno = ENOMSG;
serr->ee.ee_origin = SO_EE_ORIGIN_TIMESTAMPING;
// just remove this:
// skb->sk = NULL;
err = sock_queue_err_skb(sk, skb);
The only problem(?) I see is that it violates the rules from sock.h,
quoted below. The cloned tx skb destined for the error queue would be
budgeted to sk_wmem_alloc while wait for the time stamp. But maybe we
can allow this?
from sock.h:
/*
* Socket reference counting postulates.
*
* * Each user of socket SHOULD hold a reference count.
* * Each access point to socket (an hash table bucket, reference from a list,
* running timer, skb in flight MUST hold a reference count.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/
BTW, no longer true.
* * Packets, delivered from outside (from network or from another process)
* and enqueued on receive/error queues SHOULD NOT grab reference count,
* when they sit in queue. ~~~~~~~~~~~~~~~~~~~~~~~
Want to break/bend this rule.
Thanks,
Richard
^ permalink raw reply
* Re: [RFC] net: remove erroneous sk null assignment in timestamping
From: Johannes Berg @ 2011-10-08 10:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Richard Cochran, David Miller, netdev
In-Reply-To: <1318064238.5276.2.camel@edumazet-laptop>
On Sat, 2011-10-08 at 10:57 +0200, Eric Dumazet wrote:
> Le samedi 08 octobre 2011 à 10:16 +0200, Johannes Berg a écrit :
>
> > I'm not terribly familiar with struct sock. Looking at it, I'm a bit
> > confused by skb_orphan() -- it doesn't put the sock reference. So are
> > sockets not refcounted for skbs in this way? They seem to use
> > sock_wfree() which does a bit more than this it seems, and I don't see
> > it using sk_refcnt anywhere so I'm a bit confused now.
>
> Check following commit changelog to get some information on this.
>
> commit 2b85a34e911bf483c27cfdd124aeb1605145dc80
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu Jun 11 02:55:43 2009 -0700
>
> net: No more expensive sock_hold()/sock_put() on each tx
Aha, thanks for the pointer!
> As we also update sk_wmem_alloc, we could offset sk_wmem_alloc
> by one unit at init time, until sk_free() is called.
This is the trick! Neat. I see it now, now sk_free() makes sense to
me :-)
There's one thing I still miss though: It seems to me that if you have a
reference to a socket that has been sk_free()'ed (which is possible
since it might still have sk_wmem_alloc > 0) you can't sock_hold() that
socket. That feels a bit unexpected -- and might happen in the code
Richard just suggested.
Basically, while you can bump a reference you own via sock_hold() by
sk_wmem_alloc, as soon as sk_refcnt reaches 0 it must never go > 0 again
because that will have released the sk_wmem_alloc offset.
That can be fixed, but I'm not exactly sure what would be an efficient
way of doing it. Maybe by adding some flag that says whether or not the
sk_wmem_alloc offset is present, but that flag would have to be atomic
since I guess even this could race.
> Drawback is that a skb->truesize error could lead to unfreeable sockets, or
> even worse, prematurely calling __sk_free() on a live socket.
I was thinking about this yesterday as well. What we could do is wrap
all the skb truesize operations in inlines -- the regular ones like
skb_truesize_set()/add()/sub() would (depending on a debug Kconfig)
check that the skb isn't charged to a socket, and common sequences like
changing truesize and updating the sock could be wrapped into another
set of inlines that do both. Or something like that.
I was actually thinking about this for other reasons but then realised
that with the truesize bug check gone (which was really checking
something else) I didn't really need to worry any more.
johannes
^ permalink raw reply
* [PATCH net] vlan:make mtu of vlan equal to physical dev
From: Weiping Pan @ 2011-10-08 10:12 UTC (permalink / raw)
To: netdev; +Cc: Weiping Pan
Default mtu of vlan device is the same with mtu of physical device,
for example 1500, but when change physics mtu to 1600,
VLAN device's mtu is still 1500.
Certainly, you can change vlan device's mtu to 1600 manually,
but I think when you change physics device's mtu, VLAN's mtu should be changed
automatically instead of by manually.
Steps to Reproduce:
1.vconfig add eth4 3
2.ifconfig eth4 mtu 1600
3.check mtu on eth4.3
And what's worse is that if you decrease mtu of pyhsical device,
and when you want to increase it, the mtu of vlan device won't be changed.
Steps to Reproduce:
1.vconfig add eth4 3
2.ifconfig eth4 mtu 100
3.ifconfig eth4 mtu 1500
4.the mtu of eth4.3 is still 100
This bug is reported by Liang Zheng(lzheng@redhat.com).
Signed-off-by: Weiping Pan <panweiping3@gmail.com>
---
net/8021q/vlan.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 8970ba1..f6072b4 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -417,9 +417,6 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
if (!vlandev)
continue;
- if (vlandev->mtu <= dev->mtu)
- continue;
-
dev_set_mtu(vlandev, dev->mtu);
}
break;
--
1.7.4.4
^ permalink raw reply related
* e100 + VLANs?
From: Michael Tokarev @ 2011-10-08 10:08 UTC (permalink / raw)
To: netdev
Yesterday I tried to use 802.1Q VLAN tagging with an (oldish)
e100-driven network card, identified by lspci like this:
00:12.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 02)
Just to discover that it does not quite work: packets of
size 1497+ bytes gets lost.
This appears to be a classical problems in this case -
something forgot to allocate extra 4 bytes for the
packets.
There's at least one bugreport from 2008 (!) about this
very issue: http://bugs.centos.org/view.php?id=2719
which is still open.
The kernel I tried this on was 2.6.32, I checked git log
for drivers/net/e100.c - there was no changes up to
current version which may be related to this issue.
The question: is this a driver problem or hardware? If
it's the driver, can it be fixed? And if it's hardware,
can the driver notify the user somehow - like, by refusing
to enable VLAN (sub)devices maybe?
Yesterday it was actually a bit more complicated for me,
since the card in question was used to connect to our
ISP, and they use fixed MAC address per port, so I had
to find another NIC which is a) able to work with VLAN
tags properly, and b) is able to change its mac address.
Lucky I had a VIA RhineIII which does both :)
Thanks,
/mjt
^ permalink raw reply
* Wir bieten Darlehen
From: Franck.DEBOS @ 2011-10-08 9:19 UTC (permalink / raw)
Dies ist zu informieren, dass CAPITAL GLEICHHEIT
bietet derzeit einen Kredit mit 3% Zinsen
Rate.
Wir bieten eine Vielzahl von Krediten an unsere
Kunden. Was auch immer Ihre Bedürfnisse sind Darlehen,
große oder kleine, persönliche oder Hypotheken, sind wir
bereit, mit Ihnen darüber, wie wir uns treffen können sprechen
Ihre Bedürfnisse. Anmeldeformular unter
CAPITAL GLEICHHEIT
71 Queen Victoria Street
London, United Kingdom, EC4V 4DE
Anmeldeformular:
1) Vollständiger Name :.........
2) Land :..............
3) Adresse: ...
4) Sex :..............
5) Familienstand :......................
6) Beruf :..............
7) Telefon :......
8) Monatliches Einkommen :.....................
9) Darlehensbetrag Benötigte :...............
10) Dauer der Ausleihe :..................
11) Zweck des Darlehens :.................
12) Alter: ..............
Rosmarie Neely
Loan Officer
E-mail: cequality24hoursloans@gmail.com
Tell: +447035958575
Fax: +448447742385
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: [RFC] net: remove erroneous sk null assignment in timestamping
From: Eric Dumazet @ 2011-10-08 8:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: Richard Cochran, David Miller, netdev
In-Reply-To: <1318061808.3991.12.camel@jlt3.sipsolutions.net>
Le samedi 08 octobre 2011 à 10:16 +0200, Johannes Berg a écrit :
> I'm not terribly familiar with struct sock. Looking at it, I'm a bit
> confused by skb_orphan() -- it doesn't put the sock reference. So are
> sockets not refcounted for skbs in this way? They seem to use
> sock_wfree() which does a bit more than this it seems, and I don't see
> it using sk_refcnt anywhere so I'm a bit confused now.
Check following commit changelog to get some information on this.
commit 2b85a34e911bf483c27cfdd124aeb1605145dc80
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu Jun 11 02:55:43 2009 -0700
net: No more expensive sock_hold()/sock_put() on each tx
One of the problem with sock memory accounting is it uses
a pair of sock_hold()/sock_put() for each transmitted packet.
This slows down bidirectional flows because the receive path
also needs to take a refcount on socket and might use a different
cpu than transmit path or transmit completion path. So these
two atomic operations also trigger cache line bounces.
We can see this in tx or tx/rx workloads (media gateways for example),
where sock_wfree() can be in top five functions in profiles.
We use this sock_hold()/sock_put() so that sock freeing
is delayed until all tx packets are completed.
As we also update sk_wmem_alloc, we could offset sk_wmem_alloc
by one unit at init time, until sk_free() is called.
Once sk_free() is called, we atomic_dec_and_test(sk_wmem_alloc)
to decrement initial offset and atomicaly check if any packets
are in flight.
skb_set_owner_w() doesnt call sock_hold() anymore
sock_wfree() doesnt call sock_put() anymore, but check if sk_wmem_alloc
reached 0 to perform the final freeing.
Drawback is that a skb->truesize error could lead to unfreeable sockets, or
even worse, prematurely calling __sk_free() on a live socket.
Nice speedups on SMP. tbench for example, going from 2691 MB/s to 2711 MB/s
on my 8 cpu dev machine, even if tbench was not really hitting sk_refcnt
contention point. 5 % speedup on a UDP transmit workload (depends
on number of flows), lowering TX completion cpu usage.
^ permalink raw reply
* Re: [PATCH v2 2/2] virtio-net: Prevent NULL dereference
From: Sasha Levin @ 2011-10-08 8:40 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Rusty Russell, virtualization, netdev, kvm
In-Reply-To: <20111003190516.GD22427@redhat.com>
On Mon, 2011-10-03 at 21:05 +0200, Michael S. Tsirkin wrote:
> I thought about this some more. If length was too large host is
> right now writing into pages that we have freed.
> That is very bad, and I don't know what do do with it,
> really not worth prettifying that IMO, NULL pointer is the least of our
> worries.
>
> But, with mergeable buffers at least, and that is the main mode anyway,
> there is always a single page per buf, right?
> So I think we should change the code,
> and for mergeable buffers we shall only verify that
> length <= PAGE_SIZE.
In receive_mergeable() we already verify both 'page' being non-null and
length:
if (len > PAGE_SIZE)
len = PAGE_SIZE;
>
> IOW copy a bit of code from page_to_skb(vi, page, len)
> to receive_mergeable, maybe add a common function
> if we need to avoid duplication.
--
Sasha.
^ permalink raw reply
* Re: [RFC] net: remove erroneous sk null assignment in timestamping
From: Johannes Berg @ 2011-10-08 8:16 UTC (permalink / raw)
To: Richard Cochran; +Cc: David Miller, netdev
In-Reply-To: <20111008075719.GA2284@netboy.at.omicron.at>
On Sat, 2011-10-08 at 09:57 +0200, Richard Cochran wrote:
> I don't remember why I put it that way, but I took a look at the
> problem, and I am not sure how to solve it. The other callers of
> sock_queue_err_skb all create or clone the error skb immediately
> before queueing it:
>
> net/core/skbuff.c: skb_tstamp_tx
> net/ipv4/ip_sockglue.c: ip_icmp_error, ip_local_error
> net/ipv6/datagram.c: ipv6_icmp_error, ipv6_local_error
Yeah, I noticed that too. That's also the reason they pass the socket
externally I believe, since it's not a properly refcounted socket (the
reference they use is still from the original skb).
The thing that makes it work is that
a) they don't release the original SKB before sock_queue_err_skb() and
b) skb->sk is NULL for them
Since this is just a single function, they can guarantee that -- in the
case we found here it's scattered across the code and won't always be
guaranteed -- e.g. the kfree_skb() case in the PHY driver potentially
violates b).
> So I need to prevent the socket from disappearing between
> skb_clone_tx_timestamp and skb_complete_tx_timestamp:
>
> skb_clone_tx_timestamp
> clone = skb_clone(skb, GFP_ATOMIC);
> sock_hold
> skb_complete_tx_timestamp
> sock_queue_err_skb(sk, skb);
> sock_put
>
> What do you think?
I'm not terribly familiar with struct sock. Looking at it, I'm a bit
confused by skb_orphan() -- it doesn't put the sock reference. So are
sockets not refcounted for skbs in this way? They seem to use
sock_wfree() which does a bit more than this it seems, and I don't see
it using sk_refcnt anywhere so I'm a bit confused now.
> BTW, while looking for a good pattern to follow, I found that the can
> driver also sets skb->sk after clone with no special treatment, like
> so:
>
> drivers/net/can/dev.c:285
> can_put_echo_skb
> struct sock *srcsk = skb->sk;
> skb = skb_clone(old_skb, GFP_ATOMIC);
> skb->sk = srcsk;
Yeah that looks fishy too. But to me it looks a bit like it should
charge to the socket instead of refcounting it -- though of course
that's not really the correct thing to do from a socket buffer point of
view, but it seems the sk_refcnt and sk_wmem_alloc are two separate
mechanisms of refcounting the socket -- I just haven't figured out yet
how they interact.
> > The TX side of this infrastructure seems very poorly tested.
>
> In fact, we do have the phyter driver used in an extensive automated
> test farm, but the applications just don't do the kinds of things
> suggested to trigger the problem. The normal pattern is, send event
> packet, get tx timestamp, and so we haven't seen the bug at all.
Makes sense, you never wrote an application trying to crash it :-)
> > Maybe that's how you can trigger it: have one thread turn on and off
> > timestamping all the time, and another thread send frames all the time,
> > then eventually you'll probably run into the kfree_skb() case there. If
> > you ever manage to run into that case, it'll crash either when freeing
> > this skb or when freeing the original.
>
> Thats one weird app, but I get the point, and thanks for your
> attention to my code.
Agree, it's obviously a specifically devised app to try to make it
crash. It serves no other practical purpose.
johannes
^ permalink raw reply
* [net-next v2] cs89x0: Move the driver into the Cirrus dir
From: Jeff Kirsher @ 2011-10-08 8:07 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann, Russell Nelson,
Andrew Morton
The cs89x0 driver was initial placed in the apple/ when it
should have been placed in the cirrus/. This resolves the
issue by moving the dirver and fixing up the respective
Kconfig(s) and Makefile(s).
Thanks to Sascha for reporting the issue.
-v2 Fix a config error that was introduced with v1 by removing
the dependency on MACE for NET_VENDOR_APPLE.
CC: Russell Nelson <nelson@crynwr.com>
CC: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/apple/Kconfig | 22 +---------------------
drivers/net/ethernet/apple/Makefile | 1 -
drivers/net/ethernet/cirrus/Kconfig | 22 +++++++++++++++++++++-
drivers/net/ethernet/cirrus/Makefile | 1 +
drivers/net/ethernet/{apple => cirrus}/cs89x0.c | 0
drivers/net/ethernet/{apple => cirrus}/cs89x0.h | 0
6 files changed, 23 insertions(+), 23 deletions(-)
rename drivers/net/ethernet/{apple => cirrus}/cs89x0.c (100%)
rename drivers/net/ethernet/{apple => cirrus}/cs89x0.h (100%)
diff --git a/drivers/net/ethernet/apple/Kconfig b/drivers/net/ethernet/apple/Kconfig
index 59d5c26..a759d54 100644
--- a/drivers/net/ethernet/apple/Kconfig
+++ b/drivers/net/ethernet/apple/Kconfig
@@ -5,8 +5,7 @@
config NET_VENDOR_APPLE
bool "Apple devices"
default y
- depends on (PPC_PMAC && PPC32) || MAC || ISA || EISA || MACH_IXDP2351 \
- || ARCH_IXDP2X01 || MACH_MX31ADS || MACH_QQ2440
+ depends on (PPC_PMAC && PPC32) || MAC
---help---
If you have a network (Ethernet) card belonging to this class, say Y
and read the Ethernet-HOWTO, available from
@@ -75,23 +74,4 @@ config MACMACE
say Y and read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
-config CS89x0
- tristate "CS89x0 support"
- depends on (ISA || EISA || MACH_IXDP2351 \
- || ARCH_IXDP2X01 || MACH_MX31ADS || MACH_QQ2440)
- ---help---
- Support for CS89x0 chipset based Ethernet cards. If you have a
- network (Ethernet) card of this type, say Y and read the
- Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto> as well as
- <file:Documentation/networking/cs89x0.txt>.
-
- To compile this driver as a module, choose M here. The module
- will be called cs89x0.
-
-config CS89x0_NONISA_IRQ
- def_bool y
- depends on CS89x0 != n
- depends on MACH_IXDP2351 || ARCH_IXDP2X01 || MACH_MX31ADS || MACH_QQ2440
-
endif # NET_VENDOR_APPLE
diff --git a/drivers/net/ethernet/apple/Makefile b/drivers/net/ethernet/apple/Makefile
index 9d30086..0d3a591 100644
--- a/drivers/net/ethernet/apple/Makefile
+++ b/drivers/net/ethernet/apple/Makefile
@@ -5,5 +5,4 @@
obj-$(CONFIG_MACE) += mace.o
obj-$(CONFIG_BMAC) += bmac.o
obj-$(CONFIG_MAC89x0) += mac89x0.o
-obj-$(CONFIG_CS89x0) += cs89x0.o
obj-$(CONFIG_MACMACE) += macmace.o
diff --git a/drivers/net/ethernet/cirrus/Kconfig b/drivers/net/ethernet/cirrus/Kconfig
index e9386ef..6cbb81c 100644
--- a/drivers/net/ethernet/cirrus/Kconfig
+++ b/drivers/net/ethernet/cirrus/Kconfig
@@ -5,7 +5,8 @@
config NET_VENDOR_CIRRUS
bool "Cirrus devices"
default y
- depends on ARM && ARCH_EP93XX
+ depends on ISA || EISA || MACH_IXDP2351 || ARCH_IXDP2X01 \
+ || MACH_MX31ADS || MACH_QQ2440 || (ARM && ARCH_EP93XX)
---help---
If you have a network (Ethernet) card belonging to this class, say Y
and read the Ethernet-HOWTO, available from
@@ -18,6 +19,25 @@ config NET_VENDOR_CIRRUS
if NET_VENDOR_CIRRUS
+config CS89x0
+ tristate "CS89x0 support"
+ depends on (ISA || EISA || MACH_IXDP2351 \
+ || ARCH_IXDP2X01 || MACH_MX31ADS || MACH_QQ2440)
+ ---help---
+ Support for CS89x0 chipset based Ethernet cards. If you have a
+ network (Ethernet) card of this type, say Y and read the
+ Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto> as well as
+ <file:Documentation/networking/cs89x0.txt>.
+
+ To compile this driver as a module, choose M here. The module
+ will be called cs89x0.
+
+config CS89x0_NONISA_IRQ
+ def_bool y
+ depends on CS89x0 != n
+ depends on MACH_IXDP2351 || ARCH_IXDP2X01 || MACH_MX31ADS || MACH_QQ2440
+
config EP93XX_ETH
tristate "EP93xx Ethernet support"
depends on ARM && ARCH_EP93XX
diff --git a/drivers/net/ethernet/cirrus/Makefile b/drivers/net/ethernet/cirrus/Makefile
index 9905ea2..14bd77e 100644
--- a/drivers/net/ethernet/cirrus/Makefile
+++ b/drivers/net/ethernet/cirrus/Makefile
@@ -2,4 +2,5 @@
# Makefile for the Cirrus network device drivers.
#
+obj-$(CONFIG_CS89x0) += cs89x0.o
obj-$(CONFIG_EP93XX_ETH) += ep93xx_eth.o
diff --git a/drivers/net/ethernet/apple/cs89x0.c b/drivers/net/ethernet/cirrus/cs89x0.c
similarity index 100%
rename from drivers/net/ethernet/apple/cs89x0.c
rename to drivers/net/ethernet/cirrus/cs89x0.c
diff --git a/drivers/net/ethernet/apple/cs89x0.h b/drivers/net/ethernet/cirrus/cs89x0.h
similarity index 100%
rename from drivers/net/ethernet/apple/cs89x0.h
rename to drivers/net/ethernet/cirrus/cs89x0.h
--
1.7.6.4
^ permalink raw reply related
* Re: [RFC] net: remove erroneous sk null assignment in timestamping
From: Richard Cochran @ 2011-10-08 7:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: David Miller, netdev
In-Reply-To: <1318012932.3974.7.camel@jlt3.sipsolutions.net>
On Fri, Oct 07, 2011 at 08:42:12PM +0200, Johannes Berg wrote:
> Maybe that's how you can trigger it: have one thread turn on and off
> timestamping all the time, and another thread send frames all the time,
> then eventually you'll probably run into the kfree_skb() case there. If
> you ever manage to run into that case, it'll crash either when freeing
> this skb or when freeing the original.
Thats one weird app, but I get the point, and thanks for your
attention to my code.
Richard
^ permalink raw reply
* Re: [RFC] net: remove erroneous sk null assignment in timestamping
From: Richard Cochran @ 2011-10-08 7:57 UTC (permalink / raw)
To: David Miller; +Cc: johannes, netdev
In-Reply-To: <20111007.133356.489094996618032061.davem@davemloft.net>
On Fri, Oct 07, 2011 at 01:33:56PM -0400, David Miller wrote:
> It looks like skb_clone_tx_timestamp() sets clone->sk without any
> proper refcounting, so I bet this NULL'ing it out is working
> around that bug.
I don't remember why I put it that way, but I took a look at the
problem, and I am not sure how to solve it. The other callers of
sock_queue_err_skb all create or clone the error skb immediately
before queueing it:
net/core/skbuff.c: skb_tstamp_tx
net/ipv4/ip_sockglue.c: ip_icmp_error, ip_local_error
net/ipv6/datagram.c: ipv6_icmp_error, ipv6_local_error
So I need to prevent the socket from disappearing between
skb_clone_tx_timestamp and skb_complete_tx_timestamp:
skb_clone_tx_timestamp
clone = skb_clone(skb, GFP_ATOMIC);
sock_hold
skb_complete_tx_timestamp
sock_queue_err_skb(sk, skb);
sock_put
What do you think?
BTW, while looking for a good pattern to follow, I found that the can
driver also sets skb->sk after clone with no special treatment, like
so:
drivers/net/can/dev.c:285
can_put_echo_skb
struct sock *srcsk = skb->sk;
skb = skb_clone(old_skb, GFP_ATOMIC);
skb->sk = srcsk;
> The TX side of this infrastructure seems very poorly tested.
In fact, we do have the phyter driver used in an extensive automated
test farm, but the applications just don't do the kinds of things
suggested to trigger the problem. The normal pattern is, send event
packet, get tx timestamp, and so we haven't seen the bug at all.
Thanks,
Richard
^ 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