Discussion: ACPI selective IRQ blacklist

Discussion: ACPI selective IRQ blacklist

[Andrew de Quincey]

Hi, I've been looking into this VIA ACPI issue some more. From various 
reports, if you disable ACPI, the standard linux PCI IRQ routing system is 
able to correctly set up the board.

Some VIA motherboards DO work correctly in ACPI APIC mode however. These 
boards have the APIC IRQ settings hardwired (i.e. they do not use link 
devices).

The problem comes when the BIOS does use link devices. These will work fine in 
PIC mode. However, in APIC mode, the AML code is wrong in several respects in 
lots of BIOSes:

1) The _SRS method can only cope with IRQs <= 15, yet the BIOS returns IRQs > 
15 in the _PRS method. 

2) The _CRS method is hardcoded to return 0 ALWAYS for link devices in APIC 
mode.

The above means we cannot use the AML code for setting APIC IRQ devices on 
many VIA motherboards.

My new patch (acpi-picmode) should mean the boards are functional... just that 
they do not take advantage of any APIC/IO-APIC present.

I looked into trying to fall back to the non-ACPI PCI IRQ routing code. Its 
not really feasible: ACPI does an awful lot of setup before setting up the 
link devices, which it is not really possible to undo without lots of pain.

My suggestion is I expand the current ACPI blacklist to have a field 
specifying whether ACPI PCI routing can be relied upon. 

Using the current blacklisting (which disables ACPI completely) on masses of 
VIA motherboards is not really an option IMO.

So:
If a motherboard is dodgy and IS in the bad-routing-blacklist, ACPI will not 
be used for PCI routing.

If a motherboard is dodgy and is NOT in the bad-routing-blacklist, the 
fallback to picmode code should catch it. If the user then wants APIC with 
ACPI, they report the issue and the board is added to the 
bad-routing-blacklist.

What do people think? This is the best solution I can come up for this problem 
that would not involve a large messy error-prone change.


I'm gonna start implementing this.. but I'd appreciate feedback on this idea.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Discussion: ACPI selective IRQ blacklist

[Andrew de Quincey]

On Wednesday 03 September 2003 23:16, Andrew de Quincey wrote:
> So:
> If a motherboard is dodgy and IS in the bad-routing-blacklist, ACPI will
> not be used for PCI routing.
>
> If a motherboard is dodgy and is NOT in the bad-routing-blacklist, the
> fallback to picmode code should catch it. If the user then wants APIC with
> ACPI, they report the issue and the board is added to the
> bad-routing-blacklist.

On further thought, I realise this isn't future proof. This relies on the 
existence of legacy BIOS tables (e.g. MPBIOS). My machine for one does not 
have such a table; instead it relies on ACPI.

In the meantime, VIA have kindly sent me the docs I need. It turns out the PCI 
routing entries for the problem BIOSes are wrong. The south bridge chip in 
question is the VT8235 (device ID 0x1337), which explains the spread of 
motherboards I've been seeing.

I have a solution in mind; should have something in the next few days.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Discussion: ACPI selective IRQ blacklist

[James Courtier-Dutton]

Andrew de Quincey wrote:
> On Wednesday 03 September 2003 23:16, Andrew de Quincey wrote:
> 
>>So:
>>If a motherboard is dodgy and IS in the bad-routing-blacklist, ACPI will
>>not be used for PCI routing.
>>
>>If a motherboard is dodgy and is NOT in the bad-routing-blacklist, the
>>fallback to picmode code should catch it. If the user then wants APIC with
>>ACPI, they report the issue and the board is added to the
>>bad-routing-blacklist.
> 
> 
> On further thought, I realise this isn't future proof. This relies on the 
> existence of legacy BIOS tables (e.g. MPBIOS). My machine for one does not 
> have such a table; instead it relies on ACPI.
> 
> In the meantime, VIA have kindly sent me the docs I need. It turns out the PCI 
> routing entries for the problem BIOSes are wrong. The south bridge chip in 
> question is the VT8235 (device ID 0x1337), which explains the spread of 
> motherboards I've been seeing.
> 
> I have a solution in mind; should have something in the next few days.
> 
Would it be possible to bypass the BIOS completely, and talk to the 
chips on the motherboard direct ?
It should work, unless the BIOS provides information that the chips on 
the motherboard do not have. At a guess, I would say that the chips on 
the motherboard might not have information like a wiring diagram.

Cheers
James




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Discussion: ACPI selective IRQ blacklist

[Andrew de Quincey]

> Would it be possible to bypass the BIOS completely, and talk to the
> chips on the motherboard direct ?
> It should work, unless the BIOS provides information that the chips on
> the motherboard do not have. At a guess, I would say that the chips on
> the motherboard might not have information like a wiring diagram.

Yeah, that was what I was hoping from the docs. 

However, the VIA8235, its even easier.. the IRQ routing is hardwired in the 
chip itself.. so those BIOSes which provide a list of potential IRQs for link 
devices are completely wrong.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: Discussion: ACPI selective IRQ blacklist

[Nakajima, Jun]

I think acpi-picmode is reasonable and probably it would work more
reliably compared with APIC mode, but the behavior is triggered by
"noapic" (i.e. boot parameter). It was broken for ACPI, but Len has
fixed it. 

Which VIA motherboards should be listed in the blacklist?

Thanks,
Jun

> -----Original Message-----
> From: Andrew de Quincey [mailto:adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org]
> Sent: Wednesday, September 03, 2003 3:16 PM
> To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Cc: linux-acpi
> Subject: Discussion: ACPI selective IRQ blacklist
> 
> Hi, I've been looking into this VIA ACPI issue some more. From various
> reports, if you disable ACPI, the standard linux PCI IRQ routing
system is
> able to correctly set up the board.
> 
> Some VIA motherboards DO work correctly in ACPI APIC mode however.
These
> boards have the APIC IRQ settings hardwired (i.e. they do not use link
> devices).
> 
> The problem comes when the BIOS does use link devices. These will work
> fine in
> PIC mode. However, in APIC mode, the AML code is wrong in several
respects
> in
> lots of BIOSes:
> 
> 1) The _SRS method can only cope with IRQs <= 15, yet the BIOS returns
> IRQs >
> 15 in the _PRS method.
> 
> 2) The _CRS method is hardcoded to return 0 ALWAYS for link devices in
> APIC
> mode.
> 
> The above means we cannot use the AML code for setting APIC IRQ
devices on
> many VIA motherboards.
> 
> My new patch (acpi-picmode) should mean the boards are functional...
just
> that
> they do not take advantage of any APIC/IO-APIC present.
> 
> I looked into trying to fall back to the non-ACPI PCI IRQ routing
code.
> Its
> not really feasible: ACPI does an awful lot of setup before setting up
the
> link devices, which it is not really possible to undo without lots of
pain.
> 
> My suggestion is I expand the current ACPI blacklist to have a field
> specifying whether ACPI PCI routing can be relied upon.
> 
> Using the current blacklisting (which disables ACPI completely) on
masses
> of
> VIA motherboards is not really an option IMO.
> 
> So:
> If a motherboard is dodgy and IS in the bad-routing-blacklist, ACPI
will
> not
> be used for PCI routing.
> 
> If a motherboard is dodgy and is NOT in the bad-routing-blacklist, the
> fallback to picmode code should catch it. If the user then wants APIC
with
> ACPI, they report the issue and the board is added to the
> bad-routing-blacklist.
> 
> What do people think? This is the best solution I can come up for this
> problem
> that would not involve a large messy error-prone change.
> 
> 
> I'm gonna start implementing this.. but I'd appreciate feedback on
this
> idea.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf