Re: possible bug in net/tc35815.c in linux-2.6.19
On Sat, Feb 24, 2007 at 05:04:01PM -0500, Jeff Garzik wrote:
I am a graduate student working on finding bugs in Linux drivers using
an automated research tool. I think I've found a possible bug in
net/tc35815.c, and I'd appreciate it if you could confirm/disconfirm it.
Thanks,
Philip
---
net/tc35815.c
tc35815_driver is never unregistered in tc35815_cleanup_module()
static int __init tc35815_init_module(void)
{
return pci_register_driver(tc35815_driver);
}
static void __exit tc35815_cleanup_module(void)
{
struct net_device *next_dev;
while (root_tc35815_dev) {
struct net_device *dev = root_tc35815_dev;
next_dev = ((struct tc35815_local *)dev-priv)-next_module;
iounmap((void *)(dev-base_addr));
unregister_netdev(dev);
free_netdev(dev);
root_tc35815_dev = next_dev;
}
}
I think that you are right, but I don't know this code.
Jeff, what do you think about this?
Regards,
Michal
I created my own patch for this (and one other bug), and checked it in.
Really, though, someone in MIPS-land should give this driver some loving
care. It is filled with bugs and 2.4-era anachronisms.
Took a look at it. It's sort of a non-bug because the driver cannot be
compiled as module, so the module_exit function cannot possibly be
executed. The board support code is calling into the driver which makes
it impossible to build this driver as a module, yet it's possible to
select building this driver as a module ... Oh yeah, that root_tc35815_dev
stuff is also pretty ugly.
Atsushi?
Ralf
-
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/majordomo-info.html
Re: Weird problem with PPPoE on tap interface
Hi,
I'm experiencing a pretty strange problem with kernel PPPoE on tap
interfaces with a vanilla 2.6.20 kernel that prevents the PPP connection
from being established:
[...]
Well, I guess I have found the source of the problem: The PPPoE code seems
to match inbound packets to sockets based only on source address and
session ID - so in the given scenario, packets are delivered to pppd
once when they arrive at the real ethernet interface and a second time
when they arrive at the tap interface. Now, this is kindof two problems,
actually:
1. This is not in compliance with RFC 2516, which states in section 4:
| The SESSION_ID field is sixteen bits. It is an unsigned value in
| network byte order. It's value is defined below for Discovery
| packets. The value is fixed for a given PPP session and, in fact,
| defines a PPP session along with the Ethernet SOURCE_ADDR and
| DESTINATION_ADDR.
So, it would be legal for there to be multiple sessions with the same
peer using the same session ID, as long as they are using different
local MAC addresses - but the current PPPoE code would not be able to
distinguish those.
This probably is not a problem for me, but should be fixed anyway,
IMO. (I say probably since I am actually using different local MAC
addresses for multiple PPPoE sessions to the same DSL-AC, as T-Com
doesn't allow for multiple sessions from the same MAC address -
so they would be allowed by the RFC to use the same session ID for
more than one of those sessions, even though I doubt that they're
doing that.)
2. In addition to session ID, source and destination address, IMO, the
incoming interface should be added to the key that's used for
matching packets to sockets. This is probably somewhat of a design
decision much like the weak ES vs. strong ES issue with IP, but
AFAICS, the userspace-API works by binding to an interface index, not
by binding to a MAC address (unlike IP socket binding), which is why
I'd expect from pppd's perspective that only packets from that
interface are delivered.
Plus, from the end user's perspective, this might even be somewhat of
a security problem. I for one would (well, I obviuosly _did_ :-)
expect that if I do specify an interface name in pppd's config,
pppd won't get into contact with anything that's going on on
interfaces other than the one specified. As the involved MAC addresses
probably usually aren't considered a secret, all you'd have to guess
in order to interfere with/inject packets into PPPoE sessions on a
different interface is the 16-bit session identifier, which might not
even be random.
Well, your opinions are welcome. Plus any hints as to how to fix this.
I'd tend to simply(?) add some more fields to the
{hash,get,set,delete}_item() functions in drivers/net/pppoe.c.
But maybe there is some better way?
Florian
-
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/majordomo-info.html
Re: possible bug in net/tc35815.c in linux-2.6.19
On Mon, 26 Feb 2007 10:26:59 +, Ralf Baechle [EMAIL PROTECTED] wrote: I created my own patch for this (and one other bug), and checked it in. Really, though, someone in MIPS-land should give this driver some loving care. It is filled with bugs and 2.4-era anachronisms. Took a look at it. It's sort of a non-bug because the driver cannot be compiled as module, so the module_exit function cannot possibly be executed. The board support code is calling into the driver which makes it impossible to build this driver as a module, yet it's possible to select building this driver as a module ... Oh yeah, that root_tc35815_dev stuff is also pretty ugly. Yes, the driver is quite obsoleted. It was added long ago with arch/mips/jmr3927 and not maintained long time, as like as the board itself. I know both MontaVista and CELF have new driver for the chip. If anybody in MontaVista did not complain I can send CELF's one available at http://tree.celinuxforum.org/pubwiki/moin.cgi/PatchArchive. (it needs some changes for recent kernel, for example pt_regs removal, but it would be easy). Sergei? --- Atsushi Nemoto - 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/majordomo-info.html
Re: reliable bond interface
Randy Macleod wrote: In a different thred, Jon Paul Maloy wrote: One (TIPC user) I know about,who has developed a very interesting reliable bond interface based on this API, doesn't regard his code to be up to the kernel coding standards yet, although I am trying to encourage him. Sounds interesting! Can you ask this person to post the code or at least to present the basic design on the tipc and/or netdev mailing list/s? I am in contact with the author. You will hear from him. (Or me). ///jon - 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/majordomo-info.html
Re: [PATCH 0/6] more sky2 patches for 2.6.16.42-rc1
On Fri, Feb 23, 2007 at 03:10:42PM -0800, Stephen Hemminger wrote: More backport of sky2 stuff. * [bugfix] ram buffer setup * [bugfix] listen to pause packets * [bugfix] big endian Optional: * add more statistics (add entries to table) * add more pci-ids for newer boards * update version and email address Thanks, I've applied all 6 patches. Stephen Hemminger cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/majordomo-info.html
Fw: [Bugme-new] [Bug 8085] New: performance drop in 2.6.20
ooh. Begin forwarded message: Date: Mon, 26 Feb 2007 07:10:48 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 8085] New: performance drop in 2.6.20 http://bugzilla.kernel.org/show_bug.cgi?id=8085 Summary: performance drop in 2.6.20 Kernel Version: 2.6.20 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did *NOT* occur: 2.6.19.5 Distribution: slackware based Hardware Environment: Xeon + e1000 Software Environment: gcc 3.3.x Problem Description: noticeable (10-15%) routing and bridging (possibly overall) performance drop between 2.6.19.5 - 2.6.20 (2.6.20.1 2.6.21-rc1 too) same configs we are experiencing performance drop on our rather busy(150kpps 700Mbps in one direction) bridge with ebtables and routers (210k routes, 30kpps duplex). It's not e1000 issue. Steps to reproduce: --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - 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/majordomo-info.html
need some help on a backport of r8169
Hello everyone, I am experiencing a big fight with a Realtek RTL8168 ethernet card that I need to use with a 2.6.11.11 kernel. Here is my problem : the RTL8168 (which seems to be the PIC-express version of the RTL8169) isn't recognized by the 2.6.11.11 kernel. So I tried the r1000 driver supplied by Realtek, which recognizes my RTL8168 card but doesn't do what I want. In fact, it only supports ethtool for speed control and always uses autonegotiation to force a mode, which is also the behaviour of the r8169 driver but doesn't fit my needs because some of my company's clients use network switches that do not support autonegotiation. I must precise that I previously succeeded to backport the support for mii-tool in the r8169 driver from the 2.6.20 kernel to the 2.6.11.11, which allows me to effectively force the speed without using autonegotiation. Ok, but that was for the RTL8169 card, already supported in the 2.6.11.11 kernel, now I need to support a RTL8168 one. So I tried a 2.6.20 kernel with this card and I saw that it was supported by the r8169 driver. So I decided to backport some of this driver to add the RTL8168 in it for the 2.6.11.11 kernel. I thought it was easy and just required to add some references (pci id ...) but sadly it isn't, and my patch results in a kernel panic when I turn the interface up. Could anyone take a look at my patch and tell me what is missing, or what is wrong? Or if you have other suggestions, do not hesitate, if you think I'd better patch the r1000 driver to add mii-tool support (it didn't seem so easy) or anything else, but please don't suggest me to change my network switches, these are not mines so I cannot do anything for this. Also I cannot change my entire kernel for the moment. Here you can find my patch : http://www.synerway.net/patch/r8169-backport.patch it adds mii-tool support and TRIES to add RTL8168 support. Thank you for any help Pascal - 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/majordomo-info.html
tcp_info struct
Hi,
i want to use the tcp_info struct to keep track of some tcp related
information. This works fine so far, however i'm wondering how to
interpret some of the values delivered. I would expect values like cwnd
and sst to be given out in packets regarding the source code. Can anyone
give me some hints in interpreting the tcp_info values as this option is
very poor documented and only documentation on how to fill the tcp_info
struct can be found.
Below are some values i got out of the tcp_info structure with the tcp
connection in state 8 and the code snippet which uses the tcp_struct.
Especially the SND_MSS (i would expect this to be 1460) and the ssthresh
value are strange.
tcp_info:
RTOs = 0, 0WProbes = 0, Backoffs = 0
RTO = 204 msec, RTT = 7 msec, RTT_var = 3 msec
lost packets = 0, sacked packets = 0, retransmitted packets = 1
SND_MSS = 16384, RCV_MSS = 536, ssthresh = 65535, cwnd = 13
struct tcp_info info;
int optlen=sizeof(struct tcp_info);
if(getsockopt(socket_fd, IPPROTO_TCP, TCP_INFO, info, optlen) 0){
// Error Handling
}
printf(RTOs = %u, 0WProbes = %u, Backoffs = %u\n\
RTO = %u msec, RTT = %u msec, RTT_var = %u msec\n\
lost packets = %u, sacked packets = %u, retransmitted
packets = %u\n\
SND_MSS = %u, RCV_MSS = %u, ssthresh = %u, cwnd = %u \n\n,
info.tcpi_retransmits, info.tcpi_probes, info.tcpi_backoff,
(info.tcpi_rto/1000), (info.tcpi_rtt/1000),
(info.tcpi_rttvar/1000),
info.tcpi_lost, info.tcpi_sacked, info.tcpi_total_retrans,
info.tcpi_snd_mss, info.tcpi_rcv_mss,
info.tcpi_snd_ssthresh, info.tcpi_snd_cwnd);
thx
Michael
-
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/majordomo-info.html
Re: [PATCH,RFC] bridge: call eth_type_trans() in br_pass_frame_up()
On Wed, 18 Oct 2006 11:14:45 +0200 Lennert Buytenhek [EMAIL PROTECTED] wrote: Hi, I've been seeing a failure to reply to incoming ARP packets on a bridge interface until after the first few packets have been transmitted over that interface, and the patch below seems to fix the issue, the 'issue' being that the incoming ARP packets are marked with PACKET_OTHERHOST, and there not being anything to set that back to PACKET_HOST even if the destination MAC address matches the bridge interface's MAC address. If this looks good, I'll prepare a proper commit message. cheers, Lennert Signed-off-by: Tom Billman [EMAIL PROTECTED] Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED] --- linux-2.6.19-rc2.orig/net/bridge/br_input.c 2006-10-18 11:11:08.0 +0200 +++ linux-2.6.19-rc2/net/bridge/br_input.c2006-10-18 11:10:08.0 +0200 @@ -32,6 +32,9 @@ indev = skb-dev; skb-dev = br-dev; + skb_push(skb, ETH_HLEN); + skb-protocol = eth_type_trans(skb, skb-dev); + NF_HOOK(PF_BRIDGE, NF_BR_LOCAL_IN, skb, indev, NULL, netif_receive_skb); } No, eth_type_trans already be called by the device in the receive path. Looks like a device driver bug, not a bridge issue. If you add this, the code ends up doing eth_type_trans twice. -- Stephen Hemminger [EMAIL PROTECTED] - 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/majordomo-info.html
Re: tcp_info struct
On 2/26/07, Michael Faber [EMAIL PROTECTED] wrote: Hi, i want to use the tcp_info struct to keep track of some tcp related information. This works fine so far, however i'm wondering how to interpret some of the values delivered. I would expect values like cwnd and sst to be given out in packets regarding the source code. Can anyone give me some hints in interpreting the tcp_info values as this option is very poor documented and only documentation on how to fill the tcp_info struct can be found. Rule #N: Use the current users as the documentation Use rule #N, by looking at the iproute2 source code, more specifically the ss source code 8) - Arnaldo - 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/majordomo-info.html
[PATCH 0/13] qla3xxx: bugfixes and cleanup after IBM/Redhat testing.
This patch series addresses a number of issues found when testing at IBM and Redhat. The patches were built and tested against the netdev/upstream kernel on i386/x86_64/PPC64 platforms. Signed-off-by: Ron Mercer [EMAIL PROTECTED] - 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/majordomo-info.html
[PATCH 01/13] qla3xxx: Return proper error codes when the 4022/4032 is being probed
From: Benjamin Li [EMAIL PROTECTED]
The return code was not properly set when when allocating memory or mapping
memory failed. Depending on the stack, the return code would sometimes
return 0, which indicates everything was ok, when in fact there was an error.
This would cause trouble when the module was removed. Now, we will pass
back the proper return code when an error occurs during the PCI probe.
Signed-off-by: Benjamin Li [EMAIL PROTECTED]
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
---
drivers/net/qla3xxx.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index 2429b27..d1c90ca 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -3609,8 +3609,12 @@ static int __devinit ql3xxx_probe(struct pci_dev *pdev,
}
ndev = alloc_etherdev(sizeof(struct ql3_adapter));
- if (!ndev)
+ if (!ndev) {
+ printk(KERN_ERR PFX %s could not alloc etherdev\n,
+ pci_name(pdev));
+ err = -ENOMEM;
goto err_out_free_regions;
+ }
SET_MODULE_OWNER(ndev);
SET_NETDEV_DEV(ndev, pdev-dev);
@@ -3639,6 +3643,7 @@ static int __devinit ql3xxx_probe(struct pci_dev *pdev,
if (!qdev-mem_map_registers) {
printk(KERN_ERR PFX %s: cannot map device registers\n,
pci_name(pdev));
+ err = -EIO;
goto err_out_free_ndev;
}
@@ -3667,6 +3672,7 @@ static int __devinit ql3xxx_probe(struct pci_dev *pdev,
printk(KERN_ALERT PFX
ql3xxx_probe: Adapter #%d, Invalid NVRAM parameters.\n,
qdev-index);
+ err = -EIO;
goto err_out_iounmap;
}
--
1.5.0.rc4.16.g9e258
-
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/majordomo-info.html
[PATCH 02/13] qla3xxx: Remove unnecessary memset() in qla3xxx_send()
From: Benjamin Li [EMAIL PROTECTED] We do not need to zero out the 64 byte MAC request I/O control block. By zeroing out the control block and setting it to proper fields is redundant work. This is because in the qla3xxx_send() function we will already set the proper fields in this structure. The unused fields are not looked at by the hardware and do not need to be zeroed out. Signed-off-by: Benjamin Li [EMAIL PROTECTED] Signed-off-by: Ron Mercer [EMAIL PROTECTED] --- drivers/net/qla3xxx.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c index d1c90ca..18a2bb5 100755 --- a/drivers/net/qla3xxx.c +++ b/drivers/net/qla3xxx.c @@ -2188,7 +2188,6 @@ static int ql3xxx_send(struct sk_buff *skb, struct net_device *ndev) } mac_iocb_ptr = tx_cb-queue_entry; - memset((void *)mac_iocb_ptr, 0, sizeof(struct ob_mac_iocb_req)); mac_iocb_ptr-opcode = qdev-mac_ob_opcode; mac_iocb_ptr-flags |= qdev-mb_bit_mask; mac_iocb_ptr-transaction_id = qdev-req_producer_index; -- 1.5.0.rc4.16.g9e258 - 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/majordomo-info.html
[PATCH 04/13] qla3xxx: Add ethtool functionality to report pause parameters
From: Benjamin Li [EMAIL PROTECTED]
We have added the ability to query the receive and transmit PAUSE flow
control frames parameters, in addition to the auto-negotiated status
using ethtool.
Signed-off-by: Benjamin Li [EMAIL PROTECTED]
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
---
drivers/net/qla3xxx.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index 5acae02..b853669 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -1604,6 +1604,23 @@ static void ql_set_msglevel(struct net_device *ndev, u32
value)
qdev-msg_enable = value;
}
+static void ql_get_pauseparam(struct net_device *ndev,
+ struct ethtool_pauseparam *pause)
+{
+ struct ql3_adapter *qdev = netdev_priv(ndev);
+ struct ql3xxx_port_registers __iomem *port_regs =
qdev-mem_map_registers;
+
+ u32 reg;
+ if(qdev-mac_index == 0)
+ reg = ql_read_page0_reg(qdev, port_regs-mac0ConfigReg);
+ else
+ reg = ql_read_page0_reg(qdev, port_regs-mac1ConfigReg);
+
+ pause-autoneg = ql_get_auto_cfg_status(qdev);
+ pause-rx_pause = (reg MAC_CONFIG_REG_RF) 2;
+ pause-tx_pause = (reg MAC_CONFIG_REG_TF) 1;
+}
+
static const struct ethtool_ops ql3xxx_ethtool_ops = {
.get_settings = ql_get_settings,
.get_drvinfo = ql_get_drvinfo,
@@ -1611,6 +1628,7 @@ static const struct ethtool_ops ql3xxx_ethtool_ops = {
.get_link = ethtool_op_get_link,
.get_msglevel = ql_get_msglevel,
.set_msglevel = ql_set_msglevel,
+ .get_pauseparam = ql_get_pauseparam,
};
static int ql_populate_free_queue(struct ql3_adapter *qdev)
--
1.5.0.rc4.16.g9e258
-
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/majordomo-info.html
[PATCH 03/13] qla3xxx: Changed to use netdev_alloc_skb() from dev_alloc_skb
From: Benjamin Li [EMAIL PROTECTED]
Signed-off-by: Benjamin Li [EMAIL PROTECTED]
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
---
drivers/net/qla3xxx.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index 18a2bb5..5acae02 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -287,9 +287,10 @@ static void ql_release_to_lrg_buf_free_list(struct
ql3_adapter *qdev,
}
if (!lrg_buf_cb-skb) {
- lrg_buf_cb-skb = dev_alloc_skb(qdev-lrg_buffer_len);
+ lrg_buf_cb-skb = netdev_alloc_skb(qdev-ndev,
+ qdev-lrg_buffer_len);
if (unlikely(!lrg_buf_cb-skb)) {
- printk(KERN_ERR PFX %s: failed dev_alloc_skb().\n,
+ printk(KERN_ERR PFX %s: failed netdev_alloc_skb().\n,
qdev-ndev-name);
qdev-lrg_buf_skb_check++;
} else {
@@ -1619,10 +1620,11 @@ static int ql_populate_free_queue(struct ql3_adapter
*qdev)
while (lrg_buf_cb) {
if (!lrg_buf_cb-skb) {
- lrg_buf_cb-skb = dev_alloc_skb(qdev-lrg_buffer_len);
+ lrg_buf_cb-skb = netdev_alloc_skb(qdev-ndev,
+
qdev-lrg_buffer_len);
if (unlikely(!lrg_buf_cb-skb)) {
printk(KERN_DEBUG PFX
- %s: Failed dev_alloc_skb().\n,
+ %s: Failed netdev_alloc_skb().\n,
qdev-ndev-name);
break;
} else {
@@ -2514,7 +2516,8 @@ static int ql_alloc_large_buffers(struct ql3_adapter
*qdev)
u64 map;
for (i = 0; i NUM_LARGE_BUFFERS; i++) {
- skb = dev_alloc_skb(qdev-lrg_buffer_len);
+ skb = netdev_alloc_skb(qdev-ndev,
+ qdev-lrg_buffer_len);
if (unlikely(!skb)) {
/* Better luck next round */
printk(KERN_ERR PFX
--
1.5.0.rc4.16.g9e258
-
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/majordomo-info.html
[PATCH 07/13] qla3xxx: Dynamically size the rx buffer queue based on the MTU.
This change removes use of constants for rx buffer queue size
and instead calculates the queue length based on what he MTU
is set to.
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
---
drivers/net/qla3xxx.c | 41 -
drivers/net/qla3xxx.h |8 ++--
2 files changed, 34 insertions(+), 15 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index b86cef0..fe494ac 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -1718,11 +1718,11 @@ static void ql_update_lrg_bufq_prod_index(struct
ql3_adapter *qdev)
qdev-lrg_buf_q_producer_index++;
- if (qdev-lrg_buf_q_producer_index == NUM_LBUFQ_ENTRIES)
+ if (qdev-lrg_buf_q_producer_index ==
qdev-num_lbufq_entries)
qdev-lrg_buf_q_producer_index = 0;
if (qdev-lrg_buf_q_producer_index ==
- (NUM_LBUFQ_ENTRIES - 1)) {
+ (qdev-num_lbufq_entries - 1)) {
lrg_buf_q_ele = qdev-lrg_buf_q_virt_addr;
}
}
@@ -1803,7 +1803,7 @@ static void ql_process_mac_rx_intr(struct ql3_adapter
*qdev,
lrg_buf_phy_addr_low = le32_to_cpu(*curr_ial_ptr);
lrg_buf_cb1 = qdev-lrg_buf[qdev-lrg_buf_index];
qdev-lrg_buf_release_cnt++;
- if (++qdev-lrg_buf_index == NUM_LARGE_BUFFERS) {
+ if (++qdev-lrg_buf_index == qdev-num_large_buffers) {
qdev-lrg_buf_index = 0;
}
curr_ial_ptr++; /* 64-bit pointers require two incs. */
@@ -1818,7 +1818,7 @@ static void ql_process_mac_rx_intr(struct ql3_adapter
*qdev,
* Second buffer gets sent up the stack.
*/
qdev-lrg_buf_release_cnt++;
- if (++qdev-lrg_buf_index == NUM_LARGE_BUFFERS)
+ if (++qdev-lrg_buf_index == qdev-num_large_buffers)
qdev-lrg_buf_index = 0;
skb = lrg_buf_cb2-skb;
@@ -1873,7 +1873,7 @@ static void ql_process_macip_rx_intr(struct ql3_adapter
*qdev,
lrg_buf_phy_addr_low = le32_to_cpu(*curr_ial_ptr);
lrg_buf_cb1 = qdev-lrg_buf[qdev-lrg_buf_index];
qdev-lrg_buf_release_cnt++;
- if (++qdev-lrg_buf_index == NUM_LARGE_BUFFERS)
+ if (++qdev-lrg_buf_index == qdev-num_large_buffers)
qdev-lrg_buf_index = 0;
skb1 = lrg_buf_cb1-skb;
curr_ial_ptr++; /* 64-bit pointers require two incs. */
@@ -1888,7 +1888,7 @@ static void ql_process_macip_rx_intr(struct ql3_adapter
*qdev,
lrg_buf_cb2 = qdev-lrg_buf[qdev-lrg_buf_index];
skb2 = lrg_buf_cb2-skb;
qdev-lrg_buf_release_cnt++;
- if (++qdev-lrg_buf_index == NUM_LARGE_BUFFERS)
+ if (++qdev-lrg_buf_index == qdev-num_large_buffers)
qdev-lrg_buf_index = 0;
skb_put(skb2, length); /* Just the second buffer length here. */
@@ -2365,12 +2365,19 @@ static int ql_alloc_buffer_queues(struct ql3_adapter
*qdev)
{
/* Create Large Buffer Queue */
qdev-lrg_buf_q_size =
- NUM_LBUFQ_ENTRIES * sizeof(struct lrg_buf_q_entry);
+ qdev-num_lbufq_entries * sizeof(struct lrg_buf_q_entry);
if (qdev-lrg_buf_q_size PAGE_SIZE)
qdev-lrg_buf_q_alloc_size = PAGE_SIZE;
else
qdev-lrg_buf_q_alloc_size = qdev-lrg_buf_q_size * 2;
+ qdev-lrg_buf = kmalloc(qdev-num_large_buffers * sizeof(struct
ql_rcv_buf_cb),GFP_KERNEL);
+ if (qdev-lrg_buf == NULL) {
+ printk(KERN_ERR PFX
+ %s: qdev-lrg_buf alloc failed.\n, qdev-ndev-name);
+ return -ENOMEM;
+ }
+
qdev-lrg_buf_q_alloc_virt_addr =
pci_alloc_consistent(qdev-pdev,
qdev-lrg_buf_q_alloc_size,
@@ -2420,6 +2427,7 @@ static void ql_free_buffer_queues(struct ql3_adapter
*qdev)
%s: Already done.\n, qdev-ndev-name);
return;
}
+ if(qdev-lrg_buf) kfree(qdev-lrg_buf);
pci_free_consistent(qdev-pdev,
qdev-lrg_buf_q_alloc_size,
@@ -2503,7 +2511,7 @@ static void ql_free_large_buffers(struct ql3_adapter
*qdev)
int i = 0;
struct ql_rcv_buf_cb *lrg_buf_cb;
- for (i = 0; i NUM_LARGE_BUFFERS; i++) {
+ for (i = 0; i qdev-num_large_buffers; i++) {
lrg_buf_cb = qdev-lrg_buf[i];
if (lrg_buf_cb-skb) {
dev_kfree_skb(lrg_buf_cb-skb);
@@ -2524,7 +2532,7 @@ static void ql_init_large_buffers(struct ql3_adapter
*qdev)
struct ql_rcv_buf_cb *lrg_buf_cb;
struct bufq_addr_element *buf_addr_ele = qdev-lrg_buf_q_virt_addr;
- for (i = 0; i NUM_LARGE_BUFFERS; i++) {
+ for (i = 0; i qdev-num_large_buffers; i++) {
[PATCH 08/13] qla3xxx: Clean up receive process.
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
---
drivers/net/qla3xxx.c | 78 +++--
1 files changed, 24 insertions(+), 54 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index fe494ac..cb3a05e 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -1764,6 +1764,23 @@ static void ql_process_mac_tx_intr(struct ql3_adapter
*qdev,
atomic_inc(qdev-tx_count);
}
+void ql_get_sbuf(struct ql3_adapter *qdev)
+{
+ if (++qdev-small_buf_index == NUM_SMALL_BUFFERS)
+ qdev-small_buf_index = 0;
+ qdev-small_buf_release_cnt++;
+}
+
+struct ql_rcv_buf_cb *ql_get_lbuf(struct ql3_adapter *qdev)
+{
+ struct ql_rcv_buf_cb *lrg_buf_cb = NULL;
+ lrg_buf_cb = qdev-lrg_buf[qdev-lrg_buf_index];
+ qdev-lrg_buf_release_cnt++;
+ if (++qdev-lrg_buf_index == qdev-num_large_buffers)
+ qdev-lrg_buf_index = 0;
+ return(lrg_buf_cb);
+}
+
/*
* The difference between 3022 and 3032 for inbound completions:
* 3022 uses two buffers per completion. The first buffer contains
@@ -1779,47 +1796,21 @@ static void ql_process_mac_tx_intr(struct ql3_adapter
*qdev,
static void ql_process_mac_rx_intr(struct ql3_adapter *qdev,
struct ib_mac_iocb_rsp *ib_mac_rsp_ptr)
{
- long int offset;
- u32 lrg_buf_phy_addr_low = 0;
struct ql_rcv_buf_cb *lrg_buf_cb1 = NULL;
struct ql_rcv_buf_cb *lrg_buf_cb2 = NULL;
- u32 *curr_ial_ptr;
struct sk_buff *skb;
u16 length = le16_to_cpu(ib_mac_rsp_ptr-length);
/*
* Get the inbound address list (small buffer).
*/
- offset = qdev-small_buf_index * QL_SMALL_BUFFER_SIZE;
- if (++qdev-small_buf_index == NUM_SMALL_BUFFERS)
- qdev-small_buf_index = 0;
-
- curr_ial_ptr = (u32 *) (qdev-small_buf_virt_addr + offset);
- qdev-last_rsp_offset = qdev-small_buf_phy_addr_low + offset;
- qdev-small_buf_release_cnt++;
+ ql_get_sbuf(qdev);
- if (qdev-device_id == QL3022_DEVICE_ID) {
- /* start of first buffer (3022 only) */
- lrg_buf_phy_addr_low = le32_to_cpu(*curr_ial_ptr);
- lrg_buf_cb1 = qdev-lrg_buf[qdev-lrg_buf_index];
- qdev-lrg_buf_release_cnt++;
- if (++qdev-lrg_buf_index == qdev-num_large_buffers) {
- qdev-lrg_buf_index = 0;
- }
- curr_ial_ptr++; /* 64-bit pointers require two incs. */
- curr_ial_ptr++;
- }
+ if (qdev-device_id == QL3022_DEVICE_ID)
+ lrg_buf_cb1 = ql_get_lbuf(qdev);
/* start of second buffer */
- lrg_buf_phy_addr_low = le32_to_cpu(*curr_ial_ptr);
- lrg_buf_cb2 = qdev-lrg_buf[qdev-lrg_buf_index];
-
- /*
-* Second buffer gets sent up the stack.
-*/
- qdev-lrg_buf_release_cnt++;
- if (++qdev-lrg_buf_index == qdev-num_large_buffers)
- qdev-lrg_buf_index = 0;
+ lrg_buf_cb2 = ql_get_lbuf(qdev);
skb = lrg_buf_cb2-skb;
qdev-stats.rx_packets++;
@@ -1847,11 +1838,8 @@ static void ql_process_mac_rx_intr(struct ql3_adapter
*qdev,
static void ql_process_macip_rx_intr(struct ql3_adapter *qdev,
struct ib_ip_iocb_rsp *ib_ip_rsp_ptr)
{
- long int offset;
- u32 lrg_buf_phy_addr_low = 0;
struct ql_rcv_buf_cb *lrg_buf_cb1 = NULL;
struct ql_rcv_buf_cb *lrg_buf_cb2 = NULL;
- u32 *curr_ial_ptr;
struct sk_buff *skb1 = NULL, *skb2;
struct net_device *ndev = qdev-ndev;
u16 length = le16_to_cpu(ib_ip_rsp_ptr-length);
@@ -1861,35 +1849,20 @@ static void ql_process_macip_rx_intr(struct ql3_adapter
*qdev,
* Get the inbound address list (small buffer).
*/
- offset = qdev-small_buf_index * QL_SMALL_BUFFER_SIZE;
- if (++qdev-small_buf_index == NUM_SMALL_BUFFERS)
- qdev-small_buf_index = 0;
- curr_ial_ptr = (u32 *) (qdev-small_buf_virt_addr + offset);
- qdev-last_rsp_offset = qdev-small_buf_phy_addr_low + offset;
- qdev-small_buf_release_cnt++;
+ ql_get_sbuf(qdev);
if (qdev-device_id == QL3022_DEVICE_ID) {
/* start of first buffer on 3022 */
- lrg_buf_phy_addr_low = le32_to_cpu(*curr_ial_ptr);
- lrg_buf_cb1 = qdev-lrg_buf[qdev-lrg_buf_index];
- qdev-lrg_buf_release_cnt++;
- if (++qdev-lrg_buf_index == qdev-num_large_buffers)
- qdev-lrg_buf_index = 0;
+ lrg_buf_cb1 = ql_get_lbuf(qdev);
skb1 = lrg_buf_cb1-skb;
- curr_ial_ptr++; /* 64-bit pointers require two incs. */
- curr_ial_ptr++;
size = ETH_HLEN;
if (*((u16 *) skb1-data) != 0x)
size += VLAN_ETH_HLEN - ETH_HLEN;
}
[PATCH 09/13] qla3xxx: bugfix: Fixed jumbo frame handling for 3032 chip.
The scatter/gather lists were not being build correctly. When
large frames spanned several buffers the chip would panic.
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
---
drivers/net/qla3xxx.c | 99 +++-
drivers/net/qla3xxx.h |1 -
2 files changed, 64 insertions(+), 36 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index cb3a05e..d2f4397 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -2140,11 +2140,13 @@ static void ql_hw_csum_setup(struct sk_buff *skb,
if (ip) {
if (ip-protocol == IPPROTO_TCP) {
- mac_iocb_ptr-flags1 |= OB_3032MAC_IOCB_REQ_TC;
+ mac_iocb_ptr-flags1 |= OB_3032MAC_IOCB_REQ_TC |
+ OB_3032MAC_IOCB_REQ_IC;
mac_iocb_ptr-ip_hdr_off = offset;
mac_iocb_ptr-ip_hdr_len = ip-ihl;
} else if (ip-protocol == IPPROTO_UDP) {
- mac_iocb_ptr-flags1 |= OB_3032MAC_IOCB_REQ_UC;
+ mac_iocb_ptr-flags1 |= OB_3032MAC_IOCB_REQ_UC |
+ OB_3032MAC_IOCB_REQ_IC;
mac_iocb_ptr-ip_hdr_off = offset;
mac_iocb_ptr-ip_hdr_len = ip-ihl;
}
@@ -2152,51 +2154,29 @@ static void ql_hw_csum_setup(struct sk_buff *skb,
}
/*
- * The difference between 3022 and 3032 sends:
- * 3022 only supports a simple single segment transmission.
- * 3032 supports checksumming and scatter/gather lists (fragments).
- * The 3032 supports sglists by using the 3 addr/len pairs (ALP)
- * in the IOCB plus a chain of outbound address lists (OAL) that
- * each contain 5 ALPs. The last ALP of the IOCB (3rd) or OAL (5th)
- * will used to point to an OAL when more ALP entries are required.
- * The IOCB is always the top of the chain followed by one or more
- * OALs (when necessary).
+ * Map the buffers for this transmit. This will return
+ * NETDEV_TX_BUSY or NETDEV_TX_OK based on success.
*/
-static int ql3xxx_send(struct sk_buff *skb, struct net_device *ndev)
+static int ql_send_map(struct ql3_adapter *qdev,
+ struct ob_mac_iocb_req *mac_iocb_ptr,
+ struct ql_tx_buf_cb *tx_cb,
+ struct sk_buff *skb)
{
- struct ql3_adapter *qdev = (struct ql3_adapter *)netdev_priv(ndev);
- struct ql3xxx_port_registers __iomem *port_regs =
qdev-mem_map_registers;
- struct ql_tx_buf_cb *tx_cb;
- u32 tot_len = skb-len;
struct oal *oal;
struct oal_entry *oal_entry;
- int len;
- struct ob_mac_iocb_req *mac_iocb_ptr;
+ int len = skb_headlen(skb);
u64 map;
int seg_cnt, seg = 0;
int frag_cnt = (int)skb_shinfo(skb)-nr_frags;
- if (unlikely(atomic_read(qdev-tx_count) 2)) {
- if (!netif_queue_stopped(ndev))
- netif_stop_queue(ndev);
- return NETDEV_TX_BUSY;
- }
- tx_cb = qdev-tx_buf[qdev-req_producer_index] ;
seg_cnt = tx_cb-seg_count =
ql_get_seg_count((skb_shinfo(skb)-nr_frags));
if(seg_cnt == -1) {
printk(KERN_ERR PFX%s: invalid segment count!\n,__func__);
- return NETDEV_TX_OK;
-
+ return NETDEV_TX_BUSY;
}
- mac_iocb_ptr = tx_cb-queue_entry;
- mac_iocb_ptr-opcode = qdev-mac_ob_opcode;
- mac_iocb_ptr-flags |= qdev-mb_bit_mask;
- mac_iocb_ptr-transaction_id = qdev-req_producer_index;
- mac_iocb_ptr-data_len = cpu_to_le16((u16) tot_len);
- tx_cb-skb = skb;
- if (skb-ip_summed == CHECKSUM_PARTIAL)
- ql_hw_csum_setup(skb, mac_iocb_ptr);
- len = skb_headlen(skb);
+ /*
+* Map the skb buffer first.
+*/
map = pci_map_single(qdev-pdev, skb-data, len, PCI_DMA_TODEVICE);
oal_entry = (struct oal_entry *)mac_iocb_ptr-buf_addr0_low;
oal_entry-dma_lo = cpu_to_le32(LS_64BITS(map));
@@ -2253,6 +2233,55 @@ static int ql3xxx_send(struct sk_buff *skb, struct
net_device *ndev)
oal_entry-len =
cpu_to_le32(le32_to_cpu(oal_entry-len) | OAL_LAST_ENTRY);
}
+ return NETDEV_TX_OK;
+}
+
+/*
+ * The difference between 3022 and 3032 sends:
+ * 3022 only supports a simple single segment transmission.
+ * 3032 supports checksumming and scatter/gather lists (fragments).
+ * The 3032 supports sglists by using the 3 addr/len pairs (ALP)
+ * in the IOCB plus a chain of outbound address lists (OAL) that
+ * each contain 5 ALPs. The last ALP of the IOCB (3rd) or OAL (5th)
+ * will used to point to an OAL when more ALP entries are required.
+ * The IOCB is always the top of the chain followed by one or more
+ * OALs (when necessary).
+ */
+static int ql3xxx_send(struct sk_buff *skb, struct net_device *ndev)
+{
+ struct ql3_adapter *qdev = (struct
[PATCH 13/13] qla3xxx: Bumping driver version number
From: Benjamin Li [EMAIL PROTECTED] Signed-off-by: Benjamin Li [EMAIL PROTECTED] Signed-off-by: Ron Mercer [EMAIL PROTECTED] --- drivers/net/qla3xxx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c index f446232..15f1371 100755 --- a/drivers/net/qla3xxx.c +++ b/drivers/net/qla3xxx.c @@ -39,7 +39,7 @@ #define DRV_NAME qla3xxx #define DRV_STRING QLogic ISP3XXX Network Driver -#define DRV_VERSIONv2.02.00-k36 +#define DRV_VERSIONv2.03.00-k3 #define PFXDRV_NAME static const char ql3xxx_driver_name[] = DRV_NAME; -- 1.5.0.rc4.16.g9e258 - 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/majordomo-info.html
[PATCH 11/13] qla3xxx: bugfix tx reset after stress conditions.
To Reproduce the Problem:
To reproduce this panic consistently, we run an intensive network
application like 'netperf' and then switch to a different console.
After waiting for a couple of seconds, you will see a tx reset has occured.
Reason:
We enable interrupts even if we were not running.
Solution:
Now we will enable interrupts only after we are ready to give up the poll
routine.
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
---
drivers/net/qla3xxx.c | 69 +
1 files changed, 41 insertions(+), 28 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index 63522ea..bc9109a 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -1939,10 +1939,11 @@ static int ql_tx_rx_clean(struct ql3_adapter *qdev,
struct net_rsp_iocb *net_rsp;
struct net_device *ndev = qdev-ndev;
unsigned long hw_flags;
+ int work_done = 0;
/* While there are entries in the completion queue. */
while ((cpu_to_le32(*(qdev-prsp_producer_index)) !=
- qdev-rsp_consumer_index) (*rx_cleaned work_to_do)) {
+ qdev-rsp_consumer_index) (work_done work_to_do)) {
net_rsp = qdev-rsp_current;
switch (net_rsp-opcode) {
@@ -1993,37 +1994,41 @@ static int ql_tx_rx_clean(struct ql3_adapter *qdev,
} else {
qdev-rsp_current++;
}
+
+ work_done = *tx_cleaned + *rx_cleaned;
}
- spin_lock_irqsave(qdev-hw_lock, hw_flags);
+ if(work_done) {
+ spin_lock_irqsave(qdev-hw_lock, hw_flags);
- ql_update_lrg_bufq_prod_index(qdev);
+ ql_update_lrg_bufq_prod_index(qdev);
- if (qdev-small_buf_release_cnt = 16) {
- while (qdev-small_buf_release_cnt = 16) {
- qdev-small_buf_q_producer_index++;
+ if (qdev-small_buf_release_cnt = 16) {
+ while (qdev-small_buf_release_cnt = 16) {
+ qdev-small_buf_q_producer_index++;
- if (qdev-small_buf_q_producer_index ==
- NUM_SBUFQ_ENTRIES)
- qdev-small_buf_q_producer_index = 0;
- qdev-small_buf_release_cnt -= 8;
- }
+ if (qdev-small_buf_q_producer_index ==
+ NUM_SBUFQ_ENTRIES)
+ qdev-small_buf_q_producer_index = 0;
+ qdev-small_buf_release_cnt -= 8;
+ }
- ql_write_common_reg(qdev,
- port_regs-CommonRegs.
- rxSmallQProducerIndex,
- qdev-small_buf_q_producer_index);
- }
+ wmb();
+ ql_write_common_reg(qdev,
+ port_regs-CommonRegs.
+ rxSmallQProducerIndex,
+ qdev-small_buf_q_producer_index);
- ql_write_common_reg(qdev,
- port_regs-CommonRegs.rspQConsumerIndex,
- qdev-rsp_consumer_index);
- spin_unlock_irqrestore(qdev-hw_lock, hw_flags);
+ }
- if (unlikely(netif_queue_stopped(qdev-ndev))) {
- if (netif_queue_stopped(qdev-ndev)
- (atomic_read(qdev-tx_count) (NUM_REQ_Q_ENTRIES / 4)))
- netif_wake_queue(qdev-ndev);
+ spin_unlock_irqrestore(qdev-hw_lock, hw_flags);
+
+ if (unlikely(netif_queue_stopped(qdev-ndev))) {
+ if (netif_queue_stopped(qdev-ndev)
+ (atomic_read(qdev-tx_count)
+(NUM_REQ_Q_ENTRIES / 4)))
+ netif_wake_queue(qdev-ndev);
+ }
}
return *tx_cleaned + *rx_cleaned;
@@ -2034,6 +2039,8 @@ static int ql_poll(struct net_device *ndev, int *budget)
struct ql3_adapter *qdev = netdev_priv(ndev);
int work_to_do = min(*budget, ndev-quota);
int rx_cleaned = 0, tx_cleaned = 0;
+ unsigned long hw_flags;
+ struct ql3xxx_port_registers __iomem *port_regs =
qdev-mem_map_registers;
if (!netif_carrier_ok(ndev))
goto quit_polling;
@@ -2045,6 +2052,13 @@ static int ql_poll(struct net_device *ndev, int *budget)
if ((!tx_cleaned !rx_cleaned) || !netif_running(ndev)) {
quit_polling:
netif_rx_complete(ndev);
+
+ spin_lock_irqsave(qdev-hw_lock, hw_flags);
+ ql_write_common_reg(qdev,
+ port_regs-CommonRegs.rspQConsumerIndex,
+ qdev-rsp_consumer_index);
+
[PATCH 06/13] qla3xxx: Remove API to change MTU.
This network device driver shares the same hardware as the qla4xxx
iSCSI driver. Changing the MTU via the device interface will
cause qla4xxx to crash as there is no way to make notification.
Users wishing to change the MTU must do so using an iSCSI
utility such as Qlogic SanSurfer. This forces the user to
unload/reload this network device driver after the MTU
value has been changed in flash.
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
---
drivers/net/qla3xxx.c | 24 ++--
1 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index 59cebd6..b86cef0 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -3372,27 +3372,6 @@ static struct net_device_stats *ql3xxx_get_stats(struct
net_device *dev)
return qdev-stats;
}
-static int ql3xxx_change_mtu(struct net_device *ndev, int new_mtu)
-{
- struct ql3_adapter *qdev = netdev_priv(ndev);
- printk(KERN_ERR PFX %s: new mtu size = %d.\n, ndev-name, new_mtu);
- if (new_mtu != NORMAL_MTU_SIZE new_mtu != JUMBO_MTU_SIZE) {
- printk(KERN_ERR PFX
- %s: mtu size of %d is not valid. Use exactly %d or
- %d.\n, ndev-name, new_mtu, NORMAL_MTU_SIZE,
- JUMBO_MTU_SIZE);
- return -EINVAL;
- }
-
- if (!netif_running(ndev)) {
- ndev-mtu = new_mtu;
- return 0;
- }
-
- ndev-mtu = new_mtu;
- return ql_cycle_adapter(qdev,QL_DO_RESET);
-}
-
static void ql3xxx_set_multicast_list(struct net_device *ndev)
{
/*
@@ -3684,7 +3663,6 @@ static int __devinit ql3xxx_probe(struct pci_dev *pdev,
ndev-hard_start_xmit = ql3xxx_send;
ndev-stop = ql3xxx_close;
ndev-get_stats = ql3xxx_get_stats;
- ndev-change_mtu = ql3xxx_change_mtu;
ndev-set_multicast_list = ql3xxx_set_multicast_list;
SET_ETHTOOL_OPS(ndev, ql3xxx_ethtool_ops);
ndev-set_mac_address = ql3xxx_set_mac_address;
@@ -3709,9 +3687,11 @@ static int __devinit ql3xxx_probe(struct pci_dev *pdev,
/* Validate and set parameters */
if (qdev-mac_index) {
+ ndev-mtu = qdev-nvram_data.macCfg_port1.etherMtu_mac ;
memcpy(ndev-dev_addr, qdev-nvram_data.funcCfg_fn2.macAddress,
ETH_ALEN);
} else {
+ ndev-mtu = qdev-nvram_data.macCfg_port0.etherMtu_mac ;
memcpy(ndev-dev_addr, qdev-nvram_data.funcCfg_fn0.macAddress,
ETH_ALEN);
}
--
1.5.0.rc4.16.g9e258
-
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/majordomo-info.html
[PATCH 12/13] qla3xxx: Kernic Panic on pSeries under stress conditions
From: Benjamin Li [EMAIL PROTECTED]
To reproduce this panic consistently, we run an intensive network
application like 'netperf'. After waiting for a couple of seconds,
you will see a stack trace and a kernel panic where we are calling
pci_unmap_single() in ql_poll().
Changes:
1) Check the flags on the Response MAC IO Control block to check for
errors
2) Ensure that if we are on the 4022 we only use one segment
3) Before, we were reading the memory mapped producer index register
everytime we iterated in the loop when clearing the queue. We should
only be iterating to a known point, not as the producer index
is being updated.
Signed-off-by: Benjamin Li [EMAIL PROTECTED]
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
---
drivers/net/qla3xxx.c | 64 +++-
drivers/net/qla3xxx.h |2 +-
2 files changed, 47 insertions(+), 19 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index 524a9a6..f446232 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -1765,8 +1765,31 @@ static void ql_process_mac_tx_intr(struct ql3_adapter
*qdev,
{
struct ql_tx_buf_cb *tx_cb;
int i;
+ int retval = 0;
+ if(mac_rsp-flags OB_MAC_IOCB_RSP_S) {
+ printk(KERN_WARNING Frame short but, frame was padded and
sent.\n);
+ }
+
tx_cb = qdev-tx_buf[mac_rsp-transaction_id];
+
+ /* Check the transmit response flags for any errors */
+ if(mac_rsp-flags OB_MAC_IOCB_RSP_S) {
+ printk(KERN_ERR Frame too short to be legal, frame not
sent.\n);
+
+ qdev-stats.tx_errors++;
+ retval = -EIO;
+ goto frame_not_sent;
+ }
+
+ if(tx_cb-seg_count == 0) {
+ printk(KERN_ERR tx_cb-seg_count == 0: %d\n,
mac_rsp-transaction_id);
+
+ qdev-stats.tx_errors++;
+ retval = -EIO;
+ goto invalid_seg_count;
+ }
+
pci_unmap_single(qdev-pdev,
pci_unmap_addr(tx_cb-map[0], mapaddr),
pci_unmap_len(tx_cb-map[0], maplen),
@@ -1783,8 +1806,12 @@ static void ql_process_mac_tx_intr(struct ql3_adapter
*qdev,
}
qdev-stats.tx_packets++;
qdev-stats.tx_bytes += tx_cb-skb-len;
+
+frame_not_sent:
dev_kfree_skb_irq(tx_cb-skb);
tx_cb-skb = NULL;
+
+invalid_seg_count:
atomic_inc(qdev-tx_count);
}
@@ -1941,8 +1968,10 @@ static int ql_tx_rx_clean(struct ql3_adapter *qdev,
unsigned long hw_flags;
int work_done = 0;
+ u32 rsp_producer_index = le32_to_cpu(*(qdev-prsp_producer_index));
+
/* While there are entries in the completion queue. */
- while ((cpu_to_le32(*(qdev-prsp_producer_index)) !=
+ while ((rsp_producer_index !=
qdev-rsp_consumer_index) (work_done work_to_do)) {
net_rsp = qdev-rsp_current;
@@ -2022,13 +2051,6 @@ static int ql_tx_rx_clean(struct ql3_adapter *qdev,
}
spin_unlock_irqrestore(qdev-hw_lock, hw_flags);
-
- if (unlikely(netif_queue_stopped(qdev-ndev))) {
- if (netif_queue_stopped(qdev-ndev)
- (atomic_read(qdev-tx_count)
-(NUM_REQ_Q_ENTRIES / 4)))
- netif_wake_queue(qdev-ndev);
- }
}
return *tx_cleaned + *rx_cleaned;
@@ -2049,7 +2071,8 @@ static int ql_poll(struct net_device *ndev, int *budget)
*budget -= rx_cleaned;
ndev-quota -= rx_cleaned;
- if ((!tx_cleaned !rx_cleaned) || !netif_running(ndev)) {
+ if( tx_cleaned + rx_cleaned != work_to_do ||
+ !netif_running(ndev)) {
quit_polling:
netif_rx_complete(ndev);
@@ -2111,8 +2134,8 @@ static irqreturn_t ql3xxx_isr(int irq, void *dev_id)
queue_delayed_work(qdev-workqueue, qdev-reset_work, 0);
spin_unlock(qdev-adapter_lock);
} else if (value ISP_IMR_DISABLE_CMPL_INT) {
+ ql_disable_interrupts(qdev);
if (likely(netif_rx_schedule_prep(ndev))) {
- ql_disable_interrupts(qdev);
__netif_rx_schedule(ndev);
}
} else {
@@ -2131,8 +2154,12 @@ static irqreturn_t ql3xxx_isr(int irq, void *dev_id)
* the next AOL if more frags are coming.
* That is why the frags:segment count ratio is not linear.
*/
-static int ql_get_seg_count(unsigned short frags)
+static int ql_get_seg_count(struct ql3_adapter *qdev,
+ unsigned short frags)
{
+ if (qdev-device_id == QL3022_DEVICE_ID)
+ return 1;
+
switch(frags) {
case 0: return 1; /* just the skb-data seg */
case 1: return 2; /* skb-data + 1 frag */
@@ -2201,14 +2228,15 @@ static int ql_send_map(struct ql3_adapter *qdev,
{
struct oal *oal;
[PATCH 10/13] qla3xxx: Check return code from pci_map_single() in ql_release_to_lrg_buf_free_list(), ql_populate_free_queue(), ql_alloc_large_buffers(), and ql3xxx_send()
From: Benjamin Li [EMAIL PROTECTED]
pci_map_single() could fail. We need to properly check the return
code from pci_map_single(). If we can not properly map this address,
then we should cleanup and return the proper return code.
Signed-off-by: Benjamin Li [EMAIL PROTECTED]
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
---
drivers/net/qla3xxx.c | 114 ++---
1 files changed, 107 insertions(+), 7 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index d2f4397..63522ea 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -276,7 +276,8 @@ static void ql_enable_interrupts(struct ql3_adapter *qdev)
static void ql_release_to_lrg_buf_free_list(struct ql3_adapter *qdev,
struct ql_rcv_buf_cb *lrg_buf_cb)
{
- u64 map;
+ dma_addr_t map;
+ int err;
lrg_buf_cb-next = NULL;
if (qdev-lrg_buf_free_tail == NULL) { /* The list is empty */
@@ -304,6 +305,17 @@ static void ql_release_to_lrg_buf_free_list(struct
ql3_adapter *qdev,
qdev-lrg_buffer_len -
QL_HEADER_SPACE,
PCI_DMA_FROMDEVICE);
+ err = pci_dma_mapping_error(map);
+ if(err) {
+ printk(KERN_ERR %s: PCI mapping failed with
error: %d\n,
+ qdev-ndev-name, err);
+ dev_kfree_skb(lrg_buf_cb-skb);
+ lrg_buf_cb-skb = NULL;
+
+ qdev-lrg_buf_skb_check++;
+ return;
+ }
+
lrg_buf_cb-buf_phy_addr_low =
cpu_to_le32(LS_64BITS(map));
lrg_buf_cb-buf_phy_addr_high =
@@ -1642,7 +1654,8 @@ static const struct ethtool_ops ql3xxx_ethtool_ops = {
static int ql_populate_free_queue(struct ql3_adapter *qdev)
{
struct ql_rcv_buf_cb *lrg_buf_cb = qdev-lrg_buf_free_head;
- u64 map;
+ dma_addr_t map;
+ int err;
while (lrg_buf_cb) {
if (!lrg_buf_cb-skb) {
@@ -1664,6 +1677,17 @@ static int ql_populate_free_queue(struct ql3_adapter
*qdev)
qdev-lrg_buffer_len -
QL_HEADER_SPACE,
PCI_DMA_FROMDEVICE);
+
+ err = pci_dma_mapping_error(map);
+ if(err) {
+ printk(KERN_ERR %s: PCI mapping failed
with error: %d\n,
+ qdev-ndev-name, err);
+ dev_kfree_skb(lrg_buf_cb-skb);
+ lrg_buf_cb-skb = NULL;
+ break;
+ }
+
+
lrg_buf_cb-buf_phy_addr_low =
cpu_to_le32(LS_64BITS(map));
lrg_buf_cb-buf_phy_addr_high =
@@ -2165,7 +2189,9 @@ static int ql_send_map(struct ql3_adapter *qdev,
struct oal *oal;
struct oal_entry *oal_entry;
int len = skb_headlen(skb);
- u64 map;
+ dma_addr_t map;
+ int err;
+ int completed_segs, i;
int seg_cnt, seg = 0;
int frag_cnt = (int)skb_shinfo(skb)-nr_frags;
@@ -2178,6 +2204,15 @@ static int ql_send_map(struct ql3_adapter *qdev,
* Map the skb buffer first.
*/
map = pci_map_single(qdev-pdev, skb-data, len, PCI_DMA_TODEVICE);
+
+ err = pci_dma_mapping_error(map);
+ if(err) {
+ printk(KERN_ERR %s: PCI mapping failed with error: %d\n,
+ qdev-ndev-name, err);
+
+ return NETDEV_TX_BUSY;
+ }
+
oal_entry = (struct oal_entry *)mac_iocb_ptr-buf_addr0_low;
oal_entry-dma_lo = cpu_to_le32(LS_64BITS(map));
oal_entry-dma_hi = cpu_to_le32(MS_64BITS(map));
@@ -2191,10 +2226,9 @@ static int ql_send_map(struct ql3_adapter *qdev,
oal_entry-len =
cpu_to_le32(le32_to_cpu(oal_entry-len) | OAL_LAST_ENTRY);
} else {
- int i;
oal = tx_cb-oal;
- for (i=0; ifrag_cnt; i++,seg++) {
- skb_frag_t *frag = skb_shinfo(skb)-frags[i];
+ for (completed_segs=0; completed_segsfrag_cnt;
completed_segs++,seg++) {
+ skb_frag_t *frag =
skb_shinfo(skb)-frags[completed_segs];
oal_entry++;
if ((seg == 2 seg_cnt 3) ||/* Check for
continuation */
(seg == 7 seg_cnt 8) ||/*
requirements. It's strange */
[PATCH 05/13] qla3xxx: Fix deadlock issue on error paths
From: Benjamin Li [EMAIL PROTECTED]
1) Fix deadlock issue when in QL_RESET_ACTIVE state and traversing
through the Link State Machine
2) Fix deadlock issue when ethtool would call ql_get_settings()
3) Fix deadlock issue when adaptor is ifup'ed but adaptor fails to initialize
Signed-off-by: Benjamin Li [EMAIL PROTECTED]
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
---
drivers/net/qla3xxx.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index b853669..59cebd6 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -1388,6 +1388,8 @@ static void ql_link_state_machine(struct ql3_adapter
*qdev)
printk(KERN_INFO PFX
%s: Reset in progress, skip processing link
state.\n, qdev-ndev-name);
+
+ spin_unlock_irqrestore(qdev-hw_lock, hw_flags);
return;
}
@@ -1519,8 +1521,10 @@ static int ql_get_auto_cfg_status(struct ql3_adapter
*qdev)
spin_lock_irqsave(qdev-hw_lock, hw_flags);
if(ql_sem_spinlock(qdev, QL_PHY_GIO_SEM_MASK,
(QL_RESOURCE_BITS_BASE_CODE | (qdev-mac_index) *
-2) 7))
+2) 7)) {
+ spin_unlock_irqrestore(qdev-hw_lock, hw_flags);
return 0;
+ }
status = ql_is_auto_cfg(qdev);
ql_sem_unlock(qdev, QL_PHY_GIO_SEM_MASK);
spin_unlock_irqrestore(qdev-hw_lock, hw_flags);
@@ -1534,8 +1538,10 @@ static u32 ql_get_speed(struct ql3_adapter *qdev)
spin_lock_irqsave(qdev-hw_lock, hw_flags);
if(ql_sem_spinlock(qdev, QL_PHY_GIO_SEM_MASK,
(QL_RESOURCE_BITS_BASE_CODE | (qdev-mac_index) *
-2) 7))
+2) 7)) {
+ spin_unlock_irqrestore(qdev-hw_lock, hw_flags);
return 0;
+ }
status = ql_get_link_speed(qdev);
ql_sem_unlock(qdev, QL_PHY_GIO_SEM_MASK);
spin_unlock_irqrestore(qdev-hw_lock, hw_flags);
@@ -1549,8 +1555,10 @@ static int ql_get_full_dup(struct ql3_adapter *qdev)
spin_lock_irqsave(qdev-hw_lock, hw_flags);
if(ql_sem_spinlock(qdev, QL_PHY_GIO_SEM_MASK,
(QL_RESOURCE_BITS_BASE_CODE | (qdev-mac_index) *
-2) 7))
+2) 7)) {
+ spin_unlock_irqrestore(qdev-hw_lock, hw_flags);
return 0;
+ }
status = ql_is_link_full_dup(qdev);
ql_sem_unlock(qdev, QL_PHY_GIO_SEM_MASK);
spin_unlock_irqrestore(qdev-hw_lock, hw_flags);
@@ -3312,6 +3320,7 @@ static int ql_adapter_up(struct ql3_adapter *qdev)
err_init:
ql_sem_unlock(qdev, QL_DRVR_SEM_MASK);
err_lock:
+ spin_unlock_irqrestore(qdev-hw_lock, hw_flags);
free_irq(qdev-pdev-irq, ndev);
err_irq:
if (qdev-msi test_bit(QL_MSI_ENABLED,qdev-flags)) {
--
1.5.0.rc4.16.g9e258
-
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/majordomo-info.html
[RFC][NET] Alignment in mv643xx_eth
The driver contains this little piece of candy:
#if defined(CONFIG_DMA_NONCOHERENT) || defined(CONFIG_NOT_COHERENT_CACHE)
#define ETH_DMA_ALIGN L1_CACHE_BYTES
#else
#define ETH_DMA_ALIGN 8
#endif
Any reason why we're not using dma_get_cache_alignment() instead?
Ralf
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index d98e53e..3e045a6 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -147,13 +147,13 @@ static void mv643xx_eth_rx_refill_descs(struct net_device
*dev)
int unaligned;
while (mp-rx_desc_count mp-rx_ring_size) {
- skb = dev_alloc_skb(ETH_RX_SKB_SIZE + ETH_DMA_ALIGN);
+ skb = dev_alloc_skb(ETH_RX_SKB_SIZE +
dma_get_cache_alignment());
if (!skb)
break;
mp-rx_desc_count++;
- unaligned = (u32)skb-data (ETH_DMA_ALIGN - 1);
+ unaligned = (u32)skb-data (dma_get_cache_alignment() - 1);
if (unaligned)
- skb_reserve(skb, ETH_DMA_ALIGN - unaligned);
+ skb_reserve(skb, dma_get_cache_alignment() - unaligned);
pkt_info.cmd_sts = ETH_RX_ENABLE_INTERRUPT;
pkt_info.byte_cnt = ETH_RX_SKB_SIZE;
pkt_info.buf_ptr = dma_map_single(NULL, skb-data,
diff --git a/drivers/net/mv643xx_eth.h b/drivers/net/mv643xx_eth.h
index 33c5faf..7cb0a41 100644
--- a/drivers/net/mv643xx_eth.h
+++ b/drivers/net/mv643xx_eth.h
@@ -42,17 +42,6 @@
#define MAX_DESCS_PER_SKB 1
#endif
-/*
- * The MV643XX HW requires 8-byte alignment. However, when I/O
- * is non-cache-coherent, we need to ensure that the I/O buffers
- * we use don't share cache lines with other data.
- */
-#if defined(CONFIG_DMA_NONCOHERENT) || defined(CONFIG_NOT_COHERENT_CACHE)
-#define ETH_DMA_ALIGN L1_CACHE_BYTES
-#else
-#define ETH_DMA_ALIGN 8
-#endif
-
#define ETH_VLAN_HLEN 4
#define ETH_FCS_LEN4
#define ETH_HW_IP_ALIGN2 /* hw aligns IP header
*/
-
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/majordomo-info.html
Re: [PATCH] Fix oops in xfrm4_dst_destroy()
From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 26 Feb 2007 01:24:37 +0100 Bernhard Walle wrote: With 2.6.21-rc1, I get an oops when running 'ifdown eth0' and an IPsec connection is active. If I shut down the connection before running 'ifdown eth0', then there's no problem. The critical operation of this script is to kill dhcpd. The problem is probably caused by commit with git identifier 4337226228e1cfc1d70ee975789c6bd070fb597c (Linus tree) [IPSEC]: IPv4 over IPv6 IPsec tunnel. This patch fixes that oops. I don't know the network code of the Linux kernel in deep, so if that fix is wrong, please change it. But please fix the oops. :) Looks good, when the xfrm_dst is freed in __xfrm4_bundle_create after a failed call to xfrm_dst_lookup the xfrm pointer is not set, and this is also expected by xfrm_dst_destroy. Acked-by: Patrick McHardy [EMAIL PROTECTED] Patch applied, thanks everyone. - 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/majordomo-info.html
Re: [RFC][NET] Alignment in mv643xx_eth
On Mon, Feb 26, 2007 at 07:52:06PM +, Ralf Baechle wrote: The driver contains this little piece of candy: #if defined(CONFIG_DMA_NONCOHERENT) || defined(CONFIG_NOT_COHERENT_CACHE) #define ETH_DMA_ALIGN L1_CACHE_BYTES #else #define ETH_DMA_ALIGN 8 #endif Any reason why we're not using dma_get_cache_alignment() instead? Not that I can think of. ACK. Dale Farnsworth - 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/majordomo-info.html
Re: [PATCH 4/5] r8169: more alignment for the 0x8168
On Mon, 26 Feb 2007 17:42:27 +1000 Philip Craig [EMAIL PROTECTED] wrote: Francois Romieu wrote: The experimental r8169 patch of the day against 2.6.21-rc1 is available at: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.21-rc1/ Is 0006-r8169-confusion-between-hardware-and-IP-header-alignment.txt the only relevant patch? This only partially helps. Many of the packets are greater than 200 bytes so copybreak doesn't apply to them. Can we assume anything about the alignment of skb-data? I think it should be 4 byte aligned, otherwise the whole NET_IP_ALIGN thing won't work. All the drivers I looked at just reserve NET_IP_ALIGN without checking the alignment first. This is where the alignment comes from in slab.c #ifndef ARCH_KMALLOC_MINALIGN /* * Enforce a minimum alignment for the kmalloc caches. * Usually, the kmalloc caches are cache_line_size() aligned, except when * DEBUG and FORCED_DEBUG are enabled, then they are BYTES_PER_WORD aligned. * Some archs want to perform DMA into kmalloc caches and need a guaranteed * alignment larger than BYTES_PER_WORD. ARCH_KMALLOC_MINALIGN allows that. * Note that this flag disables some debug features. */ #define ARCH_KMALLOC_MINALIGN 0 #endif Since BYTES_PER_WORD is sizeof(void *) you are safe since Linux doesn't run on 16 bit platforms. -- Stephen Hemminger [EMAIL PROTECTED] - 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/majordomo-info.html
Re: xfrm_add_sa_expire return codes
From: Kent Yoder [EMAIL PROTECTED] Date: Mon, 26 Feb 2007 16:26:41 -0600 I was browsing through the xfrm_user.c code and noticed that it appears that in xfrm_add_sa_expire, the only possible return codes are -ENOENT and -EINVAL. Was this intentional, or is this a bug? Please use netdev@vger.kernel.org for kernel networking discussions, thanks. Indeed, and the tabbing on the first err = assignment should be a clue that some mistake might have been added. It looks like the code has been like that from day one, I wonder how Jamal tested this stuff :-) I'm going to assume the intended logic, and fix it like this. Jamal? diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c index 2567453..924a2fe 100644 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -1557,14 +1557,13 @@ static int xfrm_add_sa_expire(struct sk_buff *skb, struct nlmsghdr *nlh, struct xfrm_usersa_info *p = ue-state; x = xfrm_state_lookup(p-id.daddr, p-id.spi, p-id.proto, p-family); - err = -ENOENT; + err = -ENOENT; if (x == NULL) return err; - err = -EINVAL; - spin_lock_bh(x-lock); + err = -EINVAL; if (x-km.state != XFRM_STATE_VALID) goto out; km_state_expired(x, ue-hard, current-pid); @@ -1574,6 +1573,7 @@ static int xfrm_add_sa_expire(struct sk_buff *skb, struct nlmsghdr *nlh, xfrm_audit_log(NETLINK_CB(skb).loginuid, NETLINK_CB(skb).sid, AUDIT_MAC_IPSEC_DELSA, 1, NULL, x); } + err = 0; out: spin_unlock_bh(x-lock); xfrm_state_put(x); - 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/majordomo-info.html
[PATCH] netxen: do_rom_fast_write error handling
Compiler warning spots real error!
The function do_rom_fast_read called in do_rom_fast_write can fail
and leave data1 unset. This causes a compile warning.
The correct thing is to propagate the error out.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic_init.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- pktgen.orig/drivers/net/netxen/netxen_nic_init.c2007-02-26
14:45:46.0 -0800
+++ pktgen/drivers/net/netxen/netxen_nic_init.c 2007-02-26 14:46:37.0
-0800
@@ -499,7 +499,10 @@
while(1) {
int data1;
- do_rom_fast_read(adapter, addridx, data1);
+ ret = do_rom_fast_read(adapter, addridx, data1);
+ if (ret 0)
+ return ret;
+
if (data1 == data)
break;
-
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/majordomo-info.html
[PATCH, RESEND] chelsio: Fix non-NAPI compile
Chelsio without NAPI enabled has been broken (won't compile) since
3de00b89 (chelsio: NAPI speed improvement):
drivers/net/chelsio/sge.c: In function `t1_interrupt`:
drivers/net/chelsio/sge.c:1716: error: `Q` undeclared (first use in this
function)
The change below seems to add back in the declaration and
initialization of `Q` that was removed by mistake, and at least makes
the driver compile for me, although I have no hardware and hence no
way to test whether this actually works.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
Jeff, I haven't seen any response from Stephen but Divy from Chelsio
seemed to agree with this patch, so can you please merge it? Right
now the build is broken with CONFIG_CHELSIO_T1_NAPI=n.
Thanks.
diff --git a/drivers/net/chelsio/sge.c b/drivers/net/chelsio/sge.c
index 89a6827..326d4a6 100644
--- a/drivers/net/chelsio/sge.c
+++ b/drivers/net/chelsio/sge.c
@@ -1696,6 +1696,7 @@ irqreturn_t t1_interrupt(int irq, void *cookie)
{
int work_done;
struct adapter *adapter = cookie;
+ struct respQ *Q = adapter-sge-respQ;
spin_lock(adapter-async_lock);
-
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/majordomo-info.html
Re: [PATCH, RESEND] chelsio: Fix non-NAPI compile
On Mon, 26 Feb 2007 14:58:49 -0800 Roland Dreier [EMAIL PROTECTED] wrote: Chelsio without NAPI enabled has been broken (won't compile) since 3de00b89 (chelsio: NAPI speed improvement): drivers/net/chelsio/sge.c: In function `t1_interrupt`: drivers/net/chelsio/sge.c:1716: error: `Q` undeclared (first use in this function) The change below seems to add back in the declaration and initialization of `Q` that was removed by mistake, and at least makes the driver compile for me, although I have no hardware and hence no way to test whether this actually works. Signed-off-by: Roland Dreier [EMAIL PROTECTED] --- Jeff, I haven't seen any response from Stephen but Divy from Chelsio seemed to agree with this patch, so can you please merge it? Right now the build is broken with CONFIG_CHELSIO_T1_NAPI=n. Thanks. I agree it was an obvious goof. -- Stephen Hemminger [EMAIL PROTECTED] - 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/majordomo-info.html
Re: [PATCH] IPv6 anycast refcnt fix
From: Michal Wrobel [EMAIL PROTECTED] Date: Sun, 25 Feb 2007 13:04:21 +0100 This patch fixes a bug in Linux IPv6 stack which caused anycast address to be added to a device prior DAD has been completed. This led to incorrect reference count which resulted in infinite wait for unregister_netdevice completion on interface removal. Signed-off-by: Michal Wrobel [EMAIL PROTECTED] Patch applied, thank you. - 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/majordomo-info.html
Re: need some help on a backport of r8169
Pascal GREGIS [EMAIL PROTECTED] : [...] Could anyone take a look at my patch and tell me what is missing, - It lacks the adequate registers init sequence for a 8168 for instance. - Fix went in between 2.6.11 and 2.6.12. There are 59 r8169 related patches between 2.6.12 and current. Only a few of those break the API. I'll give it a try tomorrow evening. -- Ueimor - 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/majordomo-info.html
[PATCH] /proc/net/anycast6 unbalanced inet6_dev refcnt
Reading /proc/net/anycast6 when there is no anycast address on an interface results in an ever-increasing inet6_dev reference count, as well as a reference to the netdevice you can't get rid of. Patch below attached. +-DLS Signed-off-by: David L Stevens [EMAIL PROTECTED] --- linux-2.6.20.1/net/ipv6/anycast.c 2007-02-19 22:34:32.0 -0800 +++ linux-2.6.20.1T1/net/ipv6/anycast.c 2007-02-26 15:37:04.0 -0800 @@ -462,6 +462,7 @@ static inline struct ifacaddr6 *ac6_get_ break; } read_unlock_bh(idev-lock); + in6_dev_put(idev); } return im; } ac6.patch Description: Binary data
Re: [PATCH] /proc/net/anycast6 unbalanced inet6_dev refcnt
From: David Stevens [EMAIL PROTECTED] Date: Mon, 26 Feb 2007 17:22:10 -0700 Reading /proc/net/anycast6 when there is no anycast address on an interface results in an ever-increasing inet6_dev reference count, as well as a reference to the netdevice you can't get rid of. Applied, thanks a lot David. I'll send this off to -stable too. - 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/majordomo-info.html
Re: xfrm_add_sa_expire return codes
On Mon, 2007-26-02 at 14:48 -0800, David Miller wrote: Indeed, and the tabbing on the first err = assignment should be a clue that some mistake might have been added. It looks like the code has been like that from day one, I wonder how Jamal tested this stuff :-) I am asking myself the same question staring at that;- Let me look at the test code tommorow and get back to you. I know my test was passing ;- I'm going to assume the intended logic, and fix it like this. Jamal? Looks good - thanks Dave. cheers, jamal - 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/majordomo-info.html
Re: Fix ipOutNoRoutes counter error for TCP and UDP
From: weidong [EMAIL PROTECTED]
Date: Wed, 14 Feb 2007 10:03:49 -0500
Hi, All
When I tested Linux-2.6.20 and found that counter ipOutNoRoutes can
not increase correctly.
The criteria is RFC2011
ipOutNoRoutes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
The number of IP datagrams discarded because no route could
be found to transmit them to their destination. Note that
this counter includes any packets counted in ipForwDatagrams
which meet this `no-route' criterion. Note that this
includes any datagrams which a host cannot route because all
of its default routers are down.
::= { ip 12 }
In current Linux TCP/IP stack, maybe we should not increase this counter
in input path, but only increase it in output path due to the TCP/IP
stack performance.
Now in output path, when TCP client tries to connect to an unreachable
server(net unreachable, so no route can be found), this counter has no
increment. When we use UDP sending UDP datagram to an net unreachable
address, this counter also has no increment.
Function need to fix:
tcp_v4_connect(); ip4_datagram_connect(); udp_sendmsg();
The following patch can fix the problems mentioned above
Thank you for this patch.
I think we need to make these checks more carefully.
Route lookup can fail for several reasons other than
no route being available. Two examples are:
1) Out of memory error while creating route
2) IPSEC disallows communication to that flow ID
As a result, we'll probably best limiting the counter
increment when the error is either -EHOSTUNREACH or
-ENETUNREACH.
Probably, since this logic will be duplicated to several
locations, you'll want to implement the test inside of
a helper inline function.
-
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/majordomo-info.html
[PATCH 1/3] TCP sysctl documentation: tcp_moderate_rcvbuf
Document sysctl tcp_moderate_rcvbuf. Signed-off-by: John Heffner [EMAIL PROTECTED] --- commit 4c5fd9d3a9ea8b939aed1afda2ac0fc54e3df592 tree c25c2fd01e076fbb7356a8c37d06d2e22c60f263 parent aef8811abbc9249a2bd59bd2331bbe523df05d17 author John Heffner [EMAIL PROTECTED] Mon, 26 Feb 2007 19:44:58 -0500 committer John Heffner [EMAIL PROTECTED] Mon, 26 Feb 2007 19:44:58 -0500 Documentation/networking/ip-sysctl.txt |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index a0f6842..a9ad96b 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -243,6 +243,12 @@ tcp_mem - vector of 3 INTEGERs: min, pressure, max Defaults are calculated at boot time from amount of available memory. +tcp_moderate_rcvbuf - BOOLEAN + If set, TCP performs receive buffer autotuning, attempting to + automatically size the buffer (no greater than tcp_rmem[2]) to + match the size required by the path for full throughput. Enabled by + default. + tcp_orphan_retries - INTEGER How may times to retry before killing TCP connection, closed by our side. Default value 7 corresponds to ~50sec-16min
[PATCH 2/3] TCP sysctl documentation: tcp_no_metrics_save
Document sysctl tcp_no_metrics_save. Signed-off-by: John Heffner [EMAIL PROTECTED] --- commit 17cb799000caef3b2fed28cc5d0601bb2311efa8 tree c27ccf561065b145bc48d0b8dbbaa3c608015e03 parent 4c5fd9d3a9ea8b939aed1afda2ac0fc54e3df592 author John Heffner [EMAIL PROTECTED] Mon, 26 Feb 2007 19:51:50 -0500 committer John Heffner [EMAIL PROTECTED] Mon, 26 Feb 2007 19:51:50 -0500 Documentation/networking/ip-sysctl.txt |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index a9ad96b..891f389 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -249,6 +249,14 @@ tcp_moderate_rcvbuf - BOOLEAN match the size required by the path for full throughput. Enabled by default. +tcp_no_metrics_save - BOOLEAN + By default, TCP saves various connection metrics in the route cache + when the connection closes, so that connections established in the + near future can use these to set initial conditions. Usually, this + increases overall performance, but may sometimes cause performance + degredation. If set, TCP will not cache metrics on closing + connections. + tcp_orphan_retries - INTEGER How may times to retry before killing TCP connection, closed by our side. Default value 7 corresponds to ~50sec-16min
[PATCH 2/3] TCP sysctl documentation: MTU probing
Documentation for sysctls tcp_mtu_probing and tcp_base_mss. Signed-off-by: John Heffner [EMAIL PROTECTED] --- commit 6da0563572e0a6d0abda9d950f30902844c37862 tree 6f21ae02c11a1340412a926e8e2f568f5ed3b5a8 parent 17cb799000caef3b2fed28cc5d0601bb2311efa8 author John Heffner [EMAIL PROTECTED] Mon, 26 Feb 2007 20:02:35 -0500 committer John Heffner [EMAIL PROTECTED] Mon, 26 Feb 2007 20:02:35 -0500 Documentation/networking/ip-sysctl.txt | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 891f389..d3aae1f 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -147,6 +147,11 @@ tcp_available_congestion_control - STRING More congestion control algorithms may be available as modules, but not loaded. +tcp_base_mss - INTEGER + The initial value of search_low to be used by Packetization Layer + Path MTU Discovery (MTU probing). If MTU probing is enabled, + this is the inital MSS used by the connection. + tcp_congestion_control - STRING Set the congestion control algorithm to be used for new connections. The algorithm reno is always available, but @@ -249,6 +254,13 @@ tcp_moderate_rcvbuf - BOOLEAN match the size required by the path for full throughput. Enabled by default. +tcp_mtu_probing - INTEGER + Controls TCP Packetization-Layer Path MTU Discovery. Takes three + values: + 0 - Disabled + 1 - Disabled by default, enabled when an ICMP black hole detected + 2 - Always enabled, use initial MSS of tcp_base_mss. + tcp_no_metrics_save - BOOLEAN By default, TCP saves various connection metrics in the route cache when the connection closes, so that connections established in the
system lockup
Hello,
for learning device drivers I took 8139too.c to explore it. I
disrupted the code into several logical blocks and now I'm trying to
implement my own simplified version referring to original code from
time to time. I have rtl8139d NIC for experiments. So, by now I've
acomplished the following stages:
1) detected device
2) enable PCI device
3) memory mapped IO initialised
4) initialization of 'net_device' structure
And I'm stuck on the chip reset. Whenever I load driver and try to
enable interface (ifconfig eth1 up) my system just hangs, keyboard
locks up, I can't even use 'SysRq' shortcuts.
I figured out that problem occurs after I initialised chip, i.e. in
this routine called from 'net_device-open' method:
#define CmdTxEnb (0x04)
...
#define RxOK (0x01)
#define RxErr (0x02)
#define TxOK (0x04)
#define TxErr (0x08)
#define RxOverFlow (0x10)
#define RxUnderrun (0x20)
#define RxFIFOOver (0x40)
#define CableLen (0x2000)
#define TimeOut (0x4000)
#define SysErr (0x8000)
#define INT_MASK (RxOK | RxErr | TxOK | TxErr | RxOverFlow | \
RxUnderrun | RxFIFOOver | CableLen | TimeOut | SysErr)
static void rtl8139_hw_start(struct net_device *dev)
{
struct rtl8139_private *tp = dev-priv;
void *ioaddr = tp-mmio_addr;
...
writeb(CmdTxEnb, ioaddr + REG_COMMAND);
writel(0x0600, ioaddr + REG_TX_CONFIG);/* DMA burst size 1024 */
/* init TX buffer DMA addresses */
for (i = 0; i NUM_TX_DESC; i++) {
writel(tp-tx_bufs_dma + (tp-tx_buf[i] - tp-tx_bufs), ioaddr +
REG_TX_ADDR0 + (i * 4));
}
/* enable all known interrupts by setting the interrupt mask */
writew(INT_MASK, ioaddr + REG_INTR_MASK);
netif_start_queue(dev);
return;
}
static int rtl8139_open(struct net_device *dev)
{
int retval;
struct rtl8139_private *tp = dev-priv;
...
retval = request_irq(dev-irq, rtl8139_interrupt, 0, dev-name, dev);
if (retval)
return retval;
/* Get memory for TX buffers. Memory must be DMA-able */
tp-tx_bufs = pci_alloc_consistent(tp-pci_dev, TOTAL_TX_BUF_SIZE,
tp-tx_bufs_dma);
...
rtl8139_init_ring(dev);
rtl8139_hw_start(dev);
DPRINTK(init_ring() hw_start() passed\n);
return;
}
rtl8139_hw_start() is really invoked and returned, since I'm getting
printk output. Commenting 'rtl8139_hw_start(dev);' out brings the
interface up succesfully, that's why I came to conclusion the problem
is in chip initialization routine.
If anybody has any clue, I'd appreciate to hear it and get advice.
Thanks in advance.
--
Roman
-
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/majordomo-info.html
Re: 2.6.20-rc4-mm1: PCI=n: drivers/net/3c59x.c compile error
Hello, I wrote:
3x59x-fix-pci-resource-management.patch causes the following compile
error with CONFIG_PCI=n:
-- snip --
...
CC drivers/net/3c59x.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:
In function 'vortex_init_one':
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:961:
error: implicit declaration of function 'pci_request_regions'
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:985:
error: implicit declaration of function 'pci_release_regions'
make[3]: *** [drivers/net/3c59x.o] Error 1
Grr, at at the same time it's happy with pci_enable_device().
I'd say the problem is in linux/pci.h, not in the patch.
Has there been any patch to fix the unbalanced
pci_{request|release}_regions() declarations? Am I suposed to create
such?
Alternatively, vortex_{init|remove_one() and struct pci_driver there
could have been put under #ifdef CONFIG_PCI (good idea anyway -- should
reduce driver size on non-PCI systems)...
I wonder if I may count on any feedback on this -- asking linux-pci now...
The issue is as follows: with my patch pci_{request|release}_regions() may
be called with CONFIG_PCI=n (probably, this never has been a issue before) but
linux/pci.h don't have them declared in this case -- unlike
pci_enable_device() which is just empty for CONFIG_PCI=n.
Now, what kind of approach do I take:
- a fair one, so that pci_{request|release}_regions() get balanced
declarations in the header like pci_enable_device();
- a local one (and even saving non-PCI kernel from needless bloat), i.e.
#ifdef out functions that are only meaningful with CONFIG_PCI=y)?
I'm leaning to the second now...
cu
Adrian
MBR, Sergei
-
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/majordomo-info.html
Re: [PATCH] ehea: Optional TX/RX path optimized for SMP
Hi Also, as far as the approach of using tasklets, I think it would be better to use the fake netdev approach to continue to use NAPI. Basically you create a pseudo-netdev for each receive queue and have NAPI handle the polling for you -- you could look for drivers/net/cxgb3 for an example of this. Thanks for pointing us to this solution. We are now building a NAPI version that makes use of these pseudo-netdev. The fairness amongst other netdevices should be better this way. Why make this a module option that the user has to set? Are there any circumstances when someone wouldn't want significant performance improvements? If this approach is just better, then it should just replace the old code. We'll change the default behaviour to multi queue, but we'd like to keep the option to run in a single queue mode for debug and backward compabilty. Thanks, Jan-Bernd Christoph 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/majordomo-info.html
[PATCH] ehea: NAPI multi queue TX/RX path for SMP
Hi!
This patch replaces the former posted patch
([PATCH] ehea: Optional TX/RX path optimized for SMP) and provides
a functionality that allows parallel RX processing on multiple RX
queues by using dummy netdevices as proposed by Roland Dreier.
The fairness amongst this net devices and other network devices
is thus better than in our first approach.
Is there a way to avoid overloading a single CPU with multiple netdev
receive processes using NAPI? A distribution based on CPU load might
help to improve the throughput. Pinning interrupts shows there is
still some room for improvements.
Regards,
Jan-Bernd
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
diff -Nurp -X dontdiff linux-2.6.21-rc1/drivers/net/ehea/ehea.h
patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.21-rc1/drivers/net/ehea/ehea.h2007-02-26 16:17:14.0
+0100
+++ patched_kernel/drivers/net/ehea/ehea.h 2007-02-26 16:29:08.0
+0100
@@ -39,7 +39,7 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0048
+#define DRV_VERSIONEHEA_0050
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -78,8 +78,6 @@
#define EHEA_RQ2_PKT_SIZE 1522
#define EHEA_L_PKT_SIZE 256/* low latency */
-#define EHEA_POLL_MAX_RWQE 1000
-
/* Send completion signaling */
#define EHEA_SIG_IV_LONG 1
@@ -357,8 +355,8 @@ struct ehea_port_res {
struct ehea_qp *qp;
struct ehea_cq *send_cq;
struct ehea_cq *recv_cq;
- struct ehea_eq *send_eq;
- struct ehea_eq *recv_eq;
+ struct ehea_eq *eq;
+ struct net_device *d_netdev;
spinlock_t send_lock;
struct ehea_q_skb_arr rq1_skba;
struct ehea_q_skb_arr rq2_skba;
@@ -372,7 +370,6 @@ struct ehea_port_res {
int swqe_count;
u32 swqe_id_counter;
u64 tx_packets;
- struct tasklet_struct send_comp_task;
spinlock_t recv_lock;
struct port_state p_state;
u64 rx_packets;
@@ -416,7 +413,9 @@ struct ehea_port {
char int_aff_name[EHEA_IRQ_NAME_SIZE];
int allmulti;/* Indicates IFF_ALLMULTI state */
int promisc; /* Indicates IFF_PROMISC state */
+ int num_tx_qps;
int num_add_tx_qps;
+ int num_mcs;
int resets;
u64 mac_addr;
u32 logical_port_id;
diff -Nurp -X dontdiff linux-2.6.21-rc1/drivers/net/ehea/ehea_main.c
patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.21-rc1/drivers/net/ehea/ehea_main.c 2007-02-26
16:17:14.0 +0100
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2007-02-26 16:20:16.0
+0100
@@ -51,12 +51,14 @@ static int rq1_entries = EHEA_DEF_ENTRIE
static int rq2_entries = EHEA_DEF_ENTRIES_RQ2;
static int rq3_entries = EHEA_DEF_ENTRIES_RQ3;
static int sq_entries = EHEA_DEF_ENTRIES_SQ;
+static int use_mcs = 0;
module_param(msg_level, int, 0);
module_param(rq1_entries, int, 0);
module_param(rq2_entries, int, 0);
module_param(rq3_entries, int, 0);
module_param(sq_entries, int, 0);
+module_param(use_mcs, int, 0);
MODULE_PARM_DESC(msg_level, msg_level);
MODULE_PARM_DESC(rq3_entries, Number of entries for Receive Queue 3
@@ -71,6 +73,7 @@ MODULE_PARM_DESC(rq1_entries, Number of
MODULE_PARM_DESC(sq_entries, Number of entries for the Send Queue
[2^x - 1], x = [6..14]. Default =
__MODULE_STRING(EHEA_DEF_ENTRIES_SQ) ));
+MODULE_PARM_DESC(use_mcs, 0:NAPI, 1:Multiple receive queues, Default = 1 );
void ehea_dump(void *adr, int len, char *msg) {
int x;
@@ -197,7 +200,7 @@ static int ehea_refill_rq_def(struct ehe
struct sk_buff *skb = netdev_alloc_skb(dev, packet_size);
if (!skb) {
ehea_error(%s: no mem for skb/%d wqes filled,
- dev-name, i);
+ pr-port-netdev-name, i);
q_skba-os_skbs = fill_wqes - i;
ret = -ENOMEM;
break;
@@ -345,10 +348,11 @@ static int ehea_treat_poll_error(struct
return 0;
}
-static int ehea_poll(struct net_device *dev, int *budget)
+static struct ehea_cqe *ehea_proc_rwqes(struct net_device *dev,
+ struct ehea_port_res *pr,
+ int *budget)
{
- struct ehea_port *port = netdev_priv(dev);
- struct ehea_port_res *pr = port-port_res[0];
+ struct ehea_port *port = pr-port;
struct ehea_qp *qp = pr-qp;
struct ehea_cqe *cqe;
struct sk_buff *skb;
@@ -359,14 +363,12 @@ static int ehea_poll(struct net_device *
int skb_arr_rq2_len = pr-rq2_skba.len;
int skb_arr_rq3_len = pr-rq3_skba.len;
int processed, processed_rq1, processed_rq2, processed_rq3;
- int wqe_index, last_wqe_index, rq, intreq, my_quota,
Re: 2.6.20-rc4-mm1: PCI=n: drivers/net/3c59x.c compile error
On Mon, 26 Feb 2007 16:22:27 +0300 Sergei Shtylyov wrote:
Hello, I wrote:
3x59x-fix-pci-resource-management.patch causes the following compile
error with CONFIG_PCI=n:
-- snip --
...
CC drivers/net/3c59x.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:
In function 'vortex_init_one':
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:961:
error: implicit declaration of function 'pci_request_regions'
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:985:
error: implicit declaration of function 'pci_release_regions'
make[3]: *** [drivers/net/3c59x.o] Error 1
Grr, at at the same time it's happy with pci_enable_device().
I'd say the problem is in linux/pci.h, not in the patch.
Has there been any patch to fix the unbalanced
pci_{request|release}_regions() declarations? Am I suposed to create
such?
Alternatively, vortex_{init|remove_one() and struct pci_driver there
could have been put under #ifdef CONFIG_PCI (good idea anyway -- should
reduce driver size on non-PCI systems)...
I wonder if I may count on any feedback on this -- asking linux-pci now...
The issue is as follows: with my patch pci_{request|release}_regions()
may
be called with CONFIG_PCI=n (probably, this never has been a issue before)
but
linux/pci.h don't have them declared in this case -- unlike
pci_enable_device() which is just empty for CONFIG_PCI=n.
Now, what kind of approach do I take:
- a fair one, so that pci_{request|release}_regions() get balanced
declarations in the header like pci_enable_device();
- a local one (and even saving non-PCI kernel from needless bloat), i.e.
#ifdef out functions that are only meaningful with CONFIG_PCI=y)?
I'm leaning to the second now...
I'd prefer the fair one -- add stubs to include/linux/pci.h.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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/majordomo-info.html
Re: D-Link DGE-528T (r8159) autonegotation of 1000 Mbps link does not work
Please Cc: the maintainer from the MAINTAINERS file. Petri T. Koistinen [EMAIL PROTECTED] : [...] I just brought two D-Link DGE-528T (uses r8159 driver) network adapters to have nice 1 Gbps home network between two computers. - which kernel ? - dmesg please ? [...] and when I use this cable I only get 10 Mbps connection when connected another D-Link DGE-528T. Try a straight cable between the two D-Link adapters. [...] Do anyone know if there some known bug in auto-negotiation with Realtek 8159 chip? (Or is that just wrong cable?) Can I force 1000 Mbps link on some other way than giving option to insmod? Using /proc or something? mii-tool or (better) ethtool. [...] What kind of transfer speed you have reached with these cards ? That 15 MiB/s is not what I expected. It smells like fast ethernet. Even my old PII does better than that with a 8169. Please send 'mii-tool -vv' and/or ethtool output + vmstat 1 during test. -- Ueimor - 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/majordomo-info.html
Re: [RFC] div64_64 support
On Feb 23 2007 17:05, Stephen Hemminger wrote: Since there already two users of full 64 bit division in the kernel, and other places maybe hiding out as well. Add a full 64/64 bit divide. Yes this expensive, but there are places where it is necessary. It is not clear if doing the scaling buys any advantage on 64 bit platforms, so for them a full divide is done. --- include/asm-arm/div64.h |2 ++ include/asm-generic/div64.h |8 include/asm-m68k/div64.h |2 ++ include/asm-mips/div64.h |8 include/asm-um/div64.h |1 + include/asm-xtensa/div64.h |1 + lib/div64.c | 22 ++ net/ipv4/tcp_cubic.c | 22 -- net/netfilter/xt_connbytes.c | 16 9 files changed, 44 insertions(+), 38 deletions(-) Actually, there is udivdi3 support in the kernel ./arch/arm26/lib/udivdi3.c ./arch/sh/lib/udivdi3.c ./arch/sparc/lib/udivdi3.S should not this be consolidated too? Jan -- ft: http://freshmeat.net/p/chaostables/ - 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/majordomo-info.html
Re: 2.6.20-rc4-mm1: PCI=n: drivers/net/3c59x.c compile error
On Mon, Feb 26, 2007 at 09:26:44AM -0800, Randy Dunlap wrote:
On Mon, 26 Feb 2007 16:22:27 +0300 Sergei Shtylyov wrote:
Hello, I wrote:
3x59x-fix-pci-resource-management.patch causes the following compile
error with CONFIG_PCI=n:
-- snip --
...
CC drivers/net/3c59x.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:
In function 'vortex_init_one':
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:961:
error: implicit declaration of function 'pci_request_regions'
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:985:
error: implicit declaration of function 'pci_release_regions'
make[3]: *** [drivers/net/3c59x.o] Error 1
Grr, at at the same time it's happy with pci_enable_device().
I'd say the problem is in linux/pci.h, not in the patch.
Has there been any patch to fix the unbalanced
pci_{request|release}_regions() declarations? Am I suposed to create
such?
Alternatively, vortex_{init|remove_one() and struct pci_driver there
could have been put under #ifdef CONFIG_PCI (good idea anyway -- should
reduce driver size on non-PCI systems)...
I wonder if I may count on any feedback on this -- asking linux-pci
now...
The issue is as follows: with my patch pci_{request|release}_regions()
may
be called with CONFIG_PCI=n (probably, this never has been a issue before)
but
linux/pci.h don't have them declared in this case -- unlike
pci_enable_device() which is just empty for CONFIG_PCI=n.
Now, what kind of approach do I take:
- a fair one, so that pci_{request|release}_regions() get balanced
declarations in the header like pci_enable_device();
- a local one (and even saving non-PCI kernel from needless bloat), i.e.
#ifdef out functions that are only meaningful with CONFIG_PCI=y)?
I'm leaning to the second now...
I'd prefer the fair one -- add stubs to include/linux/pci.h.
Me too, please just send me a patch adding them to pci.h so you don't
have to have #ifdefs in your .c code.
thanks,
greg k-h
-
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/majordomo-info.html
Re: [RFC] div64_64 support
On Mon, 26 Feb 2007 21:09:26 +0100 (MET) Jan Engelhardt [EMAIL PROTECTED] wrote: On Feb 23 2007 17:05, Stephen Hemminger wrote: Since there already two users of full 64 bit division in the kernel, and other places maybe hiding out as well. Add a full 64/64 bit divide. Yes this expensive, but there are places where it is necessary. It is not clear if doing the scaling buys any advantage on 64 bit platforms, so for them a full divide is done. --- include/asm-arm/div64.h |2 ++ include/asm-generic/div64.h |8 include/asm-m68k/div64.h |2 ++ include/asm-mips/div64.h |8 include/asm-um/div64.h |1 + include/asm-xtensa/div64.h |1 + lib/div64.c | 22 ++ net/ipv4/tcp_cubic.c | 22 -- net/netfilter/xt_connbytes.c | 16 9 files changed, 44 insertions(+), 38 deletions(-) Actually, there is udivdi3 support in the kernel ./arch/arm26/lib/udivdi3.c ./arch/sh/lib/udivdi3.c ./arch/sparc/lib/udivdi3.S should not this be consolidated too? Hmm. Those are the GCC internal versions, that are picked up but doing divide in place. Do we want to allow general 64 bit in kernel to be easily used? It could cause sloppy slow code, but it would look cleaner. -- Stephen Hemminger [EMAIL PROTECTED] - 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/majordomo-info.html
Re: netconsole module cannot be removed
Stephen Hemminger wrote: On Mon, 26 Feb 2007 15:35:11 -0500 Chuck Ebbert [EMAIL PROTECTED] wrote: Trying to remove netconsole, rmmod goes into a tight loop with 100% CPU usage. It can't be killed with 'kill -9'. Shutdown works, though. Kernel is 2.6.20 FC6 config, and I'm 99.9% sure the module signing has nothing to do with this. No it probably has to do with printing a message during module removal. Yeah that could explain it. But when I load it after the network has started I can't get it to output any kernel messages to the network interface, either. I'll try to reproduce this on a vanilla kernel next... - 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/majordomo-info.html
2.6.21-rc1: known regressions (v2) (part 2)
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20 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 you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: forcedeth no longer works References : http://bugzilla.kernel.org/show_bug.cgi?id=8090 Submitter : David P. Reed [EMAIL PROTECTED] Caused-By : Ayaz Abdulla [EMAIL PROTECTED] Status : unknown Subject: forcedeth: skb_over_panic References : http://bugzilla.kernel.org/show_bug.cgi?id=8058 Submitter : Albert Hopkins [EMAIL PROTECTED] Status : unknown Subject: natsemi ethernet card not detected correctly References : http://lkml.org/lkml/2007/2/23/4 http://lkml.org/lkml/2007/2/23/7 Submitter : Bob Tracy [EMAIL PROTECTED] Caused-By : Mark Brown [EMAIL PROTECTED] Handled-By : Mark Brown [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/2/23/142 Status : patch available Subject: ThinkPad T60: system doesn't come out of suspend to RAM (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin [EMAIL PROTECTED] Handled-By : Thomas Gleixner [EMAIL PROTECTED] Ingo Molnar [EMAIL PROTECTED] Status : unknown Subject: kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/16/346 Submitter : Michal Piotrowski [EMAIL PROTECTED] Handled-By : Thomas Gleixner [EMAIL PROTECTED] Status : problem is being debugged Subject: BUG: soft lockup detected on CPU#0 NOHZ: local_softirq_pending 20 (SMT scheduler) References : http://lkml.org/lkml/2007/2/20/257 Submitter : Michal Piotrowski [EMAIL PROTECTED] Handled-By : Thomas Gleixner [EMAIL PROTECTED] Ingo Molnar [EMAIL PROTECTED] Status : problem is being debugged Subject: i386: no boot with nmi_watchdog=1 (clockevents) References : http://lkml.org/lkml/2007/2/21/208 Submitter : Daniel Walker [EMAIL PROTECTED] Caused-By : Thomas Gleixner [EMAIL PROTECTED] commit e9e2cdb412412326c4827fc78ba27f410d837e6e Handled-By : Thomas Gleixner [EMAIL PROTECTED] Status : problem is being debugged - 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/majordomo-info.html
[BUG][2.6.21] af_key: kernel BUG at net/core/skbuff.c:93
Hello, I'm running 2.6.21 (current git, at 9654640d0af). kernel blows up at startup, when running setkey. Kernel 2.6.20 runs fine. A couple of words on the config: I played a bit with IPSec a while ago, then removed AH/ESP (INET_AH and INET_ESP) from the kernel; NET_KEY was left enabled. I think that the problem lies in this (mis)configuration, since re-enabling AH/ESP makes the system boots fine. Kernel is SMP with PREEMT enabled. This the boot log (captured over serial console, unfortunately it's intermixed with output from startup scripts): Loading IPsec SA/SP database from /etc/ipsec-tools.conf: NET: Registered protoco l family 15 skb_over_panic: text:f1b8a065 len:16 put:16 head:b1a3ba00 data:b1a3ba00 tail:b1a 3ba00 end:b1a3ba90 dev:NULL [ cut here ] kernel BUG at /home/kronos/src/linux-2.6.git/net/core/skbuff.c:93! invalid opcode: [#1] PREEMPT SMP Modules linked in: af_key nfsd exportfs lockd sunrpc nls_iso8859_15 nls_cp850 vf at fat nls_base cpufreq_ondemand acpi_cpufreq freq_table i2c_isa ipv6 snd_hda_in tel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm e100 ohci1394 snd_timer ieee 1394 uhci_hcd snd ehci_hcd intel_agp parport_pc parport agpgart i2c_i801 usbcore atl1 mii soundcore snd_page_alloc dm_snapshot dm_mod thermal processor fan reis erfs xfs CPU:0 EIP:0060:[b02a4192]Not tainted VLI EFLAGS: 00210282 (2.6.21-rc1-g9654640d-dirty #35) EIP is at skb_over_panic+0x59/0x5d eax: 0071 ebx: b1a3ba00 ecx: eec64000 edx: /etc/rcS.d/S37seesi: edi: eec64dd4 ebp: eeccdb40 esp: eec64d20 tkey: line 21: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 4514 SegmentatioProcess setkey (pid: 4514, ti=eec64000 task=edd82ae0 task.ti=eec 64000) n fault $SEStack: TKEY -f $SETKEY_b03a2d1d f1b8a065 0010 0010 b1a3b a00 b1a3ba00 b1a3ba00 b1a3ba90 CONF Setting up b038176f b1a3ba80 eec64f44 f1b8a06a ef19ac00 edd8301c resolvconf... 00200046 b02f70c2 eec64dd0 b02f6ffe 0 000 eec64e20 Call Trace: [f1b8a065] pfkey_sendmsg+0x99/0x33e [af_key] [f1b8a06a] pfkey_sendmsg+0x9e/0x33e [af_key] [b02f70c2] wait_for_completion+0x7b/0xaa [b02f6ffe] __sched_text_start+0x7d6/0x80b [b02f995f] _spin_unlock_irq+0x20/0x41 [b013a3fe] trace_hardirqs_on+0x11e/0x141 [b02f70c2] wait_for_completion+0x7b/0xaa [b029fb67] sock_sendmsg+0xbc/0xd4 [b01317f1] autoremove_wake_function+0x0/0x35 [b0104f1c] dump_trace+0x89/0x93 [b013a55f] check_usage+0x24/0x245 [b0148676] find_get_page+0xe/0x3b [b029fe93] sys_sendto+0x11b/0x13b [b01534ab] __handle_mm_fault+0x2a5/0x864 [b013a3fe] trace_hardirqs_on+0x11e/0x141 [b0148676] find_get_page+0xe/0x3b [b014869e] find_get_page+0x36/0x3b [b01534ab] __handle_mm_fault+0x2a5/0x864 [b02f985b] _spin_unlock+0x25/0x3b [b0153a48] __handle_mm_fault+0x842/0x864 [b029feea] sys_send+0x37/0x3b [b02a0beb] sys_socketcall+0x12d/0x242 [b0103fe8] restore_nocheck+0x12/0x15 [b0103fa0] syscall_call+0x7/0xb === Code: 00 00 89 5c 24 14 8b 98 94 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 60 89 4c 24 04 c7 04 24 1d 2d 3a b0 89 44 24 08 e8 33 ce e7 ff 0f 0b eb fe 55 89 d5 57 56 53 83 ec 3c 89 44 24 20 8b 7c 24 50 EIP: [b02a4192] skb_over_panic+0x59/0x5d SS:ESP 0068:eec64d20 done. Setting up networking Configuring network interfaces...BUG: at /home/kronos/src/linux-2.6.git/net/ipv6 /addrconf.c:3367 inet6_ifa_notify() [f1a76132] __ipv6_ifa_notify+0x87/0x169 [ipv6] [f1a76234] ipv6_ifa_notify+0x20/0x27 [ipv6] [f1a78589] addrconf_notify+0x4bf/0x6d9 [ipv6] [b02e6c39] fib_magic+0x8b/0x9c [b02f9648] _spin_lock_irqsave+0x43/0x4b [b02f5f32] packet_notifier+0x16/0x141 [b02f98d1] _read_unlock+0x25/0x3b [b02f6055] packet_notifier+0x139/0x141 [b012bc2f] notifier_call_chain+0x19/0x32 [b02a9994] dev_open+0x5c/0x62 [b02a829c] dev_change_flags+0x47/0xe6 [b02e19fd] devinet_ioctl+0x259/0x573 [b01c6ba8] copy_to_user+0x37/0x4b [b029f417] sock_ioctl+0x191/0x1b0 [b029f286] sock_ioctl+0x0/0x1b0 [b016d4ab] do_ioctl+0x1f/0x62 [b016d732] vfs_ioctl+0x244/0x256 [b016d777] sys_ioctl+0x33/0x4c [b0103fa0] syscall_call+0x7/0xb === BUG: at /home/kronos/src/linux-2.6.git/net/ipv6/route.c:2237 inet6_rt_notify() [f1a7b3b5] inet6_rt_notify+0xd4/0x137 [ipv6] [f1a7cd74] fib6_add+0x40d/0x4cd [ipv6] [b02f94ad] _write_lock_bh+0x38/0x43 [f1a7a259] __ip6_ins_rt+0x24/0x34 [ipv6] [f1a76185] __ipv6_ifa_notify+0xda/0x169 [ipv6] [f1a76234] ipv6_ifa_notify+0x20/0x27 [ipv6] [f1a78589] addrconf_notify+0x4bf/0x6d9 [ipv6] [b02e6c39] fib_magic+0x8b/0x9c [b02f9648] _spin_lock_irqsave+0x43/0x4b [b02f5f32] packet_notifier+0x16/0x141 [b02f98d1] _read_unlock+0x25/0x3b [b02f6055] packet_notifier+0x139/0x141 [b012bc2f] notifier_call_chain+0x19/0x32 [b02a9994] dev_open+0x5c/0x62 [b02a829c] dev_change_flags+0x47/0xe6 [b02e19fd] devinet_ioctl+0x259/0x573 [b01c6ba8] copy_to_user+0x37/0x4b [b029f417] sock_ioctl+0x191/0x1b0 [b029f286] sock_ioctl+0x0/0x1b0 [b016d4ab]
Re: [BUG][2.6.21] af_key: kernel BUG at net/core/skbuff.c:93
Il Mon, Feb 26, 2007 at 11:08:41PM +0100, Luca Tettamanti ha scritto: .config is attached. This time for real... This one is with INET_AH and INET_ESP enabled. Disabling them triggers the bug. Luca -- Se non puoi convincerli, confondili. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc1 # Mon Feb 26 23:12:17 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Processor type and features # CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MCORE2=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_VMSPLIT_3G is not set CONFIG_VMSPLIT_3G_OPT=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xB000 CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y
Re: [RFC] div64_64 support
Here is another way to handle the 64 bit divide case.
It allows full 64 bit divide by adding the support routine
GCC needs.
---
arch/alpha/Kconfig |4
arch/arm/Kconfig |4
arch/arm26/Kconfig |4
arch/avr32/Kconfig |4
arch/cris/Kconfig|4
arch/frv/Kconfig |4
arch/h8300/Kconfig |4
arch/i386/Kconfig|4
arch/m32r/Kconfig|4
arch/m68k/Kconfig|4
arch/m68knommu/Kconfig |4
arch/mips/Kconfig|4
arch/parisc/Kconfig |4
arch/powerpc/Kconfig |4
arch/ppc/Kconfig |4
arch/s390/Kconfig|4
arch/sh64/Kconfig|4
arch/v850/Kconfig|3 +++
arch/xtensa/Kconfig |4
lib/Makefile |1 +
lib/udivdi3.c| 37 +
net/ipv4/tcp_cubic.c | 26 ++
net/netfilter/xt_connbytes.c | 19 +--
23 files changed, 116 insertions(+), 42 deletions(-)
--- pktgen.orig/net/ipv4/tcp_cubic.c2007-02-26 13:40:08.0 -0800
+++ pktgen/net/ipv4/tcp_cubic.c 2007-02-26 14:30:00.0 -0800
@@ -51,7 +51,6 @@
module_param(tcp_friendliness, int, 0644);
MODULE_PARM_DESC(tcp_friendliness, turn on/off tcp friendliness);
-#include asm/div64.h
/* BIC TCP Parameters */
struct bictcp {
@@ -93,27 +92,6 @@
tcp_sk(sk)-snd_ssthresh = initial_ssthresh;
}
-/* 64bit divisor, dividend and result. dynamic precision */
-static inline u_int64_t div64_64(u_int64_t dividend, u_int64_t divisor)
-{
- u_int32_t d = divisor;
-
- if (divisor 0xULL) {
- unsigned int shift = fls(divisor 32);
-
- d = divisor shift;
- dividend = shift;
- }
-
- /* avoid 64 bit division if possible */
- if (dividend 32)
- do_div(dividend, d);
- else
- dividend = (uint32_t) dividend / d;
-
- return dividend;
-}
-
/*
* calculate the cubic root of x using Newton-Raphson
*/
@@ -134,7 +112,7 @@
*/
do {
x1 = x;
- x = (2 * x + (uint32_t) div64_64(a, x*x)) / 3;
+ x = (2 * x + (u32) (a / x*x)) / 3;
} while (abs(x1 - x) 1);
return x;
--- pktgen.orig/net/netfilter/xt_connbytes.c2007-02-26 13:40:08.0
-0800
+++ pktgen/net/netfilter/xt_connbytes.c 2007-02-26 14:29:13.0 -0800
@@ -16,7 +16,6 @@
#include linux/netfilter/x_tables.h
#include linux/netfilter/xt_connbytes.h
-#include asm/div64.h
#include asm/bitops.h
MODULE_LICENSE(GPL);
@@ -24,22 +23,6 @@
MODULE_DESCRIPTION(iptables match for matching number of pkts/bytes per
connection);
MODULE_ALIAS(ipt_connbytes);
-/* 64bit divisor, dividend and result. dynamic precision */
-static u_int64_t div64_64(u_int64_t dividend, u_int64_t divisor)
-{
- u_int32_t d = divisor;
-
- if (divisor 0xULL) {
- unsigned int shift = fls(divisor 32);
-
- d = divisor shift;
- dividend = shift;
- }
-
- do_div(dividend, d);
- return dividend;
-}
-
static int
match(const struct sk_buff *skb,
const struct net_device *in,
@@ -106,7 +89,7 @@
break;
}
if (pkts != 0)
- what = div64_64(bytes, pkts);
+ what = bytes / pkts;
break;
}
--- pktgen.orig/lib/Makefile2007-02-26 13:40:08.0 -0800
+++ pktgen/lib/Makefile 2007-02-26 14:17:31.0 -0800
@@ -28,6 +28,7 @@
lib-$(CONFIG_SEMAPHORE_SLEEPERS) += semaphore-sleepers.o
lib-$(CONFIG_GENERIC_FIND_NEXT_BIT) += find_next_bit.o
obj-$(CONFIG_GENERIC_HWEIGHT) += hweight.o
+obj-$(CONFIG_GENERIC_UDIVDI3) += udivdi3.o
obj-$(CONFIG_LOCK_KERNEL) += kernel_lock.o
obj-$(CONFIG_PLIST) += plist.o
obj-$(CONFIG_DEBUG_PREEMPT) += smp_processor_id.o
--- pktgen.orig/arch/alpha/Kconfig 2007-02-26 13:51:29.0 -0800
+++ pktgen/arch/alpha/Kconfig 2007-02-26 13:54:35.0 -0800
@@ -33,6 +33,10 @@
bool
default n
+config GENERIC_UDIVDI3
+ bool
+ default y
+
config GENERIC_FIND_NEXT_BIT
bool
default y
--- pktgen.orig/arch/arm/Kconfig2007-02-26 13:51:29.0 -0800
+++ pktgen/arch/arm/Kconfig 2007-02-26 13:54:57.0 -0800
@@ -90,6 +90,10 @@
bool
default n
+config GENERIC_UDIVDI3
+ bool
+ default y
+
config GENERIC_HWEIGHT
bool
default y
--- pktgen.orig/arch/arm26/Kconfig 2007-02-26 13:48:46.0 -0800
+++ pktgen/arch/arm26/Kconfig 2007-02-26 13:55:24.0 -0800
@@ -49,6 +49,10 @@
bool
default n
+config GENERIC_UDIVDI3
+
Re: [RFC] div64_64 support
On Feb 26 2007 13:28, Stephen Hemminger wrote:
./arch/arm26/lib/udivdi3.c
./arch/sh/lib/udivdi3.c
./arch/sparc/lib/udivdi3.S
should not this be consolidated too?
Hmm. Those are the GCC internal versions, that are picked up but
doing divide in place. Do we want to allow general 64 bit in kernel to
be easily used? It could cause sloppy slow code, but it would look
cleaner.
Then our reviewers should catch it, and if not, the janitors will
(/me winks at R.P.J.Day and trivial@).
@@ -134,7 +112,7 @@
*/
do {
x1 = x;
- x = (2 * x + (uint32_t) div64_64(a, x*x)) / 3;
+ x = (2 * x + (u32) (a / x*x)) / 3;
Eye see a bug.
Previously there was div64_64(a, x*x) which is equivalent to
(a)/(x*x), or just: a/(x^2). But now you do a/x*x, which is
equivalent to a*x/x (in the domain of real numbers). Furthermore,
a/x*x is a-(a%x), which does not even remotely match a/(x^2).
Please keep the math intact, thank you ;-)
Jan
--
-
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/majordomo-info.html
Re: [BUG][2.6.21] af_key: kernel BUG at net/core/skbuff.c:93
From: Luca Tettamanti [EMAIL PROTECTED] Date: Mon, 26 Feb 2007 23:08:41 +0100 skb_over_panic: text:f1b8a065 len:16 put:16 head:b1a3ba00 data:b1a3ba00 tail:b1a 3ba00 end:b1a3ba90 dev:NULL This panic message doesn't make any sense, it should not have triggered. skb_put() calls skb_over_panic() when: if (unlikely(skb-tailskb-end)) skb_over_panic(skb, len, current_text_addr()); but from the panic message it says: tail:b1a3ba00 end:b1a3ba90 tail is certainly not greater than end. - 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/majordomo-info.html
Re: netconsole module cannot be removed
Stephen Hemminger wrote: On Mon, 26 Feb 2007 15:35:11 -0500 Chuck Ebbert [EMAIL PROTECTED] wrote: Trying to remove netconsole, rmmod goes into a tight loop with 100% CPU usage. It can't be killed with 'kill -9'. Shutdown works, though. Kernel is 2.6.20 FC6 config, and I'm 99.9% sure the module signing has nothing to do with this. No it probably has to do with printing a message during module removal. Works fine in 2.6.19.5 Hangs in vanilla 2.6.20 in netpoll_cleanup() Call trace: flush_cpu_workqueue flush_workqueue cancel_rearming_delayed_workqueue netpoll_cleanup sys_delete_module It varies, but is always in one of the first three functions when you do alt-sysrq-p. - 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/majordomo-info.html
Re: [PATCH 1/2][IPX] Remove outdated information from Kconfig
From: Rolf Eike Beer [EMAIL PROTECTED] Date: Tue, 20 Feb 2007 19:58:08 +0100 SPX was removed in early 2.5. How to connect to a Mac or the other OS isn't hard to find out these days. Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED] Patch applied, thanks Rolf. - 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/majordomo-info.html
Re: [PATCH 2/2][IPX] Remove ancient changelog
From: Rolf Eike Beer [EMAIL PROTECTED] Date: Tue, 20 Feb 2007 19:59:34 +0100 [IPX] Remove ancient changelog Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED] Also applied, thanks Rolf. - 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/majordomo-info.html
Re: [RFC] div64_64 support
On Feb 26 2007 15:44, Stephen Hemminger wrote: - x = (2 * x + (uint32_t) div64_64(a, x*x)) / 3; + x = (2 * x + (u32) (a / x*x)) / 3; Previously there was div64_64(a, x*x) which is equivalent to (a)/(x*x), or just: a/(x^2). But now you do a/x*x, which is equivalent to a*x/x (in the domain of real numbers). Furthermore, a/x*x is a-(a%x), which does not even remotely match a/(x^2). Been there, done that, don't want to repeat it... I am sorry I don't quite follow. Jan -- - 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/majordomo-info.html
Re: [RFC] div64_64 support
On Tue, 27 Feb 2007 01:05:26 +0100 (MET) Jan Engelhardt [EMAIL PROTECTED] wrote: On Feb 26 2007 15:44, Stephen Hemminger wrote: - x = (2 * x + (uint32_t) div64_64(a, x*x)) / 3; + x = (2 * x + (u32) (a / x*x)) / 3; Previously there was div64_64(a, x*x) which is equivalent to (a)/(x*x), or just: a/(x^2). But now you do a/x*x, which is equivalent to a*x/x (in the domain of real numbers). Furthermore, a/x*x is a-(a%x), which does not even remotely match a/(x^2). Been there, done that, don't want to repeat it... I am sorry I don't quite follow. Once before a missed paren's caused a TCP congestion window bug that took 6 months before it was found... -- Stephen Hemminger [EMAIL PROTECTED] - 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/majordomo-info.html
Re: [RFC] div64_64 support
On Feb 26 2007 16:07, Stephen Hemminger wrote: On Feb 26 2007 15:44, Stephen Hemminger wrote: -x = (2 * x + (uint32_t) div64_64(a, x*x)) / 3; +x = (2 * x + (u32) (a / x*x)) / 3; Previously there was div64_64(a, x*x) which is equivalent to (a)/(x*x), or just: a/(x^2). But now you do a/x*x, which is equivalent to a*x/x (in the domain of real numbers). Furthermore, a/x*x is a-(a%x), which does not even remotely match a/(x^2). Been there, done that, don't want to repeat it... I am sorry I don't quite follow. Once before a missed paren's caused a TCP congestion window bug that took 6 months before it was found... Hah, just as I expected. |On Tue, 27 Feb 2007 00:02:50 +0100 (MET), Jan Engelhardt wrote: |Then our reviewers should catch it, and if not, the janitors will. Jan -- - 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/majordomo-info.html
Re: [PATCH 7/7] cxgb3 - Add SW LRO support
Christoph Hellwig wrote: On Sat, Feb 24, 2007 at 04:44:23PM -0800, [EMAIL PROTECTED] wrote: From: Divy Le Ray [EMAIL PROTECTED] Add all-in-sw lro support. Doing this in a LLDD doesn't sound like a good idea. Have you tried doing this in the core networking code instead? We have not tried to implement LRO in the core networking code. Today, the available API for a driver to pass packets up is netif_receive_skb/netif_rx. Our implementation coalesces pages, then gets a skb to point at the pages and passes it up to the stack. LRO in the core networking code would require adding methods to pass up data segments in addition to skbs. HW might also be able to assist LRO by identifying the session an incoming packet belongs to, thus avoiding the session lookup. The API should also allow for the driver to indicate such info. Cheers, Divy - 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/majordomo-info.html
Re: [PATCH 1/2] NET: Multiple queue network device support
From: Kok, Auke [EMAIL PROTECTED] Date: Thu, 08 Feb 2007 16:09:50 -0800 From: Peter Waskiewicz Jr [EMAIL PROTECTED] Added an API and associated supporting routines for multiqueue network devices. This allows network devices supporting multiple TX queues to configure each queue within the netdevice and manage each queue independantly. Changes to the PRIO Qdisc also allow a user to map multiple flows to individual TX queues, taking advantage of each queue on the device. Signed-off-by: Peter Waskiewicz Jr [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] Thanks for posting this. I was wonding if it would be better to have the -enqueue() perform the mapping operation, store the queue index selected inside of the skb, and just use the normal -hard_start_xmit() to send the packet out? The only thing to take care of is the per-queue locking, but that should be easily doable. We might be able to do this even without making sk_buff any larger. For example, I suppose skb-priority might be deducable down to a u16. After a quick audit I really cannot see any legitimate use of anything larger than 16-bit values, but a more thorough audit would be necessary to validate this. - 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/majordomo-info.html
Re: [RFC] div64_64 support
Stephen Hemminger wrote: Hmm. Those are the GCC internal versions, that are picked up but doing divide in place. Do we want to allow general 64 bit in kernel to be easily used? It could cause sloppy slow code, but it would look cleaner. ... and it would handle datatypes which may be architecture-dependent a lot cleaner. I thought the motivation for div64() was that a 64:32-32 divide could be done a lot faster on a number of platforms (including the important x86) than a generic 64:64-64 divide, but gcc doesn't handle the devolution automatically -- there is no such libgcc function. -hpa - 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/majordomo-info.html
Re: [PATCH] netxen: do_rom_fast_write error handling
Ah.. missed that.
Thanks.
-Amit
On Tuesday 27 February 2007 04:21, Stephen Hemminger wrote:
Compiler warning spots real error!
The function do_rom_fast_read called in do_rom_fast_write can fail
and leave data1 unset. This causes a compile warning.
The correct thing is to propagate the error out.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic_init.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- pktgen.orig/drivers/net/netxen/netxen_nic_init.c 2007-02-26
14:45:46.0 -0800 +++
pktgen/drivers/net/netxen/netxen_nic_init.c 2007-02-26 14:46:37.0
-0800 @@ -499,7 +499,10 @@
while(1) {
int data1;
- do_rom_fast_read(adapter, addridx, data1);
+ ret = do_rom_fast_read(adapter, addridx, data1);
+ if (ret 0)
+ return ret;
+
if (data1 == data)
break;
-
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/majordomo-info.html
Re: [RFC] div64_64 support
I thought the motivation for div64() was that a 64:32-32 divide could be done a lot faster on a number of platforms (including the important x86) than a generic 64:64-64 divide, but gcc doesn't handle the devolution automatically -- there is no such libgcc function. That there's no such function in libgcc doesn't mean GCC cannot handle this; libgcc is a bunch of library functions that are really needed for generated code (because you really don't want to expand those functions inline everywhere) -- you won't find an addsi3 in libgcc either. There does exist a divmoddisi4, sort of. It used to be defined in three GCC targets, but commented out in all three. The NS32k is long gone. For Vax, a comment says the machine insn for this isn't used because it is just too slow. And the i386 version is disabled because it returns the wrong result on overflow (not the truncated 64-bit result, required by the implicit cast to 32-bit, but the i386 arch traps to the overflow handler). The only way to express the semantics you want in (GNU) C is to use asm() -- and that's exactly what div64() does :-) Blame it on the C language, but not on GCC. Not this time. Segher - 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/majordomo-info.html
Re: [RFC] div64_64 support
On 2/26/07, Stephen Hemminger [EMAIL PROTECTED] wrote: Here is another way to handle the 64 bit divide case. It allows full 64 bit divide by adding the support routine GCC needs. snip I know ARM already went through the process of removing __udivdi3 support: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=2723/2 Copying Russell and Nicolas as a heads up. -- Dan - 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/majordomo-info.html
