2007-05-02 06:34:31

by Rafał Bilski

[permalink] [raw]
Subject: Re: Natsemi DP83815 driver spaming

[...]
>
>> With code commented out I have 1 error / 30000 transmitted packets from
>> DP83815C. I have 1 error / 100000 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, but of course log was full of "wakeup"
messages.
> Well, I certainly haven't changed anything in there. If the behavior
> has changed in recent kernels, check the rest of the diffs.
>
> Tim

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 that NIC is working at all.

Thank You
Rafa?



----------------------------------------------------------------------
NIE KUPUJ!!!
...zanim nie porownasz cen >> http://link.interia.pl/f1a5e




2007-05-02 06:51:44

by Tim Hockin

[permalink] [raw]
Subject: Re: Natsemi DP83815 driver spaming

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 that NIC is working at all.

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.

2007-05-02 08:22:34

by Mark Brown

[permalink] [raw]
Subject: Re: Natsemi DP83815 driver spaming

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 original problem that was being
worked around it's going to be hard to see if the workaround still does
the job. Given the nature of the failure I wouldn't be surprised if it
broke different things on every board that has problems.

How about a sysfs tuneable? It's not nice but at least it's runtime.

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."


Attachments:
(No filename) (682.00 B)
signature.asc (307.00 B)
Digital signature
Download all attachments