Date: Mon, 17 Mar 2003 22:14:37 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Kirk McKusick <mckusick@McKusick.COM> Cc: dwmalone@FreeBSD.org, El Vampiro <vampiro@rootshell.ru>, "Evgueni V. Gavrilov" <aquatique@rusunix.org>, Mike Makonnen <mtm@identd.net>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: kern/42277 Message-ID: <49957.1047935677@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 17 Mar 2003 11:09:25 PST." <200303171909.h2HJ9PFL013291@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200303171909.h2HJ9PFL013291@beastie.mckusick.com>, Kirk McKusick wr ites: >I had hoped that the above patch would solve the problem, but >alas it did not (though that fix should be MFC'ed into -stable >as it is a valid fix). Further investigation with the help of >Evgueni V. Gavrilov has determined that there is a memory >corruption problem in the 128-byte bucket space. Applying the >patch below makes the soft updates panics stop. It does so by >creating an "unused" field in the inodedep structure at the >64-byte offset. The printf showing that the "unused" field has >changed does occur, but at least soft updates continues to work. Kirk, How easy is this to reproduce ? The simple way to nail the culprint would be to move things out of the 128 bucket by adding to their malloc byte counts, but for such a strategy to work, we obviously need to be able to reproduce it fairly consistently. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49957.1047935677>