In message <20050927.235645.34605623.imp_at_bsdimp.com>, "M. Warner Losh" writes: >In message: <20050928041341.GA29527_at_xor.obsecurity.org> > Kris Kennaway <kris_at_obsecurity.org> 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 _at__at_ -174,6 +174,15 _at__at_ 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 _at__at_ -98,6 +98,31 _at__at_ 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 _at__at_ -316,8 +316,7 _at__at_ 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); _at__at_ -352,7 +351,7 _at__at_ 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; _at__at_ -372,7 +371,7 _at__at_ 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_at_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.Received on Wed Sep 28 2005 - 05:51:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:44 UTC