From owner-freebsd-current@FreeBSD.ORG Sat Jul 31 00:08:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AD0016A4CE for ; Sat, 31 Jul 2004 00:08:44 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CAAD43D5F for ; Sat, 31 Jul 2004 00:08:42 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i6V08Dra014341; Fri, 30 Jul 2004 17:08:14 -0700 Message-ID: <410AE2EC.50607@root.org> Date: Fri, 30 Jul 2004 17:08:12 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <20040702105414.F54403@root.org> <20040702181547.GK1034@green.homeunix.org> <40E5B8B2.7060006@DeepCore.dk> In-Reply-To: <40E5B8B2.7060006@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: Tai-hwa Liang cc: current@freebsd.org Subject: Re: [FIXED] ATAPI CD boot problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 00:08:44 -0000 Søren Schmidt wrote: >> On Fri, Jul 02, 2004 at 10:58:59AM -0700, Nate Lawson wrote: >>> That's because the bug is still there. Stick a call to "if (addr == >>> 0xc1740a00) backtrace();" in kern_malloc and you'll see the original >>> allocator was ATA. The problem is with ATA's handling of drives >>> where you >>> get the message "identify timed out". To work around, boot without your >>> cdrom drive in the drive bay. This bug is extremely annoying and has >>> forced me to install via floppy in the past. >>> >>> The reason you don't see this in a custom kernel is the check for memory >>> use after free happens only with options INVARIANTS. The bug is still >>> there, just ignored. >>> >>> I may get around to tracking this down sometime in the future but don't >>> count on it. > > Yeps, some good precise debugging of this problem would be appreciated, > I can't seem to reproduce it here no matter what I try :( Just to close off this thread, I found the problems and posted a patch including debugging info to -current. -Nate