Bug 23291

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.

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.
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.