From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: Re: Continuing problems booting
Date: Fri, 06 Mar 2009 08:08:39 -0800
Message-ID: <49B14A87.1030504@goop.org>
References: <alpine.GSO.2.00.0902201239010.757@algedi.dur.ac.uk>	<alpine.GSO.2.00.0902201554500.757@algedi.dur.ac.uk>	<alpine.LFD.2.00.0902211225540.14632@vega4.dur.ac.uk>	<49A0F68D.9070306@goop.org>	<alpine.LFD.2.00.0902220922040.4149@vega1.dur.ac.uk>	<alpine.LFD.2.00.0902221449410.17196@vega3.dur.ac.uk>	<49A187B8.7000902@goop.org>	<alpine.LFD.2.00.0902222257230.4472@vega4.dur.ac.uk>	<49A1DD80.1080903@goop.org>	<alpine.LFD.2.00.0902222359090.4472@vega4.dur.ac.uk>	<49A241EC.3050300@goop.org>	<alpine.LFD.2.00.0902242228550.12607@vega3.dur.ac.uk>	<alpine.LFD.2.00.0902272317030.17305@vega3.dur.ac.uk>
	<49A890FF.4080803@goop.org> <49ABAF7C.6050906@redhat.com>
	<49AF5FEB.4010508@goop.org> <49AF80C1.2060307@redhat.com>
	<49AFB122.5040301@redhat.com> <49B02069.5000207@goop.org>
	<49B12FE4.7050503@redhat.com> <49B13F2F.1060100@goop.org>
	<49B1426E.3080901@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <49B1426E.3080901@redhat.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: xen-devel@lists.xensource.com, M A Young <m.a.young@durham.ac.uk>
List-Id: xen-devel@lists.xenproject.org

Gerd Hoffmann wrote:
>> Hm.  I was not really planning on supporting no-ACPI; I've only hooked
>> acpi_register_gsi, which is called via acpi_pci_irq_enable.  I guess
>> you'd need to do something in pirq_enable_irq as well, and I'm not sure
>> if all the stuff gets set up properly for IO_APIC_get_PCI_irq_vector to
>> work.
>>     
>
> I have -rc6 kernel which *does* boot.  Maybe that was by accident ;)
>   

Hm, well I don't remember adding any new ENOSYSes in there, so perhaps 
the core kernel has changed in some way under us.

I'm guessing it's this:

static int
__setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)
{
	struct irqaction *old, **old_ptr;
	const char *old_name = NULL;
	unsigned long flags;
	int shared = 0;
	int ret;

	if (!desc)
		return -EINVAL;

	if (desc->chip == &no_irq_chip)
		return -ENOSYS;
...


which gets called from request_irq.  So that means that the desc is 
getting allocated but the chip hasn't been set up.  Are you using sparse 
irqs?

> The kernel initializes legacy interrupts anyway.  I think you don't need
> to do more to handle apic-less machines, no?
>   

I guess not, if its only using irqs < 16.  How old is this machine 
anyway; do you really mean its a literal i386?

But the info I'm using to set up the legacy interrupts comes from acpi 
tables, I think, so perhaps its misprogramming the legacy interrupts, 
whereas before they just happened to work in their default config (???).

    J