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]
Message-ID: <20061125160220.GA13480@electric-eye.fr.zoreil.com>
Date:	Sat, 25 Nov 2006 17:02:20 +0100
From:	Francois Romieu <romieu@...zoreil.com>
To:	Martin Michlmayr <tbm@...ius.com>
Cc:	Lennert Buytenhek <buytenh@...tstofly.org>,
	Riku Voipio <riku.voipio@....fi>, linux-kernel@...r.kernel.org
Subject: Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

Martin Michlmayr <tbm@...ius.com> :
[...]
> Do you think there'll be a better fix in the future ?

It's the best trade-off that I can figure but there are surely more
knowledgeable people than me. The patch does not completely disable
the reporting of serious PCI errors. If the user knows that it is
otherwise safe, he can disable it: the error will then be reported
only once. I must confess that the history of the 8169 PCI errors is
not crystal clear.

> Do you believe that the boot loader on the N2100 doesn't
> initialize Ethernet properly or that this is a generic problem on iop
> or with this particular RTL chip?  We have fairly good contacts with
> the company producing the N2100 so if it's the former it could
> probably be fixed. (Altough I'm not sure this is the case given that
> Realtek's driver works).

Yes, switching from MM register accesses has been reported to fix/hide
the issue but it's a sledgehammer which does not tell what is going on
(side note: Realtek's driver does not enable the SYSErr irq).

So far I can only tell that 1) the 8169 reports a data parity error on
almost each received packet when it is not silenced 2) the error can
be ignored. If there really is an error and the chipset automatically
retries the transaction, one should expect some loss of efficiency but
it will not necessarily be easy to notice through software.

If I had unlimited resources/time/$$$, I would plug a PCI bus analyzer
and check what is going on. :o)

-- 
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ