From owner-freebsd-current Wed Nov 15 00:43:56 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA07478 for current-outgoing; Wed, 15 Nov 1995 00:43:56 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA07098 for ; Wed, 15 Nov 1995 00:40:26 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA27551; Wed, 15 Nov 1995 09:38:39 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA06614; Wed, 15 Nov 1995 09:38:39 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id JAA05590; Wed, 15 Nov 1995 09:27:02 +0100 From: J Wunsch Message-Id: <199511150827.JAA05590@uriah.heep.sax.de> Subject: Re: Panic while reading CDROM with latest -current To: asami@cs.berkeley.edu (Satoshi Asami) Date: Wed, 15 Nov 1995 09:27:02 +0100 (MET) Cc: current@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511150321.TAA00669@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Nov 14, 95 07:21:51 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2735 Sender: owner-current@freebsd.org Precedence: bulk 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. ;-)