In article <[EMAIL PROTECTED]> (at Sun, 17 Jun 2007 23:17:49 -0700 (PDT)),
David Miller <[EMAIL PROTECTED]> says:
> > [PATCH 1/3] [IPV6]: Restore semantics of Routing Header processing.
> > [PATCH 2/3] [IPV6]: Do not send RH0 anymore.
> > [PATCH 3/3] [IPV6]: Make IPV6_{RECV,2292}RTHDR boolean opt
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]>
Date: Mon, 18 Jun 2007 15:02:00 +0900 (JST)
> I think the IETF community is reaching consensus on deprecation of
> RH0 (Routing Header Type 0). RH0 is now handled as unknown RH type,
> e.g, accept it if segleft == 0, or send ICMPv6 Parameter Prob
Because reversing RH0 is no longer supported by deprecation
of RH0, let's make IPV6_{RECV,2292}RTHDR boolean options.
Boolean are more appropriate from standard POV.
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
---
include/linux/ipv6.h |4 ++--
net/ipv6/ipv6_sockglue.c |8 ++--
Based on .
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
---
Documentation/networking/ip-sysctl.txt |3 +-
include/linux/ipv6.h |4 +-
net/ipv6/datagram.c|3 +-
net/ipv6/exthdrs.c | 57
The "fix" for emerging security threat was overkill and it broke
basic semantic of IPv6 routing header processing. We should assume
RT0 (or even RT2, depends on configuration) as "unknown" RH type so
that we
- silently ignore the routing header if segleft == 0
- send ICMPv6 Parameter Problem messa
Hello.
I think the IETF community is reaching consensus on deprecation of
RH0 (Routing Header Type 0). RH0 is now handled as unknown RH type,
e.g, accept it if segleft == 0, or send ICMPv6 Parameter Problem to
the sender.
[PATCH 1/3] [IPV6]: Restore semantics of Routing Header processing.
[PATCH
(Same from previous patch, resending for completion)
Changes :
- netif_queue_stopped need not be called inside qdisc_restart as
it has been called already in qdisc_run() before the first skb
is sent, and in __qdisc_run() after each intermediate skb is
sent (note : we are the only sender, s
New changes :
- Incorporated Peter Waskiewicz's comments.
- Re-added back one warning message (on driver returning wrong value).
Previous changes :
- Converted to use switch/case code which looks neater.
- "if (ret == NETDEV_TX_LOCKED && lockless)" is buggy, and the lockless
check should be r
On Fri, 2007-06-15 at 11:01 -0700, Waskiewicz Jr, Peter P wrote:
Hi Peter,
> I agree that the case shouldn't happen, and will only surface if the
> driver is indeed buggy. I've thought about this conditional being
> removed for awhile, since it will protect against a poorly written
> driver wrt
tc-pbfifo.8 does not exist because it was moved to tc-bfifo.8.
Signed-off-by: Yasuyuki Kozakai <[EMAIL PROTECTED]>
---
Makefile |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index dbcb249..af0d5e4 100644
--- a/Makefile
+++ b/Makefile
@@ -52,8 +52,
On Sun, 2007-06-17 at 14:03 +0200, Johannes Berg wrote:
> It sounds to me like you're proposing that wpa_supplicant is the only
> supported userspace MLME and that wpa_cli is the only way to configure
> it, basically. I sure hope that isn't so.
OK. This is the key of the discussion. Do we take wp
On Fri, 2007-06-15 at 06:49 -0400, jamal wrote:
> Hello Yi,
>
> On Fri, 2007-15-06 at 09:27 +0800, Zhu Yi wrote:
>
> > 1. driver becomes complicated (as it is too elaborate in the queue
> > wakeup strategies design)
>
> I am not sure i see the complexity in the wireless driver's wakeup
> strateg
On Sunday 17 June 2007, Michael Buesch wrote:
> The backplane on the b44 chip seems to have a silicon bug
> in the IRQ routing. The ethernet core IRQ routing does not work
> with the routing bit returned from the backplaneflag register.
> This patch adds a workaround for the b44 chip to use a hardc
* James Morris <[EMAIL PROTECTED]> wrote:
> > SELinux
> >
> > Subject: very high non-preempt latency in context_struct_compute_av()
> > References : http://lkml.org/lkml/2007/6/4/78
> > Submitter : Ingo Molnar <[EMAIL PROTECTED]>
> > Handled-By : Stephen Smalley <[EMAIL PROTECTED]>
> >
On Sun, 17 Jun 2007, Michal Piotrowski wrote:
> SELinux
>
> Subject: very high non-preempt latency in context_struct_compute_av()
> References : http://lkml.org/lkml/2007/6/4/78
> Submitter : Ingo Molnar <[EMAIL PROTECTED]>
> Handled-By : Stephen Smalley <[EMAIL PROTECTED]>
> Jam
Hi all,
Here is a list of some known regressions in 2.6.22-rc5
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Memory management
Subject: bug in i386 MTRR initialization
References : http://lkml.org/lkml/2007/5/19/93
S
The backplane on the b44 chip seems to have a silicon bug
in the IRQ routing. The ethernet core IRQ routing does not work
with the routing bit returned from the backplaneflag register.
This patch adds a workaround for the b44 chip to use a hardcoded
constant. This constant was also used in the old
On Sunday 17 June 2007 14:03:30 Maximilian Engelhardt wrote:
> On Sunday 17 June 2007, Michael Buesch wrote:
> > On Saturday 16 June 2007 23:27:43 Maximilian Engelhardt wrote:
> > > [...]
> > > ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
> > > ACPI: PCI Interrupt :02:02.0[A] -> Link [LNKD
On Sunday 17 June 2007, Michael Buesch wrote:
> On Saturday 16 June 2007 23:27:43 Maximilian Engelhardt wrote:
> > [...]
> > ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
> > ACPI: PCI Interrupt :02:02.0[A] -> Link [LNKD] -> GSI 10 (level, low)
> > -> IRQ 10
> > ssb: Sonics Silicon Backplan
[if you haven't seen the rest of the thread skip down to the === mark]
On Sat, 2007-06-16 at 15:16 -0700, Michael Wu wrote:
> > I don't think the implementation details are much of a problem. It's
> > just a bit of message bouncing which is trivial. Except of course when
> > you consider wext, bu
This bug was introduced by me.
val is 16bit, but the read value is 32bit.
Seems like I was smoking crack when porting that part of the driver.
I guess that's the last stupid bug in these 4 lines of code.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: bu3sch-wireless-dev/drivers/net/b44.
Hi all,
I have been investigating the random invalid instruction occourances on
sparc32 (sun4c) and identified that the problem was introduced
pre-v2.6.22-rc1. v2.6.21 is OK. The first time I have observed the issue
so far is after commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66:
Increase sla
On Sunday 17 June 2007 12:55:39 Michael Buesch wrote:
> On Saturday 16 June 2007 23:27:43 Maximilian Engelhardt wrote:
> > [...]
> > ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
> > ACPI: PCI Interrupt :02:02.0[A] -> Link [LNKD] -> GSI 10 (level, low)
> > ->
> > IRQ 10
> > ssb: Sonics Si
On Saturday 16 June 2007 23:27:43 Maximilian Engelhardt wrote:
> [...]
> ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
> ACPI: PCI Interrupt :02:02.0[A] -> Link [LNKD] -> GSI 10 (level, low) ->
> IRQ 10
> ssb: Sonics Silicon Backplane found on PCI device :02:02.0
> b44.c:v2.0
> eth0: B
hi,
Jeff please:
remove the "x" file access permission of:
drivers/net/qla3xxx.c
drivers/net/qla3xxx.h
move Documentation/networking/ifenslave.c to a user
space package(iputils, net-tools, )
-thanks-
regards,
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the bod
25 matches
Mail list logo
