Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Dec 1995 19:42:33 -0800
From:      David Greenman <davidg@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 
Message-ID:  <199512190342.TAA02913@corbin.Root.COM>
In-Reply-To: Your message of "Mon, 18 Dec 95 21:48:58 EST." <199512190248.VAA18815@hda.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
>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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512190342.TAA02913>