From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 27 02:10:04 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D16816A4CF for ; Sun, 27 Feb 2005 02:10:03 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99EA743D2D for ; Sun, 27 Feb 2005 02:10:02 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 84F78512AF; Sat, 26 Feb 2005 18:10:01 -0800 (PST) Date: Sat, 26 Feb 2005 18:10:01 -0800 From: Kris Kennaway To: sparc64@FreeBSD.org Message-ID: <20050227021000.GA47037@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: "esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 4000" on e4500 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 02:10:04 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline An e4500 running RELENG_5 crashed overnight with the following. I asked Justin Gibbs about it, and he suggested that "The driver seems to be complaining that its internal state is indicating that a DMA is *not* in progress, but the chip is saying it is." Kris db> show msgbuf msgbufp = 0xfffff80001407fe0 magic = 63062, size = 32736, r= 115944, w = 116197, ptr = 0xfffff80001400000, cksum= 2460862 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 /var: bad dir ino 94212 at offset 0: mangled entry panic: ufs_dirbad: bad dir cpuid = 1 KDB: enter: panic 0, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3800 bad block 4763148255218685140, ino 382658 <3>pid 41 (syncer), uid 0 inumber 382658 on /usr: bad block handle_workitem_freeblocks: block count esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 <118>Feb 26 04:35:51 e4500 kernel: pid 41 (syncer), uid 0 inumber 382658 on /usr: bad block esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 4000 bad block 4763148255213948044, ino 382790 <3>pid 41 (syncer), uid 0 inumber 382790 on /usr: bad block handle_workitem_freeblocks: block count esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 4000 bad block 4764278571448611635, ino 404198 <3>pid 41 (syncer), uid 0 inumber 404198 on /usr: bad block handle_workitem_freeblocks: block count bad block 4763148255222369549, ino 424054 <3>pid 41 (syncer), uid 0 inumber 424054 on /usr: bad block handle_workitem_freeblocks: block count esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 <118>Feb 26 04:35:52 e4500 kernel: pid 41 (syncer), uid 0 inumber 382790 on /usr: bad block esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 <118>Feb 26 04:35:52 e4500 kernel: pid 41 (syncer), uid 0 inumber 404198 on /usr: bad block esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 4000 <118>Feb 26 04:35:52 e4500 kernel: pid 41 (syncer), uid 0 inumber 424054 on /usr: bad block esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1000 esp0: unexpected disconnect [state 5, intr 20, stat 90, phase(c 100, p 0)]; sending REQUEST SENSE (da0:esp0:0:0:0): esp0: timed out [ecb 0x10001ec48 (flags 0x5, dleft 20, stat 0)], (da0:esp0:0:0:0): sync negotiation disabled esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 20 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 1000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 1800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 3800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 db> wh Tracing pid 6122 tid 100299 td 0xfffff8002a7e9c30 panic() at panic+0x16c ufs_dirbad() at ufs_dirbad+0x38 ufs_lookup() at ufs_lookup+0x32c ufs_vnoperate() at ufs_vnoperate+0x1c vfs_cache_lookup() at vfs_cache_lookup+0x12c ufs_vnoperate() at ufs_vnoperate+0x1c lookup() at lookup+0x440 namei() at namei+0x274 stat() at stat+0x24 syscall() at syscall+0x318 -- syscall (188, FreeBSD ELF64, stat) %o7=0x105cc8 -- userland() at 0x40673728 user trace: trap %o7=0x105cc8 pc 0x40673728, sp 0x7fdffffbae1 pc 0x10560c, sp 0x7fdffffc0b1 pc 0x104584, sp 0x7fdffffc1b1 pc 0x1024f0, sp 0x7fdffffe391 pc 0x4025ac34, sp 0x7fdffffe451 done db> --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCISv4Wry0BWjoQKURAv5IAJ9XsrzZ1vgGRSxMhKdlb51vBRi2xwCg9lzG rJNPPt3Y/wtXIrQfi8qRb1A= =ocUh -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 27 08:17:32 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C58016A4CE; Sun, 27 Feb 2005 08:17:32 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF85943D39; Sun, 27 Feb 2005 08:17:31 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j1R8HVwu045495; Sun, 27 Feb 2005 03:17:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id j1R8HVvt048044; Sun, 27 Feb 2005 03:17:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 69FD37306E; Sun, 27 Feb 2005 03:17:30 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050227081730.69FD37306E@freebsd-current.sentex.ca> Date: Sun, 27 Feb 2005 03:17:30 -0500 (EST) X-Virus-Scanned: ClamAV 0.82/730/Sat Feb 26 20:56:54 2005 on smarthost2.sentex.ca X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner3 X-Virus-Status: Clean Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 08:17:32 -0000 TB --- 2005-02-27 06:24:19 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-27 06:24:19 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-02-27 06:24:19 - checking out the source tree TB --- 2005-02-27 06:24:19 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-02-27 06:24:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-27 06:38:46 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-27 06:38:46 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-02-27 06:38:46 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-02-27 07:53:19 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-27 07:53:19 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-02-27 07:53:19 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Feb 27 07:53:19 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Feb 27 08:05:38 UTC 2005 TB --- 2005-02-27 08:05:38 - generating LINT kernel config TB --- 2005-02-27 08:05:38 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- 2005-02-27 08:05:38 - /usr/bin/make -B LINT TB --- 2005-02-27 08:05:38 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-02-27 08:05:38 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-02-27 08:05:38 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 27 08:05:39 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/netinet/in.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/netinet/ip_carp.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/netinet/ip_carp.c:1123: warning: static declaration of 'carp_iamatch6' follows non-static declaration /tinderbox/CURRENT/sparc64/sparc64/src/sys/netinet/ip_carp.h:159: warning: previous declaration of 'carp_iamatch6' was here /tinderbox/CURRENT/sparc64/sparc64/src/sys/netinet/ip_carp.c:1147: warning: static declaration of 'carp_macmatch6' follows non-static declaration /tinderbox/CURRENT/sparc64/sparc64/src/sys/netinet/ip_carp.h:160: warning: previous declaration of 'carp_macmatch6' was here /tinderbox/CURRENT/sparc64/sparc64/src/sys/netinet/ip_carp.c:1123: warning: 'carp_iamatch6' defined but not used /tinderbox/CURRENT/sparc64/sparc64/src/sys/netinet/ip_carp.c:1147: warning: 'carp_macmatch6' defined but not used *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-02-27 08:17:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-27 08:17:30 - ERROR: failed to build lint kernel TB --- 2005-02-27 08:17:30 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 27 16:06:33 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1386816A4CE for ; Sun, 27 Feb 2005 16:06:33 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id EF89D43D5F for ; Sun, 27 Feb 2005 16:06:31 +0000 (GMT) (envelope-from mmuthmann@gmx.net) Received: (qmail invoked by alias); 27 Feb 2005 16:06:30 -0000 Received: from pD954139A.dip.t-dialin.net (EHLO [192.168.0.2]) (217.84.19.154) by mail.gmx.net (mp011) with SMTP; 27 Feb 2005 17:06:30 +0100 X-Authenticated: #1009348 From: Matthias Muthmann To: freebsd-sparc64@freebsd.org In-Reply-To: <200502262246.43689.dejan.lesjak@ijs.si> References: <200502240244.03104.dejan.lesjak@ijs.si> <200502262246.43689.dejan.lesjak@ijs.si> Content-Type: text/plain Date: Sun, 27 Feb 2005 17:06:39 +0100 Message-Id: <1109520399.19005.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 cc: Dejan Lesjak cc: Aaron Dudek Subject: Re: Problems with X.. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 16:06:33 -0000 On Sa, 2005-02-26 at 22:46 +0100, Dejan Lesjak wrote: > Hmm, can you try patch at http://www.ijs.si/~lesi/xorg/patch-bsd_kbd.c in > addition to previous one. These are copied over from old keyboard driver > code. The keys you've mentioned - do they not work at all or do they produce > weird codes? > > > Dejan > Your 2nd patch does'nt seem to do anything... but I could be wrong because I cant't do very much without the last row of letters. They still don't work: The don't do anything - no strange letters, no beeps no other effects. I hope this helped - and thanks for your efforts! If I have time I will try out any other patches for the keyboard driver. -- Matthias Muthmann From owner-freebsd-sparc64@FreeBSD.ORG Sun Feb 27 20:53:38 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 282ED16A4CE; Sun, 27 Feb 2005 20:53:38 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A963043D2D; Sun, 27 Feb 2005 20:53:37 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j1RKrbcR063316; Sun, 27 Feb 2005 15:53:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j1RKrbs3043205; Sun, 27 Feb 2005 15:53:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EB82F7306E; Sun, 27 Feb 2005 15:53:36 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050227205336.EB82F7306E@freebsd-current.sentex.ca> Date: Sun, 27 Feb 2005 15:53:36 -0500 (EST) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 20:53:38 -0000 TB --- 2005-02-27 20:23:10 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-27 20:23:10 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-02-27 20:23:10 - checking out the source tree TB --- 2005-02-27 20:23:10 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-02-27 20:23:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-02-27 20:28:46 - building world (CFLAGS=-O2 -pipe) TB --- 2005-02-27 20:28:46 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-02-27 20:28:46 - /usr/bin/make -B buildworld >>> 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 [...] cc -O2 -pipe -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/string/strdup.c cc -O2 -pipe -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/include -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../include -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64 -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/../../contrib/gdtoa -DINET6 -I/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc -DPOSIX_MISTAKE -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/locale -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/rpc -DYP -DHESIOD -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/string/strerror.c /tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/string/strerror.c: In function `strerror': /tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/string/strerror.c:125: error: `NL_TEXTMAX' undeclared (first use in this function) /tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/string/strerror.c:125: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/string/strerror.c:125: error: for each function it appears in.) /tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/string/strerror.c:125: warning: unused variable `ebuf' /tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/string/strerror.c:125: error: storage size of `ebuf' isn't known *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/lib/libc. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/lib. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-02-27 20:53:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-27 20:53:36 - ERROR: failed to build world TB --- 2005-02-27 20:53:36 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 28 11:02:01 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8797216A4EB for ; Mon, 28 Feb 2005 11:02:01 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F7C743D58 for ; Mon, 28 Feb 2005 11:02:01 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1SB21RY006773 for ; Mon, 28 Feb 2005 11:02:01 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1SB20rE006767 for freebsd-sparc64@freebsd.org; Mon, 28 Feb 2005 11:02:00 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 28 Feb 2005 11:02:00 GMT Message-Id: <200502281102.j1SB20rE006767@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 11:02:01 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/06/24] sparc64/53670sparc64 pthreads implementation on 5.1-Release sp o [2004/01/29] sparc64/62053sparc64 Using bridging on 5.2 Sparc64 causes imme o [2004/09/14] sparc64/71729sparc64 printf in kernel thread causes panic on S o [2004/10/21] sparc64/72962sparc64 [sysinstall] Sysinstall panics on sparc64 o [2004/11/02] sparc64/73413sparc64 [patch] pthread(libkse) library is broken o [2004/11/10] sparc64/73782sparc64 libc is missing the _Qp_cmp function o [2005/02/12] sparc64/77417sparc64 [panic] with high usage of cpu when lan u 7 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2003/10/11] sparc64/57856sparc64 sparc64: IDE Raid controller no detect di o [2004/07/09] sparc64/68869sparc64 netcard: Unexpect packet size, drop packe o [2004/08/02] sparc64/69893sparc64 asr panics the system on sparc64 o [2004/10/15] sparc64/72731sparc64 sparc64, 5.3-BETA7, "host" command doesn' o [2004/10/22] sparc64/72998sparc64 [patch] set_mcontext() change syscalls pa o [2004/12/24] sparc64/75458sparc64 Add detection of US-IIIi processor f [2005/01/03] sparc64/75735sparc64 misconfigured qfe ports 7 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 28 11:52:11 2005 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0B0716A4CE; Mon, 28 Feb 2005 11:52:11 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7809043D2D; Mon, 28 Feb 2005 11:52:11 +0000 (GMT) (envelope-from marius@FreeBSD.org) Received: from freefall.freebsd.org (marius@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1SBqBIT023686; Mon, 28 Feb 2005 11:52:11 GMT (envelope-from marius@freefall.freebsd.org) Received: (from marius@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1SBqBpK023682; Mon, 28 Feb 2005 11:52:11 GMT (envelope-from marius) Date: Mon, 28 Feb 2005 11:52:11 GMT From: Marius Strobl Message-Id: <200502281152.j1SBqBpK023682@freefall.freebsd.org> To: king@v2project.com, marius@FreeBSD.org, freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/57856: sparc64: IDE Raid controller no detect discs X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 11:52:11 -0000 Synopsis: sparc64: IDE Raid controller no detect discs State-Changed-From-To: analyzed->closed State-Changed-By: marius State-Changed-When: Mon Feb 28 11:49:16 GMT 2005 State-Changed-Why: Close, we won't teach ata(4) to compensate for not executed x86 BIOS. http://www.freebsd.org/cgi/query-pr.cgi?pr=57856 From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 28 12:05:30 2005 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEB0016A4CE; Mon, 28 Feb 2005 12:05:30 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C496243D2F; Mon, 28 Feb 2005 12:05:30 +0000 (GMT) (envelope-from marius@FreeBSD.org) Received: from freefall.freebsd.org (marius@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1SC5UC8028389; Mon, 28 Feb 2005 12:05:30 GMT (envelope-from marius@freefall.freebsd.org) Received: (from marius@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1SC5UW3028385; Mon, 28 Feb 2005 12:05:30 GMT (envelope-from marius) Date: Mon, 28 Feb 2005 12:05:30 GMT From: Marius Strobl Message-Id: <200502281205.j1SC5UW3028385@freefall.freebsd.org> To: magicloud@hotmail.com, marius@FreeBSD.org, freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/68869: netcard: Unexpect packet size, drop packet. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 12:05:31 -0000 Synopsis: netcard: Unexpect packet size, drop packet. State-Changed-From-To: open->feedback State-Changed-By: marius State-Changed-When: Mon Feb 28 12:02:12 GMT 2005 State-Changed-Why: This is believed to be fixed since src/sbin/ifconfig/ifconfig.c rev. 1.106. Could you please test whether the problem still persists in FreeBSD >= 5.3? http://www.freebsd.org/cgi/query-pr.cgi?pr=68869 From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 28 12:10:49 2005 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90B5A16A4CE; Mon, 28 Feb 2005 12:10:49 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65BD143D5E; Mon, 28 Feb 2005 12:10:49 +0000 (GMT) (envelope-from marius@FreeBSD.org) Received: from freefall.freebsd.org (marius@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1SCAneo028646; Mon, 28 Feb 2005 12:10:49 GMT (envelope-from marius@freefall.freebsd.org) Received: (from marius@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1SCAmfN028642; Mon, 28 Feb 2005 12:10:48 GMT (envelope-from marius) Date: Mon, 28 Feb 2005 12:10:48 GMT From: Marius Strobl Message-Id: <200502281210.j1SCAmfN028642@freefall.freebsd.org> To: rblechinger@exbb.de, marius@FreeBSD.org, freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/72731: sparc64, 5.3-BETA7, "host" command doesn't work X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 12:10:49 -0000 Synopsis: sparc64, 5.3-BETA7, "host" command doesn't work State-Changed-From-To: open->closed State-Changed-By: marius State-Changed-When: Mon Feb 28 12:09:17 GMT 2005 State-Changed-Why: Not a bug, originator found local configuration problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=72731 From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 28 12:48:55 2005 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47BCD16A4CE; Mon, 28 Feb 2005 12:48:55 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B42143D46; Mon, 28 Feb 2005 12:48:55 +0000 (GMT) (envelope-from marius@FreeBSD.org) Received: from freefall.freebsd.org (marius@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1SCms0n032440; Mon, 28 Feb 2005 12:48:54 GMT (envelope-from marius@freefall.freebsd.org) Received: (from marius@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1SCms51032436; Mon, 28 Feb 2005 12:48:54 GMT (envelope-from marius) Date: Mon, 28 Feb 2005 12:48:54 GMT From: Marius Strobl Message-Id: <200502281248.j1SCms51032436@freefall.freebsd.org> To: gavin.atkinson@ury.york.ac.uk, marius@FreeBSD.org, freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/75458: Add detection of US-IIIi processor X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 12:48:55 -0000 Synopsis: Add detection of US-IIIi processor State-Changed-From-To: open->closed State-Changed-By: marius State-Changed-When: Mon Feb 28 12:41:21 GMT 2005 State-Changed-Why: Committed in: sys/sparc64/include/ver.h rev. 1.5 (MFC'ed to RELENG_5 in rev. 1.4.8.1) sys/sparc64/sparc64/identcpu.c rev. 1.13 (MFC'ed to RELENG_5 in rev. 1.12.2.2) Thanks for the report. http://www.freebsd.org/cgi/query-pr.cgi?pr=75458 From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 28 12:54:13 2005 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BC5316A4CE; Mon, 28 Feb 2005 12:54:13 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D797043D58; Mon, 28 Feb 2005 12:54:12 +0000 (GMT) (envelope-from marius@FreeBSD.org) Received: from freefall.freebsd.org (marius@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1SCsCYq032685; Mon, 28 Feb 2005 12:54:12 GMT (envelope-from marius@freefall.freebsd.org) Received: (from marius@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1SCsCct032681; Mon, 28 Feb 2005 12:54:12 GMT (envelope-from marius) Date: Mon, 28 Feb 2005 12:54:12 GMT From: Marius Strobl Message-Id: <200502281254.j1SCsCct032681@freefall.freebsd.org> To: jbrierre@bellsouth.net, marius@FreeBSD.org, freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/75735: misconfigured qfe ports X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 12:54:13 -0000 Synopsis: misconfigured qfe ports State-Changed-From-To: feedback->closed State-Changed-By: marius State-Changed-When: Mon Feb 28 12:52:31 GMT 2005 State-Changed-Why: Close, appears to be local configuration problem, no further reply from originator after feedback was provided. http://www.freebsd.org/cgi/query-pr.cgi?pr=75735 From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 28 13:59:12 2005 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31CA616A52E; Mon, 28 Feb 2005 13:59:12 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0618A43D5A; Mon, 28 Feb 2005 13:59:12 +0000 (GMT) (envelope-from marius@FreeBSD.org) Received: from freefall.freebsd.org (marius@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1SDxB0u040046; Mon, 28 Feb 2005 13:59:11 GMT (envelope-from marius@freefall.freebsd.org) Received: (from marius@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1SDxBm2040042; Mon, 28 Feb 2005 13:59:11 GMT (envelope-from marius) Date: Mon, 28 Feb 2005 13:59:11 GMT From: Marius Strobl Message-Id: <200502281359.j1SDxBm2040042@freefall.freebsd.org> To: steven@natural.keybaud.org, marius@FreeBSD.org, freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/53670: pthreads implementation on 5.1-Release sparc64 not working X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 13:59:12 -0000 Synopsis: pthreads implementation on 5.1-Release sparc64 not working State-Changed-From-To: open->closed State-Changed-By: marius State-Changed-When: Mon Feb 28 13:57:56 GMT 2005 State-Changed-Why: Close, not reproducible, no reply from originator after feedback was provided. http://www.freebsd.org/cgi/query-pr.cgi?pr=53670 From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 28 14:07:30 2005 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA77216A4CE; Mon, 28 Feb 2005 14:07:30 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80CA443D5A; Mon, 28 Feb 2005 14:07:30 +0000 (GMT) (envelope-from marius@FreeBSD.org) Received: from freefall.freebsd.org (marius@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1SE7UqB044626; Mon, 28 Feb 2005 14:07:30 GMT (envelope-from marius@freefall.freebsd.org) Received: (from marius@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1SE7U6p044622; Mon, 28 Feb 2005 14:07:30 GMT (envelope-from marius) Date: Mon, 28 Feb 2005 14:07:30 GMT From: Marius Strobl Message-Id: <200502281407.j1SE7U6p044622@freefall.freebsd.org> To: jim.small@eds.com, marius@FreeBSD.org, freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/62053: Using bridging on 5.2 Sparc64 causes immediate panic X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 14:07:30 -0000 Synopsis: Using bridging on 5.2 Sparc64 causes immediate panic State-Changed-From-To: open->feedback State-Changed-By: marius State-Changed-When: Mon Feb 28 14:03:29 GMT 2005 State-Changed-Why: Jim, this problem was reported to be no longer reproducible by another person. Could you please test whether it still persists on your machine with a recent version of FreeBSD? http://www.freebsd.org/cgi/query-pr.cgi?pr=62053 From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 28 16:30:19 2005 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A233716A4CE for ; Mon, 28 Feb 2005 16:30:19 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6285C43D55 for ; Mon, 28 Feb 2005 16:30:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1SGUJdc060145 for ; Mon, 28 Feb 2005 16:30:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1SGUJFk060143; Mon, 28 Feb 2005 16:30:19 GMT (envelope-from gnats) Date: Mon, 28 Feb 2005 16:30:19 GMT Message-Id: <200502281630.j1SGUJFk060143@freefall.freebsd.org> To: freebsd-sparc64@FreeBSD.org From: Marius Strobl Subject: Re: sparc64/72962: [sysinstall] Sysinstall panics on sparc64 if /dev/cd0 present X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Marius Strobl List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 16:30:19 -0000 The following reply was made to PR sparc64/72962; it has been noted by GNATS. From: Marius Strobl To: Pyun YongHyeon , freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: sparc64/72962: [sysinstall] Sysinstall panics on sparc64 if /dev/cd0 present Date: Mon, 28 Feb 2005 17:23:22 +0100 Pyun, the underlying cause of this problem is that SCSI CDROMs are enlisted in kern.disks, which is because cd(4) uses disk(9) since rev. 1.28 of scsi_cd.c, i.e. also pre-GEOM. Disk(9) is an API for disk-like storage devices, i.e. not necessarily limited to hard- disks. Therefore I think sysinstall(8) is actually the right place to deal with this, rather than geom(4) or libdisk(3), and your change in src/usr.sbin/sysinstall/devices.c rev. 1.159 is a fix rather than just a work-around. Maybe the comment could be improved somewhat but otherwise I think this PR can be closed. Marius From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 28 17:48:55 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C18716A4CE for ; Mon, 28 Feb 2005 17:48:55 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2EB543D54 for ; Mon, 28 Feb 2005 17:48:54 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost [IPv6:::1]) by niobe.ijs.si (Postfix) with ESMTP id E86F51DD41C; Mon, 28 Feb 2005 18:48:53 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36943-01; Mon, 28 Feb 2005 18:48:43 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id E8D651DD578; Mon, 28 Feb 2005 18:48:37 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id DCC601C00726; Mon, 28 Feb 2005 18:48:36 +0100 (CET) From: Dejan Lesjak To: Matthias Muthmann Date: Mon, 28 Feb 2005 18:48:35 +0100 User-Agent: KMail/1.7.2 References: <200502240244.03104.dejan.lesjak@ijs.si> <200502262246.43689.dejan.lesjak@ijs.si> <1109520399.19005.4.camel@localhost> In-Reply-To: <1109520399.19005.4.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502281848.36373.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: Aaron Dudek cc: freebsd-sparc64@freebsd.org Subject: Re: Problems with X.. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 17:48:55 -0000 On Sunday 27 of February 2005 17:06, Matthias Muthmann wrote: > On Sa, 2005-02-26 at 22:46 +0100, Dejan Lesjak wrote: > > Hmm, can you try patch at http://www.ijs.si/~lesi/xorg/patch-bsd_kbd.c in > > addition to previous one. These are copied over from old keyboard driver > > code. The keys you've mentioned - do they not work at all or do they > > produce weird codes? > > > > > > Dejan > > Your 2nd patch does'nt seem to do anything... but I could be wrong > because I cant't do very much without the last row of letters. They > still don't work: The don't do anything - no strange letters, no beeps > no other effects. I hope this helped - and thanks for your efforts! If I > have time I will try out any other patches for the keyboard driver. Gah, I was afraid of that. This was so far copy-pasted from old keyboard driver. Well at least some keys work...:) Could you get X server up and then run xev(1) from console and see if the keys that are not working produce any events. The ones we're looking for are KeyPress and KeyRelease and from those, keycode and keysym are interesting. Unfortunately syscons doesn't work on my Ultra5 so I can't check myself. If keycodes do come we'll have to make them translate to proper keysyms. If there are no events sent at all, you could also try this without any patches and see if those break getting keycodes (in which case I've botched copy-paste in the first place)... Dejan From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 28 20:07:57 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04E9E16A4CE for ; Mon, 28 Feb 2005 20:07:57 +0000 (GMT) Received: from elle.res.sprintlink.net (ibogw-fw2.sprintlink.net [199.0.233.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32F1143D5A for ; Mon, 28 Feb 2005 20:07:56 +0000 (GMT) (envelope-from adudek@sprint.net) Received: from iscserv1.res.sprintlink.net (iscserv1.res.sprintlink.net [199.0.237.253])j1SK2LM28835; Mon, 28 Feb 2005 15:02:21 -0500 (EST) Received: from localhost (adudek@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id PAA03145; Mon, 28 Feb 2005 15:07:53 -0500 (EST) X-Authentication-Warning: iscserv1.res.sprintlink.net: adudek owned process doing -bs Date: Mon, 28 Feb 2005 15:07:53 -0500 (EST) From: Aaron Dudek X-X-Sender: adudek@iscserv1 To: Dejan Lesjak In-Reply-To: <200502262246.43689.dejan.lesjak@ijs.si> Message-ID: References: <200502240244.03104.dejan.lesjak@ijs.si> <200502262246.43689.dejan.lesjak@ijs.si> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-sparc64@freebsd.org Subject: Re: Problems with X.. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 20:07:57 -0000 I will try it. The keys currently do not produce any output or have any visible function. Aaron On Sat, 26 Feb 2005, Dejan Lesjak wrote: > On Friday 25 of February 2005 18:07, Aaron Dudek wrote: >> I seemed to have spoken too soon. >> Keys that don't seem to work in either xterm or gvim. >> Tab, Enter, the entire bottom row of leters, the number pad. > > Hmm, can you try patch at http://www.ijs.si/~lesi/xorg/patch-bsd_kbd.c in > addition to previous one. These are copied over from old keyboard driver > code. The keys you've mentioned - do they not work at all or do they produce > weird codes? > > > Dejan > From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 28 21:39:23 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E9FD16A4CF for ; Mon, 28 Feb 2005 21:39:23 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE7A043D54 for ; Mon, 28 Feb 2005 21:39:22 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 38275512A7; Mon, 28 Feb 2005 13:39:22 -0800 (PST) Date: Mon, 28 Feb 2005 13:39:22 -0800 From: Kris Kennaway To: Kris Kennaway Message-ID: <20050228213922.GA99607@xor.obsecurity.org> References: <20050227021000.GA47037@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <20050227021000.GA47037@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: sparc64@FreeBSD.org Subject: Re: "esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 4000" on e4500 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 21:39:23 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 26, 2005 at 06:10:01PM -0800, Kris Kennaway wrote: > An e4500 running RELENG_5 crashed overnight with the following. I > asked Justin Gibbs about it, and he suggested that >=20 > "The driver seems to be complaining that its internal state is > indicating that a DMA is *not* in progress, but the chip is saying it > is." >=20 > Kris >=20 > db> show msgbuf > msgbufp =3D 0xfffff80001407fe0 > magic =3D 63062, size =3D 32736, r=3D 115944, w =3D 116197, ptr =3D 0xfff= ff80001400000, cksum=3D 2460862 > esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 > esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 > /var: bad dir ino 94212 at offset 0: mangled entry > panic: ufs_dirbad: bad dir The above panic caused quite serious data corruption, and after reinstalling 5.3-STABLE and starting a buildworld it recurred with: esp0: unexpected disconnect [state 5, intr 20, stat 90, phase(c 100, p 0)];= sending REQUEST SENSE esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 2800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 800 esp0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 0, resid 4000 /usr: bad dir ino 612938 at offset 0: mangled entry panic: ufs_dirbad: bad dir Kris --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCI4+JWry0BWjoQKURArj3AJ9TR8FgRZMwtP5lRl1s9ltQVvCAkQCgkREd TqWNFDIXAdMw+lCyQ/WIr5o= =dGwb -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 28 23:17:58 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5270716A4CE for ; Mon, 28 Feb 2005 23:17:58 +0000 (GMT) Received: from post-22.mail.nl.demon.net (post-22.mail.nl.demon.net [194.159.73.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id F033543D41 for ; Mon, 28 Feb 2005 23:17:57 +0000 (GMT) (envelope-from kwm@rainbow-runner.nl) Received: from kazerne.demon.nl ([212.238.222.22]:65320 helo=heater.rainbow-runner.nl) by post-22.mail.nl.demon.net with esmtp (Exim 4.43) id 1D5u9E-0006tu-It; Mon, 28 Feb 2005 23:17:56 +0000 From: Koop Mast To: Marius Strobl In-Reply-To: <20050216142205.N18907@newtrinity.zeist.de> References: <20050215020433.B72346@newtrinity.zeist.de> <1108478092.30515.9.camel@heater.rainbow-runner.nl> <20050216142205.N18907@newtrinity.zeist.de> Content-Type: text/plain Date: Tue, 01 Mar 2005 00:18:12 +0100 Message-Id: <1109632692.795.10.camel@heater.rainbow-runner.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: sparc64@freebsd.org Subject: Re: Testers with U10/Creator wanted X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 23:17:58 -0000 Op wo, 16-02-2005 te 14:22 +0100, schreef Marius Strobl: >On Tue, Feb 15, 2005 at 03:34:52PM +0100, Koop Mast wrote: >> Op di, 15-02-2005 te 02:04 +0100, schreef Marius Strobl: >> >People who tried syscons(4) on Ultra 10 in the past reported a hang >> >during boot after the screen is blanked. I managed to reproduce and >> >fix this on a Sun AXi board. Could someone with a Creator(3D) or >> >Elite3D equipped Ultra 10 please give the patch at: >> >http://alchemy.franken.de/~marius/delay_fix.diff >> >a try to see if it also solves the problem there? It shouldn't matter >> >if you are running -stable or -current. >> >> My hero! >> >> Works fine on my Ultra10 here. >> >> # Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 360MHz), No Keyboard >> # OpenBoot 3.31, 1024 MB (60 ns) memory installed, Serial #xxxxxxxx. >> >> Only my monitor doesn't want to display anything. Probably a local >> problem. Maybe something non related to the patch. > >The patch fixes DELAY() which would never return in certain situations >when used early in boot. The excessive use of DELAY() in uart(4) when >probing Sun keyboards seems to always manage to trigger this. >If you don't get display output then this should be another issue. >Does the monitor work before FreeBSD is booted, i.e. do you see the >Open Firmware banner etc.? >So far I got one other reply in private mail stating that syscons(4) >would work on U10 with the patch. Did the patch change anything for >you, i.e. did you try syscons(4) on your U10 in the past and also >got the mentioned hang? > >> >> I'm going to test this also on a Ultra1 with a creator card (non-3D). >> But that can take a little while. >> > >As far as I can tell only UltraSparc II[e,i] based systems are affected >by this issue so the patch shouldn't make any difference on an U1. >Have you tried syscons(4) on that U1 before? There's probably a nit >with creator(4) and old Creator cards that should be fixed but so far >I didn't find a Creator card that is "old enough" to be affected. Could >you please send me the output of `ofwdump -a -p` of that machine? My Ultra1 (5.3-stable) is happily running syscons(4) with the tick patch. Thanks again for this patch. Koop >Marius > From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 00:04:38 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DB9516A4CE; Tue, 1 Mar 2005 00:04:38 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4877E43D55; Tue, 1 Mar 2005 00:04:38 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C14D1512A7; Mon, 28 Feb 2005 16:04:36 -0800 (PST) Date: Mon, 28 Feb 2005 16:04:36 -0800 From: Kris Kennaway To: net@FreeBSD.org Message-ID: <20050301000436.GA33346@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: rwatson@FreeBSD.org cc: sparc64@FreeBSD.org Subject: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 00:04:38 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm seeing an easily-provoked livelock on quad-CPU sparc64 machines running RELENG_5. It's hard to get a good trace because the processes running on other CPUs cannot be traced from DDB, but I've been lucky a few times: db> show alllocks Process 15 (swi1: net) thread 0xfffff8001fb07480 (100008) exclusive sleep mutex so_snd r = 0 (0xfffff800178432a8) locked @ netinet/tcp_input.c:2189 exclusive sleep mutex inp (tcpinp) r = 0 (0xfffff800155c3b08) locked @ netinet/tcp_input.c:744 exclusive sleep mutex tcp r = 0 (0xc0bdf788) locked @ netinet/tcp_input.c:617 db> wh 15 Tracing pid 15 tid 100008 td 0xfffff8001fb07480 sab_intr() at sab_intr+0x40 psycho_intr_stub() at psycho_intr_stub+0x8 intr_fast() at intr_fast+0x88 -- interrupt level=0xd pil=0 %o7=0xc01a0040 -- mb_free_ext() at mb_free_ext+0x28 sbdrop_locked() at sbdrop_locked+0x19c tcp_input() at tcp_input+0x2aa0 ip_input() at ip_input+0x964 netisr_processqueue() at netisr_processqueue+0x7c swi_net() at swi_net+0x120 ithread_loop() at ithread_loop+0x24c fork_exit() at fork_exit+0xd4 fork_trampoline() at fork_trampoline+0x8 db> That code is here in mb_free_ext(): /* * This is tricky. We need to make sure to decrement the * refcount in a safe way but to also clean up if we're the * last reference. This method seems to do it without race. */ while (dofree == 0) { cnt = *(m->m_ext.ref_cnt); if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { if (cnt == 1) dofree = 1; break; } } mb_free_ext+0x24: casa 0x4 , %g2, %g1 mb_free_ext+0x28: subcc %g1, %g2, %g0 which is inside the atomic_cmpset_int (i.e. it's probably spinning in the loop). Can anyone see if there's a problem with this code, or perhaps the sparc64 implementation of atomic_cmpset_int()? Kris --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCI7GUWry0BWjoQKURAlD7AJ972l7rDX+G0cG95Iv2pqEVRINnrQCdHQeP fItGM33s+lUrRQehQkKJx8I= =TG2u -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 05:46:05 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B118416A4CE for ; Tue, 1 Mar 2005 05:46:05 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 938E643D1F for ; Tue, 1 Mar 2005 05:46:05 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 70B3372DD4; Mon, 28 Feb 2005 21:46:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 6E6C072DCB; Mon, 28 Feb 2005 21:46:05 -0800 (PST) Date: Mon, 28 Feb 2005 21:46:05 -0800 (PST) From: Doug White To: Tillman Hodgson In-Reply-To: <20050226031105.GJ92490@seekingfire.com> Message-ID: <20050228214555.R62607@carver.gumbysoft.com> References: <20050226012438.GI92490@seekingfire.com> <20050225181210.C32072@carver.gumbysoft.com> <20050226031105.GJ92490@seekingfire.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-Sparc64 Subject: Re: Serial console seems to have disappeared X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 05:46:05 -0000 On Fri, 25 Feb 2005, Tillman Hodgson wrote: > On Fri, Feb 25, 2005 at 06:14:49PM -0800, Doug White wrote: > > The current recommendation is to use the uart(4) driver, which should > > support the same chips as the zs and sab drivers (unless you're on an > > Enterprise [34][05]00). The tty device changes to /dev/ttyu*. > > > > Prior to that change I had gettys starting on ttyz[01] and not using the > > ttya/b links -- I'm not even sure where those come from. > > Thanks muchly for your information -- it's currently working great on > ttyz1, and I'm starting to look into what it'll take to move to uart(4) > (google seems to be saying that just swapping the devices into/out of my > kernel ought to work). .. and tweaking ttys appropriately :-) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 06:00:39 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1411916A4D2; Tue, 1 Mar 2005 06:00:39 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC36043D69; Tue, 1 Mar 2005 06:00:25 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id C939872DD4; Mon, 28 Feb 2005 22:00:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id C6C5B72DCB; Mon, 28 Feb 2005 22:00:25 -0800 (PST) Date: Mon, 28 Feb 2005 22:00:25 -0800 (PST) From: Doug White To: Kris Kennaway In-Reply-To: <20050301000436.GA33346@xor.obsecurity.org> Message-ID: <20050228214850.X62607@carver.gumbysoft.com> References: <20050301000436.GA33346@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: sparc64@FreeBSD.org cc: rwatson@FreeBSD.org cc: net@FreeBSD.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 06:00:39 -0000 Since we're moving the conversation on this over here.... On Mon, 28 Feb 2005, Kris Kennaway wrote: > I'm seeing an easily-provoked livelock on quad-CPU sparc64 machines > running RELENG_5. It's hard to get a good trace because the processes > running on other CPUs cannot be traced from DDB, but I've been lucky a > few times: > > db> show alllocks > Process 15 (swi1: net) thread 0xfffff8001fb07480 (100008) > exclusive sleep mutex so_snd r = 0 (0xfffff800178432a8) locked @ netinet/tcp_input.c:2189 > exclusive sleep mutex inp (tcpinp) r = 0 (0xfffff800155c3b08) locked @ netinet/tcp_input.c:744 > exclusive sleep mutex tcp r = 0 (0xc0bdf788) locked @ netinet/tcp_input.c:617 > db> wh 15 > Tracing pid 15 tid 100008 td 0xfffff8001fb07480 > sab_intr() at sab_intr+0x40 > psycho_intr_stub() at psycho_intr_stub+0x8 > intr_fast() at intr_fast+0x88 > -- interrupt level=0xd pil=0 %o7=0xc01a0040 -- > mb_free_ext() at mb_free_ext+0x28 > sbdrop_locked() at sbdrop_locked+0x19c > tcp_input() at tcp_input+0x2aa0 > ip_input() at ip_input+0x964 > netisr_processqueue() at netisr_processqueue+0x7c > swi_net() at swi_net+0x120 > ithread_loop() at ithread_loop+0x24c > fork_exit() at fork_exit+0xd4 > fork_trampoline() at fork_trampoline+0x8 > db> > > That code is here in mb_free_ext(): > > /* > * This is tricky. We need to make sure to decrement the > * refcount in a safe way but to also clean up if we're the > * last reference. This method seems to do it without race. > */ > while (dofree == 0) { > cnt = *(m->m_ext.ref_cnt); > if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { > if (cnt == 1) > dofree = 1; > break; > } > } > > mb_free_ext+0x24: casa 0x4 , %g2, %g1 > mb_free_ext+0x28: subcc %g1, %g2, %g0 > > which is inside the atomic_cmpset_int (i.e. it's probably spinning in > the loop). > > Can anyone see if there's a problem with this code, or perhaps the > sparc64 implementation of atomic_cmpset_int()? I considered earlier today changing cnt to be a u_int volitile* to match how ipi_wait() does a poll on the cpumask that other CPUs are updating. (alc@ had flagged this earlier on in our debugging.) The volitile marker forces some extra load instructions to ensure both the pointer and the value its pointing to stay fresh. rwatson convinced me to wait and never got back to me though :-) He also suggested putting a loop counter in and perhaps a KASSERT to make sure ref_cnt isn't some absurdly large value (like 0xdeadc0de). Forgive me for being naieve, but is there a reason you don't do an atomic subtraction on the refcount? I can see why it repeats -- if two things are warring over the refcount one or the other keep trying until one wins -- but the subtraction would seem more intuitive. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 07:16:43 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38CAC16A4CE for ; Tue, 1 Mar 2005 07:16:43 +0000 (GMT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3105F43D2F for ; Tue, 1 Mar 2005 07:16:42 +0000 (GMT) (envelope-from mmuthmann@gmx.net) Received: (qmail invoked by alias); 01 Mar 2005 07:16:40 -0000 Received: from p548058CF.dip.t-dialin.net (EHLO [192.168.0.2]) (84.128.88.207) by mail.gmx.net (mp022) with SMTP; 01 Mar 2005 08:16:40 +0100 X-Authenticated: #1009348 From: Matthias Muthmann To: freebsd-sparc64@freebsd.org In-Reply-To: <200502281848.36373.dejan.lesjak@ijs.si> References: <200502240244.03104.dejan.lesjak@ijs.si> <200502262246.43689.dejan.lesjak@ijs.si> <1109520399.19005.4.camel@localhost> <200502281848.36373.dejan.lesjak@ijs.si> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zmnX72h7XaiPV4xv67sb" Date: Tue, 01 Mar 2005 08:16:44 +0100 Message-Id: <1109661404.19204.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Y-GMX-Trusted: 0 cc: Dejan Lesjak Subject: Re: Problems with X.. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 07:16:43 -0000 --=-zmnX72h7XaiPV4xv67sb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mo, 2005-02-28 at 18:48 +0100, Dejan Lesjak wrote: > > have time I will try out any other patches for the keyboard driver. >=20 > Gah, I was afraid of that. This was so far copy-pasted from old keyboard=20 > driver. Well at least some keys work...:) > Could you get X server up and then run xev(1) from console and see if the= keys=20 > that are not working produce any events. The ones we're looking for are=20 > KeyPress and KeyRelease and from those, keycode and keysym are interestin= g.=20 > Unfortunately syscons doesn't work on my Ultra5 so I can't check myself. = If=20 > keycodes do come we'll have to make them translate to proper keysyms. If=20 > there are no events sent at all, you could also try this without any patc= hes=20 > and see if those break getting keycodes (in which case I've botched=20 > copy-paste in the first place)... >=20 >=20 > Dejan >=20 Well, I just played a little bit on my keyboard and all ef the key (except the "cut"-key) produce events. An example: Pressing "h" and then "n" gives: KeyPress event, serial 20, synthetic YES, window 0xe00001, root 0x34, subw 0x40005f, time 497408, (7,4), root:(739,37), state 0x0, keycode 89 (keysym 0x68, h), same_screen YES, XLookupString gives 1 bytes: (68) "h" KeyPress event, serial 20, synthetic YES, window 0xe00001, root 0x34, subw 0x40005f, time 497691, (7,4), root:(739,37), state 0x0, keycode 199 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: Some things I noticed: On the num-pad only the "+-*/" work, return doesn't (work state 0x0, keycode 156 (keysym 0x0, NoSymbol) ) and shift doesn't (work state 0x0, keycode 205 (keysym 0x0, NoSymbol) ). --=20 Matthias Muthmann --=-zmnX72h7XaiPV4xv67sb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCJBbceA8bkj+29gMRAvr4AJ93MKkdWUgHGUmWWLIgUSacg6VvMACbBdSb 07Ix5k5KOd2XiII0TVfpmjo= =VkFc -----END PGP SIGNATURE----- --=-zmnX72h7XaiPV4xv67sb-- From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 10:19:09 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7ACF616A4CF for ; Tue, 1 Mar 2005 10:19:09 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CF6243D49 for ; Tue, 1 Mar 2005 10:19:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 37EBF512A7; Tue, 1 Mar 2005 02:19:08 -0800 (PST) Date: Tue, 1 Mar 2005 02:19:08 -0800 From: Kris Kennaway To: sparc64@FreeBSD.org Message-ID: <20050301101907.GA11640@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: debug.mpsafevm=1 now usable X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 10:19:09 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FYI, this seems to make debug.mpsafevm=3D1 usable for me. Very nice on a SMP machine (e.g. hrs's 12-cpu e4500 :-). Many thanks to Alan for finding and fixing this! Kris ----- Forwarded message from Alan Cox ----- X-Original-To: kkenn@localhost Delivered-To: kkenn@localhost.obsecurity.org Delivered-To: kris@freebsd.org Delivered-To: src-committers@freebsd.org From: Alan Cox Date: Tue, 1 Mar 2005 05:06:52 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/sparc64/sparc64 pmap.c X-FreeBSD-CVS-Branch: HEAD Precedence: bulk X-Loop: FreeBSD.ORG X-UIDL: 1:T"!knl!!KQA"!eM2"! X-Bogosity: No, tests=3Dbogofilter, spamicity=3D0.000000, version=3D0.92.8 alc 2005-03-01 05:06:52 UTC FreeBSD src repository Modified files: sys/sparc64/sparc64 pmap.c=20 Log: Use the kernel pmap's lock to guarantee that only one thread at a time is using either pmap_temp_map_1 or pmap_temp_map_2. =20 Tested by: kris@ =20 Revision Changes Path 1.146 +10 -0 src/sys/sparc64/sparc64/pmap.c http://cvsweb.FreeBSD.org/src/sys/sparc64/sparc64/pmap.c.diff?r1=3D1.145&r2= =3D1.146 | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | RCS file: /usr/local/www/cvsroot/FreeBSD/src/sys/sparc64/sparc64/pmap.c,v | retrieving revision 1.145 | retrieving revision 1.146 | diff -u -p -r1.145 -r1.146 | --- src/sys/sparc64/sparc64/pmap.c 2005/02/05 22:06:47 1.145 | +++ src/sys/sparc64/sparc64/pmap.c 2005/03/01 05:06:52 1.146 | @@ -39,7 +39,7 @@ | * SUCH DAMAGE. | * | * from: @(#)pmap.c 7.7 (Berkeley) 5/12/91 | - * $FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/sparc64/sparc64/pmap= .c,v 1.145 2005/02/05 22:06:47 alc Exp $ | + * $FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/sparc64/sparc64/pmap= .c,v 1.146 2005/03/01 05:06:52 alc Exp $ | */ | =20 | /* | @@ -1518,12 +1518,14 @@ pmap_zero_page(vm_page_t m) | cpu_block_zero((void *)va, PAGE_SIZE); | } else { | PMAP_STATS_INC(pmap_nzero_page_oc); | + PMAP_LOCK(kernel_pmap); | va =3D pmap_temp_map_1 + (m->md.color * PAGE_SIZE); | tp =3D tsb_kvtotte(va); | tp->tte_data =3D TD_V | TD_8K | TD_PA(pa) | TD_CP | TD_CV | TD_W; | tp->tte_vpn =3D TV_VPN(va, TS_8K); | cpu_block_zero((void *)va, PAGE_SIZE); | tlb_page_demap(kernel_pmap, va); | + PMAP_UNLOCK(kernel_pmap); | } | } | =20 | @@ -1548,12 +1550,14 @@ pmap_zero_page_area(vm_page_t m, int off | bzero((void *)(va + off), size); | } else { | PMAP_STATS_INC(pmap_nzero_page_area_oc); | + PMAP_LOCK(kernel_pmap); | va =3D pmap_temp_map_1 + (m->md.color * PAGE_SIZE); | tp =3D tsb_kvtotte(va); | tp->tte_data =3D TD_V | TD_8K | TD_PA(pa) | TD_CP | TD_CV | TD_W; | tp->tte_vpn =3D TV_VPN(va, TS_8K); | bzero((void *)(va + off), size); | tlb_page_demap(kernel_pmap, va); | + PMAP_UNLOCK(kernel_pmap); | } | } | =20 | @@ -1619,6 +1623,7 @@ pmap_copy_page(vm_page_t msrc, vm_page_t | PAGE_SIZE); | } else { | PMAP_STATS_INC(pmap_ncopy_page_doc); | + PMAP_LOCK(kernel_pmap); | vdst =3D pmap_temp_map_1 + (mdst->md.color * PAGE_SIZE); | tp =3D tsb_kvtotte(vdst); | tp->tte_data =3D | @@ -1627,6 +1632,7 @@ pmap_copy_page(vm_page_t msrc, vm_page_t | ascopyfrom(ASI_PHYS_USE_EC, psrc, (void *)vdst, | PAGE_SIZE); | tlb_page_demap(kernel_pmap, vdst); | + PMAP_UNLOCK(kernel_pmap); | } | } else if (mdst->md.color =3D=3D -1) { | if (msrc->md.color =3D=3D DCACHE_COLOR(psrc)) { | @@ -1636,6 +1642,7 @@ pmap_copy_page(vm_page_t msrc, vm_page_t | PAGE_SIZE); | } else { | PMAP_STATS_INC(pmap_ncopy_page_soc); | + PMAP_LOCK(kernel_pmap); | vsrc =3D pmap_temp_map_1 + (msrc->md.color * PAGE_SIZE); | tp =3D tsb_kvtotte(vsrc); | tp->tte_data =3D | @@ -1644,9 +1651,11 @@ pmap_copy_page(vm_page_t msrc, vm_page_t | ascopyto((void *)vsrc, ASI_PHYS_USE_EC, pdst, | PAGE_SIZE); | tlb_page_demap(kernel_pmap, vsrc); | + PMAP_UNLOCK(kernel_pmap); | } | } else { | PMAP_STATS_INC(pmap_ncopy_page_oc); | + PMAP_LOCK(kernel_pmap); | vdst =3D pmap_temp_map_1 + (mdst->md.color * PAGE_SIZE); | tp =3D tsb_kvtotte(vdst); | tp->tte_data =3D | @@ -1660,6 +1669,7 @@ pmap_copy_page(vm_page_t msrc, vm_page_t | cpu_block_copy((void *)vsrc, (void *)vdst, PAGE_SIZE); | tlb_page_demap(kernel_pmap, vdst); | tlb_page_demap(kernel_pmap, vsrc); | + PMAP_UNLOCK(kernel_pmap); | } | } | =20 ----- End forwarded message ----- --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCJEGbWry0BWjoQKURAt70AJ9/B74CHtZKmcsfjH643vRu94hXcgCeMMc4 qyh/ov/hWB8p2Vg489NyQJM= =fvTK -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 12:01:47 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DB8C16A4CE; Tue, 1 Mar 2005 12:01:47 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE2E343D1F; Tue, 1 Mar 2005 12:01:46 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 5A83D46B0C; Tue, 1 Mar 2005 07:01:46 -0500 (EST) Date: Tue, 1 Mar 2005 11:59:49 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Doug White In-Reply-To: <20050228214850.X62607@carver.gumbysoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: sparc64@FreeBSD.org cc: net@FreeBSD.org cc: Kris Kennaway Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 12:01:47 -0000 On Mon, 28 Feb 2005, Doug White wrote: > Forgive me for being naieve, but is there a reason you don't do an > atomic subtraction on the refcount? I can see why it repeats -- if two > things are warring over the refcount one or the other keep trying until > one wins -- but the subtraction would seem more intuitive. I'm not all that familiar with this code, but my guess is that he uses the cmpset so that he guarantees the value of 'cnt' is fresh with respect to the decrement -- i.e., only one caller to mb_free_ext() will end up with a 'cnt' of 1 and perform the GC. If you re-read it, there may be a race. Robert N M Watson From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 15:16:45 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E61A16A4CE; Tue, 1 Mar 2005 15:16:45 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBDE343D2F; Tue, 1 Mar 2005 15:16:44 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j21FGifO080900; Tue, 1 Mar 2005 10:16:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j21FGita023255; Tue, 1 Mar 2005 10:16:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 00E7C7306E; Tue, 1 Mar 2005 10:16:43 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050301151643.00E7C7306E@freebsd-current.sentex.ca> Date: Tue, 1 Mar 2005 10:16:43 -0500 (EST) X-Virus-Scanned: ClamAV 0.82/738/Tue Mar 1 07:08:00 2005 on smarthost2.sentex.ca X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner3 X-Virus-Status: Clean Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 15:16:45 -0000 TB --- 2005-03-01 13:58:38 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-03-01 13:58:38 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-03-01 13:58:38 - checking out the source tree TB --- 2005-03-01 13:58:38 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-03-01 13:58:38 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-03-01 14:04:29 - building world (CFLAGS=-O2 -pipe) TB --- 2005-03-01 14:04:29 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-03-01 14:04:29 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-03-01 15:11:01 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-03-01 15:11:01 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-03-01 15:11:01 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Mar 1 15:11:01 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/home/tinderbox/CURRENT/sparc64/sparc64/obj/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make sh /tinderbox/CURRENT/sparc64/sparc64/src/sys/conf/newvers.sh GENERIC cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror vers.c linking kernel.debug kern_mib.o(.text+0x44): In function `sysctl_hw_realmem': /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_mib.c:173: undefined reference to `realmem' kern_mib.o(.text+0x4c):/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_mib.c:173: undefined reference to `realmem' *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-03-01 15:16:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-03-01 15:16:43 - ERROR: failed to build generic kernel TB --- 2005-03-01 15:16:43 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 20:03:20 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B2A916A4CE for ; Tue, 1 Mar 2005 20:03:20 +0000 (GMT) Received: from servww6.ww.uni-erlangen.de (servww6.ww.uni-erlangen.de [131.188.238.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87CE743D41 for ; Tue, 1 Mar 2005 20:03:18 +0000 (GMT) (envelope-from ardelean@ww.uni-erlangen.de) Received: from localhost (ardelean@localhost)ESMTP id j21K3ES10263 for ; Tue, 1 Mar 2005 21:03:14 +0100 Date: Tue, 1 Mar 2005 21:03:14 +0100 (CET) From: Gheorghe Ardelean To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Problems with 5.3R on Ultra1 with Qlogic SBUS Controller X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 20:03:20 -0000 Hi, I am trying to boot my plain Ultra1 (not 1E) which is not supported "as is". So I put an Qlogic SBUS Diff SCSI controller (ISP1000) in it and a HDD on which I have preinstalled FreeBSD 5.3R ( on my Ultra 5 + Adaptec 2944). As soon as it detects the zs0 the boot process hangs. Has anybody any idea about what could cause this hang? Here is the boot message: ok boot /sbus@1f,0/QLGC,isp@0,10000/sd@0,0 Boot device: /sbus@1f,0/QLGC,isp@0,10000/sd@0,0 File and args: >> FreeBSD/sparc64 boot block Boot path: /sbus@1f,0/QLGC,isp@0,10000/sd@0,0:a Boot loader: /boot/loader Console: Open Firmware console FreeBSD/sparc64 bootstrap loader, Revision 1.0 (root@bobbi.cse.buffalo.edu, Fri Nov 5 02:16:10 UTC 2004) bootpath="/sbus@1f,0/QLGC,isp@0,10000/sd@0,0:a" WARNING: attempt to free non dma-alloc'd range: -2000 2000 Loading /boot/defaults/loader.conf WARNING: attempt to free non dma-alloc'd range: -2000 2000 WARNING: attempt to free non dma-alloc'd range: -2000 2000 WARNING: attempt to free non dma-alloc'd range: -2000 2000 WARNING: attempt to free non dma-alloc'd range: -2000 2000 /boot/kernel/kernel data=0x3b5f08+0x49e28 syms=[0x8+0x4ef60+0x8+0x43746] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 8 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK boot nothing to autoload yet. jumping to kernel entry at 0xc0040000. stray vector interrupt 2033 Copyright (c) 1992-2004 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 5.3-RELEASE #0: Fri Nov 5 19:30:40 UTC 2004 root@bobbi.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "tick" frequency 142988906 Hz quality 1000 real memory = 335544320 (320 MB) avail memory = 304701440 (290 MB) cpu0: Sun Microsystems UltraSparc-I Processor (142.99 MHz CPU) nexus0: sbus0: clock 25.000 MHz sbus dvma: DVMA map: 0xfc000000 to 0xffffffff sbus0: [FAST] sbus0: [FAST] initializing counter-timer Timecounter "counter-timer" frequency 1000000 Hz quality 100 sbus0: on nexus0 sbus0: , type (unknown) (no driver attached) sbus0: , type (unknown) (no driver attached) sbus0: , type (unknown) (no driver attached) sbus0: , type block (no driver attached) eeprom0: mem 0x1200000-0x1201fff on sbus0 eeprom0: model mk48t59 eeprom0: hostid 8085fe27 zs0: mem 0x1100000-0x1100003 irq 2024 on sbus0 zs0: [FAST] zstty0: on zs0 This is the hardware I have inside the box: ok cd /sbus ok ls f0083e74 cgsix@2,0 f007c868 SUNW,fas@1,8800000 f0074390 SUNW,hme@1,8c00000 f006b9e4 QLGC,isp@0,10000 f00694b0 SUNW,bpp@e,c800000 f006668c ledma@e,8400010 f006232c espdma@e,8400000 f005ce34 SUNW,pll@f,1304000 f005cd80 sc@f,1300000 f005b324 zs@f,1000000 f0059e84 zs@f,1100000 f0059dd0 eeprom@f,1200000 f0059c9c SUNW,fdtwo@f,1400000 f0059bd4 flashprom@f,0 f0059b44 auxio@f,1900000 f0059a38 SUNW,CS4231@d,c000000 The machine is: Sun Ultra 1 SBus (UltraSPARC 143MHz), No Keyboard OpenBoot 3.25, 320 MB memory installed, Serial #xxxxxx. Ethernet address 8:0:20:xx:xx:xx, Host ID: yyyyyyy. I have also an Sun Swift (FAS+HME) combo inside the box but the HME is not able to sense the link to my switch (so I cannot netboot it). In NetBSD the hme works if I specify mediaopt 100BaseTX to ifconfig. Any ideas? What else could I try. Regards, Johny. From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 20:47:36 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FEB016A4D4 for ; Tue, 1 Mar 2005 20:47:36 +0000 (GMT) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9656A43D3F for ; Tue, 1 Mar 2005 20:47:35 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 11895 invoked from network); 1 Mar 2005 20:47:35 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 1 Mar 2005 20:47:34 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j21KlPbX074756; Tue, 1 Mar 2005 15:47:29 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-sparc64@FreeBSD.org Date: Tue, 1 Mar 2005 13:40:18 -0500 User-Agent: KMail/1.6.2 References: <20050301000436.GA33346@xor.obsecurity.org> In-Reply-To: <20050301000436.GA33346@xor.obsecurity.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503011340.18162.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: net@FreeBSD.org cc: rwatson@FreeBSD.org cc: bmilekic@FreeBSD.org cc: sparc64@FreeBSD.org cc: Kris Kennaway Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 20:47:36 -0000 On Monday 28 February 2005 07:04 pm, Kris Kennaway wrote: > I'm seeing an easily-provoked livelock on quad-CPU sparc64 machines > running RELENG_5. It's hard to get a good trace because the processes > running on other CPUs cannot be traced from DDB, but I've been lucky a > few times: > > db> show alllocks > Process 15 (swi1: net) thread 0xfffff8001fb07480 (100008) > exclusive sleep mutex so_snd r = 0 (0xfffff800178432a8) locked @ > netinet/tcp_input.c:2189 exclusive sleep mutex inp (tcpinp) r = 0 > (0xfffff800155c3b08) locked @ netinet/tcp_input.c:744 exclusive sleep mutex > tcp r = 0 (0xc0bdf788) locked @ netinet/tcp_input.c:617 db> wh 15 > Tracing pid 15 tid 100008 td 0xfffff8001fb07480 > sab_intr() at sab_intr+0x40 > psycho_intr_stub() at psycho_intr_stub+0x8 > intr_fast() at intr_fast+0x88 > -- interrupt level=0xd pil=0 %o7=0xc01a0040 -- > mb_free_ext() at mb_free_ext+0x28 > sbdrop_locked() at sbdrop_locked+0x19c > tcp_input() at tcp_input+0x2aa0 > ip_input() at ip_input+0x964 > netisr_processqueue() at netisr_processqueue+0x7c > swi_net() at swi_net+0x120 > ithread_loop() at ithread_loop+0x24c > fork_exit() at fork_exit+0xd4 > fork_trampoline() at fork_trampoline+0x8 > db> > > That code is here in mb_free_ext(): > > /* > * This is tricky. We need to make sure to decrement the > * refcount in a safe way but to also clean up if we're the > * last reference. This method seems to do it without race. > */ > while (dofree == 0) { > cnt = *(m->m_ext.ref_cnt); > if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { > if (cnt == 1) > dofree = 1; > break; > } > } Well, this is obtuse at least. A simpler version would be: do { cnt = *m->m_ext.ref_cnt; } while (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1) == 0); dofree = (cnt == 1); -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 20:47:36 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7375216A4D7 for ; Tue, 1 Mar 2005 20:47:36 +0000 (GMT) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 951E143D31 for ; Tue, 1 Mar 2005 20:47:35 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 11895 invoked from network); 1 Mar 2005 20:47:35 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 1 Mar 2005 20:47:34 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j21KlPbX074756; Tue, 1 Mar 2005 15:47:29 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-sparc64@FreeBSD.org Date: Tue, 1 Mar 2005 13:40:18 -0500 User-Agent: KMail/1.6.2 References: <20050301000436.GA33346@xor.obsecurity.org> In-Reply-To: <20050301000436.GA33346@xor.obsecurity.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503011340.18162.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: net@FreeBSD.org cc: rwatson@FreeBSD.org cc: bmilekic@FreeBSD.org cc: sparc64@FreeBSD.org cc: Kris Kennaway Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 20:47:36 -0000 On Monday 28 February 2005 07:04 pm, Kris Kennaway wrote: > I'm seeing an easily-provoked livelock on quad-CPU sparc64 machines > running RELENG_5. It's hard to get a good trace because the processes > running on other CPUs cannot be traced from DDB, but I've been lucky a > few times: > > db> show alllocks > Process 15 (swi1: net) thread 0xfffff8001fb07480 (100008) > exclusive sleep mutex so_snd r = 0 (0xfffff800178432a8) locked @ > netinet/tcp_input.c:2189 exclusive sleep mutex inp (tcpinp) r = 0 > (0xfffff800155c3b08) locked @ netinet/tcp_input.c:744 exclusive sleep mutex > tcp r = 0 (0xc0bdf788) locked @ netinet/tcp_input.c:617 db> wh 15 > Tracing pid 15 tid 100008 td 0xfffff8001fb07480 > sab_intr() at sab_intr+0x40 > psycho_intr_stub() at psycho_intr_stub+0x8 > intr_fast() at intr_fast+0x88 > -- interrupt level=0xd pil=0 %o7=0xc01a0040 -- > mb_free_ext() at mb_free_ext+0x28 > sbdrop_locked() at sbdrop_locked+0x19c > tcp_input() at tcp_input+0x2aa0 > ip_input() at ip_input+0x964 > netisr_processqueue() at netisr_processqueue+0x7c > swi_net() at swi_net+0x120 > ithread_loop() at ithread_loop+0x24c > fork_exit() at fork_exit+0xd4 > fork_trampoline() at fork_trampoline+0x8 > db> > > That code is here in mb_free_ext(): > > /* > * This is tricky. We need to make sure to decrement the > * refcount in a safe way but to also clean up if we're the > * last reference. This method seems to do it without race. > */ > while (dofree == 0) { > cnt = *(m->m_ext.ref_cnt); > if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { > if (cnt == 1) > dofree = 1; > break; > } > } Well, this is obtuse at least. A simpler version would be: do { cnt = *m->m_ext.ref_cnt; } while (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1) == 0); dofree = (cnt == 1); -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 23:04:29 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1F0416A4D0 for ; Tue, 1 Mar 2005 23:04:29 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7742943D48 for ; Tue, 1 Mar 2005 23:04:28 +0000 (GMT) (envelope-from bosko.milekic@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2439453wra for ; Tue, 01 Mar 2005 15:04:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=dZeLE31ZQy9p686MrwZ5ROAAUahNPUv/f4QmtSJXUWHOIIaIC1gMoAaWpzGqa484CPCW3SijDH7yQ+Pl4YtPHQDcNa/UpBxAkQS1dcyKEYCtCu78IyBEC1U+XE7qorrte//dal8Zc9K2ek9zNmLncT/Kw9klvao4r351Hc/NB4Y= Received: by 10.54.18.62 with SMTP id 62mr85204wrr; Tue, 01 Mar 2005 15:04:27 -0800 (PST) Received: by 10.54.24.41 with HTTP; Tue, 1 Mar 2005 15:04:27 -0800 (PST) Message-ID: Date: Tue, 1 Mar 2005 18:04:27 -0500 From: Bosko Milekic To: John Baldwin In-Reply-To: <200503011340.18162.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050301000436.GA33346@xor.obsecurity.org> <200503011340.18162.jhb@FreeBSD.org> cc: Kris Kennaway cc: net@freebsd.org cc: rwatson@freebsd.org cc: bmilekic@freebsd.org cc: sparc64@freebsd.org cc: freebsd-sparc64@freebsd.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bosko Milekic List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 23:04:30 -0000 On Tue, 1 Mar 2005 13:40:18 -0500, John Baldwin wrote: > On Monday 28 February 2005 07:04 pm, Kris Kennaway wrote: > > I'm seeing an easily-provoked livelock on quad-CPU sparc64 machines > > running RELENG_5. It's hard to get a good trace because the processes > > running on other CPUs cannot be traced from DDB, but I've been lucky a > > few times: > > > > db> show alllocks > > Process 15 (swi1: net) thread 0xfffff8001fb07480 (100008) > > exclusive sleep mutex so_snd r = 0 (0xfffff800178432a8) locked @ > > netinet/tcp_input.c:2189 exclusive sleep mutex inp (tcpinp) r = 0 > > (0xfffff800155c3b08) locked @ netinet/tcp_input.c:744 exclusive sleep mutex > > tcp r = 0 (0xc0bdf788) locked @ netinet/tcp_input.c:617 db> wh 15 > > Tracing pid 15 tid 100008 td 0xfffff8001fb07480 > > sab_intr() at sab_intr+0x40 > > psycho_intr_stub() at psycho_intr_stub+0x8 > > intr_fast() at intr_fast+0x88 > > -- interrupt level=0xd pil=0 %o7=0xc01a0040 -- > > mb_free_ext() at mb_free_ext+0x28 > > sbdrop_locked() at sbdrop_locked+0x19c > > tcp_input() at tcp_input+0x2aa0 > > ip_input() at ip_input+0x964 > > netisr_processqueue() at netisr_processqueue+0x7c > > swi_net() at swi_net+0x120 > > ithread_loop() at ithread_loop+0x24c > > fork_exit() at fork_exit+0xd4 > > fork_trampoline() at fork_trampoline+0x8 > > db> > > > > That code is here in mb_free_ext(): > > > > /* > > * This is tricky. We need to make sure to decrement the > > * refcount in a safe way but to also clean up if we're the > > * last reference. This method seems to do it without race. > > */ > > while (dofree == 0) { > > cnt = *(m->m_ext.ref_cnt); > > if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { > > if (cnt == 1) > > dofree = 1; > > break; > > } > > } > > Well, this is obtuse at least. A simpler version would be: > > do { > cnt = *m->m_ext.ref_cnt; > } while (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1) == 0); > dofree = (cnt == 1); > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org Your suggestion will always enter the loop and do the atomic regardless of what dofree is set to above that code (not shown in Kris' paste): [...] /* Account for lazy ref count assign. */ if (m->m_ext.ref_cnt == NULL) dofree = 1; else dofree = 0; /* * This is tricky. We need to make sure to decrement the * refcount in a safe way but to also clean up if we're the * last reference. This method seems to do it without race. */ [...] The segment could still be reworked, but anyway: This does not appear to explain the livelock. What's m->m_ext.ref_cnt point to? And what is the value at the location pointed to by m->m_ext.ref_cnt? Regardless, though, the livelock itself, assuming it is due to a long time being spent spinning in the above loop, should not be caused by underruns or overruns of the reference count (those may only cause leaking of the cluster). Furthermore, the above code has been around in that form for some time now and in fact the loop was probably entered *more* often in the past (before the 'dofree' variable was introduced there). Since when are you able to cause the livelock to happen, and are you sure it is the mb_free_ext() that is looping indefinitely? I do not know sparc64 well, but what are the semantics of atomic_cmpset_int()? I see that it is defined to use the 'casa' instruction; does atomic_cmpset_int() behave the same way as it does on i386? -Bosko -- Bosko Milekic - If I were a number, I'd be irrational. Contact Info: http://bmilekic.unixdaemons.com/contact.txt From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 23:04:30 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1900616A4CF for ; Tue, 1 Mar 2005 23:04:30 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0BAE43D5E for ; Tue, 1 Mar 2005 23:04:28 +0000 (GMT) (envelope-from bosko.milekic@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2439457wra for ; Tue, 01 Mar 2005 15:04:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=dZeLE31ZQy9p686MrwZ5ROAAUahNPUv/f4QmtSJXUWHOIIaIC1gMoAaWpzGqa484CPCW3SijDH7yQ+Pl4YtPHQDcNa/UpBxAkQS1dcyKEYCtCu78IyBEC1U+XE7qorrte//dal8Zc9K2ek9zNmLncT/Kw9klvao4r351Hc/NB4Y= Received: by 10.54.18.62 with SMTP id 62mr85204wrr; Tue, 01 Mar 2005 15:04:27 -0800 (PST) Received: by 10.54.24.41 with HTTP; Tue, 1 Mar 2005 15:04:27 -0800 (PST) Message-ID: Date: Tue, 1 Mar 2005 18:04:27 -0500 From: Bosko Milekic To: John Baldwin In-Reply-To: <200503011340.18162.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050301000436.GA33346@xor.obsecurity.org> <200503011340.18162.jhb@FreeBSD.org> cc: Kris Kennaway cc: net@freebsd.org cc: rwatson@freebsd.org cc: bmilekic@freebsd.org cc: sparc64@freebsd.org cc: freebsd-sparc64@freebsd.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bosko Milekic List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 23:04:30 -0000 On Tue, 1 Mar 2005 13:40:18 -0500, John Baldwin wrote: > On Monday 28 February 2005 07:04 pm, Kris Kennaway wrote: > > I'm seeing an easily-provoked livelock on quad-CPU sparc64 machines > > running RELENG_5. It's hard to get a good trace because the processes > > running on other CPUs cannot be traced from DDB, but I've been lucky a > > few times: > > > > db> show alllocks > > Process 15 (swi1: net) thread 0xfffff8001fb07480 (100008) > > exclusive sleep mutex so_snd r = 0 (0xfffff800178432a8) locked @ > > netinet/tcp_input.c:2189 exclusive sleep mutex inp (tcpinp) r = 0 > > (0xfffff800155c3b08) locked @ netinet/tcp_input.c:744 exclusive sleep mutex > > tcp r = 0 (0xc0bdf788) locked @ netinet/tcp_input.c:617 db> wh 15 > > Tracing pid 15 tid 100008 td 0xfffff8001fb07480 > > sab_intr() at sab_intr+0x40 > > psycho_intr_stub() at psycho_intr_stub+0x8 > > intr_fast() at intr_fast+0x88 > > -- interrupt level=0xd pil=0 %o7=0xc01a0040 -- > > mb_free_ext() at mb_free_ext+0x28 > > sbdrop_locked() at sbdrop_locked+0x19c > > tcp_input() at tcp_input+0x2aa0 > > ip_input() at ip_input+0x964 > > netisr_processqueue() at netisr_processqueue+0x7c > > swi_net() at swi_net+0x120 > > ithread_loop() at ithread_loop+0x24c > > fork_exit() at fork_exit+0xd4 > > fork_trampoline() at fork_trampoline+0x8 > > db> > > > > That code is here in mb_free_ext(): > > > > /* > > * This is tricky. We need to make sure to decrement the > > * refcount in a safe way but to also clean up if we're the > > * last reference. This method seems to do it without race. > > */ > > while (dofree == 0) { > > cnt = *(m->m_ext.ref_cnt); > > if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { > > if (cnt == 1) > > dofree = 1; > > break; > > } > > } > > Well, this is obtuse at least. A simpler version would be: > > do { > cnt = *m->m_ext.ref_cnt; > } while (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1) == 0); > dofree = (cnt == 1); > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org Your suggestion will always enter the loop and do the atomic regardless of what dofree is set to above that code (not shown in Kris' paste): [...] /* Account for lazy ref count assign. */ if (m->m_ext.ref_cnt == NULL) dofree = 1; else dofree = 0; /* * This is tricky. We need to make sure to decrement the * refcount in a safe way but to also clean up if we're the * last reference. This method seems to do it without race. */ [...] The segment could still be reworked, but anyway: This does not appear to explain the livelock. What's m->m_ext.ref_cnt point to? And what is the value at the location pointed to by m->m_ext.ref_cnt? Regardless, though, the livelock itself, assuming it is due to a long time being spent spinning in the above loop, should not be caused by underruns or overruns of the reference count (those may only cause leaking of the cluster). Furthermore, the above code has been around in that form for some time now and in fact the loop was probably entered *more* often in the past (before the 'dofree' variable was introduced there). Since when are you able to cause the livelock to happen, and are you sure it is the mb_free_ext() that is looping indefinitely? I do not know sparc64 well, but what are the semantics of atomic_cmpset_int()? I see that it is defined to use the 'casa' instruction; does atomic_cmpset_int() behave the same way as it does on i386? -Bosko -- Bosko Milekic - If I were a number, I'd be irrational. Contact Info: http://bmilekic.unixdaemons.com/contact.txt From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 23:10:58 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E6A316A4CE for ; Tue, 1 Mar 2005 23:10:58 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF6E543D54 for ; Tue, 1 Mar 2005 23:10:56 +0000 (GMT) (envelope-from bosko.milekic@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2440821wra for ; Tue, 01 Mar 2005 15:10:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=eyLPp9w2OH8MgKXVg+J/qseCC6uWkVFZEuVf5CQyeV/k4MVLb10vpE1DxumhyvcEga25O8Ku3rlA1YKIiyRdnnkKn2uNgO9VrXxLVhogvzZWVtWtBg6TS19zNf1QNspst4Eare/68TyNBLuWAhs59qulbataIEYNZWgtc2E3tf8= Received: by 10.54.10.7 with SMTP id 7mr87677wrj; Tue, 01 Mar 2005 15:10:55 -0800 (PST) Received: by 10.54.24.41 with HTTP; Tue, 1 Mar 2005 15:10:55 -0800 (PST) Message-ID: Date: Tue, 1 Mar 2005 18:10:55 -0500 From: Bosko Milekic To: John Baldwin In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050301000436.GA33346@xor.obsecurity.org> <200503011340.18162.jhb@FreeBSD.org> cc: Kris Kennaway cc: net@freebsd.org cc: rwatson@freebsd.org cc: bmilekic@freebsd.org cc: sparc64@freebsd.org cc: freebsd-sparc64@freebsd.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bosko Milekic List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 23:10:58 -0000 P.S.: Not sure if this is related: http://www.mail-archive.com/bk-commits-24@vger.kernel.org/msg00136.html On Tue, 1 Mar 2005 18:04:27 -0500, Bosko Milekic wrote: > On Tue, 1 Mar 2005 13:40:18 -0500, John Baldwin wrote: > > On Monday 28 February 2005 07:04 pm, Kris Kennaway wrote: > > > I'm seeing an easily-provoked livelock on quad-CPU sparc64 machines > > > running RELENG_5. It's hard to get a good trace because the processes > > > running on other CPUs cannot be traced from DDB, but I've been lucky a > > > few times: > > > > > > db> show alllocks > > > Process 15 (swi1: net) thread 0xfffff8001fb07480 (100008) > > > exclusive sleep mutex so_snd r = 0 (0xfffff800178432a8) locked @ > > > netinet/tcp_input.c:2189 exclusive sleep mutex inp (tcpinp) r = 0 > > > (0xfffff800155c3b08) locked @ netinet/tcp_input.c:744 exclusive sleep mutex > > > tcp r = 0 (0xc0bdf788) locked @ netinet/tcp_input.c:617 db> wh 15 > > > Tracing pid 15 tid 100008 td 0xfffff8001fb07480 > > > sab_intr() at sab_intr+0x40 > > > psycho_intr_stub() at psycho_intr_stub+0x8 > > > intr_fast() at intr_fast+0x88 > > > -- interrupt level=0xd pil=0 %o7=0xc01a0040 -- > > > mb_free_ext() at mb_free_ext+0x28 > > > sbdrop_locked() at sbdrop_locked+0x19c > > > tcp_input() at tcp_input+0x2aa0 > > > ip_input() at ip_input+0x964 > > > netisr_processqueue() at netisr_processqueue+0x7c > > > swi_net() at swi_net+0x120 > > > ithread_loop() at ithread_loop+0x24c > > > fork_exit() at fork_exit+0xd4 > > > fork_trampoline() at fork_trampoline+0x8 > > > db> > > > > > > That code is here in mb_free_ext(): > > > > > > /* > > > * This is tricky. We need to make sure to decrement the > > > * refcount in a safe way but to also clean up if we're the > > > * last reference. This method seems to do it without race. > > > */ > > > while (dofree == 0) { > > > cnt = *(m->m_ext.ref_cnt); > > > if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { > > > if (cnt == 1) > > > dofree = 1; > > > break; > > > } > > > } > > > > Well, this is obtuse at least. A simpler version would be: > > > > do { > > cnt = *m->m_ext.ref_cnt; > > } while (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1) == 0); > > dofree = (cnt == 1); > > > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > Your suggestion will always enter the loop and do the atomic > regardless of what dofree is set to above that code (not shown in > Kris' paste): > > [...] > /* Account for lazy ref count assign. */ > if (m->m_ext.ref_cnt == NULL) > dofree = 1; > else > dofree = 0; > > /* > * This is tricky. We need to make sure to decrement the > * refcount in a safe way but to also clean up if we're the > * last reference. This method seems to do it without race. > */ > [...] > > The segment could still be reworked, but anyway: > > This does not appear to explain the livelock. What's m->m_ext.ref_cnt > point to? And what is the value at the location pointed to by > m->m_ext.ref_cnt? Regardless, though, the livelock itself, assuming it > is due to a long time being spent spinning in the above loop, should > not be caused by underruns or overruns of the reference count (those > may only cause leaking of the cluster). > > Furthermore, the above code has been around in that form for some time > now and in fact the loop was probably entered *more* often in the past > (before the 'dofree' variable was introduced there). Since when are > you able to cause the livelock to happen, and are you sure it is the > mb_free_ext() that is looping indefinitely? > > I do not know sparc64 well, but what are the semantics of > atomic_cmpset_int()? I see that it is defined to use the 'casa' > instruction; does atomic_cmpset_int() behave the same way as it does > on i386? > > -Bosko > > -- > Bosko Milekic - If I were a number, I'd be irrational. > Contact Info: http://bmilekic.unixdaemons.com/contact.txt > -- Bosko Milekic - If I were a number, I'd be irrational. Contact Info: http://bmilekic.unixdaemons.com/contact.txt From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 23:10:58 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC7E016A4CE for ; Tue, 1 Mar 2005 23:10:58 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F91643D5C for ; Tue, 1 Mar 2005 23:10:56 +0000 (GMT) (envelope-from bosko.milekic@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2440817wra for ; Tue, 01 Mar 2005 15:10:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=eyLPp9w2OH8MgKXVg+J/qseCC6uWkVFZEuVf5CQyeV/k4MVLb10vpE1DxumhyvcEga25O8Ku3rlA1YKIiyRdnnkKn2uNgO9VrXxLVhogvzZWVtWtBg6TS19zNf1QNspst4Eare/68TyNBLuWAhs59qulbataIEYNZWgtc2E3tf8= Received: by 10.54.10.7 with SMTP id 7mr87677wrj; Tue, 01 Mar 2005 15:10:55 -0800 (PST) Received: by 10.54.24.41 with HTTP; Tue, 1 Mar 2005 15:10:55 -0800 (PST) Message-ID: Date: Tue, 1 Mar 2005 18:10:55 -0500 From: Bosko Milekic To: John Baldwin In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050301000436.GA33346@xor.obsecurity.org> <200503011340.18162.jhb@FreeBSD.org> cc: Kris Kennaway cc: net@freebsd.org cc: rwatson@freebsd.org cc: bmilekic@freebsd.org cc: sparc64@freebsd.org cc: freebsd-sparc64@freebsd.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bosko Milekic List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 23:10:58 -0000 P.S.: Not sure if this is related: http://www.mail-archive.com/bk-commits-24@vger.kernel.org/msg00136.html On Tue, 1 Mar 2005 18:04:27 -0500, Bosko Milekic wrote: > On Tue, 1 Mar 2005 13:40:18 -0500, John Baldwin wrote: > > On Monday 28 February 2005 07:04 pm, Kris Kennaway wrote: > > > I'm seeing an easily-provoked livelock on quad-CPU sparc64 machines > > > running RELENG_5. It's hard to get a good trace because the processes > > > running on other CPUs cannot be traced from DDB, but I've been lucky a > > > few times: > > > > > > db> show alllocks > > > Process 15 (swi1: net) thread 0xfffff8001fb07480 (100008) > > > exclusive sleep mutex so_snd r = 0 (0xfffff800178432a8) locked @ > > > netinet/tcp_input.c:2189 exclusive sleep mutex inp (tcpinp) r = 0 > > > (0xfffff800155c3b08) locked @ netinet/tcp_input.c:744 exclusive sleep mutex > > > tcp r = 0 (0xc0bdf788) locked @ netinet/tcp_input.c:617 db> wh 15 > > > Tracing pid 15 tid 100008 td 0xfffff8001fb07480 > > > sab_intr() at sab_intr+0x40 > > > psycho_intr_stub() at psycho_intr_stub+0x8 > > > intr_fast() at intr_fast+0x88 > > > -- interrupt level=0xd pil=0 %o7=0xc01a0040 -- > > > mb_free_ext() at mb_free_ext+0x28 > > > sbdrop_locked() at sbdrop_locked+0x19c > > > tcp_input() at tcp_input+0x2aa0 > > > ip_input() at ip_input+0x964 > > > netisr_processqueue() at netisr_processqueue+0x7c > > > swi_net() at swi_net+0x120 > > > ithread_loop() at ithread_loop+0x24c > > > fork_exit() at fork_exit+0xd4 > > > fork_trampoline() at fork_trampoline+0x8 > > > db> > > > > > > That code is here in mb_free_ext(): > > > > > > /* > > > * This is tricky. We need to make sure to decrement the > > > * refcount in a safe way but to also clean up if we're the > > > * last reference. This method seems to do it without race. > > > */ > > > while (dofree == 0) { > > > cnt = *(m->m_ext.ref_cnt); > > > if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { > > > if (cnt == 1) > > > dofree = 1; > > > break; > > > } > > > } > > > > Well, this is obtuse at least. A simpler version would be: > > > > do { > > cnt = *m->m_ext.ref_cnt; > > } while (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1) == 0); > > dofree = (cnt == 1); > > > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > Your suggestion will always enter the loop and do the atomic > regardless of what dofree is set to above that code (not shown in > Kris' paste): > > [...] > /* Account for lazy ref count assign. */ > if (m->m_ext.ref_cnt == NULL) > dofree = 1; > else > dofree = 0; > > /* > * This is tricky. We need to make sure to decrement the > * refcount in a safe way but to also clean up if we're the > * last reference. This method seems to do it without race. > */ > [...] > > The segment could still be reworked, but anyway: > > This does not appear to explain the livelock. What's m->m_ext.ref_cnt > point to? And what is the value at the location pointed to by > m->m_ext.ref_cnt? Regardless, though, the livelock itself, assuming it > is due to a long time being spent spinning in the above loop, should > not be caused by underruns or overruns of the reference count (those > may only cause leaking of the cluster). > > Furthermore, the above code has been around in that form for some time > now and in fact the loop was probably entered *more* often in the past > (before the 'dofree' variable was introduced there). Since when are > you able to cause the livelock to happen, and are you sure it is the > mb_free_ext() that is looping indefinitely? > > I do not know sparc64 well, but what are the semantics of > atomic_cmpset_int()? I see that it is defined to use the 'casa' > instruction; does atomic_cmpset_int() behave the same way as it does > on i386? > > -Bosko > > -- > Bosko Milekic - If I were a number, I'd be irrational. > Contact Info: http://bmilekic.unixdaemons.com/contact.txt > -- Bosko Milekic - If I were a number, I'd be irrational. Contact Info: http://bmilekic.unixdaemons.com/contact.txt From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 23:14:40 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D209A16A4CE; Tue, 1 Mar 2005 23:14:40 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 927B843D53; Tue, 1 Mar 2005 23:14:40 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1C2CC5126E; Tue, 1 Mar 2005 15:14:39 -0800 (PST) Date: Tue, 1 Mar 2005 15:14:38 -0800 From: Kris Kennaway To: Bosko Milekic Message-ID: <20050301231438.GA25573@xor.obsecurity.org> References: <20050301000436.GA33346@xor.obsecurity.org> <200503011340.18162.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: Kris Kennaway cc: net@freebsd.org cc: rwatson@freebsd.org cc: freebsd-sparc64@freebsd.org cc: sparc64@freebsd.org cc: bmilekic@freebsd.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 23:14:41 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 01, 2005 at 06:04:27PM -0500, Bosko Milekic wrote: > This does not appear to explain the livelock. alc and dwhite tracked it down to a missing volatile causing gcc to mis-optimize the loop: - cnt = *(m->m_ext.ref_cnt); + cnt = *(volatile u_int *)(m->m_ext.ref_cnt); I'm currently testing that. Kris --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD4DBQFCJPdeWry0BWjoQKURAhjEAJQIzH83/FFMg4OTWDMkev19ElbpAKD2mYru pC3bsDMZrisMSEJodagwXw== =WydC -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 23:14:40 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D209A16A4CE; Tue, 1 Mar 2005 23:14:40 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 927B843D53; Tue, 1 Mar 2005 23:14:40 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1C2CC5126E; Tue, 1 Mar 2005 15:14:39 -0800 (PST) Date: Tue, 1 Mar 2005 15:14:38 -0800 From: Kris Kennaway To: Bosko Milekic Message-ID: <20050301231438.GA25573@xor.obsecurity.org> References: <20050301000436.GA33346@xor.obsecurity.org> <200503011340.18162.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: Kris Kennaway cc: net@freebsd.org cc: rwatson@freebsd.org cc: freebsd-sparc64@freebsd.org cc: sparc64@freebsd.org cc: bmilekic@freebsd.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 23:14:41 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 01, 2005 at 06:04:27PM -0500, Bosko Milekic wrote: > This does not appear to explain the livelock. alc and dwhite tracked it down to a missing volatile causing gcc to mis-optimize the loop: - cnt = *(m->m_ext.ref_cnt); + cnt = *(volatile u_int *)(m->m_ext.ref_cnt); I'm currently testing that. Kris --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD4DBQFCJPdeWry0BWjoQKURAhjEAJQIzH83/FFMg4OTWDMkev19ElbpAKD2mYru pC3bsDMZrisMSEJodagwXw== =WydC -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 23:49:59 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B347D16A4CE; Tue, 1 Mar 2005 23:49:59 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 427F843D73; Tue, 1 Mar 2005 23:49:59 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])j21NnbFQ020169; Tue, 1 Mar 2005 18:49:37 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.3/8.12.1/Submit) id j21NnbO9020168; Tue, 1 Mar 2005 18:49:37 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Tue, 1 Mar 2005 18:49:37 -0500 From: Bosko Milekic To: Kris Kennaway Message-ID: <20050301234937.GA19502@technokratis.com> References: <20050301000436.GA33346@xor.obsecurity.org> <200503011340.18162.jhb@FreeBSD.org> <20050301231438.GA25573@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050301231438.GA25573@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: net@freebsd.org cc: rwatson@freebsd.org cc: freebsd-sparc64@freebsd.org cc: sparc64@freebsd.org cc: Bosko Milekic cc: bmilekic@freebsd.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 23:49:59 -0000 You know, the more and more we run into these problems specific to how reference counting is performed, I keep wondering whether some cleverly defined macros for dealing with common reference counting operations would be worthwhile. I'm not saying "introduce a refcount_t type and a full-blown abstraction," but some template-like stuff might be useful. It took a while just to get the refcount decrement on free path free of races on SMP, and that's only in the mbuf code. -Bosko On Tue, Mar 01, 2005 at 03:14:38PM -0800, Kris Kennaway wrote: > On Tue, Mar 01, 2005 at 06:04:27PM -0500, Bosko Milekic wrote: > > > This does not appear to explain the livelock. > > alc and dwhite tracked it down to a missing volatile causing gcc to > mis-optimize the loop: > > - cnt = *(m->m_ext.ref_cnt); > + cnt = *(volatile u_int *)(m->m_ext.ref_cnt); > > I'm currently testing that. > > Kris -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 23:50:04 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07A4E16A4E4 for ; Tue, 1 Mar 2005 23:50:04 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6525343D46 for ; Tue, 1 Mar 2005 23:50:03 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])j21NnbFQ020169; Tue, 1 Mar 2005 18:49:37 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.3/8.12.1/Submit) id j21NnbO9020168; Tue, 1 Mar 2005 18:49:37 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Tue, 1 Mar 2005 18:49:37 -0500 From: Bosko Milekic To: Kris Kennaway Message-ID: <20050301234937.GA19502@technokratis.com> References: <20050301000436.GA33346@xor.obsecurity.org> <200503011340.18162.jhb@FreeBSD.org> <20050301231438.GA25573@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050301231438.GA25573@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: net@freebsd.org cc: rwatson@freebsd.org cc: freebsd-sparc64@freebsd.org cc: sparc64@freebsd.org cc: Bosko Milekic cc: bmilekic@freebsd.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 23:50:04 -0000 You know, the more and more we run into these problems specific to how reference counting is performed, I keep wondering whether some cleverly defined macros for dealing with common reference counting operations would be worthwhile. I'm not saying "introduce a refcount_t type and a full-blown abstraction," but some template-like stuff might be useful. It took a while just to get the refcount decrement on free path free of races on SMP, and that's only in the mbuf code. -Bosko On Tue, Mar 01, 2005 at 03:14:38PM -0800, Kris Kennaway wrote: > On Tue, Mar 01, 2005 at 06:04:27PM -0500, Bosko Milekic wrote: > > > This does not appear to explain the livelock. > > alc and dwhite tracked it down to a missing volatile causing gcc to > mis-optimize the loop: > > - cnt = *(m->m_ext.ref_cnt); > + cnt = *(volatile u_int *)(m->m_ext.ref_cnt); > > I'm currently testing that. > > Kris -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Tue Mar 1 23:53:25 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 009A816A4CE; Tue, 1 Mar 2005 23:53:25 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0E6243D58; Tue, 1 Mar 2005 23:53:24 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])j21NrL4c020888; Tue, 1 Mar 2005 18:53:21 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.3/8.12.1/Submit) id j21NrLvm020887; Tue, 1 Mar 2005 18:53:21 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Tue, 1 Mar 2005 18:53:21 -0500 From: Bosko Milekic To: Doug White Message-ID: <20050301235321.GA20232@technokratis.com> References: <20050301000436.GA33346@xor.obsecurity.org> <20050228214850.X62607@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050228214850.X62607@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.1i cc: sparc64@FreeBSD.org cc: rwatson@FreeBSD.org cc: net@FreeBSD.org cc: Kris Kennaway Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 23:53:25 -0000 On Mon, Feb 28, 2005 at 10:00:25PM -0800, Doug White wrote: > Forgive me for being naieve, but is there a reason you don't do an atomic > subtraction on the refcount? I can see why it repeats -- if two things > are warring over the refcount one or the other keep trying until one wins > -- but the subtraction would seem more intuitive. The subtraction is atomic and is part of the cmpset. If you were to only do a subtraction, you risk racing on figuring out what the counter value before the subtraction was and making sure that it stays consistent after the subtraction. That is the purpose of the cmpset. The idea is that only the LAST thread to decrement the counter down to exactly 1 frees the cluster. If you look at the CVS history for that routine and its various incarnations (you might need to look at kern/subr_mbuf.c in the attic, since mb_free_ext() used to be there, iirc), you will see various points in time where we had this wrong. > -- > Doug White | FreeBSD: The Power to Serve > dwhite@gumbysoft.com | www.FreeBSD.org -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 2 05:29:34 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA2CE16A4CE for ; Wed, 2 Mar 2005 05:29:34 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CAC443D1F for ; Wed, 2 Mar 2005 05:29:34 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 55D5D72DD5; Tue, 1 Mar 2005 21:29:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5350772DD4 for ; Tue, 1 Mar 2005 21:29:34 -0800 (PST) Date: Tue, 1 Mar 2005 21:29:34 -0800 (PST) From: Doug White To: freebsd-sparc64@freebsd.org Message-ID: <20050301211852.C73061@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Deadlock fix candidate X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 05:29:34 -0000 Hey folks, After consultation with alc and rwatson and (limited) testing by kris, I've come up the following patch as a fix for the sparc64 deadlocks that afflict the package cluster sparc boxes. Its an exact copy of what alc suggested (thanks :) ) and by assembly inspection generates the desired code. Originally I was going to redo the loop to be more like ipi_wait() with the declared volatile pointer, but a cast does the job. :) I'm trying to determine if this also fixes similar deadlocks/hangs on i386 and amd64. I haven't seen any assembly level changes with the patch on amd64, but I'm trying again on a fresh source tree in case I have pollution from test patches that cvsup hasn't caught. I can only reproduce the hang on amd64, but adding any sort of debugging makes it go away. Comments appreciated. If things look good I'll look to commit this tomorrow evening unless events dictate otherwise. Thanks! (Patch also available at http://people.freebsd.org/~dwhite/uipc_mbuf.c.20050301.patch) Index: uipc_mbuf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_mbuf.c,v retrieving revision 1.143 diff -u -r1.143 uipc_mbuf.c --- uipc_mbuf.c 24 Feb 2005 00:40:33 -0000 1.143 +++ uipc_mbuf.c 1 Mar 2005 19:27:24 -0000 @@ -234,9 +234,12 @@ * This is tricky. We need to make sure to decrement the * refcount in a safe way but to also clean up if we're the * last reference. This method seems to do it without race. + * The volatile cast is required to emit the proper load + * instructions. Otherwise gcc will optimize the read outside + * of the while loop. */ while (dofree == 0) { - cnt = *(m->m_ext.ref_cnt); + cnt = *(volatile u_int *)(m->m_ext.ref_cnt); if (atomic_cmpset_int(m->m_ext.ref_cnt, cnt, cnt - 1)) { if (cnt == 1) dofree = 1; -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 2 06:14:05 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D6C116A4CE for ; Wed, 2 Mar 2005 06:14:05 +0000 (GMT) Received: from ns.kt-is.co.kr (ns.kt-is.co.kr [211.218.149.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6123243D2D for ; Wed, 2 Mar 2005 06:14:04 +0000 (GMT) (envelope-from yongari@kt-is.co.kr) Received: from michelle.kt-is.co.kr (ns2.kt-is.co.kr [220.76.118.193]) (authenticated bits=128) by ns.kt-is.co.kr (8.12.10/8.12.10) with ESMTP id j226BbAh074131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Mar 2005 15:11:37 +0900 (KST) Received: from michelle.kt-is.co.kr (localhost.kt-is.co.kr [127.0.0.1]) by michelle.kt-is.co.kr (8.13.1/8.13.1) with ESMTP id j226E2fP009374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Mar 2005 15:14:02 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.13.1/8.13.1/Submit) id j226DvBi009372; Wed, 2 Mar 2005 15:13:57 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Date: Wed, 2 Mar 2005 15:13:57 +0900 From: Pyun YongHyeon To: Doug White Message-ID: <20050302061357.GA9301@kt-is.co.kr> References: <20050301211852.C73061@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050301211852.C73061@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) cc: freebsd-sparc64@freebsd.org Subject: Re: Deadlock fix candidate X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: yongari@kt-is.co.kr List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 06:14:05 -0000 On Tue, Mar 01, 2005 at 09:29:34PM -0800, Doug White wrote: > Hey folks, > > After consultation with alc and rwatson and (limited) testing by kris, > I've come up the following patch as a fix for the sparc64 deadlocks that > afflict the package cluster sparc boxes. Its an exact copy of what alc > suggested (thanks :) ) and by assembly inspection generates the desired > code. Originally I was going to redo the loop to be more like ipi_wait() > with the declared volatile pointer, but a cast does the job. :) > > I'm trying to determine if this also fixes similar deadlocks/hangs on i386 > and amd64. I haven't seen any assembly level changes with the patch on > amd64, but I'm trying again on a fresh source tree in case I have > pollution from test patches that cvsup hasn't caught. I can only reproduce > the hang on amd64, but adding any sort of debugging makes it go away. > > Comments appreciated. If things look good I'll look to commit this > tomorrow evening unless events dictate otherwise. Thanks! > Confirmed on Ultra2. I always saw the lockups as soon as I started to download files from Ultra2 ftp server to fast i386 box(P4, 3GHz). But I never saw the lockup in UltraAXe (UP machine). With your patch it works like a charm. Now I can continue to check other issues on hme(4) now. :-) Thanks a lot. -- Regards, Pyun YongHyeon http://www.kr.freebsd.org/~yongari | yongari@freebsd.org From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 2 09:50:47 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B50216A4CE for ; Wed, 2 Mar 2005 09:50:47 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D9DB43D4C for ; Wed, 2 Mar 2005 09:50:46 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost [IPv6:::1]) by niobe.ijs.si (Postfix) with ESMTP id 5B0791DD42D; Wed, 2 Mar 2005 10:50:45 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 71005-01-58; Wed, 2 Mar 2005 10:50:36 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id A4E691DD41C; Wed, 2 Mar 2005 10:50:36 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id 158371C0073C; Wed, 2 Mar 2005 10:50:36 +0100 (CET) From: Dejan Lesjak To: Matthias Muthmann Date: Wed, 2 Mar 2005 10:50:35 +0100 User-Agent: KMail/1.7.2 References: <200502240244.03104.dejan.lesjak@ijs.si> <200502281848.36373.dejan.lesjak@ijs.si> <1109661404.19204.8.camel@localhost> In-Reply-To: <1109661404.19204.8.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503021050.35620.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-sparc64@freebsd.org Subject: Re: Problems with X.. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 09:50:47 -0000 On Tuesday 01 of March 2005 08:16, Matthias Muthmann wrote: > Well, I just played a little bit on my keyboard and all ef the key > (except the "cut"-key) produce events. An example: Pressing "h" and then > "n" gives: > > KeyPress event, serial 20, synthetic YES, window 0xe00001, > root 0x34, subw 0x40005f, time 497408, (7,4), root:(739,37), > state 0x0, keycode 89 (keysym 0x68, h), same_screen YES, > XLookupString gives 1 bytes: (68) "h" > > KeyPress event, serial 20, synthetic YES, window 0xe00001, > root 0x34, subw 0x40005f, time 497691, (7,4), root:(739,37), > state 0x0, keycode 199 (keysym 0x0, NoSymbol), same_screen YES, > XLookupString gives 0 bytes: > > Some things I noticed: On the num-pad only the "+-*/" work, return > doesn't (work state 0x0, keycode 156 (keysym 0x0, NoSymbol) ) and shift > doesn't (work state 0x0, keycode 205 (keysym 0x0, NoSymbol) ). Aha, so at least the keys work, they are only being mapped to strange codes. There's one thing I've missed when trying to bring sparc related stuff from keyboard driver. Can you try the whole reinstall fun with additional patch here: http://www.ijs.si/~lesi/xorg/patch-bsd_KbdMap.c This is supposed to prevent remapping so called "internet keys" for PC keyboards on sparc. Those events above were with patches applied, right? If the above patch fails, could you also try getting keycodes and keysyms with plain xorg-server version from ports? (I don't know if I'll be able to come with final solution in which case this data would be valuable when submitting bug report to X.Org.) Dejan From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 2 14:51:57 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A25C616A4CE for ; Wed, 2 Mar 2005 14:51:57 +0000 (GMT) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5727E43D2F for ; Wed, 2 Mar 2005 14:51:57 +0000 (GMT) (envelope-from j@ida.interface-business.de) Received: by ida.interface-business.de (Postfix, from userid 107) id 84EDC7A0C; Wed, 2 Mar 2005 15:51:51 +0100 (MET) Date: Wed, 2 Mar 2005 15:51:51 +0100 From: Joerg Wunsch To: freebsd-sparc64@freebsd.org Message-ID: <20050302145151.GC2266@ida.interface-business.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Phone: +49-351-31809-14 X-PGP-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 Organization: interface systems GmbH, Dresden User-Agent: Mutt/1.5.6i Subject: RELENG_5: zs(4) does not link without sbus X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joerg Wunsch List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 14:51:57 -0000 When trying to configure a kernel that has "device zs" but no "device sbus", linking fails: linking kernel zs.o(.text+0x4a4): In function `zstty_attach': : undefined reference to `zstty_console' zs.o(.text+0x1064): In function `zstty_param': : undefined reference to `zstty_set_speed' *** Error code 1 Is zs supposed to depend on sbus? There's no man page for it, so I can't tell. -- J"org Wunsch Unix support engineer joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/ From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 2 15:20:52 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C26FD16A4CE for ; Wed, 2 Mar 2005 15:20:52 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id A557443D55 for ; Wed, 2 Mar 2005 15:20:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 26109 invoked from network); 2 Mar 2005 15:20:51 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 2 Mar 2005 15:20:51 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j22FKeYM081583; Wed, 2 Mar 2005 10:20:44 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Bosko Milekic Date: Wed, 2 Mar 2005 10:16:36 -0500 User-Agent: KMail/1.6.2 References: <20050301000436.GA33346@xor.obsecurity.org> <20050301231438.GA25573@xor.obsecurity.org> <20050301234937.GA19502@technokratis.com> In-Reply-To: <20050301234937.GA19502@technokratis.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503021016.36953.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Kris Kennaway cc: sparc64@FreeBSD.org cc: rwatson@FreeBSD.org cc: freebsd-sparc64@FreeBSD.org cc: net@FreeBSD.org cc: Bosko Milekic cc: bmilekic@FreeBSD.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 15:20:52 -0000 On Tuesday 01 March 2005 06:49 pm, Bosko Milekic wrote: > You know, the more and more we run into these problems specific to how > reference counting is performed, I keep wondering whether some cleverly > defined macros for dealing with common reference counting operations > would be worthwhile. I'm not saying "introduce a refcount_t type and a > full-blown abstraction," but some template-like stuff might be useful. > It took a while just to get the refcount decrement on free path free of > races on SMP, and that's only in the mbuf code. Yeah, I have those simple refcount_foo() macros that operate on ints that would work for here and things like ucreds. Being macros, each arch can override if they have a better native instruction (xadd on x86, fetchadd on ia64, etc.) > -Bosko > > On Tue, Mar 01, 2005 at 03:14:38PM -0800, Kris Kennaway wrote: > > On Tue, Mar 01, 2005 at 06:04:27PM -0500, Bosko Milekic wrote: > > > This does not appear to explain the livelock. > > > > alc and dwhite tracked it down to a missing volatile causing gcc to > > mis-optimize the loop: > > > > - cnt = *(m->m_ext.ref_cnt); > > + cnt = *(volatile u_int *)(m->m_ext.ref_cnt); > > > > I'm currently testing that. > > > > Kris -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 2 15:20:52 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C29A216A4D0 for ; Wed, 2 Mar 2005 15:20:52 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4FD643D49 for ; Wed, 2 Mar 2005 15:20:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 26109 invoked from network); 2 Mar 2005 15:20:51 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 2 Mar 2005 15:20:51 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j22FKeYM081583; Wed, 2 Mar 2005 10:20:44 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Bosko Milekic Date: Wed, 2 Mar 2005 10:16:36 -0500 User-Agent: KMail/1.6.2 References: <20050301000436.GA33346@xor.obsecurity.org> <20050301231438.GA25573@xor.obsecurity.org> <20050301234937.GA19502@technokratis.com> In-Reply-To: <20050301234937.GA19502@technokratis.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503021016.36953.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Kris Kennaway cc: sparc64@FreeBSD.org cc: rwatson@FreeBSD.org cc: freebsd-sparc64@FreeBSD.org cc: net@FreeBSD.org cc: Bosko Milekic cc: bmilekic@FreeBSD.org Subject: Re: Race condition in mb_free_ext()? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 15:20:52 -0000 On Tuesday 01 March 2005 06:49 pm, Bosko Milekic wrote: > You know, the more and more we run into these problems specific to how > reference counting is performed, I keep wondering whether some cleverly > defined macros for dealing with common reference counting operations > would be worthwhile. I'm not saying "introduce a refcount_t type and a > full-blown abstraction," but some template-like stuff might be useful. > It took a while just to get the refcount decrement on free path free of > races on SMP, and that's only in the mbuf code. Yeah, I have those simple refcount_foo() macros that operate on ints that would work for here and things like ucreds. Being macros, each arch can override if they have a better native instruction (xadd on x86, fetchadd on ia64, etc.) > -Bosko > > On Tue, Mar 01, 2005 at 03:14:38PM -0800, Kris Kennaway wrote: > > On Tue, Mar 01, 2005 at 06:04:27PM -0500, Bosko Milekic wrote: > > > This does not appear to explain the livelock. > > > > alc and dwhite tracked it down to a missing volatile causing gcc to > > mis-optimize the loop: > > > > - cnt = *(m->m_ext.ref_cnt); > > + cnt = *(volatile u_int *)(m->m_ext.ref_cnt); > > > > I'm currently testing that. > > > > Kris -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 2 15:24:57 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A4AE16A4CE for ; Wed, 2 Mar 2005 15:24:57 +0000 (GMT) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EEB243D1F for ; Wed, 2 Mar 2005 15:24:56 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) j22FOsWW055045; Wed, 2 Mar 2005 16:24:54 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.11/8.12.10/Submit) id j22FOnlI055044; Wed, 2 Mar 2005 16:24:49 +0100 (CET) (envelope-from marius) Date: Wed, 2 Mar 2005 16:24:49 +0100 From: Marius Strobl To: Joerg Wunsch Message-ID: <20050302162448.A54517@newtrinity.zeist.de> References: <20050302145151.GC2266@ida.interface-business.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050302145151.GC2266@ida.interface-business.de>; from j@ida.interface-business.de on Wed, Mar 02, 2005 at 03:51:51PM +0100 X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-6; AVE: 6.30.0.2; VDF: 6.30.0.8; host: newtrinity.zeist.de) cc: freebsd-sparc64@freebsd.org Subject: Re: RELENG_5: zs(4) does not link without sbus X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 15:24:57 -0000 On Wed, Mar 02, 2005 at 03:51:51PM +0100, Joerg Wunsch wrote: > When trying to configure a kernel that has "device zs" but no > "device sbus", linking fails: > > linking kernel > zs.o(.text+0x4a4): In function `zstty_attach': > : undefined reference to `zstty_console' > zs.o(.text+0x1064): In function `zstty_param': > : undefined reference to `zstty_set_speed' > *** Error code 1 > > Is zs supposed to depend on sbus? There's no man page for it, so I > can't tell. > Sort of, one needs either fhc(4) or sbus(4) (or powermac(4) on powerpc) so the front-end is built. Not sure if it is a good idea to change sys/conf/files to build zs.c only when the respective front-end is also built, if a machine doesn't have a bus zs(4) can hang off from it doesn't make much sense to add zs(4) to its kernel config file in the first place. The current behaviour at least serves as a hint that zs(4) can be removed from the kernel config file... Marius From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 2 15:29:34 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B32DC16A4CE for ; Wed, 2 Mar 2005 15:29:34 +0000 (GMT) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50AE443D41 for ; Wed, 2 Mar 2005 15:29:34 +0000 (GMT) (envelope-from j@ida.interface-business.de) Received: by ida.interface-business.de (Postfix, from userid 107) id 372B07A0C; Wed, 2 Mar 2005 16:29:33 +0100 (MET) Date: Wed, 2 Mar 2005 16:29:33 +0100 From: Joerg Wunsch To: Marius Strobl Message-ID: <20050302152933.GD2266@ida.interface-business.de> References: <20050302145151.GC2266@ida.interface-business.de> <20050302162448.A54517@newtrinity.zeist.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050302162448.A54517@newtrinity.zeist.de> X-Phone: +49-351-31809-14 X-PGP-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 Organization: interface systems GmbH, Dresden User-Agent: Mutt/1.5.6i cc: freebsd-sparc64@freebsd.org Subject: Re: RELENG_5: zs(4) does not link without sbus X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joerg Wunsch List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 15:29:34 -0000 As Marius Strobl wrote: > ..., if a machine doesn't have a bus zs(4) > can hang off from it doesn't make much sense to add zs(4) to > its kernel config file in the first place. OK, it's in GENERIC, and I tried to strip that down as much as possible for my machine. I didn't notice I don't need zs(4) either. (I now removed it.) > The current behaviour > at least serves as a hint that zs(4) can be removed from the > kernel config file... Well, a man page explaining this would be better. ;-) -- J"org Wunsch Unix support engineer joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/ From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 2 16:10:46 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FC0E16A4CE for ; Wed, 2 Mar 2005 16:10:46 +0000 (GMT) Received: from device.dyndns.org (device.net1.nerim.net [62.212.100.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D57B43D1F for ; Wed, 2 Mar 2005 16:10:45 +0000 (GMT) (envelope-from guy@device.dyndns.org) Received: (from root@localhost) by device.dyndns.org (8.13.1/8.13.1) id j22GAh6w022902 for freebsd-sparc64@freebsd.org; Wed, 2 Mar 2005 17:10:43 +0100 (CET) (envelope-from guy@device.dyndns.org) Received: from pissenlit.device.local (pissenlit [10.0.0.88]) by device.dyndns.org (8.13.1/8.13.1) with ESMTP id j22GAaxM022881 for ; Wed, 2 Mar 2005 17:10:41 +0100 (CET) (envelope-from guy@device.dyndns.org) From: guy@device.dyndns.org Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 02 Mar 2005 17:10:37 +0100 (CET) To: freebsd-sparc64@freebsd.org X-Scanned-Against-Virii: by an antivirus :] Subject: 3D hardware acceleration X support ? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 16:10:46 -0000 Hello, I have a question and a request. Question : Am I right, thinking only the Elite 3D video card can do 3D hardware accelleration (opengl) for X in FreeBSD/sparc ? I - think I - have a Creator3D in my Ultra 30 Creator and cannot get it to work. Request : Please if someone on that list have supported 3d hardware, test the games/scorched3d-devel port - which I currently maintain. It builds and run fine for me - except the 0.01 FPS problem :] If not commited yet please fetch the last version from http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/78306 Thank you for your attention. -- Guy From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 2 18:47:11 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24A0B16A4CE for ; Wed, 2 Mar 2005 18:47:11 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 2425943D2D for ; Wed, 2 Mar 2005 18:47:10 +0000 (GMT) (envelope-from mmuthmann@gmx.net) Received: (qmail invoked by alias); 02 Mar 2005 18:47:07 -0000 Received: from pD9E5A618.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.166.24) by mail.gmx.net (mp020) with SMTP; 02 Mar 2005 19:47:07 +0100 X-Authenticated: #1009348 From: Matthias Muthmann To: freebsd-sparc64@freebsd.org In-Reply-To: <200503021050.35620.dejan.lesjak@ijs.si> References: <200502240244.03104.dejan.lesjak@ijs.si> <200502281848.36373.dejan.lesjak@ijs.si> <1109661404.19204.8.camel@localhost> <200503021050.35620.dejan.lesjak@ijs.si> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rA2uy+vsyQsrSQO11ZKq" Date: Wed, 02 Mar 2005 19:47:17 +0100 Message-Id: <1109789237.19508.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Y-GMX-Trusted: 0 cc: Dejan Lesjak Subject: Re: Problems with X.. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 18:47:11 -0000 --=-rA2uy+vsyQsrSQO11ZKq Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mi, 2005-03-02 at 10:50 +0100, Dejan Lesjak wrote: > Aha, so at least the keys work, they are only being mapped to strange cod= es.=20 > There's one thing I've missed when trying to bring sparc related stuff fr= om=20 > keyboard driver. Can you try the whole reinstall fun with additional patc= h=20 > here: > http://www.ijs.si/~lesi/xorg/patch-bsd_KbdMap.c > This is supposed to prevent remapping so called "internet keys" for PC=20 > keyboards on sparc. > Those events above were with patches applied, right? If the above patch f= ails,=20 > could you also try getting keycodes and keysyms with plain xorg-server=20 > version from ports? (I don't know if I'll be able to come with final solu= tion=20 > in which case this data would be valuable when submitting bug report to=20 > X.Org.) >=20 >=20 > Dejan >=20 I just tried the server with all 3 patches applied. I didn't notice any difference the the server with only the first two patches. What exactly do you want me to do? Send you all the keycodes and keysyms that outputs xev for every key? --=20 Matthias Muthmann --=-rA2uy+vsyQsrSQO11ZKq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCJgo1eA8bkj+29gMRAtDNAKCzt6C7GKkSqrsq1a33nHtYezwhCACeIn6X OL4+HHxfZJ0yCSn1hHJZK78= =yCQN -----END PGP SIGNATURE----- --=-rA2uy+vsyQsrSQO11ZKq-- From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 2 19:10:50 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4C7016A4CE for ; Wed, 2 Mar 2005 19:10:50 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAC3E43D1F for ; Wed, 2 Mar 2005 19:10:49 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost [IPv6:::1]) by niobe.ijs.si (Postfix) with ESMTP id EFD901DD436; Wed, 2 Mar 2005 20:10:48 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09218-01-24; Wed, 2 Mar 2005 20:10:40 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 48F071DD56E; Wed, 2 Mar 2005 20:10:40 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id B8BA51C0072C; Wed, 2 Mar 2005 20:10:39 +0100 (CET) From: Dejan Lesjak To: Matthias Muthmann Date: Wed, 2 Mar 2005 20:10:38 +0100 User-Agent: KMail/1.7.2 References: <200502240244.03104.dejan.lesjak@ijs.si> <200503021050.35620.dejan.lesjak@ijs.si> <1109789237.19508.3.camel@localhost> In-Reply-To: <1109789237.19508.3.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503022010.39072.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-sparc64@freebsd.org Subject: Re: Problems with X.. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 19:10:50 -0000 On Wednesday 02 of March 2005 19:47, Matthias Muthmann wrote: > On Mi, 2005-03-02 at 10:50 +0100, Dejan Lesjak wrote: > > Aha, so at least the keys work, they are only being mapped to strange > > codes. There's one thing I've missed when trying to bring sparc related > > stuff from keyboard driver. Can you try the whole reinstall fun with > > additional patch here: > > http://www.ijs.si/~lesi/xorg/patch-bsd_KbdMap.c > > This is supposed to prevent remapping so called "internet keys" for PC > > keyboards on sparc. > > Those events above were with patches applied, right? If the above patch > > fails, could you also try getting keycodes and keysyms with plain > > xorg-server version from ports? (I don't know if I'll be able to come > > with final solution in which case this data would be valuable when > > submitting bug report to X.Org.) > > > > > > Dejan > > I just tried the server with all 3 patches applied. I didn't notice any > difference the the server with only the first two patches. > What exactly do you want me to do? Send you all the keycodes and keysyms > that outputs xev for every key? Just the ones that don't work (if they are consecutive in the row, only a range would be fine). I'm also interested in whether without these patches applied - was the row in question behaving the same as the other keys (ie codes generated being off by one) or was it behaving differently even then? Dejan From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 2 22:24:04 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C90616A4CE for ; Wed, 2 Mar 2005 22:24:04 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3A3943D49 for ; Wed, 2 Mar 2005 22:24:03 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id C5B2172DD4; Wed, 2 Mar 2005 14:24:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id C159E72DCB; Wed, 2 Mar 2005 14:24:03 -0800 (PST) Date: Wed, 2 Mar 2005 14:24:03 -0800 (PST) From: Doug White To: Gheorghe Ardelean In-Reply-To: Message-ID: <20050302142332.A79573@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-sparc64@freebsd.org Subject: Re: Problems with 5.3R on Ultra1 with Qlogic SBUS Controller X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 22:24:04 -0000 On Tue, 1 Mar 2005, Gheorghe Ardelean wrote: > > Hi, > > I am trying to boot my plain Ultra1 (not 1E) which is not supported "as > is". So I put an Qlogic SBUS Diff SCSI controller (ISP1000) in it and a > HDD on which I have preinstalled FreeBSD 5.3R ( on my Ultra 5 + Adaptec 2944). > > As soon as it detects the zs0 the boot process hangs. > Has anybody any idea about what could cause this hang? I'm assuming you're booting off serial console here... does booting off the framebuffer work any better? > Here is the boot message: > > ok boot /sbus@1f,0/QLGC,isp@0,10000/sd@0,0 > Boot device: /sbus@1f,0/QLGC,isp@0,10000/sd@0,0 File and args: > > >> FreeBSD/sparc64 boot block > Boot path: /sbus@1f,0/QLGC,isp@0,10000/sd@0,0:a > Boot loader: /boot/loader > Console: Open Firmware console > > FreeBSD/sparc64 bootstrap loader, Revision 1.0 > (root@bobbi.cse.buffalo.edu, Fri Nov 5 02:16:10 UTC 2004) > bootpath="/sbus@1f,0/QLGC,isp@0,10000/sd@0,0:a" > WARNING: attempt to free non dma-alloc'd range: -2000 2000 > Loading /boot/defaults/loader.conf > WARNING: attempt to free non dma-alloc'd range: -2000 2000 > WARNING: attempt to free non dma-alloc'd range: -2000 2000 > WARNING: attempt to free non dma-alloc'd range: -2000 2000 > WARNING: attempt to free non dma-alloc'd range: -2000 2000 > /boot/kernel/kernel data=0x3b5f08+0x49e28 syms=[0x8+0x4ef60+0x8+0x43746] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel] in 8 seconds... > > Type '?' for a list of commands, 'help' for more detailed help. > OK boot > nothing to autoload yet. > jumping to kernel entry at 0xc0040000. > stray vector interrupt 2033 > Copyright (c) 1992-2004 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 5.3-RELEASE #0: Fri Nov 5 19:30:40 UTC 2004 > root@bobbi.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > Timecounter "tick" frequency 142988906 Hz quality 1000 > real memory = 335544320 (320 MB) > avail memory = 304701440 (290 MB) > cpu0: Sun Microsystems UltraSparc-I Processor (142.99 MHz CPU) > nexus0: > sbus0: clock 25.000 MHz > sbus dvma: DVMA map: 0xfc000000 to 0xffffffff > sbus0: [FAST] > sbus0: [FAST] > initializing counter-timer > Timecounter "counter-timer" frequency 1000000 Hz quality 100 > sbus0: on nexus0 > sbus0: , type (unknown) (no driver attached) > sbus0: , type (unknown) (no driver attached) > sbus0: , type (unknown) (no driver attached) > sbus0: , type block (no driver attached) > eeprom0: mem 0x1200000-0x1201fff on sbus0 > eeprom0: model mk48t59 > eeprom0: hostid 8085fe27 > zs0: mem 0x1100000-0x1100003 irq 2024 on sbus0 > zs0: [FAST] > zstty0: on zs0 > > This is the hardware I have inside the box: > ok cd /sbus > ok ls > f0083e74 cgsix@2,0 > f007c868 SUNW,fas@1,8800000 > f0074390 SUNW,hme@1,8c00000 > f006b9e4 QLGC,isp@0,10000 > f00694b0 SUNW,bpp@e,c800000 > f006668c ledma@e,8400010 > f006232c espdma@e,8400000 > f005ce34 SUNW,pll@f,1304000 > f005cd80 sc@f,1300000 > f005b324 zs@f,1000000 > f0059e84 zs@f,1100000 > f0059dd0 eeprom@f,1200000 > f0059c9c SUNW,fdtwo@f,1400000 > f0059bd4 flashprom@f,0 > f0059b44 auxio@f,1900000 > f0059a38 SUNW,CS4231@d,c000000 > > The machine is: > > Sun Ultra 1 SBus (UltraSPARC 143MHz), No Keyboard > OpenBoot 3.25, 320 MB memory installed, Serial #xxxxxx. > Ethernet address 8:0:20:xx:xx:xx, Host ID: yyyyyyy. > > I have also an Sun Swift (FAS+HME) combo inside the box but the HME is not > able to sense the link to my switch (so I cannot netboot it). In NetBSD > the hme works if I specify mediaopt 100BaseTX to ifconfig. > > Any ideas? What else could I try. > > Regards, > > Johny. > > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Thu Mar 3 02:03:40 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2EEA16A4CE for ; Thu, 3 Mar 2005 02:03:39 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 847BF43D4C for ; Thu, 3 Mar 2005 02:03:39 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 7CAD5516FB; Wed, 2 Mar 2005 18:03:37 -0800 (PST) Date: Wed, 2 Mar 2005 18:03:37 -0800 From: Kris Kennaway To: sparc64@FreeBSD.org Message-ID: <20050303020337.GA58811@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: 'Fatal reset' on e4500 running 6.0 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 02:03:40 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I updated the kernel of the e4500 to 6.0 to benchmark buildworld, but it reboots after a few seconds with: Fatal Reset @(#) Ultra Enterprise 3.2 Version 29 created 2001/06/18 17:28 0,0>FATAL ERROR 0,0> At time of error: System software was running. 0,0> Diagnosis: Board 0, any system board MTIMEOUT (target of operation) 0,0> Diagnosis: Board 2, any system board MTIMEOUT (target of operation) 0,0> Diagnosis: Board 3, any system board MTIMEOUT (target of operation) 0,0> Diagnosis: Board 4, any system board MTIMEOUT (target of operation) 0,0> Diagnosis: Board 5, any system board MTIMEOUT (target of operation) 0,0> Diagnosis: Board 7, any system board MTIMEOUT (target of operation) 0,0>Log Date: Mar 3 2:04:30 GMT 2005 0,0> 0,0>RESET INFO for CPU/Memory board in slot 0 0,0> AC ESR 00000000.01000003 MTIMEOUT UPA_B_ERR UPA_A_ERR 0,0> DC[0] 00 0,0> DC[1] 00 0,0> DC[2] 00 0,0> DC[3] 00 0,0> DC[4] 00 0,0> DC[5] 00 0,0> DC[6] 00 0,0> DC[7] 00 0,0> FHC CSR 00050200 LOC_FATAL SYNC NOT_BRD_PRES 0,0> FHC RCSR 02000000 FATAL 0,0> 0,0>RESET INFO for CPU/Memory board in slot 2 0,0> AC ESR 00000000.01000003 MTIMEOUT UPA_B_ERR UPA_A_ERR 0,0> DC[0] 00 0,0> DC[1] 00 0,0> DC[2] 00 0,0> DC[3] 00 0,0> DC[4] 00 0,0> DC[5] 00 0,0> DC[6] 00 0,0> DC[7] 00 0,0> FHC CSR 00010030 SYNC BRD_LED_M BRD_LED_R 0,0> FHC RCSR 02000000 FATAL 0,0> 0,0>RESET INFO for CPU/Memory board in slot 3 0,0> AC ESR 00000000.01000003 MTIMEOUT UPA_B_ERR UPA_A_ERR 0,0> DC[0] 00 0,0> DC[1] 00 0,0> DC[2] 00 0,0> DC[3] 00 0,0> DC[4] 00 0,0> DC[5] 00 0,0> DC[6] 00 0,0> DC[7] 00 0,0> FHC CSR 00010030 SYNC BRD_LED_M BRD_LED_R 0,0> FHC RCSR 02000000 FATAL 0,0> 0,0>RESET INFO for CPU/Memory board in slot 4 0,0> AC ESR 00000000.01000003 MTIMEOUT UPA_B_ERR UPA_A_ERR 0,0> DC[0] 00 0,0> DC[1] 00 0,0> DC[2] 00 0,0> DC[3] 00 0,0> DC[4] 00 0,0> DC[5] 00 0,0> DC[6] 00 0,0> DC[7] 00 0,0> FHC CSR 00010030 SYNC BRD_LED_M BRD_LED_R 0,0> FHC RCSR 02000000 FATAL 0,0> 0,0>RESET INFO for CPU/Memory board in slot 5 0,0> AC ESR 00000000.01000003 MTIMEOUT UPA_B_ERR UPA_A_ERR 0,0> DC[0] 00 0,0> DC[1] 00 0,0> DC[2] 00 0,0> DC[3] 00 0,0> DC[4] 00 0,0> DC[5] 00 0,0> DC[6] 00 0,0> DC[7] 00 0,0> FHC CSR 00010030 SYNC BRD_LED_M BRD_LED_R 0,0> FHC RCSR 02000000 FATAL 0,0> 0,0>RESET INFO for CPU/Memory board in slot 7 0,0> AC ESR 00000000.01000003 MTIMEOUT UPA_B_ERR UPA_A_ERR 0,0> DC[0] 00 0,0> DC[1] 00 0,0> DC[2] 00 0,0> DC[3] 00 0,0> DC[4] 00 0,0> DC[5] 00 0,0> DC[6] 00 0,0> DC[7] 00 0,0> FHC CSR 00050020 LOC_FATAL SYNC BRD_LED_M 0,0> FHC RCSR 02000000 FATAL 0 --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCJnB4Wry0BWjoQKURAkAfAJsFCe5017oix58wX+nhkh4Y2VaGpgCeKB2k u26MCI2VRpmY46LquvCtjMg= =vV3q -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From owner-freebsd-sparc64@FreeBSD.ORG Thu Mar 3 09:55:54 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA2AF16A4CE for ; Thu, 3 Mar 2005 09:55:54 +0000 (GMT) Received: from gizm0.org (gizm0.org [212.114.209.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F45043D1F for ; Thu, 3 Mar 2005 09:55:54 +0000 (GMT) (envelope-from freebsd@gizm0.org) Received: from localhost (localhost.org [127.0.0.1]) by gizm0.org (Postfix) with ESMTP id D9FD817044 for ; Thu, 3 Mar 2005 10:55:52 +0100 (CET) Received: from gizm0.org ([127.0.0.1]) by localhost (gizm0.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00434-05 for ; Thu, 3 Mar 2005 10:55:41 +0100 (CET) Received: from [10.0.0.122] (unknown [10.0.0.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gizm0.org (Postfix) with ESMTP for ; Thu, 3 Mar 2005 10:55:41 +0100 (CET) Message-ID: <4226DF25.3010802@gizm0.org> Date: Thu, 03 Mar 2005 10:55:49 +0100 From: Steven Enderle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050203 X-Accept-Language: de-de, de, en MIME-Version: 1.0 To: sparc64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at gizm0.org Subject: Sparc64 and gmirror (failture) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 09:55:55 -0000 Hello List, while trying to set up a gmirror boot partition for a sun netra x1, i ran into problems. I followed closely the well known manual at http://people.freebsd.org/%7Erse/mirror/ , except using sunlabel instead of bsdlabel and skipping fdisk process. I do see the disk with mirror/gm0 but not the partitions. But they do show up when viewed with sunlabel and in /dev/ad1x What i am missing here? Tested with boot 5.3-REL and 5.4-PREREL # ls total 1 dr-xr-xr-x 2 root wheel 512 Mar 3 10:12 . dr-xr-xr-x 5 root wheel 512 Mar 3 10:12 .. crw-r----- 1 root operator 4, 19 Mar 3 10:45 gm0 # ls ../ad1* crw-r----- 1 root operator 4, 18 Mar 3 10:17 ../ad1 crw-r----- 1 root operator 4, 20 Mar 3 10:17 ../ad1b crw-r----- 1 root operator 4, 21 Mar 3 10:17 ../ad1c crw-r----- 1 root operator 4, 22 Mar 3 10:17 ../ad1d crw-r----- 1 root operator 4, 23 Mar 3 10:17 ../ad1e crw-r----- 1 root operator 4, 24 Mar 3 10:17 ../ad1f crw-r----- 1 root operator 4, 25 Mar 3 10:17 ../ad1g # sunlabel mirror/gm0 # /dev/mirror/gm0: text: FreeBSD93G cyl 62747 alt 2 hd 16 sec 63 bytes/sectors: 512 sectors/cylinder: 1008 sectors/unit: 63248976 ls 8 partitions: # # Size is in sectors. # Offset is in cylinders. # size offset # ---------- ---------- a: 3248976 0 c: 63248976 0 From owner-freebsd-sparc64@FreeBSD.ORG Thu Mar 3 11:24:00 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AEDC16A4CE for ; Thu, 3 Mar 2005 11:24:00 +0000 (GMT) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id C622C43D58 for ; Thu, 3 Mar 2005 11:23:59 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) j23BNwp9075805; Thu, 3 Mar 2005 12:23:58 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.11/8.12.10/Submit) id j23BNrct075804; Thu, 3 Mar 2005 12:23:53 +0100 (CET) (envelope-from marius) Date: Thu, 3 Mar 2005 12:23:52 +0100 From: Marius Strobl To: Kris Kennaway Message-ID: <20050303122352.A74807@newtrinity.zeist.de> References: <20050303020337.GA58811@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050303020337.GA58811@xor.obsecurity.org>; from kris@obsecurity.org on Wed, Mar 02, 2005 at 06:03:37PM -0800 X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-6; AVE: 6.30.0.2; VDF: 6.30.0.10; host: newtrinity.zeist.de) cc: sparc64@freebsd.org Subject: Re: 'Fatal reset' on e4500 running 6.0 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 11:24:00 -0000 On Wed, Mar 02, 2005 at 06:03:37PM -0800, Kris Kennaway wrote: > I updated the kernel of the e4500 to 6.0 to benchmark buildworld, but > it reboots after a few seconds with: > <...> As far as I understand this means that it's a bug in a device driver. The sole sparc64 device driver that I'm aware of where -STABLE and -CURRENT aren't in sync is esp(4). If reverting the recent changes to esp_sbus.c and ncr53c9x.c doesn't make a difference you'll probably have to search for the commit that causes this. Marius From owner-freebsd-sparc64@FreeBSD.ORG Thu Mar 3 19:37:28 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1751B16A4CE for ; Thu, 3 Mar 2005 19:37:28 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id E7A3043D39 for ; Thu, 3 Mar 2005 19:37:26 +0000 (GMT) (envelope-from mmuthmann@gmx.net) Received: (qmail invoked by alias); 03 Mar 2005 19:37:25 -0000 Received: from pD9541E74.dip.t-dialin.net (EHLO [192.168.0.2]) (217.84.30.116) by mail.gmx.net (mp024) with SMTP; 03 Mar 2005 20:37:25 +0100 X-Authenticated: #1009348 From: Matthias Muthmann To: freebsd-sparc64@freebsd.org In-Reply-To: <200503022010.39072.dejan.lesjak@ijs.si> References: <200502240244.03104.dejan.lesjak@ijs.si> <200503021050.35620.dejan.lesjak@ijs.si> <1109789237.19508.3.camel@localhost> <200503022010.39072.dejan.lesjak@ijs.si> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dHO3Ah9RoZz6ro72YPvS" Date: Thu, 03 Mar 2005 20:37:25 +0100 Message-Id: <1109878645.18345.37.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Y-GMX-Trusted: 0 cc: Dejan Lesjak Subject: Re: Problems with X.. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 19:37:28 -0000 --=-dHO3Ah9RoZz6ro72YPvS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > Just the ones that don't work (if they are consecutive in the row, only a= =20 > range would be fine). I'm also interested in whether without these patche= s=20 > applied - was the row in question behaving the same as the other keys (ie= =20 > codes generated being off by one) or was it behaving differently even the= n? >=20 >=20 > Dejan >=20 Well, here's the output of xev for keys that don't seem to do anything (with your patches applied). I think I'll check the unpatched x-server tomorrow.=20 Since I have a German keyboard, there are also some special German keys (that btw dont't work). I wrote down every key, where xev outputs: XLookupString gives 0 bytes: None of the lights in the key (Num Lock, Caps Lock, ...) work. Mode Switch (=3D=3DAlt Gr) works (I con write an @). Shift doesn't work. (Help) keycode 220 (keysym 0x0, NoSymbol), keycode 8 (keysym 0xff69, Cancel) keycode 10 (keysym 0xff66, Redo) keycode 32 (keysym 0x1005ff70, SunProps) keycode 33 (keysym 0xff65, Undo) keycode 56 (keysym 0x1005ff71, SunFront) keycode 58 (keysym 0x1005ff72, SunCopy) keycode 79 (keysym 0x1005ff73, SunOpen) keycode 80 (keysym 0x1005ff74, SunPaste) (Search) keycode 183 (keysym 0x0, NoSymbol) Cut doesn't produce any event (I tried 2 different keyboards) keycode 12 (keysym 0xffbe, F1) keycode 13 (keysym 0xffbf, F2) keycode 15 (keysym 0xffc0, F3) keycode 17 (keysym 0xffc1, F4) keycode 19 (keysym 0xffc2, F5) keycode 21 (keysym 0xffc3, F6) keycode 23 (keysym 0xffc4, F7) keycode 24 (keysym 0xffc5, F8) keycode 25 (keysym 0xffc6, F9) keycode 14 (keysym 0xffc7, F10) keycode 16 (keysym 0xffc8, F11) keycode 18 (keysym 0xffc9, F12) keycode 29 (keysym 0xff61, Print) keycode 29 (keysym 0xff15, Sys_Req) keycode 30 (keysym 0xff14, Scroll_Lock) keycode 28 (keysym 0xff13, Pause) keycode 28 (keysym 0xff6b, Break) keycode 51 (keysym 0xff63, Insert) keycode 59 (keysym 0xff50, Home) (Page Up) keycode 223 (keysym 0x0, NoSymbol) keycode 81 (keysym 0xff57, End) keycode 130 (keysym 0xff56, Next) keycode 27 (keysym 0xff52, Up) keycode 34 (keysym 0xff54, Down) keycode 31 (keysym 0xff51, Left) keycode 35 (keysym 0xff53, Right) (Num Lock) keycode 188 (keysym 0x0, NoSymbol) (Enter) keycode 169 (keysym 0x0, NoSymbol) keycode 75 (keysym 0xff95, KP_Home) keycode 76 (keysym 0xff97, KP_Up) keycode 77 (keysym 0xff9a, KP_Prior) (KP Left) keycode 180 (keysym 0x0, NoSymbol) (KP 5) keycode 125 (keysym 0xff6a, Help) (KP Right) keycode 181 (keysym 0x0, NoSymbol) (KP End) keycode 207 (keysym 0x0, NoSymbol) (KP Down) keycode 208 (keysym 0x0, NoSymbol) (KP Next) keycode 209 (keysym 0x0, NoSymbol) (KP Insert) keycode 182 (keysym 0x0, NoSymbol) keycode 57 (keysym 0xff9f, KP_Delete) keycode 47 (keysym 0xdf, ssharp) keycode 48 (keysym 0xfe51, dead_acute) keycode 71 (keysym 0xfc, udiaeresis) keycode 126 (keysym 0xffe5, Caps_Lock) keycode 93 (keysym 0xf6, odiaeresis) keycode 94 (keysym 0xe4, adiaeresis) (Return) keycode 156 (keysym 0x0, NoSymbol) (Left Shift) keycode 189 (keysym 0x0, NoSymbol) (Right Shift) keycode 205 (keysym 0x0, NoSymbol) YXC keycode 190-192 (keysym 0x0, NoSymbol) VBNM keycode 197-200 (keysym 0x0, NoSymbol) ,.- keycode 202-204 (keysym 0x0, NoSymbol) keycode 83 (keysym 0xffe3, Control_L) keycode 26 (keysym 0xffe9, Alt_L) keycode 127 (keysym 0xffe7, Meta_L) keycode 129 (keysym 0xffe8, Meta_R) keycode 74 (keysym 0xff20, Multi_key) keycode 20 (keysym 0xff7e, Mode_switch) I hope this helps you. Btw, I don't know if this is interesting, but I searched if this bug also exists in Linux and discovered that it seems only to exist with the 2.4 kernel, but not with the 2.6 kernel.=20 --=20 Matthias Muthmann --=-dHO3Ah9RoZz6ro72YPvS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCJ2d1eA8bkj+29gMRAkQMAJ4k81sbzyy8KmI+nPqJiHdDUoWPNACfc5y2 rnE66QRoVPbAGK8/ZMk68D8= =Wusz -----END PGP SIGNATURE----- --=-dHO3Ah9RoZz6ro72YPvS-- From owner-freebsd-sparc64@FreeBSD.ORG Thu Mar 3 20:42:10 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1531516A4CE for ; Thu, 3 Mar 2005 20:42:10 +0000 (GMT) Received: from post-24.mail.nl.demon.net (post-24.mail.nl.demon.net [194.159.73.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA9F243D54 for ; Thu, 3 Mar 2005 20:42:09 +0000 (GMT) (envelope-from kwm@rainbow-runner.nl) Received: from kazerne.demon.nl ([212.238.222.22]:58325 helo=heater.rainbow-runner.nl) by post-24.mail.nl.demon.net with esmtp (Exim 4.43) id 1D6x96-0007fR-Qk for freebsd-sparc64@freebsd.org; Thu, 03 Mar 2005 20:42:08 +0000 From: Koop Mast To: freebsd-sparc64@freebsd.org Content-Type: text/plain Date: Thu, 03 Mar 2005 21:42:22 +0100 Message-Id: <1109882542.38269.13.camel@heater.rainbow-runner.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: esp driver complains X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:42:10 -0000 Hello, On my Ultra 2 I get the following below. The box works like it should but its complaining about something. I don't know when this turned up but this wasn't there in 5.3-R or in older -current builds. Koop > uname -a FreeBSD ultra 6.0-CURRENT FreeBSD 6.0-CURRENT #70: Wed Mar 2 00:12:13 CET 2005 root@ultra:/usr/obj/usr/src/sys/BlackBird sparc64 Timecounters tick every 10.000 msec Waiting 2 seconds for SCSI devices to settle esp0: target didn't send tag: 15 bytes in fifo [127] [0] [3] [18] [139] [0] [1] [62] [83] [69] [65] [71] [65] [84] [69] esp0: SCSI bus reset esp0: target didn't send tag: 0 bytes in fifo esp0: SCSI bus reset esp0: target didn't send tag: 0 bytes in fifo esp0: SCSI bus reset esp0: target didn't send tag: 0 bytes in fifo esp0: SCSI bus reset esp0: target didn't send tag: 0 bytes in fifo esp0: SCSI bus reset SMP: AP CPU #1 Launched! cd0 at esp0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Logical unit is in process of becoming ready da0 at esp0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 6.600MB/s transfers (16bit), Tagged Queueing Enabled da0: 35003MB (71687369 512 byte sectors: 255H 63S/T 4462C) Trying to mount root from ufs:/dev/da0a From owner-freebsd-sparc64@FreeBSD.ORG Fri Mar 4 02:18:53 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69B7516A4CE for ; Fri, 4 Mar 2005 02:18:53 +0000 (GMT) Received: from ns.kt-is.co.kr (ns.kt-is.co.kr [211.218.149.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8435543D1D for ; Fri, 4 Mar 2005 02:18:52 +0000 (GMT) (envelope-from yongari@kt-is.co.kr) Received: from michelle.kt-is.co.kr (ns2.kt-is.co.kr [220.76.118.193]) (authenticated bits=128) by ns.kt-is.co.kr (8.12.10/8.12.10) with ESMTP id j242FjAh062240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Mar 2005 11:15:56 +0900 (KST) Received: from michelle.kt-is.co.kr (localhost.kt-is.co.kr [127.0.0.1]) by michelle.kt-is.co.kr (8.13.1/8.13.1) with ESMTP id j242Idm8016550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Mar 2005 11:18:39 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Received: (from yongari@localhost) by michelle.kt-is.co.kr (8.13.1/8.13.1/Submit) id j242IW58016549; Fri, 4 Mar 2005 11:18:32 +0900 (KST) (envelope-from yongari@kt-is.co.kr) Date: Fri, 4 Mar 2005 11:18:32 +0900 From: Pyun YongHyeon To: Koop Mast Message-ID: <20050304021832.GA16398@kt-is.co.kr> References: <1109882542.38269.13.camel@heater.rainbow-runner.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109882542.38269.13.camel@heater.rainbow-runner.nl> User-Agent: Mutt/1.4.2.1i X-Filter-Version: 1.11a (ns.kt-is.co.kr) cc: freebsd-sparc64@freebsd.org Subject: Re: esp driver complains X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: yongari@kt-is.co.kr List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 02:18:53 -0000 On Thu, Mar 03, 2005 at 09:42:22PM +0100, Koop Mast wrote: > Hello, > > On my Ultra 2 I get the following below. > The box works like it should but its complaining about something. > I don't know when this turned up but this wasn't there in 5.3-R or in > older -current builds. > There was a change in esp(4) driver. Modified files: sys/dev/esp esp_sbus.c ncr53c9x.c Log: The existing locking in the esp driver appears to be fairly adequate, so set the interrupt handler to be INTR_MPSAFE now that xpt_done() can be called without Giant. Giant is still on the top half of the driver and the timeout handlers. Revision Changes Path 1.9 +1 -1 src/sys/dev/esp/esp_sbus.c 1.8 +0 -2 src/sys/dev/esp/ncr53c9x.c I had no problems with these changes on Ultra2. But it's worthwile to back out and check whether it helps. -- Regards, Pyun YongHyeon http://www.kr.freebsd.org/~yongari | yongari@freebsd.org From owner-freebsd-sparc64@FreeBSD.ORG Fri Mar 4 03:28:59 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72FBF16A4CE for ; Fri, 4 Mar 2005 03:28:59 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAAB743D2F for ; Fri, 4 Mar 2005 03:28:56 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j243Uuc1007917; Thu, 3 Mar 2005 20:30:56 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4227D572.9060406@samsco.org> Date: Thu, 03 Mar 2005 20:26:42 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Koop Mast References: <1109882542.38269.13.camel@heater.rainbow-runner.nl> In-Reply-To: <1109882542.38269.13.camel@heater.rainbow-runner.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-sparc64@freebsd.org Subject: Re: esp driver complains X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 03:28:59 -0000 Koop Mast wrote: > Hello, > > On my Ultra 2 I get the following below. > The box works like it should but its complaining about something. > I don't know when this turned up but this wasn't there in 5.3-R or in > older -current builds. > > Koop > > >>uname -a > > FreeBSD ultra 6.0-CURRENT FreeBSD 6.0-CURRENT #70: Wed Mar 2 00:12:13 > CET 2005 root@ultra:/usr/obj/usr/src/sys/BlackBird sparc64 > > Timecounters tick every 10.000 msec > Waiting 2 seconds for SCSI devices to settle > esp0: target didn't send tag: 15 bytes in fifo > [127] [0] [3] [18] [139] [0] [1] [62] [83] [69] [65] [71] [65] [84] [69] > esp0: SCSI bus reset > esp0: target didn't send tag: 0 bytes in fifo > esp0: SCSI bus reset > esp0: target didn't send tag: 0 bytes in fifo > esp0: SCSI bus reset > esp0: target didn't send tag: 0 bytes in fifo > esp0: SCSI bus reset > esp0: target didn't send tag: 0 bytes in fifo > esp0: SCSI bus reset > SMP: AP CPU #1 Launched! > cd0 at esp0 bus 0 target 6 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 3.300MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Logical unit is in > process of becoming ready > da0 at esp0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 6.600MB/s transfers (16bit), Tagged Queueing Enabled > da0: 35003MB (71687369 512 byte sectors: 255H 63S/T 4462C) > Trying to mount root from ufs:/dev/da0a > > The negotiated transfer rates also look awefully suspicious. You can try reverting the recent esp driver changes like Pyun suggests. Scott From owner-freebsd-sparc64@FreeBSD.ORG Fri Mar 4 03:44:49 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DA6616A4CE for ; Fri, 4 Mar 2005 03:44:49 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6C4443D3F for ; Fri, 4 Mar 2005 03:44:48 +0000 (GMT) (envelope-from gaspolo@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so520114rng for ; Thu, 03 Mar 2005 19:44:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=sQ3CIDmm2vgmmnguc+hyZCd5SfwxlXuQFDMhskqVRz6BEPhKNSpUs/LesFPNokbC/gWfPodcKFbWdJOh+zffgtgH7GfEk4GYGxzx4hbYpSOgkKU0jjVpG1GHU62Q6j/NTA4ocDnniaQCJoY+RsBWjoHpG9nCgTYbyDYDIgTwTJg= Received: by 10.38.24.59 with SMTP id 59mr363711rnx; Thu, 03 Mar 2005 19:44:48 -0800 (PST) Received: by 10.38.24.75 with HTTP; Thu, 3 Mar 2005 19:44:47 -0800 (PST) Message-ID: Date: Fri, 4 Mar 2005 04:44:47 +0100 From: gaspo To: freebsd-sparc64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: boot cdrom error X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: gaspo List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 03:44:49 -0000 hi i have this problem now..i wanna reinstall my freebsd for have a fresh installation of freebsd....5.3... on my ultra5 sun server... but when i type: stop A ok > boot cdrom Can't read disk label. Can't open disk label package Can't open boot device .... how is possible? because on this hard disk was installed solaris5.7.. i replace freebsd 5.3 some day ago with normal installation on cd boot cdrom ecc.....and all work...perfectly..now WITH same hard disk and same CD...i can boot freebsd rom cd why?? i have tried also to reburn cdrom...change CDROM ..change Operative sistem...like netbsd openbsd ecc... but The only sistem boot from Cd is sun 10.. anybody have any idea? From owner-freebsd-sparc64@FreeBSD.ORG Fri Mar 4 03:48:59 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D29C916A4CE for ; Fri, 4 Mar 2005 03:48:59 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69F9F43D5C for ; Fri, 4 Mar 2005 03:48:59 +0000 (GMT) (envelope-from gaspolo@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so520738rng for ; Thu, 03 Mar 2005 19:48:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=F+PkZUS+GISoZiJ2r9pSZyxgjPYr5lm3K6yskYGyUcvMlS/Upuip++b5bNrkNvNn4+GuJd1joqwgyr2gOlNO1hhikNfVoAqDguqGYc+2YIH9IMLuRGYFbMN75x5qcJFy/ihYtgOTgDdCZ/yzYqXmgYxc5VQlbl5yAKcQZTEjUF8= Received: by 10.38.165.20 with SMTP id n20mr95348rne; Thu, 03 Mar 2005 19:48:58 -0800 (PST) Received: by 10.38.24.75 with HTTP; Thu, 3 Mar 2005 19:48:58 -0800 (PST) Message-ID: Date: Fri, 4 Mar 2005 04:48:58 +0100 From: gaspo To: sparc64@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Subject: Re: boot cdrom error X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: gaspo List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 03:48:59 -0000 hi i have this problem now..i wanna reinstall my freebsd for have a fresh installation of freebsd....5.3... on my ultra5 sun server... but when i type: stop A ok > boot cdrom Can't read disk label. Can't open disk label package Can't open boot device .... how is possible? because on this hard disk was installed solaris5.7.. i replace freebsd 5.3 some day ago with normal installation on cd boot cdrom ecc.....and all work...perfectly..now WITH same hard disk and same CD...i can boot freebsd rom cd why?? i have tried also to reburn cdrom...change CDROM ..change Operative sistem...like netbsd openbsd ecc... but The only sistem boot from Cd is sun 10.. anybody have any idea? From owner-freebsd-sparc64@FreeBSD.ORG Fri Mar 4 15:35:07 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50DCE16A4CE for ; Fri, 4 Mar 2005 15:35:07 +0000 (GMT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 31AC643D2D for ; Fri, 4 Mar 2005 15:35:06 +0000 (GMT) (envelope-from mmuthmann@gmx.net) Received: (qmail invoked by alias); 04 Mar 2005 15:35:03 -0000 Received: from p54805A62.dip.t-dialin.net (EHLO [192.168.0.2]) (84.128.90.98) by mail.gmx.net (mp004) with SMTP; 04 Mar 2005 16:35:03 +0100 X-Authenticated: #1009348 From: Matthias Muthmann To: freebsd-sparc64@freebsd.org In-Reply-To: <200503022010.39072.dejan.lesjak@ijs.si> References: <200502240244.03104.dejan.lesjak@ijs.si> <200503021050.35620.dejan.lesjak@ijs.si> <1109789237.19508.3.camel@localhost> <200503022010.39072.dejan.lesjak@ijs.si> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-97gOsJDFP9evNzfI2IR+" Date: Fri, 04 Mar 2005 16:34:53 +0100 Message-Id: <1109950493.21431.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Y-GMX-Trusted: 0 cc: Dejan Lesjak Subject: Re: Problems with X.. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 15:35:07 -0000 --=-97gOsJDFP9evNzfI2IR+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mi, 2005-03-02 at 20:10 +0100, Dejan Lesjak wrote: > Just the ones that don't work (if they are consecutive in the row, only a= =20 > range would be fine). I'm also interested in whether without these patche= s=20 > applied - was the row in question behaving the same as the other keys (ie= =20 > codes generated being off by one) or was it behaving differently even the= n? >=20 >=20 > Dejan >=20 Ok, now I tried X without your patches. The lowest row behaves in the same way as with your patches: e.g. keycode 198 (keysym 0x0, NoSymbol) But the keycodes are shifted by one (Y is 191, not 190 ...) --=20 Matthias Muthmann --=-97gOsJDFP9evNzfI2IR+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCKIAdeA8bkj+29gMRAsdbAKCRp+J6gsRWeQfdgV0Jl0YaeA9eiwCfbFos YguyZiSkMhyLpv8oNZsOE7U= =JkEP -----END PGP SIGNATURE----- --=-97gOsJDFP9evNzfI2IR+-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Mar 4 15:44:50 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0760B16A4CE for ; Fri, 4 Mar 2005 15:44:50 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F19343D54 for ; Fri, 4 Mar 2005 15:44:49 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost [IPv6:::1]) by niobe.ijs.si (Postfix) with ESMTP id 4D4581DD5A7; Fri, 4 Mar 2005 16:44:48 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 65020-01-92; Fri, 4 Mar 2005 16:44:35 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id A133F1DD59D; Fri, 4 Mar 2005 16:44:35 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id E29531C00715; Fri, 4 Mar 2005 16:44:34 +0100 (CET) From: Dejan Lesjak To: Matthias Muthmann Date: Fri, 4 Mar 2005 16:44:34 +0100 User-Agent: KMail/1.7.2 References: <200502240244.03104.dejan.lesjak@ijs.si> <200503022010.39072.dejan.lesjak@ijs.si> <1109950493.21431.5.camel@localhost> In-Reply-To: <1109950493.21431.5.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503041644.34459.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-sparc64@freebsd.org Subject: Re: Problems with X.. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 15:44:50 -0000 On Friday 04 of March 2005 16:34, Matthias Muthmann wrote: > On Mi, 2005-03-02 at 20:10 +0100, Dejan Lesjak wrote: > > Just the ones that don't work (if they are consecutive in the row, only a > > range would be fine). I'm also interested in whether without these > > patches applied - was the row in question behaving the same as the other > > keys (ie codes generated being off by one) or was it behaving differently > > even then? > > > > > > Dejan > > Ok, now I tried X without your patches. The lowest row behaves in the > same way as with your patches: > e.g. keycode 198 (keysym 0x0, NoSymbol) > But the keycodes are shifted by one (Y is 191, not 190 ...) Thank you! I'll try digging into this over weekend and hopefully find something that can be done to map codes properly :) Dejan From owner-freebsd-sparc64@FreeBSD.ORG Sat Mar 5 07:51:26 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 677E516A4CE for ; Sat, 5 Mar 2005 07:51:26 +0000 (GMT) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22E8E43D2F for ; Sat, 5 Mar 2005 07:51:22 +0000 (GMT) (envelope-from phil.stracchino@speakeasy.net) Received: (qmail 19950 invoked from network); 5 Mar 2005 07:32:31 -0000 Received: from dsl081-053-242.sfo1.dsl.speakeasy.net (HELO [192.168.0.20]) (caerllewys@[64.81.53.242]) (envelope-sender ) AES256-SHA encrypted SMTP for ; 5 Mar 2005 07:32:31 -0000 Message-ID: <4229608E.3040903@speakeasy.net> Date: Fri, 04 Mar 2005 23:32:30 -0800 From: Phil Stracchino User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-sparc@FreeBSD.org X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Terminal question for U5 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 07:51:26 -0000 Hi, I hope this is a quickie question: What can I do to get a usable terminal for sysinstall on a Sun Ultra5, using the default built-in framebuffer attached to a Sun 365-1343 17" color monitor? I have a perfectly good FreeBSD 5.3 sparc64 CD here which I can't install from because I can't see what I'm doing in sysinstall, because all the available terminal types appear to assume my screen is 80x25. -- Phil Stracchino Renaissance Man, Unix generalist, Perl hacker phil.stracchino@speakeasy.net phil.stracchino@ceva-dsp.com Mobile: 408-592-8081 From owner-freebsd-sparc64@FreeBSD.ORG Sat Mar 5 08:04:20 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCF7016A4CE for ; Sat, 5 Mar 2005 08:04:20 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74AFD43D55 for ; Sat, 5 Mar 2005 08:04:20 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5156872DD8; Sat, 5 Mar 2005 00:04:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 4BFB572DD4; Sat, 5 Mar 2005 00:04:20 -0800 (PST) Date: Sat, 5 Mar 2005 00:04:20 -0800 (PST) From: Doug White To: gaspo In-Reply-To: Message-ID: <20050305000242.K4084@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-sparc64@freebsd.org Subject: Re: boot cdrom error X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 08:04:20 -0000 On Fri, 4 Mar 2005, gaspo wrote: > hi i have this problem now..i wanna reinstall my freebsd for have a > fresh installation of freebsd....5.3... on my ultra5 sun server... > but when i type: > stop A > ok > boot cdrom > Can't read disk label. > Can't open disk label package > Can't open boot device > .... > how is possible? You're using the i386 disc image on a SPARC? :) It sounds like you may have the CDROM drive miscabled or the master/slave/cable select jumper incorrectly set for your system. Its also possible the drive doesn't like the brand of CD-Rs you're using. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Sat Mar 5 08:08:37 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D51916A4CE for ; Sat, 5 Mar 2005 08:08:37 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E87F43D1D for ; Sat, 5 Mar 2005 08:08:37 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 2316772DD8; Sat, 5 Mar 2005 00:08:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 1E86A72DD4; Sat, 5 Mar 2005 00:08:37 -0800 (PST) Date: Sat, 5 Mar 2005 00:08:37 -0800 (PST) From: Doug White To: Phil Stracchino In-Reply-To: <4229608E.3040903@speakeasy.net> Message-ID: <20050305000429.A4084@carver.gumbysoft.com> References: <4229608E.3040903@speakeasy.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-sparc@FreeBSD.org Subject: Re: Terminal question for U5 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 08:08:37 -0000 On Fri, 4 Mar 2005, Phil Stracchino wrote: > I hope this is a quickie question: What can I do to get a usable > terminal for sysinstall on a Sun Ultra5, using the default built-in > framebuffer attached to a Sun 365-1343 17" color monitor? I have a > perfectly good FreeBSD 5.3 sparc64 CD here which I can't install from > because I can't see what I'm doing in sysinstall, because all the > available terminal types appear to assume my screen is 80x25. Use a serial console. Plug in a null-modem cable into the serial port, connect the other end to a system of choice, and unplug the sun keyboard from the U5. Fire up a terminal emulator on the other system. Boot the U5 from CD and follow the prompts. If you have another FreeBSD or Linux machine you can typically get the color menus to work :) Note that you can't run X on the builtin display anyway so unless you particularly like the slow OBP console you'll want to use some other method of communication. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Sat Mar 5 09:13:04 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F3CC16A4CE for ; Sat, 5 Mar 2005 09:13:04 +0000 (GMT) Received: from mail26.sea5.speakeasy.net (mail26.sea5.speakeasy.net [69.17.117.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id C256F43D3F for ; Sat, 5 Mar 2005 09:13:03 +0000 (GMT) (envelope-from phil.stracchino@speakeasy.net) Received: (qmail 13256 invoked from network); 5 Mar 2005 09:13:03 -0000 Received: from dsl081-053-242.sfo1.dsl.speakeasy.net (HELO [192.168.1.100]) (caerllewys@[64.81.53.242]) (envelope-sender ) by mail26.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 5 Mar 2005 09:13:02 -0000 Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.6.2]); Sat, 05 Mar 2005 01:13:01 -0800 Message-ID: <4229781B.1040609@speakeasy.net> Date: Sat, 05 Mar 2005 01:12:59 -0800 From: Phil Stracchino User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug White References: <4229608E.3040903@speakeasy.net> <20050305000429.A4084@carver.gumbysoft.com> In-Reply-To: <20050305000429.A4084@carver.gumbysoft.com> X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit cc: freebsd-sparc@FreeBSD.org Subject: Re: Terminal question for U5 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 09:13:04 -0000 Doug White wrote: > On Fri, 4 Mar 2005, Phil Stracchino wrote: > > >>I hope this is a quickie question: What can I do to get a usable >>terminal for sysinstall on a Sun Ultra5, using the default built-in >>framebuffer attached to a Sun 365-1343 17" color monitor? I have a >>perfectly good FreeBSD 5.3 sparc64 CD here which I can't install from >>because I can't see what I'm doing in sysinstall, because all the >>available terminal types appear to assume my screen is 80x25. > > > Use a serial console. Plug in a null-modem cable into the serial port, > connect the other end to a system of choice, and unplug the sun keyboard > from the U5. Fire up a terminal emulator on the other system. Boot the U5 > from CD and follow the prompts. If you have another FreeBSD or Linux > machine you can typically get the color menus to work :) Thanks. I suspected something like that might be the case. Unfortunately, I don't have a working serial-console cable here with me. > Note that you can't run X on the builtin display anyway so unless you > particularly like the slow OBP console you'll want to use some other > method of communication. Well, I was figuring the box would run headless. It's tasked to be a nameserver and not much else at present. But by the sound of things, unless I can come up with a working serial console cable, I may have to rethink what to put on it. -- Phil Stracchino Renaissance Man, Unix generalist, Perl hacker phil.stracchino@speakeasy.net phil.stracchino@ceva-dsp.com Mobile: 408-592-8081