* Re: 2.6.39.2 BUG: unable to handle kernel NULL pointer dereference
From: Eric Dumazet @ 2011-06-26 12:42 UTC (permalink / raw)
To: Fabio Coatti; +Cc: linux-kernel, netdev, David Miller
In-Reply-To: <BANLkTikhGVYAFEZGS-AZf3CyS4yVN+Acvg@mail.gmail.com>
Le dimanche 26 juin 2011 à 13:34 +0200, Fabio Coatti a écrit :
> 2011/6/26 Eric Dumazet <eric.dumazet@gmail.com>:
> > Le dimanche 26 juin 2011 à 10:28 +0200, Fabio Coatti a écrit :
> >> I'm trying to boot with 2.6.39.2 but the process stops somewhere in
> >> network stack, with a BUG: report.
> >> I've been able to capture the kernel messages usign netconsole, so be
> >> patient with poor alignment :)
>
> >
> > Hi Fabio
> >
> > Could you test following patch :
> >
> > http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6407d74c5106bb362b4087693688afd34942b094
> >
> >
> > This should be included in 2.6.39.3, if you confirm this fixes the
> > problem.
> >
>
> Yes, I can confirm that your patch fixes the problem, now running
> 2.6.39.2 just fine. Many thanks!
Thanks for testing, David will include this to his stable queue I
presume.
^ permalink raw reply
* Re: [RFC 46/72] ixp2000: Move the Radisys driver
From: Lennert Buytenhek @ 2011-06-26 11:47 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, Lennert Buytenhek
In-Reply-To: <1309010363-22750-47-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jun 25, 2011 at 06:58:57AM -0700, Jeff Kirsher wrote:
> Move the Radisys driver into drivers/net/ethernet/radisys/ and
> make the necessary Kconfig and Makefile changes
>
> CC: Lennert Buytenhek <kernel@wantstofly.org>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> MAINTAINERS | 2 +-
> drivers/net/Kconfig | 2 --
> drivers/net/Makefile | 1 -
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/radisys/Kconfig | 16 ++++++++++++++++
> drivers/net/ethernet/radisys/Makefile | 5 +++++
> drivers/net/{ => ethernet/radisys}/ixp2000/Kconfig | 2 +-
> .../net/{ => ethernet/radisys}/ixp2000/Makefile | 0
The ixp2000 is a series of Intel ARM SoCs, and the ENP2611 is a Radisys
PCI board based on the ixp2000 series (ixp2400), so it doesn't make
sense to put everything in the radisys/ directory.
If you insist on moving all drivers into vendor directories (I don't
like that idea at all -- are we going to rename directories and shuffle
stuff around every time vendor A buys vendor B or takes over one of
vendor B's products?), at least the core ixp2000 code should be under
intel/.
^ permalink raw reply
* Re: 2.6.39.2 BUG: unable to handle kernel NULL pointer dereference
From: Fabio Coatti @ 2011-06-26 11:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1309082172.2532.31.camel@edumazet-laptop>
2011/6/26 Eric Dumazet <eric.dumazet@gmail.com>:
> Le dimanche 26 juin 2011 à 10:28 +0200, Fabio Coatti a écrit :
>> I'm trying to boot with 2.6.39.2 but the process stops somewhere in
>> network stack, with a BUG: report.
>> I've been able to capture the kernel messages usign netconsole, so be
>> patient with poor alignment :)
>
> Hi Fabio
>
> Could you test following patch :
>
> http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6407d74c5106bb362b4087693688afd34942b094
>
>
> This should be included in 2.6.39.3, if you confirm this fixes the
> problem.
>
Yes, I can confirm that your patch fixes the problem, now running
2.6.39.2 just fine. Many thanks!
--
Fabio
^ permalink raw reply
* [PATCH 07/12] NET: de4x5: Fix section mismatch
From: Ralf Baechle @ 2011-06-26 11:28 UTC (permalink / raw)
To: David S. Miller; +Cc: Grant Grundler, netdev, linux-kernel, linux-mips
In-Reply-To: <17dd5038b15d7135791aadbe80464a13c80758d3.1309182742.git.ralf@linux-mips.org>
WARNING: drivers/net/tulip/de4x5.o(.data+0x34): Section mismatch in reference from the variable de4x5_eisa_driver to the function .init.text:de4x5_eisa_probe()
The variable de4x5_eisa_driver references
the function __init de4x5_eisa_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: Grant Grundler <grundler@parisc-linux.org>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
---
drivers/net/tulip/de4x5.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tulip/de4x5.c b/drivers/net/tulip/de4x5.c
index efaa1d6..ea473b6 100644
--- a/drivers/net/tulip/de4x5.c
+++ b/drivers/net/tulip/de4x5.c
@@ -1995,7 +1995,7 @@ SetMulticastFilter(struct net_device *dev)
static u_char de4x5_irq[] = EISA_ALLOWED_IRQ_LIST;
-static int __init de4x5_eisa_probe (struct device *gendev)
+static int __devinit de4x5_eisa_probe (struct device *gendev)
{
struct eisa_device *edev;
u_long iobase;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 06/12] NET: ne3210: Fix bucketload full of section mismatches.
From: Ralf Baechle @ 2011-06-26 11:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, linux-mips
In-Reply-To: <17dd5038b15d7135791aadbe80464a13c80758d3.1309182742.git.ralf@linux-mips.org>
WARNING: drivers/net/ne3210.o(.data+0x40): Section mismatch in reference from the variable ne3210_eisa_driver to the function .init.text:ne3210_eisa_probe()
The variable ne3210_eisa_driver references
the function __init ne3210_eisa_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Fixing this mismatch triggers yet more mismatches, fix those as well.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
---
drivers/net/ne3210.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ne3210.c b/drivers/net/ne3210.c
index 243ed2a..e30b8ff 100644
--- a/drivers/net/ne3210.c
+++ b/drivers/net/ne3210.c
@@ -80,17 +80,19 @@ static void ne3210_block_output(struct net_device *dev, int count, const unsigne
#define NE3210_DEBUG 0x0
-static unsigned char irq_map[] __initdata = {15, 12, 11, 10, 9, 7, 5, 3};
-static unsigned int shmem_map[] __initdata = {0xff0, 0xfe0, 0xfff0, 0xd8, 0xffe0, 0xffc0, 0xd0, 0x0};
-static const char *ifmap[] __initdata = {"UTP", "?", "BNC", "AUI"};
-static int ifmap_val[] __initdata = {
+static unsigned char irq_map[] __devinitdata = {15, 12, 11, 10, 9, 7, 5, 3};
+static unsigned int shmem_map[] __devinitdata = {
+ 0xff0, 0xfe0, 0xfff0, 0xd8, 0xffe0, 0xffc0, 0xd0, 0x0
+};
+static const char *ifmap[] __devinitdata = {"UTP", "?", "BNC", "AUI"};
+static int ifmap_val[] __devinitdata = {
IF_PORT_10BASET,
IF_PORT_UNKNOWN,
IF_PORT_10BASE2,
IF_PORT_AUI,
};
-static int __init ne3210_eisa_probe (struct device *device)
+static int __devinit ne3210_eisa_probe (struct device *device)
{
unsigned long ioaddr, phys_mem;
int i, retval, port_index;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 04/12] NET: depca: Fix bucketload full of section mismatches.
From: Ralf Baechle @ 2011-06-26 11:23 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, linux-mips
In-Reply-To: <17dd5038b15d7135791aadbe80464a13c80758d3.1309182742.git.ralf@linux-mips.org>
WARNING: drivers/net/depca.o(.data+0x34): Section mismatch in reference from the variable depca_eisa_driver to the function .init.text:depca_eisa_probe()
The variable depca_eisa_driver references
the function __init depca_eisa_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
WARNING: drivers/net/depca.o(.devinit.text+0x2c): Section mismatch in reference from the function depca_isa_probe() to the function .init.text:depca_common_init()
The function __devinit depca_isa_probe() references
a function __init depca_common_init().
If depca_common_init is only used by depca_isa_probe then
annotate depca_common_init with a matching annotation.
WARNING: drivers/net/depca.o(.devinit.text+0x44): Section mismatch in reference from the function depca_isa_probe() to the function .init.text:depca_shmem_probe()
The function __devinit depca_isa_probe() references
a function __init depca_shmem_probe().
If depca_shmem_probe is only used by depca_isa_probe then
annotate depca_shmem_probe with a matching annotation.
WARNING: drivers/net/depca.o(.devinit.text+0x8c): Section mismatch in reference from the function depca_isa_probe() to the function .init.text:depca_hw_init()
The function __devinit depca_isa_probe() references
a function __init depca_hw_init().
If depca_hw_init is only used by depca_isa_probe then
annotate depca_hw_init with a matching annotation.
Fixing these in turn triggers yet more mismatches, fix those as well.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
---
drivers/net/depca.c | 25 +++++++++++++------------
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/net/depca.c b/drivers/net/depca.c
index 8b0084d..d40536a 100644
--- a/drivers/net/depca.c
+++ b/drivers/net/depca.c
@@ -331,7 +331,7 @@ static struct {
"DE422",\
""}
-static char* __initdata depca_signature[] = DEPCA_SIGNATURE;
+static char* __devinitdata depca_signature[] = DEPCA_SIGNATURE;
enum depca_type {
DEPCA, de100, de101, de200, de201, de202, de210, de212, de422, unknown
@@ -541,9 +541,9 @@ static void SetMulticastFilter(struct net_device *dev);
static int load_packet(struct net_device *dev, struct sk_buff *skb);
static void depca_dbg_open(struct net_device *dev);
-static u_char de1xx_irq[] __initdata = { 2, 3, 4, 5, 7, 9, 0 };
-static u_char de2xx_irq[] __initdata = { 5, 9, 10, 11, 15, 0 };
-static u_char de422_irq[] __initdata = { 5, 9, 10, 11, 0 };
+static u_char de1xx_irq[] __devinitdata = { 2, 3, 4, 5, 7, 9, 0 };
+static u_char de2xx_irq[] __devinitdata = { 5, 9, 10, 11, 15, 0 };
+static u_char de422_irq[] __devinitdata = { 5, 9, 10, 11, 0 };
static u_char *depca_irq;
static int irq;
@@ -580,7 +580,8 @@ static const struct net_device_ops depca_netdev_ops = {
.ndo_validate_addr = eth_validate_addr,
};
-static int __init depca_hw_init (struct net_device *dev, struct device *device)
+static int __devinit depca_hw_init (struct net_device *dev,
+ struct device *device)
{
struct depca_private *lp;
int i, j, offset, netRAM, mem_len, status = 0;
@@ -1302,7 +1303,7 @@ static void SetMulticastFilter(struct net_device *dev)
}
}
-static int __init depca_common_init (u_long ioaddr, struct net_device **devp)
+static int __devinit depca_common_init (u_long ioaddr, struct net_device **devp)
{
int status = 0;
@@ -1333,7 +1334,7 @@ static int __init depca_common_init (u_long ioaddr, struct net_device **devp)
/*
** Microchannel bus I/O device probe
*/
-static int __init depca_mca_probe(struct device *device)
+static int __devinit depca_mca_probe(struct device *device)
{
unsigned char pos[2];
unsigned char where;
@@ -1497,7 +1498,7 @@ static void __init depca_platform_probe (void)
}
}
-static enum depca_type __init depca_shmem_probe (ulong *mem_start)
+static enum depca_type __devinit depca_shmem_probe (ulong *mem_start)
{
u_long mem_base[] = DEPCA_RAM_BASE_ADDRESSES;
enum depca_type adapter = unknown;
@@ -1558,7 +1559,7 @@ static int __devinit depca_isa_probe (struct platform_device *device)
*/
#ifdef CONFIG_EISA
-static int __init depca_eisa_probe (struct device *device)
+static int __devinit depca_eisa_probe (struct device *device)
{
enum depca_type adapter = unknown;
struct eisa_device *edev;
@@ -1629,7 +1630,7 @@ static int __devexit depca_device_remove (struct device *device)
** and Boot (readb) ROM. This will also give us a clue to the network RAM
** base address.
*/
-static int __init DepcaSignature(char *name, u_long base_addr)
+static int __devinit DepcaSignature(char *name, u_long base_addr)
{
u_int i, j, k;
void __iomem *ptr;
@@ -1698,7 +1699,7 @@ static int __init DepcaSignature(char *name, u_long base_addr)
** PROM address counter is correctly positioned at the start of the
** ethernet address for later read out.
*/
-static int __init DevicePresent(u_long ioaddr)
+static int __devinit DevicePresent(u_long ioaddr)
{
union {
struct {
@@ -1751,7 +1752,7 @@ static int __init DevicePresent(u_long ioaddr)
** reason: access the upper half of the PROM with x=0; access the lower half
** with x=1.
*/
-static int __init get_hw_addr(struct net_device *dev)
+static int __devinit get_hw_addr(struct net_device *dev)
{
u_long ioaddr = dev->base_addr;
struct depca_private *lp = netdev_priv(dev);
--
1.7.4.4
^ permalink raw reply related
* [PATCH 00/12] Fix various section mismatches and build errors.
From: Ralf Baechle @ 2011-06-26 11:19 UTC (permalink / raw)
To: Andrew Morton, Alan Cox, Brent Casavant, David Airlie, "David
Cc: dri-devel, linux-kernel, linux-mips, linux-scsi, linux-serial,
netdev
I'm getting screen and screens full of section mismatches from my test
builds of the current kernel to the point where it's sometimes more
meaningful messages get hidden by the bulk of mismatches. This is the
first round of fixes with more to come.
Ralf
drivers/gpu/drm/radeon/radeon_clocks.c | 4 ++--
drivers/leds/leds-lp5521.c | 4 ++--
drivers/leds/leds-lp5523.c | 4 ++--
drivers/misc/ioc4.c | 2 +-
drivers/net/3c509.c | 2 +-
drivers/net/3c59x.c | 2 +-
drivers/net/depca.c | 25 +++++++++++++------------
drivers/net/hp100.c | 2 +-
drivers/net/ne3210.c | 12 +++++++-----
drivers/net/tulip/de4x5.c | 2 +-
drivers/scsi/sim710.c | 2 +-
drivers/tty/serial/Kconfig | 2 +-
12 files changed, 33 insertions(+), 30 deletions(-)
^ permalink raw reply
* Re: SKB paged fragment lifecycle on receive
From: Michael S. Tsirkin @ 2011-06-26 10:25 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev, xen-devel, Jeremy Fitzhardinge, Rusty Russell, mashirle
In-Reply-To: <1308930202.32717.144.camel@zakaz.uk.xensource.com>
On Fri, Jun 24, 2011 at 04:43:22PM +0100, Ian Campbell wrote:
> In this mode guest data pages ("foreign pages") were mapped into the
> backend domain (using Xen grant-table functionality) and placed into the
> skb's paged frag list (skb_shinfo(skb)->frags, I hope I am using the
> right term). Once the page is finished with netback unmaps it in order
> to return it to the guest (we really want to avoid returning such pages
> to the general allocation pool!).
Are the pages writeable by the source guest while netback processes
them? If yes, firewalling becomes unreliable as the packet can be
modified after it's checked, right?
Also, for guest to guest communication, do you wait for
the destination to stop looking at the packet in order
to return it to the source? If yes, can source guest
networking be disrupted by a slow destination?
> Jeremy Fitzhardinge and I subsequently
> looked at the possibility of a no-clone skb flag (i.e. always forcing a
> copy instead of a clone)
I think this is the approach that the patchset
'macvtap/vhost TX zero-copy support' takes.
> but IIRC honouring it universally turned into a
> very twisty maze with a number of nasty corner cases etc.
Any examples? Are they covered by the patchset above?
> FWIW I proposed a session on the subject for LPC this year.
We also plan to discuss this on kvm forum 2011
(colocated with linuxcon 2011).
http://www.linux-kvm.org/page/KVM_Forum_2011
--
MST
^ permalink raw reply
* Re: 2.6.39.2 BUG: unable to handle kernel NULL pointer dereference
From: Eric Dumazet @ 2011-06-26 9:56 UTC (permalink / raw)
To: Fabio Coatti; +Cc: linux-kernel, netdev
In-Reply-To: <BANLkTing9LWO6AjbdzOJzkJ9aoJhn_TLnw@mail.gmail.com>
Le dimanche 26 juin 2011 à 10:28 +0200, Fabio Coatti a écrit :
> I'm trying to boot with 2.6.39.2 but the process stops somewhere in
> network stack, with a BUG: report.
> I've been able to capture the kernel messages usign netconsole, so be
> patient with poor alignment :)
>
> Please note that at this moment I'm not subscribed to LKML, so please
> keep me in CC if any answer is required. Below you can find the
> netconsole trace and .config file.
>
> Thanks for the attention.
>
>
> ACPI: PCI Interrupt Link [LSMB] (IRQs 5 7 9 10 11 14 15) *0, disabled.
> br0: port 1(eth0) entering forwarding state
> i8042: PNP: No PS/2 controller found. Probing ports directly.
> serio: i8042 KBD port at 0x60,0x64 irq 1
> serio: i8042 AUX port at 0x60,0x64 irq 12
> mousedev: PS/2 mouse device common for all mice
> rtc_cmos 00:05: RTC can wake from S4
> rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
> rtc0: alarms up to one year, y3k, 242 bytes nvram, hpet irqs
> md: linear personality registered for level -1
> md: raid0 personality registered for level 0
> md: raid1 personality registered for level 1
> md: raid10 personality registered for level 10
> md: raid6 personality registered for level 6
> md: raid5 personality registered for level 5
> md: raid4 personality registered for level 4
> md: multipath personality registered for level -4
> device-mapper: uevent: version 1.0.3
> device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: dm-devel@redhat.com
> cpuidle: using governor ladder
> Netfilter messages via NETLINK v0.30.
> TCP cubic registered
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> Registering the dns_resolver key type
> rtc_cmos 00:05: setting system clock to 2011-06-26 08:10:48 UTC (1309075848)
> Freeing unused kernel memory: 6372k freed
> BUG: unable to handle kernel
> NULL pointer dereference
> at (null)
> IP:
> [< (null)>] (null)
> PGD 230a57067
> PUD 2309fb067
> PMD 0
>
> Oops: 0010 [#1]
> PREEMPT
> SMP
>
> last sysfs file: /sys/devices/virtual/net/br0/uevent
> CPU 2
>
> Modules linked in:
> bridge
> stp
> llc
> ip6t_rt
> ip6table_filter
> ip6_tables
> x_tables
> snd_usb_audio
> uvcvideo
> videodev
> snd_usbmidi_lib
> v4l2_compat_ioctl32
> snd_rawmidi
> snd_seq_device
> hid_logitech
> ipv6
> usbhid
> usb_storage
> usb_libusual
> uas
> snd_hda_codec_hdmi
> snd_hda_codec_analog
> ohci_hcd
> ehci_hcd
> snd_hda_intel
> snd_hda_codec
> k10temp
> i2c_nforce2
> snd_hwdep
> snd_pcm
> asus_atk0110
> snd_timer
> snd
> usbcore
> soundcore
> snd_page_alloc
>
>
> Pid: 3359, comm: ip Tainted: G W 2.6.39.2 #2
> System manufacturer System Product Name
> /M3N-HT DELUXE
>
> RIP: 0010:[<0000000000000000>]
> [< (null)>] (null)
> RSP: 0018:ffff8802264398a0 EFLAGS: 00010202
> RAX: 00000000000005dc RBX: 0000000000000320 RCX: ffff88022d38e608
> RDX: ffffffffa01d6fc0 RSI: ffffffffa01d5c61 RDI: ffff88022d38ee38
> RBP: ffff88022d38e000 R08: 0000000000000000 R09: ffff880230a5bb80
> R10: ffffffff81353339 R11: 0000000000000000 R12: ffff88022d38e600
> R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffa01d5870
> FS: 00007f4e5bb98700(0000) GS:ffff88023fd00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 000000022640b000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process ip (pid: 3359, threadinfo ffff880226438000, task ffff880230ade300)
> Stack:
> ffffffffa01cc1e7
> ffff88022d38e000
> ffff8802264399a8
> 0000000000000000
>
> ffffffff8135bd0f
> ffff88022d38e000
> ffffffff81366ab9
> ffff88022d38e000
>
> ffff88022a4cfc10
> ffff880226439ae8
> 00000009a0124919
> ffff88022d39ed00
>
> Call Trace:
> [<ffffffffa01cc1e7>] ? br_change_mtu+0x50/0x6f [bridge]
> [<ffffffff8135bd0f>] ? dev_set_mtu+0x35/0x5b
> [<ffffffff81366ab9>] ? do_setlink+0x189/0x706
> [<ffffffff81365cfd>] ? rtnl_fill_ifinfo+0x954/0xa20
> [<ffffffff810925fd>] ? handle_mm_fault+0x107/0x189
> [<ffffffff8136738d>] ? rtnl_newlink+0x26a/0x4c1
> [<ffffffff813671d3>] ? rtnl_newlink+0xb0/0x4c1
> [<ffffffff813d7ead>] ? _raw_spin_unlock_irqrestore+0x20/0x2e
> [<ffffffff813553dc>] ? __skb_recv_datagram+0x103/0x23f
> [<ffffffff81366437>] ? rtnetlink_rcv+0x28/0x28
> [<ffffffff8137744b>] ? netlink_rcv_skb+0x34/0x7d
> [<ffffffff8136642e>] ? rtnetlink_rcv+0x1f/0x28
> [<ffffffff81377239>] ? netlink_unicast+0xe5/0x14d
> [<ffffffff813776da>] ? netlink_sendmsg+0x246/0x266
> [<ffffffff8134a6bb>] ? sock_sendmsg+0x83/0x9b
> [<ffffffff81091332>] ? __do_fault+0x396/0x3d1
> [<ffffffff8134a49f>] ? move_addr_to_kernel+0x2c/0x4a
> [<ffffffff8135463f>] ? verify_iovec+0x46/0x98
> [<ffffffff8134aae5>] ? sys_sendmsg+0x22c/0x2b4
> [<ffffffff810925fd>] ? handle_mm_fault+0x107/0x189
> [<ffffffff8101a773>] ? do_page_fault+0x29b/0x2d4
> [<ffffffff810960d3>] ? do_brk+0x2ca/0x326
> [<ffffffff813d887b>] ? system_call_fastpath+0x16/0x1b
> Code:
> Bad RIP value.
>
> RIP
> [< (null)>] (null)
> RSP <ffff8802264398a0>
> CR2: 0000000000000000
> ---[ end trace c2ce621f7ff96fed ]---
> br0: no IPv6 routers present
> br0: port 1(eth0) entering forwarding state
>
>
Hi Fabio
Could you test following patch :
http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6407d74c5106bb362b4087693688afd34942b094
This should be included in 2.6.39.3, if you confirm this fixes the
problem.
^ permalink raw reply
* Re: [RFC 00/72] Organize/Move of the Ethernet drivers in drivers/net/
From: Francois Romieu @ 2011-06-26 8:35 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev
In-Reply-To: <1309010363-22750-1-git-send-email-jeffrey.t.kirsher@intel.com>
Jeff Kirsher <jeffrey.t.kirsher@intel.com> :
> The following series is the first attempt to organize the drivers/net
> directory. This process was started a year ago, and the emphasis was
> on making the drivers/net/ easier to maintain and to group similar
> drivers into the appropriate sub-directory.
No opinion on the topic here. The changes look sane.
--
Ueimor
^ permalink raw reply
* Re: [RFC 00/72] Organize/Move of the Ethernet drivers in drivers/net/
From: Bill Fink @ 2011-06-26 7:54 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev
In-Reply-To: <1309010363-22750-1-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 25 Jun 2011, Jeff Kirsher wrote:
> The following series is the first attempt to organize the drivers/net
> directory. This process was started a year ago, and the emphasis was
> on making the drivers/net/ easier to maintain and to group similar
> drivers into the appropriate sub-directory.
>
> The next steps are to move all the FIDDI drivers into drivers/net/fiddi,
> and like so. In addition, look at splitting the PS3 driver so that the
> wireless portion can be moved into /drivers/net/wireless.
That should be FDDI, not FIDDI.
-Bill
^ permalink raw reply
* Re: [RFC 26/72] arm: Move the ARM/ACORN drivers
From: Joe Perches @ 2011-06-26 6:38 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: Arnd Bergmann, Russell King - ARM Linux, davem@davemloft.net,
netdev@vger.kernel.org, Sriram, Vinay Hegde, Cyril Chemparathy,
Wan ZongShun, Lennert Buytenhek, Krzysztof Halasa, Anant Gole,
Chaithrika U S
In-Reply-To: <1309025217.2454.89.camel@jtkirshe-mobl>
On Sat, 2011-06-25 at 11:06 -0700, Jeff Kirsher wrote:
> On Sat, 2011-06-25 at 09:59 -0700, Arnd Bergmann wrote:
> > Jeff created a drivers/net/ethernet/8390/ directory for all of those,
> > which sounds sensible to me, but apparently he missed some of the
> > nonobvious ones.
> I was trying to keep the drivers that use the 8390 common files grouped
> together.
Please move a2065, ariadne and zorro8390 too.
> I know that there are other instances like this (for instance drivers
> derived from the lance.c driver) yet these derived drivers do not use
> the common files that other lance drivers use. Because they are
> derived, yet do not use the common code, should they still be grouped
> together?
IMO, yes.
^ permalink raw reply
* Re: [RFC 20/72] pasemic_mac*: Move the PA Semi driver
From: Olof Johansson @ 2011-06-26 1:34 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev
In-Reply-To: <1309010363-22750-21-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jun 25, 2011 at 6:58 AM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> Move the PA Semi driver into drivers/net/ethernet/ and make the
> necessary Kconfig and Makefile changes.
>
> CC: Olof Johansson <olof@lixom.net>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: [RFC 18/72] ehea/ibm*: Move the IBM drivers
From: Benjamin Herrenschmidt @ 2011-06-26 0:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Oliver Hartkopp, Jeff Kirsher, davem, netdev, Christoph Raisch,
Alfred Arnold, Santiago Leon
In-Reply-To: <201106251704.22561.arnd@arndb.de>
On Sat, 2011-06-25 at 17:04 +0200, Arnd Bergmann wrote:
> You can probably rename to just emac now, since the "old" emac driver
> has been gone for some time.
>
> The "new" part of the name does not refer to the hardware, just to
> the driver.
Right. Agreed.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] net, llc: Avoid undefined behaviour in llc_conn_ac_inc_vr_by_1()
From: Jesper Juhl @ 2011-06-26 0:01 UTC (permalink / raw)
To: David Miller; +Cc: acme, netdev, linux-kernel
In-Reply-To: <20110625.170445.957364657527336185.davem@davemloft.net>
On Sat, 25 Jun 2011, David Miller wrote:
> From: Jesper Juhl <jj@chaosbits.net>
> Date: Sun, 26 Jun 2011 00:11:12 +0200 (CEST)
>
> > Introduce a sequence point (;) between two writes to llc_sk(sk)->vR in
> > net/llc/llc_c_ac.c:llc_conn_ac_inc_vr_by_1() so that the order in
> > which the writes happen become well defined.
> >
> > While the code may work fine now it may break at any time with a
> > different compiler, a new version of current compiler or even just a
> > different optimization level of the current compiler. Much better to
> > clearly express what's intended in a way that guarantees the result.
> >
> > Signed-off-by: Jesper Juhl <jj@chaosbits.net>
>
> How about fixing the macro so that it doesn't have side effects
> like this?
>
> That's much better than a 6 line (improperly formatted, BTW) comment
> every time someone tried to use that macros with an lvalue that isn't
> a local variable.
Sure, that's also a way to go - better probably.
I just thought that I would fix up the one call site I found that was
problematic...
But gimme a couple of days (I don't have much free time) and I'll cook up
a different patch.
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply
* Re: [PATCH] net, llc: Avoid undefined behaviour in llc_conn_ac_inc_vr_by_1()
From: David Miller @ 2011-06-26 0:04 UTC (permalink / raw)
To: jj; +Cc: acme, netdev, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1106260009530.23991@swampdragon.chaosbits.net>
From: Jesper Juhl <jj@chaosbits.net>
Date: Sun, 26 Jun 2011 00:11:12 +0200 (CEST)
> Introduce a sequence point (;) between two writes to llc_sk(sk)->vR in
> net/llc/llc_c_ac.c:llc_conn_ac_inc_vr_by_1() so that the order in
> which the writes happen become well defined.
>
> While the code may work fine now it may break at any time with a
> different compiler, a new version of current compiler or even just a
> different optimization level of the current compiler. Much better to
> clearly express what's intended in a way that guarantees the result.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
How about fixing the macro so that it doesn't have side effects
like this?
That's much better than a 6 line (improperly formatted, BTW) comment
every time someone tried to use that macros with an lvalue that isn't
a local variable.
^ permalink raw reply
* Re: [RFC 11/72] cassini/niu/sun*: Move the Sun drivers
From: David Miller @ 2011-06-25 23:56 UTC (permalink / raw)
To: socketcan; +Cc: jeffrey.t.kirsher, netdev, sammy, asun, benh
In-Reply-To: <4E05F4D3.9020407@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Sat, 25 Jun 2011 16:46:43 +0200
> On 25.06.2011 15:58, Jeff Kirsher wrote:
>> Moves the Sun drivers into drivers/net/ethernet/sun/ and make
>> the necessary Kconfig and Makefile changes.
>>
>
> (..)
>
>> ---
>> MAINTAINERS | 1 +
>> drivers/net/Kconfig | 75 ----------------------
>> drivers/net/Makefile | 11 +---
>> drivers/net/ethernet/Kconfig | 1 +
>> drivers/net/ethernet/Makefile | 1 +
>> drivers/net/ethernet/sun/Kconfig | 91 +++++++++++++++++++++++++++
>> drivers/net/ethernet/sun/Makefile | 12 ++++
>> drivers/net/{ => ethernet/sun}/cassini.c | 0
>> drivers/net/{ => ethernet/sun}/cassini.h | 0
>> drivers/net/{ => ethernet/sun}/niu.c | 0
>> drivers/net/{ => ethernet/sun}/niu.h | 0
>> drivers/net/{ => ethernet/sun}/sun3_82586.c | 0
>> drivers/net/{ => ethernet/sun}/sun3_82586.h | 0
>
> s/sun3_// in filenames?
It's a special instance of the chip which only ever
appears on the motherboard of m68k based sun3 systems.
The sun3 prefix is absolutely appropriate.
^ permalink raw reply
* [PATCH] net, llc: Avoid undefined behaviour in llc_conn_ac_inc_vr_by_1()
From: Jesper Juhl @ 2011-06-25 22:11 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: David S. Miller, netdev, linux-kernel
Introduce a sequence point (;) between two writes to llc_sk(sk)->vR in
net/llc/llc_c_ac.c:llc_conn_ac_inc_vr_by_1() so that the order in
which the writes happen become well defined.
While the code may work fine now it may break at any time with a
different compiler, a new version of current compiler or even just a
different optimization level of the current compiler. Much better to
clearly express what's intended in a way that guarantees the result.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
net/llc/llc_c_ac.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/net/llc/llc_c_ac.c b/net/llc/llc_c_ac.c
index ea225bd..e535ca4 100644
--- a/net/llc/llc_c_ac.c
+++ b/net/llc/llc_c_ac.c
@@ -1296,7 +1296,14 @@ int llc_conn_ac_set_vr_0(struct sock *sk, struct sk_buff *skb)
int llc_conn_ac_inc_vr_by_1(struct sock *sk, struct sk_buff *skb)
{
- llc_sk(sk)->vR = PDU_GET_NEXT_Vr(llc_sk(sk)->vR);
+ /* Do not consolidate this on one line. Since the PDU_GET_NEXT_Vr
+ macro increments its argument which is the same as what we are
+ writing to, then we'll have two writes to the same variable
+ without an intervening sequence point, which leads to the
+ situation where we can't really know what gets stored as the
+ result since the compiler is free to do those in any order. */
+ const u8 new_vr = PDU_GET_NEXT_Vr(llc_sk(sk)->vR);
+ llc_sk(sk)->vR = new_vr;
return 0;
}
--
1.7.5.2
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: RFT: virtio_net: limit xmit polling
From: Roopa Prabhu @ 2011-06-25 19:44 UTC (permalink / raw)
To: Roopa Prabhu, Tom Lendacky, Michael S. Tsirkin
Cc: Krishna Kumar2, habanero, lguest, Shirley Ma, kvm, Carsten Otte,
linux-s390, Heiko Carstens, linux-kernel, virtualization, steved,
Christian Borntraeger, netdev, Martin Schwidefsky, linux390
In-Reply-To: <CA29D629.2C9B1%roprabhu@cisco.com>
[-- Attachment #1.1: Type: text/plain, Size: 3019 bytes --]
Here are the results I am getting with a Cisco 10G VIC adapter.
All tests are from the guest to an external host.
virtio-net-limit-xmit-polling/base:
TCP_STREAM: 8089Mbps
TCP_MAERTS: 9334Mbps
virtio-net-limit-xmit-polling/v0
TCP_STREAM: 8004Mbps
TCP_MAERTS: 9338Mbps
virtio-net-limit-xmit-polling/v1
TCP_STREAM: 8028Mbps
TCP_MAERTS: 9339Mbps
virtio-net-limit-xmit-polling/v2
TCP_STREAM: 8045Mbps
TCP_MAERTS: 9337Mbps
For the TCP_STREAM tests I don¹t get consistent results.
Every run gives me slightly different results. But its always between
7900Mbps to 8100Mbps.
But I also see this with the base kernel so its not related to these
patches.
Thanks,
Roopa
On 6/24/11 5:50 AM, "Roopa Prabhu" <roprabhu@cisco.com> wrote:
> Michael,
>
> I am testing this too.
> I have finished one round of testing. But am running it again just to
> confirm.
> This time I will see if I can collect some exit stats too. Will post results
> sometime this weekend.
> I am just doing TCP_STREAM and TCP_MAERTS from guest to remote host.
>
> Thanks,
> Roopa
>
>
> On 6/21/11 8:23 AM, "Tom Lendacky" <tahm@linux.vnet.ibm.com> wrote:
>
>> On Sunday, June 19, 2011 05:27:00 AM Michael S. Tsirkin wrote:
>>> > OK, different people seem to test different trees. In the hope to get
>>> > everyone on the same page, I created several variants of this patch so
>>> > they can be compared. Whoever's interested, please check out the
>>> > following, and tell me how these compare:
>>
>> I'm in the process of testing these patches. Base and v0 are complete
>> and v1 is near complete with v2 to follow. I'm testing with a variety
>> of TCP_RR and TCP_STREAM/TCP_MAERTS tests involving local guest-to-guest
>> tests and remote host-to-guest tests. I'll post the results in the next
>> day or two when the tests finish.
>>
>> Thanks,
>> Tom
>>
>>> >
>>> > kernel:
>>> >
>>> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
>>> >
>>> > virtio-net-limit-xmit-polling/base - this is net-next baseline to test
>>> > against virtio-net-limit-xmit-polling/v0 - fixes checks on out of capacity
>>> > virtio-net-limit-xmit-polling/v1 - previous revision of the patch
>>> > this does xmit,free,xmit,2*free,free
>>> > virtio-net-limit-xmit-polling/v2 - new revision of the patch
>>> > this does free,xmit,2*free,free
>>> >
>>> > There's also this on top:
>>> > virtio-net-limit-xmit-polling/v3 -> don't delay avail index update
>>> > I don't think it's important to test this one, yet
>>> >
>>> > Userspace to use: event index work is not yet merged upstream
>>> > so the revision to use is still this:
>>> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git
>>> > virtio-net-event-idx-v3
>>
>
>
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/virtualization
[-- Attachment #1.2: Type: text/html, Size: 4335 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC 59/72] r6040: Move the RDC driver
From: Florian Fainelli @ 2011-06-25 18:59 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, Sten Wang, Daniel Gimpelevich
In-Reply-To: <1309010363-22750-60-git-send-email-jeffrey.t.kirsher@intel.com>
Hello Jeff,
On Saturday 25 June 2011 15:59:10 Jeff Kirsher wrote:
> Move the RDC driver into drivers/net/ethernet/ and make the
> necessary Kconfig and Makefile changes.
>
> CC: Sten Wang <sten.wang@rdc.com.tw>
> CC: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
> CC: Florian Fainelli <florian@openwrt.org>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> MAINTAINERS | 2 +-
> drivers/net/Kconfig | 13 -------------
> drivers/net/Makefile | 1 -
> drivers/net/ethernet/Kconfig | 14 ++++++++++++++
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/{ => ethernet}/r6040.c | 0
> 6 files changed, 16 insertions(+), 15 deletions(-)
> rename drivers/net/{ => ethernet}/r6040.c (100%)
Why not move this to drivers/net/ethernet/rdc/r6040.c?
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9ddb715..f1f555d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5258,7 +5258,7 @@ RDC R6040 FAST ETHERNET DRIVER
> M: Florian Fainelli <florian@openwrt.org>
> L: netdev@vger.kernel.org
> S: Maintained
> -F: drivers/net/r6040.c
> +F: drivers/net/ethernet/r6040.c
>
> RDS - RELIABLE DATAGRAM SOCKETS
> M: Andy Grover <andy.grover@oracle.com>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 82da415..463e4cf 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -404,19 +404,6 @@ config FEALNX
> Say Y here to support the Myson MTD-800 family of PCI-based Ethernet
> cards. <http://www.myson.com.tw/>
>
> -config R6040
> - tristate "RDC R6040 Fast Ethernet Adapter support"
> - depends on NET_PCI && PCI
> - select CRC32
> - select MII
> - select PHYLIB
> - help
> - This is a driver for the R6040 Fast Ethernet MACs found in the
> - the RDC R-321x System-on-chips.
> -
> - To compile this driver as a module, choose M here: the module
> - will be called r6040. This is recommended.
> -
> config NET_POCKET
> bool "Pocket and portable adapters"
> depends on PARPORT
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index b7e875a..f57a0be 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -16,7 +16,6 @@ obj-$(CONFIG_PLIP) += plip.o
>
> obj-$(CONFIG_ROADRUNNER) += rrunner.o
>
> -obj-$(CONFIG_R6040) += r6040.o
> obj-$(CONFIG_ISERIES_VETH) += iseries_veth.o
> obj-$(CONFIG_FEALNX) += fealnx.o
> obj-$(CONFIG_SKFP) += skfp/
> diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
> index f5eb70e..3c10879 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -98,6 +98,20 @@ config PASEMI_MAC
> source "drivers/net/ethernet/qlogic/Kconfig"
> source "drivers/net/ethernet/racal/Kconfig"
> source "drivers/net/ethernet/radisys/Kconfig"
> +
> +config R6040
> + tristate "RDC R6040 Fast Ethernet Adapter support"
> + depends on PCI
> + select CRC32
> + select MII
> + select PHYLIB
> + ---help---
> + This is a driver for the R6040 Fast Ethernet MACs found in the
> + the RDC R-321x System-on-chips.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called r6040. This is recommended.
> +
> source "drivers/net/ethernet/realtek/Kconfig"
>
> config S6GMAC
> diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
> index 2ccb194..537631b 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -41,6 +41,7 @@ obj-$(CONFIG_PASEMI_MAC) += pasemi_mac.o
> pasemi_mac_ethtool.o obj-$(CONFIG_NET_VENDOR_QLOGIC) += qlogic/
> obj-$(CONFIG_NET_VENDOR_RACAL) += racal/
> obj-$(CONFIG_NET_VENDOR_RADISYS) += radisys/
> +obj-$(CONFIG_R6040) += r6040.o
> obj-$(CONFIG_NET_VENDOR_REALTEK) += realtek/
> obj-$(CONFIG_S6GMAC) += s6gmac.o
> obj-$(CONFIG_NET_VENDOR_SIS) += sis/
> diff --git a/drivers/net/r6040.c b/drivers/net/ethernet/r6040.c
> similarity index 100%
> rename from drivers/net/r6040.c
> rename to drivers/net/ethernet/r6040.c
--
Florian
^ permalink raw reply
* Re: [RFC 26/72] arm: Move the ARM/ACORN drivers
From: Arnd Bergmann @ 2011-06-25 18:22 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: Russell King - ARM Linux, davem@davemloft.net,
netdev@vger.kernel.org, Sriram, Vinay Hegde, Cyril Chemparathy,
Wan ZongShun, Lennert Buytenhek, Krzysztof Halasa, Anant Gole,
Chaithrika U S
In-Reply-To: <1309025217.2454.89.camel@jtkirshe-mobl>
On Saturday 25 June 2011, Jeff Kirsher wrote:
> On Sat, 2011-06-25 at 09:59 -0700, Arnd Bergmann wrote:
> > > More interestingly, if you have one of the 8390 clones, which
> > directory
> > > do you look in? And shouldn't etherh.c live along side 8390's files
> > > as etherh is 8390-derived?
> >
> > Jeff created a drivers/net/ethernet/8390/ directory for all of those,
> > which sounds sensible to me, but apparently he missed some of the
> > nonobvious ones.
>
> I was trying to keep the drivers that use the 8390 common files grouped
> together.
>
> I know that there are other instances like this (for instance drivers
> derived from the lance.c driver) yet these derived drivers do not use
> the common files that other lance drivers use. Because they are
> derived, yet do not use the common code, should they still be grouped
> together? Just a question, I am fine with the idea.
Generally, I'd say yes, but it's not a strong preference.
In other subsystems, we group similar stuff together like that as well,
as a reminder that it should better use the common infrastructure, so
that someone copying the odd implementation has a better chance of
noticing the mistake early.
Arnd
^ permalink raw reply
* Re: [RFC 30/72] atl*: Move the Atheros drivers
From: Chris Snook @ 2011-06-25 18:16 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, Jay Cliburn
In-Reply-To: <1309010363-22750-31-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jun 25, 2011 at 9:58 AM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> Move the Atheros drivers into drivers/net/ethernet/atheros/ and
> make the necessary Kconfig and Makefile changes.
>
> CC: Jay Cliburn <jcliburn@gmail.com>
> CC: Chris Snook <chris.snook@gmail.com>
> CC: Jie Yang <jie.yang@atheros.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
I'm fine with this as long as the other ethernet maintainers are fine
with the whole series. I don't want to be making changes like this
unless it's to a new standard that's applied consistently.
-- Chris
^ permalink raw reply
* Re: [RFC 54/72] au1000_eth/mipsnet/tc35815: Move the MIPS drivers
From: Jeff Kirsher @ 2011-06-25 18:11 UTC (permalink / raw)
To: Ralf Baechle
Cc: davem@davemloft.net, netdev@vger.kernel.org, Matt Porter,
Herbert Valerio Riedel, MontaVista Software, Kyle McMartin,
Helge Deller, James E.J. Bottomley, linux-parisc@vger.kernel.org,
Sam Creasey, Geert Uytterhoeven, linux-m68k@vger.kernel.org
In-Reply-To: <20110625161353.GA20976@linux-mips.org>
[-- Attachment #1: Type: text/plain, Size: 869 bytes --]
On Sat, 2011-06-25 at 09:13 -0700, Ralf Baechle wrote:
> On Sat, Jun 25, 2011 at 06:59:05AM -0700, Jeff Kirsher wrote:
>
> > Move the MIPS drivers into drivers/net/ethernet/mips/ and
> > make the necessary Kconfig and Makefile changes.
>
> NAck.
>
> sni_82596.c is a driver for the same chip but used in particular
> Siemens-
> Nixdorf systems. Lasi_82596 is an Intel NIC being used in PARISC
> systems.
> Not a good reason th throw PA-RISC drivers into the same directory
> after
> all PA-RISC has no relation to MIPS at all. So maybe they should go
> into
> drivers/net/ethernet/i82596 or drivers/net/ethernet/intel. And
> wherever
> they go, both drivers #include lib82596.c which your patch did not
> move
> around.
My bad, I had grouped these drivers because they both used lib82596.c
and had thought I had moved that file as well.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC 26/72] arm: Move the ARM/ACORN drivers
From: Jeff Kirsher @ 2011-06-25 18:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King - ARM Linux, davem@davemloft.net,
netdev@vger.kernel.org, Sriram, Vinay Hegde, Cyril Chemparathy,
Wan ZongShun, Lennert Buytenhek, Krzysztof Halasa, Anant Gole,
Chaithrika U S
In-Reply-To: <201106251859.38963.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
On Sat, 2011-06-25 at 09:59 -0700, Arnd Bergmann wrote:
> > More interestingly, if you have one of the 8390 clones, which
> directory
> > do you look in? And shouldn't etherh.c live along side 8390's files
> > as etherh is 8390-derived?
>
> Jeff created a drivers/net/ethernet/8390/ directory for all of those,
> which sounds sensible to me, but apparently he missed some of the
> nonobvious ones.
I was trying to keep the drivers that use the 8390 common files grouped
together.
I know that there are other instances like this (for instance drivers
derived from the lance.c driver) yet these derived drivers do not use
the common files that other lance drivers use. Because they are
derived, yet do not use the common code, should they still be grouped
together? Just a question, I am fine with the idea.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC 26/72] arm: Move the ARM/ACORN drivers
From: Jeff Kirsher @ 2011-06-25 18:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King - ARM Linux, davem@davemloft.net,
netdev@vger.kernel.org, Sriram, Vinay Hegde, Cyril Chemparathy,
Wan ZongShun, Lennert Buytenhek, Krzysztof Halasa, Anant Gole,
Chaithrika U S
In-Reply-To: <201106251859.38963.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
On Sat, 2011-06-25 at 09:59 -0700, Arnd Bergmann wrote:
>
> > ether1 is 82586, so presumably that should be Intel subdirectory.
>
> Yes, according to the new layout, it should at least live together
> with the other 82586-based drivers (eexpress.c, ni52.c, sun3_82586.c),
> which could be either a directory for all of these, or the
> generic intel directory.
My personal preference is that these drivers that were not created by
Intel or maintained by Intel, not be in the Intel sub-directory.
While many of the drivers were organized in a layout that matches
drivers/net/ethernet/<company>, I tried to organize the drivers in the
most logical way possible (i.e. 8390/ all the drivers that used the 8390
shared files).
I do like all the suggestions made, except for the suggestion to move
eexpress.c, eepro.c, sun3_82596.c, etc. in to the intel sub-directory.
I am open to suggestions on a way to better to organize these drivers
that use an Intel part but were created and maintained by someone else.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ 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