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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20070221010630.GA3883@mea-ext.zmailer.org>
Date:	Wed, 21 Feb 2007 03:06:30 +0200
From:	Matti Aarnio <matti.aarnio@...iler.org>
To:	Chris Wedgwood <cw@...f.org>
Cc:	netdev@...r.kernel.org
Subject: Re: skge dysfunction on Amd X2 machine with 4GB memory

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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html