Quoting Michael Buesch <[EMAIL PROTECTED]>:
> > drivers/ssb/driver_mips/mips.c includes asm/time.h, which is missing on
> > x86_64. It also refers to struct ssb_serial_ports, which is not defined
> > anywhere.
>
> Yeah, CONFIG_SSB_MIPS should depend on the MIPS CPU.
> Which kconfig option do you
This fix attempts to solve a customer (IBM) reported issue with NAPI
enabled e1000 having bad performance when transmitting simultaneously
on four ports. The issue comes down to an interaction between NAPI,
hardware interrupt balancing, and the driver rescheduling poll on
the same processor. Try
Hi,
This patch series contains exclusively fixes for e1000. Some of these patches
were
already sent in december, but didn't make it into any usptream tree yet. Most
importantly, it addresses two issues in the recently merged msi interrupt
handler and dynamic itr code. A performance fix and some m
Since the driver sets the IP checksum insertion bit (IXSM in Status
field) in transmit context descriptors, it should clear the IP checksum
bits of any garbage so as not to confuse the hardware.
Signed-off-by: Bruce Allan <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drive
Unfortunately the read-free MSI interrupt handler needs to flush write
the icr register and thus we can't be read-free. Our MSI irq routine
thus becomes a lot more simpler since we don't need to track link state
anymore.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index ae76479..2035ca4 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/driver
Remvoe duplicate code handling erraneous user supplied wrong case
of gigabit speed with half duplex.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_param.c | 15 +++
1 files changed, 3 insertions(+), 12 d
Print RX/TX flow control setting at link up time to display the
actual link FC properties instead of the advertised values.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/driv
The driver was still mis-calculating the number of bytes sent during
transmit, now the driver computes what appears to be exactly 100%
correct byte counts (not including CRC) when figuring out how many
bytes and frames were sent during the current transmit packet.
---
drivers/net/e1000/e1000_mai
Remove unused MSGOUT macro and add "\n" to function debug output.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_osdep.h |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000/e1000_osdep.h b/drivers/net/e1000/e1000_osdep.h
index 1
On Tue, Jan 09, 2007 at 12:01:28PM +0300, Dmitriy Monakhov wrote:
> ata pci drivers have to return correct error code during resume stage in
> case of errors.
...
> @@ -6246,8 +6253,10 @@ int ata_pci_device_suspend(struct pci_de
> int ata_pci_device_resume(struct pci_dev *pdev)
> {
> struct
You can get the 2.6.18 patches from
ftp://lwfinger.dynalias.org/patches. You will need the PCI-E
patch for 2.6.18.1, and will probably want the
patch_2.6.18.1_fix_leds and radio_hwenable_for_2.6.18
patches if your radio has a switch.
Thank you I will try it when I get the time.
--
http://ww
evan foss wrote:
>> This hunk is OK, but I just want to point out that bustype is
>> always equal to BCM43xx_BUSTYPE_PCI ;)
>> The 0x53 timeouts are for an SSB-BUS.
>> So strictly said this hunk is a NOP.
>>
>> The other hunks are OK, too. They fix real bugs.
>> Thanks for spotting them, Larry!
>
Michael Buesch wrote:
> On Friday 12 January 2007 19:50, Stephen Sinclair wrote:
>>> The PCI-E modifications to bcm43xx do not set up the interrupt vector
>>> correctly. Tested with BCM4311 (PCI-E) on x86_64 and BCM4306 (PCI) on i386.
>> This was successful for me. My 4311 is now getting interrupt
This hunk is OK, but I just want to point out that bustype is
always equal to BCM43xx_BUSTYPE_PCI ;)
The 0x53 timeouts are for an SSB-BUS.
So strictly said this hunk is a NOP.
The other hunks are OK, too. They fix real bugs.
Thanks for spotting them, Larry!
So then what fixed int's for Stephen
On Friday 12 January 2007 19:50, Stephen Sinclair wrote:
> > The PCI-E modifications to bcm43xx do not set up the interrupt vector
> > correctly. Tested with BCM4311 (PCI-E) on x86_64 and BCM4306 (PCI) on i386.
>
> This was successful for me. My 4311 is now getting interrupts, and I
> was able to
On Friday 12 January 2007 19:08, Larry Finger wrote:
> The PCI-E modifications to bcm43xx do not set up the interrupt vector
> correctly. Tested with BCM4311 (PCI-E) on x86_64 and BCM4306 (PCI) on i386.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
ACK.
> ---
>
> John,
>
> This fix shoul
The PCI-E modifications to bcm43xx do not set up the interrupt vector
correctly. Tested with BCM4311 (PCI-E) on x86_64 and BCM4306 (PCI) on i386.
This was successful for me. My 4311 is now getting interrupts, and I
was able to successfully associate with an AP. (i386)
Steve
-
To unsubscribe
The PCI-E modifications to bcm43xx do not set up the interrupt vector
correctly. Tested with BCM4311 (PCI-E) on x86_64 and BCM4306 (PCI) on i386.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This fix should be applied to wireless-2.6 _AND_ pushed upstream to
2.6.20-rcX. Without this
On Friday 12 January 2007 17:36, Larry Finger wrote:
> Michael Buesch wrote:
>
> I have one general question before I address your comments. Does a BCM43xx
> chip always have either a
> PCI or a PCI-E core? I've seen discussion on this list that makes me wonder.
> That is why I had some
> explic
Michael Buesch wrote:
I have one general question before I address your comments. Does a BCM43xx chip
always have either a
PCI or a PCI-E core? I've seen discussion on this list that makes me wonder.
That is why I had some
explicit tests for PCI-E in the code.
> On Friday 12 January 2007 05:52,
That's a good change.
Thanks.
-Amit
On Friday 12 January 2007 18:49, Richard Knutsson wrote:
> Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
> ---
>
> diff --git a/drivers/net/netxen/netxen_nic_main.c
> b/drivers/net/netxen/netxen_nic_main.c index 8a5792f..96e1bee 100644
> --- a/drivers/net/
On Friday 12 January 2007 05:52, Larry Finger wrote:
> The PCI-E modifications to bcm43xx do not set up the interrupt vector
> correctly.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> John,
>
> This fix should be applied to wireless-2.6 _AND_ pushed upstream to
> 2.6.20-rcX. With
On Friday 12 January 2007 08:25, Pavel Roskin wrote:
> Hello, Michael!
>
> I've tried the master branch of bcm43xx-wireless-dev.git for the first
> time. The results are not encouraging so far (although I'm quite new to
> this chipset).
>
> drivers/ssb/driver_mips/mips.c includes asm/time.h, whi
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/netxen/netxen_nic_main.c
b/drivers/net/netxen/netxen_nic_main.c
index 8a5792f..96e1bee 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1144,7 +1144,7 @@ static int __
On Thu, Jan 11, 2007 at 09:42:13AM -0800, Stephen Hemminger wrote:
> Paul McKenney has given lots of talks on RCU see:
> http://www.rdrop.com/users/paulmck/RCU/
>
> and look in Documentation/RCU
I've read a lot of this but it's sometimes confusing e.g.:
>From Documentation/RCU/checklist.t
26 matches
Mail list logo
