Kumar Gala wrote:
On Mar 30, 2006, at 12:36 PM, Andrew Grover wrote:
Wellit's true they're useful for debugging but I would put them in
the category of system statistics that shouldn't go in debugfs. I
think they are like /proc/interrupts' interrupt counts or the TX/RX
stats reported
Hi Jesse,
More datapoints.
First of all, I don't see the problem, so this is an exclusion data point.
Machine is up 1 day, 19:02
I use 2.6.16 and I'm NBOT running at Gigabit speed.
(just couldn't get e100 cards anymore, they are not sold anymore here)
Version: vendor 00:aa:00, model 56 rev 0
From: Ingo Oeser [EMAIL PROTECTED]
Date: Fri, 31 Mar 2006 10:57:06 +0200
Hi Jesse,
More datapoints.
First of all, I don't see the problem, so this is an exclusion data point.
Machine is up 1 day, 19:02
I use 2.6.16 and I'm NBOT running at Gigabit speed.
If you're not running at
From: Boris B. Zhmurov [EMAIL PROTECTED]
Date: Thu, 30 Mar 2006 17:29:09 +0400
Hello, Herbert Xu.
On 30.03.2006 14:12 you said the following:
On Thu, Mar 30, 2006 at 10:02:01AM +, Boris B. Zhmurov wrote:
[EMAIL PROTECTED] linux-2.6.16]$ patch -p1
From: Herbert Xu [EMAIL PROTECTED]
Date: Thu, 30 Mar 2006 20:52:45 +1100
Well I started from the beginning again, and found this. This may be
the smoking gun that we're after :)
The xmit routine is lockless but checks last_tx_tso outside the locked
section. So if a TSO packet wins a race
Ingo Oeser [EMAIL PROTECTED] wrote:
More datapoints.
First of all, I don't see the problem, so this is an exclusion data point.
Great. I think so far all the configurations that have this problem
are
e1000 + SMP + TSO
Since your machine is not SMP but has the other two things it would
From: Herbert Xu [EMAIL PROTECTED]
Date: Fri, 31 Mar 2006 20:16:53 +1100
Ingo Oeser [EMAIL PROTECTED] wrote:
More datapoints.
First of all, I don't see the problem, so this is an exclusion data point.
Great. I think so far all the configurations that have this problem
are
e1000
On Fri, Mar 31, 2006 at 01:35:40AM -0800, David S. Miller wrote:
He does not have TSO enabled, e1000 disables TSO when on a link speed
slower than gigabit.
Indeed. But I think that only happens on PCI Express and I don't think
Ingo is using PCI Express.
Cheers,
--
Visit Openswan at
Hi:
This patches merges the separate calls to le16_to_cpu and ntohl into one
swab32 call so that it is clear that we're simply changing a little-endian
value from the hardware to big-endian for the networking stack.
Let x be any 16 any 16-bit integer, we have
csum_fold(x 16) = csum_fold(x).
Hello, David S. Miller.
On 31.03.2006 13:12 you said the following:
From: Boris B. Zhmurov [EMAIL PROTECTED]
Date: Thu, 30 Mar 2006 17:29:09 +0400
Hello, Herbert Xu.
On 30.03.2006 14:12 you said the following:
On Thu, Mar 30, 2006 at 10:02:01AM +, Boris B. Zhmurov wrote:
[EMAIL
From: Zach Brown [EMAIL PROTECTED]
Date: Thu, 30 Mar 2006 15:00:30 -0800
We've had reports from customers of boxes with a week's uptime and 32k MTUs
getting failed order-3 allocs under:
udp_sendmsg .. ip_append_data .. {sock_wmalloc, sock_alloc_send_skb}
I came up with the following
On Fri, Mar 31, 2006 at 09:14:45PM +1100, Herbert Xu wrote:
Hi:
This patches merges the separate calls to le16_to_cpu and ntohl into one
swab32 call so that it is clear that we're simply changing a little-endian
value from the hardware to big-endian for the networking stack.
This defeats
From: Anton Blanchard [EMAIL PROTECTED]
Date: Sat, 25 Mar 2006 23:19:29 +1100
Previously we added NET_IP_ALIGN so an architecture can override the
padding done to align headers. The next step is to allow the skb
headroom to be overridden.
We currently always reserve 16 bytes to grow into,
On Fri, Mar 31, 2006 at 02:16:38PM +0400, Boris B. Zhmurov wrote:
And xdelta tells, that e1000.ko was modified :)
Thanks for checking again.
Anyway, it didn't take long to find another bug in the same area.
I'm afraid this driver does seem to be full of them :)
It sets last_tx_tso in between
From: Herbert Xu [EMAIL PROTECTED]
Date: Fri, 31 Mar 2006 21:39:56 +1100
Anyway, it didn't take long to find another bug in the same area.
I'm afraid this driver does seem to be full of them :)
Indeed.
Thanks for picking through this some more Herbert. I hope we got it
this time.
-
To
Hello, David S. Miller.
On 31.03.2006 14:45 you said the following:
From: Herbert Xu [EMAIL PROTECTED]
Date: Fri, 31 Mar 2006 21:39:56 +1100
Anyway, it didn't take long to find another bug in the same area.
I'm afraid this driver does seem to be full of them :)
Indeed.
Thanks for
On 31 Mar 2006, David S. Miller wrote:
He does not have TSO enabled, e1000 disables TSO when on a link speed
slower than gigabit.
You'll see something like the following in your logs:
e1000: eth0: e1000_watchdog_task: 10/100 speed: disabling TSO
Um...
---
$ uname -a
Linux king
Me again.
I think I have found where the issue is. I have updated the
network schema:
customer private network 10.0.0.0/8
|
|
+ipsec customer gateway (nokia/checkpoint)
|==MTU=1444
|
|
|---ipsec tunnel 10.0.0.0/8-172.29.128.0/28 (3DES/MD5)
|
|
|+---ipsec gateway (pleiadi)---priv net
Hello, Herbert Xu.
On 31.03.2006 14:52 you said the following:
BTW, if you kept the built tree it is possible to apply the patch and
then do a make which should compile just the e1000 driver.
Cheers,
Thank's for the tip, actually I knew that :) First of, I've already
applied some other new
- Original Message -
From: Herbert Xu [EMAIL PROTECTED]
To: David S. Miller [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED];
Hello, Herbert Xu.
On 31.03.2006 14:39 you said the following:
On Fri, Mar 31, 2006 at 02:16:38PM +0400, Boris B. Zhmurov wrote:
And xdelta tells, that e1000.ko was modified :)
Thanks for checking again.
Anyway, it didn't take long to find another bug in the same area.
I'm afraid this
On 31 Mar 2006, Boris B. Zhmurov wrote:
David, Herbert - FYI. One of my colleague confirmed, that idea bug
reproducible only if there is more then one e1000 adapter onboard is
true. He has a 3 servers with double intel pro 1000 adapters, and that
bug occurs. Also, he has 4 servers with
On Friday 31 March 2006 09:24, David S. Miller wrote:
For example, if you, for example, receive a lot of tiny UDP packets,
wherein the struct sk_buff overhead far exceeds the amount of data
in the packet, it still might not work out. You could specify 100K
and only be able to receive say 60K
On Friday 31 March 2006 14:07, Boris B. Zhmurov wrote:
David, Herbert - FYI. One of my colleague confirmed, that idea bug
reproducible only if there is more then one e1000 adapter onboard is
true. He has a 3 servers with double intel pro 1000 adapters, and that
bug occurs. Also, he has 4
Hi,
Herbert Xu wrote:
On Fri, Mar 31, 2006 at 01:35:40AM -0800, David S. Miller wrote:
He does not have TSO enabled, e1000 disables TSO when on a link speed
slower than gigabit.
dmesg|grep eth0
[4294671.426000] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
[4294679.125000]
Hello, Mark Nipper.
On 31.03.2006 16:10 you said the following:
This unfortunately is not the case. I have two e1000
interfaces but only eth1 is up and in use. And I still had
assertions.
Can you switch to eth0? There is no problem with _eth0_, my friend says.
And I still had
On Fri, Mar 31, 2006 at 04:23:02PM +0400, Boris B. Zhmurov wrote:
I'm already using kernel with second Herbert's patch. We'll see...
If it still fails, here is a debugging patch which should tell us
whether we need to look elsewhere.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Hello, Herbert Xu.
On 31.03.2006 16:35 you said the following:
On Fri, Mar 31, 2006 at 04:23:02PM +0400, Boris B. Zhmurov wrote:
I'm already using kernel with second Herbert's patch. We'll see...
If it still fails
Not yet. But give it a time :)
--
Boris B. Zhmurov
mailto: [EMAIL
- Original Message -
From: Boris B. Zhmurov [EMAIL PROTECTED]
To: Herbert Xu [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED];
Hello, Boris B. Zhmurov.
On 31.03.2006 16:23 you said the following:
Hello, Mark Nipper.
On 31.03.2006 16:10 you said the following:
This unfortunately is not the case. I have two e1000
interfaces but only eth1 is up and in use. And I still had
assertions.
Can you switch to
- Original Message -
From: JaniD++ [EMAIL PROTECTED]
To: BRM [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org
Sent: Friday, March 31, 2006 9:33 AM
Subject: Re: e1000 - packet lost bug in 6.3.9 (old version :NETDEV WATCHDOG:
eth0: transmit timed out)
- Original Message -
From:
Hello, Christiaan den Besten.
On 31.03.2006 17:12 you said the following:
Hi !
P.S. I have another high-load server as gateway. Same distro, same
kernels, but less memory (512Mb lowmem). eth0 up - e100, eth1 up -
e1000. No errors at all! It kinda looks like assertions happens on
systems,
On Tue, 21 Feb 2006, Jay Vosburgh wrote:
Originally submitted by Kenzo Iwami; his original description is:
The current bonding driver receives duplicate packets when broadcast/
multicast packets are sent by other devices or packets are flooded by the
switch. In this patch, new flags
I have done a little test to try to understand how ipsec and
mtu play together.
Here is my simple network schema:
net 172.16.0.0--|2.6.16 box|--internet--|2.4-KLIPS|--net 172.25.5.0
+---ipsec tunnel--+
When I run 'ping 172.25.5.30 -M do -s 1472 -c 3' from a
Hello, Boris B. Zhmurov.
On 31.03.2006 17:30 you said the following:
Herbert, with your second patch still no luck. After an hour of uptime I
have assertion (!sk-sk_forward_alloc) failed at net/core/stream.c (283)
again...
Trying your debug patch.
Hmm... with lastest debug patch I can't
On Thu, 30 Mar 2006, David S. Miller wrote:
From: Bill Fink [EMAIL PROTECTED]
Date: Fri, 31 Mar 2006 01:58:35 -0500
I don't think it makes perfect sense. If there's overhead, fine go
ahead and add the overhead, but do it under the covers and invisible
to the user.
How in the world
Hello, Boris B. Zhmurov.
On 31.03.2006 19:08 you said the following:
Hmm... with lastest debug patch I can't see any of debug info:
But wait a minute. Two days ago, without Herbert's patches, assertion's
errors was like this:
Mar 29 20:03:23 msk4 kernel: KERNEL: assertion
On 31 Mar 2006, Boris B. Zhmurov wrote:
stream.c (279) - stream.c (283)
af_inet.c (148) - af_inet.c (150)
That will be because the patches changed the line numbers
in the source I believe. Nothing helpful unfortunately.
--
Mark Nipper
On Thu, Mar 30, 2006 at 09:14:56PM -0700, Jeffrey V. Merkey wrote:
Yes, we need one. The adapter needs to maintain these stats from the
registers in the kernel structure and not
its own local variables.
Did you read the code to see what the adapter does with these stats?
Among other things,
On Thu, Mar 30, 2006 at 09:46:54PM -0800, Greg KH wrote:
(hint, use a tab...)
glurg.
[PATCH]: e1000: prevent statistics from getting garbled during reset.
If a PCI bus error/fault triggers a PCI bus reset, attempts to get the
ethernet packet count statistics from the hardware will fail,
Hello, Mark Nipper.
On 31.03.2006 20:01 you said the following:
On 31 Mar 2006, Boris B. Zhmurov wrote:
stream.c (279) - stream.c (283)
af_inet.c (148) - af_inet.c (150)
That will be because the patches changed the line numbers
in the source I believe. Nothing helpful
On Fri, 31 Mar 2006, Ingo Oeser wrote:
Hi,
Herbert Xu wrote:
On Fri, Mar 31, 2006 at 01:35:40AM -0800, David S. Miller wrote:
He does not have TSO enabled, e1000 disables TSO when on a link speed
slower than gigabit.
dmesg|grep eth0
[4294671.426000] e1000: eth0: e1000_probe: Intel(R)
Bill Fink wrote:
Another reason the SO_SNDBUF/SO_RCVBUF values shouldn't include
the kernel overhead. If the user requests 100K of kernel data
buffering, then they should get 100K. It shouldn't matter to the
user that the kernel would actually be using a total of 167K of
memory to satisfy
What exactly are you trying to do with that watch out for trailer_len
thing where you subtract 2 from datalen?
The danger is in chosing a datalen that just fits in a page but then
finding that it == length and so we want to add on trailer_len, bringing
the alloc back over a page.
The logic
2) What's wrong with taking deltas? Typical through-put performance
measurement is done by pre-loading the pipes (i.e. running for
a few minutes wihtout measuring, then starting the measurement).
I'd think that snapshotting the numbers would be easier, and is
trivially doable in user-space. I
Linas Vepstas wrote:
On Thu, Mar 30, 2006 at 09:14:56PM -0700, Jeffrey V. Merkey wrote:
Yes, we need one. The adapter needs to maintain these stats from the
registers in the kernel structure and not
its own local variables.
Did you read the code to see what the adapter does with
Could you please describe how struct ioat_dma_chan channels are freed?
Sorry, I got distracted by other issues and never ended up following
up on this. You're right, and it's just sloppiness on my part for
missing it, those structs are being leaked on module unload. I'll fix
it. Thanks.
On Mar 31, 2006, at 2:04 PM, Andrew Grover wrote:
On 3/31/06, Ingo Oeser [EMAIL PROTECTED] wrote:
Kumar Gala wrote:
Fair, but wouldn't it be better to have the association per client.
Maybe leave the one as a summary and have a dir per client with
similar stats that are for each client and
On 3/31/06, Ingo Oeser [EMAIL PROTECTED] wrote:
Kumar Gala wrote:
Fair, but wouldn't it be better to have the association per client.
Maybe leave the one as a summary and have a dir per client with
similar stats that are for each client and add a per channel summary
at the top level as
Airo firmware versions = 5.30.17 send re-association events to the
driver that are currently unrecognized, causing spurious disassociation
events to be sent to user space. Loss of sync due to scan requests also
results in disassociation events sent to user space. This patch traps
those two
Send scan completion events to user space when a scan completes.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
--- a/drivers/net/wireless/atmel.c.scan-fixups 2006-03-31 13:31:02.0
-0500
+++ b/drivers/net/wireless/atmel.c 2006-03-31 15:11:13.0 -0500
@@ -3463,6 +3463,7 @@
On 3/31/06, Kumar Gala [EMAIL PROTECTED] wrote:
Currently the code updates these variables (kept per cpu) every time a
copy is queued. See include/linux/dmaengine.h.
Might it be better to update when the transfer is done incase of an
error?
The queueing function is really in the best
In all but one case, the suspend and resume functions of PCMCIA drivers
contain mostly of calls to pcmcia_release_configuration() and
pcmcia_request_configuration(). Therefore, move this code out of the
drivers and into the core.
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
---
pcmcia_disable_device(struct pcmcia_device *p_dev) performs the necessary
cleanups upon device or driver removal: it calls the appropriate
pcmcia_release_* functions, and can replace (most) of the current drivers'
_release() functions.
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
---
Handle the _modifying_ operation sm91c92_cs requires in
pcmcia_modify_configuration, so that the only remaining users
of pcmcia_release_configuration() are within the pcmcia core
module.
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
---
drivers/mtd/maps/pcmciamtd.c |3 +--
Remove the unused DEV_RELEASE_PENDING flag, and move the DEV_SUSPEND flag
into the p_dev structure, and make use of it at the core level.
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
---
drivers/net/wireless/atmel_cs.c |2 +-
drivers/net/wireless/ray_cs.c |2 +-
Convert the remaining drivers which use pcmcia_release_io or
pcmcia_release_irq, and remove the EXPORT of these symbols.
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
---
Documentation/pcmcia/driver-changes.txt |4 ++--
drivers/isdn/hardware/avm/avm_cs.c | 10 +-
Instead of the DEV_OK macro, drivers should use pcmcia_dev_present().
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
---
drivers/char/pcmcia/cm4000_cs.c |4 ++--
drivers/char/pcmcia/cm4040_cs.c |2 +-
drivers/net/pcmcia/3c574_cs.c |4 ++--
As we do not allow setting Vcc in the pcmcia core, and Vpp1 and
Vpp2 can only be set to the same value, a lot of code can be
streamlined.
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
---
drivers/bluetooth/bluecard_cs.c |4
drivers/bluetooth/bt3c_cs.c |6
From: Andi Kleen [EMAIL PROTECTED]
Date: Fri, 31 Mar 2006 13:11:21 +0200
For TCP it doesn't apply anymore though because the kernel would
do a GC of the skbs in this case. So maybe it could be changed for STREAM
sockets.
TCP does some clever things to determine overhead on the send
side,
From: Bill Fink [EMAIL PROTECTED]
Date: Fri, 31 Mar 2006 10:15:08 -0500
Another reason the SO_SNDBUF/SO_RCVBUF values shouldn't include
the kernel overhead. If the user requests 100K of kernel data
buffering, then they should get 100K. It shouldn't matter to the
user that the kernel would
Zach Brown [EMAIL PROTECTED] wrote:
Index: 2.6.16-mm2-bigmtu/net/ipv4/ip_output.c
===
--- 2.6.16-mm2-bigmtu.orig/net/ipv4/ip_output.c
+++ 2.6.16-mm2-bigmtu/net/ipv4/ip_output.c
@@ -891,13 +891,26 @@ alloc_new_skb:
Marco Berizzi [EMAIL PROTECTED] wrote:
Pleiadi is also running another tunnel with an old linux
2.4.28/KLIPS FreeS/WAN 2.05 an the MTU is 1444. May anyone
explain me why ipsec tunnels established with linux 2.6.16
(linux 2.6-linux2.6) have an MTU equal to 1428? And why
tunnels established
For the else clause wouldn't we be counting fragheaderlen twice if
the multi page if falls through above despite NETIF_F_SG being true?
Looks like, yeah. I'll fix up and resend. Thanks for the sharp eyes.
- z
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in RFC
3927. There are several user space daemons available that implement
most of the protocol (zcip, busybox, ...). The kernel's APR
Has anyone had a chance to run pktgen between a pair of 82597EX
adapters? I am interested if anyone has pps numbers for 1500 MTU
and perhaps 9000 MTU.
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the
On Fri, 2006-31-03 at 15:26 -0800, David Daney wrote:
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in RFC
3927. There are several user space daemons available that implement
On Wed, 2006-29-03 at 13:16 -0800, [EMAIL PROTECTED] wrote:
On Wed, 2006-29-03 at 11:14 -0800, Jouni Malinen wrote:
[..]
A digression: One of the problems of the bridge in my opinion is having
STP, a control protocol, inside the kernel. I do hope someone with time
will rip it out of
David Daney [EMAIL PROTECTED] wrote:
--- net/ipv4/arp.c.orig 2006-03-31 13:44:50.0 -0800
+++ net/ipv4/arp.c 2006-03-31 13:48:26.0 -0800
@@ -690,8 +691,13 @@ void arp_send(int type, int ptype, u32 d
if (dev-flagsIFF_NOARP)
return;
+ /* If
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
[...]
I took this patch from linux-2.6 using git tree and applied to 2.6.16.1
together with recent link status fix. Unfortunately broadcast packet
duplication still occurs.
I am unable to induce any duplicate packets using the current
David Daney [EMAIL PROTECTED] wrote:
In any event, yes we should be testing the dest_ip. If the ARP packet
is destined for the link local network, it should be broadcast.
The RFC seems to talk about sender IP address instead though...
--
Visit Openswan at http://www.openswan.org/
Email:
Remove Host AP and Prism2 references from IEEE 802.11 crypto code. Clean
up coding style and some comments. Replace couple of kmalloc+memset with
kzalloc.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-2.6/include/net/ieee80211_crypt.h
On Sat, 2006-01-04 at 13:01 +1100, Herbert Xu wrote:
David Daney [EMAIL PROTECTED] wrote:
In any event, yes we should be testing the dest_ip. If the ARP packet
is destined for the link local network, it should be broadcast.
The RFC seems to talk about sender IP address instead
From: Mark Butler [EMAIL PROTECTED]
Date: Fri, 31 Mar 2006 10:26:05 -0700
That could be done with separate atomic variables for allocated data and
allocated overhead, at measurable cost with relatively little gain.
Overhead would still have be tracked and limited separately to handle
Hi Dave:
This patch removes the decap_state argument from the xfrm input hook.
Previously this function allowed the input hook to share state with the
post_input hook. The latter has since been removed.
The only purpose for it now is to check the encap type. However, it is
easier and better to
jamal wrote:
On Wed, 2006-29-03 at 13:16 -0800, [EMAIL PROTECTED] wrote:
On Wed, 2006-29-03 at 11:14 -0800, Jouni Malinen wrote:
[..]
A digression: One of the problems of the bridge in my opinion is having
STP, a control protocol, inside the kernel. I do hope someone with time
will rip it
Hi Dave:
This patch removes the *_decap_state structures which were previously
used to share state between input/post_input. This is no longer needed.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL
Ayaz Abdulla wrote:
This patch adds flow control support for tx and rx pause frames in
forcedeth.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
Signed-Off-By: Manfred Spraul [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
Implement proper set_bssid_filter. If filters are not set, firmware receives
management frames only (instead of everything), so this is necessary.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
---
You know guys, it's very tough to be a moron. All this time I was trying
to set filters in
Ayaz Abdulla wrote:
This patch adds support for configuration of various parameters. This
includes module parameters and ethtool commands.
+
+ if (netif_running(dev)) {
+ nv_start_rx(dev);
+ nv_start_tx(dev);
+ nv_enable_irq(dev);
+ }
+
Ayaz Abdulla wrote:
+
+ NvRegPowerState2 = 0x600,
+#define NVREG_POWERSTATE2_POWERUP_MASK 0x0F11
+#define NVREG_POWERSTATE2_POWERUP_REV_A3 0x0001
};
If the nic has a register 0x600, then we should
- ioremap enough memory. Right now, the code only remaps 0x270
- report
Ayaz Abdulla wrote:
if (nv_alloc_rx(dev)) {
- spin_lock(np-lock);
+ spin_lock_irqsave(np-lock, flags);
Tiny point:
there is not need for irqsave(): we are in timer context, that guarantees:
- bottom half disabled
- interrupts enabled
Just use
82 matches
Mail list logo
