From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Subject: Re: Re: logs attached. Re: [Xen-users] Can not findthe cdrom device in /dev/ afterbooted into xen(3.0.3) Date: Fri, 1 Dec 2006 19:58:36 +0000 Message-ID: <20061201195836.439e5ca1@localhost.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com Cc: Liang Yang , "Petersson, Mats" , xen-devel@lists.xensource.com, tim.post@netkinetics.net, Keir Fraser , xen-users@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Fri, 01 Dec 2006 19:24:33 +0000 Keir Fraser wrote: > Looks like the I/O ports are allocated correctly to the device in both cases > (both Xen and native). So I have no idea why the IDE PCI probing code isn't > picking up on this. At this point I'd be adding tracing to the two kernels > to find out where their probing paths diverge. Looking over the current kernel code it is known to work in the non-Xen case. The native mode on the ESB2 has other problems recently reported but they would cause hangs later with stuck interrupts. Since I've got bugs filed on this I know the detection works outside of Xen. The old IDE probe code predates PCI so conveniently the PCI side of the scan logic is all in setup-pci.c. Modules registering with ide during init are added to a list and all run post init, modules added later get their setup methods run immediately. Thus you can trace loading the piix module pretty directly through idepci_register_driver and ide_setup_pci_device, beyond that you are pretty much out of PCI territory