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