From owner-freebsd-bugs  Mon Dec 18 19:43:00 1995
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id TAA15348
          for bugs-outgoing; Mon, 18 Dec 1995 19:43:00 -0800 (PST)
Received: from Root.COM (implode.Root.COM [198.145.90.17])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA15328
          for <freebsd-bugs@freebsd.org>; Mon, 18 Dec 1995 19:42:56 -0800 (PST)
Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id TAA02079; Mon, 18 Dec 1995 19:42:30 -0800
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id TAA02913; Mon, 18 Dec 1995 19:42:42 -0800
Message-Id: <199512190342.TAA02913@corbin.Root.COM>
To: Peter Dufault <dufault@hda.com>
cc: gibbs@freefall.freebsd.org (Justin T. Gibbs), m.sapsed@bangor.ac.uk,
        hm@hcs.de, freebsd-bugs@freebsd.org
Subject: Re: Problem with FreeBSD 2.1.0-RELEASE 
In-reply-to: Your message of "Mon, 18 Dec 95 21:48:58 EST."
             <199512190248.VAA18815@hda.com> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Mon, 18 Dec 1995 19:42:33 -0800
Sender: owner-bugs@freebsd.org
Precedence: bulk

>This is certainly the same problem that Hellmuth and others
>have been having with CD-ROM changers.  Hellmuth sent me the changer so I
>want to find some time to track it down soon.  I saved some mail from
>him that says it takes place here:
>
>> Fatal trap 12: page fault while in kernel mode
>> Fault virtual address              = 0x60
>> Fault code                         = supervisor read, page not present
...
>> Stopped at _incore+0x48: cmpl %esi, 0x48(%ebx)
>
>I believe this is here in kern/vfs_bio.c:
>
>>	int s = splbio();
>>
>>	bh = BUFHASH(vp, blkno);
>>	bp = bh->lh_first;
>>
>>	/* Search hash chain */
>>	while (bp) {
>
>where we go indirect on that bp.

   This is a "can't happen" panic. It can only happen if the CPU executes the
instructions incorrectly. The assembly code is:

...
        movl _bufhashtbl(,%eax,4),%ebx
        testl %ebx,%ebx		<- exit if bp is NULL
        je L326
        movl %edx,%ecx
        notl %ecx
        movl %ecx,-4(%ebp)
        .align 2,0x90
L327:
        cmpl %esi,72(%ebx)	<- failing here
        jne L328
        cmpl %edi,88(%ebx)
        jne L328
        movl 36(%ebx),%eax
        testb $32,%ah
        jne L328
        movl %edx,_cpl
        movl _ipending,%eax
        testl %eax,-4(%ebp)
        je L329
        call _splz
L329:
        movl %ebx,%eax
        jmp L334
        .align 2,0x90
L328:
        movl (%ebx),%ebx
        testl %ebx,%ebx		<- jump if bp *not* NULL
        jne L327
L326:
        movl %edx,_cpl
        notl %edx
        movl _ipending,%eax
        testl %edx,%eax
        je L332
        call _splz
L332:
        xorl %eax,%eax
L334:
        leal -16(%ebp),%esp
        popl %ebx
        popl %esi
        popl %edi
        leave
        ret

   The only other possibility is that incore() isn't actually being called at
all and the CPU ended up here because of some weird stack corruption or
bogus function pointer or something. ...This seems unlikely.

-DG