From owner-freebsd-bugs Mon Dec 4 20:40: 5 2000 From owner-freebsd-bugs@FreeBSD.ORG Mon Dec 4 20:40:01 2000 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 521AD37B401 for ; Mon, 4 Dec 2000 20:40:01 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id eB54e1h72107; Mon, 4 Dec 2000 20:40:01 -0800 (PST) (envelope-from gnats) Resent-Date: Mon, 4 Dec 2000 20:40:01 -0800 (PST) Resent-Message-Id: <200012050440.eB54e1h72107@freefall.freebsd.org> Resent-From: gnats-admin@FreeBSD.org (GNATS Management) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: gnats-admin@FreeBSD.org, atrens@nortel.ca Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A958C37B400 for ; Mon, 4 Dec 2000 20:32:35 -0800 (PST) Received: (from nobody@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id eB54WZ771244; Mon, 4 Dec 2000 20:32:35 -0800 (PST) (envelope-from nobody) Message-Id: <200012050432.eB54WZ771244@freefall.freebsd.org> Date: Mon, 4 Dec 2000 20:32:35 -0800 (PST) From: atrens@nortel.ca Sender: nobody@FreeBSD.org To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: kern/23291: kernel panic on fd0 access with Athlon and >256MB of RAM Resent-Sender: gnats@FreeBSD.org Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 23291 >Category: kern >Synopsis: kernel panic on fd0 access with Athlon and >256MB of RAM >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Dec 04 20:40:00 PST 2000 >Closed-Date: >Last-Modified: >Originator: Andrew Atrens >Release: -current >Organization: Self >Environment: FreeBSD churchill 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Dec 4 01:00:14 EST 2000 atrens@churchill:/tmp/CHURCHILL i386 >Description: Firstly the symptoms - * message like `dmainint(2, 1024) failed' in my dmesg output, subsequent to fdc0 probe, but preceding fd0 - fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 isa_dmainit(2, 1024) failed fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 this appears to indicate that isa_dmainit failed to malloc/contigmalloc a 1024B dma bounce buffer - the only requirement being that this buffer must be alloc'd in the first 16MB of RAM. * any subsequent access to the floppy results in a kernel panic, the exact message escapes me but the gist is 'invalid bounce buffer'. * Setting hw.physmem=256MB in my loader config cures the problem. >How-To-Repeat: Using an Athlon, load it up with more than 256MB of RAM, and try any kind of floppy drive access - mount, mdir, cp, etc. >Fix: Now for the root cause, and my attempt at a fix - * Alan Cox made the following changes to vm/vm_page.c:311 - + /* + * Construct the free queue(s) in descending order (by physical + * address) so that the first 16MB of physical memory is allocated + * last rather than first. On large-memory machines, this avoids + * the exhaustion of low physical memory before isa_dmainit has run. + */ ... - TAILQ_INSERT_HEAD(&vm_page_queues[m->queue].pl, m, pageq); + TAILQ_INSERT_TAIL(&vm_page_queues[m->queue].pl, m, pageq); this spring sometime. March maybe ? * Some time later, Peter Wemm changed the call to TAIL_Q_INSERT_TAIL to a call to a new function `vm_add_new_page()'. Looking at the internals of vm_add_new_page() we see a call to TAILQ_INSERT_HEAD(...), thus (apparently) reversing Alan's change, (fortunately) without changing the comments to reflect this. My attempt at a `fix' is simply to, in vm_add_new_page(), change TAILQ_INSERT_HEAD(...) to TAILQ_INSERT_TAIL(...) This appears to work, but I can't claim to understand the larger picture. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message