Date: Sat, 28 Feb 1998 12:32:53 +1030 From: Greg Lehey <grog@lemis.com> To: Mike Smith <mike@smith.net.au> Cc: FreeBSD Hackers <hackers@FreeBSD.ORG> Subject: Re: Kernel debugging: what's going on here? Message-ID: <19980228123253.24049@freebie.lemis.com> In-Reply-To: <199802280156.RAA29982@dingo.cdrom.com>; from Mike Smith on Fri, Feb 27, 1998 at 05:56:46PM -0800 References: <19980228122110.36590@freebie.lemis.com> <199802280156.RAA29982@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 27 February 1998 at 17:56:46 -0800, Mike Smith wrote: >> On Fri, 27 February 1998 at 17:45:39 -0800, Mike Smith wrote: >>>> Can anybody explain this to me? I'm writing a disk block, and am >>>> currently at bwrite: >>>> >>>> (kgdb) bt >>>> #0 bwrite (bp=0xf051ec00) at ../../kern/vfs_bio.c:364 >>>> #1 0xf0138d6a in vop_stdbwrite (ap=0xf2a76c74) at ../../kern/vfs_default.c:283 >>>> #2 0xf0138bb1 in vop_defaultop (ap=0xf2a76c74) at ../../kern/vfs_default.c:130 >>>> #3 0xf0146639 in spec_vnoperate (ap=0xf2a76c74) at ../../miscfs/specfs/spec_vnops.c:127 >>>> #4 0xf01c5679 in ufs_vnoperatespec (ap=0xf2a76c74) at ../../ufs/ufs/ufs_vnops.c:2242 >>>> #5 0xf2aab097 in VOP_BWRITE (bp=0xf051ec00) at vnode_if.h:1117 >>>> #6 0xf2aa95c4 in vinumstart (vol=0xf0563000, bp=0xf10f1bb0) at request.c:228 >>>> #7 0xf2aa9189 in vinumstrategy (bp=0xf10f1bb0) at request.c:71 >>>> #8 0xf2aa7b63 in vinum_writedisklabel (vol=0xf0563000, lp=0xf0563110) at io.c:830 >>>> >>>> I've handed a buffer header up from frame 6 (not the bp in the >>>> parameter list). When it gets to bwrite, it has a different content. >>>> gdb tells me different contents depending on the frame it's in: >>> >>> My guess would be that the bp has been translated to reflect the block >>> device that it will be operating on at bwrite level rather than the >>> logical device that you were operating on when you called VOP_BWRITE. >>> >>> This would involve a change in vnode, as well as (maybe) offset etc. >> >> Look at the addresses. They're the same: > > Yes, I noticed. But rewriting the bp on the fly is not uncommon; quite > a few device drivers do it, it wouldn't surprise me if it wasn't done > elsewhere rather than cloning the original. Sure, all sorts of things modify the buffer header. But you're still missing the point: the processor is stopped here, it's in the debugger. No instructions were executed between the two views. You might just as well take a look at a dump. Since when does the content of memory differ depending on where you look at it from? Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980228123253.24049>