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-current mailing list