while compiling a new kernel with "nice make -j3"...
login: panic: pool_do_get: dwc2qtd free list modified: page
0x98041cf7; item addr 0x98041cf70018; offset 0x0=0xadbeef
Stopped at 0x812c0ddc: jr ra
0x812c0de0: nop
TIDPIDUID PRFLAGS
Hi,
i have a server at the german hosting provider Hetzner. They provide
IPv6. You get a /64 assigned for your host. The problem is, that IPv6
doesn't work right after a reboot, but you have to ping the gateway
first and after that, everything works as expected. For that i have a
line in roots cro
On 2017/06/22 14:13, Marc Peters wrote:
> Hi,
>
> i have a server at the german hosting provider Hetzner. They provide
> IPv6. You get a /64 assigned for your host. The problem is, that IPv6
> doesn't work right after a reboot, but you have to ping the gateway
> first and after that, everything wo
Am 06/22/17 um 15:30 schrieb Stuart Henderson:
>
> How are your PF rules? Do they allow NDP packets to pass? If you're
> unsure, I would try "pass log inet6 proto icmp6" or similar.
>
> (this might be a bit of a surprise if used to IPv4 where address
> resolution is done by a separate protocol th
On Thu, Jun 22, 2017 at 02:24:46PM +0200, Janne Johansson wrote:
> while compiling a new kernel with "nice make -j3"...
>
>
> login: panic: pool_do_get: dwc2qtd free list modified: page
> 0x98041cf7; item addr 0x98041cf70018; offset 0x0=0xadbeef
This should be fixed by a patch that I
On 2017/06/22 16:05, Marc Peters wrote:
> Am 06/22/17 um 15:30 schrieb Stuart Henderson:
> >
> > How are your PF rules? Do they allow NDP packets to pass? If you're
> > unsure, I would try "pass log inet6 proto icmp6" or similar.
> >
> > (this might be a bit of a surprise if used to IPv4 where ad
On Thu, Jun 22, 2017 at 04:05:27PM +0200, Marc Peters wrote:
> Is there any way for us to fix it or is it just a misconfiguration at
> Hetzner?
It might help to look at what is actually going over the wire
while pings are stuck: tcpdump -n -i em0 ip6
Hi,
Ingo Schwarze wrote on Thu, Jun 22, 2017 at 03:13:36AM +0200:
> Ted Unangst wrote on Wed, Jun 21, 2017 at 08:48:48PM -0400:
>> Instead, I suggest shifting the names by one. Leave -W style
>> as the portable option, but introduce -W openbsd which performs
>> the additional checks.
> That's a
Yes. If You send link to binary
On June 22, 2017 11:27:21 AM GMT+05:00, YASUOKA Masahiko
wrote:
>Hi,
>
>On Fri, 16 Jun 2017 09:29:50 +0500
>"dmitry.sensei" wrote:
>> FrameBufferBase = 0xc000
>> FrameBufferSize = 0x4000
>> VerticalResolution = 768
>> HorizontalResolution = 1366
>> Pixel
Am 06/22/17 um 16:49 schrieb Stuart Henderson:
> On 2017/06/22 16:05, Marc Peters wrote:
>> Am 06/22/17 um 15:30 schrieb Stuart Henderson:
>>>
>>> How are your PF rules? Do they allow NDP packets to pass? If you're
>>> unsure, I would try "pass log inet6 proto icmp6" or similar.
>>>
>>> (this might
Am 06/22/17 um 16:51 schrieb Stefan Sperling:
> On Thu, Jun 22, 2017 at 04:05:27PM +0200, Marc Peters wrote:
>> Is there any way for us to fix it or is it just a misconfiguration at
>> Hetzner?
>
> It might help to look at what is actually going over the wire
> while pings are stuck: tcpdump -n -i
n 06/21/17 12:16, Ricardo Mestre wrote:
> Hi,
>
> I can confirm this issue, and the diff below seems to solve it for me.
>
> Could you please test it and let us know if it works on your side?
It does fix the issue. Thanks you.
>
> Reason: In clientloop.c during client_loop() this function call
Hi,
I will try to get it done tonight (CEST).
I will let you know once it's done.
On 06/22/2017 08:27 AM, YASUOKA Masahiko wrote:
> Can you test the diff for the kernel?
Thanks,
The diff doesn't seem to fix the problem.
I think horizontal resolution 1366 is the key of the problem and efifb
need a workaround for it.
On Thu, 22 Jun 2017 23:14:47 +0200
Lukasz Jendrysik wrote:
> Okay, so I finally have a while to test your diff.
> Unfortunately the issue still pers
Grégoire Jadi writes:
> n 06/21/17 12:16, Ricardo Mestre wrote:
>> Hi,
>>
>> I can confirm this issue, and the diff below seems to solve it for me.
>>
>> Could you please test it and let us know if it works on your side?
>
> It does fix the issue. Thanks you.
>
>>
>> Reason: In clientloop.c du
Okay, so I finally have a while to test your diff.
Unfortunately the issue still persists, but dmesg output is different
now especially when it comes to efifb.
dmesgNative:efifb0 at mainbus0: 1366x768, 32bpp
dmesgNative:wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation),
using wskbd0
dmesg
16 matches
Mail list logo
