sparc64 panic in rman_set_start
Poul-Henning Kamp
phk at phk.freebsd.dk
Wed Sep 28 00:51:19 PDT 2005
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
@@ -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 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.
More information about the freebsd-sparc64
mailing list