Martin Husemann transcribed 430 bytes:
> On Sat, Apr 27, 2019 at 04:18:20PM +, n...@n0.is wrote:
> > It's an T440s, so one module can be exchanged, the other is soldered
> > to the board.
> >
> > I can give exchanging the replacable one a try.
>
> I have had good experience with running
On Sat, Apr 27, 2019 at 04:18:20PM +, n...@n0.is wrote:
> It's an T440s, so one module can be exchanged, the other is soldered
> to the board.
>
> I can give exchanging the replacable one a try.
I have had good experience with running memtest+ from pkgsrc (I had to use
an older binary, newer
On 27 April 2019 7:50:08 PM GMT+05:45, n...@n0.is wrote:
>Ryota Ozaki transcribed 512 bytes:
>> On Mon, Apr 1, 2019 at 6:53 AM wrote:
>> >
>> > Hi,
>> >
>> > would further dmesg outputs from the last 10 or so kernel crashes
>> > still be useful?
>>
>> Yes, and if you have crashdumps, could you
Ryota Ozaki transcribed 512 bytes:
> On Mon, Apr 1, 2019 at 6:53 AM wrote:
> >
> > Hi,
> >
> > would further dmesg outputs from the last 10 or so kernel crashes
> > still be useful?
>
> Yes, and if you have crashdumps, could you please provide detailed
> information from them? (see
On Mon, Apr 1, 2019 at 6:53 AM wrote:
>
> Hi,
>
> would further dmesg outputs from the last 10 or so kernel crashes
> still be useful?
Yes, and if you have crashdumps, could you please provide detailed
information from them? (see https://wiki.netbsd.org/panic/ for the
instructions).
> This
Hi,
would further dmesg outputs from the last 10 or so kernel crashes
still be useful?
This still keeps happening (workaround so far is to use ethernet).
Or maybe I'm looking at the wrong kind of bug and there is something
to track / being worked on already?
n...@n0.is transcribed 452 bytes:
>
m...@netbsd.org transcribed 280 bytes:
> It's not iwm. I have the same bug reported but with re(4) which isn't
> wireless even. the backtrace looks different from ddb.
> from ddb, the failing instruction is,
>
> stopped at pid 276.1 (dhcpcd) at netbsd:npf_ifaddrhook+0x55: movq
> 18(%r12),
It's not iwm. I have the same bug reported but with re(4) which isn't
wireless even. the backtrace looks different from ddb.
from ddb, the failing instruction is,
stopped at pid 276.1 (dhcpcd) at netbsd:npf_ifaddrhook+0x55: movq
18(%r12), %rsi
(without using npf at all)
Hi,
this behavior on an Lenovo Thinkpad started
today after rebuilding the system yesterday.
I'm not sure what else could help, this is
the dmesg from the second kernel crash.
msi5 vec 0
[ 1.053482] ehci0 at pci0 dev 29 function 0: vendor 8086 product 9c26 (rev.
0x04)
[ 1.053482] ehci0:
