netdev - Re: [PATCH 15/17] sky2: only disable 88e8056 on some boards

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 May 2007 12:55:38 -0700
From:	Stephen Hemminger <shemminger@...ux-foundation.org>
To:	Florin Malita <fmalita@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH 15/17] sky2: only disable 88e8056 on some boards

On Mon, 14 May 2007 00:53:42 -0400
Florin Malita <fmalita@...il.com> wrote:

> Hi Stephen,
> 
> Stephen Hemminger wrote:
> > Use DMI to add a blacklist of broken board. For now only one is known
> > bad. Gentoo users report driver works on other motherboards (strange). 
> [snip]
> > +               .ident = "Gigabyte 965P-S3",
> > +               .matches = {
> > +                       DMI_MATCH(DMI_SYS_VENDOR, "Gigabyte Technology Co., 
> > Ltd."),
> > +                       DMI_MATCH(DMI_PRODUCT_NAME, "965P-S3"),
> 
> Actually, I've been using sky2 with a 965P-S3 for a couple of months 
> (x86_64 kernel) and as far as I can tell it works like a charm. Recently 
> I had to hack around the blacklisting but other than that I haven't 
> noticed anything strange.
> 
> What failures are you trying to prevent? Would a warning (instead of 
> blacklisting) be acceptable?
> 
> Thanks,
> Florin

What happens on my system is that the chip is accessing some unknown
memory location when it reads the descriptors. This leads to:
  * Transmit descriptor errors because the transmit descriptor doesn't
    have the "Owner" bit set. The list is fine, and all the barriers
    are there it seems like the chip read of memory is getting crap.
  * TSO errors (probably same problem as before)
  * Receive packets with no data. The stack ends up ignoring the 
    garbage; but since we reuse the memory the DMA can/will happen
    later and cause random memory corruption.

Overall it looks like a PCI synchronization problem. Possible differences
between working/non-working are:
  * BIOS, tried up to the latest beta version with no change
  * Memory, switched to name brand DDR2 800 (2G)
  * MSI
  * AHCI/SATA, I am using Raptor with AHCI when booted with i386 on old
    IDE drive saw no problems
 

-
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