[LinuxBIOS] GA M57SLI _really_ supported?

[Torsten Duwe]

Hi all,

trying to get my machine into productive use with LinuxBIOSv2 I just found 
major issues with the bridge configuration. The primary PCIe cannot generate 
interrupts, the other PCIe bridges are configured although the slots are 
empty (the legacy BIOS does not do that), and the non-express PCI slots don't 
even seem to exist!

Question: is anyone successfully using any of the slots?

Torsten

[Ward Vandewege]

Hi Torsten,

On Thu, Oct 25, 2007 at 08:12:31PM +0200, Torsten Duwe wrote:
> trying to get my machine into productive use with LinuxBIOSv2 I just found 
> major issues with the bridge configuration. The primary PCIe cannot generate 
> interrupts, the other PCIe bridges are configured although the slots are 
> empty (the legacy BIOS does not do that), and the non-express PCI slots don't 
> even seem to exist!

There are 2 pci slots. We've managed to enable one of them; the patch is not
in the repo yet, but you can find the thread here:

http://www.linuxbios.org/pipermail/linuxbios/2007-September/024688.html

There's a patch there to that enables the pci slot not on the edge of the
board.

I will make work of getting that patch committed, and I want to figure out
how to enable the other slot too, when I find some time.
> Question: is anyone successfully using any of the slots?

I was not aware of PCI-E issues. I am successfully using a PCI-E video card.

Thanks,
Ward.

[Torsten Duwe]

On Thursday 25 October 2007, Ward Vandewege wrote:
> There are 2 pci slots. We've managed to enable one of them; the patch is
> not in the repo yet, but you can find the thread here:
>
> http://www.linuxbios.org/pipermail/linuxbios/2007-September/024688.html
>
> There's a patch there to that enables the pci slot not on the edge of the
> board.

Only one? That's strange. You mean
http://www.linuxbios.org/pipermail/linuxbios/2007-September/024816.html ?
> I was not aware of PCI-E issues. I am successfully using a PCI-E video
> card.

That depends on your definition of succesful. I run an X850 radeon in that 
slot. There's no picture before X is up, and X startup alone takes two 
minutes thirty seconds or so. Glxgears performs at 20% of the possible 
maximum, most probably because I'm not able to get a single interrupt from 
the card. But there is a picture and some acceleration, so you may call that 
succesful.

Which card do you use? Do you see interrupts from it? (make sure 
glxinfo/driinfo says dri: yes and run e.g. glxgears)

Torsten

[Ward Vandewege]

On Fri, Oct 26, 2007 at 12:03:29AM +0200, Torsten Duwe wrote:
> On Thursday 25 October 2007, Ward Vandewege wrote:
> > There are 2 pci slots. We've managed to enable one of them; the patch is
> > not in the repo yet, but you can find the thread here:
> >
> > http://www.linuxbios.org/pipermail/linuxbios/2007-September/024688.html
> >
> > There's a patch there to that enables the pci slot not on the edge of the
> > board.
>
> Only one? That's strange. You mean
> http://www.linuxbios.org/pipermail/linuxbios/2007-September/024816.html ?

No, this is it (the thread continued into this month):

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

I think we can probably get the other one working by fiddling some more with
the registers. I tried the most obvious things but to no avail yet.
> > I was not aware of PCI-E issues. I am successfully using a PCI-E video
> > card.
>
> That depends on your definition of succesful. I run an X850 radeon in that 
> slot. There's no picture before X is up, and X startup alone takes two 
> minutes thirty seconds or so.

I have picture before X is up.

There's a workaround for the slow X startup; add

Option   "NoDDC2"

to your X config, as documented here:

http://linuxbios.org/index.php/GIGABYTE_GA-M57SLI-S4_Build_Tutorial

I have not had time yet to investigate the real cause of this problem.
> Glxgears performs at 20% of the possible 
> maximum, most probably because I'm not able to get a single interrupt from 
> the card. But there is a picture and some acceleration, so you may call that 
> succesful.

... we should fix all this.
> Which card do you use? Do you see interrupts from it? (make sure 
> glxinfo/driinfo says dri: yes and run e.g. glxgears)

It's an nvidia-based card, and I use the free (nv) driver, not the
proprietary nvidia driver. Hence, no acceleration, and hence I have not
experienced those problems. We should fix this though. What version of the
board do you have?

Suggestions on getting the interrupts sorted out?

Thanks,
Ward.

[Torsten Duwe]

On Friday 26 October 2007, Ward Vandewege wrote:
> No, this is it (the thread continued into this month):
>
> http://www.linuxbios.org/pipermail/linuxbios/2007-October/025385.html

Can someone please attach some source code to the term "dumpio"?
The FAQ does not tell anything, nor does the LB source.
> I think we can probably get the other one working by fiddling some more
> with the registers. I tried the most obvious things but to no avail yet.

The same old story. HW manufacturers wire up GPIOs any way they like...
> There's a workaround for the slow X startup; add
>  Option   "NoDDC2"

Will try; maybe it helps radeons, too.
> to your X config, as documented here:
>
> http://linuxbios.org/index.php/GIGABYTE_GA-M57SLI-S4_Build_Tutorial

This has changed quite a bit since I last looked at it early this year. Good 
work!
> It's an nvidia-based card, and I use the free (nv) driver, not the
> proprietary nvidia driver.

Guess why I keep bying X800? Fastest 3D with open source. This one is an 
R480-based X850XT [1002:5d52] by ATI/Sapphire, I guess.
> Suggestions on getting the interrupts sorted out?

The PCI config should be close enough now. Either the board does not generate 
them in the first place, or something near the IO-APIC eats them.

So where's this dumpio?

Torsten

[Carl-Daniel Hailfinger]

On 26.10.2007 16:38, Ward Vandewege wrote:
> On Fri, Oct 26, 2007 at 12:03:29AM +0200, Torsten Duwe wrote:
> > On Thursday 25 October 2007, Ward Vandewege wrote:
> > > There are 2 pci slots. We've managed to enable one of them; the patch is
> > > not in the repo yet, but you can find the thread here:
> > >
> > > http://www.linuxbios.org/pipermail/linuxbios/2007-September/024688.html
> > >
> > > There's a patch there to that enables the pci slot not on the edge of the
> > > board.
> >
> > Only one? That's strange. You mean
> > http://www.linuxbios.org/pipermail/linuxbios/2007-September/024816.html ?
>
> No, this is it (the thread continued into this month):
>
> http://www.linuxbios.org/pipermail/linuxbios/2007-October/025385.html
>
> I think we can probably get the other one working by fiddling some more with
> the registers. I tried the most obvious things but to no avail yet.

Besides that, there are still unexplained differences between vendor
BIOS and LinuxBIOS in the PCI configuration.

http://linuxbios.org/pipermail/linuxbios/2007-May/021538.html and the
followup
http://linuxbios.org/pipermail/linuxbios/2007-June/022299.html

Oh, and here is a nice dmesg diff snippet:

--- dmesg.vendor    2007-10-27 03:11:10.000000000 +0200
+++ dmesg.LB    2007-10-27 03:11:10.000000000 +0200
 PCI: Bridge: 0000:00:06.0
   IO window: disabled.
-  MEM window: fb000000-fb0fffff
+  MEM window: disabled.

Notice the disabled mem window. Fix.

+  PREFETCH window: disabled.
+PCI: Bridge: 0000:00:0a.0
+  IO window: disabled.
+  MEM window: disabled.
+  PREFETCH window: disabled.
+PCI: Bridge: 0000:00:0b.0
+  IO window: disabled.
+  MEM window: disabled.
+  PREFETCH window: disabled.
+PCI: Bridge: 0000:00:0c.0
+  IO window: disabled.
+  MEM window: disabled.
+  PREFETCH window: disabled.
+PCI: Bridge: 0000:00:0d.0
+  IO window: disabled.
+  MEM window: disabled.
+  PREFETCH window: disabled.
+PCI: Bridge: 0000:00:0e.0
+  IO window: disabled.
+  MEM window: disabled.
   PREFETCH window: disabled.

Notice all these added PCI bridges. Fix.

PCI: Bridge: 0000:00:0f.0
-  IO window: 9000-9fff
-  MEM window: f8000000-faffffff
+  IO window: 1000-1fff
+  MEM window: f4000000-f60fffff
   PREFETCH window: e0000000-efffffff
[...]
+mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining
+mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining

Set up MTRRs the right way. Fix.

Once the issues mentioned and linked above are fixed, we may be able to
claim support for the M57SLI.

Oh, and io_dump.c is here:
http://linuxbios.org/pipermail/linuxbios/2007-October/025630.html

Carl-Daniel

[Carl-Daniel Hailfinger]

On 27.10.2007 03:27, Carl-Daniel Hailfinger wrote:
> > Oh, and here is a nice dmesg diff snippet:
> >
> > --- dmesg.vendor    2007-10-27 03:11:10.000000000 +0200
> > +++ dmesg.LB    2007-10-27 03:11:10.000000000 +0200
> PREFETCH window: disabled.
>
> +PCI: Bridge: 0000:00:0a.0
> IO window: disabled.
> MEM window: disabled.
> PREFETCH window: disabled.
>
> +PCI: Bridge: 0000:00:0b.0
> IO window: disabled.
> MEM window: disabled.
> PREFETCH window: disabled.
>
> +PCI: Bridge: 0000:00:0c.0
> IO window: disabled.
> MEM window: disabled.
> PREFETCH window: disabled.
>
> +PCI: Bridge: 0000:00:0d.0
> IO window: disabled.
> MEM window: disabled.
> PREFETCH window: disabled.
>
> +PCI: Bridge: 0000:00:0e.0
> IO window: disabled.
> MEM window: disabled.
> PREFETCH window: disabled.
>
> Notice all these added PCI bridges. Fix.

Try this diff (whitespace-damaged):

Index: src/mainboard/gigabyte/m57sli/Config.lb
===================================================================
--- src/mainboard/gigabyte/m57sli/Config.lb     (Revision 2899)
+++ src/mainboard/gigabyte/m57sli/Config.lb     (Arbeitskopie)
@@ -305,6 +305,7 @@
                                                         device i2c 57 on end
                                                 end 
                                        end # SM
+#wtf?!? we already have device pci 1.1 in the section above
                                         device pci 1.1 on # SM 1
 #PCI device smbus address will depend on addon pci device, do we need to scan_smbus_bus?
 #                                                chip drivers/generic/generic #PCIXA Slot1
@@ -340,11 +341,12 @@
                                        device pci 6.1 on end # AZA
                                        device pci 8.0 on end # NIC
                                        device pci 9.0 off end # NIC
-                                       device pci a.0 on end # PCI E 5
-                                       device pci b.0 on end # PCI E 4
-                                       device pci c.0 on end # PCI E 3
-                                       device pci d.0 on end # PCI E 2
-                                       device pci e.0 on end # PCI E 1
+#hope not mentioning these should be sufficient
+#                                      device pci a.0 on end # PCI E 5
+#                                      device pci b.0 on end # PCI E 4
+#                                      device pci c.0 on end # PCI E 3
+#                                      device pci d.0 on end # PCI E 2
+#                                      device pci e.0 on end # PCI E 1
                                        device pci f.0 on end # PCI E 0
                                        register "ide0_enable" = "1"
                                        register "sata0_enable" = "1"

Someone should read the Config.lb thoroughly and check its internal
consistency and validity.

Carl-Daniel

[Torsten Duwe]

On Saturday 27 October 2007, Carl-Daniel Hailfinger wrote:
> Besides that, there are still unexplained differences between vendor
> BIOS and LinuxBIOS in the PCI configuration.
>
> http://linuxbios.org/pipermail/linuxbios/2007-May/021538.html and the
> followup
> http://linuxbios.org/pipermail/linuxbios/2007-June/022299.html

As you already mentioned, legacy BIOS assigns resources downwards, while LB 
does it upwards. Some other differences might just be consecutive errors from 
the GPIO misconfig.

From my understanding we're talkin plain Linux here, not LinuxBIOS; if there's 
ACPI or the like, the kernel will use the described config. If not, Linux 
will (re-)configure the bridges itself. Bridges that seem to lead nowhere are 
assigned no resources.
> Oh, and here is a nice dmesg diff snippet:
>
> --- dmesg.vendor    2007-10-27 03:11:10.000000000 +0200
> +++ dmesg.LB    2007-10-27 03:11:10.000000000 +0200
>  PCI: Bridge: 0000:00:06.0
>    IO window: disabled.
> MEM window: fb000000-fb0fffff
> MEM window: disabled.
>
> Notice the disabled mem window. Fix.

PCI slots are dead due to the GPIO problem.
BTW firewire lives behind that bridge, too?
> PREFETCH window: disabled.
>
> +PCI: Bridge: 0000:00:0a.0
> IO window: disabled.
> MEM window: disabled.
> PREFETCH window: disabled.
>
> +PCI: Bridge: 0000:00:0b.0
> IO window: disabled.
> MEM window: disabled.
> PREFETCH window: disabled.
>
> +PCI: Bridge: 0000:00:0c.0
> IO window: disabled.
> MEM window: disabled.
> PREFETCH window: disabled.
>
> +PCI: Bridge: 0000:00:0d.0
> IO window: disabled.
> MEM window: disabled.
> PREFETCH window: disabled.
>
> +PCI: Bridge: 0000:00:0e.0
> IO window: disabled.
> MEM window: disabled.
> PREFETCH window: disabled.
>
> Notice all these added PCI bridges. Fix.

These are the PCIe bridges. Do you have any cards in there, besides the 
primary graphics (0000:00:0f.0)? If not: see above.
> PCI: Bridge: 0000:00:0f.0
> IO window: 9000-9fff
> MEM window: f8000000-faffffff
> IO window: 1000-1fff
> MEM window: f4000000-f60fffff
> PREFETCH window: e0000000-efffffff
>
> [...]

Different allocation strategy. Only 
-       [virtual] Expansion ROM at f8000000 [disabled] [size=128K]
+       Expansion ROM at c8000000 [disabled] [size=128K]
on my system worries me.
> +mtrr: type mismatch for e0000000,10000000 old: write-back new:
> write-combining +mtrr: type mismatch for e0000000,10000000 old: write-back
> new: write-combining
>
> Set up MTRRs the right way. Fix.

Indeed!
> Once the issues mentioned and linked above are fixed, we may be able to
> claim support for the M57SLI.

Good to hear I'm not alone :-)
> Oh, and io_dump.c is here:
> http://linuxbios.org/pipermail/linuxbios/2007-October/025630.html

Thanks!
I'll now reboot to get a diff, and test NoDDC2...

Torsten

[Torsten Duwe]

> > Oh, and io_dump.c is here:
> > http://linuxbios.org/pipermail/linuxbios/2007-October/025630.html
>
> Thanks!
> I'll now reboot to get a diff, and test NoDDC2...

Diff attached, s/^ 00002/ 00001/ on the LB dump. That board has both PCI slots 
populated, in case it matters. Also, the base address was 0x1401 and 0x2401, 
respectively; I ignored that bit so far.

NoDDC2 does not mix well with ReverseDDC :-(

Torsten

[Harald Gutmann]

Am Donnerstag, 25. Oktober 2007 20:12:31 schrieb Torsten Duwe:
> Hi all,
>
> trying to get my machine into productive use with LinuxBIOSv2 I just found
> major issues with the bridge configuration. The primary PCIe cannot
> generate interrupts, the other PCIe bridges are configured although the
> slots are empty (the legacy BIOS does not do that), and the non-express PCI
> slots don't even seem to exist!

that problem also exists here.
grapic card works, but just with the nv driver module, because the propritary 
module cannot be used without interrupts.

"(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!"
> Question: is anyone successfully using any of the slots?

using yes, but not really successfully.
> Torsten

Harald