* Re: tbench regression in 2.6.25-rc1
From: Eric Dumazet @ 2008-02-18 10:11 UTC (permalink / raw)
To: Zhang, Yanmin; +Cc: David Miller, herbert, linux-kernel, netdev
In-Reply-To: <1203322358.3027.200.camel@ymzhang>
On Mon, 18 Feb 2008 16:12:38 +0800
"Zhang, Yanmin" <yanmin_zhang@linux.intel.com> wrote:
> On Fri, 2008-02-15 at 15:22 -0800, David Miller wrote:
> > From: Eric Dumazet <dada1@cosmosbay.com>
> > Date: Fri, 15 Feb 2008 15:21:48 +0100
> >
> > > On linux-2.6.25-rc1 x86_64 :
> > >
> > > offsetof(struct dst_entry, lastuse)=0xb0
> > > offsetof(struct dst_entry, __refcnt)=0xb8
> > > offsetof(struct dst_entry, __use)=0xbc
> > > offsetof(struct dst_entry, next)=0xc0
> > >
> > > So it should be optimal... I dont know why tbench prefers __refcnt being
> > > on 0xc0, since in this case lastuse will be on a different cache line...
> > >
> > > Each incoming IP packet will need to change lastuse, __refcnt and __use,
> > > so keeping them in the same cache line is a win.
> > >
> > > I suspect then that even this patch could help tbench, since it avoids
> > > writing lastuse...
> >
> > I think your suspicions are right, and even moreso
> > it helps to keep __refcnt out of the same cache line
> > as input/output/ops which are read-almost-entirely :-
> I think you are right. The issue is these three variables sharing the same cache line
> with input/output/ops.
>
> > )
> >
> > I haven't done an exhaustive analysis, but it seems that
> > the write traffic to lastuse and __refcnt are about the
> > same. However if we find that __refcnt gets hit more
> > than lastuse in this workload, it explains the regression.
> I also think __refcnt is the key. I did a new testing by adding 2 unsigned long
> pading before lastuse, so the 3 members are moved to next cache line. The performance is
> recovered.
>
> How about below patch? Almost all performance is recovered with the new patch.
>
> Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>
>
> ---
>
> --- linux-2.6.25-rc1/include/net/dst.h 2008-02-21 14:33:43.000000000 +0800
> +++ linux-2.6.25-rc1_work/include/net/dst.h 2008-02-21 14:36:22.000000000 +0800
> @@ -52,11 +52,10 @@ struct dst_entry
> unsigned short header_len; /* more space at head required */
> unsigned short trailer_len; /* space to reserve at tail */
>
> - u32 metrics[RTAX_MAX];
> - struct dst_entry *path;
> -
> - unsigned long rate_last; /* rate limiting for ICMP */
> unsigned int rate_tokens;
> + unsigned long rate_last; /* rate limiting for ICMP */
> +
> + struct dst_entry *path;
>
> #ifdef CONFIG_NET_CLS_ROUTE
> __u32 tclassid;
> @@ -70,10 +69,12 @@ struct dst_entry
> int (*output)(struct sk_buff*);
>
> struct dst_ops *ops;
> -
> - unsigned long lastuse;
> +
> + u32 metrics[RTAX_MAX];
> +
> atomic_t __refcnt; /* client references */
> int __use;
> + unsigned long lastuse;
> union {
> struct dst_entry *next;
> struct rtable *rt_next;
>
>
Well, after this patch, we grow dst_entry by 8 bytes :
sizeof(struct dst_entry)=0xd0
offsetof(struct dst_entry, input)=0x68
offsetof(struct dst_entry, output)=0x70
offsetof(struct dst_entry, __refcnt)=0xb4
offsetof(struct dst_entry, lastuse)=0xc0
offsetof(struct dst_entry, __use)=0xb8
sizeof(struct rtable)=0x140
So we dirty two cache lines instead of one, unless your cpu have 128 bytes cache lines ?
I am quite suprised that my patch to not change lastuse if already set to jiffies changes nothing...
If you have some time, could you also test this (unrelated) patch ?
We can avoid dirty all the time a cache line of loopback device.
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index f2a6e71..0a4186a 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -150,7 +150,10 @@ static int loopback_xmit(struct sk_buff *skb, struct net_device *dev)
return 0;
}
#endif
- dev->last_rx = jiffies;
+#ifdef CONFIG_SMP
+ if (dev->last_rx != jiffies)
+#endif
+ dev->last_rx = jiffies;
/* it's OK to use per_cpu_ptr() because BHs are off */
pcpu_lstats = netdev_priv(dev);
^ permalink raw reply related
* Re: [PATCH 2.6.24 1/1] sch_htb: fix "too many events" situation
From: David Miller @ 2008-02-18 10:43 UTC (permalink / raw)
To: devik; +Cc: linux-kernel, kaber, netdev
In-Reply-To: <47B95909.8060202@cdi.cz>
From: Martin Devera <devik@cdi.cz>
Date: Mon, 18 Feb 2008 11:08:09 +0100
> Like
> max_jiff = jiffies+2; /* not +1 at we could be at +0.9999 now */
> while (jiffies<max_jiff) do_hard_potentionaly_long_work();
> if (more_work) schedule_to_next_jiffie();
>
> This will keep event queue work load under 66% of system load which
> seems reasonable to me.
>
> Would you accept such solution ?
Sure.
^ permalink raw reply
* [PATCH][IBMVETH]: Use single_open instead of manual manipulations.
From: Pavel Emelyanov @ 2008-02-18 10:55 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Netdev List, Brian King
The code opening proc entry for each device makes the
same thing, as the single_open does, so remove the
unneeded code.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
index 57772be..bb31e09 100644
--- a/drivers/net/ibmveth.c
+++ b/drivers/net/ibmveth.c
@@ -1259,26 +1259,7 @@ static void ibmveth_proc_unregister_driver(void)
remove_proc_entry(IBMVETH_PROC_DIR, init_net.proc_net);
}
-static void *ibmveth_seq_start(struct seq_file *seq, loff_t *pos)
-{
- if (*pos == 0) {
- return (void *)1;
- } else {
- return NULL;
- }
-}
-
-static void *ibmveth_seq_next(struct seq_file *seq, void *v, loff_t *pos)
-{
- ++*pos;
- return NULL;
-}
-
-static void ibmveth_seq_stop(struct seq_file *seq, void *v)
-{
-}
-
-static int ibmveth_seq_show(struct seq_file *seq, void *v)
+static int ibmveth_show(struct seq_file *seq, void *v)
{
struct ibmveth_adapter *adapter = seq->private;
char *current_mac = ((char*) &adapter->netdev->dev_addr);
@@ -1302,27 +1283,10 @@ static int ibmveth_seq_show(struct seq_file *seq, void *v)
return 0;
}
-static struct seq_operations ibmveth_seq_ops = {
- .start = ibmveth_seq_start,
- .next = ibmveth_seq_next,
- .stop = ibmveth_seq_stop,
- .show = ibmveth_seq_show,
-};
static int ibmveth_proc_open(struct inode *inode, struct file *file)
{
- struct seq_file *seq;
- struct proc_dir_entry *proc;
- int rc;
-
- rc = seq_open(file, &ibmveth_seq_ops);
- if (!rc) {
- /* recover the pointer buried in proc_dir_entry data */
- seq = file->private_data;
- proc = PDE(inode);
- seq->private = proc->data;
- }
- return rc;
+ return single_open(file, ibmveth_show, PDE(inode)->data);
}
static const struct file_operations ibmveth_proc_fops = {
@@ -1330,7 +1294,7 @@ static const struct file_operations ibmveth_proc_fops = {
.open = ibmveth_proc_open,
.read = seq_read,
.llseek = seq_lseek,
- .release = seq_release,
+ .release = single_release,
};
static void ibmveth_proc_register_adapter(struct ibmveth_adapter *adapter)
^ permalink raw reply related
* [PATCH][IPV6]: Use BUG_ON instead of if + BUG in fib6_del_route.
From: Pavel Emelyanov @ 2008-02-18 12:50 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index f93407c..bab72b6 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -1151,7 +1151,7 @@ static void fib6_del_route(struct fib6_node *fn, struct rt6_info **rtp,
fn = fn->parent;
}
/* No more references are possible at this point. */
- if (atomic_read(&rt->rt6i_ref) != 1) BUG();
+ BUG_ON(atomic_read(&rt->rt6i_ref) != 1);
}
inet6_rt_notify(RTM_DELROUTE, rt, info);
^ permalink raw reply related
* Re: [2.6.25-rc2, 2.6.24-rc8] page allocation failure...
From: Andrew Morton @ 2008-02-18 12:58 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: Linux Kernel, netdev, Auke Kok
In-Reply-To: <6278d2220802170520k2ddf9072x386e4a9e3062f4da@mail.gmail.com>
On Sun, 17 Feb 2008 13:20:59 +0000 "Daniel J Blueman" <daniel.blueman@gmail.com> wrote:
> I'm still hitting this with e1000e on 2.6.25-rc2, 10 times again.
>
> It's clearly non-fatal, but then do we expect it to occur?
>
> Daniel
>
> --- [dmesg]
>
> [ 1250.822786] swapper: page allocation failure. order:3, mode:0x4020
> [ 1250.822786] Pid: 0, comm: swapper Not tainted 2.6.25-rc2-119 #2
> [ 1250.822786]
> [ 1250.822786] Call Trace:
> [ 1250.822786] <IRQ> [<ffffffff8025fe9e>] __alloc_pages+0x34e/0x3a0
> [ 1250.822786] [<ffffffff8048c6df>] ? __netdev_alloc_skb+0x1f/0x40
> [ 1250.822786] [<ffffffff8027acc2>] __slab_alloc+0x102/0x3d0
> [ 1250.822786] [<ffffffff8048c6df>] ? __netdev_alloc_skb+0x1f/0x40
> [ 1250.822786] [<ffffffff8027b8cb>] __kmalloc_track_caller+0x7b/0xc0
> [ 1250.822786] [<ffffffff8048b74f>] __alloc_skb+0x6f/0x160
> [ 1250.822786] [<ffffffff8048c6df>] __netdev_alloc_skb+0x1f/0x40
> [ 1250.822786] [<ffffffff8042652d>] e1000_alloc_rx_buffers+0x1ed/0x260
> [ 1250.822786] [<ffffffff80426b5a>] e1000_clean_rx_irq+0x22a/0x330
> [ 1250.822786] [<ffffffff80422981>] e1000_clean+0x1e1/0x540
> [ 1250.822786] [<ffffffff8024b7a5>] ? tick_program_event+0x45/0x70
> [ 1250.822786] [<ffffffff804930ba>] net_rx_action+0x9a/0x150
> [ 1250.822786] [<ffffffff802336b4>] __do_softirq+0x74/0xf0
> [ 1250.822786] [<ffffffff8020c5fc>] call_softirq+0x1c/0x30
> [ 1250.822786] [<ffffffff8020eaad>] do_softirq+0x3d/0x80
> [ 1250.822786] [<ffffffff80233635>] irq_exit+0x85/0x90
> [ 1250.822786] [<ffffffff8020eba5>] do_IRQ+0x85/0x100
> [ 1250.822786] [<ffffffff8020a5b0>] ? mwait_idle+0x0/0x50
> [ 1250.822786] [<ffffffff8020b981>] ret_from_intr+0x0/0xa
> [ 1250.822786] <EOI> [<ffffffff8020a5f5>] ? mwait_idle+0x45/0x50
> [ 1250.822786] [<ffffffff80209a92>] ? enter_idle+0x22/0x30
> [ 1250.822786] [<ffffffff8020a534>] ? cpu_idle+0x74/0xa0
> [ 1250.822786] [<ffffffff80527825>] ? rest_init+0x55/0x60
They're regularly reported with e1000 too - I don't think aything really
changed.
e1000 has this crazy problem where because of a cascade of follies (mainly
borked hardware) it has to do a 32kb allocation for a 9kb(?) packet. It
would be sad if that was carried over into e1000e?
^ permalink raw reply
* Re: [2.6.25-rc2] e100: Trying to free already-free IRQ 11 during suspend ...
From: Andrew Morton @ 2008-02-18 13:01 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: e1000-devel, netdev, linux-kernel
In-Reply-To: <200802171536.51695.arvidjaar@mail.ru>
On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> ... and possibly reboot/poweroff (it flows by too fast to be legible).
>
> [ 8803.850634] ACPI: Preparing to enter system sleep state S3
> [ 8803.853141] Suspending console(s)
> [ 8805.287505] serial 00:09: disabled
> [ 8805.291564] Trying to free already-free IRQ 11
> [ 8805.291579] Pid: 6920, comm: pm-suspend Not tainted 2.6.25-rc2-1avb #2
> [ 8805.291628] [<c0152127>] free_irq+0xb7/0x130
> [ 8805.291675] [<c024bd80>] e100_suspend+0xc0/0x100
> [ 8805.291724] [<c01eaa36>] pci_device_suspend+0x26/0x70
> [ 8805.291747] [<c0243674>] suspend_device+0x94/0xd0
> [ 8805.291763] [<c02439a3>] device_suspend+0x153/0x240
> [ 8805.291784] [<c014314f>] suspend_devices_and_enter+0x4f/0xf0
> [ 8805.291808] [<c0143a5f>] ? freeze_processes+0x3f/0x80
> [ 8805.291825] [<c01432fa>] enter_state+0xaa/0x140
> [ 8805.291840] [<c014341f>] state_store+0x8f/0xd0
> [ 8805.291852] [<c0143390>] ? state_store+0x0/0xd0
> [ 8805.291866] [<c01d3404>] kobj_attr_store+0x24/0x30
> [ 8805.291901] [<c01b547b>] sysfs_write_file+0xbb/0x110
> [ 8805.291936] [<c0177d79>] vfs_write+0x99/0x130
> [ 8805.291963] [<c01b53c0>] ? sysfs_write_file+0x0/0x110
> [ 8805.291979] [<c01782fd>] sys_write+0x3d/0x70
> [ 8805.291998] [<c010409a>] sysenter_past_esp+0x5f/0xa5
> [ 8805.292038] =======================
> [ 8805.347640] ACPI: PCI interrupt for device 0000:00:06.0 disabled
> [ 8805.361128] ACPI: PCI interrupt for device 0000:00:02.0 disabled
> [ 8805.376670] hwsleep-0322 [00] enter_sleep_state : Entering sleep state [S3]
> [ 8805.376670] Back to C!
>
> Interface is unused normally (only for netconsole sometimes). dmesg and config
> attached.
Does reverting this:
commit 8543da6672b0994921f014f2250e27ae81645580
Author: Auke Kok <auke-jan.h.kok@intel.com>
Date: Wed Dec 12 16:30:42 2007 -0800
e100: free IRQ to remove warningwhenrebooting
with this patch:
--- a/drivers/net/e100.c~revert-1
+++ a/drivers/net/e100.c
@@ -2804,9 +2804,8 @@ static int e100_suspend(struct pci_dev *
pci_enable_wake(pdev, PCI_D3cold, 0);
}
- free_irq(pdev->irq, netdev);
-
pci_disable_device(pdev);
+ free_irq(pdev->irq, netdev);
pci_set_power_state(pdev, PCI_D3hot);
return 0;
@@ -2848,8 +2847,6 @@ static void e100_shutdown(struct pci_dev
pci_enable_wake(pdev, PCI_D3cold, 0);
}
- free_irq(pdev->irq, netdev);
-
pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
}
_
fix it?
> Hmm ... after resume device has disappeared at all ...
>
> {pts/1}% cat /proc/interrupts
> CPU0
> 0: 1290492 XT-PIC-XT timer
> 1: 6675 XT-PIC-XT i8042
> 2: 0 XT-PIC-XT cascade
> 3: 2 XT-PIC-XT
> 4: 2 XT-PIC-XT
> 5: 3 XT-PIC-XT
> 7: 4 XT-PIC-XT irda0
> 8: 0 XT-PIC-XT rtc0
> 9: 583 XT-PIC-XT acpi
> 10: 2 XT-PIC-XT
> 11: 31483 XT-PIC-XT yenta, yenta, yenta, ohci_hcd:usb1, ALI 5451, pcmcia0.0
> 12: 28070 XT-PIC-XT i8042
> 14: 21705 XT-PIC-XT ide0
> 15: 82123 XT-PIC-XT ide1
> NMI: 0 Non-maskable interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
I hope that's not a separate bug...
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
From: Andrew Morton @ 2008-02-18 13:00 UTC (permalink / raw)
To: Chris Rankin; +Cc: linux-acpi, linux-kernel, netdev, Stephen Hemminger
In-Reply-To: <23590.97305.qm@web52910.mail.re2.yahoo.com>
On Sun, 17 Feb 2008 00:54:08 +0000 (GMT) Chris Rankin <rankincj@yahoo.com> wrote:
> [Try this again, except this time I'll force the attachment as inline text!]
>
> Hi,
>
> I have managed to boot 2.6.24.1 on this machine, with the NMI watchdog enabled, by using the
> "acpi=noirq" option. (There does seem to be some unhappiness with bridge symlinks in sysfs,
> though.)
>
> ...
>
> sysfs: duplicate filename 'bridge' can not be created
> WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> [<c0105990>] show_trace+0x12/0x14
> [<c010613d>] dump_stack+0x6c/0x72
> [<c01991bf>] sysfs_add_one+0x57/0xbc
> [<c0199e41>] sysfs_create_link+0xc2/0x10d
> [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> [<c034016c>] pci_legacy_init+0x56/0xe3
> [<c03274e1>] kernel_init+0x157/0x2c3
> [<c0104c83>] kernel_thread_helper+0x7/0x10
> =======================
> pci 0000:00:01.0: Error creating sysfs bridge symlink, continuing...
> sysfs: duplicate filename 'bridge' can not be created
> WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> [<c0105990>] show_trace+0x12/0x14
> [<c010613d>] dump_stack+0x6c/0x72
> [<c01991bf>] sysfs_add_one+0x57/0xbc
> [<c0199e41>] sysfs_create_link+0xc2/0x10d
> [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> [<c01bae82>] pci_bus_add_devices+0xa5/0x103
> [<c034016c>] pci_legacy_init+0x56/0xe3
> [<c03274e1>] kernel_init+0x157/0x2c3
> [<c0104c83>] kernel_thread_helper+0x7/0x10
> =======================
I have a vague feeling that this was fixed, perhaps in 2.6.24.x?
^ permalink raw reply
* Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
From: Chris Rankin @ 2008-02-18 13:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-acpi, linux-kernel, netdev, Stephen Hemminger
In-Reply-To: <20080218050049.12bcc596.akpm@linux-foundation.org>
--- Andrew Morton <akpm@linux-foundation.org> wrote:
> > sysfs: duplicate filename 'bridge' can not be created
> > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> > [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> > [<c0105990>] show_trace+0x12/0x14
> > [<c010613d>] dump_stack+0x6c/0x72
> > [<c01991bf>] sysfs_add_one+0x57/0xbc
> > [<c0199e41>] sysfs_create_link+0xc2/0x10d
> > [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> > [<c034016c>] pci_legacy_init+0x56/0xe3
> > [<c03274e1>] kernel_init+0x157/0x2c3
> > [<c0104c83>] kernel_thread_helper+0x7/0x10
> > =======================
> > pci 0000:00:01.0: Error creating sysfs bridge symlink, continuing...
> > sysfs: duplicate filename 'bridge' can not be created
> > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> > [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> > [<c0105990>] show_trace+0x12/0x14
> > [<c010613d>] dump_stack+0x6c/0x72
> > [<c01991bf>] sysfs_add_one+0x57/0xbc
> > [<c0199e41>] sysfs_create_link+0xc2/0x10d
> > [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> > [<c01bae82>] pci_bus_add_devices+0xa5/0x103
> > [<c034016c>] pci_legacy_init+0x56/0xe3
> > [<c03274e1>] kernel_init+0x157/0x2c3
> > [<c0104c83>] kernel_thread_helper+0x7/0x10
> > =======================
>
> I have a vague feeling that this was fixed, perhaps in 2.6.24.x?
Obviously not in 2.6.24.1, and I thought that 2.6.24.2 just added the fix for the vmsplice
exploit. So unless 2.6.24.3 has been released...?
Cheers,
Chris
___________________________________________________________
Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/
^ permalink raw reply
* [patch 0/1] s390: claw - More use DIV_ROUND_UP
From: Ursula Braun @ 2008-02-18 13:41 UTC (permalink / raw)
To: jgarzik, netdev, linux-s390, julia
--
Jeff,
this patch is intended for 2.6.25.
It makes use of the DIV_ROUND_UP function as proposed by Julia Lawall.
Regards, Ursula Braun
^ permalink raw reply
* [patch 1/1] claw: make use of DIV_ROUND_UP
From: Ursula Braun @ 2008-02-18 13:41 UTC (permalink / raw)
To: jgarzik, netdev, linux-s390, julia
In-Reply-To: <20080218134154.893427000@linux.vnet.ibm.com>
[-- Attachment #1: 715-claw-div.diff --]
[-- Type: text/plain, Size: 3391 bytes --]
From: Julia Lawall <julia@diku.dk>
The kernel.h macro DIV_ROUND_UP performs the computation
(((n) + (d) - 1) / (d)) but is perhaps more readable.
Signed-off-by: Ursula Braun <braunu@de.ibm.com>
---
drivers/s390/net/claw.c | 39 ++++++++++++++++++---------------------
1 file changed, 18 insertions(+), 21 deletions(-)
Index: linux-2.6-uschi/drivers/s390/net/claw.c
===================================================================
--- linux-2.6-uschi.orig/drivers/s390/net/claw.c
+++ linux-2.6-uschi/drivers/s390/net/claw.c
@@ -1851,8 +1851,7 @@ claw_hw_tx(struct sk_buff *skb, struct n
}
}
/* See how many write buffers are required to hold this data */
- numBuffers= ( skb->len + privptr->p_env->write_size - 1) /
- ( privptr->p_env->write_size);
+ numBuffers = DIV_ROUND_UP(skb->len, privptr->p_env->write_size);
/* If that number of buffers isn't available, give up for now */
if (privptr->write_free_count < numBuffers ||
@@ -2114,8 +2113,7 @@ init_ccw_bk(struct net_device *dev)
*/
ccw_blocks_perpage= PAGE_SIZE / CCWBK_SIZE;
ccw_pages_required=
- (ccw_blocks_required+ccw_blocks_perpage -1) /
- ccw_blocks_perpage;
+ DIV_ROUND_UP(ccw_blocks_required, ccw_blocks_perpage);
#ifdef DEBUGMSG
printk(KERN_INFO "%s: %s() > ccw_blocks_perpage=%d\n",
@@ -2131,30 +2129,29 @@ init_ccw_bk(struct net_device *dev)
* provide good performance. With packing buffers support 32k
* buffers are used.
*/
- if (privptr->p_env->read_size < PAGE_SIZE) {
- claw_reads_perpage= PAGE_SIZE / privptr->p_env->read_size;
- claw_read_pages= (privptr->p_env->read_buffers +
- claw_reads_perpage -1) / claw_reads_perpage;
+ if (privptr->p_env->read_size < PAGE_SIZE) {
+ claw_reads_perpage = PAGE_SIZE / privptr->p_env->read_size;
+ claw_read_pages = DIV_ROUND_UP(privptr->p_env->read_buffers,
+ claw_reads_perpage);
}
else { /* > or equal */
- privptr->p_buff_pages_perread=
- (privptr->p_env->read_size + PAGE_SIZE - 1) / PAGE_SIZE;
- claw_read_pages=
- privptr->p_env->read_buffers * privptr->p_buff_pages_perread;
+ privptr->p_buff_pages_perread =
+ DIV_ROUND_UP(privptr->p_env->read_size, PAGE_SIZE);
+ claw_read_pages = privptr->p_env->read_buffers *
+ privptr->p_buff_pages_perread;
}
if (privptr->p_env->write_size < PAGE_SIZE) {
- claw_writes_perpage=
- PAGE_SIZE / privptr->p_env->write_size;
- claw_write_pages=
- (privptr->p_env->write_buffers + claw_writes_perpage -1) /
- claw_writes_perpage;
+ claw_writes_perpage =
+ PAGE_SIZE / privptr->p_env->write_size;
+ claw_write_pages = DIV_ROUND_UP(privptr->p_env->write_buffers,
+ claw_writes_perpage);
}
else { /* > or equal */
- privptr->p_buff_pages_perwrite=
- (privptr->p_env->read_size + PAGE_SIZE - 1) / PAGE_SIZE;
- claw_write_pages=
- privptr->p_env->write_buffers * privptr->p_buff_pages_perwrite;
+ privptr->p_buff_pages_perwrite =
+ DIV_ROUND_UP(privptr->p_env->read_size, PAGE_SIZE);
+ claw_write_pages = privptr->p_env->write_buffers *
+ privptr->p_buff_pages_perwrite;
}
#ifdef DEBUGMSG
if (privptr->p_env->read_size < PAGE_SIZE) {
--
^ permalink raw reply
* ipv6 debugging
From: Ferenc Wagner @ 2008-02-18 14:06 UTC (permalink / raw)
To: netdev
Hi,
I'm kindly asking for some debugging tips with the following problem:
a machine is running Linux 2.6.24.2, several 802.1q VLAN-s over
active/backup bonding over two physical interfaces. Everything is
allright, except for after a reboot, there's no IPv6, while IPv4
works. The router's ARP(6) table is empty, the machine doesn't answer
ping6. However, if I start tcpdump -i bond0 ip6, everything is
allright again. There are some indications that after some period
without IPv6 traffic, the same can happen again. Are there known
issues which can exhibit themselves like this? Other very similar
setups don't show this erratic behaviour.
I know that the above doesn't give a fully detailed picture, but
thought that I'd better ask before taking the setup into pieces.
--
Thanks for your thoughts,
Feri.
^ permalink raw reply
* Re: [PATCH 2.6.24-mm1] error compiling net driver NE2000/NE1000
From: Pierre Peiffer @ 2008-02-18 15:04 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev, Alan Cox
In-Reply-To: <20080204131038.699c28c1.akpm@linux-foundation.org>
Hi,
I don't know if I have to warn on this or not, but as I didn't find any
discussion, it's probably better to mention it: the compiling error reported
below (or here: http://lkml.org/lkml/2008/2/4/173 ) does not seem to be
corrected in 2.6.25-rc2.mm1... So, I don't know if a fix is going on somewhere
or if the bug has fallen in a black hole.
(In the original mail, I've proposed a patch as a quick fix, but I don't know if
it can be considered as a definitive correction or not)
Thanks,
P.
Andrew Morton wrote:
> On Mon, 4 Feb 2008 16:29:21 +0100
> Pierre Peiffer <pierre.peiffer@bull.net> wrote:
>
>> Hi,
>>
>> When I compile the kernel 2.6.24-mm1 with:
>> CONFIG_NET_ISA=y
>> CONFIG_NE2000=y
>>
>> I have the following compile error:
>> ...
>> GEN .version
>> CHK include/linux/compile.h
>> UPD include/linux/compile.h
>> CC init/version.o
>> LD init/built-in.o
>> LD .tmp_vmlinux1
>> drivers/built-in.o: In function `ne_block_output':
>> linux-2.6.24-mm1/drivers/net/ne.c:797: undefined reference to `NS8390_init'
>> drivers/built-in.o: In function `ne_drv_resume':
>> linux-2.6.24-mm1/drivers/net/ne.c:858: undefined reference to `NS8390_init'
>> drivers/built-in.o: In function `ne_probe1':
>> linux-2.6.24-mm1/drivers/net/ne.c:539: undefined reference to `NS8390_init'
>> make[1]: *** [.tmp_vmlinux1] Error 1
>> make: *** [sub-make] Error 2
>
> Thanks for reporting this.
>
>> As I saw that the file 8390p.c is compiled for this driver, but not the file
>> 8390.c which contains this function NS8390_init(), I fixed this error with
>> the following patch.
>
> Alan's
> 8390-split-8390-support-into-a-pausing-and-a-non-pausing-driver-core.patch
> would be a prime suspect. I assume this bug isn't present ing mainline or
> in 2.6.24?
>
>> As NS8390p_init() does the same thing than NS8390_init(), I suppose that this is the right fix ?
>>
>> Signed-off-by: Pierre Peiffer <pierre.peiffer@bull.net>
>> ---
>> drivers/net/ne.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> Index: b/drivers/net/ne.c
>> ===================================================================
>> --- a/drivers/net/ne.c
>> +++ b/drivers/net/ne.c
>> @@ -536,7 +536,7 @@ static int __init ne_probe1(struct net_d
>> #ifdef CONFIG_NET_POLL_CONTROLLER
>> dev->poll_controller = eip_poll;
>> #endif
>> - NS8390_init(dev, 0);
>> + NS8390p_init(dev, 0);
>>
>> ret = register_netdev(dev);
>> if (ret)
>> @@ -794,7 +794,7 @@ retry:
>> if (time_after(jiffies, dma_start + 2*HZ/100)) { /* 20ms */
>> printk(KERN_WARNING "%s: timeout waiting for Tx RDC.\n", dev->name);
>> ne_reset_8390(dev);
>> - NS8390_init(dev,1);
>> + NS8390p_init(dev,1);
>> break;
>> }
>>
>> @@ -855,7 +855,7 @@ static int ne_drv_resume(struct platform
>>
>> if (netif_running(dev)) {
>> ne_reset_8390(dev);
>> - NS8390_init(dev, 1);
>> + NS8390p_init(dev, 1);
>> netif_device_attach(dev);
>> }
>> return 0;
>
>
>
>
--
Pierre Peiffer
^ permalink raw reply
* Re: ipv6 debugging
From: Jorge Boncompte [DTI2] @ 2008-02-18 15:02 UTC (permalink / raw)
To: Ferenc Wagner, netdev
In-Reply-To: <87zltyjr50.fsf@tac.ki.iif.hu>
This sounds to me like the same problem that I was having with OSPF, I
think ARP(6) uses multicast ethernet address too. Can you try if the patch
below, that I sent Patrick McHardy some days ago, fixes your problem?
Regards,
Jorge
---
Hi Patrick,
Commit a0a400d79e3dd7843e7e81baa3ef2957bdc292d0 from you
introduced a new field "da_synced" to struct dev_addr_list that is
not properly initialized to 0. So when any of the current users (8021q,
macvlan, mac80211) calls dev_mc_sync/unsync they mess the address
list for both devices.
The attached patch fixed it for me and avoid future problems.
Regards,
Jorge
Signed-off-by: Jorge Boncompte [DTI2] jorge@dti2.net
---
diff --git a/net/core/dev.c b/net/core/dev.c
index 9549417..f1b6708 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2900,7 +2900,7 @@ int __dev_addr_add(struct dev_addr_list **list, int
*count,
}
}
- da = kmalloc(sizeof(*da), GFP_ATOMIC);
+ da = kzalloc(sizeof(*da), GFP_ATOMIC);
if (da == NULL)
return -ENOMEM;
memcpy(da->da_addr, addr, alen);
----- Original Message -----
From: "Ferenc Wagner" <wferi@niif.hu>
To: <netdev@vger.kernel.org>
Sent: Monday, February 18, 2008 3:06 PM
Subject: ipv6 debugging
> Hi,
>
> I'm kindly asking for some debugging tips with the following problem:
> a machine is running Linux 2.6.24.2, several 802.1q VLAN-s over
> active/backup bonding over two physical interfaces. Everything is
> allright, except for after a reboot, there's no IPv6, while IPv4
> works. The router's ARP(6) table is empty, the machine doesn't answer
> ping6. However, if I start tcpdump -i bond0 ip6, everything is
> allright again. There are some indications that after some period
> without IPv6 traffic, the same can happen again. Are there known
> issues which can exhibit themselves like this? Other very similar
> setups don't show this erratic behaviour.
>
> I know that the above doesn't give a fully detailed picture, but
> thought that I'd better ask before taking the setup into pieces.
> --
> Thanks for your thoughts,
> Feri.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply related
* Re: [2.6 patch] remove include/linux/netfilter_ipv4/ipt_SAME.h
From: Patrick McHardy @ 2008-02-18 15:10 UTC (permalink / raw)
To: Adrian Bunk; +Cc: David S. Miller, linux-kernel, netdev
In-Reply-To: <20080217083031.GY3848@cs181133002.pp.htv.fi>
Adrian Bunk wrote:
> This patch removes the no longer used include/linux/netfilter_ipv4/ipt_SAME.h
We kept it around because old iptables binaries need it to build.
The kernel no longer supports it, but people might still wish to
use a distributor-built iptables binary with old kernels. It will
be removed with a number of other headers kept for compatibility
in 1-2 years.
^ permalink raw reply
* Re: [PATCH] net/8021q/vlan_dev.c - Use print_mac
From: Patrick McHardy @ 2008-02-18 15:19 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, bruno, netdev, jgarzik, linux-wireless, linville
In-Reply-To: <1203097370.21308.18.camel@localhost>
Joe Perches wrote:
> On Fri, 2008-02-15 at 02:58 -0800, David Miller wrote:
>> From: Bruno Randolf <bruno@thinktube.com>
>> Date: Fri, 15 Feb 2008 19:48:05 +0900
>>> is there any chance to include a macro like this for printing mac
>> addresses?
>>> its advantage is that it can be used without the need to declare
>> buffers for
>>> print_mac(), for example:
>> We specifically removed this sort of thing, please don't
>> add it back.
Why?
> @@ -404,11 +405,8 @@ static int vlan_dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
>
> pr_debug("%s: about to send skb: %p to dev: %s\n",
> __FUNCTION__, skb, skb->dev->name);
> - pr_debug(" " MAC_FMT " " MAC_FMT " %4hx %4hx %4hx\n",
> - veth->h_dest[0], veth->h_dest[1], veth->h_dest[2],
> - veth->h_dest[3], veth->h_dest[4], veth->h_dest[5],
> - veth->h_source[0], veth->h_source[1], veth->h_source[2],
> - veth->h_source[3], veth->h_source[4], veth->h_source[5],
> + pr_debug(" %s %s %4hx %4hx %4hx\n",
> + print_mac(mac, veth->h_dest), print_mac(mac2, veth->h_source),
This results in print_mac getting called twice per packet even without
debugging. Whats the problem with MAC_FMT?
^ permalink raw reply
* "protocol 0300 is buggy" spam in dmesg when injecting&capturing on same interface
From: Pekka Pietikainen @ 2008-02-18 15:39 UTC (permalink / raw)
To: netdev
When playing with some L2 level fuzzing I started getting lots of
"protocol 0300 is buggy, dev eth3" spew in dmesg. That interface is also
capturing the traffic that's being sent, that's probably why the
dev_queue_xmit_nit codepath is getting called in the first place.
Tested on 2.6.23-as-shipped-in-F8. didn't spot any relevant changes in .24
but can pretty easily verify there too.
Oh. That printk wasn't very easy to find:
if (net_ratelimit())
printk(KERN_CRIT "protocol %04x is "
"buggy, dev %s\n",
and I naturally grepped for "is buggy".
Any ideas? Add a "If it came from AF_PACKET, don't print out anything" to
that if-statement?
^ permalink raw reply
* Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x
From: Ondrej Zary @ 2008-02-18 16:40 UTC (permalink / raw)
To: Grant Grundler; +Cc: jgarzik, Linux Kernel, netdev
In-Reply-To: <20080218032111.GA7970@colo.lackof.org>
On Monday 18 February 2008 04:21:11 Grant Grundler wrote:
> On Wed, Jan 30, 2008 at 09:23:06PM +0100, Ondrej Zary wrote:
> > On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:
> > > Hello,
> > > I was having problems with these FreedomLine cards with Linux before
> > > but tested it thoroughly today. This card uses DEC 21041 chip and has
> > > TP and BNC connectors:
> > >
> > > 00:12.0 Ethernet controller [0200]: Digital Equipment Corporation
> > > DECchip 21041 [Tulip Pass 3] [1011:0014] (rev 21)
> > >
> > >
> > > de2104x driver was loaded automatically by udev and card seemed to
> > > work. Until I disconnected the TP cable and putting it back after a
> > > while. The driver then switched to (non-existing) AUI port and remained
> > > there. I tried to set media to TP using ethtool - and the whole kernel
> > > crashed because of BUG_ON(de_is_running(de));
> > > in de_set_media(). Seems that the driver is unable to stop the DMA in
> > > de_stop_rxtx().
>
> The BUG_ON() is probably fine normally. But the media selection sounds
> broken. It's possible to select the wrong media type with 21040 chip but
> shouldn't be possible with 21041. For 21040 support, see
> de21040_get_media_info(). But de21041_get_srom_info() is expected to
> determine which media
> types are supported from SEPROM "media blocks". My guess is that code
> is broken since it seems to work with de405 driver. If you care to
> work the difference, I'd be happy to make a patch to fix that up.
I don't think that BUG_ON() should be there. It should probably printk a
warning but certainly not crash the whole machine.
> Also, from code review, DE2104X driver still has a few places with
> potential PCI MMIO Write posting issues. Specifically, I was looking
> in de_stop_hw() and de_set_media(). Several other bits of code correctly
> flush MMIO writes: e.g. tulip_read_eeprom().
>
> > > I commented out AUI detection in the driver - this time it switched to
> > > BNC after unplugging the cable and remained there. I also attempted to
> > > reset the chip when de_stop_rxtx failed but failed to do it.
>
> You'd have to basically hardcode only one media type and it's corresponding
> parameters.
That's bad. It just works with de4x5 with any cable at any time.
> > > Then I found that there's de4x5 driver which supports the same cards as
> > > de2104x (and some other too) - and this one works fine! I can plug and
> > > unplug the cable and even change between TP and BNC ports just by
> > > unplugging one and plugging the other cable in. Unfortunately, this
> > > driver is blacklisted by default - at least in Slackware and Debian.
>
> ISTR there was a time when tulip would compete with de4x5 for devices.
> tulip is the preferred driver. That's clearly no longer the case
> and perhaps both distro's need to revisit this.
de4x5 has no MODULE_DEVICE_TABLE for PCI devices anymore, so no conflicts.
That's probably good for cards that work with tulip driver but bad for mine
card and also probably for some other cards that (should) work with de2104x.
>
> > > The question is: why does de2104x exist? Does it work better with some
> > > hardware?
>
> de2104x is a "work in progress".
> That's why it's marked "EXPERIMENTAL" in the Kconfig file.
Great, it looks to be 6 years old and it's still experimental. Probably
because it never worked properly.
I think that de2104x driver should be removed (or at least its
MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI
IDs added to de4x5.
I can send a patch if this is acceptable.
>
> > > BTW. Found that the problem exist at least since 2003:
> > > http://oss.sgi.com/archives/netdev/2003-08/msg00951.html
> >
> > Does the de2104x driver work correctly for anyone?
>
> No idea. I've only used tulip driver.
>
> thanks for the bug report,
> grant
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH 1/3] fib_trie: move statistics to debugfs
From: Stephen Hemminger @ 2008-02-18 16:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20080217.222655.262637827.davem@davemloft.net>
On Sun, 17 Feb 2008 22:26:55 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Wed, 13 Feb 2008 11:58:06 -0800
>
> > Don't want /proc/net/fib_trie and /proc/net/fib_triestat to become
> > permanent kernel space ABI issues, so move to the safer confines of debugfs.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Stephen, the cat is already out of the bag. We already export this
> thing so if you want to export different stuff you'll have to provide
> it via some other means, somewhere else.
>
> Thanks.
Are we stuck with the format problems?
* crappy tree printout
* not printing other tables
^ permalink raw reply
* Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
From: Stephen Hemminger @ 2008-02-18 16:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: Chris Rankin, linux-acpi, linux-kernel, netdev
In-Reply-To: <20080218050049.12bcc596.akpm@linux-foundation.org>
On Mon, 18 Feb 2008 05:00:49 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sun, 17 Feb 2008 00:54:08 +0000 (GMT) Chris Rankin <rankincj@yahoo.com> wrote:
>
> > [Try this again, except this time I'll force the attachment as inline text!]
> >
> > Hi,
> >
> > I have managed to boot 2.6.24.1 on this machine, with the NMI watchdog enabled, by using the
> > "acpi=noirq" option. (There does seem to be some unhappiness with bridge symlinks in sysfs,
> > though.)
> >
> > ...
> >
> > sysfs: duplicate filename 'bridge' can not be created
> > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> > [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> > [<c0105990>] show_trace+0x12/0x14
> > [<c010613d>] dump_stack+0x6c/0x72
> > [<c01991bf>] sysfs_add_one+0x57/0xbc
> > [<c0199e41>] sysfs_create_link+0xc2/0x10d
> > [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> > [<c034016c>] pci_legacy_init+0x56/0xe3
> > [<c03274e1>] kernel_init+0x157/0x2c3
> > [<c0104c83>] kernel_thread_helper+0x7/0x10
> > =======================
> > pci 0000:00:01.0: Error creating sysfs bridge symlink, continuing...
> > sysfs: duplicate filename 'bridge' can not be created
> > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> > [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> > [<c0105990>] show_trace+0x12/0x14
> > [<c010613d>] dump_stack+0x6c/0x72
> > [<c01991bf>] sysfs_add_one+0x57/0xbc
> > [<c0199e41>] sysfs_create_link+0xc2/0x10d
> > [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> > [<c01bae82>] pci_bus_add_devices+0xa5/0x103
> > [<c034016c>] pci_legacy_init+0x56/0xe3
> > [<c03274e1>] kernel_init+0x157/0x2c3
> > [<c0104c83>] kernel_thread_helper+0x7/0x10
> > =======================
>
> I have a vague feeling that this was fixed, perhaps in 2.6.24.x?
Never heard of this, what is the initialization script that causes this?
Also do you have the SYSFS_DEPRECATED option configured? that caused issues
with regular network drivers.
^ permalink raw reply
* Re: tbench regression in 2.6.25-rc1
From: Valdis.Kletnieks @ 2008-02-18 17:33 UTC (permalink / raw)
To: Zhang, Yanmin; +Cc: David Miller, dada1, herbert, linux-kernel, netdev
In-Reply-To: <1203322358.3027.200.camel@ymzhang>
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
On Mon, 18 Feb 2008 16:12:38 +0800, "Zhang, Yanmin" said:
> I also think __refcnt is the key. I did a new testing by adding 2 unsigned long
> pading before lastuse, so the 3 members are moved to next cache line. The performance is
> recovered.
>
> How about below patch? Almost all performance is recovered with the new patch.
>
> Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>
Could you add a comment someplace that says "refcnt wants to be on a different
cache line from input/output/ops or performance tanks badly", to warn some
future kernel hacker who starts adding new fields to the structure?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* keyboard dead with 45b5035
From: Pierre Ossman @ 2008-02-18 17:53 UTC (permalink / raw)
To: Laszlo Attila Toth, netdev, LKML
The patch "[RTNETLINK]: Send a single notification on device state changes." kills (at least) the keyboard here. Everything seems to work fine in single user mode, but when init starts spawning of logins, the keyboard goes bye-bye. Even the power button is ignored. :/
I've tried just creating another vt with "chvt 2", but that is insufficient to trigger the bug.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
^ permalink raw reply
* Re: [PATHCH 1/16] ServerEngines 10Gb NIC driver
From: Subbu Seetharaman @ 2008-02-18 18:00 UTC (permalink / raw)
To: netdev; +Cc: shemminger, jacliburn, sam
Thanks for all comments.
I had run checkpatch and corrected all errors excepting a
few errors about some macros and the warning about the
typedefs. The mail client I used to send the patch folded
lines at arbitrary points introduced several trailing white
space. This was also the reason for one of the patch not
applying clean. We will use git to generate the patches
as suggested.
Our desire to share common code across drivers for other
OSes has been a cause for some ugliness in coding styles.
I have one question about bit fields. Several of
headers in the common code are generated by
srcgen from f/w source files. Some of the structures
in these headers have bit fields (with separate definitions
for little endian and big endian hosts). Are these un-acceptable
in Linux driver submissions ?
Thanks.
Subbu
--------------------------------------
From: Stephen Hemminger [mailto:shemminger@linux-foundation.org]
To: netdev@vger.kernel.org
Sent: Sun, 17 Feb 2008 09:44:45 -0800
Subject: Re: [PATHCH 1/16] ServerEngines 10Gb NIC driver
Do all vendor drivers have to come in with the same mistakes.
Where is the vendor driver ugly school, and how can the Linux
developers teach there?
Run this through checkpatch script or just read some of the
things that a quick scan shows.
<snip>
___________________________________________________________________________________
This message, together with any attachment(s), contains confidential and proprietary information of
ServerEngines Corporation and is intended only for the designated recipient(s) named above. Any unauthorized
review, printing, retention, copying, disclosure or distribution is strictly prohibited. If you are not the
intended recipient of this message, please immediately advise the sender by reply email message and
delete all copies of this message and any attachment(s). Thank you.
^ permalink raw reply
* Re: [2.6.25-rc2] e100: Trying to free already-free IRQ 11 during suspend ...
From: Andrey Borzenkov @ 2008-02-18 18:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: e1000-devel, netdev, linux-kernel
In-Reply-To: <20080218050113.1b4b0897.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 3128 bytes --]
On Monday 18 February 2008, Andrew Morton wrote:
> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <arvidjaar@mail.ru> wrote:
>
> > ... and possibly reboot/poweroff (it flows by too fast to be legible).
> >
> > [ 8803.850634] ACPI: Preparing to enter system sleep state S3
> > [ 8803.853141] Suspending console(s)
> > [ 8805.287505] serial 00:09: disabled
> > [ 8805.291564] Trying to free already-free IRQ 11
> > [ 8805.291579] Pid: 6920, comm: pm-suspend Not tainted 2.6.25-rc2-1avb #2
> > [ 8805.291628] [<c0152127>] free_irq+0xb7/0x130
> > [ 8805.291675] [<c024bd80>] e100_suspend+0xc0/0x100
> > [ 8805.291724] [<c01eaa36>] pci_device_suspend+0x26/0x70
> > [ 8805.291747] [<c0243674>] suspend_device+0x94/0xd0
> > [ 8805.291763] [<c02439a3>] device_suspend+0x153/0x240
> > [ 8805.291784] [<c014314f>] suspend_devices_and_enter+0x4f/0xf0
> > [ 8805.291808] [<c0143a5f>] ? freeze_processes+0x3f/0x80
> > [ 8805.291825] [<c01432fa>] enter_state+0xaa/0x140
> > [ 8805.291840] [<c014341f>] state_store+0x8f/0xd0
> > [ 8805.291852] [<c0143390>] ? state_store+0x0/0xd0
> > [ 8805.291866] [<c01d3404>] kobj_attr_store+0x24/0x30
> > [ 8805.291901] [<c01b547b>] sysfs_write_file+0xbb/0x110
> > [ 8805.291936] [<c0177d79>] vfs_write+0x99/0x130
> > [ 8805.291963] [<c01b53c0>] ? sysfs_write_file+0x0/0x110
> > [ 8805.291979] [<c01782fd>] sys_write+0x3d/0x70
> > [ 8805.291998] [<c010409a>] sysenter_past_esp+0x5f/0xa5
> > [ 8805.292038] =======================
> > [ 8805.347640] ACPI: PCI interrupt for device 0000:00:06.0 disabled
> > [ 8805.361128] ACPI: PCI interrupt for device 0000:00:02.0 disabled
> > [ 8805.376670] hwsleep-0322 [00] enter_sleep_state : Entering sleep state [S3]
> > [ 8805.376670] Back to C!
> >
> > Interface is unused normally (only for netconsole sometimes). dmesg and config
> > attached.
>
> Does reverting this:
>
> commit 8543da6672b0994921f014f2250e27ae81645580
[...]
> fix it?
>
no
> > Hmm ... after resume device has disappeared at all ...
> >
> > {pts/1}% cat /proc/interrupts
> > CPU0
> > 0: 1290492 XT-PIC-XT timer
> > 1: 6675 XT-PIC-XT i8042
> > 2: 0 XT-PIC-XT cascade
> > 3: 2 XT-PIC-XT
> > 4: 2 XT-PIC-XT
> > 5: 3 XT-PIC-XT
> > 7: 4 XT-PIC-XT irda0
> > 8: 0 XT-PIC-XT rtc0
> > 9: 583 XT-PIC-XT acpi
> > 10: 2 XT-PIC-XT
> > 11: 31483 XT-PIC-XT yenta, yenta, yenta, ohci_hcd:usb1, ALI 5451, pcmcia0.0
> > 12: 28070 XT-PIC-XT i8042
> > 14: 21705 XT-PIC-XT ide0
> > 15: 82123 XT-PIC-XT ide1
> > NMI: 0 Non-maskable interrupts
> > TRM: 0 Thermal event interrupts
> > SPU: 0 Spurious interrupts
> > ERR: 0
>
> I hope that's not a separate bug...
>
>
this is red herring. pm-utils restart network across suspend; eth0 is not
activated automatically so it "disappears". ifconfig eth0 up brings it back.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] tlan: add static to function definitions
From: Harvey Harrison @ 2008-02-18 18:04 UTC (permalink / raw)
To: Jeff Garzik, Samuel Chessman; +Cc: LKML, linux-netdev
The forward declarations were already marked static, make the definitions
be static as well. Fixes the sparse warnings as well.
drivers/net/tlan.c:1403:5: warning: symbol 'TLan_HandleInvalid' was not declared. Should it be static?
drivers/net/tlan.c:1435:5: warning: symbol 'TLan_HandleTxEOF' was not declared. Should it be static?
drivers/net/tlan.c:1521:5: warning: symbol 'TLan_HandleStatOverflow' was not declared. Should it be static?
drivers/net/tlan.c:1557:5: warning: symbol 'TLan_HandleRxEOF' was not declared. Should it be static?
drivers/net/tlan.c:1692:5: warning: symbol 'TLan_HandleDummy' was not declared. Should it be static?
drivers/net/tlan.c:1722:5: warning: symbol 'TLan_HandleTxEOC' was not declared. Should it be static?
drivers/net/tlan.c:1770:5: warning: symbol 'TLan_HandleStatusCheck' was not declared. Should it be static?
drivers/net/tlan.c:1845:5: warning: symbol 'TLan_HandleRxEOC' was not declared. Should it be static?
drivers/net/tlan.c:1905:6: warning: symbol 'TLan_Timer' was not declared. Should it be static?
drivers/net/tlan.c:1986:6: warning: symbol 'TLan_ResetLists' was not declared. Should it be static?
drivers/net/tlan.c:2046:6: warning: symbol 'TLan_FreeLists' was not declared. Should it be static?
drivers/net/tlan.c:2095:6: warning: symbol 'TLan_PrintDio' was not declared. Should it be static?
drivers/net/tlan.c:2130:6: warning: symbol 'TLan_PrintList' was not declared. Should it be static?
drivers/net/tlan.c:2166:6: warning: symbol 'TLan_ReadAndClearStats' was not declared. Should it be static?
drivers/net/tlan.c:2242:1: warning: symbol 'TLan_ResetAdapter' was not declared. Should it be static?
drivers/net/tlan.c:2328:1: warning: symbol 'TLan_FinishReset' was not declared. Should it be static?
drivers/net/tlan.c:2451:6: warning: symbol 'TLan_SetMac' was not declared. Should it be static?
drivers/net/tlan.c:2493:6: warning: symbol 'TLan_PhyPrint' was not declared. Should it be static?
drivers/net/tlan.c:2542:6: warning: symbol 'TLan_PhyDetect' was not declared. Should it be static?
drivers/net/tlan.c:2589:6: warning: symbol 'TLan_PhyPowerDown' was not declared. Should it be static?
drivers/net/tlan.c:2614:6: warning: symbol 'TLan_PhyPowerUp' was not declared. Should it be static?
drivers/net/tlan.c:2635:6: warning: symbol 'TLan_PhyReset' was not declared. Should it be static?
drivers/net/tlan.c:2663:6: warning: symbol 'TLan_PhyStartLink' was not declared. Should it be static?
drivers/net/tlan.c:2750:6: warning: symbol 'TLan_PhyFinishAutoNeg' was not declared. Should it be static?
drivers/net/tlan.c:2906:5: warning: symbol 'TLan_MiiReadReg' was not declared. Should it be static?
drivers/net/tlan.c:2996:6: warning: symbol 'TLan_MiiSendData' was not declared. Should it be static?
drivers/net/tlan.c:3038:6: warning: symbol 'TLan_MiiSync' was not declared. Should it be static?
drivers/net/tlan.c:3077:6: warning: symbol 'TLan_MiiWriteReg' was not declared. Should it be static?
drivers/net/tlan.c:3147:6: warning: symbol 'TLan_EeSendStart' was not declared. Should it be static?
drivers/net/tlan.c:3187:5: warning: symbol 'TLan_EeSendByte' was not declared. Should it be static?
drivers/net/tlan.c:3248:6: warning: symbol 'TLan_EeReceiveByte' was not declared. Should it be static?
drivers/net/tlan.c:3306:5: warning: symbol 'TLan_EeReadByte' was not declared. Should it be static?
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
Kept the style consistent with the rest of the file, checkpatch will complain.
drivers/net/tlan.c | 64 ++++++++++++++++++++++++++--------------------------
1 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/net/tlan.c b/drivers/net/tlan.c
index 3af5b92..0166407 100644
--- a/drivers/net/tlan.c
+++ b/drivers/net/tlan.c
@@ -1400,7 +1400,7 @@ static void TLan_SetMulticastList( struct net_device *dev )
*
**************************************************************/
-u32 TLan_HandleInvalid( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleInvalid( struct net_device *dev, u16 host_int )
{
/* printk( "TLAN: Invalid interrupt on %s.\n", dev->name ); */
return 0;
@@ -1432,7 +1432,7 @@ u32 TLan_HandleInvalid( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleTxEOF( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleTxEOF( struct net_device *dev, u16 host_int )
{
TLanPrivateInfo *priv = netdev_priv(dev);
int eoc = 0;
@@ -1518,7 +1518,7 @@ u32 TLan_HandleTxEOF( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleStatOverflow( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleStatOverflow( struct net_device *dev, u16 host_int )
{
TLan_ReadAndClearStats( dev, TLAN_RECORD );
@@ -1554,7 +1554,7 @@ u32 TLan_HandleStatOverflow( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleRxEOF( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleRxEOF( struct net_device *dev, u16 host_int )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u32 ack = 0;
@@ -1689,7 +1689,7 @@ u32 TLan_HandleRxEOF( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleDummy( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleDummy( struct net_device *dev, u16 host_int )
{
printk( "TLAN: Test interrupt on %s.\n", dev->name );
return 1;
@@ -1719,7 +1719,7 @@ u32 TLan_HandleDummy( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleTxEOC( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleTxEOC( struct net_device *dev, u16 host_int )
{
TLanPrivateInfo *priv = netdev_priv(dev);
TLanList *head_list;
@@ -1767,7 +1767,7 @@ u32 TLan_HandleTxEOC( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleStatusCheck( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleStatusCheck( struct net_device *dev, u16 host_int )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u32 ack;
@@ -1842,7 +1842,7 @@ u32 TLan_HandleStatusCheck( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleRxEOC( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleRxEOC( struct net_device *dev, u16 host_int )
{
TLanPrivateInfo *priv = netdev_priv(dev);
dma_addr_t head_list_phys;
@@ -1902,7 +1902,7 @@ u32 TLan_HandleRxEOC( struct net_device *dev, u16 host_int )
*
**************************************************************/
-void TLan_Timer( unsigned long data )
+static void TLan_Timer( unsigned long data )
{
struct net_device *dev = (struct net_device *) data;
TLanPrivateInfo *priv = netdev_priv(dev);
@@ -1983,7 +1983,7 @@ void TLan_Timer( unsigned long data )
*
**************************************************************/
-void TLan_ResetLists( struct net_device *dev )
+static void TLan_ResetLists( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
int i;
@@ -2043,7 +2043,7 @@ void TLan_ResetLists( struct net_device *dev )
} /* TLan_ResetLists */
-void TLan_FreeLists( struct net_device *dev )
+static void TLan_FreeLists( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
int i;
@@ -2092,7 +2092,7 @@ void TLan_FreeLists( struct net_device *dev )
*
**************************************************************/
-void TLan_PrintDio( u16 io_base )
+static void TLan_PrintDio( u16 io_base )
{
u32 data0, data1;
int i;
@@ -2127,7 +2127,7 @@ void TLan_PrintDio( u16 io_base )
*
**************************************************************/
-void TLan_PrintList( TLanList *list, char *type, int num)
+static void TLan_PrintList( TLanList *list, char *type, int num)
{
int i;
@@ -2163,7 +2163,7 @@ void TLan_PrintList( TLanList *list, char *type, int num)
*
**************************************************************/
-void TLan_ReadAndClearStats( struct net_device *dev, int record )
+static void TLan_ReadAndClearStats( struct net_device *dev, int record )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u32 tx_good, tx_under;
@@ -2238,7 +2238,7 @@ void TLan_ReadAndClearStats( struct net_device *dev, int record )
*
**************************************************************/
-void
+static void
TLan_ResetAdapter( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
@@ -2324,7 +2324,7 @@ TLan_ResetAdapter( struct net_device *dev )
-void
+static void
TLan_FinishReset( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
@@ -2448,7 +2448,7 @@ TLan_FinishReset( struct net_device *dev )
*
**************************************************************/
-void TLan_SetMac( struct net_device *dev, int areg, char *mac )
+static void TLan_SetMac( struct net_device *dev, int areg, char *mac )
{
int i;
@@ -2490,7 +2490,7 @@ void TLan_SetMac( struct net_device *dev, int areg, char *mac )
*
********************************************************************/
-void TLan_PhyPrint( struct net_device *dev )
+static void TLan_PhyPrint( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 i, data0, data1, data2, data3, phy;
@@ -2539,7 +2539,7 @@ void TLan_PhyPrint( struct net_device *dev )
*
********************************************************************/
-void TLan_PhyDetect( struct net_device *dev )
+static void TLan_PhyDetect( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 control;
@@ -2586,7 +2586,7 @@ void TLan_PhyDetect( struct net_device *dev )
-void TLan_PhyPowerDown( struct net_device *dev )
+static void TLan_PhyPowerDown( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 value;
@@ -2611,7 +2611,7 @@ void TLan_PhyPowerDown( struct net_device *dev )
-void TLan_PhyPowerUp( struct net_device *dev )
+static void TLan_PhyPowerUp( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 value;
@@ -2632,7 +2632,7 @@ void TLan_PhyPowerUp( struct net_device *dev )
-void TLan_PhyReset( struct net_device *dev )
+static void TLan_PhyReset( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 phy;
@@ -2660,7 +2660,7 @@ void TLan_PhyReset( struct net_device *dev )
-void TLan_PhyStartLink( struct net_device *dev )
+static void TLan_PhyStartLink( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 ability;
@@ -2747,7 +2747,7 @@ void TLan_PhyStartLink( struct net_device *dev )
-void TLan_PhyFinishAutoNeg( struct net_device *dev )
+static void TLan_PhyFinishAutoNeg( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 an_adv;
@@ -2903,7 +2903,7 @@ void TLan_PhyMonitor( struct net_device *dev )
*
**************************************************************/
-int TLan_MiiReadReg( struct net_device *dev, u16 phy, u16 reg, u16 *val )
+static int TLan_MiiReadReg( struct net_device *dev, u16 phy, u16 reg, u16 *val )
{
u8 nack;
u16 sio, tmp;
@@ -2993,7 +2993,7 @@ int TLan_MiiReadReg( struct net_device *dev, u16 phy, u16 reg, u16 *val )
*
**************************************************************/
-void TLan_MiiSendData( u16 base_port, u32 data, unsigned num_bits )
+static void TLan_MiiSendData( u16 base_port, u32 data, unsigned num_bits )
{
u16 sio;
u32 i;
@@ -3035,7 +3035,7 @@ void TLan_MiiSendData( u16 base_port, u32 data, unsigned num_bits )
*
**************************************************************/
-void TLan_MiiSync( u16 base_port )
+static void TLan_MiiSync( u16 base_port )
{
int i;
u16 sio;
@@ -3074,7 +3074,7 @@ void TLan_MiiSync( u16 base_port )
*
**************************************************************/
-void TLan_MiiWriteReg( struct net_device *dev, u16 phy, u16 reg, u16 val )
+static void TLan_MiiWriteReg( struct net_device *dev, u16 phy, u16 reg, u16 val )
{
u16 sio;
int minten;
@@ -3144,7 +3144,7 @@ void TLan_MiiWriteReg( struct net_device *dev, u16 phy, u16 reg, u16 val )
*
**************************************************************/
-void TLan_EeSendStart( u16 io_base )
+static void TLan_EeSendStart( u16 io_base )
{
u16 sio;
@@ -3184,7 +3184,7 @@ void TLan_EeSendStart( u16 io_base )
*
**************************************************************/
-int TLan_EeSendByte( u16 io_base, u8 data, int stop )
+static int TLan_EeSendByte( u16 io_base, u8 data, int stop )
{
int err;
u8 place;
@@ -3245,7 +3245,7 @@ int TLan_EeSendByte( u16 io_base, u8 data, int stop )
*
**************************************************************/
-void TLan_EeReceiveByte( u16 io_base, u8 *data, int stop )
+static void TLan_EeReceiveByte( u16 io_base, u8 *data, int stop )
{
u8 place;
u16 sio;
@@ -3303,7 +3303,7 @@ void TLan_EeReceiveByte( u16 io_base, u8 *data, int stop )
*
**************************************************************/
-int TLan_EeReadByte( struct net_device *dev, u8 ee_addr, u8 *data )
+static int TLan_EeReadByte( struct net_device *dev, u8 ee_addr, u8 *data )
{
int err;
TLanPrivateInfo *priv = netdev_priv(dev);
--
1.5.4.1.1278.gc75be
^ permalink raw reply related
* Re: [PATCH] net/8021q/vlan_dev.c - Use print_mac
From: Joe Perches @ 2008-02-18 18:31 UTC (permalink / raw)
To: Patrick McHardy
Cc: David Miller, bruno-L9ZBdB2wSWtl57MIdRCFDg,
netdev-u79uwXL29TY76Z2rM5mHXA, jgarzik-e+AXbWqSrlAAvxtiuMwx3w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <47B9A20C.10304-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
On Mon, 2008-02-18 at 16:19 +0100, Patrick McHardy wrote:
> > @@ -404,11 +405,8 @@ static int vlan_dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >
> > pr_debug("%s: about to send skb: %p to dev: %s\n",
> > __FUNCTION__, skb, skb->dev->name);
> > - pr_debug(" " MAC_FMT " " MAC_FMT " %4hx %4hx %4hx\n",
> > - veth->h_dest[0], veth->h_dest[1], veth->h_dest[2],
> > - veth->h_dest[3], veth->h_dest[4], veth->h_dest[5],
> > - veth->h_source[0], veth->h_source[1], veth->h_source[2],
> > - veth->h_source[3], veth->h_source[4], veth->h_source[5],
> > + pr_debug(" %s %s %4hx %4hx %4hx\n",
> > + print_mac(mac, veth->h_dest), print_mac(mac2, veth->h_source),
> This results in print_mac getting called twice per packet even without
> debugging. Whats the problem with MAC_FMT?
It's just a consistency thing.
It identifies code where MAC addresses are used.
an allyesconfig is a bit smaller (~.1%).
pr_debug is a noop when not debugging, print_mac is optimized away.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox