linux-kernel - Re: r8169 MAC addresses broken

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: <200810260055.59783.alistair@devzero.co.uk>
Date:	Sun, 26 Oct 2008 00:55:59 +0100
From:	Alistair John Strachan <alistair@...zero.co.uk>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	Jiri Slaby <jirislaby@...il.com>, Simon Arlott <simon@...e.lp0.eu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>,
	Edward Hsu <edward_hsu@...ltek.com.tw>,
	Ivan Vecera <ivecera@...hat.com>
Subject: Re: r8169 MAC addresses broken

On Saturday 25 October 2008 23:34:43 Francois Romieu wrote:
> Jiri Slaby <jirislaby@...il.com> :
> [...]
>
> > Ah, I thought I have broken hardware. I have similar problem, my mac is
> > initially all zeroes. When I set it up, it works until suspend. After
> > that I need to unbind the driver, bind it again, and it works then (mac
> > is still the set one).
> >
> > I'm out of the notebook right now, but it is 10ec:8168:
> > 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> > RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
> > 	Subsystem: ASUSTeK Computer Inc. Unknown device 11f5
> >
> > I used it perfectly far later than 2.6.24 (maybe 2.6.26?), 2.6.27 is yet
> > defunct.
>
> 2.6.27 proper ? That's bad news.

Just thought I'd chime in to report the same thing. I don't use the NICs very
frequently, so I didn't notice until I read the report.

On this machine, the NICs are never put through a suspend/resume cycle, so
that doesn't seem to be anything to do with it.

The NICs should have incremental MAC addresses, since they're mainboard
devices. Put it this way, they used to.

Now when they're detected, one has the correct MAC, and the second has the
first 32bits of its MAC corrupted.

eth0: RTL8169sc/8110sc at 0xffffc2000001e000, 00:50:8d:b3:5f:de, XID 18000000 IRQ 23                                                          
eth1: RTL8169sc/8110sc at 0xffffc20000070000, d8:81:ec:10:5f:df, XID 18000000 IRQ 22

d8:81:ec:10 is corruption; 00:50:8d:b3 is correct.

I can bisect pretty easily if this is helpful.

-- 
Cheers,
Alistair.
--
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/