From owner-freebsd-arm@FreeBSD.ORG Sun Sep 12 22:36:12 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EA11106566C for ; Sun, 12 Sep 2010 22:36:12 +0000 (UTC) (envelope-from crest@informatik.uni-bremen.de) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by mx1.freebsd.org (Postfix) with ESMTP id BEF868FC12 for ; Sun, 12 Sep 2010 22:36:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from webmail.informatik.uni-bremen.de (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o87NbKTs024184 for ; Wed, 8 Sep 2010 01:37:25 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 08 Sep 2010 01:37:20 +0200 From: crest To: Message-ID: <8bdd58156a2cf1977c57893355ab4dad@localhost> X-Sender: crest@localhost User-Agent: Roundcube Webmail/0.4 X-Mailman-Approved-At: Mon, 13 Sep 2010 02:30:22 +0000 Subject: TUKLIB_FAST_UNALIGNED_ACCESS must not be defined in src/lib/liblzma/config.h on strict alignment architectures X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 22:36:12 -0000 I noticed that /usr/bin/xz crashed with signal 10 on a Feroceon 88FR131 rev 1 CPU and traced back to an unaligned 16 bit memory access in liblzma. This is enabled by TUKLIB_FAST_UNALIGNED_ACCESS in src/lib/liblzma/config.h. Uncommenting this line fixed the problem. This may cost some performance on non strict aligment architectures (e.g. x86, most ppc). Passing it via CFLAGS instead of config.h based on architecture would fix this problem. From owner-freebsd-arm@FreeBSD.ORG Mon Sep 13 09:08:38 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5890E1065674 for ; Mon, 13 Sep 2010 09:08:38 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:50:40:63ff:feea:93a]) by mx1.freebsd.org (Postfix) with ESMTP id EAABE8FC17 for ; Mon, 13 Sep 2010 09:08:37 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.2/8.14.3) with ESMTP id o8D993km056576; Mon, 13 Sep 2010 11:09:03 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id o8D993T8056575; Mon, 13 Sep 2010 11:09:03 +0200 (CEST) (envelope-from mlfbsd) Date: Mon, 13 Sep 2010 11:09:03 +0200 From: Olivier Houchard To: crest Message-ID: <20100913090903.GA56310@ci0.org> References: <8bdd58156a2cf1977c57893355ab4dad@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8bdd58156a2cf1977c57893355ab4dad@localhost> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: TUKLIB_FAST_UNALIGNED_ACCESS must not be defined in src/lib/liblzma/config.h on strict alignment architectures X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 09:08:38 -0000 On Wed, Sep 08, 2010 at 01:37:20AM +0200, crest wrote: > I noticed that /usr/bin/xz crashed with signal 10 on a Feroceon > 88FR131 rev 1 CPU and traced back to an unaligned 16 bit memory access > in liblzma. This is enabled by TUKLIB_FAST_UNALIGNED_ACCESS in > src/lib/liblzma/config.h. Uncommenting this line fixed the problem. > This may cost some performance on non strict aligment architectures > (e.g. x86, most ppc). Passing it via CFLAGS instead of config.h based > on architecture would fix this problem. Hi, We define __NO_STRICT_ALIGNMENT in machine/_types.h for machine which can do unaligned access, so maybe defining TUKLIB_FAST_UNALIGNED_ACCESS only if __NO_STRICT_ALIGNMENT is there would do the trick ? Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Mon Sep 13 11:06:51 2010 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DC421065694 for ; Mon, 13 Sep 2010 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EF6778FC1A for ; Mon, 13 Sep 2010 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8DB6oxq001823 for ; Mon, 13 Sep 2010 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8DB6oqn001821 for freebsd-arm@FreeBSD.org; Mon, 13 Sep 2010 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Sep 2010 11:06:50 GMT Message-Id: <201009131106.o8DB6oqn001821@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 11:06:51 -0000 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 kern/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 3 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Sep 13 13:46:16 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83FF0106566B for ; Mon, 13 Sep 2010 13:46:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 441F58FC13 for ; Mon, 13 Sep 2010 13:46:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o8DDhnl3060874; Mon, 13 Sep 2010 07:43:50 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 13 Sep 2010 07:43:57 -0600 (MDT) Message-Id: <20100913.074357.195002336778407179.imp@bsdimp.com> To: mlfbsd@ci0.org From: "M. Warner Losh" In-Reply-To: <20100913090903.GA56310@ci0.org> References: <8bdd58156a2cf1977c57893355ab4dad@localhost> <20100913090903.GA56310@ci0.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, crest@informatik.uni-bremen.de Subject: Re: TUKLIB_FAST_UNALIGNED_ACCESS must not be defined in src/lib/liblzma/config.h on strict alignment architectures X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 13:46:16 -0000 In message: <20100913090903.GA56310@ci0.org> Olivier Houchard writes: : On Wed, Sep 08, 2010 at 01:37:20AM +0200, crest wrote: : > I noticed that /usr/bin/xz crashed with signal 10 on a Feroceon : > 88FR131 rev 1 CPU and traced back to an unaligned 16 bit memory access : > in liblzma. This is enabled by TUKLIB_FAST_UNALIGNED_ACCESS in : > src/lib/liblzma/config.h. Uncommenting this line fixed the problem. : > This may cost some performance on non strict aligment architectures : > (e.g. x86, most ppc). Passing it via CFLAGS instead of config.h based : > on architecture would fix this problem. : : Hi, : : : We define __NO_STRICT_ALIGNMENT in machine/_types.h for machine which can do : unaligned access, so maybe defining TUKLIB_FAST_UNALIGNED_ACCESS only if : __NO_STRICT_ALIGNMENT is there would do the trick ? I was going to suggest the same thing... Warner From owner-freebsd-arm@FreeBSD.ORG Mon Sep 13 15:01:08 2010 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11E351065672; Mon, 13 Sep 2010 15:01:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BEC148FC0C; Mon, 13 Sep 2010 15:01:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o8DF17uB099093; Mon, 13 Sep 2010 11:01:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o8DF17Cd099079; Mon, 13 Sep 2010 15:01:07 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 13 Sep 2010 15:01:07 GMT Message-Id: <201009131501.o8DF17Cd099079@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 15:01:08 -0000 TB --- 2010-09-13 14:21:57 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-13 14:21:57 - starting RELENG_8_1 tinderbox run for arm/arm TB --- 2010-09-13 14:21:57 - cleaning the object tree TB --- 2010-09-13 14:22:19 - cvsupping the source tree TB --- 2010-09-13 14:22:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/arm/arm/supfile TB --- 2010-09-13 15:01:07 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-13 15:01:07 - ERROR: unable to cvsup the source tree TB --- 2010-09-13 15:01:07 - 0.73 user 18.38 system 2349.92 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Sep 14 15:46:43 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC3FD1065672 for ; Tue, 14 Sep 2010 15:46:43 +0000 (UTC) (envelope-from yohanes@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 78C4C8FC13 for ; Tue, 14 Sep 2010 15:46:43 +0000 (UTC) Received: by iwn34 with SMTP id 34so7060379iwn.13 for ; Tue, 14 Sep 2010 08:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=S48KlEEH0zj6C4Ra3CcZoLVqoMLJa5k9J55MQRK/Ri0=; b=IKyB77x42d8N21eSRbLVv8/atD19CLM/rN5fPfBytnI4BFQbHUDCV8x/kHMsmS6c1f rLmHLn59IkTWMqAEeOA0ti03nWKE5FaHMDsRRyqZNPURTyB/yq+PrTSftRmFGrF0hN90 atb9MtXcxyglKErsJGgTqD0tYVyWq9wR8Iqhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=REZlLDnXv854Lud5cEfHZwcdhYLlC/6WBaBiZpKhCe/SLRThZCeuo0uJ1/T9kWtIX/ aWZwluE+sMfZ+YJUg1DunhxgW7D1coYz3YEKvTZUWBbvsWmXnA2c3cnzH+tKE/selJ2g 9vwTvOY3fKwdKNGs9XOJpEKe+thrmOYJmpUas= Received: by 10.231.156.65 with SMTP id v1mr17482ibw.107.1284477314369; Tue, 14 Sep 2010 08:15:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.115.12 with HTTP; Tue, 14 Sep 2010 08:14:43 -0700 (PDT) From: Yohanes Nugroho Date: Tue, 14 Sep 2010 22:14:43 +0700 Message-ID: To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Compiling xorg-server X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 15:46:43 -0000 Hi everyone, Is there anyone that have succeeded in compiling xorg-server for FreeBSD arm? When i try to compile it, it stopped at: fb.h:102:2: error: #error "GLYPHPADBYTES must be 4" I tried adding #define __arm32__ in include/servermd.h but then it stopped at arm_video.c arm_video.c: In function 'xf86OSInitVidMem': arm_video.c:179: error: 'struct ' has no member named 'unmapVidMem' arm_video.c:179: error: 'armUnmapVidMem' undeclared (first use in this function) arm_video.c:179: error: (Each undeclared identifier is reported only once arm_video.c:179: error: for each function it appears in.) If i try to define __arm32__, it can not find machine/devmap.h ------------------------------ #ifdef __arm32__ #include "machine/devmap.h" struct memAccess ... --------------------------- -- Regards Yohanes http://yohan.es/ From owner-freebsd-arm@FreeBSD.ORG Wed Sep 15 02:10:02 2010 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 005871065674 for ; Wed, 15 Sep 2010 02:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CD7448FC0A for ; Wed, 15 Sep 2010 02:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8F2A1xE082087 for ; Wed, 15 Sep 2010 02:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8F2A1ZQ082085; Wed, 15 Sep 2010 02:10:01 GMT (envelope-from gnats) Resent-Date: Wed, 15 Sep 2010 02:10:01 GMT Resent-Message-Id: <201009150210.o8F2A1ZQ082085@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Tyler S Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21E09106566B for ; Wed, 15 Sep 2010 02:05:16 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 102278FC0C for ; Wed, 15 Sep 2010 02:05:16 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o8F25FVI083061 for ; Wed, 15 Sep 2010 02:05:15 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id o8F25F39083060; Wed, 15 Sep 2010 02:05:15 GMT (envelope-from nobody) Message-Id: <201009150205.o8F25F39083060@www.freebsd.org> Date: Wed, 15 Sep 2010 02:05:15 GMT From: Tyler S To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: arm/150581: Unknown error generates IRQ address decoding error X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 02:10:02 -0000 >Number: 150581 >Category: arm >Synopsis: Unknown error generates IRQ address decoding error >Confidential: no >Severity: critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 15 02:10:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Tyler S >Release: -current >Organization: >Environment: FreeBSD armadeus 9.0-CURRENT FreeBSD 9.0-CURRENT #3: Tue Sep 14 04:49:25 UTC 2010 ulterior@adumbral.local:/usr/obj/arm.arm/usr/src/sys/SHEEVAPLUG arm >Description: When executing "portsnap fetch", the machine (a guruplug server plus) floods its local console with: c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 46% of 63 MB 214 kBps 02m43s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 46% of 63 MB 213 kBps 02m43s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 46% of 63 MB 213 kBps 02m43s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 47% of 63 MB 213 kBps 02m41s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 47% of 63 MB 213 kBps 02m40s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 47% of 63 MB 213 kBps 02m39s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 47% of 63 MB 213 kBps 02m38s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 48% of 63 MB 212 kBps 02m38s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 48% of 63 MB 213 kBps 02m37s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 48% of 63 MB 213 kBps 02m35s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 49% of 63 MB 212 kBps 02m35s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 49% of 63 MB 212 kBps 02m34s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 49% of 63 MB 213 kBps 02m32s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 50% of 63 MB 214 kBps 02m30s c86a862ec3012622d1fc4d0d450dcb2469828ffec71fd7 50% of 63 MB 214 kBps 02m28s c86a862ec301262IRQ ERR: cause: 0x00000001 IRQ ERR: Address decoding error IRQ ERR: cause: 0x00000001 IRQ ERR: Address decoding error IRQ ERR: cause: 0x00000001 IRQ ERR: Address decoding error IRQ ERR: cause: 0x00000001 IRQ ERR: Address decoding error IRQ ERR: cause: 0x00000001 IRQ ERR: Address decoding error IRQ ERR: cause: 0x00000001 IRQ ERR: Address decoding error IRQ ERR: cause: 0x00000001 IRQ ERR: Address decoding error IRQ ERR: cause: 0x00000001 IRQ ERR: Address decoding error IRQ ERR: cause: 0x00000001 IRQ ERR: Address decoding error IRQ ERR: cause: 0x00000001 IRQ ERR: Address decoding error IRQ ERR: cause: 0x00000001 IRQ ERR: Address decoding error IRQ ERR: cause: 0x00000001 IRQ ERR: Address decoding error IRQ ERR: cause: 0x00000001 - snip - and the machine becomes unresponsive, prompting a cold boot. Kernel was built with the following patches applied to it: --- /usr/src/sys/kern/vfs_mount.c.orig 2010-07-04 22:50:00.613726077 -0400 +++ /usr/src/sys/kern/vfs_mount.c 2010-07-05 12:11:09.986561693 -0400 @@ -1651,6 +1651,9 @@ int error, i, asked = 0; options = NULL; + + /* NASTY HACK: wait for USB sticks to appear */ + pause("usbhack", hz * 10); root_mount_prepare(); --- /usr/src/etc/rc.d/fsck.orig 2010-07-07 13:02:41.765255856 -0400 +++ /usr/src/etc/rc.d/fsck 2010-07-07 13:02:46.286575144 -0400 @@ -27,7 +27,16 @@ if checkyesno background_fsck; then fsck -F -p else - fsck -p + if checkyesno force_fsck; then + echo "Force fsck enabled" + for filesystem in ${force_fsck_list} + do + echo "Force check $filesystem" + fsck -y $filesystem + done + else + fsck -p + fi fi case $? in --- /usr/src/contrib/bind9/lib/isc/arm/include/isc/atomic.h.orig 2010-08-04 02:02:01.194401084 -0400 +++ /usr/src/contrib/bind9/lib/isc/arm/include/isc/atomic.h 2010-08-04 02:04:53.462379414 -0400 @@ -49,26 +49,22 @@ static inline isc_int32_t isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) { - register int done, ras_start; + register int done, ras_start = 0xffff1004; __asm __volatile("1:\n" "adr %1, 1b\n" - "mov %0, #0xe0000004\n" "str %1, [%0]\n" - "mov %0, #0xe0000008\n" "adr %1, 2f\n" - "str %1, [%0]\n" + "str %1, [%0, #4]\n" "ldr %1, [%2]\n" "cmp %1, %3\n" "streq %4, [%2]\n" "2:\n" "mov %3, #0\n" - "mov %0, #0xe0000004\n" "str %3, [%0]\n" "mov %3, #0xffffffff\n" - "mov %0, #0xe0000008\n" - "str %3, [%0]\n" - : "=r" (ras_start), "=r" (done) + "str %3, [%0, #4]\n" + : "+r" (ras_start), "=r" (done) ,"+r" (p), "+r" (cmpval), "+r" (val) : : "memory"); return (done); and, the following kernel configuration: # # Custom kernel for Marvell SheevaPlug devices. # # $FreeBSD: src/sys/arm/conf/SHEEVAPLUG,v 1.3 2010/06/13 13:28:53 raj Exp $ # ident SHEEVAPLUG include "../mv/kirkwood/std.sheevaplug" options SOC_MV_KIRKWOOD makeoptions MODULES_OVERRIDE="" #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols makeoptions WERROR="-Werror" options SCHED_4BSD #4BSD scheduler options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options NFSCLIENT #Network Filesystem Client options NFSLOCKD #Network Lock Manager options NFS_ROOT #NFS usable as /, requires NFSCLIENT #options BOOTP #options BOOTP_NFSROOT #options BOOTP_NFSV3 #options BOOTP_WIRED_TO=mge0 options GEOM_PART_BSD options GEOM_PART_GPT options GEOM_PART_MBR options GEOM_LABEL options SOFTUPDATES # Enable FF Soft updates support options MSDOSFS # Enable MSDOS Filesystems options PROCFS # Process Filesystem options PSEUDOFS # Psuedo-filesystem support #options ZFS # zfs module #options opensolaris # support module for zfs # Root fs on USB device #options ROOTDEVNAME=\"ufs:/dev/da0a\" options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options MUTEX_NOINLINE options RWLOCK_NOINLINE #options NO_FFS_SNAPSHOT #options NO_SWAPPING # extra options SW_WATCHDOG options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=80 device ata device atadisk # ATA disk drives options ATA_STATIC_ID # Static device numbering # Debugging options ALT_BREAK_TO_DEBUGGER options DDB options KDB # Pseudo devices device random device pty device loop device md # Memory Disks # Serial ports device uart # Networking device ether device mge # Marvell Gigabit Ethernet controller device mii device e1000phy device bpf options HZ=1000 options DEVICE_POLLING device vlan # USB options USB_DEBUG # enable debug msgs device usb device ehci device umass device scbus device pass device da # Flattened Device Tree options FDT options FDT_DTB_STATIC makeoptions FDT_DTS_FILE=sheevaplug.dts >How-To-Repeat: run "portsnap fetch" on a guruplug server+ with the above configuration. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Wed Sep 15 09:40:03 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74980106566C; Wed, 15 Sep 2010 09:40:03 +0000 (UTC) (envelope-from wthww@680x0.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 206658FC13; Wed, 15 Sep 2010 09:40:02 +0000 (UTC) Received: by vws7 with SMTP id 7so6936vws.13 for ; Wed, 15 Sep 2010 02:40:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.128.141 with SMTP id k13mr670762vcs.170.1284542234977; Wed, 15 Sep 2010 02:17:14 -0700 (PDT) Received: by 10.220.98.7 with HTTP; Wed, 15 Sep 2010 02:17:14 -0700 (PDT) X-Originating-IP: [98.157.152.196] In-Reply-To: <201009150210.o8F2A1St082081@freefall.freebsd.org> References: <201009150205.o8F25F39083060@www.freebsd.org> <201009150210.o8F2A1St082081@freefall.freebsd.org> Date: Wed, 15 Sep 2010 05:17:14 -0400 Message-ID: From: Tyler Saylor To: FreeBSD-gnats-submit@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: arm/150581: Unknown error generates IRQ address decoding error X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 09:40:03 -0000 Actually, this may not be an issue. I realized I applied patches meant for -stable to -current. I will checkout the source again and rebuild to see what happens. On Tue, Sep 14, 2010 at 10:10 PM, wrote: > Thank you very much for your problem report. > It has the internal identification `arm/150581'. > The individual assigned to look at your > report is: freebsd-arm. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=150581 > > >Category: arm > >Responsible: freebsd-arm > >Synopsis: Unknown error generates IRQ address decoding error > >Arrival-Date: Wed Sep 15 02:10:01 UTC 2010 > From owner-freebsd-arm@FreeBSD.ORG Wed Sep 15 09:50:03 2010 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF44F1065670 for ; Wed, 15 Sep 2010 09:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9612F8FC08 for ; Wed, 15 Sep 2010 09:50:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8F9o3bE008740 for ; Wed, 15 Sep 2010 09:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8F9o3mT008739; Wed, 15 Sep 2010 09:50:03 GMT (envelope-from gnats) Date: Wed, 15 Sep 2010 09:50:03 GMT Message-Id: <201009150950.o8F9o3mT008739@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: Tyler Saylor Cc: Subject: Re: arm/150581: Unknown error generates IRQ address decoding error X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tyler Saylor List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 09:50:03 -0000 The following reply was made to PR arm/150581; it has been noted by GNATS. From: Tyler Saylor To: FreeBSD-gnats-submit@freebsd.org, freebsd-arm@freebsd.org Cc: Subject: Re: arm/150581: Unknown error generates IRQ address decoding error Date: Wed, 15 Sep 2010 05:17:14 -0400 --e0cb4e8875659d65f7049048cb30 Content-Type: text/plain; charset=ISO-8859-1 Actually, this may not be an issue. I realized I applied patches meant for -stable to -current. I will checkout the source again and rebuild to see what happens. On Tue, Sep 14, 2010 at 10:10 PM, wrote: > Thank you very much for your problem report. > It has the internal identification `arm/150581'. > The individual assigned to look at your > report is: freebsd-arm. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=150581 > > >Category: arm > >Responsible: freebsd-arm > >Synopsis: Unknown error generates IRQ address decoding error > >Arrival-Date: Wed Sep 15 02:10:01 UTC 2010 > --e0cb4e8875659d65f7049048cb30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually, this may not be an issue. I realized I applied patches meant for = -stable to -current. I will checkout the source again and rebuild to see wh= at happens.

On Tue, Sep 14, 2010 at 10:10= PM, <FreeBSD-gnats-submit@freebsd.org> wrote:
Thank you very mu= ch for your problem report.
It has the internal identification `arm/150581'.
The individual assigned to look at your
report is: freebsd-arm.

You can access the state of your problem report at any time
via this link:

http://www.freebsd.org/cgi/query-pr.cgi?pr=3D150581

>Category: =A0 =A0 =A0 arm
>Responsible: =A0 =A0freebsd-arm
>Synopsis: =A0 =A0 =A0 Unknown error generates IRQ address decoding erro= r
>Arrival-Date: =A0 Wed Sep 15 02:10:01 UTC 2010

--e0cb4e8875659d65f7049048cb30-- From owner-freebsd-arm@FreeBSD.ORG Thu Sep 16 13:24:40 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 622461065675 for ; Thu, 16 Sep 2010 13:24:40 +0000 (UTC) (envelope-from johan.petersen@apica.com) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id 24CE28FC13 for ; Thu, 16 Sep 2010 13:24:40 +0000 (UTC) Received: from [192.168.1.59] (unknown [78.123.29.192]) by csmtp3.one.com (Postfix) with ESMTP id 244E1240697E for ; Thu, 16 Sep 2010 13:07:36 +0000 (UTC) Message-ID: <4C921697.8040801@apica.com> Date: Thu, 16 Sep 2010 15:07:35 +0200 From: Johan Petersen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.12) Gecko/20100824 Lightning/1.0b1 Thunderbird/3.0.7 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD (or nanoBSD) on NXP LPC X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 13:24:40 -0000 Hi! Ive been searching for any experience porting to an NXP LPC (LPC 32xx or LPC 314x) CPU without success. Now, since memory is sparse, I need to compile a kernel for ARM, then emulate an ARM machine (fx with QEMU) and then use nanoBSD.sh to reduce the size. Anyone done such things before? BR /Johan From owner-freebsd-arm@FreeBSD.ORG Fri Sep 17 00:44:59 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65D78106566C for ; Fri, 17 Sep 2010 00:44:59 +0000 (UTC) (envelope-from johny.mattsson@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 271308FC08 for ; Fri, 17 Sep 2010 00:44:58 +0000 (UTC) Received: by iwn34 with SMTP id 34so1776447iwn.13 for ; Thu, 16 Sep 2010 17:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=HiTqh2KiSKpfFFoVoJrjgQcJFKW4jGBdzzdnd7J6sog=; b=oXvoS3UVGSYYkegF5xAqTSNxJsG2QTCiUgIvRd323HQogm9geOoxb8xiw/n0f3Fc49 Fbd8+ef8kOpuqi/GWsnlen0ipmX/zeSfBbvymHOYRziGLQQfFP4K3M+ysRmbRuQ9q3dz 1hUnA3iLMaG5WX5XYmNBSQykMR45rStYgtBUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=QZV2GI2yqMWrHy89D3boM16KCCyBUm1+7skYVDRDgFXzxyMdJkZBK1yDyZ8pkw7uzS WWw7Tzs0FnCUlOsXJAeSga4CqE42oVw2I/gyqcOGcGOphQiuepHpIqGbBDuHrCF0H0X6 cOn3Brk9/ytfBolnUG5ty76CDD+2ey4RFjbZM= MIME-Version: 1.0 Received: by 10.231.12.77 with SMTP id w13mr3843476ibw.80.1284684298232; Thu, 16 Sep 2010 17:44:58 -0700 (PDT) Sender: johny.mattsson@gmail.com Received: by 10.231.199.197 with HTTP; Thu, 16 Sep 2010 17:44:58 -0700 (PDT) In-Reply-To: References: <201009150205.o8F25F39083060@www.freebsd.org> <201009150210.o8F2A1St082081@freefall.freebsd.org> Date: Fri, 17 Sep 2010 10:44:58 +1000 X-Google-Sender-Auth: O67yhelQiHGe0_kMJFMeKVPxo_E Message-ID: From: Johny Mattsson To: Tyler Saylor Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arm@freebsd.org, FreeBSD-gnats-submit@freebsd.org Subject: Re: arm/150581: Unknown error generates IRQ address decoding error X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 00:44:59 -0000 Hi Tyler, The issue could be the same that I'm having on my PogoPlug (stripped down version of the Sheevaplug essentially). I don't have a serial console on it, so I haven't been able to get any actual error messages, but I do experience the same hard hang when I have heavy USB I/O. I'm still working on resolving this issue properly, but I have found a work-around. If rolling back those patches didn't fix the problem for you, try limiting the amount of RAM the kernel sees down to 128MiB. For me, going from the actual 256MiB down to 128MiB prevents the I/O lock-up and I have a stable system (I can in fact push it up to 131MiB, but above that it's bad news). To limit the RAM, open /usr/src/sys/boot/fdt/dts/sheevaplug.dts, find the "memory" entry and reduce it to 0x08000000, then rebuild your kernel. I'd be very interested in hearing whether this fixes your issue, as it's been quite frustrating to troubleshoot this without seeing what goes on the console when the hang occurs! Regards, /Johny From owner-freebsd-arm@FreeBSD.ORG Fri Sep 17 01:20:05 2010 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24FFC1065670 for ; Fri, 17 Sep 2010 01:20:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id ED8AF8FC0C for ; Fri, 17 Sep 2010 01:20:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8H1K4jL024083 for ; Fri, 17 Sep 2010 01:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8H1K4Mc024082; Fri, 17 Sep 2010 01:20:04 GMT (envelope-from gnats) Date: Fri, 17 Sep 2010 01:20:04 GMT Message-Id: <201009170120.o8H1K4Mc024082@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: Johny Mattsson Cc: Subject: Re: arm/150581: Unknown error generates IRQ address decoding error X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Johny Mattsson List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 01:20:05 -0000 The following reply was made to PR arm/150581; it has been noted by GNATS. From: Johny Mattsson To: Tyler Saylor Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-arm@freebsd.org Subject: Re: arm/150581: Unknown error generates IRQ address decoding error Date: Fri, 17 Sep 2010 10:44:58 +1000 --0003255753be3ea5ae049069df63 Content-Type: text/plain; charset=UTF-8 Hi Tyler, The issue could be the same that I'm having on my PogoPlug (stripped down version of the Sheevaplug essentially). I don't have a serial console on it, so I haven't been able to get any actual error messages, but I do experience the same hard hang when I have heavy USB I/O. I'm still working on resolving this issue properly, but I have found a work-around. If rolling back those patches didn't fix the problem for you, try limiting the amount of RAM the kernel sees down to 128MiB. For me, going from the actual 256MiB down to 128MiB prevents the I/O lock-up and I have a stable system (I can in fact push it up to 131MiB, but above that it's bad news). To limit the RAM, open /usr/src/sys/boot/fdt/dts/sheevaplug.dts, find the "memory" entry and reduce it to 0x08000000, then rebuild your kernel. I'd be very interested in hearing whether this fixes your issue, as it's been quite frustrating to troubleshoot this without seeing what goes on the console when the hang occurs! Regards, /Johny --0003255753be3ea5ae049069df63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tyler,

The issue could be the same that I'm having on my Pogo= Plug (stripped down version of the Sheevaplug essentially). I don't hav= e a serial console on it, so I haven't been able to get any actual erro= r messages, but I do experience the same hard hang when I have heavy USB I/= O. I'm still working on resolving this issue properly, but I have found= a work-around. If rolling back those patches didn't fix the problem fo= r you, try limiting the amount of RAM the kernel sees down to 128MiB. For m= e, going from the actual 256MiB down to 128MiB prevents the I/O lock-up and= I have a stable system (I can in fact push it up to 131MiB, but above that= it's bad news).

To limit the RAM, open /usr/src/sys/boot/fdt/dts/sheevaplug.dts, find t= he "memory" entry and reduce it to 0x08000000, then rebuild your = kernel.

I'd be very interested in hearing whether this fixes you= r issue, as it's been quite frustrating to troubleshoot this without se= eing what goes on the console when the hang occurs!

Regards,
/Johny
--0003255753be3ea5ae049069df63-- From owner-freebsd-arm@FreeBSD.ORG Sat Sep 18 09:01:53 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C833106566C; Sat, 18 Sep 2010 09:01:53 +0000 (UTC) (envelope-from johny.mattsson@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B3F518FC0A; Sat, 18 Sep 2010 09:01:52 +0000 (UTC) Received: by iwn34 with SMTP id 34so3154269iwn.13 for ; Sat, 18 Sep 2010 02:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3vjl8kEVQ2TkxxWC/AeNhWnpm4aiJWUj3htE+4tZJvM=; b=XNg8T/3iiUb+OjcpMsgcy9EoRI2cCNIkJQ3CePyp7nzaioIgUJJUOe3myy2V5+HycJ NiIBnyJpC93UGP9ik9/j7C7v8lnKer+e17M/vpAgAbTZMcYhlkJthIu4ZAkqqwWxVUku eDtaIEGpwujzLSIWPwqbkEqiXOxJnA/EL0qdQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=k4h44Hp/sYNHlJpQY+B+CzyS/Yb6DdMwao0HC85x8976F35RjzERUNU535BpzGcd8E vl0oFGx+6wJPGBceKuZtViWa6Ql/TLL6ZiOsMT4T2S6BbmOZnGa/gj2dWDmz7UhUBe5C VnHBAG5XlBO7wlUwSQlsVwOSebMDsQYoopFC4= MIME-Version: 1.0 Received: by 10.231.166.9 with SMTP id k9mr6595854iby.127.1284800511698; Sat, 18 Sep 2010 02:01:51 -0700 (PDT) Sender: johny.mattsson@gmail.com Received: by 10.231.199.197 with HTTP; Sat, 18 Sep 2010 02:01:51 -0700 (PDT) Date: Sat, 18 Sep 2010 19:01:51 +1000 X-Google-Sender-Auth: NDGWcSm_TdM4omM_KuRkOyNAvGQ Message-ID: From: Johny Mattsson To: Tyler Saylor Content-Type: multipart/mixed; boundary=005045013dcc1b66c1049084eec3 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arm@freebsd.org, FreeBSD-gnats-submit@freebsd.org Subject: Re: arm/150581: Unknown error generates IRQ address decoding error [patch] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 09:01:53 -0000 --005045013dcc1b66c1049084eec3 Content-Type: text/plain; charset=UTF-8 Hi Tyler (and list), It turned out this was the same issue I've been trying to hunt down the cause of for a couple of weeks. With a lot of help from Mark Tinguely I've finally nailed it. This problem is caused by a double-whammy of bugs. First of all, the USB bridge address decoding register definitions fail to account for the main offset from the base of the USB port range. This means that decode_win_usb_setup() in sys/arm/mv/common.c doesn't actually manage to set up the windows properly. Instead of poking the address decoding registers it writes to the ID and HWGENERAL registers, and possibly others depending on how much RAM is installed. As a result of not getting the windows set up properly, the USB controller ends up only being capable of decoding a limited range of addresses. The precise range might depend on how the boot loader initialized the controller, or it might use a default range. As I only have one type of hardware I can't readily verify which it is. With the incorrect windows established, under heavy USB I/O the controller typically ends up trying to decode an address which is outside its window(s), and raises an error interrupt for it. This in itself is not fatal. The actual hang is caused by a failure to sufficiently clear the error condition in the error interrupt handler (err_intr() in dev/usb/controllers/ehci_mv.c). For an address decode error, it is necessary to read out the error address from the bridge error address register. Failure to do so before returning from the interrupt handler causes the interrupt to be reissued. The attached patch addresses both issues. I have successfully tested it on my 88F6281 based Pogoplug, and I have verified the register addresses against the 88F5281 documentation. Unless someone can find fault with this patch, I'd love to see this committed. Regards, /Johny --005045013dcc1b66c1049084eec3 Content-Type: application/octet-stream; name="arm150581.patch" Content-Disposition: attachment; filename="arm150581.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ge88ndz60 LS0tIHN5cy9kZXYvdXNiL2NvbnRyb2xsZXIvZWhjaV9tdi5jLm9yaWcJMjAxMC0wOS0xNyAxODo1 NjowMy4wMDAwMDAwMDAgKzEwMDAKKysrIHN5cy9kZXYvdXNiL2NvbnRyb2xsZXIvZWhjaV9tdi5j CTIwMTAtMDktMTggMTg6Mjc6MzYuMDAwMDAwMDAwICsxMDAwCkBAIC05Niw2ICs5Niw3IEBACiAK ICNkZWZpbmUJVVNCX0JSSURHRV9JTlRSX0NBVVNFICAweDIxMAogI2RlZmluZQlVU0JfQlJJREdF X0lOVFJfTUFTSyAgIDB4MjE0CisjZGVmaW5lCVVTQl9CUklER0VfRVJSX0FERFIgICAgMHgyMUMK IAogI2RlZmluZQlNVl9VU0JfQUREUl9ERUNPREVfRVJSICgxIDw8IDApCiAjZGVmaW5lCU1WX1VT Ql9IT1NUX1VOREVSRkxPVyAgKDEgPDwgMSkKQEAgLTM2MCw2ICszNjEsMjEgQEAKIAkJCXByaW50 ZigiSVJRIEVSUjogVW5rbm93biBlcnJvclxuIik7CiAKIAkJRVdSSVRFNChzYywgVVNCX0JSSURH RV9JTlRSX0NBVVNFLCAwKTsKKworCQkvKgorCQkgKiBJbiBjYXNlIG9mIGFuIGFkZHJlc3MgZGVj b2RlIGVycm9yLCB3ZSBtdXN0IHJlYWQgZnJvbQorCQkgKiB0aGUgVVNCX0JSSURHRV9FUlJfQURE UiByZWdpc3RlciB0byBjbGVhciBpdCB0byBhbGxvdworCQkgKiB0aGUgY29udHJvbGxlciB0byBs YXRjaCBhIG5ldyBhZGRyZXNzIGluIG5leHQgdGltZSB0aGlzCisJCSAqIGVycm9yIG9jY3Vycy4g SWYgd2UgZG9uJ3QgcmVhZCBpdCwgd2UgZ2V0IHRoZSBpbnRlcnJ1cHQKKwkJICogcmVpc3N1ZWQg YWQgaW5maW5pdHVtLCBldmVuIHRob3VnaCB3ZSBoYXZlIGNsZWFyZWQgdGhlCisJCSAqIGludGVy cnVwdCBjYXVzZS4KKwkJICovCisJCWlmIChjYXVzZSAmIE1WX1VTQl9BRERSX0RFQ09ERV9FUlIp CisJCXsKKwkJCXVuc2lnbmVkIGVycmFkZHIgPSBFUkVBRDQoc2MsIFVTQl9CUklER0VfRVJSX0FE RFIpOworCQkJcHJpbnRmKCJJUlEgRVJSOiBVU0IgQnJpZGdlIEVycm9yIEFkZHJlc3M6IDB4JTA4 eFxuIiwKKwkJCQllcnJhZGRyKTsKKwkJfQogCX0KIAlyZXR1cm4gKEZJTFRFUl9IQU5ETEVEKTsK IH0KLS0tIHN5cy9hcm0vbXYvbXZ3aW4uaC5vcmlnCTIwMTAtMDktMTggMTg6MTM6MDkuMDAwMDAw MDAwICsxMDAwCisrKyBzeXMvYXJtL212L212d2luLmgJMjAxMC0wOS0xOCAxODoxNzo0NC4wMDAw MDAwMDAgKzEwMDAKQEAgLTEzOCw4ICsxMzgsOCBAQAogI2RlZmluZSBNVl9XSU5fQ0VTQV9BVFRS CQkwCiAjZW5kaWYKIAotI2RlZmluZSBNVl9XSU5fVVNCX0NUUkwobikJCSgweDEwICogKG4pICsg MHgwKQotI2RlZmluZSBNVl9XSU5fVVNCX0JBU0UobikJCSgweDEwICogKG4pICsgMHg0KQorI2Rl ZmluZSBNVl9XSU5fVVNCX0NUUkwobikJCSgweDEwICogKG4pICsgMHgzMjApCisjZGVmaW5lIE1W X1dJTl9VU0JfQkFTRShuKQkJKDB4MTAgKiAobikgKyAweDMyNCkKICNkZWZpbmUgTVZfV0lOX1VT Ql9NQVgJCQk0CiAKICNkZWZpbmUgTVZfV0lOX0VUSF9CQVNFKG4pCQkoMHg4ICogKG4pICsgMHgy MDApCg== --005045013dcc1b66c1049084eec3-- From owner-freebsd-arm@FreeBSD.ORG Sat Sep 18 09:10:04 2010 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8937E106566C for ; Sat, 18 Sep 2010 09:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4448FC15 for ; Sat, 18 Sep 2010 09:10:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8I9A4IQ043434 for ; Sat, 18 Sep 2010 09:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8I9A4pF043433; Sat, 18 Sep 2010 09:10:04 GMT (envelope-from gnats) Date: Sat, 18 Sep 2010 09:10:04 GMT Message-Id: <201009180910.o8I9A4pF043433@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: Johny Mattsson Cc: Subject: Re: arm/150581: Unknown error generates IRQ address decoding error [patch] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Johny Mattsson List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 09:10:04 -0000 The following reply was made to PR arm/150581; it has been noted by GNATS. From: Johny Mattsson To: Tyler Saylor Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-arm@freebsd.org, Mark Tinguely Subject: Re: arm/150581: Unknown error generates IRQ address decoding error [patch] Date: Sat, 18 Sep 2010 19:01:51 +1000 --005045013dcc1b66c1049084eec3 Content-Type: multipart/alternative; boundary=005045013dcc1b66bb049084eec1 --005045013dcc1b66bb049084eec1 Content-Type: text/plain; charset=UTF-8 Hi Tyler (and list), It turned out this was the same issue I've been trying to hunt down the cause of for a couple of weeks. With a lot of help from Mark Tinguely I've finally nailed it. This problem is caused by a double-whammy of bugs. First of all, the USB bridge address decoding register definitions fail to account for the main offset from the base of the USB port range. This means that decode_win_usb_setup() in sys/arm/mv/common.c doesn't actually manage to set up the windows properly. Instead of poking the address decoding registers it writes to the ID and HWGENERAL registers, and possibly others depending on how much RAM is installed. As a result of not getting the windows set up properly, the USB controller ends up only being capable of decoding a limited range of addresses. The precise range might depend on how the boot loader initialized the controller, or it might use a default range. As I only have one type of hardware I can't readily verify which it is. With the incorrect windows established, under heavy USB I/O the controller typically ends up trying to decode an address which is outside its window(s), and raises an error interrupt for it. This in itself is not fatal. The actual hang is caused by a failure to sufficiently clear the error condition in the error interrupt handler (err_intr() in dev/usb/controllers/ehci_mv.c). For an address decode error, it is necessary to read out the error address from the bridge error address register. Failure to do so before returning from the interrupt handler causes the interrupt to be reissued. The attached patch addresses both issues. I have successfully tested it on my 88F6281 based Pogoplug, and I have verified the register addresses against the 88F5281 documentation. Unless someone can find fault with this patch, I'd love to see this committed. Regards, /Johny --005045013dcc1b66bb049084eec1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tyler (and list),

It turned out this was the same issue I've = been trying to hunt down the cause of for a couple of weeks. With a lot of = help from Mark Tinguely I've finally nailed it.

This problem is = caused by a double-whammy of bugs.

First of all, the USB bridge address decoding register definitions fail= to account for the main offset from the base of the USB port range. This m= eans that decode_win_usb_setup() in sys/arm/mv/common.c doesn't actuall= y manage to set up the windows properly. Instead of poking the address deco= ding registers it writes to the ID and HWGENERAL registers, and possibly ot= hers depending on how much RAM is installed. As a result of not getting the= windows set up properly, the USB controller ends up only being capable of = decoding a limited range of addresses. The precise range might depend on ho= w the boot loader initialized the controller, or it might use a default ran= ge. As I only have one type of hardware I can't readily verify which it= is.

With the incorrect windows established, under heavy USB I/O the control= ler typically ends up trying to decode an address which is outside its wind= ow(s), and raises an error interrupt for it. This in itself is not fatal.
The actual hang is caused by a failure to sufficiently clear the error = condition in the error interrupt handler (err_intr() in dev/usb/controllers= /ehci_mv.c). For an address decode error, it is necessary to read out the e= rror address from the bridge error address register. Failure to do so befor= e returning from the interrupt handler causes the interrupt to be reissued.=

The attached patch addresses both issues. I have successfully tested it= on my 88F6281 based Pogoplug, and I have verified the register addresses a= gainst the 88F5281 documentation.

Unless someone can find fault with= this patch, I'd love to see this committed.

Regards,
/Johny
--005045013dcc1b66bb049084eec1-- --005045013dcc1b66c1049084eec3 Content-Type: application/octet-stream; name="arm150581.patch" Content-Disposition: attachment; filename="arm150581.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ge88ndz60 LS0tIHN5cy9kZXYvdXNiL2NvbnRyb2xsZXIvZWhjaV9tdi5jLm9yaWcJMjAxMC0wOS0xNyAxODo1 NjowMy4wMDAwMDAwMDAgKzEwMDAKKysrIHN5cy9kZXYvdXNiL2NvbnRyb2xsZXIvZWhjaV9tdi5j CTIwMTAtMDktMTggMTg6Mjc6MzYuMDAwMDAwMDAwICsxMDAwCkBAIC05Niw2ICs5Niw3IEBACiAK ICNkZWZpbmUJVVNCX0JSSURHRV9JTlRSX0NBVVNFICAweDIxMAogI2RlZmluZQlVU0JfQlJJREdF X0lOVFJfTUFTSyAgIDB4MjE0CisjZGVmaW5lCVVTQl9CUklER0VfRVJSX0FERFIgICAgMHgyMUMK IAogI2RlZmluZQlNVl9VU0JfQUREUl9ERUNPREVfRVJSICgxIDw8IDApCiAjZGVmaW5lCU1WX1VT Ql9IT1NUX1VOREVSRkxPVyAgKDEgPDwgMSkKQEAgLTM2MCw2ICszNjEsMjEgQEAKIAkJCXByaW50 ZigiSVJRIEVSUjogVW5rbm93biBlcnJvclxuIik7CiAKIAkJRVdSSVRFNChzYywgVVNCX0JSSURH RV9JTlRSX0NBVVNFLCAwKTsKKworCQkvKgorCQkgKiBJbiBjYXNlIG9mIGFuIGFkZHJlc3MgZGVj b2RlIGVycm9yLCB3ZSBtdXN0IHJlYWQgZnJvbQorCQkgKiB0aGUgVVNCX0JSSURHRV9FUlJfQURE UiByZWdpc3RlciB0byBjbGVhciBpdCB0byBhbGxvdworCQkgKiB0aGUgY29udHJvbGxlciB0byBs YXRjaCBhIG5ldyBhZGRyZXNzIGluIG5leHQgdGltZSB0aGlzCisJCSAqIGVycm9yIG9jY3Vycy4g SWYgd2UgZG9uJ3QgcmVhZCBpdCwgd2UgZ2V0IHRoZSBpbnRlcnJ1cHQKKwkJICogcmVpc3N1ZWQg YWQgaW5maW5pdHVtLCBldmVuIHRob3VnaCB3ZSBoYXZlIGNsZWFyZWQgdGhlCisJCSAqIGludGVy cnVwdCBjYXVzZS4KKwkJICovCisJCWlmIChjYXVzZSAmIE1WX1VTQl9BRERSX0RFQ09ERV9FUlIp CisJCXsKKwkJCXVuc2lnbmVkIGVycmFkZHIgPSBFUkVBRDQoc2MsIFVTQl9CUklER0VfRVJSX0FE RFIpOworCQkJcHJpbnRmKCJJUlEgRVJSOiBVU0IgQnJpZGdlIEVycm9yIEFkZHJlc3M6IDB4JTA4 eFxuIiwKKwkJCQllcnJhZGRyKTsKKwkJfQogCX0KIAlyZXR1cm4gKEZJTFRFUl9IQU5ETEVEKTsK IH0KLS0tIHN5cy9hcm0vbXYvbXZ3aW4uaC5vcmlnCTIwMTAtMDktMTggMTg6MTM6MDkuMDAwMDAw MDAwICsxMDAwCisrKyBzeXMvYXJtL212L212d2luLmgJMjAxMC0wOS0xOCAxODoxNzo0NC4wMDAw MDAwMDAgKzEwMDAKQEAgLTEzOCw4ICsxMzgsOCBAQAogI2RlZmluZSBNVl9XSU5fQ0VTQV9BVFRS CQkwCiAjZW5kaWYKIAotI2RlZmluZSBNVl9XSU5fVVNCX0NUUkwobikJCSgweDEwICogKG4pICsg MHgwKQotI2RlZmluZSBNVl9XSU5fVVNCX0JBU0UobikJCSgweDEwICogKG4pICsgMHg0KQorI2Rl ZmluZSBNVl9XSU5fVVNCX0NUUkwobikJCSgweDEwICogKG4pICsgMHgzMjApCisjZGVmaW5lIE1W X1dJTl9VU0JfQkFTRShuKQkJKDB4MTAgKiAobikgKyAweDMyNCkKICNkZWZpbmUgTVZfV0lOX1VT Ql9NQVgJCQk0CiAKICNkZWZpbmUgTVZfV0lOX0VUSF9CQVNFKG4pCQkoMHg4ICogKG4pICsgMHgy MDApCg== --005045013dcc1b66c1049084eec3--