On 18/02/18 22:43, Hauke Mehrtens wrote:
The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
on the target. All targets that are *not* on either kernel 4.9 or 4.14
will not be included in the next release.
I did some overview of the kernel version some months ago here:
http:
It's fixed by
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.9.y&id=83946c33b9b99b5bc6157cfbf3970265f006c2bf
Best Regards,
Syrone Wong
On Mon, Feb 19, 2018 at 4:46 AM, Stijn Segers wrote:
> CONFIG_X86_VSYSCALL_EMULATION is disabled by default on x86/6
On 02/18/2018 10:21 PM, edgar.sol...@web.de wrote:
On 2/18/2018 21:26, Philip Prindeville wrote:
On Feb 18, 2018, at 11:25 AM, Philip Prindeville
wrote:
On Feb 18, 2018, at 2:27 AM, John Crispin wrote:
On 20/06/17 19:13, Stefan Tomanek wrote:
While sshd should be favoured over telne
On 02/18/2018 11:21 PM, Andrey Jr. Melnikov wrote:
> Fix this patch before release. Or drop it if no one has seen this damage and
> does not complain.
Hi Andrey,
What is the problem with this patch?
Hauke
>
>> Hauke Mehrtens wrote:
>>> This modifies the patches in a way that they will apply
The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
on the target. All targets that are *not* on either kernel 4.9 or 4.14
will not be included in the next release.
I did some overview of the kernel version some months ago here:
http://lists.infradead.org/pipermail/lede-dev/2017
On 2/18/2018 21:26, Philip Prindeville wrote:
>
>> On Feb 18, 2018, at 11:25 AM, Philip Prindeville
>> wrote:
>>
>>
>>
>>> On Feb 18, 2018, at 2:27 AM, John Crispin wrote:
>>>
>>>
>>>
On 20/06/17 19:13, Stefan Tomanek wrote:
While sshd should be favoured over telnetd, having a telnet
CONFIG_X86_VSYSCALL_EMULATION is disabled by default on x86/64, but without it
the new KAISER stuff it breaks
kernel 4.4 in the way shown below:
CC arch/x86/mm/kaiser.o
arch/x86/mm/kaiser.c: In function 'kaiser_init':
arch/x86/mm/kaiser.c:348:8: error: 'vsyscall_pgprot' undeclared (first us
This bumps the 4.4. kernel in LEDE 17.01 to 4.4.116.
More Meltdown & Spectre mitigation.
* Refresh patches.
* Refresh x86/config for RETPOLINE.
* Deleted 8049-PCI-layerscape-Add-fsl-ls2085a-pcie-compatible-ID.patch
(accepted upstream)
* Deleted 8050-PCI-layerscape-Fix-MSG-TLP-drop-setting.patch (
This bumps the 4.4. kernel in LEDE 17.01 to 4.4.116.
More Meltdown & Spectre mitigation.
* Refresh patches.
* Refresh x86/config for RETPOLINE.
* Deleted 8049-PCI-layerscape-Add-fsl-ls2085a-pcie-compatible-ID.patch
(accepted upstream)
* Deleted 8050-PCI-layerscape-Fix-MSG-TLP-drop-setting.patch (
CONFIG_X86_VSYSCALL_EMULATION is disabled by default on x86/64, but without it
the new KAISER stuff breaks
in the way shown below:
CC arch/x86/mm/kaiser.o
arch/x86/mm/kaiser.c: In function 'kaiser_init':
arch/x86/mm/kaiser.c:348:8: error: 'vsyscall_pgprot' undeclared (first use in
this fun
> On Feb 18, 2018, at 11:25 AM, Philip Prindeville
> wrote:
>
>
>
>> On Feb 18, 2018, at 2:27 AM, John Crispin wrote:
>>
>>
>>
>>> On 20/06/17 19:13, Stefan Tomanek wrote:
>>> While sshd should be favoured over telnetd, having a telnet client on the
>>> router is useful for connecting to
On 02/18/2018 07:29 PM, Philip Prindeville wrote:
> Why did we even do this to begin with?
That is a good question. ;-)
My assumption is that about 13 years ago uClibc did not provide the
IPPROTO_SCTP define and this is still a workaround for this problem.
I haven't checked the uClibc code.
Commit
Why did we even do this to begin with?
> On Feb 15, 2018, at 3:52 PM, Hauke Mehrtens wrote:
>
> Remove this old patch which prevents showing the xfrm ports for SCTP
>
> This was added in commit 60c1f0f64d23 ("finally move buildroot-ng to trunk")
> ---
> .../network/utils/iproute2/patches/006-n
> On Feb 18, 2018, at 2:27 AM, John Crispin wrote:
>
>
>
>> On 20/06/17 19:13, Stefan Tomanek wrote:
>> While sshd should be favoured over telnetd, having a telnet client on the
>> router is useful for connecting to other devices in the same LAN.
>>
>> Signed-off-by: Stefan Tomanek
>
> sor
On 18/02/18 16:35, Hauke Mehrtens wrote:
On 02/18/2018 12:35 PM, John Crispin wrote:
On 17/02/18 13:30, Hauke Mehrtens wrote:
On 02/15/2018 05:34 PM, Tim Harvey wrote:
Testted on a Gateworks GW54xx. Does not support enabling imx-drm modules
yet as those will need some adjustments based on k
On 02/18/2018 12:35 PM, John Crispin wrote:
>
>
> On 17/02/18 13:30, Hauke Mehrtens wrote:
>> On 02/15/2018 05:34 PM, Tim Harvey wrote:
>>> Testted on a Gateworks GW54xx. Does not support enabling imx-drm modules
>>> yet as those will need some adjustments based on kernel configs.
>>>
>>> v3:
>>>
On 17/02/18 13:30, Hauke Mehrtens wrote:
On 02/15/2018 05:34 PM, Tim Harvey wrote:
Testted on a Gateworks GW54xx. Does not support enabling imx-drm modules
yet as those will need some adjustments based on kernel configs.
v3:
- included missing patch for pcie enumeration fix
v2:
- move dw
On 17/02/18 13:33, Hauke Mehrtens wrote:
On 02/15/2018 05:34 PM, Tim Harvey wrote:
Backport of: http://patchwork.ozlabs.org/patch/860701/
Signed-off-by: Tim Harvey
---
.../generic/pending-4.14/812-pci-dwc-fix-enumeration.patch| 11 +++
1 file changed, 11 insertions(+)
creat
On 20/06/17 19:13, Stefan Tomanek wrote:
While sshd should be favoured over telnetd, having a telnet client on the
router is useful for connecting to other devices in the same LAN.
Signed-off-by: Stefan Tomanek
sorry for the late reply, it has been discussed over and over and the
decision
19 matches
Mail list logo