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.txt:
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
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
---
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
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.
---
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
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
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
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
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]
---
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.
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, which is
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. 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
explicit
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
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 should be
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
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
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 interrupts, and I
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!
So then what
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.
--
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 suggest to
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
23 matches
Mail list logo
