Re: [NETPOLL] netconsole: fix soft lockup when removing module
On Sun, Jul 01, 2007 at 09:35:58PM +0400, Oleg Nesterov wrote:
Jarek Poplawski wrote:
#1
Until kernel ver. 2.6.21 (including) cancel_rearming_delayed_work()
required a work function should always (unconditionally) rearm with
delay 0 - otherwise it would endlessly loop. This patch replaces
this function with cancel_delayed_work(). Later kernel versions don't
require this, so here it's only for uniformity.
But 2.6.22 doesn't need this change, why it was merged?
One bad reason is given above. Should I look for another one?
In fact, I suspect this change adds a race,
You are right!
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -72,7 +72,8 @@ static void queue_process(struct work_struct *work)
netif_tx_unlock(dev);
local_irq_restore(flags);
- schedule_delayed_work(npinfo-tx_work, HZ/10);
+ if (atomic_read(npinfo-refcnt))
+ schedule_delayed_work(npinfo-tx_work, HZ/10);
return;
}
netif_tx_unlock(dev);
@@ -785,9 +786,15 @@ void netpoll_cleanup(struct netpoll *np)
if (atomic_dec_and_test(npinfo-refcnt)) {
skb_queue_purge(npinfo-arp_tx);
skb_queue_purge(npinfo-txq);
- cancel_rearming_delayed_work(npinfo-tx_work);
+ cancel_delayed_work(npinfo-tx_work);
flush_scheduled_work();
Suppose that -refcnt == 1, and queue_process() was preempted just after
atomic_read(npinfo-refcnt).
netpoll_cleanup() comes, cancel_delayed_work() does nothing,
flush_scheduled_work()
sleeps.
queue_process() gets CPU, re-schedules -tx_work, and returns.
flush_scheduled_work() completes, netpoll_cleanup() frees npinfo and returns
while -tx_work is pending.
No?
No no. (Yes!)
I had some doubts about this, and you found very good reason
for this.
I'll soon send a patch to restore cancel_rearming_delayed_work
in 2.6.22.
So, 2.6.21 needs something better (maybe you've found it btw.?),
but they weren't too interested, anyway.
Thanks very much regards,
Jarek 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
[PATCH] Re: [NETPOLL] netconsole: fix soft lockup when removing module
From my recent patch:
#1
Until kernel ver. 2.6.21 (including) cancel_rearming_delayed_work()
required a work function should always (unconditionally) rearm with
delay 0 - otherwise it would endlessly loop. This patch replaces
this function with cancel_delayed_work(). Later kernel versions don't
require this, so here it's only for uniformity.
But Oleg Nesterov [EMAIL PROTECTED] found:
But 2.6.22 doesn't need this change, why it was merged?
In fact, I suspect this change adds a race,
...
His description was right (thanks), so this patch reverts #1.
Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
---
diff -Nurp 2.6.22-rc7-/net/core/netpoll.c 2.6.22-rc7/net/core/netpoll.c
--- 2.6.22-rc7-/net/core/netpoll.c 2007-07-02 09:03:27.0 +0200
+++ 2.6.22-rc7/net/core/netpoll.c 2007-07-02 09:32:34.0 +0200
@@ -72,8 +72,7 @@ static void queue_process(struct work_st
netif_tx_unlock(dev);
local_irq_restore(flags);
- if (atomic_read(npinfo-refcnt))
- schedule_delayed_work(npinfo-tx_work, HZ/10);
+ schedule_delayed_work(npinfo-tx_work, HZ/10);
return;
}
netif_tx_unlock(dev);
@@ -786,7 +785,7 @@ void netpoll_cleanup(struct netpoll *np)
if (atomic_dec_and_test(npinfo-refcnt)) {
skb_queue_purge(npinfo-arp_tx);
skb_queue_purge(npinfo-txq);
- cancel_delayed_work(npinfo-tx_work);
+ cancel_rearming_delayed_work(npinfo-tx_work);
flush_scheduled_work();
/* clean after last, unfinished work */
-
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: quirk_e100_interrupt() called too early
Bjorn Helgaas wrote: On Thursday 28 June 2007 10:01:08 am Kok, Auke wrote: I copied Nils Rennebarth, who originally reported the bug: http://bugzilla.kernel.org/show_bug.cgi?id=5918 in case he can test your patch. Most of the embedded boards we now work with appear to exhibit the same behaviour: During boot the Firmware left :01:05.0 e100 interrupts enabled, disabling message appears for all four e100 nics. (The mainboard is a em-8510A btw.) When I have time I could try if the quirk still works with the mentioned patch, but I am quite busy with other things at the moment. -- Mit freundlichen Grüßen / with kind regards Nils Rennebarth, Software Developer -- Funkwerk IP-Appliances GmbH Mönchhaldenstraße 28 D-70191 Stuttgart Tel: +49 711 900300 - 0 Fax: +49 711 900300 - 90 E-Mail: [EMAIL PROTECTED] Location: GmbH Neu-Ulm, Local Court Memmingen, HRB 13043 Managing Directors: Michael Marsanu, Soenke Weisner The information contained in this e-mail has been carefully researched, but the possibility of it being inapplicable in individual cases cannot be ruled out. We therefore regret that we cannot accept responsibility or liability of any kind whatsoever for the correctness of the information given. Please notify us if you discover that information is inapplicable. - 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: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
On Sat, 2007-06-30 at 11:32 -0400, jamal wrote:
+static void genl_unregister_mc_group(struct genl_multicast_group *grp)
+{
+ /*
+* TODO: fix multicast group re-use by clearing the bit
+* for this group in all genetlink sockets.
+*/
+ clear_bit(grp-id, mc_groups);
+ list_del(grp-list);
I think you need a
genl_ctrl_event(CTRL_CMD_DELMCAST_GRP, family);
here? You may need to save the mcast details before you delete.
I will, but not currently because right now mcast groups are only
deleted when the family is dropped.
+ NLA_PUT_U32(skb, CTRL_ATTR_MCAST_GRP_ID, grp-id);
+ NLA_PUT_STRING(skb, CTRL_ATTR_MCAST_GRP_NAME,
+ grp-name);
+
Consider my earlier suggestion to use CTRL_ATTR_MCAST_GRP which has both
id and name in one struct.
Yeah I thought about that but then saw Patrick's patches to convert
other things away from structs so I wasn't sure what the idea here is.
Patrick, care to comment?
Other than that - looking good.
:)
johannes
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] Re: [NETPOLL] netconsole: fix soft lockup when removing module
On 07/02, Jarek Poplawski wrote:
diff -Nurp 2.6.22-rc7-/net/core/netpoll.c 2.6.22-rc7/net/core/netpoll.c
--- 2.6.22-rc7-/net/core/netpoll.c2007-07-02 09:03:27.0 +0200
+++ 2.6.22-rc7/net/core/netpoll.c 2007-07-02 09:32:34.0 +0200
@@ -72,8 +72,7 @@ static void queue_process(struct work_st
netif_tx_unlock(dev);
local_irq_restore(flags);
- if (atomic_read(npinfo-refcnt))
- schedule_delayed_work(npinfo-tx_work, HZ/10);
+ schedule_delayed_work(npinfo-tx_work, HZ/10);
return;
}
netif_tx_unlock(dev);
@@ -786,7 +785,7 @@ void netpoll_cleanup(struct netpoll *np)
if (atomic_dec_and_test(npinfo-refcnt)) {
skb_queue_purge(npinfo-arp_tx);
skb_queue_purge(npinfo-txq);
- cancel_delayed_work(npinfo-tx_work);
+ cancel_rearming_delayed_work(npinfo-tx_work);
flush_scheduled_work();
While you are here, could you also delete this flush_scheduled_work() ?
It is not needed any longer.
Oleg.
-
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: [NETPOLL] netconsole: fix soft lockup when removing module
On 07/02, Jarek Poplawski wrote:
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -72,7 +72,8 @@ static void queue_process(struct work_struct *work)
netif_tx_unlock(dev);
local_irq_restore(flags);
- schedule_delayed_work(npinfo-tx_work, HZ/10);
+ if (atomic_read(npinfo-refcnt))
+ schedule_delayed_work(npinfo-tx_work, HZ/10);
return;
}
[...snip...]
So, 2.6.21 needs something better (maybe you've found it btw.?),
but they weren't too interested, anyway.
We can do a double flush trick. If queue_process() checks -refcnt before
schedule_delayed_work() like above, netpoll_cleanup() can do
flush_scheduled_work();
// the next invocation of queue_process()
// must see -refcnt == 0
if (!cancel_delayed_work(npinfo-tx_work)) {
/* may be queued, wait for completion */
flush_scheduled_work();
}
Jarek, I don't understand net/, a silly question. Why do we need the #2 chunk?
Isn't it better to move skb_queue_purge(npinfo-txq) after cancel_..._work()
instead?
Oleg.
-
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 2/2][NETPOLL] netconsole: delete flush_scheduled_work
On Mon, Jul 02, 2007 at 12:59:49PM +0400, Oleg Nesterov wrote:
...
While you are here, could you also delete this flush_scheduled_work() ?
It is not needed any longer.
Yes. I've thought about this, and even planned to mention, but then
forgotten... Of course, you are right, but since it stayed so long
and doesn't seem to be dangerous, and there is -rc7 I wasn't so brave.
But now I have an explanation...
Jarek P.
--
Subject: [PATCH][NETPOLL] netconsole: delete flush_scheduled_work
flush_scheduled_work() isn't needed after cancel_rearming_delayed_work(),
so here it's removed from netpoll_cleanup().
PS: This patch was prepared on 2.6.22-rc7 with my other today's patch:
netconsole: fix soft lockup ...
Noticed-by: Oleg Nesterov [EMAIL PROTECTED]
Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
---
diff -Nurp 2.6.22-rc7-plus-revert1-/net/core/netpoll.c
2.6.22-rc7-plus-revert1/net/core/netpoll.c
--- 2.6.22-rc7-plus-revert1-/net/core/netpoll.c 2007-07-02 09:32:34.0
+0200
+++ 2.6.22-rc7-plus-revert1/net/core/netpoll.c 2007-07-02 11:43:29.0
+0200
@@ -786,7 +786,6 @@ void netpoll_cleanup(struct netpoll *np)
skb_queue_purge(npinfo-arp_tx);
skb_queue_purge(npinfo-txq);
cancel_rearming_delayed_work(npinfo-tx_work);
- flush_scheduled_work();
/* clean after last, unfinished work */
if (!skb_queue_empty(npinfo-txq)) {
-
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: sky2 hangs without any messages
Hi Stephen, Tino Keitel [EMAIL PROTECTED] wrote: in the last 2 days, I had 2 outages of the NIC of my Mac mini Core Duo. I checked the kernel log but I found nothing sky2 related. After reloading the module, the interface worked again. There is a reproducible hang (due to missed IRQ) in sky2. It is more reproducible with slower CPU's like Mac Mini. This feels like the same problem I hit once every ~2 days on my server platform or laptop [1]: both Yukon-ECs, rev 1 and 2, running NFSv4 over TCP over a gig-e switch, ia32, PCI-E. Observations: 1. problem happens with both rev-1 and 2 Yukon-ECs, so less likely a silicon bug 2. reproducible with 1500 MTU on both ends 3. reproducible with and without receive offloading disabled (ie 'ethtool -K gig0 rx off') [check with tx offload too?] 4. reproducible with two different gig-e switches and different cables 5. reproducible with MSI interrupts [check with legacy interrupts?] Is there anything that I can do to help debug this missing IRQ hang? I'm thinking of moving to the vendor driver [2] to see if the issue is entirely avoidable in software. Thanks, Daniel --- [1] sky2 :02:00.0: v1.14 addr 0xd600 irq 16 Yukon-EC (0xb6) rev 2 sky2 gig0: addr 00:16:b6:70:d8:3d sky2 gig0: enabling interface sky2 gig0: ram buffer 48K sky2 gig0: Link is up at 1000 Mbps, full duplex, flow control both NFS hang observed NETDEV WATCHDOG: gig0: transmit timed out sky2 gig0: tx timeout sky2 gig0: transmit ring 424 .. 401 report=427 done=427 sky2 gig0: disabling interface sky2 gig0: enabling interface sky2 gig0: ram buffer 48K sky2 gig0: Link is up at 1000 Mbps, full duplex, flow control both NFS resumes after a few minutes $ grep gig0 /proc/interrupts 218: 27297 0 PCI-MSI-edge gig0 --- [2] http://www.syskonnect.de/e_en/products/adapters/pcie_server/sk-9exx/software/linux/driver/install-8_31.tar.bz2 -- Daniel J Blueman - 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: r8169 2.2LK: Low link speed after suspend
Francois Romieu wrote: Francois Romieu [EMAIL PROTECTED] : [...] The patch will not apply directly against 2.6.21.5. Is it an option for you to try 2.6.22-rc6 or are you stuck with 2.6.21.5 ? If you feel adventurous, you will find a compile-tested-only patchkit for 2.6.21.5 here: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.21.5 or: http://www.fr.zoreil.com/people/francois/misc/20060630-2.6.21.5-r8169-test.patch The content should be almost the same as the 2.6.22-rc6 patchkit dated from 2007/06/28 (i.e. pending 2.6.23 merge). Wow, great; I applied it to the kernel build this morning; in itself, it does not stop the blocking behavior from happening. But I will try to add the patch I mentioned in the previous messages of which you said it shouldn't be used without applying the patchset first. greets, jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion - 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: [NETPOLL] netconsole: fix soft lockup when removing module
On Mon, Jul 02, 2007 at 01:24:08PM +0400, Oleg Nesterov wrote:
On 07/02, Jarek Poplawski wrote:
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -72,7 +72,8 @@ static void queue_process(struct work_struct *work)
netif_tx_unlock(dev);
local_irq_restore(flags);
- schedule_delayed_work(npinfo-tx_work, HZ/10);
+ if (atomic_read(npinfo-refcnt))
+ schedule_delayed_work(npinfo-tx_work,
HZ/10);
return;
}
[...snip...]
So, 2.6.21 needs something better (maybe you've found it btw.?),
but they weren't too interested, anyway.
We can do a double flush trick. If queue_process() checks -refcnt before
schedule_delayed_work() like above, netpoll_cleanup() can do
flush_scheduled_work();
// the next invocation of queue_process()
// must see -refcnt == 0
if (!cancel_delayed_work(npinfo-tx_work)) {
/* may be queued, wait for completion */
flush_scheduled_work();
}
I'll try to think about it later, but I don't plan to do next patch,
so feel free to send this. I didn't plan to fix netpoll at all
(I never didn't use nor studied this before...). But couldn't stand
this stupid lockup stays in 2.6.21. Now, I see it probably doesn't
annoy more than 2 or 3 people around...
Jarek, I don't understand net/, a silly question. Why do we need the #2 chunk?
Isn't it better to move skb_queue_purge(npinfo-txq) after cancel_..._work()
instead?
I've thought about this too, but because I don't know netpoll/netconsole
enough I didn't want to change more than minimum needed.
skb_queue_purge() uses heavy locking (irqsave) and I don't remember now
if I've found the reason or simply believed somebody had to have a reason
to do this there, anyway, if moved after cancel_ it could be done without
this locking, and something like while () instead of my if () should be
enough.
But there was not much interest about this patch, and I'm not currently
interested to be the main netconsole expert too, so maybe you would
like to try...
Cheers,
Jarek 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: r8169 2.2LK: Low link speed after suspend
Jens Stroebel wrote: Francois Romieu wrote: Francois Romieu [EMAIL PROTECTED] : [...] The patch will not apply directly against 2.6.21.5. Is it an option for you to try 2.6.22-rc6 or are you stuck with 2.6.21.5 ? If you feel adventurous, you will find a compile-tested-only patchkit for 2.6.21.5 here: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.21.5 or: http://www.fr.zoreil.com/people/francois/misc/20060630-2.6.21.5-r8169-test.patch The content should be almost the same as the 2.6.22-rc6 patchkit dated from 2007/06/28 (i.e. pending 2.6.23 merge). Wow, great; I applied it to the kernel build this morning; in itself, it does not stop the blocking behavior from happening. But I will try to add the patch I mentioned in the previous messages of which you said it shouldn't be used without applying the patchset first. Still the same hard-lockup behavior (with the patch mentioned before, which is not part of your patchset but remedies the blocking) as without your patchkit applied first. greets, drifter -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion - 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/RESENT] ehea: Whitespace cleanup
This patch fixes several whitespace issues.
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index c0f81b5..abaf3ac 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0064
+#define DRV_VERSIONEHEA_0065
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -136,10 +136,10 @@ void ehea_dump(void *adr, int len, char *msg);
(0xULL ((64 - (mask)) 0x))
#define EHEA_BMASK_SET(mask, value) \
-((EHEA_BMASK_MASK(mask) ((u64)(value))) EHEA_BMASK_SHIFTPOS(mask))
+ ((EHEA_BMASK_MASK(mask) ((u64)(value))) EHEA_BMASK_SHIFTPOS(mask))
#define EHEA_BMASK_GET(mask, value) \
-(EHEA_BMASK_MASK(mask) (((u64)(value)) EHEA_BMASK_SHIFTPOS(mask)))
+ (EHEA_BMASK_MASK(mask) (((u64)(value)) EHEA_BMASK_SHIFTPOS(mask)))
/*
* Generic ehea page
@@ -190,7 +190,7 @@ struct ehea_av;
* Queue attributes passed to ehea_create_qp()
*/
struct ehea_qp_init_attr {
-/* input parameter */
+ /* input parameter */
u32 qp_token; /* queue token */
u8 low_lat_rq1;
u8 signalingtype; /* cqe generation flag */
@@ -212,7 +212,7 @@ struct ehea_qp_init_attr {
u64 recv_cq_handle;
u64 aff_eq_handle;
-/* output parameter */
+ /* output parameter */
u32 qp_nr;
u16 act_nr_send_wqes;
u16 act_nr_rwqes_rq1;
@@ -279,12 +279,12 @@ struct ehea_qp {
* Completion Queue attributes
*/
struct ehea_cq_attr {
-/* input parameter */
+ /* input parameter */
u32 max_nr_of_cqes;
u32 cq_token;
u64 eq_handle;
-/* output parameter */
+ /* output parameter */
u32 act_nr_of_cqes;
u32 nr_pages;
};
diff --git a/drivers/net/ehea/ehea_hw.h b/drivers/net/ehea/ehea_hw.h
index 1246757..1af7ca4 100644
--- a/drivers/net/ehea/ehea_hw.h
+++ b/drivers/net/ehea/ehea_hw.h
@@ -211,34 +211,34 @@ static inline void epa_store_acc(struct h_epa epa, u32
offset, u64 value)
}
#define epa_store_eq(epa, offset, value)\
-epa_store(epa, EQTEMM_OFFSET(offset), value)
+ epa_store(epa, EQTEMM_OFFSET(offset), value)
#define epa_load_eq(epa, offset)\
-epa_load(epa, EQTEMM_OFFSET(offset))
+ epa_load(epa, EQTEMM_OFFSET(offset))
#define epa_store_cq(epa, offset, value)\
-epa_store(epa, CQTEMM_OFFSET(offset), value)
+ epa_store(epa, CQTEMM_OFFSET(offset), value)
#define epa_load_cq(epa, offset)\
-epa_load(epa, CQTEMM_OFFSET(offset))
+ epa_load(epa, CQTEMM_OFFSET(offset))
#define epa_store_qp(epa, offset, value)\
-epa_store(epa, QPTEMM_OFFSET(offset), value)
+ epa_store(epa, QPTEMM_OFFSET(offset), value)
#define epa_load_qp(epa, offset)\
-epa_load(epa, QPTEMM_OFFSET(offset))
+ epa_load(epa, QPTEMM_OFFSET(offset))
#define epa_store_qped(epa, offset, value)\
-epa_store(epa, QPEDMM_OFFSET(offset), value)
+ epa_store(epa, QPEDMM_OFFSET(offset), value)
#define epa_load_qped(epa, offset)\
-epa_load(epa, QPEDMM_OFFSET(offset))
+ epa_load(epa, QPEDMM_OFFSET(offset))
#define epa_store_mrmw(epa, offset, value)\
-epa_store(epa, MRMWMM_OFFSET(offset), value)
+ epa_store(epa, MRMWMM_OFFSET(offset), value)
#define epa_load_mrmw(epa, offset)\
-epa_load(epa, MRMWMM_OFFSET(offset))
+ epa_load(epa, MRMWMM_OFFSET(offset))
#define epa_store_base(epa, offset, value)\
-epa_store(epa, HCAGR_OFFSET(offset), value)
+ epa_store(epa, HCAGR_OFFSET(offset), value)
#define epa_load_base(epa, offset)\
-epa_load(epa, HCAGR_OFFSET(offset))
+ epa_load(epa, HCAGR_OFFSET(offset))
static inline void ehea_update_sqa(struct ehea_qp *qp, u16 nr_wqes)
{
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 9e13433..bdb5241 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -81,7 +81,7 @@ MODULE_PARM_DESC(use_mcs, 0:NAPI, 1:Multiple receive
queues, Default = 1 );
static int port_name_cnt = 0;
static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
-const struct of_device_id *id);
+ const struct of_device_id *id);
static int __devexit ehea_remove(struct ibmebus_dev *dev);
@@ -236,7 +236,7 @@ static int ehea_refill_rq_def(struct ehea_port_res *pr,
rwqe = ehea_get_next_rwqe(qp, rq_nr);
rwqe-wr_id = EHEA_BMASK_SET(EHEA_WR_ID_TYPE, wqe_type)
- | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
+ | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
rwqe-sg_list[0].l_key = pr-recv_mr.lkey;
rwqe-sg_list[0].vaddr =
Re: Please pull 'libertas-fixes' branch of wireless-2.6
John W. Linville wrote: The following changes since commit 189548642c5962e60c3667bdb3a703fe0bed12a6: Linus Torvalds (1): Linus 2.6.22-rc6 are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git libertas-fixes Dan Williams (4): libertas: style fixes libertas: kill wlan_scan_process_results libertas: fix WPA associations by handling ENABLE_RSN correctly libertas: remove private ioctls drivers/net/wireless/libertas/Makefile |2 +- drivers/net/wireless/libertas/README| 275 drivers/net/wireless/libertas/assoc.c | 28 +- drivers/net/wireless/libertas/cmd.c | 12 +- drivers/net/wireless/libertas/cmdresp.c | 21 + drivers/net/wireless/libertas/hostcmd.h |2 +- drivers/net/wireless/libertas/ioctl.c | 1081 --- drivers/net/wireless/libertas/main.c|8 +- drivers/net/wireless/libertas/scan.c| 51 +-- drivers/net/wireless/libertas/wext.c| 152 - drivers/net/wireless/libertas/wext.h| 45 +-- 11 files changed, 79 insertions(+), 1598 deletions(-) delete mode 100644 drivers/net/wireless/libertas/ioctl.c pulled - 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: Please pull from 'from_linus' branch
Kumar Gala wrote: Please pull from 'for_linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_linus to receive the following updates: drivers/net/gianfar.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Kumar Gala (1): gianfar: Fix typo bug introduced by move to udp_hdr() pulled - 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.6.22 2/4]S2IO: Removing MSI support from the driver
Veena Parat wrote: 1.Removed MSI support from driver - unused feature 2.Removed pci_request_regions call to allocate bar2 as it is not used in driver 3.Removed pci_release_regions since pci_request_regions is not done This is wrong. pci_request_regions() grabs all the regions for the associated PCI device, which is the desired behavior. Using request_mem_region() is not what you want to do for PCI devices. - 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.6.22 1/4]S2IO: Adding checks to check the return value of pci mapping function
Veena Parat wrote:
Adding checks to check the return value of pci mapping function
Signed-off-by: Veena Parat [EMAIL PROTECTED]
---
diff -urpN org/drivers/net/s2io.c patch_1/drivers/net/s2io.c
--- org/drivers/net/s2io.c 2007-05-17 20:35:39.0 +0530
+++ patch_1/drivers/net/s2io.c 2007-05-17 20:35:55.0 +0530
@@ -282,6 +282,7 @@ static char ethtool_driver_stats_keys[][
(lro_flush_due_to_max_pkts),
(lro_avg_aggr_pkts),
(mem_alloc_fail_cnt),
+ {pci_map_fail_cnt},
(watchdog_timer_cnt),
(mem_allocated),
(mem_freed),
@@ -2247,10 +2248,19 @@ static int fill_rxd_3buf(struct s2io_nic
(nic-pdev, skb-data, l3l4hdr_size + 4,
PCI_DMA_FROMDEVICE);
+ if struct RxD3*)rxdp)-Buffer1_ptr == 0) ||
+ (((struct RxD3*)rxdp)-Buffer1_ptr == DMA_ERROR_CODE)) {
+ nic-mac_control.stats_info-sw_stat.pci_map_fail_cnt++;
+ return -ENOMEM;
+ }
+
/* skb_shinfo(skb)-frag_list will have L4 data payload */
skb_shinfo(skb)-frag_list = dev_alloc_skb(dev-mtu + ALIGN_SIZE);
if (skb_shinfo(skb)-frag_list == NULL) {
nic-mac_control.stats_info-sw_stat.mem_alloc_fail_cnt++;
+ pci_unmap_single
+ (nic-pdev, (dma_addr_t)skb-data, l3l4hdr_size + 4,
+ PCI_DMA_FROMDEVICE);
DBG_PRINT(INFO_DBG, %s: dev_alloc_skb failed\n , dev-name);
return -ENOMEM ;
}
@@ -2267,6 +2277,11 @@ static int fill_rxd_3buf(struct s2io_nic
((struct RxD3*)rxdp)-Buffer2_ptr = pci_map_single(nic-pdev,
frag_list-data, dev-mtu,
PCI_DMA_FROMDEVICE);
+ if struct RxD3*)rxdp)-Buffer2_ptr == 0) ||
+ (((struct RxD3*)rxdp)-Buffer2_ptr == DMA_ERROR_CODE)) {
+ nic-mac_control.stats_info-sw_stat.pci_map_fail_cnt++;
+ return -ENOMEM;
+ }
rxdp-Control_2 |= SET_BUFFER1_SIZE_3(l3l4hdr_size + 4);
rxdp-Control_2 |= SET_BUFFER2_SIZE_3(dev-mtu);
@@ -2399,6 +2414,16 @@ static int fill_rx_buffers(struct s2io_n
((struct RxD1*)rxdp)-Buffer0_ptr = pci_map_single
(nic-pdev, skb-data, size - NET_IP_ALIGN,
PCI_DMA_FROMDEVICE);
+ if struct RxD1*)rxdp)-Buffer0_ptr == 0) ||
+(((struct RxD1*)rxdp)-Buffer0_ptr ==
+DMA_ERROR_CODE)) {
+ nic-mac_control.stats_info-sw_stat.
+ pci_map_fail_cnt++;
+ nic-mac_control.stats_info-sw_stat.mem_freed
+ += skb-truesize;
+ dev_kfree_skb_irq(skb);
+ return -ENOMEM;
+ }
rxdp-Control_2 =
SET_BUFFER0_SIZE_1(size - NET_IP_ALIGN);
please provide a prep patch that eliminates all these inline casts.
Create temporary variables or whatever you need to do to convert the
messy and unreadable (((struct RxD1*)rxdp)-Buffer0_ptr into
desc-Buffer0_ptr.
otherwise looks OK
-
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] myri10ge: SET_NETDEV_DEV()
Maik Hampel wrote: SET_NETDEV_DEV() in myri10ge to create the /sys/class/net/if/device symlink. Signed-off-by: Maik Hampel [EMAIL PROTECTED] applied - 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] starfire list alpha as 64 bit arch
maximilian attems wrote: instead of: This driver has not been ported to this 64-bit architecture yet. the driver is said to work on alpha, see http://bugs.debian.org/305330 Signed-off-by: maximilian attems [EMAIL PROTECTED] applied - 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] dm9601: HW header size shouldn't be included in packet length
Peter Korsgaard wrote: The dm9601 driver was including the 2 byte hardware header in the packet length, causing the HW to send 2 extra bytes of garbage on tx. Signed-off-by: Peter Korsgaard [EMAIL PROTECTED] --- drivers/net/usb/dm9601.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) applied - 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] usbnet: Zero padding byte if there is tail room in skb
Peter Korsgaard wrote: Usbnet adds a padding byte if a 0 byte USB packet would be sent. Zero padding byte if there is tail room in skb. Signed-of-by: Peter Korsgaard [EMAIL PROTECTED] Acked-by: David Brownell [EMAIL PROTECTED] --- drivers/net/usb/usbnet.c |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) applied - 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] Update MAINTAINERS for USB network devices
Peter Korsgaard wrote: Greg == Greg KH [EMAIL PROTECTED] writes: Greg Yeah, this is the cdc_acm driver that is still in the USB drivers/ Greg directory tree as it is a USB class driver that shows up as a tty device Greg to userspace. It should not be moved to the networking list unless no Greg one minds that I never see any queries about it :) Ok, here's an updated patch: Questions regarding the USB network drivers should now go to netdev. Signed-off-by: Peter Korsgaard [EMAIL PROTECTED] Acked-by: David Brownell [EMAIL PROTECTED] applied - 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] dm9601: Return 0 from bind() on success
Peter Korsgaard wrote: Fixup dm9601_bind() so it returns 0 on success rather than just a positive number, as otherwise usbnet doesn't init the status handler. Signed-off-by: Peter Korsgaard [EMAIL PROTECTED] --- drivers/net/usb/dm9601.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) applied - 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: RESEND [PATCH 1/3] NetXen: Fix issue of MSI not working correctly
[EMAIL PROTECTED] wrote: NetXen driver uses PCI function 0 to provide the functionality of MSI. The patch makes driver check the bus master bit for function 0 and enable it after the card initialization. Signed-off-by: Dhananjay Phadke[EMAIL PROTECTED] Signed-off-by: Milan Bag [EMAIL PROTECTED] Signed-off-by: Wen Xiong [EMAIL PROTECTED] applied patch #1 and #2 (dated July 1, 2:55PM) applied patch #3 (dated July 2, 12:07 AM) - 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 patch] drivers/net/ns83820.c: fix a check-after-use
Adrian Bunk wrote: This patch fixes a check-after-use spotted by the Coverity checker. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] applied - 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] ps3: gigabit ethernet driver for PS3, take2
MOKUNO Masakazu wrote: Hi, This is the second submission of the network driver for PS3. This version have been updated to address issues raised in the review. Please apply for 2.6.23. From: Masakazu Mokuno [EMAIL PROTECTED] Add Gigabit Ethernet support for the PS3 game console. The module will be called ps3_gelic. CC: Geoff Levand [EMAIL PROTECTED] Signed-off-by: Masakazu Mokuno [EMAIL PROTECTED] --- MAINTAINERS |6 drivers/net/Kconfig | 10 drivers/net/Makefile|2 drivers/net/gelic_net.c | 1578 drivers/net/gelic_net.h | 241 +++ 5 files changed, 1837 insertions(+) --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2920,6 +2920,12 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] S: Maintained +PS3 NETWORK SUPPORT +P: Masakazu Mokuno +M: [EMAIL PROTECTED] +L: netdev@vger.kernel.org +S: Supported + PS3 PLATFORM SUPPORT P: Geoff Levand M: [EMAIL PROTECTED] --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2264,6 +2264,16 @@ config TSI108_ETH To compile this driver as a module, choose M here: the module will be called tsi108_eth. +config GELIC_NET + tristate PS3 Gigabit Ethernet driver + depends on PPC_PS3 + help + This driver supports the network device on the PS3 game + console. This driver has built-in support for Ethernet. + + To compile this driver as a module, choose M here: the + module will be called ps3_gelic. + config GIANFAR tristate Gianfar Ethernet depends on 85xx || 83xx || PPC_86xx --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -60,6 +60,8 @@ obj-$(CONFIG_TIGON3) += tg3.o obj-$(CONFIG_BNX2) += bnx2.o spidernet-y += spider_net.o spider_net_ethtool.o obj-$(CONFIG_SPIDER_NET) += spidernet.o sungem_phy.o +obj-$(CONFIG_GELIC_NET) += ps3_gelic.o +ps3_gelic-objs += gelic_net.o obj-$(CONFIG_TC35815) += tc35815.o obj-$(CONFIG_SKGE) += skge.o obj-$(CONFIG_SKY2) += sky2.o --- /dev/null +++ b/drivers/net/gelic_net.c The patch does not reflect the new name... - 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 3/9] pasemi_mac: Abstract out register access
Olof Johansson wrote:
Abstract out the PCI config read/write accesses into reg read/write ones, still
calling the pci accessors on the back end.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/pasemi_mac.c
===
--- netdev-2.6.orig/drivers/net/pasemi_mac.c
+++ netdev-2.6/drivers/net/pasemi_mac.c
@@ -81,6 +81,48 @@ MODULE_PARM_DESC(debug, PA Semi MAC bit
static struct pasdma_status *dma_status;
+static unsigned int read_iob_reg(struct pasemi_mac *mac, unsigned int reg)
+{
+ unsigned int val;
+
+ pci_read_config_dword(mac-iob_pdev, reg, val);
+ return val;
+}
+
+static void write_iob_reg(struct pasemi_mac *mac, unsigned int reg,
+ unsigned int val)
+{
+ pci_write_config_dword(mac-iob_pdev, reg, val);
+}
+
+static unsigned int read_mac_reg(struct pasemi_mac *mac, unsigned int reg)
+{
+ unsigned int val;
+
+ pci_read_config_dword(mac-pdev, reg, val);
+ return val;
+}
+
+static void write_mac_reg(struct pasemi_mac *mac, unsigned int reg,
+ unsigned int val)
+{
+ pci_write_config_dword(mac-pdev, reg, val);
+}
+
+static unsigned int read_dma_reg(struct pasemi_mac *mac, unsigned int reg)
+{
+ unsigned int val;
+
+ pci_read_config_dword(mac-dma_pdev, reg, val);
+ return val;
+}
+
+static void write_dma_reg(struct pasemi_mac *mac, unsigned int reg,
+ unsigned int val)
+{
+ pci_write_config_dword(mac-dma_pdev, reg, val);
+}
The general concept is fine, but you should use 'u32' and similar
size-based types for your input and output values.
-
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/9] pasemi_mac: Clean TX ring in poll
Olof Johansson wrote: Clean the TX ring in the poll call, to avoid sitting on mapped buffers for a long time. NFS doesn't seem to like it much, for example. Signed-off-by: Olof Johansson [EMAIL PROTECTED] Index: netdev-2.6/drivers/net/pasemi_mac.c === --- netdev-2.6.orig/drivers/net/pasemi_mac.c +++ netdev-2.6/drivers/net/pasemi_mac.c @@ -1052,6 +1052,7 @@ static int pasemi_mac_poll(struct net_de int pkts, limit = min(*budget, dev-quota); struct pasemi_mac *mac = netdev_priv(dev); + pasemi_mac_clean_tx(mac); pkts = pasemi_mac_clean_rx(mac, limit); Why is this needed? Is your TX interrupt mitigated or delayed somehow? In general, drivers should only clean TX in one place. Doing so in multiple places tends to indicate a bug somewhere. You are correct that you should not sit on buffers for too long -- that increases latency of all who are waiting on those buffers to be sent. - 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] spidernet: Replace literal with const
Linas Vepstas wrote: Replace literal with const; add bit definitions. Signed-off-by: Linas Vepstas [EMAIL PROTECTED] On Wed, Jun 13, 2007 at 04:12:00PM -0400, Jeff Garzik wrote: A follow-up patch needs to remove the above magic numbers (==numeric constants), replacing them with named constants Here it is. Lightly stres-tested (about 1/2 hour), as this patch tests some additonal bits. drivers/net/spider_net.c |2 +- drivers/net/spider_net.h | 19 +++ 2 files changed, 20 insertions(+), 1 deletion(-) applied to #upstream (2.6.23) - 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/9] pasemi_mac: Fix TX interrupt threshold
Olof Johansson wrote: It was mistakenly set to interrupt on the second packet instead of first, causing some interesting latency behaviour. Signed-off-by: Olof Johansson [EMAIL PROTECTED] applied - 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/RESENT] ehea: Whitespace cleanup
Jan-Bernd Themann wrote: This patch fixes several whitespace issues. Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED] applied - 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.6.21.5] 8139cp: dev-tx_timeout
[EMAIL PROTECTED] wrote: This patch implements the missing dev-tx_timeout for 8139cp driver Signed-off-by: Mika Lansirinne [EMAIL PROTECTED] does not seem to apply to current kernel. please resend against netdev-2.6.git#upstream or 2.6.22-rc7. - 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 UPDATE #2] Extract chip specific code out of lasi_82596.c
applied both patches. Please provide an update that does at Andrew requested -- rather than #include'ing lib82596.c, you should update the Makefile for relevant drivers to look like obj-$(CONFIG_FOO_BAR) += lib82596.o foo_bar_82596.o and make sure it exports everything to make lib82596 a full fledged module. - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Ayyappan Veeraiyan wrote:
+#define IXGBE_TX_FLAGS_CSUM0x0001
+#define IXGBE_TX_FLAGS_VLAN0x0002
+#define IXGBE_TX_FLAGS_TSO 0x0004
+#define IXGBE_TX_FLAGS_IPV40x0008
+#define IXGBE_TX_FLAGS_VLAN_MASK 0x
+#define IXGBE_TX_FLAGS_VLAN_SHIFT 16
defining bits using the form (1 n) is preferred. Makes it easier
to read, by eliminating the requirement of the human brain to decode hex
into bit numbers.
+ union {
+ /* To protect race between sender and clean_tx_irq */
+ spinlock_t tx_lock;
+ struct net_device netdev;
+ };
Embedded a struct net_device into your ring? How can I put this?
Wrong, wrong. Wrong, wrong, wrong. Wrong.
+ struct ixgbe_queue_stats stats;
+
+ u32 eims_value;
+ u32 itr_val;
+ u16 itr_range;
+ u16 itr_register;
+
+ char name[IFNAMSIZ + 5];
The interface name should not be stored by your ring structure
+#define IXGBE_DESC_UNUSED(R) \
+ R)-next_to_clean (R)-next_to_use) ? 0 : (R)-count) + \
+ (R)-next_to_clean - (R)-next_to_use - 1)
+
+#define IXGBE_RX_DESC_ADV(R, i)\
+ union ixgbe_adv_rx_desc *)((R).desc))[i]))
+#define IXGBE_TX_DESC_ADV(R, i)\
+ union ixgbe_adv_tx_desc *)((R).desc))[i]))
+#define IXGBE_TX_CTXTDESC_ADV(R, i)\
+ struct ixgbe_adv_tx_context_desc *)((R).desc))[i]))
+
+#define IXGBE_MAX_JUMBO_FRAME_SIZE 16128
+
+/* board specific private data structure */
+struct ixgbe_adapter {
+ struct timer_list watchdog_timer;
+ struct vlan_group *vlgrp;
+ u16 bd_number;
+ u16 rx_buf_len;
+ u32 part_num;
+ u32 link_speed;
+ unsigned long io_base;
Kill io_base and stop setting netdev-base_addr
+ atomic_t irq_sem;
+ struct work_struct reset_task;
+
+ /* TX */
+ struct ixgbe_ring *tx_ring; /* One per active queue */
+ u64 restart_queue;
+ u64 lsc_int;
+ u32 txd_cmd;
+ u64 hw_tso_ctxt;
+ u64 hw_tso6_ctxt;
+ u32 tx_timeout_count;
+ boolean_t detect_tx_hung;
+
+ /* RX */
+ struct ixgbe_ring *rx_ring; /* One per active queue */
+ u64 hw_csum_tx_good;
+ u64 hw_csum_rx_error;
+ u64 hw_csum_rx_good;
+ u64 non_eop_descs;
+ int num_tx_queues;
+ int num_rx_queues;
+ struct msix_entry *msix_entries;
+
+ u64 rx_hdr_split;
+ u32 alloc_rx_page_failed;
+ u32 alloc_rx_buff_failed;
+ struct {
+ unsigned int rx_csum_enabled:1;
+ unsigned int msi_capable:1;
+ unsigned int msi_enabled:1;
+ unsigned int msix_capable :1;
+ unsigned int msix_enabled :1;
+ unsigned int imir_enabled :1;
+ unsigned int in_netpoll :1;
+ } flags;
always avoid bitfields. They generate horrible code, and endian
problems abound (though no endian problems are apparent here).
+ u32 max_frame_size; /* Maximum frame size supported */
+ u32 eitr; /* Interrupt Throttle Rate */
+
+ /* OS defined structs */
+ struct net_device *netdev;
+ struct pci_dev *pdev;
+ struct net_device_stats net_stats;
+
+ /* structs defined in ixgbe_hw.h */
+ struct ixgbe_hw hw;
+ u16 msg_enable;
+ struct ixgbe_hw_stats stats;
+ char lsc_name[IFNAMSIZ + 5];
delete lsc_name and use netdev name directly in request_irq()
Will review more after you fix these problems.
-
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: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
Johannes Berg wrote: On Sat, 2007-06-30 at 11:32 -0400, jamal wrote: +NLA_PUT_U32(skb, CTRL_ATTR_MCAST_GRP_ID, grp-id); +NLA_PUT_STRING(skb, CTRL_ATTR_MCAST_GRP_NAME, + grp-name); + Consider my earlier suggestion to use CTRL_ATTR_MCAST_GRP which has both id and name in one struct. Yeah I thought about that but then saw Patrick's patches to convert other things away from structs so I wasn't sure what the idea here is. Patrick, care to comment? For information that belongs together logically a struct is fine. The main reason to use nested attributes is when you only have a single attribute to store your data in (for example TCA_OPTIONS for qdiscs). In that case a nested attribute should be used to allow to extend it in the future. Below that nested attribute you could put a struct of course. In this case I think using a string attribute instead of a fixed sized structure also makes sense for a different reason. Its unlikely that groups will really use the maximum name length allowed, so it should save some bandwidth. - 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 2.6.21.1] nfs-root: added possibility to override default MTU (for UDP jumbo frames)
To use a NFS-root for UDP jumbo frames the kernel on the client need to bring
up interface with MTU set to 9000 bytes - otherwise it cannot contact server
with jumbo frames enabled (nfs server not responding, still trying) and cannot
boot. Added a kernel parameter named 'ipmtu' which can be used to specify
initial MTU size when booting via nfsroot.
Signed-off-by: Mariusz Bialonczyk [EMAIL PROTECTED]
diff -Nru linux-2.6.21.1-orig/Documentation/kernel-parameters.txt
linux-2.6.21.1/Documentation/kernel-parameters.txt
--- linux-2.6.21.1-orig/Documentation/kernel-parameters.txt 2007-04-27
23:49:26.0 +0200
+++ linux-2.6.21.1/Documentation/kernel-parameters.txt 2007-07-01
18:47:11.0 +0200
@@ -720,6 +720,9 @@
ip2=[HW] Set IO/IRQ pairs for up to 4 IntelliPort boards
See comment before ip2_setup() in drivers/char/ip2.c.
+ ipmtu= [IP_PNP]
+ See Documentation/nfsroot.txt.
+
ips=[HW,SCSI] Adaptec / IBM ServeRAID controller
See header of drivers/scsi/ips.c.
diff -Nru linux-2.6.21.1-orig/Documentation/nfsroot.txt
linux-2.6.21.1/Documentation/nfsroot.txt
--- linux-2.6.21.1-orig/Documentation/nfsroot.txt 2007-04-27
23:49:26.0 +0200
+++ linux-2.6.21.1/Documentation/nfsroot.txt2007-07-01 19:02:40.0
+0200
@@ -153,6 +153,16 @@
Default: any
+ipmtu=mtu_value
+
+ This parameter tells the kernel to override default MTU size to specified
+ mtu_value. Useful in cases where NFS server have jumbo frames enabled and
+ client can't connect via UDP because of default MTU value (in ethernet
+ usually 1500 bytes). With this option before bringing interface up, kernel
+ will set the passed MTU size. In case of NFS-root booting server and client
+ can use UDP jumbo frames (NFS's rsize and wsize set to 8192 for instance).
+
+
3.) Boot Loader
diff -Nru linux-2.6.21.1-orig/net/ipv4/ipconfig.c
linux-2.6.21.1/net/ipv4/ipconfig.c
--- linux-2.6.21.1-orig/net/ipv4/ipconfig.c 2007-04-27 23:49:26.0
+0200
+++ linux-2.6.21.1/net/ipv4/ipconfig.c 2007-07-01 15:44:44.0 +0200
@@ -113,6 +113,8 @@
*/
int ic_set_manually __initdata = 0;/* IPconfig parameters set
manually */
+unsigned int ic_mtu __initdata = 0;/* IPconfig MTU parameter: 0 -
defaults, other - override */
+
static int ic_enable __initdata = 0; /* IP config enabled? */
/* Protocol choice */
@@ -209,6 +211,11 @@
able = ic_proto_enabled;
if (ic_proto_enabled !able)
continue;
+ if (ic_mtu 0)
+ {
+ printk(KERN_ERR IP-Config: Overriding %s MTU
to %d bytes\n, dev-name, ic_mtu);
+ dev-mtu = ic_mtu;
+ }
oflags = dev-flags;
if (dev_change_flags(dev, oflags | IFF_UP) 0) {
printk(KERN_ERR IP-Config: Failed to open
%s\n, dev-name);
@@ -1506,5 +1513,14 @@
return ip_auto_config_setup(addrs);
}
+static int __init mtu_config_setup(char *str)
+{
+ if (!str)
+ return 0;
+ ic_mtu = simple_strtoul(str, str, 0);
+ return 1;
+}
+
__setup(ip=, ip_auto_config_setup);
+__setup(ipmtu=, mtu_config_setup);
__setup(nfsaddrs=, nfsaddrs_config_setup);
-
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.6.21.1] nfs-root: added possibility to override default MTU (for UDP jumbo frames)
[EMAIL PROTECTED] wrote:
To use a NFS-root for UDP jumbo frames the kernel on the client need to bring
up interface with MTU set to 9000 bytes - otherwise it cannot contact server
with jumbo frames enabled (nfs server not responding, still trying) and cannot
boot. Added a kernel parameter named 'ipmtu' which can be used to specify
initial MTU size when booting via nfsroot.
Could you describe the problem better, please? Something does not
sound right. Both ends need to have jumbo frames enabled in order
to use jumbo frames, but if one end or the other does not, the systems
still should be able to exchange packets using normal sized ethernet
packets. Isn't this a problem that mtu discovery should handle?
Thanx...
ps
Signed-off-by: Mariusz Bialonczyk [EMAIL PROTECTED]
diff -Nru linux-2.6.21.1-orig/Documentation/kernel-parameters.txt
linux-2.6.21.1/Documentation/kernel-parameters.txt
--- linux-2.6.21.1-orig/Documentation/kernel-parameters.txt 2007-04-27
23:49:26.0 +0200
+++ linux-2.6.21.1/Documentation/kernel-parameters.txt 2007-07-01
18:47:11.0 +0200
@@ -720,6 +720,9 @@
ip2=[HW] Set IO/IRQ pairs for up to 4 IntelliPort boards
See comment before ip2_setup() in drivers/char/ip2.c.
+ ipmtu= [IP_PNP]
+ See Documentation/nfsroot.txt.
+
ips=[HW,SCSI] Adaptec / IBM ServeRAID controller
See header of drivers/scsi/ips.c.
diff -Nru linux-2.6.21.1-orig/Documentation/nfsroot.txt linux-2.6.21.1/Documentation/nfsroot.txt
--- linux-2.6.21.1-orig/Documentation/nfsroot.txt 2007-04-27
23:49:26.0 +0200
+++ linux-2.6.21.1/Documentation/nfsroot.txt2007-07-01 19:02:40.0
+0200
@@ -153,6 +153,16 @@
Default: any
+ipmtu=mtu_value
+
+ This parameter tells the kernel to override default MTU size to specified
+ mtu_value. Useful in cases where NFS server have jumbo frames enabled and
+ client can't connect via UDP because of default MTU value (in ethernet
+ usually 1500 bytes). With this option before bringing interface up, kernel
+ will set the passed MTU size. In case of NFS-root booting server and client
+ can use UDP jumbo frames (NFS's rsize and wsize set to 8192 for instance).
+
+
3.) Boot Loader
diff -Nru linux-2.6.21.1-orig/net/ipv4/ipconfig.c
linux-2.6.21.1/net/ipv4/ipconfig.c
--- linux-2.6.21.1-orig/net/ipv4/ipconfig.c 2007-04-27 23:49:26.0
+0200
+++ linux-2.6.21.1/net/ipv4/ipconfig.c 2007-07-01 15:44:44.0 +0200
@@ -113,6 +113,8 @@
*/
int ic_set_manually __initdata = 0;/* IPconfig parameters set
manually */
+unsigned int ic_mtu __initdata = 0; /* IPconfig MTU parameter: 0 - defaults, other - override */
+
static int ic_enable __initdata = 0; /* IP config enabled? */
/* Protocol choice */
@@ -209,6 +211,11 @@
able = ic_proto_enabled;
if (ic_proto_enabled !able)
continue;
+ if (ic_mtu 0)
+ {
+ printk(KERN_ERR IP-Config: Overriding %s MTU to %d
bytes\n, dev-name, ic_mtu);
+ dev-mtu = ic_mtu;
+ }
oflags = dev-flags;
if (dev_change_flags(dev, oflags | IFF_UP) 0) {
printk(KERN_ERR IP-Config: Failed to open %s\n,
dev-name);
@@ -1506,5 +1513,14 @@
return ip_auto_config_setup(addrs);
}
+static int __init mtu_config_setup(char *str)
+{
+ if (!str)
+ return 0;
+ ic_mtu = simple_strtoul(str, str, 0);
+ return 1;
+}
+
__setup(ip=, ip_auto_config_setup);
+__setup(ipmtu=, mtu_config_setup);
__setup(nfsaddrs=, nfsaddrs_config_setup);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
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
sky2 silicon bugs and workarounds...
Hi Stephen, When the sky2 driver initialises, it sets the the ISR timer register (STAT_ISR_TIMER_INI) to 125 * 20 = 2500, whereas the vendor sk98lin driver sets it to 400, irrespective of the clockspeed of the NIC processor. I guess you found more performance/stability from this value...? I've checked through the errata workarounds common to my rev-1 and 2 Yukon-EC chips...the HWF_WA_DEV_4167 oversize receive hang workaround checks and can reset the (as I understand) bus master unit of the NIC (in CheckRxPath) in a periodic timer that is fired, where is finds no progress is made. With the issues we see, can they be detected earlier by the stats counters not being incremented, then resetting the bus-master unit, rather than the whole chip getting kicked after a far longer period. It looks like if it is a silicon bug, we can just acknowledge it and have a better framework to detect the chip's PCI interface locking up and kick it in a smarter way perhaps... Daniel -- Daniel J Blueman - 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 UPDATE #2] Extract chip specific code out of lasi_82596.c
On Mon, Jul 02, 2007 at 08:43:04AM -0400, Jeff Garzik wrote: applied both patches. Please provide an update that does at Andrew requested -- rather than #include'ing lib82596.c, you should update the Makefile for relevant drivers to look like I got the impression that Andrew is fine with that approach after my explanation. I would need additional header files for all the different swap macros/dma stuff, and that isn't nice either, isn't it ? There are other drivers doing the same as I do, which didn't get any objections. Is it me you have a prolem with ? Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea.[ RFC1925, 2.3 ] - 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] dgrs romove Kconfig option
nobody objected to adrian's rfc dropping dgrs on netdev back in dec. 2006. - http://marc.info/?l=linux-netdevm=116507999803538w=2 as bonus points this will get rid of a prorpietary licensed firmware. so now be a bit more serious and remove the Kconfig entries and see if anyone shouts. if no voice is to be heard as expected by zero bug entries on kernel.org or debian.org, the full removal is scheduled for 2.6.24. Signed-off-by: maximilian attems [EMAIL PROTECTED] Acked-by: Alan [EMAIL PROTECTED] diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 7d3f205..306276e 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -348,3 +348,10 @@ Who: Tejun Heo [EMAIL PROTECTED] --- +What: drivers/net/dgrs.c +When: option 2.6.23, code 2.6.24 +Why: no users, product never reached market +Who: maximilian attems [EMAIL PROTECTED] + +--- + diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 7d57f4a..78a6a78 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1447,21 +1447,6 @@ config TC35815 depends on NET_PCI PCI MIPS select MII -config DGRS - tristate Digi Intl. RightSwitch SE-X support - depends on NET_PCI (PCI || EISA) - ---help--- - This is support for the Digi International RightSwitch series of - PCI/EISA Ethernet switch cards. These include the SE-4 and the SE-6 - models. If you have a network card of this type, say Y and read the - Ethernet-HOWTO, available from - http://www.tldp.org/docs.html#howto. More specific - information is contained in file:Documentation/networking/dgrs.txt. - - To compile this driver as a module, choose M here and read - file:Documentation/networking/net-modules.txt. The module - will be called dgrs. - config EEPRO100 tristate EtherExpressPro/100 support (eepro100, original Becker driver) depends on NET_PCI PCI diff --git a/drivers/net/Makefile b/drivers/net/Makefile index a77affa..209a079 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -38,7 +38,6 @@ obj-$(CONFIG_CASSINI) += cassini.o obj-$(CONFIG_MACE) += mace.o obj-$(CONFIG_BMAC) += bmac.o -obj-$(CONFIG_DGRS) += dgrs.o obj-$(CONFIG_VORTEX) += 3c59x.o obj-$(CONFIG_TYPHOON) += typhoon.o obj-$(CONFIG_NE2K_PCI) += ne2k-pci.o 8390.o - 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 UPDATE #2] Extract chip specific code out of lasi_82596.c
Thomas Bogendoerfer wrote: On Mon, Jul 02, 2007 at 08:43:04AM -0400, Jeff Garzik wrote: applied both patches. Please provide an update that does at Andrew requested -- rather than #include'ing lib82596.c, you should update the Makefile for relevant drivers to look like I got the impression that Andrew is fine with that approach after my explanation. I would need additional header files for all the different swap macros/dma stuff, and that isn't nice either, isn't it ? Fair enough. There are other drivers doing the same as I do, which didn't get any objections. Is it me you have a prolem with ? Put down the insanity and paranoia juice. Slowly. Jeff - 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 2.6.22-rc7] 8139cp: dev-tx_timeout
(Resending the patch against 2.6.22-rc7)
This patch implements the missing dev-tx_timeout for 8139cp driver
Signed-off-by: Mika Lansirinne [EMAIL PROTECTED]
---
diff -uprN linux-2.6.22-rc7/drivers/net/8139cp.c
linux-2.6.22-rc7_8139cp-tx_timeout/drivers/net/8139cp.c
--- linux-2.6.22-rc7/drivers/net/8139cp.c 2007-07-01 22:54:24.0 +0300
+++ linux-2.6.22-rc7_8139cp-tx_timeout/drivers/net/8139cp.c 2007-07-02
16:00:38.0 +0300
@@ -26,7 +26,6 @@
TODO:
* Test Tx checksumming thoroughly
- * Implement dev-tx_timeout
Low priority TODO:
* Complete reset on PciErr
@@ -1223,6 +1222,30 @@ static int cp_close (struct net_device *
return 0;
}
+static void cp_tx_timeout(struct net_device *dev)
+{
+ struct cp_private *cp = netdev_priv(dev);
+ int rc;
+ unsigned long flags;
+
+printk (KERN_WARNING %s: Transmit timeout, status %2x %4x %4x %4x\n,
+dev-name, cpr8(Cmd), cpr16(CpCmd),
+cpr16(IntrStatus), cpr16(IntrMask));
+
+ spin_lock_irqsave(cp-lock, flags);
+
+ cp_stop_hw(cp);
+ cp_clean_rings(cp);
+ rc = cp_init_rings(cp);
+ cp_start_hw(cp);
+
+ netif_wake_queue(dev);
+
+ spin_unlock_irqrestore(cp-lock, flags);
+
+ return;
+}
+
#ifdef BROKEN
static int cp_change_mtu(struct net_device *dev, int new_mtu)
{
@@ -1928,10 +1951,8 @@ static int cp_init_one (struct pci_dev *
dev-change_mtu = cp_change_mtu;
#endif
dev-ethtool_ops = cp_ethtool_ops;
-#if 0
dev-tx_timeout = cp_tx_timeout;
dev-watchdog_timeo = TX_TIMEOUT;
-#endif
#if CP_VLAN_TAG_USED
dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
-
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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
+u32 alloc_rx_buff_failed;
+struct {
+unsigned int rx_csum_enabled:1;
+unsigned int msi_capable:1;
+unsigned int msi_enabled:1;
+unsigned int msix_capable:1;
+unsigned int msix_enabled:1;
+unsigned int imir_enabled:1;
+unsigned int in_netpoll:1;
+} flags;
always avoid bitfields. They generate horrible code, and endian
problems abound (though no endian problems are apparent here).
they generate no worse code than open coding the checks for these
feature flags...
-
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.22-rc6: local_bh_enable warning
Russell King wrote: Having upgraded from 2.6.16 to 2.6.22-rc6, I'm now seeing the following. Looks like netfilter is calling local_bh_enable() with IRQs disabled, which would appear to be illegal. Thankfully, this is a warn-once warning. WARNING: at /home/rmk/git/linux-2.6-rmk/kernel/softirq.c:138 local_bh_enable() [...] [c01447fc] (nf_conntrack_destroy+0x0/0x2c) from [c012c05c] (__kfree_skb+0xd0/0x100) [c012bf8c] (__kfree_skb+0x0/0x100) from [c012c0d8] (kfree_skb+0x4c/0x50) r5:c12a3800 r4:0300 [c012c08c] (kfree_skb+0x0/0x50) from [bf03cbb0] (el3_start_xmit+0xb8/0xd0 [3c589_cs]) [bf03caf8] (el3_start_xmit+0x0/0xd0 [3c589_cs]) from [c01324dc] (dev_hard_start_xmit+0x1a8/0x244) r7:c12a3800 r6:c1a9aa00 r5:c1a9aa00 r4:c12a3800 [c0132334] (dev_hard_start_xmit+0x0/0x244) from [c013fcc0] (__qdisc_run+0xb0/0x198) Thats a bug in the 3c589_cs driver. Patch attached. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] diff --git a/drivers/net/pcmcia/3c589_cs.c b/drivers/net/pcmcia/3c589_cs.c index 143ae2f..503f268 100644 --- a/drivers/net/pcmcia/3c589_cs.c +++ b/drivers/net/pcmcia/3c589_cs.c @@ -629,9 +629,9 @@ static int el3_start_xmit(struct sk_buff *skb, struct net_device *dev) outw(SetTxThreshold + 1536, ioaddr + EL3_CMD); } -dev_kfree_skb(skb); pop_tx_status(dev); spin_unlock_irqrestore(priv-lock, flags); +dev_kfree_skb(skb); return 0; }
Re: [PATCH 2.6.21.1] nfs-root: added possibility to override default MTU (for UDP jumbo frames)
[EMAIL PROTECTED] writes: To use a NFS-root for UDP jumbo frames the kernel on the client need to bring up interface with MTU set to 9000 bytes - otherwise it cannot contact server with jumbo frames enabled (nfs server not responding, still trying) and cannot boot. Added a kernel parameter named 'ipmtu' which can be used to specify initial MTU size when booting via nfsroot. Isn't the whole IP autoconfig and NFS root set to die? Why not do it in initramfs? -- Krzysztof Halasa - 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.22-rc6: local_bh_enable warning
Patrick McHardy wrote: Russell King wrote: Having upgraded from 2.6.16 to 2.6.22-rc6, I'm now seeing the following. Looks like netfilter is calling local_bh_enable() with IRQs disabled, which would appear to be illegal. Thankfully, this is a warn-once warning. WARNING: at /home/rmk/git/linux-2.6-rmk/kernel/softirq.c:138 local_bh_enable() [...] [c01447fc] (nf_conntrack_destroy+0x0/0x2c) from [c012c05c] (__kfree_skb+0xd0/0x100) [c012bf8c] (__kfree_skb+0x0/0x100) from [c012c0d8] (kfree_skb+0x4c/0x50) r5:c12a3800 r4:0300 [c012c08c] (kfree_skb+0x0/0x50) from [bf03cbb0] (el3_start_xmit+0xb8/0xd0 [3c589_cs]) [bf03caf8] (el3_start_xmit+0x0/0xd0 [3c589_cs]) from [c01324dc] (dev_hard_start_xmit+0x1a8/0x244) r7:c12a3800 r6:c1a9aa00 r5:c1a9aa00 r4:c12a3800 [c0132334] (dev_hard_start_xmit+0x0/0x244) from [c013fcc0] (__qdisc_run+0xb0/0x198) Thats a bug in the 3c589_cs driver. Patch attached. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] You would post this JUST after I finished my patch applying run, wouldn't you? :) Will apply in a few minutes, thanks :) Jeff - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Arjan van de Ven wrote:
+u32 alloc_rx_buff_failed;
+struct {
+unsigned int rx_csum_enabled:1;
+unsigned int msi_capable:1;
+unsigned int msi_enabled:1;
+unsigned int msix_capable:1;
+unsigned int msix_enabled:1;
+unsigned int imir_enabled:1;
+unsigned int in_netpoll:1;
+} flags;
always avoid bitfields. They generate horrible code, and endian
problems abound (though no endian problems are apparent here).
they generate no worse code than open coding the checks for these
feature flags...
That would be the logical assumption, but reality does not bear that
logic out to be true.
I'm not sure whether gcc is confused about ABI alignment or such, on
various platforms, but every time I look at the asm generated it is
/not/ equivalent to open-coded feature flags and bitwise logic. Often
it is demonstrably worse.
The same is true for icc too :) Bitfields are just bad juju for
compilers, I guess.
Jeff
-
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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Jeff Garzik wrote: always avoid bitfields. They generate horrible code, and endian problems abound (though no endian problems are apparent here). they generate no worse code than open coding the checks for these feature flags... That would be the logical assumption, but reality does not bear that logic out to be true. I just checked a small example and gcc just generates a testb with an immediate value, which isn't all that bad code. Do you remember which gcc you tested with? - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Jeff Garzik wrote: I'm not sure whether gcc is confused about ABI alignment or such, on various platforms, but every time I look at the asm generated it is /not/ equivalent to open-coded feature flags and bitwise logic. Often it is demonstrably worse. (I can imagine this being different if you forcefully pack your structure to align with hw masks, but that is obviously not the case here) - 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: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
On Mon, 2007-07-02 at 14:56 +0200, Patrick McHardy wrote: For information that belongs together logically a struct is fine. Ok. The main reason to use nested attributes is when you only have a single attribute to store your data in (for example TCA_OPTIONS for qdiscs). In that case a nested attribute should be used to allow to extend it in the future. Below that nested attribute you could put a struct of course. Right, but that's not applicable to this unless I'm misunderstanding you. In this case I think using a string attribute instead of a fixed sized structure also makes sense for a different reason. Its unlikely that groups will really use the maximum name length allowed, so it should save some bandwidth. I suppose if I put (ID,name) into the struct it needn't be fixed-size length, but I dislike that as well. Do I understand you correctly in that you prefer the way I did it now? johannes signature.asc Description: This is a digitally signed message part
Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
Johannes Berg wrote: On Mon, 2007-07-02 at 14:56 +0200, Patrick McHardy wrote: The main reason to use nested attributes is when you only have a single attribute to store your data in (for example TCA_OPTIONS for qdiscs). In that case a nested attribute should be used to allow to extend it in the future. Below that nested attribute you could put a struct of course. Right, but that's not applicable to this unless I'm misunderstanding you. Not really, it already uses a nested top-level attribute. In this case I think using a string attribute instead of a fixed sized structure also makes sense for a different reason. Its unlikely that groups will really use the maximum name length allowed, so it should save some bandwidth. I suppose if I put (ID,name) into the struct it needn't be fixed-size length, but I dislike that as well. Me too. Do I understand you correctly in that you prefer the way I did it now? Yes. - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Arjan van de Ven wrote: Jeff Garzik wrote: always avoid bitfields. They generate horrible code, and endian problems abound (though no endian problems are apparent here). they generate no worse code than open coding the checks for these feature flags... That would be the logical assumption, but reality does not bear that logic out to be true. I just checked a small example and gcc just generates a testb with an immediate value, which isn't all that bad code. Do you remember which gcc you tested with? gcc 2.95, gcc 3.x, gcc 4.x, ... on multiple architectures, not just ia32. It's simple logic: using machine integers are the easiest for the compiler to Do The Right Thing, the easiest way to eliminate endian problems, the easiest way for programmers to read and understand struct alignment. Just say no to bitfields. Jeff - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Jeff Garzik wrote: It's simple logic: using machine integers are the easiest for the compiler to Do The Right Thing, the easiest way to eliminate endian problems, the easiest way for programmers to read and understand struct alignment. using integers pure is obviously natural.. but using integers and then manually doing bit masking yourself... that's not fundamentally better than what the compiler can do. yes bitfields are hard for not-1-bit cases and for cases where you mimick hardware layouts. neither is the case in this code. The code gets actually harder to read for the feature flags if you don't use bitfields so unless the code is really worse (and so far I've not seen that, but I'll investigate more when I get to work), I think it's fair to use single-bit, non-packed bitfields for them... - 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: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
On Mon, 2007-07-02 at 16:38 +0200, Patrick McHardy wrote: Do I understand you correctly in that you prefer the way I did it now? Yes. Alright, then I'll rework the event generation to not include the whole family info and repost with that tomorrow or so. If I find time I might actually fix the unregistration bug too, but I have a feeling digging in the socket code might take more time than I have right now. johannes signature.asc Description: This is a digitally signed message part
[info] What's in netdev-2.6.git?
This is what is currently queued for 2.6.23. There are a few patches in my mbox not yet applied to the git tree, but this is most of them. The following is found in the 'upstream' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git Akinobu Mita (1): softmac: use list_for_each_entry Bill Nottingham (1): drivers/net: fix comparisons of unsigned 0 Daniel Drake (4): zd1211rw: Add ID for ZyXEL G-200v2 zd1211rw: Extend RF layer zd1211rw: Add UW2453 RF support zd1211rw: Make CCK gain patching conditional on RF type David Brownell (1): usbnet whitespace fixes David S. Miller (1): r8169: kill eth_copy_and_sum() Divy Le Ray (3): cxgb3 - sge page management cxgb3 - Firmware update cxgb3 - TP SRAM update Francois Romieu (17): r8169: de-obfuscate modulo arithmetic r8169: add hooks for per-device hw_start handler r8169: add helpers for per-device hw_start handler r8169: populate the hw_start handler for the 8168 r8169: populate the hw_start handler for the 8110 r8169: prettify mac_version r8169: merge with version 6.001.00 of Realtek's r8169 driver r8169: merge with version 8.001.00 of Realtek's r8168 driver r8169: confusion between hardware and IP header alignment r8169: small 8101 comment r8169: remove the media option r8169: cleanup r8169: add bit description for the TxPoll register r8169: align the IP header when there is no DMA constraint r8169: display some extra debug information during startup r8169: mac address change support r8169: perform RX config change after mac filtering Geert Uytterhoeven (1): acenic: SET_NETDEV_DEV is always there these days Ivo van Doorn (2): Add 93cx6 eeprom library eeprom_93cx6: Add comment for 1us delay after pulse Jan Engelhardt (1): Use menuconfig objects II - netdev (general+100mbit) Jan-Bernd Themann (1): ehea: Whitespace cleanup Jeff Garzik (2): Merge branch 'upstream-fixes' into upstream Merge branch 'upstream-fixes' into upstream John W. Linville (2): eeprom_93cx6: shorten pulse timing to match spec rtl8187: add header blocks and indicate origin of magic values Jouni Malinen (1): hostap: Remove driver version number Kapil Juneja (2): gianfar: add support for SGMII phylib: m88e: enable SGMII mode Komuro (1): PCMCIA-NETDEV : add new ID of lanmodem multifunction card Larry Finger (1): bcm43xx: Fix deviation from specifications in set_baseband_attenuation Linas Vepstas (10): s2io: add PCI error recovery support s2io: add PCI error recovery support spidernet: beautify error messages spidernet: enhance the dump routine spidernet: invalidate unused pointer. spidernet: service TX later. spidernet: move a block of code around spidernet: fix misnamed flag spidernet: driver docmentation spidernet: Replace literal with const Matthias Kaehlcke (1): hostap: Use list_for_each_entry Michael Barkowski (1): phylib: add the ICPlus IP175C PHY driver Michael Wu (1): Add rtl8187 wireless driver Olof Johansson (1): pasemi_mac: Fix TX interrupt threshold Pavel Roskin (1): hostap: Suppress broadcast if no stations are associated Richard Knutsson (2): 8139cp: Convert to generic boolean tulip: Convert to generic boolean Rolf Eike Beer (1): r8169: add endianess annotations to [RT]xDesc Stephen Hemminger (14): b44: timer power saving b44: tx bounce sizing. b44: packet offset is constant b44: use netdev_alloc_skb qla3xxx: cleanup checksum offload code sky2: avoid reserved regions on ethtool reg dump sky2: Add PCI device specfic register 4 5 sky2: rename BMU register sky2: enable clocks before probe sky2: GPIO register sky2: Yukon Extreme (88e8071) support. sky2: version 1.15 r8169: use netdev_alloc_skb r8169: Rx path update Thomas Bogendoerfer (2): Extract chip specific code out of lasi_82596.c Ethernet driver for EISA only SNI RM200/RM400 machines Yoichi Yuasa (1): add return value check of request_irq() Documentation/networking/spider_net.txt | 204 +++ MAINTAINERS | 10 drivers/misc/Kconfig|5 drivers/misc/Makefile |1 drivers/misc/eeprom_93cx6.c | 241 +++ drivers/net/8139cp.c| 11 drivers/net/Kconfig | 172 +- drivers/net/Makefile|1 drivers/net/acenic.c|4 drivers/net/arm/Kconfig | 12 drivers/net/b44.c | 56 drivers/net/b44.h |2
Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Jeff Garzik wrote: Arjan van de Ven wrote: Jeff Garzik wrote: always avoid bitfields. They generate horrible code, and endian problems abound (though no endian problems are apparent here). they generate no worse code than open coding the checks for these feature flags... That would be the logical assumption, but reality does not bear that logic out to be true. I just checked a small example and gcc just generates a testb with an immediate value, which isn't all that bad code. Do you remember which gcc you tested with? gcc 2.95, gcc 3.x, gcc 4.x, ... on multiple architectures, not just ia32. It's simple logic: using machine integers are the easiest for the compiler to Do The Right Thing, the easiest way to eliminate endian problems, the easiest way for programmers to read and understand struct alignment. I really disagree with you here, I much rather prefer using code style like: if (adapter-flags.msi_enabled) .. than if (adapter-flags E1000_FLAG_MSI_ENABLED) ... not only does it read easier, it's also shorter and not prone to / confusion typo's, takes away parentheses when the test has multiple parts etc... Maybe this is not most important for ixgbe, where we only have 8 or so flags, but the new e1000 driver that I posted this weekend currently has 63 (you wanted flags ;)) of them. Do you want me to use 63 integers or just 2 ? And as Arjan said, we're not passing any of these to hardware, so there should not be any endian issues. I think acme would agree with me that pahole currently is the easiest way to show struct alignment ... Auke - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Kok, Auke wrote: Maybe this is not most important for ixgbe, where we only have 8 or so flags, but the new e1000 driver that I posted this weekend currently has 63 (you wanted flags ;)) of them. Do you want me to use 63 integers or just 2 ? Don't be silly. We are talking about single-bit feature flags implemented using machine ints (a la tg3 with 32 flags per int), versus bitfields. Bitfields are to be avoided for many reasons: * more difficult, in general, for a compiler to generate optimal code * in particular, known to generate worse code on various architectures * often causes endian problems * often enhances programmer confusion, when trying to review structs and determine optimal layout and alignment * programmers have proven they will screw up bitfields in e.g. cases with 1-bit and signedness. I can probably think up more reasons to avoid bitfields if given another 5 minutes :) Jeff - 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] Cleanup usbnet_probe() return value handling
usbnet_probe() handles a positive return value from the driver bind()
function as success, but will later only setup the status handler if the
return value was zero, leading to confusion. Patch adjusts this to only
accept 0 as success in both checks.
Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
drivers/net/usb/usbnet.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.22-rc7/drivers/net/usb/usbnet.c
===
--- linux-2.6.22-rc7.orig/drivers/net/usb/usbnet.c
+++ linux-2.6.22-rc7/drivers/net/usb/usbnet.c
@@ -1182,7 +1182,7 @@
// NOTE net-name still not usable ...
if (info-bind) {
status = info-bind (dev, udev);
- if (status 0)
+ if (status != 0)
goto out1;
// heuristic: usb%d for links we know are two-host,
--
Bye, Peter Korsgaard
-
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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Andrew Morton wrote: On Mon, 02 Jul 2007 11:32:41 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Bitfields are to be avoided for many reasons: * more difficult, in general, for a compiler to generate optimal code * in particular, known to generate worse code on various architectures * often causes endian problems * often enhances programmer confusion, when trying to review structs and determine optimal layout and alignment * programmers have proven they will screw up bitfields in e.g. cases with 1-bit and signedness. I can probably think up more reasons to avoid bitfields if given another 5 minutes :) A significant problem is that modifications to nearby bitfields need locking: concurrent modifications to two bitfields can result in concurrent modifications to the same word. And that's OK, but it's pretty unobvious that these stores are nonatomic from the source code and people could easily forget to do it. Indeed. Overall, it isn't any one specific thing that makes me reject bitfields in new code, it's the sum of all these reasons. Kernel and compiler history proves that humans and compilers screw up bitfields early and often :) Another reason that I just thought of: bitfields cannot be conglomerated into easy-to-assign-and-test masks, making foo = (1 0), bar = (1 4), baz = (1 9), default_feature_flags = foo | bar | baz, foo-flags = default_feature_flags; impossible with bitfields. You also cannot test multiple bits at one time, with bitfields. That being said, they _are_ attractive from the nice-to-read POV... My personal style disagrees, but that's a personal taste. I can see how other people might think that, though, agreed. Jeff - 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: sky2 silicon bugs and workarounds...
On 02/07/07, Stephen Hemminger [EMAIL PROTECTED] wrote: On Mon, 2 Jul 2007 14:37:06 +0100 Daniel J Blueman [EMAIL PROTECTED] wrote: When the sky2 driver initialises, it sets the the ISR timer register (STAT_ISR_TIMER_INI) to 125 * 20 = 2500, whereas the vendor sk98lin driver sets it to 400, irrespective of the clockspeed of the NIC processor. I guess you found more performance/stability from this value...? Not really, it was just a rough guess to try and get more frames per irq under DoS load. Haven't fine tuned those values. I've checked through the errata workarounds common to my rev-1 and 2 Yukon-EC chips...the HWF_WA_DEV_4167 oversize receive hang workaround checks and can reset the (as I understand) bus master unit of the NIC (in CheckRxPath) in a periodic timer that is fired, where is finds no progress is made. Where did you get those errata's. I keep having to do reverse engineering guessing with vendor driver. http://www.syskonnect.de/e_en/products/adapters/pcie_server/sk-9exx/software/linux/driver/install_v10.0.4.3.tar.bz2 from sk98lin.tar.bz2 inside --- defined in ./common/h/skgeinit.h /*-RMV- DWORD 1: Deviations */ #define HWF_WA_DEV_53 0x1100UL/*-RMV- 5.3 (Tx Done LSOv2 rep)*/ #define HWF_WA_DEV_LIM_IPV6_RSS 0x1080UL/*-RMV- IPV6 RSS limitted */ #define HWF_WA_DEV_4217 0x1040UL/*-RMV- 4.217 (PCI-E blockage) */ #define HWF_WA_DEV_4200 0x1020UL/*-RMV- 4.200 (D3 Blue Screen)*/ #define HWF_WA_DEV_4185CS 0x1010UL/*-RMV- 4.185 (ECU 100 CS cal)*/ #define HWF_WA_DEV_4185 0x1008UL/*-RMV- 4.185 (ECU Tx h check)*/ #define HWF_WA_DEV_4167 0x1004UL/*-RMV- 4.167 (Rx OvSize Hang)*/ #define HWF_WA_DEV_4152 0x1002UL/*-RMV- 4.152 (RSS issue) */ #define HWF_WA_DEV_4115 0x1001UL/*-RMV- 4.115 (Rx MAC FIFO) */ #define HWF_WA_DEV_4109 0x10008000UL/*-RMV- 4.109 (BIU hang) */ #define HWF_WA_DEV_483 0x10004000UL/*-RMV- 4.83 (Rx TCP wrong) */ #define HWF_WA_DEV_479 0x10002000UL/*-RMV- 4.79 (Rx BMU hang II) */ #define HWF_WA_DEV_472 0x10001000UL/*-RMV- 4.72 (GPHY2 MDC clk) */ #define HWF_WA_DEV_463 0x1800UL/*-RMV- 4.63 (Rx BMU hang I) */ #define HWF_WA_DEV_427 0x1400UL/*-RMV- 4.27 (Tx Done Rep) */ #define HWF_WA_DEV_42 0x1200UL/*-RMV- 4.2 (pref unit burst) */ #define HWF_WA_DEV_46 0x1100UL/*-RMV- 4.6 (CPU crash II) */ #define HWF_WA_DEV_43_418 0x1080UL/*-RMV- 4.3 4.18 (PCI unexp */ /*-RMV- complStat BMU deadl) */ #define HWF_WA_DEV_420 0x1040UL/*-RMV- 4.20 (Status BMU ov) */ #define HWF_WA_DEV_423 0x1020UL/*-RMV- 4.23 (TCP Segm Hang) */ #define HWF_WA_DEV_424 0x1010UL/*-RMV- 4.24 (MAC reg overwr) */ #define HWF_WA_DEV_425 0x1008UL/*-RMV- 4.25 (Magic packet */ /*-RMV- with odd offset) */ #define HWF_WA_DEV_428 0x1004UL/*-RMV- 4.28 (Poll-U BigEndi)*/ #define HWF_WA_FIFO_FLUSH_YLA0 0x1002UL/*-RMV- dis Rx GMAC FIFO Flush*/ /*-RMV- for Yu-L Rev. A0 only */ #define HWF_WA_COMA_MODE0x1001UL/*-RMV- Coma Mode WA req */ --- common/skgeinit.c:SkGeSetUpSupFeatures() case CHIP_ID_YUKON_EC: pAC-GIni.HwF.Features[HW_DEV_LIST] = HWF_WA_DEV_42 | HWF_WA_DEV_46 | HWF_WA_DEV_43_418 | ... case CHIP_ID_YUKON_FE: pAC-GIni.HwF.Features[HW_DEV_LIST] = HWF_WA_DEV_427 | HWF_WA_DEV_4109 | HWF_WA_DEV_4152 | HWF_WA_DEV_4167; break; case CHIP_ID_YUKON_XL: ... etc It's worthwhile looking at 2.6/skge.c:CheckRxPath() and it's call-site from the timer handler. Thanks, Daniel -- Daniel J Blueman - 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] Cleanup usbnet_probe() return value handling
On Monday 02 July 2007, Peter Korsgaard wrote:
usbnet_probe() handles a positive return value from the driver bind()
function as success, but will later only setup the status handler if the
return value was zero, leading to confusion. Patch adjusts this to only
accept 0 as success in both checks.
I'd rather see the later test updated to match this one.
(Good catch!)
The return convention is negative means error. There's
code in USB which has multiple nonnegative success codes.
In particular usb_control_msg(), which would very naturally
used as the body of a bind() method, returns negative or
the number of bytes transferred.
- Dave
Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
drivers/net/usb/usbnet.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.22-rc7/drivers/net/usb/usbnet.c
===
--- linux-2.6.22-rc7.orig/drivers/net/usb/usbnet.c
+++ linux-2.6.22-rc7/drivers/net/usb/usbnet.c
@@ -1182,7 +1182,7 @@
// NOTE net-name still not usable ...
if (info-bind) {
status = info-bind (dev, udev);
- if (status 0)
+ if (status != 0)
goto out1;
// heuristic: usb%d for links we know are two-host,
--
Bye, Peter Korsgaard
-
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: sky2 silicon bugs and workarounds...
On Mon, 2 Jul 2007 14:37:06 +0100 Daniel J Blueman [EMAIL PROTECTED] wrote: Hi Stephen, When the sky2 driver initialises, it sets the the ISR timer register (STAT_ISR_TIMER_INI) to 125 * 20 = 2500, whereas the vendor sk98lin driver sets it to 400, irrespective of the clockspeed of the NIC processor. I guess you found more performance/stability from this value...? I've checked through the errata workarounds common to my rev-1 and 2 Yukon-EC chips...the HWF_WA_DEV_4167 oversize receive hang workaround checks and can reset the (as I understand) bus master unit of the NIC (in CheckRxPath) in a periodic timer that is fired, where is finds no progress is made. This code in the vendor driver is not acceptable. It causes the device to continually reset itself in idle state. The sk9lin driver can not tell the difference between no packets arriving and hung! -- 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: [info] What's in netdev-2.6.git?
On Mon, Jul 02, 2007 at 11:08:26AM -0400, Jeff Garzik wrote: This is what is currently queued for 2.6.23. There are a few patches in my mbox not yet applied to the git tree, but this is most of them. I sent driver support for the AX88796 a few weeks ago with no feedback, should I re-send this CC: you? -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' - 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.6.21.1] nfs-root: added possibility to override default MTU (for UDP jumbo frames)
Peter Staubach wrote: [EMAIL PROTECTED] wrote: To use a NFS-root for UDP jumbo frames the kernel on the client need to bring up interface with MTU set to 9000 bytes - otherwise it cannot contact server with jumbo frames enabled (nfs server not responding, still trying) and cannot boot. Added a kernel parameter named 'ipmtu' which can be used to specify initial MTU size when booting via nfsroot. Could you describe the problem better, please? Something does not sound right. Both ends need to have jumbo frames enabled in order to use jumbo frames, but if one end or the other does not, the systems still should be able to exchange packets using normal sized ethernet packets. Isn't this a problem that mtu discovery should handle? Thanx... ps ok - first of all: yes you're right - if both ends have jumbo frames enabled it is all working fine - the patch is just for enabling client's MTU to jumbo because when booting via NFS-root client's MTU is set to default (1500 in ethernet case). I know that when server has MTU=9000 and client=1500 it should work - but it only work when nfs-root directory is mounted with TCP protocol. But i mean using UDP frames (then nfs options: wsize and rsize could be 8192 bytes). If I'm not clear I'll give you simple example: My server has jumbo frames enabled (it's not a problem to set it because server has HDD - can set up MTU during run time). The problem is when my diskless client need to boot via nfs-root. With vanilla kernel it looks like this: 1. Client boots 2. PXE get address from DHCP 3. without problem PXE client get kernel from server (via tftpboot) 4. it stop when kernel is going to mount root filesystem from NFS it still trying because server has jumbo enabled and client doesn't (endless message: NFS server is not responding, still trying) If I pass the ipmtu option with 9000 value to client's patched kernel then all is working fine because both client and server has jumbo frames enabled and client is able to mount root filesystem via NFS from server. the problem was some time ago posted by Tupshin Harper: http://www.ussg.iu.edu/hypermail/linux/kernel/0311.1/1055.html ... and is also described on my webpage: http://manio.skyboo.net/nfsroot_jumbo/ i hope you know what's going on :) best regards, Mariusz Bialonczyk - 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: [info] What's in netdev-2.6.git?
Ben Dooks wrote: On Mon, Jul 02, 2007 at 11:08:26AM -0400, Jeff Garzik wrote: This is what is currently queued for 2.6.23. There are a few patches in my mbox not yet applied to the git tree, but this is most of them. I sent driver support for the AX88796 a few weeks ago with no feedback, should I re-send this CC: you? Nothing from you in my mbox, so please do resend against 2.6.22-rc7... Jeff - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
On 7/2/07, Jeff Garzik [EMAIL PROTECTED] wrote: Ayyappan Veeraiyan wrote: +#define IXGBE_TX_FLAGS_VLAN_MASK 0x +#define IXGBE_TX_FLAGS_VLAN_SHIFT16 defining bits using the form (1 n) is preferred. Makes it easier to read, by eliminating the requirement of the human brain to decode hex into bit numbers. Ok. + struct net_device netdev; + }; Embedded a struct net_device into your ring? How can I put this? Wrong, wrong. Wrong, wrong, wrong. Wrong. Agreed. Fake netdevs are needed for doing the multiple Rx queues in NAPI mode. We are thinking to solve in 2 ways. Having netdev pointer in ring structure or having an array of netdev pointers in ixgbe_adatper struct which would be visible to all rings. + + char name[IFNAMSIZ + 5]; The interface name should not be stored by your ring structure Yes, I agree and also (pointed out by someone before) this would break if the user changes the interface name.. But, having the cause in the MSIX vector name really helps in debugging and helps the user also. I think the below output is much better [EMAIL PROTECTED] src]# cat /proc/interrupts | grep eth0 214: 0 0 PCI-MSI-edge eth0-lsc 215: 11763 4 PCI-MSI-edge eth0-rx7 216: 0 0 PCI-MSI-edge eth0-rx6 217: 77324 0 PCI-MSI-edge eth0-rx5 218: 0 0 PCI-MSI-edge eth0-rx4 219: 52911 0 PCI-MSI-edge eth0-rx3 220: 80271 0 PCI-MSI-edge eth0-rx2 221: 80244 6 PCI-MSI-edge eth0-rx1 222: 12 0 PCI-MSI-edge eth0-rx0 223: 124870 28543 PCI-MSI-edge eth0-tx0 Compared to [EMAIL PROTECTED] src]# cat /proc/interrupts | grep eth0 214: 0 0 PCI-MSI-edge eth0 215: 11763 4 PCI-MSI-edge eth0 216: 0 0 PCI-MSI-edge eth0 217: 77324 0 PCI-MSI-edge eth0 218: 0 0 PCI-MSI-edge eth0 219: 52911 0 PCI-MSI-edge eth0 220: 80271 0 PCI-MSI-edge eth0 221: 80244 6 PCI-MSI-edge eth0 222: 12 0 PCI-MSI-edge eth0 223: 124900 28543 PCI-MSI-edge eth0 Since we wanted to distinguish the various MSIX vectors in /proc/interrupts and since request_irq expects memory for name to be allocated somewhere, I added this part of the ring struct. Kill io_base and stop setting netdev-base_addr In my latest internal version, I already removed the io_base member (and couple more from ixgbe_adapter) but still setting the netdev-base_addr. I will remove that also.. + struct ixgbe_hw_stats stats; + char lsc_name[IFNAMSIZ + 5]; delete lsc_name and use netdev name directly in request_irq() Please see the response for the name member of ring structure. Will review more after you fix these problems. Thanks for the feedback. I will post another version shortly (except the feature flags change and the ring struct name members) which fixes my previous TODO list and also most of Francois comments.. Ayyappan - 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 patch] the overdue eepro100 removal
Adrian Bunk wrote: This patch contains the overdue removal of the eepro100 driver. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] The hardware supported by this driver is still in use, thanks. It's probably easier to leave the eepro100 driver in than find anyone who wants to investigate why the other driver (e100? from memory) doesn't work with some cards. As I recall this was suggested over a year ago and it was decided to leave it in, all of the reasons for doing so still seem valid. There really doesn't seem to be a benefit, it's not like people are working night and day to support new cards for this chip. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - 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: quirk_e100_interrupt() called too early
Nils Rennebarth wrote: Bjorn Helgaas wrote: On Thursday 28 June 2007 10:01:08 am Kok, Auke wrote: I copied Nils Rennebarth, who originally reported the bug: http://bugzilla.kernel.org/show_bug.cgi?id=5918 in case he can test your patch. Most of the embedded boards we now work with appear to exhibit the same behaviour: During boot the Firmware left :01:05.0 e100 interrupts enabled, disabling message appears for all four e100 nics. (The mainboard is a em-8510A btw.) When I have time I could try if the quirk still works with the mentioned patch, but I am quite busy with other things at the moment. well, we're too late for 2.6.22 I think so you have some time. However I'd like to make sure we can get this in with 2.6.23. Alternatively, someone could always send me one of these boards ;) Thanks for taking the time to test Auke - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
On 7/2/07, Veeraiyan, Ayyappan [EMAIL PROTECTED] wrote: Thanks for the feedback. I will post another version shortly (except the feature flags change and the ring struct name members) which fixes my Just to clarify this, I will wait some more time for feature flags discussion and the ring structure name feedback.. Ayyappan - 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] dgrs romove Kconfig option
On Mon, 2 Jul 2007 15:52:01 +0200 maximilian attems [EMAIL PROTECTED] wrote: nobody objected to adrian's rfc dropping dgrs on netdev back in dec. 2006. - http://marc.info/?l=linux-netdevm=116507999803538w=2 as bonus points this will get rid of a prorpietary licensed firmware. so now be a bit more serious and remove the Kconfig entries and see if anyone shouts. if no voice is to be heard as expected by zero bug entries on kernel.org or debian.org, the full removal is scheduled for 2.6.24. Why not just do the full removal now? If someone shouts, it's just as easy to add it all back. Leaving around half a driver is just annoying.. -- Andres Salomon [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: [2.6 patch] the overdue eepro100 removal
Bill Davidsen wrote: Adrian Bunk wrote: This patch contains the overdue removal of the eepro100 driver. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] The hardware supported by this driver is still in use, thanks. It's probably easier to leave the eepro100 driver in than find anyone who wants to investigate why the other driver (e100? from memory) doesn't work with some cards. As I recall this was suggested over a year ago and it was decided to leave it in, all of the reasons for doing so still seem valid. There really doesn't seem to be a benefit, it's not like people are working night and day to support new cards for this chip. please see the thread Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits) which is discussing a fix for this issue and currently being worked. eepro100 will *still* be removed once e100 is fixed to support those devices. Moreover, we now also have a fix for the e100 IPMI issues on some tyan boards (patch coming this week!). That hopefully solves all e100 issues that are still open. Auke - 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: r8169 2.2LK: Low link speed after suspend
Peter Missel [EMAIL PROTECTED] : [...] Unfortunately I couldn't get NFS to work with the updated kernel, so I had to revert to the original from SuSE 10.2. No NFS but networking or no networking at all ? -- 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: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Christoph Hellwig wrote: On Mon, Jul 02, 2007 at 02:09:58PM -0700, Stephen Hemminger wrote: The patch is close to ready for 2.6.24 when this driver will need to show up. If intel manages to fix up the reamining issues I'd rather see it appear in 2.6.23.. Since I know Intel will be forced to backport this to older distro's. You would be best to have a single receive queue version when you have to make it work on the older code. But that'll require the single receiver queue version I guess. The netdevice abuse is the only really major issue I see, although I'd of course really like to see the driver getting rid of the bitfield abuse aswell. well, FWIW when I started looking at adding these flags I looked in various subsystems in the kernel and picked an implementation that suited. Guess what pci.h has? ...: unsigned int msi_enabled:1; unsigned int msix_enabled:1; this is literally where I copied the example from I suppose I can fix those, but I really don't understand what all the fuzz is about here. We're only conserving memory and staying far away from the real risks of bitmasks, so forgive me if I don't grasp the problem. Honestly, if this is really considered Bad coding (TM) then we need to fix these prominent abuses of it too. I count about 60 or so of these bitfields in drivers/net... (and countless more in other parts) ! Auke - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Kok, Auke wrote: I suppose I can fix those, but I really don't understand what all the fuzz is about here. We're only conserving memory and staying far away from the real risks of bitmasks, so forgive me if I don't grasp the problem. Be it machine ints or bitfields, you're not conserving memory. Think about struct padding. As to the overall question, I already posted a long list of problems with bitfields. Shall I repeat? Jeff - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
On Tuesday 03 July 2007 00:02:57 Kok, Auke wrote: well, FWIW when I started looking at adding these flags I looked in various subsystems in the kernel and picked an implementation that suited. Guess what pci.h has? ...: unsigned int msi_enabled:1; unsigned int msix_enabled:1; this is literally where I copied the example from I suppose I can fix those, but I really don't understand what all the fuzz is about here. We're only conserving memory and staying far away from the real I'm not sure if these bitfields actually _do_ conserve memory. Generated code gets bigger (need bitwise masks and stuff). Code also needs memory. It probably only conserves memory, if the structure is instanciated a lot. -- Greetings 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: [git patches] net driver fixes
On Mon, Jul 02, 2007 at 10:54:01AM -0400, Jeff Garzik wrote:
...
maximilian attems (1):
starfire list alpha as 64 bit arch
...
--- a/drivers/net/starfire.c
+++ b/drivers/net/starfire.c
@@ -152,7 +152,7 @@ static int full_duplex[MAX_UNITS] = {0, };
* This SUCKS.
* We need a much better method to determine if dma_addr_t is 64-bit.
*/
-#if (defined(__i386__) defined(CONFIG_HIGHMEM64G)) || defined(__x86_64__)
|| defined (__ia64__) || defined(__mips64__) || (defined(__mips__)
defined(CONFIG_HIGHMEM) defined(CONFIG_64BIT_PHYS_ADDR))
+#if (defined(__i386__) defined(CONFIG_HIGHMEM64G)) || defined(__x86_64__)
|| defined (__ia64__) || defined(__alpha__) || defined(__mips64__) ||
(defined(__mips__) defined(CONFIG_HIGHMEM)
defined(CONFIG_64BIT_PHYS_ADDR))
/* 64-bit dma_addr_t */
#define ADDR_64BITS /* This chip uses 64 bit addresses. */
#define netdrv_addr_t u64
...
The patch is correct and definitely the best solution at this time of
the 2.6.22 development cycle.
But the comment in the context exactly matches what I thought when
I saw this code...
Does anyone have a suggestion how to do this better?
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
Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Michael Buesch wrote: On Tuesday 03 July 2007 00:02:57 Kok, Auke wrote: well, FWIW when I started looking at adding these flags I looked in various subsystems in the kernel and picked an implementation that suited. Guess what pci.h has? ...: unsigned int msi_enabled:1; unsigned int msix_enabled:1; this is literally where I copied the example from I suppose I can fix those, but I really don't understand what all the fuzz is about here. We're only conserving memory and staying far away from the real I'm not sure if these bitfields actually _do_ conserve memory. Generated code gets bigger (need bitwise masks and stuff). Code also needs memory. It probably only conserves memory, if the structure is instanciated a lot. Actually, that's a good point. On several RISC architectures it certainly generates bigger code. Jeff - 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: [git patches] net driver fixes
On Tue, 3 Jul 2007 00:13:29 +0200
Adrian Bunk [EMAIL PROTECTED] wrote:
On Mon, Jul 02, 2007 at 10:54:01AM -0400, Jeff Garzik wrote:
...
maximilian attems (1):
starfire list alpha as 64 bit arch
...
--- a/drivers/net/starfire.c
+++ b/drivers/net/starfire.c
@@ -152,7 +152,7 @@ static int full_duplex[MAX_UNITS] = {0, };
* This SUCKS.
* We need a much better method to determine if dma_addr_t is 64-bit.
*/
-#if (defined(__i386__) defined(CONFIG_HIGHMEM64G)) ||
defined(__x86_64__) || defined (__ia64__) || defined(__mips64__) ||
(defined(__mips__) defined(CONFIG_HIGHMEM)
defined(CONFIG_64BIT_PHYS_ADDR))
+#if (defined(__i386__) defined(CONFIG_HIGHMEM64G)) ||
defined(__x86_64__) || defined (__ia64__) || defined(__alpha__) ||
defined(__mips64__) || (defined(__mips__) defined(CONFIG_HIGHMEM)
defined(CONFIG_64BIT_PHYS_ADDR))
/* 64-bit dma_addr_t */
#define ADDR_64BITS/* This chip uses 64 bit addresses. */
#define netdrv_addr_t u64
...
The patch is correct and definitely the best solution at this time of
the 2.6.22 development cycle.
But the comment in the context exactly matches what I thought when
I saw this code...
Does anyone have a suggestion how to do this better?
cu
Adrian
Yeah, write code that handles it in compiler. Like:
if (sizeof(dma_addr_t) sizeof(u32)) {
do something...
}
That means that it gets checked even if optimizer removes it as
unneeded.
--
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] Cleanup usbnet_probe() return value handling
David == David Brownell [EMAIL PROTECTED] writes: Hi, David I'd rather see the later test updated to match this one. David (Good catch!) David The return convention is negative means error. There's David code in USB which has multiple nonnegative success codes. Ok, updated patch does that instead. David In particular usb_control_msg(), which would very naturally David used as the body of a bind() method, returns negative or David the number of bytes transferred. Yeah, that was the original problem in my dm9601 driver. usbnet_probe() handles a positive return value from the driver bind() function as success, but will later only setup the status handler if the return value was zero, leading to confusion. Patch adjusts this to accept positive values as success in both checks. Signed-off-by: Peter Korsgaard [EMAIL PROTECTED] --- drivers/net/usb/usbnet.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.22-rc7/drivers/net/usb/usbnet.c === --- linux-2.6.22-rc7.orig/drivers/net/usb/usbnet.c +++ linux-2.6.22-rc7/drivers/net/usb/usbnet.c @@ -1208,7 +1208,7 @@ status = 0; } - if (status == 0 dev-status) + if (status = 0 dev-status) status = init_status (dev, udev); if (status 0) goto out3; -- Bye, Peter Korsgaard - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
On 7/2/07, Stephen Hemminger [EMAIL PROTECTED] wrote:
Fake netdevs are needed for doing the multiple Rx queues in NAPI
mode.
We are thinking to solve in 2 ways. Having netdev pointer in ring
structure or having an array of netdev pointers in ixgbe_adatper
struct
which would be visible to all rings.
Wait until Davem I separate NAPI from network device.
The patch is close to ready for 2.6.24 when this driver will need to
show up.
Since I know Intel will be forced to backport this to older distro's.
You
would be best to have a single receive queue version when you have to
make
it work on the older code.
So far all our testing indicates we need multiple Rx queues to have
better CPU utilization number at 10Gig line rate. So I am thinking
adding the non-NAPI support to the driver (like other 10Gig drivers) and
restrict to single rx queue in case of NAPI. I already have the non-NAPI
version coded up and went through internal testing. I will add this in
the next submission. We will add the multiple Rx queues support in NAPI
mode once when separate NAPI from network device is done. Does this
sound ok?
You only need to store the name for when you are doing request_irq, so
it can just be a stack temporary.
request_irq expects allocated memory not just stack temporary. I glanced
the kernel source.. There are precedents to the way we did.
linux-2.6/source/drivers/usb/core/hcd.c
1594 /* enable irqs just before we start the controller */
1595 if (hcd-driver-irq) {
1596 snprintf(hcd-irq_descr, sizeof(hcd-irq_descr),
%s:usb%d,
1597 hcd-driver-description,
hcd-self.busnum);
1598 if ((retval = request_irq(irqnum, usb_hcd_irq,
irqflags,
1599 hcd-irq_descr, hcd)) != 0) {
1600 dev_err(hcd-self.controller,
1601 request interrupt %d
failed\n, irqnum);
1602 goto err_request_irq;
1603 }
Stephen Hemminger [EMAIL PROTECTED]
I appreciate the feedback.
Thanks,
Ayyappa
-
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: [WIP][PATCHES] Network xmit batching - tg3 support
On Mon, 2007-07-02 at 14:20 -0700, Matt Carlson wrote:
Also, I think the count, max_per_txd, and nr_frags fields of the
tg3_tx_cbdata struct are not needed.
The count field is not needed also.
+struct tg3_tx_cbdata {
+ u32 base_flags;
+ int count;
+ unsigned int max_per_txd;
+ unsigned int nr_frags;
+ unsigned int mss;
+};
+#define TG3_SKB_CB(__skb) ((struct tg3_tx_cbdata *)((__skb)-cb[0]))
Only base_flags and mss are needed and these can be determined right
before sending the frame. So is it better not to store these in the
skb-cb at all?
@@ -3118,12 +3120,16 @@ static void tg3_tx(struct tg3 *tp)
*/
smp_mb();
+ dcount = tg3_tx_avail(tp);
if (unlikely(netif_queue_stopped(tp-dev)
-(tg3_tx_avail(tp) TG3_TX_WAKEUP_THRESH(tp {
+(dcount TG3_TX_WAKEUP_THRESH(tp {
netif_tx_lock(tp-dev);
+ tp-dev-xmit_win = 1;
if (netif_queue_stopped(tp-dev)
- (tg3_tx_avail(tp) TG3_TX_WAKEUP_THRESH(tp)))
+ (dcount TG3_TX_WAKEUP_THRESH(tp))) {
netif_wake_queue(tp-dev);
+ tp-dev-xmit_win = dcount;
+ }
netif_tx_unlock(tp-dev);
}
}
This is also not right. tg3_tx() runs without netif_tx_lock().
tg3_tx_avail() can change after you get the netif_tx_lock() and we must
get the updated value again. If we just rely on dcount, we can call
wake_queue() when the ring is full, or there may be no wakeup when the
ring is empty.
-
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: [E1000-devel] e1000: backport ich9 support from 7.5.5 ?
Mark McLoughlin wrote: I disagree, we should not break the current e1000 driver in the kernel while there is a new driver coming up that introduces ich9 support without breaking (the old e1000) support for all other devices. This is why we want to drop a new version of the e1000 driver upstream instead, and put all newer devices in that driver. Clearly some major changes are happening around e1000, but the point I'm making is that ich9 support, in particular, doesn't need to be held hostage to these longer term changes. I think the backport shows that: There seems to be a lot of concern over obsoleting the e1000 driver too quickly, and with confusing users (and startup scripts) about which driver to load. Obviously, we at Intel want to get e1000new into the kernel as quickly as possible, and to obsolete e1000 also as quickly as possible. The point of this exercise is to reduce our support and maintenance burden, and e1000new has shown itself internally to be much easier to work on. So how about this: - We include e1000new in 2.6.23, along side e1000. We expose ICH9 device IDs in e1000new, and gate the rest of the IDs inside #ifndef CONFIG_E1000. This gives distis ICH9 support, along with a guarantee of the known e1000 driver. It also lets the more bleeding-edge people turn off e1000 and run with just e1000new to work out any kinks. - For 2.6.24, we reverse the situation: Gate all device IDs in e1000 behind #ifndef CONFIG_E1000NEW, and expose all of them in e1000new. At this point we (i.e. the community, not just Intel) should be confident in e1000new, and we can mark e1000 as obsolete. It's still a fallback option for those with old/funky/misconfigured hardware. - After a year (or whatever), we remove e1000. Seems to me that this plan should appease either everybody or nobody. We get ICH9 support out there, e1000new gets in the kernel and exercised, and we get to set a definite date for obsoleting e1000. -Mitch - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Jeff Garzik wrote: Michael Buesch wrote: On Tuesday 03 July 2007 00:02:57 Kok, Auke wrote: well, FWIW when I started looking at adding these flags I looked in various subsystems in the kernel and picked an implementation that suited. Guess what pci.h has? ...: unsigned int msi_enabled:1; unsigned int msix_enabled:1; this is literally where I copied the example from I suppose I can fix those, but I really don't understand what all the fuzz is about here. We're only conserving memory and staying far away from the real I'm not sure if these bitfields actually _do_ conserve memory. Generated code gets bigger (need bitwise masks and stuff). Code also needs memory. It probably only conserves memory, if the structure is instanciated a lot. Actually, that's a good point. On several RISC architectures it certainly generates bigger code. so, even on i386 it does (17 bytes and 6 instructions to test vs. 10:3 if using a bool): unsigned int:1: 8048365: 0f b6 45 f8 movzbl 0xfff8(%ebp),%eax 8048369: 0c 01 or $0x1,%al 804836b: 88 45 f8mov%al,0xfff8(%ebp) 804836e: 0f b6 45 f8 movzbl 0xfff8(%ebp),%eax 8048372: 24 01 and$0x1,%al 8048374: 84 c0 test %al,%al bool: 8048365: c6 45 fb 01 movb $0x1,0xfffb(%ebp) 8048369: 0f b6 45 fb movzbl 0xfffb(%ebp),%eax 804836d: 84 c0 test %al,%al unsigned int: 8048365: c7 45 f8 01 00 00 00movl $0x1,0xfff8(%ebp) 804836c: 8b 45 f8mov0xfff8(%ebp),%eax 804836f: 85 c0 test %eax,%eax using var flag: 8048365: c7 45 f8 01 00 00 00movl $0x1,0xfff8(%ebp) 804836c: 8b 45 f8mov0xfff8(%ebp),%eax 804836f: 25 00 04 00 00 and$0x400,%eax 8048374: 85 c0 test %eax,%eax note that using var flag is slightly larger here... 1 extra instruction and 7 more bytes. interesting... but let's stay constructive here: ~/git/linux-2.6 $ grep -r 'unsigned int.*:1;' * | wc -l 748 Is anyone going to fix those? If we don't, someone will certainly again submit patches to add more of these bitfields, after all, some very prominent parts of the kernel still use them. Only recently for instance mac80211 merged like 30 of these and drivers/net, include etc.. certainly has a lot of these. Cheers, Auke - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
On 7/2/07, Christoph Hellwig [EMAIL PROTECTED] wrote: But that'll require the single receiver queue version I guess. The netdevice abuse is the only really major issue I see, although I'd of course really like to see the driver getting rid of the bitfield abuse aswell. The submitted driver code supports single queue version in case of MSIX allocation failures... As I said in the other mail, I feel, restricting to single Rx queue in NAPI mode is better approach till Stephen's and DaveM' work of separating NAPI from netdevice is done.. Lots of drivers where the interface name is assigned after request_irq just use an internal name, e.g. ixgbeX in the case of this driver. This sounds ok to me. With this change, this is the output.. [EMAIL PROTECTED] src]# ip link 1: lo: LOOPBACK,UP,1 mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: sit0: NOARP mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 3: eth6: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:50:8b:05:5f:95 brd ff:ff:ff:ff:ff:ff 29: eth0: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:1b:21:01:e4:93 brd ff:ff:ff:ff:ff:ff 30: eth1: BROADCAST,MULTICAST mtu 1500 qdisc noop qlen 1000 link/ether 00:1b:21:01:e4:92 brd ff:ff:ff:ff:ff:ff [EMAIL PROTECTED] src]# cat /proc/interrupts | grep 29 214: 0 0 PCI-MSI-edge ixgbe29-lsc 215: 11764 80213 PCI-MSI-edge ixgbe29-rx7 216: 80257 0 PCI-MSI-edge ixgbe29-rx6 217: 77331 0 PCI-MSI-edge ixgbe29-rx5 218: 24201 0 PCI-MSI-edge ixgbe29-rx4 219: 52911 0 PCI-MSI-edge ixgbe29-rx3 220: 104591 0 PCI-MSI-edge ixgbe29-rx2 221: 80249 8 PCI-MSI-edge ixgbe29-rx1 222: 14 0 PCI-MSI-edge ixgbe29-rx0 223: 194023 118220 PCI-MSI-edge ixgbe29-tx0 Ayyappan - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
Kok, Auke wrote: but let's stay constructive here: ~/git/linux-2.6 $ grep -r 'unsigned int.*:1;' * | wc -l 748 Is anyone going to fix those? If we don't, someone will certainly again submit patches to add more of these bitfields, after all, some very prominent parts of the kernel still use them. Only recently for instance mac80211 merged like 30 of these and drivers/net, include etc.. certainly has a lot of these. There is a lot of crap in the kernel. Just look at all the grotty SCSI or char drivers, for example. The first task is to avoid adding more crap :) Jeff - 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: [E1000-devel] e1000: backport ich9 support from 7.5.5 ?
There seems to be a lot of concern over obsoleting the e1000 driver too quickly, and with confusing users (and startup scripts) about which driver to load. Yes. Obviously, we at Intel want to get e1000new into the kernel as quickly as possible, and to obsolete e1000 also as quickly as possible. The point of this exercise is to reduce our support and maintenance burden, and e1000new has shown itself internally to be much easier to work on. So how about this: - We include e1000new in 2.6.23, along side e1000. We expose ICH9 device IDs in e1000new, and gate the rest of the IDs inside #ifndef CONFIG_E1000. This gives distis ICH9 support, along with a guarantee of the known e1000 driver. It also lets the more bleeding-edge people turn off e1000 and run with just e1000new to work out any kinks. - For 2.6.24, we reverse the situation: Gate all device IDs in e1000 behind #ifndef CONFIG_E1000NEW, and expose all of them in e1000new. At this point we (i.e. the community, not just Intel) should be confident in e1000new, and we can mark e1000 as obsolete. It's still a fallback option for those with old/funky/misconfigured hardware. - After a year (or whatever), we remove e1000. Seems to me that this plan should appease either everybody or nobody. We get ICH9 support out there, e1000new gets in the kernel and exercised, and we get to set a definite date for obsoleting e1000. What sort of timeframes are we looking at with 2.6.23 and then 2.6.24 and how might they map to distro releases? Much as everyone wants/encourages folks to test the kernel.org kernels and such, the _real_ exposure still seems to come with a distro release. Rambling a bit, and recognizing that e1000new was probably just a strawman name, but I suspect that a _very_ different name for the new driver would be a good thing, rather than a varition on the e1000 theme. The Law of the Telephone Game pretty much guaratees that something with e1000 in its name will be shortened to just e1000. How about elk (ee el kay) - applying that same telephone game (consistency? nah) to e1000 to get e1k, which if you look at it quickly enough looks like elk. OK, that's half in jest, but only half. I may be wrong, but I don't think I've seen anyone shortening the current e1000 to e1k? rick jones - 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] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
On Monday 02 July 2007, Kok, Auke wrote:
Jeff Garzik wrote:
Michael Buesch wrote:
On Tuesday 03 July 2007 00:02:57 Kok, Auke wrote:
well, FWIW when I started looking at adding these flags I looked in
various
subsystems in the kernel and picked an implementation that suited. Guess
what
pci.h has? ...:
unsigned int msi_enabled:1;
unsigned int msix_enabled:1;
this is literally where I copied the example from
I suppose I can fix those, but I really don't understand what all the
fuzz is
about here. We're only conserving memory and staying far away from the
real
I'm not sure if these bitfields actually _do_ conserve memory.
Generated code gets bigger (need bitwise masks and stuff).
Code also needs memory. It probably only conserves memory, if the
structure is instanciated a lot.
Actually, that's a good point. On several RISC architectures it
certainly generates bigger code.
...
but let's stay constructive here:
~/git/linux-2.6 $ grep -r 'unsigned int.*:1;' * | wc -l
748
Is anyone going to fix those? If we don't, someone will certainly again
submit
patches to add more of these bitfields, after all, some very prominent parts
of
the kernel still use them. Only recently for instance mac80211 merged like 30
of
these and drivers/net, include etc.. certainly has a lot of these.
I don't think bitfields are broken. Maybe it's the compiler what should be
fixed (*)
...bitfields are there to save the coder having to type masks by hand. There
should
be no difference in the generated code from doing
u32 value = readl(fromsomewhere);
printf(bits 16 15 0x%08x\n, value 0x00018000 15);
union {
struct {
u32 reserved1:15;
u32 val:2;
} __attribute__((packed))
u32 data;
} value;
value.data = readl(fromsomewhere);
printf(bits 16 15 0x%08x\n, value.val);
Granted, that looks big, but once you nail it out at your struct definitons, it
makes maintenance much easier when looking at the bitmasks in the specs. Masks
and
shifts tend to suck on the long term when they accumulate.
-- Inaky
(*) not to mention the endianness mess
-
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] ucc_geth.c, make PHY device optional.
This patch makes the PHY optional for ucc_geth.c ethernet driver. This is useful to support a direct mii to mii connection to, for example, a onboard swicth. Signed-off-by: Joakim Tjernlund [EMAIL PROTECTED] [SNIP patch sent last Friday] Since this is my last week before vacation, I would really like to get feedback on this patch sooner than later :) Jocke - 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 07/12] use a dynamic pool of sk_buffs to keep up with fast targets
On Tue, 26 Jun 2007 14:50:11 -0400 Ed L. Cashin [EMAIL PROTECTED] wrote:
Use a dynamic pool of sk_buffs to keep up with fast targets.
That's far too skimpy a description of what this patch is doing, what it is
for, what makes AOE need this functionality, etc.
My initial thought is that if there is a legitimate need for this new capability
then it should be made available to other parts of the kernel rather than being
private to the AEO driver.
But 12 words is not enough information for us to make that judgement.
I have one lower-level comment way down below:
Signed-off-by: Ed L. Cashin [EMAIL PROTECTED]
---
drivers/block/aoe/aoe.h|5 ++
drivers/block/aoe/aoecmd.c | 129
+---
drivers/block/aoe/aoedev.c | 51 +++---
3 files changed, 134 insertions(+), 51 deletions(-)
diff --git a/drivers/block/aoe/aoe.h b/drivers/block/aoe/aoe.h
index 7fa86dd..55c2f08 100644
--- a/drivers/block/aoe/aoe.h
+++ b/drivers/block/aoe/aoe.h
@@ -98,6 +98,7 @@ enum {
MIN_BUFS = 16,
NTARGETS = 8,
NAOEIFS = 8,
+ NSKBPOOLMAX = 128,
TIMERTICK = HZ / 10,
MINTIMER = HZ 2,
@@ -147,6 +148,7 @@ struct aoetgt {
u16 useme;
ulong lastwadj; /* last window adjustment */
int wpkts, rpkts;
+int dataref;
};
struct aoedev {
@@ -168,6 +170,9 @@ struct aoedev {
spinlock_t lock;
struct sk_buff *sendq_hd; /* packets needing to be sent, list head */
struct sk_buff *sendq_tl;
+ struct sk_buff *skbpool_hd;
+ struct sk_buff *skbpool_tl;
+ int nskbpool;
mempool_t *bufpool; /* for deadlock-free Buf allocation */
struct list_head bufq; /* queue of bios to work on */
struct buf *inprocess; /* the one we're currently working on */
diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
index 62ba58c..89df9de 100644
--- a/drivers/block/aoe/aoecmd.c
+++ b/drivers/block/aoe/aoecmd.c
@@ -105,43 +105,102 @@ ifrotate(struct aoetgt *t)
}
}
+static void
+skb_pool_put(struct aoedev *d, struct sk_buff *skb)
+{
+ if (!d-skbpool_hd)
+ d-skbpool_hd = skb;
+ else
+ d-skbpool_tl-next = skb;
+ d-skbpool_tl = skb;
+}
+
+static struct sk_buff *
+skb_pool_get(struct aoedev *d)
+{
+ struct sk_buff *skb;
+
+ skb = d-skbpool_hd;
+ if (skb)
+ if (atomic_read(skb_shinfo(skb)-dataref) == 1) {
+ d-skbpool_hd = skb-next;
+ skb-next = NULL;
+ return skb;
+ }
+ if (d-nskbpool NSKBPOOLMAX)
+ if ((skb = new_skb(ETH_ZLEN))) {
+ d-nskbpool++;
+ return skb;
+ }
+ return NULL;
+}
+
+/* freeframe is where we do our load balancing so it's a little hairy. */
static struct frame *
freeframe(struct aoedev *d)
{
- struct frame *f, *e;
+ struct frame *f, *e, *rf;
struct aoetgt **t;
- ulong n;
+ struct sk_buff *skb;
if (d-targets[0] == NULL) {/* shouldn't happen, but I'm paranoid */
printk(KERN_ERR aoe: NULL TARGETS!\n);
return NULL;
}
- t = d-targets;
- do {
+ t = d-tgt;
+ t++;
+ if (t = d-targets[NTARGETS] || !*t)
+ t = d-targets;
+ for (;;) {
+ if ((*t)-nout (*t)-maxout)
if (t != d-htgt)
- if ((*t)-ifp-nd)
- if ((*t)-nout (*t)-maxout) {
- n = (*t)-nframes;
+ if ((*t)-ifp-nd) {
+ rf = NULL;
f = (*t)-frames;
- e = f + n;
+ e = f + (*t)-nframes;
for (; fe; f++) {
if (f-tag != FREETAG)
continue;
- if (atomic_read(skb_shinfo(f-skb)-dataref)
!= 1) {
- n--;
+ skb = f-skb;
+ if (!skb)
+ if (!(f-skb = skb = new_skb(ETH_ZLEN)))
+ continue;
+ if (atomic_read(skb_shinfo(skb)-dataref) !=
1) {
+ if (!rf)
+ rf = f;
continue;
}
- skb_shinfo(f-skb)-nr_frags = f-skb-data_len
= 0;
- skb_trim(f-skb, 0);
+gotone: skb_shinfo(skb)-nr_frags =
skb-data_len = 0;
+ skb_trim(skb, 0);
d-tgt = t;
ifrotate(*t);
return f;
}
- if (n == 0) /* slow polling network card */
+ /* Work can be
Re: [PATCH 07/12] use a dynamic pool of sk_buffs to keep up with fast targets
From: Andrew Morton [EMAIL PROTECTED] Date: Mon, 2 Jul 2007 21:36:36 -0700 My initial thought is that if there is a legitimate need for this new capability then it should be made available to other parts of the kernel rather than being private to the AEO driver. Absolutely. We even used to have something like this on a per-cpu basis but using generic SLAB is so much better for caching and NUMA that we got rid of that. Every sk_buff private quicklist pool implementation you see should essentially be NAK'd from the get go, it's meaningless and if it's really needed one should investigate why SKB allocations become such a problem instead of papering over the issue. :-) - 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 8/9] [TCP]: Reduce sacked_out with reno when purging write_queue
From: Ilpo_Järvinen [EMAIL PROTECTED] Date: Sat, 26 May 2007 11:36:01 +0300 Previously TCP had a transitional state during which reno counted segments that are already below the current window into sacked_out, which is now prevented. Re-try now unconditional S+L catching (I wonder if we could get that BUG_ON place pinpointed more exactly in oops because now inlining makes it lose its original context as they always seem to be in tcp_ack, #define helps?). Beware, this change is not a trivial one and might have some unexpected side-effects under obscure conditions since state tracking is to happen much later on and the reno sack counting was highly depending on the current state. This approach conservatively calls just remove_sack and leaves reset_sack() calls alone. The best solution to the whole problem would be to first calculate the new sacked_out fully (this patch does not move reno_sack_reset calls from original sites and thus does not implement this). However, that would require very invasive change to fastretrans_alert (perhaps even slicing it to two halves). Alternatively, all callers of tcp_packets_in_flight (i.e., users that depend on sacked_out) should be postponed until the new sacked_out has been calculated but it isn't any simpler alternative. Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] So basically the idea behind this patch is to do the update of the fake RENO sakcs in clean_rtx_queue instead of fixing it up at the very last moment right before we invoke tcp_try_to_undo_partial(). I like this patch and I can't find any holes in the idea. But some things have changed in the meantime and this patch (and probably 9/9 too) don't apply cleanly. Could you respin these against current tcp-2.6 so I can apply them? Thanks. - 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 3/9] [TCP]: Tighten tcp_sock's belt, drop left_out
From: Ilpo_Järvinen [EMAIL PROTECTED] Date: Thu, 31 May 2007 19:31:21 +0300 (EEST) (i.e, how does it show up in oops if tcp_verify_left_out looks like this): #define tcp_verify_left_out(tp) BUG_ON(...) ...does it still point to the tcp.h line then or to the tcp_sync_left_out(tp) @ line in tcp_input.c? ...I'll test that later on by myself in case you don't know the answer. Yes a define would make the BUG appear in the function it gets used in. Depending upon the configuration and the implementation of BUG() the same might happen for inline functions too. For example, if the BUG() is configured in non-verbose mode and is implemented using a trap instruction or __builtin_trap(). But you cannot depend upon this universally of course. - 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: Suspicious fackets_out handling
From: Ilpo_Järvinen [EMAIL PROTECTED] Date: Fri, 1 Jun 2007 15:17:00 +0300 (EEST) On Thu, 31 May 2007, David Miller wrote: Is it possible to update fastpath_cnt_hint properly perhaps? I think that would be valid and even accurate as it can checks skb's seq against fastpath_skb_hint-seq. I'm in a hurry and will be a week out of reach of internet connectivity but here's quick attempt to deal with this cleanly. Compile tested (be extra careful with this one, it's done i a hurry :-)), consider to net-2.6. Considering the marginality of this issue, stable might really be an overkill for this one, only a remotely valid concern comes to my mind in this case: possibility of fackets_out packet_out might not be dealt that cleanly everywhere (but I'm sure that you can come to a good decicion about it): [PATCH] [TCP]: SACK fastpath did override adjusted fackets_out Do same adjustment to SACK fastpath counters provided that they're valid. Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] Since the case is marginal and the patch does need some testing I'm putting this into net-2.6.23 for now. - 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 tcp-2.6 1/3] [TCP]: Add tcp_dec_pcount_approx int variant
From: Ilpo_Järvinen [EMAIL PROTECTED] Date: Fri, 15 Jun 2007 14:10:28 +0300 From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= [EMAIL PROTECTED] Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] Applied to tcp-2.6 - 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] [TCP]: Fix logic breakage due to DSACK separation
From: Ilpo_Järvinen [EMAIL PROTECTED] Date: Sat, 16 Jun 2007 02:04:25 +0300 (EEST) There are still some things I must think carefully in sacktag processing since it does not validate start_seq and end_seq at all which can be abused currently at least in tcp-2.6. ...I would rather put end to the whole russian roulette in tcp-2.6 sacktag rather than fix/think individual cases and leave future modifications of it similarily hazardous. It's not very clear to me how to handle all possible cases of invalid SACK blocks though, perhaps TCP should just ignore such sack blocks without doing any processing based on them, i.e., ignore them whenever start_seq-end_seq does not fully fit to snd_una-snd_nxt (expect DSACK of course, which should be processed if it's between undo_marker-snd_nxt). Do you have any thoughts about this? I agree. This is a problem that basically every single TCP stack out there right now is vulnerable to, lots of cpu processing for invalid or maliciously created SACK blocks. This is why I even considered the RB-Tree stuff at all. Therefore the earlier we toss out bad SACK blocks the better, and thus I agree with a scheme that does validation at the earliest stage possible as you seem to be suggesting. - 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] mac80211: Set low initial rate in rc80211_simple
From: John W. Linville [EMAIL PROTECTED] Date: Mon, 11 Jun 2007 21:24:11 -0400 From: Larry Finger [EMAIL PROTECTED] The initial rate for STA's using rc80211_simple is set to the last rate in the rate table. For situations for which the signal is weak, the rate may be too high for authentication and association. Although the rc80211_simple module will adjust the speed, the response may not be fast enough for a successful connection. This modification sets the initial rate to the lowest supported value. Signed-off-by: Larry Finger [EMAIL PROTECTED] Signed-off-by: Johannes Berg [EMAIL PROTECTED] Signed-off-by: John W. Linville [EMAIL PROTECTED] Applied to net-2.6.23 - 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] mac80211: Add support for SIOCGIWRATE ioctl to provide rate information
From: John W. Linville [EMAIL PROTECTED] Date: Mon, 11 Jun 2007 21:23:19 -0400 From: Larry Finger [EMAIL PROTECTED] At present, transmission rate information for mac80211 is available only if verbose debugging is turned on, and then only in the logs. This patch implements the SIOCGIWRATE ioctl, which adds the current transmission rate to the output of iwconfig. Signed-off-by: Larry Finger [EMAIL PROTECTED] Signed-off-by: John W. Linville [EMAIL PROTECTED] This change appears to already be in the tree. - 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] pktgen IPSEC 1/4: Centralize pktgen packet overhead management
From: jamal [EMAIL PROTECTED] Date: Tue, 12 Jun 2007 08:00:28 -0400 commit 38477d7ddfa58f58cce99bc902b4c18883647a71 Author: Jamal Hadi Salim [EMAIL PROTECTED] Date: Tue Jun 12 06:43:00 2007 -0400 [PKTGEN] Centralize packet overhead tracking Track the extra packet overhead for VLAN tags, MPLS, IPSEC etc Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED] Applied. - 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: Resend: [PATCH] pktgen IPSEC 3/4: Introduce xfrm SAD only lookup
From: jamal [EMAIL PROTECTED] Date: Tue, 12 Jun 2007 19:06:03 -0400 commit 4fe3190756589ef8155eb97fe725f2564f1fc77d Author: Jamal Hadi Salim [EMAIL PROTECTED] Date: Tue Jun 12 12:35:39 2007 -0400 [XFRM] Introduce standalone SAD lookup This allows other in-kernel functions to do SAD lookups. The only known user at the moment is pktgen. Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED] Applied. - 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: Resend: [PATCH] pktgen IPSEC 4/4: Add IPSEC support to pktgen
From: jamal [EMAIL PROTECTED] Date: Tue, 12 Jun 2007 19:08:39 -0400 commit bfd389bba7654aa118f0949ff0de45a3bce9700c Author: Jamal Hadi Salim [EMAIL PROTECTED] Date: Tue Jun 12 18:59:33 2007 -0400 [PKTGEN] IPSEC support Added transport mode ESP support for starters. I will send more of these modes and types once i have resolved the tunnel mode isses. Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED] Also applied, thanks 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: [NET_SCHED 01/04]: Remove CONFIG_NET_ESTIMATOR option
From: Patrick McHardy [EMAIL PROTECTED] Date: Tue, 19 Jun 2007 17:02:19 +0200 (MEST) [NET_SCHED]: Remove CONFIG_NET_ESTIMATOR option The generic estimator is always built in anways and all the config options does is prevent including a minimal amount of code for setting it up. Additionally the option is already automatically selected for most cases. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Applied, thanks Patrick. - 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
