Re: [PATCH] softmac: don't send out packets while scanning
Johannes Berg <[EMAIL PROTECTED]> wrote:
>
> Yeah, thanks. I had realised that a while later but it was too late.
> Note that this blows up for me anyway so don't apply:
>
> [ 416.448315] SoftMAC: Start scanning with channel: 1
> [ 416.448331] SoftMAC: Scanning 14 channels
> [ 416.495245] NETDEV WATCHDOG: eth1: transmit timed out
> [ 416.495265] bcm43xx: Controller RESET (TX timeout) ...
Right. You can't stop the queue for a period longer than the watchdog
timeout (default is 5s) on the device. In fact there is a bug here in
that neither bcm43xx nor the softmac layer is setting trans_start.
Without that the message will trigger any time when you stop the queue
and the watchdog timer fires while it's stopped.
So I suggest that you first of all make sure that trans_start is set.
Then you need to ask yourself is this going to take a longer time than
a reasonable TX timeout. If the answer is no then you're fine.
Otherwise you need to do something more drastic to stop the traffic.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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
[PATCH wireless-dev] Move d80211-based drivers into new subdirectory
Move rt2x00 and bcm43xx-d80211 drivers into a new drivers/net/wireless/d80211 subdirectory. This directory is used for collecting wireless LAN drivers that use the Devicescape IEEE 802.11 stack (net/d80211). After applying this patch file, the existing directories must be moved with following commands: mv drivers/net/wireless/bcm43xx-d80211 drivers/net/wireless/d80211/bcm43xx mv drivers/net/wireless/rt2x00 drivers/net/wireless/d80211/rt2x00 Signed-off-by: Jouni Malinen <[EMAIL PROTECTED]> Index: wireless-dev/drivers/net/wireless/d80211/README === --- /dev/null +++ wireless-dev/drivers/net/wireless/d80211/README @@ -0,0 +1,2 @@ +This directory contains IEEE 802.11 wireless LAN drivers that are using +Devicescape IEEE 802.11 stack (net/d80211). Index: wireless-dev/drivers/net/wireless/Kconfig === --- wireless-dev.orig/drivers/net/wireless/Kconfig +++ wireless-dev/drivers/net/wireless/Kconfig @@ -506,8 +506,7 @@ config PRISM54 source "drivers/net/wireless/hostap/Kconfig" source "drivers/net/wireless/bcm43xx/Kconfig" -source "drivers/net/wireless/bcm43xx-d80211/Kconfig" -source "drivers/net/wireless/rt2x00/Kconfig" +source "drivers/net/wireless/d80211/Kconfig" # yes, this works even when no drivers are selected config NET_WIRELESS Index: wireless-dev/drivers/net/wireless/Makefile === --- wireless-dev.orig/drivers/net/wireless/Makefile +++ wireless-dev/drivers/net/wireless/Makefile @@ -37,9 +37,9 @@ obj-$(CONFIG_PRISM54) += prism54/ obj-$(CONFIG_HOSTAP) += hostap/ obj-$(CONFIG_BCM43XX) += bcm43xx/ -obj-$(CONFIG_BCM43XX_D80211) += bcm43xx-d80211/ -obj-$(CONFIG_RT2X00) += rt2x00/ - # 16-bit wireless PCMCIA client drivers obj-$(CONFIG_PCMCIA_RAYCS) += ray_cs.o obj-$(CONFIG_PCMCIA_WL3501)+= wl3501_cs.o + +# Drivers using Devicescape IEEE 802.11 stack (net/d80211) +obj-y += d80211/ Index: wireless-dev/drivers/net/wireless/d80211/Kconfig === --- /dev/null +++ wireless-dev/drivers/net/wireless/d80211/Kconfig @@ -0,0 +1,2 @@ +source "drivers/net/wireless/d80211/bcm43xx/Kconfig" +source "drivers/net/wireless/d80211/rt2x00/Kconfig" Index: wireless-dev/drivers/net/wireless/d80211/Makefile === --- /dev/null +++ wireless-dev/drivers/net/wireless/d80211/Makefile @@ -0,0 +1,2 @@ +obj-$(CONFIG_BCM43XX_D80211) += bcm43xx/ +obj-$(CONFIG_RT2X00) += rt2x00/ -- Jouni MalinenPGP id EFC895FA - 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
[PATCH wireless-dev] d80211: Replace MODULE_PARM with module_param
MODULE_PARM macro was removed and this broke net/d80211 build. Fix this by using module_param instead of MODULE_PARM. Signed-off-by: Jouni Malinen <[EMAIL PROTECTED]> Index: wireless-dev/net/d80211/ieee80211_ioctl.c === --- wireless-dev.orig/net/d80211/ieee80211_ioctl.c +++ wireless-dev/net/d80211/ieee80211_ioctl.c @@ -30,7 +30,7 @@ static int ieee80211_regdom = 0x10; /* FCC */ -MODULE_PARM(ieee80211_regdom, "i"); +module_param(ieee80211_regdom, int, 0444); MODULE_PARM_DESC(ieee80211_regdom, "IEEE 802.11 regulatory domain; 64=MKK"); /* @@ -40,7 +40,7 @@ MODULE_PARM_DESC(ieee80211_regdom, "IEEE * module. */ static int ieee80211_japan_5ghz /* = 0 */; -MODULE_PARM(ieee80211_japan_5ghz, "i"); +module_param(ieee80211_japan_5ghz, int, 0444); MODULE_PARM_DESC(ieee80211_japan_5ghz, "Vendor-updated firmware for 5 GHz"); -- Jouni MalinenPGP id EFC895FA - 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
Re: 2.4.32: unresolved symbol unregister_qdisc
On Sat, 8 Apr 2006 19:18:47 -0400 (EDT) George P Nychis wrote: > Yeah, this module is unfortunately not under the GPL, it was made for > research and i am not the author, I was only given the code for my own > research. > > I enabled that support in the kernel, and then tried to recompile and get > tons of errors/warnings... so maybe I am missing something else to be enabled > in the kernel... here are a few examples of errors: > /usr/include/linux/skbuff.h:30:26: net/checksum.h: No such file or directory > /usr/include/asm/irq.h:16:25: irq_vectors.h: No such file or directory > /usr/include/linux/irq.h:72: error: `NR_IRQS' undeclared here (not in a > function) > /usr/include/asm/hw_irq.h:28: error: `NR_IRQ_VECTORS' undeclared here (not in > a function) > > I think those are the top most errors, so if i can fix those hopefully the > rest shall vanish! Looks like a Makefile problem then. Can you post the Makefile? Hopefully it is using a Makefile and not just an elaborate gcc command line. [and please don't top-post] > - George > > > > From: "George P Nychis" <[EMAIL PROTECTED]> Date: Sat, 8 Apr 2006 18:47:34 > > -0400 (EDT) > > > >> Hey, > >> > >> I have a kernel module that uses unregister_qdisc and register_qdisc, > >> whenever i try to insert the module I get: > >> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: > >> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol > >> unregister_qdisc /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: > >> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol > >> register_qdisc > >> > >> Am i missing some sort of support in the kernel? > > > > Make sure CONFIG_NET_SCHED is enabled and that you compiled your module > > against that kernel. > > > > Where does this sch_xcp come from? It's not in the vanilla sources. > > > > Also, please direct networking questions to the netdev@vger.kernel.org > > mailing list which I have added to the CC:. --- ~Randy - 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
Re: 2.4.32: unresolved symbol unregister_qdisc
Yeah, this module is unfortunately not under the GPL, it was made for research and i am not the author, I was only given the code for my own research. I enabled that support in the kernel, and then tried to recompile and get tons of errors/warnings... so maybe I am missing something else to be enabled in the kernel... here are a few examples of errors: /usr/include/linux/skbuff.h:30:26: net/checksum.h: No such file or directory /usr/include/asm/irq.h:16:25: irq_vectors.h: No such file or directory /usr/include/linux/irq.h:72: error: `NR_IRQS' undeclared here (not in a function) /usr/include/asm/hw_irq.h:28: error: `NR_IRQ_VECTORS' undeclared here (not in a function) I think those are the top most errors, so if i can fix those hopefully the rest shall vanish! - George > From: "George P Nychis" <[EMAIL PROTECTED]> Date: Sat, 8 Apr 2006 18:47:34 > -0400 (EDT) > >> Hey, >> >> I have a kernel module that uses unregister_qdisc and register_qdisc, >> whenever i try to insert the module I get: >> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: >> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol >> unregister_qdisc /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: >> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol >> register_qdisc >> >> Am i missing some sort of support in the kernel? > > Make sure CONFIG_NET_SCHED is enabled and that you compiled your module > against that kernel. > > Where does this sch_xcp come from? It's not in the vanilla sources. > > Also, please direct networking questions to the netdev@vger.kernel.org > mailing list which I have added to the CC:. > > -- - 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
Re: 2.4.32: unresolved symbol unregister_qdisc
From: "George P Nychis" <[EMAIL PROTECTED]> Date: Sat, 8 Apr 2006 18:47:34 -0400 (EDT) > Hey, > > I have a kernel module that uses unregister_qdisc and register_qdisc, > whenever i try to insert the module I get: > /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: > /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol > unregister_qdisc > /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: > /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol > register_qdisc > > Am i missing some sort of support in the kernel? Make sure CONFIG_NET_SCHED is enabled and that you compiled your module against that kernel. Where does this sch_xcp come from? It's not in the vanilla sources. Also, please direct networking questions to the netdev@vger.kernel.org mailing list which I have added to the CC:. - 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
Fw: [Bugme-new] [Bug 6354] New: NULL Pointer lapbether
Begin forwarded message: Date: Sat, 8 Apr 2006 08:11:18 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 6354] New: NULL Pointer lapbether http://bugzilla.kernel.org/show_bug.cgi?id=6354 Summary: NULL Pointer lapbether Kernel Version: 2.6.14 2.6.15 2.6.16 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Problem Description: Lapbether generate an oops, when I try to receive or sends packets over X25. I think that the problem was introduced by this patch: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=86e65da9c1fc6fb421b9f796b597b3eced6b55ab The line skb->input_dev = skb->dev = dev; was removed from x25devices.h causing all drivers using x25_type_trans() to crash, because skb->dev stay unintialized. I think this line should have been replaced by skb->dev=dev; PS: Sorry for my bad english --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - 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
Re: [PATCH] softmac: don't send out packets while scanning
On Sat, 2006-04-08 at 13:33 +1000, Herbert Xu wrote: > Please use netif_wake_queue as otherwise packets can get stuck for quite > a while. Yeah, thanks. I had realised that a while later but it was too late. Note that this blows up for me anyway so don't apply: [ 416.448315] SoftMAC: Start scanning with channel: 1 [ 416.448331] SoftMAC: Scanning 14 channels [ 416.495245] NETDEV WATCHDOG: eth1: transmit timed out [ 416.495265] bcm43xx: Controller RESET (TX timeout) ... ... [ 416.995237] SoftMAC: Scanning finished any idea? johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 17/21] orinoco_pci: use pci_iomap() for resources
Pavel Roskin wrote:
Quoting Francois Romieu <[EMAIL PROTECTED]>:
Is there a reason why dev->mem_{start/end} should not be removed ?
Is there a reason why it should? Is it going to be obsolete?
It is slowly obsoleting for a few years (don't laugh...). It is preferred
to store the relevant address in the private part of the (pci) device.
Moderately recent drivers do not use it at all. However it's fairly common
in the setup code of the (legacy) isa devices.
I agree that many drivers don't use it. But it would be nice to have a document
describing what is going on. On one hand we are adding new information elements
(such as the bus in "ethtool -i"), on the other hand we are removing addresses
from the ifconfig output. Who is deciding which information is useful and
which is not?
Most of the ifconfig-exported stuff is obsolete, simply because most of
it is quite inappropriate for hardware more modern than ISA.
dev->mem_start has been a hacky way to pass options for over 10 years
now, since only few, rare drivers use it to specify the ISA memory
region for probing.
How about netdev->irq? Is it going to be obsolete too? Then I can easily
remove orinoco_pci_setup_netdev() with very minimal adjustments.
netdev->irq is obsolete as well. Some newer drivers don't even bother
to set it. With PCI, it became write-only, because modern drivers
autoprobe their irq, ignoring whatever the user requests. With PCI
MSI[-X] and even more modern hardware, dev->irq is just a cookie, not
something to program PCI_INTERRUPT_LINE with. So setting netdev->irq is
even less useful.
Programs which need to discover hardware information when given a
network interface name should do ETHTOOL_GDRVINFO, get the bus info, and
then obtain the information needed in a bus-specific way.
Jeff
-
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
Re: Broadcast ARP packets on link local addresses (Version2).
On Sat, 2006-08-04 at 13:27 +1000, Herbert Xu wrote: > I like the idea of allowing user-space to control what addresses cause > broadcasts. However, I'm uncomfortable with overloading existing flags > even though they might appear to fit the bill on the face of it. > > People may be using this for completely different reasons (address > selection) and it's not polite to suddenly turn all their ARPs into > broadcasts. > It would be interesting to see the creative ways in how people use the feature for src selection. IMO: the intent for link local is _auto config_ and src address selection or nexthop/route-scoping for link local is a side effect. But given that one could use the scope to manipulate src and nexthop, I wouldnt be shocked there are creative uses. > So how about a new address flag? We still have some vacancies there. I honestly dont know if we deserve to waste flag space for this. But I do agree this is such a grey area, so much so that it may require tossing a coin - given that the reason for broadcast ARPs is obscure. A simpler alternative is to have "config-arp-bcast-for-link-local" around those three lines which check for link local flag. Note: We also still have some ways to go before becoming fully conformant; I think we still forward these packets out as a router even though the specs say not to. cheers, jamal - 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
Re: [patch] ipv4: initialize arp_tbl rw lock
On Sat, Apr 08, 2006 at 03:14:04AM -0700, David S. Miller wrote: > Perhaps fs_initcall() would work better. Or if that causes > problems we could create a net_initcall() that sits between > fs_initcall() and device_initcall(). fs_initcall() seems to be used mainly for "init after subsystem" stuff. Within fs/ only pipe.c uses fs_initcall(). If we are going to overload the usage of fs_initcall() even more then we should maybe try to rename it? Sam - 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
Re: Fw: [Bugme-new] [Bug 6349] New: iptables DNAT returns unknown error 4294967295
Patrick McHardy wrote: > Please try if this patch helps. > > + .hooks = 1 << NF_IP_PRE_ROUTING || 1 << NF_IP_LOCAL_OUT, I shouldn't send patches before getting out of bed .. :) Please try this one instead. [NETFILTER]: Fix DNAT in LOCAL_OUT Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> --- commit 2ceefa038e908d5da21aefedae02da4eab1b2787 tree 417f03eca3b97b16a78321ace1556e57f5c60351 parent 8cc24d7ca2ffc6d9d70e1d94dc8dffbdf677e58f author Patrick McHardy <[EMAIL PROTECTED]> Sat, 08 Apr 2006 13:59:53 +0200 committer Patrick McHardy <[EMAIL PROTECTED]> Sat, 08 Apr 2006 13:59:53 +0200 net/ipv4/netfilter/ip_nat_rule.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/ipv4/netfilter/ip_nat_rule.c b/net/ipv4/netfilter/ip_nat_rule.c index efba8c4..1aba926 100644 --- a/net/ipv4/netfilter/ip_nat_rule.c +++ b/net/ipv4/netfilter/ip_nat_rule.c @@ -279,7 +279,7 @@ static struct ipt_target ipt_dnat_reg = .target = ipt_dnat_target, .targetsize = sizeof(struct ip_nat_multi_range_compat), .table = "nat", - .hooks = 1 << NF_IP_PRE_ROUTING, + .hooks = (1 << NF_IP_PRE_ROUTING) | (1 << NF_IP_LOCAL_OUT), .checkentry = ipt_dnat_checkentry, };
Re: Fw: [Bugme-new] [Bug 6349] New: iptables DNAT returns unknown error 4294967295
Andrew Morton wrote: > > Begin forwarded message: > > Date: Fri, 7 Apr 2006 06:12:07 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: [Bugme-new] [Bug 6349] New: iptables DNAT returns unknown error > 4294967295 > > > http://bugzilla.kernel.org/show_bug.cgi?id=6349 > >Summary: iptables DNAT returns unknown error 4294967295 > Kernel Version: 2.6.17-rc1 > Status: NEW > Severity: blocking > Owner: [EMAIL PROTECTED] > Submitter: [EMAIL PROTECTED] > > > Problem Description: > When I try to add the rule with target DNAT to the OUTPUT chain I get the > error > message: > [EMAIL PROTECTED]:~]# iptables -t nat -A OUTPUT -p tcp -d 192.168.1.1 --dport > 119 -j > DNAT --to-destination 192.168.1.10:8119 > iptables: Unknown error 4294967295 > > No rule is added, and the kernel says the message to the syslog: > Apr 7 15:20:05 dbagrii kernel: ip_tables: DNAT target: bad hook_mask 8 > > This error appears with iptables tool version 1.3.3 and 1.3.5 i tried to use. > > Steps to reproduce: > Run the iptables tool with this arguments: > $ iptables -t nat -A OUTPUT -p tcp -d 192.168.1.1 --dport 119 -j DNAT > --to-destination 192.168.1.10:8119 Please try if this patch helps. [NETFILTER]: Fix DNAT in LOCAL_OUT Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> --- commit 0fc7ff57191de5c09afe7db3932009963bba44d6 tree 02bc033088605bfd51fa4ea7ceb57d0aae1db65e parent 8cc24d7ca2ffc6d9d70e1d94dc8dffbdf677e58f author Patrick McHardy <[EMAIL PROTECTED]> Sat, 08 Apr 2006 13:52:18 +0200 committer Patrick McHardy <[EMAIL PROTECTED]> Sat, 08 Apr 2006 13:52:18 +0200 net/ipv4/netfilter/ip_nat_rule.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/ipv4/netfilter/ip_nat_rule.c b/net/ipv4/netfilter/ip_nat_rule.c index efba8c4..250b8ed 100644 --- a/net/ipv4/netfilter/ip_nat_rule.c +++ b/net/ipv4/netfilter/ip_nat_rule.c @@ -279,7 +279,7 @@ static struct ipt_target ipt_dnat_reg = .target = ipt_dnat_target, .targetsize = sizeof(struct ip_nat_multi_range_compat), .table = "nat", - .hooks = 1 << NF_IP_PRE_ROUTING, + .hooks = 1 << NF_IP_PRE_ROUTING || 1 << NF_IP_LOCAL_OUT, .checkentry = ipt_dnat_checkentry, };
Re: [patch] ipv4: initialize arp_tbl rw lock
> We could make inet_init() a subsystem init but I vaguely recall > that we were doing that at one point and it broke things for > some reason. > > Perhaps fs_initcall() would work better. Or if that causes > problems we could create a net_initcall() that sits between > fs_initcall() and device_initcall(). > > Or any other ideas? Just tried fs_initcall() and net_initcall(). Both seem to have some side effects: Symptom is that console output sometimes hangs for several seconds at: "NET: Registered protocol family 2" while all cpus are in cpu_idle(). Heiko - 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
Re: [patch] ipv4: initialize arp_tbl rw lock
Heiko Carstens <[EMAIL PROTECTED]> wrote: > > Ok, so the problem seems to be that inet_init gets called after qeth_init. > Looking at the top level Makefile this seems to be true for all network > drivers in drivers/net/ and drivers/s390/net/ since we have > > vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) > > The patch below works for me... I guess there must be a better way to make > sure that any networking driver's initcall is made before inet_init? > > Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> > --- > > Makefile |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index b401942..c5cea07 100644 > --- a/Makefile > +++ b/Makefile > @@ -567,7 +567,7 @@ # > # System.map is generated to document addresses of all kernel symbols > > vmlinux-init := $(head-y) $(init-y) > -vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) > +vmlinux-main := $(core-y) $(libs-y) $(net-y) $(drivers-y) I have a bad feeling that one day we're going to come unstuck with this practice. Is there anything which dictates that the linker has to lay sections out in .o-file-order? Perhaps net initcalls should be using something higher priority than device_initcall(). - 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
Re: [patch] ipv4: initialize arp_tbl rw lock
From: Heiko Carstens <[EMAIL PROTECTED]> Date: Sat, 8 Apr 2006 12:02:13 +0200 > Ok, so the problem seems to be that inet_init gets called after qeth_init. > Looking at the top level Makefile this seems to be true for all network > drivers in drivers/net/ and drivers/s390/net/ since we have > > vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) > > The patch below works for me... I guess there must be a better way to make > sure that any networking driver's initcall is made before inet_init? > > Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> We could make inet_init() a subsystem init but I vaguely recall that we were doing that at one point and it broke things for some reason. Perhaps fs_initcall() would work better. Or if that causes problems we could create a net_initcall() that sits between fs_initcall() and device_initcall(). Or any other ideas? - 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
Re: [patch] ipv4: initialize arp_tbl rw lock
> > The qeth driver makes use of the arp_tbl rw lock. CONFIG_DEBUG_SPINLOCK > > detects that this lock is not initialized as it is supposed to be. > > This is a initialization order problem then, because: > arp_init > neigh_table_init > rwlock_init > > does the initialization already. So fix the initialization sequence > of the qeth driver or you will have other problems. > > My impression was the -rt folks wanted all lock initializations t be > done at runtime not compile time. Ok, so the problem seems to be that inet_init gets called after qeth_init. Looking at the top level Makefile this seems to be true for all network drivers in drivers/net/ and drivers/s390/net/ since we have vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) The patch below works for me... I guess there must be a better way to make sure that any networking driver's initcall is made before inet_init? Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> --- Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index b401942..c5cea07 100644 --- a/Makefile +++ b/Makefile @@ -567,7 +567,7 @@ # # System.map is generated to document addresses of all kernel symbols vmlinux-init := $(head-y) $(init-y) -vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) +vmlinux-main := $(core-y) $(libs-y) $(net-y) $(drivers-y) vmlinux-all := $(vmlinux-init) $(vmlinux-main) vmlinux-lds := arch/$(ARCH)/kernel/vmlinux.lds - 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
Re: [PATCH] PCI Error Recovery: e100 network device driver
Linas Vepstas <[EMAIL PROTECTED]> :
> Index: linux-2.6.17-rc1/drivers/net/e100.c
> ===
> --- linux-2.6.17-rc1.orig/drivers/net/e100.c 2006-04-07 16:21:46.0
> -0500
> +++ linux-2.6.17-rc1/drivers/net/e100.c 2006-04-07 18:10:52.411266545
> -0500
[...]
> +static pci_ers_result_t e100_io_error_detected(struct pci_dev *pdev,
> pci_channel_state_t state)
80 cols limit.
[...]
> +static pci_ers_result_t e100_io_slot_reset(struct pci_dev *pdev)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
> + struct nic *nic = netdev_priv(netdev);
> +
> + if (pci_enable_device(pdev)) {
> + printk(KERN_ERR "e100: Cannot re-enable PCI device after
> reset.\n");
- The driver supports {get/set}_msglevel. Please consider using netif_msg_xxx
(see include/linux/netdevice.h).
- s/e100/DRV_NAME/ (or netdev->name, or pci_name(...) depending on the
context).
[...]
> +static struct pci_error_handlers e100_err_handler = {
> + .error_detected = e100_io_error_detected,
> + .slot_reset = e100_io_slot_reset,
> + .resume = e100_io_resume,
> +};
Nit: I'd rather follow the style in the declaration of e100_driver.
--
Ueimor
-
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
