WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: Continuing problems booting

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Re: Continuing problems booting
From: Gerd Hoffmann <kraxel@xxxxxxxxxx>
Date: Mon, 09 Mar 2009 09:02:37 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, M A Young <m.a.young@xxxxxxxxxxxx>
Delivery-date: Mon, 09 Mar 2009 01:03:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49B14A87.1030504@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.GSO.2.00.0902201239010.757@xxxxxxxxxxxxxxxx> <alpine.GSO.2.00.0902201554500.757@xxxxxxxxxxxxxxxx> <alpine.LFD.2.00.0902211225540.14632@xxxxxxxxxxxxxxx> <49A0F68D.9070306@xxxxxxxx> <alpine.LFD.2.00.0902220922040.4149@xxxxxxxxxxxxxxx> <alpine.LFD.2.00.0902221449410.17196@xxxxxxxxxxxxxxx> <49A187B8.7000902@xxxxxxxx> <alpine.LFD.2.00.0902222257230.4472@xxxxxxxxxxxxxxx> <49A1DD80.1080903@xxxxxxxx> <alpine.LFD.2.00.0902222359090.4472@xxxxxxxxxxxxxxx> <49A241EC.3050300@xxxxxxxx> <alpine.LFD.2.00.0902242228550.12607@xxxxxxxxxxxxxxx> <alpine.LFD.2.00.0902272317030.17305@xxxxxxxxxxxxxxx> <49A890FF.4080803@xxxxxxxx> <49ABAF7C.6050906@xxxxxxxxxx> <49AF5FEB.4010508@xxxxxxxx> <49AF80C1.2060307@xxxxxxxxxx> <49AFB122.5040301@xxxxxxxxxx> <49B02069.5000207@xxxxxxxx> <49B12FE4.7050503@xxxxxxxxxx> <49B13F2F.1060100@xxxxxxxx> <49B1426E.3080901@xxxxxxxxxx> <49B14A87.1030504@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.19 (X11/20090105)
Jeremy Fitzhardinge wrote:
> 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;
> ...

I can try sprinkle in some printk's to figure ...

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

It's enabled, yes (config is derived from default fedora one ...)

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

Pentium III (~2001), /proc/interrupts on bare metal looks like this:

           CPU0
  0:     617526    XT-PIC-XT        timer
  1:        286    XT-PIC-XT        i8042
  2:          0    XT-PIC-XT        cascade
  3:          3    XT-PIC-XT
  4:          1    XT-PIC-XT
  5:          1    XT-PIC-XT        Intel 440MX Modem, Intel 440MX
  6:          1    XT-PIC-XT
  7:          1    XT-PIC-XT
  8:          1    XT-PIC-XT        rtc0
  9:          5    XT-PIC-XT        acpi
 10:         50    XT-PIC-XT        yenta, firewire_ohci
 11:      13186    XT-PIC-XT        uhci_hcd:usb1, eth0
 12:       6131    XT-PIC-XT        i8042
 14:      56351    XT-PIC-XT        ata_piix
 15:          0    XT-PIC-XT        ata_piix
NMI:          0   Non-maskable interrupts
LOC:          0   Local timer interrupts
RES:          0   Rescheduling interrupts
CAL:          0   Function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
SPU:          0   Spurious interrupts
ERR:          0
MIS:          0

> 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 (???).

As the *registration* fails already I don't think it is misprogramming.

cheers,
  Gerd

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel