On Tue, May 01, 2007 at 09:52:30PM +0200, Rafał Bilski wrote: > > * 2) check for sudden death of the NIC: > > * It seems that a reference set for this chip went out with incorrect info, > > * and there exist boards that aren't quite right. An unexpected voltage > > * drop can cause the PHY to get itself in a weird state (basically reset). > > * NOTE: this only seems to affect revC chips. > Code commented out and NIC is working OK. Strange. > eth0: DSPCFG accepted after 0 usec. > eth0: link up. > eth0: Setting full-duplex based on negotiated link capability. > dspcfg = 0x00000000 np->dspcfg = 0x00005060 Oh, that's entertaining. I have to confess that I've never seen an that triggered the workaround before - adding the maintainer, Tim Hockin, who may be able to shed some light on the expected behaviour here? -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Attachment:
signature.asc
Description: Digital signature
- References:
- Natsemi DP83815 driver spaming
- From: Rafał Bilski <[email protected]>
- Re: Natsemi DP83815 driver spaming
- From: Andrew Morton <[email protected]>
- Re: Natsemi DP83815 driver spaming
- From: Mark Brown <[email protected]>
- Re: Natsemi DP83815 driver spaming
- From: Rafał Bilski <[email protected]>
- Re: Natsemi DP83815 driver spaming
- From: Mark Brown <[email protected]>
- Re: Natsemi DP83815 driver spaming
- From: Rafał Bilski <[email protected]>
- Natsemi DP83815 driver spaming
- Prev by Date: [PATCH] doc: fix oops-tracing duplicate
- Next by Date: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
- Previous by thread: Re: Natsemi DP83815 driver spaming
- Next by thread: Re: Natsemi DP83815 driver spaming
- Index(es):