* Re: 2.6.17-rc4: netfilter LOG messages truncated via NETCONSOLE
From: Patrick McHardy @ 2006-06-01 17:34 UTC (permalink / raw)
To: Frank van Maarseveen; +Cc: linux-kernel, Kernel Netdev Mailing List
In-Reply-To: <20060601091124.GA31642@janus>
Frank van Maarseveen wrote:
> ok, now "tc -s -d qdisc show" says (after noticing missing netconsole
> packets):
>
> qdisc pfifo_fast 0: dev eth0 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> Sent 155031 bytes 2067 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
Mhh no dropped packets. I tried to reproduce the problem by changing
netconsole to always use the dev_queue_xmit path, but works flawlessly
for me. Please try to find out if the packets are lost before or after
the qdisc by looking at the packet counter.
BTW: You still haven't sent me the packet dump (from the originating
machine).
^ permalink raw reply
* Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
From: Patrick McHardy @ 2006-06-01 17:44 UTC (permalink / raw)
To: Meelis Roos; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <Pine.SOC.4.61.0606011002180.13777@math.ut.ee>
Meelis Roos wrote:
>> Meelis, it would really help if you could try 2.6.16 and in case
>> that doesn't work 2.6.15 to give an idea about whether this is a
>> recent regression or an old problem. We had a number of changes
>> in this area in the last two kernel versions that could be related.
>
>
> Have not gotten 2.6.15 to work with one evening of tinkering - the irq
> patch was not sufficent, there is something more broken in booting that
> I dodn't figure out yet. So no test results for 2.6.15 yet.
Then lets try something different. Please enable the
DEBUG_IP_FIREWALL_USER define in net/ipv4/netfilter/ip_tables.c and
post the results, if any.
^ permalink raw reply
* Re: monitor_during_oper on rt*pci (or any other pcmcia card)?
From: Ivo van Doorn @ 2006-06-01 17:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, rt2x00-devel, Jean Tourrilhes, Florian.Rampp
In-Reply-To: <1149162449.8877.72.camel@johannes>
[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]
Hi,
> Florian approached me with a project where you need a pcmcia card that
> can have monitor_during_oper. I'd use bcm43xx but unfortunately the
> signal strength calculations are way off right now, and that's another
> requirement.
>
> Can the rt family of cards be made to support this with reliable signal
> strength readings?
At this moment the rt2x00 drivers are not known for their correct signal
strength reporting. The reading is coming out of the registers but
it isn't working in all cases.
Even the legacy drivers from Ralink self are not known for their correct
behaviour but some issues around that have been traced to bugs in the
driver. But it could be possible the registers are wrong as well.
> Or maybe I should rephrase the questions: which pcmcia cards can support
> this in their hardware? I might be willing to port their drivers over to
> d80211 just to get some more familiarity with the stack...
>
> Now, if no one can point me to ones that do have working signal
> strength, I'll probably have to do more reverse engineering on bcm43xx
> to get some reliable readings :/
>
> Thanks,
> johannes
>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Question about tcp hash function tcp_hashfn()
From: Brian F. G. Bidulock @ 2006-06-01 18:40 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David Miller, draghuram, linux-kernel, netdev
In-Reply-To: <20060601110625.GA15069@2ka.mipt.ru>
Evgeniy,
On Thu, 01 Jun 2006, Evgeniy Polyakov wrote:
I think the sun shines more in Moscow than in Edmonton, so it is not
so random. ;)
>
> Specially for you :)
Thank you for being so gracious and patient with me.
> It does not have artifacts, but it's dispersion is wider than XOR one.
> _Much_ wider, which tends to creation of some specially crafted source
> distribution which ends up in totally broken fairness.
> As usual folded and not folded versions behave exactly the same.
>
> > > With following ip/port selection algo:
> > > if (++sport == 0) {
> > > //saddr++;
> > > sport += 123;
> > > }
> > >
> > > I see yet another jenkins artefacts, but again different from previous
> > > two.
> >
> > Adding primes. Again, the arithmetic series of primes might auto-correlate
> > with the Jenkins function. Or it plain might not like gaps.
> >
>
> I want to confirm three things and one state:
> 1. Jenkins hash has some unacceptible artefacts in some source
> address/port distributions, no matter if it has some law embedded or it
> is (pseudo)-random set.
>
> If there are bugs, bugs exist.
True, artifacts appeared even in the basic arithmetic sequence of
primes. It is quite possible that a large set of natural sequences
might cause artifacts.
>
> 2. If it does not have artifacts it has unacceptible dispersion.
This is likely due to the relatively small sample sets; however, real
experienced data sets would be very small compared to the widest
possible set and might also contain structured gaps.
>
> 3. It is 3 times slower than XOR one (28 seconds for XOR for 2^29
> iterations vs. 101 seconds jhash nonfolded and 109 jhash folded on my AMD64
> 3500+ 2.2 Ghz desktop).
Yes, it is slower by inspection.
>
> 4. I believe it can be tuned or has some gaps inside refactoring logic,
> which can be fixed, but as is it can not be used for fair hash creation.
Yes, I now agree. And, for the purpose of dynamic hash sizing, high
dispersion is worse than artifacts.
For some realistic TCP data sets it appears that XOR is superior.
Thank you again for your efforts in resolving my doubts.
So what are your thoughts about my sequence number approach (for
connected sockets)?
^ permalink raw reply
* RE: pci_enable_msix throws up error
From: Ravinandan Arakali @ 2006-06-01 19:08 UTC (permalink / raw)
To: Andi Kleen, Ayaz Abdulla
Cc: Ravinandan Arakali, linux-kernel, Ananda. Raju, netdev,
Leonid Grossman
I have submitted a proposed fix for the below issue.
Will wait for comments.
Ravi
-----Original Message-----
From: Andi Kleen [mailto:ak@suse.de]
Sent: Friday, May 05, 2006 1:44 AM
To: Ayaz Abdulla
Cc: ravinandan.arakali@neterion.com; linux-kernel@vger.kernel.org;
Ananda. Raju; netdev@vger.kernel.org; Leonid Grossman
Subject: Re: pci_enable_msix throws up error
On Friday 05 May 2006 07:14, Ayaz Abdulla wrote:
> I noticed the same behaviour, i.e. can not use both MSI and MSIX without
> rebooting.
>
> I had sent a message to the maintainer of the MSI/MSIX source a few
> months ago and got a response that they were working on fixing it. Not
> sure what the progress is on it.
The best way to make progress faster would be for someone like you
who needs it to submit a patch to fix it then.
-Andi
^ permalink raw reply
* [RFT] Realtek 8168 ethernet support
From: Daniel Drake @ 2006-06-01 20:02 UTC (permalink / raw)
To: netdev
I've produced this patch which should allow the r8169 driver to work with the
new Realtek 8168 chips. These are found in PCI-Express form and onboard some
newer motherboards.
Does anyone own this hardware? I'm looking for someone to test it before I
send it on.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Index: linux/drivers/net/r8169.c
===================================================================
--- linux.orig/drivers/net/r8169.c
+++ linux/drivers/net/r8169.c
@@ -184,6 +184,7 @@ static const struct {
static struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), },
{ PCI_DEVICE(0x16ec, 0x0116), },
{ PCI_VENDOR_ID_LINKSYS, 0x1032, PCI_ANY_ID, 0x0024, },
@@ -1398,6 +1399,7 @@ rtl8169_init_board(struct pci_dev *pdev,
struct net_device *dev;
struct rtl8169_private *tp;
int rc = -ENOMEM, i, acpi_idle_state = 0, pm_cap;
+ u32 mmio_base = 0;
assert(ioaddr_out != NULL);
@@ -1442,20 +1444,24 @@ rtl8169_init_board(struct pci_dev *pdev,
}
}
- /* make sure PCI base addr 1 is MMIO */
- if (!(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) {
- if (netif_msg_probe(tp)) {
- printk(KERN_ERR PFX
- "region #1 not an MMIO resource, aborting\n");
- }
- rc = -ENODEV;
- goto err_out_mwi;
+ /* find MMIO resource: this varies between 8168 and 8169 */
+ for (i = 0; i < 5; i++) {
+ /* check resource type */
+ if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
+ continue;
+
+ /* check for weird/broken PCI region reporting */
+ if (pci_resource_len(pdev, i) < R8169_REGS_SIZE)
+ continue;
+
+ mmio_base = pci_resource_start(pdev, i);
+ break;
}
- /* check for weird/broken PCI region reporting */
- if (pci_resource_len(pdev, 1) < R8169_REGS_SIZE) {
+
+ if (mmio_base == 0) {
if (netif_msg_probe(tp)) {
printk(KERN_ERR PFX
- "Invalid PCI region size(s), aborting\n");
+ "couldn't find valid MMIO resource, aborting\n");
}
rc = -ENODEV;
goto err_out_mwi;
@@ -1490,7 +1496,7 @@ rtl8169_init_board(struct pci_dev *pdev,
pci_set_master(pdev);
/* ioremap MMIO region */
- ioaddr = ioremap(pci_resource_start(pdev, 1), R8169_REGS_SIZE);
+ ioaddr = ioremap(mmio_base, R8169_REGS_SIZE);
if (ioaddr == NULL) {
if (netif_msg_probe(tp))
printk(KERN_ERR PFX "cannot remap MMIO, aborting\n");
^ permalink raw reply
* Re: Question about tcp hash function tcp_hashfn()
From: David Miller @ 2006-06-01 20:21 UTC (permalink / raw)
To: bidulock; +Cc: johnpol, draghuram, linux-kernel, netdev
In-Reply-To: <20060601124010.C554@openss7.org>
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
Date: Thu, 1 Jun 2006 12:40:10 -0600
> I think the sun shines more in Moscow than in Edmonton, so it is not
> so random. ;)
Go Oilers :)
^ permalink raw reply
* Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
From: Meelis Roos @ 2006-06-01 20:50 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <447F2787.8010203@trash.net>
> Then lets try something different. Please enable the
> DEBUG_IP_FIREWALL_USER define in net/ipv4/netfilter/ip_tables.c and
> post the results, if any.
On bootup I get this in dmesg (one Bad offset has been added):
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (1536 buckets, 12288 max) - 224 bytes per conntrack
translate_table: size 632
Bad offset cb437924
ip_nat_init: can't setup rules.
And on iptables -t nat -L
translate_table: size 632
Bad offset cb4368f4
ip_nat_init: can't setup rules.
translate_table: size 632
Bad offset cb4368f4
ip_nat_init: can't setup rules.
Seems iptable_nat does not load at all this time.
Modprobe iptable_filter still fails, dmesg contains
translate_table: size 632
Finished chain 1
Finished chain 2
Finished chain 3
Next modprobe iptable_nat gives
translate_table: size 632
Bad offset c8e01944
ip_nat_init: can't setup rules.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [PATCH 1/2] iWARP Connection Manager.
From: Sean Hefty @ 2006-06-01 21:09 UTC (permalink / raw)
To: Steve Wise; +Cc: rdreier, linux-kernel, netdev, openib-general
In-Reply-To: <1149181233.31610.34.camel@stevo-desktop>
Steve Wise wrote:
>>>+int iw_cm_disconnect(struct iw_cm_id *cm_id, int abrupt)
>>>+{
>>>+ struct iwcm_id_private *cm_id_priv;
>>>+ unsigned long flags;
>>>+ int ret = 0;
>>>+
>>>+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
>>>+ /* Wait if we're currently in a connect or accept downcall */
>>>+ wait_event(cm_id_priv->connect_wait,
>>>+ !test_bit(IWCM_F_CONNECT_WAIT, &cm_id_priv->flags));
>>
>>Am I understanding this check correctly? You're checking to see if the user has
>>called iw_cm_disconnect() at the same time that they called iw_cm_connect() or
>>iw_cm_accept(). Are connect / accept blocking, or are you just waiting for an
>>event?
>
>
> The CM must wait for the low level provider to finish a connect() or
> accept() operation before telling the low level provider to disconnect
> via modifying the iwarp QP. Regardless of whether they block, this
> disconnect can happen concurrently with the connect/accept so we need to
> hold the disconnect until the connect/accept completes.
>
>
>>>+EXPORT_SYMBOL(iw_cm_disconnect);
>>>+static void destroy_cm_id(struct iw_cm_id *cm_id)
>>>+{
>>>+ struct iwcm_id_private *cm_id_priv;
>>>+ unsigned long flags;
>>>+ int ret;
>>>+
>>>+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
>>>+ /* Wait if we're currently in a connect or accept downcall. A
>>>+ * listening endpoint should never block here. */
>>>+ wait_event(cm_id_priv->connect_wait,
>>>+ !test_bit(IWCM_F_CONNECT_WAIT, &cm_id_priv->flags));
>>
>>Same question/comment as above.
>>
>
>
> Same answer.
There's a difference between trying to handle the user calling
disconnect/destroy at the same time a call to accept/connect is active, versus
the user calling disconnect/destroy after accept/connect have returned. In the
latter case, I think you're fine. In the first case, this is allowing a user to
call destroy at the same time that they're calling accept/connect.
Additionally, there's no guarantee that the F_CONNECT_WAIT flag has been set by
accept/connect by the time disconnect/destroy tests it.
- Sean
^ permalink raw reply
* [RFC] new qla3xxx NIC Driver v2.02.00k30
From: Ron Mercer @ 2006-06-01 21:40 UTC (permalink / raw)
To: netdev; +Cc: linux-driver, Ron Mercer
All,
Forth submission for the upstream inclusion of the qla3xxx Ethernet
driver. This is a complementary network driver for our ISP4XXX parts.
There is a concurrent effort underway to get the iSCSI driver (qla4xxx)
integrated upstream as well.
This submission is contained in a patch file that does the following:
Adds:
drivers/net/qla3xxx.c
drivers/net/qla3xxx.h
Modifies:
MAINTAINERS
drivers/net/Makefile
drivers/net/Kconfig
Built and tested using kernel 2.6.17-rc4.
Patch file qla3xxxpatch1-v2.02.00k30 is at the following link:
ftp://ftp.qlogic.com/outgoing/linux/network/upstream/2.02.00k30/
third submission:
http://marc.theaimsgroup.com/?l=linux-netdev&m=114867289310324&w=2
Comments from third submission:
http://marc.theaimsgroup.com/?l=linux-netdev&m=114868292920149&w=2
Changes in this release:
1. Call unregister_netdev before doing any hardware tear down.
2. Call pci_unmap_single before reference in eth_type_trans.
3. Change kfree to free_netdev.
4. Cleaned up indentation.
5. Changed more globals to use const.
6. ethtool get_link reports carrier state.
7. Got rid if multicast list comparisons since kernel has to do it.
8. Added call to prefetch before sending packet up the stack.
9. Renamed files to qla3xxx.c and qla3xxx.h.
10. Moved files to drivers/net and got rid of drivers/net/qla3xxx.
11. Updated Kconfig and Makefile to include driver build.
12. Cleaned up indents, eol whitespaces, and 80 column limits.
13. Added Ron Mercer to Maintainers list.
Looking forward to any and all feedback.
Regards,
Ron Mercer
Qlogic Corporation
^ permalink raw reply
* Re: DPRINTKs in e1000 code (2.6.x kernels)
From: Amit Arora @ 2006-06-01 21:57 UTC (permalink / raw)
To: Auke Kok; +Cc: netdev, auke-jan.h.kok, amitarora
In-Reply-To: <23630a870399173fdc21603d9300d905@localhost>
On Wed, 2006-05-31 at 16:30, Auke Kok wrote:
> On Wed, 31 May 2006 14:31:05 +0530, Amit K Arora <aarora@in.ibm.com> wrote:
> >
> > Should these DPRINTKs be removed from the 2.6.x e1000 code as well ?
>
> they already are. the patch was merged in 7.0.38-k2 or so which is over a month ago.
I do not think these DPRINTKs have been removed from the latest code.
Or, they did get removed at some point of time, but somehow again got
added.
I checked in 2.16.17-rc4 kernel, and also in the following versions of
e1000 codebase (pulled from
git://lost.foo-projects.org/~ahkok/git/netdev-2.6):
e1000-7.0.38-k1, -k2 ... -k5
e1000-7.0.41
All of the above versions have the concerned DPRINTKs in e1000_suspend()
and other routines.
Please check once and let me know if I am missing something. Thanks!
> Also, if you are getting these errors there are several fixes in 7.0.38+ in the kernel that might be related. especially the WoL fix that re-enables the shutdown handler correctly might fix this issue for you. Please give this kernel/module a try (see http://www.mail-archive.com/netdev@vger.kernel.org/msg12689.html).
>
> Cheers,
>
> Auke
Regards,
Amit Arora
^ permalink raw reply
* Re: DPRINTKs in e1000 code (2.6.x kernels)
From: Auke Kok @ 2006-06-01 22:08 UTC (permalink / raw)
To: Amit Arora; +Cc: Auke Kok, netdev, amitarora
In-Reply-To: <1149199027.7160.22.camel@amitarora.in.ibm.com>
Amit Arora wrote:
> On Wed, 2006-05-31 at 16:30, Auke Kok wrote:
>> On Wed, 31 May 2006 14:31:05 +0530, Amit K Arora <aarora@in.ibm.com> wrote:
>>> Should these DPRINTKs be removed from the 2.6.x e1000 code as well ?
>> they already are. the patch was merged in 7.0.38-k2 or so which is over a month ago.
>
> I do not think these DPRINTKs have been removed from the latest code.
> Or, they did get removed at some point of time, but somehow again got
> added.
> I checked in 2.16.17-rc4 kernel, and also in the following versions of
> e1000 codebase (pulled from
> git://lost.foo-projects.org/~ahkok/git/netdev-2.6):
> e1000-7.0.38-k1, -k2 ... -k5
> e1000-7.0.41
>
> All of the above versions have the concerned DPRINTKs in e1000_suspend()
> and other routines.
>
> Please check once and let me know if I am missing something. Thanks!
git-show d0e027db7861ef03de0ac08494a9a61984d8f8b0
it's really in there - please use jgarzik's netdev#upstream branch. Not sure
if it already made it to 2.16.17-rc5, but I don't think this made it into
2.16.17-rc4, so that is where you may be missing it.
Auke
---
ref.:
diff-tree d0e027db7861ef03de0ac08494a9a61984d8f8b0 (from
a145410dccdb44f81d3b56763ef9b6f721f4e47c)
Author: Auke Kok <auke-jan.h.kok@intel.com>
Date: Fri Apr 14 19:04:40 2006 -0700
e1000: Remove PM warning DPRINTKs breaking 2.4.x kernels
remove DPRINTKs that were printing warnings about power management on
2.4 kernels. Since we really don't react differently these printk
statements are not needed. This code was originally added to fix
some compile time warnings that got fixed by newer kernels.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: John Ronciak <john.ronciak@intel.com>
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index add8dc4..ac1e838 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -4515,21 +4515,13 @@ e1000_suspend(struct pci_dev *pdev, pm_m
E1000_WRITE_REG(&adapter->hw, WUC, E1000_WUC_PME_EN);
E1000_WRITE_REG(&adapter->hw, WUFC, wufc);
- retval = pci_enable_wake(pdev, PCI_D3hot, 1);
- if (retval)
- DPRINTK(PROBE, ERR, "Error enabling D3 wake\n");
- retval = pci_enable_wake(pdev, PCI_D3cold, 1);
- if (retval)
- DPRINTK(PROBE, ERR, "Error enabling D3 cold wake\n");
+ pci_enable_wake(pdev, PCI_D3hot, 1);
+ pci_enable_wake(pdev, PCI_D3cold, 1);
} else {
E1000_WRITE_REG(&adapter->hw, WUC, 0);
E1000_WRITE_REG(&adapter->hw, WUFC, 0);
- retval = pci_enable_wake(pdev, PCI_D3hot, 0);
- if (retval)
- DPRINTK(PROBE, ERR, "Error enabling D3 wake\n");
- retval = pci_enable_wake(pdev, PCI_D3cold, 0);
- if (retval)
- DPRINTK(PROBE, ERR, "Error enabling D3 cold wake\n");
+ pci_enable_wake(pdev, PCI_D3hot, 0);
+ pci_enable_wake(pdev, PCI_D3cold, 0);
}
if (adapter->hw.mac_type >= e1000_82540 &&
@@ -4538,13 +4530,8 @@ e1000_suspend(struct pci_dev *pdev, pm_m
if (manc & E1000_MANC_SMBUS_EN) {
manc |= E1000_MANC_ARP_EN;
E1000_WRITE_REG(&adapter->hw, MANC, manc);
- retval = pci_enable_wake(pdev, PCI_D3hot, 1);
- if (retval)
- DPRINTK(PROBE, ERR, "Error enabling D3 wake\n");
- retval = pci_enable_wake(pdev, PCI_D3cold, 1);
- if (retval)
- DPRINTK(PROBE, ERR,
- "Error enabling D3 cold wake\n");
+ pci_enable_wake(pdev, PCI_D3hot, 1);
+ pci_enable_wake(pdev, PCI_D3cold, 1);
}
}
@@ -4554,9 +4541,7 @@ e1000_suspend(struct pci_dev *pdev, pm_m
pci_disable_device(pdev);
- retval = pci_set_power_state(pdev, pci_choose_state(pdev, state));
- if (retval)
- DPRINTK(PROBE, ERR, "Error in setting power state\n");
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
return 0;
}
@@ -4567,22 +4552,15 @@ e1000_resume(struct pci_dev *pdev)
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct e1000_adapter *adapter = netdev_priv(netdev);
- int retval;
uint32_t manc, ret_val;
- retval = pci_set_power_state(pdev, PCI_D0);
- if (retval)
- DPRINTK(PROBE, ERR, "Error in setting power state\n");
+ pci_set_power_state(pdev, PCI_D0);
e1000_pci_restore_state(adapter);
ret_val = pci_enable_device(pdev);
pci_set_master(pdev);
- retval = pci_enable_wake(pdev, PCI_D3hot, 0);
- if (retval)
- DPRINTK(PROBE, ERR, "Error enabling D3 wake\n");
- retval = pci_enable_wake(pdev, PCI_D3cold, 0);
- if (retval)
- DPRINTK(PROBE, ERR, "Error enabling D3 cold wake\n");
+ pci_enable_wake(pdev, PCI_D3hot, 0);
+ pci_enable_wake(pdev, PCI_D3cold, 0);
e1000_reset(adapter);
E1000_WRITE_REG(&adapter->hw, WUS, ~0);
^ permalink raw reply related
* Re: [openib-general] Re: [PATCH 1/2] iWARP Connection Manager.
From: Tom Tucker @ 2006-06-01 22:21 UTC (permalink / raw)
To: Sean Hefty; +Cc: Steve Wise, netdev, rdreier, linux-kernel, openib-general
In-Reply-To: <447F5778.6010202@ichips.intel.com>
On Thu, 2006-06-01 at 14:09 -0700, Sean Hefty wrote:
> Steve Wise wrote:
> >>>+int iw_cm_disconnect(struct iw_cm_id *cm_id, int abrupt)
> >>>+{
> >>>+ struct iwcm_id_private *cm_id_priv;
> >>>+ unsigned long flags;
> >>>+ int ret = 0;
> >>>+
> >>>+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
> >>>+ /* Wait if we're currently in a connect or accept downcall */
> >>>+ wait_event(cm_id_priv->connect_wait,
> >>>+ !test_bit(IWCM_F_CONNECT_WAIT, &cm_id_priv->flags));
> >>
> >>Am I understanding this check correctly? You're checking to see if the user has
> >>called iw_cm_disconnect() at the same time that they called iw_cm_connect() or
> >>iw_cm_accept(). Are connect / accept blocking, or are you just waiting for an
> >>event?
> >
> >
> > The CM must wait for the low level provider to finish a connect() or
> > accept() operation before telling the low level provider to disconnect
> > via modifying the iwarp QP. Regardless of whether they block, this
> > disconnect can happen concurrently with the connect/accept so we need to
> > hold the disconnect until the connect/accept completes.
> >
> >
> >>>+EXPORT_SYMBOL(iw_cm_disconnect);
> >>>+static void destroy_cm_id(struct iw_cm_id *cm_id)
> >>>+{
> >>>+ struct iwcm_id_private *cm_id_priv;
> >>>+ unsigned long flags;
> >>>+ int ret;
> >>>+
> >>>+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
> >>>+ /* Wait if we're currently in a connect or accept downcall. A
> >>>+ * listening endpoint should never block here. */
> >>>+ wait_event(cm_id_priv->connect_wait,
> >>>+ !test_bit(IWCM_F_CONNECT_WAIT, &cm_id_priv->flags));
> >>
> >>Same question/comment as above.
> >>
> >
> >
> > Same answer.
>
> There's a difference between trying to handle the user calling
> disconnect/destroy at the same time a call to accept/connect is active, versus
> the user calling disconnect/destroy after accept/connect have returned. In the
> latter case, I think you're fine. In the first case, this is allowing a user to
> call destroy at the same time that they're calling accept/connect.
> Additionally, there's no guarantee that the F_CONNECT_WAIT flag has been set by
> accept/connect by the time disconnect/destroy tests it.
The problem is that we can't synchronously cancel an outstanding connect
request. Once we've asked the adapter to connect, we can't tell him to
stop, we have to wait for it to fail. During the time period between
when we ask to connect and the adapter says yeah-or-nay, the user hits
ctrl-C. This is the case where disconnect and/or destroy gets called and
we have to block it waiting for the outstanding connect request to
complete.
One alternative to this approach is to do the kfree of the cm_id in the
deref logic. This was the original design and leaves the object around
to handle the completion of the connect and still allows the app to
clean up and go away without all this waitin' around. When the adapter
finally finishes and releases it's reference, the object is kfree'd.
Hope this helps.
>
> - Sean
> _______________________________________________
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
^ permalink raw reply
* Re: DPRINTKs in e1000 code (2.6.x kernels)
From: Auke Kok @ 2006-06-01 22:22 UTC (permalink / raw)
To: Auke Kok; +Cc: Amit Arora, Auke Kok, netdev, amitarora
In-Reply-To: <447F654A.3040406@intel.com>
Auke Kok wrote:
> Amit Arora wrote:
>> On Wed, 2006-05-31 at 16:30, Auke Kok wrote:
>>> On Wed, 31 May 2006 14:31:05 +0530, Amit K Arora <aarora@in.ibm.com>
>>> wrote:
>>>> Should these DPRINTKs be removed from the 2.6.x e1000 code as well ?
>>> they already are. the patch was merged in 7.0.38-k2 or so which is
>>> over a month ago.
>>
>> I do not think these DPRINTKs have been removed from the latest code.
>> Or, they did get removed at some point of time, but somehow again got
>> added.
>> I checked in 2.16.17-rc4 kernel, and also in the following versions of
>> e1000 codebase (pulled from
>> git://lost.foo-projects.org/~ahkok/git/netdev-2.6):
>> e1000-7.0.38-k1, -k2 ... -k5 e1000-7.0.41
>>
>> All of the above versions have the concerned DPRINTKs in e1000_suspend()
>> and other routines.
>>
>> Please check once and let me know if I am missing something. Thanks!
>
> git-show d0e027db7861ef03de0ac08494a9a61984d8f8b0
>
> it's really in there - please use jgarzik's netdev#upstream branch. Not
> sure if it already made it to 2.16.17-rc5, but I don't think this made
> it into 2.16.17-rc4, so that is where you may be missing it.
I'm in need of coffee - these changes got queued for 2.6.18. They're in
jgarziks netdev-2.6.git, but not anywhere in 2.6.17rcX
Auke
^ permalink raw reply
* RE: [openib-general] Re: [PATCH 1/2] iWARP Connection Manager.
From: Caitlin Bestler @ 2006-06-01 22:28 UTC (permalink / raw)
To: Tom Tucker, Sean Hefty
Cc: Steve Wise, netdev, rdreier, linux-kernel, openib-general
>>
>> There's a difference between trying to handle the user calling
>> disconnect/destroy at the same time a call to accept/connect is
>> active, versus the user calling disconnect/destroy after
>> accept/connect have returned. In the latter case, I think you're
>> fine. In the first case, this is allowing a user to call
> destroy at the same time that they're calling accept/connect.
>> Additionally, there's no guarantee that the F_CONNECT_WAIT flag has
>> been set by accept/connect by the time disconnect/destroy tests it.
>
> The problem is that we can't synchronously cancel an
> outstanding connect request. Once we've asked the adapter to
> connect, we can't tell him to stop, we have to wait for it to
> fail. During the time period between when we ask to connect
> and the adapter says yeah-or-nay, the user hits ctrl-C. This
> is the case where disconnect and/or destroy gets called and
> we have to block it waiting for the outstanding connect
> request to complete.
>
> One alternative to this approach is to do the kfree of the
> cm_id in the deref logic. This was the original design and
> leaves the object around to handle the completion of the
> connect and still allows the app to clean up and go away
> without all this waitin' around. When the adapter finally
> finishes and releases it's reference, the object is kfree'd.
>
> Hope this helps.
>
Why couldn't you synchronously put the cm_id in a state of
"pending delete" and do the actual delete when the RNIC
provides a response to the request? There could even be
an optional method to see if the device is capable of
cancelling the request. I know it can't yank a SYN back
from the wire, but it could refrain from retransmitting.
^ permalink raw reply
* Re: [RFT] Realtek 8168 ethernet support
From: Francois Romieu @ 2006-06-01 22:24 UTC (permalink / raw)
To: Daniel Drake; +Cc: netdev
In-Reply-To: <20060601200200.A0E0689D05D@zog.reactivated.net>
Daniel Drake <dsd@gentoo.org> :
[...]
> @@ -1442,20 +1444,24 @@ rtl8169_init_board(struct pci_dev *pdev,
> }
> }
>
> - /* make sure PCI base addr 1 is MMIO */
> - if (!(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) {
> - if (netif_msg_probe(tp)) {
> - printk(KERN_ERR PFX
> - "region #1 not an MMIO resource, aborting\n");
> - }
> - rc = -ENODEV;
> - goto err_out_mwi;
> + /* find MMIO resource: this varies between 8168 and 8169 */
> + for (i = 0; i < 5; i++) {
I'd rather use pci_device_id->driver_data but it's an option.
Btw a 0x8167 may be encountered too.
A diff between latest versions of Realtek's code suggests that
rtl_chip_info and mac_info need an update as well.
--
Ueimor
^ permalink raw reply
* Re: DPRINTKs in e1000 code (2.6.x kernels)
From: Amit K Arora @ 2006-06-01 10:04 UTC (permalink / raw)
To: Auke Kok; +Cc: Auke Kok, netdev, amitarora
In-Reply-To: <447F68A2.20605@intel.com>
Auke Kok wrote:
>
> I'm in need of coffee - these changes got queued for 2.6.18. They're in
> jgarziks netdev-2.6.git, but not anywhere in 2.6.17rcX
>
> Auke
Thanks for the clarification !
Regards,
Amit Arora
^ permalink raw reply
* e1000 fails to load sometimes: The EEPROM Checksum Is Not Valid
From: Jeremy Fitzhardinge @ 2006-06-01 23:47 UTC (permalink / raw)
To: john.ronciak, jesse.brandeburg, jeffrey.t.kirsher, auke-jan.h.kok,
cramerj
Cc: Linux Kernel Mailing List, netdev
With 2.6.17-rc5-mm2 (and other kernels), the e1000 fails to load
sometimes, with the message:
Intel(R) PRO/1000 Network Driver - version 7.0.38-k4-NAPI
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:02:00.0 to 64
e1000: 0000:02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid
e1000: probe of 0000:02:00.0 failed with error -5
Sometimes it will do this after several modprobe/rmmod cycles, and then
it will load OK. Once loaded, it seems to work perfectly.
This is this built-in e1000 in a Thinkpad X60:
02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet
Controller
The full lspci output:
00:00.0 Host bridge: Intel Corporation Mobile Memory Controller Hub (rev 03)
Subsystem: Lenovo Unknown device 2017
Flags: bus master, fast devsel, latency 0
Capabilities: [e0] Vendor Specific Information
00:02.0 VGA compatible controller: Intel Corporation Mobile Integrated Graphics Controller (rev 03) (prog-if 00 [VGA])
Subsystem: Lenovo Unknown device 201a
Flags: bus master, fast devsel, latency 0, IRQ 20
Memory at ee100000 (32-bit, non-prefetchable) [size=512K]
I/O ports at 1800 [size=8]
Memory at d0000000 (32-bit, prefetchable) [size=256M]
Memory at ee200000 (32-bit, non-prefetchable) [size=256K]
Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Capabilities: [d0] Power Management version 2
00:02.1 Display controller: Intel Corporation Mobile Integrated Graphics Controller (rev 03)
Subsystem: Lenovo Unknown device 201a
Flags: fast devsel
Memory at ee180000 (32-bit, non-prefetchable) [size=512K]
Capabilities: [d0] Power Management version 2
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
Subsystem: Lenovo Unknown device 2010
Flags: bus master, fast devsel, latency 0, IRQ 22
Memory at ee240000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
Capabilities: [70] Express Unknown type IRQ 0
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: ee000000-ee0fffff
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00003000-00004fff
Memory behind bridge: ec000000-edffffff
Prefetchable memory behind bridge: 00000000e4000000-00000000e4000000
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=04, subordinate=0b, sec-latency=0
I/O behind bridge: 00005000-00006fff
Memory behind bridge: e8000000-e9ffffff
Prefetchable memory behind bridge: 00000000e4100000-00000000e4100000
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=0c, subordinate=13, sec-latency=0
I/O behind bridge: 00007000-00008fff
Memory behind bridge: ea000000-ebffffff
Prefetchable memory behind bridge: 00000000e4200000-00000000e4200000
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02) (prog-if 00 [UHCI])
Subsystem: Lenovo Unknown device 200a
Flags: bus master, medium devsel, latency 0, IRQ 20
I/O ports at 1820 [size=32]
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02) (prog-if 00 [UHCI])
Subsystem: Lenovo Unknown device 200a
Flags: bus master, medium devsel, latency 0, IRQ 22
I/O ports at 1840 [size=32]
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02) (prog-if 00 [UHCI])
Subsystem: Lenovo Unknown device 200a
Flags: bus master, medium devsel, latency 0, IRQ 23
I/O ports at 1860 [size=32]
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02) (prog-if 00 [UHCI])
Subsystem: Lenovo Unknown device 200a
Flags: bus master, medium devsel, latency 0, IRQ 21
I/O ports at 1880 [size=32]
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
Subsystem: Lenovo Unknown device 200b
Flags: bus master, medium devsel, latency 0, IRQ 21
Memory at ee444000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=15, subordinate=18, sec-latency=32
I/O behind bridge: 00009000-0000cfff
Memory behind bridge: e4300000-e7ffffff
Prefetchable memory behind bridge: 00000000e0000000-00000000e3f00000
Capabilities: [50] #0d [0000]
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
Subsystem: Lenovo Unknown device 2009
Flags: bus master, medium devsel, latency 0
Capabilities: [e0] Vendor Specific Information
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP])
Subsystem: Lenovo Unknown device 200c
Flags: bus master, medium devsel, latency 0, IRQ 20
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at 1810 [size=16]
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controllers cc=AHCI (rev 02) (prog-if 01 [AHCI 1.0])
Subsystem: Lenovo Unknown device 200d
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 20
I/O ports at 18d0 [size=8]
I/O ports at 18c4 [size=4]
I/O ports at 18c8 [size=8]
I/O ports at 18c0 [size=4]
I/O ports at 18b0 [size=16]
Memory at ee444400 (32-bit, non-prefetchable) [size=1K]
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Capabilities: [70] Power Management version 2
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
Subsystem: Lenovo Unknown device 200f
Flags: medium devsel, IRQ 11
I/O ports at 18e0 [size=32]
02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
Subsystem: Lenovo Unknown device 207e
Flags: bus master, fast devsel, latency 0, IRQ 20
Memory at ee000000 (32-bit, non-prefetchable) [size=128K]
I/O ports at 2000 [size=32]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
Capabilities: [e0] Express Endpoint IRQ 0
03:00.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
Subsystem: IBM Unknown device 058a
Flags: bus master, fast devsel, latency 0, IRQ 22
Memory at edf00000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Capabilities: [50] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Capabilities: [60] Express Legacy Endpoint IRQ 0
Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b4)
Subsystem: Lenovo Unknown device 201c
Flags: bus master, medium devsel, latency 168, IRQ 20
Memory at e4300000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=15, secondary=16, subordinate=17, sec-latency=176
Memory window 0: e0000000-e1fff000 (prefetchable)
Memory window 1: e6000000-e7fff000
I/O window 0: 00009000-000090ff
I/O window 1: 00009400-000094ff
16-bit legacy interface ports at 0001
15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 09) (prog-if 10 [OHCI])
Subsystem: Lenovo Unknown device 201e
Flags: bus master, medium devsel, latency 64, IRQ 22
Memory at e4301000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [dc] Power Management version 2
15:00.2 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 18)
Subsystem: Lenovo Unknown device 201d
Flags: bus master, medium devsel, latency 0, IRQ 23
Memory at e4301800 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
What's going on here? How can this be fixed?
Thanks,
J
^ permalink raw reply
* Re: [RFT] Realtek 8168 ethernet support
From: Jeff Garzik @ 2006-06-02 1:38 UTC (permalink / raw)
To: Francois Romieu; +Cc: Daniel Drake, netdev
In-Reply-To: <20060601222436.GA12054@electric-eye.fr.zoreil.com>
On Fri, Jun 02, 2006 at 12:24:37AM +0200, Francois Romieu wrote:
> I'd rather use pci_device_id->driver_data but it's an option.
I would prefer this, too.
Jeff
^ permalink raw reply
* Re: [PATCH] softmac: Fix handling of authentication failure
From: Larry Finger @ 2006-06-02 2:43 UTC (permalink / raw)
To: Daniel Drake; +Cc: linville, netdev, johannes
In-Reply-To: <20060601143722.D0B2C89CF47@zog.reactivated.net>
Daniel Drake wrote:
> My router blew up earlier, but exhibited some interesting behaviour during
> its dying moments. It was broadcasting beacons but wouldn't respond to
> any authentication requests.
>
> I noticed that softmac wasn't playing nice with this, as I couldn't make it try
> to connect to other networks after it had timed out authenticating to my ill
> router.
>
> To resolve this, I modified the softmac event/notify API to pass the event
> code to the callback, so that callbacks being notified from
> IEEE80211SOFTMAC_EVENT_ANY masks can make some judgement. In this case, the
> ieee80211softmac_assoc callback needs to make a decision based upon whether
> the association passed or failed.
>
> Signed-off-by: Daniel Drake <dsd@gentoo.org>
> Acked-by: Johannes Berg <johannes@sipsolutions.net>
--snip--
> Index: linux/net/ieee80211/softmac/ieee80211softmac_assoc.c
> ===================================================================
> --- linux.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
> +++ linux/net/ieee80211/softmac/ieee80211softmac_assoc.c
> @@ -164,12 +164,28 @@ network_matches_request(struct ieee80211
> }
>
> static void
> -ieee80211softmac_assoc_notify(struct net_device *dev, void *context)
> +ieee80211softmac_assoc_notify_scan(struct net_device *dev, int event_type, void *context)
> {
> struct ieee80211softmac_device *mac = ieee80211_priv(dev);
> ieee80211softmac_assoc_work((void*)mac);
> }
>
> +static void
> +ieee80211softmac_assoc_notify_auth(struct net_device *dev, int event_type, void *context)
> +{
> + struct ieee80211softmac_device *mac = ieee80211_priv(dev);
> +
> + switch (event_type) {
> + case IEEE80211SOFTMAC_EVENT_AUTHENTICATED:
> + ieee80211softmac_assoc_work((void*)mac);
> + break;
> + case IEEE80211SOFTMAC_EVENT_AUTH_FAILED:
> + case IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT:
> + ieee80211softmac_disassoc(mac);
>
This statement fails to compile on my system using Linus' tree, because
ieee80211softmac_disassoc needs a second argument - the reason. It seems
as if WLAN_REASON_PREV_AUTH_NOT_VALID would be appropriate.
Larry
^ permalink raw reply
* Re: netif_tx_disable and lockless TX
From: Stephen Hemminger @ 2006-06-02 3:25 UTC (permalink / raw)
To: Robert Olsson
Cc: hadi, Herbert Xu, netdev, jgarzik, mchan, David Miller,
Andi Kleen
In-Reply-To: <17533.55270.172654.98522@robur.slu.se>
Robert Olsson wrote:
> jamal writes:
>
> > Latency-wise: TX completion interrupt provides the best latency.
> > Processing in the poll() -aka softirq- was almost close to the hardirq
> > variant. So if you can make things run in a softirq such as transmit
> > one, then the numbers will likely stay the same.
>
> I don't remember we tried tasklet for TX a la Herbert's suggestion but we
> used use tasklets for controlling RX processing to avoid hardirq livelock
> in pre-NAPI versions.
>
> Had variants of tulip driver with both TX cleaning at ->poll and TX
> cleaning at hardirq and didn't see any performance difference. The
> ->poll was much cleaner but we kept Alexey's original work for tulip.
>
> > Sorry, I havent been following discussions on netchannels[1] so i am not
> > qualified to comment on the "replacement" part Dave mentioned earlier.
> > What I can say is the tx processing doesnt have to be part of the NAPI
> > poll() and still use hardirq.
>
> Yes true but I see TX numbers with newer boards (wire rate small pakets)
> with cleaing in ->poll. Also now linux is very safe in network "overload"
> situations. Moving work to hardirq may change that.
>
>
>
I also noticed that you really don't save much by doing TX cleaning at
hardirq, because in hardirq you need to do dev_kfree_irq and that causes
a softirq (for the routing case where users=1). So when routing it
doesn't make much difference, both methods cause the softirq delayed
processing to be invoked. For locally generated packets which are
cloned, the hardirq will drop the ref count, and that is faster than
doing the whole softirq round trip.
^ permalink raw reply
* [patch 01/17] clean up initcall warning for netconsole
From: akpm @ 2006-06-02 3:32 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, mpm
From: Matt Mackall <mpm@selenic.com>
netconsole is being wrong here. If it wasn't enabled there's no error.
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/net/netconsole.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/netconsole.c~clean-up-initcall-warning-for-netconsole drivers/net/netconsole.c
--- devel/drivers/net/netconsole.c~clean-up-initcall-warning-for-netconsole 2006-06-01 20:31:49.000000000 -0700
+++ devel-akpm/drivers/net/netconsole.c 2006-06-01 20:31:49.000000000 -0700
@@ -107,7 +107,7 @@ static int init_netconsole(void)
if(!configured) {
printk("netconsole: not configured, aborting\n");
- return -EINVAL;
+ return 0;
}
if(netpoll_setup(&np))
_
^ permalink raw reply
* [patch 02/17] remove dead entry in net wan Kconfig
From: akpm @ 2006-06-02 3:32 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, paulkf
From: Paul Fulghum <paulkf@microgate.com>
Remove dead entry from net wan Kconfig. This entry is left over from 2.4
where synclink used syncppp driver directly. synclink drivers now use
generic HDLC
Signed-off-by: Paul Fulghum <paulkf@microgate.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/net/wan/Kconfig | 12 ------------
1 file changed, 12 deletions(-)
diff -puN drivers/net/wan/Kconfig~remove-dead-entry-in-net-wan-kconfig drivers/net/wan/Kconfig
--- devel/drivers/net/wan/Kconfig~remove-dead-entry-in-net-wan-kconfig 2006-06-01 20:31:49.000000000 -0700
+++ devel-akpm/drivers/net/wan/Kconfig 2006-06-01 20:31:49.000000000 -0700
@@ -134,18 +134,6 @@ config SEALEVEL_4021
The driver will be compiled as a module: the
module will be called sealevel.
-config SYNCLINK_SYNCPPP
- tristate "SyncLink HDLC/SYNCPPP support"
- depends on WAN
- help
- Enables HDLC/SYNCPPP support for the SyncLink WAN driver.
-
- Normally the SyncLink WAN driver works with the main PPP driver
- <file:drivers/net/ppp_generic.c> and pppd program.
- HDLC/SYNCPPP support allows use of the Cisco HDLC/PPP driver
- <file:drivers/net/wan/syncppp.c>. The SyncLink WAN driver (in
- character devices) must also be enabled.
-
# Generic HDLC
config HDLC
tristate "Generic HDLC layer"
_
^ permalink raw reply
* [patch 06/17] neighbour.c, pneigh_get_next() skips published entry
From: akpm @ 2006-06-02 3:32 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, Jari.Takkala, jari.takkala
From: "Jari Takkala" <Jari.Takkala@Q9.com>
Fix a problem where output from /proc/net/arp skips a record when the full
output does not fit into the users read() buffer.
To reproduce: publish a large number of ARP entries (more than 10 required
on my system). Run 'dd if=/proc/net/arp of=arp-1024.out bs=1024'. View
the output, one entry will be missing.
Signed-off-by: Jari Takkala <jari.takkala@q9.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
net/core/neighbour.c | 6 ++++++
1 file changed, 6 insertions(+)
diff -puN net/core/neighbour.c~neighbourc-pneigh_get_next-skips-published-entry net/core/neighbour.c
--- devel/net/core/neighbour.c~neighbourc-pneigh_get_next-skips-published-entry 2006-06-01 20:31:49.000000000 -0700
+++ devel-akpm/net/core/neighbour.c 2006-06-01 20:31:49.000000000 -0700
@@ -2138,6 +2138,12 @@ static struct pneigh_entry *pneigh_get_n
struct neigh_seq_state *state = seq->private;
struct neigh_table *tbl = state->tbl;
+ if (pos != NULL && *pos == 1 &&
+ (pn->next || tbl->phash_buckets[state->bucket])) {
+ --(*pos);
+ return pn;
+ }
+
pn = pn->next;
while (!pn) {
if (++state->bucket > PNEIGH_HASHMASK)
_
^ permalink raw reply
* [patch 03/17] eliminate unused /proc/sys/net/ethernet
From: akpm @ 2006-06-02 3:32 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, jes, jeff
From: Jes Sorensen <jes@sgi.com>
The /proc/sys/net/ethernet directory has been sitting empty for more than
10 years! Time to eliminate it!
Signed-off-by: Jes Sorensen <jes@sgi.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
net/ethernet/Makefile | 1 -
net/ethernet/sysctl_net_ether.c | 14 --------------
net/sysctl_net.c | 8 --------
3 files changed, 23 deletions(-)
diff -puN net/ethernet/Makefile~eliminate-unused-proc-sys-net-ethernet net/ethernet/Makefile
--- devel/net/ethernet/Makefile~eliminate-unused-proc-sys-net-ethernet 2006-06-01 20:31:49.000000000 -0700
+++ devel-akpm/net/ethernet/Makefile 2006-06-01 20:31:49.000000000 -0700
@@ -3,6 +3,5 @@
#
obj-y += eth.o
-obj-$(CONFIG_SYSCTL) += sysctl_net_ether.o
obj-$(subst m,y,$(CONFIG_IPX)) += pe2.o
obj-$(subst m,y,$(CONFIG_ATALK)) += pe2.o
diff -L net/ethernet/sysctl_net_ether.c -puN net/ethernet/sysctl_net_ether.c~eliminate-unused-proc-sys-net-ethernet /dev/null
--- devel/net/ethernet/sysctl_net_ether.c
+++ /dev/null 2006-06-01 17:04:03.273681250 -0700
@@ -1,14 +0,0 @@
-/* -*- linux-c -*-
- * sysctl_net_ether.c: sysctl interface to net Ethernet subsystem.
- *
- * Begun April 1, 1996, Mike Shaver.
- * Added /proc/sys/net/ether directory entry (empty =) ). [MS]
- */
-
-#include <linux/mm.h>
-#include <linux/sysctl.h>
-#include <linux/if_ether.h>
-
-ctl_table ether_table[] = {
- {0}
-};
diff -puN net/sysctl_net.c~eliminate-unused-proc-sys-net-ethernet net/sysctl_net.c
--- devel/net/sysctl_net.c~eliminate-unused-proc-sys-net-ethernet 2006-06-01 20:31:49.000000000 -0700
+++ devel-akpm/net/sysctl_net.c 2006-06-01 20:31:49.000000000 -0700
@@ -37,14 +37,6 @@ struct ctl_table net_table[] = {
.mode = 0555,
.child = core_table,
},
-#ifdef CONFIG_NET
- {
- .ctl_name = NET_ETHER,
- .procname = "ethernet",
- .mode = 0555,
- .child = ether_table,
- },
-#endif
#ifdef CONFIG_INET
{
.ctl_name = NET_IPV4,
_
^ 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