From bugmaster at FreeBSD.org Mon Nov 2 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 2 11:07:32 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200911021106.nA2B6nRq033528@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From Matthias.Reyelt at brunel.de Wed Nov 4 09:14:04 2009 From: Matthias.Reyelt at brunel.de (Matthias Reyelt) Date: Wed Nov 4 09:14:10 2009 Subject: Marvell Kirkwood 6281 mge1 interface Message-ID: <200911040956.09749.Matthias.Reyelt@brunel.de> Hi, I have tried to use the second network interface on an Marvell OpenRD board with BETA3. The mge1 interfaces seems to have problems with it's phy. I am not familiar with kernel debugging, I've only seen that mii_phy_probe() detects the bmsr register at 0x09, but readreg returns 0xffff. Has anybody got that second interface up already? Regards Matthias -- Dr.-Ing. Matthias Reyelt Master Software Designer Brunel GmbH Bereich Communications Daimlerring 9 31135 Hildesheim Tel: +49 5121 1760 805 Fax: +49 5121 1760 999 email: Matthias.Reyelt@brunel.de Internet: www.brunel.de Hauptsitz: Airport City, Hermann-K?hl-Str. 1, 28199 Bremen Amtsgericht Bremen HRB 16935 General Manager: Johan Arie van Barneveld From raj at semihalf.com Wed Nov 4 09:37:55 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Wed Nov 4 09:38:02 2009 Subject: Marvell Kirkwood 6281 mge1 interface In-Reply-To: <200911040956.09749.Matthias.Reyelt@brunel.de> References: <200911040956.09749.Matthias.Reyelt@brunel.de> Message-ID: On 2009-11-04, at 09:56, Matthias Reyelt wrote: > I have tried to use the second network interface on an Marvell > OpenRD board > with BETA3. The mge1 interfaces seems to have problems with it's phy. > > I am not familiar with kernel debugging, I've only seen that > mii_phy_probe() > detects the bmsr register at 0x09, but readreg returns 0xffff. > > Has anybody got that second interface up already? Please paste the log with errors you're seeing. Rafal From Matthias.Reyelt at brunel.de Wed Nov 4 10:42:36 2009 From: Matthias.Reyelt at brunel.de (Matthias Reyelt) Date: Wed Nov 4 10:42:43 2009 Subject: Marvell Kirkwood 6281 mge1 interface In-Reply-To: References: <200911040956.09749.Matthias.Reyelt@brunel.de> Message-ID: <200911041142.32349.Matthias.Reyelt@brunel.de> Hi, here is the boot log. I have added several device_printf's and removed the 0xffff condition in mii_phy_probe() Matthias ge0: at mem 0xf1072000-0xf1073fff irq 12,13,14,11,46 on mbus0 mge0: bpf attached mge0: Ethernet address: 00:50:43:01:a2:5e mge0: Now probing PHY mge0: mii_phy_probe: Starting to probe PHYs: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 8:31085 ok miibus0: (miibus_probe) is the mii device mge0: (miibus_probe) is the eth device miibus0: Probing phy 0 miibus0: No phy found miibus0: Probing phy 1 miibus0: No phy found miibus0: Probing phy 2 miibus0: No phy found miibus0: Probing phy 3 miibus0: No phy found miibus0: Probing phy 4 miibus0: No phy found miibus0: Probing phy 5 miibus0: No phy found miibus0: Probing phy 6 miibus0: No phy found miibus0: Probing phy 7 miibus0: No phy found miibus0: Probing phy 8 miibus0: found one. Now looking for ID miibus0: Probing phy 9 miibus0: No phy found miibus0: Probing phy a miibus0: No phy found miibus0: Probing phy b miibus0: No phy found miibus0: Probing phy c miibus0: No phy found miibus0: Probing phy d miibus0: No phy found miibus0: Probing phy e miibus0: No phy found miibus0: Probing phy f miibus0: No phy found miibus0: Probing phy 10 miibus0: No phy found miibus0: Probing phy 11 miibus0: No phy found miibus0: Probing phy 12 miibus0: No phy found miibus0: Probing phy 13 miibus0: No phy found miibus0: Probing phy 14 miibus0: No phy found miibus0: Probing phy 15 miibus0: No phy found miibus0: Probing phy 16 miibus0: No phy found miibus0: Probing phy 17 miibus0: No phy found miibus0: Probing phy 18 miibus0: No phy found miibus0: Probing phy 19 miibus0: No phy found miibus0: Probing phy 1a miibus0: No phy found miibus0: Probing phy 1b miibus0: No phy found miibus0: Probing phy 1c miibus0: No phy found miibus0: Probing phy 1d miibus0: No phy found miibus0: Probing phy 1e miibus0: No phy found miibus0: Probing phy 1f miibus0: No phy found miibus0: on mge0 miibus0: miibus_attach e1000phy0: Probing e1000 PHY e1000phy0: Probing e1000 PHY e1000phy0: PHY 8 on miibus0 mge0: Writing 6800 to reg 10 on phy 8 mge0: Writing 70 to reg 14 on phy 8 mge0: Writing 9140 to reg 0 on phy 8 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto mge0: [MPSAFE] mge0: [ITHREAD] mge0: [MPSAFE] mge0: [ITHREAD] mge1: at mem 0xf1076000-0xf1077fff irq 16,17,18,15,46 on mbus0 mge1: bpf attached mge1: Ethernet address: 00:50:43:01:a2:5f mge1: Now probing PHY mge1: mii_phy_probe: Starting to probe PHYs: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 8:0 9:65535 ok miibus1: (miibus_probe) is the mii device mge1: (miibus_probe) is the eth device miibus1: Probing phy 0 miibus1: No phy found miibus1: Probing phy 1 miibus1: No phy found miibus1: Probing phy 2 miibus1: No phy found miibus1: Probing phy 3 miibus1: No phy found miibus1: Probing phy 4 miibus1: No phy found miibus1: Probing phy 5 miibus1: No phy found miibus1: Probing phy 6 miibus1: No phy found miibus1: Probing phy 7 miibus1: No phy found miibus1: Probing phy 8 miibus1: No phy found miibus1: Probing phy 9 miibus1: found one. Now looking for ID miibus1: Probing phy a miibus1: No phy found miibus1: Probing phy b miibus1: No phy found miibus1: Probing phy c miibus1: No phy found miibus1: Probing phy d miibus1: No phy found miibus1: Probing phy e miibus1: No phy found miibus1: Probing phy f miibus1: No phy found miibus1: Probing phy 10 miibus1: No phy found miibus1: Probing phy 11 miibus1: No phy found miibus1: Probing phy 12 miibus1: No phy found miibus1: Probing phy 13 miibus1: No phy found miibus1: Probing phy 14 miibus1: No phy found miibus1: Probing phy 15 miibus1: No phy found miibus1: Probing phy 16 miibus1: No phy found miibus1: Probing phy 17 miibus1: No phy found miibus1: Probing phy 18 miibus1: No phy found miibus1: Probing phy 19 miibus1: No phy found miibus1: Probing phy 1a miibus1: No phy found miibus1: Probing phy 1b miibus1: No phy found miibus1: Probing phy 1c miibus1: No phy found miibus1: Probing phy 1d miibus1: No phy found miibus1: Probing phy 1e miibus1: No phy found miibus1: Probing phy 1f miibus1: No phy found miibus1: on mge1 miibus1: miibus_attach e1000phy1: Probing e1000 PHY ukphy0: PHY 9 on miibus1 ukphy0: OUI 0x3fffff, model 0x003f, rev. 15 mge1: Writing 8400 to reg 0 on phy 9 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 100baseT4, 1000baseSX, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX, auto mge1: [MPSAFE] Am Mittwoch 04 November 2009 10:37:52 schrieb Rafal Jaworowski: > > On 2009-11-04, at 09:56, Matthias Reyelt wrote: > > > I have tried to use the second network interface on an Marvell > > OpenRD board > > with BETA3. The mge1 interfaces seems to have problems with it's phy. > > > > I am not familiar with kernel debugging, I've only seen that > > mii_phy_probe() > > detects the bmsr register at 0x09, but readreg returns 0xffff. > > > > Has anybody got that second interface up already? > > Please paste the log with errors you're seeing. > > Rafal > > From raj at semihalf.com Thu Nov 5 10:46:09 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Thu Nov 5 10:46:15 2009 Subject: Marvell Kirkwood 6281 mge1 interface In-Reply-To: <200911041142.32349.Matthias.Reyelt@brunel.de> References: <200911040956.09749.Matthias.Reyelt@brunel.de> <200911041142.32349.Matthias.Reyelt@brunel.de> Message-ID: On 2009-11-04, at 11:42, Matthias Reyelt wrote: > Hi, > > here is the boot log. I have added several device_printf's and > removed the > 0xffff condition in mii_phy_probe() Before trying to identify PHY problems, can you share all your changes (a diff)? So far all Kirkwood based boards we support had only a single active Ethernet port, so the Kirkwood platform config only accounted for a single MAC, have you altered the obio_devices[] in particular? Rafal From Matthias.Reyelt at brunel.de Thu Nov 5 13:24:06 2009 From: Matthias.Reyelt at brunel.de (Matthias Reyelt) Date: Thu Nov 5 13:24:16 2009 Subject: Marvell Kirkwood 6281 mge1 interface In-Reply-To: References: <200911040956.09749.Matthias.Reyelt@brunel.de> <200911041142.32349.Matthias.Reyelt@brunel.de> Message-ID: <200911051423.52940.Matthias.Reyelt@brunel.de> Hi, here is the diff. The removal of the debug options were due to some performance tests I did before. Am Donnerstag 05 November 2009 11:46:06 schrieb Rafal Jaworowski: > > On 2009-11-04, at 11:42, Matthias Reyelt wrote: > > > Hi, > > > > here is the boot log. I have added several device_printf's and > > removed the > > 0xffff condition in mii_phy_probe() > > Before trying to identify PHY problems, can you share all your > changes (a diff)? So far all Kirkwood based boards we support had only > a single active Ethernet port, so the Kirkwood platform config only Yes, the OpenRD client is rather new, and the board contains an awful lot of interfaces (and no fan), really great. > accounted for a single MAC, have you altered the obio_devices[] in > particular? I did add the second interface to the obio_devices[], and adjusted the defines according to the header files as good as I knew (although I have been aware that there would be a reason for the missing interface :-) Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: changes-kw2ndif.diff Type: text/x-diff Size: 5451 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20091105/fd1c1f3e/changes-kw2ndif.bin From raj at semihalf.com Thu Nov 5 14:16:11 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Thu Nov 5 14:16:18 2009 Subject: Marvell Kirkwood 6281 mge1 interface In-Reply-To: <200911051423.52940.Matthias.Reyelt@brunel.de> References: <200911040956.09749.Matthias.Reyelt@brunel.de> <200911041142.32349.Matthias.Reyelt@brunel.de> <200911051423.52940.Matthias.Reyelt@brunel.de> Message-ID: On 2009-11-05, at 14:23, Matthias Reyelt wrote: >> Before trying to identify PHY problems, can you share all your >> changes (a diff)? So far all Kirkwood based boards we support had >> only >> a single active Ethernet port, so the Kirkwood platform config only > Yes, the OpenRD client is rather new, and the board contains an > awful lot of > interfaces (and no fan), really great. Can you eye inspect the PHY chip connected to the second MAC, is it E1116 as well? BTW: if you managed to get OpenRD to boot, please send a full booting log for reference. >> accounted for a single MAC, have you altered the obio_devices[] in >> particular? > I did add the second interface to the obio_devices[], and adjusted > the defines > according to the header files as good as I knew (although I have > been aware > that there would be a reason for the missing interface :-) Your diff looks fine, however there is missing at least one important piece: decode window for the second ETH is not being configured. Try adding the change below. Rafal diff --git a/sys/arm/mv/common.c b/sys/arm/mv/common.c index 76758be..b60d0ac 100644 --- a/sys/arm/mv/common.c +++ b/sys/arm/mv/common.c @@ -204,7 +204,8 @@ soc_decode_win(void) decode_win_cpu_setup(); decode_win_usb_setup(); decode_win_eth_setup(MV_ETH0_BASE); - if (dev == MV_DEV_MV78100 || dev == MV_DEV_MV78100_Z0) + if (dev == MV_DEV_88F6281 || + dev == MV_DEV_MV78100 || dev == MV_DEV_MV78100_Z0) decode_win_eth_setup(MV_ETH1_BASE); if (dev == MV_DEV_88F6281 || dev == MV_DEV_MV78100 || dev == MV_DEV_MV78100_Z0) From Matthias.Reyelt at brunel.de Thu Nov 5 15:24:02 2009 From: Matthias.Reyelt at brunel.de (Matthias Reyelt) Date: Thu Nov 5 15:24:08 2009 Subject: Marvell Kirkwood 6281 mge1 interface In-Reply-To: References: <200911040956.09749.Matthias.Reyelt@brunel.de> <200911051423.52940.Matthias.Reyelt@brunel.de> Message-ID: <200911051623.56583.Matthias.Reyelt@brunel.de> Hi, the second phy is an E1116 as well. I have applied the patch to common.h There is still something missing. Here is the boot log. There are some other error messages, e.g. from pcib. Matthias -------------------------------snip----------------------------------------------------------------- __ __ _ _ | \/ | __ _ _ ____ _____| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_| \_/ \___|_|_| _ _ ____ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/ |____/ \___/ \___/ \__| ** MARVELL BOARD: OpenRD-Client LE U-Boot 1.1.4 (May 18 2009 - 13:33:10) Marvell version: 3.4.16 U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CEE80 Soc: 88F6281 A0 (DDR2) CPU running @ 1200Mhz L2 running @ 400Mhz SysClock = 400Mhz , TClock = 200Mhz DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 DRAM CS[0] base 0x00000000 size 256MB DRAM CS[1] base 0x10000000 size 256MB DRAM Total size 512MB 16bit width Flash: 0 kB Addresses 8M - 0M are saved for the U-Boot usage. Mem malloc Initialization (8M - 7M): Done NAND:512 MB Checking for BootROM Routine Errors No. of BootROM routine retries: 0 No error found Running POST... DDR2 data bus test PASSED DDR2 address bus test PASSED UART 1 internal loopback test on baudrate 9600 PASSED UART 1 internal loopback test on baudrate 19200 PASSED UART 1 internal loopback test on baudrate 115200 PASSED Device: 0, Size: 512 MB, Page Size: 2 KB, Block Size: 128 KB NAND detection test PASSED Bad Block: 1a5a0000 NAND bad-block detection test PASSED RTC test PASSED 6/6 tests PASSED POST completed CPU : Marvell Feroceon (Rev 1) Streaming disabled Write allocate disabled Module 0 is AUDIO Module 1 is RGMII USB 0: host mode PCI 0: PCI Express Root Complex Interface PEX interface detected Link X1 Net: egiga0 [PRIME], egiga1 Hit any key to stop autoboot: 0 Marvell>> tftpboot 900000 kernel.bin Using egiga0 device TFTP from server 172.16.102.81; our IP address is 172.16.102.69 Filename 'kernel.bin'. Load address: 0x900000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############################################################### done Bytes transferred = 2980852 (2d7bf4 hex) Marvell>> go 900000 ## Starting application at 0x00900000 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 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 8.0-RC2 #15 r198539:198785M: Thu Nov 5 15:46:38 CET 2009 root@bcspc5.bcs.brunel.local:/usr/obj/arm/arm/src/8-stable/8/sys/DB-88F6XXX Preloaded elf kernel "elf kernel" at 0xc0bf11d8. CPU: Feroceon 88FR131 rev 1 (write-through core) WB enabled EABT branch prediction enabled 16KB/32B 4-way Instruction cache 16KB/32B 4-way write-back-locking-C Data cache real memory = 536870912 (512 MB) Physical memory chunk(s): 00000000 - 0x8fffff, 9437184 bytes (2304 pages) 0xce7000 - 0x1f64bfff, 513167360 bytes (125285 pages) avail memory = 520372224 (496 MB) SOC: (0x6281:0x02) Marvell 88F6281 rev A0, TClock 200MHz nfslock: pseudo-device mem: null: random: mbus0: on motherboard ic0: at mem 0xf1020200-0xf102023b on mbus0 timer0: at mem 0xf1020300-0xf102032f irq 1 on mbus0 timer0: [FILTER] rtc0: at mem 0xf1010300-0xf1010307 on mbus0 rtc0: registered as a time-of-day clock (resolution 1000000us) gpio0: at mem 0xf1010100-0xf101011f irq 35,36,37,38,39,40,41 on mbus0 gpio0: [FILTER] gpio0: [FILTER] gpio0: [FILTER] gpio0: [FILTER] gpio0: [FILTER] gpio0: [FILTER] gpio0: [FILTER] uart0: <16550 or compatible> at mem 0xf1012000-0xf101201f irq 33 on mbus0 uart0: [FILTER] uart0: fast interrupt uart0: console (115740,n,8,1) uart1: <16550 or compatible> at mem 0xf1012100-0xf101211f irq 34 on mbus0 uart1: [FILTER] uart1: fast interrupt ehci0: at mem 0xf1050000-0xf1050fff irq 48,19 on mbus0 ehci0: [FILTER] ehci0: [MPSAFE] ehci0: [ITHREAD] ehci0: 5.24 GL USB-2 workaround enabled usbus0: EHCI version 1.0 usbus0: set host controller mode usbus0: on ehci0 mge0: at mem 0xf1072000-0xf1073fff irq 12,13,14,11,46 on mbus0 mge0: bpf attached mge0: Ethernet address: 00:50:43:01:a2:5e mge0: Now probing PHY mge0: mii_phy_probe: Starting to probe PHYs: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 8:31085 ok miibus0: (miibus_probe) is the mii device mge0: (miibus_probe) is the eth device miibus0: Probing phy 0 miibus0: No phy found miibus0: Probing phy 1 miibus0: No phy found miibus0: Probing phy 2 miibus0: No phy found miibus0: Probing phy 3 miibus0: No phy found miibus0: Probing phy 4 miibus0: No phy found miibus0: Probing phy 5 miibus0: No phy found miibus0: Probing phy 6 miibus0: No phy found miibus0: Probing phy 7 miibus0: No phy found miibus0: Probing phy 8 miibus0: found one. Now looking for ID miibus0: Probing phy 9 miibus0: No phy found miibus0: Probing phy a miibus0: No phy found miibus0: Probing phy b miibus0: No phy found miibus0: Probing phy c miibus0: No phy found miibus0: Probing phy d miibus0: No phy found miibus0: Probing phy e miibus0: No phy found miibus0: Probing phy f miibus0: No phy found miibus0: Probing phy 10 miibus0: No phy found miibus0: Probing phy 11 miibus0: No phy found miibus0: Probing phy 12 miibus0: No phy found miibus0: Probing phy 13 miibus0: No phy found miibus0: Probing phy 14 miibus0: No phy found miibus0: Probing phy 15 miibus0: No phy found miibus0: Probing phy 16 miibus0: No phy found miibus0: Probing phy 17 miibus0: No phy found miibus0: Probing phy 18 miibus0: No phy found miibus0: Probing phy 19 miibus0: No phy found miibus0: Probing phy 1a miibus0: No phy found miibus0: Probing phy 1b miibus0: No phy found miibus0: Probing phy 1c miibus0: No phy found miibus0: Probing phy 1d miibus0: No phy found miibus0: Probing phy 1e miibus0: No phy found miibus0: Probing phy 1f miibus0: No phy found miibus0: on mge0 miibus0: miibus_attach e1000phy0: Probing e1000 PHY e1000phy0: Probing e1000 PHY e1000phy0: PHY 8 on miibus0 mge0: Writing 6800 to reg 10 on phy 8 mge0: Writing 70 to reg 14 on phy 8 mge0: Writing 9140 to reg 0 on phy 8 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto mge0: [MPSAFE] mge0: [ITHREAD] mge0: [MPSAFE] mge0: [ITHREAD] mge1: at mem 0xf1076000-0xf1077fff irq 16,17,18,15,46 on mbus0 mge1: bpf attached mge1: Ethernet address: 00:50:43:01:a2:5f mge1: Now probing PHY mge1: mii_phy_probe: Starting to probe PHYs: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 8:0 9:65535 ok miibus1: (miibus_probe) is the mii device mge1: (miibus_probe) is the eth device miibus1: Probing phy 0 miibus1: No phy found miibus1: Probing phy 1 miibus1: No phy found miibus1: Probing phy 2 miibus1: No phy found miibus1: Probing phy 3 miibus1: No phy found miibus1: Probing phy 4 miibus1: No phy found miibus1: Probing phy 5 miibus1: No phy found miibus1: Probing phy 6 miibus1: No phy found miibus1: Probing phy 7 miibus1: No phy found miibus1: Probing phy 8 miibus1: No phy found miibus1: Probing phy 9 miibus1: found one. Now looking for ID miibus1: Probing phy a miibus1: No phy found miibus1: Probing phy b miibus1: No phy found miibus1: Probing phy c miibus1: No phy found miibus1: Probing phy d miibus1: No phy found miibus1: Probing phy e miibus1: No phy found miibus1: Probing phy f miibus1: No phy found miibus1: Probing phy 10 miibus1: No phy found miibus1: Probing phy 11 miibus1: No phy found miibus1: Probing phy 12 miibus1: No phy found miibus1: Probing phy 13 miibus1: No phy found miibus1: Probing phy 14 miibus1: No phy found miibus1: Probing phy 15 miibus1: No phy found miibus1: Probing phy 16 miibus1: No phy found miibus1: Probing phy 17 miibus1: No phy found miibus1: Probing phy 18 miibus1: No phy found miibus1: Probing phy 19 miibus1: No phy found miibus1: Probing phy 1a miibus1: No phy found miibus1: Probing phy 1b miibus1: No phy found miibus1: Probing phy 1c miibus1: No phy found miibus1: Probing phy 1d miibus1: No phy found miibus1: Probing phy 1e miibus1: No phy found miibus1: Probing phy 1f miibus1: No phy found miibus1: on mge1 miibus1: miibus_attach e1000phy1: Probing e1000 PHY ukphy0: PHY 9 on miibus1 ukphy0: OUI 0x3fffff, model 0x003f, rev. 15 mge1: Writing 8400 to reg 0 on phy 9 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 100baseT4, 1000baseSX, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX, auto mge1: [MPSAFE] mge1: [ITHREAD] mge1: [MPSAFE] mge1: [ITHREAD] twsi0: at mem 0xf1011000-0xf101101f on mbus0 iicbus0: on twsi0 iic0: on iicbus0 sata0: at mem 0xf1080000-0xf1085fff irq 21 on mbus0 sata0: [MPSAFE] sata0: [ITHREAD] ata0: on sata0 ata0: hardware reset ... ata0: SATA connect timeout status=00000000 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on sata0 ata1: hardware reset ... ata1: SATA connect timeout status=00000000 ata1: [MPSAFE] ata1: [ITHREAD] pcib0: at mem 0xf1040000-0xf1041fff on mbus0 pcib0: PCI IO/Memory space exhausted device_attach: pcib0 attach returned 12 Timecounter "CPU Timer" frequency 200000000 Hz quality 1000 Timecounters tick every 10.000 msec lo0: bpf attached ata0: Identifying devices: 00000000 ata0: New devices: 00000000 ata1: Identifying devices: 00000000 ata1: New devices: 00000000 usbus0: 480Mbps High Speed USB v2.0 bootpc_init: wired to interface 'mge0' Sending DHCP Discover packet from interface mge0 (00:50:43:01:a2:5e) ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered mge0: link state changed to UP ugen0.2: at usbus0 uhub1: on usbus0 uhub1: 7 ports with 7 removable, self powered DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 Received DHCP Offer packet on mge0 from 172.16.102.81 (accepted) (no root path) Sending DHCP Request packet from interface mge0 (00:50:43:01:a2:5e) DHCP/BOOTP timeout for server 255.255.255.255 Received DHCP Ack packet on mge0 from 172.16.102.81 (accepted) (got root path) mge0 at 172.16.102.69 server 172.16.102.81 boot file kernel.bin subnet mask 255.255.255.0 router 172.16.102.3 rootfs 172.16.102.81:/nfsroot/arm-8-le hostname open-rd1 Adjusted interface mge0 ifa_del_loopback_route: deletion failed Trying to mount root from nfs: NFS ROOT: 172.16.102.81:/nfsroot/arm-8-le ct_to_ts([2009-11-05 14:55:27]) = 1257432927.000000000 ct_to_ts([2009-11-05 14:55:27]) = 1257432927.000000000 start_init: trying /sbin/init Enter full pathname of shell or RETURN for /bin/sh: # exit Interface mge0 IP-Address 172.16.102.69 Broadcast 172.16.102.255 Entropy harvesting: interrupts ethernet point_to_point kickstart. Fast boot: skipping disk checks. mount_nfs: can't update /var/db/mounttab for 172.16.102.81:/nfsroot/arm-8-le Starting Network: lo0. route: writing to routing socket: File exists add net default: gateway 172.16.102.3: route already in table devd: cannot open pid file: Operation not supported Mounting NFS file systems:mount_nfs: can't update /var/db/mounttab for 172.16.102.81:/nfsvar/arm-8-le . syslogd: cannot open pid file: Operation not supported Recovering vi editor sessions:. Starting local daemons:rc.local . Nov 5 14:55:45 open-rd1 sm-mta[820]: nA5EtjYr000820: SYSERR(root): hash map "Alias0": missing map file /etc/mail/aliases.db: No such file or directory Nov 5 14:55:45 open-rd1 sm-mta[829]: nA5EtjYr000820: SYSERR(root): hash map "Alias0": missing map file /etc/mail/aliases.db: No such file or directory Thu Nov 5 14:55:46 UTC 2009 FreeBSD/arm (open-rd1) (ttyu0) login: ----------------------------------snip--------------------------------------------------- Am Donnerstag 05 November 2009 15:16:08 schrieb Rafal Jaworowski: > > On 2009-11-05, at 14:23, Matthias Reyelt wrote: > > >> Before trying to identify PHY problems, can you share all your > >> changes (a diff)? So far all Kirkwood based boards we support had > >> only > >> a single active Ethernet port, so the Kirkwood platform config only > > Yes, the OpenRD client is rather new, and the board contains an > > awful lot of > > interfaces (and no fan), really great. > > Can you eye inspect the PHY chip connected to the second MAC, is it > E1116 as well? > > BTW: if you managed to get OpenRD to boot, please send a full booting > log for reference. > > >> accounted for a single MAC, have you altered the obio_devices[] in > >> particular? > > I did add the second interface to the obio_devices[], and adjusted > > the defines > > according to the header files as good as I knew (although I have > > been aware > > that there would be a reason for the missing interface :-) > > Your diff looks fine, however there is missing at least one important > piece: decode window for the second ETH is not being configured. Try > adding the change below. > > Rafal > > diff --git a/sys/arm/mv/common.c b/sys/arm/mv/common.c > index 76758be..b60d0ac 100644 > --- a/sys/arm/mv/common.c > +++ b/sys/arm/mv/common.c > @@ -204,7 +204,8 @@ soc_decode_win(void) > decode_win_cpu_setup(); > decode_win_usb_setup(); > decode_win_eth_setup(MV_ETH0_BASE); > - if (dev == MV_DEV_MV78100 || dev == MV_DEV_MV78100_Z0) > + if (dev == MV_DEV_88F6281 || > + dev == MV_DEV_MV78100 || dev == MV_DEV_MV78100_Z0) > decode_win_eth_setup(MV_ETH1_BASE); > if (dev == MV_DEV_88F6281 || dev == MV_DEV_MV78100 || > dev == MV_DEV_MV78100_Z0) > > From gballet at gmail.com Thu Nov 5 20:12:31 2009 From: gballet at gmail.com (Guillaume Ballet) Date: Thu Nov 5 20:12:37 2009 Subject: Initarm function for the Beagleboard Message-ID: Hello list, I have just submitted the first of many files of my port fo FreeBSD the BeagleBoard. This is the initarm function. The cleanup continues and I will submit the rest as soon a possible, but I figured it would be great if I could have some feedback already. Link to the file: http://code.google.com/p/freebsd-bgb/source/browse/trunk/cortexa8_machdep.c For instance, suggestions on how to use DOMAIN_CLIENT instead of DOMAIN_MANAGER on line 265 would be particularly appreciated. Note that this is the backward-compatibility version. I am working on integrating some of the ARMv[67] features, but that will come later. Guillaume From Matthias.Reyelt at brunel.de Fri Nov 6 13:36:06 2009 From: Matthias.Reyelt at brunel.de (Matthias Reyelt) Date: Fri Nov 6 13:36:13 2009 Subject: Marvell Kirkwood 6281 mge1 interface In-Reply-To: <200911051623.56583.Matthias.Reyelt@brunel.de> References: <200911040956.09749.Matthias.Reyelt@brunel.de> <200911051623.56583.Matthias.Reyelt@brunel.de> Message-ID: <200911061435.57673.Matthias.Reyelt@brunel.de> Hi, I have built a linux kernel with some debug code and found out that the base address for the second phy is not at 0x09 but at 0x18. Actually it's in the config files, but I wasn't looking for an extra configuration for this board before. I think this would require a patch to mge_miibus_readreg(), because it's a different mapping. Is that correct? I will do a quick patch on monday to test it. Are there other files that have to be patched, Rafal? Matthias From sales at c2it-hardware.co.za Fri Nov 6 20:05:58 2009 From: sales at c2it-hardware.co.za (C2IT Computer Hardware) Date: Fri Nov 6 20:06:28 2009 Subject: New Arrival of REFURBISHED and NEW Computers & Laptops Message-ID: <20091106120552.118049343@telkomsa.net> From rpaulo at freebsd.org Sun Nov 8 13:30:52 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Sun Nov 8 13:30:58 2009 Subject: SCHED_ULE? Message-ID: Hi, I guess this has been discussed in the past but, can't we turn on ULE on ARM embedded systems ? What's the bottleneck or performance regression (assuming there's one) ? -- Rui Paulo From mlfbsd at ci0.org Mon Nov 9 10:25:45 2009 From: mlfbsd at ci0.org (Olivier Houchard) Date: Mon Nov 9 10:25:52 2009 Subject: SCHED_ULE? In-Reply-To: References: Message-ID: <20091109102704.GA75988@ci0.org> On Sun, Nov 08, 2009 at 01:30:48PM +0000, Rui Paulo wrote: > Hi, > I guess this has been discussed in the past but, can't we turn on ULE > on ARM embedded systems ? What's the bottleneck or performance > regression (assuming there's one) ? > > -- > Rui Paulo Hi, At one point ULE was buggy on arm, but I think it's been fixed like years ago, so it should be safe to use it. Regards, Olivier From bugmaster at FreeBSD.org Mon Nov 9 11:06:48 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 9 11:07:31 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200911091106.nA9B6lwU078930@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From tinderbox at freebsd.org Mon Nov 9 19:47:12 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Nov 9 19:47:38 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <200911091854.nA9Is2dZ054553@freebsd-current.sentex.ca> TB --- 2009-11-09 18:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-09 18:15:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-11-09 18:15:00 - cleaning the object tree TB --- 2009-11-09 18:15:10 - cvsupping the source tree TB --- 2009-11-09 18:15:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2009-11-09 18:15:47 - building world TB --- 2009-11-09 18:15:47 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-09 18:15:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-09 18:15:47 - TARGET=arm TB --- 2009-11-09 18:15:47 - TARGET_ARCH=arm TB --- 2009-11-09 18:15:47 - TZ=UTC TB --- 2009-11-09 18:15:47 - __MAKE_CONF=/dev/null TB --- 2009-11-09 18:15:47 - cd /src TB --- 2009-11-09 18:15:47 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 9 18:15:47 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] (cd /src/rescue/rescue/../../sbin/camcontrol && /usr/bin/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/camcontrol/ depend && /usr/bin/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/camcontrol/ camcontrol.o util.o modeedit.o) rm -f .depend mkdep -f .depend -a -DRESCUE /src/sbin/camcontrol/camcontrol.c /src/sbin/camcontrol/util.c /src/sbin/camcontrol/modeedit.c echo camcontrol: /obj/arm/src/tmp/usr/lib/libc.a /obj/arm/src/tmp/usr/lib/libcam.a /obj/arm/src/tmp/usr/lib/libsbuf.a /obj/arm/src/tmp/usr/lib/libutil.a >> .depend cc -O -pipe -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/camcontrol/camcontrol.c cc1: warnings being treated as errors /src/sbin/camcontrol/camcontrol.c: In function 'atapm': /src/sbin/camcontrol/camcontrol.c:4156: warning: comparison is always true due to limited range of data type *** Error code 1 Stop in /src/sbin/camcontrol. *** Error code 1 Stop in /obj/arm/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-09 18:54:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-09 18:54:02 - ERROR: failed to build world TB --- 2009-11-09 18:54:02 - 1693.77 user 465.28 system 2342.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From sam at errno.com Tue Nov 10 04:49:28 2009 From: sam at errno.com (Sam Leffler) Date: Tue Nov 10 04:49:34 2009 Subject: SCHED_ULE? In-Reply-To: <20091109102704.GA75988@ci0.org> References: <20091109102704.GA75988@ci0.org> Message-ID: <4AF8EE61.8060502@errno.com> Olivier Houchard wrote: > On Sun, Nov 08, 2009 at 01:30:48PM +0000, Rui Paulo wrote: >> Hi, >> I guess this has been discussed in the past but, can't we turn on ULE >> on ARM embedded systems ? What's the bottleneck or performance >> regression (assuming there's one) ? >> >> -- >> Rui Paulo > > Hi, > > At one point ULE was buggy on arm, but I think it's been fixed like years ago, > so it should be safe to use it. Last I measured it was slower than 4BSD on my xscale boards (not much but measurable). This was mostly doing network packet pushing (wired+wireless). Sam From Matthias.Reyelt at brunel.de Tue Nov 10 10:50:07 2009 From: Matthias.Reyelt at brunel.de (Matthias Reyelt) Date: Tue Nov 10 10:50:13 2009 Subject: Marvell MV6281 OpenRD client mge1 In-Reply-To: <200911061435.57673.Matthias.Reyelt@brunel.de> References: <200911040956.09749.Matthias.Reyelt@brunel.de> <200911051623.56583.Matthias.Reyelt@brunel.de> <200911061435.57673.Matthias.Reyelt@brunel.de> Message-ID: <200911101150.00262.Matthias.Reyelt@brunel.de> Hi, I have changed the PHY address for mge1 to 0x18 in the code, and the second PHY is now correctly detected. I can ifconfig the interface and I am able to receive packets. I am not able to send packets yet. If I ping mge1 over the network tcpdump reports the ARP requests and it reports the ARP replies as well. The replies do not reach the cable though. (They aren't sent to mge0 either). I haven't yet found out, where the packets get lost, they seem to pass mge_start_locked() correctly. I will check the register settings. Matthias Am Freitag 06 November 2009 14:35:55 schrieb Matthias Reyelt: > Hi, > > I have built a linux kernel with some debug code and found out that the base > address for the second phy is not at 0x09 but at 0x18. Actually it's in the > config files, but I wasn't looking for an extra configuration for this board > before. > > I think this would require a patch to mge_miibus_readreg(), because it's a > different mapping. Is that correct? > > I will do a quick patch on monday to test it. Are there other files that have > to be patched, Rafal? > > Matthias > > -- Dr.-Ing. Matthias Reyelt Master Software Designer Brunel GmbH Bereich Communications Daimlerring 9 31135 Hildesheim Tel: +49 5121 1760 805 Fax: +49 5121 1760 999 email: Matthias.Reyelt@brunel.de Internet: www.brunel.de Hauptsitz: Airport City, Hermann-K?hl-Str. 1, 28199 Bremen Amtsgericht Bremen HRB 16935 General Manager: Johan Arie van Barneveld From rpaulo at freebsd.org Tue Nov 10 19:57:00 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Tue Nov 10 19:57:07 2009 Subject: SCHED_ULE? In-Reply-To: <4AF8EE61.8060502@errno.com> References: <20091109102704.GA75988@ci0.org> <4AF8EE61.8060502@errno.com> Message-ID: <43EE151E-574E-4A17-9946-0BC5A6B3BC69@freebsd.org> Hi, On 10 Nov 2009, at 04:38, Sam Leffler wrote: > Olivier Houchard wrote: >> On Sun, Nov 08, 2009 at 01:30:48PM +0000, Rui Paulo wrote: >>> Hi, >>> I guess this has been discussed in the past but, can't we turn on ULE on ARM embedded systems ? What's the bottleneck or performance regression (assuming there's one) ? >>> >>> -- >>> Rui Paulo >> Hi, >> At one point ULE was buggy on arm, but I think it's been fixed like years ago, >> so it should be safe to use it. > > Last I measured it was slower than 4BSD on my xscale boards (not much but measurable). This was mostly doing network packet pushing (wired+wireless). I also tested this on the Cambria board and I concluded the same (I used sysbench). -- Rui Paulo From imp at bsdimp.com Tue Nov 10 20:31:18 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Nov 10 20:31:24 2009 Subject: SCHED_ULE? In-Reply-To: <43EE151E-574E-4A17-9946-0BC5A6B3BC69@freebsd.org> References: <20091109102704.GA75988@ci0.org> <4AF8EE61.8060502@errno.com> <43EE151E-574E-4A17-9946-0BC5A6B3BC69@freebsd.org> Message-ID: <20091110.132335.1735450040.imp@bsdimp.com> In message: <43EE151E-574E-4A17-9946-0BC5A6B3BC69@freebsd.org> Rui Paulo writes: : Hi, : : On 10 Nov 2009, at 04:38, Sam Leffler wrote: : : > Olivier Houchard wrote: : >> On Sun, Nov 08, 2009 at 01:30:48PM +0000, Rui Paulo wrote: : >>> Hi, : >>> I guess this has been discussed in the past but, can't we turn on ULE on ARM embedded systems ? What's the bottleneck or performance regression (assuming there's one) ? : >>> : >>> -- : >>> Rui Paulo : >> Hi, : >> At one point ULE was buggy on arm, but I think it's been fixed like years ago, : >> so it should be safe to use it. : > : > Last I measured it was slower than 4BSD on my xscale boards (not much but measurable). This was mostly doing network packet pushing (wired+wireless). : : I also tested this on the Cambria board and I concluded the same (I used sysbench). This isn't too surprising, since it is optimized for multicore and 4BSD grew up on single-core systems... Warner From Matthias.Reyelt at brunel.de Thu Nov 12 14:42:54 2009 From: Matthias.Reyelt at brunel.de (Matthias Reyelt) Date: Thu Nov 12 14:43:02 2009 Subject: Eval board Marvell 78xxx (Discovery) Message-ID: <200911121542.45078.Matthias.Reyelt@brunel.de> Hi, I am looking for an Eval board with the 78xxx Discovery cpu to run FreeBSD on. Does the Marvell DB-MV78100-A1 run FreeBSD (regarding Ethernet, Flash,..)? Are there other Discovery based boards, that have been successfully booted with FreeBSD? Regards Matthias From raj at semihalf.com Thu Nov 12 15:38:29 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Thu Nov 12 15:39:04 2009 Subject: Eval board Marvell 78xxx (Discovery) In-Reply-To: <200911121542.45078.Matthias.Reyelt@brunel.de> References: <200911121542.45078.Matthias.Reyelt@brunel.de> Message-ID: <60F8C54E-69DF-4ABD-8619-6093EDF240F0@semihalf.com> On 2009-11-12, at 15:42, Matthias Reyelt wrote: > I am looking for an Eval board with the 78xxx Discovery cpu to run > FreeBSD on. > Does the Marvell DB-MV78100-A1 run FreeBSD (regarding Ethernet, > Flash,..)? The DB -78100 board is supported and should boot. Marcel is seeing some cache coherency problems still with it, but that's a separate story i.e. bug(s). I didn't manage to return to your issues with secondary mge unit on Kirkwood, but the only board with more than one Eth port we have is this MV-78xxx, and it both ports worked for us on this board. Rafal From bugmaster at FreeBSD.org Mon Nov 16 11:06:49 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 16 11:07:34 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200911161106.nAGB6mQF011103@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From jhb at freebsd.org Thu Nov 19 16:38:33 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 19 16:38:40 2009 Subject: [PATCH] Fix a few nits in ate(4) Message-ID: <200911191122.02975.jhb@freebsd.org> I ran into this while working on purging if_watchdog/if_timer use from the tree. This patch fixes a few things in ate(4): - Initialize callout before it is used in atestop() during attach. - Fixup detach. By fixing detach, I mean that it calls ether_ifdetach() to remove outside references to the device before shutting down the device. Please test. --- //depot/vendor/freebsd/src/sys/arm/at91/if_ate.c 2009/06/26 11:50:17 +++ //depot/user/jhb/cleanup/sys/arm/at91/if_ate.c 2009/11/17 18:08:42 @@ -75,8 +75,7 @@ /* * Driver-specific flags. */ -#define ATE_FLAG_DETACHING 0x01 -#define ATE_FLAG_MULTICAST 0x02 +#define ATE_FLAG_MULTICAST 0x01 struct ate_softc { @@ -196,6 +195,7 @@ sc = device_get_softc(dev); sc->dev = dev; ATE_LOCK_INIT(sc); + callout_init_mtx(&sc->tick_ch, &sc->sc_mtx, 0); /* * Allocate resources. @@ -233,7 +233,6 @@ ATE_LOCK(sc); atestop(sc); ATE_UNLOCK(sc); - callout_init_mtx(&sc->tick_ch, &sc->sc_mtx, 0); if ((err = ate_get_mac(sc, eaddr)) != 0) { /* @@ -311,12 +309,11 @@ KASSERT(sc != NULL, ("[ate: %d]: sc is NULL", __LINE__)); ifp = sc->ifp; if (device_is_attached(dev)) { + ether_ifdetach(ifp); ATE_LOCK(sc); - sc->flags |= ATE_FLAG_DETACHING; - atestop(sc); + atestop(sc); ATE_UNLOCK(sc); callout_drain(&sc->tick_ch); - ether_ifdetach(ifp); } if (sc->miibus != NULL) { device_delete_child(dev, sc->miibus); @@ -1109,11 +1105,9 @@ & (IFF_PROMISC | IFF_ALLMULTI)) != 0) ate_rxfilter(sc); } else { - if ((sc->flags & ATE_FLAG_DETACHING) == 0) - ateinit_locked(sc); + ateinit_locked(sc); } } else if ((drv_flags & IFF_DRV_RUNNING) != 0) { - ifp->if_drv_flags &= ~IFF_DRV_RUNNING; atestop(sc); } sc->if_flags = flags; -- John Baldwin From imp at bsdimp.com Thu Nov 19 21:22:06 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Nov 19 21:22:12 2009 Subject: [PATCH] Fix a few nits in ate(4) In-Reply-To: <200911191122.02975.jhb@freebsd.org> References: <200911191122.02975.jhb@freebsd.org> Message-ID: <20091119.141917.-1843205663.imp@bsdimp.com> In message: <200911191122.02975.jhb@freebsd.org> John Baldwin writes: : I ran into this while working on purging if_watchdog/if_timer use from the : tree. This patch fixes a few things in ate(4): : : - Initialize callout before it is used in atestop() during attach. : - Fixup detach. : : By fixing detach, I mean that it calls ether_ifdetach() to remove outside : references to the device before shutting down the device. Please test. OK. I thought the other order was right. See below for one or two concerns.. Warner : --- //depot/vendor/freebsd/src/sys/arm/at91/if_ate.c 2009/06/26 11:50:17 : +++ //depot/user/jhb/cleanup/sys/arm/at91/if_ate.c 2009/11/17 18:08:42 : @@ -75,8 +75,7 @@ : /* : * Driver-specific flags. : */ : -#define ATE_FLAG_DETACHING 0x01 : -#define ATE_FLAG_MULTICAST 0x02 : +#define ATE_FLAG_MULTICAST 0x01 : : struct ate_softc : { : @@ -196,6 +195,7 @@ : sc = device_get_softc(dev); : sc->dev = dev; : ATE_LOCK_INIT(sc); : + callout_init_mtx(&sc->tick_ch, &sc->sc_mtx, 0); : : /* : * Allocate resources. : @@ -233,7 +233,6 @@ : ATE_LOCK(sc); : atestop(sc); : ATE_UNLOCK(sc); : - callout_init_mtx(&sc->tick_ch, &sc->sc_mtx, 0); : : if ((err = ate_get_mac(sc, eaddr)) != 0) { : /* : @@ -311,12 +309,11 @@ : KASSERT(sc != NULL, ("[ate: %d]: sc is NULL", __LINE__)); : ifp = sc->ifp; : if (device_is_attached(dev)) { : + ether_ifdetach(ifp); : ATE_LOCK(sc); : - sc->flags |= ATE_FLAG_DETACHING; : - atestop(sc); : + atestop(sc); : ATE_UNLOCK(sc); : callout_drain(&sc->tick_ch); : - ether_ifdetach(ifp); : } : if (sc->miibus != NULL) { : device_delete_child(dev, sc->miibus); : @@ -1109,11 +1105,9 @@ : & (IFF_PROMISC | IFF_ALLMULTI)) != 0) : ate_rxfilter(sc); : } else { : - if ((sc->flags & ATE_FLAG_DETACHING) == 0) : - ateinit_locked(sc); : + ateinit_locked(sc); Here we reinitialize the device just before we detach it. I put the detaching stuff in to prevent that. With this change, are you saying this routine won't be called, so we don't need this check anymore? : } : } else if ((drv_flags & IFF_DRV_RUNNING) != 0) { : - ifp->if_drv_flags &= ~IFF_DRV_RUNNING; : atestop(sc); : } : sc->if_flags = flags; Why remove this line? I think it is kinda needed. I don't understand. Warner From jhb at freebsd.org Thu Nov 19 22:01:38 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 19 22:01:44 2009 Subject: [PATCH] Fix a few nits in ate(4) In-Reply-To: <20091119.141917.-1843205663.imp@bsdimp.com> References: <200911191122.02975.jhb@freebsd.org> <20091119.141917.-1843205663.imp@bsdimp.com> Message-ID: <200911191701.33852.jhb@freebsd.org> On Thursday 19 November 2009 4:19:17 pm M. Warner Losh wrote: > In message: <200911191122.02975.jhb@freebsd.org> > John Baldwin writes: > : @@ -1109,11 +1105,9 @@ > : & (IFF_PROMISC | IFF_ALLMULTI)) != 0) > : ate_rxfilter(sc); > : } else { > : - if ((sc->flags & ATE_FLAG_DETACHING) == 0) > : - ateinit_locked(sc); > : + ateinit_locked(sc); > > Here we reinitialize the device just before we detach it. I put the > detaching stuff in to prevent that. With this change, are you saying > this routine won't be called, so we don't need this check anymore? Basically, yes. More to the point, the previous order of calling atestop() before ether_ifdetach() opened up a race wherein userland (or bpf_detach() within if_detach()) could cause this to get invoked after atestop() had been called. Now that we call ether_ifdetach() first, we know that neither bpf nor userland is going to mess with the device anymore, and at that time we can safely call atestop(). That now removes the need for doing this check. > : } > : } else if ((drv_flags & IFF_DRV_RUNNING) != 0) { > : - ifp->if_drv_flags &= ~IFF_DRV_RUNNING; > : atestop(sc); > : } > : sc->if_flags = flags; > > Why remove this line? I think it is kinda needed. I don't understand. It is a duplicate of the first line of atestop(). -- John Baldwin From bugmaster at FreeBSD.org Mon Nov 23 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 23 11:07:32 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200911231106.nANB6mh7070064@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total.