From owner-freebsd-arm@FreeBSD.ORG Sun Aug 31 09:28:36 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C32706F4; Sun, 31 Aug 2014 09:28:36 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DAE11E24; Sun, 31 Aug 2014 09:28:36 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 4D24925D3A85; Sun, 31 Aug 2014 09:28:33 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 1F543C770B1; Sun, 31 Aug 2014 09:28:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id GIHzCC5WSRuG; Sun, 31 Aug 2014 09:28:29 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:f973:5b8d:9a90:cf0f] (unknown [IPv6:fde9:577b:c1a9:4410:f973:5b8d:9a90:cf0f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C7DFBC770B0; Sun, 31 Aug 2014 09:28:27 +0000 (UTC) From: "Bjoern A. Zeeb" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: ARM IMX6 build failure Date: Sun, 31 Aug 2014 09:28:10 +0000 Message-Id: <6B1B2203-C20E-4E98-B93D-D0368839544B@lists.zabbadoz.net> To: freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Cc: current@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 09:28:36 -0000 linking kernel.debug locore.o: In function `virt_done': (.text+0x130): undefined reference to `initarm' uart_core.o: In function `uart_bus_probe': /scratch/tmp/bz/head.svn/sys/dev/uart/uart_core.c:381: undefined = reference to `uart_cpu_eqres' uart_subr.o: In function `uart_getenv': /scratch/tmp/bz/head.svn/sys/dev/uart/uart_subr.c:307: undefined = reference to `uart_bus_space_mem' /scratch/tmp/bz/head.svn/sys/dev/uart/uart_subr.c:307: undefined = reference to `uart_bus_space_io' uart_tty.o: In function `uart_cnprobe': /scratch/tmp/bz/head.svn/sys/dev/uart/uart_tty.c:72: undefined reference = to `uart_cpu_getdev' machdep.o: In function `set_stackptrs': /scratch/tmp/bz/head.svn/sys/arm/arm/machdep.c:1006: undefined reference = to `irqstack' /scratch/tmp/bz/head.svn/sys/arm/arm/machdep.c:1006: undefined reference = to `abtstack' /scratch/tmp/bz/head.svn/sys/arm/arm/machdep.c:1006: undefined reference = to `undstack' mp_machdep.o: In function `init_secondary': /scratch/tmp/bz/head.svn/sys/arm/arm/mp_machdep.c:257: undefined = reference to `pmap_pa' pmap-v6.o: In function `pmap_enter_locked': /scratch/tmp/bz/head.svn/sys/arm/arm/pmap-v6.c:3085: undefined reference = to `systempage' pmap-v6.o: In function `pmap_pinit': /scratch/tmp/bz/head.svn/sys/arm/arm/pmap-v6.c:3506: undefined reference = to `systempage' gic.o: In function `arm_gic_probe': /scratch/tmp/bz/head.svn/sys/arm/arm/gic.c:134: undefined reference to = `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/arm/arm/gic.c:137: undefined reference to = `ofw_bus_is_compatible' pl310.o: In function `pl310_probe': /scratch/tmp/bz/head.svn/sys/arm/arm/pl310.c:423: undefined reference to = `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/arm/arm/pl310.c:426: undefined reference to = `ofw_bus_is_compatible' mpcore_timer.o: In function `arm_tmr_probe': /scratch/tmp/bz/head.svn/sys/arm/arm/mpcore_timer.c:257: undefined = reference to `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/arm/arm/mpcore_timer.c:260: undefined = reference to `ofw_bus_is_compatible=92 mpcore_timer.o: In function `arm_tmr_probe': /scratch/tmp/bz/head.svn/sys/arm/arm/mpcore_timer.c:257: undefined = reference to `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/arm/arm/mpcore_timer.c:260: undefined = reference to `ofw_bus_is_compatible' mpcore_timer.o: In function `arm_tmr_attach': /scratch/tmp/bz/head.svn/sys/arm/arm/mpcore_timer.c:298: undefined = reference to `OF_getencprop' /scratch/tmp/bz/head.svn/sys/arm/arm/mpcore_timer.c:366: undefined = reference to `ofw_bus_get_node_desc' fsl_ocotp.o: In function `fsl_ocotp_devmap': /scratch/tmp/bz/head.svn/sys/arm/freescale/fsl_ocotp.c:73: undefined = reference to `OF_finddevice' /scratch/tmp/bz/head.svn/sys/arm/freescale/fsl_ocotp.c:75: undefined = reference to `fdt_depth_search_compatible' /scratch/tmp/bz/head.svn/sys/arm/freescale/fsl_ocotp.c:77: undefined = reference to `fdt_regsize' fsl_ocotp.o: In function `ocotp_probe': /scratch/tmp/bz/head.svn/sys/arm/freescale/fsl_ocotp.c:151: undefined = reference to `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/arm/freescale/fsl_ocotp.c:154: undefined = reference to `ofw_bus_is_compatible' imx6_anatop.o: In function `imx6_anatop_probe': /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx6_anatop.c:678: = undefined reference to `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx6_anatop.c:681: = undefined reference to `ofw_bus_is_compatible' imx6_ccm.o: In function `ccm_probe': /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx6_ccm.c:147: undefined = reference to `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx6_ccm.c:150: undefined = reference to `ofw_bus_is_compatible' imx_gpt.o: In function `imx_gpt_probe': /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx_gpt.c:124: undefined = reference to `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx_gpt.c:127: undefined = reference to `ofw_bus_search_compatible' imx_gpio.o: In function `imx51_gpio_probe': /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx_gpio.c:380: undefined = reference to `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx_gpio.c:383: undefined = reference to `ofw_bus_search_compatible' imx_i2c.o: In function `i2c_probe': /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx_i2c.c:233: undefined = reference to `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx_i2c.c:236: undefined = reference to `ofw_bus_search_compatible' imx_i2c.o: In function `i2c_get_node': /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx_i2c.c:151: undefined = reference to `ofw_bus_get_node_desc' imx_i2c.o:(.rodata+0x10): undefined reference to `ofw_bus_get_node_desc' imx_sdhci.o: In function `imx_sdhci_probe': /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx_sdhci.c:772: = undefined reference to `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx_sdhci.c:775: = undefined reference to `ofw_bus_search_compatible' imx_sdhci.o: In function `imx_sdhci_attach': /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx_sdhci.c:672: = undefined reference to `ofw_bus_search_compatible' /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx_sdhci.c:740: = undefined reference to `OF_hasprop' /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx_sdhci.c:742: = undefined reference to `OF_hasprop' /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx_sdhci.c:674: = undefined reference to `ofw_bus_get_node_desc' if_ffec.o: In function `ffec_probe': /scratch/tmp/bz/head.svn/sys/dev/ffec/if_ffec.c:1717: undefined = reference to `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/dev/ffec/if_ffec.c:1720: undefined = reference to `ofw_bus_search_compatible' if_ffec.o: In function `ffec_attach': /scratch/tmp/bz/head.svn/sys/dev/ffec/if_ffec.c:1434: undefined = reference to `ofw_bus_search_compatible' /scratch/tmp/bz/head.svn/sys/dev/ffec/if_ffec.c:1445: undefined = reference to `OF_searchprop' /scratch/tmp/bz/head.svn/sys/dev/ffec/if_ffec.c:1658: undefined = reference to `OF_hasprop' /scratch/tmp/bz/head.svn/sys/dev/ffec/if_ffec.c:1701: undefined = reference to `ofw_bus_get_node_desc' ehci_imx.o: In function `imx_ehci_probe': /scratch/tmp/bz/head.svn/sys/dev/usb/controller/ehci_imx.c:164: = undefined reference to `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/dev/usb/controller/ehci_imx.c:167: = undefined reference to `ofw_bus_search_compatible' imx6_usbphy.o: In function `usbphy_probe': /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx6_usbphy.c:163: = undefined reference to `ofw_bus_status_okay' /scratch/tmp/bz/head.svn/sys/arm/freescale/imx/imx6_usbphy.c:166: = undefined reference to `ofw_bus_is_compatible' --- kernel.debug --- *** [kernel.debug] Error code 1 bmake: stopped in = /storage/head/obj/arm.armv6/scratch/tmp/bz/head.svn/sys/IMX6 =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-arm@FreeBSD.ORG Sun Aug 31 12:57:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A198E75C for ; Sun, 31 Aug 2014 12:57:52 +0000 (UTC) Received: from poczta.toomeek.waw.pl (unknown [IPv6:2001:67c:232c:1000::fd9b:4fb4]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0251310 for ; Sun, 31 Aug 2014 12:57:51 +0000 (UTC) Received: from [192.168.137.1] (dmp75.neoplus.adsl.tpnet.pl [83.24.71.75]) by poczta.toomeek.waw.pl (Postfix) with ESMTPSA id 6CA35C601AC for ; Sun, 31 Aug 2014 08:57:47 -0400 (EDT) Message-ID: <54031BC8.8020407@toomeek.waw.pl> Date: Sun, 31 Aug 2014 14:57:44 +0200 From: TooMeeK Admin User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: Re: U-boot for Banana Pi References: <53EE0F93.6060407@toomeek.waw.pl> <53EE23B1.2020403@toomeek.waw.pl> <53EE402D.8000204@toomeek.waw.pl> <20140815214416.GJ60808@cicely7.cicely.de> <53EFCD6C.5000601@toomeek.waw.pl> <53EFD5D5.7010406@toomeek.waw.pl> <53F0E640.5030506@toomeek.waw.pl> <53F14BD7.1050007@fukaumi.org> <53F1A126.1020408@toomeek.waw.pl> <53F1D8FD.9010903@fukaumi.org> <53F27EB9.3090805@toomeek.waw.pl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.9 (poczta.toomeek.waw.pl [0.0.0.0]); Sun, 31 Aug 2014 08:57:49 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.98.4 at a8d2ba546e X-Virus-Status: Clean X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 12:57:52 -0000 Thank You for response, and very sorry for long feedback (very busy week). Ok.. so once again.. gpart add -b 1m -s 24m -t '\!12' md0 returns invalid command. So replaced with: gpart add -b 1m -s 64m -t fat16 md0 root@freebsd:~/cubie # cat prepare_wiki.sh #!/bin/bash #force unmount if mounted umount /mnt mdconfig -d -u0 sysctl kern.geom.debugflags=16 cd /root/cubie rm /root/cubie/cubie_boot.img truncate -s 940M cubie_boot.img mdconfig -f cubie_boot.img -u0 gpart create -s mbr md0 gpart add -b 1m -s 64m -t fat16 md0 gpart set -a active -i 1 md0 newfs_msdos -L boot -F 16 /dev/md0s1 newfs_msdos -L boot -F 16 /dev/md0s1 mount_msdosfs /dev/md0s1 /mnt cp /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2/kernel /mnt cd /usr/src/sunxi-tools echo "fatload mmc 0 0x40200000 kernel; go 0x40200100" > boot.cmd /usr/src/u-boot-bananapi/tools/mkimage -C none -A arm -T script -d boot.cmd boot.scr cp boot.scr /mnt umount /mnt mdconfig -d -u0 cd /root/cubie # Cubieboard's 2 U-boot loader dd if=sunxi-spl.bin conv=notrunc of=cubie_boot.img bs=1024 seek=8 dd if=u-boot.bin conv=notrunc of=cubie_boot.img bs=1024 seek=32 Done on not fully updated OS: pkg update .... FreeBSD repository update completed. 23409 packages processed: 9710 updated, 91 removed and 117 added. ... The following 29 packages will be affected (of 0 checked): New packages to be INSTALLED: compat9x-amd64: 9.2.902000.201310 plexmediaserver-plexpass: 0.9.9.16.555 gcc5: 5.0.s20140824 Installed packages to be UPGRADED: python27: 2.7.8_2 -> 2.7.8_4 pcre: 8.34_2 -> 8.35 git: 2.0.2 -> 2.1.0 p5-Socket: 2.014 -> 2.015 rubygem-pkg-config: 1.1.4 -> 1.1.5 bash: 4.3.22 -> 4.3.24 i386-wine-devel: 1.7.23,1 -> 1.7.24,1 Installed packages to be REINSTALLED: wget-1.15_1 (needed shared library changed) gettext-0.18.3.1_1 (needed shared library changed) perl5-5.16.3_11 (needed shared library changed) aspell-0.60.6.1_5 (needed shared library changed) libxcb-1.10_2 (needed shared library changed) libX11-1.6.2_2,1 (needed shared library changed) libXext-1.3.2_2,1 (needed shared library changed) libxml2-2.9.1_1 (needed shared library changed) mpfr-3.1.2_2 (needed shared library changed) mpc-1.0.2 (needed shared library changed) arm-eabi-gcc-4.5.4_1 (needed shared library changed) expat-2.1.0_1 (needed shared library changed) binutils-2.24 (needed shared library changed) libidn-1.28_1 (needed shared library changed) isl-0.13 (needed shared library changed) cloog-0.18.1_3 (needed shared library changed) libiconv-1.14_3 (needed shared library changed) gmake-3.82_1 (needed shared library changed) gsed-4.2.2 (needed shared library changed) Result - 512MB of RAM available.. U-Boot 2013.07-07794-gc0f3b94 (Aug 15 2013 - 18:01:45) Allwinner Technology CPU: Allwinner A20 (SUN7I) Board: Cubieboard2 I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: emac Hit any key to stop autoboot: 3  2  1  0 reading uEnv.txt ** Unable to read file uEnv.txt ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** reading boot.scr 119 bytes read in 3 ms (38.1 KiB/s) Jumping to boot.scr ## Executing script at 44000000 reading kernel 4757950 bytes read in 416 ms (10.9 MiB/s) ## Starting application at 0x40200100 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-RELEASE #2: Sun Aug 31 14:28:22 CEST 2014 root@freebsd:/usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2 arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: Cortex A7 rev 4 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:2 Cache level 1: 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 2-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WB Read-Alloc Write-Alloc real memory = 536870912 (512 MB) avail memory = 517623808 (493 MB) random device not loaded; using insecure entropy random: initialized simplebus0: on fdtbus0 gic0: mem 0x1c81000-0x1c81fff,0x1c82000-0x1c820ff on simplebus0 gic0: pn 0x10, arch 0x2, rev 0x1, implementer 0x43b nirqs 160 a20_cpu_cfg0: mem 0x1c25c00-0x1c25fff on simplebus0 a10_ccm0: mem 0x1c20000-0x1c203ff on simplebus0 a10_timer0: mem 0x1c20c00-0x1c20c8f irq 54 on simplebus0 Event timer "a10_timer Eventtimer" frequency 24000000 Hz quality 1000 Timecounter "a10_timer timer0" frequency 24000000 Hz quality 1000 a10wd0: mem 0x1c20c90-0x1c20c9f on simplebus0 gpio0: mem 0x1c20800-0x1c20bff irq 60 on simplebus0 gpioc0: on gpio0 gpiobus0: on gpio0 ehci0: mem 0x1c14000-0x1c14fff irq 71 on simplebus0 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci1: mem 0x1c1c000-0x1c1cfff irq 72 on simplebus0 usbus1: EHCI version 1.0 usbus1 on ehci1 uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 33 on simplebus0 uart0: console (115200,n,8,1) Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 random: unblocking device. WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus1 usbus0 uhub1: 1 port with 1 removable, self powered uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 Trying to mount root from ufs:/dev/da0s2 []... mountroot: waiting for device /dev/da0s2 ... Mounting from ufs:/dev/da0s2 failed with error 19. What is in Your /usr/src/sys/boot/fdt/dts/cubieboard2.dts file, section memory? Best regards, TooMeeK W dniu 2014-08-27 14:53, Ganbold Tsagaankhuu pisze: > > > > I've just got Banana PI today, and I confirm that Cubieboard2 kernel > works just fine detecting 1GB RAM and booting to multi user mode. I > run recent Current of course. > > Ganbold > > From owner-freebsd-arm@FreeBSD.ORG Sun Aug 31 16:10:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72520C61 for ; Sun, 31 Aug 2014 16:10:21 +0000 (UTC) Received: from poczta.toomeek.waw.pl (unknown [IPv6:2001:67c:232c:1000::fd9b:4fb4]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA701838 for ; Sun, 31 Aug 2014 16:10:20 +0000 (UTC) Received: from [10.20.20.49] (dmp75.neoplus.adsl.tpnet.pl [83.24.71.75]) by poczta.toomeek.waw.pl (Postfix) with ESMTPSA id 6374CC60AB7 for ; Sun, 31 Aug 2014 12:10:09 -0400 (EDT) Message-ID: <540348DD.3090406@toomeek.waw.pl> Date: Sun, 31 Aug 2014 18:10:05 +0200 From: TooMeeK Admin User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: U-boot for Banana Pi References: <53EE0F93.6060407@toomeek.waw.pl> <53EE23B1.2020403@toomeek.waw.pl> <53EE402D.8000204@toomeek.waw.pl> <20140815214416.GJ60808@cicely7.cicely.de> <53EFCD6C.5000601@toomeek.waw.pl> <53EFD5D5.7010406@toomeek.waw.pl> <53F0E640.5030506@toomeek.waw.pl> <53F14BD7.1050007@fukaumi.org> <53F1A126.1020408@toomeek.waw.pl> <53F1D8FD.9010903@fukaumi.org> <53F27EB9.3090805@toomeek.waw.pl> <54031BC8.8020407@toomeek.waw.pl> In-Reply-To: <54031BC8.8020407@toomeek.waw.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.9 (poczta.toomeek.waw.pl [0.0.0.0]); Sun, 31 Aug 2014 12:10:11 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.98.4 at a8d2ba546e X-Virus-Status: Clean X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 16:10:21 -0000 Reinstalled FreeBSD 10 64-bit from scratch.. fully updated.. /usr/src/sys/boot/fdt/dts/cubieboard2.dts contains 512MB addressing, so it cannot be right.. The same at: ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.0-RELEASE/src.txz They are simply - outdated. Wiki page doesn't say where sources are, just: "1. Get FreeBSD head" So what sources You're using to build Cubieboard2 kernel? But anyway I found answer here: https://lists.freebsd.org/pipermail/freebsd-arm/2013-August/006201.html and changed Banana Pi files accordinately: file: a10_machdep.c change at: initarm_late_init adding: unmapped_buf_allowed = 0; I'm running 1GB of memory now. But no networking, no HDMI output. Added 1Gbit GMAC driver to BANANAPI config and /boot/loader.conf: miibus_load="YES" if_gem_load="YES" but still getting only lo0. Login prompt works. So.. how You did it working, Ganbold ? Best regards, TooMeeK > > What is in Your /usr/src/sys/boot/fdt/dts/cubieboard2.dts file, > section memory? > > Best regards, > TooMeeK > > W dniu 2014-08-27 14:53, Ganbold Tsagaankhuu pisze: >> >> >> >> I've just got Banana PI today, and I confirm that Cubieboard2 kernel >> works just fine detecting 1GB RAM and booting to multi user mode. I >> run recent Current of course. >> >> Ganbold >> >> > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Sun Aug 31 16:20:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 288CFF38 for ; Sun, 31 Aug 2014 16:20:08 +0000 (UTC) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B13AA191F for ; Sun, 31 Aug 2014 16:20:07 +0000 (UTC) Received: from asc-t60.schwarzes.net (p5B0313E2.dip0.t-ipconnect.de [91.3.19.226]) (authenticated bits=0) by olinguito.schwarzes.net (8.14.8/8.14.8) with ESMTP id s7VGK1bA072169; Sun, 31 Aug 2014 18:20:01 +0200 (CEST) (envelope-from Andreas.Schwarz@schwarzes.net) Date: Sun, 31 Aug 2014 18:20:01 +0200 (CEST) From: Andreas Schwarz To: TooMeeK Admin Subject: Re: U-boot for Banana Pi Message-Id: <20140831181954.499135cfbffb3266d7ce69ab@schwarzes.net> In-Reply-To: <540348DD.3090406@toomeek.waw.pl> References: <53EE0F93.6060407@toomeek.waw.pl> <53EE23B1.2020403@toomeek.waw.pl> <53EE402D.8000204@toomeek.waw.pl> <20140815214416.GJ60808@cicely7.cicely.de> <53EFCD6C.5000601@toomeek.waw.pl> <53EFD5D5.7010406@toomeek.waw.pl> <53F0E640.5030506@toomeek.waw.pl> <53F14BD7.1050007@fukaumi.org> <53F1A126.1020408@toomeek.waw.pl> <53F1D8FD.9010903@fukaumi.org> <53F27EB9.3090805@toomeek.waw.pl> <54031BC8.8020407@toomeek.waw.pl> <540348DD.3090406@toomeek.waw.pl> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Sun, 31 Aug 2014 18:20:02 +0200 (CEST) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 16:20:08 -0000 On Sun, 31 Aug 2014 18:10:05 +0200 TooMeeK Admin wrote: > Reinstalled FreeBSD 10 64-bit from scratch.. fully updated.. > /usr/src/sys/boot/fdt/dts/cubieboard2.dts contains 512MB addressing, so > it cannot be right.. > The same at: > ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.0-RELEASE/src.txz > They are simply - outdated. > > Wiki page doesn't say where sources are, just: > "1. Get FreeBSD head" > So what sources You're using to build Cubieboard2 kernel? The simplest way to get head is to use svn (or the included svnlite). initial : svnlite checkout http://svn.freebsd.org/base/head /usr/src (change protocol and path if needed) update : cd /usr/src svnlite update -- best regards Andreas From owner-freebsd-arm@FreeBSD.ORG Sun Aug 31 18:29:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D12D03BF for ; Sun, 31 Aug 2014 18:29:11 +0000 (UTC) Received: from poczta.toomeek.waw.pl (unknown [IPv6:2001:67c:232c:1000::fd9b:4fb4]) by mx1.freebsd.org (Postfix) with ESMTP id 88ADD18A7 for ; Sun, 31 Aug 2014 18:29:11 +0000 (UTC) Received: from [192.168.137.1] (dmp75.neoplus.adsl.tpnet.pl [83.24.71.75]) by poczta.toomeek.waw.pl (Postfix) with ESMTPSA id 59F4BC601AC for ; Sun, 31 Aug 2014 14:29:06 -0400 (EDT) Message-ID: <54036970.9040503@toomeek.waw.pl> Date: Sun, 31 Aug 2014 20:29:04 +0200 From: TooMeeK Admin User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: U-boot for Banana Pi References: <53EE0F93.6060407@toomeek.waw.pl> <53EE23B1.2020403@toomeek.waw.pl> <53EE402D.8000204@toomeek.waw.pl> <20140815214416.GJ60808@cicely7.cicely.de> <53EFCD6C.5000601@toomeek.waw.pl> <53EFD5D5.7010406@toomeek.waw.pl> <53F0E640.5030506@toomeek.waw.pl> <53F14BD7.1050007@fukaumi.org> <53F1A126.1020408@toomeek.waw.pl> <53F1D8FD.9010903@fukaumi.org> <53F27EB9.3090805@toomeek.waw.pl> <54031BC8.8020407@toomeek.waw.pl> <540348DD.3090406@toomeek.waw.pl> <20140831181954.499135cfbffb3266d7ce69ab@schwarzes.net> In-Reply-To: <20140831181954.499135cfbffb3266d7ce69ab@schwarzes.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.9 (poczta.toomeek.waw.pl [0.0.0.0]); Sun, 31 Aug 2014 14:29:07 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.98.4 at a8d2ba546e X-Virus-Status: Clean X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 18:29:11 -0000 Thanks, I didn't used this tool before. How to resolve conflicts? .... Tree conflict on '/usr/src/COPYRIGHT' > local file unversioned, incoming file add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: h (r) - accept current working copy state (p) - resolve the conflict later [postpone] (q) - postpone all remaining conflicts (h) - show this help (also '?') Should I type "r" here? If yes, then I still have obsolete versions, example: /usr/src/sys/boot/fdt/dts/cubieboard2.dts doesn't match: http://svn.freebsd.org/base/head/sys/boot/fdt/dts/arm/cubieboard2.dts root@freebsd:/sys/boot/fdt/dts # cd /usr/src root@freebsd:/usr/src # svnlite checkout http://svn.freebsd.org/base/head /usr/src Checked out revision 270885. root@freebsd:/usr/src # svnlite update Updating '.': At revision 270885. Best regards, TooMeeK W dniu 2014-08-31 18:20, Andreas Schwarz pisze: > On Sun, 31 Aug 2014 18:10:05 +0200 > > The simplest way to get head is to use svn (or the included svnlite). > > initial : > > svnlite checkout http://svn.freebsd.org/base/head /usr/src > > (change protocol and path if needed) > > update : > > cd /usr/src > svnlite update > > > From owner-freebsd-arm@FreeBSD.ORG Mon Sep 1 12:33:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 731C1E09 for ; Mon, 1 Sep 2014 12:33:23 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B44B14C6 for ; Mon, 1 Sep 2014 12:33:23 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id h18so12719490igc.6 for ; Mon, 01 Sep 2014 05:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w9NBdPND2XI0cR5zSQfkf6L40eVpEI971ZGi2RwJNiY=; b=Pq5YN8q1h1pfqKe8pAVYO4Q8UQYkiQIQW1Gz9lB11DO9K7Rt0Qd916WEdvlkQz0OWR Z05dvbcWAFErg6LrWKQoXaKGK7uC9TkY6+vkCisgCHkvXXkFtthr05oXn5w+JPgvf3Nc tGikRGITrWqdJHmIAjneJ5El7pit0sNHlRgiG+zVRpWCIuy5dZchoT1mw+UIACd5INTn MW5rFVcuHo4nVnLWNMgUzlK66e4cmHLyxt2LMDlPIpTYQ+mD6T/zjYQNIX6HSWkJgG8d Ly4PJohfML8CZKorKQTHPh27NBkwhw1nCYZo+NB8410r8hSJhYVmV23dGg6NAwHvEzNr yJIg== MIME-Version: 1.0 X-Received: by 10.43.64.198 with SMTP id xj6mr1586142icb.70.1409574802653; Mon, 01 Sep 2014 05:33:22 -0700 (PDT) Received: by 10.64.88.163 with HTTP; Mon, 1 Sep 2014 05:33:22 -0700 (PDT) In-Reply-To: <540348DD.3090406@toomeek.waw.pl> References: <53EE0F93.6060407@toomeek.waw.pl> <53EE23B1.2020403@toomeek.waw.pl> <53EE402D.8000204@toomeek.waw.pl> <20140815214416.GJ60808@cicely7.cicely.de> <53EFCD6C.5000601@toomeek.waw.pl> <53EFD5D5.7010406@toomeek.waw.pl> <53F0E640.5030506@toomeek.waw.pl> <53F14BD7.1050007@fukaumi.org> <53F1A126.1020408@toomeek.waw.pl> <53F1D8FD.9010903@fukaumi.org> <53F27EB9.3090805@toomeek.waw.pl> <54031BC8.8020407@toomeek.waw.pl> <540348DD.3090406@toomeek.waw.pl> Date: Mon, 1 Sep 2014 20:33:22 +0800 Message-ID: Subject: Re: U-boot for Banana Pi From: Ganbold Tsagaankhuu To: TooMeeK Admin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 12:33:23 -0000 On Mon, Sep 1, 2014 at 12:10 AM, TooMeeK Admin wrote: > Reinstalled FreeBSD 10 64-bit from scratch.. fully updated.. > /usr/src/sys/boot/fdt/dts/cubieboard2.dts contains 512MB addressing, so > it cannot be right.. > The same at: > ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ > 10.0-RELEASE/src.txz > They are simply - outdated. > > Wiki page doesn't say where sources are, just: > "1. Get FreeBSD head" > So what sources You're using to build Cubieboard2 kernel? > > But anyway I found answer here: > https://lists.freebsd.org/pipermail/freebsd-arm/2013-August/006201.html > and changed Banana Pi files accordinately: > file: a10_machdep.c > change at: initarm_late_init > adding: unmapped_buf_allowed = 0; > > I'm running 1GB of memory now. > But no networking, no HDMI output. > Added 1Gbit GMAC driver to BANANAPI config and /boot/loader.conf: > miibus_load="YES" > if_gem_load="YES" > but still getting only lo0. > Login prompt works. > > So.. how You did it working, Ganbold ? > There is no support (no driver) yet for A20 GMAC controller as well as hdmi. Ganbold > > Best regards, > TooMeeK > > > >> What is in Your /usr/src/sys/boot/fdt/dts/cubieboard2.dts file, section >> memory? >> >> Best regards, >> TooMeeK >> >> W dniu 2014-08-27 14:53, Ganbold Tsagaankhuu pisze: >> >>> >>> >>> >>> I've just got Banana PI today, and I confirm that Cubieboard2 kernel >>> works just fine detecting 1GB RAM and booting to multi user mode. I run >>> recent Current of course. >>> >>> Ganbold >>> >>> >>> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> >> > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Mon Sep 1 14:18:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8DECD19 for ; Mon, 1 Sep 2014 14:18:06 +0000 (UTC) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3CE051122 for ; Mon, 1 Sep 2014 14:18:05 +0000 (UTC) Received: from asc-t60.schwarzes.net (p5B0329D2.dip0.t-ipconnect.de [91.3.41.210]) (authenticated bits=0) by olinguito.schwarzes.net (8.14.8/8.14.8) with ESMTP id s81EI1tN081335; Mon, 1 Sep 2014 16:18:02 +0200 (CEST) (envelope-from freebsd.asc@strcmp.org) Date: Mon, 1 Sep 2014 16:17:53 +0200 From: Andreas Schwarz To: TooMeeK Admin Subject: Re: U-boot for Banana Pi Message-Id: <20140901161753.042f46918777774d313272b0@strcmp.org> In-Reply-To: <54036970.9040503@toomeek.waw.pl> References: <53EE0F93.6060407@toomeek.waw.pl> <53EE23B1.2020403@toomeek.waw.pl> <53EE402D.8000204@toomeek.waw.pl> <20140815214416.GJ60808@cicely7.cicely.de> <53EFCD6C.5000601@toomeek.waw.pl> <53EFD5D5.7010406@toomeek.waw.pl> <53F0E640.5030506@toomeek.waw.pl> <53F14BD7.1050007@fukaumi.org> <53F1A126.1020408@toomeek.waw.pl> <53F1D8FD.9010903@fukaumi.org> <53F27EB9.3090805@toomeek.waw.pl> <54031BC8.8020407@toomeek.waw.pl> <540348DD.3090406@toomeek.waw.pl> <20140831181954.499135cfbffb3266d7ce69ab@schwarzes.net> <54036970.9040503@toomeek.waw.pl> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Mon, 01 Sep 2014 16:18:02 +0200 (CEST) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 14:18:06 -0000 On Sun, 31 Aug 2014 20:29:04 +0200 TooMeeK Admin wrote: > Thanks, > > I didn't used this tool before. How to resolve conflicts? > .... > Tree conflict on '/usr/src/COPYRIGHT' > > local file unversioned, incoming file add upon update > Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: h > > (r) - accept current working copy state > (p) - resolve the conflict later [postpone] > (q) - postpone all remaining conflicts > (h) - show this help (also '?') > > Should I type "r" here? > If yes, then I still have obsolete versions, example: > /usr/src/sys/boot/fdt/dts/cubieboard2.dts > doesn't match: > http://svn.freebsd.org/base/head/sys/boot/fdt/dts/arm/cubieboard2.dts I've not expected that you have already an existing copy in /usr/src (probably the 10 release). To avoid problems, please do the checkout and update in a clean dir and then add your modifications. -- best regards Andreas From owner-freebsd-arm@FreeBSD.ORG Tue Sep 2 00:09:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26E1AA60 for ; Tue, 2 Sep 2014 00:09:23 +0000 (UTC) Received: from poczta.toomeek.waw.pl (unknown [IPv6:2001:67c:232c:1000::fd9b:4fb4]) by mx1.freebsd.org (Postfix) with ESMTP id A2861147F for ; Tue, 2 Sep 2014 00:09:22 +0000 (UTC) Received: from [192.168.137.1] (afow104.neoplus.adsl.tpnet.pl [178.42.126.104]) by poczta.toomeek.waw.pl (Postfix) with ESMTPSA id B06F0C60204 for ; Mon, 1 Sep 2014 20:09:11 -0400 (EDT) Message-ID: <54050AA1.4050908@toomeek.waw.pl> Date: Tue, 02 Sep 2014 02:09:05 +0200 From: TooMeeK Admin User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: Re: U-boot for Banana Pi References: <53EE0F93.6060407@toomeek.waw.pl> <53EE23B1.2020403@toomeek.waw.pl> <53EE402D.8000204@toomeek.waw.pl> <20140815214416.GJ60808@cicely7.cicely.de> <53EFCD6C.5000601@toomeek.waw.pl> <53EFD5D5.7010406@toomeek.waw.pl> <53F0E640.5030506@toomeek.waw.pl> <53F14BD7.1050007@fukaumi.org> <53F1A126.1020408@toomeek.waw.pl> <53F1D8FD.9010903@fukaumi.org> <53F27EB9.3090805@toomeek.waw.pl> <54031BC8.8020407@toomeek.waw.pl> <540348DD.3090406@toomeek.waw.pl> In-Reply-To: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.9 (poczta.toomeek.waw.pl [0.0.0.0]); Mon, 01 Sep 2014 20:09:12 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.98.4 at a8d2ba546e X-Virus-Status: Clean Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 00:09:23 -0000 Uh :( That's sad. The main purpuse of this thread was to port FreeBSD 10.0 OS for Banana Pi as base for great pfSense OS.. ..as this is very good base for low power, low cost, high performance router.. Shame there's no 1Gbit driver yet. I suppose running EMAC driver at 100Mbit won't work too. Case closed, goes to archive X... Thank You all for clues and help. Best regards, TooMeeK W dniu 2014-09-01 14:33, Ganbold Tsagaankhuu pisze: > > > There is no support (no driver) yet for A20 GMAC controller as well as > hdmi. > > Ganbold > > From owner-freebsd-arm@FreeBSD.ORG Wed Sep 3 22:11:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DC354FF for ; Wed, 3 Sep 2014 22:11:18 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40D7A1DB8 for ; Wed, 3 Sep 2014 22:11:18 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id m20so9692405qcx.35 for ; Wed, 03 Sep 2014 15:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Y/2P1ckSICnAiIMco5IGqEPDCuyUDZ0Gv95VxstEMO8=; b=VMAmvogHhaHhv5CV8xnRfjooYE06YoXj4zIJUHLE63cBG/wsRyCePEf6Ecy40WNOui k4z4jH4ZXNj9EyA4B80W7JMtE67B34K6Yup7/FUHeEih4mqwPomi6HpOtf92+9eBsBoQ Zaq3uAxqO54PjbV6p69tPWE8TJ/r3VFxEYMUh1AeR2ihsG8JVOPoJt/la5GLSt49QBws 1fsI5FZSu5Zb7R8nEkYX+7pMfjvpgoSZ7qOc9zLB+fX3DCxgPVStI+NDWGFH13svW9cS T/AlKigcd3im2MnAUBd7Xx2MMEk+CH3O7o1K3wvk00IaVloKn8D4P03MzX3laGNNU99n UZ3A== MIME-Version: 1.0 X-Received: by 10.224.86.5 with SMTP id q5mr734381qal.36.1409782275652; Wed, 03 Sep 2014 15:11:15 -0700 (PDT) Received: by 10.140.106.136 with HTTP; Wed, 3 Sep 2014 15:11:15 -0700 (PDT) Date: Wed, 3 Sep 2014 19:11:15 -0300 Message-ID: Subject: address dependent code? From: =?UTF-8?Q?Mat=C3=ADas_Perret_Cantoni?= To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 22:11:18 -0000 Hello! I've found that for compiling ubldr I need to specify the address where it will be loaded and executed, and I'd like to know more about this. It's the first time I find that I need to specify a physical address on compile time. I'm sure it's kind of a whole specific programming field, so can you point out some material that I can read about this? Any info about this will be appreciated! Thanks in advance. Regards, Matias. From owner-freebsd-arm@FreeBSD.ORG Wed Sep 3 22:30:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B39B2ABB for ; Wed, 3 Sep 2014 22:30:12 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 860791F44 for ; Wed, 3 Sep 2014 22:30:12 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XPJ47-000Ag6-0H; Wed, 03 Sep 2014 22:30:11 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s83MUApx009025; Wed, 3 Sep 2014 16:30:10 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18tlCnj38gEBMYy8XZTCY6T X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: address dependent code? From: Ian Lepore To: =?ISO-8859-1?Q?Mat=EDas?= Perret Cantoni In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 03 Sep 2014 16:30:09 -0600 Message-ID: <1409783409.1150.297.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s83MUApx009025 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 22:30:12 -0000 On Wed, 2014-09-03 at 19:11 -0300, Mat=EDas Perret Cantoni wrote: > Hello! I've found that for compiling ubldr I need to specify the addres= s > where it will be loaded and executed, and I'd like to know more about t= his. > It's the first time I find that I need to specify a physical address on > compile time. >=20 > I'm sure it's kind of a whole specific programming field, so can you po= int > out some material that I can read about this? Any info about this will = be > appreciated! >=20 > Thanks in advance. >=20 > Regards, Matias. The kernel also needs to be compiled to load at a specific address, but you don't have to set it manually because it's hard-coded in the std.soctype file for each chip. In the case of ubldr, it's because u-boot doesn't know how to do relocation, it can only load an image that is pre-linked to run at a fixed address. ubldr isn't built along with the kernel, so there's nowhere to configure the load address on a per-system basis, it has to be provided manually. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Sep 4 10:11:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 278E4E68 for ; Thu, 4 Sep 2014 10:11:46 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00A921082 for ; Thu, 4 Sep 2014 10:11:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=ydmq2nrJSZ+ecMn/ZZoY7Jk21HCmwY1q6ux2k9Kr/js=; b=WE/1V1jZmGmTUsDEyn5N/dDVE5xMJK8gapggyBH5WcddWzINao5JQ/dL2LVeQUj/L35G4QZahsTluvYGa8T3ZJzNk9tI3+3ioVZNWmAfCc7umfnTD3tlYn3pQYp9Xx9LJ/cZ6xuCJyLqc1qNXqG1fOcyFxSriHXFjnCpp5uOkk4=; Received: from [182.0.87.136] (port=28543 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPU0v-003YTR-Ve for freebsd-arm@freebsd.org; Thu, 04 Sep 2014 04:11:38 -0600 Date: Thu, 4 Sep 2014 18:11:29 +0800 From: Erich Dollansky To: freebsd-arm@freebsd.org Subject: buildworld on a Raspberry Message-ID: <20140904181129.5d38c1ef@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 10:11:46 -0000 Hi, did anybody do a buildworld on the device itself? How long will it take? I estimate that it could take some days. Erich From owner-freebsd-arm@FreeBSD.ORG Thu Sep 4 11:28:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E99D31C4 for ; Thu, 4 Sep 2014 11:28:43 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2BAE19BE for ; Thu, 4 Sep 2014 11:28:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=Gta+9Vi35fb9UYRkT3nINzbx+dX0fEE/Sy6du4Ve58o=; b=LSViwwR64GbnsOTA2e2x7Iek2lpRLIU5SX85IjFD2N3B9lUqS9DbcPRF1Ha+zq1wyAoQFqTU7bNOEk63r1CXerGMW+aBVqGZ0JAuZJ1GnkboitNMbPP3rHK6USVcm1l9Ka9EIZikVX9wIJpGPU80JUNXNwSY1FmOJSk310aIQ6s=; Received: from [182.0.87.136] (port=52962 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPVDW-000Bcc-1m; Thu, 04 Sep 2014 05:28:42 -0600 Date: Thu, 4 Sep 2014 19:28:31 +0800 From: Erich Dollansky To: YAMAMOTO Shigeru Subject: Re: buildworld on a Raspberry Message-ID: <20140904192831.5f483f3c@X220.alogt.com> In-Reply-To: <20140904.201648.1532098598554690924.shigeru@os-hackers.jp> References: <20140904181129.5d38c1ef@X220.alogt.com> <20140904.201648.1532098598554690924.shigeru@os-hackers.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 11:28:44 -0000 Hi, On Thu, 04 Sep 2014 20:16:48 +0900 (JST) YAMAMOTO Shigeru wrote: > >>>>> "Erich" == Erich Dollansky writes: > Erich> Hi, did anybody do a buildworld on the device itself? > Erich> How long will it take? > Erich> I estimate that it could take some days. > > I do sometime buildworld on RasbperryPi Type B. > I use external USB HDD for work area. > this is what I plan to do too after my initial tests and getting a bit used to the device. > In my case, a time for buildworld is 3 or 4 days. This sounds much more like it. With other words, as long as I cannot make sure that the machine can run for a week, I should not bother to start building it on the device itself. Erich From owner-freebsd-arm@FreeBSD.ORG Thu Sep 4 11:38:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E99DF26A for ; Thu, 4 Sep 2014 11:38:05 +0000 (UTC) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id BCF3D1A7D for ; Thu, 4 Sep 2014 11:38:04 +0000 (UTC) Received: from localhost (w142149.ppp.asahi-net.or.jp [121.1.142.149]) by mailssl.asahi-net.or.jp (Postfix) with ESMTP id 36AE0F140; Thu, 4 Sep 2014 20:16:53 +0900 (JST) Date: Thu, 04 Sep 2014 20:16:48 +0900 (JST) Message-Id: <20140904.201648.1532098598554690924.shigeru@os-hackers.jp> To: erichsfreebsdlist@alogt.com Subject: Re: buildworld on a Raspberry From: YAMAMOTO Shigeru In-Reply-To: <20140904181129.5d38c1ef@X220.alogt.com> References: <20140904181129.5d38c1ef@X220.alogt.com> X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 11:38:06 -0000 Hi, >>>>> "Erich" == Erich Dollansky writes: Erich> Hi, did anybody do a buildworld on the device itself? Erich> How long will it take? Erich> I estimate that it could take some days. I do sometime buildworld on RasbperryPi Type B. I use external USB HDD for work area. In my case, a time for buildworld is 3 or 4 days. Thanks, --- YAMAMOTO Shigeru From owner-freebsd-arm@FreeBSD.ORG Thu Sep 4 11:42:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C924377 for ; Thu, 4 Sep 2014 11:42:25 +0000 (UTC) Received: from iwiw02d.mail.t-online.hu (iwiw02d.mail.t-online.hu [84.2.42.67]) by mx1.freebsd.org (Postfix) with ESMTP id 38EB71B2E for ; Thu, 4 Sep 2014 11:42:24 +0000 (UTC) Received: from fmx24.freemail.hu (fmx24.freemail.hu [195.228.245.74]) by iwiw02d.mail.t-online.hu (Postfix) with SMTP id 0CC78488FD9 for ; Thu, 4 Sep 2014 13:42:23 +0200 (CEST) Received: (qmail 71706 invoked by uid 151); 4 Sep 2014 13:42:22 +0200 Received: from 195.228.245.212 (HELO fmxmldata07.freemail.hu) (80.98.117.10) by fmx24.freemail.hu with SMTP; 4 Sep 2014 13:42:22 +0200 Received: from webmail by smtp gw id s84BgMDj007096; Thu, 4 Sep 2014 13:42:22 +0200 (CEST) Date: Thu, 4 Sep 2014 13:42:22 +0200 (CEST) From: Kover Attila Subject: buildworld on a Raspberry To: freebsd-arm@freebsd.org Message-ID: X-Originating-IP: [80.98.117.10] X-HTTP-User-Agent: Opera/9.80 (X11; Linux x86_64) Presto/2.12.388 Version/12.15 X-Original-User: koverat MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 11:42:25 -0000 Hi, I made a self hosted image in April this year with HEAD r246986 on my PI-B, here is the relevant information (date is in yyyy.mm.dd hh:mm:ss format ): ***** DEBUG * 2014.04.27. 00:33:32 * buildworld begins -- 247588.40 real 155340.16 user 15553.08 sys ***** DEBUG * 2014.04.29. 21:20:00 * buildkernel begins -- 20382.90 real 11168.55 user 1936.28 sys ***** DEBUG * 2014.04.30. 02:59:43 * installkernel begins -- 459.26 real 60.40 user 69.29 sys ***** DEBUG * 2014.04.30. 03:07:22 * READY 1/3RegardsAttila > Hi,> did anybody do a buildworld on the device itself?> How long will it take?> I estimate that it could take some days.> Erich From owner-freebsd-arm@FreeBSD.ORG Thu Sep 4 14:05:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC13FA81 for ; Thu, 4 Sep 2014 14:05:31 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A42441C90 for ; Thu, 4 Sep 2014 14:05:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=9y/HkcDF+/copjWjZrFMyWhU+3RIKA7D+hWMhs1gkJI=; b=GSk89/SBQ9hfqIyZ3XttYI7VFsPNB7oXMRCCO+q1QVwlxc09Hq5yUwV38zsFBxHW7hOQLedCKqUF4P50Bu6a4bzmS+xYbjT+o9weeleJDtsVMskSnIhWyIp7dqyjIcll3EK7KXtxQOd/Fj0k6UsdHSfPS02xBzHNQMpTHoXkHig=; Received: from [182.0.87.136] (port=65292 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPXfF-0029sW-IJ; Thu, 04 Sep 2014 08:05:30 -0600 Date: Thu, 4 Sep 2014 22:05:23 +0800 From: Erich Dollansky To: YAMAMOTO Shigeru Subject: Re: buildworld on a Raspberry Message-ID: <20140904220523.5e1a482f@X220.alogt.com> In-Reply-To: <20140904.201648.1532098598554690924.shigeru@os-hackers.jp> References: <20140904181129.5d38c1ef@X220.alogt.com> <20140904.201648.1532098598554690924.shigeru@os-hackers.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 14:05:31 -0000 Hi, you wrote recently that your own kernel works with a Raspberry but not the kernel from FreeBSD itself. You believe the old firmware might be the problem. I did not some tests. Of course, the kernel downloaded from your site works. When I installed my own kernel with revision 271057 (from this morning), I still do not get a running image. I did these tests and all failed: Use your firmware with the new kernel, Use your kernel with the firmware from the new kernel. The image works the moment I use the new kernel but copy your /boot and your files from the FAT to the media. My problem is that I lost my monitor cable and I am currently at a location where they do not sell such things. So, all I can tell is that an image comes to the state when I can log-on remotely. The log files show always that ue0 is not recognised when the image fails. Do you have any idea what is wrong? Erich On Thu, 04 Sep 2014 20:16:48 +0900 (JST) YAMAMOTO Shigeru wrote: > > Hi, > > >>>>> "Erich" == Erich Dollansky writes: > Erich> Hi, did anybody do a buildworld on the device itself? > Erich> How long will it take? > Erich> I estimate that it could take some days. > > I do sometime buildworld on RasbperryPi Type B. > I use external USB HDD for work area. > > In my case, a time for buildworld is 3 or 4 days. > > Thanks, > --- > YAMAMOTO Shigeru From owner-freebsd-arm@FreeBSD.ORG Thu Sep 4 15:30:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 483C7103 for ; Thu, 4 Sep 2014 15:30:14 +0000 (UTC) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D641B1929 for ; Thu, 4 Sep 2014 15:30:13 +0000 (UTC) Received: from asc-t60.schwarzes.net (p5B031F34.dip0.t-ipconnect.de [91.3.31.52]) (authenticated bits=0) by olinguito.schwarzes.net (8.14.8/8.14.8) with ESMTP id s84FTw2x000546; Thu, 4 Sep 2014 17:29:59 +0200 (CEST) (envelope-from freebsd.asc@strcmp.org) Date: Thu, 4 Sep 2014 17:29:47 +0200 From: Andreas Schwarz To: Erich Dollansky Subject: Re: buildworld on a Raspberry Message-Id: <20140904172947.0ee838ae0249c80fdcbae3c2@strcmp.org> In-Reply-To: <20140904181129.5d38c1ef@X220.alogt.com> References: <20140904181129.5d38c1ef@X220.alogt.com> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Thu, 04 Sep 2014 17:30:00 +0200 (CEST) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:30:14 -0000 On Thu, 4 Sep 2014 18:11:29 +0800 Erich Dollansky wrote: Hi Erich, > did anybody do a buildworld on the device itself? I do this regularly, I've two RPI, one for "production" and the other one for building and testing. > How long will it take? Depends on you setup (a little bit), I'm using tmpfs for /tmp and /var/tmp and there is also a difference with different SD Cards (some of them are up to 50% faster). My experiences : make kernel-toolchain : 1.5 days make buildkernel : 0.5 days make buildworld : 2 days -- best regards Andreas From owner-freebsd-arm@FreeBSD.ORG Fri Sep 5 21:41:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9861DA9 for ; Fri, 5 Sep 2014 21:41:44 +0000 (UTC) Received: from bein.link (unknown [IPv6:2a02:2770:3:0:21a:4aff:fee6:9061]) by mx1.freebsd.org (Postfix) with ESMTP id 62136124F for ; Fri, 5 Sep 2014 21:41:44 +0000 (UTC) Received: from quad.localnet (unknown [188.134.8.193]) by bein.link (Postfix) with ESMTPSA id 69A194051D for ; Fri, 5 Sep 2014 23:41:41 +0200 (CEST) From: Maxim V FIlimonov To: freebsd-arm@freebsd.org Subject: Cubieboard: load average above 2 Date: Sat, 06 Sep 2014 01:41:40 +0400 Message-ID: <27116175.UDSoyStjsX@quad> User-Agent: KMail/4.12.5 (FreeBSD/10.0-RELEASE-p7; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 21:41:44 -0000 Recently, I installed FreeBSD-current to my Cubieboard2: root@cubie:~ # uname -a FreeBSD cubie 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r271182M: Sat Sep 6 01:17:28 MSK 2014 root@quad:/usr/obj/arm.armv6/home/che/freebsd- src/head/sys/CUBIEBOARD2 arm And the system's load average keeps being above 2: root@cubie:~ # uptime 8:31PM up 19 mins, 1 user, load averages: 2.36, 1.89, 1.32 Everything is not really slow, but sometimes takes time. What could be the problem here? What can I do with that? -- wbr, Maxim Filimonov che@bein.link From owner-freebsd-arm@FreeBSD.ORG Fri Sep 5 21:43:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3B201CA for ; Fri, 5 Sep 2014 21:43:32 +0000 (UTC) Received: from bein.link (unknown [IPv6:2a02:2770:3:0:21a:4aff:fee6:9061]) by mx1.freebsd.org (Postfix) with ESMTP id AC9D31266 for ; Fri, 5 Sep 2014 21:43:32 +0000 (UTC) Received: from quad.localnet (unknown [188.134.8.193]) by bein.link (Postfix) with ESMTPSA id 0EBD34051D for ; Fri, 5 Sep 2014 23:43:24 +0200 (CEST) From: Maxim V FIlimonov To: freebsd-arm@freebsd.org Subject: Cubieboard: Spurious interrupt detected Date: Sat, 06 Sep 2014 01:43:23 +0400 Message-ID: <2279481.3MX4OEDuCl@quad> User-Agent: KMail/4.12.5 (FreeBSD/10.0-RELEASE-p7; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 21:43:33 -0000 And another problem: every now and then the kernel says something like that: Sep 5 19:22:37 kernel: Spurious interrupt detected Sep 5 19:22:37 kernel: Spurious interrupt detected Sep 5 19:23:46 last message repeated 10 times I've heard that FreeBSD happens to do that on ARM devices. What could be the problem here? -- wbr, Maxim Filimonov che@bein.link From owner-freebsd-arm@FreeBSD.ORG Fri Sep 5 21:57:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D27B5CC for ; Fri, 5 Sep 2014 21:57:14 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D33A11386 for ; Fri, 5 Sep 2014 21:57:13 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s85Lv7Yh090836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 Sep 2014 23:57:08 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s85Lv2xk072371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2014 23:57:02 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s85Lv23Y004629; Fri, 5 Sep 2014 23:57:02 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s85Lv2Gq004628; Fri, 5 Sep 2014 23:57:02 +0200 (CEST) (envelope-from ticso) Date: Fri, 5 Sep 2014 23:57:02 +0200 From: Bernd Walter To: Maxim V FIlimonov Subject: Re: Cubieboard: Spurious interrupt detected Message-ID: <20140905215702.GL3196@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <2279481.3MX4OEDuCl@quad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2279481.3MX4OEDuCl@quad> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 21:57:14 -0000 On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote: > And another problem: every now and then the kernel says something like that: > Sep 5 19:22:37 kernel: Spurious interrupt detected > Sep 5 19:22:37 kernel: Spurious interrupt detected > Sep 5 19:23:46 last message repeated 10 times > > I've heard that FreeBSD happens to do that on ARM devices. What could be the > problem here? Means something generates inetrrupts, which are not handled by a driver. Could be the cause for your load problem too. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Fri Sep 5 22:02:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C32987A for ; Fri, 5 Sep 2014 22:02:33 +0000 (UTC) Received: from bein.link (vps-6159-8629.cloud.tilaa.com [37.252.124.82]) by mx1.freebsd.org (Postfix) with ESMTP id 11FDF14AE for ; Fri, 5 Sep 2014 22:02:32 +0000 (UTC) Received: from quad.localnet (unknown [188.134.8.193]) by bein.link (Postfix) with ESMTPSA id 78E9E4051D; Sat, 6 Sep 2014 00:02:29 +0200 (CEST) From: Maxim V FIlimonov To: ticso@cicely.de Subject: Re: Cubieboard: load average above 2 Date: Sat, 06 Sep 2014 02:02:29 +0400 Message-ID: <6780316.UDbfH4Htdv@quad> User-Agent: KMail/4.12.5 (FreeBSD/10.0-RELEASE-p7; KDE/4.12.5; amd64; ; ) In-Reply-To: <20140905215555.GK3196@cicely7.cicely.de> References: <27116175.UDSoyStjsX@quad> <20140905215555.GK3196@cicely7.cicely.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 22:02:33 -0000 On Friday 05 September 2014 23:55:55 you wrote: > On Sat, Sep 06, 2014 at 01:41:40AM +0400, Maxim V FIlimonov wrote: > > Recently, I installed FreeBSD-current to my Cubieboard2: > > root@cubie:~ # uname -a > > FreeBSD cubie 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r271182M: Sat Sep 6 > > 01:17:28 MSK 2014 root@quad:/usr/obj/arm.armv6/home/che/freebsd- > > src/head/sys/CUBIEBOARD2 arm > > > > And the system's load average keeps being above 2: > > root@cubie:~ # uptime > > > > 8:31PM up 19 mins, 1 user, load averages: 2.36, 1.89, 1.32 > > > > Everything is not really slow, but sometimes takes time. > > What could be the problem here? What can I do with that? > > top -SH is the first thing I do to find what's consuming CPU. > Note that an idle thread consuming CPU means it's really idling. It shows about 200% idle and about 0.5% per task for other tasks. That's weird. -- wbr, Maxim Filimonov che@bein.link From owner-freebsd-arm@FreeBSD.ORG Fri Sep 5 22:03:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC7048BE for ; Fri, 5 Sep 2014 22:03:18 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E85214B7 for ; Fri, 5 Sep 2014 22:03:17 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s85Lu2H2090833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 Sep 2014 23:56:02 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s85LtuDs072367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2014 23:55:56 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s85LtuaR004622; Fri, 5 Sep 2014 23:55:56 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s85LtuCo004621; Fri, 5 Sep 2014 23:55:56 +0200 (CEST) (envelope-from ticso) Date: Fri, 5 Sep 2014 23:55:55 +0200 From: Bernd Walter To: Maxim V FIlimonov Subject: Re: Cubieboard: load average above 2 Message-ID: <20140905215555.GK3196@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <27116175.UDSoyStjsX@quad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27116175.UDSoyStjsX@quad> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 22:03:18 -0000 On Sat, Sep 06, 2014 at 01:41:40AM +0400, Maxim V FIlimonov wrote: > Recently, I installed FreeBSD-current to my Cubieboard2: > root@cubie:~ # uname -a > FreeBSD cubie 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r271182M: Sat Sep 6 > 01:17:28 MSK 2014 root@quad:/usr/obj/arm.armv6/home/che/freebsd- > src/head/sys/CUBIEBOARD2 arm > > And the system's load average keeps being above 2: > root@cubie:~ # uptime > 8:31PM up 19 mins, 1 user, load averages: 2.36, 1.89, 1.32 > > Everything is not really slow, but sometimes takes time. > What could be the problem here? What can I do with that? top -SH is the first thing I do to find what's consuming CPU. Note that an idle thread consuming CPU means it's really idling. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Fri Sep 5 22:08:24 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A995EA98 for ; Fri, 5 Sep 2014 22:08:24 +0000 (UTC) Received: from bein.link (vps-6159-8629.cloud.tilaa.com [37.252.124.82]) by mx1.freebsd.org (Postfix) with ESMTP id 6F37014F7 for ; Fri, 5 Sep 2014 22:08:24 +0000 (UTC) Received: from quad.localnet (unknown [188.134.8.193]) by bein.link (Postfix) with ESMTPSA id 457FF4051F; Sat, 6 Sep 2014 00:08:22 +0200 (CEST) From: Maxim V FIlimonov To: ticso@cicely.de Subject: Re: Cubieboard: load average above 2 Date: Sat, 06 Sep 2014 02:08:22 +0400 Message-ID: <6240427.cmkfEefv07@quad> User-Agent: KMail/4.12.5 (FreeBSD/10.0-RELEASE-p7; KDE/4.12.5; amd64; ; ) In-Reply-To: <20140905215555.GK3196@cicely7.cicely.de> References: <27116175.UDSoyStjsX@quad> <20140905215555.GK3196@cicely7.cicely.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 22:08:24 -0000 On Friday 05 September 2014 23:55:55 Bernd Walter wrote: > On Sat, Sep 06, 2014 at 01:41:40AM +0400, Maxim V FIlimonov wrote: > > Recently, I installed FreeBSD-current to my Cubieboard2: > > root@cubie:~ # uname -a > > FreeBSD cubie 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r271182M: Sat Sep 6 > > 01:17:28 MSK 2014 root@quad:/usr/obj/arm.armv6/home/che/freebsd- > > src/head/sys/CUBIEBOARD2 arm > > > > And the system's load average keeps being above 2: > > root@cubie:~ # uptime > > > > 8:31PM up 19 mins, 1 user, load averages: 2.36, 1.89, 1.32 > > > > Everything is not really slow, but sometimes takes time. > > What could be the problem here? What can I do with that? > > top -SH is the first thing I do to find what's consuming CPU. > Note that an idle thread consuming CPU means it's really idling. I took away I2C support from the kernel config, and now LA is about 1.3 which is also a bit too much, but not that big, AFAIK. Could i2c be the problem here? -- wbr, Maxim Filimonov che@bein.link From owner-freebsd-arm@FreeBSD.ORG Fri Sep 5 23:12:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FEC7F24 for ; Fri, 5 Sep 2014 23:12:05 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 739021D00 for ; Fri, 5 Sep 2014 23:12:05 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XQ2fe-000NYu-J2; Fri, 05 Sep 2014 23:11:58 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s85NBu5C013907; Fri, 5 Sep 2014 17:11:56 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18xVaK0H901ut73qUn1wJLC X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Cubieboard: Spurious interrupt detected From: Ian Lepore To: ticso@cicely.de In-Reply-To: <20140905215702.GL3196@cicely7.cicely.de> References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Sep 2014 17:11:56 -0600 Message-ID: <1409958716.1150.321.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 23:12:05 -0000 On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote: > On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote: > > And another problem: every now and then the kernel says something like that: > > Sep 5 19:22:37 kernel: Spurious interrupt detected > > Sep 5 19:22:37 kernel: Spurious interrupt detected > > Sep 5 19:23:46 last message repeated 10 times > > > > I've heard that FreeBSD happens to do that on ARM devices. What could be the > > problem here? > > Means something generates inetrrupts, which are not handled by a driver. > Could be the cause for your load problem too. > No, that would be stray interrupts. Spurious interrupts happen when an interrupt is asserted, but by time the processor asks the interrupt controller for the current active interrupt, it is no longer active. One way it can happen is when an interrupt handler writes to a device to clear a pending interrupt and that write takes a long time to complete because the device is on a slow bus, and the interrupt controller is on a faster bus. The EOI to the controller outraces the device write that would clear the pending interrupt condition, so the processor is re-interrupted, but by time it asks for the next active interrupt the device write has finally completed and the interrupt is no longer pending. That sequence used to happen a lot, and it was "fixed" by adding an l2cache sync (basically a "drain write buffer") just before an EOI. You sometimes still see an occasional spurious interrupt, but it shouldn't be happening multiple times per second as seen in the logging above. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 00:44:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17A658CF; Sat, 6 Sep 2014 00:44:36 +0000 (UTC) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC4EC17C6; Sat, 6 Sep 2014 00:44:35 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id j107so49511qga.18 for ; Fri, 05 Sep 2014 17:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UYXur3/Z+7bJFREjtmI5KF7Al6YN4KRO5P++8FdRIjQ=; b=XWLTMtBlLnKs6yhPT/Fi71WH4cJBAEtwwlxOlOZu8dOZEsXoo18X/B7qJ0HJbjBJPE 1BhwN3BRzRaXTpYuqVdKLLwy5nlV+U1iRtESmiMtU9slVKMg0oNOvTbNiEw5lwRMDlam qryeOAGz6uuJUtrzgibkQGsJ1Yxol0oxOke3kJs9c4aXWWG7g6xlL2Sz1PKsoHYLHr70 /Euh/LSsZviVqjr7facMstDjayBdKelip7hHWtXgEMdMUYZFyMGMNcXiL2rEkp/Q59ZN r1gRSNZ5mmm6UOFdu3yL8lxsHkPPfYqNYDa/C5Mh6rEKD74ukLCeVPfdeigUZa5tvV/v ovnA== MIME-Version: 1.0 X-Received: by 10.224.75.73 with SMTP id x9mr23859515qaj.63.1409964274978; Fri, 05 Sep 2014 17:44:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Fri, 5 Sep 2014 17:44:34 -0700 (PDT) In-Reply-To: <1409958716.1150.321.camel@revolution.hippie.lan> References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> Date: Fri, 5 Sep 2014 17:44:34 -0700 X-Google-Sender-Auth: P1v5hWHYo9e5D2BMCAR43lbLdoo Message-ID: Subject: Re: Cubieboard: Spurious interrupt detected From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 00:44:36 -0000 On 5 September 2014 16:11, Ian Lepore wrote: > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote: >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote: >> > And another problem: every now and then the kernel says something like that: >> > Sep 5 19:22:37 kernel: Spurious interrupt detected >> > Sep 5 19:22:37 kernel: Spurious interrupt detected >> > Sep 5 19:23:46 last message repeated 10 times >> > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the >> > problem here? >> >> Means something generates inetrrupts, which are not handled by a driver. >> Could be the cause for your load problem too. >> > > No, that would be stray interrupts. Spurious interrupts happen when an > interrupt is asserted, but by time the processor asks the interrupt > controller for the current active interrupt, it is no longer active. > > One way it can happen is when an interrupt handler writes to a device to > clear a pending interrupt and that write takes a long time to complete > because the device is on a slow bus, and the interrupt controller is on > a faster bus. The EOI to the controller outraces the device write that > would clear the pending interrupt condition, so the processor is > re-interrupted, but by time it asks for the next active interrupt the > device write has finally completed and the interrupt is no longer > pending. > > That sequence used to happen a lot, and it was "fixed" by adding an > l2cache sync (basically a "drain write buffer") just before an EOI. You > sometimes still see an occasional spurious interrupt, but it shouldn't > be happening multiple times per second as seen in the logging above. Hm, interesting. I remember your discussion about it on IRC. The atheros code ends up working around this in the driver by doing a read from the ISR after writing out bits to clear things, so the clear is flushed out. I wonder if we should be asking all device drivers to be doing their own ISR flushing before returning from their interrupt handlers. -a From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 01:13:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 831F4E48; Sat, 6 Sep 2014 01:13:06 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42FFE1A56; Sat, 6 Sep 2014 01:13:05 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XQ4Yp-000GZJ-T7; Sat, 06 Sep 2014 01:13:04 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s861D1D4014050; Fri, 5 Sep 2014 19:13:01 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19VsheTPZVf3eJ4gRM27sLf X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Cubieboard: Spurious interrupt detected From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Sep 2014 19:13:00 -0600 Message-ID: <1409965980.1150.327.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 01:13:06 -0000 On Fri, 2014-09-05 at 17:44 -0700, Adrian Chadd wrote: > On 5 September 2014 16:11, Ian Lepore wrote: > > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote: > >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote: > >> > And another problem: every now and then the kernel says something like that: > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected > >> > Sep 5 19:23:46 last message repeated 10 times > >> > > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the > >> > problem here? > >> > >> Means something generates inetrrupts, which are not handled by a driver. > >> Could be the cause for your load problem too. > >> > > > > No, that would be stray interrupts. Spurious interrupts happen when an > > interrupt is asserted, but by time the processor asks the interrupt > > controller for the current active interrupt, it is no longer active. > > > > One way it can happen is when an interrupt handler writes to a device to > > clear a pending interrupt and that write takes a long time to complete > > because the device is on a slow bus, and the interrupt controller is on > > a faster bus. The EOI to the controller outraces the device write that > > would clear the pending interrupt condition, so the processor is > > re-interrupted, but by time it asks for the next active interrupt the > > device write has finally completed and the interrupt is no longer > > pending. > > > > That sequence used to happen a lot, and it was "fixed" by adding an > > l2cache sync (basically a "drain write buffer") just before an EOI. You > > sometimes still see an occasional spurious interrupt, but it shouldn't > > be happening multiple times per second as seen in the logging above. > > Hm, interesting. I remember your discussion about it on IRC. The > atheros code ends up working around this in the driver by doing a read > from the ISR after writing out bits to clear things, so the clear is > flushed out. > > I wonder if we should be asking all device drivers to be doing their > own ISR flushing before returning from their interrupt handlers. That's a big job, it means modifying more or less every driver in the system. Quoting part of the comment block I added along with the fix: The right way to fix this problem is for every device driver to use the proper bus_space_barrier() calls in its interrupt handler. For ARM a single barrier call at the end of the handler would work. This would have to be done to every driver in the system, not just arm-specific drivers. Another potential fix is to map all device memory as Strongly-Ordered rather than Device memory, which takes the store buffers out of the picture. This has a pretty big impact on overall system performance, because each strongly ordered memory access causes all L2 store buffers to be drained. A compromise solution is to have the interrupt controller implementation call this function to establish a barrier between writes to the interrupt-source device and writes to the interrupt controller device. This takes the interrupt number as an argument, and currently doesn't use it. The plan is that maybe some day there is a way to flag certain interrupts as "memory barrier safe" and we can avoid this overhead with them. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 01:15:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65145B1; Sat, 6 Sep 2014 01:15:37 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 392011A93; Sat, 6 Sep 2014 01:15:36 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s861FQpe027465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2014 18:15:26 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s861FQj0027464; Fri, 5 Sep 2014 18:15:26 -0700 (PDT) (envelope-from jmg) Date: Fri, 5 Sep 2014 18:15:26 -0700 From: John-Mark Gurney To: Adrian Chadd Subject: Re: Cubieboard: Spurious interrupt detected Message-ID: <20140906011526.GT82175@funkthat.com> Mail-Followup-To: Adrian Chadd , Ian Lepore , "freebsd-arm@freebsd.org" , ticso@cicely.de References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 05 Sep 2014 18:15:27 -0700 (PDT) Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 01:15:37 -0000 Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 17:44 -0700: > On 5 September 2014 16:11, Ian Lepore wrote: > > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote: > >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote: > >> > And another problem: every now and then the kernel says something like that: > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected > >> > Sep 5 19:23:46 last message repeated 10 times > >> > > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the > >> > problem here? > >> > >> Means something generates inetrrupts, which are not handled by a driver. > >> Could be the cause for your load problem too. > >> > > > > No, that would be stray interrupts. Spurious interrupts happen when an > > interrupt is asserted, but by time the processor asks the interrupt > > controller for the current active interrupt, it is no longer active. > > > > One way it can happen is when an interrupt handler writes to a device to > > clear a pending interrupt and that write takes a long time to complete > > because the device is on a slow bus, and the interrupt controller is on > > a faster bus. The EOI to the controller outraces the device write that > > would clear the pending interrupt condition, so the processor is > > re-interrupted, but by time it asks for the next active interrupt the > > device write has finally completed and the interrupt is no longer > > pending. > > > > That sequence used to happen a lot, and it was "fixed" by adding an > > l2cache sync (basically a "drain write buffer") just before an EOI. You > > sometimes still see an occasional spurious interrupt, but it shouldn't > > be happening multiple times per second as seen in the logging above. > > Hm, interesting. I remember your discussion about it on IRC. The > atheros code ends up working around this in the driver by doing a read > from the ISR after writing out bits to clear things, so the clear is > flushed out. > > I wonder if we should be asking all device drivers to be doing their > own ISR flushing before returning from their interrupt handlers. This is required on PCI (that you do a read to clear the posted/pending write)... So, IMO, yes, all device drivers should do the proper clearing of their writes to the ISR... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 01:33:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B7504E4; Sat, 6 Sep 2014 01:33:21 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4AC231CCD; Sat, 6 Sep 2014 01:33:20 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XQ4sR-000KpP-Tr; Sat, 06 Sep 2014 01:33:20 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s861XImA014079; Fri, 5 Sep 2014 19:33:18 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18cz6DY/QbAf5z23EXpnbHD X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Cubieboard: Spurious interrupt detected From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20140906011526.GT82175@funkthat.com> References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> <20140906011526.GT82175@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Sep 2014 19:33:17 -0600 Message-ID: <1409967197.1150.339.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 01:33:21 -0000 On Fri, 2014-09-05 at 18:15 -0700, John-Mark Gurney wrote: > Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 17:44 -0700: > > On 5 September 2014 16:11, Ian Lepore wrote: > > > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote: > > >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote: > > >> > And another problem: every now and then the kernel says something like that: > > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected > > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected > > >> > Sep 5 19:23:46 last message repeated 10 times > > >> > > > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the > > >> > problem here? > > >> > > >> Means something generates inetrrupts, which are not handled by a driver. > > >> Could be the cause for your load problem too. > > >> > > > > > > No, that would be stray interrupts. Spurious interrupts happen when an > > > interrupt is asserted, but by time the processor asks the interrupt > > > controller for the current active interrupt, it is no longer active. > > > > > > One way it can happen is when an interrupt handler writes to a device to > > > clear a pending interrupt and that write takes a long time to complete > > > because the device is on a slow bus, and the interrupt controller is on > > > a faster bus. The EOI to the controller outraces the device write that > > > would clear the pending interrupt condition, so the processor is > > > re-interrupted, but by time it asks for the next active interrupt the > > > device write has finally completed and the interrupt is no longer > > > pending. > > > > > > That sequence used to happen a lot, and it was "fixed" by adding an > > > l2cache sync (basically a "drain write buffer") just before an EOI. You > > > sometimes still see an occasional spurious interrupt, but it shouldn't > > > be happening multiple times per second as seen in the logging above. > > > > Hm, interesting. I remember your discussion about it on IRC. The > > atheros code ends up working around this in the driver by doing a read > > from the ISR after writing out bits to clear things, so the clear is > > flushed out. > > > > I wonder if we should be asking all device drivers to be doing their > > own ISR flushing before returning from their interrupt handlers. > > This is required on PCI (that you do a read to clear the posted/pending > write)... So, IMO, yes, all device drivers should do the proper > clearing of their writes to the ISR... > But a driver can't assume that a read is sufficient on all architectures it may run on. bus_space_barrier() is the right way. Also, it's not just that a barrier is needed before exiting an isr... if the isr uses locking to synchronize with hardware access by the non-isr part of the driver, then the bus space barriers are needed in conjunction with the locking, so that, for example, the isr's usage of the hardware is truly complete before a lock is released. Scattered amongst 10 of the roughly 240 drivers in sys/dev there are 42 calls to bus_space_barrier(). Getting all the drivers fixed will be a big job. That's why I was thinking along the lines of an architecture-wide workaround with potentially a way to mark a driver as not needing the workaround once we get the fixing underway. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 04:54:15 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9600533F; Sat, 6 Sep 2014 04:54:15 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 667FC1079; Sat, 6 Sep 2014 04:54:15 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s864s4cI030011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2014 21:54:04 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s864s3TA030010; Fri, 5 Sep 2014 21:54:03 -0700 (PDT) (envelope-from jmg) Date: Fri, 5 Sep 2014 21:54:03 -0700 From: John-Mark Gurney To: Ian Lepore Subject: Re: Cubieboard: Spurious interrupt detected Message-ID: <20140906045403.GU82175@funkthat.com> Mail-Followup-To: Ian Lepore , Adrian Chadd , "freebsd-arm@freebsd.org" , ticso@cicely.de References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> <20140906011526.GT82175@funkthat.com> <1409967197.1150.339.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1409967197.1150.339.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 05 Sep 2014 21:54:04 -0700 (PDT) Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 04:54:15 -0000 Ian Lepore wrote this message on Fri, Sep 05, 2014 at 19:33 -0600: > On Fri, 2014-09-05 at 18:15 -0700, John-Mark Gurney wrote: > > Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 17:44 -0700: > > > On 5 September 2014 16:11, Ian Lepore wrote: > > > > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote: > > > >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote: > > > >> > And another problem: every now and then the kernel says something like that: > > > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected > > > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected > > > >> > Sep 5 19:23:46 last message repeated 10 times > > > >> > > > > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the > > > >> > problem here? > > > >> > > > >> Means something generates inetrrupts, which are not handled by a driver. > > > >> Could be the cause for your load problem too. > > > >> > > > > > > > > No, that would be stray interrupts. Spurious interrupts happen when an > > > > interrupt is asserted, but by time the processor asks the interrupt > > > > controller for the current active interrupt, it is no longer active. > > > > > > > > One way it can happen is when an interrupt handler writes to a device to > > > > clear a pending interrupt and that write takes a long time to complete > > > > because the device is on a slow bus, and the interrupt controller is on > > > > a faster bus. The EOI to the controller outraces the device write that > > > > would clear the pending interrupt condition, so the processor is > > > > re-interrupted, but by time it asks for the next active interrupt the > > > > device write has finally completed and the interrupt is no longer > > > > pending. > > > > > > > > That sequence used to happen a lot, and it was "fixed" by adding an > > > > l2cache sync (basically a "drain write buffer") just before an EOI. You > > > > sometimes still see an occasional spurious interrupt, but it shouldn't > > > > be happening multiple times per second as seen in the logging above. > > > > > > Hm, interesting. I remember your discussion about it on IRC. The > > > atheros code ends up working around this in the driver by doing a read > > > from the ISR after writing out bits to clear things, so the clear is > > > flushed out. > > > > > > I wonder if we should be asking all device drivers to be doing their > > > own ISR flushing before returning from their interrupt handlers. > > > > This is required on PCI (that you do a read to clear the posted/pending > > write)... So, IMO, yes, all device drivers should do the proper > > clearing of their writes to the ISR... > > > > But a driver can't assume that a read is sufficient on all architectures > it may run on. bus_space_barrier() is the right way. Also, it's not Except that I don't think even on PCI a bus_space_barrier is sufficient... I was just looking at i386's implementation of bus_space_barrier and it just does a stack access... This won't be sufficient to clear any PCI bridges that may have the write still pending... There's also the issue that if __GNUCLIKE_ASM is not defined, the code will compile w/o ANY barrier, not even a compiler_membar... We should probably add a #else #error please add your compilers equivalent... > just that a barrier is needed before exiting an isr... if the isr uses > locking to synchronize with hardware access by the non-isr part of the > driver, then the bus space barriers are needed in conjunction with the > locking, so that, for example, the isr's usage of the hardware is truly > complete before a lock is released. > > Scattered amongst 10 of the roughly 240 drivers in sys/dev there are 42 > calls to bus_space_barrier(). Getting all the drivers fixed will be a > big job. That's why I was thinking along the lines of an > architecture-wide workaround with potentially a way to mark a driver as > not needing the workaround once we get the fixing underway. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 06:45:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40C3FB89; Sat, 6 Sep 2014 06:45:59 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D31861C40; Sat, 6 Sep 2014 06:45:58 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id j7so11853999qaq.17 for ; Fri, 05 Sep 2014 23:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=q/9Zl3yeVKpUi5JbapGpZC7N5vffawvXH3GNbdN+YmU=; b=QoNdjxW/d5CTw+oUJzfBQD25CPRNH6CdZdHLaDUhomHfLb/h2Wn3MufyUYS8OeiEpe zkmVq319ApWENZP8JV01H7iZa0wzm+TzVFXTkcQGPXJKrfPsez/WJcLqw/7ehR8OIDdK IGKITyExH/RHcoQJOORHfiXsjWGgfIqv9Lj/73M5aPB+g39l0wSCxil0tx3YZfDWstxD JtdAM+Nft+4Lx228tN7iyLKURWko2SdX6gOvppIlZEe4YTjqzzty/g+IyDY9bbZHwhYK 0Q03dRH0OVJIG+OO2naPBU2qntMDekUXOkfGXxNKU5gYlsCeGCTur8J4Ct5Iv+7ZNYGJ d7Bg== MIME-Version: 1.0 X-Received: by 10.224.36.4 with SMTP id r4mr24828594qad.69.1409985957157; Fri, 05 Sep 2014 23:45:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Fri, 5 Sep 2014 23:45:57 -0700 (PDT) In-Reply-To: <20140906045403.GU82175@funkthat.com> References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> <20140906011526.GT82175@funkthat.com> <1409967197.1150.339.camel@revolution.hippie.lan> <20140906045403.GU82175@funkthat.com> Date: Fri, 5 Sep 2014 23:45:57 -0700 X-Google-Sender-Auth: F7DNqGLBUZJq9YeyWfVnpFUTo2o Message-ID: Subject: Re: Cubieboard: Spurious interrupt detected From: Adrian Chadd To: Ian Lepore , Adrian Chadd , "freebsd-arm@freebsd.org" , ticso@cicely.de Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 06:45:59 -0000 On 5 September 2014 21:54, John-Mark Gurney wrote: > Ian Lepore wrote this message on Fri, Sep 05, 2014 at 19:33 -0600: >> On Fri, 2014-09-05 at 18:15 -0700, John-Mark Gurney wrote: >> > Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 17:44 -0700: >> > > On 5 September 2014 16:11, Ian Lepore wrote: >> > > > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote: >> > > >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote: >> > > >> > And another problem: every now and then the kernel says something like that: >> > > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected >> > > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected >> > > >> > Sep 5 19:23:46 last message repeated 10 times >> > > >> > >> > > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the >> > > >> > problem here? >> > > >> >> > > >> Means something generates inetrrupts, which are not handled by a driver. >> > > >> Could be the cause for your load problem too. >> > > >> >> > > > >> > > > No, that would be stray interrupts. Spurious interrupts happen when an >> > > > interrupt is asserted, but by time the processor asks the interrupt >> > > > controller for the current active interrupt, it is no longer active. >> > > > >> > > > One way it can happen is when an interrupt handler writes to a device to >> > > > clear a pending interrupt and that write takes a long time to complete >> > > > because the device is on a slow bus, and the interrupt controller is on >> > > > a faster bus. The EOI to the controller outraces the device write that >> > > > would clear the pending interrupt condition, so the processor is >> > > > re-interrupted, but by time it asks for the next active interrupt the >> > > > device write has finally completed and the interrupt is no longer >> > > > pending. >> > > > >> > > > That sequence used to happen a lot, and it was "fixed" by adding an >> > > > l2cache sync (basically a "drain write buffer") just before an EOI. You >> > > > sometimes still see an occasional spurious interrupt, but it shouldn't >> > > > be happening multiple times per second as seen in the logging above. >> > > >> > > Hm, interesting. I remember your discussion about it on IRC. The >> > > atheros code ends up working around this in the driver by doing a read >> > > from the ISR after writing out bits to clear things, so the clear is >> > > flushed out. >> > > >> > > I wonder if we should be asking all device drivers to be doing their >> > > own ISR flushing before returning from their interrupt handlers. >> > >> > This is required on PCI (that you do a read to clear the posted/pending >> > write)... So, IMO, yes, all device drivers should do the proper >> > clearing of their writes to the ISR... >> > >> >> But a driver can't assume that a read is sufficient on all architectures >> it may run on. bus_space_barrier() is the right way. Also, it's not > > Except that I don't think even on PCI a bus_space_barrier is sufficient... It isn't. The device itself may have FIFOs and internal busses that also need to be flushed. > I was just looking at i386's implementation of bus_space_barrier and > it just does a stack access... This won't be sufficient to clear any > PCI bridges that may have the write still pending... Right. The memory barrier semantics right now don't at all guarantee that bus and device FIFOs have actually been flushed. So I don't think doing it using the existing bus space barrier semantics is 'right'. For interrupts, it's highly likely that we do actually need device drivers to read from their interrupt register to ensure the update has been posted before returning. That's better than causing entire L2 cache flushes. Question is - can we expose this somehow as a generic device method, so the higher bus layers can actually do something with it, or should we just leave it to device drivers to correctly do? (Also - do any of the freebsd device driver books or the handbook mention this?) -a From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 06:46:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1BF0BC5; Sat, 6 Sep 2014 06:46:50 +0000 (UTC) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F3011C47; Sat, 6 Sep 2014 06:46:50 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id z60so12868201qgd.34 for ; Fri, 05 Sep 2014 23:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=nKW5AS6eRbxXgVt7/aNXmQI9IZaO9CeyYScce/eUgX0=; b=IceCJyhdwO9J+yLPrDbe9ACi56ys3awb1QmyO+lS3ri/eN78wS19nMBSdv1srkSoj/ gKaz3YyYULZVS6WU8sxo3Vf82MYfYfvE0VhmqOOOuF5KMY+KtgwgCN0phS0ZEuWsTBjL e3HO3xwdV5uQJuOMbDIc1UwDUBXuJw3ydP/2w4vtCV7cH0XPwL3/VlPMGxzR6DGNOQSi gaTfBGkV9QXcMt8flB0t0xQt6tzZcsw91L7LKlSLNnsdDJ+pZqMGHUiVOMZhR7DOB4ML fXCQwN6oNEO9hfHIqmSeHbQMzyokZSQAlygY8VX8tH09P1/An7A0jsRiWj1B+hTMtalO BVRQ== MIME-Version: 1.0 X-Received: by 10.224.167.72 with SMTP id p8mr25493458qay.62.1409986009676; Fri, 05 Sep 2014 23:46:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Fri, 5 Sep 2014 23:46:49 -0700 (PDT) In-Reply-To: References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> <20140906011526.GT82175@funkthat.com> <1409967197.1150.339.camel@revolution.hippie.lan> <20140906045403.GU82175@funkthat.com> Date: Fri, 5 Sep 2014 23:46:49 -0700 X-Google-Sender-Auth: e6glz1xUzH_oGRjYbJqn6r6KMU8 Message-ID: Subject: Re: Cubieboard: Spurious interrupt detected From: Adrian Chadd To: Ian Lepore , Adrian Chadd , "freebsd-arm@freebsd.org" , ticso@cicely.de Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 06:46:51 -0000 seems not: https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/driverbasics-net.html ... is very, very bare. :( -a From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 07:11:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC774CEC; Sat, 6 Sep 2014 07:11:06 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6ECC61E36; Sat, 6 Sep 2014 07:11:05 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s867Atiw032022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2014 00:10:55 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s867At7l032021; Sat, 6 Sep 2014 00:10:55 -0700 (PDT) (envelope-from jmg) Date: Sat, 6 Sep 2014 00:10:55 -0700 From: John-Mark Gurney To: Adrian Chadd Subject: Re: Cubieboard: Spurious interrupt detected Message-ID: <20140906071055.GW82175@funkthat.com> Mail-Followup-To: Adrian Chadd , Ian Lepore , "freebsd-arm@freebsd.org" , ticso@cicely.de References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> <20140906011526.GT82175@funkthat.com> <1409967197.1150.339.camel@revolution.hippie.lan> <20140906045403.GU82175@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 06 Sep 2014 00:10:55 -0700 (PDT) Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 07:11:06 -0000 Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 23:45 -0700: > On 5 September 2014 21:54, John-Mark Gurney wrote: > > Ian Lepore wrote this message on Fri, Sep 05, 2014 at 19:33 -0600: > >> On Fri, 2014-09-05 at 18:15 -0700, John-Mark Gurney wrote: > >> > Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 17:44 -0700: > >> > > On 5 September 2014 16:11, Ian Lepore wrote: > >> > > > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote: > >> > > >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote: > >> > > >> > And another problem: every now and then the kernel says something like that: > >> > > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected > >> > > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected > >> > > >> > Sep 5 19:23:46 last message repeated 10 times > >> > > >> > > >> > > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the > >> > > >> > problem here? > >> > > >> > >> > > >> Means something generates inetrrupts, which are not handled by a driver. > >> > > >> Could be the cause for your load problem too. > >> > > >> > >> > > > > >> > > > No, that would be stray interrupts. Spurious interrupts happen when an > >> > > > interrupt is asserted, but by time the processor asks the interrupt > >> > > > controller for the current active interrupt, it is no longer active. > >> > > > > >> > > > One way it can happen is when an interrupt handler writes to a device to > >> > > > clear a pending interrupt and that write takes a long time to complete > >> > > > because the device is on a slow bus, and the interrupt controller is on > >> > > > a faster bus. The EOI to the controller outraces the device write that > >> > > > would clear the pending interrupt condition, so the processor is > >> > > > re-interrupted, but by time it asks for the next active interrupt the > >> > > > device write has finally completed and the interrupt is no longer > >> > > > pending. > >> > > > > >> > > > That sequence used to happen a lot, and it was "fixed" by adding an > >> > > > l2cache sync (basically a "drain write buffer") just before an EOI. You > >> > > > sometimes still see an occasional spurious interrupt, but it shouldn't > >> > > > be happening multiple times per second as seen in the logging above. > >> > > > >> > > Hm, interesting. I remember your discussion about it on IRC. The > >> > > atheros code ends up working around this in the driver by doing a read > >> > > from the ISR after writing out bits to clear things, so the clear is > >> > > flushed out. > >> > > > >> > > I wonder if we should be asking all device drivers to be doing their > >> > > own ISR flushing before returning from their interrupt handlers. > >> > > >> > This is required on PCI (that you do a read to clear the posted/pending > >> > write)... So, IMO, yes, all device drivers should do the proper > >> > clearing of their writes to the ISR... > >> > > >> > >> But a driver can't assume that a read is sufficient on all architectures > >> it may run on. bus_space_barrier() is the right way. Also, it's not > > > > Except that I don't think even on PCI a bus_space_barrier is sufficient... > > It isn't. > > The device itself may have FIFOs and internal busses that also need to > be flushed. Partly this depends upon which bus the device is on... Though we'd like our drivers to be bus agnostic, items like these force them not to be... > > I was just looking at i386's implementation of bus_space_barrier and > > it just does a stack access... This won't be sufficient to clear any > > PCI bridges that may have the write still pending... > > Right. The memory barrier semantics right now don't at all guarantee > that bus and device FIFOs have actually been flushed. > > So I don't think doing it using the existing bus space barrier > semantics is 'right'. For interrupts, it's highly likely that we do > actually need device drivers to read from their interrupt register to > ensure the update has been posted before returning. That's better than > causing entire L2 cache flushes. > > Question is - can we expose this somehow as a generic device method, > so the higher bus layers can actually do something with it, or should > we just leave it to device drivers to correctly do? Sadly, I really think it's up to the device driver... Are we going to require the driver to expose a register that gets read before we EOI the interrupt? what if another bus does it differently? > (Also - do any of the freebsd device driver books or the handbook mention this?) Well, when I did a quick search, I found an HP Writing PCI Driver guide... Googled: "pci read after write isr" and the first link was: http://h21007.www2.hp.com/portal/download/files/unprot/ddk/ddg/chap8.pdf PCI Transaction Ordering - Write Side Effects And I just checked the old D&I (haven't gotten my new one yet) and it's device driver section is quite small and doesn't mention this issue... But it also doesn't talk about how to setup interrupts or resources... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 07:14:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE65AD33; Sat, 6 Sep 2014 07:14:41 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E1F51E42; Sat, 6 Sep 2014 07:14:40 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s867EWcE032073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2014 00:14:33 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s867EWbI032072; Sat, 6 Sep 2014 00:14:32 -0700 (PDT) (envelope-from jmg) Date: Sat, 6 Sep 2014 00:14:32 -0700 From: John-Mark Gurney To: Adrian Chadd Subject: Re: Cubieboard: Spurious interrupt detected Message-ID: <20140906071432.GX82175@funkthat.com> Mail-Followup-To: Adrian Chadd , Ian Lepore , "freebsd-arm@freebsd.org" , ticso@cicely.de References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> <20140906011526.GT82175@funkthat.com> <1409967197.1150.339.camel@revolution.hippie.lan> <20140906045403.GU82175@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 06 Sep 2014 00:14:33 -0700 (PDT) Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 07:14:41 -0000 Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 23:46 -0700: > seems not: > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/driverbasics-net.html > > ... is very, very bare. > > :( You need to look at: https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/pci.html and: https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/isa-driver-intr.html At least there's a bit more info, but not much... Device drivers are hard.. :( That's why I don't use one for my ATSC tuner... It's ethernet attached.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 07:53:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77F36703 for ; Sat, 6 Sep 2014 07:53:33 +0000 (UTC) Received: from bein.link (unknown [IPv6:2a02:2770:3:0:21a:4aff:fee6:9061]) by mx1.freebsd.org (Postfix) with ESMTP id 403C41258 for ; Sat, 6 Sep 2014 07:53:33 +0000 (UTC) Received: from quad.localnet (unknown [188.134.8.193]) by bein.link (Postfix) with ESMTPSA id A80C94051D; Sat, 6 Sep 2014 09:53:30 +0200 (CEST) From: Maxim V FIlimonov To: freebsd-arm@freebsd.org Subject: Re: Cubieboard: load average above 2 Date: Sat, 06 Sep 2014 11:53:30 +0400 Message-ID: <1559689.QT1haudsVa@quad> User-Agent: KMail/4.12.5 (FreeBSD/10.0-RELEASE-p7; KDE/4.12.5; amd64; ; ) In-Reply-To: <6240427.cmkfEefv07@quad> References: <27116175.UDSoyStjsX@quad> <20140905215555.GK3196@cicely7.cicely.de> <6240427.cmkfEefv07@quad> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 07:53:33 -0000 On Saturday 06 September 2014 02:08:22 Maxim V FIlimonov wrote: > I took away I2C support from the kernel config, and now LA is about 1.3 > which is also a bit too much, but not that big, AFAIK. Could i2c be the > problem here? That's funny: after a couple of buildkernels without i2c support, the load average is over 2 again. -- wbr, Maxim Filimonov che@bein.link From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 14:54:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B88A961; Sat, 6 Sep 2014 14:54:34 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC8A51F41; Sat, 6 Sep 2014 14:54:33 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XQHNo-000NLe-E3; Sat, 06 Sep 2014 14:54:32 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s86EsTgk015484; Sat, 6 Sep 2014 08:54:29 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19bNdtkz2KtSFzds53WRCoj X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Cubieboard: Spurious interrupt detected From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> <20140906011526.GT82175@funkthat.com> <1409967197.1150.339.camel@revolution.hippie.lan> <20140906045403.GU82175@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Sat, 06 Sep 2014 08:54:28 -0600 Message-ID: <1410015268.1150.351.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 14:54:34 -0000 On Fri, 2014-09-05 at 23:45 -0700, Adrian Chadd wrote: > On 5 September 2014 21:54, John-Mark Gurney wrote: > > Ian Lepore wrote this message on Fri, Sep 05, 2014 at 19:33 -0600: > >> On Fri, 2014-09-05 at 18:15 -0700, John-Mark Gurney wrote: > >> > Adrian Chadd wrote this message on Fri, Sep 05, 2014 at 17:44 -0700: > >> > > On 5 September 2014 16:11, Ian Lepore wrote: > >> > > > On Fri, 2014-09-05 at 23:57 +0200, Bernd Walter wrote: > >> > > >> On Sat, Sep 06, 2014 at 01:43:23AM +0400, Maxim V FIlimonov wrote: > >> > > >> > And another problem: every now and then the kernel says something like that: > >> > > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected > >> > > >> > Sep 5 19:22:37 kernel: Spurious interrupt detected > >> > > >> > Sep 5 19:23:46 last message repeated 10 times > >> > > >> > > >> > > >> > I've heard that FreeBSD happens to do that on ARM devices. What could be the > >> > > >> > problem here? > >> > > >> > >> > > >> Means something generates inetrrupts, which are not handled by a driver. > >> > > >> Could be the cause for your load problem too. > >> > > >> > >> > > > > >> > > > No, that would be stray interrupts. Spurious interrupts happen when an > >> > > > interrupt is asserted, but by time the processor asks the interrupt > >> > > > controller for the current active interrupt, it is no longer active. > >> > > > > >> > > > One way it can happen is when an interrupt handler writes to a device to > >> > > > clear a pending interrupt and that write takes a long time to complete > >> > > > because the device is on a slow bus, and the interrupt controller is on > >> > > > a faster bus. The EOI to the controller outraces the device write that > >> > > > would clear the pending interrupt condition, so the processor is > >> > > > re-interrupted, but by time it asks for the next active interrupt the > >> > > > device write has finally completed and the interrupt is no longer > >> > > > pending. > >> > > > > >> > > > That sequence used to happen a lot, and it was "fixed" by adding an > >> > > > l2cache sync (basically a "drain write buffer") just before an EOI. You > >> > > > sometimes still see an occasional spurious interrupt, but it shouldn't > >> > > > be happening multiple times per second as seen in the logging above. > >> > > > >> > > Hm, interesting. I remember your discussion about it on IRC. The > >> > > atheros code ends up working around this in the driver by doing a read > >> > > from the ISR after writing out bits to clear things, so the clear is > >> > > flushed out. > >> > > > >> > > I wonder if we should be asking all device drivers to be doing their > >> > > own ISR flushing before returning from their interrupt handlers. > >> > > >> > This is required on PCI (that you do a read to clear the posted/pending > >> > write)... So, IMO, yes, all device drivers should do the proper > >> > clearing of their writes to the ISR... > >> > > >> > >> But a driver can't assume that a read is sufficient on all architectures > >> it may run on. bus_space_barrier() is the right way. Also, it's not > > > > Except that I don't think even on PCI a bus_space_barrier is sufficient... > > It isn't. > > The device itself may have FIFOs and internal busses that also need to > be flushed. > The question isn't whether or not it's sufficient, because it's necessary. The device driver knows what its hardware requirements are and should meet them. It doesn't not know what its parent bus requirements are, and that's why it must call bus_space_barrier() to handle architecture needs above the level of the device itself. > > I was just looking at i386's implementation of bus_space_barrier and > > it just does a stack access... This won't be sufficient to clear any > > PCI bridges that may have the write still pending... > > Right. The memory barrier semantics right now don't at all guarantee > that bus and device FIFOs have actually been flushed. > The fact that some architectures don't implement bus_space_barrier() in a way that's useful for that architecture is just a bug. It doesn't change the fact that bus_space_barrier() is currently our only defined MI interface to barriers in device space. > So I don't think doing it using the existing bus space barrier > semantics is 'right'. For interrupts, it's highly likely that we do > actually need device drivers to read from their interrupt register to > ensure the update has been posted before returning. That's better than > causing entire L2 cache flushes. > Where did you see code that does an "entire L2 cache flush"? You didn't, you just saw a function name and made assumptions about what it does. The fact is, it does what is necessary for the architecture. It also happens to do what a write-then-read does on armv6, but that's exactly the sort of assumption that should NOT be written into MI code. > Question is - can we expose this somehow as a generic device method, > so the higher bus layers can actually do something with it, or should > we just leave it to device drivers to correctly do? > In what way is that not EXACTLY whas bus_space_barrier() is defined to do? I've got to say, I don't understand all this pushback. We have one function defined already that's intended to be the machine-independant way to ensure that any previous access to hardware using bus_space reads and writes has completed, so why all this argument that it is not the function to use? -- Ian > (Also - do any of the freebsd device driver books or the handbook mention this?) > > > > -a From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 16:20:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9A87698 for ; Sat, 6 Sep 2014 16:20:09 +0000 (UTC) Received: from bein.link (vps-6159-8629.cloud.tilaa.com [37.252.124.82]) by mx1.freebsd.org (Postfix) with ESMTP id 6F78318CB for ; Sat, 6 Sep 2014 16:20:08 +0000 (UTC) Received: from quad.localnet (unknown [188.134.8.193]) by bein.link (Postfix) with ESMTPSA id A97664051D for ; Sat, 6 Sep 2014 18:20:05 +0200 (CEST) From: Maxim V FIlimonov To: freebsd-arm@freebsd.org Subject: Re: Cubieboard: Spurious interrupt detected Date: Sat, 06 Sep 2014 20:20:05 +0400 Message-ID: <42729580.BghYiSHhz3@quad> User-Agent: KMail/4.12.5 (FreeBSD/10.0-RELEASE-p7; KDE/4.12.5; amd64; ; ) In-Reply-To: <2279481.3MX4OEDuCl@quad> References: <2279481.3MX4OEDuCl@quad> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 16:20:09 -0000 On Saturday 06 September 2014 01:43:23 Maxim V FIlimonov wrote: > And another problem: every now and then the kernel says something like that: > Sep 5 19:22:37 kernel: Spurious interrupt detected > Sep 5 19:22:37 kernel: Spurious interrupt detected > Sep 5 19:23:46 last message repeated 10 times > > I've heard that FreeBSD happens to do that on ARM devices. What could be the > problem here? A small detail: when I turn off SMP in the kernel config, the message disappears, but everything becomes too slow to operate. -- wbr, Maxim Filimonov che@bein.link From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 16:47:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32086EBE for ; Sat, 6 Sep 2014 16:47:21 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 060301B7E for ; Sat, 6 Sep 2014 16:47:20 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XQJ8x-000Hdh-Ej; Sat, 06 Sep 2014 16:47:19 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s86GlIMP015722; Sat, 6 Sep 2014 10:47:18 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+cUuJPjAd4WC036enwvtU0 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Cubieboard: Spurious interrupt detected From: Ian Lepore To: Maxim V FIlimonov In-Reply-To: <42729580.BghYiSHhz3@quad> References: <2279481.3MX4OEDuCl@quad> <42729580.BghYiSHhz3@quad> Content-Type: text/plain; charset="us-ascii" Date: Sat, 06 Sep 2014 10:47:17 -0600 Message-ID: <1410022037.1150.360.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 16:47:21 -0000 On Sat, 2014-09-06 at 20:20 +0400, Maxim V FIlimonov wrote: > On Saturday 06 September 2014 01:43:23 Maxim V FIlimonov wrote: > > And another problem: every now and then the kernel says something like that: > > Sep 5 19:22:37 kernel: Spurious interrupt detected > > Sep 5 19:22:37 kernel: Spurious interrupt detected > > Sep 5 19:23:46 last message repeated 10 times > > > > I've heard that FreeBSD happens to do that on ARM devices. What could be the > > problem here? > > A small detail: when I turn off SMP in the kernel config, the message > disappears, but everything becomes too slow to operate. Post the output of 'vmstat -i' -- it sounds like maybe there's an interrupt handler monopolizing the system, or a timer that's firing at way too high a rate, or something like that. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 16:52:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52F0592; Sat, 6 Sep 2014 16:52:56 +0000 (UTC) Received: from bein.link (vps-6159-8629.cloud.tilaa.com [37.252.124.82]) by mx1.freebsd.org (Postfix) with ESMTP id 178B51C34; Sat, 6 Sep 2014 16:52:55 +0000 (UTC) Received: from quad.localnet (unknown [188.134.8.193]) by bein.link (Postfix) with ESMTPSA id EA64E4051D; Sat, 6 Sep 2014 18:52:53 +0200 (CEST) From: Maxim V FIlimonov To: Ian Lepore Subject: Re: Cubieboard: Spurious interrupt detected Date: Sat, 06 Sep 2014 20:52:53 +0400 Message-ID: <2229212.jhyveZzD6x@quad> User-Agent: KMail/4.12.5 (FreeBSD/10.0-RELEASE-p7; KDE/4.12.5; amd64; ; ) In-Reply-To: <1410022037.1150.360.camel@revolution.hippie.lan> References: <2279481.3MX4OEDuCl@quad> <42729580.BghYiSHhz3@quad> <1410022037.1150.360.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 16:52:56 -0000 On Saturday 06 September 2014 10:47:17 Ian Lepore wrote: > On Sat, 2014-09-06 at 20:20 +0400, Maxim V FIlimonov wrote: > > On Saturday 06 September 2014 01:43:23 Maxim V FIlimonov wrote: > > > And another problem: every now and then the kernel says something like > > > that: Sep 5 19:22:37 kernel: Spurious interrupt detected > > > Sep 5 19:22:37 kernel: Spurious interrupt detected > > > Sep 5 19:23:46 last message repeated 10 times > > > > > > I've heard that FreeBSD happens to do that on ARM devices. What could be > > > the problem here? > > > > A small detail: when I turn off SMP in the kernel config, the message > > disappears, but everything becomes too slow to operate. > > Post the output of 'vmstat -i' -- it sounds like maybe there's an > interrupt handler monopolizing the system, or a timer that's firing at > way too high a rate, or something like that. Here it is: root@cubie:~ # vmstat -i interrupt total rate irq0: ipi 10968 15 irq3: ipi 293 0 irq6: ipi 786 1 irq33: uart0 217 0 irq54: a10_timer0 1629 2 irq71: ehci0 5791 8 irq87: emac0 308 0 Total 19992 28 -- wbr, Maxim Filimonov che@bein.link From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 20:21:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFCD7B5A for ; Sat, 6 Sep 2014 20:21:52 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7046B10C0 for ; Sat, 6 Sep 2014 20:21:52 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id rl12so383625iec.24 for ; Sat, 06 Sep 2014 13:21:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=LgQXrDhnlEY7qFXPqEG3iQQpgsCRW/xKVqAGtxvKono=; b=GiFGFbjGynR7Q6dZt9nnPRWC4eQAE4gIYRH8AztF6Zg1CBF4of0y3D0b/sV8iIs3Qc +m06FyfA4/Jd3OEAPJ3tSNdJinYD5STuPbbkjDK9LB52IgEN+mXox9ijgquyY5bO+i4T vQjwEOVmHqBE0P8Wue8DtOYmDkP1LXlCu+JpUCyGnNljNxmfswwJqFqzO3cpYW1xxqfd 7HynaM4XgL9HlRGitEhIPTU7A6QnLORCVbVl5uxaNXpjrhzcdZtTT4CB17VqzCoBqYiH BaxJUIAD3W0ZYPq07HV/8cCE3fzUg9JHfslS+Ij3mydTaBz/S7Rfyj3u2ThkicDmZ0jQ KTvg== X-Gm-Message-State: ALoCoQkUdsikc0ODG21ZCz0Xq6hvFnTEUFnKQJsIcC1JCCdP+XKB0w4/zn2bjhUJ1EGCoufmYbOj X-Received: by 10.50.57.68 with SMTP id g4mr13801607igq.48.1410034905207; Sat, 06 Sep 2014 13:21:45 -0700 (PDT) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id an1sm4824431igc.7.2014.09.06.13.21.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Sep 2014 13:21:44 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_699FFA10-C065-44E0-B38E-7E259302D757"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Cubieboard: Spurious interrupt detected From: Warner Losh In-Reply-To: <1410015268.1150.351.camel@revolution.hippie.lan> Date: Sat, 6 Sep 2014 14:20:51 -0600 Message-Id: References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> <20140906011526.GT82175@funkthat.com> <1409967197.1150.339.camel@revolution.hippie.lan> <20140906045403.GU82175@funkthat.com> <1410015268.1150.351.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 20:21:52 -0000 --Apple-Mail=_699FFA10-C065-44E0-B38E-7E259302D757 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 6, 2014, at 8:54 AM, Ian Lepore wrote: > On Fri, 2014-09-05 at 23:45 -0700, Adrian Chadd wrote: >> The device itself may have FIFOs and internal busses that also need = to >> be flushed. >>=20 >=20 > The question isn't whether or not it's sufficient, because it's > necessary. The device driver knows what its hardware requirements are > and should meet them. It doesn't not know what its parent bus > requirements are, and that's why it must call bus_space_barrier() to > handle architecture needs above the level of the device itself. Yea, all that bus_space_barrier() does is say =93We=92ve made sure that the CPU and all other bridges between the CPU and the device have any buffered writes pushed to the device.=94 If the device has = additional FIFOs and other things, that=92s 100% on the device writer. >>> I was just looking at i386's implementation of bus_space_barrier and >>> it just does a stack access... This won't be sufficient to clear = any >>> PCI bridges that may have the write still pending... >>=20 >> Right. The memory barrier semantics right now don't at all guarantee >> that bus and device FIFOs have actually been flushed. >>=20 > The fact that some architectures don't implement bus_space_barrier() = in > a way that's useful for that architecture is just a bug. It doesn't > change the fact that bus_space_barrier() is currently our only defined > MI interface to barriers in device space. Agreed. But PCI defines that reads flush out all prior writes. >> So I don't think doing it using the existing bus space barrier >> semantics is 'right'. For interrupts, it's highly likely that we do >> actually need device drivers to read from their interrupt register to >> ensure the update has been posted before returning. That's better = than >> causing entire L2 cache flushes. >>=20 >=20 > Where did you see code that does an "entire L2 cache flush"? You > didn't, you just saw a function name and made assumptions about what = it > does. The fact is, it does what is necessary for the architecture. = It > also happens to do what a write-then-read does on armv6, but that's > exactly the sort of assumption that should NOT be written into MI > code. =20 Yea, a bus barrier just means a temporal ordering. The exact strength of that guarantee is a bit fuzzy, but generally it means we know things are done. L2 is usually not an issue, because we have the devices mapped uncached. As for reading the ISR, that is device dependent. When using MSI things = are different because the status is pushed to the host and you get the info = from reading the host memory. Ideally, you=92d want to write to ack them without = having to do a read over PCIe, but even that=92s not always required (and on such = devices they would correct without bus barriers). Newer devices have been = designed to avoid round-trips over the PCIe bus and having semantics that matter. >> Question is - can we expose this somehow as a generic device method, >> so the higher bus layers can actually do something with it, or should >> we just leave it to device drivers to correctly do? >>=20 >=20 > In what way is that not EXACTLY whas bus_space_barrier() is defined to > do? >=20 > I've got to say, I don't understand all this pushback. We have one > function defined already that's intended to be the machine-independant > way to ensure that any previous access to hardware using bus_space = reads > and writes has completed, so why all this argument that it is not the > function to use? I agree with Ian here. If we=92ve messed up, we need to fix that. But = for the most part, devices that are in embedded land actually do the right thing = (more often than not). If we=92re doing something wrong on coherent architectures = that accidentally works, we should fix that. I may disagree with Ian about the need for some of the flushing based on = the notion that we should fix the drivers. I feel it just makes the problem = persist. Things should be more visibly broken. Ian thinks things should work, and I have a hard = time arguing with that position even if I disagree :). Warner --Apple-Mail=_699FFA10-C065-44E0-B38E-7E259302D757 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUC2yjAAoJEGwc0Sh9sBEAjnEP/Rtr/UOfDdL2MoI1GNT8NzPf S15PjHdUHT2ucH/Iv+3hp9Az8ZKPzl+Phmvf7Jaf6mPBCvW0TXDVCxGYs5m3CMpR zNQiuS1cSNZreDjVQhiW39qmqIIKJ0xJYyHTdqq4iNh+9KVsGQpSQ3l493Xg4IFS SnbzO8Fia7lmypiIz/HDbEo8u9jtSqDBCIEeNyU7BEZezeNJ3TinvFsB1u3SgWDc YyHf4s64W6qKzzuWYTTQQ6QbjCImESvGJhvgx8FToUW2Mp350maqY1ivVfkF5l5p 3e1rLhQGNkDK1XUZLBja4BggtJxNrid3AlBM0si+k8/y9V32VSpQ5lG/i/2HyCQR E1Y/eItljaOeNaustVUZsU1MqNvQS/PYs8WKHEh/X52/JOw0nOiWz3E8uihzAxcZ SRg3s7xxBrvvQPKVkC1x+cH+OBi5NJACHrfSxF8rwzLl2W1qQsJmasTqn8H/Djsi EgojcbB3iJvP6BnrOVXlqAcmxdudjEAt2c5/mQPAzyc7xmMuZJ0DMeE+YJxHKdeX 7n1bJplwsNwmcW/w3ZHTmg8tr1c9ruIogaBbyY5d8YFoGrW6erIIoDuJ3p1A3GZI zm73d2piiG7e948FUtXXnkCBYQ9Ozvz+RJyoRW2VGAaPtsDvDbVgwBxjhmDpNVgC Ky3hCOw5O/reIlDSBlg4 =Jo1+ -----END PGP SIGNATURE----- --Apple-Mail=_699FFA10-C065-44E0-B38E-7E259302D757-- From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 21:19:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9513329F for ; Sat, 6 Sep 2014 21:19:03 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F32217B7 for ; Sat, 6 Sep 2014 21:19:03 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XQNNt-0008eS-JA; Sat, 06 Sep 2014 21:19:01 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s86LIx31017027; Sat, 6 Sep 2014 15:19:00 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+Jn6WshhHD238v/InB6bHu X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Cubieboard: Spurious interrupt detected From: Ian Lepore To: Warner Losh In-Reply-To: References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> <20140906011526.GT82175@funkthat.com> <1409967197.1150.339.camel@revolution.hippie.lan> <20140906045403.GU82175@funkthat.com> <1410015268.1150.351.camel@revolution.hippie.lan> Content-Type: text/plain; charset="iso-8859-13" Date: Sat, 06 Sep 2014 15:18:59 -0600 Message-ID: <1410038339.1150.381.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s86LIx31017027 Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 21:19:03 -0000 On Sat, 2014-09-06 at 14:20 -0600, Warner Losh wrote: > On Sep 6, 2014, at 8:54 AM, Ian Lepore wrote: >=20 > > On Fri, 2014-09-05 at 23:45 -0700, Adrian Chadd wrote: > >> The device itself may have FIFOs and internal busses that also need = to > >> be flushed. > >>=20 > >=20 > > The question isn't whether or not it's sufficient, because it's > > necessary. The device driver knows what its hardware requirements ar= e > > and should meet them. It doesn't not know what its parent bus > > requirements are, and that's why it must call bus_space_barrier() to > > handle architecture needs above the level of the device itself. >=20 > Yea, all that bus_space_barrier() does is say =B4We=FFve made sure that > the CPU and all other bridges between the CPU and the device have > any buffered writes pushed to the device.=A1 If the device has addition= al FIFOs > and other things, that=FFs 100% on the device writer. >=20 > >>> I was just looking at i386's implementation of bus_space_barrier an= d > >>> it just does a stack access... This won't be sufficient to clear a= ny > >>> PCI bridges that may have the write still pending... > >>=20 > >> Right. The memory barrier semantics right now don't at all guarantee > >> that bus and device FIFOs have actually been flushed. > >>=20 > > The fact that some architectures don't implement bus_space_barrier() = in > > a way that's useful for that architecture is just a bug. It doesn't > > change the fact that bus_space_barrier() is currently our only define= d > > MI interface to barriers in device space. >=20 > Agreed. But PCI defines that reads flush out all prior writes. >=20 > >> So I don't think doing it using the existing bus space barrier > >> semantics is 'right'. For interrupts, it's highly likely that we do > >> actually need device drivers to read from their interrupt register t= o > >> ensure the update has been posted before returning. That's better th= an > >> causing entire L2 cache flushes. > >>=20 > >=20 > > Where did you see code that does an "entire L2 cache flush"? You > > didn't, you just saw a function name and made assumptions about what = it > > does. The fact is, it does what is necessary for the architecture. = It > > also happens to do what a write-then-read does on armv6, but that's > > exactly the sort of assumption that should NOT be written into MI > > code. =20 >=20 > Yea, a bus barrier just means a temporal ordering. The exact strength > of that guarantee is a bit fuzzy, but generally it means we know things > are done. L2 is usually not an issue, because we have the devices mappe= d > uncached. >=20 It more complicated than that in the armv6/7 world. They are mapped as Device memory which means uncached but writes are buffered (using some rules specifically designed to work for memory mapped devices, such as disabling write-combining so that N writes issued results in N writes at the device). The buffering happens at the L2 cache controller, so when you need to ensure that the write has reached the hardware you can make a call to an L2 routine that blocks until the write has completed. On armv7 you can also do a read of any address within the same 1K address block as the write you want to have completed, but I don't think any driver should contain code like that unless it's for soc-specific hardware. Like code for an on-chip timer might be able to make that assumption, but an EHCI driver couldn't. > As for reading the ISR, that is device dependent. When using MSI things= are > different because the status is pushed to the host and you get the info= from reading > the host memory. Ideally, you=FFd want to write to ack them without hav= ing to do > a read over PCIe, but even that=FFs not always required (and on such de= vices > they would correct without bus barriers). Newer devices have been desig= ned > to avoid round-trips over the PCIe bus and having semantics that matter. >=20 > >> Question is - can we expose this somehow as a generic device method, > >> so the higher bus layers can actually do something with it, or shoul= d > >> we just leave it to device drivers to correctly do? > >>=20 > >=20 > > In what way is that not EXACTLY whas bus_space_barrier() is defined t= o > > do? > >=20 > > I've got to say, I don't understand all this pushback. We have one > > function defined already that's intended to be the machine-independan= t > > way to ensure that any previous access to hardware using bus_space re= ads > > and writes has completed, so why all this argument that it is not the > > function to use? >=20 > I agree with Ian here. If we=FFve messed up, we need to fix that. But f= or the most > part, devices that are in embedded land actually do the right thing (mo= re often > than not). If we=FFre doing something wrong on coherent architectures t= hat accidentally > works, we should fix that. >=20 > I may disagree with Ian about the need for some of the flushing based o= n the notion > that we should fix the drivers. I feel it just makes the problem persis= t. Things should > be more visibly broken. Ian thinks things should work, and I have a har= d time arguing > with that position even if I disagree :). It has to work because if it doesn't then they'll start running linux on imx6 at work and I'll have to look for a new job. :) -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Sep 6 23:09:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C744EEFA for ; Sat, 6 Sep 2014 23:09:43 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86A731113 for ; Sat, 6 Sep 2014 23:09:42 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id tp5so2279665ieb.15 for ; Sat, 06 Sep 2014 16:09:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=d3CwqV9fB1SnfSfAKUIBjNzgH9vaywIkHvqgMc7XSn4=; b=RCOxSU1/ZDYPZvEmejTRpwjdEtosgQImP1fyOkkjUJvDPuUu9OBaWMpMG15UEPoEzt SR5BXmIdHoASNm33YBj6anrHjfpccPGCRKHlx9EX0JRJrm6OfAPtGw12v2NOXrYVPMcu E+hKng0g8AD6+0e5Sqgbql9h+PS3zydbQKG1NfgsWzRPCdKdQKCfNq2cXvIA9V0gH/oO LIwtVG1FY4od299Fkb3wkwRaegQvBAIesvd++0C8AtslpM83nVDn++vYMceUnLL2o3gh DVFQlO+NKbexak9LgdG68M+piR3jJK0hHXZfH5+zlFQsGJpMSW9MmP68fEnyLliDFH80 n8XQ== X-Gm-Message-State: ALoCoQkcolMb5NxRAFAi0aH7tu5yRhhamvxzEyjftvcZ6IOoXP8F5mJQiy2LxYJo8EksvPzkbjLD X-Received: by 10.43.152.211 with SMTP id kx19mr23017640icc.8.1410044597674; Sat, 06 Sep 2014 16:03:17 -0700 (PDT) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id x9sm7144094igw.15.2014.09.06.16.03.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Sep 2014 16:03:16 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_9927933C-4FE5-4F9B-BC07-7FE6E249B737"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Cubieboard: Spurious interrupt detected From: Warner Losh In-Reply-To: <1410038339.1150.381.camel@revolution.hippie.lan> Date: Sat, 6 Sep 2014 17:03:14 -0600 Message-Id: <39CA4EF7-10CD-4BF5-B1FC-74107FDF5525@bsdimp.com> References: <2279481.3MX4OEDuCl@quad> <20140905215702.GL3196@cicely7.cicely.de> <1409958716.1150.321.camel@revolution.hippie.lan> <20140906011526.GT82175@funkthat.com> <1409967197.1150.339.camel@revolution.hippie.lan> <20140906045403.GU82175@funkthat.com> <1410015268.1150.351.camel@revolution.hippie.lan> <1410038339.1150.381.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 23:09:43 -0000 --Apple-Mail=_9927933C-4FE5-4F9B-BC07-7FE6E249B737 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 6, 2014, at 3:18 PM, Ian Lepore wrote: > On Sat, 2014-09-06 at 14:20 -0600, Warner Losh wrote: >> On Sep 6, 2014, at 8:54 AM, Ian Lepore wrote: >>=20 >>> On Fri, 2014-09-05 at 23:45 -0700, Adrian Chadd wrote: >>>> The device itself may have FIFOs and internal busses that also need = to >>>> be flushed. >>>>=20 >>>=20 >>> The question isn't whether or not it's sufficient, because it's >>> necessary. The device driver knows what its hardware requirements = are >>> and should meet them. It doesn't not know what its parent bus >>> requirements are, and that's why it must call bus_space_barrier() to >>> handle architecture needs above the level of the device itself. >>=20 >> Yea, all that bus_space_barrier() does is say =93We=B4ve made sure = that >> the CPU and all other bridges between the CPU and the device have >> any buffered writes pushed to the device.=94 If the device has = additional FIFOs >> and other things, that=B4s 100% on the device writer. >>=20 >>>>> I was just looking at i386's implementation of bus_space_barrier = and >>>>> it just does a stack access... This won't be sufficient to clear = any >>>>> PCI bridges that may have the write still pending... >>>>=20 >>>> Right. The memory barrier semantics right now don't at all = guarantee >>>> that bus and device FIFOs have actually been flushed. >>>>=20 >>> The fact that some architectures don't implement bus_space_barrier() = in >>> a way that's useful for that architecture is just a bug. It doesn't >>> change the fact that bus_space_barrier() is currently our only = defined >>> MI interface to barriers in device space. >>=20 >> Agreed. But PCI defines that reads flush out all prior writes. >>=20 >>>> So I don't think doing it using the existing bus space barrier >>>> semantics is 'right'. For interrupts, it's highly likely that we do >>>> actually need device drivers to read from their interrupt register = to >>>> ensure the update has been posted before returning. That's better = than >>>> causing entire L2 cache flushes. >>>>=20 >>>=20 >>> Where did you see code that does an "entire L2 cache flush"? You >>> didn't, you just saw a function name and made assumptions about what = it >>> does. The fact is, it does what is necessary for the architecture. = It >>> also happens to do what a write-then-read does on armv6, but that's >>> exactly the sort of assumption that should NOT be written into MI >>> code. =20 >>=20 >> Yea, a bus barrier just means a temporal ordering. The exact strength >> of that guarantee is a bit fuzzy, but generally it means we know = things >> are done. L2 is usually not an issue, because we have the devices = mapped >> uncached. >>=20 >=20 > It more complicated than that in the armv6/7 world. They are mapped = as > Device memory which means uncached but writes are buffered (using some > rules specifically designed to work for memory mapped devices, such as > disabling write-combining so that N writes issued results in N writes = at > the device). The buffering happens at the L2 cache controller, so = when > you need to ensure that the write has reached the hardware you can = make > a call to an L2 routine that blocks until the write has completed. >=20 > On armv7 you can also do a read of any address within the same 1K > address block as the write you want to have completed, but I don't = think > any driver should contain code like that unless it's for soc-specific > hardware. Like code for an on-chip timer might be able to make that > assumption, but an EHCI driver couldn=92t. Wouldn=92t the bus_space_barrier() block until the write to the bus = space area flushes? Or does our API make that kinda tough to implement? >> As for reading the ISR, that is device dependent. When using MSI = things are >> different because the status is pushed to the host and you get the = info from reading >> the host memory. Ideally, you=B4d want to write to ack them without = having to do >> a read over PCIe, but even that=B4s not always required (and on such = devices >> they would correct without bus barriers). Newer devices have been = designed >> to avoid round-trips over the PCIe bus and having semantics that = matter. >>=20 >>>> Question is - can we expose this somehow as a generic device = method, >>>> so the higher bus layers can actually do something with it, or = should >>>> we just leave it to device drivers to correctly do? >>>>=20 >>>=20 >>> In what way is that not EXACTLY whas bus_space_barrier() is defined = to >>> do? >>>=20 >>> I've got to say, I don't understand all this pushback. We have one >>> function defined already that's intended to be the = machine-independant >>> way to ensure that any previous access to hardware using bus_space = reads >>> and writes has completed, so why all this argument that it is not = the >>> function to use? >>=20 >> I agree with Ian here. If we=B4ve messed up, we need to fix that. But = for the most >> part, devices that are in embedded land actually do the right thing = (more often >> than not). If we=B4re doing something wrong on coherent architectures = that accidentally >> works, we should fix that. >>=20 >> I may disagree with Ian about the need for some of the flushing based = on the notion >> that we should fix the drivers. I feel it just makes the problem = persist. Things should >> be more visibly broken. Ian thinks things should work, and I have a = hard time arguing >> with that position even if I disagree :). >=20 > It has to work because if it doesn't then they'll start running linux = on > imx6 at work and I'll have to look for a new job. :) Like I said, it is hard to argue with it=85 I=92m curious if you know which drivers are broken? Is this list of = known broken long, or is this just a case of =93at least one was broken, so let=92s be = conservative for now to get the thing working?=94 If the latter, is there any way we can see what=92s = broken and get bugzillas going on them? Warner --Apple-Mail=_9927933C-4FE5-4F9B-BC07-7FE6E249B737 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUC5KyAAoJEGwc0Sh9sBEAZ64QALYr9ohs/tGuxFhwaeLHx0Wd PDigVhcByuL8YizWsMes3guIsXDM8jA+sex0iiSJFZzphK3reuADNHfqrui2zvLj FBMQAPUr9Bel2hOoRg2JCwAtOtx2R8Q600vtfhO48dykPCdvnRoVu3cXiUxbXRaK RLHksKYxJ9qLQLKvqRdLtOT2P1g5wPjf0y9w/GfUPQ2C2DMGaU+L3uLuNfo2i8R/ mE1xFGxeDEH6ScMjIY4P9XMVRo5I1zrtkq970QnNVnwHLZzYSLEhYnwdUjnKuBfR OmHp9N6Zaz3dPK2iSz358u3s3+G1Z4hsvDi+n56fb7N3xrY+iew+O5yWKhoxyM9k m9cxBBMtk8Ed0FXAswV/ZzEvBbi+u0W5VqLy9KB+rRjuL1jLdRu+3tu9lqBJznUn EgtkTWMnJ0OL/mbScxuwXJy3u7KcnfxCNrrj0ROkGsyM1Lh1qrTPMR2ofaEode43 3jc4darxrGs3rAGjEwRkWEqxpGSzLFozKpH1uHfCi/PdHRY46mYjWxf1Fao1RdA2 lvn90SKeGo1eguUKeLBgBtGQ+wjASF7qgfrLqrTEZqUlLlJuKYlkucEuZ+VMH4u0 +zXs0ES1CytGk4S1yHdxm41Fo9GuNAR+qn5dYI6ujwD2aUGekUBDB59hnZcR11bO g/RCojsLnPk1sJ6uNLHS =Icgr -----END PGP SIGNATURE----- --Apple-Mail=_9927933C-4FE5-4F9B-BC07-7FE6E249B737--