* Re: [PATCH] via-velocity: allow MTU size less than 1500 bytes
From: Jeff Garzik @ 2006-05-28 20:36 UTC (permalink / raw)
To: Francois Romieu; +Cc: Jay Cliburn, netdev
In-Reply-To: <20060527193118.GA7998@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
> Jeff Garzik <jgarzik@pobox.com> :
> [...]
>> ACK, but patch won't apply:
>
> I have regenerated it against mainline. It can be pulled from the repository
>
> git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git velocity
pulled, thanks
^ permalink raw reply
* Re: [PATCH] TCP Veno module for kernel 2.6.16.13
From: Thomas Kho @ 2006-05-28 22:22 UTC (permalink / raw)
To: #ZHOU BIN#; +Cc: jmorris, netdev
In-Reply-To: <A975FFC51622704CBEAB749E263D1799015540B3@mail01.student.main.ntu.edu.sg>
On 5/24/06, #ZHOU BIN# <ZHOU0022@ntu.edu.sg> wrote:
> + u16 cntRTT; /* # of RTTs measured within last RTT */
> + /* veno->cntRTT = 0; */
It looks like this counter is never initialized, and the comment is deceiving.
Thomas Kho
^ permalink raw reply
* Re: [PATCH] GRE: fixup gre_keymap_lookup() return type
From: Patrick McHardy @ 2006-05-28 23:01 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: netfilter-devel, netdev
In-Reply-To: <20060526190716.GA7266@martell.zuzino.mipt.ru>
Alexey Dobriyan wrote:
> GRE keys are 16-bit wide.
This looks harmless, so I've queued it for 2.6.18. Thanks.
^ permalink raw reply
* RE: [PATCH] TCP Veno module for kernel 2.6.16.13
From: #ZHOU BIN# @ 2006-05-29 3:26 UTC (permalink / raw)
To: Thomas Kho; +Cc: Fu Cheng Peng, Franklin, jmorris, shemminger, netdev
> -----Original Message-----
> From: Thomas Kho [mailto:thomaskho@gmail.com]
> Sent: Monday, May 29, 2006 6:22 AM
> To: #ZHOU BIN#
> Cc: jmorris@namei.org; netdev@vger.kernel.org
> Subject: Re: [PATCH] TCP Veno module for kernel 2.6.16.13
>
>
> On 5/24/06, #ZHOU BIN# <ZHOU0022@ntu.edu.sg> wrote:
> > + u16 cntRTT; /* # of RTTs measured
> within last RTT */
>
> > + /* veno->cntRTT = 0; */
>
> It looks like this counter is never initialized
Yes, I agree. It should be done at tcp_veno_init(). I've corrected it. Also avoid the mix caps this time, according to the suggestion from J. Morris. Following is the new patch.
Thank you all for the comments.
Sign-off-by: Bin Zhou <zhou0022@ntu.edu.sg>, Cheng Peng Fu <ascpfu@ntu.edu.sg>
diff -urN linux-2.6.16.13/net/ipv4/Kconfig linux-2.6.16.13-veno-1/net/ipv4/Kconfig
--- linux-2.6.16.13/net/ipv4/Kconfig 2006-05-03 05:38:44.000000000 +0800
+++ linux-2.6.16.13-veno-1/net/ipv4/Kconfig 2006-05-20 16:16:44.712926200 +0800
@@ -521,6 +521,18 @@
window. TCP Vegas should provide less packet loss, but it is
not as aggressive as TCP Reno.
+config TCP_CONG_VENO
+ tristate "TCP Veno"
+ depends on EXPERIMENTAL
+ default n
+ ---help---
+ TCP Veno is a sender-side only enhancement of TCP to obtain better
+ throughput over wirless networks. TCP Veno makes use of state
+ distinguishing to circumvent the difficult judgment of the packet loss type.
+ TCP Veno cuts down less congestion window in response to random loss
+ packets.
+ See http://www.ntu.edu.sg/home5/ZHOU0022/papers/CPFu03a.pdf
+
config TCP_CONG_SCALABLE
tristate "Scalable TCP"
depends on EXPERIMENTAL
diff -urN linux-2.6.16.13/net/ipv4/Makefile linux-2.6.16.13-veno-1/net/ipv4/Makefile
--- linux-2.6.16.13/net/ipv4/Makefile 2006-05-03 05:38:44.000000000 +0800
+++ linux-2.6.16.13-veno-1/net/ipv4/Makefile 2006-05-20 15:57:45.308758200 +0800
@@ -40,6 +40,7 @@
obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybla.o
obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o
obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o
+obj-$(CONFIG_TCP_CONG_VENO) += tcp_veno.o
obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
diff -urN linux-2.6.16.13/net/ipv4/tcp_veno.c linux-2.6.16.13-veno-1/net/ipv4/tcp_veno.c
--- linux-2.6.16.13/net/ipv4/tcp_veno.c 1970-01-01 08:00:00.000000000 +0800
+++ linux-2.6.16.13-veno-1/net/ipv4/tcp_veno.c 2006-05-29 11:10:04.368125900 +0800
@@ -0,0 +1,253 @@
+/*
+ * TCP Veno congestion control
+ *
+ * This is based on the congestion detection/avoidance scheme described in
+ * C. P. Fu, S. C. Liew.
+ * "TCP Veno: TCP Enhancement for Transmission over Wireless Access Networks."
+ * IEEE Journal on Selected Areas in Communication,
+ * Feb. 2003.
+ * See http://www.ntu.edu.sg/home5/ZHOU0022/papers/CPFu03a.pdf
+ */
+
+#include <linux/config.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <linux/inet_diag.h>
+
+#include <net/tcp.h>
+
+/* Default values of the Veno variables, in fixed-point representation
+ * with V_PARAM_SHIFT bits to the right of the binary point.
+ */
+#define V_PARAM_SHIFT 1
+static int beta = 3<<V_PARAM_SHIFT;
+
+
+/* Veno variables */
+struct veno {
+ u8 doing_veno_now;/* if true, do veno for this RTT */
+ u16 cntrtt; /* # of RTTs measured */
+ u32 minrtt; /* min of RTTs measured within last RTT (in usec) */
+ u32 basertt; /* the min of all Veno RTT measurements seen (in usec) */
+ u32 inc; /* decide whether to increase cwnd */
+ u32 diff; /* calculate the diff rate */
+};
+
+/* There are several situations when we must "re-start" Veno:
+ *
+ * o when a connection is established
+ * o after an RTO
+ * o after fast recovery
+ * o when we send a packet and there is no outstanding
+ * unacknowledged data (restarting an idle connection)
+ *
+ */
+static inline void veno_enable(struct sock *sk)
+{
+ struct veno *veno = inet_csk_ca(sk);
+
+ /* turn on Veno */
+ veno->doing_veno_now = 1;
+
+ veno->minrtt = 0x7fffffff;
+}
+
+static inline void veno_disable(struct sock *sk)
+{
+ struct veno *veno = inet_csk_ca(sk);
+
+ /* turn off Veno */
+ veno->doing_veno_now = 0;
+}
+
+static void tcp_veno_init(struct sock *sk)
+{
+ struct veno *veno = inet_csk_ca(sk);
+
+ veno->basertt = 0x7fffffff;
+ veno->inc = 1;
+ veno->cntrtt = 0;
+ veno_enable(sk);
+}
+
+/* Do RTT sampling needed for Veno. */
+static void tcp_veno_rtt_calc(struct sock *sk, u32 usrtt)
+{
+ struct veno *veno = inet_csk_ca(sk);
+ u32 vrtt = usrtt + 1; /* Never allow zero rtt or baseRTT */
+
+ /* Filter to find propagation delay: */
+ if (vrtt < veno->basertt)
+ veno->basertt = vrtt;
+
+ /* Find the min RTT during the last RTT to find
+ * the current prop. delay + queuing delay:
+ */
+ veno->minrtt = min(veno->minrtt, vrtt);
+ veno->cntrtt++;
+}
+
+static void tcp_veno_state(struct sock *sk, u8 ca_state)
+{
+
+ if (ca_state == TCP_CA_Open)
+ veno_enable(sk);
+ else
+ veno_disable(sk);
+}
+
+/*
+ * If the connection is idle and we are restarting,
+ * then we don't want to do any Veno calculations
+ * until we get fresh RTT samples. So when we
+ * restart, we reset our Veno state to a clean
+ * state. After we get acks for this flight of
+ * packets, _then_ we can make Veno calculations
+ * again.
+ */
+static void tcp_veno_cwnd_event(struct sock *sk, enum tcp_ca_event event)
+{
+ if (event == CA_EVENT_CWND_RESTART ||
+ event == CA_EVENT_TX_START)
+ tcp_veno_init(sk);
+}
+
+static void tcp_veno_cong_avoid(struct sock *sk, u32 ack,
+ u32 seq_rtt, u32 in_flight, int flag)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ struct veno *veno = inet_csk_ca(sk);
+
+ if (!veno->doing_veno_now)
+ return tcp_reno_cong_avoid(sk, ack, seq_rtt, in_flight, flag);
+
+ /* limited by applications */
+ if (!tcp_is_cwnd_limited(sk, in_flight))
+ return;
+
+ /* We do the Veno calculations only if we got enough RTT samples */
+ if (veno->cntrtt <= 2) {
+ /* We don't have enough RTT samples to do the Veno
+ * calculation, so we'll behave like Reno.
+ */
+ tcp_reno_cong_avoid(sk, ack, seq_rtt, in_flight, flag);
+ } else {
+ u32 rtt, target_cwnd;
+
+ /* We have enough RTT samples, so, using the Veno
+ * algorithm, we determine the state of the network.
+ */
+
+ rtt = veno->minrtt;
+
+ target_cwnd = ((tp->snd_cwnd * veno->basertt)
+ << V_PARAM_SHIFT) / rtt;
+
+ veno->diff = (tp->snd_cwnd << V_PARAM_SHIFT) - target_cwnd;
+
+ if (tp->snd_cwnd <= tp->snd_ssthresh) {
+ /* Slow start. */
+ tcp_slow_start(tp);
+ }
+ else if (sysctl_tcp_abc) {
+ /* RFC3465: Apppriate Byte Count
+ * increase once for each full cwnd acked.
+ * Veno has no idear about it so far, so we keep
+ * it as Reno.
+ */
+ if (tp->bytes_acked >= tp->snd_cwnd*tp->mss_cache) {
+ tp->bytes_acked -= tp->snd_cwnd*tp->mss_cache;
+ if (tp->snd_cwnd < tp->snd_cwnd_clamp)
+ tp->snd_cwnd++;
+ }
+ }else {
+ /* Congestion avoidance. */
+ if (veno->diff < beta) {
+ /* In the "non-congestive state", increase cwnd
+ * every rtt.
+ */
+ if (tp->snd_cwnd_cnt >= tp->snd_cwnd) {
+ if (tp->snd_cwnd < tp->snd_cwnd_clamp)
+ tp->snd_cwnd++;
+ tp->snd_cwnd_cnt = 0;
+ } else
+ tp->snd_cwnd_cnt++;
+ } else {
+ /* In the "congestive state", increase cwnd
+ * every other rtt.
+ */
+ if (tp->snd_cwnd_cnt >= tp->snd_cwnd) {
+ if (veno->inc && tp->snd_cwnd < tp->snd_cwnd_clamp) {
+ tp->snd_cwnd++;
+ veno->inc = 0;
+ }
+ else
+ veno->inc = 1;
+ tp->snd_cwnd_cnt = 0;
+ } else
+ tp->snd_cwnd_cnt++;
+ }
+
+ }
+ if (tp->snd_cwnd < 2)
+ tp->snd_cwnd = 2;
+ else if (tp->snd_cwnd > tp->snd_cwnd_clamp)
+ tp->snd_cwnd = tp->snd_cwnd_clamp;
+ }
+ /* Wipe the state clean for the next RTT. */
+ veno->minrtt = 0x7fffffff;
+ }
+
+/* Veno MD phase */
+u32 tcp_veno_ssthresh(struct sock *sk)
+{
+ const struct tcp_sock *tp = tcp_sk(sk);
+ struct veno *veno = inet_csk_ca(sk);
+ if(veno->diff < beta) {
+ /* in "non-congestive state", cut cwnd by 1/5 */
+ return max(tp->snd_cwnd*4/5, 2U);
+ }else {
+ /* in "congestive state", cut cwnd by 1/2 */
+ return max(tp->snd_cwnd >> 1U, 2U);
+ }
+}
+
+u32 tcp_veno_min_cwnd(struct sock *sk)
+{
+ const struct tcp_sock *tp = tcp_sk(sk);
+ return tp->snd_ssthresh;
+}
+
+
+static struct tcp_congestion_ops tcp_veno = {
+ .init = tcp_veno_init,
+ .ssthresh = tcp_veno_ssthresh,
+ .cong_avoid = tcp_veno_cong_avoid,
+ .min_cwnd = tcp_veno_min_cwnd,
+ .rtt_sample = tcp_veno_rtt_calc,
+ .set_state = tcp_veno_state,
+ .cwnd_event = tcp_veno_cwnd_event,
+
+ .owner = THIS_MODULE,
+ .name = "veno",
+};
+
+static int __init tcp_veno_register(void)
+{
+ BUG_ON(sizeof(struct veno) > ICSK_CA_PRIV_SIZE);
+ tcp_register_congestion_control(&tcp_veno);
+ return 0;
+}
+
+static void __exit tcp_veno_unregister(void)
+{
+ tcp_unregister_congestion_control(&tcp_veno);
+}
+
+module_init(tcp_veno_register);
+module_exit(tcp_veno_unregister);
+
+MODULE_AUTHOR("Bin Zhou, Cheng Peng Fu");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("TCP Veno");
^ permalink raw reply
* Re: Refactor Netlink connector?
From: David Miller @ 2006-05-29 6:36 UTC (permalink / raw)
To: johnpol; +Cc: jmorris, netdev, tgraf, sds
In-Reply-To: <20060528153321.GB31822@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Sun, 28 May 2006 19:33:21 +0400
> Does SELinux have security handlers for each type of possible ioctls
> over the world? Each ioctl number is like each netlink type of message,
> but instead there is only one check per ioctl syscall as long as lsm
> hook for socket's send/recv syscall.
Yes, the problem is similar to what the compat layer needs to face.
But I think James will tell us that SELinux has a way that it handles
the mess that is ioctl(). :-)
More to the point I think that none of this will be handled
transparently unless the onus is put on new netlink module users.
Ie. make the register of a netlink subsystem user (either direct
netlink or via generic netlink) fail if the operations don't
provide the SELinux handlers.
Otherwise, the SELinux folks will continually be playing catchup
writing the handlers. That doesn't scale.
^ permalink raw reply
* 3c59x transmit timed out.
From: Evgeniy Polyakov @ 2006-05-29 7:07 UTC (permalink / raw)
To: netdev; +Cc: akpm
Here is part of the dmesg on my 3c59x test machine.
This happend first time and I'm quite sure after module reloading things
will be ok again, so it is not bug report but probably some meat for brain...
Hmm... I can not login using neither serial console, nor direct access,
it looks like something eats 100% cpu, since I can scroll console and
type, but login is frozen.
You can find lspci -vxxx at the end.
Kernel is 2.6.16.
[17422676.004000] eth0: transmit timed out, tx_status 00 status e680.
[17422676.012000] diagnostics: net 0cfa media 8880 dma 0000003a fifo
8000
[17422676.016000] Flags; bus-master 1, dirty 35095(7) current 35111(7)
[17422676.024000] Transmit list 00000000 vs. f6f54660.
[17422676.028000] 0: @f6f54200 length 8000002a status 0001002a
[17422676.036000] 1: @f6f542a0 length 8000002a status 0001002a
[17422676.040000] 2: @f6f54340 length 8000002a status 0001002a
[17422676.048000] 3: @f6f543e0 length 8000002a status 0001002a
[17422676.052000] 4: @f6f54480 length 8000002a status 0001002a
[17422676.060000] 5: @f6f54520 length 8000002a status 8001002a
[17422676.064000] 6: @f6f545c0 length 8000002a status 8001002a
[17422676.072000] 7: @f6f54660 length 80000042 status 00010042
[17422676.076000] 8: @f6f54700 length 8000002a status 0001002a
[17422676.080000] 9: @f6f547a0 length 8000002a status 0001002a
[17422676.088000] 10: @f6f54840 length 8000002a status 0001002a
[17422676.092000] 11: @f6f548e0 length 8000002a status 0001002a
[17422676.100000] 12: @f6f54980 length 8000002a status 0001002a
[17422676.104000] 13: @f6f54a20 length 8000002a status 0001002a
[17422676.112000] 14: @f6f54ac0 length 8000002a status 0001002a
[17422676.116000] 15: @f6f54b60 length 8000002a status 0001002a
[17422686.124000] eth0: transmit timed out, tx_status 00 status e680.
[17422686.132000] diagnostics: net 0cfa media 8880 dma 0000003a fifo
8000
[17422686.136000] Flags; bus-master 1, dirty 35095(7) current 35111(7)
[17422686.144000] Transmit list 00000000 vs. f6f54660.
[17422686.148000] 0: @f6f54200 length 8000002a status 0001002a
[17422686.156000] 1: @f6f542a0 length 8000002a status 0001002a
[17422686.160000] 2: @f6f54340 length 8000002a status 0001002a
[17422686.168000] 3: @f6f543e0 length 8000002a status 0001002a
[17422686.172000] 4: @f6f54480 length 8000002a status 0001002a
[17422686.180000] 5: @f6f54520 length 8000002a status 8001002a
[17422686.184000] 6: @f6f545c0 length 8000002a status 8001002a
[17422686.188000] 7: @f6f54660 length 80000042 status 00010042
[17422686.196000] 8: @f6f54700 length 8000002a status 0001002a
[17422686.200000] 9: @f6f547a0 length 8000002a status 0001002a
[17422686.208000] 10: @f6f54840 length 8000002a status 0001002a
[17422686.212000] 11: @f6f548e0 length 8000002a status 0001002a
[17422686.220000] 12: @f6f54980 length 8000002a status 0001002a
[17422686.224000] 13: @f6f54a20 length 8000002a status 0001002a
[17422686.232000] 14: @f6f54ac0 length 8000002a status 0001002a
[17422686.236000] 15: @f6f54b60 length 8000002a status 0001002a
lspci:
01:00.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 74)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
Flags: bus master, medium devsel, latency 64, IRQ 17
I/O ports at cc00 [size=128]
Memory at fc7ffc00 (32-bit, non-prefetchable) [size=128]
Expansion ROM at 54000000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
00: b7 10 00 92 17 01 10 02 74 00 00 02 10 40 00 00
10: 01 cc 00 00 00 fc 7f fc 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 00 10
30: 00 00 7c fc dc 00 00 00 00 00 00 00 0b 01 0a 0a
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 02 fe
e0: 00 40 00 b7 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
--
Evgeniy Polyakov
^ permalink raw reply
* Re: Refactor Netlink connector?
From: jamal @ 2006-05-29 12:11 UTC (permalink / raw)
To: David Miller; +Cc: sds, tgraf, netdev, jmorris, johnpol
In-Reply-To: <20060528.233649.22498001.davem@davemloft.net>
On Sun, 2006-28-05 at 23:36 -0700, David Miller wrote:
[..]
>
> More to the point I think that none of this will be handled
> transparently unless the onus is put on new netlink module users.
> Ie. make the register of a netlink subsystem user (either direct
> netlink or via generic netlink) fail if the operations don't
> provide the SELinux handlers.
>
> Otherwise, the SELinux folks will continually be playing catchup
> writing the handlers. That doesn't scale.
The scaling problem may be more related to SELinux trying to have
ultimate knowledge of all the subsystems classification. It breaks when
it is something that is not simple as a type (as in this case).
If SELinux should provide ways to add "filters" more dynamically at its
hooks - instead of having people go and look for that table and update
it then it would simplify things and we may be able to easily have
netlink users to register such filters at startup; infact we may be able
to hide this from the users in genetlink.
One could argue that if SELinux is capable of adding such filters at its
hooks, then the problem could be moved to user space policy perhaps?
cheers,
jamal
^ permalink raw reply
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Ivo van Doorn @ 2006-05-29 15:58 UTC (permalink / raw)
To: netdev
In-Reply-To: <200605251716.00742.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 10010 bytes --]
Hi,
I made a small update on this patch, only a small compile fix
and small bugfix.
The thing I would like to know now, is if the current approach
is the desired situation.
- Should only 1 input device be created, or multiple devices?
- Should instead of KEY_RADIO new keys be created (KEY_RADIO_WIFI
and KEY_RADIO_BLUETOOTH for example) or should instead input_event
be used and instead of "1", other values be passed to indicate the device which
has triggered the event?
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 4bad588..212caad 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,14 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RADIOBTN
+ tristate "Hardware radio button support"
+ help
+ Say Y here if you have an integrated WiFi or Bluetooth device
+ which contains an hardware button for enabling or disabling the radio.
+ When this driver is used, this driver will make sure the radio will
+ be correctly enabled and disabled when needed. It will then also
+ use the created input device to signal user space of this event
+ which allows userspace to take additional actions.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..9af3d98 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT) += uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RADIOBTN) += radiobtn.o
\ No newline at end of file
diff --git a/drivers/input/misc/radiobtn.c b/drivers/input/misc/radiobtn.c
new file mode 100644
index 0000000..8d3b84a
--- /dev/null
+++ b/drivers/input/misc/radiobtn.c
@@ -0,0 +1,163 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/*
+ Radio hardware button support
+ Poll frequently all registered hardware for hardware button status,
+ if changed enabled or disable the radio of that hardware device.
+ Send signal to input device to inform userspace about the new status.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/input.h>
+#include <linux/radiobtn.h>
+
+MODULE_AUTHOR("Ivo van Doorn <IvDoorn@gmail.com>");
+MODULE_VERSION("1.0");
+MODULE_DESCRIPTION("Radio hardware button support");
+MODULE_LICENSE("GPL");
+
+void radiobtn_poll(unsigned long data)
+{
+ struct radio_button *radiobtn = (struct radio_button*)data;
+ int state;
+
+ /*
+ * Poll for the new state.
+ * Check if the state has changed.
+ */
+ state = !!radiobtn->button_poll(radiobtn->data);
+ if (state != radiobtn->current_state) {
+ radiobtn->current_state = state;
+
+ /*
+ * Enable or disable the radio when this
+ * should be done in software.
+ */
+ if (state && radiobtn->enable_radio)
+ radiobtn->enable_radio(radiobtn->data);
+ else if (!state && radiobtn->disable_radio)
+ radiobtn->disable_radio(radiobtn->data);
+
+ /*
+ * Report key event.
+ */
+ input_report_key(radiobtn->input_dev, KEY_RADIO, 1);
+ input_sync(radiobtn->input_dev);
+ input_report_key(radiobtn->input_dev, KEY_RADIO, 0);
+ input_sync(radiobtn->input_dev);
+ }
+
+ /*
+ * Check if polling has been disabled.
+ */
+ if (radiobtn->poll_delay != 0) {
+ radiobtn->poll_timer.expires =
+ jiffies + msecs_to_jiffies(radiobtn->poll_delay);
+ add_timer(&radiobtn->poll_timer);
+ }
+}
+
+int radiobtn_register_device(struct radio_button *radiobtn)
+{
+ int status;
+
+ /*
+ * Check if all mandatory fields have been set.
+ */
+ if (radiobtn->poll_delay == 0 || radiobtn->button_poll == NULL)
+ return -EINVAL;
+
+ /*
+ * Allocate, initialize and register input device.
+ */
+ radiobtn->input_dev = input_allocate_device();
+ if (!radiobtn->input_dev) {
+ printk(KERN_ERR "Failed to allocate input device %s.\n",
+ radiobtn->dev_name);
+ return -ENOMEM;
+ }
+
+ radiobtn->input_dev->name = "Radio button";
+ radiobtn->input_dev->phys = strcat("radiobtn/", radiobtn->dev_name);
+ radiobtn->input_dev->id.bustype = BUS_HOST;
+ set_bit(KEY_RADIO, radiobtn->input_dev->keybit);
+
+ status = input_register_device(radiobtn->input_dev);
+ if (status) {
+ printk(KERN_ERR "Failed to register input device %s.\n",
+ radiobtn->dev_name);
+ input_free_device(radiobtn->input_dev);
+ return status;
+ }
+
+ /*
+ * Set the initial state of the button.
+ */
+ radiobtn->current_state = radiobtn->button_poll(radiobtn->data);
+
+ /*
+ * Initialize timer.
+ */
+ init_timer(&radiobtn->poll_timer);
+ radiobtn->poll_timer.function = radiobtn_poll;
+ radiobtn->poll_timer.data = (unsigned long)radiobtn;
+ radiobtn->poll_timer.expires =
+ jiffies + msecs_to_jiffies(radiobtn->poll_delay);
+ add_timer(&radiobtn->poll_timer);
+
+ printk(KERN_INFO "Created new %s: %s.\n",
+ radiobtn->input_dev->name, radiobtn->input_dev->phys);
+
+ return 0;
+}
+
+void radiobtn_unregister_device(struct radio_button *radiobtn)
+{
+ /*
+ * Stop timer.
+ */
+ radiobtn->poll_delay = 0;
+ del_timer_sync(&radiobtn->poll_timer);
+
+ /*
+ * Remove input device.
+ */
+ input_unregister_device(radiobtn->input_dev);
+ input_free_device(radiobtn->input_dev);
+}
+
+static int __init radiobtn_init(void)
+{
+ printk(KERN_INFO "Loading radio button driver.\n");
+ return 0;
+}
+
+static void __exit radiobtn_exit(void)
+{
+ printk(KERN_INFO "Unloading radio button driver.\n");
+}
+
+EXPORT_SYMBOL(radiobtn_register_device);
+EXPORT_SYMBOL(radiobtn_unregister_device);
+
+module_init(radiobtn_init);
+module_exit(radiobtn_exit);
diff --git a/include/linux/radiobtn.h b/include/linux/radiobtn.h
new file mode 100644
index 0000000..3467606
--- /dev/null
+++ b/include/linux/radiobtn.h
@@ -0,0 +1,84 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/*
+ Radio hardware button support
+ Laptops are quite often equiped with support with a hardware button
+ to enabled and disable the radio of the integrated wireless network
+ or bluetooth interface.
+ Altough some devices will make sure that when pressed the radio
+ is disabled in hardware, other device depend on the software
+ to enabled or disable the radio accordingly.
+ This driver will create an input device and will poll registered
+ hardware frequently to listen if the button has been pressed.
+ When the device requires the software to disable or enable
+ the radio it will do so correctly, but it will also in all cases
+ send a signal to the input device to inform any listening daemon
+ the state has changed and will allow userspace to handle certain
+ tasks as well if required.
+ */
+
+#ifndef RADIOBTN_H
+#define RADIOBTN_H
+
+#include <linux/input.h>
+
+/**
+ * struct radio_button - radio hardware structure.
+ * @dev_name: Name of the interface. This will become the name
+ * of the input device created in /dev/radio/.
+ * @data: Private data which will be passed along with the radio handlers.
+ * @button_poll(unsigned long data): Handler which will be called
+ * with the poll_delay interval.
+ * @enable_radio(unsigned long data): Optional handler to enable the radio
+ * once the button has been pressed when the hardware does not do this
+ * automaticly.
+ * @disable_radio(unsigned long data): Optional handler to disable the radio
+ * once the button has been pressed when the hardware does not do this
+ * automaticly.
+ * @poll_delay: Delay in msecs between each poll.
+ * @current_state: Current state of the button.
+ * (Should not be touched by driver)
+ * @input_dev: Pointer to input device for this radio button.
+ * (Should not be touched by driver)
+ * @poll_timer: Timer used to poll for the button status.
+ * (Should not be touched by driver)
+ */
+struct radio_button {
+ const char *dev_name;
+
+ unsigned long data;
+
+ int (*button_poll)(unsigned long data);
+ void (*enable_radio)(unsigned long data);
+ void (*disable_radio)(unsigned long data);
+
+ unsigned int poll_delay;
+
+ unsigned int current_state;
+
+ struct input_dev *input_dev;
+
+ struct timer_list poll_timer;
+};
+
+int radiobtn_register_device(struct radio_button *);
+void radiobtn_unregister_device(struct radio_button *);
+
+#endif /* RADIOBTN_H */
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: skge driver oops
From: Beschorner Daniel @ 2006-05-29 17:54 UTC (permalink / raw)
To: 'Stephen Hemminger'
Cc: 'Krzysztof Oledzki', netdev, 'david@mantara.com'
Hi Stephen,
the patch doesn't help.
As soon as the card is receiving lots of data, the box crashes after some
seconds.
Testing these patches is very tricky for me, as it is a production system at
a remote location crashing on every test.
It's a D-Link card, ID 4C00 (530T), SysKonnect's driver is working fine.
Daniel
-----
Stephen Hemminger [mailto:shemminger@osdl.org]
> Please give this a try, it rearranges the transmit buffer management,
> and may avoid issues with partial completions causing SKB reuse.
^ permalink raw reply
* [BUG 6480]Re: Asus K8N-VM Motherboard Ethernet Problem
From: Ingo Oeser @ 2006-05-29 22:03 UTC (permalink / raw)
To: James Courtier-Dutton; +Cc: linux-kernel, Marc Perkel, bugme, netdev, aabdulla
In-Reply-To: <447B3408.1020001@superbug.co.uk>
Hi James,
On Monday, 29. May 2006 19:48, James Courtier-Dutton wrote:
> I can concur that the forcedeth is unreliable on nvidia based motherboards.
> I have a ethernet device that works with forcedeth.
> 0000:00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
> 0000:00:0a.0 0680: 10de:0057 (rev a3)
> Subsystem: 147b:1c12
> Flags: 66MHz, fast devsel, IRQ 11
> Memory at fe02f000 (32-bit, non-prefetchable) [size=4K]
> I/O ports at fc00 [size=8]
> Capabilities: [44] Power Management version 2
>
> It works in that it can actually send and receive packets.
> The problems are:
> 1) one cannot rmmod the forcedeth module. Even after ifdown etc.
> 2) the machine hangs randomly.
> Before someone asks, the MB has no serial port, so no stack trace available.
> 3) The netconsole fails to function with it.
>
> I have installed a standard PCI based intel ethernet card, and only use
> that. Without the forcedeth loaded, no hangs since.
>
> So, although I can confirm that there are certainly problems with the
> forcedeth driver, without a serial port, I am at a loss at how I might
> help diagnose the problem and fix it.
This sounds like http://bugzilla.kernel.org/show_bug.cgi?id=6480
Maybe we can help to resolve this. I already stored a lot of info in
the bugzilla entry.
Could you please describe your setup further? I'm interested on
the devices behind your nvidia NIC, since we only have it at one customers
mail server behind a SonicWall, so we cannot really try a lot.
For all other customers it works. I'm a bit lost on the cause.
I've seen 4% collisions, which might reduce performance,
but should not stop the transmitter forever.
PS: CC'ed some more relevant addresses to increase awareness.
Regards
Ingo Oeser
^ permalink raw reply
* Re: Job
From: Terrence Lugo @ 2006-05-29 16:33 UTC (permalink / raw)
To: linux-sound
Hello Linux-sound
Are you energetic, honest and responsible?
Are you a student looking for extra income? Are you retired but sill willing to work?
Or maybe you are just looking for a way to make a few extra bucks?
Ask us! We have great job offer for you.
Please contact us to get more information.
Our e-mail: support@support-tolliscatalogue.com
========================
Jerold Glass
Mon, 29 May 2006 21:33:10 +0500
^ permalink raw reply
* The AI parameter of tcp_highspeed.c (in 2.6.18)
From: Xiaoliang (David) Wei @ 2006-05-30 4:12 UTC (permalink / raw)
To: netdev
Hi gurus,
I am not sure if there is a problem in the additive increment (AI)
parameter of tcp_highspeed.c:
When snd_cwnd is smaller than 38 and the connection is in
congestion avoidance phase (snd_cwnd > snd_ssthresh), the snd_cwnd
seems to stop growing. I guess the problem is in the function of
hstcp_cong_avoid (Ln 126~Ln 138 of tcp_highspeed.c):
--------------------------------
if (tp->snd_cwnd > hstcp_aimd_vals[ca->ai].cwnd) {
while (tp->snd_cwnd > hstcp_aimd_vals[ca->ai].cwnd &&
ca->ai < HSTCP_AIMD_MAX - 1)
ca->ai++;
} else if (tp->snd_cwnd < hstcp_aimd_vals[ca->ai].cwnd) {
while (tp->snd_cwnd > hstcp_aimd_vals[ca->ai].cwnd &&
ca->ai > 0)
ca->ai--;
}
/* Do additive increase */
if (tp->snd_cwnd < tp->snd_cwnd_clamp) {
tp->snd_cwnd_cnt += ca->ai;
--------------------------------
When snd_cwnd < snd_ssthresh, this part of code is effective. And
since snd_cwnd is smaller than 38, which is hstcp_aimd_vals[0].cwnd,
ca->ai will be equal to 0.
Hence, snd_cwnd_cnt will be unchanged for the rest of the connection.
As a result, snd_cwnd also freezes.
I guess we can add change the Line 138 to make the algorithm more reliable?
- tp->snd_cwnd_cnt += ca->ai;
+ tp->snd_cwnd_cnt += (ca->ai+1);
Thanks.
-David
---------------------------------------------------------
Xiaoliang (David) Wei
http://davidwei.org Graduate Student, Netlab, Caltech
======================================
^ permalink raw reply
* Re: Sign-off for the IP1000A driver before inclusion
From: Pekka J Enberg @ 2006-05-30 6:16 UTC (permalink / raw)
To: jesse\(建興\)
Cc: Francois Romieu, David Vrabel, linux-kernel, netdev, david, akpm
In-Reply-To: <021f01c683b0$34b5cbd0$4964a8c0@icplus.com.tw>
On Tue, 30 May 2006, jesse\(??\)~H~H\) wrote:
> I had did some modification of ipg.h and ipg.c. Please see attach file.
> 20060521-2.6.17-rc4-git-ip1000-test.patch__icplus_modify.zip
Please send them as regular patches. Please
Documentation/SubmittingPatches and the following URL for details:
http://www.zipworld.com.au/~akpm/linux/patches/stuff/tpp.txt
Thanks.
Pekka
^ permalink raw reply
* Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing
From: Herman Elfrink @ 2006-05-30 6:42 UTC (permalink / raw)
To: Alan Cox; +Cc: Erik Mouw, Simon Oosthoek, netdev
In-Reply-To: <1148397268.25255.81.camel@localhost.localdomain>
An attempt to clear up the confusion that seems to have occurred:
FLAME is an intermediate layer between existing MAC and network (IP) layers.
From MAC layer point of view FLAME is another network layer protocol
(besides IP, IPX etc.), so the FLAME protocol ID we are taking about is
a network layer (IANA) protocol number.
From IP point of view FLAME behaves like a 'normal' ethernet-type MAC
layer; no need for new IEEE protocol number.
Regards,
Herman Elfrink.
Alan Cox wrote:
>On Maw, 2006-05-23 at 16:55 +0200, Erik Mouw wrote:
>
>
>>>>Ethernet protocol number I assume you mean. If so this at least used to
>>>>be handled by the IEEE, along with ethernet mac address ranges.
>>>>
>>>>
>>>>
>>>Yes ethernet protocol (it's below IP level), I didn't realise that IEEE
>>>also handled the portnumbers. I'll check the ieee website to see how it
>>>works, tnx!
>>>
>>>
>>IEEE doesn't handle port numbers. Port numbers are for whatever is
>>layered on top of ethernet, so you need to register those with the
>>appropriate authorities (IANA for IP).
>>
>>
>
>No no no
>
>There are several sets of numbers here
>
>Each ethernet DIX frame has a "protocol" (its the bits used for length
>in 802.*). IEEE at least used to handle the assignment of those. On top
>of that you have IP, IPX, etc with their own numbering agency.
>
>As he said "ethernet protocol (it's below IP level)", those are the
>protocol numbering bodies he wants, or to whomever it was delegated.
>
>Alan
>
>
>
>
^ permalink raw reply
* Re: Sign-off for the IP1000A driver before inclusion
From: Andrew Morton @ 2006-05-30 6:46 UTC (permalink / raw)
To: Pekka J Enberg; +Cc: jesse, romieu, dvrabel, linux-kernel, netdev, david
In-Reply-To: <Pine.LNX.4.58.0605300915400.18933@sbz-30.cs.Helsinki.FI>
On Tue, 30 May 2006 09:16:29 +0300 (EEST)
Pekka J Enberg <penberg@cs.Helsinki.FI> wrote:
> On Tue, 30 May 2006, jesse\(??\)~H~H\) wrote:
> > I had did some modification of ipg.h and ipg.c. Please see attach file.
> > 20060521-2.6.17-rc4-git-ip1000-test.patch__icplus_modify.zip
>
> Please send them as regular patches. Please
> Documentation/SubmittingPatches and the following URL for details:
>
> http://www.zipworld.com.au/~akpm/linux/patches/stuff/tpp.txt
>
It takes people quite a few iterations to get patch preparation worked out.
Pekka, if you have time, perhaps you can extract the patches for us?
^ permalink raw reply
* Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing
From: Herman Elfrink @ 2006-05-30 7:01 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Simon Oosthoek
In-Reply-To: <20060523094324.11926fcc@localhost.localdomain>
Stephen Hemminger wrote:
>Didn't you just reinvent 802.1d bridging? and/or WDS?
>
>
>
Hi Stephen,
Yes, more or less, but with a twist.
802.1D does not allow retransmitting over the same interface (which is
what basically happens in mesh networks), and WDS uses static
configuration of neighbouring hops (we want to support dynamically
changing configurations).
Regards,
Herman.
^ permalink raw reply
* Re: Sign-off for the IP1000A driver before inclusion
From: Pekka J Enberg @ 2006-05-30 7:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: jesse, romieu, dvrabel, linux-kernel, netdev, david
In-Reply-To: <20060529234610.e5671e4c.akpm@osdl.org>
On Mon, 29 May 2006, Andrew Morton wrote:
> It takes people quite a few iterations to get patch preparation worked out.
>
> Pekka, if you have time, perhaps you can extract the patches for us?
Jesse, I wasn't able to work out the ipg_config_autoneg() changes, but the
rest of them are at:
http://www.cs.helsinki.fi/u/penberg/linux/ip1000-jesse/
They're missing changelogs, though, so I'd much appreciate if Jesse
submitted them properly to Francois who's maintaining the ipg git tree.
Pekka
^ permalink raw reply
* RE:.
From: Stanley Morse @ 2006-05-30 8:57 UTC (permalink / raw)
To: netdev
Hello!
Our company Barcelo Travel Inc. seek enthusiastic, organised and alert individual to
support our busy sales offices. If you live in germany our offer its good chance change your liife.
You must have excellent customer relations, communication and administration skills
Successful candidates will be required to work in Main our Office for approximately
one month.
To apply, please email CV to barcelotravinc@aol.com
regards,
Dominico Barcelo
^ permalink raw reply
* Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing
From: Herman Elfrink @ 2006-05-30 8:29 UTC (permalink / raw)
To: Pavel Machek; +Cc: netdev, Simon Oosthoek, Alex Stienstra
In-Reply-To: <20060524205035.GA4149@ucw.cz>
Pavel Machek wrote:
>Hi!
>
>
>
>>FLAME stands for "Forwarding Layer for Meshing"
>>
>>FLAME provides an intermediate layer between the network
>>layer (e.g. IPv4/IPv6) and the link (MAC) layer,
>>providing L2.5 meshing. Both network layer and MAC layer
>>
>>
>
>What is wrong with meshing on L3?
>
>(It is called flame so lets at least have nice flamewar :-)
> Pavel
>
>
Hi Pavel,
I basically have two arguments against L3 meshing, which, for me, were
strong enough to turn to "below IP" meshing as a better solution for the
problems I was facing.
The first one comes from my experimental setup where I want to use a ad
hoc IPv6 network that has one or more Internet access gateways. With ad
hoc I mean in this context that nodes can be plugged into and taken out
of the network at any moment in time. If one would do this on a normal
wired ethernet subnet, this works fine, thanks to the IPv6
autoconfiguration capabilities: the Internet gateways transmit Router
Advertisements, which are used by all other nodes to autoconfigure their
own (global) IPv6 addresses.
When replacing the fixed ethernet by a meshed ad hoc wireless net, I
would like this to work just the same.
Unfortunately, and here's the argument: basic L3 meshing does not allow
that. It creates a routing domain instead of a subnet, and IPv6
autoconfiguration does not work through routers. Similar problems occurs
with broad- and multicast.
One way to solve this is to re-invent autoconfiguration specifically for
L3 meshing, which is non-trivial, and which is exactly what is happening
now in IETF, given the large amount of RFCs on this and related subjects.
Another solution is meshing below IP. Then your mesh network, from
IP/IPv6 point of view, behaves like a normal subnet again, so all
standard IP/IPv6 mechanism work as expected.
I've explored both solutions, spent several months on trying (and
failing) to get OLSR to do what I wanted, and then spent a couple of
weeks to create FLAME.
The second argument is that in the future meshing is going to be built
into the relevant MAC layers (see 802.11s and corresponding efforts for
e.g. Wimax and Zigbee),
so "below IP" seems the natural place to solve this.
Regards,
Herman.
^ permalink raw reply
* Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing
From: Herman Elfrink @ 2006-05-30 8:43 UTC (permalink / raw)
To: Alan Cox; +Cc: Erik Mouw, Simon Oosthoek, netdev
In-Reply-To: <447BE93D.2070605@ti-wmc.nl>
Hi,
Seems that instead of clearing the confusion I was confused myself.
What we are talking about here is the protocol ID carried in the
ethernet header, which ethernet uses to identify the network layer (as
defined in the file <linux/if_ether.h>).
So its indeed IEEE to address for this, and not IANA.
Thanks for your help on this issue.
Herman.
Herman Elfrink wrote:
> An attempt to clear up the confusion that seems to have occurred:
> FLAME is an intermediate layer between existing MAC and network (IP)
> layers.
> From MAC layer point of view FLAME is another network layer protocol
> (besides IP, IPX etc.), so the FLAME protocol ID we are taking about
> is a network layer (IANA) protocol number.
> From IP point of view FLAME behaves like a 'normal' ethernet-type MAC
> layer; no need for new IEEE protocol number.
>
> Regards,
>
> Herman Elfrink.
>
> Alan Cox wrote:
>
>> On Maw, 2006-05-23 at 16:55 +0200, Erik Mouw wrote:
>>
>>
>>>>> Ethernet protocol number I assume you mean. If so this at least
>>>>> used to
>>>>> be handled by the IEEE, along with ethernet mac address ranges.
>>>>>
>>>>>
>>>>
>>>> Yes ethernet protocol (it's below IP level), I didn't realise that
>>>> IEEE also handled the portnumbers. I'll check the ieee website to
>>>> see how it works, tnx!
>>>>
>>>
>>> IEEE doesn't handle port numbers. Port numbers are for whatever is
>>> layered on top of ethernet, so you need to register those with the
>>> appropriate authorities (IANA for IP).
>>>
>>
>>
>> No no no
>>
>> There are several sets of numbers here
>>
>> Each ethernet DIX frame has a "protocol" (its the bits used for length
>> in 802.*). IEEE at least used to handle the assignment of those. On top
>> of that you have IP, IPX, etc with their own numbering agency.
>>
>> As he said "ethernet protocol (it's below IP level)", those are the
>> protocol numbering bodies he wants, or to whomever it was delegated.
>>
>> Alan
>>
>>
>>
>>
>
>
^ permalink raw reply
* Re: sky2 hw csum failure [was Re: sky2 large MTU problems]
From: Daniel J Blueman @ 2006-05-30 9:10 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Stephen Hemminger, netdev, Netfilter Developer
In-Reply-To: <447591DB.2020901@trash.net>
On 25/05/06, Patrick McHardy <kaber@trash.net> wrote:
> Daniel J Blueman wrote:
> > On 25/05/06, Patrick McHardy <kaber@trash.net> wrote:
> >
> >> Daniel, is there an easy way to reproduce the checksum failure?
> >
> > In short, no. This was seen when packets may have been truncated by
> > large MTU (eg 9000) problems in the sky2 driver transmit path.
> >
> > There is a small chance that this could relate to transmitting with an
> > MTU of 9000 (possibly with receiving with an MTU of 1500 too)
>
> Unfortunately I can't test this myself because my other NICs don't
> support MTUs > 1500.
>
> > On that interface, the only rules that were being exercised were:
> >
> > iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> > iptables -t filter -A INPUT -p tcp -m tcp --dport 445 --syn -j ACCEPT # SMB
> > iptables -t filter -A INPUT -j DROP
>
> That shouldn't cause any packet modifications. Can you trigger the
> checksum failures without netfilter?
When testing, I always run into the "kernel: sky2 lan0: rx error,
status 0x977d977d length 0" problem before anything else.
I need to eliminate the sky2 driver from the equation before I'm able
to prove if there is a problem elsewhere or not. I did have some e1000
NICs, but not any longer, so it'll have to wait until I can find a
stable scenario for my sky2 NIC...
--
Daniel J Blueman
^ permalink raw reply
* Re: Sign-off for the IP1000A driver before inclusion
From: Pekka J Enberg @ 2006-05-30 9:53 UTC (permalink / raw)
To: jesse\(建興\)
Cc: Andrew Morton, romieu, dvrabel, linux-kernel, netdev, david
In-Reply-To: <026801c683c8$e3f63860$4964a8c0@icplus.com.tw>
Hi Jesse,
On Tue, 30 May 2006, jesse\(??\)~H~H\) wrote:
> Sorry for that. I try to generate the patch file. But I only can use
> "diff -uN" to generate it. The "diff --git" is not work. I still try to
> generate it.
I assume you're using Francois' git tree, right? What you need to do is:
- Check out netdev-ipg branch:
git checkout netdev-ipg
- Create a new branch against netdev-ipg (this is where you'll do the
work):
git checkout -b ipg-mine
- Commit patches in your ipg-mine branch. Use git update-index and git
commit for this. Please commit each changeset separately. You can
use my patchset as a starting point:
http://www.cs.helsinki.fi/u/penberg/linux/ip1000-jesse/
- When you're done, you can generate diffs against the netdev-ipg
branch:
git format-patch netdev-ipg ipg-mine
- If you want, you can then delete your working branch:
git checkout netdev-ipg ; git branch -D ipg-mine
On Tue, 30 May 2006, jesse\(??\)~H~H\) wrote:
> --Changelog:
> --Updata mentainer information
> --Remove some default phy params
> --Remove Threshold comfig and RxDMAInt from ipg_io_config(). Remove relative
> define form ipg.h
> --Remove and Rewrite ipg_config_autoneg() function.
The changelog isn't telling me much. Why are you removing default phy
params and the threshold config?
Pekka
^ permalink raw reply
* BUG: warning at ... (netlink) [Was: 2.6.17-rc5-mm1]
From: Jiri Slaby @ 2006-05-30 11:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, jgarzik, netdev, kuznet, alan
In-Reply-To: <20060530022925.8a67b613.akpm@osdl.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrew Morton napsal(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm1/
BUG: warning at /l/latest/xxx/kernel/softirq.c:86/local_bh_disable()
[<c0103e66>] show_trace+0x1b/0x1d
[<c01045a4>] dump_stack+0x26/0x28
[<c012708f>] local_bh_disable+0x53/0x55
[<c0399fd6>] _write_lock_bh+0x10/0x15
[<c034e314>] netlink_table_grab+0x12/0xe9
[<c034e6f6>] netlink_insert+0x2a/0x156
[<c034fa46>] netlink_kernel_create+0xad/0x143
[<c051f869>] rtnetlink_init+0x70/0xc7
[<c051fb9f>] netlink_proto_init+0x187/0x192
[<c01003cb>] init+0x12b/0x2f1
[<c0101005>] kernel_thread_helper+0x5/0xb
If more info needed, feel free to ask.
regards,
- --
Jiri Slaby www.fi.muni.cz/~xslaby
\_.-^-._ jirislaby@gmail.com _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEfCYeMsxVwznUen4RApvNAJ94piY4mvFzO9x3qSBKL8DstkeBbgCguCnz
Zzw1YFf/s3AtKVo0XgYWsek=
=x+hX
-----END PGP SIGNATURE-----
^ permalink raw reply
* zd1201 & ipw2200 problems
From: Pavel Machek @ 2006-05-30 11:17 UTC (permalink / raw)
To: Netdev list, Jirka Lenost Benc, kernel list; +Cc: Greg KH
Hi!
I see some strange problems with zd1201. (Ccing greg, he seen
something similar).
Wireless LAN is configured on eth1 (ipw2200) and works. I insert
zd1201 usb wireless card, and pings stop. I do not have (or should not
have) any hotplug scripts doing anything. Leds on zd1201 light up.
If I unplug zd1201, pings immediately continue.
If I issue iwlist wlan0 scan, zd1201 discovers some networks, its led
goes out, and ipw2200 ping immediately continue (ipw2200 starts to
work).
Now... what is going on? Any ideas how to debug it?
Plus, zd1201 does not work on sharp zaurus (pxa arm-based)
machine. (Any idea if that is little or big endian?). It is detected
okay, lights light up, but iwlist wlan0 scan produces no results.
Pavel
pavel@amd:~$ cat /proc/interrupts
CPU0
0: 776518 XT-PIC timer
1: 12266 XT-PIC i8042
2: 0 XT-PIC cascade
8: 1 XT-PIC rtc
9: 123162 XT-PIC acpi
11: 48021 XT-PIC ohci1394, yenta, yenta,
ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3,
uhci_hcd:usb4, Intel 82801DB-ICH4, ipw2200
12: 11315 XT-PIC i8042
14: 21677 XT-PIC ide0
NMI: 0
LOC: 0
ERR: 0
MIS: 0
pavel@amd:~$
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* drivers/connector/cn_queue.c:130: warning: value computed is not used
From: Andreas Schwab @ 2006-05-30 11:34 UTC (permalink / raw)
To: netdev
There is no point in testing the atomic value if the result is thrown
away.
Signed-off-by: Andreas Schwab <schwab@suse.de>
diff --git a/drivers/connector/cn_queue.c b/drivers/connector/cn_queue.c
index 9f2f00d..05f8ce2 100644
--- a/drivers/connector/cn_queue.c
+++ b/drivers/connector/cn_queue.c
@@ -127,7 +127,7 @@ void cn_queue_del_callback(struct cn_que
if (found) {
cn_queue_free_callback(cbq);
- atomic_dec_and_test(&dev->refcnt);
+ atomic_dec(&dev->refcnt);
}
}
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox