[LinuxBIOS] Kernel lock-ups??

Hello,
Here is my new problem. My kernel is locking up right after this line with LB:
---
Checking if this processor honours the WP bit even in supervisor mode... Ok.
---

Looking at the original bootlog the next lines are supposed to be:
---
Security Framework v1.0.0 initialized

SELinux:  Initializing.

SELinux:  Starting in permissive mode

selinux_register_security:  Registering secondary module capability
---

Is there some kind of a bug between LB and SELinux?? Is there a  
command line option to just ignore SELinux?

Thanks - Joe

[Uwe Hermann]

On Sun, Oct 14, 2007 at 12:08:25PM -0400, [e-mail] wrote:
> Hello,
> Here is my new problem. My kernel is locking up right after this line with LB:
> Checking if this processor honours the WP bit even in supervisor mode... Ok.
> Looking at the original bootlog the next lines are supposed to be:
>
> Security Framework v1.0.0 initialized
>
> SELinux:  Initializing.
>
> SELinux:  Starting in permissive mode
> selinux_register_security:  Registering secondary module capability
>
> Is there some kind of a bug between LB and SELinux?? Is there a

I don't think so, this is likely not related to SELinux.
> command line option to just ignore SELinux?

selinux=0 (kernel parameter)

Try with more debugging output in the kernel. Try irqpoll, debug,
acpi=off, dunno maybe more...

Uwe.

[Rudolf Marek]

CHeck the calibrating delay loop code.

Kernel will lockup if the IRQs arent generated at all. Imho there were some
"lpj" options to force at least some value, maybe you can get further.

Rudolf

Quoting Rudolf Marek :
> CHeck the calibrating delay loop code.
>
> Kernel will lockup if the IRQs arent generated at all. Imho there were some
> "lpj" options to force at least some value, maybe you can get further.
>
> Rudolf

Would the IRQs arent generated have anything to do with this:

ACPI: Unable to locate RSDP

Also, it is a custom kernel config. I will try the normal one and see  
if that helps.

Thanks - Joe

[Rudolf Marek]

you need to supply some routing table to kernel. Any of following:

in DSDT
PIR table
MP Table.

There is some util to dump this table friom original bios, although in my case 
MP table was totally b0rked.

I think for a start you may switch off the acpi=off

Rudolf

Quoting Rudolf Marek :
> you need to supply some routing table to kernel. Any of following:
>
> in DSDT
> PIR table
> MP Table.
>
> There is some util to dump this table friom original bios, although in
> my case MP table was totally b0rked.
>
> I think for a start you may switch off the acpi=off
>
> Rudolf

I have HAVE_PIRQ_TABLE=1 and irq_tables.c.
What is the utility for the MP table?

Anyways I tried these kernel options acpi=off irqpoll lpj=720896
and it gets a little further. Now it locks-up on this line:

Checking 'hlt' instruction...

Any ideas?

Thanks - Joe

[Jordan Crouse]

On 15/10/07 08:48 -0400, [e-mail] wrote:
> Quoting Rudolf Marek :
> > you need to supply some routing table to kernel. Any of following:
> >
> > in DSDT
> > PIR table
> > MP Table.
> >
> > There is some util to dump this table friom original bios, although in
> > my case MP table was totally b0rked.
> >
> > I think for a start you may switch off the acpi=off
> >
> > Rudolf
>
> I have HAVE_PIRQ_TABLE=1 and irq_tables.c.
> What is the utility for the MP table?
>
> Anyways I tried these kernel options acpi=off irqpoll lpj=720896
> and it gets a little further. Now it locks-up on this line:
>
> Checking 'hlt' instruction...
>
> Any ideas?

Interrupts are very obviously broken.  In this case, its waiting for an
interrupt to verify that the 'hlt' instruction works.  You can work around
this as well, if you want, but its really going to be in your best interest
to figure out whats wrong in the BIOS.

Jordan

Quoting Jordan Crouse :
> > I have HAVE_PIRQ_TABLE=1 and irq_tables.c.
> > What is the utility for the MP table?
> >
> > Anyways I tried these kernel options acpi=off irqpoll lpj=720896
> > and it gets a little further. Now it locks-up on this line:
> >
> > Checking 'hlt' instruction...
> >
> > Any ideas?
>
> Interrupts are very obviously broken.  In this case, its waiting for an
> interrupt to verify that the 'hlt' instruction works.  You can work around
> this as well, if you want, but its really going to be in your best interest
> to figure out whats wrong in the BIOS.
>
> Jordan

I agree Jordan it needs to be fixed in LB. I don't really know where  
to start. Can someone point me in the right direction? Everything  
looks ok in my bootlog.
Here is the output pertaining to the irq_routing_table.

Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...done
Checking IRQ routing table consistency...
check_pirq_routing_table() - irq_routing_table located at: 0x000f0000
done.
Moving GDT to 0x500...ok
Adjust low_table_end from 0x00000530 to 0x00001000
Adjust rom_table_end from 0x000f0400 to 0x00100000
Wrote linuxbios table at: 00000530 - 000006ec  checksum 622a

Heck, I just attached my whole bootlog. Please take a look and see if  
you can see anything wrong. I would really appreciate it.

Thanks - Joe

> > Interrupts are very obviously broken.  In this case, its waiting for an
> > interrupt to verify that the 'hlt' instruction works.  You can work around
> > this as well, if you want, but its really going to be in your best interest
> > to figure out whats wrong in the BIOS.
>
> Copying IRQ routing tables to 0xf0000...done.
> Verifing copy of IRQ routing tables at 0xf0000...done
> Checking IRQ routing table consistency...
> check_pirq_routing_table() - irq_routing_table located at: 0x000f0000
> done.
> Moving GDT to 0x500...ok
> Adjust low_table_end from 0x00000530 to 0x00001000
> Adjust rom_table_end from 0x000f0400 to 0x00100000
> Wrote linuxbios table at: 00000530 - 000006ec  checksum 622a

So it looks like the IRQ routing tables are copied to 0xf0000. This is  
the Upper Bios Area 0x0F0000(960K) - 0x0FFFFF(1MB) Correct?? Could  
this area be write only? I have the PAM register set to R/W. This is  
also the "shadow" Bios area, could that be the issue? Is there a way  
to dump this area in human readable format right after the  
check_pirq_routing_table() function, so I can see what the heck is  
going on here? By the way I used getpir.c to get my irq_tables.c file.  
Could this be messed up? If so how come the functions above do not  
detect any errors?

Thanks - Joe

[Uwe Hermann]

On Tue, Oct 16, 2007 at 03:43:12AM -0400, [e-mail] wrote:
> So it looks like the IRQ routing tables are copied to 0xf0000. This is  
> the Upper Bios Area 0x0F0000(960K) - 0x0FFFFF(1MB) Correct?? Could  
> this area be write only? I have the PAM register set to R/W. This is  
> also the "shadow" Bios area, could that be the issue? Is there a way  
> to dump this area in human readable format right after the  
> check_pirq_routing_table() function, so I can see what the heck is  
> going on here? By the way I used getpir.c to get my irq_tables.c file.  
> Could this be messed up? If so how come the functions above do not

Yes, messed up in the sense of "incorrect for your board".
> detect any errors?

The maximum it can do is check a checksum, but it won't detect whether
your routing table is correct for your specific board.

This might be helpful: http://linuxbios.org/Creating_Valid_IRQ_Tables

Uwe.

[ron minnich]

Factory bioses frequently ship with broken IRQ tables. The 'hlt'
problem is a classic 'clock interrupts are not working' symptom. This
is good (it's basic) and bad (it can be a bear to debug).

how do vendors get around their own broken tables in the fuctory bios?
It appears they ignore them and just jam the correct bits into
correct places. sad, but true. We see it all the time.

You're going to have to dig in and make sure you understand the IRQ
routing on your board, dump the registers on fuctory bios, and figure
out why the irq table is wrong -- assuming it is.

ron

[Stefan Reinauer]

ron minnich wrote:
> Factory bioses frequently ship with broken IRQ tables. The 'hlt'
> problem is a classic 'clock interrupts are not working' symptom. This
> is good (it's basic) and bad (it can be a bear to debug).
>
> how do vendors get around their own broken tables in the fuctory bios?
> It appears they ignore them and just jam the correct bits into
> correct places. sad, but true. We see it all the time.

Vendors also ship with ACPI. As soon as Linux detects a reasonably
complete ACPI implementation, it will not even look at IRQ tables anymore.

Stefan

[Uwe Hermann]

On Tue, Oct 16, 2007 at 06:31:19PM +0200, Stefan Reinauer wrote:
> ron minnich wrote:
> > Factory bioses frequently ship with broken IRQ tables. The 'hlt'
> > problem is a classic 'clock interrupts are not working' symptom. This
> > is good (it's basic) and bad (it can be a bear to debug).
> >
> > how do vendors get around their own broken tables in the fuctory bios?
> > It appears they ignore them and just jam the correct bits into
> > correct places. sad, but true. We see it all the time.
>
> Vendors also ship with ACPI. As soon as Linux detects a reasonably
> complete ACPI implementation, it will not even look at IRQ tables anymore.

I'm curious, can we make the same assumptions for other payloads/OSes?
Windows, *BSD, Solaris, Plan 9, OS/2 (yuck), DOS, OFW(?), whatever...

Uwe.

[Stefan Reinauer]

Uwe Hermann wrote:
> On Tue, Oct 16, 2007 at 06:31:19PM +0200, Stefan Reinauer wrote:
> > ron minnich wrote:
> > > Factory bioses frequently ship with broken IRQ tables. The 'hlt'
> > > problem is a classic 'clock interrupts are not working' symptom. This
> > > is good (it's basic) and bad (it can be a bear to debug).
> > >
> > > how do vendors get around their own broken tables in the fuctory bios?
> > > It appears they ignore them and just jam the correct bits into
> > > correct places. sad, but true. We see it all the time.
> >
> > Vendors also ship with ACPI. As soon as Linux detects a reasonably
> > complete ACPI implementation, it will not even look at IRQ tables anymore.
>
> I'm curious, can we make the same assumptions for other payloads/OSes?
> Windows, *BSD, Solaris, Plan 9, OS/2 (yuck), DOS, OFW(?), whatever...

The assumption we can make is: either ACPI or MP+PIRQ have to be there.
The other assumption is no "legacy" BIOS supports MP+PIRQ anymore.
So the "legacy" stuff is only actively maintained in LinuxBIOS ;-)

Stefan

Quoting Stefan Reinauer :
> Uwe Hermann wrote:
> > On Tue, Oct 16, 2007 at 06:31:19PM +0200, Stefan Reinauer wrote:
> > > ron minnich wrote:
> > > > Factory bioses frequently ship with broken IRQ tables. The 'hlt'
> > > > problem is a classic 'clock interrupts are not working' symptom. This
> > > > is good (it's basic) and bad (it can be a bear to debug).
> > > >
> > > > how do vendors get around their own broken tables in the fuctory bios?
> > > > It appears they ignore them and just jam the correct bits into
> > > > correct places. sad, but true. We see it all the time.
> > >
> > > Vendors also ship with ACPI. As soon as Linux detects a reasonably
> > > complete ACPI implementation, it will not even look at IRQ tables anymore.
> >
> > I'm curious, can we make the same assumptions for other payloads/OSes?
> > Windows, *BSD, Solaris, Plan 9, OS/2 (yuck), DOS, OFW(?), whatever...
>
> The assumption we can make is: either ACPI or MP+PIRQ have to be there.
> The other assumption is no "legacy" BIOS supports MP+PIRQ anymore.
> So the "legacy" stuff is only actively maintained in LinuxBIOS ;-)
>
> Stefan

Ok, So I will dig into the irq tables and see what I can find. But,  
how do I now this isn't just related to a Read issue with the Upper  
Bios Area 0x0F0000(960K) - 0x0FFFFF(1MB)?? That is why I would like to  
diagnos that first. So I ask is there a way to dump (printk) this area  
in human readable format right after the check_pirq_routing_table()  
function?? Or if I can fudge my way to a linux command line with a  
whole bunch of work arounds can I dump it then to see the issue?

FYI: The original Bios does use ACPI for interrupt & irq routing.
 From the kernel booting:

ACPI: Subsystem revision 20040816
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 *7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0,  
disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0,  
disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 7
ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 7 (level, low) -> IRQ 7
ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 7 (level, low) -> IRQ 7
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 5 (level, low) -> IRQ 5
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 9
ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 9 (level, low) -> IRQ 9
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 10
ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 10 (level, low) -> IRQ 10
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 9 (level, low) -> IRQ 9
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
ACPI: PCI interrupt 0000:00:1f.3[B] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 11
ACPI: PCI interrupt 0000:01:08.0[A] -> GSI 11 (level, low) -> IRQ 11

Thanks - Joe

Quoting [e-mail]:
> Quoting Stefan Reinauer :
> > Uwe Hermann wrote:
> > > On Tue, Oct 16, 2007 at 06:31:19PM +0200, Stefan Reinauer wrote:
> > > > ron minnich wrote:
> > > > > Factory bioses frequently ship with broken IRQ tables. The 'hlt'
> > > > > problem is a classic 'clock interrupts are not working' symptom. This
> > > > > is good (it's basic) and bad (it can be a bear to debug).
> > > > >
> > > > > how do vendors get around their own broken tables in the fuctory bios?
> > > > > It appears they ignore them and just jam the correct bits into
> > > > > correct places. sad, but true. We see it all the time.
> > > >
> > > > Vendors also ship with ACPI. As soon as Linux detects a reasonably
> > > > complete ACPI implementation, it will not even look at IRQ tables anymore.
> > >
> > > I'm curious, can we make the same assumptions for other payloads/OSes?
> > > Windows, *BSD, Solaris, Plan 9, OS/2 (yuck), DOS, OFW(?), whatever...
> >
> > The assumption we can make is: either ACPI or MP+PIRQ have to be there.
> > The other assumption is no "legacy" BIOS supports MP+PIRQ anymore.
> > So the "legacy" stuff is only actively maintained in LinuxBIOS ;-)
> >
> > Stefan
>
> Ok, So I will dig into the irq tables and see what I can find. But,
> how do I now this isn't just related to a Read issue with the Upper
> Bios Area 0x0F0000(960K) - 0x0FFFFF(1MB)?? That is why I would like to
> diagnos that first. So I ask is there a way to dump (printk) this area
> in human readable format right after the check_pirq_routing_table()
> function?? Or if I can fudge my way to a linux command line with a
> whole bunch of work arounds can I dump it then to see the issue?
>
> FYI: The original Bios does use ACPI for interrupt & irq routing.
>  From the kernel booting:
>
> ACPI: Subsystem revision 20040816
> ACPI: Interpreter enabled
> ACPI: Using PIC for interrupt routing
> ACPI: PCI Root Bridge [PCI0] (00:00)
> PCI: Probing PCI hardware (bus 00)
> PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
> PCI: Transparent bridge - 0000:00:1e.0
> ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 *7 9 10 11 12 14 15)
> ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
> ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
> ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
> ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
> ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0,
> disabled.
> ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0,
> disabled.
> ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
> Linux Plug and Play Support v0.97 (c) Adam Belay
> usbcore: registered new driver usbfs
> usbcore: registered new driver hub
> PCI: Using ACPI for IRQ routing
> ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 7
> ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 7 (level, low) -> IRQ 7
> ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 7 (level, low) -> IRQ 7
> ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
> ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 5 (level, low) -> IRQ 5
> ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 9
> ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 9 (level, low) -> IRQ 9
> ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 10
> ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 10 (level, low) -> IRQ 10
> ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 9 (level, low) -> IRQ 9
> ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
> ACPI: PCI interrupt 0000:00:1f.3[B] -> GSI 11 (level, low) -> IRQ 11
> ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 11 (level, low) -> IRQ 11
> ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 11
> ACPI: PCI interrupt 0000:01:08.0[A] -> GSI 11 (level, low) -> IRQ 11
>
> Thanks - Joe

Another quick thought. According to irc_tables.c the LPC Bridge is where

(0x1f<<3)|0x0,   /* Where the interrupt router lies (dev) */

the interrupt router lies. Could there be a bad register setting  
messing this up??

Thanks - Joe

Quoting [e-mail]:
> Quoting [e-mail]:
> > Quoting Stefan Reinauer :
> > > Uwe Hermann wrote:
> > > > On Tue, Oct 16, 2007 at 06:31:19PM +0200, Stefan Reinauer wrote:
> > > > > ron minnich wrote:
> > > > > > Factory bioses frequently ship with broken IRQ tables. The 'hlt'
> > > > > > problem is a classic 'clock interrupts are not working' symptom. This
> > > > > > is good (it's basic) and bad (it can be a bear to debug).
> > > > > >
> > > > > > how do vendors get around their own broken tables in the fuctory bios?
> > > > > > It appears they ignore them and just jam the correct bits into
> > > > > > correct places. sad, but true. We see it all the time.
> > > > >
> > > > > Vendors also ship with ACPI. As soon as Linux detects a reasonably
> > > > > complete ACPI implementation, it will not even look at IRQ   
> > > > > tables anymore.
> > > >
> > > > I'm curious, can we make the same assumptions for other payloads/OSes?
> > > > Windows, *BSD, Solaris, Plan 9, OS/2 (yuck), DOS, OFW(?), whatever...
> > >
> > > The assumption we can make is: either ACPI or MP+PIRQ have to be there.
> > > The other assumption is no "legacy" BIOS supports MP+PIRQ anymore.
> > > So the "legacy" stuff is only actively maintained in LinuxBIOS ;-)
> > >
> > > Stefan
> >
> > Ok, So I will dig into the irq tables and see what I can find. But,
> > how do I now this isn't just related to a Read issue with the Upper
> > Bios Area 0x0F0000(960K) - 0x0FFFFF(1MB)?? That is why I would like to
> > diagnos that first. So I ask is there a way to dump (printk) this area
> > in human readable format right after the check_pirq_routing_table()
> > function?? Or if I can fudge my way to a linux command line with a
> > whole bunch of work arounds can I dump it then to see the issue?

So just for sh*** and giggles I tried the no-hlt command and it got a  
little further. Does this look like the kernel is able to read the irq  
tables from LB but they are incorrect???

Thanks - Joe

Booting 'hdc1:/vmlinuz-2.6.9-1.667 ro root=/dev/hdc2 console=tty0  
console=ttyS0
,115200n8 acpi=off irqpoll lpj=720896 no-hlt initrd=/initrd-2.6.9-1.667.img'

PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
PCI: Using IRQ router PIIX/ICH [8086/24c0] at 0000:00:1f.
PCI: IRQ 0 for device 0000:00:02.0 doesn't match PIRQ mask - try  
pci=usepirqmask
PCI: Found IRQ 11 for device 0000:00:02.0
PCI: Sharing IRQ 11 with 0000:00:1d.0
PCI: IRQ 0 for device 0000:00:1d.1 doesn't match PIRQ mask - try  
pci=usepirqmask
PCI: Found IRQ 10 for device 0000:00:1d.1
PCI: IRQ 0 for device 0000:00:1d.2 doesn't match PIRQ mask - try  
pci=usepirqmask
PCI: Found IRQ 5 for device 0000:00:1d.2
PCI: Sharing IRQ 5 with 0000:00:1f.1
PCI: IRQ 0 for device 0000:00:1d.7 doesn't match PIRQ mask - try  
pci=usepirqmask
PCI: IRQ 0 for device 0000:00:1f.3 doesn't match PIRQ mask - try  
pci=usepirqmask
PCI: Found IRQ 3 for device 0000:00:1f.3
PCI: Sharing IRQ 3 with 0000:00:1f.5
PCI: Sharing IRQ 3 with 0000:00:1f.6

[Stefan Reinauer]

* [e-mail]  [071017 09:18]:
> PCI: IRQ 0 for device 0000:00:02.0 doesn't match PIRQ mask - try  
> PCI: IRQ 0 for device 0000:00:1d.1 doesn't match PIRQ mask - try  
> PCI: IRQ 0 for device 0000:00:1d.2 doesn't match PIRQ mask - try  
> PCI: IRQ 0 for device 0000:00:1d.7 doesn't match PIRQ mask - try  
> PCI: IRQ 0 for device 0000:00:1f.3 doesn't match PIRQ mask - try

Do you have these devices in your mptable, pirq table?

[Rudolf Marek]

Hi,

Doing ACPI only IRQ routing is quite easy. I'm not going to describe whole ACPI 
table stuff just the part you need for the routing:

http://www.linuxbios.org/pipermail/linuxbios/2007-October/025845.html

Check the dsdt.asl file in patch above.
    	/* top PCI device */
    	Device (PCI0)
    	{
    		Name (_HID, EisaId ("PNP0A03"))
    		Name (_ADR, 0x00)
    		Name (_UID, 0x00)
    		Name (_BBN, 0x00)
    		
    		/* PCI Routing Table */
    		//aaa
    		Name (_PRT, Package () {

This is where actual routing table for SB starts:

Package (0x04) { 0x000BFFFF, 0x00, 0x00, 0x10 },

0xDDDDFFFF, LNK, 00, GSI

DDDD is PCI DEV, FFFF is function, LNK is PCI link - so LNKA B etc...
Next parameter is 00 if you do not support legacy PIC routing at all.

Last parameter is global interrupt NR.

//slot 0xB
         	            Package (0x04) { 0x000BFFFF, 0x01, 0x00, 0x11 },
                 	    Package (0x04) { 0x000BFFFF, 0x02, 0x00, 0x12 },
                        Package (0x04) { 0x000BFFFF, 0x03, 0x00, 0x13 },
         	            Package (0x04) { 0x000CFFFF, 0x00, 0x00, 0x11 }, //Slot 0xC
                 	    Package (0x04) { 0x000CFFFF, 0x01, 0x00, 0x12 },
                 	    Package (0x04) { 0x000CFFFF, 0x02, 0x00, 0x13 },
    		    Package (0x04) { 0x000CFFFF, 0x03, 0x00, 0x10 },
         	            Package (0x04) { 0x000DFFFF, 0x00, 0x00, 0x12 }, //Slot 0xD
                 	    Package (0x04) { 0x000DFFFF, 0x01, 0x00, 0x13 },
                 	    Package (0x04) { 0x000DFFFF, 0x02, 0x00, 0x10 },
    		    Package (0x04) { 0x000DFFFF, 0x03, 0x00, 0x11 },
         	            Package (0x04) { 0x000F0000, 0x01, 0x00, 0x14 }, //0xf 
SATA IRQ 20
                 	    Package (0x04) { 0x000F0001, 0x00, 0x00, 0x14 },

So for example SATA is routed through LNKA, and it is device 0f.1.

//0xf NAtive IDE IRQ 20
         	            Package (0x04) { 0x0010FFFF, 0x00, 0x00, 0x15 }, //USB routing
                 	    Package (0x04) { 0x0010FFFF, 0x01, 0x00, 0x15 },
                 	    Package (0x04) { 0x0010FFFF, 0x02, 0x00, 0x15 },
    		    Package (0x04) { 0x0010FFFF, 0x03, 0x00, 0x15 },
    		    Package (0x04) { 0x0011FFFF, 0x02, 0x00, 0x16 }, //AC97 MC97
         	            Package (0x04) { 0x0002FFFF, 0x00, 0x00, 0x1B }, //PCIE16 
bridge IRQ27
                 	    Package (0x04) { 0x0002FFFF, 0x01, 0x00, 0x1B },
                 	    Package (0x04) { 0x0002FFFF, 0x02, 0x00, 0x1B },
    		    Package (0x04) { 0x0002FFFF, 0x03, 0x00, 0x1B },
         	            Package (0x04) { 0x0003FFFF, 0x00, 0x00, 0x1F }, //PCIE 
bridge IRQ31
                 	    Package (0x04) { 0x0003FFFF, 0x01, 0x00, 0x23 }, //IRQ36
                 	    Package (0x04) { 0x0003FFFF, 0x02, 0x00, 0x27 }, //IRQ39
    		    Package (0x04) { 0x0003FFFF, 0x03, 0x00, 0x2B } //IRQ43
             		})

Device (PEGG)
    	{
    		Name (_ADR, 0x00020000)
    		Name (_UID, 0x00)
    		Name (_BBN, 0x02)

Other devices may have own PRT tables.
    		
    		Name (_PRT, Package () {
                        Package (0x04) { 0x0000FFFF, 0x00, 0x00, 0x18 }, //PCIE 
IRQ24-IRQ27
         	            Package (0x04) { 0x0000FFFF, 0x01, 0x00, 0x19 },
                 	    Package (0x04) { 0x0000FFFF, 0x02, 0x00, 0x1A },
                        Package (0x04) { 0x0000FFFF, 0x03, 0x00, 0x1B },
    		})	
    	} //end of PCIEG

Hope it helps,

Rudolf

[Stefan Reinauer]

* [e-mail]  [071017 03:08]:
> Ok, So I will dig into the irq tables and see what I can find. But, how do 
> I now this isn't just related to a Read issue with the Upper Bios Area 
> 0x0F0000(960K) - 0x0FFFFF(1MB)?? That is why I would like to diagnos that 
> first. So I ask is there a way to dump (printk) this area in human readable 
> format right after the check_pirq_routing_table() function?? Or if I can 
> fudge my way to a linux command line with a whole bunch of work arounds can 
> I dump it then to see the issue?

It is very likely that F0000 is not writable per default. I think a
workaround was to not compress the LinuxBIOS image, so the PIRQ table
would stay uncompressed in the F0000 area.
> FYI: The original Bios does use ACPI for interrupt & irq routing.

Yep, they're all like that these days. (Mostly)