skge dysfunction on Amd X2 machine with 4GB memory

skge dysfunction on Amd X2 machine with 4GB memory

[Matti Aarnio]

With the skge driver there seems to be some sort of problem to
work in a system with memory above the 4 GB of PCI address space.

System doesn't crash (not outright anyway) with skge, but that
network interface just doesn't function.

My box has also  forcedeth  network interface, which works just fine.

Running kernel is:  2.6.20-1.2922.fc7

This system board had previously buggy bios that prevented the
functioning with more than around 3GB memory at all.  Now things
do work, and "Rev.E memory hoist" kicks 1280 MB of memory above
the 4 GB mark.

Without the previously dysfunctioning "4GB memory or more" the
same kernel and drivers worked just fine.  Indeed the  skge was
my eth0.

Any ideas ?

  /Matti Aarnio

Re: skge dysfunction on Amd X2 machine with 4GB memory

[Chris Wedgwood]

On Sun, Feb 11, 2007 at 04:57:55PM +0200, Matti Aarnio wrote:

> With the skge driver there seems to be some sort of problem to work
> in a system with memory above the 4 GB of PCI address space.

The chipset (apparently) doesn't deal with bus addresses over 4GB even
though the MAC does.

I guess the right way to fix this long term is to detect systems with
these chips and mask the dma_mask globally (or if you're clever per
bus)?

Re: skge dysfunction on Amd X2 machine with 4GB memory

[Stephen Hemminger]

On Mon, 19 Feb 2007 23:15:02 -0800
Chris Wedgwood <cw@f00f.org> wrote:

> On Sun, Feb 11, 2007 at 04:57:55PM +0200, Matti Aarnio wrote:
> 
> > With the skge driver there seems to be some sort of problem to work
> > in a system with memory above the 4 GB of PCI address space.
> 
> The chipset (apparently) doesn't deal with bus addresses over 4GB even
> though the MAC does.
> 
> I guess the right way to fix this long term is to detect systems with
> these chips and mask the dma_mask globally (or if you're clever per
> bus)?


This needs to be done in via PCI quirks blacklisting. The driver has no
real way to test it.

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: skge dysfunction on Amd X2 machine with 4GB memory

[Matti Aarnio]

On Mon, Feb 19, 2007 at 11:15:02PM -0800, Chris Wedgwood wrote:
> On Sun, Feb 11, 2007 at 04:57:55PM +0200, Matti Aarnio wrote:
> > With the skge driver there seems to be some sort of problem to work
> > in a system with memory above the 4 GB of PCI address space.
> 
> The chipset (apparently) doesn't deal with bus addresses over 4GB even
> though the MAC does.

Would NVidia made such a mistake at nForce4 ?

The system is ASUS board (A8N-*) for AMD Athlon X2 with NVidia nForce4
chipset, which (I am sure I did mention it) should be apparent from
"forcedeth" ethernet driver.

That one is working just fine with its "HIGHDMA" mode.

Peeking deeper into system hardware:

 # dmesg|grep forcedeth
 forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.59.
 forcedeth: using HIGHDMA
 eth0: forcedeth.c: subsystem: 01043:8141 bound to 0000:00:0a.0
 # dmesg|grep skge
 skge 1.9 addr 0xc9008000 irq 17 chip Yukon-Lite rev 9


forcedeth:

  00:0a.0 0680: 10de:0057 (rev f3)
        Subsystem: 1043:8141
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20
        Memory at ca100000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at d000 [size=8]
        Capabilities: [44] Power Management version 2

skge:

  05:0c.0 0200: 11ab:4320 (rev 13)
        Subsystem: 1043:811a
        Flags: 66MHz, medium devsel, IRQ 17
        Memory at c9008000 (32-bit, non-prefetchable) [size=16K]
        I/O ports at c400 [size=256]
        Expansion ROM at ca020000 [disabled] [size=128K]
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Vital Product Data


Hmm..  The skge is on bus #5, which is behind bridge:

  00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev f2) (prog-if 01 [Subtractive decode])
        Flags: bus master, 66MHz, fast devsel, latency 0
        Bus: primary=00, secondary=05, subordinate=05, sec-latency=128
        I/O behind bridge: 0000b000-0000cfff
        Memory behind bridge: c8000000-c9ffffff
        Prefetchable memory behind bridge: ca000000-ca0fffff



> I guess the right way to fix this long term is to detect systems with
> these chips and mask the dma_mask globally (or if you're clever per
> bus)?


I don't have any DAC capable PCI cards to see if the bus #5 is unable to pass
DACs to primary bus and to Athlon's memory controller.

The bus #5 has following devices:

 05:06.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 IEEE-1394 Controller
 05:08.0 Multimedia video controller: Brooktree Corporation Bt848 Video Capture (rev 12)
 05:0a.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)
 05:0b.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link)
 05:0c.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)

Numbers 6 and 8 are plugin cards, and they don't use DACs.
I don't think that SiI 3114 or TI TSB43AB22A are using DACs either.

/Matti Aarnio