Arm-dev

arm-dev@lists.centos.org

686 discussions

[PATCH 00/16] Integrate upstream patches for Cavium ThunderX I2C support
by Vadim Lomovtsev 18 Jan '17

18 Jan '17

This patch series integrates already accepted patches that provides: - support for Cavium ThunderX I2C; - bugfixes for Cavium Octeon I2C driver; Dmitry Bazhenov (2): i2c: octeon: Fix set SCL recovery function i2c: octeon: Avoid sending STOP during recovery Jan Glauber (14): i2c: octeon: Missing AAK flag in case of I2C_M_RECV_LEN i2c: octeon: Avoid printk after too long SMBUS message i2c: octeon: Rename driver to prepare for split i2c: octeon: Split the driver into two parts i2c: thunderx: Add i2c driver for ThunderX SOC i2c: thunderx: Add SMBUS alert support i2c: octeon,thunderx: Move register offsets to struct i2c: octeon: Sort include files alphabetically i2c: octeon: Use booleon values for booleon variables i2c: octeon: thunderx: Add MAINTAINERS entry i2c: octeon: Fix high-level controller status check i2c: octeon: thunderx: TWSI software reset in recovery i2c: octeon: thunderx: Remove double-check after interrupt i2c: octeon: thunderx: Limit register access retries MAINTAINERS | 8 + drivers/i2c/busses/Kconfig | 11 + drivers/i2c/busses/Makefile | 3 + drivers/i2c/busses/i2c-octeon-core.c | 791 +++++++++++++++++++ drivers/i2c/busses/i2c-octeon-core.h | 222 ++++++ drivers/i2c/busses/i2c-octeon-platdrv.c | 288 +++++++ drivers/i2c/busses/i2c-octeon.c | 1252 ------------------------------ drivers/i2c/busses/i2c-thunderx-pcidrv.c | 259 ++++++ 8 files changed, 1582 insertions(+), 1252 deletions(-) create mode 100644 drivers/i2c/busses/i2c-octeon-core.c create mode 100644 drivers/i2c/busses/i2c-octeon-core.h create mode 100644 drivers/i2c/busses/i2c-octeon-platdrv.c delete mode 100644 drivers/i2c/busses/i2c-octeon.c create mode 100644 drivers/i2c/busses/i2c-thunderx-pcidrv.c -- 2.4.11

3 18

Bananapi / Kernel 4.4.26-201
by Nicolas Repentin 17 Jan '17

17 Jan '17

Hi all, Simple question, is anyone have validated the kernel 4.4.26, on armv7hl repo, on bananapi ? Actually my bananapi is running fine on 4.2.3-200, and the new kernel have been installed, but, the pi is actually far away, and I need to be sure it will reboot :D :D Thanks

3 11

Status of release of CentOS 7.3 Aarch64 cloud image
by Daniel Askew 13 Jan '17

13 Jan '17

CentOS 7.3 cloud images for Aarch64 haven't been released yet (as far as I know). I have been checking this list and http://cloud.centos.org/altarch/7/images/aarch64/. Is there a (rough or not) timeframe for their release? Thanks

2 3

[PATCH] net: thunderx: acpi: fix LMAC initialization
by Vadim Lomovtsev 13 Jan '17

13 Jan '17

While probing BGX we requesting appropriate QLM for it's configuration and get LMAC count by that request. Then, while reading configured MAC values from SSDT table we need to save them in proper mapping: BGX[i]->lmac[j].mac = <MAC value> to later provide for initialization stuff. In order to fill such mapping properly we need to add lmac index to be used while acpi initialization since at this moment bgx->lmac_count already contains actual value. Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev(a)caviumnetworks.com> --- drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c index be30ad0..a3f4f83 100644 --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c @@ -47,8 +47,9 @@ struct lmac { struct bgx { u8 bgx_id; struct lmac lmac[MAX_LMAC_PER_BGX]; - int lmac_count; + u8 lmac_count; u8 max_lmac; + u8 acpi_lmac_idx; void __iomem *reg_base; struct pci_dev *pdev; bool is_dlm; @@ -1073,13 +1074,13 @@ static acpi_status bgx_acpi_register_phy(acpi_handle handle, if (acpi_bus_get_device(handle, &adev)) goto out; - acpi_get_mac_address(dev, adev, bgx->lmac[bgx->lmac_count].mac); + acpi_get_mac_address(dev, adev, bgx->lmac[bgx->acpi_lmac_idx].mac); - SET_NETDEV_DEV(&bgx->lmac[bgx->lmac_count].netdev, dev); + SET_NETDEV_DEV(&bgx->lmac[bgx->acpi_lmac_idx].netdev, dev); - bgx->lmac[bgx->lmac_count].lmacid = bgx->lmac_count; + bgx->lmac[bgx->acpi_lmac_idx].lmacid = bgx->acpi_lmac_idx; + bgx->acpi_lmac_idx++; /* move to next LMAC */ out: - bgx->lmac_count++; return AE_OK; } -- 1.8.3.1

1 1

Kernel for BananaPi R1 (Lamobo R1)
by arm_ml＠rirasoft.de 11 Jan '17

11 Jan '17

Hi there, I'm playing around with a BananaPi R1 (Lamobo R1). I want to setup a router with this board and try IPfire for this board or CentOS. The plain image CentOS-Userland-7-armv7hl-Minimal-1611-BananaPi.img.xz is working without Ethernet. There was a discussion in Februar 2016 on this list with a kernel 4.4.2-300.LR1.el7.armv7hl, but I can't find this rpm. Is there any updates / more Information to get this board working? thanks Andreas

2 1

Kernel update
by Nicolas Repentin 11 Jan '17

11 Jan '17

Hi all, I'm using the 7.3 release on my Bananapi. I still using kernel 4.2, and on the updates, I saw the 4.4.26. But, my /boot is quite little (~500MB), and I saw the update want to install the 4.4.12 too : ================================================================================================================================================================================ Package Architecture Version Dépôt Taille ================================================================================================================================================================================ Installation : kernel armv7hl 4.4.26-201.el7 centos-kernel 80 k kernel-core armv7hl 4.4.26-201.el7 centos-kernel 18 M kernel-modules armv7hl 4.4.26-201.el7 centos-kernel 11 M Installation pour dépendances : kernel-core armv7hl 4.4.12-301.el7 centos-kernel 18 M Résumé de la transaction ================================================================================================================================================================================ Installation 3 Paquets (+1 Paquet en dépendance) Is it normal? Is it gonna fit on my /boot? Actually quite used already by the running kernel: [root@atlas /]# df -h /boot/ Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/mmcblk0p1 477M 223M 231M 50% /boot Thanks

2 2

RPI3 and Gnome
by Paul R. Ganci 09 Jan '17

09 Jan '17

I am playing around with making a "desktop" workstation out of a Raspberry PI3 using the armv7hl CentOS. I have had no problems installing the OS and pretty much have everything working except a Gnome desktop. I did: > yum groupinstall "GNOME Desktop" and from what I can tell everything necessary is installed. However when I try to start X up I see it try and start, the display blinks as if everything is good and then drops back down to the console. The log file shown below shows a single error ([ 2665.952] (EE) AIGLX: reverting to software rendering). [ 2665.710] X.Org X Server 1.17.2 Release Date: 2015-06-16 [ 2665.725] X Protocol Version 11, Revision 0 [ 2665.731] Build Operating System: 4.5.7-fedora-4 [ 2665.736] Current Operating System: Linux centos-rpi3 4.4.33-v7.1.el7 #1 SMP Mon Nov 21 18:48:06 UTC 2016 armv7l [ 2665.736] Kernel command line: 8250.nr_uarts=0 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1872 bcm2708_fb.fbheight=1168 bcm2709.boardrev=0xa22082 bcm2709.serial=0x54bd9ed0 smsc95xx.macaddr=B8:27:EB:BD:9E:D0 bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p3 rootfstype=ext4 elevator=deadline rootwait selinux=1 security=selinux enforcing=0 [ 2665.756] Build Date: 09 November 2016 05:46:31PM [ 2665.763] Build ID: xorg-x11-server 1.17.2-22.el7 [ 2665.769] Current version of pixman: 0.34.0 [ 2665.783] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 2665.783] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 2665.812] (==) Log file: "/var/log/Xorg.1.log", Time: Sat Dec 31 20:08:58 2016 [ 2665.819] (==) Using config file: "/etc/X11/xorg.conf" [ 2665.827] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 2665.828] (==) ServerLayout "Default Layout" [ 2665.828] (**) |-->Screen "Screen0" (0) [ 2665.828] (**) | |-->Monitor "Monitor0" [ 2665.829] (**) | |-->Device "VideocoreIV" [ 2665.829] (**) |-->Input Device "Keyboard0" [ 2665.829] (==) Automatically adding devices [ 2665.829] (==) Automatically enabling devices [ 2665.830] (==) Automatically adding GPU devices [ 2665.830] (==) Max clients allowed: 256, resource mask: 0x1fffff [ 2665.830] (==) FontPath set to: catalogue:/etc/X11/fontpath.d, built-ins [ 2665.830] (==) ModulePath set to "/usr/lib/xorg/modules" [ 2665.830] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 2665.830] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. [ 2665.830] (WW) Disabling Keyboard0 [ 2665.830] (II) Loader magic: 0x54cf7004 [ 2665.830] (II) Module ABI versions: [ 2665.830] X.Org ANSI C Emulation: 0.4 [ 2665.830] X.Org Video Driver: 19.0 [ 2665.830] X.Org XInput driver : 21.0 [ 2665.830] X.Org Server Extension : 9.0 [ 2665.831] (II) no primary bus or device found [ 2665.831] (II) LoadModule: "glx" [ 2665.832] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 2665.855] (II) Module glx: vendor="X.Org Foundation" [ 2665.855] compiled for 1.17.2, module version = 1.0.0 [ 2665.855] ABI class: X.Org Server Extension, version 9.0 [ 2665.855] (==) AIGLX enabled [ 2665.855] (II) LoadModule: "fbdev" [ 2665.856] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [ 2665.857] (II) Module fbdev: vendor="X.Org Foundation" [ 2665.857] compiled for 1.17.2, module version = 0.4.3 [ 2665.857] Module class: X.Org Video Driver [ 2665.857] ABI class: X.Org Video Driver, version 19.0 [ 2665.857] (II) FBDEV: driver for framebuffer: fbdev [ 2665.857] (++) using VT number 1 [ 2665.857] (WW) Falling back to old probe method for fbdev [ 2665.857] (II) Loading sub module "fbdevhw" [ 2665.857] (II) LoadModule: "fbdevhw" [ 2665.858] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [ 2665.859] (II) Module fbdevhw: vendor="X.Org Foundation" [ 2665.859] compiled for 1.17.2, module version = 0.0.2 [ 2665.859] ABI class: X.Org Video Driver, version 19.0 [ 2665.859] (II) FBDEV(0): using default device [ 2665.859] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 2665.860] (**) FBDEV(0): Depth 24, (--) framebuffer bpp 32 [ 2665.860] (==) FBDEV(0): RGB weight 888 [ 2665.860] (==) FBDEV(0): Default visual is TrueColor [ 2665.860] (==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0) [ 2665.860] (II) FBDEV(0): hardware: BCM2708 FB (video memory: 8541kB) [ 2665.860] (II) FBDEV(0): checking modes against framebuffer device... [ 2665.860] (II) FBDEV(0): mode "1920x1200" not found [ 2665.860] (II) FBDEV(0): mode "1600x1200" ok [ 2665.860] (II) FBDEV(0): mode "1280x1024" ok [ 2665.860] (II) FBDEV(0): mode "1152x864" ok [ 2665.860] (II) FBDEV(0): mode "1024x768" ok [ 2665.861] (II) FBDEV(0): mode "800x600" ok [ 2665.861] (II) FBDEV(0): mode "720x400" ok [ 2665.861] (II) FBDEV(0): mode "640x480" ok [ 2665.861] (II) FBDEV(0): checking modes against monitor... [ 2665.861] (--) FBDEV(0): Virtual size is 1600x1200 (pitch 1600) [ 2665.861] (**) FBDEV(0): Default mode "1600x1200": 162.0 MHz (scaled from 0.0 MHz), 75.0 kHz, 60.0 Hz [ 2665.861] (II) FBDEV(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz d) [ 2665.861] (**) FBDEV(0): Default mode "1280x1024": 108.0 MHz (scaled from 0.0 MHz), 64.0 kHz, 60.0 Hz [ 2665.861] (II) FBDEV(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz d) [ 2665.861] (**) FBDEV(0): Default mode "1152x864": 108.0 MHz (scaled from 0.0 MHz), 67.5 kHz, 75.0 Hz [ 2665.861] (II) FBDEV(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz d) [ 2665.861] (**) FBDEV(0): Default mode "1024x768": 65.0 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz [ 2665.861] (II) FBDEV(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz d) [ 2665.861] (**) FBDEV(0): Default mode "800x600": 36.0 MHz (scaled from 0.0 MHz), 35.2 kHz, 56.2 Hz [ 2665.861] (II) FBDEV(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz d) [ 2665.862] (**) FBDEV(0): Default mode "640x480": 25.2 MHz (scaled from 0.0 MHz), 31.5 kHz, 59.9 Hz [ 2665.862] (II) FBDEV(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz d) [ 2665.862] (**) FBDEV(0): Display dimensions: (518, 324) mm [ 2665.862] (**) FBDEV(0): DPI set to (78, 94) [ 2665.862] (II) Loading sub module "fb" [ 2665.862] (II) LoadModule: "fb" [ 2665.863] (II) Loading /usr/lib/xorg/modules/libfb.so [ 2665.864] (II) Module fb: vendor="X.Org Foundation" [ 2665.864] compiled for 1.17.2, module version = 1.0.0 [ 2665.865] ABI class: X.Org ANSI C Emulation, version 0.4 [ 2665.865] (**) FBDEV(0): using shadow framebuffer [ 2665.865] (II) Loading sub module "shadow" [ 2665.865] (II) LoadModule: "shadow" [ 2665.865] (II) Loading /usr/lib/xorg/modules/libshadow.so [ 2665.865] (II) Module shadow: vendor="X.Org Foundation" [ 2665.865] compiled for 1.17.2, module version = 1.1.0 [ 2665.866] ABI class: X.Org ANSI C Emulation, version 0.4 [ 2665.866] (==) Depth 24 pixmap format is 32 bpp [ 2665.892] (==) FBDEV(0): Backing store enabled [ 2665.894] (**) FBDEV(0): DPMS enabled [ 2665.894] (==) RandR enabled [ 2665.945] (II) SELinux: Disabled by boolean [ 2665.952] (II) AIGLX: Screen 0 is not DRI2 capable [ 2665.952] (EE) AIGLX: reverting to software rendering [ 2665.998] (II) AIGLX: Loaded and initialized swrast [ 2665.998] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 2666.260] (II) config/udev: Adding input device CM Storm QuickFire Rapid keyboard (/dev/input/event0) [ 2666.260] (**) CM Storm QuickFire Rapid keyboard: Applying InputClass "evdev keyboard catchall" [ 2666.260] (II) LoadModule: "evdev" [ 2666.261] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [ 2666.263] (II) Module evdev: vendor="X.Org Foundation" [ 2666.263] compiled for 1.17.2, module version = 2.9.2 [ 2666.264] Module class: X.Org XInput Driver [ 2666.264] ABI class: X.Org XInput driver, version 21.0 [ 2666.264] (II) Using input driver 'evdev' for 'CM Storm QuickFire Rapid keyboard' [ 2666.264] (**) CM Storm QuickFire Rapid keyboard: always reports core events [ 2666.264] (**) evdev: CM Storm QuickFire Rapid keyboard: Device: "/dev/input/event0" [ 2666.264] (--) evdev: CM Storm QuickFire Rapid keyboard: Vendor 0x2516 Product 0x4 [ 2666.265] (--) evdev: CM Storm QuickFire Rapid keyboard: Found keys [ 2666.265] (II) evdev: CM Storm QuickFire Rapid keyboard: Configuring as keyboard [ 2666.265] (**) Option "config_info" "udev:/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/0003:2516:0004.000E/input/input13/event0" [ 2666.265] (II) XINPUT: Adding extended input device "CM Storm QuickFire Rapid keyboard" (type: KEYBOARD, id 6) [ 2666.265] (**) Option "xkb_rules" "evdev" [ 2666.270] (II) config/udev: Adding input device CM Storm QuickFire Rapid keyboard (/dev/input/event1) [ 2666.270] (**) CM Storm QuickFire Rapid keyboard: Applying InputClass "evdev keyboard catchall" [ 2666.270] (II) Using input driver 'evdev' for 'CM Storm QuickFire Rapid keyboard' [ 2666.270] (**) CM Storm QuickFire Rapid keyboard: always reports core events [ 2666.270] (**) evdev: CM Storm QuickFire Rapid keyboard: Device: "/dev/input/event1" [ 2666.271] (--) evdev: CM Storm QuickFire Rapid keyboard: Vendor 0x2516 Product 0x4 [ 2666.271] (--) evdev: CM Storm QuickFire Rapid keyboard: Found keys [ 2666.271] (II) evdev: CM Storm QuickFire Rapid keyboard: Configuring as keyboard [ 2666.271] (**) Option "config_info" "udev:/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.1/0003:2516:0004.000F/input/input14/event1" [ 2666.271] (II) XINPUT: Adding extended input device "CM Storm QuickFire Rapid keyboard" (type: KEYBOARD, id 7) [ 2666.271] (**) Option "xkb_rules" "evdev" [ 2666.623] (II) evdev: CM Storm QuickFire Rapid keyboard: Close [ 2666.623] (II) UnloadModule: "evdev" [ 2666.623] (II) evdev: CM Storm QuickFire Rapid keyboard: Close [ 2666.623] (II) UnloadModule: "evdev" [ 2666.703] (II) Server terminated successfully (0). Closing log file. I used this /etc.X11/xorg.conf: Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection Section "Device" Identifier "VideocoreIV" VendorName "Broadcom" BoardName "RPI3Graphics" Driver "fbdev" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Dell" ModelName "Ultrasharp U2410" DisplaySize 518 324 HorizSync 30.0 - 81.0 VertRefresh 56.0 - 75.0 Option "DPMS" EndSection Section "Screen" Identifier "Screen0" Device "VideocoreIV" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "1920x1200" "1600x1200" "1280x1024" "1152x864" "1024x768" "800x600" "720x400" "640x480" EndSubSection EndSection Does anybody see what I am doing wrong? Like I said it looks like the desktop wants to startup but then just crashes. Thanks for your help. -- Paul (ganci(a)nurdog.com) Cell: (303)257-5208

2 3

Release for CentOS 7.3.1611 on ARM64/AArch64
by Jim Perrin 06 Jan '17

06 Jan '17

I am pleased to announce the general availability of CentOS Linux 7 (1611) for AArch64/ARM64 machines. == Changes The kernel has been rebased from 4.2.0 to 4.5.0, and includes several patches recently merged into the upstream. The kernel patches and modifications can be found at https://git.centos.org/summary/sig-altarch!kernel.git in the sig-altarch7-aarch64 branch. == Download You can download new images and isos via http://mirror.centos.org/altarch/7/isos/aarch64/ Images and sha256sums: 1513f5325accfd32ac7973a9b24e401c829ece24da78e24d021e507e877f930e CentOS-7-aarch64-Everything.iso f7ae6bae6c2cc177134d7f8f3808e0f457537c4cd48a119620f50d18ff7bb908 CentOS-7-aarch64.img.xz 48776338f8c8994a9499f07e3af847253cf7235c6aac635a8418a2028ec675cf CentOS-7-aarch64-NetInstall.iso f7ae6bae6c2cc177134d7f8f3808e0f457537c4cd48a119620f50d18ff7bb908 CentOS-7-aarch64-rolling.img.xz 238b1ebf22a0ff894064e6ed2ac35ee02a6503657a40ad51f2eee7afc8229e75 CentOS-7-aarch64-rootfs-7.3.1611.tar.xz == Known Issues 1. Mustang based boards must be on the most recent firmware version, otherwise the network may lose connectivity when using 4.5.0-19+ based kernels. Please ensure your hardware is running the most recent firmware available to avoid network issues. 2. Merlin based boards should be on the most recent firmware version, in order to take full advantage of recent kernel improvements. 3. Some ThunderX based boards have been reported to have MAC address inconsistency when using older firmware versions. Please make sure you have the most recent firmware applied to your hardware to avoid network issues. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

3 5

Fwd: Golang Performance
by Gordan Bobic 06 Jan '17

06 Jan '17

The --cpuprofile option doesn't seem to generate a human-readable file and my go-fu is weak, but I've attached it anyway. On Tue, Jan 3, 2017 at 9:18 PM, Jeremy Linton <jlinton(a)redhat.com> wrote: > Hi, > > On 01/01/2017 11:57 AM, Gordan Bobic wrote: > >> I'm not much of a Go user at the best of times, but I am noticing that >> there seems to be a huge ( > 10x clock-for-clock) performance >> discrepancy between x86-64 and aarch64 binaries. >> >> Specific example I am looking at is rclone, uploading encryoted backups >> to Amazon Cloud Drive. >> >> When I run it on a Westmere class Xeon (3.6GHz), it is comsuming about >> 2% CPU to saturate a 20Mbit uplink. When I run it on an X-Gene (2.0GHz), >> it is consuming about 50% CPU. Even adjusting for differences in clock >> speeds, this seems to be a huge difference. >> >> Is the Go complier known to produce very poor results on aarch64, or is >> something else in play? I know that x86-64 has a much more powerful SIMD >> unit, but I am not convinced that this is the explanation, and rclone >> doesn't use AES AFAIK, so hardware implementation of that doesn't seem >> to explain it either. >> > > AFAIK, amazon drive uses SSL/TLS so its likely you are using AES. Further, > go implements their own TLS/etc libraries rather than depending on > openSSL/gnuTLS. So, while ARMv8 cores have hardware AES instructions, go's > AES implementation is currently only hardware accelerated on x86 and s390. > MD5 (also used AFAIK) is also missing an ARM64 native implementation even > though there is an ARM one. So, just those two issues could cause a large > performance delta, but at those data rates it seems possible there is > something else going on. > > So, a couple questions, did you build rclone yourself or use one of the > binaries from rclone.org? > > There is a --cpuprofile option to rclone. It might be helpful if you can > post the output from that. > > Thanks, > > > >> At general purpose pointer chasing such as compiling, the X-Gene seems >> to produce similar performance clock-for-clock as the Westmere Xeon, so >> the large discrepancy with rclone seems odd. >> >> Has anyone got any insights? Both machines are running CentOS 7. >> >> Gordan >> >> >> _______________________________________________ >> Arm-dev mailing list >> Arm-dev(a)centos.org >> https://lists.centos.org/mailman/listinfo/arm-dev >> >> > _______________________________________________ > Arm-dev mailing list > Arm-dev(a)centos.org > https://lists.centos.org/mailman/listinfo/arm-dev >

2 1

[PATCH] PCI/ASPM: Don't retrain link if ASPM not possible.
by Vadim Lomovtsev 05 Jan '17

05 Jan '17

From: David Daney <david.daney(a)cavium.com> Some (defective) PCIe devices are not able to reliably do link retraining. Check to see if ASPM is possible between link partners before configuring common clocking, and doing the resulting link retraining. If ASPM is not possible, there is no reason to risk losing access to a device due to an unnecessary link retraining. Signed-off-by: David Daney <david.daney(a)cavium.com> Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev(a)caviumnetworks.com> --- drivers/pci/pcie/aspm.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c index 2dfe7fd..abad79e 100644 --- a/drivers/pci/pcie/aspm.c +++ b/drivers/pci/pcie/aspm.c @@ -351,12 +351,26 @@ static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist) return; } + /* Get upstream/downstream components' register state */ + pcie_get_aspm_reg(parent, &upreg); + child = list_entry(linkbus->devices.next, struct pci_dev, bus_list); + pcie_get_aspm_reg(child, &dwreg); + + /* + * If ASPM not supported, don't mess with the clocks and link, + * bail out now. + */ + if (!(upreg.support & dwreg.support)) + return; + /* Configure common clock before checking latencies */ pcie_aspm_configure_common_clock(link); - /* Get upstream/downstream components' register state */ + /* + * Re-read upstream/downstream components' register state + * after clock configuration + */ pcie_get_aspm_reg(parent, &upreg); - child = list_entry(linkbus->devices.next, struct pci_dev, bus_list); pcie_get_aspm_reg(child, &dwreg); /* -- 2.5.5

2 2

← Newer
1
...
33
34
35
36
37
38
39
...
69
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Arm-dev