Date: Wed, 15 Nov 1995 09:27:02 +0100 (MET) From: J Wunsch <j@uriah.heep.sax.de> To: asami@cs.berkeley.edu (Satoshi Asami) Cc: current@freebsd.org Subject: Re: Panic while reading CDROM with latest -current Message-ID: <199511150827.JAA05590@uriah.heep.sax.de> In-Reply-To: <199511150321.TAA00669@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Nov 14, 95 07:21:51 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As Satoshi Asami wrote:
>
> I got a panic while reading from a CDROM. A simple command such as
> "dd if=/cdrom/packages/printing/mltex-3.1415.tgz of=/dev/null" will
> cause a panic reliably.
>
> I moved the CDROM drive from the Adaptec 2940UW to NCR 53c825 today,
> and the panic happened after that. But then, I haven't been using the
> CDROM for anything else than playing audio CD's for a while, so this
> may just be a coincidence.
>
> ===
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x242
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0x60125000
0xf0125000
...i assume.
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL=0
> current process = 28 (dd)
> interrupt mask = bio
> panic: page fault
> ===
>
> nm /kernel | sort gives:
>
> ===
> f0124b44 T _vfs_bio_awrite
> f0124d14 t _getnewbuf
> f0124fc8 T _incore
> f012503c T _inmem
Argl! This is the incore() panic again. At least Hellmuth Michaelis
and somebody else who's name i forgot have been reporting this one,
but it only occured for the last (highest ID #) CD drive of a multi-CD
environment for them. So it's never been tracked down to the bitter
end.
If i look at your configuration:
> 19: ncr0 at pci0:15 # int a irq 9
> 20: sd2 at SCSI bus 1:1:0 (ready)
> 21: sd3 at SCSI bus 1:2:0 (ready)
> 22: sd4 at SCSI bus 1:3:0 (ready)
> 23: sd5 at SCSI bus 1:4:0 (ready)
> 24: sd6 at SCSI bus 1:5:0 (ready)
> 25: cd0 at SCSI bus 1:6:0 (ready) (open)
there's some resemblance to their environment however: the CD is the
highest ID#, only the lower numbered devices are sd ones. Dunno if
this is an incidence only.
FWIW, the problem happens:
struct buf *
incore(struct vnode * vp, daddr_t blkno)
{
struct buf *bp;
struct bufhashhdr *bh;
int s = splbio();
bh = BUFHASH(vp, blkno);
bp = bh->lh_first;
^^^^ <<================ here
/* Search hash chain */
while (bp != NULL) {
/* hit */
if (bp->b_vp == vp && bp->b_lblkno == blkno &&
(bp->b_flags & B_INVAL) == 0) {
break;
}
bp = bp->b_hash.le_next;
}
splx(s);
return (bp);
}
Somehow, BUFHASH() returns a bogus value (but is apparently believed
to always return valid pointers /* CANTHAPPEN */).
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511150827.JAA05590>