What about module option?
That would work, though you crossed in the post with me writing a patch
adding a sysfs file; I merged the two for overkill (below). I also have
a patch which changes the log message for the workaround so that it is
displayed by default in order to make this easier
[...]
With code commented out I have 1 error / 3 transmitted packets from
DP83815C. I have 1 error / 10 transmitted packets to DP83815C. Maybe
it works at all because I have short cable, only 10m long.
I don't remember any errors with plain 2.6.21.1.
Sorry. I mean transmition errors,
On 5/1/07, Rafal Bilski [EMAIL PROTECTED] wrote:
2.6.21.1 is first kernel which I'm using at this device. Earlier it was
WindowsCE terminal. It is hardware fault. Commenting out the code is my
way to avoid wakeup messages in log, but I don't want to change anything
in vanilla kernel. I'm lucky
On Tue, May 01, 2007 at 11:51:41PM -0700, Tim Hockin wrote:
I'm not sure what the right answer is. The code was designed to do
the right thing, and yet in your case it's broken. Does it need to be
a build option to work around broken hardware? Yuck.
Without a system that really needs the
On Wed, May 02, 2007 at 10:05:31PM +0200, Rafał Bilski wrote:
What about module option?
That would work, though you crossed in the post with me writing a patch
adding a sysfs file; I merged the two for overkill (below). I also have
a patch which changes the log message for the workaround so
On Tue, 01 May 2007 10:23:38 +0200 Rafał Bilski [EMAIL PROTECTED] wrote:
Hello again,
I have downloaded DP83815 datasheet and I see that
eth0: Wake-up event 0x20a
means broadcast received and wakup on broadcast and
unicast enabled.
eth0: Wake-up event 0x8a
Above means unicast
On Mon, Apr 30, 2007 at 08:55:22PM -0700, Andrew Morton wrote:
On Mon, 30 Apr 2007 22:58:47 +0200 Rafał Bilski [EMAIL PROTECTED] wrote:
ezri user.info kernel: eth0: DSPCFG accepted after 0 usec.
ezri user.notice kernel: eth0: Wake-up event 0x8a
ezri user.info kernel: eth0: Setting
[...]
Could you please run ethtool -s eth0 msglvl 0x to turn logging
from the driver right up and send a log? This will spam the log if
there is any traffic but should say why the driver is doing this.
OK. Here it is. It is from 2.6.21.1 with Andrew patch applied. I had to
disable
On Tue, May 01, 2007 at 12:25:20PM +0200, Rafał Bilski wrote:
eth0: Media selection timer tick.
eth0: possible phy reset: re-initializing
This is why the reset is being triggered - it's a workaround for a hardware
bug which checks to make sure the hardware is in the state that the
kernel
eth0: Media selection timer tick.
eth0: possible phy reset: re-initializing
This is why the reset is being triggered - it's a workaround for a hardware
bug which checks to make sure the hardware is in the state that the
kernel thinks it is is going off. The code has this explanatory
eth0: Media selection timer tick.
eth0: possible phy reset: re-initializing
This is why the reset is being triggered - it's a workaround for a hardware
bug which checks to make sure the hardware is in the state that the
kernel thinks it is is going off. The code has this explanatory
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
* 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).
*
On Mon, 30 Apr 2007 22:58:47 +0200 Rafał Bilski [EMAIL PROTECTED] wrote:
Hello,
I have Wyse 3360SE terminal running Linux 2.6.21-rc7. Everything
works great with one small exception. Natsemi DP83815 driver is
filling log with:
ezri user.info kernel: eth0: DSPCFG accepted after 0 usec.
14 matches
Mail list logo
