5h later…
login: panic: assertwaitok: non-zero mutex count: 1
Stopped at db_enter+0x10: popq%rbp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
db_enter() at db_enter+0x10
panic(81c882c4) at panic+0x128
assertwaitok() at assertwaitok+0xc7
mi_switch() at
Comitted, Thanks!
Leah Neukirchen(l...@vuxu.org) on 2020.05.20 21:18:09 +0200:
> Leah Neukirchen writes:
>
> >>Synopsis: ksh: failing eval stops execution even when in OR-list
>
> I noticed this issue else appears only in pdksh, but not in mksh.
> Bisecting mksh I found this fixed between
> 1) Broken emulator
> 2) Old broken emulator
>
> A real cpu behaves that way. The capability bits says the feature
> exists, and when it exists, it MUST work.
Yes, I think KVM/QEMU may be malfunction and I found a patch for
QEMU that supports MSR_TSX_CTRL.
Hi everyone,
After a few hours OpenBSD 6.7 crashes to ddb> . Without a LTE modem OpenBSD 6.7
works stable. Huawei E3372s-153 HiLink on OpenBSD 6.6 works perfectly, stable.
Something wrong with USB, xHCI or cdce on OpenBSD 6.7 imho.
ddb{2}> show panic
assertwaitok: non-zero mutex count: 1
> On May 21, 2020, at 7:04 PM, Jonathon Fletcher
> wrote:
>
>
>> On May 21, 2020, at 12:39 AM, Kevin Lo wrote:
>>
>> On Tue, May 19, 2020 at 09:52:57AM -0700, Jonathon Fletcher wrote:
>>>
>>>
Synopsis: ure RTL8153 panics on 6.7 - was stable on 6.6
>>>
Environment:
>>>
Reading that diff, I get a sense they pass on underlying-hardware
cpu flags as-is, and then only write the support code when they feel
like it.
If so, that is ridiculous. They should immediately mask against a list
of KNOWN and CURRENTLY SUPPORTED bits, and not pass on unknown stuff.
SASANO
On Thu, May 21, 2020 at 9:11 AM Stefan Sperling wrote:
> On Thu, May 21, 2020 at 01:04:36AM +0200, stolen data wrote:
>
> ...
>
> > > You can try MCS1, MCS2, ..., all the way up to MCS15.
> >
> > Unfortunately no change. Some are unusable but none of them offer a
> > visible improvement.
>
>
30 min ago… :/
OpenBSD/amd64 (master.bsdxxx.xx) (tty00)
login: panic: assertwaitok: non-zero mutex count: 1
Stopped at db_enter+0x10: popq%rbp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
db_enter() at db_enter+0x10
panic(81c882c4) at panic+0x128
assertwaitok()
> From: Łukasz Lejtkowski
> Date: Fri, 22 May 2020 20:51:57 +0200
>
> Probably power supply 12 V is broken. Showing 16,87 V(Fluke 179) -
> too high. Should be 12,25-12,50 V. I replaced to the new one.
That might be why the device stops responding. The fact that cleaning
up from a failed USB
Probably power supply 12 V is broken. Showing 16,87 V(Fluke 179) - too high.
Should be 12,25-12,50 V. I replaced to the new one.
> On 22 May 2020, at 20:05, Łukasz Lejtkowski wrote:
>
> 30 min ago… :/
>
>
> OpenBSD/amd64 (master.bsdxxx.xx) (tty00)
>
> login: panic: assertwaitok: non-zero
Hi
I upgraded today two openbsd routers with openbgpd from 6.6 -> 6.7. Upgrade
was done using sysupgrade. Router1 and Router2 have two ebgp peers, two
iBGP peers to local switches and one iBGP peer between Router1 <->Router2.
Router2 was first upgraded and no problems there. After Router1
And before anyone asks, I did check eBGP peers that networks in question
did not repeatedly update and withdrew. Update messages between eBGP peers
are nominal.
Br
-Esa
On Sat, May 23, 2020 at 12:47 AM Esa Kuusisto
wrote:
> Hi
>
> I upgraded today two openbsd routers with openbgpd from 6.6 ->
12 matches
Mail list logo
