On Fri, 2006-11-17 at 18:46 +1100, Benjamin Herrenschmidt wrote:
> So what is the solution for Apple machines owner who only get a v3
> firmware from Apple ? I remember you telling me the answer on irc but I
> wanted to make it public :-) Some web site we can d/l the windows
> updates and extract
On Thu, 2006-11-16 at 15:07 +0100, Michael Buesch wrote:
> This fixes various bcm43xx-d80211 hwcrypto issues,
> which mainly prevented mcast frames from being decrypted properly.
>
> This is mostly a rewrite of the key managing code.
> Note that after this patch v3 firmware is no longer supported.
On Thu, Nov 16, 2006 at 11:25:01PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 17 Nov 2006, Jarek Poplawski wrote:
> >
> > With great astonishment I've found none of
> > these "networking" names in the CREDITS file:
> > Stephen Hemminger, Thomas Graf, Alexey Kuznetsov,
> > Andrew Morton, Pedro Ro
On Fri, 17 Nov 2006, Jarek Poplawski wrote:
>
> With great astonishment I've found none of
> these "networking" names in the CREDITS file:
> Stephen Hemminger, Thomas Graf, Alexey Kuznetsov,
> Andrew Morton, Pedro Roque, Jamal Hadi Salim,
> Herbert Xu etc.
You should basically consider the CRED
Hello,
With great astonishment I've found none of
these "networking" names in the CREDITS file:
Stephen Hemminger, Thomas Graf, Alexey Kuznetsov,
Andrew Morton, Pedro Roque, Jamal Hadi Salim,
Herbert Xu etc.
IMHO there is something wrong with the hitherto
way of updating this file and probably so
Wei Yongjun <[EMAIL PROTECTED]> wrote:
>
> Yes, time_after() works correctly for values that wraparound. For examples:
> if
> time a = (unsigned long)(-1), and time b = 1; time_after(b, a) = true.
> But if a is increaseing, after a circle of jiffies, a' = a + (unsigned
> long)(-1)
> + 1 = (uns
David,
Please consider pulling from the "2.6.19-rc6-20061117-to-davem-20061117"
branch at
,
which contains the following changesets:
HEADLINES
-
[IPV6] ROUTE: Try to use router which is not known unreachable.
[IPV6] ROUTE: Prefer reachable nexthop only if the caller requ
On Friday, November 17, 2006 11:51 AM
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
On Thu, 16 Nov 2006 23:57:50 -0500
Li Yewang <[EMAIL PROTECTED]> wrote:
[1]Summary of the problem:
On IA32 system, If jiffies - b > 0x7fff, router can not send
redirect packet.unsigned long b = rt->u.dst.rat
On Friday 10 November 2006 09:42, Dan Williams wrote:
> On Thu, 2006-11-09 at 18:16 -0500, Luis R. Rodriguez wrote:
> > On 11/9/06, Luis R. Rodriguez <[EMAIL PROTECTED]> wrote:
> > > On 11/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > Am Mittwoch, 8. November 2006 01:39 schrieben Sie:
From: Randy Dunlap <[EMAIL PROTECTED]>
drivers/built-in.o: In function `netxen_nic_remove':
netxen_nic_main.c:(.text+0x31b4d): undefined reference to `pci_disable_msi'
netxen_nic_main.c:(.text+0x31b8e): undefined reference to `pci_release_regions'
drivers/built-in.o: In function `netxen_init_modul
Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
>
> BUG()s there would be a mechanism to document invariants so next time
> someone is looking at the code there are no questions.
Well if someone is documenting this then wouldn't a comment (or even a
kerneldoc style block) be better?
Cheers,
--
Visit
On Thursday 16 November 2006 19:37, Herbert Xu wrote:
> David Miller <[EMAIL PROTECTED]> wrote:
> >
> > I'm very happy to accept a patch which assert's this using BUG()
> > checks :-)
>
> A BUG() won't be necessary because the NULL pointer dereferences will
> OOPS anyway.
>
BUG()s there would be
> +struct t3_send_wr {
> +struct fw_riwrh wrh;/* 0 */
> +union t3_wrid wrid; /* 1 */
> +
> +enum t3_rdma_opcode rdmaop:8;
> +u32 reserved:24;/* 2 */
Does this do the right thing wrt endianness? I'd be more comfortable
with something like
u8 rdmaop;
On Thu, 16 Nov 2006 23:57:50 -0500
Li Yewang <[EMAIL PROTECTED]> wrote:
> [1]Summary of the problem:
> On IA32 system, If jiffies - b > 0x7fff, router can not send
> redirect packet.unsigned long b = rt->u.dst.rate_last
> +(ip_rt_redirect_load << rt->u.dst.rate_tokens)
>
> [2]Full description
On 2006-11-16, Ian McDonald wrote:
> I've searched lkml archives but can't find anything there apart from
> one person complaining.
>
> Can anybody basically tell me how to get access to git trees in a way
> that works at present?
>
> I've tried git://git.kernel.org, git://git2.kernel.org,
> http:/
Michael Chan wrote:
David, A set of BNX2 patches for 2.6.20 to fix bugs, improve
SerDes, and support a new chip. Please review and apply.
ACK patchkit
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
[1]Summary of the problem:
On IA32 system, If jiffies - b > 0x7fff, router can not send
redirect packet.unsigned long b = rt->u.dst.rate_last
+(ip_rt_redirect_load << rt->u.dst.rate_tokens)
[2]Full description of the problem:
In linux kernel, if time_after(jiffies, (rt->u.dst.rate_last
+(ip_rt
On Thu, 2006-11-16 at 18:25 -0500, John W. Linville wrote:
> On Fri, Nov 17, 2006 at 12:04:29AM +0100, Johannes Berg wrote:
> > Remove things like "for (;;)" or "for (; condition ;)".
> > Ever heard of while loops?
>
> > --- wireless-dev.orig/net/d80211/sta_info.c 2006-11-16 23:40:48.164935990
>
[BNX2]: Add bnx2_5706_serdes_timer().
Separate the 5706S SerDes handling code in bnx2_timer() and put it
in a new function.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 9b391cf..7897481 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/ne
[BNX2]: Add 5709 PCI ID.
Add PCI ID and detection for 5709 copper and SerDes chips.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 92897ef..157463b 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -86,6 +86,7 @@ typedef enum
[BNX2]: Update version and rel date.
Update version to 1.5.1.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 157463b..fc2f1d1 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -57,8 +57,8 @@
#define DRV_MODULE_NAME
[BNX2]: Download 5709 firmware.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 52fe620..92897ef 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -53,6 +53,7 @@
#include "bnx2.h"
#include "bnx2_fw.h"
+#include "bnx2_fw2.h"
[BNX2]: New firmware to support 5709 (part 3).
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2_fw2.h b/drivers/net/bnx2_fw2.h
index 66ff441..abab341 100644
--- a/drivers/net/bnx2_fw2.h
+++ b/drivers/net/bnx2_fw2.h
@@ -2335,3 +2335,715 @@ static struct fw_info bnx2_cp
[BNX2]: Add 5709 reset and runtime code.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index baad015..52fe620 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -3247,31 +3247,44 @@ bnx2_reset_chip(struct bnx2 *bp, u32 res
*
[BNX2]: Add 5709 init code.
Add basic support to initialize the 5709 chip.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 2633579..baad015 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -236,8 +236,23 @@ static void
bnx2_c
[BNX2]: Add 5708S parallel detection.
Add code to parallel detect 1Gbps and 2.5Gbps link speeds.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 7897481..ea5daf6 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -1067,19 +1067,
[BNX2]: Remove udelay() in copper PHY code.
Change a long udelay() in bnx2_setup_copper_phy() to msleep().
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index ea5daf6..0a46b45 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -1159
[BNX2]: Improve SerDes handling.
1. Add support for 2.5Gbps forced speed setting.
2. Remove a long udelay() loop and change to msleep().
3. Other misc. SerDes fixes.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index b60e45d..9b391cf 100644
[BNX2]: Re-organize firmware structures.
Re-organize the firmware handling code and declarations a bit to make
the code more compact.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 0a46b45..2633579 100644
--- a/drivers/net/bnx2.c
+++ b/
David, A set of BNX2 patches for 2.6.20 to fix bugs, improve
SerDes, and support a new chip. Please review and apply.
Thanks.
[PATCH 1/17][BNX2]: Fix Xen problem.
[PATCH 2/17][BNX2]: Improve SerDes handling.
[PATCH 3/17][BNX2]: Add bnx2_5706_serdes_timer().
[PATCH 4/17][BNX2]: Add 5708S paralle
The IGMPV3_EXP() macro doesn't correctly shift the normalization bit, so
time-out values are longer than they should be. Patch below for viewing
and attached for applying.
Thanks to Dirk Ooms for finding the problem in IGMPv3 - MLDv2 had a
similar problem that was already fixed a year ago. :-(
Ray Lee wrote:
First off, thanks for all your help.
Second off,
On 11/16/06, Larry Finger <[EMAIL PROTECTED]> wrote:
Ray Lee wrote:
>
> If I could figure out a way to make it repeatable, I'd happily do a
blind
> bisect.
[...]
> I'm open to suggestions on how to make the problem trigger more
David Miller <[EMAIL PROTECTED]> wrote:
>
> I'm very happy to accept a patch which assert's this using BUG()
> checks :-)
A BUG() won't be necessary because the NULL pointer dereferences will
OOPS anyway.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL
On Thu, Nov 16, 2006 at 07:00:02PM -0500, John W. Linville wrote:
> No need to resend. Any other opinions on this? I suppose it is just
> a beached discussion...
What the heck was I typing?
"a bikeshed discussion"
--
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send th
zd1211b chip 050d:705c v4810 high 00-17-3f AL2230_RF pa0 g--N
Tested by Bryan Barnard
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
zd_usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Index: linux/drivers/net/wireless/zd1211rw/zd_usb.c
=
Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> So if 'skb' is NULL, the only route I see that doesn't cause a NULL
> pointer deref is if (opt != NULL) and at the same time
> (opt->is_data != NULL) . Is that guaranteed in any way? If now,
> how come we don't blow up regularly?
Yes that's how it'
zd1211 chip 14ea:ab13 v4330 high 00-90-cc AL2230_RF pa0 g---
Tested by Tetsuya Yatagai.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
zd_usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Index: linux/drivers/net/wireless/zd1211rw/zd_usb.c
===
On Fri, Nov 17, 2006 at 12:37:40AM +0100, Johannes Berg wrote:
> > FWIW, I think I prefer the "for (;;)" version for endless loops.
> > It looks more intentional to me. Some grep'ing showed nearly equal
> > usage of "for (;;)" versus "while (1)". Is there any "official"
> > preference? I don't
From: "Jesper Juhl" <[EMAIL PROTECTED]>
Date: Thu, 16 Nov 2006 23:34:14 +0100
> So if 'skb' is NULL, the only route I see that doesn't cause a NULL
> pointer deref is if (opt != NULL) and at the same time
> (opt->is_data != NULL) . Is that guaranteed in any way?
Yes, it is guarenteed, all ca
On Thu, 2006-11-16 at 15:40 -0800, Jouni Malinen wrote:
> Isn't "for (;;)" the standard way of doing infinite loops? Please don't
> change that.
In *BSD it is apparently mandated, but Linux doesn't seem to do that as
John pointed out. Personally, I find while (1) much easier to read but
really, t
On Fri, Nov 17, 2006 at 12:04:29AM +0100, Johannes Berg wrote:
> Remove things like "for (;;)" or "for (; condition ;)".
> Ever heard of while loops?
Isn't "for (;;)" the standard way of doing infinite loops? Please don't
change that. Changing loops to use list_for_each*() is of course
welcome.
-
> > Ever heard of while loops?
was more about
> "for (; condition ;)".
:)
> FWIW, I think I prefer the "for (;;)" version for endless loops.
> It looks more intentional to me. Some grep'ing showed nearly equal
> usage of "for (;;)" versus "while (1)". Is there any "official"
> preference?
On Fri, Nov 17, 2006 at 12:04:29AM +0100, Johannes Berg wrote:
> Remove things like "for (;;)" or "for (; condition ;)".
> Ever heard of while loops?
> --- wireless-dev.orig/net/d80211/sta_info.c 2006-11-16 23:40:48.164935990
> +0100
> +++ wireless-dev/net/d80211/sta_info.c2006-11-16 23
First off, thanks for all your help.
Second off,
On 11/16/06, Larry Finger <[EMAIL PROTECTED]> wrote:
Ray Lee wrote:
>
> If I could figure out a way to make it repeatable, I'd happily do a blind
> bisect.
[...]
> I'm open to suggestions on how to make the problem trigger more than once
> ever
Remove things like "for (;;)" or "for (; condition ;)".
Ever heard of while loops?
Also clean up a bunch of things that list.h offers. No need to code it
here.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
---
This is just insane. Can't we just rewrite the whole thing? :)
I'm not really sur
On Thu, 2006-11-16 at 20:23 +, James Courtier-Dutton wrote:
> Hi,
>
> For a host using a Pentium 4 CPU at 2.8Mhz, what is a sensible max value
> for number of TCP sessions this host could run under Linux?
> Bandwidth per TCP session is likely to be about 10kbytes/second.
To a first order, a
Ray Lee wrote:
If I could figure out a way to make it repeatable, I'd happily do a blind
bisect. As it stands, I can't trigger it manually. I've got a while true; do
iwconfig eth1; done running to hit the ioctls (as the trace in my first
message showed one of them in use), but that's might be a
Adrian Bunk napisał(a):
On Thu, Nov 16, 2006 at 04:29:44PM +0100, Krzysztof Sierota wrote:
Hi,
I'm getting the following in dmesg with 2.6.19-rc5 and 2.6.19-rc6 kernels quad
opteron server running 64bit kernel, and the network card gets disabled.
...
Please send the dmesg from the l
Hi,
In net/ipv4/ip_options.c::ip_options_compile() we have the following
code at the start of the function :
int ip_options_compile(struct ip_options * opt, struct sk_buff * skb)
{
int l;
unsigned char * iph;
unsigned char * optptr;
int optlen;
unsigned char *
Hi John,
A user reported that commit 4e1bbd846d00a245dcf78b6b331d8a9afed8e6d7
(Remove unneeded packed attributes) breaks the zd1211rw driver on ARM.
Please revert it for 2.6.19, we may attempt this change again at a later
date.
Thanks,
Daniel
-
To unsubscribe from this list: send the line "u
On Thu, 16 Nov 2006 20:23:37 +
James Courtier-Dutton <[EMAIL PROTECTED]> wrote:
> Hi,
>
> For a host using a Pentium 4 CPU at 2.8Mhz, what is a sensible max value
> for number of TCP sessions this host could run under Linux?
> Bandwidth per TCP session is likely to be about 10kbytes/second.
Jesse Brandeburg napisał(a):
On 11/16/06, Krzysztof Sierota <[EMAIL PROTECTED]> wrote:
Hi,
I'm getting the following in dmesg with 2.6.19-rc5 and 2.6.19-rc6
kernels quad
opteron server running 64bit kernel, and the network card gets disabled.
On identical server running 32bit kernel, same ca
On Thu, Nov 16, 2006 at 10:37:18PM +0100, Adrian Bunk wrote:
> Subject: aoe: Add forgotten NULL at end of attribute list in aoeblk.c
> References : http://lkml.org/lkml/2006/11/13/26
> Submitter : Dennis Stosberg <[EMAIL PROTECTED]>
> Caused-By : Greg Kroah-Hartman <[EMAIL PROTECTED]>
>
This email lists some known regressions in 2.6.19-rc6 compared to 2.6.18
that are not yet fixed in Linus' tree.
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
These two commands are currently unused. They were previously used to enable
hardware compression on Atheros hardware.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.ori
On Thu, Nov 16, 2006 at 04:29:44PM +0100, Krzysztof Sierota wrote:
> Hi,
>
> I'm getting the following in dmesg with 2.6.19-rc5 and 2.6.19-rc6 kernels
> quad
> opteron server running 64bit kernel, and the network card gets disabled.
>...
Please send the dmesg from the latest kernel that works
From: Al Viro <[EMAIL PROTECTED]>
Date: Thu, 16 Nov 2006 12:04:23 +
> FWIW, with these patches in we have net/ nearly endian-clean. Two
> major exceptions are ieee80211 and sctp. I think I've got more or
> less sane way to deal with the latter, it won't be fun (and yes,
> that's the queue I'
Hi,
For a host using a Pentium 4 CPU at 2.8Mhz, what is a sensible max value
for number of TCP sessions this host could run under Linux?
Bandwidth per TCP session is likely to be about 10kbytes/second.
Kind Regards
James
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
t
Fix an offset error when reading the CS89x0 ADD_PORT register.
Signed-off-by: George G. Davis
---
Index: linux-2.6/drivers/net/cs89x0.c
===
--- linux-2.6.orig/drivers/net/cs89x0.c
+++ linux-2.6/drivers/net/cs89x0.c
@@ -588,10 +588,10
On 11/16/06, Krzysztof Sierota <[EMAIL PROTECTED]> wrote:
Hi,
I'm getting the following in dmesg with 2.6.19-rc5 and 2.6.19-rc6 kernels quad
opteron server running 64bit kernel, and the network card gets disabled.
On identical server running 32bit kernel, same cards, same slots, same
configurat
This looks completely sane to me, so I have no problem merging this
stuff once the rest of the Chelsio-specific stuff is reviewed.
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/
I've searched lkml archives but can't find anything there apart from
one person complaining.
Can anybody basically tell me how to get access to git trees in a way
that works at present?
I've tried git://git.kernel.org, git://git2.kernel.org,
http://master.kernel.org, http://kernel.org all withou
Michael Buesch wrote:
> On Thursday 16 November 2006 19:17, Larry Finger wrote:
>> Ray Lee wrote:
>>> Larry Finger wrote:
Ray Lee wrote:
> Michael Buesch wrote:
>> On Wednesday 15 November 2006 20:01, Ray Lee wrote:
>>> Suggestions? Requests for even more info?
>> Yeah, enable
On Thursday 16 November 2006 19:17, Larry Finger wrote:
> Ray Lee wrote:
> > Larry Finger wrote:
> >> Ray Lee wrote:
> >>> Michael Buesch wrote:
> On Wednesday 15 November 2006 20:01, Ray Lee wrote:
> > Suggestions? Requests for even more info?
> Yeah, enable bcm43xx debugging.
> >>>
* Larry Finger ([EMAIL PROTECTED]) wrote:
> We have a report of a regression between 2.6.19-rc3 and -rc5. As this patch
> seems to be the only one that could cause the problem, please pull it from
> -stable while we sort out the difficulty.
Thanks a lot for the heads up Larry, dropping this one.
Ray Lee wrote:
Larry Finger wrote:
Ray Lee wrote:
Michael Buesch wrote:
On Wednesday 15 November 2006 20:01, Ray Lee wrote:
Suggestions? Requests for even more info?
Yeah, enable bcm43xx debugging.
Sigh, didn't even think to look for that. Okay, enabled and compiling
a new kernel. This wil
On Thu, 2006-11-16 at 09:40 -0800, Jouni Malinen wrote:
> It's been awhile since I working on this part, but if I remember
> correctly, this can be done easily by the driver behaving different
> based on the frame being fragmented or not (it is fragmented if MoreFrag
> flag is set or seq# != 0). T
On Thu, Nov 16, 2006 at 06:38:20PM +0100, Johannes Berg wrote:
> Oh, good point. Will need to think about this more. But right now, if
> that MMIC flag is set (i.e. hw does MMIC), we still do MMIC for
> fragmented frames. And there's actually a bug here I think: if hw does
> MMIC, how can the driv
On Thu, Nov 16, 2006 at 09:38:21AM -0800, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> Please retest with 2.76.18.2 or 2.6.19-rc6, there were some fixes
> already there.
I will install that kernel, but I can not test it right now.
If there will be any problem I will report it.
Thank you.
> --
On Thu, 2006-11-16 at 09:21 -0800, Jouni Malinen wrote:
> Hmm.. I think I need to see the patch for doing this before being able
> to decide whether I'd like this or not.. Michael MIC is a bit
> unfortunate design since it happens at MSDU, not MPDU level. Because of
> this, most hardware designs h
On Thu, 16 Nov 2006 20:35:32 +0300
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 31, 2006 at 12:44:25PM +0300, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
> > > > > > Bug was filled against 2.6.17-9, but was fixed in recent git
> > > > > > (2.6.19-rc3), probably also
> > > > > > fi
On Thu, Nov 16, 2006 at 10:52:42AM +0100, Johannes Berg wrote:
> I think we should simplify the stack code by making it have *only* the
> distinction between between hardware and software crypto (on a per-key
> basis).
Hmm.. I think I need to see the patch for doing this before being able
to deci
Kenzo Iwami wrote:
> ethtool processing holding semaphore
> INTERRUPT
> e1000_watchdog waits for semaphore to be released
>
> The semaphore e1000_watchdog is waiting for can only be released when
> ethtool resumes from interrupt after e1000_watchdog finishes
> (basically a deadlock)
>
Chris Wright wrote:
-stable review patch. If anyone has any objections, please let us know.
--
From: Michael Buesch <[EMAIL PROTECTED]>
Drain the Microcode TX-status-FIFO before we enable IRQs.
This is required, because the FIFO may still have entries left
from a previous run.
Hi,
I'm getting the following in dmesg with 2.6.19-rc5 and 2.6.19-rc6 kernels quad
opteron server running 64bit kernel, and the network card gets disabled.
On identical server running 32bit kernel, same cards, same slots, same
configuration running rc5 I see no errors.
irq 48: nobody cared (t
Hi.
> At least, this way we have a chance to get USB working as well (See
> http://madwifi.org/ticket/33).
It's not the HAL that prevents MadWifi implementing USB support. Replacing
the binary-only HAL with OpenHAL and/or dissolving the HAL functionality
in the driver source does not get us any c
On Wed, 2006-11-15 at 14:39 -0500, Pavel Roskin wrote:
> Hello!
>
> On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote:
> > On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote:
> >
> > > Now that it seems to be ok to use these openbsd sources, should I port
> > > them to my driv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Michael,
>> I don't think anyone likes the HAL-based architecture. I don't think
>> we will accept a HAL-based driver into the upstream kernel.
>
> Yeah, wanted to hear that. ;)
+1
At least, this way we have a chance to get USB working as well
This fixes various bcm43xx-d80211 hwcrypto issues,
which mainly prevented mcast frames from being decrypted properly.
This is mostly a rewrite of the key managing code.
Note that after this patch v3 firmware is no longer supported.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireles
On Wed, Nov 15, 2006 at 07:48:08PM +0100, Michael Buesch wrote:
> Please test if this fixes hwcrypto.
> Note that we will require v4 firmware with this patch.
> I will remove v3 firmware support, because it's _really_
> a huge pain to support both firmware versions.
> If someone wants to have v3 su
On Thu, Nov 16, 2006 at 05:58:40AM -0500, David Miller wrote:
>
> I just rebased net-2.6.20 at:
>
> master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.20.git
>
> Al Viro has been going crazy with endianness and checksum type
> sparse annotations, which brings the patch count up to 171.
Hi.
> Just in case you want to experiment, i have a working port of ar5k
> that works on madwifi-old before the BSD - HEAD merge...
Just to mention it: madwifi-old is no longer officially supported, and is
a bad ground to start working on IMO (at least for anything that goes
beyond a quick test).
Hi,
I've written a document to lay out what I'd like to do to make an AF_RXRPC
network protocol for Linux, with intent to replacing the current net/rxrpc/ in
the kernel and also providing an RxRPC transport for userspace.
Can you look it over and see what you think?
Also, is it feasible to add
Faidon Liambotis wrote:
> H.323 connection tracking code calls ip_ct_refresh_acct() when
> processing RCFs and URQs but passes NULL as the skb.
> When CONFIG_IP_NF_CT_ACCT is enabled, the connection tracking core tries
> to derefence the skb, which results in an obvious panic.
> A similar fix was a
I just rebased net-2.6.20 at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.20.git
Al Viro has been going crazy with endianness and checksum type
sparse annotations, which brings the patch count up to 171.
Not bad for how long the net-2.6.20 tree has been open :-)
I'm moving over
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 15 Nov 2006 15:16:46 -0800
> If Dave wants to nod at it then I can merge all of it, else I can hand
> patch 3/3 over to Dave once its prerequisites are in mainline.
I'm completely fine with this, nice work Christoph.
Andrew, just toss it all into
H.323 connection tracking code calls ip_ct_refresh_acct() when
processing RCFs and URQs but passes NULL as the skb.
When CONFIG_IP_NF_CT_ACCT is enabled, the connection tracking core tries
to derefence the skb, which results in an obvious panic.
A similar fix was applied on the SIP connection track
Compiling the program which uses a lot "sysctl" syscalls, gives me this
warning on Debian unstable:
"warning: the `sysctl' syscall has been removed from 2.6.18+ kernels,
direct access to `/proc/sys' should be used instead."
Is it true? And what can be used as alternative which would work with b
Just in case you want to experiment, i have a working port of ar5k
that works on madwifi-old before the BSD - HEAD merge...
well i'm no good programmer (yet), i did what i could (i'm sure those
define macros are nasty for most people :P) and hope that helps...
you can git clone from the followin
On Wed, 2006-11-15 at 17:25 +0100, Johannes Berg wrote:
> Instead of putting all this into the stack, however, I think we could
> make those drivers that require it do the bookkeeping and export
> ieee80211_tkip_gen_phase1key and ieee80211_tkip_gen_rc4key for their
> use. Maybe that's too much aga
On Thu, 16 Nov 2006 01:11:20 -0800
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=7535
>
>Summary: ARP notifications to NETLINK_ROUTE
> Kernel Version: 2.6.16, 2.6.17
> Status: NEW
> Severity: normal
> Owner: [EMAIL PROTECT
Hi,
Thank you for your comment.
>>> I think this problem occurs because interrupt handler is executed in same
>>> CPU as process that acquires semaphore.
>>> How about disabling interrupt while the process is holding the semaphore?
>>> I think this is possible, if the total lock time has been red
92 matches
Mail list logo
