linux-kernel - Re: Realtek 8168D: no active link (2.6.29.2)

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: <200905180017.n4I0HFjV020018@turbo.physics.adelaide.edu.au>
Date:	Mon, 18 May 2009 09:47:15 +0930 (CST)
From:	Jonathan Woithe <jwoithe@...sics.adelaide.edu.au>
To:	romieu@...zoreil.com (Francois Romieu)
Cc:	jwoithe@...sics.adelaide.edu.au (Jonathan Woithe),
	dave@...dillows.org (David Dillow), linux-kernel@...r.kernel.org,
	edward_hsu@...ltek.com.tw (Edward Hsu)
Subject: Re: Realtek 8168D: no active link (2.6.29.2)

> Jonathan Woithe <jwoithe@...sics.adelaide.edu.au> :
> [...]
> > Indeed.  To follow up on this, as per my earlier email I left the machine
> > disconnected from the mains all night - so it was truly "off" for about 9
> > hours.  Just before coming to work I flicked it on and the "link" LED lit
> > almost immediately.  So whatever the Realtek driver did, the resulting
> > status would appear to be stored in some kind of non-volatile memory.  While
> > it would appear that this has worked around the problem for me, it would be
> > nice if the mainline driver could do this itself.
> 
> The attached patch is not complete but can you give it a try and check if
> it makes a difference ?

Will do.  Given that at present the chip appears to be bringing up the link
more or less as soon as it's powered up (having run the Realtek's driver
once last week), what behavioural changes should I see?  The patch appears
to change the initialisation sequence which may bring the link to life
without having to run the driver from Realtek.  It doesn't appear to change
the shutdown behaviour though, so presumedly the link status in the PHY will
remain.  Since my chip is already set to have a live link (and that this is
persistent across power cycles), what changes might I look out for?

Regards
  jonathan
--
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/