Subject: Re: kern/32717: alpha 3.0 install kernel doesn't see scsi disks
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: netbsd-bugs
Date: 04/06/2006 02:45:02
The following reply was made to PR kern/32717; it has been noted by GNATS.
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, raeburn@MIT.EDU
Subject: Re: kern/32717: alpha 3.0 install kernel doesn't see scsi disks
Date: Thu, 06 Apr 2006 11:41:24 +0900
hi,
> Only two files changed in this time interval: uvm/uvm_page.c and uvm/
> uvm_pglist.c, each changed in one line aside from CVS keywords.
> Version 1.100 of uvm_page.c and version 1.32 of uvm_pglist.c have
> this log message:
>
> date: 2004/09/17 20:46:03; author: yamt; state: Exp; lines: +3 -3
> make free page queue filo rather than fifo.
> data in pages freed more recently are more likely on cpu cache.
i hardly see how it causes the symptom.
i think it discovered a bug in somewhere else as you said.
> The uvm_page.c change itself seems logical. Assuming it's actually
> correct, I would guess that my problem means that some page is being
> put onto the free list, and probably allocated again, while some
> other part of the kernel (or a DMA device) isn't done with it yet,
> and the FIFO version of the queue happens to give the extra time
> needed. Or maybe it's bad memory and during the boot process one
> pattern of usage trips over it consistently and the other pattern (as
> well as running NetBSD 2.0 and doing nightly builds of some code I
> work on) does not in any noticeable way. But I think I'm done for
> tonight....
because uvm_page_physload also uses uvm_pagefree,
boot process likely uses very different set of pages after the change.
YAMAMOTO Takashi