> now that you put it that way, I get the merit of what you are saying.
> Very well. I will submit the first set of patches.
>
> May I add your "Tested-by"?
Yes, absolutely:
Tested-by: Roland Dreier
> > to preserve the legacy behavior rather than changing the behavior of
> > every usbnet driver all at once? Like make a new
> > usbnet_get_link_ksettings_nonmdio and update only cdc_ncm to use it?
>
> Then I would have to touch them all. The problem is that the MDIO
> stuff really is pretty much
I haven't tried these patches yet but they don't look quite right to
me. inlining the first 0001 patch:
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index 1447da1d5729..bcd17f6d6de6 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -944,7 +
> I looked at them again and found that there is a way to get
> the same effect that will make maintenance easier in the long run.
> Could I send them to you later this week for testing?
Yes, please. I have a good test setup now so I can easily try out patches.
Thanks,
Roland
> Applied to net and queued for LTS, thanks!
Thanks - is Oliver's series of 3 patches that get rid of the other
half of the log spam also on the way upstream?
- R.
m spamming the kernel log with
cdc_ncm 2-2:2.0 enp0s2u2c2: network connection: connected
messages every 60 msec or so.
Signed-off-by: Roland Dreier
---
drivers/net/usb/cdc_ncm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_n
On Tue, Dec 22, 2020 at 6:49 PM Jakub Kicinski wrote:
> I'm not sure what the story here is but if this change is expected to
> get into the networking tree we'll need a fresh posting. This sort of
> scissored reply does not get into patchwork.
OK, will resend. Too bad about patchwork, "git am"
[ 30.086548] cdc_ncm 2-2:2.0 enp0s2u2c2: network connection: connected
with the below patch on top of your 3, then my kernel log is clean.
Please apply your patches plus my patch, and feel free to add
Tested-by: Roland Dreier
to the other three.
--- 8< -- 8< ---
Subject: [PATCH] CDC-NCM:
> your criticism was valid. Could you test the attached patches?
Thanks - I will build a kernel and report back.
- R.
device is just sending
USB_CDC_NOTIFY_NETWORK_CONNECTION and USB_CDC_NOTIFY_SPEED_CHANGE urbs
over and over, and the driver logs every single one.
Should we add code to the driver to keep track of what the last event
was and only log if the state has really change?
Thanks!
Roland
Full details on
can provide you editing test on your photos.
Please reply if you are interested.
Thanks,
Roland
can provide you editing test on your photos.
Please reply if you are interested.
Thanks,
Roland
can provide you editing test on your photos.
Please reply if you are interested.
Thanks,
Roland
err kernel: BUG: scheduling while atomic: tc/23022/0x0200
Best regards,
Roland
Hello,
On Tue, Jan 30, 2018 at 9:46 AM, Roland Franke
wrote:
Hello,
Well, not min_qdisc things, but it should be resolved by:
commit efbf78973978b0d25af59bc26c8013a942af6e64
Author: Cong Wang
Date: Mon Dec 4 10:48:18 2017 -0800
net_sched: get rid of rcu_barrier() in
Hello,
On Mon, Jan 29, 2018 at 9:03 AM, Cong Wang
wrote:
On Mon, Jan 29, 2018 at 8:00 AM, Stephen Hemminger
wrote:
On Mon, 29 Jan 2018 16:18:07 +0100
"Roland Franke" wrote:
Hello,
> To: Roland Franke ; netdev@vger.kernel.org
> Subject: Re: BUG: iproute2 4.14.1 tc c
Hello,
To: Roland Franke ; netdev@vger.kernel.org
Subject: Re: BUG: iproute2 4.14.1 tc class add come to kernel-panic
tc qdisc add dev eth0 root handle 20: htb default 4 r2q 1
tc class add dev eth0 parent 20: classid 20:7 htb rate 1kbit
tc qdisc add dev eth0 parent 20:7 sfq perturb 10
tc
kernels from the 4.13 series,
i had no problem.Will this be solved in the kernel-series 4.14 or will this
only with the
coming series 4.15 be made?
Kernel 4.15 is not be tested till now.
Best regards,
Roland Franke
From: Roland Dreier
We need to check if p_ent->comp_mode is QED_SPQ_MODE_EBLOCK before
calling qed_spq_add_entry(). The test is fine is the mode is EBLOCK,
but if it isn't then qed_spq_add_entry() might kfree(p_ent).
Signed-off-by: Roland Dreier
---
drivers/net/ethernet/qlogic/qed/q
Your patch was damaged by the mailer you used.
Please fix and resubmit.
Sorry, now as attachment.
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index ae018fdf..2a27a56e 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -187,7 +187,8 @@ executes specified command over all objects, it depends if comm
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index ae018fdf..2a27a56e 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -187,7 +187,8 @@ executes specified command over all objects, it
depends if command supports this
.TP
.BR "\-c" , " -color"
-Use color output.
+Use color output. The color pa
> I think the conclusion is that a hard-wired ACS capability is a
> positive indication of isolation for a multifunction device, the code
> is intended to support this and appears to do so, and Roland was going
> to investigate the sightings that inspired this patch in more detail.
&g
> Is there a misunderstanding of the code flow here? We're never setting
> EC. In the first code block we're just masking out requested
> capabilities where unimplemented capabilities is the same as
> implemented + enabled. We're not adding EC to the request, we're
> just not removing it based o
> I think that the device implementing ACS and not implementing certain
> features that are "must be implemented if..." is a positive indication
> that the device does not have that behavior and therefore the ability
> to control that behavior is unnecessary. pci_acs_flags_enabled() is
> coded wit
On Thu, Jul 20, 2017 at 3:15 PM, Alex Williamson
wrote:
> Most of the ACS capabilities are worded as "Must be implemented by
> devices that implement ..." Shouldn't a hard-wired ACS capability
> sufficiently describe that, or is there something wrong with how
> they're hard wired?
Interesting q
From: Roland Dreier
Add one more variant of the 82599 plus the device IDs for X540 and X550
variants. Intel has confirmed that none of these devices does peer-to-peer
between functions. The X540 and X550 have added ACS capabilities in their
PCI config space, but the ACS control register is
On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe
wrote:
> So, it appears, the dst and neigh can be used for all performances cases.
>
> For the non performance dst == null case, can we just burn cycles and
> stuff the daddr in front of the packet at hardheader time, even if we
> have to copy?
OK,
On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe
wrote:
> We have neighbour_priv, and ndo_neigh_construct/destruct now ..
>
> A first blush that would seem to be enough to let ipoib store the AH
> and other path information in the neigh and avoid the cb? At least the
> example in clip sure looks li
>> struct skb_gso_cb {
>> int mac_offset;
>> int encap_level;
>> __u16 csum_start;
>> };
> This is based on an out-dated version of this struct. The 4.7 RC
> kernel has a few more fields that were added to support local checksum
> offload for encapsulated frames.
On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov wrote:
> Or just shift GSO CB and add couple checks like
> BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb)));
Resurrecting this old thread, because the patch that ultimately went
upstream (commit 9207f9d45b0a / net: preserve IP
From: Roland Dreier
Backports of 41fc014332d9 ("fib_rules: fix fib rule dumps across
multiple skbs") introduced a regression in "ip rule show" - it ends up
dumping the first rule over and over and never exiting, because 3.19
and earlier are missing commit 053c095a82cf (&quo
On Tue, Sep 22, 2015 at 9:40 PM, Roopa Prabhu wrote:
> + err = fib_nl_fill_rule(skb, rule, NETLINK_CB(cb->skb).portid,
> + cb->nlh->nlmsg_seq, RTM_NEWRULE,
> + NLM_F_MULTI, ops);
> + if (err)
FWI
Thanks, applied, although I assume based on the Signed-off-by line
that you left out a
From: Bryan Rosenburg <[EMAIL PROTECTED]>
at the top (to get the authorship in git correctly).
> RDMA/cxgb3: Shift calculation wrong for single sge entries.
BTW, there's no need to duplicate the subject li
there were no problems with undefined symbols.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/wireless/libertas/cmd.c
b/drivers/net/wireless/libertas/cmd.c
index eab0203..b3c1acb 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/lib
: Fail loopback connections
The cxgb3 HW and driver don't support loopback RDMA connections. So
fail any connection attempt where the destination address is local.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
> how can a static void function return 0?
good question... I've fixed the patch in my tree.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
applied, although:
> +static void is_loopback_dst(struct iw_cm_id *cm_id)
> +{
> +struct net_device *dev;
> +
> +dev = ip_dev_find(&init_net, cm_id->remote_addr.sin_addr.s_addr);
> +if (!dev)
> +return 0;
> +dev_put(dev);
> +return 1;
> +}
is there an
dware, so this is not
run-tested, but I tested the build with
CONFIG_LIBERTAS=y
CONFIG_LIBERTAS_USB=m
CONFIG_LIBERTAS_CS=m
CONFIG_LIBERTAS_SDIO=m
and there were no problems with undefined symbols.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
Here's the patch
thanks, just merged the same patch from Olof Johansson.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> Why not pull the exports? they aren't used anywhere in the existing kernel.
I'm guessing there's some not-(yet-)merged mesh networking stuff that
uses the symbols, but it doesn't matter much to me...
- R.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a me
conflict
Therefore, remove the static marking on lbs_remove_mesh and lbs_add_mesh.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/wireless/libertas/main.c
b/drivers/net/wireless/libertas/main.c
index 84fb49c..a688ce8 100644
--- a/drivers/net/wireless/libertas/
> On a 2GB Core2 system here I see a time cat /proc/net/tcp > /dev/null
> constently dropping from 0.44s to 0.4-0.8s system time with this change.
Seems like there must be a typo in either the before or after times
you report here?
--
To unsubscribe from this list: send the line "unsubscribe net
that it calls, which fixes
WARNING: drivers/net/cxgb3/built-in.o(.text+0x2427): Section mismatch in
reference from the function t3_io_slot_reset() to the function
.devinit.text:t3_prep_adapter()
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/mc5.c |2 +-
d
thanks, applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
thanks, applied 1-3
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Any objection to merging the following for 2.6.25?
[Rolf -- I think it makes more sense to delete the overwriting of the
P_Key in ipoib_multicast.c in this patch rather than later in the
series; do you agree?]
Thanks,
Roland
From: Rolf Manderscheid <[EMAIL PROTECTED]>
An IPoIB subnet
Commit 70eba18b ("make bnx2x select ZLIB_INFLATE") in Linus's tree
seems bogus. As far as I can tell, bnx2x is not upstream yet, and the
commit in question actually adds "select ZLIB_INFLATE" to the TEHUTI
config, since there is no BNX2X config option (and also I don't see
any reference to zlib in
> >> - skb = netdev_alloc_skb(lro_mgr->dev, hlen);
> >> + skb = netdev_alloc_skb(lro_mgr->dev, hlen + NET_IP_ALIGN);
> > NET_IP_ALIGN should only be used if you're DMAing into the skb head.
> > Otherwise you should say 2. It would be nice to have another macro
> > for that I suppo
OK, applied 1 and 2...
> Note: this change requires 5.0 firmware.
I assume the change to the cxgb3 FW versions is pending in a net
driver change for 2.6.25?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
> Agreed. On first glance, I was intrigued but:
>
> 1) Why is everyone so concerned that export symbol space is large?
> - does it cost cpu or running memory?
> - does it cause bugs?
> - or are you just worried about "evil modules"?
>
> 2) These aren't real namespaces
>
> Except C doesn't have namespaces and this mechanism doesn't create them. So
> this is just complete and utter makework; as I said before, noone's going to
> confuse all those udp_* functions if they're not in the udp namespace.
I don't understand why you're so opposed to organizing the ker
> > I agree that we shouldn't make things too hard for out-of-tree
> > modules, but I disagree with your first statement: there clearly is a
> > large class of symbols that are used by multiple modules but which are
> > not generically useful -- they are only useful by a certain small class
>
> Yes, and if a symbol is already used by multiple modules, it's generically
> useful. And if so, why restrict it to in-tree modules?
I agree that we shouldn't make things too hard for out-of-tree
modules, but I disagree with your first statement: there clearly is a
large class of symbols that
> This patch allows to export symbols only for specific modules by
> introducing symbol name spaces. A module name space has a white
> list of modules that are allowed to import symbols for it; all others
> can't use the symbols.
>
> It adds two new macros:
>
> MODULE_NAMESPACE_ALLOW(na
elf is what makes the most sense structurally.
I don't know if it matters to whatever use you are concerned with to have
two more steps in the lookup.
Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More ma
Oh, it seems it has indeed been that way for a very long time, so I was
mistaken. It still seems a little odd to me. Ulrich can say definitively
whether the kind of concern I mentioned really matters one way or the other
for glibc.
Thanks,
Roland
-
To unsubscribe from this list: send the line
has changed uids so it no longer has access to the group leader's
/proc/PID/fd, suddenly it using /proc/self/fd starts failing.
Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordom
thanks, applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> +/**
> + * nes_post_send
> + */
> +static int nes_post_send(struct ib_qp *ibqp, struct ib_send_wr *ib_wr,
> +struct ib_send_wr **bad_wr)
> ...
> +switch (ib_wr->opcode) {
> ...
> +if (ib_wr->num_sge >
> nesdev->nes
> +/* TODO: deal with EEPROM endian issues */
This is pretty scary. Is the driver broken on big-endian systems now?
> +/*
> +"Everything you wanted to know about CRC algorithms, but were afraid to ask
> + for fear that errors in your understanding might be detected." Version :
> 3.
e
> Thanks Roland. Let me know when you have your branch ready.
OK, I pushed out a "neteffect" branch at
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
This has the driver from your git tree plus some compile fixes and
cleanups (added as separate commits, s
OK, a couple quick review comments and a process comment too:
- First step in the driver is to kill off a lot of the #ifdefs:
> +#ifdef IRQF_SHARED
The upstream driver really shouldn't have compatibility gunk for older
kernels... just make it build against the kernel it's in.
> +#ifdef OFED_
> +config INFINIBAND_NES_DEBUG
> +bool "Verbose debugging output"
> +depends on INFINIBAND_NES
> +default n
> +---help---
> + This option causes the NetEffect RNIC driver to produce debug
> + messages. Select this if you are developing the driver
> + or tryin
> +
> +EXTRA_CFLAGS += -DNES_MINICM
I don't see anyplace NES_MINICM is used. Delete this line?
> +
> +obj-$(CONFIG_INFINIBAND_NES) += iw_nes.o
> +
> +iw_nes-objs := nes.o nes_hw.o nes_nic.o nes_utils.o nes_verbs.o nes_cm.o
> +
Also the file has an extra blank line at the beginning and en
> You are starting off on the wrong foot.
???
> > +if(!(expr)) {
> > \
> > + printk(KERN_ERR PFX "Assertion failed! %s, %s, %s, line %d\n", \
> > + #expr, __FILE__, __FU
Thanks... I am kind of overloaded trying to handle the last few things
for the 2.6.24 merge window, but I will look at this next week, and I
expect we should be able to merge the driver for 2.6.25 unless there
are unexpected hangups.
-
To unsubscribe from this list: send the line "unsubscribe netde
> +static void __iomem *mv643xx_eth_base;
> +return readl(((void __iomem *)mv643xx_eth_base) + offset);
Given the declaration of mv643xx_eth_base as void __iomem * already, I
don't understand why you need the cast to the same type here (and
elsewhere in the driver).
- R.
-
To unsubscribe
> The bonding sources have a few occurrences of EOPNOTSUPP. Unless I
> missed something, they are all related to setting the hardware address
> of the interface. AFAICS this is impossible with IP over FireWire. If
> it is crucial to bonding to be able to change the slaves' hardware
> addres
> It happens only when ib interfaces are slaves of a bonding device.
> I thought before that the stuck is in napi_disable() but it's almost right.
> I put prints before and after call to napi_disable and see that it is called
> twice.
> I'll try to investigate in this direction.
>
> ib0: s
> I also ran a test for the code in the branch of 2.6.24 and found a problem.
> I see that ifconfig down doesn't return (for IPoIB interfaces) and it's
> stuck in napi_disable() in the kernel (any idea why?)
For what it's worth, I took the upstream 2.6.23 git tree and merged in
Dave's latest n
Sorry... wrong subject here; it should have been "ibm_newemac: ..."
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ts to have multiple NAPI structures for a single net_device.
Compile-tested only as I don't have a system that uses the ibm_newemac
driver. This conversion the conversion for the ibm_emac driver that
was tested on real PowerPC 440SPe hardware.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]
The conversion to use netdevice internal stats left an unused variable
in ipoib_neigh_free(), since there's no longer any reason to get
netdev_priv() in order to increment dropped packets. Delete the
unused priv variable.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers
e multiple NAPI structures for a single net_device.
Tested with the internal MAC of a PowerPC 440SPe SoC with an AMCC
'Yucca' evaluation board.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/net/ibm_emac/ibm_emac_mal.c | 48 --
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index ce127b9..8ea5009 100644
--- a/drivers/net/ibm_newemac/core.c
> Before you add new entries to your list, how is that ibm driver NAPI
> conversion coming along? :-)
OK, thanks for the kick in the pants, I have a couple of patches for
net-2.6.24 coming (including an unrelated trivial warning fix for
IPoIB).
- R.
-
To unsubscribe from this list: send the li
> Before you add new entries to your list, how is that ibm driver NAPI
> conversion coming along? :-)
I still haven't done much. OK, I will try to get my board booting
again this week.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECT
> I'd say we can probably try to get rid of it in 2.6.25, this is
> assuming we get driver authors to cooperate and do the conversions
> or alternatively some other motivated person.
>
> I can just threaten to do them all and that should get the driver
> maintainers going :-)
I can definite
> I tested this by simulating a slow passive side responder, and it worked as
> expected for those tests. Using an MRA does add another MAD to the CM
> exchange,
> which is why it is sent only after seeing a duplicate request.
> Alternatively,
> we can take the OFED module parameter patch
Just as a quick update -- I seem to only be able to reproduce this
crash when my ppp session drops, which seems associated with marginal
signal. And unfortunately I have great coverage at home so I haven't
been able to reproduce this again today. Maybe on the train tomorrow
I can crash my laptop.
> Programming with assertions (and BUG_ON is a form of that) is
> generally a good practice. Almost any book or other source on
> good programming practices will agree. Yes, it can be overdone.
> But I don't really think that is the case here, since the check is
> relatively inexpensive and
> I don't want to jump the gun on the analysis but it just might
> be the packet sharing fixes Herbert put in a short time ago.
>
> What you could do is go back to say rc2 and see if you still get
> the panics, then bisect from there to narrow it down.
>
> If rc2 still gives the panic, it'
I'm running 2.6.23-rc9 on my laptop, and when in a coffee shop I use
a Verizon EVDO card to get network access. This is a kyocera device
that looks like a serial adapter behind an ohci usb controller, and
uses the airprime driver (for usb device 0c88:17da). The actual IP
networking is ppp over th
> It would be really great to see numbers with a more recent kernel
> than 2.6.18
FWIW Debian has binaries for 2.6.21 in testing and for 2.6.22 in
unstable so it should be very easy for Larry to try at least those.
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
> >OK -- just to make sure I'm understanding what you're saying: have you
> >confirmed that your proposed [CM MRA] patches actually fix the issue?
>
> Not directly. I cannot easily test kernel patches on our larger, production
> clusters. We've seen the issue with specific applications on 5
> How is that ibm_emac NAPI conversion coming along? :-)
Sorry, trying to reduce my backlog first, but it is still on my list
of things to work on :)
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
Use the stats member of struct netdevice in IPoIB, so we can save
memory by deleting the stats member of struct ipoib_dev_priv, and save
code by deleting ipoib_get_stats().
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
Dave, can you queue this in net-2.6.24 please? I would ordi
> Roland, are you comfortable with the IB changes in patches 1 and 2?
Yes, they look fine to me. Feel free to apply, with
Acked-by: Roland Dreier <[EMAIL PROTECTED]>
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
> The action in bonding to a detach of slave is to unregister the master (see
> patch 10).
> This can't be done from the context of unregister_netdevice itself (it is
> protected by rtnl_lock).
I'm confused. Your patch has:
> +ipoib_slave_detach(cpriv->dev);
> un
> Just change the makefiles to always install gzip'ed modules
> modutils knows how to unzip them on the fly.
But that leaves the uncompressed firmware blobs in .data that ends up
in unswappable kernel memory.
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
> Roland - can you please queue this up for 2.6.24?
Done, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> +ipoib_slave_detach(cpriv->dev);
> unregister_netdev(cpriv->dev);
Maybe you already answered this before, but I'm still not clear why
this notifier call can't just be added to the start of
unregister_netdevice(), so we can avoid having driver needing to know
anything a
l
> push all the patches to the networking git. Is it OK with you Roland?
Yes, that's fine.
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
mutex_unlock(&lock);
> }
I don't understand this code. It seems you keep track of the minimum
timeout, and then ignore the value you computed. What am I missing?
Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> One other thing I observed is that I can not unload the module as the
> ref counter of the eth device is too low. I haven't tracked down the
> source of this problem yet.
I suspect that this is because netif_rx_reschedule() was missing a
dev_hold() to match the dev_put() in netif_rx_complete
> > and I think that is only in Dave's net-2.6.24 tree now, right?
>
> Nope, that was what I downloaded yesterday:
>
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 23
> EXTRAVERSION =-rc6
> NAME = Pink Farting Weasel
Please double check your tree. I just very carefully looked at my
trees,
> Further complicating things is that you need to setup a ppc32
> cross-build environment to even build test a conversion, and I'm not
> comfortable doing the surgery until I can test build the thing.
OK, I actually have a system with a ppc 440 SoC that uses this driver,
so I'll try to get thin
It looks like the comments for dev_put() and dev_hold() got reversed somehow.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
include/linux/netdevice.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
Krishna Kumar
<[EMAIL PROTECTED]> with IPoIB waiting forever for netdev refcounts
to become 0 during module unload.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
Dave, feel free to roll this up into earlier NAPI conversion patches
(assuming I'm understanding things correct
> Maybe this new notification function should be in net/core/dev.c
> instead of exporting call_netdevice_notifiers()?
Or actually, does it work to add the call to the notifiers directly in
unregister_netdev() so that device drivers don't have to worry about it?
(And is the existing patch missin
1 - 100 of 325 matches
Mail list logo
