On Fri, Feb 01, 2019 at 07:24:01PM +0100, Heiner Kallweit wrote:
> It's too much effort to make the current r8169 compile under an older kernel.
> But thanks anyway for trying!
Will the patch be in 5.0-rc5?
Greetings
Marc
--
--
It's too much effort to make the current r8169 compile under an older kernel.
But thanks anyway for trying!
Heiner
On 01.02.2019 18:19, Marc Haber wrote:
> On Fri, Feb 01, 2019 at 07:49:09AM +0100, Heiner Kallweit wrote:
>> Great, thanks. This patch has been applied and is part of latest linux-n
On Fri, Feb 01, 2019 at 07:49:09AM +0100, Heiner Kallweit wrote:
> Great, thanks. This patch has been applied and is part of latest linux-next
> kernel already:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/?h=next-20190201
> Would be much appreciated if you could buil
Great, thanks. This patch has been applied and is part of latest linux-next
kernel already:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/?h=next-20190201
Would be much appreciated if you could build and test this kernel version.
Heiner
On 30.01.2019 16:37, Marc Haber
On Tue, Jan 29, 2019 at 10:20:48PM +0100, Heiner Kallweit wrote:
> one more attempt, could you please test the following with 4.19 or 4.20
> (w/o the other debug patches) ?
With the following patch, the machine wakes up fine on a WoL magic
packet:
nux-4.20.5/drivers/net/ethernet/realtek/r8169.c
On Tue, Jan 29, 2019 at 08:01:14PM +0100, Heiner Kallweit wrote:
> the change to replace __rtl8169_set_wol(tp, 0) doesn't seem to be the right
> commit
> because it was included in 4.18 already. And if you read the commit
> description you'll
> see that it was replaced because it caused issues wi
Hi Marc,
one more attempt, could you please test the following with 4.19 or 4.20
(w/o the other debug patches) ?
Rgds, Heiner
---
drivers/net/ethernet/realtek/r8169.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/
Hi Marc,
the change to replace __rtl8169_set_wol(tp, 0) doesn't seem to be the right
commit
because it was included in 4.18 already. And if you read the commit description
you'll
see that it was replaced because it caused issues with certain boards. Having
said that
it's not an option for us.
Hi,
after having a good night's sleep over that, it's obviously a merge
commit which cannot easily be reverted. How would I continue after
identifying a merge commit as the culprit?
On Tue, Jan 29, 2019 at 08:32:53AM +0100, Marc Haber wrote:
> According to bisect, the first bad commit is
> 197254
On Mon, Jan 28, 2019 at 10:21:50PM +0100, Heiner Kallweit wrote:
> And I wonder why the following didn't work for you, you said it makes
> no difference. Could you try again the following in addition to the
> latest debug output statement?
This time it says
Jan 29 12:34:59 fan kernel: [ 141.39730
On Mon, Jan 28, 2019 at 09:28:13PM +0100, Heiner Kallweit wrote:
> Because we're interested in file r8169.c only, you could test r8169.c
> from the oops-ing kernel on top of a working kernel version.
That's a really nice idea, and so obvious once one thinks about it.
According to bisect, the firs
On 28.01.2019 21:59, Marc Haber wrote:
> On Mon, Jan 28, 2019 at 08:02:47PM +0100, Heiner Kallweit wrote:
>> One more test .. Can you provide the output of the following under 4.18 and
>> under 4.19?
>> It may not apply cleanly, but you get the idea. The message is written when
>> suspending.
>
On Mon, Jan 28, 2019 at 08:02:47PM +0100, Heiner Kallweit wrote:
> One more test .. Can you provide the output of the following under 4.18 and
> under 4.19?
> It may not apply cleanly, but you get the idea. The message is written when
> suspending.
I booted, suspeneded, sent a magic packet that
On 28.01.2019 21:22, Marc Haber wrote:
> On Mon, Jan 28, 2019 at 08:30:10AM +0100, Marc Haber wrote:
>> On Sun, Jan 27, 2019 at 10:09:51PM +0100, Heiner Kallweit wrote:
>>> Yes. All you have to do after each "git bisect good/bad" is build again,
>>> test, and make current build as good or bad.
>>
>
On Mon, Jan 28, 2019 at 08:30:10AM +0100, Marc Haber wrote:
> On Sun, Jan 27, 2019 at 10:09:51PM +0100, Heiner Kallweit wrote:
> > Yes. All you have to do after each "git bisect good/bad" is build again,
> > test, and make current build as good or bad.
>
> Will report back if I get any results. Wh
On 28.01.2019 08:30, Marc Haber wrote:
> On Sun, Jan 27, 2019 at 10:09:51PM +0100, Heiner Kallweit wrote:
>> Yes. All you have to do after each "git bisect good/bad" is build again,
>> test, and make current build as good or bad.
>
> Will report back if I get any results. When I bisected last time
On Sun, Jan 27, 2019 at 10:09:51PM +0100, Heiner Kallweit wrote:
> Yes. All you have to do after each "git bisect good/bad" is build again,
> test, and make current build as good or bad.
Will report back if I get any results. When I bisected last time, I
ended up with a kernel that didn't even boo
On 27.01.2019 21:55, Marc Haber wrote:
> On Sat, Jan 26, 2019 at 08:22:33PM +0100, Heiner Kallweit wrote:
>> You could go with this range:
>> from 4ff364662814 ("r8169: replace get_protocol with vlan_get_protocol")
>> to 649f0837a8cc ("r8169: fix broken Wake-on-LAN from S5 (poweroff)")
>
> I am qu
On Sat, Jan 26, 2019 at 08:22:33PM +0100, Heiner Kallweit wrote:
> You could go with this range:
> from 4ff364662814 ("r8169: replace get_protocol with vlan_get_protocol")
> to 649f0837a8cc ("r8169: fix broken Wake-on-LAN from S5 (poweroff)")
I am quite inexperienced with bisecting and am therefor
On 26.01.2019 18:07, Marc Haber wrote:
> On Sat, Jan 26, 2019 at 03:04:34PM +0100, Heiner Kallweit wrote:
>> Thanks for testing. Then the only way to find the offending commit is
>> bisecting.
>
> :-(
>
> Bisecting between which tags?
>
You could go with this range:
from 4ff364662814 ("r8169:
On Sat, Jan 26, 2019 at 03:04:34PM +0100, Heiner Kallweit wrote:
> Thanks for testing. Then the only way to find the offending commit is
> bisecting.
:-(
Bisecting between which tags?
Greetings
Ma "at least this issue is readily reproducible" rc
--
On 26.01.2019 15:08, Heiner Kallweit wrote:
> On 13.01.2019 17:01, Marc Haber wrote:
>> On Sat, Jan 12, 2019 at 09:28:48PM +0100, Heiner Kallweit wrote:
>>> On 12.01.2019 21:08, Marc Haber wrote:
I am writing to all people who have commits in r8169.c between the v4.18
and v4.19 tags in th
On 13.01.2019 17:01, Marc Haber wrote:
> On Sat, Jan 12, 2019 at 09:28:48PM +0100, Heiner Kallweit wrote:
>> On 12.01.2019 21:08, Marc Haber wrote:
>>> I am writing to all people who have commits in r8169.c between the v4.18
>>> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
>
On 26.01.2019 14:56, Marc Haber wrote:
> On Fri, Jan 25, 2019 at 07:22:36PM +0100, Heiner Kallweit wrote:
>> Then I'm slowly running out of ideas. New in 4.19 is a check for invalid
>> WoL flags, but usually the caller should warn if -EINVAL is returned.
>> Nevertheless, could you try the following
On Fri, Jan 25, 2019 at 07:22:36PM +0100, Heiner Kallweit wrote:
> Then I'm slowly running out of ideas. New in 4.19 is a check for invalid
> WoL flags, but usually the caller should warn if -EINVAL is returned.
> Nevertheless, could you try the following and check whether the warning
> is triggere
On 25.01.2019 13:02, Marc Haber wrote:
> On Fri, Jan 25, 2019 at 07:49:56AM +0100, Heiner Kallweit wrote:
>> thanks a lot for the detailed analysis. That this ethtool sequence
>>
>> ethtool -s wol d
>> ethtool -s wol g
>>
>> helps makes me think that the following patch should help too.
>> Could
On Fri, Jan 25, 2019 at 07:49:56AM +0100, Heiner Kallweit wrote:
> thanks a lot for the detailed analysis. That this ethtool sequence
>
> ethtool -s wol d
> ethtool -s wol g
>
> helps makes me think that the following patch should help too.
> Could you please test?
That patch didn't apply clea
Hi Marc,
thanks a lot for the detailed analysis. That this ethtool sequence
ethtool -s wol d
ethtool -s wol g
helps makes me think that the following patch should help too.
Could you please test?
There's an old story why this call is missing. Certain notebooks immediately
woke up again if WoL
Hi Heiner,
On Tue, Jan 22, 2019 at 07:47:45PM +0100, Heiner Kallweit wrote:
> Which version of 4.18 are you running that is ok? To check the code ..
I pull over drivers/net/ethernet/realtek/r8169.c from an unpacked
4.18.16 source tree. It sets RTL8169_VERSION "2.3LK-NAPI". The last
commit in this
On 22.01.2019 17:10, Marc Haber wrote:
> On Sun, Jan 13, 2019 at 05:19:41PM +0100, Heiner Kallweit wrote:
>> I assume you want to wake the system from S5 (poweroff).
>
> No. The machine is almost never completely powered down.
>
>> Does is wake from S3 (suspend-to-RAM) ? You can trigger this with
On Sun, Jan 13, 2019 at 05:19:41PM +0100, Heiner Kallweit wrote:
> I assume you want to wake the system from S5 (poweroff).
No. The machine is almost never completely powered down.
> Does is wake from S3 (suspend-to-RAM) ? You can trigger this with
> "systemctl suspend".
That's what I am doing,
On 13.01.2019 17:01, Marc Haber wrote:
> On Sat, Jan 12, 2019 at 09:28:48PM +0100, Heiner Kallweit wrote:
>> On 12.01.2019 21:08, Marc Haber wrote:
>>> I am writing to all people who have commits in r8169.c between the v4.18
>>> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
>
Hi,
I am writing to all people who have commits in r8169.c between the v4.18
and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
you'd prefer that to be on a mailing list, please indicate on which list
you want to have that, and I'll resend.
My desktop copmuter has the following
On Sat, Jan 12, 2019 at 09:28:48PM +0100, Heiner Kallweit wrote:
> On 12.01.2019 21:08, Marc Haber wrote:
> > I am writing to all people who have commits in r8169.c between the v4.18
> > and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
> > you'd prefer that to be on a mailing li
On 12.01.2019 21:28, Heiner Kallweit wrote:
> On 12.01.2019 21:08, Marc Haber wrote:
>> Hi,
>>
>> I am writing to all people who have commits in r8169.c between the v4.18
>> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
>> you'd prefer that to be on a mailing list, please ind
On 12.01.2019 21:08, Marc Haber wrote:
> Hi,
>
> I am writing to all people who have commits in r8169.c between the v4.18
> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
> you'd prefer that to be on a mailing list, please indicate on which list
> you want to have that, and I
36 matches
Mail list logo
