[LinuxBIOS] [patch] Fix M57SLI interrupt routing

[Torsten Duwe]

This patch makes both PCI slots and the primary PCIe work for me, sort of.
The only downsides are that under heavy usage I lose an interrupt once in a 
while, but this might be due to irqpoll.

The other issue is that the graphics card still only initialises under X, and 
still very slowly.

Looking at mptable.c I get the impression it was copied almost verbatim from 
another board and not adopted to the M57SLI. Yinghai, where did you get the 
routing info from?

Another scary thing is that the wiring seems to differ when the board is set 
up via LinuxBIOS; legacy BIOS puts the PCIe 16x int A on the same line with 
bus 1 device 8, while LinuxBIOS does that with bus 1 device 7 ! Can anyone 
with a datasheet shed some light on this?

Anyway, here's the patch that improves things quite a lot on my machine.

please SVN-quote only below this line :-)
------------------------------------------------------------------------------------------
Fix the M57SLI routing table, as apparently  set up from LinuxBIOS on that 
board. Shift PCIe pin numbers downwards, and PCI int pins upwards. This puts 
both PCI slots' int A and PCIe 16x int A into the right position.

Signed-off-by: Torsten Duwe

[Carl-Daniel Hailfinger]

On 05.11.2007 12:04, Torsten Duwe wrote:
> This patch makes both PCI slots and the primary PCIe work for me, sort of.
> The only downsides are that under heavy usage I lose an interrupt once in a 
> while, but this might be due to irqpoll.
>
> The other issue is that the graphics card still only initialises under X, and 
> still very slowly.
>
> Looking at mptable.c I get the impression it was copied almost verbatim from 
> another board and not adopted to the M57SLI. Yinghai, where did you get the 
> routing info from?
>
> Another scary thing is that the wiring seems to differ when the board is set 
> up via LinuxBIOS; legacy BIOS puts the PCIe 16x int A on the same line with 
> bus 1 device 8, while LinuxBIOS does that with bus 1 device 7 ! Can anyone 
> with a datasheet shed some light on this?
>
> Anyway, here's the patch that improves things quite a lot on my machine.
> please SVN-quote only below this line :-)
>
> Fix the M57SLI routing table, as apparently  set up from LinuxBIOS on that 
> board. Shift PCIe pin numbers downwards, and PCI int pins upwards. This puts 
> both PCI slots' int A and PCIe 16x int A into the right position.
>
> Signed-off-by: Torsten Duwe

Acked-by: Carl-Daniel Hailfinger

Thanks, Torsten. Checked in in r2946.

What issues remain for the board now that this has been checked in? Do
you still need irqpoll?

Regards,
Carl-Daniel

[Torsten Duwe]

On Monday 05 November 2007, Carl-Daniel Hailfinger wrote:
> What issues remain for the board now that this has been checked in?

* the MTRR problem
* my ATI "atom BIOS" still does not init the GFX card, X startup slow
* other INTs (B, C, D) mostly untested
* FireWire untested
* assumed write protect lines to the flash chips
* more possible issues due to GPIO and INT route programming...
> Do you still need irqpoll?

Rebuilding and rebooting right after this mail ... :-)

Torsten

[Carl-Daniel Hailfinger]

On 06.11.2007 00:40, Torsten Duwe wrote:
> On Monday 05 November 2007, Carl-Daniel Hailfinger wrote:
> > What issues remain for the board now that this has been checked in?
>
> [...]
> assumed write protect lines to the flash chips

IIRC we can flash PLCC boards under LB just fine, the SPI variants need
to set one bit and allocate a port range in the SuperIO. Once I know how
to tell board types apart, I can post a patch to fix that issue
automatically.
> more possible issues due to GPIO and INT route programming...

This would be a lot easier with proper documentation.

Carl-Daniel

[Torsten Duwe]

On Tuesday 06 November 2007 00:51, Carl-Daniel Hailfinger wrote:
> On 06.11.2007 00:40, Torsten Duwe wrote:
> > On Monday 05 November 2007, Carl-Daniel Hailfinger wrote:
> > > What issues remain for the board now that this has been checked in?
> >
> > [...]
> > assumed write protect lines to the flash chips
>
> IIRC we can flash PLCC boards under LB just fine, the SPI variants need
> to set one bit and allocate a port range in the SuperIO. Once I know how
> to tell board types apart, I can post a patch to fix that issue
> automatically.

Nope, flash erase fails reliably for me. I suggest we call it SPI flashing vs. 
LPC flashing for consistency's sake; there might be SPI chips in a PLCC 
housing out there?

My original idea was to say that gigabyte has one flash image for all board 
revisions, but SPI flashing alone will make them different, bit-wise.
> > more possible issues due to GPIO and INT route programming...
>
> This would be a lot easier with proper documentation.

Amen, brother!

'night
    Torsten

[Torsten Duwe]

On Tuesday 06 November 2007 00:40, Torsten Duwe wrote:
> On Monday 05 November 2007, Carl-Daniel Hailfinger wrote:
> > Do you still need irqpoll?
>
> Rebuilding and rebooting right after this mail ... :-)

...now posting from it.

No more irqpoll, glxgears at full performance, both PCI slots' INT A working.
PCIe 16x INT A working. No more lost interrupts.

Save for the untested FireWire, interrupts are basically working now for me.

Torsten

[Ward Vandewege]

On Tue, Nov 06, 2007 at 01:25:28AM +0100, Torsten Duwe wrote:
> On Tuesday 06 November 2007 00:40, Torsten Duwe wrote:
> > On Monday 05 November 2007, Carl-Daniel Hailfinger wrote:
> > > Do you still need irqpoll?
> >
> > Rebuilding and rebooting right after this mail ... :-)
>
> ...now posting from it.
>
> No more irqpoll, glxgears at full performance, both PCI slots' INT A working.
> PCIe 16x INT A working. No more lost interrupts.
>
> Save for the untested FireWire, interrupts are basically working now for me.

Yeah, thanks! Your patch also seems to have fixed the flashrom problem I saw
under LB (http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/87). I'm going
to give it some more testing because it *sometimes* would work before, but
it's looking good so far.

Are you using NoDCC2 in xorg.conf to get X to start up fast? Seems I still
need that.

Thanks!
Ward.

[Andreas B. Mundt]

Hello,

unfortunately, for me flashrom still fails (I've never seen it working 
on my bord with LB, factory bios works).

I still need "NoDCC2".

Regards,

Andi

On Tue, Nov 06, 2007 at 02:21:26PM -0500, Ward Vandewege wrote:
> Yeah, thanks! Your patch also seems to have fixed the flashrom problem I saw
> under LB (http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/87). I'm going
> to give it some more testing because it *sometimes* would work before, but
> it's looking good so far.
>
> Are you using NoDCC2 in xorg.conf to get X to start up fast? Seems I still
> need that.
>
> Thanks!
> Ward.

[Ward Vandewege]

Hi Andi,

On Tue, Nov 06, 2007 at 10:02:05PM +0100, Andreas B. Mundt wrote:
> unfortunately, for me flashrom still fails (I've never seen it working 
> on my bord with LB, factory bios works).

Yeah, same here, I was wrong :/

However, I'm glad you also see the problem - it's not just my board then
(which had the plcc chip removed and a socket soldered on).

Did you also modify your board?

Thanks,
Ward.

[Andreas B. Mundt]

On Tue, Nov 06, 2007 at 04:12:59PM -0500, Ward Vandewege wrote:
> Hi Andi,
>
> On Tue, Nov 06, 2007 at 10:02:05PM +0100, Andreas B. Mundt wrote:
> > unfortunately, for me flashrom still fails (I've never seen it working 
> > on my bord with LB, factory bios works).
>
> Yeah, same here, I was wrong :/
>
> However, I'm glad you also see the problem - it's not just my board then
> (which had the plcc chip removed and a socket soldered on).
>
> Did you also modify your board?

Hi Ward,

I used ST's approach with the socket soldered on the free patches:

http://private.vlsi.informatik.tu-darmstadt.de/st/instructions.html

Up to now, I just checked the new (socketed) BIOS chip with LB flashing 
because I have the proprietary BIOS still on the soldered chip. 
I could flip this if it turns out to cause the failure. 
But I don't think so.

Regards,

Andi

[Harald Gutmann]

Am Dienstag, 6. November 2007 01:25:28 schrieb Torsten Duwe:
> On Tuesday 06 November 2007 00:40, Torsten Duwe wrote:
> > On Monday 05 November 2007, Carl-Daniel Hailfinger wrote:
> > > Do you still need irqpoll?
> >
> > Rebuilding and rebooting right after this mail ... :-)
>
> ...now posting from it.
>
> No more irqpoll, glxgears at full performance, both PCI slots' INT A
> working. PCIe 16x INT A working. No more lost interrupts.

today i tried rev 2955 from LB with your patch for getting the PCI's working.
what i can tell is:
the pci slot to the edge is listed, and the device appears in /proc/interrups,
also firewire shows up in lspci. in the other pci-slot there is no card in my 
pc.

one problem remains:
the nvidia grapic card won't start up with X11 and the propritary nvidia 
driver. i get the following error message from X:
"(EE) NVIDIA(0): The NVIDIA kernel module does not appear to be receiving
(EE) NVIDIA(0):     interrupts generated by the NVIDIA graphics device
(EE) NVIDIA(0):     PCI:7:0:0.  Please see Chapter 8: Common Problems in the
(EE) NVIDIA(0):     README for additional information.
(EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device!"

i've the rev. 2.0 from this mainboard. the superiotool output from lb in 
rev.2955 is attaced in the thread to bug #87 and also the output from the 
propritary bios is to find there.
> Save for the untested FireWire, interrupts are basically working now for
> me.
>
> Torsten

regards,
harald

[yhlu]

On 11/5/07, Torsten Duwe  wrote:
> This patch makes both PCI slots and the primary PCIe work for me, sort of.
> The only downsides are that under heavy usage I lose an interrupt once in a
> while, but this might be due to irqpoll.
>
> The other issue is that the graphics card still only initialises under X, and
> still very slowly.
>
> Looking at mptable.c I get the impression it was copied almost verbatim from
> another board and not adopted to the M57SLI. Yinghai, where did you get the
> routing info from?

these are all belonging to MCP internal devices esp pcie.

when set the pci irq routing in pci conf space carefully, the mptable
entry could be computed via some simple equation.

YH

[Torsten Duwe]

On Tuesday 06 November 2007, yhlu wrote:
> On 11/5/07, Torsten Duwe  wrote:
> > Yinghai, where did you
> > get the routing info from?
>
> these are all belonging to MCP internal devices esp pcie.

Documented where?
> when set the pci irq routing in pci conf space carefully, the mptable
> entry could be computed via some simple equation.

Which did not match my hardware. Can you tell us how the setup is done?

Torsten