From owner-freebsd-sparc64@FreeBSD.ORG Wed Sep 28 07:51:18 2005 Return-Path: X-Original-To: sparc64@freebsd.org 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 C54F516A41F; Wed, 28 Sep 2005 07:51:18 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E13943D48; Wed, 28 Sep 2005 07:51:17 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id E2ADDBC6D; Wed, 28 Sep 2005 07:51:15 +0000 (UTC) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 27 Sep 2005 23:56:45 MDT." <20050927.235645.34605623.imp@bsdimp.com> Date: Wed, 28 Sep 2005 09:51:15 +0200 Message-ID: <97231.1127893875@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: sparc64@freebsd.org, current@freebsd.org, kris@obsecurity.org Subject: Re: sparc64 panic in rman_set_start X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 07:51:19 -0000 In message <20050927.235645.34605623.imp@bsdimp.com>, "M. Warner Losh" writes: >In message: <20050928041341.GA29527@xor.obsecurity.org> > Kris Kennaway writes: >: Since updating this e4500 from a few days ago it panics at boot with: >: >: -- fast data access mmu miss tar=0 %o7=0xc00ffdbc -- >: rman_set_start() at rman_set_start+0x8 >: puc_sbus_attach() at puc_sbus_attach+0x74 [...] >: Can someone please fix this? > >I think it is phk's changes. puc allocates a struct resource, but not >the private part, so the rman_set_* won't work: [...] All my puc hardware is currently busy with real life, so I can't test this, but the attached patch is an attempted workaround. Looking at it, it looks to me like puc.c doesn't do the right thing. I would expect puc to act like a bridge to a "pucbus" and that the sio/lpt/uart etc drivers would have probe/attach methods for that bus in addition to isa/pci/etc. That way, puc could do the resource allocation properly, using the same methods as for instance a pci bridge does. The probe/attach could be done using a bus property which puc creates which sets the name/type of hardware it has found. Any takers ? I have neither hardware nor time :-( Index: sys/rman.h =================================================================== RCS file: /home/ncvs/src/sys/sys/rman.h,v retrieving revision 1.30 diff -u -r1.30 rman.h --- sys/rman.h 25 Sep 2005 20:10:10 -0000 1.30 +++ sys/rman.h 28 Sep 2005 07:25:52 -0000 @@ -174,6 +174,15 @@ void rman_set_virtual(struct resource *_r, void *_v); extern struct rman_head rman_head; + +/* + * XXX: puc.c is a big hack. + * XXX: it should be rewritten to act like a bridge and offer + * XXX: its own resource manager. + * XXX: until somebody has time, help it out with these two functions + */ +struct resource *rman_secret_puc_alloc_resource(int malloc_flag); +void rman_secret_puc_free_resource(struct resource *r); #endif /* _KERNEL */ #endif /* !_SYS_RMAN_H_ */ Index: kern/subr_rman.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_rman.c,v retrieving revision 1.45 diff -u -r1.45 subr_rman.c --- kern/subr_rman.c 25 Sep 2005 20:10:10 -0000 1.45 +++ kern/subr_rman.c 28 Sep 2005 07:38:53 -0000 @@ -98,6 +98,31 @@ return (r); } +/* + * XXX: puc.c is a big hack. + * XXX: it should be rewritten to act like a bridge and offer + * XXX: its own resource manager. + * XXX: until somebody has time, help it out with these two functions + */ + +struct resource * +rman_secret_puc_alloc_resource(int malloc_flag) +{ + struct resource_i *r; + + r = int_alloc_resource(malloc_flag); + if (r) + return (&r->r_r); + return (NULL); +} + +void +rman_secret_puc_free_resource(struct resource *r) +{ + + free(r->__r_i, M_RMAN); +} + int rman_init(struct rman *rm) { Index: dev/puc/puc.c =================================================================== RCS file: /home/ncvs/src/sys/dev/puc/puc.c,v retrieving revision 1.40 diff -u -r1.40 puc.c --- dev/puc/puc.c 25 Sep 2005 20:21:14 -0000 1.40 +++ dev/puc/puc.c 28 Sep 2005 07:14:56 -0000 @@ -316,8 +316,7 @@ if (sc->barmuxed == 0) { rle->res = sc->sc_bar_mappings[bidx].res; } else { - rle->res = malloc(sizeof(struct resource), M_DEVBUF, - M_WAITOK | M_ZERO); + rle->res = rman_secret_puc_alloc_resource(M_WAITOK); if (rle->res == NULL) { free(pdev, M_DEVBUF); return (ENOMEM); @@ -352,7 +351,7 @@ if (sc->barmuxed) { bus_space_unmap(rman_get_bustag(rle->res), rman_get_bushandle(rle->res), ressz); - free(rle->res, M_DEVBUF); + rman_secret_puc_free_resource(rle->res); free(pdev, M_DEVBUF); } continue; @@ -372,7 +371,7 @@ if (sc->barmuxed) { bus_space_unmap(rman_get_bustag(rle->res), rman_get_bushandle(rle->res), ressz); - free(rle->res, M_DEVBUF); + rman_secret_puc_free_resource(rle->res); free(pdev, M_DEVBUF); } } -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.