Re: dscape doesn't auto associate
Jon Smirl wrote: Has this project moved elsewhere? http://hostap.epitest.fi/wpa_supplicant Apparently it's down at this moment: http://permalink.gmane.org/gmane.linux.drivers.hostap/15287 - 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] d80211: select CRC32 functions
The d80211 stack requires CRC32 functions for the WEP implementation. Signed-off-by: Marcus Better [EMAIL PROTECTED] --- net/d80211/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/d80211/Kconfig b/net/d80211/Kconfig index 7e2635f..d91f0db 100644 --- a/net/d80211/Kconfig +++ b/net/d80211/Kconfig @@ -3,6 +3,7 @@ config D80211 select CRYPTO select CRYPTO_ARC4 select CRYPTO_AES + select CRC32 select WIRELESS_EXT ---help--- This option enables the hardware independent IEEE 802.11 -- - 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][NET_SCHED] sch_htb: htb_class optimization
Hello,
Some time ago Patrick McHardy suggested to separate
structures of htb_class for inner and leaf. Currently
they are part of an union and because of big difference
in their sizes some memory is unnecessary used for leaves.
Here is my preliminary proposal. It's done with a premise
to change (or to work) as little as possible, so it isn't
probably the optimal solution, but if it's really bad or
could be much better without serious rewriting, I'd like
to know your suggestions. From the above reasons it's also
not tested - I'd better do it with something accepted,
just a little.
Regards,
Jarek P.
---
[PATCH][NET_SCHED] sch_htb: htb_class optimization
htb_class_leaf and htb_class_inner are separated from
main htb_class structure to use memory more effectively.
Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
---
diff -Nurp linux-2.6.20-rc5-/net/sched/sch_htb.c
linux-2.6.20-rc5/net/sched/sch_htb.c
--- linux-2.6.20-rc5-/net/sched/sch_htb.c 2007-01-08 20:23:58.0
+0100
+++ linux-2.6.20-rc5/net/sched/sch_htb.c2007-01-24 07:54:21.0
+0100
@@ -85,6 +85,26 @@ enum htb_cmode {
HTB_CAN_SEND/* class can send */
};
+
+struct htb_class_leaf {
+ struct Qdisc *q;
+ int aprio;
+ int deficit[TC_HTB_MAXDEPTH];
+ struct list_head drop_list;
+};
+
+struct htb_class_inner {
+ struct rb_root feed[TC_HTB_NUMPRIO];/* feed trees */
+ struct rb_node *ptr[TC_HTB_NUMPRIO];/* current class ptr */
+ /*
+* When class changes from state 1-2 and disconnects from
+* parent's feed then we lost ptr value and start from the
+* first child again. Here we store classid of the
+* last valid ptr (used when ptr is NULL).
+*/
+ u32 last_ptr_id[TC_HTB_NUMPRIO];
+};
+
/* interior leaf nodes; props specific to leaves are marked L: */
struct htb_class {
/* general class parameters */
@@ -109,23 +129,8 @@ struct htb_class {
struct list_head children; /* children list */
union {
- struct htb_class_leaf {
- struct Qdisc *q;
- int prio;
- int aprio;
- int quantum;
- int deficit[TC_HTB_MAXDEPTH];
- struct list_head drop_list;
- } leaf;
- struct htb_class_inner {
- struct rb_root feed[TC_HTB_NUMPRIO];/* feed trees */
- struct rb_node *ptr[TC_HTB_NUMPRIO];/* current
class ptr */
- /* When class changes from state 1-2 and disconnects
from
- parent's feed then we lost ptr value and start from
the
- first child again. Here we store classid of the
- last valid ptr (used when ptr is NULL). */
- u32 last_ptr_id[TC_HTB_NUMPRIO];
- } inner;
+ struct htb_class_leaf *leaf;
+ struct htb_class_inner *inner;
} un;
struct rb_node node[TC_HTB_NUMPRIO];/* node for self or feed tree */
struct rb_node pq_node; /* node for event queue */
@@ -148,11 +153,51 @@ struct htb_class {
long tokens, ctokens; /* current number of tokens */
psched_time_t t_c; /* checkpoint time */
- int prio; /* For parent to leaf return possible here */
- int quantum;/* we do backup. Finally full replacement */
- /* of un.leaf originals should be done. */
+ int prio; /* Used only by leaves but made common for */
+ int quantum;/* parent to leaf change after class delete. */
};
+#define HTB_DEBUG_MM 1
+#ifdef HTB_DEBUG_MM
+static int htb_debug_mm[3];
+
+static inline void HTB_DEBUG_LEAF(int sign)
+{
+ if ((htb_debug_mm[0] += sign * sizeof(struct htb_class_leaf)) 0) {
+ printk(htb_class_leaf kfree error);
+ BUG();
+ }
+}
+
+static inline void HTB_DEBUG_INNER(int sign)
+{
+ if ((htb_debug_mm[1] += sign * sizeof(struct htb_class_inner)) 0) {
+ printk(htb_class_inner kfree error);
+ BUG();
+ }
+}
+
+static inline void HTB_DEBUG_CLASS(int sign)
+{
+ if ((htb_debug_mm[2] += sign * sizeof(struct htb_class)) 0) {
+ printk(htb_class kfree error);
+ BUG();
+ }
+}
+
+static inline void HTB_DEBUG_CLASSES(void)
+{
+ if (htb_debug_mm[0] || htb_debug_mm[1] || htb_debug_mm[2])
+ printk(htb_classes error: %d %d %d\n,
+ htb_debug_mm[0], htb_debug_mm[1], htb_debug_mm[2]);
+}
+#else
+static inline void HTB_DEBUG_LEAF(int sign) {}
+static inline void HTB_DEBUG_INNER(int sign) {}
+static inline void HTB_DEBUG_CLASS(int sign) {}
+static inline void HTB_DEBUG_CLASSES(void) {}
+#endif
+
/* TODO: maybe compute rate when size is too
Re: Can someone please try...
On Wednesday 24 January 2007 06:43, Pavel Roskin wrote: On Tue, 2007-01-23 at 10:21 +0100, Michael Buesch wrote: On Tuesday 23 January 2007 07:14, Pavel Roskin wrote: I have tried the patch, and it doesn't fix the problem. It's a separate problem. It happens when bcm43xx_interrupt_handler() is called on a device that has already been removed. That shouldn't happen and doesn't for me. It looks like bcm43xx_wireless_core_stop() should be called from bcm43xx_one_core_detach(). No, well... . remove_interface should have been called by the stack, no? It is not. It's called if I bring the interface down with ifconfig. If I remove live interface with rmmod bcm43xx_d80211, bcm43xx_one_core_detach() is called first, followed by kernel panic in bcm43xx_interrupt_handler(). And that's what I see in the code. Module removal calls bcm43xx_exit(). It unregisters the ssb driver first. The ssb layer calls bcm43xx_remove(), which calls bcm43xx_one_core_detach() before doing anything with the wireless stack or with interrupts. I tried to put bcm43xx_one_core_detach() to the end of bcm43xx_remove(), but the result was the same. Still, I think the solution lies in that direction. We should stop the hardware before dismantling any data structures. Ok, I see. I will try to debug this. -- Greetings Michael. - 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
Retransmission and packet handling in the TCP-code
Hello, I have recently started working with the Linux-kernel TCP-code with regards to implementing a few (hopefully good) algorithms. But I want to make sure that I have understood everything correctly before I start implementing, so I have a few questions. 1. Are the skb's aware of the sk_buff_head? E.g. does the prev pointer of the last skb (the one that buff_head-next points to) in the write queue point to buff_head or to the first skb? 2. Is the only thing that seperates a for instance lost packet from a recently queued one the value of the tcp_skb_cb-sacked-variable (from the kernels point of view)? (Except for the fact that send_head might point to the recently queued one). 3. When a retransmission occur, are all the lost packets resent or just n-1 of them? A couple of my friends claim that the latter is true, but I can't find anything in the source code to support that. My theory is that they (my friends) don't count the packet that triggers the retransmission, even though this is also retransmitted. 4. Does the kernel bundle two and two packets (if possible) during retransmission? The same friends that told me about the n-1-thing, also told me that the kernel tries to bundle as many packets as possible. But I can't find anything in the code to support this, as far as can see it tries to bundle two packets (skb's) and sends the new packet (or this first one, if the collapse wasnt succsessful) to tcp_transmit_skb() (and then it is to late to bundle any more). 5. Say that you have sent three packets (called p1, p2 and p3) and p2 arrives succsessfully, but p1 doesn't and triggers a timeout. If I have understod the code correctly, the kernel will try to collapse p1 and p3 and send the combined packet if successfully (or just p1). If we assume that the collapse took place and that p3 got lost, how does the reciever detect what part of the data (in the packet) belongs to p1 and p3? To me it seems that tcp_retrans_try_collapse() appends all the data from (in this case) p3 to the data-field of p1, without e.g. marking that the last 25 bytes belongs to p3. Thanks in advance for any answers and have a good day :) -Kristian - 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: [IPV6] RAW: Add checksum default defines for MH.
David Miller wrote: From: Herbert Xu [EMAIL PROTECTED] Date: Wed, 24 Jan 2007 17:56:23 +1100 David Miller [EMAIL PROTECTED] wrote: Did a complete agreement occur that this patch is ok? My only concern is that we're putting an arbitrary list of protocols in the generic raw.c. What's the justification for including these protocols in particular but not others? Is there any reason why the application can't just use the existing IPV6_CHECKSUM socket option to set the same fields? My understanding in the MH case is that the kernel is going to make changes to the header that the user can't predict and thus it's impossible for them to set the correct checksum. Yes, kernel will change the IPv6 header address, however, actually it is possible to compute MH checksum by user-space since final address (=home address) is seen by application on both sending and receiving case and the checksum is calculated by the address. It is true user can use IPV6_CHECKSUM option to set the same fields. (FYI, it is failed to validate MH checksum with IPv6 header address on wire (or before parsing extension headers) for such Mobile IPv6 routing optimized packet). So this fix is not mandatory feature for kernel. This patch just relaxes user application like ICMPv6 case then we can cancel this if it is too much. Thanks for taking care of this again, guys. -- Masahide NAKAMURA - 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: dscape doesn't auto associate
On Tue, 2007-01-23 at 20:48 -0500, Jon Smirl wrote: On 1/23/07, Michael Wu [EMAIL PROTECTED] wrote: On Tuesday 23 January 2007 18:23, Jon Smirl wrote: I have to manually associate the dscape stack with my AP. Is this way the code is supposed to work? Everything works ok after the manual association. It's suppose to work with wpa_supplicant which sets every parameter. NetworkManager uses wpa_supplicant so configuration can be pretty easy. Something isn't working right with NetworkManager for me. I have both zd1211 and rt2570 devices and neither will start automatically but I can get the going manually. I'll try running NetworkManager in the debugger and see if I can figure out what is failing. NetworkManager is working ok for me on non-dscape devices. As for running as an AP: rt2570 will start in Master mode zd1211 refused to set Master mode zd1211 has this problem too: Error for wireless request Set Encode (8B2A) : SET failed on device wlan1 ; Invalid argument. If you get this error in the _NM_ logs, it's likely just trying to clear out the key, and you can probably ignore it. If you get this error from wpa_supplicant, it's probably a driver issue. Can you send me some logs privately? I think SUSE directs the NM logs somewhere like /var/log/NetworkManager.log. Stop NM as a service, get root, then NetworkManager --no-daemon and redirect the output to a file if you don't want to track down the logs themselves. Cheers, Dan If you really want to manually associate, set the channel, (e)ssid, and encryption (if any) in any order, and then set the bssid (ap) last. There will be patches to allow association by just setting the SSID for backwards compatibility with configuration scripts. -Michael Wu - 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: dscape doesn't auto associate
Dan Williams wrote: If you get this error in the _NM_ logs, it's likely just trying to clear out the key, and you can probably ignore it. If you get this error from wpa_supplicant, it's probably a driver issue. Can you send me some logs privately? I think SUSE directs the NM logs somewhere like /var/log/NetworkManager.log. Stop NM as a service, get root, then NetworkManager --no-daemon and redirect the output to a file if you don't want to track down the logs themselves. The log is in /var/log/NetworkManager on openSUSE 10.2. Using bcm43xx-softmac, the returned frequency is 0. Any suggestions on where I should look to get the proper frequency or channel data? Larry - 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 REPOST 1/2] NET: Accurate packet scheduling for ATM/ADSL (kernel)
Russell Stuart wrote: On Sat, 2007-01-20 at 09:47 +0100, Patrick McHardy wrote: Russell Stuart wrote: b. There is no compatibility problem. Again, (b). You seem to have something in mind, it would be easier if you would just explain exactly where you think there is a problem. I though I had :(. Consider: Line speed is 256 K bits/sec. Protocol: ADSL/ATM (PPPoE VC/LLC) (Overhead is 42 bytes + cell pad). Kernel HZ is 1000. cell_log = 8. Below is a table which shows the RTAB that would be sent to a pre-STAB kernel: IP Datagram Packet Size Packet Size Ticks to Packet Size Seen by KernelOn the Wire Send packet RTAB[0]=2-14..-7 0..7 53..53 1.656 RTAB[1]=2 -6..1 8..1553..53 1.656 RTAB[2]=3 2..9 16..2353..106 3.313 RTAB[3]=3 10..17 24..31 106..106 3.313 ... RTAB[9]=5 58..63 72..79 106..159 4.968 RTAB[10]=564..71 80..87 159..159 4.968 Below is the same thing for a post-STAB kernel: IP Datagram Packet Size Packet Size Ticks to Packet Size Seen by KernelOn the Wire Send packet RTAB[0]=0 - Undefined as no STAB entry is 0. RTAB[1]=0 - Undefined as no STAB entry is 0. ... RTAB[5]=0 - Undefined as no STAB entry is 0. RTAB[6]=2-14..-7 0..7 53..53 1.656 RTAB[7]=2 -6..1 8..1553..53 1.656 RTAB[8]=3 2..9 16..2353..106 3.313 RTAB[9]=3 10..17 24..31 106..106 3.313 ... RTAB[15]=558..63 72..79 106..159 4.968 RTAB[16]=564..71 80..87 159..159 4.968 The two RTAB's are different. Thus you must send different RTAB's to pre-STAB and post-STAB kernels. How is tc to decide which one to send? I did add code that checked uname once to solve a very similar problem in tc, but that got my wrist slapped. If the users asks to use STABs, send the modified RTAB. If the kernel doesn't support STABs it will return an error, which is good enough. Replacing RTAB with STAB would solve the problem, BTW, as the post-STAB kernel would ignore the RTAB. It would also solve another problem. The granularity of RTAB sucks for VOIP (my area of interest). Eg on a 2 M bit link, one ATM cell takes 0.0848 ticks to send, two cells 0.170 ticks, three cells 0.2544 ticks. RTP voice packets are typically two or three cells. RTAB only holds an integral number of ticks of course, making the current traffic control engine useless for VOIP links with speeds of around 2.5M bit or above. This could be fixed in an STAB implementation. I think this is a different problem. If you replace RTABs by STABs you again can't use it for anything that is only interested in the size, not the transmission time (HFSC, SFQ, ...). - 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] Marvell Libertas 8388 802.11b/g USB driver (v2)
On Thu, Jan 18, 2007 at 03:22:50AM -0500, John W. Linville wrote: On Wed, Jan 17, 2007 at 06:19:07PM -0500, Jeff Garzik wrote: Christoph Hellwig wrote: On Wed, Jan 17, 2007 at 01:00:47PM -0500, Dan Williams wrote: allows the 8388 to continue routing other laptops' packets over the mesh *while the host CPU is asleep*. We're not going to put a lot of junk into the kernel just because the OLPC folks decide to do odd powermanagment schemes. We're not going to ignore useful power management schemes just because they don't fit neatly into a pre-existing category. I think the request to determine how all this maps into MLME is fair, though. Definitely. Also, I wonder if there was any attempt to evaluate how the ieee80211 (or d80211) code might be extended in order to elimnate the need for some of the libertas wlan_* files? The regulatory domain structures, channel information (struct ieee80211_channel), HW mode (struct ieee80211_hw_mode) compromised of supported channels and rates, and probably a few others in the same category. I can't see the possibility of using d80211 as it stands (designed for softmac cards dealing with 802.11 packets to/from the OS). However, it does not make any sense to use the structures defined by d80211 if not effectively using it (we send/receive 802.3 frames to the firmware, after all), IMO. As discussed on this thread, there is a lot of code to be cleanup up, but no structural changes AFAICT. Is there a general agreement on that, now? - 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.6.19.2 sky2/acpi crashes
On Tue, 23 Jan 2007 09:59:28 +0100 Lionel Landwerlin [EMAIL PROTECTED] wrote: Hi, I'm running a macbook with a Marvell ethernet controller, and I have a lots of freezes when using the ethernet controller under a load of ~100K/s. Since I'm running a 2.6.19.2 kernel, I'm able to get some report from the kernel. Here they are : Please send sky2 bugs to me [EMAIL PROTECTED] and [EMAIL PROTECTED] I hope some fix could be released soon. I get problem reports all the time, unfortunately, so far these have not been reproducible on the configurations and hardware I have. I am not denying there is a problem, but if I can't reproduce it, it takes a long time to fix. Your problem seems to be missed/lost interrupts. If you display the contents of /proc/interrupts (ie cat /proc/interrupts), it will show whether level (good), edge (bad) or MSI (good if hw works) are being used. Some workaround related things to try are: 1) Adding the module parameter idle_timeout=10 will cause the driver to poll for status every 10ms. This is obviously a performance overhead but it can allow system to function. 2) Disabling MSI with either pci=nomsi on boot cmdline or by using module parameter disable_msi=1. Message Signaled Interrupts are good, but it seems some chipsets don't work right. -- Stephen Hemminger [EMAIL PROTECTED] - 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.6 patch] process include/linux/if_{addr,link}.h with unifdef
On Tue, Jan 23, 2007 at 10:05:17PM -0800, David Miller wrote:
From: Adrian Bunk [EMAIL PROTECTED]
Date: Sun, 21 Jan 2007 20:13:19 +0100
After commit d3dcc077bf88806201093f86325ec656e4dbfbce,
include/linux/if_{addr,link}.h should be processed with unifdef.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Applied, thanks Adrian.
I believe at least the 2.6.19 -stable branch will need
this too, right? Please submit to -stable as needed,
and feel free to add my sign-off:
Signed-off-by: David S. Miller [EMAIL PROTECTED]
All my patch does is to remove #ifndef __KERNEL__'s around userspace
#define's from the userspace headers, so it's purely cosmetical.
Except when userspace wrongly defines __KERNEL__, no
header-y-unifdef-y should ever have any non-cosmetical effect.
That said, we really want what I called cosmetical - not having
#if{,n}def __KERNEL__ in any userspace headers - it's simply that this
is not a serious bug.
cu
Adrian
--
Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
-
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
2.6.20-rc4-mm1: PCI=n: drivers/net/3c59x.c compile error
3x59x-fix-pci-resource-management.patch causes the following compile error with CONFIG_PCI=n: -- snip -- ... CC drivers/net/3c59x.o /home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c: In function 'vortex_init_one': /home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:961: error: implicit declaration of function 'pci_request_regions' /home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:985: error: implicit declaration of function 'pci_release_regions' make[3]: *** [drivers/net/3c59x.o] Error 1 -- snip -- cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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.6.20-rc4-mm1: PCI=n: drivers/net/3c59x.c compile error
Hello. Adrian Bunk wrote: 3x59x-fix-pci-resource-management.patch causes the following compile error with CONFIG_PCI=n: -- snip -- ... CC drivers/net/3c59x.o /home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c: In function 'vortex_init_one': /home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:961: error: implicit declaration of function 'pci_request_regions' /home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:985: error: implicit declaration of function 'pci_release_regions' make[3]: *** [drivers/net/3c59x.o] Error 1 Grr, at at the same time it's happy with pci_enable_device(). I'd say the problem is in linux/pci.h, not in the patch. cu Adrian MBR, Sergei - 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] [FS_ENET] OF-related fixup for FEC and SCC MAC's
Updated direct resource pass with ioremap call, make it grant proper IRQ
mapping, stuff incompatible with the new approach were respectively put under
#ifndef CONFIG_PPC_MERGE. It is required so that both ppc and powerpc
could utilize fs_enet effectively.
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
---
drivers/net/fs_enet/mac-fec.c | 13 +
drivers/net/fs_enet/mac-scc.c |6 --
drivers/net/phy/fixed.c |2 +-
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c
index c2c5fd4..ff68394 100644
--- a/drivers/net/fs_enet/mac-fec.c
+++ b/drivers/net/fs_enet/mac-fec.c
@@ -104,9 +104,9 @@ static int do_pd_setup(struct fs_enet_private *fep)
fep-interrupt = platform_get_irq_byname(pdev,interrupt);
if (fep-interrupt 0)
return -EINVAL;
-
+
r = platform_get_resource_byname(pdev, IORESOURCE_MEM, regs);
- fep-fec.fecp =(void*)r-start;
+ fep-fec.fecp = ioremap(r-start, r-end - r-start + 1);
if(fep-fec.fecp == NULL)
return -EINVAL;
@@ -319,11 +319,14 @@ static void restart(struct net_device *dev)
* Clear any outstanding interrupt.
*/
FW(fecp, ievent, 0xffc0);
+#ifndef CONFIG_PPC_MERGE
FW(fecp, ivec, (fep-interrupt / 2) 29);
-
+#else
+ FW(fecp, ivec, (virq_to_hw(fep-interrupt) / 2) 29);
+#endif
/*
-* adjust to speed (only for DUET RMII)
+* adjust to speed (only for DUET RMII)
*/
#ifdef CONFIG_DUET
if (fpi-use_rmii) {
@@ -418,6 +421,7 @@ static void stop(struct net_device *dev)
static void pre_request_irq(struct net_device *dev, int irq)
{
+#ifndef CONFIG_PPC_MERGE
immap_t *immap = fs_enet_immap;
u32 siel;
@@ -431,6 +435,7 @@ static void pre_request_irq(struct net_device *dev, int irq)
siel = ~(0x8000 (irq ~1));
out_be32(immap-im_siu_conf.sc_siel, siel);
}
+#endif
}
static void post_free_irq(struct net_device *dev, int irq)
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index 95ec587..afd7fca 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -121,13 +121,13 @@ static int do_pd_setup(struct fs_enet_private *fep)
return -EINVAL;
r = platform_get_resource_byname(pdev, IORESOURCE_MEM, regs);
- fep-scc.sccp = (void *)r-start;
+ fep-scc.sccp = ioremap(r-start, r-end - r-start + 1);
if (fep-scc.sccp == NULL)
return -EINVAL;
r = platform_get_resource_byname(pdev, IORESOURCE_MEM, pram);
- fep-scc.ep = (void *)r-start;
+ fep-scc.ep = ioremap(r-start, r-end - r-start + 1);
if (fep-scc.ep == NULL)
return -EINVAL;
@@ -397,6 +397,7 @@ static void stop(struct net_device *dev)
static void pre_request_irq(struct net_device *dev, int irq)
{
+#ifndef CONFIG_PPC_MERGE
immap_t *immap = fs_enet_immap;
u32 siel;
@@ -410,6 +411,7 @@ static void pre_request_irq(struct net_device *dev, int irq)
siel = ~(0x8000 (irq ~1));
out_be32(immap-im_siu_conf.sc_siel, siel);
}
+#endif
}
static void post_free_irq(struct net_device *dev, int irq)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index 096d4a1..8613539 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -349,7 +349,7 @@ static int __init fixed_init(void)
fixed_mdio_register_device(0, 100, 1);
#endif
-#ifdef CONFIX_FIXED_MII_10_FDX
+#ifdef CONFIG_FIXED_MII_10_FDX
fixed_mdio_register_device(0, 10, 1);
#endif
return 0;
-
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
2.6.20-rc5: known regressions with patches (v3)
This email lists some known regressions in 2.6.20-rc5 compared to 2.6.19 with patches available. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: sata_nv: SATA exceptions References : http://lkml.org/lkml/2007/1/14/108 Submitter : Björn Steinbrink [EMAIL PROTECTED] Caused-By : Robert Hancock [EMAIL PROTECTED] commit 2dec7555e6bf2772749113ea0ad454fcdb8cf861 Handled-By : Robert Hancock [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/1/23/280 Status : patch available Subject: does not pickup ipv6 addresses References : http://bugzilla.kernel.org/show_bug.cgi?id=7817 http://lkml.org/lkml/2007/1/14/146 Submitter : Michael Gernoth [EMAIL PROTECTED] Daniel Drake [EMAIL PROTECTED] Caused-By : David L Stevens [EMAIL PROTECTED] commit 30c4cf577fb5b68c16e5750d6bdbd7072e42b279 Handled-By : YOSHIFUJI Hideaki [EMAIL PROTECTED] Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7817 Status : patch available Subject: ACPI: fix cpufreq regression References : http://lkml.org/lkml/2007/1/16/120 Submitter : Ingo Molnar [EMAIL PROTECTED] Caused-By : Dave Jones [EMAIL PROTECTED] commit 0916bd3ebb7cefdd0f432e8491abe24f4b5a101e Handled-By : Ingo Molnar [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/1/16/120 Status : patch available - 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] Marvell Libertas 8388 802.11b/g USB driver (v2)
On Wed, 2007-01-24 at 13:26 -0200, Marcelo Tosatti wrote: On Thu, Jan 18, 2007 at 03:22:50AM -0500, John W. Linville wrote: On Wed, Jan 17, 2007 at 06:19:07PM -0500, Jeff Garzik wrote: Christoph Hellwig wrote: On Wed, Jan 17, 2007 at 01:00:47PM -0500, Dan Williams wrote: allows the 8388 to continue routing other laptops' packets over the mesh *while the host CPU is asleep*. We're not going to put a lot of junk into the kernel just because the OLPC folks decide to do odd powermanagment schemes. We're not going to ignore useful power management schemes just because they don't fit neatly into a pre-existing category. I think the request to determine how all this maps into MLME is fair, though. Definitely. Also, I wonder if there was any attempt to evaluate how the ieee80211 (or d80211) code might be extended in order to elimnate the need for some of the libertas wlan_* files? The regulatory domain structures, channel information (struct ieee80211_channel), HW mode (struct ieee80211_hw_mode) compromised of supported channels and rates, and probably a few others in the same category. I can't see the possibility of using d80211 as it stands (designed for softmac cards dealing with 802.11 packets to/from the OS). However, it does not make any sense to use the structures defined by d80211 if not effectively using it (we send/receive 802.3 frames to the firmware, after all), IMO. As discussed on this thread, there is a lot of code to be cleanup up, but no structural changes AFAICT. Is there a general agreement on that, now? I pushed for a general lib80211 sort of thing at the Summit, which I think was agreed in principle with others like Intel. We need something to hold the bits that are common to d80211 and non-softmac drivers. These include scan result handling, some bits of the regulatory stuff (at least structures and definitions for allowed channels and txpower in each domain), and 802.3 - 802.11 framing conversion code. We should be able to fold more stuff in there as we go along. But there certainly will be code that both softmac/d80211 and non-softmac drivers (airo, ipw2x00, libertas, etc) can share. Dan - 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] net: Fix the fib trie iterator to work with a single entry routing tables
In a kernel with trie routing enabled I had a simple routing setup
with only a single route to the outside world and no default
route. ip route table list main showed my the route just fine but
/proc/net/route was an empty file. What was going on?
Thinking it was a bug in something I did and I looked deeper. Eventually
I setup a second route and everything looked correct, huh? Finally I
realized that the it was just the iterator pair in fib_trie_get_first,
fib_trie_get_next just could not handle a routing table with a single entry.
So to save myself and others further confusion, here is a simple fix for
the fib proc iterator so it works even when there is only a single route
in a routing table.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/ipv4/fib_trie.c | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index cfb249c..13307c0 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1989,6 +1989,10 @@ static struct node *fib_trie_get_next(struct
fib_trie_iter *iter)
unsigned cindex = iter-index;
struct tnode *p;
+ /* A single entry routing table */
+ if (!tn)
+ return NULL;
+
pr_debug(get_next iter={node=%p index=%d depth=%d}\n,
iter-tnode, iter-index, iter-depth);
rescan:
@@ -2037,11 +2041,18 @@ static struct node *fib_trie_get_first(struct
fib_trie_iter *iter,
if(!iter)
return NULL;
- if (n IS_TNODE(n)) {
- iter-tnode = (struct tnode *) n;
- iter-trie = t;
- iter-index = 0;
- iter-depth = 1;
+ if (n) {
+ if (IS_TNODE(n)) {
+ iter-tnode = (struct tnode *) n;
+ iter-trie = t;
+ iter-index = 0;
+ iter-depth = 1;
+ } else {
+ iter-tnode = NULL;
+ iter-trie = t;
+ iter-index = 0;
+ iter-depth = 0;
+ }
return n;
}
return NULL;
--
1.4.4.1.g278f
-
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] decnet: handle a failure in neigh_parms_alloc
While enhancing the neighbour code to handle multiple network
namespaces I noticed that decnet is assuming neigh_parms_alloc
will allways succeed, which is clearly wrong. So handle the
failure.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/decnet/dn_dev.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/decnet/dn_dev.c b/net/decnet/dn_dev.c
index 324eb47..f6a2b2a 100644
--- a/net/decnet/dn_dev.c
+++ b/net/decnet/dn_dev.c
@@ -1149,6 +1149,11 @@ struct dn_dev *dn_dev_create(struct net_device *dev, int
*err)
}
dn_db-neigh_parms = neigh_parms_alloc(dev, dn_neigh_table);
+ if (!dn_db-neigh_parms) {
+ dev-dn_ptr = NULL;
+ kfree(dn_db);
+ return NULL;
+ }
dn_dev_sysctl_register(dev, dn_db-parms);
--
1.4.4.1.g278f
-
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] Marvell Libertas 8388 802.11b/g USB driver (v2)
On Wed, Jan 24, 2007 at 01:52:35PM -0500, Dan Williams wrote: I pushed for a general lib80211 sort of thing at the Summit, which I think was agreed in principle with others like Intel. We need something to hold the bits that are common to d80211 and non-softmac drivers. These include scan result handling, some bits of the regulatory stuff (at least structures and definitions for allowed channels and txpower in each domain), and 802.3 - 802.11 framing conversion code. We should be able to fold more stuff in there as we go along. But there certainly will be code that both softmac/d80211 and non-softmac drivers (airo, ipw2x00, libertas, etc) can share. ACK -- John W. Linville [EMAIL PROTECTED] - 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: Nvidia MCP55 Machine reboots on ixgb driver load
[added netdev to CC] Roger Heflin wrote: I have a machine (actually 2 machines) that upon loading the intel 10GBe driver (ixgb) the machine reboots, I am using a RHAS4.4 based distribution with Vanilla 2.6.19.2 (the RHAS 4.4.03 kernel also reboots with the ixgb load), I don't see any messages on the machine before it reboots, loading the driver with debug does not appear to produce any extra messages. The basic steps are the I load the driver, the machine locks up, and then in a second or 2 it starts to post. some suggestions immediately come to mind: * have you tried the latest driver from http://e1000.sf.net/ ? * what happens when you unplug the card and modprobe the ixgb module? * have you tried capturing a trace with netconsole or serial console? probing the ixgb driver produces at least 1 syslog line that should show up. If nothing shows up on serial or netconsole, the issue may be way outside the ixgb driver. I have tried the default ixgb driver in 2.6.19.2, and I have tried the open source intel driver on RH4.4, both cause the same reboot.I also tried the linux firmware development kit, and booting fc6 causes the same reboot upon the network driver load. just for completeness, which driver versions were this? and when you say booting fc6 I assume you mean that fc6 boots OK until you modprobe the ixgb driver? I have tried pci=nomsi try compiling your kernel without MSI support alltogether. There have been serious issues found with MSI on certain configurations, and in your case this might be the cause. Allthough passing pci=nomsi should be the same as compiling it out, it can't hurt to try. Also note that the [EMAIL PROTECTED] address is apparently unused and returns an email telling you to use a web page, and so far after using the web page I have not got any response indicating that anything got to anyone. I've taken action to get that straightened out. You're always welcome to mail netdev, the e1000 devel list or even lkml which we will all pick up on. I can't think of a specific reason for the issue right now, other than attempting to get a serial/netconsole attached and trying without any msi support in the kernel. Please give that a try and let us know. Auke - 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] net: Fix the fib trie iterator to work with a single entry routing tables
Hello!
Yes the case when the trie is just a single leaf got wrong with the iterator
and your patchs
cures it. I think we have a similar problem with /proc/net/fib_trie
Cheers
--ro
Signed-off-by: Robert Olsson [EMAIL PROTECTED]
Eric W. Biederman writes:
In a kernel with trie routing enabled I had a simple routing setup
with only a single route to the outside world and no default
route. ip route table list main showed my the route just fine but
/proc/net/route was an empty file. What was going on?
Thinking it was a bug in something I did and I looked deeper. Eventually
I setup a second route and everything looked correct, huh? Finally I
realized that the it was just the iterator pair in fib_trie_get_first,
fib_trie_get_next just could not handle a routing table with a single entry.
So to save myself and others further confusion, here is a simple fix for
the fib proc iterator so it works even when there is only a single route
in a routing table.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/ipv4/fib_trie.c | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index cfb249c..13307c0 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1989,6 +1989,10 @@ static struct node *fib_trie_get_next(struct
fib_trie_iter *iter)
unsigned cindex = iter-index;
struct tnode *p;
+/* A single entry routing table */
+if (!tn)
+return NULL;
+
pr_debug(get_next iter={node=%p index=%d depth=%d}\n,
iter-tnode, iter-index, iter-depth);
rescan:
@@ -2037,11 +2041,18 @@ static struct node *fib_trie_get_first(struct
fib_trie_iter *iter,
if(!iter)
return NULL;
-if (n IS_TNODE(n)) {
-iter-tnode = (struct tnode *) n;
-iter-trie = t;
-iter-index = 0;
-iter-depth = 1;
+if (n) {
+if (IS_TNODE(n)) {
+iter-tnode = (struct tnode *) n;
+iter-trie = t;
+iter-index = 0;
+iter-depth = 1;
+} else {
+iter-tnode = NULL;
+iter-trie = t;
+iter-index = 0;
+iter-depth = 0;
+}
return n;
}
return NULL;
--
1.4.4.1.g278f
-
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 REPOST 1/2] NET: Accurate packet scheduling for ATM/ADSL (kernel)
On Wed, 2007-01-24 at 17:38 +0100, Patrick McHardy wrote: The two RTAB's are different. Thus you must send different RTAB's to pre-STAB and post-STAB kernels. How is tc to decide which one to send? I did add code that checked uname once to solve a very similar problem in tc, but that got my wrist slapped. If the users asks to use STABs, send the modified RTAB. If the kernel doesn't support STABs it will return an error, which is good enough. Yuk! Now the user has to say whether he wants to use STAB's or not? Currently, apart from some debugging params to tc, the user isn't even aware that the traffic control is implemented in terms of RTAB's. That is how it should be - it is an implementation detail. I think this is a different problem. If you replace RTABs by STABs you again can't use it for anything that is only interested in the size, not the transmission time (HFSC, SFQ, ...). I was a little too brief. The comment stems from the observation that in all current implementations: const A_CONSTANT; for (i = 0; i 256; i += 1) assert(RTAB[i] == STAB[i] * A_CONSTANT); Ergo, if in addition to implementing STAB as you plan to, A_CONSTANT was shipped to the kernel then RTAB could be replaced. A_CONSTANT could be set so the calculation would return the time it would take to send a packet in micro seconds, say (a figure I just pulled out of the air). This is 1000 times more precise than the kernel can do now. It wouldn't be perfect - the kernel would send the packets in bursts. But it would be good enough to solve my problem with VOIP, I think. - 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] net: Fix the fib trie iterator to work with a single entry routing tables
From: Robert Olsson [EMAIL PROTECTED] Date: Wed, 24 Jan 2007 22:43:30 +0100 Yes the case when the trie is just a single leaf got wrong with the iterator and your patchs cures it. I think we have a similar problem with /proc/net/fib_trie I'm happy to review a fix for that :-) Signed-off-by: Robert Olsson [EMAIL PROTECTED] Patch applied, thanks everyone. - 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] decnet: handle a failure in neigh_parms_alloc
From: [EMAIL PROTECTED] (Eric W. Biederman) Date: Wed, 24 Jan 2007 13:09:40 -0700 While enhancing the neighbour code to handle multiple network namespaces I noticed that decnet is assuming neigh_parms_alloc will allways succeed, which is clearly wrong. So handle the failure. Signed-off-by: Eric W. Biederman [EMAIL PROTECTED] I don't think this one is correct. During failure cleanup you also have to invoke the neighbour parms -down() operation if present, else you leave multicast entries on the ethernet device for example. - 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] decnet: handle a failure in neigh_parms_alloc
From: David Miller [EMAIL PROTECTED] Date: Wed, 24 Jan 2007 14:45:11 -0800 (PST) From: [EMAIL PROTECTED] (Eric W. Biederman) Date: Wed, 24 Jan 2007 13:09:40 -0700 While enhancing the neighbour code to handle multiple network namespaces I noticed that decnet is assuming neigh_parms_alloc will allways succeed, which is clearly wrong. So handle the failure. Signed-off-by: Eric W. Biederman [EMAIL PROTECTED] I don't think this one is correct. During failure cleanup you also have to invoke the neighbour parms -down() operation if present, else you leave multicast entries on the ethernet device for example. BTW, it occurs to me that a good way to handle this might be to try and do the neigh_parms_alloc() before running the -up() method. - 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: [BUG] problem with BPF in PF_PACKET sockets, introduced in linux-2.6.19
From: Raivis Bucis [EMAIL PROTECTED]
Date: Thu, 4 Jan 2007 17:47:46 +0200
I believe I have found a bug in PF_PACKET socket filtering
(introduced in linux-2.6.19). If BPF returns values larger than
0x8000u, run_filter in af_packet.c considers that as error
instead of simply accepting packet in its full length. sk_filter
does not have this problem.
Indeed, this bug was introduced by this change:
commit fda9ef5d679b07c9d9097aaf6ef7f069d794a8f9
Author: Dmitry Mishin [EMAIL PROTECTED]
Date: Thu Aug 31 15:28:39 2006 -0700
[NET]: Fix sk-sk_filter field access
Function sk_filter() is called from tcp_v{4,6}_rcv() functions with arg
needlock = 0, while socket is not locked at that moment. In order to avoid
this and similar issues in the future, use rcu for sk-sk_filter field read
protection.
Signed-off-by: Dmitry Mishin [EMAIL PROTECTED]
Signed-off-by: Alexey Kuznetsov [EMAIL PROTECTED]
Signed-off-by: Kirill Korotaev [EMAIL PROTECTED]
The expected semantics are that sk_run_filter() returns either
0 which means drop the packet, or a positive 32-bit integer
which states how many bytes of the packet to retain. If the
returned length is larger than the packet, the packet is left
at it's full length, unchanged, and accepted.
That last case is what was broken by the logic modifications
done by Dmitry Mishin's RCU'ification of socket filters. He
tries to combine 32-bit signed error code handling with
interpretation of the 32-bit unsigned return value from
sk_run_filter().
So this whole idea to make run_filter() return signed integers
and fail on negative is entirely flawed, it simply cannot work
and retain the expected semantics which have been there forever.
Drop on zero works, and was what the code did originally, and there
was no reason at all to modify the logic here, it was perfect. The
callers to run_filter() told it what the expected return value should
be if there was no filter hooked up to the socket, and that is the
current length of the packet. It simulates the case of there actually
being a filter and it saying that the whole packet should be accepted.
This is yet another case of someone doing some logic cleanups to make
the logic nicer to them, and adding a bug in the process.
Here is how I am likely to fix this:
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index da73e8a..594c078 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -428,24 +428,18 @@ out_unlock:
}
#endif
-static inline int run_filter(struct sk_buff *skb, struct sock *sk,
- unsigned *snaplen)
+static inline unsigned int run_filter(struct sk_buff *skb, struct sock *sk,
+ unsigned int res)
{
struct sk_filter *filter;
- int err = 0;
rcu_read_lock_bh();
filter = rcu_dereference(sk-sk_filter);
- if (filter != NULL) {
- err = sk_run_filter(skb, filter-insns, filter-len);
- if (!err)
- err = -EPERM;
- else if (*snaplen err)
- *snaplen = err;
- }
+ if (filter != NULL)
+ res = sk_run_filter(skb, filter-insns, filter-len);
rcu_read_unlock_bh();
- return err;
+ return res;
}
/*
@@ -467,7 +461,7 @@ static int packet_rcv(struct sk_buff *skb, struct
net_device *dev, struct packet
struct packet_sock *po;
u8 * skb_head = skb-data;
int skb_len = skb-len;
- unsigned snaplen;
+ unsigned int snaplen, res;
if (skb-pkt_type == PACKET_LOOPBACK)
goto drop;
@@ -495,8 +489,11 @@ static int packet_rcv(struct sk_buff *skb, struct
net_device *dev, struct packet
snaplen = skb-len;
- if (run_filter(skb, sk, snaplen) 0)
+ res = run_filter(skb, sk, snaplen);
+ if (!res)
goto drop_n_restore;
+ if (snaplen res)
+ snaplen = res;
if (atomic_read(sk-sk_rmem_alloc) + skb-truesize =
(unsigned)sk-sk_rcvbuf)
@@ -568,7 +565,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct
net_device *dev, struct packe
struct tpacket_hdr *h;
u8 * skb_head = skb-data;
int skb_len = skb-len;
- unsigned snaplen;
+ unsigned int snaplen, res;
unsigned long status = TP_STATUS_LOSING|TP_STATUS_USER;
unsigned short macoff, netoff;
struct sk_buff *copy_skb = NULL;
@@ -592,8 +589,11 @@ static int tpacket_rcv(struct sk_buff *skb, struct
net_device *dev, struct packe
snaplen = skb-len;
- if (run_filter(skb, sk, snaplen) 0)
+ res = run_filter(skb, sk, snaplen);
+ if (!res)
goto drop_n_restore;
+ if (snaplen res)
+ snaplen = res;
if (sk-sk_type == SOCK_DGRAM) {
macoff = netoff = TPACKET_ALIGN(TPACKET_HDRLEN) + 16;
-
To unsubscribe from this
Re: [PATCH REPOST 1/2] NET: Accurate packet scheduling for ATM/ADSL (kernel)
Russell Stuart wrote: Yuk! Now the user has to say whether he wants to use STAB's or not? Currently, apart from some debugging params to tc, the user isn't even aware that the traffic control is implemented in terms of RTAB's. That is how it should be - it is an implementation detail. Of course he has to, just like your atm parameter. In case of stabs it would be something like stab atm. I think this is a different problem. If you replace RTABs by STABs you again can't use it for anything that is only interested in the size, not the transmission time (HFSC, SFQ, ...). I was a little too brief. The comment stems from the observation that in all current implementations: const A_CONSTANT; for (i = 0; i 256; i += 1) assert(RTAB[i] == STAB[i] * A_CONSTANT); Ergo, if in addition to implementing STAB as you plan to, A_CONSTANT was shipped to the kernel then RTAB could be replaced. At least look at the patch I sent. STAB mapping is _not_ a multiplication by a constant (which wouldn't be able to express minimum packet size or padding to multiples of cell sizes). - 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 REPOST 1/2] NET: Accurate packet scheduling for ATM/ADSL (kernel)
On Thu, 2007-01-25 at 01:06 +0100, Patrick McHardy wrote: Of course he has to, just like your atm parameter. In case of stabs it would be something like stab atm. The difference being with atm he is telling the kernel he has an ATM line, but with STAB he is telling the kernel how it should internally calculate packet lengths and transmission times. Why should he care how the kernel does it? Surely this should be hidden. As it is now, BTW. I was a little too brief. The comment stems from the observation that in all current implementations: const A_CONSTANT; for (i = 0; i 256; i += 1) assert(RTAB[i] == STAB[i] * A_CONSTANT); Ergo, if in addition to implementing STAB as you plan to, A_CONSTANT was shipped to the kernel then RTAB could be replaced. At least look at the patch I sent. STAB mapping is _not_ a multiplication by a constant (which wouldn't be able to express minimum packet size or padding to multiples of cell sizes). You have read this the wrong way. Firstly I did look at the patch you posted - and commented on it in some detail. Admittedly it was a while ago. The details are fuzzy now, but I am pretty sure I know what you want achieve and how you plan to go about it. Secondly, I am not saying STAB is a multiplication by a constant - any more than RTAB is multiplication by a constant. I am fully aware that STAB can take into account MPU's, cell padding, additional protocol overhead and whatnot - just like RTAB does now. What I am saying is that on or about is summed up in the tc_calc_xmittime() function in tc_core.c. It is a grand total of 1 line long: return tc_core_usec2tick(100*((double)size/rate)); Later on in the code, we have this assignment: rtab[i] = tc_calc_xmittime(bps, sz); Which can be re-written: rtab[i] = tc_core_usec2tick(100*((double)size/rate)); If STAB was introduced and was kept to a fixed 256 elements (I am not suggesting it should be), the core change would be to change the line above to read: stab[i] = size; rtab[i] = tc_core_usec2tick(100*((double)stab[i]/rate)); Thus my assertion that: RTAB[i] = STAB[i] * A_CONSTANT is literally true. A_CONSTANT is currently always 100 / rate * HZ. All I am saying is that in the kernel, wherever we have a reference to rtab[i] now, after your stab is introduced that reference could be replaced by stab[i] * A_CONSTANT, provided A_CONSTANT was sent with stab by tc. Doing this would have several advantages: a. Uses less space than having both RTAB and STAB. b. Provides the framework to allow the kernel to overcomes my problem with HZ being too slow for ATM links 2M bips/sec. c. Puts an end to my whinging about compatibility problems above. We can just send the old RTAB. It will be ignored by kernels that use STAB. Are you objecting to this because I hadn't spelt it out clearly, or is there something deeper I am missing? It doesn't seem like a radical proposal to me. - 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: bonding: bug in balance-alb mode (incorrect update-ARP-replies)
JUNG, Christian [EMAIL PROTECTED] wrote: You have to setup a box with at least two NICs, a bonding device enslaving those, assign at least two IPs to the bond and make some traffic from a different machine to one of those IPs. If you delete that IP, the box will regardlessly send ARP-replies to the machine which communicated to that IP before removing it. I've fooled around with this for a while today, and I see generically what you're describing: after a local IP address is removed, the corresponding entries in the bonding receive balance hash table are not removed. However, I'm not able induce the ill effects you describe from this (following the script you supplied); I don't see the (apparently) unsolicited ARP replies you show in your tcpdump traces. I do see some other weirdness when the receive balance hash table becomes heavily populated, but nothing that is an ARP reply for an address not assigned to the system. Is your test occuring on an isolated network, and is there other concurrent network traffic that might be affecting things? -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - 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
[RFC: 2.6 patch] net/tipc/: possible cleanups
This patch contains the following possible cleanups: - make needlessly global functions static - #if 0 unused functions - remove all EXPORT_SYMBOL's My impression is that most of this might have users that are not yet submitted for inclusion in the kernel - one year after TIPC was merged. If this is true, please submit the users for inclusion in the kernel. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- include/net/tipc/tipc.h | 60 include/net/tipc/tipc_port.h |9 net/tipc/addr.c |2 net/tipc/cluster.c |2 net/tipc/cluster.h |1 net/tipc/config.c|9 +++- net/tipc/config.h|7 --- net/tipc/core.c | 74 ++- net/tipc/core.h | 14 -- net/tipc/dbg.c | 15 +-- net/tipc/dbg.h |3 - net/tipc/discover.c |4 + net/tipc/discover.h |1 net/tipc/link.c | 14 +++--- net/tipc/link.h |4 - net/tipc/name_table.c|3 - net/tipc/node.c |6 +- net/tipc/node.h |1 net/tipc/port.c | 59 +-- net/tipc/port.h |2 net/tipc/subscr.c|2 net/tipc/zone.c |2 net/tipc/zone.h |1 23 files changed, 97 insertions(+), 198 deletions(-) --- linux-2.6.20-rc4-mm1/include/net/tipc/tipc.h.old2007-01-24 19:12:15.0 +0100 +++ linux-2.6.20-rc4-mm1/include/net/tipc/tipc.h2007-01-24 20:40:58.0 +0100 @@ -50,8 +50,6 @@ * TIPC operating mode routines */ -u32 tipc_get_addr(void); - #define TIPC_NOT_RUNNING 0 #define TIPC_NODE_MODE1 #define TIPC_NET_MODE 2 @@ -62,8 +60,6 @@ void tipc_detach(unsigned int userref); -int tipc_get_mode(void); - /* * TIPC port manipulation routines */ @@ -153,12 +149,8 @@ int tipc_shutdown(u32 ref); /* Sends SHUTDOWN msg */ -int tipc_isconnected(u32 portref, int *isconnected); - int tipc_peer(u32 portref, struct tipc_portid *peer); -int tipc_ref_valid(u32 portref); - /* * TIPC messaging routines */ @@ -170,38 +162,12 @@ unsigned int num_sect, struct iovec const *msg_sect); -int tipc_send_buf(u32 portref, - struct sk_buff *buf, - unsigned int dsz); - int tipc_send2name(u32 portref, struct tipc_name const *name, u32 domain, /* 0:own zone */ unsigned int num_sect, struct iovec const *msg_sect); -int tipc_send_buf2name(u32 portref, - struct tipc_name const *name, - u32 domain, - struct sk_buff *buf, - unsigned int dsz); - -int tipc_forward2name(u32 portref, - struct tipc_name const *name, - u32 domain, /*0: own zone */ - unsigned int section_count, - struct iovec const *msg_sect, - struct tipc_portid const *origin, - unsigned int importance); - -int tipc_forward_buf2name(u32 portref, - struct tipc_name const *name, - u32 domain, - struct sk_buff *buf, - unsigned int dsz, - struct tipc_portid const *orig, - unsigned int importance); - int tipc_send2port(u32 portref, struct tipc_portid const *dest, unsigned int num_sect, @@ -212,20 +178,6 @@ struct sk_buff *buf, unsigned int dsz); -int tipc_forward2port(u32 portref, - struct tipc_portid const *dest, - unsigned int num_sect, - struct iovec const *msg_sect, - struct tipc_portid const *origin, - unsigned int importance); - -int tipc_forward_buf2port(u32 portref, - struct tipc_portid const *dest, - struct sk_buff *buf, - unsigned int dsz, - struct tipc_portid const *orig, - unsigned int importance); - int tipc_multicast(u32 portref, struct tipc_name_seq const *seq, u32 domain, /* 0:own zone */ @@ -240,18 +192,6 @@ unsigned int size); #endif -/* - * TIPC subscription routines - */ - -int tipc_ispublished(struct tipc_name const *name); - -/* - * Get number of available nodes within specified domain (excluding own node) - */ - -unsigned int tipc_available_nodes(const u32 domain); - #endif #endif --- linux-2.6.20-rc4-mm1/net/tipc/addr.c.old2007-01-24 19:12:34.0 +0100 +++
[rft] r8169: merge release 6.001.00 of Realtek's driver - take #1
Untested, straight from the release early dept. You have been warned.
Realtek's driver restricts itself to 0x8169 and 0x8167.
It won't be surprising if it breaks on anything else until
I merge the new 0x8168 and 0x8136 bits.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 159 ++
1 files changed, 121 insertions(+), 38 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 577babd..2f320de 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -150,11 +150,13 @@ static const int multicast_filter_limit = 32;
#define RTL_R32(reg) ((unsigned long) readl (ioaddr + (reg)))
enum mac_version {
- RTL_GIGA_MAC_VER_01 = 0x00,
- RTL_GIGA_MAC_VER_02 = 0x01,
- RTL_GIGA_MAC_VER_03 = 0x02,
- RTL_GIGA_MAC_VER_04 = 0x03,
- RTL_GIGA_MAC_VER_05 = 0x04,
+ RTL_GIGA_MAC_VER_00 = 0x00, // 8169
+ RTL_GIGA_MAC_VER_01 = 0x01, // 8169S
+ RTL_GIGA_MAC_VER_02 = 0x02, // 8110S
+ RTL_GIGA_MAC_VER_03 = 0x03,
+ RTL_GIGA_MAC_VER_04 = 0x04, // 8169SB
+ RTL_GIGA_MAC_VER_05 = 0x05, // 8169SCd
+ RTL_GIGA_MAC_VER_06 = 0x06, // 8169SCe
RTL_GIGA_MAC_VER_11 = 0x0b,
RTL_GIGA_MAC_VER_12 = 0x0c,
RTL_GIGA_MAC_VER_13 = 0x0d,
@@ -179,11 +181,13 @@ static const struct {
u8 mac_version;
u32 RxConfigMask; /* Clears the bits supported by this chip */
} rtl_chip_info[] = {
- _R(RTL8169, RTL_GIGA_MAC_VER_01, 0xff7e1880),
+ _R(RTL8169, RTL_GIGA_MAC_VER_00, 0xff7e1880),
+ _R(RTL8169s/8110s,RTL_GIGA_MAC_VER_01, 0xff7e1880),
_R(RTL8169s/8110s,RTL_GIGA_MAC_VER_02, 0xff7e1880),
- _R(RTL8169s/8110s,RTL_GIGA_MAC_VER_03, 0xff7e1880),
- _R(RTL8169sb/8110sb, RTL_GIGA_MAC_VER_04, 0xff7e1880),
+ _R(RTL8169sb/8110sb, RTL_GIGA_MAC_VER_03, 0xff7e1880),
+ _R(RTL8169sc/8110sc, RTL_GIGA_MAC_VER_04, 0xff7e1880),
_R(RTL8169sc/8110sc, RTL_GIGA_MAC_VER_05, 0xff7e1880),
+ _R(RTL8169sc/8110sc, RTL_GIGA_MAC_VER_06, 0xff7e1880),
_R(RTL8168b/8111b,RTL_GIGA_MAC_VER_11, 0xff7e1880), // PCI-E
_R(RTL8168b/8111b,RTL_GIGA_MAC_VER_12, 0xff7e1880), // PCI-E
_R(RTL8101e, RTL_GIGA_MAC_VER_13, 0xff7e1880), // PCI-E 8139
@@ -231,6 +235,7 @@ static struct {
enum RTL8169_registers {
MAC0 = 0, /* Ethernet hardware address. */
+ MAC4 = 4,
MAR0 = 8, /* Multicast filter. */
CounterAddrLow = 0x10,
CounterAddrHigh = 0x14,
@@ -322,6 +327,11 @@ enum RTL8169_register_content {
/* Config1 register p.24 */
PMEnable= (1 0), /* Power Management Enable */
+ /* Config2 register p. 25 */
+ PCI_Clock_66MHz = 0x01,
+ PCI_Clock_33MHz = 0x00,
+
+
/* Config3 register p.25 */
MagicPacket = (1 5), /* Wake up when receives a Magic Packet
*/
LinkUp = (1 4), /* Wake up when the cable connection is
re-established */
@@ -1172,15 +1182,17 @@ static void rtl8169_get_mac_version(struct
rtl8169_private *tp, void __iomem *io
{ 0x3400, RTL_GIGA_MAC_VER_13 },
{ 0x3080, RTL_GIGA_MAC_VER_14 },
{ 0x3000, RTL_GIGA_MAC_VER_11 },
+ { 0x9800, RTL_GIGA_MAC_VER_05 },
{ 0x1800, RTL_GIGA_MAC_VER_05 },
- { 0x1000, RTL_GIGA_MAC_VER_04 },
- { 0x0400, RTL_GIGA_MAC_VER_03 },
- { 0x0080, RTL_GIGA_MAC_VER_02 },
- { 0x, RTL_GIGA_MAC_VER_01 } /* Catch-all */
+ { 0x1800, RTL_GIGA_MAC_VER_04 },
+ { 0x1000, RTL_GIGA_MAC_VER_03 },
+ { 0x0400, RTL_GIGA_MAC_VER_02 },
+ { 0x0080, RTL_GIGA_MAC_VER_01 },
+ { 0x, RTL_GIGA_MAC_VER_00 } /* Catch-all */
}, *p = mac_info;
u32 reg;
- reg = RTL_R32(TxConfig) 0x7c80;
+ reg = RTL_R32(TxConfig) 0xfc80;
while ((reg p-mask) != p-mask)
p++;
tp-mac_version = p-mac_version;
@@ -1273,7 +1285,7 @@ static void rtl8169_hw_phy_config(struct net_device *dev)
rtl8169_print_mac_version(tp);
rtl8169_print_phy_version(tp);
- if (tp-mac_version = RTL_GIGA_MAC_VER_01)
+ if (tp-mac_version = RTL_GIGA_MAC_VER_00)
return;
if (tp-phy_version = RTL_GIGA_PHY_VER_H)
return;
@@ -1283,7 +1295,7 @@ static void rtl8169_hw_phy_config(struct net_device *dev)
/* Shazam ! */
- if (tp-mac_version == RTL_GIGA_MAC_VER_04) {
+ if (tp-mac_version == RTL_GIGA_MAC_VER_03) {
mdio_write(ioaddr, 31, 0x0002);
mdio_write(ioaddr, 1, 0x90d0);
mdio_write(ioaddr, 31, 0x);
@@ -1317,7 +1329,7 @@
Re: Nvidia MCP55 Machine reboots on ixgb driver load
Auke Kok wrote: [added netdev to CC] Roger Heflin wrote: I have a machine (actually 2 machines) that upon loading the intel 10GBe driver (ixgb) the machine reboots, I am using a RHAS4.4 based distribution with Vanilla 2.6.19.2 (the RHAS 4.4.03 kernel also reboots with the ixgb load), I don't see any messages on the machine before it reboots, loading the driver with debug does not appear to produce any extra messages. The basic steps are the I load the driver, the machine locks up, and then in a second or 2 it starts to post. some suggestions immediately come to mind: * have you tried the latest driver from http://e1000.sf.net/ ? I have tried the ixgb-1.0-126 driver from intel's web site, with it doing the same thing, and that looks to be the same as the sf driver. * what happens when you unplug the card and modprobe the ixgb module? That loads just fine, and prints out the driver information, and the copyright. * have you tried capturing a trace with netconsole or serial console? probing the ixgb driver produces at least 1 syslog line that should show up. If nothing shows up on serial or netconsole, the issue may be way outside the ixgb driver. I *think* have got the line listing the interrupt 1 or 2 times just before it goes away, I got the serial crossover working to a laptop and got no extra kernel messages when the driver was loaded and rebooted the machine, I did see the full kernel bootup so I know the serial console was working correctly. I have tried the default ixgb driver in 2.6.19.2, and I have tried the open source intel driver on RH4.4, both cause the same reboot.I also tried the linux firmware development kit, and booting fc6 causes the same reboot upon the network driver load. just for completeness, which driver versions were this? The ixgb-1.0.126 driver from Intel's site. The default driver on 4.4.03 does not support the CX4 board, but loads just fine, just does not find any cards that it can drive. I did confirm that it does not list the PCIID for the CX4 card. and when you say booting fc6 I assume you mean that fc6 boots OK until you modprobe the ixgb driver? Yes, that is correct the machine goes to full multiuser (I have the .ko file moved elsewhere so automatic module loading does not kill the machine-until it choose to test it), and has been used for some io test with no issues until the ixgb driver is loaded. Both machines have been heavily tested with high cpu applications that verify their results to make sure memory is working correctly under load. I have tried pci=nomsi try compiling your kernel without MSI support alltogether. There have been serious issues found with MSI on certain configurations, and in your case this might be the cause. Allthough passing pci=nomsi should be the same as compiling it out, it can't hurt to try. Ok, I tried that. I found out that breaks some other unrelated stuff, but loading the ixgb driver still crashes the machine. Also note that the [EMAIL PROTECTED] address is apparently unused and returns an email telling you to use a web page, and so far after using the web page I have not got any response indicating that anything got to anyone. I've taken action to get that straightened out. You're always welcome to mail netdev, the e1000 devel list or even lkml which we will all pick up on. I can't think of a specific reason for the issue right now, other than attempting to get a serial/netconsole attached and trying without any msi support in the kernel. Please give that a try and let us know. Nothing extra from the serial console, and still locks up with no msi support. Roger - 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] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Sec 2.1 of RFC 4429 says
Unless noted otherwise, components of the IPv6 protocol stack should
treat addresses in the Optimistic state equivalently to those in the
Deprecated state, indicating that the address is available for use
but should not be used if another suitable address is available. For
example, Default Address Selection [RFC3484] uses the address state
to decide which source address to use for an outgoing packet.
Implementations should treat an address in state Optimistic as if it
were in state Deprecated. If address states are recorded as
individual flags, this can easily be achieved by also setting
'Deprecated' when 'Optimistic' is set.
So i think DEPRECATED flag also should be set when we mark an address
as OPTIMISTIC so that we don't use it as source address for new
connections if another address is available until DAD is completed.
Thanks
Sridhar
On Tue, 2007-01-23 at 15:51 -0500, Neil Horman wrote:
On Tue, Jan 23, 2007 at 09:18:20AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
Hello.
snip
New patch attached, incorporating Yoshijui and Vlads latest comments. I
didn't
follow guidance on the ndisc_recv_ns comment, Yoshifuji, since Vlad had
already
suggested an alternate solution in a previous post, but from looking at them
both, they should be equivalent.
Thanks Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
include/linux/if_addr.h |1
include/linux/ipv6.h|2 +
include/linux/sysctl.h |1
include/net/addrconf.h |4 +-
net/ipv6/addrconf.c | 56
net/ipv6/mcast.c|4 +-
net/ipv6/ndisc.c| 82
+++-
7 files changed, 117 insertions(+), 33 deletions(-)
diff --git a/include/linux/if_addr.h b/include/linux/if_addr.h
index d557e4c..43f3bed 100644
--- a/include/linux/if_addr.h
+++ b/include/linux/if_addr.h
@@ -39,6 +39,7 @@ enum
#define IFA_F_TEMPORARY IFA_F_SECONDARY
#define IFA_F_NODAD 0x02
+#define IFA_F_OPTIMISTIC 0x04
#define IFA_F_HOMEADDRESS 0x10
#define IFA_F_DEPRECATED 0x20
#define IFA_F_TENTATIVE 0x40
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index f824113..5d37abf 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -177,6 +177,7 @@ struct ipv6_devconf {
#endif
#endif
__s32 proxy_ndp;
+ __s32 optimistic_dad;
void*sysctl;
};
@@ -205,6 +206,7 @@ enum {
DEVCONF_RTR_PROBE_INTERVAL,
DEVCONF_ACCEPT_RA_RT_INFO_MAX_PLEN,
DEVCONF_PROXY_NDP,
+ DEVCONF_OPTIMISTIC_DAD,
DEVCONF_MAX
};
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 81480e6..972a33a 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -570,6 +570,7 @@ enum {
NET_IPV6_RTR_PROBE_INTERVAL=21,
NET_IPV6_ACCEPT_RA_RT_INFO_MAX_PLEN=22,
NET_IPV6_PROXY_NDP=23,
+ NET_IPV6_OPTIMISTIC_DAD=24,
__NET_IPV6_MAX
};
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 88df8fc..d248a19 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -73,7 +73,9 @@ extern int ipv6_get_saddr(struct dst_entry
*dst,
extern int ipv6_dev_get_saddr(struct net_device *dev,
struct in6_addr *daddr,
struct in6_addr *saddr);
-extern int ipv6_get_lladdr(struct net_device *dev, struct
in6_addr *);
+extern int ipv6_get_lladdr(struct net_device *dev,
+ struct in6_addr *,
+ unsigned char banned_flags);
extern int ipv6_rcv_saddr_equal(const struct sock *sk,
const struct sock *sk2);
extern void addrconf_join_solict(struct net_device *dev,
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2a7e461..d2b01ec 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -830,7 +830,8 @@ retry:
ift = !max_addresses ||
ipv6_count_addresses(idev) max_addresses ?
ipv6_add_addr(idev, addr, tmp_plen,
- ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK,
IFA_F_TEMPORARY) : NULL;
+ ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK,
+ IFA_F_TEMPORARY|IFA_F_OPTIMISTIC) : NULL;
if (!ift || IS_ERR(ift)) {
in6_ifa_put(ifp);
in6_dev_put(idev);
@@ -1174,7 +1175,8 @@ int ipv6_get_saddr(struct dst_entry *dst,
}
-int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr)
+int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr,
+ unsigned char
Re: [PATCH] net: Fix the fib trie iterator to work with a single entry routing tables
David Miller [EMAIL PROTECTED] writes: From: Robert Olsson [EMAIL PROTECTED] Date: Wed, 24 Jan 2007 22:43:30 +0100 Yes the case when the trie is just a single leaf got wrong with the iterator and your patchs cures it. I think we have a similar problem with /proc/net/fib_trie I'm happy to review a fix for that :-) Signed-off-by: Robert Olsson [EMAIL PROTECTED] Patch applied, thanks everyone. Same iterator function so this fixes that as well. Eric - 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
[BNX2]: Fix 2nd port's MAC address.
[BNX2]: Fix 2nd port's MAC address.
On the 5709, we need to add the proper offset to calculate the shared
memory base address of the 2nd port correctly. Otherwise, the 2nd
port's MAC address and other information will be the same as the 1st
port.
Update version to 1.5.4.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index ca5acc4..953808e 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -57,8 +57,8 @@
#define DRV_MODULE_NAMEbnx2
#define PFX DRV_MODULE_NAME:
-#define DRV_MODULE_VERSION 1.5.3
-#define DRV_MODULE_RELDATE January 8, 2007
+#define DRV_MODULE_VERSION 1.5.4
+#define DRV_MODULE_RELDATE January 24, 2007
#define RUN_AT(x) (jiffies + (x))
@@ -5845,9 +5845,11 @@ bnx2_init_board(struct pci_dev *pdev, st
reg = REG_RD_IND(bp, BNX2_SHM_HDR_SIGNATURE);
if ((reg BNX2_SHM_HDR_SIGNATURE_SIG_MASK) ==
- BNX2_SHM_HDR_SIGNATURE_SIG)
- bp-shmem_base = REG_RD_IND(bp, BNX2_SHM_HDR_ADDR_0);
- else
+ BNX2_SHM_HDR_SIGNATURE_SIG) {
+ u32 off = PCI_FUNC(pdev-devfn) 2;
+
+ bp-shmem_base = REG_RD_IND(bp, BNX2_SHM_HDR_ADDR_0 + off);
+ } else
bp-shmem_base = HOST_VIEW_SHMEM_BASE;
/* Get the permanent MAC address. First we need to make sure the
-
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] net: decnet handle a failure in neigh_parms_alloc (take 2)
While enhancing the neighbour code to handle multiple network
namespaces I noticed that decnet is assuming neigh_parms_alloc
will allways succeed, which is clearly wrong. So handle the
failure.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/decnet/dn_dev.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/decnet/dn_dev.c b/net/decnet/dn_dev.c
index 324eb47..913e25a 100644
--- a/net/decnet/dn_dev.c
+++ b/net/decnet/dn_dev.c
@@ -1140,16 +1140,23 @@ struct dn_dev *dn_dev_create(struct net_device *dev,
int *err)
init_timer(dn_db-timer);
dn_db-uptime = jiffies;
+
+ dn_db-neigh_parms = neigh_parms_alloc(dev, dn_neigh_table);
+ if (!dn_db-neigh_parms) {
+ dev-dn_ptr = NULL;
+ kfree(dn_db);
+ return NULL;
+ }
+
if (dn_db-parms.up) {
if (dn_db-parms.up(dev) 0) {
+ neigh_parms_release(dn_neigh_table,
dn_db-neigh_parms);
dev-dn_ptr = NULL;
kfree(dn_db);
return NULL;
}
}
- dn_db-neigh_parms = neigh_parms_alloc(dev, dn_neigh_table);
-
dn_dev_sysctl_register(dev, dn_db-parms);
dn_dev_set_timer(dev);
--
1.4.4.1.g278f
-
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 0/4] spidernet: add support for Celleb
Jens-san, This is a revised version of the patch set for spider_net driver that works on Toshiba Cell Refererence Set (aka Celleb). This patch set is based on netdev-2.6.git#upstream. Jens, can you give that a go on our blades see if it doesn't break anything ? We are all at LCA here so it's a bit hard to test ! Nope, doesn't work for us... I have a patch based on Ishizaki's previous patch which I think will work on Celleb. Will post it here when I have adapted it to the new version. Thank you for testing our patch and we are sorry that our patch does not work on Cell Blade. We will test your modified patch on celleb when you post it. Best regards, Kou Ishizaki - 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 1/12] L2 network namespace (v3): current network namespace operations
Dmitry Mishin [EMAIL PROTECTED] writes: On Wednesday 17 January 2007 23:16, Eric W. Biederman wrote: Dmitry Mishin [EMAIL PROTECTED] writes: Added functions and macros required to operate with network namespaces. They are required in order to switch network namespace for incoming packets and to not extend current network interface by additional network namespace argue. Is exec_net only used in interrupt context? I tried to do so. Or how do you ensure a sleeping function does not get called and the kernel process comes back on another cpu? Seems that I forgot to remove it's usage at least in one place - in clone_net_ns(). If you caught more, please, let me know. Hmm. veth seems to be using it around unregister_netdevice. Eric - 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
[RFC PATCH] bcm43xx: set channel when the interface is brought up
Hello! I have discovered that while I can indeed associate without wpa_supplicant using bcm43xx_d80211 driver, I have to set the channel every time the interface is brought down and up. It turns out d80211 uses the config method of the hardware drivers very sparingly. It's only used for scanning and in ioctl commands. It is not called after the interface has been brought up with the open method. I don't know whose responsibility it should be to apply the configuration when the interface is brought up. I'm not familiar with d80211 design principles. If the hardware drivers are supposed to do it, here's my patch. It is working fine for me and ready to be applied. The changelog is in the subject. Signed-off-by: Pavel Roskin [EMAIL PROTECTED] --- drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c index 9f4d51d..d408e38 100644 --- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c +++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c @@ -2809,6 +2809,9 @@ static int bcm43xx_dev_open(struct ieee80211_hw *hw) } mutex_unlock(wl-mutex); + if (!err) + err = bcm43xx_dev_config(hw, hw-conf); + return err; } -- Regards, Pavel Roskin - 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] scrub non-__GLIBC__ checks in linux/socket.h and linux/stat.h
Erik Andersen wrote: On Sat Dec 16, 2006 at 01:42:11PM -0500, Mike Frysinger wrote: On 11/30/06, Robert P. J. Day [EMAIL PROTECTED] wrote: but there are a few other cases which still contain compound preprocessor directives such as: #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ 2) having never worked with unifdef before, i guess i was being overly optimistic in thinking that it, if i unifdefed __KERNEL__, it might at least simplify the expression. oh, well ... live and learn. userspace should be worrying about userspace, so having the socket.h and stat.h pollute the namespace in the non-glibc case is wrong and pretty much prevents any other libc from utilizing these headers sanely unless they set up the __GLIBC__ define themselves (which sucks) -mike Ack from me. I'd love to see this applied so uClibc could stop have to define __GLIBC__ klibc uses these definitions, but the right thing to do is to have libc ask for it: #if defined(__KERNEL__) || defined(__EXPORT_LINUX_SOCKET_H) /* ... */ #endif That way, klibc can just #define __EXPORT_LINUX_SOCKET_H #include linux/socket.h -hpa - 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 25/59] sysctl: C99 convert arch/frv/kernel/pm.c
Fine by me. Acked-By: David Howells [EMAIL PROTECTED] - 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
