From owner-freebsd-alpha@FreeBSD.ORG Sun Mar 30 09:31:53 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C4A437B401 for ; Sun, 30 Mar 2003 09:31:53 -0800 (PST) Received: from ns1.smartnet.ca (ns1.smartnet.ca [216.113.20.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C92F343FA3 for ; Sun, 30 Mar 2003 09:31:51 -0800 (PST) (envelope-from chrisr@beosppc.org) Received: from homeipaq (modemcable061.53-202-24.mtl.mc.videotron.ca [24.202.53.61]) by ns1.smartnet.ca (8.11.0/8.11.0) with SMTP id h2UHVnj07799 for ; Sun, 30 Mar 2003 12:31:50 -0500 (EST) Message-ID: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> From: "Chris Rupnik" To: Date: Sun, 30 Mar 2003 12:31:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 17:31:54 -0000 Hi, I submitted a bug report in early Feb regarding the fact that a 5.0 kernel with a FDDI card produces a machine check. I cannot believe I am the only one to use such a card? http://www.freebsd.org/cgi/query-pr.cgi?pr=alpha/47952 Or am I? Thanks Christopher From owner-freebsd-alpha@FreeBSD.ORG Sun Mar 30 09:42:17 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6476637B401 for ; Sun, 30 Mar 2003 09:42:17 -0800 (PST) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 420E543FCB for ; Sun, 30 Mar 2003 09:42:16 -0800 (PST) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.8/8.12.8) with ESMTP id h2UHgCmk001318; Sun, 30 Mar 2003 19:42:12 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.8/8.12.8/Submit) id h2UHgCO8001317; Sun, 30 Mar 2003 19:42:12 +0200 (CEST) Date: Sun, 30 Mar 2003 19:42:12 +0200 From: Wilko Bulte To: Chris Rupnik Message-ID: <20030330174212.GA1302@freebie.xs4all.nl> References: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> User-Agent: Mutt/1.4i X-OS: FreeBSD 4.8-RC X-PGP: finger wilko@freebsd.org cc: freebsd-alpha@freebsd.org Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 17:42:18 -0000 On Sun, Mar 30, 2003 at 12:31:43PM -0500, Chris Rupnik wrote: > Hi, > I submitted a bug report in early Feb regarding the fact that a 5.0 kernel > with a FDDI card produces a machine check. I cannot believe I am the only > one to use such a card? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=alpha/47952 > > Or am I? Maybe ;-) I have 2 DEFPAs here but they are sitting in the parts store room. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte From owner-freebsd-alpha@FreeBSD.ORG Sun Mar 30 09:57:45 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F33C37B401 for ; Sun, 30 Mar 2003 09:57:45 -0800 (PST) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [80.86.187.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B78543FAF for ; Sun, 30 Mar 2003 09:57:43 -0800 (PST) (envelope-from lehmann@ans-netz.de) Received: (qmail 67422 invoked from network); 30 Mar 2003 17:57:38 -0000 Received: from unknown (HELO dill.salatschuessel.net) (217.226.26.244) by avocado.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 30 Mar 2003 17:57:38 -0000 Received: (qmail 7326 invoked from network); 30 Mar 2003 17:57:39 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (10.0.1.51) by dill.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 30 Mar 2003 17:57:39 -0000 Received: from kartoffel.salatschuessel.net (localhost [127.0.0.1]) h2UHvPJG002002; Sun, 30 Mar 2003 19:57:26 +0200 (CEST) (envelope-from lehmann@ans-netz.de) Date: Sun, 30 Mar 2003 19:57:25 +0200 From: Oliver Lehmann To: freebsd-alpha@freebsd.org Message-Id: <20030330195725.4678d99f.lehmann@ans-netz.de> In-Reply-To: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> References: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> X-Mailer: Sylpheed version 0.8.11cvs14 (GTK+ 1.2.10; i386-unknown-freebsdelf4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: Chris Rupnik Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 17:57:50 -0000 Chris Rupnik wrote: > I cannot believe I am the only > one to use such a card? Hm.. I have a FDDI Card - but the card is sitting in my x86-router (And is waiting for the receiver [FDDI EISA Card @HP 9000/735]) fpa0: port 0x6100-0x617f mem 0xe0000000-0xe000ffff,0xe0010000-0xe001007f irq 11 at device 18.0 on pci0 fpa0: DEC DEFPA PCI FDDI SAS Controller fpa0: FDDI address 00:a0:24:61:dd:36, FW=2.46, HW=1, SMT V7.2 fpa0: FDDI Port = S (PMD = ANSI Multi-Mode) fpa0: driver is using old-style compatibility shims If i can find some time, i can plug the card out and in my alpha (which runs 5.0-REL-p6 - my Router is still on 4). Maybe tomorrow. Greetings, Oliver -- Oliver Lehmann @home: lehmann@ans-netz.de @office: oliver.lehmann@mgi.de @www: http://www.pofo.de/ | http://wishlist.ans-netz.de/ From owner-freebsd-alpha@FreeBSD.ORG Sun Mar 30 10:00:57 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9D6037B401 for ; Sun, 30 Mar 2003 10:00:57 -0800 (PST) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E3BA43FE1 for ; Sun, 30 Mar 2003 10:00:56 -0800 (PST) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.8/8.12.8) with ESMTP id h2UI0rmk001467; Sun, 30 Mar 2003 20:00:53 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.8/8.12.8/Submit) id h2UI0rpp001466; Sun, 30 Mar 2003 20:00:53 +0200 (CEST) Date: Sun, 30 Mar 2003 20:00:53 +0200 From: Wilko Bulte To: Oliver Lehmann Message-ID: <20030330180053.GA1421@freebie.xs4all.nl> References: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> <20030330195725.4678d99f.lehmann@ans-netz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030330195725.4678d99f.lehmann@ans-netz.de> User-Agent: Mutt/1.4i X-OS: FreeBSD 4.8-RC X-PGP: finger wilko@freebsd.org cc: Chris Rupnik cc: freebsd-alpha@freebsd.org Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 18:00:58 -0000 On Sun, Mar 30, 2003 at 07:57:25PM +0200, Oliver Lehmann wrote: > Chris Rupnik wrote: > > > I cannot believe I am the only > > one to use such a card? > > Hm.. I have a FDDI Card - but the card is sitting in my x86-router (And is > waiting for the receiver [FDDI EISA Card @HP 9000/735]) > > fpa0: port 0x6100-0x617f mem > 0xe0000000-0xe000ffff,0xe0010000-0xe001007f irq 11 at device 18.0 on pci0 > fpa0: DEC DEFPA PCI FDDI SAS Controller > fpa0: FDDI address 00:a0:24:61:dd:36, FW=2.46, HW=1, SMT V7.2 > fpa0: FDDI Port = S (PMD = ANSI Multi-Mode) > fpa0: driver is using old-style compatibility shims > IIRC it works on x86 but not on alpha -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte From owner-freebsd-alpha@FreeBSD.ORG Sun Mar 30 10:11:31 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FC9E37B401 for ; Sun, 30 Mar 2003 10:11:31 -0800 (PST) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [80.86.187.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2F7043F93 for ; Sun, 30 Mar 2003 10:11:29 -0800 (PST) (envelope-from lehmann@ans-netz.de) Received: (qmail 67698 invoked from network); 30 Mar 2003 18:11:25 -0000 Received: from unknown (HELO dill.salatschuessel.net) (217.226.26.244) by avocado.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 30 Mar 2003 18:11:25 -0000 Received: (qmail 7417 invoked from network); 30 Mar 2003 18:11:24 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (10.0.1.51) by dill.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 30 Mar 2003 18:11:24 -0000 Received: from kartoffel.salatschuessel.net (localhost [127.0.0.1]) h2UIBNJG002029; Sun, 30 Mar 2003 20:11:23 +0200 (CEST) (envelope-from lehmann@ans-netz.de) Date: Sun, 30 Mar 2003 20:11:23 +0200 From: Oliver Lehmann To: Wilko Bulte Message-Id: <20030330201123.1186e026.lehmann@ans-netz.de> In-Reply-To: <20030330180053.GA1421@freebie.xs4all.nl> References: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> <20030330195725.4678d99f.lehmann@ans-netz.de> <20030330180053.GA1421@freebie.xs4all.nl> X-Mailer: Sylpheed version 0.8.11cvs14 (GTK+ 1.2.10; i386-unknown-freebsdelf4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: chrisr@beosppc.org cc: freebsd-alpha@freebsd.org Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 18:11:32 -0000 Wilko Bulte wrote: > > fpa0: port 0x6100-0x617f mem > > IIRC it works on x86 but not on alpha I didn't say anything else ;) Thats why I will plug the card in my alpha if i find some time. Just to see if the panic occurs. -- Oliver Lehmann @home: lehmann@ans-netz.de @office: oliver.lehmann@mgi.de @www: http://www.pofo.de/ | http://wishlist.ans-netz.de/ From owner-freebsd-alpha@FreeBSD.ORG Sun Mar 30 10:40:36 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA5A337B401 for ; Sun, 30 Mar 2003 10:40:36 -0800 (PST) Received: from mail12.atl.registeredsite.com (mail12.atl.registeredsite.com [64.224.219.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB68343FD7 for ; Sun, 30 Mar 2003 10:40:35 -0800 (PST) (envelope-from opalpha@terraflux.com) Received: from terraflux.com ([216.122.242.190])h2UIeYoh022035 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sun, 30 Mar 2003 13:40:35 -0500 Received: from [192.168.0.40] (simon.metroflux.net [63.201.252.211]) by terraflux.com (8.11.6/8.11.0) with ESMTP id h2UIeYt80344 for ; Sun, 30 Mar 2003 10:40:34 -0800 (PST) (envelope-from opalpha@terraflux.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 30 Mar 2003 10:40:32 -0800 From: oliver To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 18:40:37 -0000 From owner-freebsd-alpha@FreeBSD.ORG Sun Mar 30 11:08:05 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FC1837B401 for ; Sun, 30 Mar 2003 11:08:05 -0800 (PST) Received: from mail12.atl.registeredsite.com (mail12.atl.registeredsite.com [64.224.219.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5866343F93 for ; Sun, 30 Mar 2003 11:08:04 -0800 (PST) (envelope-from opalpha@terraflux.com) Received: from terraflux.com ([216.122.242.190])h2UJ80oh005004 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sun, 30 Mar 2003 14:08:03 -0500 Received: from [192.168.0.40] (simon.metroflux.net [63.201.252.211]) by terraflux.com (8.11.6/8.11.0) with ESMTP id h2UJ7wt95058 for ; Sun, 30 Mar 2003 11:07:59 -0800 (PST) (envelope-from opalpha@terraflux.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 30 Mar 2003 11:07:56 -0800 From: oliver To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Ipfw unaligned access fault X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 19:08:08 -0000 Hi there, I hope this is the correct newsgroup for this problem: We have: FreeBSD metroflux.net 5.0-RELEASE-p7 FreeBSD 5.0-RELEASE-p7 #0: Sat Mar 29 22:53:49 PST 2003 opi@metroflux.net:/usr/src/sys/alpha/compile/CARMEN alpha running on a DEC Alpha 1200 (Tincup). After a recent cvsup, the machine seems to reboot every 5-6 hours or so. I included sections from /var/log/messages of two separate occasions: Mar 27 02:00:04 metroflux ntpdate[1009]: step time server 204.123.2.72 offset 3.291332 sec Mar 27 03:04:31 metroflux syslogd: kernel boot file is /boot/kernel/kernel Mar 27 03:04:31 metroflux kernel: Mar 27 03:04:31 metroflux kernel: fatal kernel trap: Mar 27 03:04:31 metroflux kernel: Mar 27 03:04:31 metroflux kernel: trap entry = 0x4 (unaligned access fault) Mar 27 03:04:31 metroflux kernel: cpuid = 0 Mar 27 03:04:31 metroflux kernel: faulting va = 0xfffffc000d1d3b34 Mar 27 03:04:31 metroflux kernel: opcode = 0x2d Mar 27 03:04:31 metroflux kernel: register = 0x9 Mar 27 03:04:31 metroflux kernel: pc = 0xfffffc00004a3640 Mar 27 03:04:31 metroflux kernel: ra = 0xfffffc00004a3614 Mar 27 03:04:31 metroflux kernel: sp = 0xfffffe0014021b70 Mar 27 03:04:31 metroflux kernel: usp = 0x11fffba0 Mar 27 03:04:31 metroflux kernel: curthread = 0xfffffc0027e9b930 Mar 27 03:04:31 metroflux kernel: pid = 1310, comm = ipfw Mar 27 03:04:31 metroflux kernel: Mar 27 03:04:31 metroflux kernel: panic: trap Mar 27 03:04:31 metroflux kernel: cpuid = 0; Mar 27 03:04:31 metroflux kernel: boot() called on cpu#0 Mar 27 03:04:31 metroflux kernel: Mar 27 03:04:31 metroflux kernel: syncing disks, buffers remaining... panic: bdwrite: buffer is not busy Mar 27 03:04:31 metroflux kernel: cpuid = 0; Mar 27 03:04:31 metroflux kernel: boot() called on cpu#0 Mar 27 03:04:31 metroflux kernel: Uptime: 3h59m45s Mar 27 03:04:31 metroflux kernel: Automatic reboot in 15 seconds - press a key on the console to abort Mar 30 03:03:51 metroflux syslogd: kernel boot file is /boot/kernel/kernel Mar 30 03:03:51 metroflux kernel: Mar 30 03:03:51 metroflux kernel: fatal kernel trap: Mar 30 03:03:51 metroflux kernel: Mar 30 03:03:51 metroflux kernel: trap entry = 0x4 (unaligned access fault) Mar 30 03:03:51 metroflux kernel: cpuid = 0 Mar 30 03:03:51 metroflux kernel: faulting va = 0xfffffc0000c30b34 Mar 30 03:03:51 metroflux kernel: opcode = 0x2d Mar 30 03:03:51 metroflux kernel: register = 0x9 Mar 30 03:03:51 metroflux kernel: pc = 0xfffffc00004a9d00 Mar 30 03:03:51 metroflux kernel: ra = 0xfffffc00004a9cd4 Mar 30 03:03:51 metroflux kernel: sp = 0xfffffe0014001b60 Mar 30 03:03:51 metroflux kernel: usp = 0x11fffba0 Mar 30 03:03:51 metroflux kernel: curthread = 0xfffffc00265baf80 Mar 30 03:03:51 metroflux kernel: pid = 1213, comm = ipfw Mar 30 03:03:51 metroflux kernel: Mar 30 03:03:51 metroflux kernel: panic: trap Mar 30 03:03:51 metroflux kernel: cpuid = 0; Mar 30 03:03:51 metroflux kernel: boot() called on cpu#0 Mar 30 03:03:51 metroflux kernel: Mar 30 03:03:51 metroflux kernel: syncing disks, buffers remaining... panic: bremfree: bp 0xfffffe000a827610 not locked Mar 30 03:03:51 metroflux kernel: cpuid = 0; Mar 30 03:03:51 metroflux kernel: boot() called on cpu#0 Mar 30 03:03:51 metroflux kernel: Uptime: 3h36m39s Mar 30 03:03:51 metroflux kernel: Automatic reboot in 15 seconds - press a key on the console to abort Just to be sure I deleted all src, resupped, then recompiled world and kernel (with sanity). Unfortunately, no change in behavior. Also by running ipfw show, I receive the following output (and so on until all rules are listed): 108 10:50am # ipfw show 00100 268 29682 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 pid 1611 (ipfw): unaligned access: va=0x1200ac0b4 pc=0x120001780 ra=0x120001764 op=ldq pid 1611 (ipfw): unaligned access: va=0x1200ac0bc pc=0x120001784 ra=0x120001764 op=ldq 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 0 0 deny ip from any to 10.0.0.0/8 via fxp0 pid 1611 (ipfw): unaligned access: va=0x1200ac154 pc=0x120001780 ra=0x120001764 op=ldq pid 1611 (ipfw): unaligned access: va=0x1200ac15c pc=0x120001784 ra=0x120001764 op=ldq 00500 0 0 deny ip from any to 172.16.0.0/12 via fxp0 00600 0 0 deny ip from any to 192.168.0.0/16 via fxp0 pid 1611 (ipfw): unaligned access: va=0x1200ac20c pc=0x120001780 ra=0x120001764 op=ldq pid 1611 (ipfw): unaligned access: va=0x1200ac214 pc=0x120001784 ra=0x120001764 op=ldq Of course, I would like to resolve this without removing the firewall options from the kernel (assuming this will fix it), hoping someone on this list can shed light on this problem. Thanks, Oliver From owner-freebsd-alpha@FreeBSD.ORG Sun Mar 30 11:46:31 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52C9037B401; Sun, 30 Mar 2003 11:46:31 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id E90B143FB1; Sun, 30 Mar 2003 11:46:30 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id D67EC2A89E; Sun, 30 Mar 2003 11:46:30 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: sos@freebsd.org Date: Sun, 30 Mar 2003 11:46:30 -0800 From: Peter Wemm Message-Id: <20030330194630.D67EC2A89E@canning.wemm.org> cc: alpha@freebsd.org cc: current@freebsd.org Subject: ATA broken on alpha? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 19:46:32 -0000 beast.freebsd.org is panicing at bootup with this: Copyright (c) 1992-2003 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.0-CURRENT #81: Sun Mar 30 07:48:29 PST 2003 root@beast.freebsd.org:/usr/src/sys/alpha/compile/BEAST Preloaded elf kernel "/boot/kernel/kernel" at 0xfffffc0000714000. ST6600 AlphaPC 264DP 833 MHz, 833MHz 8192 byte page size, 2 processors. CPU: EV6 (21264) major=8 minor=0 extensions=0x1307 OSF PAL rev: 0x200370002013e real memory = 2144706560 (2045 MB) avail memory = 2081095680 (1984 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Allocating major#253 to "net" Allocating major#252 to "g_ctl" Allocating major#251 to "pci" tsunami0: <21271 Core Logic chipset> pcib0: <21271 PCI host bus adapter> on tsunami0 pci0: on pcib0 isab0: at device 5.0 on pci0 isa0: on isab0 atapci0: port 0x1300-0x130f,0x3f4-0x3f7,0x1f0-0x1f7 irq 238 at device 5.1 on pci0 fatal kernel trap: trap entry = 0x2 (memory management fault) cpuid = 0 faulting va = 0x0 type = access violation cause = load instructon pc = 0xfffffc000037b0fc ra = 0xfffffc000037b0d0 sp = 0xfffffc000071ba50 usp = 0x0 curthread = 0xfffffc000063d3f8 pid = 0, comm = swapper Stopped at ata_pcisub_probe+0x11c: ldl t0,0(t0) <0x0> db> trace ata_pcisub_probe() at ata_pcisub_probe+0x11c device_probe_child() at device_probe_child+0x114 device_probe_and_attach() at device_probe_and_attach+0x58 bus_generic_attach() at bus_generic_attach+0x28 ata_pci_attach() at ata_pci_attach+0x600 device_probe_and_attach() at device_probe_and_attach+0xc4 bus_generic_attach() at bus_generic_attach+0x28 pci_attach() at pci_attach+0xe0 device_probe_and_attach() at device_probe_and_attach+0xc4 bus_generic_attach() at bus_generic_attach+0x28 device_probe_and_attach() at device_probe_and_attach+0xc4 bus_generic_attach() at bus_generic_attach+0x28 tsunami_attach() at tsunami_attach+0x98 device_probe_and_attach() at device_probe_and_attach+0xc4 root_bus_configure() at root_bus_configure+0x38 configure() at configure+0x40 mi_startup() at mi_startup+0x144 locorestart() at locorestart+0x64 --- root of call graph --- Do you need more details or is that enough of a clue? Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-alpha@FreeBSD.ORG Sun Mar 30 11:56:51 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4FA537B401; Sun, 30 Mar 2003 11:56:51 -0800 (PST) Received: from spider.deepcore.dk (cpe.atm2-0-56339.0x50c6aa0a.abnxx2.customer.tele.dk [80.198.170.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 811C643F85; Sun, 30 Mar 2003 11:56:48 -0800 (PST) (envelope-from sos@spider.deepcore.dk) Received: (from sos@localhost) by spider.deepcore.dk (8.12.8/8.12.8) id h2UJulHN032136; Sun, 30 Mar 2003 21:56:47 +0200 (CEST) (envelope-from sos) From: Soeren Schmidt Message-Id: <200303301956.h2UJulHN032136@spider.deepcore.dk> In-Reply-To: <20030330194630.D67EC2A89E@canning.wemm.org> To: Peter Wemm Date: Sun, 30 Mar 2003 21:56:47 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL98b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 cc: alpha@FreeBSD.ORG cc: current@FreeBSD.ORG cc: sos@FreeBSD.ORG Subject: Re: ATA broken on alpha? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 19:56:53 -0000 It seems Peter Wemm wrote: > Do you need more details or is that enough of a clue? I can see what the problem is, I'll have to look to find the reason... -Søren From owner-freebsd-alpha@FreeBSD.ORG Sun Mar 30 14:02:14 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0A1E37B401 for ; Sun, 30 Mar 2003 14:02:14 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D445543FAF for ; Sun, 30 Mar 2003 14:02:13 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h2UM2DMS028356 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 30 Mar 2003 17:02:13 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h2UM28l25947; Sun, 30 Mar 2003 17:02:08 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16007.26976.112185.428882@grasshopper.cs.duke.edu> Date: Sun, 30 Mar 2003 17:02:08 -0500 (EST) To: oliver In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-alpha@freebsd.org Subject: Re: Ipfw unaligned access fault X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 22:02:15 -0000 oliver writes: > Hi there, > > I hope this is the correct newsgroup for this problem: > Mar 27 03:04:31 metroflux kernel: pc = 0xfffffc00004a3640 > Mar 27 03:04:31 metroflux kernel: ra = 0xfffffc00004a3614 Can you run gdb on the kernel.debug which corresponds to /boot/kernel/kernel, and do: (gdb) l* 0xfffffc00004a3640 (gdb) l* 0xfffffc00004a3614 A stack trace would also be quite useful, but would require you to rebuild your kernel with 'options DDB' Drew From owner-freebsd-alpha@FreeBSD.ORG Sun Mar 30 23:21:55 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 973E137B401 for ; Sun, 30 Mar 2003 23:21:55 -0800 (PST) Received: from mail1.infoeng.flinders.edu.au (infoeng.flinders.edu.au [129.96.1.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43DC043F3F for ; Sun, 30 Mar 2003 23:21:53 -0800 (PST) (envelope-from paul@foo.infoeng.flinders.edu.au) Received: from foo (foo.infoeng.flinders.edu.au [129.96.1.138]) h2V7Lpl00120 for ; Mon, 31 Mar 2003 16:51:51 +0930 (CST) Message-Id: <200303310721.h2V7Lpl00120@mail1.infoeng.flinders.edu.au> X-Mailer: exmh version 2.5 07/16/2001 with nmh-1.0.4 To: freebsd-alpha@freebsd.org X-Message-Flag: Warning: Outlook spreads computer virii Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 Mar 2003 16:51:51 +0930 From: Paul Gardner-Stephen Subject: OSF binary emulation problem X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 07:21:56 -0000 Hi, I am having problems running OSF 4.0 binaries under FreeBSD 5.0-RELEASE on an alpha personal workstation 500au: ~ {16:49} [70] :uname -a FreeBSD cluebat 5.0-RELEASE-p6 FreeBSD 5.0-RELEASE-p6 #0: Mon Mar 24 18:11:18 GMT 2003 root@cluebat:/usr/src/sys/alpha/compile/CLUEBAT alpha If I run almost anything I get: ~ {16:47} [65] :~/trace exception system: exiting due to internal error: out of memory trying to allocate exception system resources Abort (core dumped) I am led to believe that this might be related to a problem with limits. I however, using 'unlimit' has been in vain to date, eg: ~ {16:47} [67] :limits Resource limits (current): cputime infinity secs filesize infinity kb datasize 1048576 kb stacksize 32768 kb coredumpsize-cur 0 kb memoryuse infinity kb memorylocked infinity kb maxprocesses 5547 openfiles 11095 sbsize infinity bytes vmemoryuse infinity kb ~ {16:49} [68] :unlimit ~ {16:49} [69] :~/trace exception system: exiting due to internal error: out of memory trying to allocate exception system resources Abort Any suggestions would be greatly appreciated. Paul. From owner-freebsd-alpha@FreeBSD.ORG Mon Mar 31 02:22:03 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6E3837B401 for ; Mon, 31 Mar 2003 02:22:03 -0800 (PST) Received: from spider.deepcore.dk (cpe.atm2-0-56339.0x50c6aa0a.abnxx2.customer.tele.dk [80.198.170.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB42143F3F for ; Mon, 31 Mar 2003 02:22:01 -0800 (PST) (envelope-from sos@spider.deepcore.dk) Received: (from sos@localhost) by spider.deepcore.dk (8.12.8/8.12.8) id h2VALxZ6000706; Mon, 31 Mar 2003 12:21:59 +0200 (CEST) (envelope-from sos) From: Soeren Schmidt Message-Id: <200303311021.h2VALxZ6000706@spider.deepcore.dk> In-Reply-To: <200303301956.h2UJulHN032136@spider.deepcore.dk> To: Soeren Schmidt Date: Mon, 31 Mar 2003 12:21:59 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL98b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 cc: alpha@FreeBSD.ORG Subject: Re: ATA broken on alpha? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 10:22:05 -0000 It seems Soeren Schmidt wrote: > It seems Peter Wemm wrote: > > > Do you need more details or is that enough of a clue? > > I can see what the problem is, I'll have to look to find the reason... Hmm, must be someting cypress related, could I have the lineno's in ATA that it fails on please ? It doesn't fit anything in my kernel :) -Søren From owner-freebsd-alpha@FreeBSD.ORG Mon Mar 31 05:25:20 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 398D037B401 for ; Mon, 31 Mar 2003 05:25:20 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51E3C43FB1 for ; Mon, 31 Mar 2003 05:25:19 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h2VDPHMS027700 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 31 Mar 2003 08:25:17 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h2VDPCL27148; Mon, 31 Mar 2003 08:25:12 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16008.16824.753151.308099@grasshopper.cs.duke.edu> Date: Mon, 31 Mar 2003 08:25:12 -0500 (EST) To: Paul Gardner-Stephen In-Reply-To: <200303310721.h2V7Lpl00120@mail1.infoeng.flinders.edu.au> References: <200303310721.h2V7Lpl00120@mail1.infoeng.flinders.edu.au> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-alpha@freebsd.org Subject: Re: OSF binary emulation problem X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 13:25:21 -0000 Paul Gardner-Stephen writes: > Hi, > > I am having problems running OSF 4.0 binaries under FreeBSD 5.0-RELEASE on an > alpha personal workstation 500au: Its a bug in 5.0 that only bites SMP kernels (GENERIC is SMP on alpha). This was just fixed Sat. in -currrent. See the freebsd-alpha archives for the patch. Or rebuild a kernel without 'options SMP', or upgrade to -current. Cheers, Drew From owner-freebsd-alpha@FreeBSD.ORG Mon Mar 31 08:18:42 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 935DD37B401 for ; Mon, 31 Mar 2003 08:18:42 -0800 (PST) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [80.86.187.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 173CE43FBD for ; Mon, 31 Mar 2003 08:18:41 -0800 (PST) (envelope-from lehmann@ans-netz.de) Received: (qmail 92621 invoked from network); 31 Mar 2003 16:18:36 -0000 Received: from unknown (HELO dill.salatschuessel.net) (217.226.27.207) by avocado.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 31 Mar 2003 16:18:36 -0000 Received: (qmail 907 invoked from network); 31 Mar 2003 16:18:37 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (10.0.1.51) by dill.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 31 Mar 2003 16:18:37 -0000 Received: from kartoffel.salatschuessel.net (localhost [127.0.0.1]) h2VGIaJG003832 for ; Mon, 31 Mar 2003 18:18:37 +0200 (CEST) (envelope-from lehmann@ans-netz.de) Date: Mon, 31 Mar 2003 18:18:36 +0200 From: Oliver Lehmann To: freebsd-alpha@freebsd.org Message-Id: <20030331181836.0c9b67d0.lehmann@ans-netz.de> In-Reply-To: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> References: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> X-Mailer: Sylpheed version 0.8.11cvs14 (GTK+ 1.2.10; i386-unknown-freebsdelf4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 16:18:50 -0000 Same here: *** keyboard not plugged in... halted CPU 0 halt code = 5 HALT instruction executed PC = fffffc000051fee0 *** no timer interrupts on CPU 0 *** CPU 0 booting Resetting I/O buses... *** keyboard not plugged in... (boot dka0.0.0.5.0) block 0 of dka0.0.0.5.0 is a valid boot block reading 15 blocks from dka0.0.0.5.0 bootstrap code read in base = 200000, image_start = 0, image_bytes = 1e00 initializing HWRPB at 2000 initializing page table at 2ffec000 initializing machine state setting affinity to the primary CPU jumping to bootstrap code Loading /boot/loader Console: SRM firmware console VMS PAL rev: 0x1000200010115 OSF PAL rev: 0x1000200020117 Switch to OSF PAL code succeeded. FreeBSD/alpha SRM disk boot, Revision 1.2 (olivleh1@dill.salatschuessel.net, Sun Mar 23 19:14:47 CET 2003) Memory: 786432 k Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x2c7630+0x53140 syms=[0x8+0x474c0+0x8+0x36fdf] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Entering /boot/kernel/kernel at 0xfffffc0000330de0... Copyright (c) 1992-2003 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.0-RELEASE-p6 #1: Mon Mar 31 16:17:19 CEST 2003 olivleh1@dill.salatschuessel.net:/usr/obj/usr/src/sys/DILL Preloaded elf kernel "/boot/kernel/kernel" at 0xfffffc000069c000. EB164 Digital AlphaPC 164LX 599 MHz, 598MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=2 extensions=0x1 OSF PAL rev: 0x1000200020117 real memory = 803119104 (765 MB) avail memory = 775102464 (739 MB) Initializing GEOMetry subsystem cia0: <2117x Core Logic chipset> cia0: Pyxis, pass 1 cia0: extended capabilities: 1 pcib0: <2117x PCI host bus adapter> on cia0 pci0: on pcib0 sym0: <895> port 0x10000-0x100ff mem 0x82040000-0x82040fff,0x82041000-0x820410ff irq 2 at device 5.0 on pci0 sym0: Tekram NVRAM, ID 7, Fast-40, SE, parity checking sym0: interrupting at CIA irq 2 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x10100-0x1017f mem 0x82041100-0x8204117f irq 0 at device 6.0 on pci0 xl0: interrupting at CIA irq 0 xl0: Ethernet address: 00:01:02:b4:75:9e miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 8.0 on pci0 isa0: on isab0 fpa0: port 0x10180-0x101ff mem 0x82030000-0x8203ffff,0x82041180-0x820411ff irq 3 at device 9.0 on pci0 unexpected machine check: mces = 0x1 vector = 0x660 param = 0xfffffc0000006068 pc = 0xfffffc00005186c4 ra = 0xfffffc000038ff2c curproc = 0xfffffc00005d6bc8 pid = 0, comm = swapper panic: machine check Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... -- Oliver Lehmann @home: lehmann@ans-netz.de @office: oliver.lehmann@mgi.de @www: http://www.pofo.de/ | http://wishlist.ans-netz.de/ From owner-freebsd-alpha@FreeBSD.ORG Mon Mar 31 08:35:54 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76C8337B404 for ; Mon, 31 Mar 2003 08:35:54 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D91EA43FB1 for ; Mon, 31 Mar 2003 08:35:52 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h2VGZoMS015999 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 31 Mar 2003 11:35:50 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h2VGZjX27317; Mon, 31 Mar 2003 11:35:45 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16008.28257.658768.820352@grasshopper.cs.duke.edu> Date: Mon, 31 Mar 2003 11:35:45 -0500 (EST) To: Oliver Lehmann In-Reply-To: <20030331181836.0c9b67d0.lehmann@ans-netz.de> References: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> <20030331181836.0c9b67d0.lehmann@ans-netz.de> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-alpha@freebsd.org Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 16:35:56 -0000 Oliver Lehmann writes: > pc = 0xfffffc00005186c4 > ra = 0xfffffc000038ff2c If you can map the pc and ra to source code using gdb, we might be able to debug this.. gdb kernel.debug (gdb) l *0xfffffc00005186c4 (gdb) l *0xfffffc000038ff2c Drew From owner-freebsd-alpha@FreeBSD.ORG Mon Mar 31 10:05:58 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CD2537B401; Mon, 31 Mar 2003 10:05:58 -0800 (PST) Received: from gatekeeper.oremut01.us.wh.verio.net (gatekeeper.oremut01.us.wh.verio.net [198.65.168.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id D52F743F93; Mon, 31 Mar 2003 10:05:57 -0800 (PST) (envelope-from fclift@verio.net) Received: from mx.dmz.orem.verio.net (mx.dmz.orem.verio.net [10.1.1.10]) by gatekeeper.oremut01.us.wh.verio.net (Postfix) with ESMTP id 9114B3BF134; Mon, 31 Mar 2003 11:05:57 -0700 (MST) Received: from vespa.dmz.orem.verio.net (vespa.dmz.orem.verio.net [10.1.1.59]) by mx.dmz.orem.verio.net (8.11.6p2/8.11.6) with ESMTP id h2VI5vA06591; Mon, 31 Mar 2003 11:05:57 -0700 (MST) Date: Mon, 31 Mar 2003 11:08:46 -0700 (MST) From: Fred Clift X-X-Sender: To: "David O'Brien" In-Reply-To: <20030329211839.GE37614@dragon.nuxi.com> Message-ID: <20030331110729.P76254-100000@vespa.dmz.orem.verio.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: alpha@freebsd.org Subject: Re: HEADS UP: Don't upgrade your Alphas! X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 18:05:59 -0000 On Sat, 29 Mar 2003, David O'Brien wrote: > Uh... show me your FSF GCC committable patches please. You're boarder > line insulting me here, so do not offer anymore suggestions w/o some code > to back it up. No offense intended - I understand that sometimes things are more complicated than they appear. I've been 'busy' all weekend, but perhaps I will take a peek at the code since now you've got me interested :). Fred -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. From owner-freebsd-alpha@FreeBSD.ORG Mon Mar 31 11:30:13 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CD7037B401 for ; Mon, 31 Mar 2003 11:30:13 -0800 (PST) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [80.86.187.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74A0A43FB1 for ; Mon, 31 Mar 2003 11:30:11 -0800 (PST) (envelope-from lehmann@ans-netz.de) Received: (qmail 96328 invoked from network); 31 Mar 2003 19:30:06 -0000 Received: from unknown (HELO dill.salatschuessel.net) (217.226.27.207) by avocado.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 31 Mar 2003 19:30:06 -0000 Received: (qmail 624 invoked from network); 31 Mar 2003 19:30:07 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (10.0.1.51) by dill.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 31 Mar 2003 19:30:07 -0000 Received: from kartoffel.salatschuessel.net (localhost [127.0.0.1]) h2VJU3JG004172; Mon, 31 Mar 2003 21:30:06 +0200 (CEST) (envelope-from lehmann@ans-netz.de) Date: Mon, 31 Mar 2003 21:30:03 +0200 From: Oliver Lehmann To: Andrew Gallatin Message-Id: <20030331213003.4e67d88f.lehmann@ans-netz.de> In-Reply-To: <16008.28257.658768.820352@grasshopper.cs.duke.edu> References: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> <20030331181836.0c9b67d0.lehmann@ans-netz.de> <16008.28257.658768.820352@grasshopper.cs.duke.edu> X-Mailer: Sylpheed version 0.8.11cvs14 (GTK+ 1.2.10; i386-unknown-freebsdelf4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-alpha@freebsd.org Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 19:30:15 -0000 Hiho, here we go: *** keyboard not plugged in... ff.fe.fd.fc.fb.fa.f9.f8.f7.f6.f5.f3.f2.f1.f0. ef.ee.ed.probing hose 0, PCI probing PCI-to-ISA bridge, bus 1 bus 0, slot 5 -- pka -- NCR 53C895 bus 0, slot 9 -- fwa -- DEC PCI FDDI bus 0, slot 11 -- dqa -- CMD PCI0646 IDE bus 0, slot 11 -- dqb -- CMD PCI0646 IDE ec.f4.eb.ea.e9.e8.e7. Digital AlphaPC 164LX 599 MHz Console V5.8-1, Jun 21 2000 11:28:32 CPU 0 booting (boot dka0.0.0.5.0) block 0 of dka0.0.0.5.0 is a valid boot block reading 15 blocks from dka0.0.0.5.0 bootstrap code read in base = 200000, image_start = 0, image_bytes = 1e00 initializing HWRPB at 2000 initializing page table at 1ffee000 initializing machine state setting affinity to the primary CPU jumping to bootstrap code Loading /boot/loader *** no timer interrupts on CPU 0 *** Console: SRM firmware console VMS PAL rev: 0x1000200010115 OSF PAL rev: 0x1000200020117 Switch to OSF PAL code succeeded. FreeBSD/alpha SRM disk boot, Revision 1.2 (olivleh1@dill.salatschuessel.net, Sun Mar 23 19:14:47 CET 2003) Memory: 262144 k Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x2ebbe0+0x56af0 syms=[0x8+0x48c00+0x8+0x38573] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 6 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK boot -v Entering /boot/kernel/kernel at 0xfffffc0000336520... sio1: gdb debugging port Copyright (c) 1992-2003 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.0-RELEASE-p6 #3: Mon Mar 31 20:02:01 CEST 2003 olivleh1@dill.salatschuessel.net:/usr/obj/usr/src/sys/DILL Preloaded elf kernel "/boot/kernel/kernel" at 0xfffffc00006c6000. EB164 Digital AlphaPC 164LX 599 MHz, 598MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=2 extensions=0x1 OSF PAL rev: 0x1000200020117 real memory = 266256384 (253 MB) Physical memory chunk(s): 0x006e8000 - 0x0ffe3fff, 261079040 bytes (31870 pages) avail memory = 252870656 (241 MB) Initializing GEOMetry subsystem random: null: mem: cia0: <2117x Core Logic chipset> cia0: Pyxis, pass 1 cia0: extended capabilities: 1 pcib0: <2117x PCI host bus adapter> on cia0 pci0: on pcib0 pci0: physical bus=0 map[10]: type 4, range 32, base 00010000, size 8, enabled map[14]: type 1, range 32, base 82041000, size 8, enabled map[18]: type 1, range 32, base 82040000, size 12, enabled found-> vendor=0x1000, dev=0x000c, revid=0x01 bus=0, slot=5, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x1e (7500 ns), maxlat=0x40 (16000 ns) intpin=a, irq=2 map[10]: type 4, range 32, base 00010100, size 7, enabled map[14]: type 1, range 32, base 82041100, size 7, enabled found-> vendor=0x10b7, dev=0x9200, revid=0x74 bus=0, slot=6, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0a (2500 ns), maxlat=0x0a (2500 ns) intpin=a, irq=0 powerspec 2 supports D0 D1 D2 D3 current D0 found-> vendor=0x8086, dev=0x0484, revid=0x43 bus=0, slot=8, func=0 class=00-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base 82041180, size 7, enabled map[14]: type 4, range 32, base 00010180, size 7, enabled map[18]: type 1, range 32, base 82030000, size 16, enabled found-> vendor=0x1011, dev=0x000f, revid=0x00 bus=0, slot=9, func=0 class=02-02-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 map[20]: type 4, range 32, base 00010210, size 4, enabled found-> vendor=0x1095, dev=0x0646, revid=0x01 bus=0, slot=11, func=0 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=5 sym0: <895> port 0x10000-0x100ff mem 0x82040000-0x82040fff,0x82041000-0x820410ff irq 2 at device 5.0 on pci0 sym0: Delay (GEN=11): 240 msec, 37034 KHz sym0: Delay (GEN=11): 231 msec, 38477 KHz sym0: Delay (GEN=11): 230 msec, 38644 KHz sym0: chip clock is 38477KHz sym0: clock multiplier assumed sym0: Tekram NVRAM, ID 7, Fast-40, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/00/00/00/00/00 sym0: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 07/4e/80/01/08/24 sym0: Delay (GEN=11): 289 msec, 30755 KHz sym0: Delay (GEN=11): 286 msec, 31078 KHz sym0: Delay (GEN=11): 285 msec, 31187 KHz sym0: interrupting at CIA irq 2 sym0: enabling clock multiplier sym0: Downloading SCSI SCRIPTS. xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x10100-0x1017f mem 0x82041100-0x8204117f irq 0 at device 6.0 on pci0 xl0: interrupting at CIA irq 0 xl0: Ethernet address: 00:01:02:b4:75:9e xl0: media options word: a xl0: found MII/AUTO miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached PCI-ISA bridge with incorrect subclass 0x0 PCI-ISA bridge with incorrect subclass 0x0 isab0: at device 8.0 on pci0 isa0: on isab0 fpa0: port 0x10180-0x101ff mem 0x82030000-0x8203ffff,0x82041180-0x820411ff irq 3 at device 9.0 on pci0 unexpected machine check: mces = 0x1 vector = 0x660 param = 0xfffffc0000006068 pc = 0xfffffc0000530d84 ra = 0xfffffc000039b51c curproc = 0xfffffc00005fdaf8 pid = 0, comm = swapper Stopped at DELAY+0x30: rpcc t0 db> show reg v0 0x20411ac t0 0x257 intr_n+0x216 t1 0 t2 0xfb intr_n+0xba t3 0 t4 0x3b627560 t5 0x3b627552 t6 0x100000000 t7 0xfffffc00006ce000 s0 0 s1 0x3 s2 0xfffffc000075fab8 s3 0xfffffc000075f000 s4 0xfffffc000075f000 s5 0 s6 0xffffffff82041180 a0 0x3e8 intr_n+0x3a7 a1 0x20411ac a2 0x1 a3 0x1 a4 0x1 a5 0xfffffc00006cd940 t8 0xfffffc00005ed170 cycles_per_usec t9 0xfffffc0000522028 uma_dbg_alloc+0x68 t10 0 t11 0x2000 intr_n+0x1fbf ra 0xfffffc000039b51c pdq_stop+0x52c t12 0xfffffc0000530d30 DELAY at 0x20001ff8 gp 0xfffffc00005eebe0 db_lhistory+0x460 sp 0xfffffc00006cdac0 pc 0xfffffc0000530d84 DELAY+0x54 ps 0x6 ai 0x2000 intr_n+0x1fbf pv 0xfffffc0000530d30 DELAY DELAY+0x54: cmpule t2,t0,t0 db> ps pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 20 fffffc000f81bb00 fffffe000a424000 0 0 0 0000204 new [IWAIT] intr: xl0 19 fffffc000f87c000 fffffe000b7e6000 0 0 0 0000204 new [IWAIT] intr: sym0 18 fffffc000f87c300 fffffe000b7e8000 0 0 0 0000204 new [IWAIT] swi5: task queue 17 fffffc000f87c600 fffffe000b7ea000 0 0 0 0000204 new [IWAIT] swi3: cambio 16 fffffc000f7cc000 fffffe000a2de000 0 0 0 0000204 new [IWAIT] swi2: camnet 15 fffffc000f7cc300 fffffe000a3a0000 0 0 0 0000204 new [RUNQ] random ffc000f7ccc00 fffffe000a3a6000 0 0 0 0000204 new [RUNQ] g_event 14 fffffc000f7ccf00 fffffe000a3a8000 0 0 0 0000204 new [IWAIT] swi1: net 13 fffffc000f7cd200 fffffe000a3aa000 0 0 0 0000204 new [IWAIT] swi4: vm 12 fffffc000f7cd500 fffffe000a3ac000 0 0 0 000020c new [IWAIT] swi6: clock 11 fffffc000f7cd800 fffffe000a3ae000 0 0 0 000020c norm[Can run] idle 1 fffffc000f7cdb00 fffffe000a3b0000 0 0 0 0000200 newpanic: unknown thread state panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 db> continue Uptime: 1s panic: Assertion mtx_unowned(m) failed at /usr/src/sys/kern/kern_mutex.c:956 panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 db> call boot(0) Uptime: 1s panic: _sx_xlock (shutdown_final): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:367 panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 db> call cpu_reset() but why i got no crash-dump? After the shutdown, i removed the fddi card, and booted again: [...] Checking for core dump... savecore: no dumps found [...] hrm... what did i wrong in db? root@dill /root> gdb -k /boot/kernel/kernel.debug GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "alpha-undermydesk-freebsd"... (kgdb) l *0xfffffc0000530d84 0xfffffc0000530d84 is in DELAY (/usr/src/sys/alpha/alpha/machdep.c:1123). 1118 * last checked. Add the current cycle count to the 1119 * running total. If it's over cycles_per_usec, increment 1120 * the usec counter. 1121 */ 1122 cycles += curcycle; 1123 while (cycles > cycles_per_usec) { 1124 usec++; 1125 cycles -= cycles_per_usec; 1126 } 1127 pcc0 = pcc1; (kgdb) l *0xfffffc000039b51c 0xfffffc000039b51c is in pdq_stop (/usr/src/sys/dev/pdq/pdq.c:1327). 1322 for (cnt = 0; cnt < 1000; cnt++) { 1323 PDQ_OS_CONSUMER_POSTSYNC(pdq); 1324 pdq_process_command_responses(pdq); 1325 if (pdq->pdq_command_info.ci_response_producer == pdq->pdq_command_info.ci_response_completion) 1326 break; 1327 PDQ_OS_USEC_DELAY(1000); 1328 } 1329 state = PDQ_PSTS_ADAPTER_STATE(PDQ_CSR_READ(csrs, csr_port_status)); 1330 } 1331 (kgdb) Greetings, Oliver PS: yes, i disabled the 74-chars warp for this mail...Andrew Gallatin wrote: -- Oliver Lehmann @home: lehmann@ans-netz.de @office: oliver.lehmann@mgi.de @www: http://www.pofo.de/ | http://wishlist.ans-netz.de/ From owner-freebsd-alpha@FreeBSD.ORG Mon Mar 31 12:01:54 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D892137B401 for ; Mon, 31 Mar 2003 12:01:54 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0682F43FBF for ; Mon, 31 Mar 2003 12:01:54 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h2VK1qMS004996 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 31 Mar 2003 15:01:52 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h2VK1ld27516; Mon, 31 Mar 2003 15:01:47 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16008.40619.177277.973890@grasshopper.cs.duke.edu> Date: Mon, 31 Mar 2003 15:01:47 -0500 (EST) To: Oliver Lehmann In-Reply-To: <20030331213003.4e67d88f.lehmann@ans-netz.de> References: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> <20030331181836.0c9b67d0.lehmann@ans-netz.de> <16008.28257.658768.820352@grasshopper.cs.duke.edu> <20030331213003.4e67d88f.lehmann@ans-netz.de> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-alpha@freebsd.org Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2003 20:01:56 -0000 Oliver Lehmann writes: > > but why i got no crash-dump? crashdumps are hit or miss in -current. Besides, you've not finished booting yet, so the dump device might not have gotten set. > (kgdb) l *0xfffffc000039b51c > 0xfffffc000039b51c is in pdq_stop (/usr/src/sys/dev/pdq/pdq.c:1327). > 1322 for (cnt = 0; cnt < 1000; cnt++) { > 1323 PDQ_OS_CONSUMER_POSTSYNC(pdq); > 1324 pdq_process_command_responses(pdq); > 1325 if (pdq->pdq_command_info.ci_response_producer == pdq->pdq_command_info.ci_response_completion) > 1326 break; > 1327 PDQ_OS_USEC_DELAY(1000); > 1328 } > 1329 state = PDQ_PSTS_ADAPTER_STATE(PDQ_CSR_READ(csrs, csr_port_status)); > 1330 } > 1331 > (kgdb) Probably something in pdq_process_command_responses(). Maybe its accessing PCI mem directly w/going through busspace accessors. Either that, or the device initiated a bad dma... Can you try the following patch & see if it helps? Drew Index: if_fpa.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pdq/if_fpa.c,v retrieving revision 1.17 diff -u -r1.17 if_fpa.c --- if_fpa.c 2 Jun 2002 20:05:45 -0000 1.17 +++ if_fpa.c 31 Mar 2003 20:00:17 -0000 @@ -144,7 +144,7 @@ sc->mem_rid = PCI_CBMA; sc->mem_type = SYS_RES_MEMORY; sc->mem = bus_alloc_resource(dev, sc->mem_type, &sc->mem_rid, - 0, ~0, 1, RF_ACTIVE); + 0, ~0, 1, RF_ACTIVE | PCI_RF_DENSE); if (!sc->mem) { device_printf(dev, "Unable to allocate I/O space resource.\n"); error = ENXIO; From owner-freebsd-alpha@FreeBSD.ORG Mon Mar 31 18:56:11 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6607837B401 for ; Mon, 31 Mar 2003 18:56:11 -0800 (PST) Received: from mail1.infoeng.flinders.edu.au (infoeng.flinders.edu.au [129.96.1.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7515A43FBD for ; Mon, 31 Mar 2003 18:56:09 -0800 (PST) (envelope-from paul@foo.infoeng.flinders.edu.au) Received: from foo (foo.infoeng.flinders.edu.au [129.96.1.138]) h312u3l16467; Tue, 1 Apr 2003 12:26:03 +0930 (CST) Message-Id: <200304010256.h312u3l16467@mail1.infoeng.flinders.edu.au> X-Mailer: exmh version 2.5 07/16/2001 with nmh-1.0.4 To: Andrew Gallatin In-Reply-To: Your message of "Mon, 31 Mar 2003 08:25:12 EST." <16008.16824.753151.308099@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Apr 2003 12:26:03 +0930 From: Paul Gardner-Stephen cc: freebsd-alpha@freebsd.org Subject: Re: OSF binary emulation problem X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 02:56:11 -0000 > > I am having problems running OSF 4.0 binaries under FreeBSD 5.0-RELEASE on > > an alpha personal workstation 500au: > > Its a bug in 5.0 that only bites SMP kernels (GENERIC is SMP on > alpha). This was just fixed Sat. in -currrent. See the freebsd-alpha > archives for the patch. Or rebuild a kernel without 'options SMP', or > upgrade to -current. Thanks, I'll start by compiling without SMP and let you know how I go. Paul. From owner-freebsd-alpha@FreeBSD.ORG Mon Mar 31 20:22:44 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E50E37B401 for ; Mon, 31 Mar 2003 20:22:44 -0800 (PST) Received: from mail1.infoeng.flinders.edu.au (infoeng.flinders.edu.au [129.96.1.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12D0A43FA3 for ; Mon, 31 Mar 2003 20:22:43 -0800 (PST) (envelope-from paul@foo.infoeng.flinders.edu.au) Received: from foo (foo.infoeng.flinders.edu.au [129.96.1.138]) h314Mal19098; Tue, 1 Apr 2003 13:52:36 +0930 (CST) Message-Id: <200304010422.h314Mal19098@mail1.infoeng.flinders.edu.au> X-Mailer: exmh version 2.5 07/16/2001 with nmh-1.0.4 To: Andrew Gallatin In-Reply-To: Your message of "Mon, 31 Mar 2003 08:25:12 EST." <16008.16824.753151.308099@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Apr 2003 13:52:36 +0930 From: Paul Gardner-Stephen cc: freebsd-alpha@freebsd.org Subject: Re: OSF binary emulation problem X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 04:22:44 -0000 Hi Andres, > Its a bug in 5.0 that only bites SMP kernels (GENERIC is SMP on > alpha). This was just fixed Sat. in -currrent. See the freebsd-alpha > archives for the patch. Or rebuild a kernel without 'options SMP', or > upgrade to -current. All is working now. Thanks for the tip. matlab 5 is now running fine, including GUI. Now to get mathematica running... Paul. From owner-freebsd-alpha@FreeBSD.ORG Mon Mar 31 21:18:59 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F5AF37B404 for ; Mon, 31 Mar 2003 21:18:59 -0800 (PST) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [80.86.187.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDA9D43F75 for ; Mon, 31 Mar 2003 21:18:57 -0800 (PST) (envelope-from lehmann@ans-netz.de) Received: (qmail 7941 invoked from network); 1 Apr 2003 05:18:52 -0000 Received: from unknown (HELO dill.salatschuessel.net) (217.226.27.207) by avocado.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 1 Apr 2003 05:18:52 -0000 Received: (qmail 1684 invoked from network); 1 Apr 2003 05:18:54 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (10.0.1.51) by dill.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 1 Apr 2003 05:18:54 -0000 Received: from kartoffel.salatschuessel.net (localhost [127.0.0.1]) h2VLZ9JG004361; Mon, 31 Mar 2003 23:35:10 +0200 (CEST) (envelope-from lehmann@ans-netz.de) Date: Mon, 31 Mar 2003 23:35:09 +0200 From: Oliver Lehmann To: Andrew Gallatin Message-Id: <20030331233509.21ba9cce.lehmann@ans-netz.de> In-Reply-To: <16008.40619.177277.973890@grasshopper.cs.duke.edu> References: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> <20030331181836.0c9b67d0.lehmann@ans-netz.de> <16008.28257.658768.820352@grasshopper.cs.duke.edu> <20030331213003.4e67d88f.lehmann@ans-netz.de> <16008.40619.177277.973890@grasshopper.cs.duke.edu> X-Mailer: Sylpheed version 0.8.11cvs14 (GTK+ 1.2.10; i386-unknown-freebsdelf4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-alpha@freebsd.org Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 05:18:59 -0000 Andrew Gallatin wrote: > Probably something in pdq_process_command_responses(). > Maybe its accessing PCI mem directly w/going through busspace > accessors. > > Either that, or the device initiated a bad dma... > > Can you try the following patch & see if it helps? > > Drew > > > Index: if_fpa.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/pdq/if_fpa.c,v > retrieving revision 1.17 > diff -u -r1.17 if_fpa.c > --- if_fpa.c 2 Jun 2002 20:05:45 -0000 1.17 > +++ if_fpa.c 31 Mar 2003 20:00:17 -0000 > @@ -144,7 +144,7 @@ > sc->mem_rid = PCI_CBMA; > sc->mem_type = SYS_RES_MEMORY; > sc->mem = bus_alloc_resource(dev, sc->mem_type, &sc->mem_rid, > - 0, ~0, 1, RF_ACTIVE); > + 0, ~0, 1, RF_ACTIVE | PCI_RF_DENSE); > if (!sc->mem) { > device_printf(dev, "Unable to allocate I/O space resource.\n"); > error = ENXIO; > > Still the same problem: fpa0: port 0x10180-0x101ff mem 0x82030000-0x8203ffff,0x82041180-0x820411ff irq 3 at device 9.0 on pci0 unexpected machine check: mces = 0x1 vector = 0x660 param = 0xfffffc0000006068 pc = 0xfffffc0000530d80 ra = 0xfffffc000039b51c curproc = 0xfffffc00005fdaf8 pid = 0, comm = swapper Stopped at DELAY+0x50: ldq -- Oliver Lehmann @home: lehmann@ans-netz.de @office: oliver.lehmann@mgi.de @www: http://www.pofo.de/ | http://wishlist.ans-netz.de/ From owner-freebsd-alpha@FreeBSD.ORG Mon Mar 31 21:22:45 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1287C37B401 for ; Mon, 31 Mar 2003 21:22:45 -0800 (PST) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [80.86.187.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4F4C43FCB for ; Mon, 31 Mar 2003 21:22:43 -0800 (PST) (envelope-from lehmann@ans-netz.de) Received: (qmail 8045 invoked from network); 1 Apr 2003 05:22:39 -0000 Received: from unknown (HELO dill.salatschuessel.net) (217.226.27.207) by avocado.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 1 Apr 2003 05:22:39 -0000 Received: (qmail 1729 invoked from network); 1 Apr 2003 05:22:41 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (10.0.1.51) by dill.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 1 Apr 2003 05:22:41 -0000 Received: from kartoffel.salatschuessel.net (localhost [127.0.0.1]) h315MaJG005042; Tue, 1 Apr 2003 07:22:41 +0200 (CEST) (envelope-from lehmann@ans-netz.de) Date: Tue, 1 Apr 2003 07:22:36 +0200 From: Oliver Lehmann To: Andrew Gallatin Message-Id: <20030401072236.37350d34.lehmann@ans-netz.de> X-Mailer: Sylpheed version 0.8.11cvs14 (GTK+ 1.2.10; i386-unknown-freebsdelf4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-alpha@freebsd.org Subject: Fw: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 05:22:45 -0000 Andrew Gallatin wrote: > Probably something in pdq_process_command_responses(). > Maybe its accessing PCI mem directly w/going through busspace > accessors. > > Either that, or the device initiated a bad dma... > > Can you try the following patch & see if it helps? > > Drew > > > Index: if_fpa.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/pdq/if_fpa.c,v > retrieving revision 1.17 > diff -u -r1.17 if_fpa.c > --- if_fpa.c 2 Jun 2002 20:05:45 -0000 1.17 > +++ if_fpa.c 31 Mar 2003 20:00:17 -0000 > @@ -144,7 +144,7 @@ > sc->mem_rid = PCI_CBMA; > sc->mem_type = SYS_RES_MEMORY; > sc->mem = bus_alloc_resource(dev, sc->mem_type, &sc->mem_rid, > - 0, ~0, 1, RF_ACTIVE); > + 0, ~0, 1, RF_ACTIVE | PCI_RF_DENSE); > if (!sc->mem) { > device_printf(dev, "Unable to allocate I/O space resource.\n"); > error = ENXIO; > > Still the same problem: fpa0: port 0x10180-0x101ff mem 0x82030000-0x8203ffff,0x82041180-0x820411ff irq 3 at device 9.0 on pci0 unexpected machine check: mces = 0x1 vector = 0x660 param = 0xfffffc0000006068 pc = 0xfffffc0000530d80 ra = 0xfffffc000039b51c curproc = 0xfffffc00005fdaf8 pid = 0, comm = swapper Stopped at DELAY+0x50: ldq -- Oliver Lehmann @home: lehmann@ans-netz.de @office: oliver.lehmann@mgi.de @www: http://www.pofo.de/ | http://wishlist.ans-netz.de/ From owner-freebsd-alpha@FreeBSD.ORG Tue Apr 1 03:58:04 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30FF937B401 for ; Tue, 1 Apr 2003 03:58:04 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id F06BD43F85 for ; Tue, 1 Apr 2003 03:58:02 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id C52EC2ED412; Tue, 1 Apr 2003 03:58:02 -0800 (PST) Date: Tue, 1 Apr 2003 13:58:02 +0200 From: Maxime Henrion To: alpha@freebsd.org Message-ID: <20030401115802.GB1750@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dTy3Mrz/UPE2dbVg" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: call for testers: busdma-ified fxp(4) driver X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 11:58:04 -0000 --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, My fxp(4) patch should now be nearly commit ready. It has been tested successfully on ia64, and also works on x86. It would be of a great help if someone with an alpha box and a fxp(4) card could test this patch since I lack the necessary hardware. I'm attaching the patch to this mail. Thanks in advance, Maxime --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="if_fxp.patch" --- //depot/vendor/freebsd/src/sys/dev/fxp/if_fxp.c 2003/03/08 13:45:18 +++ //depot/user/mux/busdma/dev/fxp/if_fxp.c 2003/03/31 16:07:31 @@ -35,7 +35,6 @@ #include #include #include -#include /* #include */ #include #include @@ -55,8 +54,6 @@ #include #include -#include /* for vtophys */ -#include /* for vtophys */ #include /* for DELAY */ #include @@ -194,7 +191,8 @@ static int fxp_ioctl(struct ifnet *ifp, u_long command, caddr_t data); static void fxp_watchdog(struct ifnet *ifp); -static int fxp_add_rfabuf(struct fxp_softc *sc, struct mbuf *oldm); +static int fxp_add_rfabuf(struct fxp_softc *sc, + struct fxp_rx *rxp); static int fxp_mc_addrs(struct fxp_softc *sc); static void fxp_mc_setup(struct fxp_softc *sc); static u_int16_t fxp_eeprom_getword(struct fxp_softc *sc, int offset, @@ -363,12 +361,26 @@ #endif } +static void +fxp_dma_map_addr(void *arg, bus_dma_segment_t *segs, int nseg, int error) +{ + u_int32_t *addr; + + if (error) + return; + + KASSERT(nseg == 1, ("too many DMA segments, %d should be 1", nseg)); + addr = arg; + *addr = segs->ds_addr; +} + static int fxp_attach(device_t dev) { int error = 0; struct fxp_softc *sc = device_get_softc(dev); struct ifnet *ifp; + struct fxp_rx *rxp; u_int32_t val; u_int16_t data; int i, rid, m1, m2, prefer_iomap; @@ -461,29 +473,6 @@ CSR_WRITE_4(sc, FXP_CSR_PORT, FXP_PORT_SELECTIVE_RESET); DELAY(10); - sc->cbl_base = malloc(sizeof(struct fxp_cb_tx) * FXP_NTXCB, - M_DEVBUF, M_NOWAIT | M_ZERO); - if (sc->cbl_base == NULL) - goto failmem; - - sc->fxp_stats = malloc(sizeof(struct fxp_stats), M_DEVBUF, - M_NOWAIT | M_ZERO); - if (sc->fxp_stats == NULL) - goto failmem; - - sc->mcsp = malloc(sizeof(struct fxp_cb_mcs), M_DEVBUF, M_NOWAIT); - if (sc->mcsp == NULL) - goto failmem; - - /* - * Pre-allocate our receive buffers. - */ - for (i = 0; i < FXP_NRFABUFS; i++) { - if (fxp_add_rfabuf(sc, NULL) != 0) { - goto failmem; - } - } - /* * Find out how large of an SEEPROM we have. */ @@ -617,6 +606,112 @@ } /* + * Allocate DMA tags and DMA safe memory. + */ + error = bus_dma_tag_create(NULL, 2, 0, BUS_SPACE_MAXADDR_32BIT, + BUS_SPACE_MAXADDR, NULL, NULL, MCLBYTES, + sc->flags & FXP_FLAG_EXT_RFA ? FXP_NTXSEG - 1 : FXP_NTXSEG, + BUS_SPACE_MAXSIZE_32BIT, 0, &sc->fxp_mtag); + if (error) { + device_printf(dev, "could not allocate dma tag\n"); + goto fail; + } + + error = bus_dma_tag_create(NULL, 4, 0, BUS_SPACE_MAXADDR_32BIT, + BUS_SPACE_MAXADDR, NULL, NULL, sizeof(struct fxp_stats), 1, + BUS_SPACE_MAXSIZE_32BIT, 0, &sc->fxp_stag); + if (error) { + device_printf(dev, "could not allocate dma tag\n"); + goto fail; + } + + error = bus_dmamem_alloc(sc->fxp_stag, (void **)&sc->fxp_stats, + BUS_DMA_NOWAIT, &sc->fxp_smap); + if (error) + goto failmem; + error = bus_dmamap_load(sc->fxp_stag, sc->fxp_smap, sc->fxp_stats, + sizeof(struct fxp_stats), fxp_dma_map_addr, &sc->stats_addr, 0); + if (error) { + device_printf(dev, "could not map the stats buffer\n"); + goto fail; + } + bzero(sc->fxp_stats, sizeof(struct fxp_stats)); + + error = bus_dma_tag_create(NULL, 4, 0, BUS_SPACE_MAXADDR_32BIT, + BUS_SPACE_MAXADDR, NULL, NULL, FXP_TXCB_SZ, 1, + BUS_SPACE_MAXSIZE_32BIT, 0, &sc->cbl_tag); + if (error) { + device_printf(dev, "could not allocate dma tag\n"); + goto fail; + } + + error = bus_dmamem_alloc(sc->cbl_tag, (void **)&sc->fxp_desc.cbl_list, + BUS_DMA_NOWAIT, &sc->cbl_map); + if (error) + goto failmem; + bzero(sc->fxp_desc.cbl_list, FXP_TXCB_SZ); + + error = bus_dmamap_load(sc->cbl_tag, sc->cbl_map, + sc->fxp_desc.cbl_list, FXP_TXCB_SZ, fxp_dma_map_addr, + &sc->fxp_desc.cbl_addr, 0); + if (error) { + device_printf(dev, "could not map DMA memory\n"); + goto fail; + } + + error = bus_dma_tag_create(NULL, 4, 0, BUS_SPACE_MAXADDR_32BIT, + BUS_SPACE_MAXADDR, NULL, NULL, sizeof(struct fxp_cb_mcs), 1, + BUS_SPACE_MAXSIZE_32BIT, 0, &sc->mcs_tag); + if (error) { + device_printf(dev, "could not allocate dma tag\n"); + goto fail; + } + + error = bus_dmamem_alloc(sc->mcs_tag, (void **)&sc->mcsp, + BUS_DMA_NOWAIT, &sc->mcs_map); + if (error) + goto failmem; + error = bus_dmamap_load(sc->mcs_tag, sc->mcs_map, sc->mcsp, + sizeof(struct fxp_cb_mcs), fxp_dma_map_addr, &sc->mcs_addr, 0); + if (error) { + device_printf(dev, "can't map the multicast setup command\n"); + goto fail; + } + + /* + * Pre-allocate the TX DMA maps. + */ + for (i = 0; i < FXP_NRFABUFS; i++) { + error = bus_dmamap_create(sc->fxp_mtag, 0, + &sc->fxp_desc.tx_list[i].tx_map); + if (error) { + device_printf(dev, "can't create DMA map for TX\n"); + goto fail; + } + } + error = bus_dmamap_create(sc->fxp_mtag, 0, &sc->spare_map); + if (error) { + device_printf(dev, "can't create spare DMA map\n"); + goto fail; + } + + /* + * Pre-allocate our receive buffers. + */ + sc->fxp_desc.rx_head = sc->fxp_desc.rx_tail = NULL; + for (i = 0; i < FXP_NRFABUFS; i++) { + rxp = &sc->fxp_desc.rx_list[i]; + rxp->rx_mbuf = NULL; + error = bus_dmamap_create(sc->fxp_mtag, 0, &rxp->rx_map); + if (error) { + device_printf(dev, "can't create DMA map for RX\n"); + goto fail; + } + if (fxp_add_rfabuf(sc, rxp) != 0) + goto failmem; + } + + /* * Read MAC address. */ fxp_read_eeprom(sc, (u_int16_t *)sc->arpcom.ac_enaddr, 0, 3); @@ -711,26 +806,64 @@ static void fxp_release(struct fxp_softc *sc) { + struct fxp_rx *rxp; + struct fxp_tx *txp; + int i; + + for (i = 0; i < FXP_NRFABUFS; i++) { + rxp = &sc->fxp_desc.rx_list[i]; + if (rxp->rx_mbuf != NULL) { + bus_dmamap_sync(sc->fxp_mtag, rxp->rx_map, + BUS_DMASYNC_POSTREAD); + bus_dmamap_unload(sc->fxp_mtag, rxp->rx_map); + m_freem(rxp->rx_mbuf); + } + bus_dmamap_destroy(sc->fxp_mtag, rxp->rx_map); + } + bus_dmamap_destroy(sc->fxp_mtag, sc->spare_map); + + for (i = 0; i < FXP_NTXCB; i++) { + txp = &sc->fxp_desc.tx_list[i]; + if (txp->tx_mbuf != NULL) { + bus_dmamap_sync(sc->fxp_mtag, txp->tx_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(sc->fxp_mtag, txp->tx_map); + m_freem(txp->tx_mbuf); + } + bus_dmamap_destroy(sc->fxp_mtag, txp->tx_map); + } bus_generic_detach(sc->dev); if (sc->miibus) device_delete_child(sc->dev, sc->miibus); - if (sc->cbl_base) - free(sc->cbl_base, M_DEVBUF); - if (sc->fxp_stats) - free(sc->fxp_stats, M_DEVBUF); - if (sc->mcsp) - free(sc->mcsp, M_DEVBUF); - if (sc->rfa_headm) - m_freem(sc->rfa_headm); - + if (sc->fxp_desc.cbl_list) { + bus_dmamap_unload(sc->cbl_tag, sc->cbl_map); + bus_dmamem_free(sc->cbl_tag, sc->fxp_desc.cbl_list, + sc->cbl_map); + } + if (sc->fxp_stats) { + bus_dmamap_unload(sc->fxp_stag, sc->fxp_smap); + bus_dmamem_free(sc->fxp_stag, sc->fxp_stats, sc->fxp_smap); + } + if (sc->mcsp) { + bus_dmamap_unload(sc->mcs_tag, sc->mcs_map); + bus_dmamem_free(sc->mcs_tag, sc->mcsp, sc->mcs_map); + } if (sc->ih) bus_teardown_intr(sc->dev, sc->irq, sc->ih); if (sc->irq) bus_release_resource(sc->dev, SYS_RES_IRQ, 0, sc->irq); if (sc->mem) bus_release_resource(sc->dev, sc->rtp, sc->rgd, sc->mem); + if (sc->fxp_mtag) + bus_dma_tag_destroy(sc->fxp_mtag); + if (sc->fxp_stag) + bus_dma_tag_destroy(sc->fxp_stag); + if (sc->cbl_tag) + bus_dma_tag_destroy(sc->cbl_tag); + if (sc->mcs_tag) + bus_dma_tag_destroy(sc->mcs_tag); sysctl_ctx_free(&sc->sysctl_ctx); @@ -1037,6 +1170,47 @@ fxp_eeprom_putword(sc, offset + i, data[i]); } +static void +fxp_dma_map_txbuf(void *arg, bus_dma_segment_t *segs, int nseg, + bus_size_t mapsize, int error) +{ + struct fxp_softc *sc; + struct fxp_cb_tx *txp; + int i; + + if (error) + return; + + KASSERT(nseg <= FXP_NTXSEG, ("too many DMA segments")); + + sc = arg; + txp = sc->fxp_desc.tx_last->tx_next->tx_cb; + for (i = 0; i < nseg; i++) { + KASSERT(segs[i].ds_len <= MCLBYTES, ("segment size too large")); + /* + * If this is an 82550/82551, then we're using extended + * TxCBs _and_ we're using checksum offload. This means + * that the TxCB is really an IPCB. One major difference + * between the two is that with plain extended TxCBs, + * the bottom half of the TxCB contains two entries from + * the TBD array, whereas IPCBs contain just one entry: + * one entry (8 bytes) has been sacrificed for the TCP/IP + * checksum offload control bits. So to make things work + * right, we have to start filling in the TBD array + * starting from a different place depending on whether + * the chip is an 82550/82551 or not. + */ + if (sc->flags & FXP_FLAG_EXT_RFA) { + txp->tbd[i + 1].tb_addr = segs[i].ds_addr; + txp->tbd[i + 1].tb_size = segs[i].ds_len; + } else { + txp->tbd[i].tb_addr = segs[i].ds_addr; + txp->tbd[i].tb_size = segs[i].ds_len; + } + } + txp->tbd_number = nseg; +} + /* * Start packet transmission on the interface. */ @@ -1044,8 +1218,9 @@ fxp_start(struct ifnet *ifp) { struct fxp_softc *sc = ifp->if_softc; - struct fxp_cb_tx *txp; - volatile struct fxp_tbd *bdptr; + struct fxp_tx *txp; + struct mbuf *mb_head; + int error; /* * See if we need to suspend xmit until the multicast filter @@ -1065,8 +1240,6 @@ * a NOP command when needed. */ while (ifp->if_snd.ifq_head != NULL && sc->tx_queued < FXP_NTXCB - 1) { - struct mbuf *m, *mb_head; - int segment; /* * Grab a packet to transmit. @@ -1076,27 +1249,9 @@ /* * Get pointer to next available tx desc. */ - txp = sc->cbl_last->next; + txp = sc->fxp_desc.tx_last->tx_next; /* - * If this is an 82550/82551, then we're using extended - * TxCBs _and_ we're using checksum offload. This means - * that the TxCB is really an IPCB. One major difference - * between the two is that with plain extended TxCBs, - * the bottom half of the TxCB contains two entries from - * the TBD array, whereas IPCBs contain just one entry: - * one entry (8 bytes) has been sacrificed for the TCP/IP - * checksum offload control bits. So to make things work - * right, we have to start filling in the TBD array - * starting from a different place depending on whether - * the chip is an 82550/82551 or not. - */ - - bdptr = &txp->tbd[0]; - if (sc->flags & FXP_FLAG_EXT_RFA) - bdptr++; - - /* * Deal with TCP/IP checksum offload. Note that * in order for TCP checksum offload to work, * the pseudo header checksum must have already @@ -1107,12 +1262,12 @@ if (mb_head->m_pkthdr.csum_flags) { if (mb_head->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { - txp->ipcb_ip_activation_high = + txp->tx_cb->ipcb_ip_activation_high = FXP_IPCB_HARDWAREPARSING_ENABLE; - txp->ipcb_ip_schedule = + txp->tx_cb->ipcb_ip_schedule = FXP_IPCB_TCPUDP_CHECKSUM_ENABLE; if (mb_head->m_pkthdr.csum_flags & CSUM_TCP) - txp->ipcb_ip_schedule |= + txp->tx_cb->ipcb_ip_schedule |= FXP_IPCB_TCP_PACKET; } #ifdef FXP_IP_CSUM_WAR @@ -1147,9 +1302,9 @@ ip->ip_hl << 2); mb_head->m_data -= ETHER_HDR_LEN; } else { - txp->ipcb_ip_activation_high = + txp->tx_cb->ipcb_ip_activation_high = FXP_IPCB_HARDWAREPARSING_ENABLE; - txp->ipcb_ip_schedule |= + txp->tx_cb->ipcb_ip_schedule |= FXP_IPCB_IP_CHECKSUM_ENABLE; } } @@ -1161,18 +1316,17 @@ * the transmit buffer descriptors with the physical address * and size of the mbuf. */ -tbdinit: - for (m = mb_head, segment = 0; m != NULL; m = m->m_next) { - if (m->m_len != 0) { - if (segment == (FXP_NTXSEG - 1)) - break; - bdptr[segment].tb_addr = - vtophys(mtod(m, vm_offset_t)); - bdptr[segment].tb_size = m->m_len; - segment++; - } + error = bus_dmamap_load_mbuf(sc->fxp_mtag, txp->tx_map, + mb_head, fxp_dma_map_txbuf, sc, 0); + + if (error && error != EFBIG) { + device_printf(sc->dev, "can't map mbuf (error %d)\n", + error); + m_freem(mb_head); + break; } - if (m != NULL) { + + if (error) { struct mbuf *mn; /* @@ -1198,19 +1352,28 @@ mn->m_pkthdr.len = mn->m_len = mb_head->m_pkthdr.len; m_freem(mb_head); mb_head = mn; - goto tbdinit; + error = bus_dmamap_load_mbuf(sc->fxp_mtag, txp->tx_map, + mb_head, fxp_dma_map_txbuf, sc, 0); + if (error) { + device_printf(sc->dev, + "can't map mbuf (error %d)\n", error); + m_freem(mb_head); + break; + } } - txp->byte_count = 0; - txp->tbd_number = segment; - txp->mb_head = mb_head; - txp->cb_status = 0; + bus_dmamap_sync(sc->fxp_mtag, txp->tx_map, + BUS_DMASYNC_PREWRITE); + + txp->tx_mbuf = mb_head; + txp->tx_cb->cb_status = 0; + txp->tx_cb->byte_count = 0; if (sc->tx_queued != FXP_CXINT_THRESH - 1) { - txp->cb_command = + txp->tx_cb->cb_command = sc->tx_cmd | FXP_CB_COMMAND_SF | FXP_CB_COMMAND_S; } else { - txp->cb_command = + txp->tx_cb->cb_command = sc->tx_cmd | FXP_CB_COMMAND_SF | FXP_CB_COMMAND_S | FXP_CB_COMMAND_I; /* @@ -1219,8 +1382,8 @@ */ ifp->if_timer = 5; } - txp->tx_threshold = tx_threshold; - + txp->tx_cb->tx_threshold = tx_threshold; + /* * Advance the end of list forward. */ @@ -1232,20 +1395,20 @@ * up the status while we update the command field. * This could cause us to overwrite the completion status. */ - atomic_clear_short(&sc->cbl_last->cb_command, + atomic_clear_short(&sc->fxp_desc.tx_last->tx_cb->cb_command, FXP_CB_COMMAND_S); #else - sc->cbl_last->cb_command &= ~FXP_CB_COMMAND_S; + sc->fxp_desc.tx_last->tx_cb->cb_command &= ~FXP_CB_COMMAND_S; #endif /*__alpha__*/ - sc->cbl_last = txp; + sc->fxp_desc.tx_last = txp; /* * Advance the beginning of the list forward if there are - * no other packets queued (when nothing is queued, cbl_first + * no other packets queued (when nothing is queued, tx_first * sits on the last TxCB that was sent out). */ if (sc->tx_queued == 0) - sc->cbl_first = txp; + sc->fxp_desc.tx_first = txp; sc->tx_queued++; @@ -1254,6 +1417,7 @@ */ BPF_MTAP(ifp, mb_head); } + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); /* * We're finished. If we added to the list, issue a RESUME to get DMA @@ -1343,10 +1507,35 @@ } static void +fxp_txeof(struct fxp_softc *sc) +{ + struct fxp_tx *txp; + + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREREAD); + for (txp = sc->fxp_desc.tx_first; sc->tx_queued && + (txp->tx_cb->cb_status & FXP_CB_STATUS_C) != 0; + txp = txp->tx_next) { + if (txp->tx_mbuf != NULL) { + bus_dmamap_sync(sc->fxp_mtag, txp->tx_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(sc->fxp_mtag, txp->tx_map); + m_freem(txp->tx_mbuf); + txp->tx_mbuf = NULL; + /* clear this to reset csum offload bits */ + txp->tx_cb->tbd[0].tb_addr = 0; + } + sc->tx_queued--; + } + sc->fxp_desc.tx_first = txp; + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); +} + +static void fxp_intr_body(struct fxp_softc *sc, u_int8_t statack, int count) { struct ifnet *ifp = &sc->sc_if; struct mbuf *m; + struct fxp_rx *rxp; struct fxp_rfa *rfa; int rnr = (statack & FXP_SCB_STATACK_RNR) ? 1 : 0; @@ -1374,20 +1563,8 @@ * after the interface is ifconfig'ed for the first time. */ if (statack & (FXP_SCB_STATACK_CXTNO | FXP_SCB_STATACK_CNA)) { - struct fxp_cb_tx *txp; + fxp_txeof(sc); - for (txp = sc->cbl_first; sc->tx_queued && - (txp->cb_status & FXP_CB_STATUS_C) != 0; - txp = txp->next) { - if (txp->mb_head != NULL) { - m_freem(txp->mb_head); - txp->mb_head = NULL; - /* clear this to reset csum offload bits */ - txp->tbd[0].tb_addr = 0; - } - sc->tx_queued--; - } - sc->cbl_first = txp; ifp->if_timer = 0; if (sc->tx_queued == 0) { if (sc->need_mcsetup) @@ -1419,9 +1596,12 @@ * that the info will be used in the subsequent polling cycle. */ for (;;) { - m = sc->rfa_headm; + rxp = sc->fxp_desc.rx_head; + m = rxp->rx_mbuf; rfa = (struct fxp_rfa *)(m->m_ext.ext_buf + RFA_ALIGNMENT_FUDGE); + bus_dmamap_sync(sc->fxp_mtag, rxp->rx_map, + BUS_DMASYNC_POSTREAD); #ifdef DEVICE_POLLING /* loop at most count times if count >=0 */ if (count >= 0 && count-- == 0) { @@ -1434,21 +1614,20 @@ } #endif /* DEVICE_POLLING */ - if ( (rfa->rfa_status & FXP_RFA_STATUS_C) == 0) + if ((rfa->rfa_status & FXP_RFA_STATUS_C) == 0) break; /* - * Remove first packet from the chain. + * Advance head forward. */ - sc->rfa_headm = m->m_next; - m->m_next = NULL; + sc->fxp_desc.rx_head = rxp->rx_next; /* * Add a new buffer to the receive chain. * If this fails, the old buffer is recycled * instead. */ - if (fxp_add_rfabuf(sc, m) == 0) { + if (fxp_add_rfabuf(sc, rxp) == 0) { int total_len; /* @@ -1460,7 +1639,7 @@ total_len = rfa->actual_size & 0x3fff; if (total_len < sizeof(struct ether_header) || total_len > MCLBYTES - RFA_ALIGNMENT_FUDGE - - sizeof(struct fxp_rfa) || + sc->rfa_size || rfa->rfa_status & FXP_RFA_STATUS_CRC) { m_freem(m); continue; @@ -1495,8 +1674,7 @@ if (rnr) { fxp_scb_wait(sc); CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, - vtophys(sc->rfa_headm->m_ext.ext_buf) + - RFA_ALIGNMENT_FUDGE); + sc->fxp_desc.rx_head->rx_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_RU_START); } } @@ -1518,7 +1696,6 @@ struct fxp_softc *sc = xsc; struct ifnet *ifp = &sc->sc_if; struct fxp_stats *sp = sc->fxp_stats; - struct fxp_cb_tx *txp; int s; ifp->if_opackets += sp->tx_good; @@ -1546,6 +1723,7 @@ if (tx_threshold < 192) tx_threshold += 64; } + bus_dmamap_sync(sc->fxp_stag, sc->fxp_smap, BUS_DMASYNC_POSTREAD); s = splimp(); /* * Release any xmit buffers that have completed DMA. This isn't @@ -1554,18 +1732,8 @@ * than being defered for a potentially long time. This limits * the delay to a maximum of one second. */ - for (txp = sc->cbl_first; sc->tx_queued && - (txp->cb_status & FXP_CB_STATUS_C) != 0; - txp = txp->next) { - if (txp->mb_head != NULL) { - m_freem(txp->mb_head); - txp->mb_head = NULL; - /* clear this to reset csum offload bits */ - txp->tbd[0].tb_addr = 0; - } - sc->tx_queued--; - } - sc->cbl_first = txp; + fxp_txeof(sc); + /* * If we haven't received any packets in FXP_MAC_RX_IDLE seconds, * then assume the receiver has locked up and attempt to clear @@ -1588,6 +1756,8 @@ /* * Start another stats dump. */ + bus_dmamap_sync(sc->fxp_stag, sc->fxp_smap, + BUS_DMASYNC_PREREAD); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_DUMPRESET); } else { /* @@ -1622,7 +1792,7 @@ fxp_stop(struct fxp_softc *sc) { struct ifnet *ifp = &sc->sc_if; - struct fxp_cb_tx *txp; + struct fxp_tx *txp; int i; ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE); @@ -1646,36 +1816,22 @@ /* * Release any xmit buffers. */ - txp = sc->cbl_base; + txp = sc->fxp_desc.tx_list; if (txp != NULL) { for (i = 0; i < FXP_NTXCB; i++) { - if (txp[i].mb_head != NULL) { - m_freem(txp[i].mb_head); - txp[i].mb_head = NULL; + if (txp[i].tx_mbuf != NULL) { + bus_dmamap_sync(sc->fxp_mtag, txp[i].tx_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(sc->fxp_mtag, txp[i].tx_map); + m_freem(txp[i].tx_mbuf); + txp[i].tx_mbuf = NULL; /* clear this to reset csum offload bits */ - txp[i].tbd[0].tb_addr = 0; + txp[i].tx_cb->tbd[0].tb_addr = 0; } } } + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); sc->tx_queued = 0; - - /* - * Free all the receive buffers then reallocate/reinitialize - */ - if (sc->rfa_headm != NULL) - m_freem(sc->rfa_headm); - sc->rfa_headm = NULL; - sc->rfa_tailm = NULL; - for (i = 0; i < FXP_NRFABUFS; i++) { - if (fxp_add_rfabuf(sc, NULL) != 0) { - /* - * This "can't happen" - we're at splimp() - * and we just freed all the buffers we need - * above. - */ - panic("fxp_stop: no buffers!"); - } - } } /* @@ -1702,7 +1858,8 @@ struct ifnet *ifp = &sc->sc_if; struct fxp_cb_config *cbp; struct fxp_cb_ias *cb_ias; - struct fxp_cb_tx *txp; + struct fxp_cb_tx *tcbp; + struct fxp_tx *txp; struct fxp_cb_mcs *mcsp; int i, prm, s; @@ -1728,7 +1885,8 @@ * Initialize base of dump-stats buffer. */ fxp_scb_wait(sc); - CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, vtophys(sc->fxp_stats)); + bus_dmamap_sync(sc->fxp_stag, sc->fxp_smap, BUS_DMASYNC_PREREAD); + CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, sc->stats_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_DUMP_ADR); /* @@ -1749,10 +1907,13 @@ * Start the multicast setup command. */ fxp_scb_wait(sc); - CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, vtophys(&mcsp->cb_status)); + bus_dmamap_sync(sc->mcs_tag, sc->mcs_map, BUS_DMASYNC_PREWRITE); + CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, sc->mcs_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_START); /* ...and wait for it to complete. */ fxp_dma_wait(&mcsp->cb_status, sc); + bus_dmamap_sync(sc->mcs_tag, sc->mcs_map, + BUS_DMASYNC_POSTWRITE); } /* @@ -1760,16 +1921,14 @@ * construct the config CB. The TxCB list memory is rebuilt * later. */ - cbp = (struct fxp_cb_config *) sc->cbl_base; + cbp = (struct fxp_cb_config *)sc->fxp_desc.cbl_list; /* * This bcopy is kind of disgusting, but there are a bunch of must be * zero and must be one bits in this structure and this is the easiest * way to initialize them all to proper values. */ - bcopy(fxp_cb_config_template, - (void *)(uintptr_t)(volatile void *)&cbp->cb_status, - sizeof(fxp_cb_config_template)); + bcopy(fxp_cb_config_template, cbp, sizeof(fxp_cb_config_template)); cbp->cb_status = 0; cbp->cb_command = FXP_CB_COMMAND_CONFIG | FXP_CB_COMMAND_EL; @@ -1859,16 +2018,18 @@ * Start the config command/DMA. */ fxp_scb_wait(sc); - CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, vtophys(&cbp->cb_status)); + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); + CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, sc->fxp_desc.cbl_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_START); /* ...and wait for it to complete. */ fxp_dma_wait(&cbp->cb_status, sc); + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_POSTWRITE); /* * Now initialize the station address. Temporarily use the TxCB * memory area like we did above for the config CB. */ - cb_ias = (struct fxp_cb_ias *) sc->cbl_base; + cb_ias = (struct fxp_cb_ias *)sc->fxp_desc.cbl_list; cb_ias->cb_status = 0; cb_ias->cb_command = FXP_CB_COMMAND_IAS | FXP_CB_COMMAND_EL; cb_ias->link_addr = -1; @@ -1880,33 +2041,40 @@ * Start the IAS (Individual Address Setup) command/DMA. */ fxp_scb_wait(sc); + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_START); /* ...and wait for it to complete. */ fxp_dma_wait(&cb_ias->cb_status, sc); + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_POSTWRITE); /* * Initialize transmit control block (TxCB) list. */ - - txp = sc->cbl_base; - bzero(txp, sizeof(struct fxp_cb_tx) * FXP_NTXCB); + txp = sc->fxp_desc.tx_list; + tcbp = sc->fxp_desc.cbl_list; + bzero(tcbp, FXP_TXCB_SZ); for (i = 0; i < FXP_NTXCB; i++) { - txp[i].cb_status = FXP_CB_STATUS_C | FXP_CB_STATUS_OK; - txp[i].cb_command = FXP_CB_COMMAND_NOP; - txp[i].link_addr = - vtophys(&txp[(i + 1) & FXP_TXCB_MASK].cb_status); + txp[i].tx_cb = tcbp + i; + txp[i].tx_mbuf = NULL; + tcbp[i].cb_status = FXP_CB_STATUS_C | FXP_CB_STATUS_OK; + tcbp[i].cb_command = FXP_CB_COMMAND_NOP; + tcbp[i].link_addr = sc->fxp_desc.cbl_addr + + (((i + 1) & FXP_TXCB_MASK) * sizeof(struct fxp_cb_tx)); if (sc->flags & FXP_FLAG_EXT_TXCB) - txp[i].tbd_array_addr = vtophys(&txp[i].tbd[2]); + tcbp[i].tbd_array_addr = + FXP_TXCB_DMA_ADDR(sc, &tcbp[i].tbd[2]); else - txp[i].tbd_array_addr = vtophys(&txp[i].tbd[0]); - txp[i].next = &txp[(i + 1) & FXP_TXCB_MASK]; + tcbp[i].tbd_array_addr = + FXP_TXCB_DMA_ADDR(sc, &tcbp[i].tbd[0]); + txp[i].tx_next = &txp[(i + 1) & FXP_TXCB_MASK]; } /* * Set the suspend flag on the first TxCB and start the control * unit. It will execute the NOP and then suspend. */ - txp->cb_command = FXP_CB_COMMAND_NOP | FXP_CB_COMMAND_S; - sc->cbl_first = sc->cbl_last = txp; + tcbp->cb_command = FXP_CB_COMMAND_NOP | FXP_CB_COMMAND_S; + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); + sc->fxp_desc.tx_first = sc->fxp_desc.tx_last = txp; sc->tx_queued = 1; fxp_scb_wait(sc); @@ -1916,8 +2084,7 @@ * Initialize receiver buffer area - RFA. */ fxp_scb_wait(sc); - CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, - vtophys(sc->rfa_headm->m_ext.ext_buf) + RFA_ALIGNMENT_FUDGE); + CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, sc->fxp_desc.rx_head->rx_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_RU_START); /* @@ -2007,19 +2174,18 @@ * data pointer is fixed up to point just past it. */ static int -fxp_add_rfabuf(struct fxp_softc *sc, struct mbuf *oldm) +fxp_add_rfabuf(struct fxp_softc *sc, struct fxp_rx *rxp) { - u_int32_t v; struct mbuf *m; struct fxp_rfa *rfa, *p_rfa; + struct fxp_rx *p_rx; + bus_dmamap_t tmp_map; + u_int32_t v; + int error; m = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR); - if (m == NULL) { /* try to recycle the old mbuf instead */ - if (oldm == NULL) - return 1; - m = oldm; - m->m_data = m->m_ext.ext_buf; - } + if (m == NULL) + return (ENOBUFS); /* * Move the data pointer up so that the incoming data packet @@ -2033,8 +2199,7 @@ */ rfa = mtod(m, struct fxp_rfa *); m->m_data += sc->rfa_size; - rfa->size = (u_int16_t)(MCLBYTES - sizeof(struct fxp_rfa) - - RFA_ALIGNMENT_FUDGE); + rfa->size = MCLBYTES - sc->rfa_size - RFA_ALIGNMENT_FUDGE; /* * Initialize the rest of the RFA. Note that since the RFA @@ -2050,23 +2215,43 @@ fxp_lwcopy(&v, (volatile u_int32_t *) rfa->link_addr); fxp_lwcopy(&v, (volatile u_int32_t *) rfa->rbd_addr); + /* Map the RFA into DMA memory. */ + error = bus_dmamap_load(sc->fxp_mtag, sc->spare_map, rfa, + MCLBYTES - RFA_ALIGNMENT_FUDGE, fxp_dma_map_addr, + &rxp->rx_addr, 0); + if (error) { + m_freem(m); + return (error); + } + + bus_dmamap_unload(sc->fxp_mtag, rxp->rx_map); + tmp_map = sc->spare_map; + sc->spare_map = rxp->rx_map; + rxp->rx_map = tmp_map; + rxp->rx_mbuf = m; + + bus_dmamap_sync(sc->fxp_mtag, rxp->rx_map, BUS_DMASYNC_PREREAD); + /* * If there are other buffers already on the list, attach this * one to the end by fixing up the tail to point to this one. */ - if (sc->rfa_headm != NULL) { - p_rfa = (struct fxp_rfa *) (sc->rfa_tailm->m_ext.ext_buf + - RFA_ALIGNMENT_FUDGE); - sc->rfa_tailm->m_next = m; - v = vtophys(rfa); - fxp_lwcopy(&v, (volatile u_int32_t *) p_rfa->link_addr); + if (sc->fxp_desc.rx_head != NULL) { + p_rx = sc->fxp_desc.rx_tail; + p_rfa = (struct fxp_rfa *) + (p_rx->rx_mbuf->m_ext.ext_buf + RFA_ALIGNMENT_FUDGE); + p_rx->rx_next = rxp; + fxp_lwcopy(&rxp->rx_addr, + (volatile u_int32_t *)p_rfa->link_addr); p_rfa->rfa_control = 0; + bus_dmamap_sync(sc->fxp_mtag, p_rx->rx_map, + BUS_DMASYNC_PREREAD); } else { - sc->rfa_headm = m; + rxp->rx_next = NULL; + sc->fxp_desc.rx_head = rxp; } - sc->rfa_tailm = m; - - return (m == oldm); + sc->fxp_desc.rx_tail = rxp; + return (0); } static volatile int @@ -2231,6 +2416,7 @@ { struct fxp_cb_mcs *mcsp = sc->mcsp; struct ifnet *ifp = &sc->sc_if; + struct fxp_tx *txp; int count; /* @@ -2241,8 +2427,6 @@ * TX commands will be added when need_mcsetup is true. */ if (sc->tx_queued) { - struct fxp_cb_tx *txp; - /* * need_mcsetup will be true if we are already waiting for the * NOP command to be completed (see below). In this case, bail. @@ -2255,16 +2439,17 @@ * Add a NOP command with interrupt so that we are notified * when all TX commands have been processed. */ - txp = sc->cbl_last->next; - txp->mb_head = NULL; - txp->cb_status = 0; - txp->cb_command = FXP_CB_COMMAND_NOP | + txp = sc->fxp_desc.tx_last->tx_next; + txp->tx_mbuf = NULL; + txp->tx_cb->cb_status = 0; + txp->tx_cb->cb_command = FXP_CB_COMMAND_NOP | FXP_CB_COMMAND_S | FXP_CB_COMMAND_I; + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); /* * Advance the end of list forward. */ - sc->cbl_last->cb_command &= ~FXP_CB_COMMAND_S; - sc->cbl_last = txp; + sc->fxp_desc.tx_last->tx_cb->cb_command &= ~FXP_CB_COMMAND_S; + sc->fxp_desc.tx_last = txp; sc->tx_queued++; /* * Issue a resume in case the CU has just suspended. @@ -2284,14 +2469,17 @@ /* * Initialize multicast setup descriptor. */ - mcsp->next = sc->cbl_base; - mcsp->mb_head = NULL; + bus_dmamap_sync(sc->mcs_tag, sc->mcs_map, BUS_DMASYNC_POSTWRITE); mcsp->cb_status = 0; mcsp->cb_command = FXP_CB_COMMAND_MCAS | FXP_CB_COMMAND_S | FXP_CB_COMMAND_I; - mcsp->link_addr = vtophys(&sc->cbl_base->cb_status); + mcsp->link_addr = sc->fxp_desc.cbl_addr; + txp = &sc->fxp_desc.mcs_tx; + txp->tx_mbuf = NULL; + txp->tx_cb = (struct fxp_cb_tx *)sc->mcsp; + txp->tx_next = sc->fxp_desc.tx_list; (void) fxp_mc_addrs(sc); - sc->cbl_first = sc->cbl_last = (struct fxp_cb_tx *) mcsp; + sc->fxp_desc.tx_first = sc->fxp_desc.tx_last = txp; sc->tx_queued = 1; /* @@ -2311,7 +2499,8 @@ * Start the multicast setup command. */ fxp_scb_wait(sc); - CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, vtophys(&mcsp->cb_status)); + bus_dmamap_sync(sc->mcs_tag, sc->mcs_map, BUS_DMASYNC_PREWRITE); + CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, sc->mcs_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_START); ifp->if_timer = 2; @@ -2358,7 +2547,7 @@ break; if (uc->ucode == NULL) return; - cbp = (struct fxp_cb_ucode *)sc->cbl_base; + cbp = (struct fxp_cb_ucode *)sc->fxp_desc.cbl_list; cbp->cb_status = 0; cbp->cb_command = FXP_CB_COMMAND_UCODE | FXP_CB_COMMAND_EL; cbp->link_addr = -1; /* (no) next command */ @@ -2373,10 +2562,12 @@ * Download the ucode to the chip. */ fxp_scb_wait(sc); - CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, vtophys(&cbp->cb_status)); + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); + CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, sc->fxp_desc.cbl_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_START); /* ...and wait for it to complete. */ fxp_dma_wait(&cbp->cb_status, sc); + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_POSTWRITE); device_printf(sc->dev, "Microcode loaded, int_delay: %d usec bundle_max: %d\n", sc->tunable_int_delay, --- //depot/vendor/freebsd/src/sys/dev/fxp/if_fxpreg.h 2003/02/26 14:15:17 +++ //depot/user/mux/busdma/dev/fxp/if_fxpreg.h 2003/03/30 15:55:57 @@ -111,13 +111,11 @@ * Command block definitions */ struct fxp_cb_nop { - void *fill[2]; volatile u_int16_t cb_status; volatile u_int16_t cb_command; volatile u_int32_t link_addr; }; struct fxp_cb_ias { - void *fill[2]; volatile u_int16_t cb_status; volatile u_int16_t cb_command; volatile u_int32_t link_addr; @@ -125,7 +123,6 @@ }; /* I hate bit-fields :-( */ struct fxp_cb_config { - void *fill[2]; volatile u_int16_t cb_status; volatile u_int16_t cb_command; volatile u_int32_t link_addr; @@ -215,8 +212,6 @@ #define MAXMCADDR 80 struct fxp_cb_mcs { - struct fxp_cb_tx *next; - struct mbuf *mb_head; volatile u_int16_t cb_status; volatile u_int16_t cb_command; volatile u_int32_t link_addr; @@ -226,7 +221,6 @@ #define MAXUCODESIZE 192 struct fxp_cb_ucode { - void *fill[2]; u_int16_t cb_status; u_int16_t cb_command; u_int32_t link_addr; @@ -234,13 +228,9 @@ }; /* - * Number of DMA segments in a TxCB. Note that this is carefully - * chosen to make the total struct size an even power of two. It's - * critical that no TxCB be split across a page boundry since - * no attempt is made to allocate physically contiguous memory. + * Number of DMA segments in a TxCB. */ -#define FXP_TXCB_FIXED 16 /* cb_status .. tbd_number */ -#define FXP_NTXSEG ((256 - (sizeof(void *) * 2) - FXP_TXCB_FIXED) / 8) +#define FXP_NTXSEG 32 struct fxp_tbd { volatile u_int32_t tb_addr; @@ -268,8 +258,6 @@ }; struct fxp_cb_tx { - struct fxp_cb_tx *next; - struct mbuf *mb_head; volatile u_int16_t cb_status; volatile u_int16_t cb_command; volatile u_int32_t link_addr; --- //depot/vendor/freebsd/src/sys/dev/fxp/if_fxpvar.h 2003/02/26 14:15:17 +++ //depot/user/mux/busdma/dev/fxp/if_fxpvar.h 2003/03/31 15:30:37 @@ -40,6 +40,19 @@ #define FXP_NTXCB 128 /* + * Size of the TxCB list. + */ +#define FXP_TXCB_SZ (FXP_NTXCB * sizeof(struct fxp_cb_tx)) + +/* + * Macro to obtain the DMA address of a virtual address in the + * TxCB list based on the base DMA address of the TxCB list. + */ +#define FXP_TXCB_DMA_ADDR(sc, addr) \ + (sc->fxp_desc.cbl_addr + (uintptr_t)addr - \ + (uintptr_t)sc->fxp_desc.cbl_list) + +/* * Number of completed TX commands at which point an interrupt * will be generated to garbage collect the attached buffers. * Must be at least one less than FXP_NTXCB, and should be @@ -99,10 +112,36 @@ #define FXP_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx) #endif -#ifdef __alpha__ -#undef vtophys -#define vtophys(va) alpha_XXX_dmamap((vm_offset_t)(va)) -#endif /* __alpha__ */ +/* + * Structures to handle TX and RX descriptors. + */ +struct fxp_rx { + struct fxp_rx *rx_next; + struct mbuf *rx_mbuf; + bus_dmamap_t rx_map; + u_int32_t rx_addr; +}; + +struct fxp_tx { + struct fxp_tx *tx_next; + struct fxp_cb_tx *tx_cb; + struct mbuf *tx_mbuf; + bus_dmamap_t tx_map; +}; + +struct fxp_desc_list { + struct fxp_rx rx_list[FXP_NRFABUFS]; + struct fxp_tx tx_list[FXP_NTXCB]; + struct fxp_tx mcs_tx; + struct fxp_rx *rx_head; + struct fxp_rx *rx_tail; + struct fxp_tx *tx_first; + struct fxp_tx *tx_last; + struct fxp_rfa *rfa_list; + struct fxp_cb_tx *cbl_list; + u_int32_t cbl_addr; + bus_dma_tag_t rx_tag; +}; /* * NOTE: Elements are ordered for optimal cacheline behavior, and NOT @@ -118,17 +157,23 @@ struct mtx sc_mtx; bus_space_tag_t sc_st; /* bus space tag */ bus_space_handle_t sc_sh; /* bus space handle */ - struct mbuf *rfa_headm; /* first mbuf in receive frame area */ - struct mbuf *rfa_tailm; /* last mbuf in receive frame area */ - struct fxp_cb_tx *cbl_first; /* first active TxCB in list */ + bus_dma_tag_t fxp_mtag; /* bus DMA tag for mbufs */ + bus_dma_tag_t fxp_stag; /* bus DMA tag for stats */ + bus_dmamap_t fxp_smap; /* bus DMA map for stats */ + bus_dma_tag_t cbl_tag; /* DMA tag for the TxCB list */ + bus_dmamap_t cbl_map; /* DMA map for the TxCB list */ + bus_dma_tag_t mcs_tag; /* DMA tag for the multicast setup */ + bus_dmamap_t mcs_map; /* DMA map for the multicast setup */ + bus_dmamap_t spare_map; /* spare DMA map */ + struct fxp_desc_list fxp_desc; /* descriptors management struct */ int tx_queued; /* # of active TxCB's */ int need_mcsetup; /* multicast filter needs programming */ - struct fxp_cb_tx *cbl_last; /* last active TxCB in list */ struct fxp_stats *fxp_stats; /* Pointer to interface stats */ + u_int32_t stats_addr; /* DMA address of the stats structure */ int rx_idle_secs; /* # of seconds RX has been idle */ struct callout_handle stat_ch; /* Handle for canceling our stat timeout */ - struct fxp_cb_tx *cbl_base; /* base of TxCB list */ struct fxp_cb_mcs *mcsp; /* Pointer to mcast setup descriptor */ + u_int32_t mcs_addr; /* DMA address of the multicast cmd */ struct ifmedia sc_media; /* media information */ device_t miibus; device_t dev; --- //depot/vendor/freebsd/src/sys/i386/isa/npx.c 2003/03/30 16:35:17 +++ //depot/user/mux/busdma/i386/isa/npx.c 2003/02/17 15:28:52 @@ -32,7 +32,7 @@ * SUCH DAMAGE. * * from: @(#)npx.c 7.2 (Berkeley) 5/12/91 - * $FreeBSD: src/sys/i386/isa/npx.c,v 1.138 2003/03/31 00:32:43 jeff Exp $ + * $FreeBSD: src/sys/i386/isa/npx.c,v 1.137 2003/02/17 09:55:08 julian Exp $ */ #include "opt_cpu.h" @@ -996,7 +996,7 @@ return; s = intr_disable(); - if (td == PCPU_GET(fpcurthread)) { + if (curthread == PCPU_GET(fpcurthread)) { fpurstor(addr); intr_restore(s); } else { --- //depot/vendor/freebsd/src/sys/pci/if_xl.c 2003/03/28 22:35:19 +++ //depot/user/mux/busdma/pci/if_xl.c 2003/03/30 16:37:29 @@ -1903,6 +1903,10 @@ cd = &sc->xl_cdata; ld = &sc->xl_ldata; + error = bus_dmamap_create(sc->xl_mtag, 0, &sc->xl_tmpmap); + if (error) + return(error); + for (i = 0; i < XL_RX_LIST_CNT; i++) { cd->xl_rx_chain[i].xl_ptr = &ld->xl_rx_list[i]; error = bus_dmamap_create(sc->xl_mtag, 0, @@ -3182,6 +3186,7 @@ sc->xl_cdata.xl_rx_chain[i].xl_mbuf = NULL; } } + bus_dmamap_destroy(sc->xl_mtag, sc->xl_tmpmap); bzero(sc->xl_ldata.xl_rx_list, XL_RX_LIST_SZ); /* * Free the TX list buffers. --dTy3Mrz/UPE2dbVg-- From owner-freebsd-alpha@FreeBSD.ORG Tue Apr 1 05:41:14 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBB8837B401 for ; Tue, 1 Apr 2003 05:41:14 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A685D43F3F for ; Tue, 1 Apr 2003 05:41:13 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 8D4BE2ED407; Tue, 1 Apr 2003 05:41:13 -0800 (PST) Date: Tue, 1 Apr 2003 15:41:13 +0200 From: Maxime Henrion To: alpha@freebsd.org Message-ID: <20030401134113.GC1750@elvis.mu.org> References: <20030401115802.GB1750@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VywGB/WGlW4DM4P8" Content-Disposition: inline In-Reply-To: <20030401115802.GB1750@elvis.mu.org> User-Agent: Mutt/1.4.1i Subject: Re: call for testers: busdma-ified fxp(4) driver X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 13:41:15 -0000 --VywGB/WGlW4DM4P8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Maxime Henrion wrote: > Hi all, > > > My fxp(4) patch should now be nearly commit ready. It has been tested > successfully on ia64, and also works on x86. It would be of a great > help if someone with an alpha box and a fxp(4) card could test this > patch since I lack the necessary hardware. I'm attaching the patch to > this mail. Sorry to follow-up to myself, but this patch had some bogus and irrelevant diffs in it. I'm attaching a fixed one now. It can also be found at http://mu.org/~mux/patches/if_fxp.patch. Cheers, Maxime --VywGB/WGlW4DM4P8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="if_fxp.patch" --- //depot/vendor/freebsd/src/sys/dev/fxp/if_fxp.c 2003/03/08 13:45:18 +++ //depot/user/mux/busdma/dev/fxp/if_fxp.c 2003/04/01 05:27:39 @@ -35,7 +35,6 @@ #include #include #include -#include /* #include */ #include #include @@ -55,8 +54,7 @@ #include #include -#include /* for vtophys */ -#include /* for vtophys */ +#include #include /* for DELAY */ #include @@ -194,7 +192,8 @@ static int fxp_ioctl(struct ifnet *ifp, u_long command, caddr_t data); static void fxp_watchdog(struct ifnet *ifp); -static int fxp_add_rfabuf(struct fxp_softc *sc, struct mbuf *oldm); +static int fxp_add_rfabuf(struct fxp_softc *sc, + struct fxp_rx *rxp); static int fxp_mc_addrs(struct fxp_softc *sc); static void fxp_mc_setup(struct fxp_softc *sc); static u_int16_t fxp_eeprom_getword(struct fxp_softc *sc, int offset, @@ -363,12 +362,26 @@ #endif } +static void +fxp_dma_map_addr(void *arg, bus_dma_segment_t *segs, int nseg, int error) +{ + u_int32_t *addr; + + if (error) + return; + + KASSERT(nseg == 1, ("too many DMA segments, %d should be 1", nseg)); + addr = arg; + *addr = segs->ds_addr; +} + static int fxp_attach(device_t dev) { int error = 0; struct fxp_softc *sc = device_get_softc(dev); struct ifnet *ifp; + struct fxp_rx *rxp; u_int32_t val; u_int16_t data; int i, rid, m1, m2, prefer_iomap; @@ -461,29 +474,6 @@ CSR_WRITE_4(sc, FXP_CSR_PORT, FXP_PORT_SELECTIVE_RESET); DELAY(10); - sc->cbl_base = malloc(sizeof(struct fxp_cb_tx) * FXP_NTXCB, - M_DEVBUF, M_NOWAIT | M_ZERO); - if (sc->cbl_base == NULL) - goto failmem; - - sc->fxp_stats = malloc(sizeof(struct fxp_stats), M_DEVBUF, - M_NOWAIT | M_ZERO); - if (sc->fxp_stats == NULL) - goto failmem; - - sc->mcsp = malloc(sizeof(struct fxp_cb_mcs), M_DEVBUF, M_NOWAIT); - if (sc->mcsp == NULL) - goto failmem; - - /* - * Pre-allocate our receive buffers. - */ - for (i = 0; i < FXP_NRFABUFS; i++) { - if (fxp_add_rfabuf(sc, NULL) != 0) { - goto failmem; - } - } - /* * Find out how large of an SEEPROM we have. */ @@ -617,6 +607,112 @@ } /* + * Allocate DMA tags and DMA safe memory. + */ + error = bus_dma_tag_create(NULL, 2, 0, BUS_SPACE_MAXADDR_32BIT, + BUS_SPACE_MAXADDR, NULL, NULL, MCLBYTES, + sc->flags & FXP_FLAG_EXT_RFA ? FXP_NTXSEG - 1 : FXP_NTXSEG, + BUS_SPACE_MAXSIZE_32BIT, 0, &sc->fxp_mtag); + if (error) { + device_printf(dev, "could not allocate dma tag\n"); + goto fail; + } + + error = bus_dma_tag_create(NULL, 4, 0, BUS_SPACE_MAXADDR_32BIT, + BUS_SPACE_MAXADDR, NULL, NULL, sizeof(struct fxp_stats), 1, + BUS_SPACE_MAXSIZE_32BIT, 0, &sc->fxp_stag); + if (error) { + device_printf(dev, "could not allocate dma tag\n"); + goto fail; + } + + error = bus_dmamem_alloc(sc->fxp_stag, (void **)&sc->fxp_stats, + BUS_DMA_NOWAIT, &sc->fxp_smap); + if (error) + goto failmem; + error = bus_dmamap_load(sc->fxp_stag, sc->fxp_smap, sc->fxp_stats, + sizeof(struct fxp_stats), fxp_dma_map_addr, &sc->stats_addr, 0); + if (error) { + device_printf(dev, "could not map the stats buffer\n"); + goto fail; + } + bzero(sc->fxp_stats, sizeof(struct fxp_stats)); + + error = bus_dma_tag_create(NULL, 4, 0, BUS_SPACE_MAXADDR_32BIT, + BUS_SPACE_MAXADDR, NULL, NULL, FXP_TXCB_SZ, 1, + BUS_SPACE_MAXSIZE_32BIT, 0, &sc->cbl_tag); + if (error) { + device_printf(dev, "could not allocate dma tag\n"); + goto fail; + } + + error = bus_dmamem_alloc(sc->cbl_tag, (void **)&sc->fxp_desc.cbl_list, + BUS_DMA_NOWAIT, &sc->cbl_map); + if (error) + goto failmem; + bzero(sc->fxp_desc.cbl_list, FXP_TXCB_SZ); + + error = bus_dmamap_load(sc->cbl_tag, sc->cbl_map, + sc->fxp_desc.cbl_list, FXP_TXCB_SZ, fxp_dma_map_addr, + &sc->fxp_desc.cbl_addr, 0); + if (error) { + device_printf(dev, "could not map DMA memory\n"); + goto fail; + } + + error = bus_dma_tag_create(NULL, 4, 0, BUS_SPACE_MAXADDR_32BIT, + BUS_SPACE_MAXADDR, NULL, NULL, sizeof(struct fxp_cb_mcs), 1, + BUS_SPACE_MAXSIZE_32BIT, 0, &sc->mcs_tag); + if (error) { + device_printf(dev, "could not allocate dma tag\n"); + goto fail; + } + + error = bus_dmamem_alloc(sc->mcs_tag, (void **)&sc->mcsp, + BUS_DMA_NOWAIT, &sc->mcs_map); + if (error) + goto failmem; + error = bus_dmamap_load(sc->mcs_tag, sc->mcs_map, sc->mcsp, + sizeof(struct fxp_cb_mcs), fxp_dma_map_addr, &sc->mcs_addr, 0); + if (error) { + device_printf(dev, "can't map the multicast setup command\n"); + goto fail; + } + + /* + * Pre-allocate the TX DMA maps. + */ + for (i = 0; i < FXP_NRFABUFS; i++) { + error = bus_dmamap_create(sc->fxp_mtag, 0, + &sc->fxp_desc.tx_list[i].tx_map); + if (error) { + device_printf(dev, "can't create DMA map for TX\n"); + goto fail; + } + } + error = bus_dmamap_create(sc->fxp_mtag, 0, &sc->spare_map); + if (error) { + device_printf(dev, "can't create spare DMA map\n"); + goto fail; + } + + /* + * Pre-allocate our receive buffers. + */ + sc->fxp_desc.rx_head = sc->fxp_desc.rx_tail = NULL; + for (i = 0; i < FXP_NRFABUFS; i++) { + rxp = &sc->fxp_desc.rx_list[i]; + rxp->rx_mbuf = NULL; + error = bus_dmamap_create(sc->fxp_mtag, 0, &rxp->rx_map); + if (error) { + device_printf(dev, "can't create DMA map for RX\n"); + goto fail; + } + if (fxp_add_rfabuf(sc, rxp) != 0) + goto failmem; + } + + /* * Read MAC address. */ fxp_read_eeprom(sc, (u_int16_t *)sc->arpcom.ac_enaddr, 0, 3); @@ -711,26 +807,64 @@ static void fxp_release(struct fxp_softc *sc) { + struct fxp_rx *rxp; + struct fxp_tx *txp; + int i; + + for (i = 0; i < FXP_NRFABUFS; i++) { + rxp = &sc->fxp_desc.rx_list[i]; + if (rxp->rx_mbuf != NULL) { + bus_dmamap_sync(sc->fxp_mtag, rxp->rx_map, + BUS_DMASYNC_POSTREAD); + bus_dmamap_unload(sc->fxp_mtag, rxp->rx_map); + m_freem(rxp->rx_mbuf); + } + bus_dmamap_destroy(sc->fxp_mtag, rxp->rx_map); + } + bus_dmamap_destroy(sc->fxp_mtag, sc->spare_map); + + for (i = 0; i < FXP_NTXCB; i++) { + txp = &sc->fxp_desc.tx_list[i]; + if (txp->tx_mbuf != NULL) { + bus_dmamap_sync(sc->fxp_mtag, txp->tx_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(sc->fxp_mtag, txp->tx_map); + m_freem(txp->tx_mbuf); + } + bus_dmamap_destroy(sc->fxp_mtag, txp->tx_map); + } bus_generic_detach(sc->dev); if (sc->miibus) device_delete_child(sc->dev, sc->miibus); - if (sc->cbl_base) - free(sc->cbl_base, M_DEVBUF); - if (sc->fxp_stats) - free(sc->fxp_stats, M_DEVBUF); - if (sc->mcsp) - free(sc->mcsp, M_DEVBUF); - if (sc->rfa_headm) - m_freem(sc->rfa_headm); - + if (sc->fxp_desc.cbl_list) { + bus_dmamap_unload(sc->cbl_tag, sc->cbl_map); + bus_dmamem_free(sc->cbl_tag, sc->fxp_desc.cbl_list, + sc->cbl_map); + } + if (sc->fxp_stats) { + bus_dmamap_unload(sc->fxp_stag, sc->fxp_smap); + bus_dmamem_free(sc->fxp_stag, sc->fxp_stats, sc->fxp_smap); + } + if (sc->mcsp) { + bus_dmamap_unload(sc->mcs_tag, sc->mcs_map); + bus_dmamem_free(sc->mcs_tag, sc->mcsp, sc->mcs_map); + } if (sc->ih) bus_teardown_intr(sc->dev, sc->irq, sc->ih); if (sc->irq) bus_release_resource(sc->dev, SYS_RES_IRQ, 0, sc->irq); if (sc->mem) bus_release_resource(sc->dev, sc->rtp, sc->rgd, sc->mem); + if (sc->fxp_mtag) + bus_dma_tag_destroy(sc->fxp_mtag); + if (sc->fxp_stag) + bus_dma_tag_destroy(sc->fxp_stag); + if (sc->cbl_tag) + bus_dma_tag_destroy(sc->cbl_tag); + if (sc->mcs_tag) + bus_dma_tag_destroy(sc->mcs_tag); sysctl_ctx_free(&sc->sysctl_ctx); @@ -1037,6 +1171,47 @@ fxp_eeprom_putword(sc, offset + i, data[i]); } +static void +fxp_dma_map_txbuf(void *arg, bus_dma_segment_t *segs, int nseg, + bus_size_t mapsize, int error) +{ + struct fxp_softc *sc; + struct fxp_cb_tx *txp; + int i; + + if (error) + return; + + KASSERT(nseg <= FXP_NTXSEG, ("too many DMA segments")); + + sc = arg; + txp = sc->fxp_desc.tx_last->tx_next->tx_cb; + for (i = 0; i < nseg; i++) { + KASSERT(segs[i].ds_len <= MCLBYTES, ("segment size too large")); + /* + * If this is an 82550/82551, then we're using extended + * TxCBs _and_ we're using checksum offload. This means + * that the TxCB is really an IPCB. One major difference + * between the two is that with plain extended TxCBs, + * the bottom half of the TxCB contains two entries from + * the TBD array, whereas IPCBs contain just one entry: + * one entry (8 bytes) has been sacrificed for the TCP/IP + * checksum offload control bits. So to make things work + * right, we have to start filling in the TBD array + * starting from a different place depending on whether + * the chip is an 82550/82551 or not. + */ + if (sc->flags & FXP_FLAG_EXT_RFA) { + txp->tbd[i + 1].tb_addr = segs[i].ds_addr; + txp->tbd[i + 1].tb_size = segs[i].ds_len; + } else { + txp->tbd[i].tb_addr = segs[i].ds_addr; + txp->tbd[i].tb_size = segs[i].ds_len; + } + } + txp->tbd_number = nseg; +} + /* * Start packet transmission on the interface. */ @@ -1044,8 +1219,9 @@ fxp_start(struct ifnet *ifp) { struct fxp_softc *sc = ifp->if_softc; - struct fxp_cb_tx *txp; - volatile struct fxp_tbd *bdptr; + struct fxp_tx *txp; + struct mbuf *mb_head; + int error; /* * See if we need to suspend xmit until the multicast filter @@ -1065,8 +1241,6 @@ * a NOP command when needed. */ while (ifp->if_snd.ifq_head != NULL && sc->tx_queued < FXP_NTXCB - 1) { - struct mbuf *m, *mb_head; - int segment; /* * Grab a packet to transmit. @@ -1076,27 +1250,9 @@ /* * Get pointer to next available tx desc. */ - txp = sc->cbl_last->next; + txp = sc->fxp_desc.tx_last->tx_next; /* - * If this is an 82550/82551, then we're using extended - * TxCBs _and_ we're using checksum offload. This means - * that the TxCB is really an IPCB. One major difference - * between the two is that with plain extended TxCBs, - * the bottom half of the TxCB contains two entries from - * the TBD array, whereas IPCBs contain just one entry: - * one entry (8 bytes) has been sacrificed for the TCP/IP - * checksum offload control bits. So to make things work - * right, we have to start filling in the TBD array - * starting from a different place depending on whether - * the chip is an 82550/82551 or not. - */ - - bdptr = &txp->tbd[0]; - if (sc->flags & FXP_FLAG_EXT_RFA) - bdptr++; - - /* * Deal with TCP/IP checksum offload. Note that * in order for TCP checksum offload to work, * the pseudo header checksum must have already @@ -1107,12 +1263,12 @@ if (mb_head->m_pkthdr.csum_flags) { if (mb_head->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { - txp->ipcb_ip_activation_high = + txp->tx_cb->ipcb_ip_activation_high = FXP_IPCB_HARDWAREPARSING_ENABLE; - txp->ipcb_ip_schedule = + txp->tx_cb->ipcb_ip_schedule = FXP_IPCB_TCPUDP_CHECKSUM_ENABLE; if (mb_head->m_pkthdr.csum_flags & CSUM_TCP) - txp->ipcb_ip_schedule |= + txp->tx_cb->ipcb_ip_schedule |= FXP_IPCB_TCP_PACKET; } #ifdef FXP_IP_CSUM_WAR @@ -1147,9 +1303,9 @@ ip->ip_hl << 2); mb_head->m_data -= ETHER_HDR_LEN; } else { - txp->ipcb_ip_activation_high = + txp->tx_cb->ipcb_ip_activation_high = FXP_IPCB_HARDWAREPARSING_ENABLE; - txp->ipcb_ip_schedule |= + txp->tx_cb->ipcb_ip_schedule |= FXP_IPCB_IP_CHECKSUM_ENABLE; } } @@ -1161,18 +1317,17 @@ * the transmit buffer descriptors with the physical address * and size of the mbuf. */ -tbdinit: - for (m = mb_head, segment = 0; m != NULL; m = m->m_next) { - if (m->m_len != 0) { - if (segment == (FXP_NTXSEG - 1)) - break; - bdptr[segment].tb_addr = - vtophys(mtod(m, vm_offset_t)); - bdptr[segment].tb_size = m->m_len; - segment++; - } + error = bus_dmamap_load_mbuf(sc->fxp_mtag, txp->tx_map, + mb_head, fxp_dma_map_txbuf, sc, 0); + + if (error && error != EFBIG) { + device_printf(sc->dev, "can't map mbuf (error %d)\n", + error); + m_freem(mb_head); + break; } - if (m != NULL) { + + if (error) { struct mbuf *mn; /* @@ -1198,19 +1353,28 @@ mn->m_pkthdr.len = mn->m_len = mb_head->m_pkthdr.len; m_freem(mb_head); mb_head = mn; - goto tbdinit; + error = bus_dmamap_load_mbuf(sc->fxp_mtag, txp->tx_map, + mb_head, fxp_dma_map_txbuf, sc, 0); + if (error) { + device_printf(sc->dev, + "can't map mbuf (error %d)\n", error); + m_freem(mb_head); + break; + } } - txp->byte_count = 0; - txp->tbd_number = segment; - txp->mb_head = mb_head; - txp->cb_status = 0; + bus_dmamap_sync(sc->fxp_mtag, txp->tx_map, + BUS_DMASYNC_PREWRITE); + + txp->tx_mbuf = mb_head; + txp->tx_cb->cb_status = 0; + txp->tx_cb->byte_count = 0; if (sc->tx_queued != FXP_CXINT_THRESH - 1) { - txp->cb_command = + txp->tx_cb->cb_command = sc->tx_cmd | FXP_CB_COMMAND_SF | FXP_CB_COMMAND_S; } else { - txp->cb_command = + txp->tx_cb->cb_command = sc->tx_cmd | FXP_CB_COMMAND_SF | FXP_CB_COMMAND_S | FXP_CB_COMMAND_I; /* @@ -1219,33 +1383,29 @@ */ ifp->if_timer = 5; } - txp->tx_threshold = tx_threshold; - + txp->tx_cb->tx_threshold = tx_threshold; + /* * Advance the end of list forward. */ -#ifdef __alpha__ /* * On platforms which can't access memory in 16-bit * granularities, we must prevent the card from DMA'ing * up the status while we update the command field. * This could cause us to overwrite the completion status. */ - atomic_clear_short(&sc->cbl_last->cb_command, + atomic_clear_short(&sc->fxp_desc.tx_last->tx_cb->cb_command, FXP_CB_COMMAND_S); -#else - sc->cbl_last->cb_command &= ~FXP_CB_COMMAND_S; -#endif /*__alpha__*/ - sc->cbl_last = txp; + sc->fxp_desc.tx_last = txp; /* * Advance the beginning of the list forward if there are - * no other packets queued (when nothing is queued, cbl_first + * no other packets queued (when nothing is queued, tx_first * sits on the last TxCB that was sent out). */ if (sc->tx_queued == 0) - sc->cbl_first = txp; + sc->fxp_desc.tx_first = txp; sc->tx_queued++; @@ -1254,6 +1414,7 @@ */ BPF_MTAP(ifp, mb_head); } + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); /* * We're finished. If we added to the list, issue a RESUME to get DMA @@ -1343,10 +1504,35 @@ } static void +fxp_txeof(struct fxp_softc *sc) +{ + struct fxp_tx *txp; + + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREREAD); + for (txp = sc->fxp_desc.tx_first; sc->tx_queued && + (txp->tx_cb->cb_status & FXP_CB_STATUS_C) != 0; + txp = txp->tx_next) { + if (txp->tx_mbuf != NULL) { + bus_dmamap_sync(sc->fxp_mtag, txp->tx_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(sc->fxp_mtag, txp->tx_map); + m_freem(txp->tx_mbuf); + txp->tx_mbuf = NULL; + /* clear this to reset csum offload bits */ + txp->tx_cb->tbd[0].tb_addr = 0; + } + sc->tx_queued--; + } + sc->fxp_desc.tx_first = txp; + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); +} + +static void fxp_intr_body(struct fxp_softc *sc, u_int8_t statack, int count) { struct ifnet *ifp = &sc->sc_if; struct mbuf *m; + struct fxp_rx *rxp; struct fxp_rfa *rfa; int rnr = (statack & FXP_SCB_STATACK_RNR) ? 1 : 0; @@ -1374,20 +1560,8 @@ * after the interface is ifconfig'ed for the first time. */ if (statack & (FXP_SCB_STATACK_CXTNO | FXP_SCB_STATACK_CNA)) { - struct fxp_cb_tx *txp; + fxp_txeof(sc); - for (txp = sc->cbl_first; sc->tx_queued && - (txp->cb_status & FXP_CB_STATUS_C) != 0; - txp = txp->next) { - if (txp->mb_head != NULL) { - m_freem(txp->mb_head); - txp->mb_head = NULL; - /* clear this to reset csum offload bits */ - txp->tbd[0].tb_addr = 0; - } - sc->tx_queued--; - } - sc->cbl_first = txp; ifp->if_timer = 0; if (sc->tx_queued == 0) { if (sc->need_mcsetup) @@ -1419,9 +1593,12 @@ * that the info will be used in the subsequent polling cycle. */ for (;;) { - m = sc->rfa_headm; + rxp = sc->fxp_desc.rx_head; + m = rxp->rx_mbuf; rfa = (struct fxp_rfa *)(m->m_ext.ext_buf + RFA_ALIGNMENT_FUDGE); + bus_dmamap_sync(sc->fxp_mtag, rxp->rx_map, + BUS_DMASYNC_POSTREAD); #ifdef DEVICE_POLLING /* loop at most count times if count >=0 */ if (count >= 0 && count-- == 0) { @@ -1434,21 +1611,20 @@ } #endif /* DEVICE_POLLING */ - if ( (rfa->rfa_status & FXP_RFA_STATUS_C) == 0) + if ((rfa->rfa_status & FXP_RFA_STATUS_C) == 0) break; /* - * Remove first packet from the chain. + * Advance head forward. */ - sc->rfa_headm = m->m_next; - m->m_next = NULL; + sc->fxp_desc.rx_head = rxp->rx_next; /* * Add a new buffer to the receive chain. * If this fails, the old buffer is recycled * instead. */ - if (fxp_add_rfabuf(sc, m) == 0) { + if (fxp_add_rfabuf(sc, rxp) == 0) { int total_len; /* @@ -1460,7 +1636,7 @@ total_len = rfa->actual_size & 0x3fff; if (total_len < sizeof(struct ether_header) || total_len > MCLBYTES - RFA_ALIGNMENT_FUDGE - - sizeof(struct fxp_rfa) || + sc->rfa_size || rfa->rfa_status & FXP_RFA_STATUS_CRC) { m_freem(m); continue; @@ -1495,8 +1671,7 @@ if (rnr) { fxp_scb_wait(sc); CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, - vtophys(sc->rfa_headm->m_ext.ext_buf) + - RFA_ALIGNMENT_FUDGE); + sc->fxp_desc.rx_head->rx_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_RU_START); } } @@ -1518,7 +1693,6 @@ struct fxp_softc *sc = xsc; struct ifnet *ifp = &sc->sc_if; struct fxp_stats *sp = sc->fxp_stats; - struct fxp_cb_tx *txp; int s; ifp->if_opackets += sp->tx_good; @@ -1546,6 +1720,7 @@ if (tx_threshold < 192) tx_threshold += 64; } + bus_dmamap_sync(sc->fxp_stag, sc->fxp_smap, BUS_DMASYNC_POSTREAD); s = splimp(); /* * Release any xmit buffers that have completed DMA. This isn't @@ -1554,18 +1729,8 @@ * than being defered for a potentially long time. This limits * the delay to a maximum of one second. */ - for (txp = sc->cbl_first; sc->tx_queued && - (txp->cb_status & FXP_CB_STATUS_C) != 0; - txp = txp->next) { - if (txp->mb_head != NULL) { - m_freem(txp->mb_head); - txp->mb_head = NULL; - /* clear this to reset csum offload bits */ - txp->tbd[0].tb_addr = 0; - } - sc->tx_queued--; - } - sc->cbl_first = txp; + fxp_txeof(sc); + /* * If we haven't received any packets in FXP_MAC_RX_IDLE seconds, * then assume the receiver has locked up and attempt to clear @@ -1588,6 +1753,8 @@ /* * Start another stats dump. */ + bus_dmamap_sync(sc->fxp_stag, sc->fxp_smap, + BUS_DMASYNC_PREREAD); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_DUMPRESET); } else { /* @@ -1622,7 +1789,7 @@ fxp_stop(struct fxp_softc *sc) { struct ifnet *ifp = &sc->sc_if; - struct fxp_cb_tx *txp; + struct fxp_tx *txp; int i; ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE); @@ -1646,36 +1813,22 @@ /* * Release any xmit buffers. */ - txp = sc->cbl_base; + txp = sc->fxp_desc.tx_list; if (txp != NULL) { for (i = 0; i < FXP_NTXCB; i++) { - if (txp[i].mb_head != NULL) { - m_freem(txp[i].mb_head); - txp[i].mb_head = NULL; + if (txp[i].tx_mbuf != NULL) { + bus_dmamap_sync(sc->fxp_mtag, txp[i].tx_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(sc->fxp_mtag, txp[i].tx_map); + m_freem(txp[i].tx_mbuf); + txp[i].tx_mbuf = NULL; /* clear this to reset csum offload bits */ - txp[i].tbd[0].tb_addr = 0; + txp[i].tx_cb->tbd[0].tb_addr = 0; } } } + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); sc->tx_queued = 0; - - /* - * Free all the receive buffers then reallocate/reinitialize - */ - if (sc->rfa_headm != NULL) - m_freem(sc->rfa_headm); - sc->rfa_headm = NULL; - sc->rfa_tailm = NULL; - for (i = 0; i < FXP_NRFABUFS; i++) { - if (fxp_add_rfabuf(sc, NULL) != 0) { - /* - * This "can't happen" - we're at splimp() - * and we just freed all the buffers we need - * above. - */ - panic("fxp_stop: no buffers!"); - } - } } /* @@ -1702,7 +1855,8 @@ struct ifnet *ifp = &sc->sc_if; struct fxp_cb_config *cbp; struct fxp_cb_ias *cb_ias; - struct fxp_cb_tx *txp; + struct fxp_cb_tx *tcbp; + struct fxp_tx *txp; struct fxp_cb_mcs *mcsp; int i, prm, s; @@ -1728,7 +1882,8 @@ * Initialize base of dump-stats buffer. */ fxp_scb_wait(sc); - CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, vtophys(sc->fxp_stats)); + bus_dmamap_sync(sc->fxp_stag, sc->fxp_smap, BUS_DMASYNC_PREREAD); + CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, sc->stats_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_DUMP_ADR); /* @@ -1749,10 +1904,13 @@ * Start the multicast setup command. */ fxp_scb_wait(sc); - CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, vtophys(&mcsp->cb_status)); + bus_dmamap_sync(sc->mcs_tag, sc->mcs_map, BUS_DMASYNC_PREWRITE); + CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, sc->mcs_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_START); /* ...and wait for it to complete. */ fxp_dma_wait(&mcsp->cb_status, sc); + bus_dmamap_sync(sc->mcs_tag, sc->mcs_map, + BUS_DMASYNC_POSTWRITE); } /* @@ -1760,16 +1918,14 @@ * construct the config CB. The TxCB list memory is rebuilt * later. */ - cbp = (struct fxp_cb_config *) sc->cbl_base; + cbp = (struct fxp_cb_config *)sc->fxp_desc.cbl_list; /* * This bcopy is kind of disgusting, but there are a bunch of must be * zero and must be one bits in this structure and this is the easiest * way to initialize them all to proper values. */ - bcopy(fxp_cb_config_template, - (void *)(uintptr_t)(volatile void *)&cbp->cb_status, - sizeof(fxp_cb_config_template)); + bcopy(fxp_cb_config_template, cbp, sizeof(fxp_cb_config_template)); cbp->cb_status = 0; cbp->cb_command = FXP_CB_COMMAND_CONFIG | FXP_CB_COMMAND_EL; @@ -1859,16 +2015,18 @@ * Start the config command/DMA. */ fxp_scb_wait(sc); - CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, vtophys(&cbp->cb_status)); + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); + CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, sc->fxp_desc.cbl_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_START); /* ...and wait for it to complete. */ fxp_dma_wait(&cbp->cb_status, sc); + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_POSTWRITE); /* * Now initialize the station address. Temporarily use the TxCB * memory area like we did above for the config CB. */ - cb_ias = (struct fxp_cb_ias *) sc->cbl_base; + cb_ias = (struct fxp_cb_ias *)sc->fxp_desc.cbl_list; cb_ias->cb_status = 0; cb_ias->cb_command = FXP_CB_COMMAND_IAS | FXP_CB_COMMAND_EL; cb_ias->link_addr = -1; @@ -1880,33 +2038,40 @@ * Start the IAS (Individual Address Setup) command/DMA. */ fxp_scb_wait(sc); + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_START); /* ...and wait for it to complete. */ fxp_dma_wait(&cb_ias->cb_status, sc); + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_POSTWRITE); /* * Initialize transmit control block (TxCB) list. */ - - txp = sc->cbl_base; - bzero(txp, sizeof(struct fxp_cb_tx) * FXP_NTXCB); + txp = sc->fxp_desc.tx_list; + tcbp = sc->fxp_desc.cbl_list; + bzero(tcbp, FXP_TXCB_SZ); for (i = 0; i < FXP_NTXCB; i++) { - txp[i].cb_status = FXP_CB_STATUS_C | FXP_CB_STATUS_OK; - txp[i].cb_command = FXP_CB_COMMAND_NOP; - txp[i].link_addr = - vtophys(&txp[(i + 1) & FXP_TXCB_MASK].cb_status); + txp[i].tx_cb = tcbp + i; + txp[i].tx_mbuf = NULL; + tcbp[i].cb_status = FXP_CB_STATUS_C | FXP_CB_STATUS_OK; + tcbp[i].cb_command = FXP_CB_COMMAND_NOP; + tcbp[i].link_addr = sc->fxp_desc.cbl_addr + + (((i + 1) & FXP_TXCB_MASK) * sizeof(struct fxp_cb_tx)); if (sc->flags & FXP_FLAG_EXT_TXCB) - txp[i].tbd_array_addr = vtophys(&txp[i].tbd[2]); + tcbp[i].tbd_array_addr = + FXP_TXCB_DMA_ADDR(sc, &tcbp[i].tbd[2]); else - txp[i].tbd_array_addr = vtophys(&txp[i].tbd[0]); - txp[i].next = &txp[(i + 1) & FXP_TXCB_MASK]; + tcbp[i].tbd_array_addr = + FXP_TXCB_DMA_ADDR(sc, &tcbp[i].tbd[0]); + txp[i].tx_next = &txp[(i + 1) & FXP_TXCB_MASK]; } /* * Set the suspend flag on the first TxCB and start the control * unit. It will execute the NOP and then suspend. */ - txp->cb_command = FXP_CB_COMMAND_NOP | FXP_CB_COMMAND_S; - sc->cbl_first = sc->cbl_last = txp; + tcbp->cb_command = FXP_CB_COMMAND_NOP | FXP_CB_COMMAND_S; + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); + sc->fxp_desc.tx_first = sc->fxp_desc.tx_last = txp; sc->tx_queued = 1; fxp_scb_wait(sc); @@ -1916,8 +2081,7 @@ * Initialize receiver buffer area - RFA. */ fxp_scb_wait(sc); - CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, - vtophys(sc->rfa_headm->m_ext.ext_buf) + RFA_ALIGNMENT_FUDGE); + CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, sc->fxp_desc.rx_head->rx_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_RU_START); /* @@ -2007,19 +2171,18 @@ * data pointer is fixed up to point just past it. */ static int -fxp_add_rfabuf(struct fxp_softc *sc, struct mbuf *oldm) +fxp_add_rfabuf(struct fxp_softc *sc, struct fxp_rx *rxp) { - u_int32_t v; struct mbuf *m; struct fxp_rfa *rfa, *p_rfa; + struct fxp_rx *p_rx; + bus_dmamap_t tmp_map; + u_int32_t v; + int error; m = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR); - if (m == NULL) { /* try to recycle the old mbuf instead */ - if (oldm == NULL) - return 1; - m = oldm; - m->m_data = m->m_ext.ext_buf; - } + if (m == NULL) + return (ENOBUFS); /* * Move the data pointer up so that the incoming data packet @@ -2033,8 +2196,7 @@ */ rfa = mtod(m, struct fxp_rfa *); m->m_data += sc->rfa_size; - rfa->size = (u_int16_t)(MCLBYTES - sizeof(struct fxp_rfa) - - RFA_ALIGNMENT_FUDGE); + rfa->size = MCLBYTES - sc->rfa_size - RFA_ALIGNMENT_FUDGE; /* * Initialize the rest of the RFA. Note that since the RFA @@ -2050,23 +2212,43 @@ fxp_lwcopy(&v, (volatile u_int32_t *) rfa->link_addr); fxp_lwcopy(&v, (volatile u_int32_t *) rfa->rbd_addr); + /* Map the RFA into DMA memory. */ + error = bus_dmamap_load(sc->fxp_mtag, sc->spare_map, rfa, + MCLBYTES - RFA_ALIGNMENT_FUDGE, fxp_dma_map_addr, + &rxp->rx_addr, 0); + if (error) { + m_freem(m); + return (error); + } + + bus_dmamap_unload(sc->fxp_mtag, rxp->rx_map); + tmp_map = sc->spare_map; + sc->spare_map = rxp->rx_map; + rxp->rx_map = tmp_map; + rxp->rx_mbuf = m; + + bus_dmamap_sync(sc->fxp_mtag, rxp->rx_map, BUS_DMASYNC_PREREAD); + /* * If there are other buffers already on the list, attach this * one to the end by fixing up the tail to point to this one. */ - if (sc->rfa_headm != NULL) { - p_rfa = (struct fxp_rfa *) (sc->rfa_tailm->m_ext.ext_buf + - RFA_ALIGNMENT_FUDGE); - sc->rfa_tailm->m_next = m; - v = vtophys(rfa); - fxp_lwcopy(&v, (volatile u_int32_t *) p_rfa->link_addr); + if (sc->fxp_desc.rx_head != NULL) { + p_rx = sc->fxp_desc.rx_tail; + p_rfa = (struct fxp_rfa *) + (p_rx->rx_mbuf->m_ext.ext_buf + RFA_ALIGNMENT_FUDGE); + p_rx->rx_next = rxp; + fxp_lwcopy(&rxp->rx_addr, + (volatile u_int32_t *)p_rfa->link_addr); p_rfa->rfa_control = 0; + bus_dmamap_sync(sc->fxp_mtag, p_rx->rx_map, + BUS_DMASYNC_PREREAD); } else { - sc->rfa_headm = m; + rxp->rx_next = NULL; + sc->fxp_desc.rx_head = rxp; } - sc->rfa_tailm = m; - - return (m == oldm); + sc->fxp_desc.rx_tail = rxp; + return (0); } static volatile int @@ -2231,6 +2413,7 @@ { struct fxp_cb_mcs *mcsp = sc->mcsp; struct ifnet *ifp = &sc->sc_if; + struct fxp_tx *txp; int count; /* @@ -2241,8 +2424,6 @@ * TX commands will be added when need_mcsetup is true. */ if (sc->tx_queued) { - struct fxp_cb_tx *txp; - /* * need_mcsetup will be true if we are already waiting for the * NOP command to be completed (see below). In this case, bail. @@ -2255,16 +2436,17 @@ * Add a NOP command with interrupt so that we are notified * when all TX commands have been processed. */ - txp = sc->cbl_last->next; - txp->mb_head = NULL; - txp->cb_status = 0; - txp->cb_command = FXP_CB_COMMAND_NOP | + txp = sc->fxp_desc.tx_last->tx_next; + txp->tx_mbuf = NULL; + txp->tx_cb->cb_status = 0; + txp->tx_cb->cb_command = FXP_CB_COMMAND_NOP | FXP_CB_COMMAND_S | FXP_CB_COMMAND_I; + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); /* * Advance the end of list forward. */ - sc->cbl_last->cb_command &= ~FXP_CB_COMMAND_S; - sc->cbl_last = txp; + sc->fxp_desc.tx_last->tx_cb->cb_command &= ~FXP_CB_COMMAND_S; + sc->fxp_desc.tx_last = txp; sc->tx_queued++; /* * Issue a resume in case the CU has just suspended. @@ -2284,14 +2466,17 @@ /* * Initialize multicast setup descriptor. */ - mcsp->next = sc->cbl_base; - mcsp->mb_head = NULL; + bus_dmamap_sync(sc->mcs_tag, sc->mcs_map, BUS_DMASYNC_POSTWRITE); mcsp->cb_status = 0; mcsp->cb_command = FXP_CB_COMMAND_MCAS | FXP_CB_COMMAND_S | FXP_CB_COMMAND_I; - mcsp->link_addr = vtophys(&sc->cbl_base->cb_status); + mcsp->link_addr = sc->fxp_desc.cbl_addr; + txp = &sc->fxp_desc.mcs_tx; + txp->tx_mbuf = NULL; + txp->tx_cb = (struct fxp_cb_tx *)sc->mcsp; + txp->tx_next = sc->fxp_desc.tx_list; (void) fxp_mc_addrs(sc); - sc->cbl_first = sc->cbl_last = (struct fxp_cb_tx *) mcsp; + sc->fxp_desc.tx_first = sc->fxp_desc.tx_last = txp; sc->tx_queued = 1; /* @@ -2311,7 +2496,8 @@ * Start the multicast setup command. */ fxp_scb_wait(sc); - CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, vtophys(&mcsp->cb_status)); + bus_dmamap_sync(sc->mcs_tag, sc->mcs_map, BUS_DMASYNC_PREWRITE); + CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, sc->mcs_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_START); ifp->if_timer = 2; @@ -2358,7 +2544,7 @@ break; if (uc->ucode == NULL) return; - cbp = (struct fxp_cb_ucode *)sc->cbl_base; + cbp = (struct fxp_cb_ucode *)sc->fxp_desc.cbl_list; cbp->cb_status = 0; cbp->cb_command = FXP_CB_COMMAND_UCODE | FXP_CB_COMMAND_EL; cbp->link_addr = -1; /* (no) next command */ @@ -2373,10 +2559,12 @@ * Download the ucode to the chip. */ fxp_scb_wait(sc); - CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, vtophys(&cbp->cb_status)); + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_PREWRITE); + CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL, sc->fxp_desc.cbl_addr); fxp_scb_cmd(sc, FXP_SCB_COMMAND_CU_START); /* ...and wait for it to complete. */ fxp_dma_wait(&cbp->cb_status, sc); + bus_dmamap_sync(sc->cbl_tag, sc->cbl_map, BUS_DMASYNC_POSTWRITE); device_printf(sc->dev, "Microcode loaded, int_delay: %d usec bundle_max: %d\n", sc->tunable_int_delay, --- //depot/vendor/freebsd/src/sys/dev/fxp/if_fxpreg.h 2003/02/26 14:15:17 +++ //depot/user/mux/busdma/dev/fxp/if_fxpreg.h 2003/03/30 15:55:57 @@ -111,13 +111,11 @@ * Command block definitions */ struct fxp_cb_nop { - void *fill[2]; volatile u_int16_t cb_status; volatile u_int16_t cb_command; volatile u_int32_t link_addr; }; struct fxp_cb_ias { - void *fill[2]; volatile u_int16_t cb_status; volatile u_int16_t cb_command; volatile u_int32_t link_addr; @@ -125,7 +123,6 @@ }; /* I hate bit-fields :-( */ struct fxp_cb_config { - void *fill[2]; volatile u_int16_t cb_status; volatile u_int16_t cb_command; volatile u_int32_t link_addr; @@ -215,8 +212,6 @@ #define MAXMCADDR 80 struct fxp_cb_mcs { - struct fxp_cb_tx *next; - struct mbuf *mb_head; volatile u_int16_t cb_status; volatile u_int16_t cb_command; volatile u_int32_t link_addr; @@ -226,7 +221,6 @@ #define MAXUCODESIZE 192 struct fxp_cb_ucode { - void *fill[2]; u_int16_t cb_status; u_int16_t cb_command; u_int32_t link_addr; @@ -234,13 +228,9 @@ }; /* - * Number of DMA segments in a TxCB. Note that this is carefully - * chosen to make the total struct size an even power of two. It's - * critical that no TxCB be split across a page boundry since - * no attempt is made to allocate physically contiguous memory. + * Number of DMA segments in a TxCB. */ -#define FXP_TXCB_FIXED 16 /* cb_status .. tbd_number */ -#define FXP_NTXSEG ((256 - (sizeof(void *) * 2) - FXP_TXCB_FIXED) / 8) +#define FXP_NTXSEG 32 struct fxp_tbd { volatile u_int32_t tb_addr; @@ -268,8 +258,6 @@ }; struct fxp_cb_tx { - struct fxp_cb_tx *next; - struct mbuf *mb_head; volatile u_int16_t cb_status; volatile u_int16_t cb_command; volatile u_int32_t link_addr; --- //depot/vendor/freebsd/src/sys/dev/fxp/if_fxpvar.h 2003/02/26 14:15:17 +++ //depot/user/mux/busdma/dev/fxp/if_fxpvar.h 2003/03/31 15:30:37 @@ -40,6 +40,19 @@ #define FXP_NTXCB 128 /* + * Size of the TxCB list. + */ +#define FXP_TXCB_SZ (FXP_NTXCB * sizeof(struct fxp_cb_tx)) + +/* + * Macro to obtain the DMA address of a virtual address in the + * TxCB list based on the base DMA address of the TxCB list. + */ +#define FXP_TXCB_DMA_ADDR(sc, addr) \ + (sc->fxp_desc.cbl_addr + (uintptr_t)addr - \ + (uintptr_t)sc->fxp_desc.cbl_list) + +/* * Number of completed TX commands at which point an interrupt * will be generated to garbage collect the attached buffers. * Must be at least one less than FXP_NTXCB, and should be @@ -99,10 +112,36 @@ #define FXP_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx) #endif -#ifdef __alpha__ -#undef vtophys -#define vtophys(va) alpha_XXX_dmamap((vm_offset_t)(va)) -#endif /* __alpha__ */ +/* + * Structures to handle TX and RX descriptors. + */ +struct fxp_rx { + struct fxp_rx *rx_next; + struct mbuf *rx_mbuf; + bus_dmamap_t rx_map; + u_int32_t rx_addr; +}; + +struct fxp_tx { + struct fxp_tx *tx_next; + struct fxp_cb_tx *tx_cb; + struct mbuf *tx_mbuf; + bus_dmamap_t tx_map; +}; + +struct fxp_desc_list { + struct fxp_rx rx_list[FXP_NRFABUFS]; + struct fxp_tx tx_list[FXP_NTXCB]; + struct fxp_tx mcs_tx; + struct fxp_rx *rx_head; + struct fxp_rx *rx_tail; + struct fxp_tx *tx_first; + struct fxp_tx *tx_last; + struct fxp_rfa *rfa_list; + struct fxp_cb_tx *cbl_list; + u_int32_t cbl_addr; + bus_dma_tag_t rx_tag; +}; /* * NOTE: Elements are ordered for optimal cacheline behavior, and NOT @@ -118,17 +157,23 @@ struct mtx sc_mtx; bus_space_tag_t sc_st; /* bus space tag */ bus_space_handle_t sc_sh; /* bus space handle */ - struct mbuf *rfa_headm; /* first mbuf in receive frame area */ - struct mbuf *rfa_tailm; /* last mbuf in receive frame area */ - struct fxp_cb_tx *cbl_first; /* first active TxCB in list */ + bus_dma_tag_t fxp_mtag; /* bus DMA tag for mbufs */ + bus_dma_tag_t fxp_stag; /* bus DMA tag for stats */ + bus_dmamap_t fxp_smap; /* bus DMA map for stats */ + bus_dma_tag_t cbl_tag; /* DMA tag for the TxCB list */ + bus_dmamap_t cbl_map; /* DMA map for the TxCB list */ + bus_dma_tag_t mcs_tag; /* DMA tag for the multicast setup */ + bus_dmamap_t mcs_map; /* DMA map for the multicast setup */ + bus_dmamap_t spare_map; /* spare DMA map */ + struct fxp_desc_list fxp_desc; /* descriptors management struct */ int tx_queued; /* # of active TxCB's */ int need_mcsetup; /* multicast filter needs programming */ - struct fxp_cb_tx *cbl_last; /* last active TxCB in list */ struct fxp_stats *fxp_stats; /* Pointer to interface stats */ + u_int32_t stats_addr; /* DMA address of the stats structure */ int rx_idle_secs; /* # of seconds RX has been idle */ struct callout_handle stat_ch; /* Handle for canceling our stat timeout */ - struct fxp_cb_tx *cbl_base; /* base of TxCB list */ struct fxp_cb_mcs *mcsp; /* Pointer to mcast setup descriptor */ + u_int32_t mcs_addr; /* DMA address of the multicast cmd */ struct ifmedia sc_media; /* media information */ device_t miibus; device_t dev; --VywGB/WGlW4DM4P8-- From owner-freebsd-alpha@FreeBSD.ORG Tue Apr 1 06:03:08 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 862CF37B404 for ; Tue, 1 Apr 2003 06:03:08 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BF1543F75 for ; Tue, 1 Apr 2003 06:03:07 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h31E35MS018172 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Apr 2003 09:03:05 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h31E30w28957; Tue, 1 Apr 2003 09:03:00 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16009.39956.192664.42414@grasshopper.cs.duke.edu> Date: Tue, 1 Apr 2003 09:03:00 -0500 (EST) To: Oliver Lehmann In-Reply-To: <20030331233509.21ba9cce.lehmann@ans-netz.de> References: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> <20030331181836.0c9b67d0.lehmann@ans-netz.de> <16008.28257.658768.820352@grasshopper.cs.duke.edu> <20030331213003.4e67d88f.lehmann@ans-netz.de> <16008.40619.177277.973890@grasshopper.cs.duke.edu> <20030331233509.21ba9cce.lehmann@ans-netz.de> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-alpha@freebsd.org Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 14:03:08 -0000 Ah, OK. DMA is definately a problem. Try the appended patch. Drew Index: dev/pdq/pdq_freebsd.h =================================================================== RCS file: /home/ncvs/src/sys/dev/pdq/pdq_freebsd.h,v retrieving revision 1.2 diff -u -r1.2 pdq_freebsd.h --- dev/pdq/pdq_freebsd.h 2 Jun 2002 20:05:46 -0000 1.2 +++ dev/pdq/pdq_freebsd.h 1 Apr 2003 14:01:41 -0000 @@ -165,7 +165,11 @@ #define PDQ_OS_CSR_FMT "0x%x" #define PDQ_OS_USEC_DELAY(n) DELAY(n) +#ifdef __alpha__ +#define PDQ_OS_VA_TO_BUSPA(pdq, p) alpha_XXX_dmamap((vm_offset_t)p) +#else #define PDQ_OS_VA_TO_BUSPA(pdq, p) vtophys(p) +#endif #define PDQ_OS_MEMALLOC(n) malloc(n, M_DEVBUF, M_NOWAIT) #define PDQ_OS_MEMFREE(p, n) free((void *) p, M_DEVBUF) From owner-freebsd-alpha@FreeBSD.ORG Tue Apr 1 08:18:59 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9194337B401 for ; Tue, 1 Apr 2003 08:18:59 -0800 (PST) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [80.86.187.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06E1643FCB for ; Tue, 1 Apr 2003 08:18:58 -0800 (PST) (envelope-from lehmann@ans-netz.de) Received: (qmail 19894 invoked from network); 1 Apr 2003 16:18:53 -0000 Received: from unknown (HELO dill.salatschuessel.net) (217.226.30.2) by avocado.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 1 Apr 2003 16:18:53 -0000 Received: (qmail 706 invoked from network); 1 Apr 2003 16:18:55 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (10.0.1.51) by dill.salatschuessel.net with DES-CBC3-SHA encrypted SMTP; 1 Apr 2003 16:18:55 -0000 Received: from kartoffel.salatschuessel.net (localhost [127.0.0.1]) h31FtoJG005633; Tue, 1 Apr 2003 17:55:51 +0200 (CEST) (envelope-from lehmann@ans-netz.de) Date: Tue, 1 Apr 2003 17:55:50 +0200 From: Oliver Lehmann To: Andrew Gallatin Message-Id: <20030401175550.40e1bb92.lehmann@ans-netz.de> In-Reply-To: <16009.39956.192664.42414@grasshopper.cs.duke.edu> References: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> <20030331181836.0c9b67d0.lehmann@ans-netz.de> <16008.28257.658768.820352@grasshopper.cs.duke.edu> <20030331213003.4e67d88f.lehmann@ans-netz.de> <16008.40619.177277.973890@grasshopper.cs.duke.edu> <20030331233509.21ba9cce.lehmann@ans-netz.de> <16009.39956.192664.42414@grasshopper.cs.duke.edu> X-Mailer: Sylpheed version 0.8.11cvs14 (GTK+ 1.2.10; i386-unknown-freebsdelf4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-alpha@freebsd.org Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 16:18:59 -0000 Andrew Gallatin wrote: > Index: dev/pdq/pdq_freebsd.h > =================================================================== > RCS file: /home/ncvs/src/sys/dev/pdq/pdq_freebsd.h,v > retrieving revision 1.2 > diff -u -r1.2 pdq_freebsd.h > --- dev/pdq/pdq_freebsd.h 2 Jun 2002 20:05:46 -0000 1.2 > +++ dev/pdq/pdq_freebsd.h 1 Apr 2003 14:01:41 -0000 > @@ -165,7 +165,11 @@ > #define PDQ_OS_CSR_FMT "0x%x" > > #define PDQ_OS_USEC_DELAY(n) DELAY(n) > +#ifdef __alpha__ > +#define PDQ_OS_VA_TO_BUSPA(pdq, p) alpha_XXX_dmamap((vm_offset_t)p) > +#else > #define PDQ_OS_VA_TO_BUSPA(pdq, p) vtophys(p) > +#endif > > #define PDQ_OS_MEMALLOC(n) malloc(n, M_DEVBUF, M_NOWAIT) > #define PDQ_OS_MEMFREE(p, n) free((void *) p, M_DEVBUF) > > After rebooting with a new kernel which has both patches applied (this, and still the 1st one), i got: fpa0: port 0x10180-0x101ff mem 0x82030000-0x8203ffff,0x82041180-0x820411ff irq 3 at device 9.0 on pci0 fpa0: DEC DEFPA PCI FDDI SAS Controller fpa0: FDDI address 00:a0:24:61:dd:36, FW=2.46, HW=1, SMT V7.2 fpa0: FDDI Port = S (PMD = ANSI Multi-Mode) fpa0: interrupting at CIA irq 3 panic: mutex fpa 0xfffffc0000900da0 already initialized panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 db> By the way, why didn't apeear your mails on the mailinglist? Greetings, Oliver -- Oliver Lehmann @home: lehmann@ans-netz.de @office: oliver.lehmann@mgi.de @www: http://www.pofo.de/ | http://wishlist.ans-netz.de/ From owner-freebsd-alpha@FreeBSD.ORG Tue Apr 1 08:32:51 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A334037B401 for ; Tue, 1 Apr 2003 08:32:51 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4BE243F93 for ; Tue, 1 Apr 2003 08:32:50 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h31GWmMS002299 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Apr 2003 11:32:49 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h31GWho29068; Tue, 1 Apr 2003 11:32:43 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16009.48939.810313.81256@grasshopper.cs.duke.edu> Date: Tue, 1 Apr 2003 11:32:43 -0500 (EST) To: Oliver Lehmann In-Reply-To: <20030401175550.40e1bb92.lehmann@ans-netz.de> References: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> <20030331181836.0c9b67d0.lehmann@ans-netz.de> <16008.28257.658768.820352@grasshopper.cs.duke.edu> <20030331213003.4e67d88f.lehmann@ans-netz.de> <16008.40619.177277.973890@grasshopper.cs.duke.edu> <20030331233509.21ba9cce.lehmann@ans-netz.de> <16009.39956.192664.42414@grasshopper.cs.duke.edu> <20030401175550.40e1bb92.lehmann@ans-netz.de> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-alpha@freebsd.org Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 16:32:51 -0000 Oliver Lehmann writes: > > fpa0: port 0x10180-0x101ff mem > 0x82030000-0x8203ffff,0x82041180-0x820411ff irq 3 at device 9.0 on pci0 > fpa0: DEC DEFPA PCI FDDI SAS Controller > fpa0: FDDI address 00:a0:24:61:dd:36, FW=2.46, HW=1, SMT V7.2 > fpa0: FDDI Port = S (PMD = ANSI Multi-Mode) > fpa0: interrupting at CIA irq 3 Cool! I've just committed the DMA patch to -current. Next time you reboot, please try without the first patch (PCI_RF_DENSE). > panic: mutex fpa 0xfffffc0000900da0 already initialized > panic > Stopped at Debugger+0x34: zapnot v0,#0xf,v0 > db> A trace would be really helpful here. > > By the way, why didn't apear your mails on the mailinglist? I dunno. I got it.. Drew From owner-freebsd-alpha@FreeBSD.ORG Tue Apr 1 09:13:32 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FFA137B401; Tue, 1 Apr 2003 09:13:32 -0800 (PST) Received: from gatekeeper.oremut01.us.wh.verio.net (gatekeeper.oremut01.us.wh.verio.net [198.65.168.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id C699143FA3; Tue, 1 Apr 2003 09:13:31 -0800 (PST) (envelope-from fclift@verio.net) Received: from mx.dmz.orem.verio.net (mx.dmz.orem.verio.net [10.1.1.10]) by gatekeeper.oremut01.us.wh.verio.net (Postfix) with ESMTP id 3425C3BF118; Tue, 1 Apr 2003 10:13:29 -0700 (MST) Received: from vespa.dmz.orem.verio.net (vespa.dmz.orem.verio.net [10.1.1.59]) by mx.dmz.orem.verio.net (8.11.6p2/8.11.6) with ESMTP id h31HDSA41084; Tue, 1 Apr 2003 10:13:28 -0700 (MST) Date: Tue, 1 Apr 2003 10:16:23 -0700 (MST) From: Fred Clift X-X-Sender: To: Maxime Henrion In-Reply-To: <20030401115802.GB1750@elvis.mu.org> Message-ID: <20030401101427.O79076-100000@vespa.dmz.orem.verio.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: alpha@freebsd.org Subject: Re: call for testers: busdma-ified fxp(4) driver X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 17:13:32 -0000 On Tue, 1 Apr 2003, Maxime Henrion wrote: > It would be of a great help if someone with an alpha box and a fxp(4) > card could test this patch since I lack the necessary hardware. I might be able to make some time this evening - I have a couple or 3 different revs of fxp cards and a pws 400au to try them in. Just looking for basic functionality? You want netperf performance numbers or something? Fred -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. From owner-freebsd-alpha@FreeBSD.ORG Tue Apr 1 09:19:23 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E78E437B401 for ; Tue, 1 Apr 2003 09:19:23 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77CAF43FA3 for ; Tue, 1 Apr 2003 09:19:23 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 5DCCF2ED428; Tue, 1 Apr 2003 09:19:21 -0800 (PST) Date: Tue, 1 Apr 2003 19:19:21 +0200 From: Maxime Henrion To: Fred Clift Message-ID: <20030401171921.GD1750@elvis.mu.org> References: <20030401115802.GB1750@elvis.mu.org> <20030401101427.O79076-100000@vespa.dmz.orem.verio.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030401101427.O79076-100000@vespa.dmz.orem.verio.net> User-Agent: Mutt/1.4.1i cc: alpha@freebsd.org Subject: Re: call for testers: busdma-ified fxp(4) driver X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 17:19:24 -0000 Fred Clift wrote: > On Tue, 1 Apr 2003, Maxime Henrion wrote: > > > It would be of a great help if someone with an alpha box and a fxp(4) > > card could test this patch since I lack the necessary hardware. > > I might be able to make some time this evening - I have a couple or 3 > different revs of fxp cards and a pws 400au to try them in. Just looking > for basic functionality? You want netperf performance numbers or > something? I'm mostly interested in knowing if it still works with this patch. Of course, netperf numbers would be interesting to have, to make sure I didn't kill performance somehow :-). By the way, I was a bit fast when writing this e-mail, and I forgot to mention that this patch is for -CURRENT. Thanks, Maxime From owner-freebsd-alpha@FreeBSD.ORG Tue Apr 1 17:51:56 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76F0537B401; Tue, 1 Apr 2003 17:51:56 -0800 (PST) Received: from alcanet.com.au (mail2.alcanet.com.au [203.62.196.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F4B543F3F; Tue, 1 Apr 2003 17:51:54 -0800 (PST) (envelope-from peter.jeremy@alcatel.com.au) Received: from sydsmtp01.alcatel.com.au (IDENT:root@localhost.localdomain [127.0.0.1])h321pcd6015494; Wed, 2 Apr 2003 11:51:39 +1000 Received: from gsmx07.alcatel.com.au ([139.188.20.247]) by sydsmtp01.alcatel.com.au (Lotus Domino Release 5.0.11) with ESMTP id 2003040211513617:18069 ; Wed, 2 Apr 2003 11:51:36 +1000 Received: from gsmx07.alcatel.com.au (localhost [127.0.0.1]) by gsmx07.alcatel.com.au (8.12.8/8.12.5) with ESMTP id h321paai026223; Wed, 2 Apr 2003 11:51:36 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.12.8/8.12.5/Submit) id h321pTjx026222; Wed, 2 Apr 2003 11:51:29 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Date: Wed, 2 Apr 2003 11:51:29 +1000 From: Peter Jeremy To: Andrew Gallatin Message-ID: <20030402015129.GH310@gsmx07.alcatel.com.au> Mail-Followup-To: Andrew Gallatin , Oliver Lehmann , freebsd-alpha@freebsd.org, peter@freebsd.org References: <003901c2f6e2$3f1c0d40$0a04a8c0@PLANETEORANGE.CA> <20030331181836.0c9b67d0.lehmann@ans-netz.de> <16008.28257.658768.820352@grasshopper.cs.duke.edu> <20030331213003.4e67d88f.lehmann@ans-netz.de> <16008.40619.177277.973890@grasshopper.cs.duke.edu> <20030331233509.21ba9cce.lehmann@ans-netz.de> <16009.39956.192664.42414@grasshopper.cs.duke.edu> <20030401175550.40e1bb92.lehmann@ans-netz.de> <16009.48939.810313.81256@grasshopper.cs.duke.edu> Mime-Version: 1.0 In-Reply-To: <16009.48939.810313.81256@grasshopper.cs.duke.edu> User-Agent: Mutt/1.4i X-MIMETrack: Itemize by SMTP Server on SYDSMTP01/AlcatelAustralia(Release 5.0.11 |July 24, 2002) at 02/04/2003 11:51:36 AM,|July 24, 2002) at 02/04/2003 11:51:39 AM, Serialize complete at 02/04/2003 11:51:39 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline cc: peter@freebsd.org cc: freebsd-alpha@freebsd.org Subject: Re: Does anyone use a FDDI card on 5.0? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 01:51:56 -0000 On 2003-Apr-01 11:32:43 -0500, Andrew Gallatin wrote: > >Oliver Lehmann writes: > > By the way, why didn't apear your mails on the mailinglist? > >I dunno. I got it.. I've noticed this as well - but only recently. Does mailmail check the To and Cc lists and strip any names it finds out of the mailing list distribution? Peter From owner-freebsd-alpha@FreeBSD.ORG Wed Apr 2 03:47:45 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABC0837B401 for ; Wed, 2 Apr 2003 03:47:45 -0800 (PST) Received: from chuggalug.clues.com (chuggalug.clues.com [194.159.1.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCC8643FBF for ; Wed, 2 Apr 2003 03:47:44 -0800 (PST) (envelope-from geoffb@chuggalug.clues.com) Received: from chuggalug.clues.com (localhost [127.0.0.1]) by chuggalug.clues.com (8.12.6/8.9.3) with ESMTP id h32CPbvv033108 for ; Wed, 2 Apr 2003 13:25:37 +0100 (BST) (envelope-from geoffb@chuggalug.clues.com) Received: (from geoffb@localhost) by chuggalug.clues.com (8.12.6/8.12.6/Submit) id h32CPajV033107 for freebsd-alpha@freebsd.org; Wed, 2 Apr 2003 13:25:36 +0100 (BST) Date: Wed, 2 Apr 2003 13:25:36 +0100 From: Geoff Buckingham To: freebsd-alpha@freebsd.org Message-ID: <20030402122536.GA33078@chuggalug.clues.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: de500 duplex settings in 5.0 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 11:47:46 -0000 Yesterday I discovered that the de500 in my AS800 has been running at 10baseT/UTP, half duplex since I installed 5.0. 'ifconfig de0 media X mediaopt Y' seems to work and ifconfig shows the new setting in effect, however the switch port is still at 10baseT and half duplex. Setting the switch port to agree with the new setting (100baseTX full-duplex) breaks connectivity. However if the switch is left alone the link continues to run at 10baseT half duplex, allthough ifconfig reports 100baseTX full-duplex. It would seem ifconfig media has no effect on the physical interface. I tried replacing the nic with another de500, which had the same problem. Using a dc card fixed this. Searching through the mailing list I saw one person with the same what looked like the same problem, they had also switched nics to fix the problem. Is this a known problem? I don't want to raise a PR for something that is fixed. From owner-freebsd-alpha@FreeBSD.ORG Wed Apr 2 04:04:35 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2138037B401 for ; Wed, 2 Apr 2003 04:04:35 -0800 (PST) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id F405E43FAF for ; Wed, 2 Apr 2003 04:04:33 -0800 (PST) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.8/8.12.8) with ESMTP id h32C4Vmk015360; Wed, 2 Apr 2003 14:04:31 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.8/8.12.8/Submit) id h32C4VFF015359; Wed, 2 Apr 2003 14:04:31 +0200 (CEST) Date: Wed, 2 Apr 2003 14:04:31 +0200 From: Wilko Bulte To: Geoff Buckingham Message-ID: <20030402120431.GA15344@freebie.xs4all.nl> References: <20030402122536.GA33078@chuggalug.clues.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030402122536.GA33078@chuggalug.clues.com> User-Agent: Mutt/1.4i X-OS: FreeBSD 4.8-RC X-PGP: finger wilko@freebsd.org cc: freebsd-alpha@freebsd.org Subject: Re: de500 duplex settings in 5.0 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 12:04:35 -0000 On Wed, Apr 02, 2003 at 01:25:36PM +0100, Geoff Buckingham wrote: What is the SRM variable ewa0_mode set to? (or ewb0_mode if your DE500 is the 2nd NIC etc) Wilko > Yesterday I discovered that the de500 in my AS800 > has been running at 10baseT/UTP, half duplex since > I installed 5.0. > > 'ifconfig de0 media X mediaopt Y' > > seems to work and ifconfig shows the new setting in > effect, however the switch port is still at 10baseT > and half duplex. Setting the switch port to agree > with the new setting (100baseTX full-duplex) breaks > connectivity. However if the switch is left alone the > link continues to run at 10baseT half duplex, allthough > ifconfig reports 100baseTX full-duplex. > > It would seem ifconfig media has no effect on the physical > interface. > > I tried replacing the nic with another de500, which had > the same problem. Using a dc card fixed this. > > Searching through the mailing list I saw one person with > the same what looked like the same problem, they had also > switched nics to fix the problem. > > Is this a known problem? I don't want to raise a PR for > something that is fixed. > _______________________________________________ > freebsd-alpha@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-alpha > To unsubscribe, send any mail to "freebsd-alpha-unsubscribe@freebsd.org" ---end of quoted text--- -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte From owner-freebsd-alpha@FreeBSD.ORG Wed Apr 2 04:08:16 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2479737B404 for ; Wed, 2 Apr 2003 04:08:16 -0800 (PST) Received: from lyra.enemy.org (lyra.enemy.org [62.116.11.42]) by mx1.FreeBSD.org (Postfix) with SMTP id 5786343FAF for ; Wed, 2 Apr 2003 04:08:14 -0800 (PST) (envelope-from cjm@satanii.enemy.org) Received: (qmail 17358 invoked from network); 2 Apr 2003 12:08:06 -0000 Received: from unknown (HELO satanii.enemy.org) (62.116.11.3) by lyra.enemy.org with SMTP; 2 Apr 2003 12:08:06 -0000 Received: from satanii.enemy.org (cjm@localhost [127.0.0.1]) by satanii.enemy.org (8.12.6p2/8.12.6) with ESMTP id h32C8D0j020495; Wed, 2 Apr 2003 14:08:13 +0200 (CEST) (envelope-from cjm@satanii.enemy.org) Message-Id: <200304021208.h32C8D0j020495@satanii.enemy.org> From: "Chris J. Mutter" To: freebsd-alpha@freebsd.org X-Mailer: NMH-1.4 Date: Wed, 02 Apr 2003 14:08:13 +0200 Sender: cjm@satanii.enemy.org cc: msmith@freebsd.org Subject: mylex dac960pu on alpha X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 12:08:16 -0000 hi, i have a question to the dac960pu: can this controller under firmware 2.x work with LVD drives bigger than 9gig? i would like to know this before i order drives. 2nd thing: with 4.7R i still had this error: /kernel: mlx0: I/O error - attempt to write beyond end of drive the workaround from here: http://www.geocrawler.com/archives/3/168/2001/5/50/5707924/ works well... and doesnt crash the machine. im not sure if this is a alpha-only problem but it doesnt seem so: -> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21220 critical, open since 4.1R ... i could provide a alpha hanging on a serial console for testing if that would help... greetings, cjm From owner-freebsd-alpha@FreeBSD.ORG Wed Apr 2 08:22:06 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3564D37B401; Wed, 2 Apr 2003 08:22:06 -0800 (PST) Received: from gatekeeper.oremut01.us.wh.verio.net (gatekeeper.oremut01.us.wh.verio.net [198.65.168.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20D5F43FCB; Wed, 2 Apr 2003 08:22:05 -0800 (PST) (envelope-from fclift@verio.net) Received: from mx.dmz.orem.verio.net (mx.dmz.orem.verio.net [10.1.1.10]) by gatekeeper.oremut01.us.wh.verio.net (Postfix) with ESMTP id AE6F63BF1AC; Wed, 2 Apr 2003 09:22:04 -0700 (MST) Received: from vespa.dmz.orem.verio.net (vespa.dmz.orem.verio.net [10.1.1.59]) by mx.dmz.orem.verio.net (8.11.6p2/8.11.6) with ESMTP id h32GM4A90212; Wed, 2 Apr 2003 09:22:04 -0700 (MST) Date: Wed, 2 Apr 2003 09:25:04 -0700 (MST) From: Fred Clift X-X-Sender: To: Maxime Henrion In-Reply-To: <20030401134113.GC1750@elvis.mu.org> Message-ID: <20030402090802.Y82002-400000@vespa.dmz.orem.verio.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-54798573-1049300704=:82002" cc: alpha@freebsd.org Subject: Re: call for testers: busdma-ified fxp(4) driver X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 16:22:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-54798573-1049300704=:82002 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Apr 2003, Maxime Henrion wrote: > > My fxp(4) patch should now be nearly commit ready. ... > > someone with an alpha box and a fxp(4) card could test this patch > > Sorry to follow-up to myself, but this patch had some bogus and > irrelevant diffs in it. I'm attaching a fixed one now. It can also be > found at http://mu.org/~mux/patches/if_fxp.patch. Well, the patch seems to work just fine - better performance now in fact. I did a bunch of scp/ftp type stuff of big and a bunch of small files just to ensure everyting was working and then I used /usr/ports/net/netperf to try and characterize performance a bit. After you install the port there is a script /usr/local/netperf/snapshot_script that tries to give a reasonable snapshot of network performance under a variety of conditions, and with a few different parameters... The target machine was a 400Mhz pentium II box (sadly, this and the alpha are the two fastest machines I own...) with '4.7-STABLE FreeBSD 4.7-STABLE #5: Mon Nov 11 12:15:39 MST 2002' (+ a few security patches) with a newer fxp card fxp0@pci0:9:0: class=0x020000 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 Both of these boxes plugged into an SMC 10/100 switch... I would have just used a cross-over cable except I forgot to bring it with me and didn't feel like making one. Attached to this email you'll find the output of snapshot_script for the old driver (about two weeks old cvsup), the output of the modified driver, and the output of the script run on the integrated dc NIC, just for fun and comparison. Some sample results at one particular set of parameters: before: throughput in 10^6 bits/sec 39.18 after: throughput in 10^6 bits/sec 94.11 (dc): throughput in 10^6 bits/sec 70.97 Honestly I'm suprised there is so much difference between the before and after and I'm doubting my testing methodology -- perhaps I had the duplex set wrong on the alpha on the 'before'? shrug. I didn't shut down, or change at all, the target test box between the two tests. At any rate, the patch seems to work fine on my alpha on the one card I had time to test (older, slightly larger formfactor etherexpress pro 100). If you can wait till tomorrow, I can probably squeeze in time for testing one or two other fxp hardware revs I have... The card I did test on shows up as this: pciconf -v -l ... fxp0@pci1:8:0: class=0x020000 card=0x00098086 chip=0x12298086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82557/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet ... Fred -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. --0-54798573-1049300704=:82002 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="before.out" Content-Transfer-Encoding: BASE64 Content-ID: <20030402092504.L82002@vespa.dmz.orem.verio.net> Content-Description: old -current as of about 2 weeks ago Content-Disposition: attachment; filename="before.out" TmV0cGVyZiBzbmFwc2hvdCBzY3JpcHQgc3RhcnRlZCBhdCBUdWUgQXByIDEg MjA6Mzg6MDcgTVNUIDIwMDMNClN0YXJ0aW5nIDU2eDQgVENQX1NUUkVBTSB0 ZXN0cyBhdCBUdWUgQXByIDEgMjA6Mzg6NDIgTVNUIDIwMDMNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUZXN0aW5nIHdpdGgg dGhlIGZvbGxvd2luZyBjb21tYW5kIGxpbmU6DQovdXNyL2xvY2FsL25ldHBl cmYvbmV0cGVyZiAtdCBUQ1BfU1RSRUFNIC1sIDYwIC1IIDE5Mi4xNjguMC4x MDIgLWkgMTAsMyAtSSA5OSw1IC0tIC1zIDU3MzQ0IC1TIDU3MzQ0IC1tIDQw OTYNCg0KVENQIFNUUkVBTSBURVNUIHRvIDE5Mi4xNjguMC4xMDIgOiArLy0y LjUlIEAgOTklIGNvbmYuIDogaGlzdG9ncmFtDQpSZWN2ICAgU2VuZCAgICBT ZW5kICAgICAgICAgICAgICAgICAgICAgICAgICANClNvY2tldCBTb2NrZXQg IE1lc3NhZ2UgIEVsYXBzZWQgICAgICAgICAgICAgIA0KU2l6ZSAgIFNpemUg ICAgU2l6ZSAgICAgVGltZSAgICAgVGhyb3VnaHB1dCAgDQpieXRlcyAgYnl0 ZXMgICBieXRlcyAgICBzZWNzLiAgICAxMF42Yml0cy9zZWMgIA0KDQogNTcz NDQgIDU3MzQ0ICAgNDA5NiAgICA2MC4wNCAgICAgIDM5LjE4ICAgDQoNCg0K U3RhcnRpbmcgMzJ4NCBUQ1BfU1RSRUFNIHRlc3RzIGF0IFR1ZSBBcHIgMSAy MDo0MTo0MiBNU1QgMjAwMw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClRlc3Rpbmcgd2l0aCB0aGUgZm9sbG93aW5nIGNvbW1h bmQgbGluZToNCi91c3IvbG9jYWwvbmV0cGVyZi9uZXRwZXJmIC10IFRDUF9T VFJFQU0gLWwgNjAgLUggMTkyLjE2OC4wLjEwMiAtaSAxMCwzIC1JIDk5LDUg LS0gLXMgMzI3NjggLVMgMzI3NjggLW0gNDA5Ng0KDQpUQ1AgU1RSRUFNIFRF U1QgdG8gMTkyLjE2OC4wLjEwMiA6ICsvLTIuNSUgQCA5OSUgY29uZi4gOiBo aXN0b2dyYW0NClJlY3YgICBTZW5kICAgIFNlbmQgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KU29ja2V0IFNvY2tldCAgTWVzc2FnZSAgRWxhcHNlZCAg ICAgICAgICAgICAgDQpTaXplICAgU2l6ZSAgICBTaXplICAgICBUaW1lICAg ICBUaHJvdWdocHV0ICANCmJ5dGVzICBieXRlcyAgIGJ5dGVzICAgIHNlY3Mu ICAgIDEwXjZiaXRzL3NlYyAgDQoNCiAzMjc2OCAgMzI3NjggICA0MDk2ICAg IDYwLjA0ICAgICAgMzkuMjQgICANCg0KDQpTdGFydGluZyAxLDEgVENQX1JS IHRlc3RzIGF0IFR1ZSBBcHIgMSAyMDo0NDo0MiBNU1QgMjAwMw0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRlc3Rpbmcgd2l0 aCB0aGUgZm9sbG93aW5nIGNvbW1hbmQgbGluZToNCi91c3IvbG9jYWwvbmV0 cGVyZi9uZXRwZXJmIC10IFRDUF9SUiAtbCA2MCAtSCAxOTIuMTY4LjAuMTAy IC1pIDEwLDMgLUkgOTksNSAtLSAtciAxLDENCg0KVENQIFJFUVVFU1QvUkVT UE9OU0UgVEVTVCB0byAxOTIuMTY4LjAuMTAyIDogKy8tMi41JSBAIDk5JSBj b25mLiA6IGhpc3RvZ3JhbQ0KTG9jYWwgL1JlbW90ZQ0KU29ja2V0IFNpemUg ICBSZXF1ZXN0ICBSZXNwLiAgIEVsYXBzZWQgIFRyYW5zLg0KU2VuZCAgIFJl Y3YgICBTaXplICAgICBTaXplICAgIFRpbWUgICAgIFJhdGUgICAgICAgICAN CmJ5dGVzICBCeXRlcyAgYnl0ZXMgICAgYnl0ZXMgICBzZWNzLiAgICBwZXIg c2VjICAgDQoNCjMyNzY4ICA2NTUzNiAgMSAgICAgICAgMSAgICAgICA2MC4w NCAgICAxNzkyLjk3ICAgDQozMjc2OCAgNTczNDQgDQoNCg0KU3RhcnRpbmcg MSwxIFVEUF9SUiB0ZXN0cyBhdCBUdWUgQXByIDEgMjA6NDc6NTQgTVNUIDIw MDMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpU ZXN0aW5nIHdpdGggdGhlIGZvbGxvd2luZyBjb21tYW5kIGxpbmU6DQovdXNy L2xvY2FsL25ldHBlcmYvbmV0cGVyZiAtdCBVRFBfUlIgLWwgNjAgLUggMTky LjE2OC4wLjEwMiAtaSAxMCwzIC1JIDk5LDUgLS0gLXIgMSwxDQoNClVEUCBS RVFVRVNUL1JFU1BPTlNFIFRFU1QgdG8gMTkyLjE2OC4wLjEwMiA6ICsvLTIu NSUgQCA5OSUgY29uZi4gOiBoaXN0b2dyYW0NCkxvY2FsIC9SZW1vdGUNClNv Y2tldCBTaXplICAgUmVxdWVzdCAgUmVzcC4gICBFbGFwc2VkICBUcmFucy4N ClNlbmQgICBSZWN2ICAgU2l6ZSAgICAgU2l6ZSAgICBUaW1lICAgICBSYXRl ICAgICAgICAgDQpieXRlcyAgQnl0ZXMgIGJ5dGVzICAgIGJ5dGVzICAgc2Vj cy4gICAgcGVyIHNlYyAgIA0KDQo5MjE2ICAgNDIwODAgIDEgICAgICAgIDEg ICAgICAgNjAuMDQgICAgMTkxNi4zNSAgIA0KOTIxNiAgIDQyMDgwIA0KDQoN ClN0YXJ0aW5nIDUxMiw0IFVEUF9SUiB0ZXN0cyBhdCBUdWUgQXByIDEgMjA6 NTE6MDYgTVNUIDIwMDMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpUZXN0aW5nIHdpdGggdGhlIGZvbGxvd2luZyBjb21tYW5k IGxpbmU6DQovdXNyL2xvY2FsL25ldHBlcmYvbmV0cGVyZiAtdCBVRFBfUlIg LWwgNjAgLUggMTkyLjE2OC4wLjEwMiAtaSAxMCwzIC1JIDk5LDUgLS0gLXIg NTE2LDQNCg0KVURQIFJFUVVFU1QvUkVTUE9OU0UgVEVTVCB0byAxOTIuMTY4 LjAuMTAyIDogKy8tMi41JSBAIDk5JSBjb25mLiA6IGhpc3RvZ3JhbQ0KTG9j YWwgL1JlbW90ZQ0KU29ja2V0IFNpemUgICBSZXF1ZXN0ICBSZXNwLiAgIEVs YXBzZWQgIFRyYW5zLg0KU2VuZCAgIFJlY3YgICBTaXplICAgICBTaXplICAg IFRpbWUgICAgIFJhdGUgICAgICAgICANCmJ5dGVzICBCeXRlcyAgYnl0ZXMg ICAgYnl0ZXMgICBzZWNzLiAgICBwZXIgc2VjICAgDQoNCjkyMTYgICA0MjA4 MCAgNTE2ICAgICAgNCAgICAgICA2MC4wNCAgICAxNTE0LjA3ICAgDQo5MjE2 ICAgNDIwODAgDQpTdGFydGluZyAzMng0IFVEUF9TVFJFQU0gdGVzdHMgYXQg VHVlIEFwciAxIDIwOjU0OjE4IE1TVCAyMDAzDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGVzdGluZyB3aXRoIHRoZSBmb2xs b3dpbmcgY29tbWFuZCBsaW5lOg0KL3Vzci9sb2NhbC9uZXRwZXJmL25ldHBl cmYgLXQgVURQX1NUUkVBTSAtbCA2MCAtSCAxOTIuMTY4LjAuMTAyIC1pIDEw LDMgLUkgOTksNSAtLSAtcyAzMjc2OCAtUyAzMjc2OCAtbSA0MDk2DQoNClVE UCBVTklESVJFQ1RJT05BTCBTRU5EIFRFU1QgdG8gMTkyLjE2OC4wLjEwMiA6 ICsvLTIuNSUgQCA5OSUgY29uZi4gOiBoaXN0b2dyYW0NClNvY2tldCAgTWVz c2FnZSAgRWxhcHNlZCAgICAgIE1lc3NhZ2VzICAgICAgICAgICAgICAgIA0K U2l6ZSAgICBTaXplICAgICBUaW1lICAgICAgICAgT2theSBFcnJvcnMgICBU aHJvdWdocHV0DQpieXRlcyAgIGJ5dGVzICAgIHNlY3MgICAgICAgICAgICAj ICAgICAgIyAgIDEwXjZiaXRzL3NlYw0KDQogMzI3NjggICAgNDA5NiAgIDYw LjA0ICAgICAgMTI3MzM5ICAgICAgMCAgICAgIDY5LjUwDQogMzI3NjggICAg ICAgICAgIDYwLjA0ICAgICAgMTI3MzM5ICAgICAgICAgICAgIDY5LjUwDQoN Cg0KDQpTdGFydGluZyAzMngxIFVEUF9TVFJFQU0gdGVzdHMgYXQgVHVlIEFw ciAxIDIwOjU3OjMwIE1TVCAyMDAzDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KVGVzdGluZyB3aXRoIHRoZSBmb2xsb3dpbmcg Y29tbWFuZCBsaW5lOg0KL3Vzci9sb2NhbC9uZXRwZXJmL25ldHBlcmYgLXQg VURQX1NUUkVBTSAtbCA2MCAtSCAxOTIuMTY4LjAuMTAyIC1pIDEwLDMgLUkg OTksNSAtLSAtcyAzMjc2OCAtUyAzMjc2OCAtbSAxMDI0DQoNClVEUCBVTklE SVJFQ1RJT05BTCBTRU5EIFRFU1QgdG8gMTkyLjE2OC4wLjEwMiA6ICsvLTIu NSUgQCA5OSUgY29uZi4gOiBoaXN0b2dyYW0NClNvY2tldCAgTWVzc2FnZSAg RWxhcHNlZCAgICAgIE1lc3NhZ2VzICAgICAgICAgICAgICAgIA0KU2l6ZSAg ICBTaXplICAgICBUaW1lICAgICAgICAgT2theSBFcnJvcnMgICBUaHJvdWdo cHV0DQpieXRlcyAgIGJ5dGVzICAgIHNlY3MgICAgICAgICAgICAjICAgICAg IyAgIDEwXjZiaXRzL3NlYw0KDQogMzI3NjggICAgMTAyNCAgIDYwLjA0ICAg ICAgMjcwMjQ5ICAgICAgMCAgICAgIDM2Ljg4DQogMzI3NjggICAgICAgICAg IDYwLjA0ICAgICAgMjcwMjQ5ICAgICAgICAgICAgIDM2Ljg4DQoNCg0KDQpU ZXN0cyBjb21wbGV0ZWQgYXQgVHVlIEFwciAxIDIxOjAxOjQ2IE1TVCAyMDAz DQoNCklmIHlvdSB3aXNoIHRvIHN1Ym1pdCB0aGVzZSByZXN1bHRzIHRvIHRo ZSBuZXRwZXJmIGRhdGFiYXNlIGF0DQpodHRwOi8vd3d3LmN1cC5ocC5jb20v bmV0cGVyZi9OZXRwZXJmUGFnZS5odG1sLCBwbGVhc2Ugc3VibWl0IGVhY2gN CmRhdGFwb2ludCBpbmRpdmlkdWFsbHkuIEluZGl2aWR1YWwgZGF0YXBvaW50 cyBhcmUgc2VwYXJhdGVkIGJ5DQpsaW5lcyBvZiBkYXNoZXMuDQo= --0-54798573-1049300704=:82002 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="after.out" Content-Transfer-Encoding: BASE64 Content-ID: <20030402092504.P82002@vespa.dmz.orem.verio.net> Content-Description: everything the same except the patch is applied. Content-Disposition: attachment; filename="after.out" TmV0cGVyZiBzbmFwc2hvdCBzY3JpcHQgc3RhcnRlZCBhdCBUdWUgQXByIDEg MjE6MTQ6MjEgTVNUIDIwMDMNClN0YXJ0aW5nIDU2eDQgVENQX1NUUkVBTSB0 ZXN0cyBhdCBUdWUgQXByIDEgMjE6MTQ6NTUgTVNUIDIwMDMNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUZXN0aW5nIHdpdGgg dGhlIGZvbGxvd2luZyBjb21tYW5kIGxpbmU6DQovdXNyL2xvY2FsL25ldHBl cmYvbmV0cGVyZiAtdCBUQ1BfU1RSRUFNIC1sIDYwIC1IIDE5Mi4xNjguMC4x MDIgLWkgMTAsMyAtSSA5OSw1IC0tIC1zIDU3MzQ0IC1TIDU3MzQ0IC1tIDQw OTYNCg0KVENQIFNUUkVBTSBURVNUIHRvIDE5Mi4xNjguMC4xMDIgOiArLy0y LjUlIEAgOTklIGNvbmYuIDogaGlzdG9ncmFtDQpSZWN2ICAgU2VuZCAgICBT ZW5kICAgICAgICAgICAgICAgICAgICAgICAgICANClNvY2tldCBTb2NrZXQg IE1lc3NhZ2UgIEVsYXBzZWQgICAgICAgICAgICAgIA0KU2l6ZSAgIFNpemUg ICAgU2l6ZSAgICAgVGltZSAgICAgVGhyb3VnaHB1dCAgDQpieXRlcyAgYnl0 ZXMgICBieXRlcyAgICBzZWNzLiAgICAxMF42Yml0cy9zZWMgIA0KDQogNTcz NDQgIDU3MzQ0ICAgNDA5NiAgICA2MC4wNCAgICAgIDk0LjExICAgDQoNCg0K U3RhcnRpbmcgMzJ4NCBUQ1BfU1RSRUFNIHRlc3RzIGF0IFR1ZSBBcHIgMSAy MToxNzo1NSBNU1QgMjAwMw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClRlc3Rpbmcgd2l0aCB0aGUgZm9sbG93aW5nIGNvbW1h bmQgbGluZToNCi91c3IvbG9jYWwvbmV0cGVyZi9uZXRwZXJmIC10IFRDUF9T VFJFQU0gLWwgNjAgLUggMTkyLjE2OC4wLjEwMiAtaSAxMCwzIC1JIDk5LDUg LS0gLXMgMzI3NjggLVMgMzI3NjggLW0gNDA5Ng0KDQpUQ1AgU1RSRUFNIFRF U1QgdG8gMTkyLjE2OC4wLjEwMiA6ICsvLTIuNSUgQCA5OSUgY29uZi4gOiBo aXN0b2dyYW0NClJlY3YgICBTZW5kICAgIFNlbmQgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KU29ja2V0IFNvY2tldCAgTWVzc2FnZSAgRWxhcHNlZCAg ICAgICAgICAgICAgDQpTaXplICAgU2l6ZSAgICBTaXplICAgICBUaW1lICAg ICBUaHJvdWdocHV0ICANCmJ5dGVzICBieXRlcyAgIGJ5dGVzICAgIHNlY3Mu ICAgIDEwXjZiaXRzL3NlYyAgDQoNCiAzMjc2OCAgMzI3NjggICA0MDk2ICAg IDYwLjA0ICAgICAgOTQuMDUgICANCg0KDQpTdGFydGluZyAxLDEgVENQX1JS IHRlc3RzIGF0IFR1ZSBBcHIgMSAyMToyMDo1NSBNU1QgMjAwMw0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRlc3Rpbmcgd2l0 aCB0aGUgZm9sbG93aW5nIGNvbW1hbmQgbGluZToNCi91c3IvbG9jYWwvbmV0 cGVyZi9uZXRwZXJmIC10IFRDUF9SUiAtbCA2MCAtSCAxOTIuMTY4LjAuMTAy IC1pIDEwLDMgLUkgOTksNSAtLSAtciAxLDENCg0KVENQIFJFUVVFU1QvUkVT UE9OU0UgVEVTVCB0byAxOTIuMTY4LjAuMTAyIDogKy8tMi41JSBAIDk5JSBj b25mLiA6IGhpc3RvZ3JhbQ0KTG9jYWwgL1JlbW90ZQ0KU29ja2V0IFNpemUg ICBSZXF1ZXN0ICBSZXNwLiAgIEVsYXBzZWQgIFRyYW5zLg0KU2VuZCAgIFJl Y3YgICBTaXplICAgICBTaXplICAgIFRpbWUgICAgIFJhdGUgICAgICAgICAN CmJ5dGVzICBCeXRlcyAgYnl0ZXMgICAgYnl0ZXMgICBzZWNzLiAgICBwZXIg c2VjICAgDQoNCjMyNzY4ICA2NTUzNiAgMSAgICAgICAgMSAgICAgICA2MC4w NCAgICAzOTE0LjA3ICAgDQozMjc2OCAgNTczNDQgDQoNCg0KU3RhcnRpbmcg MSwxIFVEUF9SUiB0ZXN0cyBhdCBUdWUgQXByIDEgMjE6MjU6MTIgTVNUIDIw MDMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpU ZXN0aW5nIHdpdGggdGhlIGZvbGxvd2luZyBjb21tYW5kIGxpbmU6DQovdXNy L2xvY2FsL25ldHBlcmYvbmV0cGVyZiAtdCBVRFBfUlIgLWwgNjAgLUggMTky LjE2OC4wLjEwMiAtaSAxMCwzIC1JIDk5LDUgLS0gLXIgMSwxDQoNClVEUCBS RVFVRVNUL1JFU1BPTlNFIFRFU1QgdG8gMTkyLjE2OC4wLjEwMiA6ICsvLTIu NSUgQCA5OSUgY29uZi4gOiBoaXN0b2dyYW0NCkxvY2FsIC9SZW1vdGUNClNv Y2tldCBTaXplICAgUmVxdWVzdCAgUmVzcC4gICBFbGFwc2VkICBUcmFucy4N ClNlbmQgICBSZWN2ICAgU2l6ZSAgICAgU2l6ZSAgICBUaW1lICAgICBSYXRl ICAgICAgICAgDQpieXRlcyAgQnl0ZXMgIGJ5dGVzICAgIGJ5dGVzICAgc2Vj cy4gICAgcGVyIHNlYyAgIA0KDQo5MjE2ICAgNDIwODAgIDEgICAgICAgIDEg ICAgICAgNjAuMDQgICAgNDQyNi44OSAgIA0KOTIxNiAgIDQyMDgwIA0KDQoN ClN0YXJ0aW5nIDUxMiw0IFVEUF9SUiB0ZXN0cyBhdCBUdWUgQXByIDEgMjE6 Mjg6MjQgTVNUIDIwMDMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpUZXN0aW5nIHdpdGggdGhlIGZvbGxvd2luZyBjb21tYW5k IGxpbmU6DQovdXNyL2xvY2FsL25ldHBlcmYvbmV0cGVyZiAtdCBVRFBfUlIg LWwgNjAgLUggMTkyLjE2OC4wLjEwMiAtaSAxMCwzIC1JIDk5LDUgLS0gLXIg NTE2LDQNCg0KVURQIFJFUVVFU1QvUkVTUE9OU0UgVEVTVCB0byAxOTIuMTY4 LjAuMTAyIDogKy8tMi41JSBAIDk5JSBjb25mLiA6IGhpc3RvZ3JhbQ0KTG9j YWwgL1JlbW90ZQ0KU29ja2V0IFNpemUgICBSZXF1ZXN0ICBSZXNwLiAgIEVs YXBzZWQgIFRyYW5zLg0KU2VuZCAgIFJlY3YgICBTaXplICAgICBTaXplICAg IFRpbWUgICAgIFJhdGUgICAgICAgICANCmJ5dGVzICBCeXRlcyAgYnl0ZXMg ICAgYnl0ZXMgICBzZWNzLiAgICBwZXIgc2VjICAgDQoNCjkyMTYgICA0MjA4 MCAgNTE2ICAgICAgNCAgICAgICA2MC4wNCAgICAzMDE4Ljg0ICAgDQo5MjE2 ICAgNDIwODAgDQpTdGFydGluZyAzMng0IFVEUF9TVFJFQU0gdGVzdHMgYXQg VHVlIEFwciAxIDIxOjMxOjM2IE1TVCAyMDAzDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGVzdGluZyB3aXRoIHRoZSBmb2xs b3dpbmcgY29tbWFuZCBsaW5lOg0KL3Vzci9sb2NhbC9uZXRwZXJmL25ldHBl cmYgLXQgVURQX1NUUkVBTSAtbCA2MCAtSCAxOTIuMTY4LjAuMTAyIC1pIDEw LDMgLUkgOTksNSAtLSAtcyAzMjc2OCAtUyAzMjc2OCAtbSA0MDk2DQoNClVE UCBVTklESVJFQ1RJT05BTCBTRU5EIFRFU1QgdG8gMTkyLjE2OC4wLjEwMiA6 ICsvLTIuNSUgQCA5OSUgY29uZi4gOiBoaXN0b2dyYW0NClNvY2tldCAgTWVz c2FnZSAgRWxhcHNlZCAgICAgIE1lc3NhZ2VzICAgICAgICAgICAgICAgIA0K U2l6ZSAgICBTaXplICAgICBUaW1lICAgICAgICAgT2theSBFcnJvcnMgICBU aHJvdWdocHV0DQpieXRlcyAgIGJ5dGVzICAgIHNlY3MgICAgICAgICAgICAj ICAgICAgIyAgIDEwXjZiaXRzL3NlYw0KDQogMzI3NjggICAgNDA5NiAgIDYw LjA0ICAgICAgMTc0MjgwIDExNTU2MDkgICAgICA5NS4xMg0KIDMyNzY4ICAg ICAgICAgICA2MC4wNCAgICAgIDE3NDI4MCAgICAgICAgICAgICA5NS4xMg0K DQoNCg0KU3RhcnRpbmcgMzJ4MSBVRFBfU1RSRUFNIHRlc3RzIGF0IFR1ZSBB cHIgMSAyMTozNDo0OCBNU1QgMjAwMw0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClRlc3Rpbmcgd2l0aCB0aGUgZm9sbG93aW5n IGNvbW1hbmQgbGluZToNCi91c3IvbG9jYWwvbmV0cGVyZi9uZXRwZXJmIC10 IFVEUF9TVFJFQU0gLWwgNjAgLUggMTkyLjE2OC4wLjEwMiAtaSAxMCwzIC1J IDk5LDUgLS0gLXMgMzI3NjggLVMgMzI3NjggLW0gMTAyNA0KDQpVRFAgVU5J RElSRUNUSU9OQUwgU0VORCBURVNUIHRvIDE5Mi4xNjguMC4xMDIgOiArLy0y LjUlIEAgOTklIGNvbmYuIDogaGlzdG9ncmFtDQpTb2NrZXQgIE1lc3NhZ2Ug IEVsYXBzZWQgICAgICBNZXNzYWdlcyAgICAgICAgICAgICAgICANClNpemUg ICAgU2l6ZSAgICAgVGltZSAgICAgICAgIE9rYXkgRXJyb3JzICAgVGhyb3Vn aHB1dA0KYnl0ZXMgICBieXRlcyAgICBzZWNzICAgICAgICAgICAgIyAgICAg ICMgICAxMF42Yml0cy9zZWMNCg0KIDMyNzY4ICAgIDEwMjQgICA2MC4wNCAg ICAgIDY3NjQ5MyAxMzcwMTYyICAgICAgOTIuMzENCiAzMjc2OCAgICAgICAg ICAgNjAuMDQgICAgICA2NzY0OTMgICAgICAgICAgICAgOTIuMzENCg0KDQoN ClRlc3RzIGNvbXBsZXRlZCBhdCBUdWUgQXByIDEgMjE6Mzg6MDAgTVNUIDIw MDMNCg0KSWYgeW91IHdpc2ggdG8gc3VibWl0IHRoZXNlIHJlc3VsdHMgdG8g dGhlIG5ldHBlcmYgZGF0YWJhc2UgYXQNCmh0dHA6Ly93d3cuY3VwLmhwLmNv bS9uZXRwZXJmL05ldHBlcmZQYWdlLmh0bWwsIHBsZWFzZSBzdWJtaXQgZWFj aA0KZGF0YXBvaW50IGluZGl2aWR1YWxseS4gSW5kaXZpZHVhbCBkYXRhcG9p bnRzIGFyZSBzZXBhcmF0ZWQgYnkNCmxpbmVzIG9mIGRhc2hlcy4NCg== --0-54798573-1049300704=:82002 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dc.out" Content-Transfer-Encoding: BASE64 Content-ID: <20030402092504.Q82002@vespa.dmz.orem.verio.net> Content-Description: similar test for dc(4) driver using the integrated NIC - baseline Content-Disposition: attachment; filename="dc.out" TmV0cGVyZiBzbmFwc2hvdCBzY3JpcHQgc3RhcnRlZCBhdCBUdWUgQXByIDEg MjI6MTU6MzIgTVNUIDIwMDMNClN0YXJ0aW5nIDU2eDQgVENQX1NUUkVBTSB0 ZXN0cyBhdCBUdWUgQXByIDEgMjI6MTY6MDYgTVNUIDIwMDMNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUZXN0aW5nIHdpdGgg dGhlIGZvbGxvd2luZyBjb21tYW5kIGxpbmU6DQovdXNyL2xvY2FsL25ldHBl cmYvbmV0cGVyZiAtdCBUQ1BfU1RSRUFNIC1sIDYwIC1IIDE5Mi4xNjguMC4x MDIgLWkgMTAsMyAtSSA5OSw1IC0tIC1zIDU3MzQ0IC1TIDU3MzQ0IC1tIDQw OTYNCg0KVENQIFNUUkVBTSBURVNUIHRvIDE5Mi4xNjguMC4xMDIgOiArLy0y LjUlIEAgOTklIGNvbmYuIDogaGlzdG9ncmFtDQpSZWN2ICAgU2VuZCAgICBT ZW5kICAgICAgICAgICAgICAgICAgICAgICAgICANClNvY2tldCBTb2NrZXQg IE1lc3NhZ2UgIEVsYXBzZWQgICAgICAgICAgICAgIA0KU2l6ZSAgIFNpemUg ICAgU2l6ZSAgICAgVGltZSAgICAgVGhyb3VnaHB1dCAgDQpieXRlcyAgYnl0 ZXMgICBieXRlcyAgICBzZWNzLiAgICAxMF42Yml0cy9zZWMgIA0KDQogNTcz NDQgIDU3MzQ0ICAgNDA5NiAgICA2MC4wNCAgICAgIDcwLjk3ICAgDQoNCg0K U3RhcnRpbmcgMzJ4NCBUQ1BfU1RSRUFNIHRlc3RzIGF0IFR1ZSBBcHIgMSAy MjoxOTowNiBNU1QgMjAwMw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClRlc3Rpbmcgd2l0aCB0aGUgZm9sbG93aW5nIGNvbW1h bmQgbGluZToNCi91c3IvbG9jYWwvbmV0cGVyZi9uZXRwZXJmIC10IFRDUF9T VFJFQU0gLWwgNjAgLUggMTkyLjE2OC4wLjEwMiAtaSAxMCwzIC1JIDk5LDUg LS0gLXMgMzI3NjggLVMgMzI3NjggLW0gNDA5Ng0KDQpUQ1AgU1RSRUFNIFRF U1QgdG8gMTkyLjE2OC4wLjEwMiA6ICsvLTIuNSUgQCA5OSUgY29uZi4gOiBo aXN0b2dyYW0NClJlY3YgICBTZW5kICAgIFNlbmQgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KU29ja2V0IFNvY2tldCAgTWVzc2FnZSAgRWxhcHNlZCAg ICAgICAgICAgICAgDQpTaXplICAgU2l6ZSAgICBTaXplICAgICBUaW1lICAg ICBUaHJvdWdocHV0ICANCmJ5dGVzICBieXRlcyAgIGJ5dGVzICAgIHNlY3Mu ICAgIDEwXjZiaXRzL3NlYyAgDQoNCiAzMjc2OCAgMzI3NjggICA0MDk2ICAg IDYwLjA0ICAgICAgNjMuNzMgICANCg0KDQpTdGFydGluZyAxLDEgVENQX1JS IHRlc3RzIGF0IFR1ZSBBcHIgMSAyMjoyMjowNiBNU1QgMjAwMw0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRlc3Rpbmcgd2l0 aCB0aGUgZm9sbG93aW5nIGNvbW1hbmQgbGluZToNCi91c3IvbG9jYWwvbmV0 cGVyZi9uZXRwZXJmIC10IFRDUF9SUiAtbCA2MCAtSCAxOTIuMTY4LjAuMTAy IC1pIDEwLDMgLUkgOTksNSAtLSAtciAxLDENCg0KVENQIFJFUVVFU1QvUkVT UE9OU0UgVEVTVCB0byAxOTIuMTY4LjAuMTAyIDogKy8tMi41JSBAIDk5JSBj b25mLiA6IGhpc3RvZ3JhbQ0KTG9jYWwgL1JlbW90ZQ0KU29ja2V0IFNpemUg ICBSZXF1ZXN0ICBSZXNwLiAgIEVsYXBzZWQgIFRyYW5zLg0KU2VuZCAgIFJl Y3YgICBTaXplICAgICBTaXplICAgIFRpbWUgICAgIFJhdGUgICAgICAgICAN CmJ5dGVzICBCeXRlcyAgYnl0ZXMgICAgYnl0ZXMgICBzZWNzLiAgICBwZXIg c2VjICAgDQoNCjMyNzY4ICA2NTUzNiAgMSAgICAgICAgMSAgICAgICA2MC4w NCAgICA0MDQ4LjA5ICAgDQozMjc2OCAgNTczNDQgDQoNCg0KU3RhcnRpbmcg MSwxIFVEUF9SUiB0ZXN0cyBhdCBUdWUgQXByIDEgMjI6MjU6MTggTVNUIDIw MDMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpU ZXN0aW5nIHdpdGggdGhlIGZvbGxvd2luZyBjb21tYW5kIGxpbmU6DQovdXNy L2xvY2FsL25ldHBlcmYvbmV0cGVyZiAtdCBVRFBfUlIgLWwgNjAgLUggMTky LjE2OC4wLjEwMiAtaSAxMCwzIC1JIDk5LDUgLS0gLXIgMSwxDQoNClVEUCBS RVFVRVNUL1JFU1BPTlNFIFRFU1QgdG8gMTkyLjE2OC4wLjEwMiA6ICsvLTIu NSUgQCA5OSUgY29uZi4gOiBoaXN0b2dyYW0NCkxvY2FsIC9SZW1vdGUNClNv Y2tldCBTaXplICAgUmVxdWVzdCAgUmVzcC4gICBFbGFwc2VkICBUcmFucy4N ClNlbmQgICBSZWN2ICAgU2l6ZSAgICAgU2l6ZSAgICBUaW1lICAgICBSYXRl ICAgICAgICAgDQpieXRlcyAgQnl0ZXMgIGJ5dGVzICAgIGJ5dGVzICAgc2Vj cy4gICAgcGVyIHNlYyAgIA0KDQo5MjE2ICAgNDIwODAgIDEgICAgICAgIDEg ICAgICAgNjAuMDQgICAgNDA2Mi40MyAgIA0KOTIxNiAgIDQyMDgwIA0KDQoN ClN0YXJ0aW5nIDUxMiw0IFVEUF9SUiB0ZXN0cyBhdCBUdWUgQXByIDEgMjI6 Mjg6MzAgTVNUIDIwMDMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpUZXN0aW5nIHdpdGggdGhlIGZvbGxvd2luZyBjb21tYW5k IGxpbmU6DQovdXNyL2xvY2FsL25ldHBlcmYvbmV0cGVyZiAtdCBVRFBfUlIg LWwgNjAgLUggMTkyLjE2OC4wLjEwMiAtaSAxMCwzIC1JIDk5LDUgLS0gLXIg NTE2LDQNCg0KVURQIFJFUVVFU1QvUkVTUE9OU0UgVEVTVCB0byAxOTIuMTY4 LjAuMTAyIDogKy8tMi41JSBAIDk5JSBjb25mLiA6IGhpc3RvZ3JhbQ0KTG9j YWwgL1JlbW90ZQ0KU29ja2V0IFNpemUgICBSZXF1ZXN0ICBSZXNwLiAgIEVs YXBzZWQgIFRyYW5zLg0KU2VuZCAgIFJlY3YgICBTaXplICAgICBTaXplICAg IFRpbWUgICAgIFJhdGUgICAgICAgICANCmJ5dGVzICBCeXRlcyAgYnl0ZXMg ICAgYnl0ZXMgICBzZWNzLiAgICBwZXIgc2VjICAgDQoNCjkyMTYgICA0MjA4 MCAgNTE2ICAgICAgNCAgICAgICA2MC4wNCAgICAzMDQ4LjU4ICAgDQo5MjE2 ICAgNDIwODAgDQpTdGFydGluZyAzMng0IFVEUF9TVFJFQU0gdGVzdHMgYXQg VHVlIEFwciAxIDIyOjMxOjQyIE1TVCAyMDAzDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGVzdGluZyB3aXRoIHRoZSBmb2xs b3dpbmcgY29tbWFuZCBsaW5lOg0KL3Vzci9sb2NhbC9uZXRwZXJmL25ldHBl cmYgLXQgVURQX1NUUkVBTSAtbCA2MCAtSCAxOTIuMTY4LjAuMTAyIC1pIDEw LDMgLUkgOTksNSAtLSAtcyAzMjc2OCAtUyAzMjc2OCAtbSA0MDk2DQoNClVE UCBVTklESVJFQ1RJT05BTCBTRU5EIFRFU1QgdG8gMTkyLjE2OC4wLjEwMiA6 ICsvLTIuNSUgQCA5OSUgY29uZi4gOiBoaXN0b2dyYW0NClNvY2tldCAgTWVz c2FnZSAgRWxhcHNlZCAgICAgIE1lc3NhZ2VzICAgICAgICAgICAgICAgIA0K U2l6ZSAgICBTaXplICAgICBUaW1lICAgICAgICAgT2theSBFcnJvcnMgICBU aHJvdWdocHV0DQpieXRlcyAgIGJ5dGVzICAgIHNlY3MgICAgICAgICAgICAj ICAgICAgIyAgIDEwXjZiaXRzL3NlYw0KDQogMzI3NjggICAgNDA5NiAgIDYw LjA0ICAgICAgMTcxNTAwIDY0MzYxNiAgICAgIDkzLjYxDQogMzI3NjggICAg ICAgICAgIDYwLjA0ICAgICAgMTcxNTAwICAgICAgICAgICAgIDkzLjYxDQoN Cg0KDQpTdGFydGluZyAzMngxIFVEUF9TVFJFQU0gdGVzdHMgYXQgVHVlIEFw ciAxIDIyOjM0OjU0IE1TVCAyMDAzDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KVGVzdGluZyB3aXRoIHRoZSBmb2xsb3dpbmcg Y29tbWFuZCBsaW5lOg0KL3Vzci9sb2NhbC9uZXRwZXJmL25ldHBlcmYgLXQg VURQX1NUUkVBTSAtbCA2MCAtSCAxOTIuMTY4LjAuMTAyIC1pIDEwLDMgLUkg OTksNSAtLSAtcyAzMjc2OCAtUyAzMjc2OCAtbSAxMDI0DQoNClVEUCBVTklE SVJFQ1RJT05BTCBTRU5EIFRFU1QgdG8gMTkyLjE2OC4wLjEwMiA6ICsvLTIu NSUgQCA5OSUgY29uZi4gOiBoaXN0b2dyYW0NClNvY2tldCAgTWVzc2FnZSAg RWxhcHNlZCAgICAgIE1lc3NhZ2VzICAgICAgICAgICAgICAgIA0KU2l6ZSAg ICBTaXplICAgICBUaW1lICAgICAgICAgT2theSBFcnJvcnMgICBUaHJvdWdo cHV0DQpieXRlcyAgIGJ5dGVzICAgIHNlY3MgICAgICAgICAgICAjICAgICAg IyAgIDEwXjZiaXRzL3NlYw0KDQogMzI3NjggICAgMTAyNCAgIDYwLjA0ICAg ICAgNjY4OTkxIDQxNjUyOCAgICAgIDkxLjI5DQogMzI3NjggICAgICAgICAg IDYwLjA0ICAgICAgNjY4OTI1ICAgICAgICAgICAgIDkxLjI4DQoNCg0KDQpU ZXN0cyBjb21wbGV0ZWQgYXQgVHVlIEFwciAxIDIyOjM4OjA2IE1TVCAyMDAz DQoNCklmIHlvdSB3aXNoIHRvIHN1Ym1pdCB0aGVzZSByZXN1bHRzIHRvIHRo ZSBuZXRwZXJmIGRhdGFiYXNlIGF0DQpodHRwOi8vd3d3LmN1cC5ocC5jb20v bmV0cGVyZi9OZXRwZXJmUGFnZS5odG1sLCBwbGVhc2Ugc3VibWl0IGVhY2gN CmRhdGFwb2ludCBpbmRpdmlkdWFsbHkuIEluZGl2aWR1YWwgZGF0YXBvaW50 cyBhcmUgc2VwYXJhdGVkIGJ5DQpsaW5lcyBvZiBkYXNoZXMuDQo= --0-54798573-1049300704=:82002-- From owner-freebsd-alpha@FreeBSD.ORG Wed Apr 2 08:33:51 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1681F37B401 for ; Wed, 2 Apr 2003 08:33:51 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31C0C43FBF for ; Wed, 2 Apr 2003 08:33:50 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 1A3A22ED407; Wed, 2 Apr 2003 08:33:50 -0800 (PST) Date: Wed, 2 Apr 2003 18:33:50 +0200 From: Maxime Henrion To: Fred Clift Message-ID: <20030402163350.GI1750@elvis.mu.org> References: <20030401134113.GC1750@elvis.mu.org> <20030402090802.Y82002-400000@vespa.dmz.orem.verio.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030402090802.Y82002-400000@vespa.dmz.orem.verio.net> User-Agent: Mutt/1.4.1i cc: alpha@freebsd.org Subject: Re: call for testers: busdma-ified fxp(4) driver X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 16:33:51 -0000 Fred Clift wrote: > On Tue, 1 Apr 2003, Maxime Henrion wrote: > > > > My fxp(4) patch should now be nearly commit ready. > ... > > > someone with an alpha box and a fxp(4) card could test this patch > > > > Sorry to follow-up to myself, but this patch had some bogus and > > irrelevant diffs in it. I'm attaching a fixed one now. It can also be > > found at http://mu.org/~mux/patches/if_fxp.patch. > > Well, the patch seems to work just fine - better performance now in fact. > > I did a bunch of scp/ftp type stuff of big and a bunch of small files just > to ensure everyting was working and then I used /usr/ports/net/netperf to > try and characterize performance a bit. After you install the port there > is a script /usr/local/netperf/snapshot_script that tries to give a > reasonable snapshot of network performance under a variety of conditions, > and with a few different parameters... The target machine was a 400Mhz > pentium II box (sadly, this and the alpha are the two fastest machines I > own...) with '4.7-STABLE FreeBSD 4.7-STABLE #5: Mon Nov 11 12:15:39 MST > 2002' (+ a few security patches) with a newer fxp card > > fxp0@pci0:9:0: class=0x020000 card=0x000c8086 chip=0x12298086 rev=0x08 > hdr=0x00 > > Both of these boxes plugged into an SMC 10/100 switch... I would have > just used a cross-over cable except I forgot to bring it with me and > didn't feel like making one. > > Attached to this email you'll find the output of snapshot_script for the > old driver (about two weeks old cvsup), the output of the modified driver, > and the output of the script run on the integrated dc NIC, just for fun > and comparison. > > Some sample results at one particular set of parameters: > > before: throughput in 10^6 bits/sec 39.18 > after: throughput in 10^6 bits/sec 94.11 > (dc): throughput in 10^6 bits/sec 70.97 > > > Honestly I'm suprised there is so much difference between the before and > after and I'm doubting my testing methodology -- perhaps I had the duplex > set wrong on the alpha on the 'before'? shrug. I didn't shut down, or > change at all, the target test box between the two tests. At any rate, the > patch seems to work fine on my alpha on the one card I had time to test > (older, slightly larger formfactor etherexpress pro 100). If you can wait > till tomorrow, I can probably squeeze in time for testing one or two other > fxp hardware revs I have... > > The card I did test on shows up as this: > > pciconf -v -l > ... > fxp0@pci1:8:0: class=0x020000 card=0x00098086 chip=0x12298086 rev=0x04 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82557/8/9 EtherExpress PRO/100(B) Ethernet Adapter' > class = network > subclass = ethernet > ... Great, many thanks to you for testing this! I'm also very surprised about that huge performance improvement, I just can't see how this patch could improve performance :-). If you feel like and have time to do some more performance testing, that would be very interesting. I'm going to commit this patch now. Cheers, Maxime From owner-freebsd-alpha@FreeBSD.ORG Wed Apr 2 08:52:18 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 227D337B401; Wed, 2 Apr 2003 08:52:18 -0800 (PST) Received: from gatekeeper.oremut01.us.wh.verio.net (gatekeeper.oremut01.us.wh.verio.net [198.65.168.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ED7243FCB; Wed, 2 Apr 2003 08:52:17 -0800 (PST) (envelope-from fclift@verio.net) Received: from mx.dmz.orem.verio.net (mx.dmz.orem.verio.net [10.1.1.10]) by gatekeeper.oremut01.us.wh.verio.net (Postfix) with ESMTP id D49B23BF158; Wed, 2 Apr 2003 09:52:16 -0700 (MST) Received: from vespa.dmz.orem.verio.net (vespa.dmz.orem.verio.net [10.1.1.59]) by mx.dmz.orem.verio.net (8.11.6p2/8.11.6) with ESMTP id h32GqGA97406; Wed, 2 Apr 2003 09:52:16 -0700 (MST) Date: Wed, 2 Apr 2003 09:55:16 -0700 (MST) From: Fred Clift X-X-Sender: To: Maxime Henrion In-Reply-To: <20030402163350.GI1750@elvis.mu.org> Message-ID: <20030402095408.W82002-100000@vespa.dmz.orem.verio.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: alpha@freebsd.org Subject: Re: call for testers: busdma-ified fxp(4) driver X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 16:52:18 -0000 On Wed, 2 Apr 2003, Maxime Henrion wrote: > could improve performance :-). If you feel like and have time to do > some more performance testing, that would be very interesting. I could probably make some time, but I have no real desire to downgrade the driver and muck with it much more :). I will try out a couple of other fxp cards I have and report if I see problems. Fred -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. From owner-freebsd-alpha@FreeBSD.ORG Wed Apr 2 16:07:26 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1845E37B401 for ; Wed, 2 Apr 2003 16:07:25 -0800 (PST) Received: from norton.palomine.net (norton.palomine.net [66.93.48.52]) by mx1.FreeBSD.org (Postfix) with SMTP id 65B7A43FA3 for ; Wed, 2 Apr 2003 16:07:25 -0800 (PST) (envelope-from ) Received: (qmail 21908 invoked for bounce); 3 Apr 2003 00:07:24 -0000 Date: 3 Apr 2003 00:07:24 -0000 From: MAILER-DAEMON@norton.palomine.net To: freebsd-alpha@FreeBSD.org Message-Id: <20030403000725.65B7A43FA3@mx1.FreeBSD.org> Subject: failure notice X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 00:07:26 -0000 Hi. This is the qmail-send program at norton.palomine.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : Sorry, no mailbox here by that name. (#5.1.1) --- Below this line is a copy of the message. Return-Path: Received: (qmail 21897 invoked from network); 3 Apr 2003 00:07:21 -0000 Received: from 67.128.30.61.isp.tfn.net.tw (HELO acer-79td2ltxfa) (61.30.128.67) by norton.palomine.net with SMTP; 3 Apr 2003 00:07:21 -0000 Received: from tpts1 by mail.ht.net.tw with SMTP id tp8S50xqVj9DP1; Thu, 03 Apr 2003 08:07:11 +0800 Message-ID: From: todd@crenshaw.reno.nv.us To: todd@crenshaw.reno.nv.us Subject: fw ®ø¶O·sª¾¡ã²{¥N¤H¤£¥i¤£ª¾¡I¡I gJUWlSPZ9rdFLBJ MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_DoSV5H1zznrhrhlz6raW1cTg1" X-Mailer: vpLTYp9w8IuSQ1R X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. ------=_NextPart_DoSV5H1zznrhrhlz6raW1cTg1 Content-Type: multipart/alternative; boundary="----=_NextPart_DoSV5H1zznrhrhlz6raW1cTg1AA" ------=_NextPart_DoSV5H1zznrhrhlz6raW1cTg1AA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9YmlnNSI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBGcm9udFBhZ2UgNC4wIj4NCjxtZXRhIG5hbWU9IlByb2dJZCIgY29udGVu dD0iRnJvbnRQYWdlLkVkaXRvci5Eb2N1bWVudCI+DQo8dGl0bGU+pdGxTbd+vHOnaatIpfOkvaVx sUiwZTwvdGl0bGU+DQo8L2hlYWQ+DQoNCjxib2R5Pg0KDQo8cCBzdHlsZT0iTUFSR0lOLVRPUDog MC40MmNtOyBDT0xPUjogIzk5OTk5OSI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0it3Oy06n6xeksIHNl cmlmIiBjb2xvcj0iIzk5OTk5OSI+PHNwYW4+PGI+pdGxTbd+vHOnaatIpfOkvaVxsUiwZaFBqdKl SL3QpMWqvbG1pl6rSLPhoeOh4zwvYj48L3NwYW4+PC9mb250PjwvcD4NCjxocj4NCjxwIHN0eWxl PSJNQVJHSU4tVE9QOiAwLjQyY207IENPTE9SOiAjMDAwMGZmIj48Zm9udCBzdHlsZT0iRk9OVC1T SVpFOiAxNnB0OyBURVhULURFQ09SQVRJT046IGJsaW5rIiBzaXplPSI0IiBmYWNlPSK3c7LTqfrF 6Swgc2VyaWYiIGNvbG9yPSIjMDAwMGZmIj48c3Bhbj48Yj6mcKbzptun2sDLtfinQbJ7pmKquqR1 rE+nX63IsW+nQafrpEqmcKa5qviquq7JtqGhSaFJPC9iPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg c3R5bGU9IkNPTE9SOiAjNjY2NjAwIj48Zm9udCBmYWNlPSK3c7LTqfrF6Swgc2VyaWYiIGNvbG9y PSIjNjY2NjAwIj48c3Bhbj6o5Lnqq9zCsrPmoUGn2qZirtGkV6zdqOyquqHjoeM8L3NwYW4+PC9m b250PjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSK3c7LTqfrF6Swgc2VyaWYiPjxz cGFuIHN0eWxlPSJCQUNLR1JPVU5EOiAjZmZmZjAwIj4xLrNvrdOkdadAr+Cko6/gxf2nQafkpEC4 c6Txp0Gn88B1qHGquqRIwLCnQaR1p0A8L3NwYW4+PC9mb250PjwvcD4NCjxwIGFsaWduPSJsZWZ0 Ij48Zm9udCBmYWNlPSK3c7LTqfrF6Swgc2VyaWYiPjxzcGFuIHN0eWxlPSJCQUNLR1JPVU5EOiAj ZmZmZjAwIj4yLrNvrdOkdadArE+ko6xPus7EsaRdr+DByL/6PC9zcGFuPjwvZm9udD48L3A+DQo8 c3BhbiBpZD0ipOWmcqTotvQxIiBzdHlsZT0iQk9SREVSLVJJR0hUOiAjMDAwMDAwIDFweCBzb2xp ZDsgUEFERElORy1SSUdIVDogMC4wNWNtOyBCT1JERVItVE9QOiAjMDAwMDAwIDFweCBzb2xpZDsg UEFERElORy1MRUZUOiAwLjA1Y207IEJBQ0tHUk9VTkQ6ICNjY2ZmZmY7IEZMT0FUOiBsZWZ0OyBQ QURESU5HLUJPVFRPTTogMC4wNWNtOyBCT1JERVItTEVGVDogIzAwMDAwMCAxcHggc29saWQ7IFdJ RFRIOiAxNS42MWNtOyBQQURESU5HLVRPUDogMC4wNWNtOyBCT1JERVItQk9UVE9NOiAjMDAwMDAw IDFweCBzb2xpZDsgSEVJR0hUOiA5LjQ0Y20iPg0KPHAgYWxpZ249ImxlZnQiPqFADQo8cD48YnI+ DQo8YnI+DQo8L3A+DQo8cCBzdHlsZT0iQ09MT1I6ICM5OTI4NGMiIGFsaWduPSJjZW50ZXIiPjxm b250IGZhY2U9IlRob3JuZGFsZSwgc2VyaWYiIGNvbG9yPSIjOTkyODRjIj48c3Bhbj48aT6mcKpH p0GquqR1p0Cko6/guqGorKVIpFex+KXzPC9pPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9 IkNPTE9SOiAjOTkyODRjIiBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJUaG9ybmRhbGUsIHNl cmlmIiBjb2xvcj0iIzk5Mjg0YyI+PHNwYW4+PGk+snumYrSjqNGnQaRArdOlraRapEiqusK9qK2+ 97d8PC9pPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9IkNPTE9SOiAjOTkyODRjIiBhbGln bj0iY2VudGVyIj48Zm9udCBmYWNlPSJUaG9ybmRhbGUsIHNlcmlmIiBjb2xvcj0iIzk5Mjg0YyI+ PHNwYW4+PGI+PGZvbnQgY29sb3I9IiMwMGFlMDAiIHNpemU9IjQiPqdBprO52rdRPC9mb250Pjwv Yj6hQbB0plg8Yj48Zm9udCBjb2xvcj0iIzAwYWUwMCIgc2l6ZT0iNCI+rmGkpLr0uPQ8L2ZvbnQ+ PC9iPqTOPGI+PGZvbnQgY29sb3I9IiMwMGFlMDAiIHNpemU9IjQiPqfarcy0o6jRqrq69K+4PC9m b250PjwvYj6hQaVIPGI+PGZvbnQgY29sb3I9IiMwMGFlMDAiIHNpemU9IjQiPq3drnSquq7JtqE8 L2ZvbnQ+PC9iPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9IkNPTE9SOiAjZmYwMDAwIiBh bGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJUaG9ybmRhbGUsIHNlcmlmIiBjb2xvcj0iI2ZmMDAw MCI+PHNwYW4+pF2v4MX9p0Gs/LnapqivdaHjoeM8L3NwYW4+PC9mb250PjwvcD4NCjxwIHN0eWxl PSJDT0xPUjogIzk5Mjg0YyIgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0iVGhvcm5kYWxlLCBz ZXJpZiIgY29sb3I9IiM5OTI4NGMiPjxzcGFuPjxzcGFuIHN0eWxlPSJCQUNLR1JPVU5EOiBub25l IHRyYW5zcGFyZW50IHNjcm9sbCByZXBlYXQgMCUgMCUiPjxiPjxmb250IGNvbG9yPSIjMDAwMGZm IiBzdHlsZT0iZm9udC1zaXplOiAxNnB0IiBzaXplPSI0Ij6npKVIq93AxTwvZm9udD48L2I+PC9z cGFuPqSjpnA8Yj48Zm9udCBjb2xvcj0iI2ZmMzMzMyIgc3R5bGU9ImZvbnQtc2l6ZTogMjBwdCIg c2l6ZT0iNSI+p+K0pL73t3w8L2ZvbnQ+oUE8L2I+tE637axPp2ymrKRArdO3c7jqsFShSaFJPC9z cGFuPjwvZm9udD48L3A+DQo8cCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJUaG9ybmRhbGUs IHNlcmlmIj48c3Bhbj48Zm9udCBjb2xvcj0iIzk5Mjg0YyI+pXWq4adBtFikwMTBoUGzb6T5PGEg aHJlZj0iaHR0cDovL2hvbWUua2ltby5jb20udHcveWlhbWl0eTMyMjUvIj48Yj49PSZndDu9daRX VkNEJmx0Oz09PC9iPjwvYT6xTrd8p+/F3KdBqrqkQKXNfn5+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPC9zcGFuPjxicj4NCjxicj4NCjxwPqFAPC9wPg0KPHAgYWxpZ249ImxlZnQiPjxicj4N Cjxicj4NCjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij48YnI+DQo8YnI+DQo8L3A+DQo8cCBhbGlnbj0i bGVmdCI+PGJyPg0KPC9wPg0KPHAgYWxpZ249ImxlZnQiPqFAPC9wPg0KPHAgYWxpZ249ImxlZnQi Pjxmb250IGZhY2U9IrdzstOp+sXpLCBzZXJpZiI+PGI+PGZvbnQgY29sb3I9IiNmZjAwMDAiPlBT PC9mb250PjwvYj46pnCms7+zvew8Yj48dT48Zm9udCBjb2xvcj0iI2ZmNjYwMCI+vdCxTrr0r7i4 1LLTuUPE/TwvZm9udD48L3U+PC9iPqjDPGI+PHU+PGZvbnQgY29sb3I9IiNmZjY2MDAiPq9kpFW4 1LLTuOquxjwvZm9udD48L3U+PC9iPqfarcyxTqnzNDikcK7JpLrBcDwvZm9udD48L3A+DQo8cCBh bGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0it3Oy06n6xeksIHNlcmlmIj61uLF6LKZwrHm2cblMpGq+ ya1QtWWtscJfwl/E8sTyvdCr3atEpnk8L2ZvbnQ+PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxmb250 IGZhY2U9IrdzstOp+sXpLCBzZXJpZiI+rnCuyajopkGkV711xlus3TwvZm9udD48YnI+DQo8L3A+ DQo8aHI+DQo8cCBzdHlsZT0iQ09MT1I6ICNmZjAwMDAiIGFsaWduPSJjZW50ZXIiPjxmb250IGZh Y2U9IrdzstOp+sXpLCBzZXJpZiIgY29sb3I9IiNmZjAwMDAiPjxzcGFuIHN0eWxlPSJCQUNLR1JP VU5EOiAjZmZmZjAwIj6mcKazpbTCWr3QqKO9zKFBpKO3UaZBpqyo7Ka5q0i90Kv2Jm5ic3A7IA0K LSZndDsmbmJzcDs8L3NwYW4+PC9mb250PjwvcD4NCjxwIGFsaWduPSJjZW50ZXIiPjxmb250IGZh Y2U9IlRob3JuZGFsZSwgc2VyaWYiPjxzcGFuIHN0eWxlPSJCQUNLR1JPVU5EOiAjZmZmZjAwIj48 Zm9udCBjb2xvcj0iI2ZmMDAwMCIgZmFjZT0it3Oy06n6xeksIHNlcmlmIj4oPGEgaHJlZj0iaHR0 cDovL3gtbWFpbC5oOGguY29tLnR3LyIgdGFyZ2V0PSJfYmxhbmsiPqnapqy8c6dpPC9hPik8L2Zv bnQ+PC9zcGFuPjwvZm9udD48L3A+DQo8cD48YnI+DQo8YnI+DQo8L3A+DQoNCjwvYm9keT4NCg0K PC9odG1sPg== ------=_NextPart_DoSV5H1zznrhrhlz6raW1cTg1AA-- ------=_NextPart_DoSV5H1zznrhrhlz6raW1cTg1-- From owner-freebsd-alpha@FreeBSD.ORG Wed Apr 2 16:09:50 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9531D37B401; Wed, 2 Apr 2003 16:09:50 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CC5E43F3F; Wed, 2 Apr 2003 16:09:50 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 1AF142A8A7; Wed, 2 Apr 2003 16:09:50 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-alpha@FreeBSD.org, freebsd-current@freebsd.org In-Reply-To: <20030403000725.65B7A43FA3@mx1.FreeBSD.org> Content-Transfer-Encoding: 8bit Date: Wed, 02 Apr 2003 16:09:50 -0800 From: Peter Wemm Message-Id: <20030403000950.1AF142A8A7@canning.wemm.org> Subject: Re: failure notice X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 00:09:50 -0000 MAILER-DAEMON@norton.palomine.net wrote: > Hi. This is the qmail-send program at norton.palomine.net. > I'm afraid I wasn't able to deliver your message to the following addresses. > This is a permanent error; I've given up. Sorry it didn't work out. GRRR. a spammer is sending out a batch of spam right now and using forged @freebsd.org addresses in the From: line. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-alpha@FreeBSD.ORG Wed Apr 2 16:17:58 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E228F37B401 for ; Wed, 2 Apr 2003 16:17:58 -0800 (PST) Received: from alcanet.com.au (mail3.alcanet.com.au [208.178.117.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B3AD43FA3 for ; Wed, 2 Apr 2003 16:17:57 -0800 (PST) (envelope-from peter.jeremy@alcatel.com.au) Received: from sydsmtp01.alcatel.com.au (IDENT:root@localhost.localdomain [127.0.0.1])h330HrGV027629; Thu, 3 Apr 2003 10:17:53 +1000 Received: from gsmx07.alcatel.com.au ([139.188.20.247]) by sydsmtp01.alcatel.com.au (Lotus Domino Release 5.0.11) with ESMTP id 2003040310175174:526 ; Thu, 3 Apr 2003 10:17:51 +1000 Received: from gsmx07.alcatel.com.au (localhost [127.0.0.1]) by gsmx07.alcatel.com.au (8.12.8/8.12.5) with ESMTP id h330Hpai029892; Thu, 3 Apr 2003 10:17:51 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.12.8/8.12.5/Submit) id h330HoRc029891; Thu, 3 Apr 2003 10:17:50 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Date: Thu, 3 Apr 2003 10:17:50 +1000 From: Peter Jeremy To: "Chris J. Mutter" Message-ID: <20030403001750.GW310@gsmx07.alcatel.com.au> Mail-Followup-To: "Chris J. Mutter" , freebsd-alpha@freebsd.org References: <200304021208.h32C8D0j020495@satanii.enemy.org> Mime-Version: 1.0 In-Reply-To: <200304021208.h32C8D0j020495@satanii.enemy.org> User-Agent: Mutt/1.4i X-MIMETrack: Itemize by SMTP Server on SYDSMTP01/AlcatelAustralia(Release 5.0.11 |July 24, 2002) at 03/04/2003 10:17:51 AM,|July 24, 2002) at 03/04/2003 10:17:53 AM, Serialize complete at 03/04/2003 10:17:53 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline cc: freebsd-alpha@freebsd.org Subject: Re: mylex dac960pu on alpha X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 00:17:59 -0000 On 2003-Apr-02 14:08:13 +0200, "Chris J. Mutter" wrote: >i have a question to the dac960pu: can this controller under firmware >2.x work with LVD drives bigger than 9gig? i would like to know this >before i order drives. If this is a KZPAC-AA or KZPAC-CA then you can use drives >9GB but I don't think it supports LVD. We have tried both 18GB and 36GB drives and both work as JBOD drives - but the 36GB drive is limited to 32GB (the block addresses wrap at 26 bits). I haven't tried mirroring (though I'd expect that to work) or creating multiple logical drives on a single physical drive. Peter From owner-freebsd-alpha@FreeBSD.ORG Wed Apr 2 16:28:59 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9D8837B49D; Wed, 2 Apr 2003 16:28:58 -0800 (PST) Received: from mail.braz.ru (bsd.braz.ru [194.84.218.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AC9743F75; Wed, 2 Apr 2003 16:28:56 -0800 (PST) (envelope-from amels@mail.braz.ru) Received: by mail.braz.ru (Postfix, from userid 1001) id C41E17B6F1; Thu, 3 Apr 2003 09:28:50 +0900 (IRKST) To: FreeBSD-gnats-submit@freebsd.org From: Sergey Amelyuschenko X-send-pr-version: 3.113 X-GNATS-Notify: Message-Id: <20030403002850.C41E17B6F1@mail.braz.ru> Date: Thu, 3 Apr 2003 09:28:50 +0900 (IRKST) cc: fjoe@freebsd.org cc: alpha@freebsd.org Subject: mc-4.6.0_2 is broken on alpha X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 00:28:59 -0000 >Submitter-Id: current-users >Originator: Sergey Amelyuschenko >Confidential: no >Synopsis: mc-4.6.0_2 is broken on alpha >Severity: non-critical >Priority: medium >Category: ports >Class: sw-bug >Release: FreeBSD 4.8-RC alpha >Environment: System: FreeBSD 4.8-RC FreeBSD 4.8-RC #8: Tue Apr 1 07:39:56 IRKST 2003 adminu5@mail.ru:/usr/obj/usr/src/sys/ALPHA alpha >Description: After upgrading mc port from 4.5.54_2 to 4.6.0_2 using of cvsup and portupgrade procedure I have in result broken mc. When I run mc it hangs. The only way to kill it is to execute "killall mc" from another console. Since CPU utilization is pretty high when mc is "hung", I think something is looping. If I roll back to mc-4.5.54_2, it works fine, so it is not kernel-related. I ran mc under truss trying to figure out what it is doing. Here is the tail of log truss mc on alpha: --- ... sigaction(SIGSYS,0x11ffb850,0x11ffb870) = 0 (0x0) __getcwd(0x12013a000,0x400) = 0 (0x0) sigaction(SIGSYS,0x11ffb870,0x0) = 0 (0x0) stat("/usr/home/user",0x11ffb928) = 0 (0x0) stat("/",0x11ffb9a0) = 0 (0x0) ioctl(1,CONS_GETINFO,0x12011b018) ERR#25 'Inappropriate ioctl for device' ioctl(1,TIOCGETA,0x12011cb2c) ERR#25 'Inappropriate ioctl for device' subshell.c: couldn't get terminal settings: Inappropriate ioctl for device writev(0x2,0x11ffb9f8,0x4) = 75 (0x4b) sigaction(SIGCHLD,0x11ffba28,0x0) = 0 (0x0) stat("/usr/home/user/.mc",0x11ffb9c8) = 0 (0x0) sigaction(SIGTSTP,0x0,0x120131410) = 0 (0x0) issetugid() = 0 (0x0) issetugid() = 0 (0x0) getuid() = 1001 (0x3e9) issetugid() = 0 (0x0) getuid() = 1001 (0x3e9) access("/usr/home/user/.terminfo/x/xterm",4) ERR#2 'No such file or directory' access("/usr/share/misc/terminfo/x/xterm",4) ERR#2 'No such file or directory' issetugid() = 0 (0x0) stat("/usr/home/user/.termcap.db",0x11ffa948) ERR#2 'No such file or directory' open("/usr/home/user/.termcap.db",0x0,00) ERR#2 'No such file or directory' open("/usr/home/user/.termcap",0x0,00) ERR#2 'No such file or directory' stat("/usr/share/misc/termcap.db",0x11ffa948) = 0 (0x0) open("/usr/share/misc/termcap.db",0x0,00) = 3 (0x3) fcntl(0x3,0x2,0x1) = 0 (0x0) read(0x3,0x120141000,0x104) = 260 (0x104) lseek(3,0x76000,0) = 483328 (0x76000) read(0x3,0x120142000,0x2000) = 8192 (0x2000) break(0x120146000) = 0 (0x0) lseek(3,0x90000,0) = 589824 (0x90000) read(0x3,0x120144000,0x2000) = 8192 (0x2000) close(3) = 0 (0x0) ioctl(1,TIOCGETA,0x11ffb928) ERR#25 'Inappropriate ioctl for device' ioctl(2,TIOCGETA,0x11ffb8e8) ERR#25 'Inappropriate ioctl for device' ioctl(1,TIOCGWINSZ,0x11ffb9a8) ERR#25 'Inappropriate ioctl for device' ioctl(0,TIOCGWINSZ,0x11ffb9a8) = 0 (0x0) ioctl(0,TIOCGETA,0x12011c5d0) = 0 (0x0) sigprocmask(0x1,0x11ffb988,0x16059b1bc) = 0 (0x0) open("/dev/tty",0x2,054026330674) = 3 (0x3) ioctl(3,TIOCGETA,0x1605893e0) = 0 (0x0) ioctl(3,TIOCGETA,0x11ffb9c8) = 0 (0x0) ioctl(3,TIOCSETAW,0x11ffb9c8) = 0 (0x0) sigprocmask(0x3,0x16059b1bc,0x0) = 0 (0x0) ioctl(3,TIOCGETA,0x12011c5fc) = 0 (0x0) ioctl(3,TIOCSETAW,0x12011c5fc) = 0 (0x0) ioctl(3,TIOCSETA,0x12011c5fc) = 0 (0x0) sigprocmask(0x1,0x11ffb9c8,0x16059b1bc) = 0 (0x0) break(0x120148000) = 0 (0x0) sigprocmask(0x3,0x16059b1bc,0x0) = 0 (0x0) sigaction(SIGINT,0x11ffba08,0x11ffba28) = 0 (0x0) access("/usr/home/user/.mc/ini",4) = 0 (0x0) open("/usr/home/user/.mc/ini",0x0,0666) = 4 (0x4) fstat(4,0x11ffa728) = 0 (0x0) break(0x12014a000) = 0 (0x0) read(0x4,0x120148000,0x2000) = 3109 (0xc25) break(0x12014c000) = 0 (0x0) read(0x4,0x120148000,0x2000) = 0 (0x0) close(4) = 0 (0x0) getuid() = 1001 (0x3e9) geteuid() = 1001 (0x3e9) getgid() = 0 (0x0) getegid() = 0 (0x0) open("/usr/local/share/mc/mc.charsets",0x0,0666) = 4 (0x4) fstat(4,0x11ffb758) = 0 (0x0) read(0x4,0x120148000,0x2000) = 213 (0xd5) read(0x4,0x120148000,0x2000) = 0 (0x0) lseek(4,0x0,0) = 213 (0xd5) lseek(4,0x0,0) = 0 (0x0) read(0x4,0x120148000,0x2000) = 213 (0xd5) read(0x4,0x120148000,0x2000) = 0 (0x0) close(4) = 0 (0x0) sigprocmask(0x1,0x11ffba18,0x16059b1bc) = 0 (0x0) 1;32r(B)032;1Hm37m40mm0mm K write(1,0x1605862e0,48) = 48 (0x30) sigprocmask(0x3,0x16059b1bc,0x0) = 0 (0x0) SIGNAL 15 SIGNAL 15 process exit, rval = 15 --- >How-To-Repeat: cvsup ports as of 04/01/03 and install /usr/ports/misc/mc port on alpha system. Run mc and it will hang. >Fix: When I roll back to mc-4.5.54_2, it works fine. From owner-freebsd-alpha@FreeBSD.ORG Thu Apr 3 05:17:54 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50D8937B401 for ; Thu, 3 Apr 2003 05:17:54 -0800 (PST) Received: from smartrafficenter.org (pacer.smartrafficenter.org [207.14.56.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 78B1A43FBD for ; Thu, 3 Apr 2003 05:17:53 -0800 (PST) (envelope-from kpieckiel@smartrafficenter.org) Received: (qmail 9624 invoked by uid 1500); 3 Apr 2003 13:17:52 -0000 Date: Thu, 3 Apr 2003 08:17:52 -0500 From: "Kevin A. Pieckiel" To: freebsd-alpha@freebsd.org Message-ID: <20030403131752.GA90878@pacer.dmz.smartrafficenter.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline User-Agent: Mutt/1.4i Subject: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 13:17:54 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I just acquired an AlphaServer 1200. This is my first experience with actually operating an alpha aside from having a shell account on one. When it arrives, it will have NetBSD; I'm considering putting FreeBSD on it. Should I decide to do so, how can I best help the alpha developers of FreeBSD in regards to testing and bug reporting? I'm a developer who's intimately familiar with ANSI C, but I've never attempted to become familiar with kernel code. I'm willing to spend some time on the alpha port since I now own an alpha. I'm guessing running 5.0-current would be helpful, since there are LOTS of untested architectural changes in the code.... Or is this best asked on -hackers? Thanks, Kevin "I am, to all intents and purposes, God. And you do not mess with God, because he is only 14 keypresses from removing your presence from the system" --- This message was signed by GnuPG. E-Mail kpieckiel-pgp@smartrafficenter.org to receive my public key. You may also get my key from pgpkeys.mit.edu; my ID is 0xF1604E92 and will expire on 01 January 2004. --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+jDSAc3iJbvFgTpIRAvZbAJ9+Zn3+QV2XH315eDZ1Sl5uGaEorACfVn1c 7+Mwm4cH6nk5/LshfIyh8lQ= =+wz3 -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-alpha@FreeBSD.ORG Thu Apr 3 10:55:13 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1413037B401 for ; Thu, 3 Apr 2003 10:55:13 -0800 (PST) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id D790D43F93 for ; Thu, 3 Apr 2003 10:55:11 -0800 (PST) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.9/8.12.9) with ESMTP id h33ItAik006327; Thu, 3 Apr 2003 20:55:11 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.9/8.12.9/Submit) id h33ItA2q006326; Thu, 3 Apr 2003 20:55:10 +0200 (CEST) Date: Thu, 3 Apr 2003 20:55:10 +0200 From: Wilko Bulte To: "Kevin A. Pieckiel" Message-ID: <20030403185510.GA6302@freebie.xs4all.nl> References: <20030403131752.GA90878@pacer.dmz.smartrafficenter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20030403131752.GA90878@pacer.dmz.smartrafficenter.org> User-Agent: Mutt/1.4i X-OS: FreeBSD 4.8-RC X-PGP: finger wilko@freebsd.org cc: freebsd-alpha@freebsd.org Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 18:55:13 -0000 On Thu, Apr 03, 2003 at 08:17:52AM -0500, Kevin A. Pieckiel wrote: > I just acquired an AlphaServer 1200. This is my first experience with actually > operating an alpha aside from having a shell account on one. When it arrives, > it will have NetBSD; I'm considering putting FreeBSD on it. Should I decide to > do so, how can I best help the alpha developers of FreeBSD in regards to testing > and bug reporting? I'm a developer who's intimately familiar with ANSI C, but > I've never attempted to become familiar with kernel code. I'm willing to spend > some time on the alpha port since I now own an alpha. I'm guessing running > 5.0-current would be helpful, since there are LOTS of untested architectural > changes in the code.... > > Or is this best asked on -hackers? There are not too many people with AS1200 in the FreeBSD community (it seems, when I looked for testers, see also http://www.freebsd.org/~wilko/testhw.html). So as a tester you are more than welcome :-P I suggest to play with 4.8 / stable a bit before going to -current. Until you get more familiar with FreeBSD. -current can be a bit of a rocky ride, especially on non-x86 architectures. my €0.02.. W/ -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte From owner-freebsd-alpha@FreeBSD.ORG Thu Apr 3 11:37:40 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8896037B401 for ; Thu, 3 Apr 2003 11:37:40 -0800 (PST) Received: from smartrafficenter.org (pacer.smartrafficenter.org [207.14.56.3]) by mx1.FreeBSD.org (Postfix) with SMTP id AA24543FD7 for ; Thu, 3 Apr 2003 11:37:39 -0800 (PST) (envelope-from kpieckiel@smartrafficenter.org) Received: (qmail 17160 invoked by uid 1500); 3 Apr 2003 19:37:38 -0000 Date: Thu, 3 Apr 2003 14:37:38 -0500 From: "Kevin A. Pieckiel" To: Wilko Bulte Message-ID: <20030403193738.GB90878@pacer.dmz.smartrafficenter.org> References: <20030403131752.GA90878@pacer.dmz.smartrafficenter.org> <20030403185510.GA6302@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" Content-Disposition: inline In-Reply-To: <20030403185510.GA6302@freebie.xs4all.nl> User-Agent: Mutt/1.4i cc: freebsd-alpha@freebsd.org Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 19:37:40 -0000 --DKU6Jbt7q3WqK7+M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 03, 2003 at 08:55:10PM +0200, Wilko Bulte wrote: > On Thu, Apr 03, 2003 at 08:17:52AM -0500, Kevin A. Pieckiel wrote: > > I just acquired an AlphaServer 1200. This is my first experience with = actually > > operating an alpha aside from having a shell account on one. When it a= rrives, > > it will have NetBSD; I'm considering putting FreeBSD on it. Should I d= ecide to > > do so, how can I best help the alpha developers of FreeBSD in regards t= o testing > > and bug reporting? I'm a developer who's intimately familiar with ANSI= C, but > > I've never attempted to become familiar with kernel code. I'm willing = to spend > > some time on the alpha port since I now own an alpha. I'm guessing run= ning > > 5.0-current would be helpful, since there are LOTS of untested architec= tural > > changes in the code.... > >=20 > > Or is this best asked on -hackers? >=20 > There are not too many people with AS1200 in the FreeBSD community (it > seems, when I looked for testers, see also > http://www.freebsd.org/~wilko/testhw.html). So as a tester you are more t= han > welcome :-P >=20 > I suggest to play with 4.8 / stable a bit before going to -current. Until > you get more familiar with FreeBSD. -current can be a bit of a rocky ride, > especially on non-x86 architectures.=20 >=20 > my ???0.02.. Very well, then. I'll be glad to take your advice and make sure I'm comfor= table on the Alpha with 4.8. Thanks for the input. Kevin Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. --- This message was signed by GnuPG. E-Mail kpieckiel-pgp@smartrafficenter.org to receive my public key. You may also get my key from pgpkeys.mit.edu; my ID is 0xF1604E92 and will expire on 01 January 2004. --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+jI2Cc3iJbvFgTpIRAkkkAJ97GzFteR/OWXILDpnd+zcEtltlqgCfboHf 212GYYSFGREjUcsJoB0macA= =4Xzi -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M-- From owner-freebsd-alpha@FreeBSD.ORG Thu Apr 3 11:53:13 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D70B37B404 for ; Thu, 3 Apr 2003 11:53:13 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D87543F3F for ; Thu, 3 Apr 2003 11:53:12 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h33JrAMS007729 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Apr 2003 14:53:10 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h33Jr5j32591; Thu, 3 Apr 2003 14:53:05 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16012.37153.407140.240893@grasshopper.cs.duke.edu> Date: Thu, 3 Apr 2003 14:53:05 -0500 (EST) To: "Kevin A. Pieckiel" In-Reply-To: <20030403193738.GB90878@pacer.dmz.smartrafficenter.org> References: <20030403131752.GA90878@pacer.dmz.smartrafficenter.org> <20030403185510.GA6302@freebie.xs4all.nl> <20030403193738.GB90878@pacer.dmz.smartrafficenter.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-alpha@freebsd.org Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 19:53:13 -0000 Bear in mind that there are some circumstances where 4.x doesn't work on a 1200. Most notably when there is an NCR scsi controller on a non-zero hose. If you have problems installing 4.x, you may need to use 5.0. Drew From owner-freebsd-alpha@FreeBSD.ORG Thu Apr 3 12:16:21 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E949737B401 for ; Thu, 3 Apr 2003 12:16:21 -0800 (PST) Received: from smartrafficenter.org (pacer.smartrafficenter.org [207.14.56.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 0866743FAF for ; Thu, 3 Apr 2003 12:16:21 -0800 (PST) (envelope-from kpieckiel@smartrafficenter.org) Received: (qmail 17925 invoked by uid 1500); 3 Apr 2003 20:16:20 -0000 Date: Thu, 3 Apr 2003 15:16:20 -0500 From: "Kevin A. Pieckiel" To: Andrew Gallatin Message-ID: <20030403201620.GC90878@pacer.dmz.smartrafficenter.org> References: <20030403131752.GA90878@pacer.dmz.smartrafficenter.org> <20030403185510.GA6302@freebie.xs4all.nl> <20030403193738.GB90878@pacer.dmz.smartrafficenter.org> <16012.37153.407140.240893@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bKyqfOwhbdpXa4YI" Content-Disposition: inline In-Reply-To: <16012.37153.407140.240893@grasshopper.cs.duke.edu> User-Agent: Mutt/1.4i cc: freebsd-alpha@freebsd.org Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 20:16:22 -0000 --bKyqfOwhbdpXa4YI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 03, 2003 at 02:53:05PM -0500, Andrew Gallatin wrote: > Bear in mind that there are some circumstances where 4.x doesn't work > on a 1200. Most notably when there is an NCR scsi controller on a=20 > non-zero hose. If you have problems installing 4.x, you may need to > use 5.0. Non-zero hose? I've not heard that terminology before. Would you please define/explain this? I'm pretty sure (but not positive) it has an NCR controller. I'll verify when I actually have my hands on the machine within a few weeks. Thanks, Kevin "College isn't the place to go for ideas." -- Hellen Keller --- This message was signed by GnuPG. E-Mail kpieckiel-pgp@smartrafficenter.org to receive my public key. You may also get my key from pgpkeys.mit.edu; my ID is 0xF1604E92 and will expire on 01 January 2004. --bKyqfOwhbdpXa4YI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+jJaUc3iJbvFgTpIRArk1AJ45ylZg4dCuvEZC8s2osc5Drn1TrACfcxzv qdoqCov0INw0I2lUWKDdzq0= =PFZ9 -----END PGP SIGNATURE----- --bKyqfOwhbdpXa4YI-- From owner-freebsd-alpha@FreeBSD.ORG Thu Apr 3 12:30:25 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1FEF37B401 for ; Thu, 3 Apr 2003 12:30:25 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71F9743F3F for ; Thu, 3 Apr 2003 12:30:24 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h33KUMMS011186 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Apr 2003 15:30:22 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h33KUHt32626; Thu, 3 Apr 2003 15:30:17 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16012.39385.672997.35768@grasshopper.cs.duke.edu> Date: Thu, 3 Apr 2003 15:30:17 -0500 (EST) To: "Kevin A. Pieckiel" In-Reply-To: <20030403201620.GC90878@pacer.dmz.smartrafficenter.org> References: <20030403131752.GA90878@pacer.dmz.smartrafficenter.org> <20030403185510.GA6302@freebie.xs4all.nl> <20030403193738.GB90878@pacer.dmz.smartrafficenter.org> <16012.37153.407140.240893@grasshopper.cs.duke.edu> <20030403201620.GC90878@pacer.dmz.smartrafficenter.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-alpha@freebsd.org Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 20:30:25 -0000 Kevin A. Pieckiel writes: > On Thu, Apr 03, 2003 at 02:53:05PM -0500, Andrew Gallatin wrote: > > > Bear in mind that there are some circumstances where 4.x doesn't work > > on a 1200. Most notably when there is an NCR scsi controller on a > > non-zero hose. If you have problems installing 4.x, you may need to > > use 5.0. > > Non-zero hose? I've not heard that terminology before. Would you please > define/explain this? I'm pretty sure (but not positive) it has an NCR > controller. I'll verify when I actually have my hands on the machine > within a few weeks. > Alpha do peer buses differently. Rather than having multiple connections to the host system appear as fake pci-pci bridges like x86s do, each connection to the host system is called a "hose". Each hose has its own address space, and has its own tree of pci buses. Eg, hose 0 has a pci bus #0, and #1, etc, hose 1 has a pci bus #0, #1 #2, etc. The address space on hoses other than hose #0 is handled via a hack in 4.x, and some boards don't work because of that. This is done right in 5.x You can search the archives for more info. Drew From owner-freebsd-alpha@FreeBSD.ORG Thu Apr 3 12:35:04 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FE8C37B401 for ; Thu, 3 Apr 2003 12:35:04 -0800 (PST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id D368B43FBD for ; Thu, 3 Apr 2003 12:35:01 -0800 (PST) (envelope-from aknoland@mindspring.com) Received: from hsa057.pool035.at101.earthlink.net ([216.249.104.57] helo=mindspring.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 191BQK-0001by-00 for freebsd-alpha@freebsd.org; Thu, 03 Apr 2003 15:35:00 -0500 Message-ID: <3E8C9AF1.3090600@mindspring.com> Date: Thu, 03 Apr 2003 12:34:57 -0800 From: anthony noland User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-alpha@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 20:35:04 -0000 I also have an AS1200 running FreeBSD. I would be greatly interested in your experiences w/ FreeBSD and as1200. From owner-freebsd-alpha@FreeBSD.ORG Thu Apr 3 13:35:42 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 136A337B401 for ; Thu, 3 Apr 2003 13:35:42 -0800 (PST) Received: from smartrafficenter.org (pacer.smartrafficenter.org [207.14.56.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 3B3CE43FB1 for ; Thu, 3 Apr 2003 13:35:41 -0800 (PST) (envelope-from kpieckiel@smartrafficenter.org) Received: (qmail 19591 invoked by uid 1500); 3 Apr 2003 21:35:40 -0000 Date: Thu, 3 Apr 2003 16:35:40 -0500 From: "Kevin A. Pieckiel" To: Andrew Gallatin Message-ID: <20030403213540.GD90878@pacer.dmz.smartrafficenter.org> References: <20030403131752.GA90878@pacer.dmz.smartrafficenter.org> <20030403185510.GA6302@freebie.xs4all.nl> <20030403193738.GB90878@pacer.dmz.smartrafficenter.org> <16012.37153.407140.240893@grasshopper.cs.duke.edu> <20030403201620.GC90878@pacer.dmz.smartrafficenter.org> <16012.39385.672997.35768@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="at6+YcpfzWZg/htY" Content-Disposition: inline In-Reply-To: <16012.39385.672997.35768@grasshopper.cs.duke.edu> User-Agent: Mutt/1.4i cc: freebsd-alpha@freebsd.org Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 21:35:42 -0000 --at6+YcpfzWZg/htY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 03, 2003 at 03:30:17PM -0500, Andrew Gallatin wrote: > Alpha do peer buses differently. Rather than having multiple > connections to the host system appear as fake pci-pci bridges like > x86s do, each connection to the host system is called a "hose". Each > hose has its own address space, and has its own tree of pci buses. > Eg, hose 0 has a pci bus #0, and #1, etc, hose 1 has a pci bus #0, #1 > #2, etc. The address space on hoses other than hose #0 is handled via > a hack in 4.x, and some boards don't work because of that. This is > done right in 5.x Good summary. Thanks for the explanation; I appreciate that a great deal. I'm getting more and more interested in finding architectureal documents--tons for the x86, of course. But I'll go looking for some books or net articles before I officially ask for suggestions... :) Afterall, I can't expect to get any real help if I'm not willing to do my homework. I will note this information and do what I can to verify this before I attempt any install of the OS. Kevin No prisoner's dilemma here. Over the long term, symbiosis is more useful than parasitism. More fun, too. Ask any mitochondria. -- Larry Wall --- This message was signed by GnuPG. E-Mail kpieckiel-pgp@smartrafficenter.org to receive my public key. You may also get my key from pgpkeys.mit.edu; my ID is 0xF1604E92 and will expire on 01 January 2004. --at6+YcpfzWZg/htY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+jKksc3iJbvFgTpIRAqRrAJ4plXQM1GxgTPQYtOiovMZzb9g6FQCffDYg dHg9ZZtyGjdQsIM6qYzN28s= =EZ2a -----END PGP SIGNATURE----- --at6+YcpfzWZg/htY-- From owner-freebsd-alpha@FreeBSD.ORG Thu Apr 3 13:49:09 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5358737B401 for ; Thu, 3 Apr 2003 13:49:09 -0800 (PST) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E41F43FB1 for ; Thu, 3 Apr 2003 13:49:08 -0800 (PST) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.9/8.12.9) with ESMTP id h33Ljuik007763; Thu, 3 Apr 2003 23:45:56 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.9/8.12.9/Submit) id h33LirZY007755; Thu, 3 Apr 2003 23:44:53 +0200 (CEST) Date: Thu, 3 Apr 2003 23:44:53 +0200 From: Wilko Bulte To: "Kevin A. Pieckiel" Message-ID: <20030403214453.GB7702@freebie.xs4all.nl> References: <20030403131752.GA90878@pacer.dmz.smartrafficenter.org> <20030403185510.GA6302@freebie.xs4all.nl> <20030403193738.GB90878@pacer.dmz.smartrafficenter.org> <16012.37153.407140.240893@grasshopper.cs.duke.edu> <20030403201620.GC90878@pacer.dmz.smartrafficenter.org> <16012.39385.672997.35768@grasshopper.cs.duke.edu> <20030403213540.GD90878@pacer.dmz.smartrafficenter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030403213540.GD90878@pacer.dmz.smartrafficenter.org> User-Agent: Mutt/1.4i X-OS: FreeBSD 4.8-RC X-PGP: finger wilko@freebsd.org cc: freebsd-alpha@freebsd.org Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 21:49:09 -0000 On Thu, Apr 03, 2003 at 04:35:40PM -0500, Kevin A. Pieckiel wrote: > On Thu, Apr 03, 2003 at 03:30:17PM -0500, Andrew Gallatin wrote: > > hose has its own address space, and has its own tree of pci buses. > > Eg, hose 0 has a pci bus #0, and #1, etc, hose 1 has a pci bus #0, #1 > > #2, etc. The address space on hoses other than hose #0 is handled via > > a hack in 4.x, and some boards don't work because of that. This is > > done right in 5.x > > Good summary. Thanks for the explanation; I appreciate that a great > deal. I'm getting more and more interested in finding architectureal > documents--tons for the x86, of course. But I'll go looking for some > books or net articles before I officially ask for suggestions... :) > Afterall, I can't expect to get any real help if I'm not willing to do > my homework. Check the HARDWARE.TXT on an Freebsd/alpha CD near you. More recommended reading on Alpha machines can be found on http://www.netbsd.org And last but not least: by all means ask if need be. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte From owner-freebsd-alpha@FreeBSD.ORG Thu Apr 3 16:37:05 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E998737B401 for ; Thu, 3 Apr 2003 16:37:05 -0800 (PST) Received: from mail4.atl.registeredsite.com (mail4.atl.registeredsite.com [64.224.219.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29D0843F93 for ; Thu, 3 Apr 2003 16:37:05 -0800 (PST) (envelope-from opalpha@terraflux.com) Received: from terraflux.com ([216.122.242.190])h340b2Mb006371 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 3 Apr 2003 19:37:02 -0500 Received: from [192.168.0.40] (simon.metroflux.net [63.201.252.211]) by terraflux.com (8.11.6/8.11.0) with ESMTP id h340b0V45633 for ; Thu, 3 Apr 2003 16:37:01 -0800 (PST) (envelope-from opalpha@terraflux.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 03 Apr 2003 16:36:59 -0800 From: oliver To: Message-ID: In-Reply-To: <3E8C9AF1.3090600_mindspring.com@ns.sol.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2003 00:37:06 -0000 I have Freebsd 5.0 running on an as1200. Works pretty good, given the current project state. Did not encounter many problems, but did switch to 5.0 because of an ncr hose issue. Drew was kind enough to help me with that one some time ago. I did not get the nic on the ncr controller to work (tulip), but installed two fxp's instead. Cheers, Oliver On 4/3/03 12:49, in article 3E8C9AF1.3090600_mindspring.com@ns.sol.net, "aknoland@mindspring.com" wrote: > I also have an AS1200 running FreeBSD. I would be greatly interested in > your experiences w/ FreeBSD and as1200. > > _______________________________________________ > freebsd-alpha@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-alpha > To unsubscribe, send any mail to "freebsd-alpha-unsubscribe@freebsd.org" From owner-freebsd-alpha@FreeBSD.ORG Thu Apr 3 17:00:07 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9067737B405 for ; Thu, 3 Apr 2003 17:00:07 -0800 (PST) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D005E43F75 for ; Thu, 3 Apr 2003 17:00:06 -0800 (PST) (envelope-from aknoland@earthlink.net) Received: from hsa057.pool035.at101.earthlink.net ([216.249.104.57] helo=earthlink.net) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 191FYr-0005Mq-00 for freebsd-alpha@freebsd.org; Thu, 03 Apr 2003 17:00:05 -0800 Message-ID: <3E8CD913.5040101@earthlink.net> Date: Thu, 03 Apr 2003 17:00:03 -0800 From: moonshine_religion User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-alpha@freebsd.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2003 01:00:07 -0000 Just a suggestion. As I read the freeBSD-Alpha post I have noticed several posters say their are very few people running as1200s. I think it would be nice to organize the few people with access to an as1200 for testing and other development specific to this hardware. Please let me know what you think. aknoland oliver wrote: > I have Freebsd 5.0 running on an as1200. Works pretty good, given the > current project state. > > Did not encounter many problems, but did switch to 5.0 because of an ncr > hose issue. Drew was kind enough to help me with that one some time ago. > > I did not get the nic on the ncr controller to work (tulip), but installed > two fxp's instead. > > Cheers, > Oliver > > > On 4/3/03 12:49, in article 3E8C9AF1.3090600_mindspring.com@ns.sol.net, > "aknoland@mindspring.com" wrote: > > >>I also have an AS1200 running FreeBSD. I would be greatly interested in >>your experiences w/ FreeBSD and as1200. >> >>_______________________________________________ >>freebsd-alpha@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-alpha >>To unsubscribe, send any mail to "freebsd-alpha-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-alpha@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-alpha > To unsubscribe, send any mail to "freebsd-alpha-unsubscribe@freebsd.org" > From owner-freebsd-alpha@FreeBSD.ORG Fri Apr 4 08:34:45 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B8AA37B405 for ; Fri, 4 Apr 2003 08:34:45 -0800 (PST) Received: from smartrafficenter.org (pacer.smartrafficenter.org [207.14.56.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 3EE1143FBF for ; Fri, 4 Apr 2003 08:34:41 -0800 (PST) (envelope-from kpieckiel@smartrafficenter.org) Received: (qmail 42459 invoked by uid 1500); 4 Apr 2003 16:34:37 -0000 Date: Fri, 4 Apr 2003 11:34:37 -0500 From: "Kevin A. Pieckiel" To: moonshine_religion Message-ID: <20030404163437.GE90878@pacer.dmz.smartrafficenter.org> References: <3E8CD913.5040101@earthlink.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pY3vCvL1qV+PayAL" Content-Disposition: inline In-Reply-To: <3E8CD913.5040101@earthlink.net> User-Agent: Mutt/1.4i cc: freebsd-alpha@freebsd.org Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2003 16:34:47 -0000 --pY3vCvL1qV+PayAL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 03, 2003 at 05:00:03PM -0800, moonshine_religion wrote: > Just a suggestion. As I read the freeBSD-Alpha post I have noticed=20 > several posters say their are very few people running as1200s. I think=20 > it would be nice to organize the few people with access to an as1200 for= =20 > testing and other development specific to this hardware. Please let me=20 > know what you think. I think it would be a great idea. If it gets structured/big enough, maybe even get a web forum set up somewhere for us to discuss/communicate. I don't think there would be enough participation to warrant a separate mailing list just for this model--the freebsd-alpha list would probably suffice (just my thinking--correct me if I'm wrong!). Like I said before, I'm no kernel developer, but I _AM_ a C programmer of many years. I would hate to pass by an opportunity to help the alpha port development if I am able to test/diagnose/etc. Is this something that we should be mentioning on -hackers? I don't know how many of the kernel programmers sift through these other lists... Kevin "Computers are the evil minions of Satan." --Too Much Coffee Man, by Shannon Wheeler --- This message was signed by GnuPG. E-Mail kpieckiel-pgp@smartrafficenter.org to receive my public key. You may also get my key from pgpkeys.mit.edu; my ID is 0xF1604E92 and will expire on 01 January 2004. --pY3vCvL1qV+PayAL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+jbQdc3iJbvFgTpIRAldpAJ4iP+YBRT3ZQAJZEO9+XY11ok6mZgCfR8bt bIXtB29+A0O77gZL+zhelSU= =ovI3 -----END PGP SIGNATURE----- --pY3vCvL1qV+PayAL-- From owner-freebsd-alpha@FreeBSD.ORG Fri Apr 4 08:50:43 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AFCB37B404 for ; Fri, 4 Apr 2003 08:50:43 -0800 (PST) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 044EA43F85 for ; Fri, 4 Apr 2003 08:50:35 -0800 (PST) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.9/8.12.9) with ESMTP id h34Gk0ik011685; Fri, 4 Apr 2003 18:46:00 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.9/8.12.9/Submit) id h34Givvq011650; Fri, 4 Apr 2003 18:44:57 +0200 (CEST) Date: Fri, 4 Apr 2003 18:44:57 +0200 From: Wilko Bulte To: "Kevin A. Pieckiel" Message-ID: <20030404164457.GA11618@freebie.xs4all.nl> References: <3E8CD913.5040101@earthlink.net> <20030404163437.GE90878@pacer.dmz.smartrafficenter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030404163437.GE90878@pacer.dmz.smartrafficenter.org> User-Agent: Mutt/1.4i X-OS: FreeBSD 4.8-RC X-PGP: finger wilko@freebsd.org cc: freebsd-alpha@freebsd.org Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2003 16:50:43 -0000 On Fri, Apr 04, 2003 at 11:34:37AM -0500, Kevin A. Pieckiel wrote: > On Thu, Apr 03, 2003 at 05:00:03PM -0800, moonshine_religion wrote: > > Just a suggestion. As I read the freeBSD-Alpha post I have noticed > > several posters say their are very few people running as1200s. I think > > it would be nice to organize the few people with access to an as1200 for > > testing and other development specific to this hardware. Please let me > > know what you think. > > I think it would be a great idea. If it gets structured/big enough, maybe > even get a web forum set up somewhere for us to discuss/communicate. > I don't think there would be enough participation to warrant a separate > mailing list just for this model--the freebsd-alpha list would probably > suffice (just my thinking--correct me if I'm wrong!). That should suffice, yes. > Like I said before, I'm no kernel developer, but I _AM_ a C programmer of > many years. I would hate to pass by an opportunity to help the alpha port > development if I am able to test/diagnose/etc. > > Is this something that we should be mentioning on -hackers? I don't know > how many of the kernel programmers sift through these other lists... Well, the alpha folks tend to be on -alpha, in addition to lists like -current etc. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte From owner-freebsd-alpha@FreeBSD.ORG Fri Apr 4 09:25:55 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B6AA37B401 for ; Fri, 4 Apr 2003 09:25:53 -0800 (PST) Received: from mail4.atl.registeredsite.com (mail4.atl.registeredsite.com [64.224.219.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16D7643FAF for ; Fri, 4 Apr 2003 09:25:53 -0800 (PST) (envelope-from opalpha@terraflux.com) Received: from terraflux.com ([216.122.242.190])h34HPmMb031573 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 4 Apr 2003 12:25:49 -0500 Received: from [192.168.0.40] (simon.metroflux.net [63.201.252.211]) by terraflux.com (8.11.6/8.11.0) with ESMTP id h34HPkV00848 for ; Fri, 4 Apr 2003 09:25:47 -0800 (PST) (envelope-from opalpha@terraflux.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 04 Apr 2003 09:25:42 -0800 From: oliver To: Message-ID: In-Reply-To: <20030404164457.GA11618@freebie.xs4all.nl> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2003 17:25:55 -0000 1. Regarding the group of as1200 owners or operators, I think it would be a good start to organize or construct some sort of list. 2. Secondly, and depending on what we want to do, I would be more than happy to set up an initial php-nuke "as1200-portal" on an adsl (384kbps up) here is San Jose, CA. In any case, I can offer to get the as1200-list started. Just email me at opi@pobox.com with name, email and owner or operator status. I you want, include some quick notes on system configuration (i.e. Nics (fxp etc), ncr controller etc)) After we have everyone, I will post the list (html) back to the group. Cheers, Oliver opi@pobox.com From owner-freebsd-alpha@FreeBSD.ORG Fri Apr 4 10:15:25 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1A6037B401 for ; Fri, 4 Apr 2003 10:15:24 -0800 (PST) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B89B43FA3 for ; Fri, 4 Apr 2003 10:15:24 -0800 (PST) (envelope-from aknoland@earthlink.net) Received: from hsa172.pool002.at101.earthlink.net ([216.249.66.172] helo=earthlink.net) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 191Vim-0005mm-00 for alpha@freebsd.org; Fri, 04 Apr 2003 10:15:24 -0800 Message-ID: <3E8DCBB8.80907@earthlink.net> Date: Fri, 04 Apr 2003 10:15:20 -0800 From: moonshine_religion User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alpha@freebsd.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: AS1200 X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2003 18:15:25 -0000 Excellent, More than I had hoped for Oliver, thanks. I will email you with my system details. oliver wrote: > 1. Regarding the group of as1200 owners or operators, I think it would be a > good start to organize or construct some sort of list. > > 2. Secondly, and depending on what we want to do, I would be more than happy > to set up an initial php-nuke "as1200-portal" on an adsl (384kbps up) here > is San Jose, CA. > > In any case, I can offer to get the as1200-list started. Just email me at > opi@pobox.com with name, email and owner or operator status. I you want, > include some quick notes on system configuration (i.e. Nics (fxp etc), ncr > controller etc)) After we have everyone, I will post the list (html) back to > the group. > > Cheers, > Oliver > opi@pobox.com > > _______________________________________________ > freebsd-alpha@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-alpha > To unsubscribe, send any mail to "freebsd-alpha-unsubscribe@freebsd.org" > From owner-freebsd-alpha@FreeBSD.ORG Fri Apr 4 16:28:03 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95F9637B401 for ; Fri, 4 Apr 2003 16:28:03 -0800 (PST) Received: from donut.efs.org (donut.efs.org [209.223.125.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE04D43F93 for ; Fri, 4 Apr 2003 16:28:01 -0800 (PST) (envelope-from matt@efs.org) Received: by donut.efs.org (Postfix, from userid 90) id D026F5C8A; Fri, 4 Apr 2003 16:26:43 -0800 (PST) Received: from sargon.photon.com (unknown [209.223.125.1]) by donut.efs.org (Postfix) with ESMTP id 3B1545C8C for ; Fri, 4 Apr 2003 16:26:32 -0800 (PST) Date: Fri, 4 Apr 2003 16:27:49 -0800 (PST) From: Matt Wilbur X-Sender: matt@sargon.photon.com To: freebsd-alpha@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=8.0 tests=AWL,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 X-Spam-Level: Subject: 4.7/4.8 problems w/AS800 and Qlogic ISP 1020/1040? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2003 00:28:03 -0000 Hi all, I have an AlphaServer 800 5/400 running 4.5-STABLE, which I've recently tried to upgrade to 4.7-STABLE (mid-march) and more recently to 4.8-RELEASE, using buildworld/etc. I've waited this long because I had to haul the beast out and verify cable connections, terminations, etc., to be sure, but I'm positive the hardware's fine - it keeps working great when I go back to 4.5-STABLE.. Upon booting into the 4.7-STABLE or 4.8-R kernel, I get this: Waiting 15 seconds for SCSI devices to settle isp0: Internal Firmware error on bus 0 @ RISC address 0x38dc isp0: Unknown isp_async event 16 as well as gobs of: (probe0: isp0:0:1:0): isp0: watchdog timeout for handle 0x30 for all the IDs on the bus.. I also (both with 4.5-S and these newer kernels) get this on bootup: isp0: port 0x10000-0x100ff mem 0x8186000 0-0x81860fff irq 0 at device 5.0 on pci0 isp0: interrupting at CIA irq 0 isp0: invalid NVRAM header Not sure if it's important.. One in ten times the system has come up after these complaints, but I don't have the guts to leave it running :) Just for the record, the system is rock-solid running its older 4.5-stable kernel (so I'm doubting any hardware scsi issues at this point), and I dont think I'm flubbing anything in the "upgrade from source" method, we maintain lots of FreeBSD systems this way - I'm just doing a buildworld, a buildkernel, installkernel, then I reboot and find its toast again, and move back to my old kernel and modules. Any suggestions, comments, etc. would be greatly appreciated.. Or would it make more sense to just submit a pr ? thanks! Matt From owner-freebsd-alpha@FreeBSD.ORG Fri Apr 4 16:48:03 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D159137B401 for ; Fri, 4 Apr 2003 16:48:03 -0800 (PST) Received: from donut.efs.org (donut.efs.org [209.223.125.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 173FE43F93 for ; Fri, 4 Apr 2003 16:48:03 -0800 (PST) (envelope-from matt@efs.org) Received: by donut.efs.org (Postfix, from userid 90) id 181815C8C; Fri, 4 Apr 2003 16:46:45 -0800 (PST) Received: from sargon.photon.com (unknown [209.223.125.1]) by donut.efs.org (Postfix) with ESMTP id E8AA75C8A for ; Fri, 4 Apr 2003 16:46:35 -0800 (PST) Date: Fri, 4 Apr 2003 16:47:53 -0800 (PST) From: Matt Wilbur X-Sender: matt@sargon.photon.com To: freebsd-alpha@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.7 required=8.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.41 X-Spam-Level: Subject: Re: 4.7/4.8 problems w/AS800 and Qlogic ISP 1020/1040? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2003 00:48:04 -0000 On Fri, 4 Apr 2003, Matt Wilbur wrote: Sorry, I forgot to include a full dmesg, unfortunately that's kind of tough to do w/the newer kernels, here it is from 4.5-STABLE from 3/8/2002 Copyright (c) 1992-2002 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 4.5-STABLE #0: Fri Mar 8 17:41:48 PST 2002 root@donut.efs.org:/d1/usrsrc/sys/compile/GENERIC AlphaServer 1000/1000A AlphaServer 800 5/400, 400MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=2 extensions=0x1 OSF PAL rev: 0x1000500020116 real memory = 266289152 (260048K bytes) avail memory = 252600320 (246680K bytes) Preloaded elf kernel "kernel" at 0xfffffc00007bc000. md0: Malloc disk cia0: ALCOR/ALCOR2, pass 3 cia0: extended capabilities: 21 pcib0: <2117x PCI host bus adapter> on cia0 pci0: on pcib0 isp0: port 0x10000-0x100ff mem 0x8186000 0-0x81860fff irq 0 at device 5.0 on pci0 isp0: interrupting at CIA irq 0 isp0: invalid NVRAM header pci0: at 6.0 irq 9 isab0: at device 7.0 on pci0 isa0: on isab0 de0: port 0x10100-0x1017f mem 0x81861000-0x818610 7f irq 1 at device 11.0 on pci0 de0: interrupting at CIA irq 1 de0: DEC DE500-AA 21140A [10-100Mb/s] pass 2.0 de0: address 00:00:f8:06:25:ce de0: enabling 10baseT port fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: interrupting at ISA irq 6 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 atkbd0: interrupting at ISA irq 1 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> mcclock0: at port 0x70-0x71 on isa0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio0: interrupting at ISA irq 4 sio1: reserved for low-level i/o ppc0: at port 0x3bc-0x3bf irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: cannot reserve interrupt, failed. lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 ppc0: interrupting at ISA irq 7 Timecounter "alpha" frequency 399998664 Hz Waiting 15 seconds for SCSI devices to settle sa0 at isp0 bus 0 target 3 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 12) da1 at isp0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da1: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da2 at isp0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da2: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da0 at isp0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da0: 2007MB (4110480 512 byte sectors: 255H 63S/T 255C) Mounting root from ufs:/dev/da0a cd0 at isp0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present TIA! Matt From owner-freebsd-alpha@FreeBSD.ORG Fri Apr 4 23:31:29 2003 Return-Path: Delivered-To: freebsd-alpha@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DA1937B401; Fri, 4 Apr 2003 23:31:29 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0FCF43FE3; Fri, 4 Apr 2003 23:31:28 -0800 (PST) (envelope-from imp@FreeBSD.org) Received: from freefall.freebsd.org (imp@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h357VSUp013758; Fri, 4 Apr 2003 23:31:28 -0800 (PST) (envelope-from imp@freefall.freebsd.org) Received: (from imp@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h357VSVb013754; Sat, 5 Apr 2003 00:31:28 -0700 (MST) Date: Sat, 5 Apr 2003 00:31:28 -0700 (MST) From: Warner Losh Message-Id: <200304050731.h357VSVb013754@freefall.freebsd.org> To: ajf@agitated.net, imp@FreeBSD.org, freebsd-alpha@FreeBSD.org Subject: Re: alpha/39560: unaligned access in wihap_input_data ( wi_hostap.c ) X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2003 07:31:29 -0000 Synopsis: unaligned access in wihap_input_data ( wi_hostap.c ) State-Changed-From-To: open->closed State-Changed-By: imp State-Changed-When: Sat Apr 5 00:30:54 MST 2003 State-Changed-Why: OBE: hostap is now done completely differently in 5.0 current and is both endian and alignment safe. http://www.freebsd.org/cgi/query-pr.cgi?pr=39560 From owner-freebsd-alpha@FreeBSD.ORG Sat Apr 5 11:43:10 2003 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBB6037B401; Sat, 5 Apr 2003 11:43:10 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 223C043FB1; Sat, 5 Apr 2003 11:43:10 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h35Jh9MS028840 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 5 Apr 2003 14:43:09 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h35Jh4Y38599; Sat, 5 Apr 2003 14:43:04 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16015.12744.366625.974350@grasshopper.cs.duke.edu> Date: Sat, 5 Apr 2003 14:43:04 -0500 (EST) To: Fred Clift In-Reply-To: <20030402090802.Y82002-400000@vespa.dmz.orem.verio.net> References: <20030401134113.GC1750@elvis.mu.org> <20030402090802.Y82002-400000@vespa.dmz.orem.verio.net> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: alpha@freebsd.org Subject: Re: call for testers: busdma-ified fxp(4) driver X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2003 19:43:11 -0000 Fred Clift writes: > > before: throughput in 10^6 bits/sec 39.18 > after: throughput in 10^6 bits/sec 94.11 > (dc): throughput in 10^6 bits/sec 70.97 > > > Honestly I'm suprised there is so much difference between the before and > after and I'm doubting my testing methodology -- perhaps I had the duplex My guess is that the old kernel has WITNESS enabled and the new kernel does not. Even a 600MHz 21264 is maxed out at 75Mb/sec with WITNESS enabled. 50% idle without. Drew