From owner-freebsd-sparc64@FreeBSD.ORG Sun Jun 8 03:49:01 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3085C37B401; Sun, 8 Jun 2003 03:48:59 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BE3143FD7; Sun, 8 Jun 2003 03:48:58 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h58Am1kF091841; Sun, 8 Jun 2003 06:48:01 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h58Am1b0091840; Sun, 8 Jun 2003 10:48:01 GMT (envelope-from des+tinderbox@freebsd.org) Date: Sun, 8 Jun 2003 10:48:01 GMT Message-Id: <200306081048.h58Am1b0091840@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Subject: [-CURRENT tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2003 10:49:01 -0000 TB --- 2003-06-08 09:39:45 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-08 09:39:45 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-08 09:42:36 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-06-08 10:34:32 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jun 8 10:34:33 GMT 2003 >>> Kernel build for GENERIC completed on Sun Jun 8 10:43:18 GMT 2003 TB --- 2003-06-08 10:43:18 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-08 10:43:18 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 8 10:43:18 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumconfig.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumdaemon.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinuminterrupt.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c: In function `write_volume_label': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: `LABELSECTOR' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-08 10:48:01 - /usr/bin/make returned exit code 1 TB --- 2003-06-08 10:48:01 - ERROR: failed to build lint kernel TB --- 2003-06-08 10:48:01 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Sun Jun 8 15:41:26 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F77337B401; Sun, 8 Jun 2003 15:41:26 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72B6A43FBD; Sun, 8 Jun 2003 15:41:25 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h58MeQkF055051; Sun, 8 Jun 2003 18:40:26 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h58MeQEj055050; Sun, 8 Jun 2003 22:40:26 GMT (envelope-from des+tinderbox@freebsd.org) Date: Sun, 8 Jun 2003 22:40:26 GMT Message-Id: <200306082240.h58MeQEj055050@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Subject: [-CURRENT tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2003 22:41:26 -0000 TB --- 2003-06-08 21:32:31 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-08 21:32:31 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-08 21:34:54 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-06-08 22:26:57 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jun 8 22:26:57 GMT 2003 >>> Kernel build for GENERIC completed on Sun Jun 8 22:35:47 GMT 2003 TB --- 2003-06-08 22:35:47 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-08 22:35:47 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 8 22:35:48 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumconfig.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumdaemon.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinuminterrupt.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c: In function `write_volume_label': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: `LABELSECTOR' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-08 22:40:26 - /usr/bin/make returned exit code 1 TB --- 2003-06-08 22:40:26 - ERROR: failed to build lint kernel TB --- 2003-06-08 22:40:26 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Sun Jun 8 18:40:34 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB9C937B401; Sun, 8 Jun 2003 18:40:34 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F9A843FBF; Sun, 8 Jun 2003 18:40:33 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h592Brvm019848; Sun, 8 Jun 2003 22:11:53 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h591eVKk079456; Sun, 8 Jun 2003 18:40:31 -0700 (PDT) (envelope-from jmg) Message-ID: <20030608184031.65067@hydrogen.funkthat.com> Date: Sun, 8 Jun 2003 18:40:31 -0700 From: John-Mark Gurney To: freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=wIy2ne0vdjdPXFts X-Mailer: Mutt 0.69 Organization: Cu Networking X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: fixing sparc build X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2003 01:40:35 -0000 --wIy2ne0vdjdPXFts Content-Type: text/plain; charset=us-ascii Does anyone object to me adding sparc64 to the #ifdef __alpha__ line in sys/disklabel.h? Attached is the patch I would commit. It has been verified to compile under sparc64. The only big change is that this changes the LABELOFFSET from 128 to 64 on sparc, but it doesn't look like any kernel source is using LABELOFFSET. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --wIy2ne0vdjdPXFts Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="disklabel.patch" Index: disklabel.h =================================================================== RCS file: /home/ncvs/src/sys/sys/disklabel.h,v retrieving revision 1.104 diff -u -r1.104 disklabel.h --- disklabel.h 2003/06/07 09:06:39 1.104 +++ disklabel.h 2003/06/09 01:37:41 @@ -60,7 +60,7 @@ #define LABELOFFSET 0 /* offset of label in sector */ #endif -#ifdef __alpha__ +#if defined(__alpha__) || defined(__sparc64__) #define LABELSECTOR 0 #define LABELOFFSET 64 #endif --wIy2ne0vdjdPXFts-- From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 9 03:48:36 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F32637B401; Mon, 9 Jun 2003 03:48:36 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79CD043FAF; Mon, 9 Jun 2003 03:48:35 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h59AlYkF018612; Mon, 9 Jun 2003 06:47:34 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h59AlXUc018611; Mon, 9 Jun 2003 10:47:33 GMT (envelope-from des+tinderbox@freebsd.org) Date: Mon, 9 Jun 2003 10:47:33 GMT Message-Id: <200306091047.h59AlXUc018611@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Subject: [-CURRENT tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2003 10:48:36 -0000 TB --- 2003-06-09 09:39:05 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-09 09:39:05 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-09 09:42:04 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-06-09 10:34:05 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Jun 9 10:34:05 GMT 2003 >>> Kernel build for GENERIC completed on Mon Jun 9 10:42:54 GMT 2003 TB --- 2003-06-09 10:42:54 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-09 10:42:54 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 9 10:42:54 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumconfig.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumdaemon.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinuminterrupt.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c: In function `write_volume_label': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: `LABELSECTOR' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-09 10:47:33 - /usr/bin/make returned exit code 1 TB --- 2003-06-09 10:47:33 - ERROR: failed to build lint kernel TB --- 2003-06-09 10:47:33 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 9 15:22:58 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC95C37B401; Mon, 9 Jun 2003 15:22:58 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19C2643F3F; Mon, 9 Jun 2003 15:22:58 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h59MLskF061779; Mon, 9 Jun 2003 18:21:54 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h59MLr76061778; Mon, 9 Jun 2003 22:21:53 GMT (envelope-from des+tinderbox@freebsd.org) Date: Mon, 9 Jun 2003 22:21:53 GMT Message-Id: <200306092221.h59MLr76061778@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Subject: [-CURRENT tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2003 22:22:59 -0000 TB --- 2003-06-09 21:14:31 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-09 21:14:31 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-09 21:16:29 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-06-09 22:08:26 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Jun 9 22:08:26 GMT 2003 >>> Kernel build for GENERIC completed on Mon Jun 9 22:17:15 GMT 2003 TB --- 2003-06-09 22:17:15 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-09 22:17:15 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 9 22:17:16 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumconfig.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumdaemon.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinuminterrupt.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c: In function `write_volume_label': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: `LABELSECTOR' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-09 22:21:53 - /usr/bin/make returned exit code 1 TB --- 2003-06-09 22:21:53 - ERROR: failed to build lint kernel TB --- 2003-06-09 22:21:53 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 9 16:58:42 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44F0737B401; Mon, 9 Jun 2003 16:58:42 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C927643FDD; Mon, 9 Jun 2003 16:58:40 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5A0UIvm020314; Mon, 9 Jun 2003 20:30:19 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h59NwcSI094334; Mon, 9 Jun 2003 16:58:38 -0700 (PDT) (envelope-from jmg) Message-ID: <20030609165838.32044@hydrogen.funkthat.com> Date: Mon, 9 Jun 2003 16:58:38 -0700 From: John-Mark Gurney To: freebsd-sparc64@freebsd.org, freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Bk0ad3yNHWXBV/QO" X-Mailer: Mutt 0.69 Organization: Cu Networking X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2003 23:58:42 -0000 --Bk0ad3yNHWXBV/QO Content-Type: text/plain; charset=us-ascii Hello, I've recently started work on making FreeBSD work better on a sparc64 box that a friend has. It's a Netra AX1105-500 (UltraSPARC-IIe 500MHz). So far I have found out that the pci bus numbering has problems. We don't attach pci busses as they are numbered in the bridge/OFW info. This causes problems with pciconf -l and pciconf -{w,r} not agreeing. It isn't too hard to tie down the busses to make pciconf agree with itself. The second problem is that this has two SME2300BGA chips on it. They are combo ebus/usb/1394/ethernet chips. The problem is that SUN in order to only have one ebus on the machine, removed function 0 of the device from probing. This means that the other functions of the pci card never get probed. This can be fixed by making sure we probe all the functions on all the devices on the PCI buses. This then gets the second ethernet and USB to probe and attach. Of course the correct way to fix it would be to mirror the OFW tree, and then probe any devices that exist in the OFW tree, but not in our device tree. Attached are the two patches to fix both the issues. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --Bk0ad3yNHWXBV/QO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pci.patch" Index: pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v retrieving revision 1.214 diff -u -r1.214 pci.c --- pci.c 2003/04/16 03:15:08 1.214 +++ pci.c 2003/06/09 23:35:56 @@ -825,7 +825,15 @@ ("dinfo_size too small")); maxslots = PCIB_MAXSLOTS(pcib); for (s = 0; s <= maxslots; s++) { +#ifdef __sparc64__ + /* + * XXX - some sparc hardware has valid hardware when the + * function 0 doesn't probe. Scan all functions. + */ + pcifunchigh = PCI_FUNCMAX; +#else pcifunchigh = 0; +#endif for (f = 0; f <= pcifunchigh; f++) { dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); if (dinfo != NULL) { --Bk0ad3yNHWXBV/QO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="apb.patch" Index: apb.c =================================================================== RCS file: /home/ncvs/src/sys/sparc64/pci/apb.c,v retrieving revision 1.4 diff -u -r1.4 apb.c --- apb.c 2002/03/24 02:10:56 1.4 +++ apb.c 2003/06/09 23:33:07 @@ -207,9 +207,11 @@ * number, we should pick a better value. One sensible alternative * would be to pick 255; the only tradeoff here is that configuration * transactions would be more widely routed than absolutely necessary. + * + * If we don't hardware the bus down, pciconf gets confused. */ if (sc->secbus != 0) { - child = device_add_child(dev, "pci", -1); + child = device_add_child(dev, "pci", sc->secbus); if (child != NULL) return (bus_generic_attach(dev)); } else --Bk0ad3yNHWXBV/QO-- From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 9 19:27:18 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB34837B401; Mon, 9 Jun 2003 19:27:18 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2225543F85; Mon, 9 Jun 2003 19:27:15 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h5A2R9Th042581 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 10 Jun 2003 04:27:12 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h5A2R8Os057780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2003 04:27:08 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h5A2R79F009469; Tue, 10 Jun 2003 04:27:08 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h5A2R7LB009468; Tue, 10 Jun 2003 04:27:07 +0200 (CEST) Date: Tue, 10 Jun 2003 04:27:07 +0200 From: Bernd Walter To: John-Mark Gurney , jhb@freebsd.org, imp@freebsd.org Message-ID: <20030610022706.GI509@cicely12.cicely.de> References: <20030609165838.32044@hydrogen.funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030609165838.32044@hydrogen.funkthat.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-RELEASE alpha User-Agent: Mutt/1.5.4i cc: freebsd-current@freebsd.org cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 02:27:19 -0000 On Mon, Jun 09, 2003 at 04:58:38PM -0700, John-Mark Gurney wrote: > Hello, > > I've recently started work on making FreeBSD work better on a sparc64 > box that a friend has. It's a Netra AX1105-500 (UltraSPARC-IIe 500MHz). > > So far I have found out that the pci bus numbering has problems. We > don't attach pci busses as they are numbered in the bridge/OFW info. > This causes problems with pciconf -l and pciconf -{w,r} not agreeing. > It isn't too hard to tie down the busses to make pciconf agree with > itself. > > The second problem is that this has two SME2300BGA chips on it. They > are combo ebus/usb/1394/ethernet chips. The problem is that SUN in > order to only have one ebus on the machine, removed function 0 of the > device from probing. This means that the other functions of the pci > card never get probed. This can be fixed by making sure we probe all > the functions on all the devices on the PCI buses. This then gets the > second ethernet and USB to probe and attach. > > Of course the correct way to fix it would be to mirror the OFW tree, > and then probe any devices that exist in the OFW tree, but not in our > device tree. > > Attached are the two patches to fix both the issues. > Index: pci.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v > retrieving revision 1.214 > diff -u -r1.214 pci.c > --- pci.c 2003/04/16 03:15:08 1.214 > +++ pci.c 2003/06/09 23:35:56 > @@ -825,7 +825,15 @@ > ("dinfo_size too small")); > maxslots = PCIB_MAXSLOTS(pcib); > for (s = 0; s <= maxslots; s++) { > +#ifdef __sparc64__ > + /* > + * XXX - some sparc hardware has valid hardware when the > + * function 0 doesn't probe. Scan all functions. > + */ > + pcifunchigh = PCI_FUNCMAX; > +#else > pcifunchigh = 0; > +#endif > for (f = 0; f <= pcifunchigh; f++) { > dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); > if (dinfo != NULL) { This is problematic as it ignores the fact about single function devices which may react to all function numbers. What about reverting the logic: Initialy set pcifunchigh = PCI_FUNCMAX and set pcifunchigh = 0 in case we catched a single function device. I don't think it should be sparc specific. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 9 21:09:35 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB33537B401; Mon, 9 Jun 2003 21:09:35 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6FD343F75; Mon, 9 Jun 2003 21:09:34 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5A4f4vm023398; Tue, 10 Jun 2003 00:41:05 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5A49Jhv097072; Mon, 9 Jun 2003 21:09:19 -0700 (PDT) (envelope-from jmg) Message-ID: <20030609210919.33379@hydrogen.funkthat.com> Date: Mon, 9 Jun 2003 21:09:19 -0700 From: John-Mark Gurney To: ticso@cicely.de References: <20030609165838.32044@hydrogen.funkthat.com> <20030610022706.GI509@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <20030610022706.GI509@cicely12.cicely.de>; from Bernd Walter on Tue, Jun 10, 2003 at 04:27:07AM +0200 Organization: Cu Networking X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-current@freebsd.org cc: imp@freebsd.org cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 04:09:36 -0000 Bernd Walter scribbled this message on Jun 10: > On Mon, Jun 09, 2003 at 04:58:38PM -0700, John-Mark Gurney wrote: > > +#ifdef __sparc64__ > > + /* > > + * XXX - some sparc hardware has valid hardware when the > > + * function 0 doesn't probe. Scan all functions. > > + */ > > + pcifunchigh = PCI_FUNCMAX; > > +#else > > pcifunchigh = 0; > > +#endif > > for (f = 0; f <= pcifunchigh; f++) { > > dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); > > if (dinfo != NULL) { > > This is problematic as it ignores the fact about single function > devices which may react to all function numbers. Wouldn't this happen with the current logic? since if function 0 is found, it scans the rest... (Might be getting confused with SCSI buses). > What about reverting the logic: > Initialy set pcifunchigh = PCI_FUNCMAX and set pcifunchigh = 0 in case > we catched a single function device. > I don't think it should be sparc specific. Actually, I was thinking that we could check to see if the next word is not -1. The chip responds to the rest of the registers, but just doesn't respond to the DEVVENDOR (first word). So, if we check if the first function's first word returns -1, check the second word, and if that is not -1, then probe all the rest of the functions. -bash-2.05b$ pciconf -r pci1:5:0 0x0:0x4 ffffffff 02800002 I'm also thinking of adding support code to the pci bus to let the userland add a new device node to be probed. It shouldn't be too hard, but would be help in these cases. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 9 21:47:42 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8574A37B401; Mon, 9 Jun 2003 21:47:42 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0B0F43FBD; Mon, 9 Jun 2003 21:47:38 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h5A4lJkA007790; Mon, 9 Jun 2003 22:47:19 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 09 Jun 2003 22:46:21 -0600 (MDT) Message-Id: <20030609.224621.71095461.imp@bsdimp.com> To: gurney_j@resnet.uoregon.edu, gurney_j@efn.org From: "M. Warner Losh" In-Reply-To: <20030609210919.33379@hydrogen.funkthat.com> References: <20030609165838.32044@hydrogen.funkthat.com> <20030610022706.GI509@cicely12.cicely.de> <20030609210919.33379@hydrogen.funkthat.com> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: ticso@cicely.de cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 04:47:42 -0000 In message: <20030609210919.33379@hydrogen.funkthat.com> John-Mark Gurney writes: : > > +#ifdef __sparc64__ : > > + /* : > > + * XXX - some sparc hardware has valid hardware when the : > > + * function 0 doesn't probe. Scan all functions. : > > + */ : > > + pcifunchigh = PCI_FUNCMAX; : > > +#else : > > pcifunchigh = 0; : > > +#endif : > > for (f = 0; f <= pcifunchigh; f++) { : > > dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); : > > if (dinfo != NULL) { : > : > This is problematic as it ignores the fact about single function : > devices which may react to all function numbers. : : Wouldn't this happen with the current logic? since if function 0 is : found, it scans the rest... (Might be getting confused with SCSI : buses). Actually, there's no reason not to scan the hardware. we likely should be checking the multi function status differently than we are right now. We also shouldn't be rejecting based on the vendor id. while that provides a convenient way to chek to see if it really isn't there, a better sanity check would be to check the header type to see if it a one we know about (0, 1 or 2). If so, then we know if the device is there. that might be a better hueristic to see if we need to scan everything. : Actually, I was thinking that we could check to see if the next word : is not -1. The chip responds to the rest of the registers, but just : doesn't respond to the DEVVENDOR (first word). since header type is a required field, this likely is a better way to go. maybe keep the test against -1 for adding it as a child, but don't assume nothing is there unless the header type is bogus. : I'm also thinking of adding support code to the pci bus to let the : userland add a new device node to be probed. It shouldn't be too hard, : but would be help in these cases. I'd rather tht we fix the pci probe code to do the right thing. Kludges like this tend to live for a long time because nobody bothers to fix them correctly... I'm thinking that the loop should be more like: pcifunchigh = 0; f = 0; hdrtype = REG(PCIR_HEADERTYPE, 1); if (hdrtype & 0x7f > 2) continue; if (hdrtype & 0x80) pcifunchigh = PCI_FUNCMAX; for (f = 0; f <= pcifunchigh; f++) { dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); if (dinfo != NULL) pci_add_child(dev, dinfo); } might be better code (REG likely needs to be correctly defined for this context). this is based on my limited understanding that function 0 shouldn't be attached and function 1 should... Warner From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 9 21:49:54 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B7CE37B401; Mon, 9 Jun 2003 21:49:54 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 494A943FD7; Mon, 9 Jun 2003 21:49:50 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h5A4nNkA007821; Mon, 9 Jun 2003 22:49:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 09 Jun 2003 22:48:25 -0600 (MDT) Message-Id: <20030609.224825.78717109.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely12.cicely.de From: "M. Warner Losh" In-Reply-To: <20030610022706.GI509@cicely12.cicely.de> References: <20030609165838.32044@hydrogen.funkthat.com> <20030610022706.GI509@cicely12.cicely.de> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: gurney_j@resnet.uoregon.edu cc: freebsd-current@freebsd.org cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 04:49:54 -0000 In message: <20030610022706.GI509@cicely12.cicely.de> Bernd Walter writes: : On Mon, Jun 09, 2003 at 04:58:38PM -0700, John-Mark Gurney wrote: : > Hello, : > : > I've recently started work on making FreeBSD work better on a sparc64 : > box that a friend has. It's a Netra AX1105-500 (UltraSPARC-IIe 500MHz). : > : > So far I have found out that the pci bus numbering has problems. We : > don't attach pci busses as they are numbered in the bridge/OFW info. : > This causes problems with pciconf -l and pciconf -{w,r} not agreeing. : > It isn't too hard to tie down the busses to make pciconf agree with : > itself. I have similar issues with cardbus cards... ... : > Of course the correct way to fix it would be to mirror the OFW tree, : > and then probe any devices that exist in the OFW tree, but not in our : > device tree. why is this the correct way to fix it? don't mean to be difficult, just don't see why sparc64 needs to eb different. Warner From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 01:23:39 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4100C37B404 for ; Tue, 10 Jun 2003 01:23:37 -0700 (PDT) Received: from abel.math.ntnu.no (abel.math.ntnu.no [129.241.15.50]) by mx1.FreeBSD.org (Postfix) with SMTP id 2DCA843F93 for ; Tue, 10 Jun 2003 01:23:36 -0700 (PDT) (envelope-from perhov@math.ntnu.no) Received: (qmail 29982 invoked by uid 29119); 10 Jun 2003 08:23:35 -0000 Date: Tue, 10 Jun 2003 10:23:35 +0200 (MEST) From: Per Kristian Hove To: freebsd-sparc64@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: if_dc on sparc64? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 08:23:39 -0000 The 5.1-RELEASE hardware notes for sparc64 lists the Netra X1 as fully supported, but the "Ethernet interfaces" section does not list the onboard Davicom network interface. Is the "ethernet interfaces" section or the "fully supported systems" section correct? (I seem to recall something about if_dc needing to be busdma'ed in order to work on sparc64, which may explain why I'm not getting mine to probe correctly?) OK load if_dc /boot/kernel/if_dc.ko text=0xdff8 data=0x608+0x8 syms=[0x8+0x1368+0x8+0xcd2] OK boot nothing to autoload yet. jumping to kernel entry at 0xc0040000. 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.1-RELEASE #0: Thu Jun 5 11:39:19 GMT 2003 root@sparkle.attlabs.net:/usr/obj/usr/src/sys/GENERIC [...] dc0: port 0x10100-0x101ff mem 0x2000-0x20ff irq 28 at device 5.0 on pci0 dc0: Ethernet address: 00:00:00:00:00:00 -- Per Kristian Hove Dept. of Mathematical Sciences Norwegian University of Science and Technology From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 03:31:04 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3684A37B401; Tue, 10 Jun 2003 03:31:04 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5852643F85; Tue, 10 Jun 2003 03:31:01 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h5AATskF001681; Tue, 10 Jun 2003 06:29:55 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h5AATpoC001680; Tue, 10 Jun 2003 10:29:51 GMT (envelope-from des+tinderbox@freebsd.org) Date: Tue, 10 Jun 2003 10:29:51 GMT Message-Id: <200306101029.h5AATpoC001680@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Subject: [-CURRENT tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 10:31:04 -0000 TB --- 2003-06-10 09:38:02 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-10 09:38:02 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-10 09:40:53 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/fwcontrol/fwcontrol.c:259: structure has no member named `isc' /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/fwcontrol/fwcontrol.c:259: structure has no member named `bmc' /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/fwcontrol/fwcontrol.c:259: structure has no member named `pmc' /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/fwcontrol/fwcontrol.c:260: structure has no member named `cyc_clk_acc' /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/fwcontrol/fwcontrol.c:260: structure has no member named `max_rec' /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/fwcontrol/fwcontrol.c:260: structure has no member named `max_rom' /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/fwcontrol/fwcontrol.c:261: structure has no member named `generation' /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/fwcontrol/fwcontrol.c:261: structure has no member named `link_spd' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/fwcontrol. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-10 10:29:51 - /usr/bin/make returned exit code 1 TB --- 2003-06-10 10:29:51 - ERROR: failed to build world TB --- 2003-06-10 10:29:51 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 04:45:48 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3519037B401 for ; Tue, 10 Jun 2003 04:45:48 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 6EF0743FB1 for ; Tue, 10 Jun 2003 04:45:46 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 10073 invoked by uid 65534); 10 Jun 2003 11:45:44 -0000 Received: from p508E7664.dip.t-dialin.net (EHLO galatea.local) (80.142.118.100) by mail.gmx.net (mp007) with SMTP; 10 Jun 2003 13:45:44 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19PhFL-0000bv-AB; Tue, 10 Jun 2003 13:24:59 +0200 Date: Tue, 10 Jun 2003 13:24:59 +0200 From: Thomas Moestl To: John-Mark Gurney Message-ID: <20030610112458.GA734@crow.dom2ip.de> Mail-Followup-To: John-Mark Gurney , freebsd-sparc64@freebsd.org, freebsd-current@freebsd.org References: <20030609165838.32044@hydrogen.funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030609165838.32044@hydrogen.funkthat.com> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl cc: freebsd-current@freebsd.org cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 11:45:48 -0000 On Mon, 2003/06/09 at 16:58:38 -0700, John-Mark Gurney wrote: > Hello, > > I've recently started work on making FreeBSD work better on a sparc64 > box that a friend has. It's a Netra AX1105-500 (UltraSPARC-IIe 500MHz). > > So far I have found out that the pci bus numbering has problems. We > don't attach pci busses as they are numbered in the bridge/OFW info. > This causes problems with pciconf -l and pciconf -{w,r} not agreeing. > It isn't too hard to tie down the busses to make pciconf agree with > itself. > > [...] > > Index: apb.c > =================================================================== > RCS file: /home/ncvs/src/sys/sparc64/pci/apb.c,v > retrieving revision 1.4 > diff -u -r1.4 apb.c > --- apb.c 2002/03/24 02:10:56 1.4 > +++ apb.c 2003/06/09 23:33:07 > @@ -207,9 +207,11 @@ > * number, we should pick a better value. One sensible alternative > * would be to pick 255; the only tradeoff here is that configuration > * transactions would be more widely routed than absolutely necessary. > + * > + * If we don't hardware the bus down, pciconf gets confused. > */ > if (sc->secbus != 0) { > - child = device_add_child(dev, "pci", -1); > + child = device_add_child(dev, "pci", sc->secbus); > if (child != NULL) > return (bus_generic_attach(dev)); > } else This one looks good, please commit. The comment above is outdated, so it might be better to just remove it completely. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 04:56:56 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 772F937B401; Tue, 10 Jun 2003 04:56:56 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E46843FA3; Tue, 10 Jun 2003 04:56:55 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h5ABuOTh050211 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 10 Jun 2003 13:56:32 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h5ABuLOs060145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2003 13:56:21 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h5ABuL9F010731; Tue, 10 Jun 2003 13:56:21 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h5ABuF7E010730; Tue, 10 Jun 2003 13:56:15 +0200 (CEST) Date: Tue, 10 Jun 2003 13:56:15 +0200 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20030610115615.GB10527@cicely12.cicely.de> References: <20030609165838.32044@hydrogen.funkthat.com> <20030610022706.GI509@cicely12.cicely.de> <20030609210919.33379@hydrogen.funkthat.com> <20030609.224621.71095461.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030609.224621.71095461.imp@bsdimp.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-RELEASE alpha User-Agent: Mutt/1.5.4i cc: gurney_j@resnet.uoregon.edu cc: freebsd-current@freebsd.org cc: freebsd-sparc64@freebsd.org cc: gurney_j@efn.org cc: ticso@cicely.de Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 11:56:56 -0000 On Mon, Jun 09, 2003 at 10:46:21PM -0600, M. Warner Losh wrote: > In message: <20030609210919.33379@hydrogen.funkthat.com> > John-Mark Gurney writes: > : > > +#ifdef __sparc64__ > : > > + /* > : > > + * XXX - some sparc hardware has valid hardware when the > : > > + * function 0 doesn't probe. Scan all functions. > : > > + */ > : > > + pcifunchigh = PCI_FUNCMAX; > : > > +#else > : > > pcifunchigh = 0; > : > > +#endif > : > > for (f = 0; f <= pcifunchigh; f++) { > : > > dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); > : > > if (dinfo != NULL) { > : > > : > This is problematic as it ignores the fact about single function > : > devices which may react to all function numbers. > : > : Wouldn't this happen with the current logic? since if function 0 is > : found, it scans the rest... (Might be getting confused with SCSI > : buses). No - it checks the mfdev flag before increasing pcifunchigh. > Actually, there's no reason not to scan the hardware. we likely > should be checking the multi function status differently than we are > right now. We also shouldn't be rejecting based on the vendor id. > while that provides a convenient way to chek to see if it really isn't > there, a better sanity check would be to check the header type to see > if it a one we know about (0, 1 or 2). If so, then we know if the > device is there. that might be a better hueristic to see if we need > to scan everything. > > : Actually, I was thinking that we could check to see if the next word > : is not -1. The chip responds to the rest of the registers, but just > : doesn't respond to the DEVVENDOR (first word). > > since header type is a required field, this likely is a better way to > go. maybe keep the test against -1 for adding it as a child, but > don't assume nothing is there unless the header type is bogus. > > : I'm also thinking of adding support code to the pci bus to let the > : userland add a new device node to be probed. It shouldn't be too hard, > : but would be help in these cases. > > I'd rather tht we fix the pci probe code to do the right thing. > Kludges like this tend to live for a long time because nobody bothers > to fix them correctly... > > I'm thinking that the loop should be more like: > > pcifunchigh = 0; > f = 0; > hdrtype = REG(PCIR_HEADERTYPE, 1); > if (hdrtype & 0x7f > 2) > continue; > if (hdrtype & 0x80) s/0x80/PCIM_MFDEV/ Maybe we should add a PCIM_REGLAYOUT as well. > pcifunchigh = PCI_FUNCMAX; > for (f = 0; f <= pcifunchigh; f++) { > dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); > if (dinfo != NULL) > pci_add_child(dev, dinfo); > } > > might be better code (REG likely needs to be correctly defined for > this context). This needs to be tested on that given hardware. I don't know if REG will work as expected because it asks function 0, which is disabled. > this is based on my limited understanding that function 0 shouldn't be > attached and function 1 should... -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 05:13:03 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BB3437B401; Tue, 10 Jun 2003 05:13:03 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FA3543F85; Tue, 10 Jun 2003 05:13:02 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h5ACCrTh050627 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 10 Jun 2003 14:12:55 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h5ACCpOs060249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2003 14:12:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h5ACCp9F010806; Tue, 10 Jun 2003 14:12:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h5ACCo4T010805; Tue, 10 Jun 2003 14:12:50 +0200 (CEST) Date: Tue, 10 Jun 2003 14:12:50 +0200 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20030610121249.GE10527@cicely12.cicely.de> References: <20030609165838.32044@hydrogen.funkthat.com> <20030610022706.GI509@cicely12.cicely.de> <20030609210919.33379@hydrogen.funkthat.com> <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610115615.GB10527@cicely12.cicely.de> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-RELEASE alpha User-Agent: Mutt/1.5.4i cc: gurney_j@resnet.uoregon.edu cc: freebsd-current@freebsd.org cc: gurney_j@efn.org cc: freebsd-sparc64@freebsd.org cc: ticso@cicely.de Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 12:13:03 -0000 On Tue, Jun 10, 2003 at 01:56:15PM +0200, Bernd Walter wrote: > On Mon, Jun 09, 2003 at 10:46:21PM -0600, M. Warner Losh wrote: > > I'm thinking that the loop should be more like: > > > > pcifunchigh = 0; > > f = 0; > > hdrtype = REG(PCIR_HEADERTYPE, 1); > > if (hdrtype & 0x7f > 2) > > continue; > > if (hdrtype & 0x80) > s/0x80/PCIM_MFDEV/ > Maybe we should add a PCIM_REGLAYOUT as well. > > > pcifunchigh = PCI_FUNCMAX; > > for (f = 0; f <= pcifunchigh; f++) { > > dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); > > if (dinfo != NULL) > > pci_add_child(dev, dinfo); > > } > > > > might be better code (REG likely needs to be correctly defined for > > this context). > > This needs to be tested on that given hardware. > I don't know if REG will work as expected because it asks function 0, > which is disabled. I've reread John-Mark's last mail about the readable registers. So - yes it should work. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 05:24:16 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D72D37B401 for ; Tue, 10 Jun 2003 05:24:16 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8896343FBF for ; Tue, 10 Jun 2003 05:24:15 -0700 (PDT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 720A02ED406; Tue, 10 Jun 2003 05:24:15 -0700 (PDT) Date: Tue, 10 Jun 2003 14:24:15 +0200 From: Maxime Henrion To: Per Kristian Hove Message-ID: <20030610122415.GI21011@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-sparc64@freebsd.org Subject: Re: if_dc on sparc64? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 12:24:16 -0000 Per Kristian Hove wrote: > The 5.1-RELEASE hardware notes for sparc64 lists the Netra X1 as fully > supported, but the "Ethernet interfaces" section does not list the > onboard Davicom network interface. > > Is the "ethernet interfaces" section or the "fully supported systems" > section correct? (I seem to recall something about if_dc needing to be > busdma'ed in order to work on sparc64, which may explain why I'm not > getting mine to probe correctly?) Yes, it needs to be busdma'd and made endian-clean. I'm taking care of this. Cheers, Maxime From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 07:30:18 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DCEB37B404; Tue, 10 Jun 2003 07:30:18 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04F8943FE0; Tue, 10 Jun 2003 07:30:16 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h5AESdkA011160; Tue, 10 Jun 2003 08:28:39 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 10 Jun 2003 08:27:30 -0600 (MDT) Message-Id: <20030610.082730.102566465.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely12.cicely.de From: "M. Warner Losh" In-Reply-To: <20030610121249.GE10527@cicely12.cicely.de> References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: gurney_j@resnet.uoregon.edu cc: freebsd-current@freebsd.org cc: gurney_j@efn.org cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 14:30:18 -0000 In message: <20030610121249.GE10527@cicely12.cicely.de> Bernd Walter writes: : On Tue, Jun 10, 2003 at 01:56:15PM +0200, Bernd Walter wrote: : > On Mon, Jun 09, 2003 at 10:46:21PM -0600, M. Warner Losh wrote: : > > I'm thinking that the loop should be more like: : > > : > > pcifunchigh = 0; : > > f = 0; : > > hdrtype = REG(PCIR_HEADERTYPE, 1); : > > if (hdrtype & 0x7f > 2) : > > continue; : > > if (hdrtype & 0x80) : > s/0x80/PCIM_MFDEV/ : > Maybe we should add a PCIM_REGLAYOUT as well. : > : > > pcifunchigh = PCI_FUNCMAX; : > > for (f = 0; f <= pcifunchigh; f++) { : > > dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); : > > if (dinfo != NULL) : > > pci_add_child(dev, dinfo); : > > } : > > : > > might be better code (REG likely needs to be correctly defined for : > > this context). : > : > This needs to be tested on that given hardware. : > I don't know if REG will work as expected because it asks function 0, : > which is disabled. : : I've reread John-Mark's last mail about the readable registers. : So - yes it should work. That's what inspired me. Also, I'd expected that we'd need some kind of tweaking to make it actually compile and be neat. Warner From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 08:46:23 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E325C37B401 for ; Tue, 10 Jun 2003 08:46:23 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BC4243FB1 for ; Tue, 10 Jun 2003 08:46:22 -0700 (PDT) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.9/8.12.9) with ESMTP id h5AFkRMZ006735; Tue, 10 Jun 2003 11:46:28 -0400 (EDT) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.9/8.12.9/Submit) id h5AFkNaZ006734; Tue, 10 Jun 2003 11:46:23 -0400 (EDT) Date: Tue, 10 Jun 2003 11:46:23 -0400 From: Jake Burkholder To: John-Mark Gurney , freebsd-sparc64@freebsd.org Message-ID: <20030610154623.GB3351@locore.ca> References: <20030609165838.32044@hydrogen.funkthat.com> <20030610112458.GA734@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610112458.GA734@crow.dom2ip.de> User-Agent: Mutt/1.4i Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 15:46:24 -0000 Apparently, On Tue, Jun 10, 2003 at 01:24:59PM +0200, Thomas Moestl said words to the effect of; > On Mon, 2003/06/09 at 16:58:38 -0700, John-Mark Gurney wrote: > > Hello, > > > > I've recently started work on making FreeBSD work better on a sparc64 > > box that a friend has. It's a Netra AX1105-500 (UltraSPARC-IIe 500MHz). > > > > So far I have found out that the pci bus numbering has problems. We > > don't attach pci busses as they are numbered in the bridge/OFW info. > > This causes problems with pciconf -l and pciconf -{w,r} not agreeing. > > It isn't too hard to tie down the busses to make pciconf agree with > > itself. > > > > [...] > > > > Index: apb.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/sparc64/pci/apb.c,v > > retrieving revision 1.4 > > diff -u -r1.4 apb.c > > --- apb.c 2002/03/24 02:10:56 1.4 > > +++ apb.c 2003/06/09 23:33:07 > > @@ -207,9 +207,11 @@ > > * number, we should pick a better value. One sensible alternative > > * would be to pick 255; the only tradeoff here is that configuration > > * transactions would be more widely routed than absolutely necessary. > > + * > > + * If we don't hardware the bus down, pciconf gets confused. > > */ > > if (sc->secbus != 0) { > > - child = device_add_child(dev, "pci", -1); > > + child = device_add_child(dev, "pci", sc->secbus); > > if (child != NULL) > > return (bus_generic_attach(dev)); > > } else > > This one looks good, please commit. The comment above is outdated, so > it might be better to just remove it completely. There's a PR about this that should be closed if it fixes the problem, sparc64/50789. Jake From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 09:49:49 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C256337B401 for ; Tue, 10 Jun 2003 09:49:49 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3095D43FE3 for ; Tue, 10 Jun 2003 09:49:48 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5AGfraV008637; Tue, 10 Jun 2003 12:41:54 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5AGnX5a014790; Tue, 10 Jun 2003 09:49:33 -0700 (PDT) (envelope-from jmg) Message-ID: <20030610094933.59350@hydrogen.funkthat.com> Date: Tue, 10 Jun 2003 09:49:33 -0700 From: John-Mark Gurney To: Jake Burkholder References: <20030609165838.32044@hydrogen.funkthat.com> <20030610112458.GA734@crow.dom2ip.de> <20030610154623.GB3351@locore.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <20030610154623.GB3351@locore.ca>; from Jake Burkholder on Tue, Jun 10, 2003 at 11:46:23AM -0400 Organization: Cu Networking X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 16:49:50 -0000 Jake Burkholder scribbled this message on Jun 10: > Apparently, On Tue, Jun 10, 2003 at 01:24:59PM +0200, > Thomas Moestl said words to the effect of; > > > This one looks good, please commit. The comment above is outdated, so > > it might be better to just remove it completely. > > There's a PR about this that should be closed if it fixes the problem, > sparc64/50789. Yes, this is the fix for that bug. Once I get it commited, I'll close the bug. Yes, that comment was quite outdated, so I have removed it. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 13:25:36 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF54A37B401 for ; Tue, 10 Jun 2003 13:25:36 -0700 (PDT) Received: from natural.keybaud.org (natural.keybaud.org [81.23.208.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id D18FB43FA3 for ; Tue, 10 Jun 2003 13:25:34 -0700 (PDT) (envelope-from steven@keybaud.org) Received: by natural.keybaud.org (Postfix, from userid 1002) id 0BB7481; Tue, 10 Jun 2003 21:25:28 +0100 (BST) Date: Tue, 10 Jun 2003 11:05:26 +0100 From: Steven Haywood To: questions@freebsd.org Message-ID: <20030610100526.GA537@keybaud.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Resent-From: steven@keybaud.org Resent-Date: Tue, 10 Jun 2003 21:25:27 +0100 Resent-To: sparc64@freebsd.org Resent-Message-Id: <20030610202528.0BB7481@natural.keybaud.org> Subject: Panic on 5.1-RELEASE sparc64 - Quotas X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 20:25:37 -0000 Hi folks I just upgraded my ultra 5 to 5.1-RELEASE from 5.0-RELEASE-p6 When I rebooted it, the box got into a panic-reboot loop. There's nothing about the panic in the message log (because it seems to have been something IO related. I've pasted the messages from the first boot at the bottom of the message. I recreated the problem in single-user mode as follows: boot -s fsck -p mount -u / mount -a quotacheck Quotacheck caused the panic, it flashed past too quickly for me to catch any details. The system then tried to sync the disks and failed, and reset. Disabling quotas in rc.conf allowed the box to boot. Have I missed something stupid? I enclose my kernel config file as well... Thanks! Steven Jun 10 10:24:44 natural reboot: rebooted by steven Jun 10 10:24:45 natural syslogd: exiting on signal 15 Jun 10 10:26:00 natural syslogd: kernel boot file is /boot/kernel/kernel Jun 10 10:26:00 natural kernel: Copyright (c) 1992-2003 The FreeBSD Project. Jun 10 10:26:00 natural kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jun 10 10:26:00 natural kernel: The Regents of the University of California. All rights reserved. Jun 10 10:26:00 natural kernel: FreeBSD 5.1-RELEASE #0: Tue Jun 10 09:41:16 BST 2003 Jun 10 10:26:00 natural kernel: root@natural.keybaud.org:/usr/obj/usr/src/sys/KEYBAUD Jun 10 10:26:00 natural kernel: Preloaded elf kernel "/boot/kernel/kernel" at 0xc0366000. Jun 10 10:26:00 natural kernel: Timecounter "tick" frequency 333000000 Hz Jun 10 10:26:00 natural kernel: real memory = 246702080 (235 MB) Jun 10 10:26:00 natural kernel: avail memory = 233340928 (222 MB) Jun 10 10:26:00 natural kernel: cpu0: Sun Microsystems UltraSparc-IIi Processor (333.00 MHz CPU) Jun 10 10:26:00 natural kernel: nexus0: Jun 10 10:26:00 natural kernel: pcib0: on nexus0 Jun 10 10:26:00 natural kernel: pcib0: Sabre, impl 0, version 0, ign 0x7c0, bus A Jun 10 10:26:00 natural kernel: DVMA map: 0xc0000000 to 0xc3ffffff Jun 10 10:26:00 natural kernel: pci0: on pcib0 Jun 10 10:26:00 natural kernel: pcib1: at device 1.0 on pci0 Jun 10 10:26:00 natural kernel: pci1: on pcib1 Jun 10 10:26:01 natural kernel: pcib2: at device 1.1 on pci0 Jun 10 10:26:01 natural kernel: pci2: on pcib2 Jun 10 10:26:01 natural kernel: ebus0: revision 0x01 Jun 10 10:26:01 natural kernel: ebus0: mem 0xf1000000-0xf17fffff,0xf0000000-0xf0ffffff at device 1.0 on pci2 Jun 10 10:26:01 natural kernel: ebus0: addr 0x140072f000-0x140072f003,0x140072c000-0x140072c003,0x140072a000-0x140072a003,0x14007 28000-0x1400728003,0x1400726000-0x1400726003 (no driver attached) Jun 10 10:26:01 natural kernel: ebus0: addr 0x1400724000-0x1400724003 irq 37 (no driver attached) Jun 10 10:26:01 natural kernel: ebus0: addr 0x1400504000-0x1400504002 (no driver attached) Jun 10 10:26:01 natural kernel: ebus0: addr 0x1400400000-0x140040007f irq 43 (no driver attached) Jun 10 10:26:01 natural kernel: ebus0: addr 0x14003083f8-0x14003083ff irq 41 (no driver attached) Jun 10 10:26:01 natural kernel: ebus0: addr 0x14003062f8-0x14003062ff irq 42 (no driver attached) Jun 10 10:26:01 natural kernel: ebus0: addr 0x1400700000-0x140070000f,0x140030015c-0x140030015d,0x14003043bc-0x14003043cb irq 34 ( no driver attached) Jun 10 10:26:01 natural kernel: ebus0: addr 0x1400720000-0x1400720003,0x1400706000-0x140070600f,0x14003023f0-0x14003023f7 irq 3 9 (no driver attached) Jun 10 10:26:01 natural kernel: eeprom0: addr 0x1400000000-0x1400001fff on ebus0 Jun 10 10:26:01 natural kernel: eeprom0: model mk48t59 Jun 10 10:26:01 natural kernel: eeprom0: hostid 80b5e4fa Jun 10 10:26:01 natural kernel: ebus0: addr 0x1000000000-0x10000fffff (no driver attached) Jun 10 10:26:01 natural kernel: ebus0: addr 0x1400722000-0x1400722003,0x1400704000-0x140070400f,0x1400702000-0x140070200f,0 x1400200000-0x14002000ff irq 36,35 (no driver attached) Jun 10 10:26:01 natural kernel: hme0: mem 0xe0000000-0xe0007fff irq 33 at device 1.1 on pci2 Jun 10 10:26:01 natural kernel: hme0: Ethernet address: 08:00:20:b5:e4:fa Jun 10 10:26:01 natural kernel: miibus0: on hme0 Jun 10 10:26:01 natural kernel: nsphy0: on miibus0 Jun 10 10:26:01 natural kernel: nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Jun 10 10:26:01 natural kernel: pci2: at device 2.0 (no driver attached) Jun 10 10:26:01 natural kernel: atapci0: port 0xc00020-0xc0002f,0xc00018-0xc0001b,0xc00010-0xc00017,0xc00008-0 xc0000b,0xc00000-0xc00007 irq 32 at device 3.0 on pci2 Jun 10 10:26:01 natural kernel: ata2: at 0xc00000 on atapci0 Jun 10 10:26:01 natural kernel: ata3: at 0xc00010 on atapci0 Jun 10 10:26:01 natural kernel: Timecounters tick every 10.000 msec Jun 10 10:26:01 natural kernel: ad0: 8693MB [17662/16/63] at ata2-master WDMA2 Jun 10 10:26:01 natural kernel: acd0: CDROM at ata3-master PIO4 Jun 10 10:26:01 natural kernel: Mounting root from ufs:/dev/ad0a Jun 10 10:27:38 natural syslogd: kernel boot file is /boot/kernel/kernel Jun 10 10:27:38 natural kernel: Copyright (c) 1992-2003 The FreeBSD Project. ------------ cat /usr/src/sys/sparc64/conf/KEYBAUD | grep -v ^# machine sparc64 cpu SUN4U ident GENERIC maxusers 0 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control options UFS_DIRHASH #Improve performance on big options MD_ROOT #MD is a potential root device options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP options COMPAT_FREEBSD4 #Keep this for a while options SCSI_DELAY=15000 #Delay (in ms) before probing options KTRACE #ktrace(1) syscall trace support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options INVARIANT_SUPPORT #Extra sanity checks of internal device apb # Sun APB PCI-PCI bridge device ebus device isa device pci device sbus device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device ahc # AHA2940 and onboard AIC7xxx devices device isp # Qlogic family device ispfw # Firmware module for Qlogic host adapters device sym # NCR/Symbios Logic (newer chipsets + device scbus # SCSI bus (required) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) device ofw_console # OpenBoot firmware console device device genclock # Generic clock interface device eeprom # eeprom (really an ebus driver for the MK48Txx) device "mk48txx" # Mostek MK48T02, MK48T08, MK48T59 clock device miibus # MII bus support device gem # Sun GEM/Sun ERI/Apple GMAC device hme # Sun HME (Happy Meal Ethernet) device random # Entropy device device loop # Network loopback device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device bpf #Berkeley packet filter options QUOTA options SCHED_4BSD From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 13:25:43 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A5BB37B401 for ; Tue, 10 Jun 2003 13:25:43 -0700 (PDT) Received: from natural.keybaud.org (natural.keybaud.org [81.23.208.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3E6A43F3F for ; Tue, 10 Jun 2003 13:25:42 -0700 (PDT) (envelope-from steven@keybaud.org) Received: by natural.keybaud.org (Postfix, from userid 1002) id 26FE383; Tue, 10 Jun 2003 21:25:36 +0100 (BST) Date: Tue, 10 Jun 2003 15:04:59 +0100 From: Steven Haywood To: questions@freebsd.org Message-ID: <20030610140459.GA1407@keybaud.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Resent-From: steven@keybaud.org Resent-Date: Tue, 10 Jun 2003 21:25:36 +0100 Resent-To: sparc64@freebsd.org Resent-Message-Id: <20030610202536.26FE383@natural.keybaud.org> Subject: Problem with threads in 5.1Release, sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 20:25:44 -0000 Hiya Pthread support seems to be a bit broken... When I try to compile mod_php4 or python from ports, the configure stage hangs at checking for pthreads_cflags... or similar Truss of conftest shows it's hanging on a poll (full truss below) I was able to install python by building without threads, but mod_php4 doesn't seem to have this option. Anyone have any suggestions? Thanks Steven natural# truss ./conftest mmap(0x0,7056,0x3,0x1000,-1,0x0) = 1075978240 (0x40222000) munmap(0x40222000,0x1b90) = 0 (0x0) __sysctl(0x7fdfffff4c0,0x2,0x40323110,0x7fdfffff4b8,0x0,0x0) = 0 (0x0) mmap(0x0,32768,0x3,0x1002,-1,0x0) = 1075978240 (0x40222000) geteuid() = 0 (0x0) getuid() = 0 (0x0) getegid() = 0 (0x0) getgid() = 0 (0x0) open("/var/run/ld-elf.so.hints",0x0,010010500130) = 3 (0x3) read(0x3,0x7fdfffff750,0x80) = 128 (0x80) mmap(0x0,40960,0x3,0x1002,-1,0x0) = 1076011008 (0x4022a000) lseek(3,0x80,-1) = 128 (0x80) read(0x3,0x4022c000,0x3d) = 61 (0x3d) close(3) = 0 (0x0) access("/usr/lib/libc_r.so.5",0) = 0 (0x0) open("/usr/lib/libc_r.so.5",0x0,013) = 3 (0x3) fstat(3,0x7fdfffff810) = 0 (0x0) read(0x3,0x7fdffffd750,0x2000) = 8192 (0x2000) mmap(0x0,1220608,0x5,0x20002,3,0x0) = 1077043200 (0x40326000) mprotect(0x40342000,0x2000,0x7) = 0 (0x0) mprotect(0x40342000,0x2000,0x5) = 0 (0x0) mmap(0x40442000,16384,0x7,0x12,3,0x0) = 1078206464 (0x40442000) mmap(0x40446000,40960,0x7,0x1012,-1,0x0) = 1078222848 (0x40446000) close(3) = 0 (0x0) access("/usr/lib/libc.so.5",0) = 0 (0x0) open("/usr/lib/libc.so.5",0x0,0137) = 3 (0x3) fstat(3,0x7fdfffff810) = 0 (0x0) read(0x3,0x7fdffffd750,0x2000) = 8192 (0x2000) mmap(0x0,2154496,0x5,0x20002,3,0x0) = 1078263808 (0x40450000) mprotect(0x40538000,0x2000,0x7) = 0 (0x0) mprotect(0x40538000,0x2000,0x5) = 0 (0x0) mmap(0x40638000,73728,0x7,0x12,3,0x0) = 1080262656 (0x40638000) mmap(0x4064a000,81920,0x7,0x1012,-1,0x0) = 1080336384 (0x4064a000) close(3) = 0 (0x0) mmap(0x0,304,0x3,0x1000,-1,0x0) = 1076051968 (0x40234000) munmap(0x40234000,0x130) = 0 (0x0) mmap(0x0,9456,0x3,0x1000,-1,0x0) = 1076051968 (0x40234000) munmap(0x40234000,0x24f0) = 0 (0x0) mmap(0x0,43072,0x3,0x1000,-1,0x0) = 1076051968 (0x40234000) munmap(0x40234000,0xa840) = 0 (0x0) __sysctl(0x7fdfffff520,0x2,0x4065b218,0x7fdfffff518,0x0,0x0) = 0 (0x0) getpid() = 24779 (0x60cb) fcntl(0x0,0x3,0x0) = 2 (0x2) fcntl(0x1,0x3,0x0) = 2 (0x2) fcntl(0x2,0x3,0x0) = 2 (0x2) pipe() = 3 (0x3) fcntl(0x3,0x3,0x0) = 2 (0x2) fcntl(0x3,0x4,0x6) = 0 (0x0) fcntl(0x4,0x3,0x0) = 2 (0x2) fcntl(0x4,0x4,0x6) = 0 (0x0) readlink("/etc/malloc.conf",0x7fdfffff350,63) ERR#2 'No such file or directory' issetugid() = 0 (0x0) getuid() = 0 (0x0) mmap(0x0,8192,0x3,0x1002,-1,0x0) = 1076051968 (0x40234000) break(0x200d68) = 0 (0x0) break(0x200d68) = 0 (0x0) break(0x204000) = 0 (0x0) break(0x204000) = 0 (0x0) break(0x206000) = 0 (0x0) break(0x206000) = 0 (0x0) break(0x208000) = 0 (0x0) break(0x208000) = 0 (0x0) break(0x20a000) = 0 (0x0) break(0x20a000) = 0 (0x0) break(0x20c000) = 0 (0x0) __sysctl(0x7fdfffff640,0x2,0x40443370,0x7fdfffff5f8,0x0,0x0) = 0 (0x0) mmap(0x7fdffefe000,8192,0x0,0x1000,-1,0x0) = -1056768 (0xffefe000) break(0x20c000) = 0 (0x0) break(0x20e000) = 0 (0x0) gettimeofday(0x40443390,0x0) = 0 (0x0) sysarch(0x2,0x4063e100) = 0 (0x0) sigaction(SIGHUP,0x0,0x40449420) = 0 (0x0) sigaction(SIGINT,0x0,0x40449440) = 0 (0x0) sigaction(SIGQUIT,0x0,0x40449460) = 0 (0x0) sigaction(SIGILL,0x0,0x40449480) = 0 (0x0) sigaction(SIGTRAP,0x0,0x404494a0) = 0 (0x0) sigaction(SIGABRT,0x0,0x404494c0) = 0 (0x0) sigaction(SIGEMT,0x0,0x404494e0) = 0 (0x0) sigaction(SIGFPE,0x0,0x40449500) = 0 (0x0) sigaction(SIGBUS,0x0,0x40449540) = 0 (0x0) sigaction(SIGSEGV,0x0,0x40449560) = 0 (0x0) sigaction(SIGSYS,0x0,0x40449580) = 0 (0x0) sigaction(SIGPIPE,0x0,0x404495a0) = 0 (0x0) sigaction(SIGALRM,0x0,0x404495c0) = 0 (0x0) sigaction(SIGTERM,0x0,0x404495e0) = 0 (0x0) sigaction(SIGURG,0x0,0x40449600) = 0 (0x0) sigaction(SIGTSTP,0x0,0x40449640) = 0 (0x0) sigaction(SIGCONT,0x0,0x40449660) = 0 (0x0) sigaction(SIGCHLD,0x0,0x40449680) = 0 (0x0) sigaction(SIGTTIN,0x0,0x404496a0) = 0 (0x0) sigaction(SIGTTOU,0x0,0x404496c0) = 0 (0x0) sigaction(SIGIO,0x0,0x404496e0) = 0 (0x0) sigaction(SIGXCPU,0x0,0x40449700) = 0 (0x0) sigaction(SIGXFSZ,0x0,0x40449720) = 0 (0x0) sigaction(SIGVTALRM,0x0,0x40449740) = 0 (0x0) sigaction(SIGPROF,0x0,0x40449760) = 0 (0x0) sigaction(SIGWINCH,0x0,0x40449780) = 0 (0x0) sigaction(SIGINFO,0x0,0x404497a0) = 0 (0x0) sigaction(SIGUSR1,0x0,0x404497c0) = 0 (0x0) sigaction(SIGUSR2,0x0,0x404497e0) = 0 (0x0) sigaction(SIGPROF,0x7fdfffff600,0x0) = 0 (0x0) sigaction(SIGINFO,0x7fdfffff600,0x0) = 0 (0x0) sigaction(SIGCHLD,0x7fdfffff600,0x0) = 0 (0x0) sigprocmask(0x3,0x0,0x40443418) = 0 (0x0) __sysctl(0x7fdfffff640,0x2,0x7fdfffff620,0x7fdfffff5f8,0x0,0x0) = 0 (0x0) getdtablesize() = 3405 (0xd4d) break(0x20e000) = 0 (0x0) break(0x216000) = 0 (0x0) break(0x216000) = 0 (0x0) break(0x21e000) = 0 (0x0) break(0x21e000) = 0 (0x0) break(0x220000) = 0 (0x0) fcntl(0x0,0x4,0x6) = 0 (0x0) fcntl(0x1,0x4,0x6) = 0 (0x0) fcntl(0x2,0x4,0x6) = 0 (0x0) sigprocmask(0x1,0x40322f40,0x7fdfffff880) = 0 (0x0) sigprocmask(0x3,0x40322f50,0x0) = 0 (0x0) sysarch(0x1,0x40639390) = 0 (0x0) mmap(0x7fdffeee000,65536,0x3,0x400,-1,0x0) = -1122304 (0xffeee000) setitimer(0x2,0x7fdfffff8f0,0x0) = 0 (0x0) poll(0x216000,0x0,0x0) = 0 (0x0) and there it stays... From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 14:17:43 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F1F137B401; Tue, 10 Jun 2003 14:17:43 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id C093B43FAF; Tue, 10 Jun 2003 14:17:42 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h5ALGYkF037507; Tue, 10 Jun 2003 17:16:34 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h5ALGXGQ037506; Tue, 10 Jun 2003 21:16:33 GMT (envelope-from des+tinderbox@freebsd.org) Date: Tue, 10 Jun 2003 21:16:33 GMT Message-Id: <200306102116.h5ALGXGQ037506@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Subject: [-CURRENT tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 21:17:44 -0000 TB --- 2003-06-10 20:31:06 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-10 20:31:06 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-10 20:33:31 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] cc -O -pipe -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -o getNAME getNAME.o gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/libexec/getNAME/getNAME.1 > getNAME.1.gz ===> libexec/getty cc -O -pipe -std=gnu99 -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/libexec/getty/main.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/libexec/getty/main.c: In function `dogettytab': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/libexec/getty/main.c:813: `NPset' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/libexec/getty/main.c:813: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/libexec/getty/main.c:813: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/libexec/getty. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/libexec. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-10 21:16:33 - /usr/bin/make returned exit code 1 TB --- 2003-06-10 21:16:33 - ERROR: failed to build world TB --- 2003-06-10 21:16:33 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 15:36:18 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98AFB37B401; Tue, 10 Jun 2003 15:36:18 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94AA543F93; Tue, 10 Jun 2003 15:36:17 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5AMQuZM001606; Tue, 10 Jun 2003 18:26:57 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5AMYaBe039427; Tue, 10 Jun 2003 15:34:36 -0700 (PDT) (envelope-from jmg) Date: Tue, 10 Jun 2003 15:34:36 -0700 From: John-Mark Gurney To: "M. Warner Losh" Message-ID: <20030610223436.GC37257@funkthat.com> Mail-Followup-To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610.082730.102566465.imp@bsdimp.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: ticso@cicely12.cicely.de cc: freebsd-current@freebsd.org cc: ticso@cicely.de cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 22:36:19 -0000 M. Warner Losh wrote this message on Tue, Jun 10, 2003 at 08:27 -0600: > : > > hdrtype = REG(PCIR_HEADERTYPE, 1); > : > This needs to be tested on that given hardware. > : > I don't know if REG will work as expected because it asks function 0, > : > which is disabled. > : > : I've reread John-Mark's last mail about the readable registers. > : So - yes it should work. > > That's what inspired me. Also, I'd expected that we'd need some kind > of tweaking to make it actually compile and be neat. Ok, attached is a patched I tried, but sad to say, this doesn't work out to well. I added a printf before and after the REG statement, and a boot with the kernel give this output: found-> vendor=0x108e, dev=0x5000, revid=0x13 bus=0, slot=1, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) about to read HEADERTYPE panic: trap: data access error cpuid = 0; Uptime: 1s panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 cpuid = 0; Uptime: 1s panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 cpuid = 0; Uptime: 1s the last three lines repeate for a while, but this is because of: psycho_read_config(...) [...] /* * The psycho bridge does not tolerate accesses to unconfigured PCI * devices' or function's config space, so look up the device in the * firmware device tree first, and if it is not present, return a value * that will make the detection code think that there is no device here. * This is ugly... */ if (reg == 0 && ofw_pci_find_node(bus, slot, func) == 0) return (0xffffffff); Which obviously will fail if reg != 0 which we try to do when reading the PCIR_HEADERTYPE.. So, the question is, does other arch's do something nasty like this too? Should I change the check to just do ofw_pci_find_node? Is this why pciconf -r is returning 0xffffffff when reading the ebus and firewire parts of the SME2300BGA? Simply because it isn't in the ofw tree? I don't have any data sheets or the PCI spec, so making heads or tails of this is going be hard. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 16:02:19 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77F0237B401 for ; Tue, 10 Jun 2003 16:02:19 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A5AFC43FCB for ; Tue, 10 Jun 2003 16:02:17 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 19180 invoked by uid 65534); 10 Jun 2003 23:02:16 -0000 Received: from p508E7664.dip.t-dialin.net (EHLO galatea.local) (80.142.118.100) by mail.gmx.net (mp026) with SMTP; 11 Jun 2003 01:02:16 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19Ps8M-000C4l-SM; Wed, 11 Jun 2003 01:02:30 +0200 Date: Wed, 11 Jun 2003 01:02:30 +0200 From: Thomas Moestl To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Message-ID: <20030610230230.GC734@crow.dom2ip.de> Mail-Followup-To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610223436.GC37257@funkthat.com> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 23:02:19 -0000 On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote: > M. Warner Losh wrote this message on Tue, Jun 10, 2003 at 08:27 -0600: > > : > > hdrtype = REG(PCIR_HEADERTYPE, 1); > > : > This needs to be tested on that given hardware. > > : > I don't know if REG will work as expected because it asks function 0, > > : > which is disabled. > > : > > : I've reread John-Mark's last mail about the readable registers. > > : So - yes it should work. > > > > That's what inspired me. Also, I'd expected that we'd need some kind > > of tweaking to make it actually compile and be neat. > > Ok, attached is a patched I tried, Hmmm, you seem to have forgotten to actually attach it. > but sad to say, this doesn't work > out to well. I added a printf before and after the REG statement, and > a boot with the kernel give this output: > found-> vendor=0x108e, dev=0x5000, revid=0x13 > bus=0, slot=1, func=1 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords) > lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > about to read HEADERTYPE > panic: trap: data access error > > [...] > > the last three lines repeate for a while, but this is because of: > psycho_read_config(...) > [...] > /* > * The psycho bridge does not tolerate accesses to unconfigured PCI > * devices' or function's config space, so look up the device in the > * firmware device tree first, and if it is not present, return a value > * that will make the detection code think that there is no device here. > * This is ugly... > */ > if (reg == 0 && ofw_pci_find_node(bus, slot, func) == 0) > return (0xffffffff); > > Which obviously will fail if reg != 0 which we try to do when reading > the PCIR_HEADERTYPE.. > > So, the question is, does other arch's do something nasty like this > too? Should I change the check to just do ofw_pci_find_node? You could safely (it would just be slow), but that alone would not help you, since you would also be ignoring requests to the registers you want to read without further hackery. You could, of course, look into the device tree to see if there are devices at higher functions, that would just make that kludge more ugly than it already is :) There's a similar problem with hme devices in some Netra models, and so far I have just ignored this because of the ugliness involved (there were patches floating around at one point, but I did not commit them). The real fix (and the way I wanted to implement things from the beginning) is to write an OFW PCI bus, analogous to the ACPI one. This is high on my list, waiting for time to become available :) > Is this why pciconf -r is returning 0xffffffff when reading the ebus > and firewire parts of the SME2300BGA? Simply because it isn't in > the ofw tree? Could be. We just cannot handle devices without firmware nodes - we don't know whether we can safely access them, cannot assign interrupts etc. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 16:17:04 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEF9237B401; Tue, 10 Jun 2003 16:17:04 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8511843F93; Tue, 10 Jun 2003 16:17:03 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h5ANGrTh063403 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 11 Jun 2003 01:16:57 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h5ANGpOs064014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2003 01:16:52 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h5ANGp9F032424; Wed, 11 Jun 2003 01:16:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h5ANGoHB032423; Wed, 11 Jun 2003 01:16:50 +0200 (CEST) Date: Wed, 11 Jun 2003 01:16:50 +0200 From: Bernd Walter To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Message-ID: <20030610231649.GD26807@cicely12.cicely.de> References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610223436.GC37257@funkthat.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-RELEASE alpha User-Agent: Mutt/1.5.4i Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 23:17:05 -0000 On Tue, Jun 10, 2003 at 03:34:36PM -0700, John-Mark Gurney wrote: > M. Warner Losh wrote this message on Tue, Jun 10, 2003 at 08:27 -0600: > > : > > hdrtype = REG(PCIR_HEADERTYPE, 1); > > : > This needs to be tested on that given hardware. > > : > I don't know if REG will work as expected because it asks function 0, > > : > which is disabled. > > : > > : I've reread John-Mark's last mail about the readable registers. > > : So - yes it should work. > > > > That's what inspired me. Also, I'd expected that we'd need some kind > > of tweaking to make it actually compile and be neat. > > Ok, attached is a patched I tried, but sad to say, this doesn't work > out to well. I added a printf before and after the REG statement, and > a boot with the kernel give this output: > found-> vendor=0x108e, dev=0x5000, revid=0x13 > bus=0, slot=1, func=1 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords) > lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > about to read HEADERTYPE > panic: trap: data access error > cpuid = 0; > Uptime: 1s > panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 > cpuid = 0; > Uptime: 1s > panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 > cpuid = 0; > Uptime: 1s > > the last three lines repeate for a while, but this is because of: > psycho_read_config(...) > [...] > /* > * The psycho bridge does not tolerate accesses to unconfigured PCI > * devices' or function's config space, so look up the device in the > * firmware device tree first, and if it is not present, return a value > * that will make the detection code think that there is no device here. > * This is ugly... > */ > if (reg == 0 && ofw_pci_find_node(bus, slot, func) == 0) > return (0xffffffff); > > Which obviously will fail if reg != 0 which we try to do when reading > the PCIR_HEADERTYPE.. > > So, the question is, does other arch's do something nasty like this > too? Should I change the check to just do ofw_pci_find_node? Is this > why pciconf -r is returning 0xffffffff when reading the ebus and firewire > parts of the SME2300BGA? Simply because it isn't in the ofw tree? Possible - in fact I was very surprised that a disabled device was not readable on some registers. We have a similar situation on alpha, where we get traps for reading non available devices. It's handled in that we tell the system to expect traps before accessing registers. This is done by reading with the badaddr function, which sets a flag for our trap handler so it can continue in case the device doesn't exist. badaddr() returns a flags which tells if reading was successfull. > I don't have any data sheets or the PCI spec, so making heads or tails > of this is going be hard. It's OK to get errors when reading locations that aren't available. Some chipsets nerver trap, others only trap for type2 access (behind Bridges) and some always trap. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 16:43:19 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC33E37B404; Tue, 10 Jun 2003 16:43:19 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0E5643FBD; Tue, 10 Jun 2003 16:43:17 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5ANXxZM011114; Tue, 10 Jun 2003 19:34:00 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5ANfiev040296; Tue, 10 Jun 2003 16:41:44 -0700 (PDT) (envelope-from jmg) Date: Tue, 10 Jun 2003 16:41:44 -0700 From: John-Mark Gurney To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Message-ID: <20030610234144.GA39701@funkthat.com> Mail-Followup-To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> <20030610230230.GC734@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <20030610230230.GC734@crow.dom2ip.de> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 23:43:20 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200: > On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote: > > > > Ok, attached is a patched I tried, > > Hmmm, you seem to have forgotten to actually attach it. Ok, this time I'll attach it! > > but sad to say, this doesn't work > > out to well. I added a printf before and after the REG statement, and > > a boot with the kernel give this output: > > found-> vendor=0x108e, dev=0x5000, revid=0x13 > > bus=0, slot=1, func=1 > > class=06-04-00, hdrtype=0x01, mfdev=1 > > cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords) > > lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > > about to read HEADERTYPE > > panic: trap: data access error > > > > [...] > > > > the last three lines repeate for a while, but this is because of: > > psycho_read_config(...) > > [...] > > /* > > * The psycho bridge does not tolerate accesses to unconfigured PCI > > * devices' or function's config space, so look up the device in the > > * firmware device tree first, and if it is not present, return a value > > * that will make the detection code think that there is no device here. > > * This is ugly... > > */ > > if (reg == 0 && ofw_pci_find_node(bus, slot, func) == 0) > > return (0xffffffff); > > > > Which obviously will fail if reg != 0 which we try to do when reading > > the PCIR_HEADERTYPE.. > > > > So, the question is, does other arch's do something nasty like this > > too? Should I change the check to just do ofw_pci_find_node? > > You could safely (it would just be slow), but that alone would not > help you, since you would also be ignoring requests to the registers > you want to read without further hackery. You could, of course, look > into the device tree to see if there are devices at higher functions, > that would just make that kludge more ugly than it already is :) Ok, right now in order to get the machine back up and functional I did remove the reg == 0, and running scanning all the functions. > There's a similar problem with hme devices in some Netra models, and > so far I have just ignored this because of the ugliness involved > (there were patches floating around at one point, but I did not commit > them). > > The real fix (and the way I wanted to implement things from the > beginning) is to write an OFW PCI bus, analogous to the ACPI one. This > is high on my list, waiting for time to become available :) Yikes, I just started looking at the acpi code, and there's a lot of code in it! > > Is this why pciconf -r is returning 0xffffffff when reading the ebus > > and firewire parts of the SME2300BGA? Simply because it isn't in > > the ofw tree? > > Could be. We just cannot handle devices without firmware nodes - we > don't know whether we can safely access them, cannot assign interrupts > etc. Ok, the only problem is that is then we have the same problem the ACPI code does in that hot swapping cards would have a problem. Since it appears to me that the OFW tree doesn't get updated upon a swap. (At least the usb part of the tree doesn't.) Does this mean that we should eliminate most of the Sun specific pci bus drivers in favor of OFW specific ones like ACPI? or? Thanks, I have plenty of time to hack on this right now, so any pointers would be useful. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pci.patch" Index: pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v retrieving revision 1.214 diff -u -r1.214 pci.c --- pci.c 2003/04/16 03:15:08 1.214 +++ pci.c 2003/06/10 21:40:16 @@ -816,25 +816,32 @@ void pci_add_children(device_t dev, int busno, size_t dinfo_size) { +#define REG(n, w) PCIB_READ_CONFIG(pcib, busno, s, f, n, w) device_t pcib = device_get_parent(dev); struct pci_devinfo *dinfo; int maxslots; int s, f, pcifunchigh; + u_int8_t hdrtype; KASSERT(dinfo_size >= sizeof(struct pci_devinfo), ("dinfo_size too small")); maxslots = PCIB_MAXSLOTS(pcib); for (s = 0; s <= maxslots; s++) { pcifunchigh = 0; + f = 0; + hdrtype = REG(PCIR_HEADERTYPE, 1); + if ((hdrtype & ~PCIM_MFDEV) > 2) + continue; + if (hdrtype & PCIM_MFDEV) + pcifunchigh = PCI_FUNCMAX; for (f = 0; f <= pcifunchigh; f++) { dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); if (dinfo != NULL) { - if (dinfo->cfg.mfdev) - pcifunchigh = PCI_FUNCMAX; pci_add_child(dev, dinfo); } } } +#undef REG } void Index: pci_user.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci_user.c,v retrieving revision 1.9 diff -u -r1.9 pci_user.c --- pci_user.c 2003/03/03 12:15:44 1.9 +++ pci_user.c 2003/06/10 21:40:16 @@ -176,9 +176,8 @@ const char *name; int error; - if (!(flag & FWRITE)) + if (!(flag & FWRITE) && cmd == PCIOCWRITE) return EPERM; - switch(cmd) { case PCIOCGETCONF: --PEIAKu/WMn1b1Hv9-- From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 18:16:19 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B331E37B401; Tue, 10 Jun 2003 18:16:19 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7565C43FA3; Tue, 10 Jun 2003 18:16:18 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5B0UhZM019225; Tue, 10 Jun 2003 20:31:24 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5B0cSAS041088; Tue, 10 Jun 2003 17:38:28 -0700 (PDT) (envelope-from jmg) Date: Tue, 10 Jun 2003 17:38:28 -0700 From: John-Mark Gurney To: ticso@cicely.de Message-ID: <20030611003828.GC39701@funkthat.com> Mail-Followup-To: ticso@cicely.de, "M. Warner Losh" , ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> <20030610231649.GD26807@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610231649.GD26807@cicely12.cicely.de> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: ticso@cicely12.cicely.de cc: freebsd-current@freebsd.org cc: freebsd-sparc64@freebsd.org cc: "M. Warner Losh" Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 01:16:20 -0000 Bernd Walter wrote this message on Wed, Jun 11, 2003 at 01:16 +0200: > On Tue, Jun 10, 2003 at 03:34:36PM -0700, John-Mark Gurney wrote: > > So, the question is, does other arch's do something nasty like this > > too? Should I change the check to just do ofw_pci_find_node? Is this > > why pciconf -r is returning 0xffffffff when reading the ebus and firewire > > parts of the SME2300BGA? Simply because it isn't in the ofw tree? > > Possible - in fact I was very surprised that a disabled device was not > readable on some registers. > We have a similar situation on alpha, where we get traps for reading non > available devices. > It's handled in that we tell the system to expect traps before accessing > registers. > This is done by reading with the badaddr function, which sets a flag for > our trap handler so it can continue in case the device doesn't exist. > badaddr() returns a flags which tells if reading was successfull. > > > I don't have any data sheets or the PCI spec, so making heads or tails > > of this is going be hard. > > It's OK to get errors when reading locations that aren't available. > Some chipsets nerver trap, others only trap for type2 access (behind > Bridges) and some always trap. It's amazing what reading the specs for a CPU can do. The US-IIi specificly has a section on this. 16.2.1 Probing PCI durning boot using deferred errors. Guess I'll be looking at implementing that. Then we can get ride of that ickyness in the psycho_read_config function. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 02:18:49 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B0FC37B401 for ; Wed, 11 Jun 2003 02:18:49 -0700 (PDT) Received: from smtp.nextra.cz (smtp.nextra.cz [195.70.130.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC16F43FBD for ; Wed, 11 Jun 2003 02:18:42 -0700 (PDT) (envelope-from akela@terminal.cz) Received: from akela.ti.cz (akela.ti.cz [213.210.153.2]) by smtp.nextra.cz (Postfix) with ESMTP id 876885DE0 for ; Wed, 11 Jun 2003 11:18:35 +0200 (CEST) Received: from akela.ti.cz (localhost [127.0.0.1]) by akela.ti.cz (8.12.8p1/8.12.8) with ESMTP id h5B9IY4v055533 for ; Wed, 11 Jun 2003 11:18:35 +0200 (CEST) (envelope-from akela@terminal.cz) Received: (from akela@localhost) by akela.ti.cz (8.12.8p1/8.12.8/Submit) id h5B9IY50055532; Wed, 11 Jun 2003 11:18:34 +0200 (CEST) X-Authentication-Warning: akela.ti.cz: akela set sender to akela@terminal.cz using -f To: freebsd-sparc64@freebsd.org From: Honza Dusak Date: Wed, 11 Jun 2003 11:18:34 +0200 Message-ID: <873cihug45.fsf@akela.ti.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: missing serial devices on NetraX1 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 09:18:49 -0000 Yesterday I installed FreeBSD-5.1BETA on NetraX1 and I wanted to use the serial B port as a network interface ( slattach ) . But I cannot find any notice about serial drivers in the dmesg output and neither there is no ttyb ( or cuaa* ) device at /dev directory . Please, can anybody advise what can be missing ? # uname -a FreeBSD 5.1-BETA FreeBSD 5.1-BETA #0: @:/usr/obj/usr/src/sys/GENERIC sparc64 # comcontrol /dev/ttya drainwait 300 # comcontrol /dev/ttyb comcontrol: couldn't open file /dev/ttyb: No such file or directory # dmesg 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.1-BETA #0: Thu May 8 21:53:34 CEST 2003 root@:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0488000. Timecounter "tick" frequency 400000000 Hz real memory = 241451008 (230 MB) avail memory = 230350848 (219 MB) cpu0: Sun Microsystems UltraSparc-IIe Processor (400.00 MHz CPU) nexus0: pcib0: on nexus0 pcib0: Sabre, impl 0, version 0, ign 0x7c0 DVMA map: 0x60000000 to 0x63ffffff pci0: on pcib0 pci0: at device 3.0 (no driver attached) pci0: at device 5.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 10.0 (no driver attached) pci0: at device 12.0 (no driver attached) atapci0: port 0x10220-0x1022f,0x10208-0x102 0b,0x10210-0x10217,0x10218-0x1021b,0x10200-0x10207 irq 12 at device 13.0 on pci0 ata2: at 0x10200 on atapci0 ata3: at 0x10210 on atapci0 Timecounters tick every 10.000 msec ad0: 19092MB [38792/16/63] at ata2-master UDMA66 Mounting root from ufs:/dev/ad0a warning: no time-of-day clock registered, system time will not be set accurately # ls -al /dev/ total 4 dr-xr-xr-x 4 root wheel 512 May 8 23:59 . drwxr-xr-x 16 root wheel 512 May 8 23:11 .. crw-r----- 1 root operator 4, 10 May 8 23:59 ad0 crw-r----- 1 root operator 4, 11 May 8 23:59 ad0a crw-r----- 1 root operator 4, 12 May 8 23:59 ad0b crw-r----- 1 root operator 4, 13 May 8 23:59 ad0c crw------- 1 root operator 159, 0 May 8 23:59 ata crw------- 1 root wheel 0, 0 May 9 00:02 console crw-rw-rw- 1 root wheel 1, 0 May 8 23:59 ctty crw------- 1 root wheel 173, 0 May 8 23:59 devctl dr-xr-xr-x 2 root wheel 512 May 8 23:59 fd crw-r----- 1 root operator 252, 0 May 8 23:59 geom.ctl crw------- 1 root wheel 7, 0 May 8 23:59 klog crw-r----- 1 root kmem 2, 1 May 8 23:59 kmem lrwxr-xr-x 1 root wheel 3 May 9 00:00 log -> /var/run/log crw------- 1 root wheel 95, 0xffff00ff May 8 23:59 mdctl crw-r----- 1 root kmem 2, 0 May 8 23:59 mem dr-xr-xr-x 2 root wheel 512 May 8 23:59 net lrwxr-xr-x 1 root wheel 4 May 8 23:59 net1 -> net/lo0 crw------- 1 root wheel 253, 0 May 8 23:59 network crw-rw-rw- 1 root wheel 2, 2 May 9 00:00 null lrwxr-xr-x 1 root wheel 7 May 8 23:59 ofwcons -> ttya crw------- 1 root wheel 177, 0 May 8 23:59 openfirm crw-r--r-- 1 root wheel 251, 0 May 8 23:59 pci crw-rw-rw- 1 root wheel 2, 3 May 9 00:00 random lrwxr-xr-x 1 root wheel 6 May 8 23:59 stderr -> fd/2 lrwxr-xr-x 1 root wheel 5 May 8 23:59 stdin -> fd/0 lrwxr-xr-x 1 root wheel 6 May 8 23:59 stdout -> fd/1 crw------- 1 root tty 97, 0 May 9 00:05 ttya lrwxr-xr-x 1 root wheel 7 May 8 23:59 urandom -> random crw------- 1 root operator 104, 0 May 8 23:59 xpt0 crw-rw-rw- 1 root wheel 2, 12 May 8 23:59 zero Regards -- Honza Dusak From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 02:31:20 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C8B037B407 for ; Wed, 11 Jun 2003 02:31:20 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5306143FE0 for ; Wed, 11 Jun 2003 02:31:19 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5B9NcZM020568; Wed, 11 Jun 2003 05:23:39 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5B9VEm5047604; Wed, 11 Jun 2003 02:31:14 -0700 (PDT) (envelope-from jmg) Date: Wed, 11 Jun 2003 02:31:14 -0700 From: John-Mark Gurney To: Honza Dusak Message-ID: <20030611093114.GD39701@funkthat.com> Mail-Followup-To: Honza Dusak , freebsd-sparc64@freebsd.org References: <873cihug45.fsf@akela.ti.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <873cihug45.fsf@akela.ti.cz> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-sparc64@freebsd.org Subject: Re: missing serial devices on NetraX1 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 09:31:23 -0000 Honza Dusak wrote this message on Wed, Jun 11, 2003 at 11:18 +0200: > Yesterday I installed FreeBSD-5.1BETA on NetraX1 and I wanted > to use the serial B port as a network interface ( slattach ) . > But I cannot find any notice about serial drivers in the dmesg > output and neither there is no ttyb ( or cuaa* ) device at > /dev directory . > > Please, can anybody advise what can be missing ? I think you have a similar box to mine, which uses an ALi south bridge for serial. The problem is that you can't have both serial (sio) ports running at the same time otherwise you might lock up your box. Try adding: hint.sio.1.at="isa" hint.sio.1.port="0x2E8" hint.sio.1.irq="4" to your /boot/device.hints files (you may have to staticly link the hints, I used this with a kld sio driver). Now, these MAY need to be changed. To get the correct information, you need to run ofwdmp -ap, and look at the output. Search for serial. You should see something similar to: Node 0xf00782f8: serial port-a-ignore-cd: interrupt-priorities: 00 00 00 0c 00 00 00 0c reg: 00 00 00 00 00 00 03 f8 00 00 00 08 if you see the port-a-ignore-cd, this will be the first port, or your console, find the next serial entery, and that should have port-b-ignore-cd, and that is your second serial port. The address in the reg which looks like PC io port is what you want. (notice the 3f8 in the reg dump above). There should also be an interrupts property, that is the interrupt that you need to attach. Be careful, on the sparcs, they don't like interrupts >7 on the isa bus! If you can't get this to work, send me a copy of your "ofwdump -ap" command, and I can help you more. Good Luck. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 03:51:03 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33F1937B401; Wed, 11 Jun 2003 03:51:03 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7492343FBD; Wed, 11 Jun 2003 03:51:02 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h5BAnokF001298; Wed, 11 Jun 2003 06:49:50 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h5BAnocw001297; Wed, 11 Jun 2003 10:49:50 GMT (envelope-from des+tinderbox@freebsd.org) Date: Wed, 11 Jun 2003 10:49:50 GMT Message-Id: <200306111049.h5BAnocw001297@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Subject: [-CURRENT tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 10:51:03 -0000 TB --- 2003-06-11 09:41:32 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-11 09:41:32 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-11 09:44:19 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-06-11 10:36:26 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Jun 11 10:36:26 GMT 2003 >>> Kernel build for GENERIC completed on Wed Jun 11 10:45:11 GMT 2003 TB --- 2003-06-11 10:45:11 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-11 10:45:11 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jun 11 10:45:12 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumconfig.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumdaemon.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinuminterrupt.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c: In function `write_volume_label': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: `LABELSECTOR' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-11 10:49:50 - /usr/bin/make returned exit code 1 TB --- 2003-06-11 10:49:50 - ERROR: failed to build lint kernel TB --- 2003-06-11 10:49:50 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 04:55:13 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B03FD37B401 for ; Wed, 11 Jun 2003 04:55:13 -0700 (PDT) Received: from surfeu.fi (mailbox.surfeu.fi [213.173.154.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95D4F43FA3 for ; Wed, 11 Jun 2003 04:55:12 -0700 (PDT) (envelope-from vezku@surfeu.fi) Received: from [213.173.154.9] (HELO surfeu.fi) by surfeu.fi (CommuniGate Pro SMTP 3.4.1) with SMTP id 43092029 for sparc64@freebsd.org; Wed, 11 Jun 2003 14:55:10 +0300 Received: from 62.142.81.6 (SquirrelMail authenticated user vezku) by webmail.surfeu.fi with HTTP; Wed, 11 Jun 2003 14:55:11 +0300 (EEST) Message-ID: <4344.62.142.81.6.1055332511.squirrel@webmail.surfeu.fi> Date: Wed, 11 Jun 2003 14:55:11 +0300 (EEST) From: To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: sparc 64 - 5.1-RELEASE - - fdisk - bsdlabel - vinum X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 11:55:14 -0000 Hi folks, I've been testing vinum on 5.1-RELEASE (sparc64) and have a few questions. I believe the problem is sparc64 specific. System: SUN 250E (2 x sparcII CPUs) da0: *FBSD installed on this disk, no probs there da1: *dedicated disk to use for /home mirror da2: *dedicated disk2 to use for /home mirror QUESTION 1) Howto partition and label da1,da2 correctly for vinum? Step-by-step please, because I tried every freakin way. test1: First I tried sysinstall which created da1d and da2d with UFS2/UFS (tested both) successfully. Some bugs must exist because the new bsdlabel prog didn't recognize these labels: bsdlabel: /dev/da1: no valid label found Anyways I continued and built the vinum module. Then I configured the volume: 1) drive drive1 device /dev/da1d drive drive2 device /dev/da2d volume home setupstate plex org concat sd length 34710M drive drive1 plex org concat sd length 34710M drive drive2 2)newfs /dev/vinum/home (tried both UFS/UFS2 with/out softupdates) Everything seemed okay until I rebooted. I have start_vinum="YES" in rc.conf. Still /dev/vinum/home file had disappeared and plexes were not up. I has a similar prob in 5.0 but then I hadn't used sysinstall correctly. Now it's not the case. test2: Second I tried the manual way, but didn't find fdisk (not available for sparc64?) so only was to follow Dedicated disk method (read comments): $ dd if=/dev/zero of=/dev/da1 bs=1k count=1 $ bsdlabel -rw da1 auto $ bsdlabel -e da1 # here u can define fstype vinum, is it okay? $ newfs /dev/da1e # this didn't work because no such device file exist # i understood fdisk creates devices but howto do it # without fdisk? Thanks for any input. If I get it right I'll write in depth document available for all...software-RAID is such low-level service it needs to work 100%. -Vesa, SysAdmin From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 06:33:45 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55C0D37B401 for ; Wed, 11 Jun 2003 06:33:45 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 6596A43FD7 for ; Wed, 11 Jun 2003 06:33:43 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 11025 invoked by uid 65534); 11 Jun 2003 13:33:41 -0000 Received: from p508E7CCE.dip.t-dialin.net (EHLO galatea.local) (80.142.124.206) by mail.gmx.net (mp008) with SMTP; 11 Jun 2003 15:33:41 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19Q5je-0004Hq-Bo; Wed, 11 Jun 2003 15:33:54 +0200 Date: Wed, 11 Jun 2003 15:33:54 +0200 From: Thomas Moestl To: ticso@cicely.de Message-ID: <20030611133353.GA634@crow.dom2ip.de> Mail-Followup-To: ticso@cicely.de, "M. Warner Losh" , ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> <20030610231649.GD26807@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610231649.GD26807@cicely12.cicely.de> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl cc: ticso@cicely12.cicely.de cc: freebsd-current@freebsd.org cc: freebsd-sparc64@freebsd.org cc: "M. Warner Losh" Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 13:33:45 -0000 On Wed, 2003/06/11 at 01:16:50 +0200, Bernd Walter wrote: > On Tue, Jun 10, 2003 at 03:34:36PM -0700, John-Mark Gurney wrote: > > M. Warner Losh wrote this message on Tue, Jun 10, 2003 at 08:27 -0600: > > > : > > hdrtype = REG(PCIR_HEADERTYPE, 1); > > > : > This needs to be tested on that given hardware. > > > : > I don't know if REG will work as expected because it asks function 0, > > > : > which is disabled. > > > : > > > : I've reread John-Mark's last mail about the readable registers. > > > : So - yes it should work. > > > > > > That's what inspired me. Also, I'd expected that we'd need some kind > > > of tweaking to make it actually compile and be neat. > > > > Ok, attached is a patched I tried, but sad to say, this doesn't work > > out to well. I added a printf before and after the REG statement, and > > a boot with the kernel give this output: > > found-> vendor=0x108e, dev=0x5000, revid=0x13 > > bus=0, slot=1, func=1 > > class=06-04-00, hdrtype=0x01, mfdev=1 > > cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords) > > lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > > about to read HEADERTYPE > > panic: trap: data access error > > cpuid = 0; > > Uptime: 1s > > panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 > > cpuid = 0; > > Uptime: 1s > > panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 > > cpuid = 0; > > Uptime: 1s > > > > the last three lines repeate for a while, but this is because of: > > psycho_read_config(...) > > [...] > > /* > > * The psycho bridge does not tolerate accesses to unconfigured PCI > > * devices' or function's config space, so look up the device in the > > * firmware device tree first, and if it is not present, return a value > > * that will make the detection code think that there is no device here. > > * This is ugly... > > */ > > if (reg == 0 && ofw_pci_find_node(bus, slot, func) == 0) > > return (0xffffffff); > > > > Which obviously will fail if reg != 0 which we try to do when reading > > the PCIR_HEADERTYPE.. > > > > So, the question is, does other arch's do something nasty like this > > too? Should I change the check to just do ofw_pci_find_node? Is this > > why pciconf -r is returning 0xffffffff when reading the ebus and firewire > > parts of the SME2300BGA? Simply because it isn't in the ofw tree? > > Possible - in fact I was very surprised that a disabled device was not > readable on some registers. > We have a similar situation on alpha, where we get traps for reading non > available devices. > It's handled in that we tell the system to expect traps before accessing > registers. > This is done by reading with the badaddr function, which sets a flag for > our trap handler so it can continue in case the device doesn't exist. > badaddr() returns a flags which tells if reading was successfull. > > > I don't have any data sheets or the PCI spec, so making heads or tails > > of this is going be hard. > > It's OK to get errors when reading locations that aren't available. > Some chipsets nerver trap, others only trap for type2 access (behind > Bridges) and some always trap. I don't have the standard handy, but from my reading of the Shanley book, it seems that for the vendor ID register, a host bridge is required to return 0xffff if no device is present. Loading this task off to the software is a bit annoying. There is no mention of other registers, so reading them in the probe might theoretically cause problems even on host bridges that handle the vendor ID register correctly. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 07:26:12 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC1FA37B401 for ; Wed, 11 Jun 2003 07:26:12 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id E62A643F85 for ; Wed, 11 Jun 2003 07:26:10 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 23893 invoked by uid 65534); 11 Jun 2003 14:26:09 -0000 Received: from p508E7CCE.dip.t-dialin.net (EHLO galatea.local) (80.142.124.206) by mail.gmx.net (mp026) with SMTP; 11 Jun 2003 16:26:09 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19Q6YV-0004TD-BI; Wed, 11 Jun 2003 16:26:27 +0200 Date: Wed, 11 Jun 2003 16:26:27 +0200 From: Thomas Moestl To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Message-ID: <20030611142627.GB634@crow.dom2ip.de> Mail-Followup-To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> <20030610230230.GC734@crow.dom2ip.de> <20030610234144.GA39701@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610234144.GA39701@funkthat.com> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 14:26:13 -0000 On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote: > Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200: > > On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote: > > There's a similar problem with hme devices in some Netra models, and > > so far I have just ignored this because of the ugliness involved > > (there were patches floating around at one point, but I did not commit > > them). > > > > The real fix (and the way I wanted to implement things from the > > beginning) is to write an OFW PCI bus, analogous to the ACPI one. This > > is high on my list, waiting for time to become available :) > > Yikes, I just started looking at the acpi code, and there's a lot of > code in it! There's much setup to be done that the firmware is too lazy to do for us. > > > Is this why pciconf -r is returning 0xffffffff when reading the ebus > > > and firewire parts of the SME2300BGA? Simply because it isn't in > > > the ofw tree? > > > > Could be. We just cannot handle devices without firmware nodes - we > > don't know whether we can safely access them, cannot assign interrupts > > etc. > > Ok, the only problem is that is then we have the same problem the ACPI > code does in that hot swapping cards would have a problem. Since it > appears to me that the OFW tree doesn't get updated upon a swap. (At > least the usb part of the tree doesn't.) We do not support hotplugging at the moment anyway. If a bridge driver would implement that in the future without using any firmware support however, it will then need to know everything information about the interrupt routing required for its devices if it cannot use the firmware for this. in that case, it can just prevent the ofw_pci bus from attaching to it (this will be easily possible). I'd hope that machines that support hot-plugging of PCI devices would have firmware methods available to support that though. > Does this mean that we should eliminate most of the Sun specific pci > bus drivers in favor of OFW specific ones like ACPI? or? No, it means introducing an OFW bus driver, which uses the firmware to enumerate the devices and to support interrupt routing. The bridge drivers would be mostly unaffected by this. The only problem with this approach is that it can change the device enumeration; I hope that the resulting one will be the same one that is printed on the boxen, so it should be advantageous for new installations, but a minor migration problem for old ones. I've got some code for this already, it just isn't done yet. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 07:37:54 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C76EE37B401; Wed, 11 Jun 2003 07:37:54 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E9CB43FA3; Wed, 11 Jun 2003 07:37:52 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h5BEa8kA021599; Wed, 11 Jun 2003 08:36:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 11 Jun 2003 08:34:39 -0600 (MDT) Message-Id: <20030611.083439.57255263.imp@bsdimp.com> To: t.moestl@tu-bs.de From: "M. Warner Losh" In-Reply-To: <20030611142627.GB634@crow.dom2ip.de> References: <20030610230230.GC734@crow.dom2ip.de> <20030610234144.GA39701@funkthat.com> <20030611142627.GB634@crow.dom2ip.de> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: ticso@cicely12.cicely.de cc: freebsd-current@freebsd.org cc: ticso@cicely.de cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 14:37:55 -0000 In message: <20030611142627.GB634@crow.dom2ip.de> Thomas Moestl writes: : On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote: : > Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200: : > > On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote: : > > There's a similar problem with hme devices in some Netra models, and : > > so far I have just ignored this because of the ugliness involved : > > (there were patches floating around at one point, but I did not commit : > > them). : > > : > > The real fix (and the way I wanted to implement things from the : > > beginning) is to write an OFW PCI bus, analogous to the ACPI one. This : > > is high on my list, waiting for time to become available :) : > : > Yikes, I just started looking at the acpi code, and there's a lot of : > code in it! : : There's much setup to be done that the firmware is too lazy to do for : us. : : > > > Is this why pciconf -r is returning 0xffffffff when reading the ebus : > > > and firewire parts of the SME2300BGA? Simply because it isn't in : > > > the ofw tree? : > > : > > Could be. We just cannot handle devices without firmware nodes - we : > > don't know whether we can safely access them, cannot assign interrupts : > > etc. : > : > Ok, the only problem is that is then we have the same problem the ACPI : > code does in that hot swapping cards would have a problem. Since it : > appears to me that the OFW tree doesn't get updated upon a swap. (At : > least the usb part of the tree doesn't.) : : We do not support hotplugging at the moment anyway. If a bridge driver : would implement that in the future without using any firmware support : however, it will then need to know everything information about the : interrupt routing required for its devices if it cannot use the : firmware for this. in that case, it can just prevent the ofw_pci bus : from attaching to it (this will be easily possible). : I'd hope that machines that support hot-plugging of PCI devices would : have firmware methods available to support that though. We'll need to do so for the cardbus bridges. However, the interupt is routed to the bridge and has to be shared with the cardbus/pccard cards. : > Does this mean that we should eliminate most of the Sun specific pci : > bus drivers in favor of OFW specific ones like ACPI? or? : : No, it means introducing an OFW bus driver, which uses the firmware to : enumerate the devices and to support interrupt routing. The bridge : drivers would be mostly unaffected by this. : The only problem with this approach is that it can change the device : enumeration; I hope that the resulting one will be the same one that is : printed on the boxen, so it should be advantageous for new : installations, but a minor migration problem for old ones. : : I've got some code for this already, it just isn't done yet. So are you talking about doing something akin to the acpi bridge code or something else? Would this more properly be called a OFW PCI bus driver, or would the OFW 'bus' reach over into other busses to add children? Warner From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 08:05:33 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03D2137B401 for ; Wed, 11 Jun 2003 08:05:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id B111243FA3 for ; Wed, 11 Jun 2003 08:05:31 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 14298 invoked by uid 65534); 11 Jun 2003 15:05:30 -0000 Received: from p508E7CCE.dip.t-dialin.net (EHLO galatea.local) (80.142.124.206) by mail.gmx.net (mp004) with SMTP; 11 Jun 2003 17:05:30 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19Q7AV-0004bI-M6; Wed, 11 Jun 2003 17:05:43 +0200 Date: Wed, 11 Jun 2003 17:05:43 +0200 From: Thomas Moestl To: "M. Warner Losh" Message-ID: <20030611150543.GC634@crow.dom2ip.de> Mail-Followup-To: "M. Warner Losh" , ticso@cicely12.cicely.de, freebsd-current@freebsd.org, ticso@cicely.de, freebsd-sparc64@freebsd.org References: <20030610230230.GC734@crow.dom2ip.de> <20030610234144.GA39701@funkthat.com> <20030611142627.GB634@crow.dom2ip.de> <20030611.083439.57255263.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030611.083439.57255263.imp@bsdimp.com> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl cc: ticso@cicely12.cicely.de cc: freebsd-current@freebsd.org cc: ticso@cicely.de cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 15:05:33 -0000 On Wed, 2003/06/11 at 08:34:39 -0600, M. Warner Losh wrote: > In message: <20030611142627.GB634@crow.dom2ip.de> > Thomas Moestl writes: > : On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote: > : > Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200: > : > Ok, the only problem is that is then we have the same problem the ACPI > : > code does in that hot swapping cards would have a problem. Since it > : > appears to me that the OFW tree doesn't get updated upon a swap. (At > : > least the usb part of the tree doesn't.) > : > : We do not support hotplugging at the moment anyway. If a bridge driver > : would implement that in the future without using any firmware support > : however, it will then need to know everything information about the > : interrupt routing required for its devices if it cannot use the > : firmware for this. in that case, it can just prevent the ofw_pci bus > : from attaching to it (this will be easily possible). > : I'd hope that machines that support hot-plugging of PCI devices would > : have firmware methods available to support that though. > > We'll need to do so for the cardbus bridges. Yes, I was just speaking of PCI. > However, the interupt is routed to the bridge and has to be shared > with the cardbus/pccard cards. That should be far less of a problem with the new code, since it will make interrupt routing work right finally (right now, everything needs to be prerouted). > : > Does this mean that we should eliminate most of the Sun specific pci > : > bus drivers in favor of OFW specific ones like ACPI? or? > : > : No, it means introducing an OFW bus driver, which uses the firmware to > : enumerate the devices and to support interrupt routing. The bridge > : drivers would be mostly unaffected by this. > : The only problem with this approach is that it can change the device > : enumeration; I hope that the resulting one will be the same one that is > : printed on the boxen, so it should be advantageous for new > : installations, but a minor migration problem for old ones. > : > : I've got some code for this already, it just isn't done yet. > > So are you talking about doing something akin to the acpi bridge code > or something else? Would this more properly be called a OFW PCI bus > driver, Yes, that's what I meant to say. It will "override" some of the PCI methods (by using it's own method table), and use the rest of them unaltered. It will attach to PCI bridges which offer an additional method to get the firmware device node (but with a higher priority than the standard PCI bus), so bridges can choose which bus driver they want to have attached by offering or not offering that method. Of course, there will need to be a generic OFW PCI-PCI bridge driver that adds this method, but it's needed anyway to override the standard interrupt routing method. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 12:35:28 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6E0C37B401; Wed, 11 Jun 2003 12:35:28 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ED0443FD7; Wed, 11 Jun 2003 12:35:27 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h5BJYUTh082131 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 11 Jun 2003 21:34:32 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h5BJYSOs068826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2003 21:34:29 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h5BJYS9F035383; Wed, 11 Jun 2003 21:34:28 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h5BJYRcM035382; Wed, 11 Jun 2003 21:34:27 +0200 (CEST) Date: Wed, 11 Jun 2003 21:34:27 +0200 From: Bernd Walter To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Message-ID: <20030611193425.GN26807@cicely12.cicely.de> References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> <20030610230230.GC734@crow.dom2ip.de> <20030610234144.GA39701@funkthat.com> <20030611142627.GB634@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030611142627.GB634@crow.dom2ip.de> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-RELEASE alpha User-Agent: Mutt/1.5.4i Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 19:35:29 -0000 On Wed, Jun 11, 2003 at 04:26:27PM +0200, Thomas Moestl wrote: > On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote: > > Ok, the only problem is that is then we have the same problem the ACPI > > code does in that hot swapping cards would have a problem. Since it > > appears to me that the OFW tree doesn't get updated upon a swap. (At > > least the usb part of the tree doesn't.) > > We do not support hotplugging at the moment anyway. If a bridge driver > would implement that in the future without using any firmware support > however, it will then need to know everything information about the > interrupt routing required for its devices if it cannot use the > firmware for this. in that case, it can just prevent the ofw_pci bus > from attaching to it (this will be easily possible). > I'd hope that machines that support hot-plugging of PCI devices would > have firmware methods available to support that though. I have no clue about cardbus, but for PCI hotplugging you need hardware specific support to power down the slots. But hotplug PCI is not a realm of specific machines, as you can attach add-on hotplug frames to any PCI system. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 14:33:56 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE83037B401; Wed, 11 Jun 2003 14:33:56 -0700 (PDT) Received: from aslan.scsiguy.com (mail.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFBBD43F93; Wed, 11 Jun 2003 14:33:55 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from localhost (aslan.scsiguy.com [63.229.232.106]) by aslan.scsiguy.com (8.12.9/8.12.8) with ESMTP id h5BLW5vl005175; Wed, 11 Jun 2003 15:32:05 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Wed, 11 Jun 2003 15:32:05 -0600 From: "Justin T. Gibbs" To: "M. Warner Losh" , gurney_j@resnet.uoregon.edu, gurney_j@efn.org Message-ID: <361340000.1055367125@caspian.scsiguy.com> In-Reply-To: <20030609.224621.71095461.imp@bsdimp.com> References: <20030609165838.32044@hydrogen.funkthat.com> <20030610022706.GI509@cicely12.cicely.de> <20030609210919.33379@hydrogen.funkthat.com> <20030609.224621.71095461.imp@bsdimp.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: freebsd-current@freebsd.org cc: ticso@cicely.de cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Justin T. Gibbs" List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 21:33:57 -0000 > I'm thinking that the loop should be more like: > > pcifunchigh = 0; > f = 0; > hdrtype = REG(PCIR_HEADERTYPE, 1); > if (hdrtype & 0x7f > 2) > continue; My only complaint about this is that if no device is present in the slot, won't you just get all bits set in whatever you read? If so, the headertype check should be better bounded. -- Justin From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 14:41:27 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32D7D37B401; Wed, 11 Jun 2003 14:41:27 -0700 (PDT) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41A5D43FB1; Wed, 11 Jun 2003 14:41:26 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from localhost (aslan.scsiguy.com [63.229.232.106]) by aslan.scsiguy.com (8.12.9/8.12.8) with ESMTP id h5BLfNvl005247; Wed, 11 Jun 2003 15:41:24 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Wed, 11 Jun 2003 15:41:24 -0600 From: "Justin T. Gibbs" To: Thomas Moestl , John-Mark Gurney Message-ID: <385060000.1055367683@caspian.scsiguy.com> In-Reply-To: <20030610112458.GA734@crow.dom2ip.de> References: <20030609165838.32044@hydrogen.funkthat.com> <20030610112458.GA734@crow.dom2ip.de> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: freebsd-current@freebsd.org cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Justin T. Gibbs" List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 21:41:27 -0000 >> + * >> + * If we don't hardware the bus down, pciconf gets confused. >> */ >> if (sc->secbus != 0) { >> - child = device_add_child(dev, "pci", -1); >> + child = device_add_child(dev, "pci", sc->secbus); >> if (child != NULL) >> return (bus_generic_attach(dev)); >> } else > > This one looks good, please commit. The comment above is outdated, so > it might be better to just remove it completely. At least fix the typo in the comment if you aren't going to remove it. -- Justin From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 14:49:08 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25C7A37B408; Wed, 11 Jun 2003 14:49:08 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C63043F93; Wed, 11 Jun 2003 14:49:05 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h5BLlAkA024200; Wed, 11 Jun 2003 15:47:13 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 11 Jun 2003 15:45:31 -0600 (MDT) Message-Id: <20030611.154531.59692646.imp@bsdimp.com> To: gibbs@scsiguy.com From: "M. Warner Losh" In-Reply-To: <361340000.1055367125@caspian.scsiguy.com> References: <20030609210919.33379@hydrogen.funkthat.com> <20030609.224621.71095461.imp@bsdimp.com> <361340000.1055367125@caspian.scsiguy.com> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: gurney_j@resnet.uoregon.edu cc: freebsd-current@freebsd.org cc: gurney_j@efn.org cc: ticso@cicely.de cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 21:49:09 -0000 In message: <361340000.1055367125@caspian.scsiguy.com> "Justin T. Gibbs" writes: : > I'm thinking that the loop should be more like: : > : > pcifunchigh = 0; : > f = 0; : > hdrtype = REG(PCIR_HEADERTYPE, 1); : > if (hdrtype & 0x7f > 2) : > continue; : : My only complaint about this is that if no device is present in the : slot, won't you just get all bits set in whatever you read? If so, : the headertype check should be better bounded. hdrtype would be 0xff. 0xff & 0x7f is 0x7f, which is greater than 2. What would the problem be? The only valid header types are 0, 1, and 2 (at least the only ones that we understand). Technically, if it is a header type we don't know, we're supposed to disable the device in the command register too. Warner From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 14:53:28 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41DBF37B417; Wed, 11 Jun 2003 14:53:28 -0700 (PDT) Received: from aslan.scsiguy.com (mail.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53FA143F93; Wed, 11 Jun 2003 14:53:27 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from localhost (aslan.scsiguy.com [63.229.232.106]) by aslan.scsiguy.com (8.12.9/8.12.8) with ESMTP id h5BLppvl005314; Wed, 11 Jun 2003 15:51:52 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Wed, 11 Jun 2003 15:51:51 -0600 From: "Justin T. Gibbs" To: "M. Warner Losh" , gibbs@scsiguy.com Message-ID: <404880000.1055368311@caspian.scsiguy.com> In-Reply-To: <20030611.154531.59692646.imp@bsdimp.com> References: <20030609210919.33379@hydrogen.funkthat.com> <20030609.224621.71095461.imp@bsdimp.com> <361340000.1055367125@caspian.scsiguy.com> <20030611.154531.59692646.imp@bsdimp.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: gurney_j@resnet.uoregon.edu cc: freebsd-current@freebsd.org cc: gurney_j@efn.org cc: ticso@cicely.de cc: freebsd-sparc64@freebsd.org Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Justin T. Gibbs" List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 21:53:28 -0000 > : > I'm thinking that the loop should be more like: > : > > : > pcifunchigh = 0; > : > f = 0; > : > hdrtype = REG(PCIR_HEADERTYPE, 1); > : > if (hdrtype & 0x7f > 2) > : > continue; > : > : My only complaint about this is that if no device is present in the > : slot, won't you just get all bits set in whatever you read? If so, > : the headertype check should be better bounded. > > hdrtype would be 0xff. 0xff & 0x7f is 0x7f, which is greater than 2. Sorry. Read the test backwards. -- Justin From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 15:41:22 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 429B037B401; Wed, 11 Jun 2003 15:41:22 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EAE443FBD; Wed, 11 Jun 2003 15:41:21 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h5BMe7kF064459; Wed, 11 Jun 2003 18:40:07 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h5BMe7fu064458; Wed, 11 Jun 2003 22:40:07 GMT (envelope-from des+tinderbox@freebsd.org) Date: Wed, 11 Jun 2003 22:40:07 GMT Message-Id: <200306112240.h5BMe7fu064458@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Subject: [-CURRENT tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 22:41:22 -0000 TB --- 2003-06-11 21:32:22 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-11 21:32:22 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-11 21:34:43 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-06-11 22:26:44 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Jun 11 22:26:44 GMT 2003 >>> Kernel build for GENERIC completed on Wed Jun 11 22:35:29 GMT 2003 TB --- 2003-06-11 22:35:29 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-11 22:35:29 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jun 11 22:35:29 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumconfig.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumdaemon.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinuminterrupt.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c: In function `write_volume_label': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: `LABELSECTOR' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumio.c:714: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-11 22:40:06 - /usr/bin/make returned exit code 1 TB --- 2003-06-11 22:40:06 - ERROR: failed to build lint kernel TB --- 2003-06-11 22:40:06 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 23:26:26 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 586F137B401 for ; Wed, 11 Jun 2003 23:26:26 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 262E643F3F for ; Wed, 11 Jun 2003 23:26:25 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5C6J0ZM028882; Thu, 12 Jun 2003 02:19:02 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5C6QqaB002881; Wed, 11 Jun 2003 23:26:52 -0700 (PDT) (envelope-from jmg) Date: Wed, 11 Jun 2003 23:26:52 -0700 From: John-Mark Gurney To: vezku@surfeu.fi Message-ID: <20030612062652.GA748@funkthat.com> Mail-Followup-To: vezku@surfeu.fi, sparc64@freebsd.org References: <4344.62.142.81.6.1055332511.squirrel@webmail.surfeu.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4344.62.142.81.6.1055332511.squirrel@webmail.surfeu.fi> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: sparc64@freebsd.org Subject: Re: sparc 64 - 5.1-RELEASE - - fdisk - bsdlabel - vinum X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 06:26:26 -0000 vezku@surfeu.fi wrote this message on Wed, Jun 11, 2003 at 14:55 +0300: > I've been testing vinum on 5.1-RELEASE (sparc64) and have a few questions. > I believe the problem is sparc64 specific. [...] > Thanks for any input. If I get it right I'll write in depth document > available for all...software-RAID is such low-level service it needs to > work 100%. You are probably hitting the bug that causes sparc64 on -current not to complile. Vinum has it's own disklabel routines because of the disklabel sometimes not being writable. But this is a problem since sparc64 isn't using bsd disklabel's... I just realized, how does one change the partitioning on a sparc64 box w/o using sysinstall? disklabel doesn't exist (at least not on the 5.1-BETA w/ -current kernel), and bsdlabel doesn't know anything about sparcs. Guess that's another thing that needs to be fixed. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 01:09:50 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D9E137B404; Thu, 12 Jun 2003 01:09:50 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F4ED43FA3; Thu, 12 Jun 2003 01:09:49 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5C82RZM008711; Thu, 12 Jun 2003 04:02:28 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5C8AORZ004199; Thu, 12 Jun 2003 01:10:24 -0700 (PDT) (envelope-from jmg) Date: Thu, 12 Jun 2003 01:10:24 -0700 From: John-Mark Gurney To: Craig Boston Message-ID: <20030612081024.GD748@funkthat.com> Mail-Followup-To: Craig Boston , current@freebsd.org, sparc64@freebsd.org References: <1055260269.91337.127.camel@owen1492.uf.corelab.com> <20030611224538.GB10822@genius.tao.org.uk> <20030612002139.GT26807@cicely12.cicely.de> <200306112244.10466.craig@xfoil.gank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200306112244.10466.craig@xfoil.gank.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: current@freebsd.org cc: sparc64@freebsd.org Subject: Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 08:09:51 -0000 Craig Boston wrote this message on Wed, Jun 11, 2003 at 22:44 -0500: > Believe it or not, after futzing with the debugger for hours, reading the OHCI > spec, and trying to figure out why writing to the control registers works > exactly as it should but the card seems to ignore the ED list, I decided to > try something completely crazy and put the line > > pci_enable_busmaster(self); > > near the top of ohci_attach() in ohci_pci.c > > ...and it worked! I believe my first words upon seeing "ums0: " > were "You have GOT to be kidding me." Hey, thanks for the great work. This got me past the same problem on the sparc box I have, but now I'm getting tons of: usb0: 198 scheduling overruns I fiddled with the PCI Latency, but it doesn't seem to do much good. (Though the latency was set wrong.) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 02:27:22 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDA9F37B401; Thu, 12 Jun 2003 02:27:22 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3464743FA3; Thu, 12 Jun 2003 02:27:22 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h5C9Q6kF007037; Thu, 12 Jun 2003 05:26:06 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h5C9PoJB007036; Thu, 12 Jun 2003 09:25:50 GMT (envelope-from des+tinderbox@freebsd.org) Date: Thu, 12 Jun 2003 09:25:50 GMT Message-Id: <200306120925.h5C9PoJB007036@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Subject: [-CURRENT tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 09:27:23 -0000 TB --- 2003-06-12 08:39:03 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-12 08:39:03 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-12 08:41:27 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/../../sys -std=gnu99 -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumutil.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumutil.c: In function `DriveState': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vinum/vinumutil.c:137: warning: implicit declaration of function `strcmp' cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/../../sys -std=gnu99 -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/commands.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/commands.c: In function `vinum_label': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/commands.c:700: `VINUM_LABEL' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/commands.c:700: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum/commands.c:700: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/vinum. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-12 09:25:50 - /usr/bin/make returned exit code 1 TB --- 2003-06-12 09:25:50 - ERROR: failed to build world TB --- 2003-06-12 09:25:50 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 05:30:11 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2BF137B401; Thu, 12 Jun 2003 05:30:11 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C38043FCB; Thu, 12 Jun 2003 05:30:10 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h5CCU6Hq098086 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 12 Jun 2003 14:30:07 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h5CCU5If073479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2003 14:30:05 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h5CCU49F038067; Thu, 12 Jun 2003 14:30:04 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h5CCU4c0038066; Thu, 12 Jun 2003 14:30:04 +0200 (CEST) Date: Thu, 12 Jun 2003 14:30:03 +0200 From: Bernd Walter To: Craig Boston , current@freebsd.org, sparc64@freebsd.org Message-ID: <20030612123003.GE26807@cicely12.cicely.de> References: <1055260269.91337.127.camel@owen1492.uf.corelab.com> <20030611224538.GB10822@genius.tao.org.uk> <20030612002139.GT26807@cicely12.cicely.de> <200306112244.10466.craig@xfoil.gank.org> <20030612081024.GD748@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030612081024.GD748@funkthat.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-RELEASE alpha User-Agent: Mutt/1.5.4i Subject: Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 12:30:12 -0000 On Thu, Jun 12, 2003 at 01:10:24AM -0700, John-Mark Gurney wrote: > Craig Boston wrote this message on Wed, Jun 11, 2003 at 22:44 -0500: > > Believe it or not, after futzing with the debugger for hours, reading the OHCI > > spec, and trying to figure out why writing to the control registers works > > exactly as it should but the card seems to ignore the ED list, I decided to > > try something completely crazy and put the line > > > > pci_enable_busmaster(self); > > > > near the top of ohci_attach() in ohci_pci.c > > > > ...and it worked! I believe my first words upon seeing "ums0: " > > were "You have GOT to be kidding me." > > Hey, thanks for the great work. This got me past the same problem on > the sparc box I have, but now I'm getting tons of: > usb0: 198 scheduling overruns usb is not available on other 64 bit platforms than alpha. We need busdma support in the controller drivers first. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 05:35:19 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D02F37B401 for ; Thu, 12 Jun 2003 05:35:19 -0700 (PDT) Received: from smtp.nextra.cz (smtp.nextra.cz [195.70.130.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D88DA43FAF for ; Thu, 12 Jun 2003 05:35:17 -0700 (PDT) (envelope-from honza.dusak@nextra.cz) Received: from akela.ti.cz (akela.ti.cz [213.210.153.2]) by smtp.nextra.cz (Postfix) with ESMTP id DC9835E04 for ; Thu, 12 Jun 2003 14:35:15 +0200 (CEST) Received: from akela.ti.cz (localhost [127.0.0.1]) by akela.ti.cz (8.12.8p1/8.12.8) with ESMTP id h5CCZFa7003428 for ; Thu, 12 Jun 2003 14:35:15 +0200 (CEST) (envelope-from honza.dusak@nextra.cz) Received: (from akela@localhost) by akela.ti.cz (8.12.8p1/8.12.8/Submit) id h5CCZF6g003427; Thu, 12 Jun 2003 14:35:15 +0200 (CEST) X-Authentication-Warning: akela.ti.cz: akela set sender to honza.dusak@nextra.cz using -f To: freebsd-sparc64@freebsd.org References: <873cihug45.fsf@akela.ti.cz> <20030611093114.GD39701@funkthat.com> From: akela@terminal.cz Date: Thu, 12 Jun 2003 14:35:14 +0200 Message-ID: <873cif4got.fsf@akela.ti.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: missing serial devices on NetraX1 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 12:35:19 -0000 John-Mark> Honza Dusak wrote this message on Wed, Jun 11, 2003 at 11:18 +0200: >> Yesterday I installed FreeBSD-5.1BETA on NetraX1 and I wanted >> to use the serial B port as a network interface ( slattach ) . >> But I cannot find any notice about serial drivers in the dmesg >> output and neither there is no ttyb ( or cuaa* ) device at >> /dev directory . >> >> Please, can anybody advise what can be missing ? John-Mark> I think you have a similar box to mine, which uses an ALi John-Mark> south bridge for serial. John-Mark> The problem is that you can't have both serial (sio) ports John-Mark> running at the same time otherwise you might lock up your John-Mark> box. John-Mark> Try adding: John-Mark> hint.sio.1.at="isa" John-Mark> hint.sio.1.port="0x2E8" John-Mark> hint.sio.1.irq="4" thank you, this did the trick . I have also noticed the sio driver is commented at GENERIC on the sparc-64 archicture . -- Honza Dusak From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 06:40:00 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C853337B407 for ; Thu, 12 Jun 2003 06:40:00 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4576F43FD7 for ; Thu, 12 Jun 2003 06:39:59 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 32463 invoked by uid 65534); 12 Jun 2003 13:39:57 -0000 Received: from p508E51CA.dip.t-dialin.net (EHLO galatea.local) (80.142.81.202) by mail.gmx.net (mp008) with SMTP; 12 Jun 2003 15:39:57 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19QS8G-0008Y4-HD for ; Thu, 12 Jun 2003 15:28:48 +0200 Date: Thu, 12 Jun 2003 15:28:48 +0200 From: Thomas Moestl To: freebsd-sparc64@freebsd.org Message-ID: <20030612132847.GA2563@crow.dom2ip.de> Mail-Followup-To: freebsd-sparc64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: Thomas Moestl Subject: Need 'ofwdump -ap' output for an Ultra 30 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 13:40:01 -0000 Hi, I'm currently in the process of redesigning the PCI support code for sparc64; this also requires some rework of the interrupt routing code. I seem to recall that the Ultra 30 had slightly unusual properties (no interrupt map on the host bridge). I would greatly appreciate if somebody could send me the output of 'ofwdump -ap' (or 'prtconf -vp' under Solaris), so that I can make sure that support for these boxen does not get broken in the process. Thanks, - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 13:58:12 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5076C37B401 for ; Thu, 12 Jun 2003 13:58:12 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-169-104-32.dsl.lsan03.pacbell.net [64.169.104.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D7D743FA3 for ; Thu, 12 Jun 2003 13:58:11 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 53E6766E40 for ; Thu, 12 Jun 2003 13:58:11 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 4CABFB75; Thu, 12 Jun 2003 13:58:11 -0700 (PDT) Date: Thu, 12 Jun 2003 13:58:11 -0700 From: Kris Kennaway To: freebsd-sparc64@freebsd.org Message-ID: <20030612205811.GA53011@rot13.obsecurity.org> References: <20030612132847.GA2563@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <20030612132847.GA2563@crow.dom2ip.de> User-Agent: Mutt/1.4.1i Subject: Re: Need 'ofwdump -ap' output for an Ultra 30 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 20:58:12 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 12, 2003 at 03:28:48PM +0200, Thomas Moestl wrote: > Hi, >=20 > I'm currently in the process of redesigning the PCI support code for > sparc64; this also requires some rework of the interrupt routing > code. I seem to recall that the Ultra 30 had slightly unusual > properties (no interrupt map on the host bridge). I would greatly > appreciate if somebody could send me the output of 'ofwdump -ap' > (or 'prtconf -vp' under Solaris), so that I can make sure that support > for these boxen does not get broken in the process. Replied in private mail. Kris --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE+6OljWry0BWjoQKURAnLZAKDW5J8vFsJO9JO4l5oQF+suY0azEwCg3Uoc 2PipGfDo9aCxdkaZIVM7Fg8= =mYXp -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 14:23:06 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B2CD37B401; Thu, 12 Jun 2003 14:23:06 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69D0143F3F; Thu, 12 Jun 2003 14:23:05 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5CLFlZM020170; Thu, 12 Jun 2003 17:15:48 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5CLNWEt008707; Thu, 12 Jun 2003 14:23:32 -0700 (PDT) (envelope-from jmg) Date: Thu, 12 Jun 2003 14:23:32 -0700 From: John-Mark Gurney To: ticso@cicely.de Message-ID: <20030612212332.GE748@funkthat.com> Mail-Followup-To: ticso@cicely.de, Craig Boston , current@freebsd.org, sparc64@freebsd.org References: <1055260269.91337.127.camel@owen1492.uf.corelab.com> <20030611224538.GB10822@genius.tao.org.uk> <20030612002139.GT26807@cicely12.cicely.de> <200306112244.10466.craig@xfoil.gank.org> <20030612081024.GD748@funkthat.com> <20030612123003.GE26807@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030612123003.GE26807@cicely12.cicely.de> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: Craig Boston cc: current@freebsd.org cc: sparc64@freebsd.org Subject: Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 21:23:06 -0000 Bernd Walter wrote this message on Thu, Jun 12, 2003 at 14:30 +0200: > On Thu, Jun 12, 2003 at 01:10:24AM -0700, John-Mark Gurney wrote: > > Craig Boston wrote this message on Wed, Jun 11, 2003 at 22:44 -0500: > > > pci_enable_busmaster(self); > > > > > > near the top of ohci_attach() in ohci_pci.c > > > > > > ...and it worked! I believe my first words upon seeing "ums0: " > > > were "You have GOT to be kidding me." > > > > Hey, thanks for the great work. This got me past the same problem on > > the sparc box I have, but now I'm getting tons of: > > usb0: 198 scheduling overruns > > usb is not available on other 64 bit platforms than alpha. > We need busdma support in the controller drivers first. Is someone working on this? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 14:44:24 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A37737B401 for ; Thu, 12 Jun 2003 14:44:24 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C8DE43F3F for ; Thu, 12 Jun 2003 14:44:23 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5CLbDZM023906 for ; Thu, 12 Jun 2003 17:37:13 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5CLixPT009049 for sparc64@freebsd.org; Thu, 12 Jun 2003 14:44:59 -0700 (PDT) (envelope-from jmg) Date: Thu, 12 Jun 2003 14:44:59 -0700 From: John-Mark Gurney To: sparc64@freebsd.org Message-ID: <20030612214458.GF748@funkthat.com> Mail-Followup-To: sparc64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: pci probing "fixed" X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 21:44:24 -0000 Well, I implemented PCI probing as per the UltraSparc IIi user's manual, and now, I get quite a bit more than I bargined for: bash-2.05b$ pciconf -l | wc 38 228 3106 The complete pciconf -l -v is at: http://people.freebsd.org/~jmg/pciconf-lv.sparc64 Now, I seem to be getting duplicates on some functions, and then of course, I am now seeing the firewire part of the SME2300BGA that doesn't have a phys attached to it. (The driver does attach to the firewire part, but fails trying to talk to the phys.) This also required updating the pci_read_device to ignore a all zero return value for PCIR_DEVVENDOR, and not probe higher functions in that case. If I tried to probe higher functions (such as 0.0.2), the system would hang. A dmesg output of the boot is at: http://people.freebsd.org/~jmg/dmesg.sparc64 I don't include the dmesg that shows me attaching the firewire driver. I have posted the patch to produce this at: http://people.freebsd.org/~jmg/sparc.patch Warning, this contains much debugging data, and probes for PCI devices that previously didn't get probed for. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 15:27:57 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B5A637B401 for ; Thu, 12 Jun 2003 15:27:57 -0700 (PDT) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5580A43FAF for ; Thu, 12 Jun 2003 15:27:55 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id E1537527A8; Fri, 13 Jun 2003 07:57:46 +0930 (CST) Date: Fri, 13 Jun 2003 07:57:46 +0930 From: Greg 'groggy' Lehey To: vezku@surfeu.fi, sparc64@freebsd.org Message-ID: <20030612222746.GC1015@wantadilla.lemis.com> References: <4344.62.142.81.6.1055332511.squirrel@webmail.surfeu.fi> <20030612062652.GA748@funkthat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jy6Sn24JjFx/iggw" Content-Disposition: inline In-Reply-To: <20030612062652.GA748@funkthat.com> User-Agent: Mutt/1.4i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Subject: Re: sparc 64 - 5.1-RELEASE - - fdisk - bsdlabel - vinum X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 22:27:57 -0000 --jy6Sn24JjFx/iggw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 11 June 2003 at 23:26:52 -0700, John-Mark Gurney wrote: > vezku@surfeu.fi wrote this message on Wed, Jun 11, 2003 at 14:55 +0300: >> I've been testing vinum on 5.1-RELEASE (sparc64) and have a few questions. >> I believe the problem is sparc64 specific. > > [...] > >> Thanks for any input. If I get it right I'll write in depth document >> available for all...software-RAID is such low-level service it needs to >> work 100%. > > You are probably hitting the bug that causes sparc64 on -current not > to complile. Vinum has it's own disklabel routines because of the > disklabel sometimes not being writable. But this is a problem since > sparc64 isn't using bsd disklabel's... This used to work, but some poorly tested changes broke it. I've now fixed the problem. I don't think it's what vezku is referring to. Greg -- See complete headers for address and phone numbers --jy6Sn24JjFx/iggw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE+6P5iIubykFB6QiMRAneDAJ0U9fWqlgrsqWLSHCm1+JzndI/HNgCeLJBx /OflB9XeINU2Pmia9JDI21o= =004L -----END PGP SIGNATURE----- --jy6Sn24JjFx/iggw-- From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 15:56:20 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 391D537B401; Thu, 12 Jun 2003 15:56:20 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CECF43F75; Thu, 12 Jun 2003 15:56:19 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5CMmrZM002540; Thu, 12 Jun 2003 18:48:54 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5CMuWGW010219; Thu, 12 Jun 2003 15:56:32 -0700 (PDT) (envelope-from jmg) Date: Thu, 12 Jun 2003 15:56:32 -0700 From: John-Mark Gurney To: ticso@cicely.de, "M. Warner Losh" , ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Message-ID: <20030612225632.GK748@funkthat.com> Mail-Followup-To: ticso@cicely.de, "M. Warner Losh" , ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> <20030610231649.GD26807@cicely12.cicely.de> <20030611133353.GA634@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030611133353.GA634@crow.dom2ip.de> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: pci probing "fixed" (was Re: PCI bus numbering and orphaned devices) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 22:56:20 -0000 Well, I implemented PCI probing as per the UltraSparc IIi user's manual, and now, I get quite a bit more than I bargined for: bash-2.05b$ pciconf -l | wc 38 228 3106 The complete pciconf -l -v is at: http://people.freebsd.org/~jmg/pciconf-lv.sparc64 Now, I seem to be getting duplicates on some functions, and then of course, I am now seeing the firewire part of the SME2300BGA that doesn't have a phys attached to it. (The driver does attach to the firewire part, but fails trying to talk to the phys.) This also required updating the pci_read_device to ignore a all zero return value for PCIR_DEVVENDOR, and not probe higher functions in that case. If I tried to probe higher functions (such as 0.0.2), the system would hang. A dmesg output of the boot is at: http://people.freebsd.org/~jmg/dmesg.sparc64 I don't include the dmesg that shows me attaching the firewire driver. I have posted the patch to produce this at: http://people.freebsd.org/~jmg/sparc.patch Warning, this contains much debugging data, and probes for PCI devices that previously didn't get probed for. P.S. Sorry for the duplicate post to -sparc64. I forgot that some of the -current crowd is interested in this work too. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 16:23:53 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F341C37B401; Thu, 12 Jun 2003 16:23:52 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 385F843FBD; Thu, 12 Jun 2003 16:23:51 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h5CNNXHq007264 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 13 Jun 2003 01:23:36 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h5CNNVIf076845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2003 01:23:32 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h5CNNV9F039687; Fri, 13 Jun 2003 01:23:31 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h5CNNUoW039686; Fri, 13 Jun 2003 01:23:30 +0200 (CEST) Date: Fri, 13 Jun 2003 01:23:30 +0200 From: Bernd Walter To: ticso@cicely.de, "M. Warner Losh" , ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Message-ID: <20030612232329.GK26807@cicely12.cicely.de> References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> <20030610231649.GD26807@cicely12.cicely.de> <20030611133353.GA634@crow.dom2ip.de> <20030612225632.GK748@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030612225632.GK748@funkthat.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-RELEASE alpha User-Agent: Mutt/1.5.4i Subject: Re: pci probing "fixed" (was Re: PCI bus numbering and orphaned devices) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 23:23:53 -0000 On Thu, Jun 12, 2003 at 03:56:32PM -0700, John-Mark Gurney wrote: > Well, I implemented PCI probing as per the UltraSparc IIi user's manual, > and now, I get quite a bit more than I bargined for: > bash-2.05b$ pciconf -l | wc > 38 228 3106 > > The complete pciconf -l -v is at: > http://people.freebsd.org/~jmg/pciconf-lv.sparc64 > > Now, I seem to be getting duplicates on some functions, and then of > course, I am now seeing the firewire part of the SME2300BGA that doesn't > have a phys attached to it. (The driver does attach to the firewire > part, but fails trying to talk to the phys.) Maybe they are not really disabled. > This also required updating the pci_read_device to ignore a all zero > return value for PCIR_DEVVENDOR, and not probe higher functions in > that case. If I tried to probe higher functions (such as 0.0.2), the > system would hang. The only defined invalid vendor number is 0xffff. The pcispace read functions should return all bits set in case a device does not exist. > A dmesg output of the boot is at: > http://people.freebsd.org/~jmg/dmesg.sparc64 > > I don't include the dmesg that shows me attaching the firewire driver. > > I have posted the patch to produce this at: > http://people.freebsd.org/~jmg/sparc.patch If the sparc64 part is the right way to do has to be commented by the sparc64 guys. Your patch still probes for additional functions without checking if the device really is a multifunction device. There are devices out there that react on every function although they are single function. Can you check this together with Warners patch? Maybe we can also keep the original code, as the problem was not not of machine independent nature as I originaly tought. > Warning, this contains much debugging data, and probes for PCI devices > that previously didn't get probed for. > > P.S. Sorry for the duplicate post to -sparc64. I forgot that some of > the -current crowd is interested in this work too. If it changes MI part - yes. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 16:51:41 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C699E37B401; Thu, 12 Jun 2003 16:51:41 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4A2643FA3; Thu, 12 Jun 2003 16:51:40 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5CNiOZM010671; Thu, 12 Jun 2003 19:44:24 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5CNq7PQ010997; Thu, 12 Jun 2003 16:52:07 -0700 (PDT) (envelope-from jmg) Date: Thu, 12 Jun 2003 16:52:07 -0700 From: John-Mark Gurney To: ticso@cicely.de Message-ID: <20030612235207.GM748@funkthat.com> Mail-Followup-To: ticso@cicely.de, "M. Warner Losh" , ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> <20030610231649.GD26807@cicely12.cicely.de> <20030611133353.GA634@crow.dom2ip.de> <20030612225632.GK748@funkthat.com> <20030612232329.GK26807@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030612232329.GK26807@cicely12.cicely.de> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: ticso@cicely12.cicely.de cc: freebsd-current@freebsd.org cc: freebsd-sparc64@freebsd.org cc: "M. Warner Losh" Subject: Re: pci probing "fixed" (was Re: PCI bus numbering and orphaned devices) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2003 23:51:42 -0000 Bernd Walter wrote this message on Fri, Jun 13, 2003 at 01:23 +0200: > Your patch still probes for additional functions without checking > if the device really is a multifunction device. I just now realized that the MFDEV ment Multi-Function device! Now the patch to pci.c makes perfect sense. > There are devices out there that react on every function although they > are single function. > Can you check this together with Warners patch? Thanks, I've been having a conversation with gibbs (via proxy through dwhite) and he suggested the same thing. The good news is that this now works "properly". I have posted the updated stuff at: http://people.FreeBSD.org/~jmg/dmesg.sparc64.v2 http://people.FreeBSD.org/~jmg/pciconf-lv.sparc64.v2 http://people.FreeBSD.org/~jmg/sparc.patch.v2 I will of course revert pci_read_device back to it's original state since the MFDEV patch makes it unnecessary. > Maybe we can also keep the original code, as the problem was not not > of machine independent nature as I originaly tought. > > > Warning, this contains much debugging data, and probes for PCI devices > > that previously didn't get probed for. > > > > P.S. Sorry for the duplicate post to -sparc64. I forgot that some of > > the -current crowd is interested in this work too. > > If it changes MI part - yes. Looks like it will change it some. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 17:25:50 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A750737B401; Thu, 12 Jun 2003 17:25:50 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A01C043FAF; Thu, 12 Jun 2003 17:25:49 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5D0IUZM015589; Thu, 12 Jun 2003 20:18:30 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5D0QDuJ011537; Thu, 12 Jun 2003 17:26:13 -0700 (PDT) (envelope-from jmg) Date: Thu, 12 Jun 2003 17:26:13 -0700 From: John-Mark Gurney To: ticso@cicely.de, "M. Warner Losh" , ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Message-ID: <20030613002613.GN748@funkthat.com> Mail-Followup-To: ticso@cicely.de, "M. Warner Losh" , ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> <20030610231649.GD26807@cicely12.cicely.de> <20030611133353.GA634@crow.dom2ip.de> <20030612225632.GK748@funkthat.com> <20030612232329.GK26807@cicely12.cicely.de> <20030612235207.GM748@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030612235207.GM748@funkthat.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: Re: pci probing "fixed" (was Re: PCI bus numbering and orphaned devices) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2003 00:25:51 -0000 John-Mark Gurney wrote this message on Thu, Jun 12, 2003 at 16:52 -0700: > I will of course revert pci_read_device back to it's original state > since the MFDEV patch makes it unnecessary. Ok, here is just the pci MFDEV patch. I would like to see if this works on other arch's, at a minimum, that things don't change and devices disappear. http://people.freebsd.org/~jmg/pci.mfdev.patch This patch compiles fine on Sparc, but requires the data access error trap patch to run. The patch is at: http://people.freebsd.org/~jmg/sparc.dae.patch Testing would be wecome. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 23:22:44 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EEEE37B401 for ; Thu, 12 Jun 2003 23:22:44 -0700 (PDT) Received: from surfeu.fi (mailbox.surfeu.fi [213.173.154.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C825243FB1 for ; Thu, 12 Jun 2003 23:22:42 -0700 (PDT) (envelope-from vezku@surfeu.fi) Received: from [213.173.154.9] (HELO surfeu.fi) by surfeu.fi (CommuniGate Pro SMTP 3.4.1) with SMTP id 43214469 for sparc64@freebsd.org; Fri, 13 Jun 2003 09:22:40 +0300 Received: from 62.142.81.6 (SquirrelMail authenticated user vezku) by redbull.tiscali.fi with HTTP; Fri, 13 Jun 2003 09:21:23 +0300 (EEST) Message-ID: <4465.62.142.81.6.1055485283.squirrel@redbull.tiscali.fi> Date: Fri, 13 Jun 2003 09:21:23 +0300 (EEST) From: To: In-Reply-To: <20030612222746.GC1015@wantadilla.lemis.com> References: <4344.62.142.81.6.1055332511.squirrel@webmail.surfeu.fi> <20030612062652.GA748@funkthat.com> <20030612222746.GC1015@wantadilla.lemis.com> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: partly solved - 5.1-RELEASE - - fdisk - bsdlabel - vinum X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2003 06:22:44 -0000 Hey guys, I was able to get vinum work on 5.1-RELEASE sparc64. The trick was to load vinum in /boot/loader.conf Using this method it accepted UFS2+S for fstype. I do not know is this recommended, but seems to work. BTW, it would be wise to mention this partition/label issue somewhere in the release document. As far as I get it sysinstall is the only way to create partitions on sparc64? Why is fdisk missing? Or am I just dumb, which is possible too. :-) And the promised document is available at: http://vesku.sdf-eu.org/txt/vinum.txt Thanks for all the hard work on sparc64 port. I can't help on programming, but in testing. I will have an extra SUN 250E available soon. Not the latest SUN box, but better than nothing. -Vesa, UNIX SysAdmin > You are probably hitting the bug that causes sparc64 on -current not > to complile. Vinum has it's own disklabel routines because of the > disklabel sometimes not being writable. But this is a problem since > sparc64 isn't using bsd disklabel's... From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 12 23:48:11 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D854E37B401 for ; Thu, 12 Jun 2003 23:48:11 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id F370643F75 for ; Thu, 12 Jun 2003 23:48:10 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5D6f7ZM002995; Fri, 13 Jun 2003 02:41:08 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5D6midN017395; Thu, 12 Jun 2003 23:48:44 -0700 (PDT) (envelope-from jmg) Date: Thu, 12 Jun 2003 23:48:44 -0700 From: John-Mark Gurney To: vezku@surfeu.fi Message-ID: <20030613064844.GA13540@funkthat.com> Mail-Followup-To: vezku@surfeu.fi, sparc64@freebsd.org References: <4344.62.142.81.6.1055332511.squirrel@webmail.surfeu.fi> <20030612062652.GA748@funkthat.com> <20030612222746.GC1015@wantadilla.lemis.com> <4465.62.142.81.6.1055485283.squirrel@redbull.tiscali.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4465.62.142.81.6.1055485283.squirrel@redbull.tiscali.fi> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: sparc64@freebsd.org Subject: Re: partly solved - 5.1-RELEASE - - fdisk - bsdlabel - vinum X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2003 06:48:12 -0000 vezku@surfeu.fi wrote this message on Fri, Jun 13, 2003 at 09:21 +0300: > BTW, it would be wise to mention this partition/label issue somewhere in > the release document. As far as I get it sysinstall is the only way to > create partitions on sparc64? Why is fdisk missing? Or am I just dumb, > which is possible too. :-) fdisk is a wart from x86... Since we are on sparcs, we do it sun's way which is to just stick a disklabel at the front of the disk. > And the promised document is available at: > http://vesku.sdf-eu.org/txt/vinum.txt > > Thanks for all the hard work on sparc64 port. I can't help on programming, > but in testing. I will have an extra SUN 250E available soon. Not the > latest SUN box, but better than nothing. Could you test my recent pci/dae pair of patches I posted? If you didn't see them, they are at: http://people.FreeBSD.org/~jmg/pci.mfdev.patch http://people.FreeBSD.org/~jmg/sparc.dae.patch This makes the attaching of PCI devices more robust on the Sparc. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 13 02:14:57 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF6FE37B401 for ; Fri, 13 Jun 2003 02:14:57 -0700 (PDT) Received: from netlx014.civ.utwente.nl (netlx014.civ.utwente.nl [130.89.1.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53F6B43F3F for ; Fri, 13 Jun 2003 02:14:56 -0700 (PDT) (envelope-from r.s.a.vandomburg@student.utwente.nl) Received: from gog (gog.student.utwente.nl [130.89.165.107]) by netlx014.civ.utwente.nl (8.11.4/HKD) with ESMTP id h5D9Eri18207 for ; Fri, 13 Jun 2003 11:14:53 +0200 Message-Id: <200306130914.h5D9Eri18207@netlx014.civ.utwente.nl> From: "Roderick van Domburg" To: Date: Fri, 13 Jun 2003 11:14:56 +0200 Organization: University of Twente MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook, Build 11.0.4920 Thread-Index: AcMxjEGmEc8COYejS2qPg+mpCb05Cg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 X-UTwente-MailScanner: Found to be clean Subject: June 13th buildkernel broke networking X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2003 09:14:58 -0000 I really don't know what caused it, but here's what happened on my E250's hme: * dhclient complains it isn't allowed to send a packet * static ifconfig and route configuration works okay, but: * I can't reach any external host, although: * I am able to successfully ping my own IP address. No firewall was loaded. I reverted to my June 7th kernel, which does work correctly. Any idea? Nothing out of the ordinary appeared in my dmesg or /var/log/messages. Roderick From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 13 09:01:25 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E42EF37B40D for ; Fri, 13 Jun 2003 09:01:24 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id E554443FCB for ; Fri, 13 Jun 2003 09:01:20 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 15261 invoked by uid 65534); 13 Jun 2003 16:01:19 -0000 Received: from p508E6807.dip.t-dialin.net (EHLO galatea.local) (80.142.104.7) by mail.gmx.net (mp016) with SMTP; 13 Jun 2003 18:01:19 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19Qqzl-0001E6-9m for ; Fri, 13 Jun 2003 18:01:41 +0200 Date: Fri, 13 Jun 2003 18:01:41 +0200 From: Thomas Moestl To: freebsd-sparc64@freebsd.org Message-ID: <20030613160140.GE658@crow.dom2ip.de> Mail-Followup-To: freebsd-sparc64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: Thomas Moestl Subject: TESTERS NEEDED: new OFW PCI code X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2003 16:01:26 -0000 Hi, I've finished implementing the long-promised new OFW PCI code; the patch is available at http://people.freebsd.org/~tmm/ofw-newpci.diff It would be very nice if people could test this on different types of sparc64 PCI machines, espcially those with more exotic firmware properties such as Ultra 30, e450 and Netra t1, and ones with the apb PCI-PCI bridge. To do so, please apply the patch, and add the new option OFW_NEWPCI to your configuration (and, to make debugging easier, OFW_PCI_DEBUG and PSYCHO_DEBUG). Test reports for kernels with the patch applied, but without OFW_NEWPCI are also very welcome, since some of the old code has also been changed. WARNING: Please be aware that device enumeration may have changed on your box with that option, so you might need to do some reconfiguration to make the system boot properly (like changing device names in your fstab and exchanging the configuration of network interfaces). You might not even be able to boot without correcting the boot device on the rootmount prompt if you've got multiple disk controllers with disks attached to more than one. I plan to commit this as soon as I'm reasonably convinced that it works on most boxen. It will still be conditional on OFW_NEWPCI then for a while, since the enumeration changes could cause major upgrade pains. I'll see how to go about making it the default later; I want to kick out the old code as soon as possible :) The advantages of the new approach are: - Odd devices (like the gem(4)s, hme(4)s etc. without function 0 in the firmware) should just work now. - Device enumeration should hopefully be more like on Solaris now, so unit numbers should match what's printed on the box more closely. - Real interrupt routing is implemented now, so cardbus bridges etc. have at least a chance to work. - The quirk tables are gone and have been replaced by (hopefully sufficient) heuristics. - Much cleaner code. For the interested, the changes are: - Introduce an OFW PCI bus driver; it inherits most methods from the generic PCI bus driver, but uses the firmware for enumeration, performs additional initialization for devices and performs firmware-specific interrupt routing in a stub alloc_resource method. It also implements an OFW-specific method to allow child devices to get their firmware nodes. - Introduce an OFW PCI-PCI bridge driver; again, it inherits most of the generic PCI-PCI bridge driver; it has it's own method for interrupt routing, as well as some sparc64-specific methods (one to get the node again, and one to adjust the bridge bus range, since we need to reenumerate all PCI buses). - Convert the apb driver to the new way of handling things - Provide a common framework for OFW bridge drivers, used be the two drivers above. - Provide a small common framework for interrupt routing (for all bridge types). - Convert the psycho driver to the new framework; this gets rid of a bunch of old kludges in pci_read_config(), and the whole preinitialization (ofw_pci_init()). - Convert the ISA MD part and the EBus driver to the new way interrupts and nodes are handled. - Correct bogus intpin settings in the driver (and allow PCI devices to use pci_set_intpin() to make this possible). - Introduce types for firmware interrupt properties. - Rename the old sparcbus_if to ofw_pci_if (it is only required for PCI), and move it to a more correct location (new support methods were also added, and an old one was deprecated). - Fix a bunch of minor bugs, perform some cleanups. In some cases, I introduced some minor code duplication to keep the new code clean, in hopes that the old code will be unifdef'ed soon. Thanks, - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 13 10:45:51 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2371D37B401; Fri, 13 Jun 2003 10:45:51 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B61E843FAF; Fri, 13 Jun 2003 10:45:50 -0700 (PDT) (envelope-from jmg@FreeBSD.org) Received: from freefall.freebsd.org (jmg@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h5DHjoUp081829; Fri, 13 Jun 2003 10:45:50 -0700 (PDT) (envelope-from jmg@freefall.freebsd.org) Received: (from jmg@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h5DHjfcL081825; Fri, 13 Jun 2003 10:45:41 -0700 (PDT) Date: Fri, 13 Jun 2003 10:45:41 -0700 (PDT) From: John-Mark Gurney Message-Id: <200306131745.h5DHjfcL081825@freefall.freebsd.org> To: akm@theinternet.com.au, jmg@FreeBSD.org, freebsd-sparc@FreeBSD.org Subject: Re: sparc64/50789: PCI Bus number reported by /dev/pci is wrong. X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2003 17:45:51 -0000 Synopsis: PCI Bus number reported by /dev/pci is wrong. State-Changed-From-To: open->closed State-Changed-By: jmg State-Changed-When: Fri Jun 13 10:44:22 PDT 2003 State-Changed-Why: Fixed in version 1.5 of src/sys/sparc64/pci/apb.c http://www.freebsd.org/cgi/query-pr.cgi?pr=50789 From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 13 11:40:05 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0010737B401 for ; Fri, 13 Jun 2003 11:40:04 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC8CC43F75 for ; Fri, 13 Jun 2003 11:40:03 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5DIX8ZM031428 for ; Fri, 13 Jun 2003 14:33:10 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5DIeO0n027939 for sparc64@freebsd.org; Fri, 13 Jun 2003 11:40:24 -0700 (PDT) (envelope-from jmg) Date: Fri, 13 Jun 2003 11:40:24 -0700 From: John-Mark Gurney To: sparc64@freebsd.org Message-ID: <20030613184024.GH26285@funkthat.com> Mail-Followup-To: sparc64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: OFWfs anyone? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2003 18:40:05 -0000 Hello, I was wondering if anyone was interested in an ofwfs? I have it pretty much complete, except you can't open/close nodes yet and isn't too dynamice. It does use extattr to query the properties of each node. /ofwfs/SUNW,UltraAX-e2/SUNW,UltraSPARC-IIe@0,0 /ofwfs/SUNW,UltraAX-e2/pci@1f,0/pci@1/display@6 /ofwfs/SUNW,UltraAX-e2/pci@1f,0/pci@1/video@5 /ofwfs/SUNW,UltraAX-e2/pci@1f,0/pci@1,1/usb@5,3 /ofwfs/SUNW,UltraAX-e2/pci@1f,0/pci@1,1/usb@5,3/mouse@1 bash-2.05b$ getextattr system banner-name /ofwfs/SUNW,UltraAX-e2 /ofwfs/SUNW,UltraAX-e2 Netra AX1105-500 (UltraSPARC-IIe 500MHz) Should work find on ppc too. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 13 12:59:13 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23A6B37B401 for ; Fri, 13 Jun 2003 12:59:13 -0700 (PDT) Received: from procyon.firepipe.net (procyon.firepipe.net [198.78.66.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3C7E43F3F for ; Fri, 13 Jun 2003 12:59:12 -0700 (PDT) (envelope-from will@csociety.org) Received: by procyon.firepipe.net (Postfix, from userid 1000) id F220922CB5; Fri, 13 Jun 2003 12:59:11 -0700 (PDT) Date: Fri, 13 Jun 2003 12:59:11 -0700 From: Will Andrews To: sparc64@freebsd.org Message-ID: <20030613195911.GT83610@procyon.firepipe.net> Mail-Followup-To: sparc64@freebsd.org References: <20030613184024.GH26285@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030613184024.GH26285@funkthat.com> User-Agent: Mutt/1.4.1i Subject: Re: OFWfs anyone? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2003 19:59:13 -0000 On Fri, Jun 13, 2003 at 11:40:24AM -0700, John-Mark Gurney wrote: > I was wondering if anyone was interested in an ofwfs? I have it pretty > much complete, except you can't open/close nodes yet and isn't too > dynamice. It does use extattr to query the properties of each node. > > /ofwfs/SUNW,UltraAX-e2/SUNW,UltraSPARC-IIe@0,0 > /ofwfs/SUNW,UltraAX-e2/pci@1f,0/pci@1/display@6 > /ofwfs/SUNW,UltraAX-e2/pci@1f,0/pci@1/video@5 > /ofwfs/SUNW,UltraAX-e2/pci@1f,0/pci@1,1/usb@5,3 > /ofwfs/SUNW,UltraAX-e2/pci@1f,0/pci@1,1/usb@5,3/mouse@1 > > bash-2.05b$ getextattr system banner-name /ofwfs/SUNW,UltraAX-e2 > /ofwfs/SUNW,UltraAX-e2 Netra AX1105-500 (UltraSPARC-IIe 500MHz) > > Should work find on ppc too. How about using a sysctl tree instead of YAFS? Regards, -- wca From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 13 13:47:43 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA3A937B404 for ; Fri, 13 Jun 2003 13:47:43 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A28EF43FAF for ; Fri, 13 Jun 2003 13:47:42 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5DKepZM020353 for ; Fri, 13 Jun 2003 16:40:51 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5DKmBmk030175 for sparc64@freebsd.org; Fri, 13 Jun 2003 13:48:11 -0700 (PDT) (envelope-from jmg) Date: Fri, 13 Jun 2003 13:48:11 -0700 From: John-Mark Gurney To: sparc64@freebsd.org Message-ID: <20030613204811.GJ26285@funkthat.com> Mail-Followup-To: sparc64@freebsd.org References: <20030613184024.GH26285@funkthat.com> <20030613195911.GT83610@procyon.firepipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030613195911.GT83610@procyon.firepipe.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: Re: OFWfs anyone? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2003 20:47:44 -0000 Will Andrews wrote this message on Fri, Jun 13, 2003 at 12:59 -0700: > On Fri, Jun 13, 2003 at 11:40:24AM -0700, John-Mark Gurney wrote: > > I was wondering if anyone was interested in an ofwfs? I have it pretty > > much complete, except you can't open/close nodes yet and isn't too > > dynamice. It does use extattr to query the properties of each node. > > > > /ofwfs/SUNW,UltraAX-e2/SUNW,UltraSPARC-IIe@0,0 > > /ofwfs/SUNW,UltraAX-e2/pci@1f,0/pci@1/display@6 > > /ofwfs/SUNW,UltraAX-e2/pci@1f,0/pci@1/video@5 > > /ofwfs/SUNW,UltraAX-e2/pci@1f,0/pci@1,1/usb@5,3 > > /ofwfs/SUNW,UltraAX-e2/pci@1f,0/pci@1,1/usb@5,3/mouse@1 > > > > bash-2.05b$ getextattr system banner-name /ofwfs/SUNW,UltraAX-e2 > > /ofwfs/SUNW,UltraAX-e2 Netra AX1105-500 (UltraSPARC-IIe 500MHz) > > > > Should work find on ppc too. > > How about using a sysctl tree instead of YAFS? Because ofwdump already exists for that. Also, the ofw tree lets you do such crazy things as open, close, read, write, and seek on them which is kinda hard to do to on a sysctl node (and much easier on an FS). The only problem right now is that pseudofs doesn't let you open/etc directories. If we want to support this either we have to stick a nasty file in the tree for EVERY node, or fix pseudofs to support opening directories (which I think SHOULD work since the VFS layer has it's on READDIR and doesn't need to open it like FFS). -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 13 14:33:02 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4043937B401; Fri, 13 Jun 2003 14:33:02 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E3FD43FCB; Fri, 13 Jun 2003 14:33:01 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h5DLUokF015342; Fri, 13 Jun 2003 17:31:01 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h5DLUev0015341; Fri, 13 Jun 2003 21:30:40 GMT (envelope-from des+tinderbox@freebsd.org) Date: Fri, 13 Jun 2003 21:30:40 GMT Message-Id: <200306132130.h5DLUev0015341@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Subject: [-CURRENT tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2003 21:33:02 -0000 TB --- 2003-06-13 20:30:15 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-13 20:30:15 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-13 20:32:42 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-06-13 21:24:50 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Jun 13 21:24:50 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/en. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-13 21:30:40 - /usr/bin/make returned exit code 1 TB --- 2003-06-13 21:30:40 - ERROR: failed to build generic kernel TB --- 2003-06-13 21:30:40 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 13 17:08:15 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A952637B401 for ; Fri, 13 Jun 2003 17:08:15 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 774A243FE9 for ; Fri, 13 Jun 2003 17:08:14 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 7668 invoked by uid 65534); 14 Jun 2003 00:08:13 -0000 Received: from p508E5CC8.dip.t-dialin.net (EHLO galatea.local) (80.142.92.200) by mail.gmx.net (mp027) with SMTP; 14 Jun 2003 02:08:13 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19Qyb0-0000RF-Rp for ; Sat, 14 Jun 2003 02:08:38 +0200 Date: Sat, 14 Jun 2003 02:08:38 +0200 From: Thomas Moestl To: freebsd-sparc64@freebsd.org Message-ID: <20030614000838.GE670@crow.dom2ip.de> Mail-Followup-To: freebsd-sparc64@freebsd.org References: <20030613160140.GE658@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030613160140.GE658@crow.dom2ip.de> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl Subject: Re: TESTERS NEEDED: new OFW PCI code X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2003 00:08:15 -0000 On Fri, 2003/06/13 at 18:01:41 +0200, Thomas Moestl wrote: > Hi, > > I've finished implementing the long-promised new OFW PCI code; the > patch is available at > http://people.freebsd.org/~tmm/ofw-newpci.diff I've put an updated diff at http://people.freebsd.org/~tmm/ofw-newpci2.diff It contains some cleanups, and fixes panics on machines with psycho host bridges. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 13 18:20:11 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 153A037B404; Fri, 13 Jun 2003 18:20:11 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3F9743F75; Fri, 13 Jun 2003 18:20:09 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5E1DLZM029371; Fri, 13 Jun 2003 21:13:22 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5E1Kbv9034295; Fri, 13 Jun 2003 18:20:37 -0700 (PDT) (envelope-from jmg) Date: Fri, 13 Jun 2003 18:20:37 -0700 From: John-Mark Gurney To: current@freebsd.org, sparc64@freebsd.org Message-ID: <20030614012037.GA32701@funkthat.com> Mail-Followup-To: current@freebsd.org, sparc64@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="huq684BweRXVnRxX" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: rarpd broken on 64bit big endien machines (i.e. sparc64) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2003 01:20:11 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Ok, I just tried to net boot an Ultra 2 from another sparc box, and rarpd is broken. It is still using u_long to represent the IPv4 addresses. Attached is a patch that switches from u_long to in_addr_t. I have confirmed that this works on both sparc64 (5.1-R) and x86 (4.7-R). Comments? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rarpd.patch" ? rarpd ? rarpd.8.gz Index: rarpd.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/rarpd/rarpd.c,v retrieving revision 1.34 diff -u -r1.34 rarpd.c --- rarpd.c 2003/05/03 21:06:39 1.34 +++ rarpd.c 2003/06/14 01:02:48 @@ -114,8 +114,8 @@ struct if_info { struct if_info *ii_next; int ii_fd; /* BPF file descriptor */ - u_long ii_ipaddr; /* IP address of this interface */ - u_long ii_netmask; /* subnet or net mask */ + in_addr_t ii_ipaddr; /* IP address of this interface */ + in_addr_t ii_netmask; /* subnet or net mask */ u_char ii_eaddr[6]; /* Ethernet address of this interface */ char ii_ifname[sizeof(((struct ifreq *)0)->ifr_name) + 1]; }; @@ -136,22 +136,22 @@ static u_char zero[6]; static int bpf_open(void); -static u_long choose_ipaddr(u_long **, u_long, u_long); +static in_addr_t choose_ipaddr(in_addr_t **, in_addr_t, in_addr_t); static char *eatoa(u_char *); static int expand_syslog_m(const char *fmt, char **newfmt); static void init(char *); static void init_one(struct ifreq *, char *); -static char *intoa(u_long); -static u_long ipaddrtonetmask(u_long); +static char *intoa(in_addr_t); +static in_addr_t ipaddrtonetmask(in_addr_t); static void logmsg(int, const char *, ...) __printflike(2, 3); -static int rarp_bootable(u_long); +static int rarp_bootable(in_addr_t); static int rarp_check(u_char *, u_int); static void rarp_loop(void); static int rarp_open(char *); static void rarp_process(struct if_info *, u_char *, u_int); static void rarp_reply(struct if_info *, struct ether_header *, - u_long, u_int); -static void update_arptab(u_char *, u_long); + in_addr_t, u_int); +static void update_arptab(u_char *, in_addr_t); static void usage(void); int @@ -390,9 +390,9 @@ /* Verbose stuff */ if (verbose) for (ii = iflist; ii != NULL; ii = ii->ii_next) - logmsg(LOG_DEBUG, "%s %s 0x%08lx %s", + logmsg(LOG_DEBUG, "%s %s 0x%08x %s", ii->ii_ifname, intoa(ntohl(ii->ii_ipaddr)), - (u_long)ntohl(ii->ii_netmask), eatoa(ii->ii_eaddr)); + (in_addr_t)ntohl(ii->ii_netmask), eatoa(ii->ii_eaddr)); } void @@ -625,7 +625,7 @@ * configuration file. */ int -rarp_bootable(u_long addr) +rarp_bootable(in_addr_t addr) { #ifdef HAVE_DIRENT_H struct dirent *dent; @@ -636,7 +636,7 @@ char ipname[9]; static DIR *dd = NULL; - (void)sprintf(ipname, "%08lX", (u_long)ntohl(addr)); + (void)sprintf(ipname, "%08X", (in_addr_t)ntohl(addr)); /* * If directory is already open, rewind it. Otherwise, open it. @@ -666,8 +666,8 @@ * is on network 'net'; 'netmask' is a mask indicating the network portion * of the address. */ -u_long -choose_ipaddr(u_long **alist, u_long net, u_long netmask) +in_addr_t +choose_ipaddr(in_addr_t **alist, in_addr_t net, in_addr_t netmask) { for (; *alist; ++alist) if ((**alist & netmask) == net) @@ -684,7 +684,7 @@ { struct ether_header *ep; struct hostent *hp; - u_long target_ipaddr; + in_addr_t target_ipaddr; char ename[256]; ep = (struct ether_header *)pkt; @@ -708,7 +708,7 @@ ename); return; } - target_ipaddr = choose_ipaddr((u_long **)hp->h_addr_list, + target_ipaddr = choose_ipaddr((in_addr_t **)hp->h_addr_list, ii->ii_ipaddr & ii->ii_netmask, ii->ii_netmask); if (target_ipaddr == 0) { @@ -748,7 +748,7 @@ } rtmsg; void -update_arptab(u_char *ep, u_long ipaddr) +update_arptab(u_char *ep, in_addr_t ipaddr) { int cc; struct sockaddr_inarp *ar, *ar2; @@ -802,7 +802,7 @@ * directly connected network (the family is AF_INET in * this case). */ - logmsg(LOG_ERR, "bogus link family (%d) wrong net for %08lX?\n", + logmsg(LOG_ERR, "bogus link family (%d) wrong net for %08X?\n", ll2->sdl_family, ipaddr); close(r); return; @@ -845,7 +845,7 @@ } #else void -update_arptab(u_char *ep, u_long ipaddr) +update_arptab(u_char *ep, in_addr_t ipaddr) { struct arpreq request; struct sockaddr_in *sin; @@ -896,7 +896,7 @@ * ARP request. */ void -rarp_reply(struct if_info *ii, struct ether_header *ep, u_long ipaddr, +rarp_reply(struct if_info *ii, struct ether_header *ep, in_addr_t ipaddr, u_int len) { u_int n; @@ -936,8 +936,8 @@ * Get the netmask of an IP address. This routine is used if * SIOCGIFNETMASK doesn't work. */ -u_long -ipaddrtonetmask(u_long addr) +in_addr_t +ipaddrtonetmask(in_addr_t addr) { addr = ntohl(addr); if (IN_CLASSA(addr)) @@ -946,7 +946,7 @@ return htonl(IN_CLASSB_NET); if (IN_CLASSC(addr)) return htonl(IN_CLASSC_NET); - logmsg(LOG_DEBUG, "unknown IP address class: %08lX", addr); + logmsg(LOG_DEBUG, "unknown IP address class: %08X", addr); return htonl(0xffffffff); } @@ -954,7 +954,7 @@ * A faster replacement for inet_ntoa(). */ char * -intoa(u_long addr) +intoa(in_addr_t addr) { char *cp; u_int byte; --huq684BweRXVnRxX-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 13 20:14:57 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C76E37B401; Fri, 13 Jun 2003 20:14:57 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E26143FBF; Fri, 13 Jun 2003 20:14:56 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5E389ZM012058; Fri, 13 Jun 2003 23:08:10 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h5E3FOZv035969; Fri, 13 Jun 2003 20:15:24 -0700 (PDT) (envelope-from jmg) Date: Fri, 13 Jun 2003 20:15:24 -0700 From: John-Mark Gurney To: FreeBSD Current , sparc64@freebsd.org Message-ID: <20030614031524.GB32701@funkthat.com> Mail-Followup-To: FreeBSD Current , sparc64@FreeBSD.org, Mark Murray Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: Mark Murray Subject: bootpd also broke :( X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2003 03:14:57 -0000 --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Well, my further diving into netbooting an Ultra 2 I have found that bootpd doesn't do select too well. It doesn't use fd_set or anything which for some reason causes it not to function on Sparc. A simple switch to using FD_* makes it function. I have also fixed a couple comments that NetBSD had already fixed. Comments? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bootpd.patch" ? bootpd ? bootpd.8.gz ? bootptab.5.gz ? bootpgw/bootpgw ? tools/bootpef/bootpef ? tools/bootpef/bootpef.8.gz ? tools/bootptest/bootptest ? tools/bootptest/bootptest.8.gz Index: bootpd.c =================================================================== RCS file: /home/ncvs/src/libexec/bootpd/bootpd.c,v retrieving revision 1.19 diff -u -r1.19 bootpd.c --- bootpd.c 2003/02/05 13:45:25 1.19 +++ bootpd.c 2003/06/14 03:06:40 @@ -186,7 +186,8 @@ struct hostent *hep; char *stmp; int n, ba_len, ra_len; - int nfound, readfds; + int nfound; + fd_set readfds; int standalone; #ifdef SA_NOCLDSTOP /* Have POSIX sigaction(2). */ struct sigaction sa; @@ -503,14 +504,15 @@ /* * Process incoming requests. */ + FD_ZERO(&readfds); for (;;) { struct timeval tv; - readfds = 1 << s; + FD_SET(s, &readfds); if (timeout) tv = *timeout; - nfound = select(s + 1, (fd_set *)&readfds, NULL, NULL, + nfound = select(s + 1, &readfds, NULL, NULL, (timeout) ? &tv : NULL); if (nfound < 0) { if (errno != EINTR) { @@ -530,7 +532,7 @@ } continue; } - if (!(readfds & (1 << s))) { + if (!FD_ISSET(s, &readfds)) { if (debug > 1) report(LOG_INFO, "exiting after %ld minutes of inactivity", actualtimeout.tv_sec / 60); @@ -667,7 +669,7 @@ } hlen = haddrlength(bp->bp_htype); if (hlen != bp->bp_hlen) { - report(LOG_NOTICE, "bad addr len from from %s address %s", + report(LOG_NOTICE, "bad addr len from %s address %s", netname(bp->bp_htype), haddrtoa(bp->bp_chaddr, hlen)); } @@ -1024,7 +1026,7 @@ /* * If the destination address was specified explicitly - * (i.e. the broadcast address for HP compatiblity) + * (i.e. the broadcast address for HP compatibility) * then send the response to that address. Otherwise, * act in accordance with RFC951: * If the client IP address is specified, use that --XOIedfhf+7KOe/yw-- From owner-freebsd-sparc64@FreeBSD.ORG Sat Jun 14 02:51:46 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C621A37B401; Sat, 14 Jun 2003 02:51:46 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id F205243F93; Sat, 14 Jun 2003 02:51:45 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h5E9lqkF086291; Sat, 14 Jun 2003 05:48:48 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h5E9kx9c086290; Sat, 14 Jun 2003 09:46:59 GMT (envelope-from des+tinderbox@freebsd.org) Date: Sat, 14 Jun 2003 09:46:59 GMT Message-Id: <200306140946.h5E9kx9c086290@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Subject: [-CURRENT tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2003 09:51:47 -0000 TB --- 2003-06-14 08:44:14 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-14 08:44:14 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-14 08:49:13 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-06-14 09:41:14 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Jun 14 09:41:14 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/en. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-14 09:46:59 - /usr/bin/make returned exit code 1 TB --- 2003-06-14 09:46:59 - ERROR: failed to build generic kernel TB --- 2003-06-14 09:46:59 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Sat Jun 14 13:19:57 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7247E37B401; Sat, 14 Jun 2003 13:19:57 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id B602D43FB1; Sat, 14 Jun 2003 13:19:56 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h5EKH1kF031054; Sat, 14 Jun 2003 16:17:34 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h5EKGU1m031053; Sat, 14 Jun 2003 20:16:30 GMT (envelope-from des+tinderbox@freebsd.org) Date: Sat, 14 Jun 2003 20:16:30 GMT Message-Id: <200306142016.h5EKGU1m031053@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Precedence: bulk Subject: [-CURRENT tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2003 20:19:57 -0000 TB --- 2003-06-14 19:26:05 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-14 19:26:05 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-14 19:28:35 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/xlint/xlint/../lint1 -DPREFIX=\"\" -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/xlint/xlint/../arch/sparc64 -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/xlint/xlint/../common -o xlint xlint.o mem.o gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/xlint/xlint/lint.1 > lint.1.gz ===> usr.bin/xlint/llib lint -cghapbx -Cposix /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/xlint/llib/llib-lposix llib-lposix: In file included from /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/sys/types.h:45, from /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/xlint/llib/llib-lposix:39: /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/sys/cdefs.h:148:2: #error FreeBSD alloca support needed for this compiler *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/xlint/llib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/xlint. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-14 20:16:30 - /usr/bin/make returned exit code 1 TB --- 2003-06-14 20:16:30 - ERROR: failed to build world TB --- 2003-06-14 20:16:30 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Sat Jun 14 22:46:35 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9337537B401; Sat, 14 Jun 2003 22:46:35 -0700 (PDT) Received: from cueball.rtp.FreeBSD.org (cueball.rtp.FreeBSD.org [192.58.184.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF27A43F3F; Sat, 14 Jun 2003 22:46:34 -0700 (PDT) (envelope-from des+tinderbox@freebsd.org) Received: from cueball.rtp.FreeBSD.org (localhost [127.0.0.1]) h5F5ixkF011684; Sun, 15 Jun 2003 01:45:01 -0400 (EDT) (envelope-from des+tinderbox@freebsd.org) Received: (from des@localhost) by cueball.rtp.FreeBSD.org (8.12.9/8.12.9/Submit) id h5F5ivmI011683; Sun, 15 Jun 2003 05:44:57 GMT (envelope-from des+tinderbox@freebsd.org) Date: Sun, 15 Jun 2003 05:44:57 GMT Message-Id: <200306150544.h5F5ivmI011683@cueball.rtp.FreeBSD.org> X-Authentication-Warning: cueball.rtp.FreeBSD.org: des set sender to Tinderbox using -f Sender: Tinderbox From: Tinderbox To: current@freebsd.org, sparc64@freebsd.org Precedence: bulk Subject: [-CURRENT tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2003 05:46:35 -0000 TB --- 2003-06-15 05:26:51 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-15 05:26:51 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-15 05:30:20 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries [...] cc -O -pipe -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libkvm/kvm_file.c -o kvm_file.o cc -O -pipe -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libkvm/kvm_getloadavg.c -o kvm_getloadavg.o cc -O -pipe -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libkvm/kvm_getswapinfo.c -o kvm_getswapinfo.o cc -O -pipe -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libkvm/kvm_proc.c -o kvm_proc.o /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libkvm/kvm_proc.c:129: `P_THREADED' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libkvm/kvm_proc.c:129: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libkvm/kvm_proc.c:129: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libkvm. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-15 05:44:57 - /usr/bin/make returned exit code 1 TB --- 2003-06-15 05:44:57 - ERROR: failed to build world TB --- 2003-06-15 05:44:57 - tinderbox aborted