Date: Mon, 4 Dec 2000 20:32:35 -0800 (PST) From: atrens@nortel.ca To: freebsd-gnats-submit@FreeBSD.org Subject: kern/23291: kernel panic on fd0 access with Athlon and >256MB of RAM Message-ID: <200012050432.eB54WZ771244@freefall.freebsd.org> Resent-Message-ID: <200012050440.eB54e1h72107@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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: <NEC 72065B or clone> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012050432.eB54WZ771244>