* Re: [net-next-2.6 PATCH 1/2] ixgbe: fix for link failure on SFP+ DA cables
From: David Miller @ 2010-12-06 21:21 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, donald.c.skidmore
In-Reply-To: <20101203232218.21869.62349.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 03 Dec 2010 15:23:30 -0800
> From: Don Skidmore <donald.c.skidmore@intel.com>
>
> This patch helps prevent FW/SW semaphore collision from leading
> to link establishment failure. The collision might mess up the
> PHY registers so we reset the PHY. However there are SFI/KR areas
> in the PHY that are not reset with a Reset_AN so we need to change
> LMS to reset it. Also wait until AN state machine is AN_GOOD
>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Tested-by: Stephen Ko <stephen.s.ko@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/2] ixgbe: fix enum type mismatch on disable laser
From: David Miller @ 2010-12-06 21:21 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips
In-Reply-To: <20101203232351.21869.98417.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 03 Dec 2010 15:24:05 -0800
> From: Don Skidmore <donald.c.skidmore@intel.com>
>
> Fixes a recent bug on the patch (c6ecf39a10ceec3e97096e2a8d3eadcecd593422)
> that disabled the laser on ifconfig down. Compilers were seeing a enum
> mismatch.
>
> Signed-off-by Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: NET_NS: unregister_netdevice: waiting for lo to become free (adding ipv6 address to interface)
From: Eric W. Biederman @ 2010-12-06 21:22 UTC (permalink / raw)
To: jean-philippe.menil
Cc: netdev, Michael Leun, David Lamparter, Greg KH, davem,
linux-kernel, Alexey Dobriyan, Patrick McHardy
In-Reply-To: <4CFD0A8F.8010906@univ-nantes.fr>
Menil Jean-Philippe <jean-philippe.menil@univ-nantes.fr> writes:
> Le 24/10/2010 15:15, Michael Leun a écrit :
>> On Fri, 22 Oct 2010 19:05:32 +0200
>> Michael Leun<lkml20100708@newton.leun.net> wrote:
>>
>>> On Fri, 22 Oct 2010 14:48:58 +0200
>>> David Lamparter<equinox@diac24.net> wrote:
>>>
>>>> On Thu, Oct 21, 2010 at 05:15:32PM +0200, Michael Leun wrote:
>>>>> unfortunately the bug described below originally reported in
>>>>> 2.6.35-rcX is still there in 2.6.36.
>>>>
>>>> can you post your full kernel .config?
>>>
>>> Please find below.
>>>
>>>> I'm using network namespaces quite extensively - OpenVPN and IPv6
>>>> included - and i haven't hit this bug. That makes it rather likely
>>>> it depends on some option difference.
>>>
>>> I take candidates for options to change for test... ;-)
>>>
>>> Maybe I will try to strip it down for test towards a minimal config.
>>
>> Now I have tried a kernel config with almost everything disabled -
>> please find below.
>>
>> If I have overlooked anything I should disable (or if you suggest I
>> should not disable, but enable any option) - please tell me.
>>
>> I've created an ~2.5MB bootable ISO image based on buildroot/busybox
>> with this kernel, which also shows this bug (e.g. when run in
>> VirtualBox).
>>
>> If anybody is interested I could send this image as mail attachment or
>> provide a download link.
>>
>> ml@xenia:~> grep -v "^#" .config |grep -v "^ *$"
>> CONFIG_X86_32=y
>> CONFIG_X86=y
>> CONFIG_INSTRUCTION_DECODER=y
>> CONFIG_OUTPUT_FORMAT="elf32-i386"
>> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
>> CONFIG_GENERIC_CMOS_UPDATE=y
>> CONFIG_CLOCKSOURCE_WATCHDOG=y
>> CONFIG_GENERIC_CLOCKEVENTS=y
>> CONFIG_LOCKDEP_SUPPORT=y
>> CONFIG_STACKTRACE_SUPPORT=y
>> CONFIG_HAVE_LATENCYTOP_SUPPORT=y
>> CONFIG_MMU=y
>> CONFIG_ZONE_DMA=y
>> CONFIG_NEED_SG_DMA_LENGTH=y
>> CONFIG_GENERIC_ISA_DMA=y
>> CONFIG_GENERIC_IOMAP=y
>> CONFIG_GENERIC_BUG=y
>> CONFIG_GENERIC_HWEIGHT=y
>> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
>> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
>> CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
>> CONFIG_GENERIC_CALIBRATE_DELAY=y
>> CONFIG_ARCH_HAS_CPU_RELAX=y
>> CONFIG_ARCH_HAS_DEFAULT_IDLE=y
>> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
>> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
>> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
>> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
>> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
>> CONFIG_ARCH_SUSPEND_POSSIBLE=y
>> CONFIG_ARCH_POPULATES_NODE_MAP=y
>> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
>> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
>> CONFIG_HAVE_EARLY_RES=y
>> CONFIG_GENERIC_HARDIRQS=y
>> CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
>> CONFIG_GENERIC_IRQ_PROBE=y
>> CONFIG_X86_32_LAZY_GS=y
>> CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
>> CONFIG_KTIME_SCALAR=y
>> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
>> CONFIG_CONSTRUCTORS=y
>> CONFIG_EXPERIMENTAL=y
>> CONFIG_BROKEN_ON_SMP=y
>> CONFIG_INIT_ENV_ARG_LIMIT=32
>> CONFIG_CROSS_COMPILE=""
>> CONFIG_LOCALVERSION=""
>> CONFIG_HAVE_KERNEL_GZIP=y
>> CONFIG_HAVE_KERNEL_BZIP2=y
>> CONFIG_HAVE_KERNEL_LZMA=y
>> CONFIG_HAVE_KERNEL_LZO=y
>> CONFIG_KERNEL_LZMA=y
>> CONFIG_TREE_RCU=y
>> CONFIG_RCU_FANOUT=32
>> CONFIG_IKCONFIG=y
>> CONFIG_IKCONFIG_PROC=y
>> CONFIG_LOG_BUF_SHIFT=18
>> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
>> CONFIG_NAMESPACES=y
>> CONFIG_NET_NS=y
>> CONFIG_BLK_DEV_INITRD=y
>> CONFIG_INITRAMFS_SOURCE=""
>> CONFIG_RD_GZIP=y
>> CONFIG_RD_BZIP2=y
>> CONFIG_RD_LZMA=y
>> CONFIG_RD_LZO=y
>> CONFIG_SYSCTL=y
>> CONFIG_ANON_INODES=y
>> CONFIG_UID16=y
>> CONFIG_SYSCTL_SYSCALL=y
>> CONFIG_KALLSYMS=y
>> CONFIG_HOTPLUG=y
>> CONFIG_PRINTK=y
>> CONFIG_BUG=y
>> CONFIG_ELF_CORE=y
>> CONFIG_PCSPKR_PLATFORM=y
>> CONFIG_BASE_FULL=y
>> CONFIG_FUTEX=y
>> CONFIG_EPOLL=y
>> CONFIG_SIGNALFD=y
>> CONFIG_TIMERFD=y
>> CONFIG_EVENTFD=y
>> CONFIG_SHMEM=y
>> CONFIG_AIO=y
>> CONFIG_HAVE_PERF_EVENTS=y
>> CONFIG_PERF_EVENTS=y
>> CONFIG_VM_EVENT_COUNTERS=y
>> CONFIG_PCI_QUIRKS=y
>> CONFIG_SLUB_DEBUG=y
>> CONFIG_SLUB=y
>> CONFIG_HAVE_OPROFILE=y
>> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
>> CONFIG_HAVE_IOREMAP_PROT=y
>> CONFIG_HAVE_KPROBES=y
>> CONFIG_HAVE_KRETPROBES=y
>> CONFIG_HAVE_OPTPROBES=y
>> CONFIG_HAVE_ARCH_TRACEHOOK=y
>> CONFIG_HAVE_DMA_ATTRS=y
>> CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
>> CONFIG_HAVE_DMA_API_DEBUG=y
>> CONFIG_HAVE_HW_BREAKPOINT=y
>> CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
>> CONFIG_HAVE_USER_RETURN_NOTIFIER=y
>> CONFIG_HAVE_PERF_EVENTS_NMI=y
>> CONFIG_HAVE_GENERIC_DMA_COHERENT=y
>> CONFIG_SLABINFO=y
>> CONFIG_RT_MUTEXES=y
>> CONFIG_BASE_SMALL=0
>> CONFIG_BLOCK=y
>> CONFIG_LBDAF=y
>> CONFIG_IOSCHED_NOOP=y
>> CONFIG_DEFAULT_NOOP=y
>> CONFIG_DEFAULT_IOSCHED="noop"
>> CONFIG_INLINE_SPIN_UNLOCK=y
>> CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
>> CONFIG_INLINE_READ_UNLOCK=y
>> CONFIG_INLINE_READ_UNLOCK_IRQ=y
>> CONFIG_INLINE_WRITE_UNLOCK=y
>> CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
>> CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
>> CONFIG_M586=y
>> CONFIG_X86_CPU=y
>> CONFIG_X86_INTERNODE_CACHE_SHIFT=5
>> CONFIG_X86_CMPXCHG=y
>> CONFIG_X86_L1_CACHE_SHIFT=5
>> CONFIG_X86_XADD=y
>> CONFIG_X86_F00F_BUG=y
>> CONFIG_X86_WP_WORKS_OK=y
>> CONFIG_X86_INVLPG=y
>> CONFIG_X86_BSWAP=y
>> CONFIG_X86_POPAD_OK=y
>> CONFIG_X86_ALIGNMENT_16=y
>> CONFIG_X86_MINIMUM_CPU_FAMILY=4
>> CONFIG_CPU_SUP_INTEL=y
>> CONFIG_CPU_SUP_CYRIX_32=y
>> CONFIG_CPU_SUP_AMD=y
>> CONFIG_CPU_SUP_CENTAUR=y
>> CONFIG_CPU_SUP_TRANSMETA_32=y
>> CONFIG_CPU_SUP_UMC_32=y
>> CONFIG_DMI=y
>> CONFIG_NR_CPUS=1
>> CONFIG_PREEMPT_NONE=y
>> CONFIG_VM86=y
>> CONFIG_HIGHMEM4G=y
>> CONFIG_PAGE_OFFSET=0xC0000000
>> CONFIG_HIGHMEM=y
>> CONFIG_NEED_NODE_MEMMAP_SIZE=y
>> CONFIG_ARCH_FLATMEM_ENABLE=y
>> CONFIG_ARCH_SPARSEMEM_ENABLE=y
>> CONFIG_ARCH_SELECT_MEMORY_MODEL=y
>> CONFIG_ILLEGAL_POINTER_VALUE=0
>> CONFIG_SELECT_MEMORY_MODEL=y
>> CONFIG_SPARSEMEM_MANUAL=y
>> CONFIG_SPARSEMEM=y
>> CONFIG_HAVE_MEMORY_PRESENT=y
>> CONFIG_SPARSEMEM_STATIC=y
>> CONFIG_SPLIT_PTLOCK_CPUS=4
>> CONFIG_ZONE_DMA_FLAG=1
>> CONFIG_BOUNCE=y
>> CONFIG_VIRT_TO_BUS=y
>> CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
>> CONFIG_MTRR=y
>> CONFIG_X86_PAT=y
>> CONFIG_ARCH_USES_PG_UNCACHED=y
>> CONFIG_HZ_1000=y
>> CONFIG_HZ=1000
>> CONFIG_PHYSICAL_START=0x1000000
>> CONFIG_PHYSICAL_ALIGN=0x1000000
>> CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
>> CONFIG_PCI=y
>> CONFIG_PCI_GOANY=y
>> CONFIG_PCI_BIOS=y
>> CONFIG_PCI_DIRECT=y
>> CONFIG_PCI_DOMAINS=y
>> CONFIG_ISA_DMA_API=y
>> CONFIG_K8_NB=y
>> CONFIG_BINFMT_ELF=y
>> CONFIG_HAVE_AOUT=y
>> CONFIG_HAVE_ATOMIC_IOMAP=y
>> CONFIG_NET=y
>> CONFIG_UNIX=y
>> CONFIG_INET=y
>> CONFIG_IP_FIB_HASH=y
>> CONFIG_TCP_CONG_CUBIC=y
>> CONFIG_DEFAULT_TCP_CONG="cubic"
>> CONFIG_IPV6=y
>> CONFIG_UEVENT_HELPER_PATH=""
>> CONFIG_DEVTMPFS=y
>> CONFIG_DEVTMPFS_MOUNT=y
>> CONFIG_PREVENT_FIRMWARE_BUILD=y
>> CONFIG_FW_LOADER=y
>> CONFIG_EXTRA_FIRMWARE=""
>> CONFIG_HAVE_IDE=y
>> CONFIG_SCSI_MOD=y
>> CONFIG_NETDEVICES=y
>> CONFIG_VETH=y
>> CONFIG_INPUT=y
>> CONFIG_INPUT_MOUSEDEV=y
>> CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
>> CONFIG_INPUT_MOUSEDEV_SCREEN_Y=576
>> CONFIG_INPUT_KEYBOARD=y
>> CONFIG_KEYBOARD_ATKBD=y
>> CONFIG_SERIO=y
>> CONFIG_SERIO_I8042=y
>> CONFIG_SERIO_LIBPS2=y
>> CONFIG_VT=y
>> CONFIG_CONSOLE_TRANSLATIONS=y
>> CONFIG_VT_CONSOLE=y
>> CONFIG_HW_CONSOLE=y
>> CONFIG_FIX_EARLYCON_MEM=y
>> CONFIG_UNIX98_PTYS=y
>> CONFIG_DEVPORT=y
>> CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
>> CONFIG_SSB_POSSIBLE=y
>> CONFIG_VGA_ARB=y
>> CONFIG_VGA_ARB_MAX_GPUS=16
>> CONFIG_VGA_CONSOLE=y
>> CONFIG_VGACON_SOFT_SCROLLBACK=y
>> CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
>> CONFIG_DUMMY_CONSOLE=y
>> CONFIG_FIRMWARE_MEMMAP=y
>> CONFIG_FILE_LOCKING=y
>> CONFIG_PROC_FS=y
>> CONFIG_PROC_SYSCTL=y
>> CONFIG_PROC_PAGE_MONITOR=y
>> CONFIG_SYSFS=y
>> CONFIG_MSDOS_PARTITION=y
>> CONFIG_TRACE_IRQFLAGS_SUPPORT=y
>> CONFIG_FRAME_WARN=2048
>> CONFIG_DEBUG_BUGVERBOSE=y
>> CONFIG_DEBUG_MEMORY_INIT=y
>> CONFIG_ARCH_WANT_FRAME_POINTERS=y
>> CONFIG_USER_STACKTRACE_SUPPORT=y
>> CONFIG_HAVE_FUNCTION_TRACER=y
>> CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
>> CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
>> CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
>> CONFIG_HAVE_DYNAMIC_FTRACE=y
>> CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
>> CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
>> CONFIG_TRACING_SUPPORT=y
>> CONFIG_HAVE_ARCH_KGDB=y
>> CONFIG_HAVE_ARCH_KMEMCHECK=y
>> CONFIG_EARLY_PRINTK=y
>> CONFIG_DOUBLEFAULT=y
>> CONFIG_HAVE_MMIOTRACE_SUPPORT=y
>> CONFIG_IO_DELAY_TYPE_0X80=0
>> CONFIG_IO_DELAY_TYPE_0XED=1
>> CONFIG_IO_DELAY_TYPE_UDELAY=2
>> CONFIG_IO_DELAY_TYPE_NONE=3
>> CONFIG_IO_DELAY_0X80=y
>> CONFIG_DEFAULT_IO_DELAY_TYPE=0
>> CONFIG_DEFAULT_SECURITY_DAC=y
>> CONFIG_DEFAULT_SECURITY=""
>> CONFIG_HAVE_KVM=y
>> CONFIG_GENERIC_FIND_FIRST_BIT=y
>> CONFIG_GENERIC_FIND_NEXT_BIT=y
>> CONFIG_GENERIC_FIND_LAST_BIT=y
>> CONFIG_ZLIB_INFLATE=y
>> CONFIG_LZO_DECOMPRESS=y
>> CONFIG_DECOMPRESS_GZIP=y
>> CONFIG_DECOMPRESS_BZIP2=y
>> CONFIG_DECOMPRESS_LZMA=y
>> CONFIG_DECOMPRESS_LZO=y
>> CONFIG_HAS_IOMEM=y
>> CONFIG_HAS_IOPORT=y
>> CONFIG_HAS_DMA=y
>> CONFIG_NLATTR=y
>>
>
> Hi,
>
> curiously, i'm facing a similar problem in 2.6.36.1
>
> in my container, when i configure ipv6 adress on the interfaces, everything
> seems good on the first boot of the host. If i shutdown my container (lxc), then
> boot it, i observe the following logs:
> Dec 6 17:04:12 suntory.u06.univ-nantes.prive kernel: [ 368.192019]
> unregister_netdevice: waiting for lo to become free. Usage count = 4
> Dec 6 17:04:22 suntory.u06.univ-nantes.prive kernel: [ 378.432018]
> unregister_netdevice: waiting for lo to become free. Usage count = 4
> Dec 6 17:04:32 suntory.u06.univ-nantes.prive kernel: [ 388.672015]
> unregister_netdevice: waiting for lo to become free. Usage count = 4
> Dec 6 17:04:42 suntory.u06.univ-nantes.prive kernel: [ 398.912016]
> unregister_netdevice: waiting for lo to become free. Usage count = 4
> Dec 6 17:04:53 suntory.u06.univ-nantes.prive kernel: [ 409.152016]
> unregister_netdevice: waiting for lo to become free. Usage count = 4
> Dec 6 17:05:03 suntory.u06.univ-nantes.prive kernel: [ 419.392018]
> unregister_netdevice: waiting for lo to become free. Usage count = 4
> Dec 6 17:05:13 suntory.u06.univ-nantes.prive kernel: [ 429.632018]
> unregister_netdevice: waiting for lo to become free. Usage count = 4
> Dec 6 17:05:23 suntory.u06.univ-nantes.prive kernel: [ 439.876016]
> unregister_netdevice: waiting for lo to become free. Usage count = 4
> Dec 6 17:05:34 suntory.u06.univ-nantes.prive kernel: [ 450.116015]
> unregister_netdevice: waiting for lo to become free. Usage count = 4
> Dec 6 17:05:44 suntory.u06.univ-nantes.prive kernel: [ 460.356019]
> unregister_netdevice: waiting for lo to become free. Usage count = 4
> Dec 6 17:05:54 suntory.u06.univ-nantes.prive kernel: [ 470.596020]
> unregister_netdevice: waiting for lo to become free. Usage count = 4
> Dec 6 17:06:04 suntory.u06.univ-nantes.prive kernel: [ 480.836019]
> unregister_netdevice: waiting for lo to become free. Usage count = 4
> Dec 6 17:06:05 suntory.u06.univ-nantes.prive kernel: [ 481.468021] INFO: task
> lxc-start:3805 blocked for more than 120 seconds.
>
> Then i must reboot the host.
> The same on kernel 2.6.34, but everything is good on a 2.6.32
>
> Some relvant informations about the kernel:
> root@suntory:~# cat /boot/config-2.6.36.1-dsiun-1d | grep -i sysfs
> # CONFIG_SYSFS_DEPRECATED_V2 is not set
> CONFIG_ACPI_SYSFS_POWER=y
> # CONFIG_WIRELESS_EXT_SYSFS is not set
> CONFIG_ISCSI_BOOT_SYSFS=m
> CONFIG_RTC_INTF_SYSFS=y
> CONFIG_SYSFS=y
> root@suntory:~# cat /boot/config-2.6.36.1-dsiun-1d | grep -i net_ns
> CONFIG_NET_NS=y
>
> Is there anything in my configuration, i must check in order to get ipv6 working
> fully in the container?
2.6.37-rc4 is working here. There were problems earlier in the earlier
rcs. Can you try that?
There have been a couple of different reference counting bugs between
2.6.34 and the present, and I haven't tracked them, just noticed they
exist.
Eric
^ permalink raw reply
* Re: [PATCH] net: am79c961a: Omit private ndo_get_stats function
From: David Miller @ 2010-12-06 21:25 UTC (permalink / raw)
To: linux; +Cc: tklauser, netdev
In-Reply-To: <20101203154057.GC30898@n2100.arm.linux.org.uk>
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
Date: Fri, 3 Dec 2010 15:40:57 +0000
> On Thu, Dec 02, 2010 at 06:20:05PM +0100, Tobias Klauser wrote:
>> am79c961_getstats() just returns dev->stats so we can leave it out
>> alltogether and let dev_get_stats() do the job.
>>
>> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH] net: emaclite: Omit private ndo_get_stats function
From: David Miller @ 2010-12-06 21:25 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1291310439-5813-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 2 Dec 2010 18:20:39 +0100
> xemaclite_get_stats() just returns dev->stats so we can leave it out
> alltogether and let dev_get_stats() do the job.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH] net: cris/eth_v10: Use net_device_stats from struct net_device_stats
From: David Miller @ 2010-12-06 21:25 UTC (permalink / raw)
To: tklauser; +Cc: netdev, starvik, jesper.nilsson
In-Reply-To: <1291310525-6101-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 2 Dec 2010 18:22:05 +0100
> struct net_device has its own struct net_device_stats member, so use
> this one instead of a private copy in struct net_local.
>
> Note: This patch was not even compile tested.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH 2.6.36] vlan: Avoid hwaccel vlan packets when vid not used
From: Michael Leun @ 2010-12-06 21:27 UTC (permalink / raw)
To: Jesse Gross; +Cc: Eric Dumazet, David Miller, Ben Greear, linux-kernel, netdev
In-Reply-To: <AANLkTikKkAesHc4Fi4SwAkV0e65D0TQRztrRYoDNu3MP@mail.gmail.com>
On Mon, 6 Dec 2010 12:04:48 -0800
Jesse Gross <jesse@nicira.com> wrote:
> On Mon, Dec 6, 2010 at 11:34 AM, Michael Leun
> <lkml20101129@newton.leun.net> wrote:
> > On Mon, 6 Dec 2010 10:14:55 -0800
> > Jesse Gross <jesse@nicira.com> wrote:
> >
> >> On Sun, Dec 5, 2010 at 2:44 AM, Michael Leun
> >> <lkml20101129@newton.leun.net> wrote:
> >> > Hi Jesse,
> >> >
> >> > On Sun, 5 Dec 2010 10:55:28 +0100
> >> > Michael Leun <lkml20101129@newton.leun.net> wrote:
> >> >
> >> >> On Sun, 05 Dec 2010 09:03:53 +0100
> >> >> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >> >>
> >> >> > > But on
> >> >> > >
> >> >> > > hpdl320g5:/home/ml # lspci | grep Eth
> >> >> > > 03:04.0 Ethernet controller: Broadcom Corporation NetXtreme
> >> >> > > BCM5714 Gigabit Ethernet (rev a3) 03:04.1 Ethernet
> >> >> > > controller: Broadcom Corporation NetXtreme BCM5714 Gigabit
> >> >> > > Ethernet (rev a3)
> >> >> > >
> >> >> > > the good message is that it also does not crash, but with
> >> >> > > tcpdump I see vlan tags when no vlan devices configured on
> >> >> > > the respective eth, if so I do not see tags anymore vlan
> >> >> > > tags on the trunk interface.
> >> >> > >
> >> >> >
> >> >> > For all these very specific needs, you'll have to try 2.6.37
> >> >> > I am afraid. Jesse did huge changes to exactly make this
> >> >> > working, we wont backport this to 2.6.36, but only avoid
> >> >> > crashes.
> >> >>
> >> >> OK, I'm perfectly fine with that, of course, actually nice to
> >> >> hear that the issue already is addressed.
> >> >>
> >> >> Likely I'll give some rc an shot on this machine (maybe over
> >> >> christmas), but it is an production machine (acutally testing
> >> >> other devices is the "product" produced on this machine), so
> >> >> unfortunately I'm not that free in when and what I can do (but
> >> >> the possibility to, for example, bridge the trunk interface
> >> >> would make testing easier, that justifies something...).
> >> >>
> >> >> Thank you all very much for your work.
> >> >
> >> > Are these changes already in 2.6.37-rc4? Or, if not are they
> >> > somewhere publically available already?
> >> >
> >> > I looked into various changelogs but have some difficulties to
> >> > identify them...
> >> >
> >> > Maybe I have some time next days to give them an try...
> >>
> >> Yes, all of the existing vlan changes are in 2.6.37-rc4. There
> >> were a number of patches but the main one was
> >> 3701e51382a026cba10c60b03efabe534fba4ca4
> >
> > Then, I'm afraid, this (seeing vlan tags even if vlan interfaces are
> > configured) does not work on HP DL320G5 (for exact description and
> > examples please see my mail a few days ago).
>
> What driver are you using? Is it tg3?
>
> The vlan changes that I made unfortunately require updating drivers to
> get the full benefit. I've been busy lately so tg3 hasn't yet been
> updated.
>
> I know that tg3 does some things differently depending on whether a
> vlan group is configured, so that would likely be the cause of what
> you are seeing. I'd have to look at it in more detail to be sure
> though.
>
> You said that everything works on the other Broadcom NIC that you
> tested? Maybe it uses bnx2 instead?
>
Both machines use tg3 / 2.6.36.1 - one is opensuse, one ubuntu (but
this should not matter, I think).
If I can do anything to support your investigations / work (most
likely testing / providing information) please let me know.
--
MfG,
Michael Leun
^ permalink raw reply
* Re: [PATCH v2] net/r8169: Remove the firmware of RTL8111D
From: Maxim Levitsky @ 2010-12-06 21:38 UTC (permalink / raw)
To: Hayes Wang; +Cc: romieu, netdev, linux-kernel
In-Reply-To: <1291619474-3244-1-git-send-email-hayeswang@realtek.com>
On Mon, 2010-12-06 at 15:11 +0800, Hayes Wang wrote:
> Remove the firmware of RTL8111D from the kernel.
> The binary file of firmware would be moved to linux-firmware repository.
> The firmwares are rtl_nic/rtl8168d-1.fw and rtl_nic/rtl8168d-2.fw.
> The driver would load the firmware through request_firmware. The driver
> would just go along if the firmware couldn't be found. However, it is
> suggested to be done with the suitable firmware.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Good day.
Hayes Wang, maybe you know who is responsible for DVB division in your
company?
I recently bought a RTL2832 based DVB-T stick and I like to make it
supportable in linux out of box.
I think I have enough knowledge/experience to do that.
(I currently use your company's driver and it works just fine)
What I miss is datasheets on the device (I can manage without them using
your driver source as a reference, but datasheets will help me a lot
simplifying things, and reduce bugs).
And I need a official statement that driver you released is
GPL-compatible.
I found few versions of it in few unofficial locations in the web, and
it contains the 'MODULE_VERSION("GPL")', but files miss the GPL header,
and in few places the code comments state that source in the file was
taken from sources provided by other companies (e.g. Microtune).
Thanks in advance,
Maxim Levitsky
> ---
> drivers/net/r8169.c | 796 ++++++++-------------------------------------------
> 1 files changed, 117 insertions(+), 679 deletions(-)
> mode change 100644 => 100755 drivers/net/r8169.c
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> old mode 100644
> new mode 100755
> index 7d33ef4..e0df607
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -24,6 +24,7 @@
> #include <linux/init.h>
> #include <linux/dma-mapping.h>
> #include <linux/pm_runtime.h>
> +#include <linux/firmware.h>
>
> #include <asm/system.h>
> #include <asm/io.h>
> @@ -1383,6 +1384,50 @@ static void rtl_phy_write(void __iomem *ioaddr, const struct phy_reg *regs, int
> }
> }
>
> +#define PHY_READ 0x00000000
> +#define PHY_DATA_OR 0x10000000
> +#define PHY_DATA_AND 0x20000000
> +#define PHY_BJMPN 0x30000000
> +#define PHY_READ_EFUSE 0x40000000
> +#define PHY_READ_MAC_BYTE 0x50000000
> +#define PHY_WRITE_MAC_BYTE 0x60000000
> +#define PHY_CLEAR_READCOUNT 0x70000000
> +#define PHY_WRITE 0x80000000
> +#define PHY_READCOUNT_EQ_SKIP 0x90000000
> +#define PHY_COMP_EQ_SKIPN 0xA0000000
> +#define PHY_COMP_NEQ_SKIPN 0xB0000000
> +#define PHY_WRITE_PREVIOUS 0xC0000000
> +#define PHY_SKIPN 0xD0000000
> +#define PHY_DELAY_MS 0xE0000000
> +#define PHY_WRITE_ERI_WORD 0xF0000000
> +
> +static void
> +rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
> +{
> + void __iomem *ioaddr = tp->mmio_addr;
> + u32 *phytable = (u32 *)fw->data;
> + u32 action;
> + size_t len = fw->size / sizeof(*phytable);
> + u32 regno, data;
> +
> + while (len-- > 0 && *phytable != 0) {
> + action = le32_to_cpu(*phytable);
> + regno = (action & 0x0FFF0000) >> 16;
> + data = action & 0x0000FFFF;
> +
> + switch(action & 0xF0000000) {
> + case PHY_WRITE:
> + mdio_write(ioaddr, regno, data);
> + phytable++;
> + break;
> + default:
> + netif_err(tp, probe, tp->dev,
> + "Unknown action 0x%08x\n", action);
> + return;
> + }
> + }
> +}
> +
> static void rtl8169s_hw_phy_config(void __iomem *ioaddr)
> {
> static const struct phy_reg phy_reg_init[] = {
> @@ -1715,9 +1760,10 @@ static void rtl8168c_4_hw_phy_config(void __iomem *ioaddr)
> rtl8168c_3_hw_phy_config(ioaddr);
> }
>
> -static void rtl8168d_1_hw_phy_config(void __iomem *ioaddr)
> +static void rtl8168d_1_hw_phy_config(struct rtl8169_private *tp)
> {
> static const struct phy_reg phy_reg_init_0[] = {
> + /* Channel Estimation */
> { 0x1f, 0x0001 },
> { 0x06, 0x4064 },
> { 0x07, 0x2863 },
> @@ -1734,379 +1780,41 @@ static void rtl8168d_1_hw_phy_config(void __iomem *ioaddr)
> { 0x12, 0xf49f },
> { 0x13, 0x070b },
> { 0x1a, 0x05ad },
> - { 0x14, 0x94c0 }
> - };
> - static const struct phy_reg phy_reg_init_1[] = {
> + { 0x14, 0x94c0 },
> +
> + /*
> + * Tx Error Issue
> + * enhance line driver power
> + */
> { 0x1f, 0x0002 },
> { 0x06, 0x5561 },
> { 0x1f, 0x0005 },
> { 0x05, 0x8332 },
> - { 0x06, 0x5561 }
> - };
> - static const struct phy_reg phy_reg_init_2[] = {
> - { 0x1f, 0x0005 },
> - { 0x05, 0xffc2 },
> - { 0x1f, 0x0005 },
> - { 0x05, 0x8000 },
> - { 0x06, 0xf8f9 },
> - { 0x06, 0xfaef },
> - { 0x06, 0x59ee },
> - { 0x06, 0xf8ea },
> - { 0x06, 0x00ee },
> - { 0x06, 0xf8eb },
> - { 0x06, 0x00e0 },
> - { 0x06, 0xf87c },
> - { 0x06, 0xe1f8 },
> - { 0x06, 0x7d59 },
> - { 0x06, 0x0fef },
> - { 0x06, 0x0139 },
> - { 0x06, 0x029e },
> - { 0x06, 0x06ef },
> - { 0x06, 0x1039 },
> - { 0x06, 0x089f },
> - { 0x06, 0x2aee },
> - { 0x06, 0xf8ea },
> - { 0x06, 0x00ee },
> - { 0x06, 0xf8eb },
> - { 0x06, 0x01e0 },
> - { 0x06, 0xf87c },
> - { 0x06, 0xe1f8 },
> - { 0x06, 0x7d58 },
> - { 0x06, 0x409e },
> - { 0x06, 0x0f39 },
> - { 0x06, 0x46aa },
> - { 0x06, 0x0bbf },
> - { 0x06, 0x8290 },
> - { 0x06, 0xd682 },
> - { 0x06, 0x9802 },
> - { 0x06, 0x014f },
> - { 0x06, 0xae09 },
> - { 0x06, 0xbf82 },
> - { 0x06, 0x98d6 },
> - { 0x06, 0x82a0 },
> - { 0x06, 0x0201 },
> - { 0x06, 0x4fef },
> - { 0x06, 0x95fe },
> - { 0x06, 0xfdfc },
> - { 0x06, 0x05f8 },
> - { 0x06, 0xf9fa },
> - { 0x06, 0xeef8 },
> - { 0x06, 0xea00 },
> - { 0x06, 0xeef8 },
> - { 0x06, 0xeb00 },
> - { 0x06, 0xe2f8 },
> - { 0x06, 0x7ce3 },
> - { 0x06, 0xf87d },
> - { 0x06, 0xa511 },
> - { 0x06, 0x1112 },
> - { 0x06, 0xd240 },
> - { 0x06, 0xd644 },
> - { 0x06, 0x4402 },
> - { 0x06, 0x8217 },
> - { 0x06, 0xd2a0 },
> - { 0x06, 0xd6aa },
> - { 0x06, 0xaa02 },
> - { 0x06, 0x8217 },
> - { 0x06, 0xae0f },
> - { 0x06, 0xa544 },
> - { 0x06, 0x4402 },
> - { 0x06, 0xae4d },
> - { 0x06, 0xa5aa },
> - { 0x06, 0xaa02 },
> - { 0x06, 0xae47 },
> - { 0x06, 0xaf82 },
> - { 0x06, 0x13ee },
> - { 0x06, 0x834e },
> - { 0x06, 0x00ee },
> - { 0x06, 0x834d },
> - { 0x06, 0x0fee },
> - { 0x06, 0x834c },
> - { 0x06, 0x0fee },
> - { 0x06, 0x834f },
> - { 0x06, 0x00ee },
> - { 0x06, 0x8351 },
> - { 0x06, 0x00ee },
> - { 0x06, 0x834a },
> - { 0x06, 0xffee },
> - { 0x06, 0x834b },
> - { 0x06, 0xffe0 },
> - { 0x06, 0x8330 },
> - { 0x06, 0xe183 },
> - { 0x06, 0x3158 },
> - { 0x06, 0xfee4 },
> - { 0x06, 0xf88a },
> - { 0x06, 0xe5f8 },
> - { 0x06, 0x8be0 },
> - { 0x06, 0x8332 },
> - { 0x06, 0xe183 },
> - { 0x06, 0x3359 },
> - { 0x06, 0x0fe2 },
> - { 0x06, 0x834d },
> - { 0x06, 0x0c24 },
> - { 0x06, 0x5af0 },
> - { 0x06, 0x1e12 },
> - { 0x06, 0xe4f8 },
> - { 0x06, 0x8ce5 },
> - { 0x06, 0xf88d },
> - { 0x06, 0xaf82 },
> - { 0x06, 0x13e0 },
> - { 0x06, 0x834f },
> - { 0x06, 0x10e4 },
> - { 0x06, 0x834f },
> - { 0x06, 0xe083 },
> - { 0x06, 0x4e78 },
> - { 0x06, 0x009f },
> - { 0x06, 0x0ae0 },
> - { 0x06, 0x834f },
> - { 0x06, 0xa010 },
> - { 0x06, 0xa5ee },
> - { 0x06, 0x834e },
> - { 0x06, 0x01e0 },
> - { 0x06, 0x834e },
> - { 0x06, 0x7805 },
> - { 0x06, 0x9e9a },
> - { 0x06, 0xe083 },
> - { 0x06, 0x4e78 },
> - { 0x06, 0x049e },
> - { 0x06, 0x10e0 },
> - { 0x06, 0x834e },
> - { 0x06, 0x7803 },
> - { 0x06, 0x9e0f },
> - { 0x06, 0xe083 },
> - { 0x06, 0x4e78 },
> - { 0x06, 0x019e },
> - { 0x06, 0x05ae },
> - { 0x06, 0x0caf },
> - { 0x06, 0x81f8 },
> - { 0x06, 0xaf81 },
> - { 0x06, 0xa3af },
> - { 0x06, 0x81dc },
> - { 0x06, 0xaf82 },
> - { 0x06, 0x13ee },
> - { 0x06, 0x8348 },
> - { 0x06, 0x00ee },
> - { 0x06, 0x8349 },
> - { 0x06, 0x00e0 },
> - { 0x06, 0x8351 },
> - { 0x06, 0x10e4 },
> - { 0x06, 0x8351 },
> - { 0x06, 0x5801 },
> - { 0x06, 0x9fea },
> - { 0x06, 0xd000 },
> - { 0x06, 0xd180 },
> - { 0x06, 0x1f66 },
> - { 0x06, 0xe2f8 },
> - { 0x06, 0xeae3 },
> - { 0x06, 0xf8eb },
> - { 0x06, 0x5af8 },
> - { 0x06, 0x1e20 },
> - { 0x06, 0xe6f8 },
> - { 0x06, 0xeae5 },
> - { 0x06, 0xf8eb },
> - { 0x06, 0xd302 },
> - { 0x06, 0xb3fe },
> - { 0x06, 0xe2f8 },
> - { 0x06, 0x7cef },
> - { 0x06, 0x325b },
> - { 0x06, 0x80e3 },
> - { 0x06, 0xf87d },
> - { 0x06, 0x9e03 },
> - { 0x06, 0x7dff },
> - { 0x06, 0xff0d },
> - { 0x06, 0x581c },
> - { 0x06, 0x551a },
> - { 0x06, 0x6511 },
> - { 0x06, 0xa190 },
> - { 0x06, 0xd3e2 },
> - { 0x06, 0x8348 },
> - { 0x06, 0xe383 },
> - { 0x06, 0x491b },
> - { 0x06, 0x56ab },
> - { 0x06, 0x08ef },
> - { 0x06, 0x56e6 },
> - { 0x06, 0x8348 },
> - { 0x06, 0xe783 },
> - { 0x06, 0x4910 },
> - { 0x06, 0xd180 },
> - { 0x06, 0x1f66 },
> - { 0x06, 0xa004 },
> - { 0x06, 0xb9e2 },
> - { 0x06, 0x8348 },
> - { 0x06, 0xe383 },
> - { 0x06, 0x49ef },
> - { 0x06, 0x65e2 },
> - { 0x06, 0x834a },
> - { 0x06, 0xe383 },
> - { 0x06, 0x4b1b },
> - { 0x06, 0x56aa },
> - { 0x06, 0x0eef },
> - { 0x06, 0x56e6 },
> - { 0x06, 0x834a },
> - { 0x06, 0xe783 },
> - { 0x06, 0x4be2 },
> - { 0x06, 0x834d },
> - { 0x06, 0xe683 },
> - { 0x06, 0x4ce0 },
> - { 0x06, 0x834d },
> - { 0x06, 0xa000 },
> - { 0x06, 0x0caf },
> - { 0x06, 0x81dc },
> - { 0x06, 0xe083 },
> - { 0x06, 0x4d10 },
> - { 0x06, 0xe483 },
> - { 0x06, 0x4dae },
> - { 0x06, 0x0480 },
> - { 0x06, 0xe483 },
> - { 0x06, 0x4de0 },
> - { 0x06, 0x834e },
> - { 0x06, 0x7803 },
> - { 0x06, 0x9e0b },
> - { 0x06, 0xe083 },
> - { 0x06, 0x4e78 },
> - { 0x06, 0x049e },
> - { 0x06, 0x04ee },
> - { 0x06, 0x834e },
> - { 0x06, 0x02e0 },
> - { 0x06, 0x8332 },
> - { 0x06, 0xe183 },
> - { 0x06, 0x3359 },
> - { 0x06, 0x0fe2 },
> - { 0x06, 0x834d },
> - { 0x06, 0x0c24 },
> - { 0x06, 0x5af0 },
> - { 0x06, 0x1e12 },
> - { 0x06, 0xe4f8 },
> - { 0x06, 0x8ce5 },
> - { 0x06, 0xf88d },
> - { 0x06, 0xe083 },
> - { 0x06, 0x30e1 },
> - { 0x06, 0x8331 },
> - { 0x06, 0x6801 },
> - { 0x06, 0xe4f8 },
> - { 0x06, 0x8ae5 },
> - { 0x06, 0xf88b },
> - { 0x06, 0xae37 },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4e03 },
> - { 0x06, 0xe083 },
> - { 0x06, 0x4ce1 },
> - { 0x06, 0x834d },
> - { 0x06, 0x1b01 },
> - { 0x06, 0x9e04 },
> - { 0x06, 0xaaa1 },
> - { 0x06, 0xaea8 },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4e04 },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4f00 },
> - { 0x06, 0xaeab },
> - { 0x06, 0xe083 },
> - { 0x06, 0x4f78 },
> - { 0x06, 0x039f },
> - { 0x06, 0x14ee },
> - { 0x06, 0x834e },
> - { 0x06, 0x05d2 },
> - { 0x06, 0x40d6 },
> - { 0x06, 0x5554 },
> - { 0x06, 0x0282 },
> - { 0x06, 0x17d2 },
> - { 0x06, 0xa0d6 },
> - { 0x06, 0xba00 },
> - { 0x06, 0x0282 },
> - { 0x06, 0x17fe },
> - { 0x06, 0xfdfc },
> - { 0x06, 0x05f8 },
> - { 0x06, 0xe0f8 },
> - { 0x06, 0x60e1 },
> - { 0x06, 0xf861 },
> - { 0x06, 0x6802 },
> - { 0x06, 0xe4f8 },
> - { 0x06, 0x60e5 },
> - { 0x06, 0xf861 },
> - { 0x06, 0xe0f8 },
> - { 0x06, 0x48e1 },
> - { 0x06, 0xf849 },
> - { 0x06, 0x580f },
> - { 0x06, 0x1e02 },
> - { 0x06, 0xe4f8 },
> - { 0x06, 0x48e5 },
> - { 0x06, 0xf849 },
> - { 0x06, 0xd000 },
> - { 0x06, 0x0282 },
> - { 0x06, 0x5bbf },
> - { 0x06, 0x8350 },
> - { 0x06, 0xef46 },
> - { 0x06, 0xdc19 },
> - { 0x06, 0xddd0 },
> - { 0x06, 0x0102 },
> - { 0x06, 0x825b },
> - { 0x06, 0x0282 },
> - { 0x06, 0x77e0 },
> - { 0x06, 0xf860 },
> - { 0x06, 0xe1f8 },
> - { 0x06, 0x6158 },
> - { 0x06, 0xfde4 },
> - { 0x06, 0xf860 },
> - { 0x06, 0xe5f8 },
> - { 0x06, 0x61fc },
> - { 0x06, 0x04f9 },
> - { 0x06, 0xfafb },
> - { 0x06, 0xc6bf },
> - { 0x06, 0xf840 },
> - { 0x06, 0xbe83 },
> - { 0x06, 0x50a0 },
> - { 0x06, 0x0101 },
> - { 0x06, 0x071b },
> - { 0x06, 0x89cf },
> - { 0x06, 0xd208 },
> - { 0x06, 0xebdb },
> - { 0x06, 0x19b2 },
> - { 0x06, 0xfbff },
> - { 0x06, 0xfefd },
> - { 0x06, 0x04f8 },
> - { 0x06, 0xe0f8 },
> - { 0x06, 0x48e1 },
> - { 0x06, 0xf849 },
> - { 0x06, 0x6808 },
> - { 0x06, 0xe4f8 },
> - { 0x06, 0x48e5 },
> - { 0x06, 0xf849 },
> - { 0x06, 0x58f7 },
> - { 0x06, 0xe4f8 },
> - { 0x06, 0x48e5 },
> - { 0x06, 0xf849 },
> - { 0x06, 0xfc04 },
> - { 0x06, 0x4d20 },
> - { 0x06, 0x0002 },
> - { 0x06, 0x4e22 },
> - { 0x06, 0x0002 },
> - { 0x06, 0x4ddf },
> - { 0x06, 0xff01 },
> - { 0x06, 0x4edd },
> - { 0x06, 0xff01 },
> - { 0x05, 0x83d4 },
> - { 0x06, 0x8000 },
> - { 0x05, 0x83d8 },
> - { 0x06, 0x8051 },
> - { 0x02, 0x6010 },
> - { 0x03, 0xdc00 },
> - { 0x05, 0xfff6 },
> - { 0x06, 0x00fc },
> - { 0x1f, 0x0000 },
> + { 0x06, 0x5561 },
> +
> + /*
> + * Can not link to 1Gbps with bad cable
> + * Decrease SNR threshold form 21.07dB to 19.04dB
> + */
> + { 0x1f, 0x0001 },
> + { 0x17, 0x0cc0 },
>
> { 0x1f, 0x0000 },
> - { 0x0d, 0xf880 },
> - { 0x1f, 0x0000 }
> + { 0x0d, 0xf880 }
> };
> + void __iomem *ioaddr = tp->mmio_addr;
> + const struct firmware *fw;
>
> rtl_phy_write(ioaddr, phy_reg_init_0, ARRAY_SIZE(phy_reg_init_0));
>
> + /*
> + * Rx Error Issue
> + * Fine Tune Switching regulator parameter
> + */
> mdio_write(ioaddr, 0x1f, 0x0002);
> mdio_plus_minus(ioaddr, 0x0b, 0x0010, 0x00ef);
> mdio_plus_minus(ioaddr, 0x0c, 0xa200, 0x5d00);
>
> - rtl_phy_write(ioaddr, phy_reg_init_1, ARRAY_SIZE(phy_reg_init_1));
> -
> if (rtl8168d_efuse_read(ioaddr, 0x01) == 0xb1) {
> static const struct phy_reg phy_reg_init[] = {
> { 0x1f, 0x0002 },
> @@ -2147,20 +1855,35 @@ static void rtl8168d_1_hw_phy_config(void __iomem *ioaddr)
> rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
> }
>
> + /* RSET couple improve */
> mdio_write(ioaddr, 0x1f, 0x0002);
> mdio_patch(ioaddr, 0x0d, 0x0300);
> mdio_patch(ioaddr, 0x0f, 0x0010);
>
> + /* Fine tune PLL performance */
> mdio_write(ioaddr, 0x1f, 0x0002);
> mdio_plus_minus(ioaddr, 0x02, 0x0100, 0x0600);
> mdio_plus_minus(ioaddr, 0x03, 0x0000, 0xe000);
>
> - rtl_phy_write(ioaddr, phy_reg_init_2, ARRAY_SIZE(phy_reg_init_2));
> + mdio_write(ioaddr, 0x1F, 0x0005);
> + mdio_write(ioaddr, 0x05, 0x001B);
> + if (mdio_read(ioaddr, 0x06) == 0xBF00 &&
> + request_firmware(&fw, "rtl_nic/rtl8168d-1.fw", &tp->pci_dev->dev) == 0) {
> + rtl_phy_write_fw(tp, fw);
> + release_firmware(fw);
> + } else {
> + netif_warn(tp, probe, tp->dev, "unable to apply firmware patch\n");
> + }
> +
> + mdio_write(ioaddr, 0x1f, 0x0000);
> }
>
> -static void rtl8168d_2_hw_phy_config(void __iomem *ioaddr)
> +MODULE_FIRMWARE("rtl_nic/rtl8168d-1.fw");
> +
> +static void rtl8168d_2_hw_phy_config(struct rtl8169_private *tp)
> {
> static const struct phy_reg phy_reg_init_0[] = {
> + /* Channel Estimation */
> { 0x1f, 0x0001 },
> { 0x06, 0x4064 },
> { 0x07, 0x2863 },
> @@ -2179,324 +1902,28 @@ static void rtl8168d_2_hw_phy_config(void __iomem *ioaddr)
> { 0x1a, 0x05ad },
> { 0x14, 0x94c0 },
>
> + /*
> + * Tx Error Issue
> + * enhance line driver power
> + */
> { 0x1f, 0x0002 },
> { 0x06, 0x5561 },
> { 0x1f, 0x0005 },
> { 0x05, 0x8332 },
> - { 0x06, 0x5561 }
> - };
> - static const struct phy_reg phy_reg_init_1[] = {
> - { 0x1f, 0x0005 },
> - { 0x05, 0xffc2 },
> - { 0x1f, 0x0005 },
> - { 0x05, 0x8000 },
> - { 0x06, 0xf8f9 },
> - { 0x06, 0xfaee },
> - { 0x06, 0xf8ea },
> - { 0x06, 0x00ee },
> - { 0x06, 0xf8eb },
> - { 0x06, 0x00e2 },
> - { 0x06, 0xf87c },
> - { 0x06, 0xe3f8 },
> - { 0x06, 0x7da5 },
> - { 0x06, 0x1111 },
> - { 0x06, 0x12d2 },
> - { 0x06, 0x40d6 },
> - { 0x06, 0x4444 },
> - { 0x06, 0x0281 },
> - { 0x06, 0xc6d2 },
> - { 0x06, 0xa0d6 },
> - { 0x06, 0xaaaa },
> - { 0x06, 0x0281 },
> - { 0x06, 0xc6ae },
> - { 0x06, 0x0fa5 },
> - { 0x06, 0x4444 },
> - { 0x06, 0x02ae },
> - { 0x06, 0x4da5 },
> - { 0x06, 0xaaaa },
> - { 0x06, 0x02ae },
> - { 0x06, 0x47af },
> - { 0x06, 0x81c2 },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4e00 },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4d0f },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4c0f },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4f00 },
> - { 0x06, 0xee83 },
> - { 0x06, 0x5100 },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4aff },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4bff },
> - { 0x06, 0xe083 },
> - { 0x06, 0x30e1 },
> - { 0x06, 0x8331 },
> - { 0x06, 0x58fe },
> - { 0x06, 0xe4f8 },
> - { 0x06, 0x8ae5 },
> - { 0x06, 0xf88b },
> - { 0x06, 0xe083 },
> - { 0x06, 0x32e1 },
> - { 0x06, 0x8333 },
> - { 0x06, 0x590f },
> - { 0x06, 0xe283 },
> - { 0x06, 0x4d0c },
> - { 0x06, 0x245a },
> - { 0x06, 0xf01e },
> - { 0x06, 0x12e4 },
> - { 0x06, 0xf88c },
> - { 0x06, 0xe5f8 },
> - { 0x06, 0x8daf },
> - { 0x06, 0x81c2 },
> - { 0x06, 0xe083 },
> - { 0x06, 0x4f10 },
> - { 0x06, 0xe483 },
> - { 0x06, 0x4fe0 },
> - { 0x06, 0x834e },
> - { 0x06, 0x7800 },
> - { 0x06, 0x9f0a },
> - { 0x06, 0xe083 },
> - { 0x06, 0x4fa0 },
> - { 0x06, 0x10a5 },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4e01 },
> - { 0x06, 0xe083 },
> - { 0x06, 0x4e78 },
> - { 0x06, 0x059e },
> - { 0x06, 0x9ae0 },
> - { 0x06, 0x834e },
> - { 0x06, 0x7804 },
> - { 0x06, 0x9e10 },
> - { 0x06, 0xe083 },
> - { 0x06, 0x4e78 },
> - { 0x06, 0x039e },
> - { 0x06, 0x0fe0 },
> - { 0x06, 0x834e },
> - { 0x06, 0x7801 },
> - { 0x06, 0x9e05 },
> - { 0x06, 0xae0c },
> - { 0x06, 0xaf81 },
> - { 0x06, 0xa7af },
> - { 0x06, 0x8152 },
> - { 0x06, 0xaf81 },
> - { 0x06, 0x8baf },
> - { 0x06, 0x81c2 },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4800 },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4900 },
> - { 0x06, 0xe083 },
> - { 0x06, 0x5110 },
> - { 0x06, 0xe483 },
> - { 0x06, 0x5158 },
> - { 0x06, 0x019f },
> - { 0x06, 0xead0 },
> - { 0x06, 0x00d1 },
> - { 0x06, 0x801f },
> - { 0x06, 0x66e2 },
> - { 0x06, 0xf8ea },
> - { 0x06, 0xe3f8 },
> - { 0x06, 0xeb5a },
> - { 0x06, 0xf81e },
> - { 0x06, 0x20e6 },
> - { 0x06, 0xf8ea },
> - { 0x06, 0xe5f8 },
> - { 0x06, 0xebd3 },
> - { 0x06, 0x02b3 },
> - { 0x06, 0xfee2 },
> - { 0x06, 0xf87c },
> - { 0x06, 0xef32 },
> - { 0x06, 0x5b80 },
> - { 0x06, 0xe3f8 },
> - { 0x06, 0x7d9e },
> - { 0x06, 0x037d },
> - { 0x06, 0xffff },
> - { 0x06, 0x0d58 },
> - { 0x06, 0x1c55 },
> - { 0x06, 0x1a65 },
> - { 0x06, 0x11a1 },
> - { 0x06, 0x90d3 },
> - { 0x06, 0xe283 },
> - { 0x06, 0x48e3 },
> - { 0x06, 0x8349 },
> - { 0x06, 0x1b56 },
> - { 0x06, 0xab08 },
> - { 0x06, 0xef56 },
> - { 0x06, 0xe683 },
> - { 0x06, 0x48e7 },
> - { 0x06, 0x8349 },
> - { 0x06, 0x10d1 },
> - { 0x06, 0x801f },
> - { 0x06, 0x66a0 },
> - { 0x06, 0x04b9 },
> - { 0x06, 0xe283 },
> - { 0x06, 0x48e3 },
> - { 0x06, 0x8349 },
> - { 0x06, 0xef65 },
> - { 0x06, 0xe283 },
> - { 0x06, 0x4ae3 },
> - { 0x06, 0x834b },
> - { 0x06, 0x1b56 },
> - { 0x06, 0xaa0e },
> - { 0x06, 0xef56 },
> - { 0x06, 0xe683 },
> - { 0x06, 0x4ae7 },
> - { 0x06, 0x834b },
> - { 0x06, 0xe283 },
> - { 0x06, 0x4de6 },
> - { 0x06, 0x834c },
> - { 0x06, 0xe083 },
> - { 0x06, 0x4da0 },
> - { 0x06, 0x000c },
> - { 0x06, 0xaf81 },
> - { 0x06, 0x8be0 },
> - { 0x06, 0x834d },
> - { 0x06, 0x10e4 },
> - { 0x06, 0x834d },
> - { 0x06, 0xae04 },
> - { 0x06, 0x80e4 },
> - { 0x06, 0x834d },
> - { 0x06, 0xe083 },
> - { 0x06, 0x4e78 },
> - { 0x06, 0x039e },
> - { 0x06, 0x0be0 },
> - { 0x06, 0x834e },
> - { 0x06, 0x7804 },
> - { 0x06, 0x9e04 },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4e02 },
> - { 0x06, 0xe083 },
> - { 0x06, 0x32e1 },
> - { 0x06, 0x8333 },
> - { 0x06, 0x590f },
> - { 0x06, 0xe283 },
> - { 0x06, 0x4d0c },
> - { 0x06, 0x245a },
> - { 0x06, 0xf01e },
> - { 0x06, 0x12e4 },
> - { 0x06, 0xf88c },
> - { 0x06, 0xe5f8 },
> - { 0x06, 0x8de0 },
> - { 0x06, 0x8330 },
> - { 0x06, 0xe183 },
> - { 0x06, 0x3168 },
> - { 0x06, 0x01e4 },
> - { 0x06, 0xf88a },
> - { 0x06, 0xe5f8 },
> - { 0x06, 0x8bae },
> - { 0x06, 0x37ee },
> - { 0x06, 0x834e },
> - { 0x06, 0x03e0 },
> - { 0x06, 0x834c },
> - { 0x06, 0xe183 },
> - { 0x06, 0x4d1b },
> - { 0x06, 0x019e },
> - { 0x06, 0x04aa },
> - { 0x06, 0xa1ae },
> - { 0x06, 0xa8ee },
> - { 0x06, 0x834e },
> - { 0x06, 0x04ee },
> - { 0x06, 0x834f },
> - { 0x06, 0x00ae },
> - { 0x06, 0xabe0 },
> - { 0x06, 0x834f },
> - { 0x06, 0x7803 },
> - { 0x06, 0x9f14 },
> - { 0x06, 0xee83 },
> - { 0x06, 0x4e05 },
> - { 0x06, 0xd240 },
> - { 0x06, 0xd655 },
> - { 0x06, 0x5402 },
> - { 0x06, 0x81c6 },
> - { 0x06, 0xd2a0 },
> - { 0x06, 0xd6ba },
> - { 0x06, 0x0002 },
> - { 0x06, 0x81c6 },
> - { 0x06, 0xfefd },
> - { 0x06, 0xfc05 },
> - { 0x06, 0xf8e0 },
> - { 0x06, 0xf860 },
> - { 0x06, 0xe1f8 },
> - { 0x06, 0x6168 },
> - { 0x06, 0x02e4 },
> - { 0x06, 0xf860 },
> - { 0x06, 0xe5f8 },
> - { 0x06, 0x61e0 },
> - { 0x06, 0xf848 },
> - { 0x06, 0xe1f8 },
> - { 0x06, 0x4958 },
> - { 0x06, 0x0f1e },
> - { 0x06, 0x02e4 },
> - { 0x06, 0xf848 },
> - { 0x06, 0xe5f8 },
> - { 0x06, 0x49d0 },
> - { 0x06, 0x0002 },
> - { 0x06, 0x820a },
> - { 0x06, 0xbf83 },
> - { 0x06, 0x50ef },
> - { 0x06, 0x46dc },
> - { 0x06, 0x19dd },
> - { 0x06, 0xd001 },
> - { 0x06, 0x0282 },
> - { 0x06, 0x0a02 },
> - { 0x06, 0x8226 },
> - { 0x06, 0xe0f8 },
> - { 0x06, 0x60e1 },
> - { 0x06, 0xf861 },
> - { 0x06, 0x58fd },
> - { 0x06, 0xe4f8 },
> - { 0x06, 0x60e5 },
> - { 0x06, 0xf861 },
> - { 0x06, 0xfc04 },
> - { 0x06, 0xf9fa },
> - { 0x06, 0xfbc6 },
> - { 0x06, 0xbff8 },
> - { 0x06, 0x40be },
> - { 0x06, 0x8350 },
> - { 0x06, 0xa001 },
> - { 0x06, 0x0107 },
> - { 0x06, 0x1b89 },
> - { 0x06, 0xcfd2 },
> - { 0x06, 0x08eb },
> - { 0x06, 0xdb19 },
> - { 0x06, 0xb2fb },
> - { 0x06, 0xfffe },
> - { 0x06, 0xfd04 },
> - { 0x06, 0xf8e0 },
> - { 0x06, 0xf848 },
> - { 0x06, 0xe1f8 },
> - { 0x06, 0x4968 },
> - { 0x06, 0x08e4 },
> - { 0x06, 0xf848 },
> - { 0x06, 0xe5f8 },
> - { 0x06, 0x4958 },
> - { 0x06, 0xf7e4 },
> - { 0x06, 0xf848 },
> - { 0x06, 0xe5f8 },
> - { 0x06, 0x49fc },
> - { 0x06, 0x044d },
> - { 0x06, 0x2000 },
> - { 0x06, 0x024e },
> - { 0x06, 0x2200 },
> - { 0x06, 0x024d },
> - { 0x06, 0xdfff },
> - { 0x06, 0x014e },
> - { 0x06, 0xddff },
> - { 0x06, 0x0100 },
> - { 0x05, 0x83d8 },
> - { 0x06, 0x8000 },
> - { 0x03, 0xdc00 },
> - { 0x05, 0xfff6 },
> - { 0x06, 0x00fc },
> - { 0x1f, 0x0000 },
> + { 0x06, 0x5561 },
> +
> + /*
> + * Can not link to 1Gbps with bad cable
> + * Decrease SNR threshold form 21.07dB to 19.04dB
> + */
> + { 0x1f, 0x0001 },
> + { 0x17, 0x0cc0 },
>
> { 0x1f, 0x0000 },
> - { 0x0d, 0xf880 },
> - { 0x1f, 0x0000 }
> + { 0x0d, 0xf880 }
> };
> + void __iomem *ioaddr = tp->mmio_addr;
> + const struct firmware *fw;
>
> rtl_phy_write(ioaddr, phy_reg_init_0, ARRAY_SIZE(phy_reg_init_0));
>
> @@ -2540,19 +1967,30 @@ static void rtl8168d_2_hw_phy_config(void __iomem *ioaddr)
> rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
> }
>
> + /* Fine tune PLL performance */
> mdio_write(ioaddr, 0x1f, 0x0002);
> mdio_plus_minus(ioaddr, 0x02, 0x0100, 0x0600);
> mdio_plus_minus(ioaddr, 0x03, 0x0000, 0xe000);
>
> - mdio_write(ioaddr, 0x1f, 0x0001);
> - mdio_write(ioaddr, 0x17, 0x0cc0);
> -
> + /* Switching regulator Slew rate */
> mdio_write(ioaddr, 0x1f, 0x0002);
> mdio_patch(ioaddr, 0x0f, 0x0017);
>
> - rtl_phy_write(ioaddr, phy_reg_init_1, ARRAY_SIZE(phy_reg_init_1));
> + mdio_write(ioaddr, 0x1F, 0x0005);
> + mdio_write(ioaddr, 0x05, 0x001B);
> + if (mdio_read(ioaddr, 0x06) == 0xB300 &&
> + request_firmware(&fw, "rtl_nic/rtl8168d-2.fw", &tp->pci_dev->dev) == 0) {
> + rtl_phy_write_fw(tp, fw);
> + release_firmware(fw);
> + } else {
> + netif_warn(tp, probe, tp->dev, "unable to apply firmware patch\n");
> + }
> +
> + mdio_write(ioaddr, 0x1f, 0x0000);
> }
>
> +MODULE_FIRMWARE("rtl_nic/rtl8168d-2.fw");
> +
> static void rtl8168d_3_hw_phy_config(void __iomem *ioaddr)
> {
> static const struct phy_reg phy_reg_init[] = {
> @@ -2688,10 +2126,10 @@ static void rtl_hw_phy_config(struct net_device *dev)
> rtl8168cp_2_hw_phy_config(ioaddr);
> break;
> case RTL_GIGA_MAC_VER_25:
> - rtl8168d_1_hw_phy_config(ioaddr);
> + rtl8168d_1_hw_phy_config(tp);
> break;
> case RTL_GIGA_MAC_VER_26:
> - rtl8168d_2_hw_phy_config(ioaddr);
> + rtl8168d_2_hw_phy_config(tp);
> break;
> case RTL_GIGA_MAC_VER_27:
> rtl8168d_3_hw_phy_config(ioaddr);
^ permalink raw reply
* Behaviour of ETHTOOL_GLINK for an interface that's down
From: Ben Hutchings @ 2010-12-06 21:59 UTC (permalink / raw)
To: netdev; +Cc: sf-linux-drivers
ETHTOOL_GLINK is yet another ethtool operation that has unclear
semantics that results in differing behaviour when the interface is
down.
The two reasonable semantics I can see are:
1. Report whether the host has a working link, i.e. netif_running() &&
netif_carrier_on().
2. Report whether the port has a working link. For hardware interfaces,
poll the PHY or firmware unless the port is powered-off. For software
interfaces, report whether the interface could plausibly pass traffic.
The default implementation (ethtool_op_get_link) uses
netif_carrier_ok(), implementing the rather unreasonable semantics:
3. Report whether the port had a working link when the interface was
last up.
At least one driver works around this by setting carrier off in its
ndo_stop() operation.
Here's a small sample of driver behaviours:
bnx2: (1)
bnx2x: (1) (I think)
cxgb3: (1) (but also (2) because PHY is powered off)
e1000e: (2)
gianfar: (3)
igb: (2)
ixgbe: (1)
niu: (3)
sfc: (3) (approximately)
sky2: (3)
tg3: (3) (but also (1) due to setting carrier off in tg3_close())
DaveM said that Network Manager may require (2), although I don't think
this is correct. At least the current version brings all managed
interfaces up whether or not they have link-up already.
My personal preference is for (1).
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net/r8169: Remove the firmware of RTL8111D
From: Francois Romieu @ 2010-12-06 22:04 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Hayes Wang, netdev, linux-kernel
In-Reply-To: <1291610284.8025.154.camel@localhost>
Ben Hutchings <benh@debian.org> :
[...]
> I have reports that the RTL8111D/8168D hardware can work without this
> firmware, possibly with limited functionality or compatibility. (I
> assume it is a patch for the original firmware loaded from ROM or
> flash.) So I feel obliged to give users the choice to use the driver
> without installing non-free firmware. If you want to make the warning
> on failure of request_firmware() more explicit then that's OK with me.
I'll make it more explicit regarding what it loads, yes.
> If you make the failure fatal I will probably revert that in Debian.
I have no technical argument against yours to make the failure fatal
yet: even Realtek's wording is rather soft. I will reconsider it if
things turn ugly.
Btw, it is not too hard to build a firmware-of-freedom binary : all
zero should be fine here.
--
Ueimor
^ permalink raw reply
* Re: Misuse of LRO, how widespread
From: Stephen Hemminger @ 2010-12-06 22:27 UTC (permalink / raw)
To: Dimitris Michailidis
Cc: David Miller, Olof Johansson, Ben Hutchings, Divy Le Ray, netdev
In-Reply-To: <4CFD527E.7000706@chelsio.com>
On Mon, 06 Dec 2010 13:15:42 -0800
Dimitris Michailidis <dm@chelsio.com> wrote:
> Stephen Hemminger wrote:
> > I inspected all drivers in net-next to see which drivers are using
> > LRO and which ones are broken. Most concerning is that Chelsio
> > and Solarflare drivers ignore ETH_FLAG_LRO.
> >
> > The ones that are using LRO but allow disabling it:
> > qlcnic, netxen, mv643, s2io, myi10ge, bnx2x, ixgbe, vmxnet3
> >
> > One driver seems confused about LRO vs GRO:
> > mlx4 - comments about LRO and depends on LRO but driver is using GRO
> >
> > Drivers with not using ethtool interface to disable LRO:
> > pasemi_mac, sfc, ehea, cxgb3, cxgb4
>
> cxgb4 uses GRO, not LRO.
Ok. but cxgb3 still uses LRO (or it least calls it lro).
--
^ permalink raw reply
* Re: Misuse of LRO, how widespread
From: Stephen Hemminger @ 2010-12-06 22:33 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, Olof Johansson, Divy Le Ray, netdev
In-Reply-To: <1291667408.3443.10.camel@bwh-desktop>
How about this?
Subject: sfc: convert references to LRO to GRO
This driver now uses Generic Receive Offload, not the older LRO.
Change references to LRO in names and comments.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/sfc/rx.c 2010-12-06 14:28:25.320929804 -0800
+++ b/drivers/net/sfc/rx.c 2010-12-06 14:29:54.424930087 -0800
@@ -37,7 +37,7 @@
* This driver supports two methods for allocating and using RX buffers:
* each RX buffer may be backed by an skb or by an order-n page.
*
- * When LRO is in use then the second method has a lower overhead,
+ * When GRO is in use then the second method has a lower overhead,
* since we don't have to allocate then free skbs on reassembled frames.
*
* Values:
@@ -50,25 +50,25 @@
*
* - Since pushing and popping descriptors are separated by the rx_queue
* size, so the watermarks should be ~rxd_size.
- * - The performance win by using page-based allocation for LRO is less
- * than the performance hit of using page-based allocation of non-LRO,
+ * - The performance win by using page-based allocation for GRO is less
+ * than the performance hit of using page-based allocation of non-GRO,
* so the watermarks should reflect this.
*
* Per channel we maintain a single variable, updated by each channel:
*
- * rx_alloc_level += (lro_performed ? RX_ALLOC_FACTOR_LRO :
+ * rx_alloc_level += (gro_performed ? RX_ALLOC_FACTOR_GRO :
* RX_ALLOC_FACTOR_SKB)
* Per NAPI poll interval, we constrain rx_alloc_level to 0..MAX (which
* limits the hysteresis), and update the allocation strategy:
*
- * rx_alloc_method = (rx_alloc_level > RX_ALLOC_LEVEL_LRO ?
+ * rx_alloc_method = (rx_alloc_level > RX_ALLOC_LEVEL_GRO ?
* RX_ALLOC_METHOD_PAGE : RX_ALLOC_METHOD_SKB)
*/
static int rx_alloc_method = RX_ALLOC_METHOD_AUTO;
-#define RX_ALLOC_LEVEL_LRO 0x2000
+#define RX_ALLOC_LEVEL_GRO 0x2000
#define RX_ALLOC_LEVEL_MAX 0x3000
-#define RX_ALLOC_FACTOR_LRO 1
+#define RX_ALLOC_FACTOR_GRO 1
#define RX_ALLOC_FACTOR_SKB (-2)
/* This is the percentage fill level below which new RX descriptors
@@ -441,19 +441,19 @@ static void efx_rx_packet__check_len(str
efx_rx_queue_channel(rx_queue)->n_rx_overlength++;
}
-/* Pass a received packet up through the generic LRO stack
+/* Pass a received packet up through the generic GRO stack
*
* Handles driverlink veto, and passes the fragment up via
- * the appropriate LRO method
+ * the appropriate GRO method
*/
-static void efx_rx_packet_lro(struct efx_channel *channel,
+static void efx_rx_packet_gro(struct efx_channel *channel,
struct efx_rx_buffer *rx_buf,
bool checksummed)
{
struct napi_struct *napi = &channel->napi_str;
gro_result_t gro_result;
- /* Pass the skb/page into the LRO engine */
+ /* Pass the skb/page into the GRO engine */
if (rx_buf->page) {
struct efx_nic *efx = channel->efx;
struct page *page = rx_buf->page;
@@ -499,7 +499,7 @@ static void efx_rx_packet_lro(struct efx
if (gro_result == GRO_NORMAL) {
channel->rx_alloc_level += RX_ALLOC_FACTOR_SKB;
} else if (gro_result != GRO_DROP) {
- channel->rx_alloc_level += RX_ALLOC_FACTOR_LRO;
+ channel->rx_alloc_level += RX_ALLOC_FACTOR_GRO;
channel->irq_mod_score += 2;
}
}
@@ -605,7 +605,7 @@ void __efx_rx_packet(struct efx_channel
}
if (likely(checksummed || rx_buf->page)) {
- efx_rx_packet_lro(channel, rx_buf, checksummed);
+ efx_rx_packet_gro(channel, rx_buf, checksummed);
return;
}
@@ -628,7 +628,7 @@ void efx_rx_strategy(struct efx_channel
{
enum efx_rx_alloc_method method = rx_alloc_method;
- /* Only makes sense to use page based allocation if LRO is enabled */
+ /* Only makes sense to use page based allocation if GRO is enabled */
if (!(channel->efx->net_dev->features & NETIF_F_GRO)) {
method = RX_ALLOC_METHOD_SKB;
} else if (method == RX_ALLOC_METHOD_AUTO) {
@@ -639,7 +639,7 @@ void efx_rx_strategy(struct efx_channel
channel->rx_alloc_level = RX_ALLOC_LEVEL_MAX;
/* Decide on the allocation method */
- method = ((channel->rx_alloc_level > RX_ALLOC_LEVEL_LRO) ?
+ method = ((channel->rx_alloc_level > RX_ALLOC_LEVEL_GRO) ?
RX_ALLOC_METHOD_PAGE : RX_ALLOC_METHOD_SKB);
}
^ permalink raw reply
* Re: Misuse of LRO, how widespread
From: Ben Hutchings @ 2010-12-06 22:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Olof Johansson, Divy Le Ray, netdev
In-Reply-To: <20101206143301.6b6dd17d@nehalam>
On Mon, 2010-12-06 at 14:33 -0800, Stephen Hemminger wrote:
> How about this?
>
> Subject: sfc: convert references to LRO to GRO
>
> This driver now uses Generic Receive Offload, not the older LRO.
> Change references to LRO in names and comments.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: NET_NS: unregister_netdevice: waiting for lo to become free (adding ipv6 address to interface)
From: Michael Leun @ 2010-12-06 22:47 UTC (permalink / raw)
To: Eric W. Biederman
Cc: jean-philippe.menil, netdev, David Lamparter, Greg KH, davem,
linux-kernel, Alexey Dobriyan, Patrick McHardy
In-Reply-To: <m11v5uk35z.fsf@fess.ebiederm.org>
On Mon, 06 Dec 2010 13:22:00 -0800
ebiederm@xmission.com (Eric W. Biederman) wrote:
> Menil Jean-Philippe <jean-philippe.menil@univ-nantes.fr> writes:
>
> > Le 24/10/2010 15:15, Michael Leun a écrit :
> >> On Fri, 22 Oct 2010 19:05:32 +0200
> >> Michael Leun<lkml20100708@newton.leun.net> wrote:
> >>
> >>> On Fri, 22 Oct 2010 14:48:58 +0200
> >>> David Lamparter<equinox@diac24.net> wrote:
> >>>
> >>>> On Thu, Oct 21, 2010 at 05:15:32PM +0200, Michael Leun wrote:
> >>>>> unfortunately the bug described below originally reported in
> >>>>> 2.6.35-rcX is still there in 2.6.36.
[...]
> > curiously, i'm facing a similar problem in 2.6.36.1
> >
> > in my container, when i configure ipv6 adress on the interfaces,
> > everything seems good on the first boot of the host. If i shutdown
> > my container (lxc), then boot it, i observe the following logs:
> > Dec 6 17:04:12 suntory.u06.univ-nantes.prive kernel: [ 368.192019]
> > unregister_netdevice: waiting for lo to become free. Usage count = 4
> > Dec 6 17:04:22 suntory.u06.univ-nantes.prive kernel: [ 378.432018]
> > unregister_netdevice: waiting for lo to become free. Usage count = 4
> > Dec 6 17:04:32 suntory.u06.univ-nantes.prive kernel: [ 388.672015]
> > unregister_netdevice: waiting for lo to become free. Usage count = 4
> > Dec 6 17:04:42 suntory.u06.univ-nantes.prive kernel: [ 398.912016]
> > unregister_netdevice: waiting for lo to become free. Usage count = 4
> > Dec 6 17:04:53 suntory.u06.univ-nantes.prive kernel: [ 409.152016]
> > unregister_netdevice: waiting for lo to become free. Usage count = 4
> > Dec 6 17:05:03 suntory.u06.univ-nantes.prive kernel: [ 419.392018]
> > unregister_netdevice: waiting for lo to become free. Usage count = 4
> > Dec 6 17:05:13 suntory.u06.univ-nantes.prive kernel: [ 429.632018]
> > unregister_netdevice: waiting for lo to become free. Usage count = 4
> > Dec 6 17:05:23 suntory.u06.univ-nantes.prive kernel: [ 439.876016]
> > unregister_netdevice: waiting for lo to become free. Usage count = 4
> > Dec 6 17:05:34 suntory.u06.univ-nantes.prive kernel: [ 450.116015]
> > unregister_netdevice: waiting for lo to become free. Usage count = 4
> > Dec 6 17:05:44 suntory.u06.univ-nantes.prive kernel: [ 460.356019]
> > unregister_netdevice: waiting for lo to become free. Usage count = 4
> > Dec 6 17:05:54 suntory.u06.univ-nantes.prive kernel: [ 470.596020]
> > unregister_netdevice: waiting for lo to become free. Usage count = 4
> > Dec 6 17:06:04 suntory.u06.univ-nantes.prive kernel: [ 480.836019]
> > unregister_netdevice: waiting for lo to become free. Usage count = 4
> > Dec 6 17:06:05 suntory.u06.univ-nantes.prive kernel:
> > [ 481.468021] INFO: task lxc-start:3805 blocked for more than 120
> > seconds.
> >
> > Then i must reboot the host.
> > The same on kernel 2.6.34, but everything is good on a 2.6.32
> >
> > Some relvant informations about the kernel:
> > root@suntory:~# cat /boot/config-2.6.36.1-dsiun-1d | grep -i sysfs
> > # CONFIG_SYSFS_DEPRECATED_V2 is not set
> > CONFIG_ACPI_SYSFS_POWER=y
> > # CONFIG_WIRELESS_EXT_SYSFS is not set
> > CONFIG_ISCSI_BOOT_SYSFS=m
> > CONFIG_RTC_INTF_SYSFS=y
> > CONFIG_SYSFS=y
> > root@suntory:~# cat /boot/config-2.6.36.1-dsiun-1d | grep -i net_ns
> > CONFIG_NET_NS=y
> >
> > Is there anything in my configuration, i must check in order to get
> > ipv6 working fully in the container?
>
> 2.6.37-rc4 is working here. There were problems earlier in the
> earlier rcs. Can you try that?
>
> There have been a couple of different reference counting bugs between
> 2.6.34 and the present, and I haven't tracked them, just noticed they
> exist.
Can reproduce the following still on 2.6.36.1, but NOT on 2.6.37-rc4 -
so indeed seems to be fixed!
Putting an ipv6 address on a device seems to be the trigger:
OrigNS > # ip link add type veth
OrigNS > # ip link set dev veth0 up
OrigNS > # unshare -n /bin/bash
NewNS > # echo $$
<SomePID>
OrigNS > # ip link set dev veth1 netns <SomePID> # this, of course is
on a different terminal NewNS > # ip link set dev veth1 up
NewNS > # ip -6 addr add dev veth1 fd50:dead:beef::1/64
NewNS > # exit
Yields
kernel: unregister_netdevice: waiting for veth1 to become free. Usage
count = 3
--
MfG,
Michael Leun
^ permalink raw reply
* Re: Misuse of LRO, how widespread
From: Dimitris Michailidis @ 2010-12-06 23:05 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, Olof Johansson, Ben Hutchings, Divy Le Ray, netdev
In-Reply-To: <20101206142715.0d296b25@nehalam>
Stephen Hemminger wrote:
> On Mon, 06 Dec 2010 13:15:42 -0800
> Dimitris Michailidis <dm@chelsio.com> wrote:
>
>> Stephen Hemminger wrote:
>>> I inspected all drivers in net-next to see which drivers are using
>>> LRO and which ones are broken. Most concerning is that Chelsio
>>> and Solarflare drivers ignore ETH_FLAG_LRO.
>>>
>>> The ones that are using LRO but allow disabling it:
>>> qlcnic, netxen, mv643, s2io, myi10ge, bnx2x, ixgbe, vmxnet3
>>>
>>> One driver seems confused about LRO vs GRO:
>>> mlx4 - comments about LRO and depends on LRO but driver is using GRO
>>>
>>> Drivers with not using ethtool interface to disable LRO:
>>> pasemi_mac, sfc, ehea, cxgb3, cxgb4
>> cxgb4 uses GRO, not LRO.
>
> Ok. but cxgb3 still uses LRO (or it least calls it lro).
>
cxgb3 was the driver Herbert implemented GRO on I think, and he converted it
to GRO. It possibly has leftover LRO references as it was using LRO before.
^ permalink raw reply
* Re: Misuse of LRO, how widespread
From: Ben Hutchings @ 2010-12-06 23:22 UTC (permalink / raw)
To: Dimitris Michailidis
Cc: Stephen Hemminger, David Miller, Olof Johansson, Divy Le Ray,
netdev
In-Reply-To: <4CFD6C2B.9020201@chelsio.com>
On Mon, 2010-12-06 at 15:05 -0800, Dimitris Michailidis wrote:
> Stephen Hemminger wrote:
> > On Mon, 06 Dec 2010 13:15:42 -0800
> > Dimitris Michailidis <dm@chelsio.com> wrote:
> >
> >> Stephen Hemminger wrote:
> >>> I inspected all drivers in net-next to see which drivers are using
> >>> LRO and which ones are broken. Most concerning is that Chelsio
> >>> and Solarflare drivers ignore ETH_FLAG_LRO.
> >>>
> >>> The ones that are using LRO but allow disabling it:
> >>> qlcnic, netxen, mv643, s2io, myi10ge, bnx2x, ixgbe, vmxnet3
> >>>
> >>> One driver seems confused about LRO vs GRO:
> >>> mlx4 - comments about LRO and depends on LRO but driver is using GRO
> >>>
> >>> Drivers with not using ethtool interface to disable LRO:
> >>> pasemi_mac, sfc, ehea, cxgb3, cxgb4
> >> cxgb4 uses GRO, not LRO.
> >
> > Ok. but cxgb3 still uses LRO (or it least calls it lro).
> >
>
> cxgb3 was the driver Herbert implemented GRO on I think, and he converted it
> to GRO. It possibly has leftover LRO references as it was using LRO before.
There's a fair amount of code setting LRO flags in various structures,
so either the driver still enables LRO in hardware/firmware or this is
dead code.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Misuse of LRO, how widespread
From: Dimitris Michailidis @ 2010-12-06 23:36 UTC (permalink / raw)
To: Ben Hutchings
Cc: Stephen Hemminger, David Miller, Olof Johansson, Divy Le Ray,
netdev
In-Reply-To: <1291677755.5405.29.camel@bwh-desktop>
Ben Hutchings wrote:
> On Mon, 2010-12-06 at 15:05 -0800, Dimitris Michailidis wrote:
>> Stephen Hemminger wrote:
>>> On Mon, 06 Dec 2010 13:15:42 -0800
>>> Dimitris Michailidis <dm@chelsio.com> wrote:
>>>
>>>> Stephen Hemminger wrote:
>>>>> I inspected all drivers in net-next to see which drivers are using
>>>>> LRO and which ones are broken. Most concerning is that Chelsio
>>>>> and Solarflare drivers ignore ETH_FLAG_LRO.
>>>>>
>>>>> The ones that are using LRO but allow disabling it:
>>>>> qlcnic, netxen, mv643, s2io, myi10ge, bnx2x, ixgbe, vmxnet3
>>>>>
>>>>> One driver seems confused about LRO vs GRO:
>>>>> mlx4 - comments about LRO and depends on LRO but driver is using GRO
>>>>>
>>>>> Drivers with not using ethtool interface to disable LRO:
>>>>> pasemi_mac, sfc, ehea, cxgb3, cxgb4
>>>> cxgb4 uses GRO, not LRO.
>>> Ok. but cxgb3 still uses LRO (or it least calls it lro).
>>>
>> cxgb3 was the driver Herbert implemented GRO on I think, and he converted it
>> to GRO. It possibly has leftover LRO references as it was using LRO before.
>
> There's a fair amount of code setting LRO flags in various structures,
> so either the driver still enables LRO in hardware/firmware or this is
> dead code.
From a quick look it appears to have a per queue lro flag. HW/FW are not
aware of LRO, whatever flags that driver has are for SW. I'd say it's
obsolete but probably not dead code.
>
> Ben.
>
^ permalink raw reply
* Re: [PATCH net-next-2.6 8/17 v2] can: EG20T PCH: Change Copyright and module description
From: Tomoya MORINAGA @ 2010-12-07 0:46 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w, Samuel Ortiz,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, Wolfgang Grandegger,
joel.clark-ral2JQCrhuEAvxtiuMwx3w, David S. Miller,
Christian Pellegrin, qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CECEE1E.9030201@pengutronix.de>
On Wednesday, November 24, 2010 7:51 PM, Marc Kleine-Budde wrote:
> Did your mailer spawn some extra spaces here? The header of your mail
> tells me:
> "User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.1.15)
> Gecko/20101027 Thunderbird/3.0.10"
> I strongly suggest to use git send-email.
At last, I can use "git send-email".
However, I have faced issue.
In case single destination address is OK, but in case multiple address is
set,
I can see the following error.
Relay access denied
I show my failure command.
git send-email --smtp-server xxx.com --smtp-server-port yyy --smtp-ssl -to
aaa.com -to bbb.com -to ccc.com
-cc ccc.com -cc ddd.com -cc eee.com -bcc fff.com -bcc ggg.com *.patch
Do you have any information about the issue ?
Thanks
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_
Tomoya Morinaga
OKI SEMICONDUCTOR CO., LTD.
^ permalink raw reply
* linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2010-12-07 1:00 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Joe Perches, Breno Leitao
[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]
Hi all,
After merging the net tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/net/ehea/ehea_main.c: In function 'ehea_refill_rq1':
drivers/net/ehea/ehea_main.c:405: error: implicit declaration of function 'ehea_info'
drivers/net/ehea/ehea_main.c: In function 'ehea_init_fill_rq1':
drivers/net/ehea/ehea_main.c:429: error: implicit declaration of function 'ehea_error'
drivers/net/ehea/ehea_main.c: In function 'ehea_neq_tasklet':
drivers/net/ehea/ehea_main.c:1306: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'u64'
Caused by commit 539995d18649023199986424d140f1d620372ce5 ("ehea: Use the
standard logging functions") interacting with commit
5c7e57f7cddb83d81d83fefa5822dfe80891130e ("ehea: Add some info messages
and fix an issue") which went into Linus' tree before 2.6.37-rc4.
Presumably a merge of net-current into the net tree will need a fixup patch.
I have used the net tree from next-20101206 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] Dot not insert RX urbs if EVENT_DEV_ASLEEP flag is set.
From: David Brownell @ 2010-12-07 2:49 UTC (permalink / raw)
To: Indrek Peri
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1291631047-23766-1-git-send-email-Indrek.Peri-rMwOiwQz3sZWk0Htik3J/w@public.gmane.org>
I realize it's not all your doing, but that's an EVENT not a state flag,
But you're treating it as a state flag. (Like the original somewhat
goofy 69ee472f2706371ca639de49b06df91615c07d8d from Oliver). Even as
a flag, its semantics seem fuzzy... like they should be covered by
other state in the network and/or power management stacks.
I'd like to see this botch fixed, not worsened. Maybe you and Oliver
could collaborate on fixing it, and getting other state flags out ofthe
word used to track and signal events? If you've ever worked with
hardware
that makes that kind of mistake, you know how error-prone it is ...
Meanwhile, NAK.
ISTR related Comments came up when a previous incarnation of this patch
circulated, from at least Alan Stern. What happened to that?
Events trigger state transitions and similar actions. So
A "leave sleep state" event" might be a place to trigger RX urb
insertion as part of wake-up processing. (Ideally, there'd be
no need to set an event bit to trigger it as deferred work ... the
reason to have a word of event bits for some other events.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Insert interrupt URB after resume, so that status transfers can flow.
From: David Brownell @ 2010-12-07 2:57 UTC (permalink / raw)
To: Indrek Peri; +Cc: netdev
In-Reply-To: <1291630983-23725-1-git-send-email-Indrek.Peri@Ericsson.com>
Building on my comment about your other patch ... shouldn't this be just
another part of the "resume driver" action,
like refilling the RX urb queue?
For the same reasons ... NAK. It looks like the work to add suspend and
resume processing to this driver had a few holes, and resume handling
can be simplified by combining re-activation of RX processing and this
status reporting (where relevant) in one routine.
- Dave
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: David Miller @ 2010-12-07 4:46 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, joe, leitao
In-Reply-To: <20101207120039.6ea1491e.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 7 Dec 2010 12:00:39 +1100
> After merging the net tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/net/ehea/ehea_main.c: In function 'ehea_refill_rq1':
> drivers/net/ehea/ehea_main.c:405: error: implicit declaration of function 'ehea_info'
> drivers/net/ehea/ehea_main.c: In function 'ehea_init_fill_rq1':
> drivers/net/ehea/ehea_main.c:429: error: implicit declaration of function 'ehea_error'
> drivers/net/ehea/ehea_main.c: In function 'ehea_neq_tasklet':
> drivers/net/ehea/ehea_main.c:1306: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'u64'
>
> Caused by commit 539995d18649023199986424d140f1d620372ce5 ("ehea: Use the
> standard logging functions") interacting with commit
> 5c7e57f7cddb83d81d83fefa5822dfe80891130e ("ehea: Add some info messages
> and fix an issue") which went into Linus' tree before 2.6.37-rc4.
>
> Presumably a merge of net-current into the net tree will need a fixup patch.
>
> I have used the net tree from next-20101206 for today.
I'm reverting Joe's change from net-next-2.6 to handle this, Joe can
resubmit after I next do a net-2.6 --> net-next-2.6 merge
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: Joe Perches @ 2010-12-07 4:57 UTC (permalink / raw)
To: David Miller; +Cc: sfr, netdev, linux-next, linux-kernel, leitao
In-Reply-To: <20101206.204646.59694635.davem@davemloft.net>
On Mon, 2010-12-06 at 20:46 -0800, David Miller wrote:
> I'm reverting Joe's change from net-next-2.6 to handle this, Joe can
> resubmit after I next do a net-2.6 --> net-next-2.6 merge
I'll get this sorted out after the merges are done.
Bruno? I hope you don't mind testing again later.
^ permalink raw reply
* [PATCH net-next-2.6] filter: constify sk_run_filter()
From: Eric Dumazet @ 2010-12-07 6:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
sk_run_filter() doesnt write on skb, change its prototype to reflect
this.
Fix two af_packet comments.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/filter.h | 2 +-
net/core/filter.c | 7 ++++---
net/core/timestamping.c | 2 +-
net/packet/af_packet.c | 31 ++++++++++++++++---------------
4 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 5334ada..45266b7 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -148,7 +148,7 @@ struct sk_buff;
struct sock;
extern int sk_filter(struct sock *sk, struct sk_buff *skb);
-extern unsigned int sk_run_filter(struct sk_buff *skb,
+extern unsigned int sk_run_filter(const struct sk_buff *skb,
const struct sock_filter *filter);
extern int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk);
extern int sk_detach_filter(struct sock *sk);
diff --git a/net/core/filter.c b/net/core/filter.c
index ac4920a..25500f1 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -88,7 +88,7 @@ enum {
};
/* No hurry in this branch */
-static void *__load_pointer(struct sk_buff *skb, int k)
+static void *__load_pointer(const struct sk_buff *skb, int k)
{
u8 *ptr = NULL;
@@ -102,7 +102,7 @@ static void *__load_pointer(struct sk_buff *skb, int k)
return NULL;
}
-static inline void *load_pointer(struct sk_buff *skb, int k,
+static inline void *load_pointer(const struct sk_buff *skb, int k,
unsigned int size, void *buffer)
{
if (k >= 0)
@@ -160,7 +160,8 @@ EXPORT_SYMBOL(sk_filter);
* and last instruction guaranteed to be a RET, we dont need to check
* flen. (We used to pass to this function the length of filter)
*/
-unsigned int sk_run_filter(struct sk_buff *skb, const struct sock_filter *fentry)
+unsigned int sk_run_filter(const struct sk_buff *skb,
+ const struct sock_filter *fentry)
{
void *ptr;
u32 A = 0; /* Accumulator */
diff --git a/net/core/timestamping.c b/net/core/timestamping.c
index dac7ed6..b124d28 100644
--- a/net/core/timestamping.c
+++ b/net/core/timestamping.c
@@ -26,7 +26,7 @@ static struct sock_filter ptp_filter[] = {
PTP_FILTER
};
-static unsigned int classify(struct sk_buff *skb)
+static unsigned int classify(const struct sk_buff *skb)
{
if (likely(skb->dev &&
skb->dev->phydev &&
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index a11c731..17eafe5 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -517,7 +517,8 @@ out_free:
return err;
}
-static inline unsigned int run_filter(struct sk_buff *skb, struct sock *sk,
+static inline unsigned int run_filter(const struct sk_buff *skb,
+ const struct sock *sk,
unsigned int res)
{
struct sk_filter *filter;
@@ -532,15 +533,15 @@ static inline unsigned int run_filter(struct sk_buff *skb, struct sock *sk,
}
/*
- This function makes lazy skb cloning in hope that most of packets
- are discarded by BPF.
-
- Note tricky part: we DO mangle shared skb! skb->data, skb->len
- and skb->cb are mangled. It works because (and until) packets
- falling here are owned by current CPU. Output packets are cloned
- by dev_queue_xmit_nit(), input packets are processed by net_bh
- sequencially, so that if we return skb to original state on exit,
- we will not harm anyone.
+ * This function makes lazy skb cloning in hope that most of packets
+ * are discarded by BPF.
+ *
+ * Note tricky part: we DO mangle shared skb! skb->data, skb->len
+ * and skb->cb are mangled. It works because (and until) packets
+ * falling here are owned by current CPU. Output packets are cloned
+ * by dev_queue_xmit_nit(), input packets are processed by net_bh
+ * sequencially, so that if we return skb to original state on exit,
+ * we will not harm anyone.
*/
static int packet_rcv(struct sk_buff *skb, struct net_device *dev,
@@ -566,11 +567,11 @@ static int packet_rcv(struct sk_buff *skb, struct net_device *dev,
if (dev->header_ops) {
/* The device has an explicit notion of ll header,
- exported to higher levels.
-
- Otherwise, the device hides datails of it frame
- structure, so that corresponding packet head
- never delivered to user.
+ * exported to higher levels.
+ *
+ * Otherwise, the device hides details of its frame
+ * structure, so that corresponding packet head is
+ * never delivered to user.
*/
if (sk->sk_type != SOCK_DGRAM)
skb_push(skb, skb->data - skb_mac_header(skb));
^ permalink raw reply related
* [PATCH net-next-2.6] net: call dev_queue_xmit_nit() after skb_dst_drop()
From: Eric Dumazet @ 2010-12-07 7:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Avoid some atomic ops on dst refcount, calling dev_queue_xmit_nit()
after skb_dst_drop() in dev_hard_start_xmit().
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
Next patch will perform the sk_run_filter() in dev_queue_xmit_nit(),
before cloning skb and af_packet rcv() call.
net/core/dev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 55ff66f..59360ef 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2025,9 +2025,6 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
int rc = NETDEV_TX_OK;
if (likely(!skb->next)) {
- if (!list_empty(&ptype_all))
- dev_queue_xmit_nit(skb, dev);
-
/*
* If device doesnt need skb->dst, release it right now while
* its hot in this cpu cache
@@ -2037,6 +2034,9 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
skb_orphan_try(skb);
+ if (!list_empty(&ptype_all))
+ dev_queue_xmit_nit(skb, dev);
+
if (vlan_tx_tag_present(skb) &&
!(dev->features & NETIF_F_HW_VLAN_TX)) {
skb = __vlan_put_tag(skb, vlan_tx_tag_get(skb));
^ permalink raw reply related
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