From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 1 12:14:08 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46B2183F for ; Sun, 1 Mar 2015 12:14:08 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E2A8E832 for ; Sun, 1 Mar 2015 12:14:07 +0000 (UTC) Received: (qmail 30509 invoked from network); 1 Mar 2015 12:14:05 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 Mar 2015 12:14:05 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 01 Mar 2015 07:14:05 -0500 (EST) Received: (qmail 26857 invoked from network); 1 Mar 2015 12:14:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Mar 2015 12:14:05 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id E8FFE1C43AA for ; Sun, 1 Mar 2015 04:14:02 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: cb_dumpdata vs. PowerMac G5's (or at least my SSD context): add involvement of dumpinfo's maxiosize value? Message-Id: <84EBF11A-FB29-440B-BA0F-9FA94F1501AD@dsl-only.net> Date: Sun, 1 Mar 2015 04:14:03 -0800 To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2015 12:14:08 -0000 Context: 10.1-STABLE powerpc64 for PowerMac G5 I'm unable to get panic dumps because the DMA size is rejected, 64K = being too big. I'd like to get things to the point where panic dumps are = possible for that context. Looking around I find: root@FBSDG5M1:/usr/src # grep DFLTPHYS sys/sys/*.h sys/sys/param.h:#ifndef DFLTPHYS sys/sys/param.h:#define DFLTPHYS (64 * 1024) /* default max = raw I/O transfer size */ sys/sys/param.h:#define MAXDUMPPGS (DFLTPHYS/PAGE_SIZE) root@FBSDG5M1:/usr/src # grep DFLTPHYS sys/powerpc/powerpc/* sys/powerpc/powerpc/dump_machdep.c: sz =3D (resid > = DFLTPHYS) ? DFLTPHYS : resid; static int cb_dumpdata(struct pmap_md *md, int seqnr, void *arg) { struct dumperinfo *di =3D (struct dumperinfo*)arg; ... resid =3D md->md_size; ... while (resid) { sz =3D (resid > DFLTPHYS) ? DFLTPHYS : resid; ... error =3D di->dumper(di->priv, (void*)va, 0, dumplo, = sz); ... } Which may well be where the 64K is from. sys/sys/conf.h has: struct dumperinfo { dumper_t *dumper; /* Dumping function. */ void *priv; /* Private parts. */ u_int blocksize; /* Size of block in bytes. */ u_int maxiosize; /* Max size allowed for an individual = I/O */ off_t mediaoffset; /* Initial offset in bytes. */ off_t mediasize; /* Space available in bytes. */ }; So it would appear that maxiosize from dumperinfo was supposed to be = involved. But at this level nothing is checking dumperinfo's maxiosize = field value to avoid using anything bigger. It may be that the di->dumper is supposed to deal with allowed sizes = being smaller than its size parameter indicates (sz here). But then = exposing maxiosize in dumperinfo would seem a bit odd as an interface. My initial guess would be that cb_dumpdata should be more like: static int cb_dumpdata(struct pmap_md *md, int seqnr, void *arg) { struct dumperinfo *di =3D (struct dumperinfo*)arg; u_int max_trans_sz =3D (di->maxiosizemaxiosize = : DFLTPHYS; ... printf(" chunk %d: %lu bytes ", seqnr, (u_long)resid); while (resid) { sz =3D (resid > max_trans_sz) ? max_trans_sz : resid; ... error =3D di->dumper(di->priv, (void*)va, 0, dumplo, = sz); ... } I have assumed that even when 0=3D=3Dresid that 0!=3Darg: the origin = code would not dereference di in that kind of context so a little more = conditional logic might be required if that property needs to be = preserved. Anyone know if I seem to be going in a reasonable direction for this? I've only noted the large transfer size that I found. Many other places = use a di->dumper with the size of something much smaller or with a = smaller symbolic constant (such as having value 512). Again there is no = maxiosize handling. It seems there there is an expected (implicit?) = minimum size for maxiosize such that these various things would always = fit. =46rom that point of view I'm just objecting to DFLTPHYS being that = minimum I guess: I want a smaller minimum so that I can get dumps from = my existing configuration. =3D=3D=3D Mark Millard markmi at dsl-only.net