* Re: [PATCH 6/6] drivers: net: ethernet: cpsw: implement timestamping capabilities in cpsw
From: Richard Cochran @ 2012-10-21 18:11 UTC (permalink / raw)
To: Mugunthan V N; +Cc: netdev, davem
In-Reply-To: <1350427518-7230-7-git-send-email-mugunthanvnm@ti.com>
On Wed, Oct 17, 2012 at 04:15:18AM +0530, Mugunthan V N wrote:
> This patch implements timestamping capabilities in cpsw through IOCTL interface
> to enable and disable PTP time stamping and adds hardware time stamps to the
> packet's skb buffer using cpts api
Just out of curiosity, I compiled and booted this patch series, but it
does not work. The CPTS driver fails with
[ 1.901459] Missing cpts_reg_ofs property in the DT.
[ 1.906835] cpsw: platform data missing
so I think you forgot to patch the dts files.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 3/5] net/at91_ether: move eth addr quirk into csb337 board setup
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-21 18:25 UTC (permalink / raw)
To: Joachim Eastwood
Cc: bgat, netdev, nicolas.ferre, hskinnemoen, davem, linux-arm-kernel,
egtvedt
In-Reply-To: <1350829392-3812-4-git-send-email-manabian@gmail.com>
On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
> Move Ethernet address byte order fix for csb337 into it's board
> setup.
>
> This will allow us to remove the last mach include from at91_ether
> and also to share the address setup with the macb driver.
no the at91rm9200 move to DT this is not compatible with it
you need to pass ths in info via platform_data
and do not touch driver code related stuff in boards
Best Regards,
J.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> ---
> arch/arm/mach-at91/board-csb337.c | 35 +++++++++++++++++++++++++++++++
> drivers/net/ethernet/cadence/Kconfig | 1 -
> drivers/net/ethernet/cadence/at91_ether.c | 26 ++++++-----------------
> 3 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-at91/board-csb337.c b/arch/arm/mach-at91/board-csb337.c
> index 3e37437..5522132 100644
> --- a/arch/arm/mach-at91/board-csb337.c
> +++ b/arch/arm/mach-at91/board-csb337.c
> @@ -217,6 +217,40 @@ static struct gpio_led csb_leds[] = {
> }
> };
>
> +/*
> + * MicroMonitor (uMon) on the CSB337 store the ethernet address in the
> + * wrong byte order (and continues to do so, for bug-compatibility).
> + */
> +#define MACB_SA1B 0x0098
> +#define MACB_SA1T 0x009c
> +static void __init csb337_fix_eth_addr(void)
> +{
> + void __iomem *emac;
> + u32 lo, hi, tmp;
> + int i;
> +
> + emac = ioremap(AT91RM9200_BASE_EMAC, SZ_16K);
> + if (!emac) {
> + printk(KERN_ERR "csb337: unable to fixup Ethernet address\n");
> + return;
> + }
> +
> + /* Fix byte order on all 4 address registers */
> + for (i = 0; i < 4; i++) {
> + lo = readl(emac + MACB_SA1B + i * 8);
> + hi = readl(emac + MACB_SA1T + i * 8);
> +
> + tmp = (lo & 0xff) << 8 | (lo & 0xff00) >> 8;
> + writel(tmp, emac + MACB_SA1T + i * 8);
> +
> + tmp = (hi & 0xff) << 8 | (hi & 0xff00) >> 8
> + | (lo & 0xff0000) << 8
> + | (lo & 0xff000000) >> 8;
> + writel(tmp, emac + MACB_SA1B + i * 8);
> + }
> +
> + iounmap(emac);
> +}
>
> static void __init csb337_board_init(void)
> {
> @@ -225,6 +259,7 @@ static void __init csb337_board_init(void)
> at91_register_uart(0, 0, 0);
> at91_add_device_serial();
> /* Ethernet */
> + csb337_fix_eth_addr();
> at91_add_device_eth(&csb337_eth_data);
> /* USB Host */
> at91_add_device_usbh(&csb337_usbh_data);
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> index f6d0956..40172d1 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -21,7 +21,6 @@ if NET_CADENCE
>
> config ARM_AT91_ETHER
> tristate "AT91RM9200 Ethernet support"
> - depends on ARM && ARCH_AT91RM9200
> select NET_CORE
> select MACB
> ---help---
> diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
> index 375d272..5ed1a63 100644
> --- a/drivers/net/ethernet/cadence/at91_ether.c
> +++ b/drivers/net/ethernet/cadence/at91_ether.c
> @@ -32,8 +32,6 @@
> #include <linux/phy.h>
> #include <linux/io.h>
>
> -#include <asm/mach-types.h>
> -
> #include "macb.h"
>
> #define DRV_NAME "at91_ether"
> @@ -55,30 +53,18 @@
> * U-Boot on the AT91RM9200-DK do not do this.
> *
> * - Likewise it must store the addresses in the correct byte order.
> - * MicroMonitor (uMon) on the CSB337 does this incorrectly (and
> - * continues to do so, for bug-compatibility).
> */
>
> static short __init unpack_mac_address(struct net_device *dev, unsigned int hi, unsigned int lo)
> {
> char addr[6];
>
> - if (machine_is_csb337()) {
> - addr[5] = (lo & 0xff); /* The CSB337 bootloader stores the MAC the wrong-way around */
> - addr[4] = (lo & 0xff00) >> 8;
> - addr[3] = (lo & 0xff0000) >> 16;
> - addr[2] = (lo & 0xff000000) >> 24;
> - addr[1] = (hi & 0xff);
> - addr[0] = (hi & 0xff00) >> 8;
> - }
> - else {
> - addr[0] = (lo & 0xff);
> - addr[1] = (lo & 0xff00) >> 8;
> - addr[2] = (lo & 0xff0000) >> 16;
> - addr[3] = (lo & 0xff000000) >> 24;
> - addr[4] = (hi & 0xff);
> - addr[5] = (hi & 0xff00) >> 8;
> - }
> + addr[0] = (lo & 0xff);
> + addr[1] = (lo & 0xff00) >> 8;
> + addr[2] = (lo & 0xff0000) >> 16;
> + addr[3] = (lo & 0xff000000) >> 24;
> + addr[4] = (hi & 0xff);
> + addr[5] = (hi & 0xff00) >> 8;
>
> if (is_valid_ether_addr(addr)) {
> memcpy(dev->dev_addr, &addr, 6);
> --
> 1.7.12.4
>
^ permalink raw reply
* Re: [PATCH 1/5] net/cadence: get rid of HAVE_NET_MACB
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-21 18:30 UTC (permalink / raw)
To: Joachim Eastwood
Cc: bgat, netdev, nicolas.ferre, hskinnemoen, davem, linux-arm-kernel,
egtvedt
In-Reply-To: <1350829392-3812-2-git-send-email-manabian@gmail.com>
On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
> macb is a platform driver and there is nothing that prevents
> this driver from being built on non-ARM/AVR32 platforms.
if you want to drop the HAVE_NET_MACB you need to drop it everywher in one
patch
Best Regards,
J.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> ---
> drivers/net/ethernet/cadence/Kconfig | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> index 57f78abe..5d1ea30 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -2,13 +2,9 @@
> # Atmel device configuration
> #
>
> -config HAVE_NET_MACB
> - bool
> -
> config NET_CADENCE
> bool "Cadence devices"
> default y
> - depends on HAVE_NET_MACB || (ARM && ARCH_AT91RM9200)
> ---help---
> If you have a network (Ethernet) card belonging to this class, say Y.
> Make sure you know the name of your card. Read the Ethernet-HOWTO,
> @@ -34,7 +30,6 @@ config ARM_AT91_ETHER
>
> config MACB
> tristate "Cadence MACB/GEM support"
> - depends on HAVE_NET_MACB
> select PHYLIB
> ---help---
> The Cadence MACB ethernet interface is found on many Atmel AT32 and
> --
> 1.7.12.4
>
^ permalink raw reply
* Re: [PATCH 2/5] net/at91_ether: select MACB in Kconfig
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-21 18:31 UTC (permalink / raw)
To: Joachim Eastwood
Cc: bgat, netdev, nicolas.ferre, hskinnemoen, davem, linux-arm-kernel,
egtvedt
In-Reply-To: <1350829392-3812-3-git-send-email-manabian@gmail.com>
On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
> Now that HAVE_NET_MACB is gone let's just select MACB to
> satisfy the dependecies in at91_ether.
>
> PHYLIB will then by selected by MACB.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> ---
> drivers/net/ethernet/cadence/Kconfig | 2 +-
> drivers/net/ethernet/cadence/Makefile | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> index 5d1ea30..f6d0956 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -23,7 +23,7 @@ config ARM_AT91_ETHER
> tristate "AT91RM9200 Ethernet support"
> depends on ARM && ARCH_AT91RM9200
> select NET_CORE
> - select PHYLIB
> + select MACB
no the ether and macb are two diferrent drivers for 2 IPs from cadence
the ehter does not need the macb
Best Regards,
J.
> ---help---
> If you wish to compile a kernel for the AT91RM9200 and enable
> ethernet support, then you should always answer Y to this.
> diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
> index 798b1e0..9068b83 100644
> --- a/drivers/net/ethernet/cadence/Makefile
> +++ b/drivers/net/ethernet/cadence/Makefile
> @@ -2,5 +2,5 @@
> # Makefile for the Atmel network device drivers.
> #
>
> -obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o macb.o
> +obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
> obj-$(CONFIG_MACB) += macb.o
> --
> 1.7.12.4
>
^ permalink raw reply
* Re: [PATCH 3/5] net/at91_ether: move eth addr quirk into csb337 board setup
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-21 18:34 UTC (permalink / raw)
To: Joachim Eastwood
Cc: bgat, netdev, nicolas.ferre, hskinnemoen, davem, linux-arm-kernel,
egtvedt
In-Reply-To: <1350829392-3812-4-git-send-email-manabian@gmail.com>
On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
> Move Ethernet address byte order fix for csb337 into it's board
> setup.
>
> This will allow us to remove the last mach include from at91_ether
> and also to share the address setup with the macb driver.
no the current drivers expect mach/board.h, mach/at91rm9200_emac.h, asm/gpio.h
waht you did will not even compile on non at91 platform
Did you even compile it on non at91?
Best Regards,
J.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> ---
> arch/arm/mach-at91/board-csb337.c | 35 +++++++++++++++++++++++++++++++
> drivers/net/ethernet/cadence/Kconfig | 1 -
> drivers/net/ethernet/cadence/at91_ether.c | 26 ++++++-----------------
> 3 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-at91/board-csb337.c b/arch/arm/mach-at91/board-csb337.c
> index 3e37437..5522132 100644
> --- a/arch/arm/mach-at91/board-csb337.c
> +++ b/arch/arm/mach-at91/board-csb337.c
> @@ -217,6 +217,40 @@ static struct gpio_led csb_leds[] = {
> }
> };
>
> +/*
> + * MicroMonitor (uMon) on the CSB337 store the ethernet address in the
> + * wrong byte order (and continues to do so, for bug-compatibility).
> + */
> +#define MACB_SA1B 0x0098
> +#define MACB_SA1T 0x009c
> +static void __init csb337_fix_eth_addr(void)
> +{
> + void __iomem *emac;
> + u32 lo, hi, tmp;
> + int i;
> +
> + emac = ioremap(AT91RM9200_BASE_EMAC, SZ_16K);
> + if (!emac) {
> + printk(KERN_ERR "csb337: unable to fixup Ethernet address\n");
> + return;
> + }
> +
> + /* Fix byte order on all 4 address registers */
> + for (i = 0; i < 4; i++) {
> + lo = readl(emac + MACB_SA1B + i * 8);
> + hi = readl(emac + MACB_SA1T + i * 8);
> +
> + tmp = (lo & 0xff) << 8 | (lo & 0xff00) >> 8;
> + writel(tmp, emac + MACB_SA1T + i * 8);
> +
> + tmp = (hi & 0xff) << 8 | (hi & 0xff00) >> 8
> + | (lo & 0xff0000) << 8
> + | (lo & 0xff000000) >> 8;
> + writel(tmp, emac + MACB_SA1B + i * 8);
> + }
> +
> + iounmap(emac);
> +}
>
> static void __init csb337_board_init(void)
> {
> @@ -225,6 +259,7 @@ static void __init csb337_board_init(void)
> at91_register_uart(0, 0, 0);
> at91_add_device_serial();
> /* Ethernet */
> + csb337_fix_eth_addr();
> at91_add_device_eth(&csb337_eth_data);
> /* USB Host */
> at91_add_device_usbh(&csb337_usbh_data);
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> index f6d0956..40172d1 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -21,7 +21,6 @@ if NET_CADENCE
>
> config ARM_AT91_ETHER
> tristate "AT91RM9200 Ethernet support"
> - depends on ARM && ARCH_AT91RM9200
> select NET_CORE
> select MACB
> ---help---
> diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
> index 375d272..5ed1a63 100644
> --- a/drivers/net/ethernet/cadence/at91_ether.c
> +++ b/drivers/net/ethernet/cadence/at91_ether.c
> @@ -32,8 +32,6 @@
> #include <linux/phy.h>
> #include <linux/io.h>
>
> -#include <asm/mach-types.h>
> -
> #include "macb.h"
>
> #define DRV_NAME "at91_ether"
> @@ -55,30 +53,18 @@
> * U-Boot on the AT91RM9200-DK do not do this.
> *
> * - Likewise it must store the addresses in the correct byte order.
> - * MicroMonitor (uMon) on the CSB337 does this incorrectly (and
> - * continues to do so, for bug-compatibility).
> */
>
> static short __init unpack_mac_address(struct net_device *dev, unsigned int hi, unsigned int lo)
> {
> char addr[6];
>
> - if (machine_is_csb337()) {
> - addr[5] = (lo & 0xff); /* The CSB337 bootloader stores the MAC the wrong-way around */
> - addr[4] = (lo & 0xff00) >> 8;
> - addr[3] = (lo & 0xff0000) >> 16;
> - addr[2] = (lo & 0xff000000) >> 24;
> - addr[1] = (hi & 0xff);
> - addr[0] = (hi & 0xff00) >> 8;
> - }
> - else {
> - addr[0] = (lo & 0xff);
> - addr[1] = (lo & 0xff00) >> 8;
> - addr[2] = (lo & 0xff0000) >> 16;
> - addr[3] = (lo & 0xff000000) >> 24;
> - addr[4] = (hi & 0xff);
> - addr[5] = (hi & 0xff00) >> 8;
> - }
> + addr[0] = (lo & 0xff);
> + addr[1] = (lo & 0xff00) >> 8;
> + addr[2] = (lo & 0xff0000) >> 16;
> + addr[3] = (lo & 0xff000000) >> 24;
> + addr[4] = (hi & 0xff);
> + addr[5] = (hi & 0xff00) >> 8;
>
> if (is_valid_ether_addr(addr)) {
> memcpy(dev->dev_addr, &addr, 6);
> --
> 1.7.12.4
>
^ permalink raw reply
* Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels
From: Mike Kazantsev @ 2012-10-21 18:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Paul Moore, netdev, linux-mm
In-Reply-To: <20121021195701.7a5872e7@sacrilege>
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
On Sun, 21 Oct 2012 19:57:01 +0600
Mike Kazantsev <mk.fraggod@gmail.com> wrote:
> On Sun, 21 Oct 2012 15:29:43 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> >
> > Did you try linux-3.7-rc2 (or linux-3.7-rc1) ?
> >
>
> I did not, will do in a few hours, thanks for the pointer.
>
I just built "torvalds/linux-2.6" (v3.7-rc2) and rebooted into it,
started same rsync-over-net test and got kmalloc-64 leaking (it went up
to tens of MiB until I stopped rsync, normally these are fixed at ~500
KiB).
Unfortunately, I forgot to add slub_debug option and build kmemleak so
wasn't able to look at this case further, and when I rebooted with
these enabled/built, it was secpath_cache again.
So previously noted "slabtop showed 'kmalloc-64' being the 99% offender
in the past, but with recent kernels (3.6.1), it has changed to
'secpath_cache'" seem to be incorrect, as it seem to depend not on
kernel version, but some other factor.
Guess I'll try to reboot a few more times to see if I can catch
kmalloc-64 leaking (instead of secpath_cache) again.
--
Mike Kazantsev // fraggod.net
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 0/6] Add CPTS PTP driver support
From: Richard Cochran @ 2012-10-21 18:46 UTC (permalink / raw)
To: Mugunthan V N; +Cc: netdev, davem
In-Reply-To: <1350427518-7230-1-git-send-email-mugunthanvnm@ti.com>
On Wed, Oct 17, 2012 at 04:15:12AM +0530, Mugunthan V N wrote:
> This patch series contains driver implementation for TI Common Platform
> Time Sync (CPTS) driver for PTP packet timestamping.
>
> CPTS is found in following TI SoC.
> * AM335X - http://www.ti.com/litv/pdf/spruh73c
> * DM814X - http://www.ti.com/litv/pdf/sprugz8
>
> The Common Platform Time Sync (CPTS) module is used to facilitate host
> control of time sync operations. It enables compliance with the IEEE 1588-2008
> standard for a precision clock synchronization protocol
>
> This patch series is tested over vanilla kernel with the below patches
> http://marc.info/?l=linux-arm-kernel&m=135032863723906&w=2
I tried v3.7-rc1 plus those patches, plus this patch series, plus the
small addition of this ...
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f6bea04..e0e152b 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -222,6 +222,7 @@
ale_entries = <1024>;
host_port_reg_ofs = <0x108>;
hw_stats_reg_ofs = <0x900>;
+ cpts_reg_ofs = <0xc00>;
bd_ram_ofs = <0x2000>;
bd_ram_size = <0x2000>;
no_bd_ram = <0>;
... and it doesn't work.
> Tested both L2 and L4 PTP packet timestamping
Really?
With your driver I could not get either L2 or L4 time stamps to
appear. At this point, my own driver is working a lot better, and so
this just adds another reason to favor my driver, in addtion to the
points I mentioned in my other post.
Thanks,
Richard
^ permalink raw reply related
* Re: Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Artem S. Tashkinov @ 2012-10-21 19:49 UTC (permalink / raw)
To: bp
Cc: pavel, linux-kernel, netdev, security, linux-media, linux-usb,
zonque, alsa-devel, stern
In-Reply-To: <20121021170315.GB20642@liondog.tnic>
>
> On Oct 21, 2012, Borislav Petkov <bp@alien8.de> wrote:
>
> On Sun, Oct 21, 2012 at 11:59:36AM +0000, Artem S. Tashkinov wrote:
> > http://imageshack.us/a/img685/9452/panicz.jpg
> >
> > list_del corruption. prev->next should be ... but was ...
>
> Btw, this is one of the debug options I told you to enable.
>
> > I cannot show you more as I have no serial console to use :( and the kernel
> > doesn't have enough time to push error messages to rsyslog and fsync
> > /var/log/messages
>
> I already told you how to catch that oops: boot with "pause_on_oops=600"
> on the kernel command line and photograph the screen when the first oops
> happens. This'll show us where the problem begins.
This option didn't have any effect, or maybe it's because it's such a serious crash
the kernel has no time to actually print an ooops/panic message.
dmesg messages up to a crash can be seen here: https://bugzilla.kernel.org/attachment.cgi?id=84221
I dumped them using this application:
$ cat scat.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#define O_LARGEFILE 0100000
#define BUFFER 4096
#define __USE_FILE_OFFSET64 1
#define __USE_LARGEFILE64 1
int main(int argc, char *argv[])
{
int fd_out;
int64_t bytes_read;
void *buffer;
if (argc!=2) {
printf("Usage is: scat destination\n");
return 1;
}
buffer = malloc(BUFFER * sizeof(char));
if (buffer == NULL) {
printf("Error: can't allocate buffers\n");
return 2;
}
memset(buffer, 0, BUFFER);
printf("Dumping to \"%s\" ... ", argv[1]);
fflush(NULL);
if ((fd_out = open64(argv[1], O_WRONLY | O_LARGEFILE | O_SYNC | O_NOFOLLOW, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH)) == -1) {
printf("Error: destination file can't be created\n");
perror("open() ");
return 2;
}
bytes_read = 1;
while (bytes_read) {
bytes_read = fread(buffer, sizeof(char), BUFFER, stdin);
if (write(fd_out, (void *) buffer, bytes_read) != bytes_read)
{
printf("Error: can't write data to the destination file! Possibly a target disk is full\n");
return 3;
}
}
close(fd_out);
printf(" OK\n");
return 0;
}
I ran it this way: while :; do dmesg -c; done | scat /dev/sda11 (yes, straight to a hdd partition to eliminate a FS cache)
Don't judge me harshly - I'm not a programmer.
^ permalink raw reply
* Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels
From: Mike Kazantsev @ 2012-10-21 19:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Paul Moore, netdev, linux-mm
In-Reply-To: <20121022004332.7e3f3f29@sacrilege>
[-- Attachment #1: Type: text/plain, Size: 2459 bytes --]
On Mon, 22 Oct 2012 00:43:32 +0600
Mike Kazantsev <mk.fraggod@gmail.com> wrote:
> > On Sun, 21 Oct 2012 15:29:43 +0200
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > >
> > > Did you try linux-3.7-rc2 (or linux-3.7-rc1) ?
> > >
>
> I just built "torvalds/linux-2.6" (v3.7-rc2) and rebooted into it,
> started same rsync-over-net test and got kmalloc-64 leaking (it went up
> to tens of MiB until I stopped rsync, normally these are fixed at ~500
> KiB).
>
> Unfortunately, I forgot to add slub_debug option and build kmemleak so
> wasn't able to look at this case further, and when I rebooted with
> these enabled/built, it was secpath_cache again.
>
> So previously noted "slabtop showed 'kmalloc-64' being the 99% offender
> in the past, but with recent kernels (3.6.1), it has changed to
> 'secpath_cache'" seem to be incorrect, as it seem to depend not on
> kernel version, but some other factor.
>
> Guess I'll try to reboot a few more times to see if I can catch
> kmalloc-64 leaking (instead of secpath_cache) again.
>
I haven't been able to catch the aforementioned condition, but noticed
that with v3.7-rc2, "hex dump" part seem to vary in kmemleak
traces, and contain all sorts of random stuff, for example:
unreferenced object 0xffff88002ae2de00 (size 56):
comm "softirq", pid 0, jiffies 4295006317 (age 213.066s)
hex dump (first 32 bytes):
01 00 00 00 01 00 00 00 20 9f f4 28 00 88 ff ff ........ ..(....
2f 6f 72 67 2f 66 72 65 65 64 65 73 6b 74 6f 70 /org/freedesktop
backtrace:
[<ffffffff814da4e3>] kmemleak_alloc+0x21/0x3e
[<ffffffff810dc1f7>] kmem_cache_alloc+0xa5/0xb1
[<ffffffff81487bf1>] secpath_dup+0x1b/0x5a
[<ffffffff81487df5>] xfrm_input+0x64/0x484
[<ffffffff814bbd70>] xfrm6_rcv_spi+0x19/0x1b
[<ffffffff814bbd92>] xfrm6_rcv+0x20/0x22
[<ffffffff814960c3>] ip6_input_finish+0x203/0x31b
[<ffffffff81496542>] ip6_input+0x1e/0x50
[<ffffffff81496240>] ip6_rcv_finish+0x65/0x69
[<ffffffff814964c3>] ipv6_rcv+0x27f/0x2e0
[<ffffffff8140a659>] __netif_receive_skb+0x5ba/0x65a
[<ffffffff8140a894>] netif_receive_skb+0x47/0x78
[<ffffffff8140b4bf>] napi_skb_finish+0x21/0x54
[<ffffffff8140b5ef>] napi_gro_receive+0xfd/0x10a
[<ffffffff81372b47>] rtl8169_poll+0x326/0x4fc
[<ffffffff8140ad44>] net_rx_action+0x9f/0x188
Not sure if it's relevant though.
--
Mike Kazantsev // fraggod.net
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Daniel Mack @ 2012-10-21 19:54 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: bp, pavel, linux-kernel, netdev, security, linux-media, linux-usb,
alsa-devel, stern
In-Reply-To: <1906833625.122006.1350848941352.JavaMail.mail@webmail16>
On 21.10.2012 21:49, Artem S. Tashkinov wrote:
>>
>> On Oct 21, 2012, Borislav Petkov <bp@alien8.de> wrote:
>>
>> On Sun, Oct 21, 2012 at 11:59:36AM +0000, Artem S. Tashkinov wrote:
>>> http://imageshack.us/a/img685/9452/panicz.jpg
>>>
>>> list_del corruption. prev->next should be ... but was ...
>>
>> Btw, this is one of the debug options I told you to enable.
>>
>>> I cannot show you more as I have no serial console to use :( and the kernel
>>> doesn't have enough time to push error messages to rsyslog and fsync
>>> /var/log/messages
>>
>> I already told you how to catch that oops: boot with "pause_on_oops=600"
>> on the kernel command line and photograph the screen when the first oops
>> happens. This'll show us where the problem begins.
>
> This option didn't have any effect, or maybe it's because it's such a serious crash
> the kernel has no time to actually print an ooops/panic message.
>
> dmesg messages up to a crash can be seen here: https://bugzilla.kernel.org/attachment.cgi?id=84221
Nice. Could you do that again with the patch applied I sent yo some
hours ago?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 1/5] net/cadence: get rid of HAVE_NET_MACB
From: Joachim Eastwood @ 2012-10-21 20:26 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: nicolas.ferre, davem, hskinnemoen, egtvedt, bgat, netdev,
linux-arm-kernel
In-Reply-To: <20121021183005.GA18964@game.jcrosoft.org>
On Sun, Oct 21, 2012 at 8:30 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
>> macb is a platform driver and there is nothing that prevents
>> this driver from being built on non-ARM/AVR32 platforms.
> if you want to drop the HAVE_NET_MACB you need to drop it everywher in one
> patch
Breaking it up in several patches doesn't seem to cause any build
failures and I did this in case the patches were going into different
git trees.
regards
Joachim Eastwood
^ permalink raw reply
* Re: [PATCH 2/5] net/at91_ether: select MACB in Kconfig
From: Joachim Eastwood @ 2012-10-21 20:27 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: nicolas.ferre, davem, hskinnemoen, egtvedt, bgat, netdev,
linux-arm-kernel
In-Reply-To: <20121021183122.GB18964@game.jcrosoft.org>
On Sun, Oct 21, 2012 at 8:31 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
>> Now that HAVE_NET_MACB is gone let's just select MACB to
>> satisfy the dependecies in at91_ether.
>>
>> PHYLIB will then by selected by MACB.
>>
>> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
>> ---
>> drivers/net/ethernet/cadence/Kconfig | 2 +-
>> drivers/net/ethernet/cadence/Makefile | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
>> index 5d1ea30..f6d0956 100644
>> --- a/drivers/net/ethernet/cadence/Kconfig
>> +++ b/drivers/net/ethernet/cadence/Kconfig
>> @@ -23,7 +23,7 @@ config ARM_AT91_ETHER
>> tristate "AT91RM9200 Ethernet support"
>> depends on ARM && ARCH_AT91RM9200
>> select NET_CORE
>> - select PHYLIB
>> + select MACB
> no the ether and macb are two diferrent drivers for 2 IPs from cadence
>
> the ehter does not need the macb
The at91_ether in net-next does.
regards
Joachim Eastwood
^ permalink raw reply
* Re: [PATCH 3/5] net/at91_ether: move eth addr quirk into csb337 board setup
From: Joachim Eastwood @ 2012-10-21 20:30 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: nicolas.ferre, davem, hskinnemoen, egtvedt, bgat, netdev,
linux-arm-kernel
In-Reply-To: <20121021183418.GC18964@game.jcrosoft.org>
On Sun, Oct 21, 2012 at 8:34 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
>> Move Ethernet address byte order fix for csb337 into it's board
>> setup.
>>
>> This will allow us to remove the last mach include from at91_ether
>> and also to share the address setup with the macb driver.
> no the current drivers expect mach/board.h, mach/at91rm9200_emac.h, asm/gpio.h
>
> waht you did will not even compile on non at91 platform
>
> Did you even compile it on non at91?
This is the last mach include in the at91_ether driver in net-next.
And, yes, after this patch it complies fine for at least x86_64.
regards
Joachim Eastwood
^ permalink raw reply
* Re: Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Borislav Petkov @ 2012-10-21 20:36 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: pavel, linux-kernel, netdev, security, linux-media, linux-usb,
zonque, alsa-devel, stern
In-Reply-To: <1906833625.122006.1350848941352.JavaMail.mail@webmail16>
On Sun, Oct 21, 2012 at 07:49:01PM +0000, Artem S. Tashkinov wrote:
> I ran it this way: while :; do dmesg -c; done | scat /dev/sda11 (yes,
> straight to a hdd partition to eliminate a FS cache)
Well, I'm no fs guy but this should still go through the buffer cache. I
think the O_SYNC flag makes sure it all lands on the partition in time.
Oh well, it doesn't matter.
> Don't judge me harshly - I'm not a programmer.
If you wrote that and you're not a programmer, it certainly looks cool,
good job!.
[ Btw, don't forget to free(buffer) at the end. ]
Also, there was a patchset recently which added a blockconsole method to
the kernel with which you can do something like that in a generic way.
Back to the issue at hand: it looks like ehci_hcd is causing some list
corruptions, maybe coming from the uvcvideo or whatever. I think the usb
people will have a better idea.
Btw, is there any particular reason you're running a 32-bit kernel?
Thanks.
--
Regards/Gruss,
Boris.
^ permalink raw reply
* Re: [PATCH 3/5] net/at91_ether: move eth addr quirk into csb337 board setup
From: Joachim Eastwood @ 2012-10-21 20:39 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: nicolas.ferre, davem, hskinnemoen, egtvedt, bgat, netdev,
linux-arm-kernel
In-Reply-To: <20121021182551.GH12801@game.jcrosoft.org>
On Sun, Oct 21, 2012 at 8:25 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
>> Move Ethernet address byte order fix for csb337 into it's board
>> setup.
>>
>> This will allow us to remove the last mach include from at91_ether
>> and also to share the address setup with the macb driver.
> no the at91rm9200 move to DT this is not compatible with it
>
> you need to pass ths in info via platform_data
>
> and do not touch driver code related stuff in boards
I know the board code is a bit nasty.
If it's unacceptable I'll cook up a flag and pass it by platform_data,
something like "reverse_eth_addr". Still it will only ever be used on
the csb337 board.
regards
Joachim Eastwood
^ permalink raw reply
* Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Artem S. Tashkinov @ 2012-10-21 20:43 UTC (permalink / raw)
To: zonque
Cc: bp, pavel, linux-kernel, netdev, security, linux-media, linux-usb,
alsa-devel, stern
In-Reply-To: <5084530B.6030209@gmail.com>
> Nice. Could you do that again with the patch applied I sent yo some
> hours ago?
That patch was of no help - the system has crashed and I couldn't spot relevant
messages.
I've no idea what it means.
Artem
^ permalink raw reply
* Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Daniel Mack @ 2012-10-21 21:00 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: bp-Gina5bIWoIWzQB+pC5nmwQ, pavel-+ZI9xUNit7I,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, security-DgEjT+Ai2ygdnm+yROfE0A,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz
In-Reply-To: <1651404200.40745.1350852195790.JavaMail.mail@webmail04>
On 21.10.2012 22:43, Artem S. Tashkinov wrote:
>> Nice. Could you do that again with the patch applied I sent yo some
>> hours ago?
>
> That patch was of no help - the system has crashed and I couldn't spot relevant
> messages.
>
> I've no idea what it means.
The sequence of driver callbacks issued on a stream start is
.open()
.hw_params()
.prepare()
.trigger()
If the ALSA part really causes this issue, the bad things happen either
in any of the driver callback functions or in the core underneath.
The patch I sent returns an error from the hw_params callback, and as
you still see the problem, that means that the crash happens before any
of the USB audio streaming really starts.
Could you try and return -EINVAL from snd_usb_capture_open() please?
If anyone has a better idea on how to debug this, please chime in.
Daniel
--
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: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels
From: Eric Dumazet @ 2012-10-21 21:47 UTC (permalink / raw)
To: Mike Kazantsev; +Cc: Paul Moore, netdev, linux-mm
In-Reply-To: <20121022015134.4de457b9@sacrilege>
On Mon, 2012-10-22 at 01:51 +0600, Mike Kazantsev wrote:
> On Mon, 22 Oct 2012 00:43:32 +0600
> Mike Kazantsev <mk.fraggod@gmail.com> wrote:
>
> > > On Sun, 21 Oct 2012 15:29:43 +0200
> > > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > >
> > > >
> > > > Did you try linux-3.7-rc2 (or linux-3.7-rc1) ?
> > > >
> >
> > I just built "torvalds/linux-2.6" (v3.7-rc2) and rebooted into it,
> > started same rsync-over-net test and got kmalloc-64 leaking (it went up
> > to tens of MiB until I stopped rsync, normally these are fixed at ~500
> > KiB).
> >
> > Unfortunately, I forgot to add slub_debug option and build kmemleak so
> > wasn't able to look at this case further, and when I rebooted with
> > these enabled/built, it was secpath_cache again.
> >
> > So previously noted "slabtop showed 'kmalloc-64' being the 99% offender
> > in the past, but with recent kernels (3.6.1), it has changed to
> > 'secpath_cache'" seem to be incorrect, as it seem to depend not on
> > kernel version, but some other factor.
> >
> > Guess I'll try to reboot a few more times to see if I can catch
> > kmalloc-64 leaking (instead of secpath_cache) again.
> >
>
> I haven't been able to catch the aforementioned condition, but noticed
> that with v3.7-rc2, "hex dump" part seem to vary in kmemleak
> traces, and contain all sorts of random stuff, for example:
>
> unreferenced object 0xffff88002ae2de00 (size 56):
> comm "softirq", pid 0, jiffies 4295006317 (age 213.066s)
> hex dump (first 32 bytes):
> 01 00 00 00 01 00 00 00 20 9f f4 28 00 88 ff ff ........ ..(....
> 2f 6f 72 67 2f 66 72 65 65 64 65 73 6b 74 6f 70 /org/freedesktop
> backtrace:
> [<ffffffff814da4e3>] kmemleak_alloc+0x21/0x3e
> [<ffffffff810dc1f7>] kmem_cache_alloc+0xa5/0xb1
> [<ffffffff81487bf1>] secpath_dup+0x1b/0x5a
> [<ffffffff81487df5>] xfrm_input+0x64/0x484
> [<ffffffff814bbd70>] xfrm6_rcv_spi+0x19/0x1b
> [<ffffffff814bbd92>] xfrm6_rcv+0x20/0x22
> [<ffffffff814960c3>] ip6_input_finish+0x203/0x31b
> [<ffffffff81496542>] ip6_input+0x1e/0x50
> [<ffffffff81496240>] ip6_rcv_finish+0x65/0x69
> [<ffffffff814964c3>] ipv6_rcv+0x27f/0x2e0
> [<ffffffff8140a659>] __netif_receive_skb+0x5ba/0x65a
> [<ffffffff8140a894>] netif_receive_skb+0x47/0x78
> [<ffffffff8140b4bf>] napi_skb_finish+0x21/0x54
> [<ffffffff8140b5ef>] napi_gro_receive+0xfd/0x10a
> [<ffffffff81372b47>] rtl8169_poll+0x326/0x4fc
> [<ffffffff8140ad44>] net_rx_action+0x9f/0x188
>
> Not sure if it's relevant though.
>
>
OK, so some layer seems to have a bug if the skb->head is exactly
allocated, instead of having extra tailroom (because of kmalloc-powerof2
alignment)
Or some layer overwrites past skb->cb[] array
If you try to move sp field in sk_buff, does it change something ?
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 6a2c34e..9b1438a 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -395,6 +395,9 @@ struct sk_buff {
struct sock *sk;
struct net_device *dev;
+#ifdef CONFIG_XFRM
+ struct sec_path *sp;
+#endif
/*
* This is the control buffer. It is free to use for every
* layer. Please put your private variables there. If you
@@ -404,9 +407,6 @@ struct sk_buff {
char cb[48] __aligned(8);
unsigned long _skb_refdst;
-#ifdef CONFIG_XFRM
- struct sec_path *sp;
-#endif
unsigned int len,
data_len;
__u16 mac_len,
Also try to increase tailroom in __netdev_alloc_skb()
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 6e04b1f..972ee4f 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -427,7 +427,7 @@ struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
unsigned int length, gfp_t gfp_mask)
{
struct sk_buff *skb = NULL;
- unsigned int fragsz = SKB_DATA_ALIGN(length + NET_SKB_PAD) +
+ unsigned int fragsz = SKB_DATA_ALIGN(length + NET_SKB_PAD + 64) +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
if (fragsz <= PAGE_SIZE && !(gfp_mask & (__GFP_WAIT | GFP_DMA))) {
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v2 0/3] make cadence ethernet drivers build on any architecture
From: Joachim Eastwood @ 2012-10-21 21:57 UTC (permalink / raw)
To: nicolas.ferre, davem, hskinnemoen, egtvedt, plagnioj, bgat
Cc: netdev, linux-arm-kernel, Joachim Eastwood
This series makes the at91_ether and macb driver build-able on any architecture.
Patch 1 removes the HAVE_NET_MACB from the cadence Kconfig and this allow macb to be built on any architecture. The macb driver requires no other modifications.
Patch 3 moves a bootloader quirk for CSB337 from at91_ether into platform data as a flag. This allow us to remove the last mach include and build this driver on any architecture. It also make it easier to share the address setup between at91_ether and macb.
The next series will make the at91_ether driver use address setting and statistics from macb. There is also a clean up of print outs plus some comment/style fixes.
Joachim Eastwood (3):
net/cadence: get rid of HAVE_NET_MACB
net/at91_ether: select MACB in Kconfig
net/at91_ether: add pdata flag for reverse Eth addr
arch/arm/mach-at91/Kconfig | 4 ----
arch/arm/mach-at91/board-csb337.c | 2 ++
arch/avr32/Kconfig | 1 -
drivers/net/ethernet/cadence/Kconfig | 8 +-------
drivers/net/ethernet/cadence/Makefile | 2 +-
drivers/net/ethernet/cadence/at91_ether.c | 5 ++---
include/linux/platform_data/macb.h | 1 +
7 files changed, 7 insertions(+), 16 deletions(-)
--
1.7.12.4
^ permalink raw reply
* [PATCH v2 1/3] net/cadence: get rid of HAVE_NET_MACB
From: Joachim Eastwood @ 2012-10-21 21:57 UTC (permalink / raw)
To: nicolas.ferre, davem, hskinnemoen, egtvedt, plagnioj, bgat
Cc: netdev, linux-arm-kernel, Joachim Eastwood
In-Reply-To: <1350856623-9819-1-git-send-email-manabian@gmail.com>
macb is a platform driver and there is nothing that prevents
this driver from being built on non-ARM/AVR32 platforms.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
arch/arm/mach-at91/Kconfig | 4 ----
arch/avr32/Kconfig | 1 -
drivers/net/ethernet/cadence/Kconfig | 5 -----
3 files changed, 10 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index d846b6e..72020fb 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -45,7 +45,6 @@ config SOC_AT91RM9200
config SOC_AT91SAM9260
bool "AT91SAM9260, AT91SAM9XE or AT91SAM9G20"
select HAVE_AT91_DBGU0
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9260, AT91SAM9XE
@@ -63,7 +62,6 @@ config SOC_AT91SAM9263
bool "AT91SAM9263"
select HAVE_AT91_DBGU1
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
config SOC_AT91SAM9RL
@@ -76,7 +74,6 @@ config SOC_AT91SAM9G45
bool "AT91SAM9G45 or AT91SAM9M10 families"
select HAVE_AT91_DBGU1
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9G45 family SoC.
@@ -86,7 +83,6 @@ config SOC_AT91SAM9X5
bool "AT91SAM9x5 family"
select HAVE_AT91_DBGU0
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index 06e73bf..09f9fa8 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -80,7 +80,6 @@ config PLATFORM_AT32AP
select ARCH_REQUIRE_GPIOLIB
select GENERIC_ALLOCATOR
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
#
# CPU types
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index 57f78abe..5d1ea30 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -2,13 +2,9 @@
# Atmel device configuration
#
-config HAVE_NET_MACB
- bool
-
config NET_CADENCE
bool "Cadence devices"
default y
- depends on HAVE_NET_MACB || (ARM && ARCH_AT91RM9200)
---help---
If you have a network (Ethernet) card belonging to this class, say Y.
Make sure you know the name of your card. Read the Ethernet-HOWTO,
@@ -34,7 +30,6 @@ config ARM_AT91_ETHER
config MACB
tristate "Cadence MACB/GEM support"
- depends on HAVE_NET_MACB
select PHYLIB
---help---
The Cadence MACB ethernet interface is found on many Atmel AT32 and
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 2/3] net/at91_ether: select MACB in Kconfig
From: Joachim Eastwood @ 2012-10-21 21:57 UTC (permalink / raw)
To: nicolas.ferre, davem, hskinnemoen, egtvedt, plagnioj, bgat
Cc: netdev, linux-arm-kernel, Joachim Eastwood
In-Reply-To: <1350856623-9819-1-git-send-email-manabian@gmail.com>
Now that HAVE_NET_MACB is gone let's just select MACB to
satisfy the dependecies in at91_ether.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
drivers/net/ethernet/cadence/Kconfig | 2 +-
drivers/net/ethernet/cadence/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index 5d1ea30..f6d0956 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -23,7 +23,7 @@ config ARM_AT91_ETHER
tristate "AT91RM9200 Ethernet support"
depends on ARM && ARCH_AT91RM9200
select NET_CORE
- select PHYLIB
+ select MACB
---help---
If you wish to compile a kernel for the AT91RM9200 and enable
ethernet support, then you should always answer Y to this.
diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
index 798b1e0..9068b83 100644
--- a/drivers/net/ethernet/cadence/Makefile
+++ b/drivers/net/ethernet/cadence/Makefile
@@ -2,5 +2,5 @@
# Makefile for the Atmel network device drivers.
#
-obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o macb.o
+obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
obj-$(CONFIG_MACB) += macb.o
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 3/3] net/at91_ether: add pdata flag for reverse Eth addr
From: Joachim Eastwood @ 2012-10-21 21:57 UTC (permalink / raw)
To: nicolas.ferre, davem, hskinnemoen, egtvedt, plagnioj, bgat
Cc: netdev, linux-arm-kernel, Joachim Eastwood
In-Reply-To: <1350856623-9819-1-git-send-email-manabian@gmail.com>
This will allow us to remove the last mach include from at91_ether
and also make it easier to share address setup with macb.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
arch/arm/mach-at91/board-csb337.c | 2 ++
drivers/net/ethernet/cadence/Kconfig | 1 -
drivers/net/ethernet/cadence/at91_ether.c | 5 ++---
include/linux/platform_data/macb.h | 1 +
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-at91/board-csb337.c b/arch/arm/mach-at91/board-csb337.c
index 3e37437..aa9b320 100644
--- a/arch/arm/mach-at91/board-csb337.c
+++ b/arch/arm/mach-at91/board-csb337.c
@@ -53,6 +53,8 @@ static void __init csb337_init_early(void)
static struct macb_platform_data __initdata csb337_eth_data = {
.phy_irq_pin = AT91_PIN_PC2,
.is_rmii = 0,
+ /* The CSB337 bootloader stores the MAC the wrong-way around */
+ .rev_eth_addr = 1,
};
static struct at91_usbh_data __initdata csb337_usbh_data = {
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index f6d0956..40172d1 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -21,7 +21,6 @@ if NET_CADENCE
config ARM_AT91_ETHER
tristate "AT91RM9200 Ethernet support"
- depends on ARM && ARCH_AT91RM9200
select NET_CORE
select MACB
---help---
diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
index 375d272..b92815a 100644
--- a/drivers/net/ethernet/cadence/at91_ether.c
+++ b/drivers/net/ethernet/cadence/at91_ether.c
@@ -32,8 +32,6 @@
#include <linux/phy.h>
#include <linux/io.h>
-#include <asm/mach-types.h>
-
#include "macb.h"
#define DRV_NAME "at91_ether"
@@ -61,9 +59,10 @@
static short __init unpack_mac_address(struct net_device *dev, unsigned int hi, unsigned int lo)
{
+ struct macb *lp = netdev_priv(dev);
char addr[6];
- if (machine_is_csb337()) {
+ if (lp->board_data.rev_eth_addr) {
addr[5] = (lo & 0xff); /* The CSB337 bootloader stores the MAC the wrong-way around */
addr[4] = (lo & 0xff00) >> 8;
addr[3] = (lo & 0xff0000) >> 16;
diff --git a/include/linux/platform_data/macb.h b/include/linux/platform_data/macb.h
index b081c72..044a124 100644
--- a/include/linux/platform_data/macb.h
+++ b/include/linux/platform_data/macb.h
@@ -12,6 +12,7 @@ struct macb_platform_data {
u32 phy_mask;
int phy_irq_pin; /* PHY IRQ */
u8 is_rmii; /* using RMII interface? */
+ u8 rev_eth_addr; /* reverse Ethernet address byte order */
};
#endif /* __MACB_PDATA_H__ */
--
1.7.12.4
^ permalink raw reply related
* Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels
From: Mike Kazantsev @ 2012-10-21 22:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Paul Moore, netdev, linux-mm
In-Reply-To: <1350856053.8609.217.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 3382 bytes --]
On Sun, 21 Oct 2012 23:47:33 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> OK, so some layer seems to have a bug if the skb->head is exactly
> allocated, instead of having extra tailroom (because of kmalloc-powerof2
> alignment)
>
> Or some layer overwrites past skb->cb[] array
>
> If you try to move sp field in sk_buff, does it change something ?
>
...
>
> Also try to increase tailroom in __netdev_alloc_skb()
>
Applied both patches, but unfortunately, the problem seem to be still
there.
This time the leaking objects seem to show up as kmalloc-64.
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
266760 265333 99% 0.30K 10260 26 82080K kmemleak_object
157440 157440 100% 0.06K 2460 64 9840K kmalloc-64
94458 94458 100% 0.10K 2422 39 9688K buffer_head
27573 27573 100% 0.19K 1313 21 5252K dentry
kmemleak traces:
unreferenced object 0xffff88002f38ec80 (size 64):
comm "softirq", pid 0, jiffies 4294900815 (age 142.346s)
hex dump (first 32 bytes):
01 00 00 00 01 00 00 00 00 08 03 2e 00 88 ff ff ................
2b 6f a0 ca 28 b2 4a f1 0a 74 33 74 5a 76 18 cb +o..(.J..t3tZv..
backtrace:
[<ffffffff814da4e3>] kmemleak_alloc+0x21/0x3e
[<ffffffff810dc1f7>] kmem_cache_alloc+0xa5/0xb1
[<ffffffff81487bf5>] secpath_dup+0x1b/0x5a
[<ffffffff81487df9>] xfrm_input+0x64/0x484
[<ffffffff8147eec3>] xfrm4_rcv_encap+0x17/0x19
[<ffffffff8147eee4>] xfrm4_rcv+0x1f/0x21
[<ffffffff8143b4e4>] ip_local_deliver_finish+0x170/0x22a
[<ffffffff8143b6d6>] ip_local_deliver+0x46/0x78
[<ffffffff8143b35d>] ip_rcv_finish+0x295/0x2ac
[<ffffffff8143b936>] ip_rcv+0x22e/0x288
[<ffffffff8140a65d>] __netif_receive_skb+0x5ba/0x65a
[<ffffffff8140a898>] netif_receive_skb+0x47/0x78
[<ffffffff8140b4c3>] napi_skb_finish+0x21/0x54
[<ffffffff8140b5f3>] napi_gro_receive+0xfd/0x10a
[<ffffffff81372b47>] rtl8169_poll+0x326/0x4fc
[<ffffffff8140ad48>] net_rx_action+0x9f/0x188
unreferenced object 0xffff880029b47580 (size 64):
comm "softirq", pid 0, jiffies 4294926900 (age 143.946s)
hex dump (first 32 bytes):
01 00 00 00 01 00 00 00 00 88 07 2e 00 88 ff ff ................
00 00 00 00 2f 6f 72 67 2f 66 72 65 65 64 65 73 ..../org/freedes
backtrace:
[<ffffffff814da4e3>] kmemleak_alloc+0x21/0x3e
[<ffffffff810dc1f7>] kmem_cache_alloc+0xa5/0xb1
[<ffffffff81487bf5>] secpath_dup+0x1b/0x5a
[<ffffffff81487df9>] xfrm_input+0x64/0x484
[<ffffffff814bbd74>] xfrm6_rcv_spi+0x19/0x1b
[<ffffffff814bbd96>] xfrm6_rcv+0x20/0x22
[<ffffffff814960c7>] ip6_input_finish+0x203/0x31b
[<ffffffff81496546>] ip6_input+0x1e/0x50
[<ffffffff81496244>] ip6_rcv_finish+0x65/0x69
[<ffffffff814964c7>] ipv6_rcv+0x27f/0x2e0
[<ffffffff8140a65d>] __netif_receive_skb+0x5ba/0x65a
[<ffffffff8140a898>] netif_receive_skb+0x47/0x78
[<ffffffff8140b4c3>] napi_skb_finish+0x21/0x54
[<ffffffff8140b5f3>] napi_gro_receive+0xfd/0x10a
[<ffffffff81372b47>] rtl8169_poll+0x326/0x4fc
[<ffffffff8140ad48>] net_rx_action+0x9f/0x188
I've grepped for "/org/free" specifically and sure enough, same scraps
of data seem to be in some of the (varied) dumps there.
--
Mike Kazantsev // fraggod.net
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH for-3.7] vhost: fix mergeable bufs on BE hosts
From: David Miller @ 2012-10-21 23:24 UTC (permalink / raw)
To: mst; +Cc: netdev, stable, kvm, virtualization
In-Reply-To: <20121021124901.GA5315@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 21 Oct 2012 14:49:01 +0200
> On Mon, Oct 15, 2012 at 07:55:34PM +0200, Michael S. Tsirkin wrote:
>> We copy head count to a 16 bit field,
>> this works by chance on LE but on BE
>> guest gets 0. Fix it up.
>>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> Tested-by: Alexander Graf <agraf@suse.de>
>> Cc: stable@kernel.org
>
> Ping. Dave, could you apply this to -net please?
Pinging me but not cc:'ing me? That's really strange.
What if I operate by just mass deleting things that I'm
not explicitly on the To: or CC: when I'm very backlogged?
^ permalink raw reply
* Business Proposal
From: Wong Hui @ 2012-10-21 23:09 UTC (permalink / raw)
Please I would like you to keep this proposal as a top secret and delete it if you
are not interested and get back to me if you are interested for details as regards
to the transfer of $24,500,000 to you.
This money initially belongs to a Libyan client who died in the libya crisis and had no next of kin in his
account-opening package in my bank here in Hong kong where I am a bank director.
In other to achieve this, I shall require your full name, and telephone number to reach you.
Most importantly, a confirmation of acceptance from you will be needed after which I
shall furnish you with the full details of this transaction.
Yours Truly,
Wong Hui.
^ 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