Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
> Does it recover after doing
>
> # ifconfig cdcef0 down
> # ifconfig cdcef0 up
root@master[~]ifconfig cdce0
cdce0: flags=8c03 mtu 1500
lladdr xx:xx:xx:xx:xx:xx
index 30 priority 0 llprio 3
inet 192.168.8.100 netmask 0xff00 broadcast 192.168.8.255
root@master[~]ping 192.168.8.1
PING 192.168.8.1 (192.168.8.1): 56 data bytes
ping: sendmsg: Network is down
ping: wrote 192.168.8.1 64 chars, ret=-1
ping: sendmsg: Network is down
ping: wrote 192.168.8.1 64 chars, ret=-1
ping: sendmsg: Network is down
root@master[~]ifconfig cdce0 down
root@master[~]ifconfig cdce0 up
root@master[~]ping 192.168.8.1
PING 192.168.8.1 (192.168.8.1): 56 data bytes
64 bytes from 192.168.8.1: icmp_seq=0 ttl=64 time=20.804 ms
64 bytes from 192.168.8.1: icmp_seq=1 ttl=64 time=13.976 ms
64 bytes from 192.168.8.1: icmp_seq=2 ttl=64 time=14.468 ms
Probably some good sign for You to next patch?
> On 15 Jun 2020, at 20:09, Gerhard Roth wrote:
>
> On 2020-06-13 01:24, Łukasz Lejtkowski wrote:
>> Good news - no more kernel panics on USB 3.0(xHCI), it’s fixed.
>> Bad news - after 2-3h LTE modem lost local network connection via USB
>> 3.0(cdce0). I have to remove modem and put it back to usb port - then local
>> network connection between OpenBSD and modem back for 2-3h, sometimes 30-40
>> min. It looks like the same problem as kernel panic, but this time there is
>> lost network connection via usb 3.0(xhci).
>> root@master[~]ping 192.168.8.1
>> PING 192.168.8.1 (192.168.8.1): 56 data bytes
>> ping: sendmsg: Network is down
>> ping: wrote 192.168.8.1 64 chars, ret=-1
>> ping: sendmsg: Network is down
>> ping: wrote 192.168.8.1 64 chars, ret=-1
>> 192.168.8.1 is default static IP on lte modem.
>> Your changes in if_cdce.c 1.77 not completely fix the problem.
>
> Hi,
>
> yes, my patch just targeted to fix the panic as a reaction to USB problems;
> not the USB problems themself.
>
> Does it recover after doing
>
> # ifconfig cdcef0 down
> # ifconfig cdcef0 up
>
> Gerhard
>
>>> On 11 Jun 2020, at 11:13, Łukasz Lejtkowski >> <mailto:emig...@gmail.com>> wrote:
>>>
>>> Hi Gerhard,
>>>
>>> Today I added Your patches to 6.7-stable and moved back LTE modem to USB
>>> 3.0. So, just waiting for… nothing or kernel panic. I’ll let you know.
>>>
>>>> On 8 Jun 2020, at 19:13, Patrick Wildt >>> <mailto:patr...@blueri.se>> wrote:
>>>>
>>>> On Mon, Jun 08, 2020 at 05:31:44PM +0200, Gerhard Roth wrote:
>>>>> On 2020-05-25 13:19, Martin Pieuchot wrote:
>>>>>> On 25/05/20(Mon) 12:56, Gerhard Roth wrote:
>>>>>>> On 5/22/20 9:05 PM, Mark Kettenis wrote:
>>>>>>>>> From: Łukasz Lejtkowski mailto:emig...@gmail.com>>
>>>>>>>>> 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 transaction leads to this panic is a bug though.
>>>>>>>>
>>>>>>>> And somebody just posted a very similar panic with ure(4). Something
>>>>>>>> in the network stack is holding a mutex when it shouldn't.
>>>>>>>
>>>>>>> I think that holding the mutex is ok. The bug is calling the stop
>>>>>>> routine in case of errors.
>>>>>>>
>>>>>>> This is what common foo_start() does:
>>>>>>>
>>>>>>> m_head = ifq_deq_begin(>if_snd);
>>>>>>> if (foo_encap(sc, m_head, 0)) {
>>>>>>> ifq_deq_rollback(>if_snd, m_head);
>>>>>>> ...
>>>>>>> return;
>>>>>>> }
>>>>>>> ifq_deq_commit(>if_snd, m_head);
>>>>>>>
>>>>>>> Here, ifq_deq_begin() grabs a mutex and it is held while
>>>>>>> calling foo_encap().
>>>>>>>
>>>>>>> For USB network interfaces foo_encap() mostly does this:
>>>>>>>
>>>>>>> err = usbd_transfer(sc->sc_xfer);
>>>>>>> if (err != USBD_IN_PROGRESS) {
>>>>>>> foo_stop(sc);
>>>>>&
Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
Good news - no more kernel panics on USB 3.0(xHCI), it’s fixed.
Bad news - after 2-3h LTE modem lost local network connection via USB
3.0(cdce0). I have to remove modem and put it back to usb port - then local
network connection between OpenBSD and modem back for 2-3h, sometimes 30-40
min. It looks like the same problem as kernel panic, but this time there is
lost network connection via usb 3.0(xhci).
root@master[~]ping 192.168.8.1
PING 192.168.8.1 (192.168.8.1): 56 data bytes
ping: sendmsg: Network is down
ping: wrote 192.168.8.1 64 chars, ret=-1
ping: sendmsg: Network is down
ping: wrote 192.168.8.1 64 chars, ret=-1
192.168.8.1 is default static IP on lte modem.
Your changes in if_cdce.c 1.77 not completely fix the problem.
> On 11 Jun 2020, at 11:13, Łukasz Lejtkowski wrote:
>
> Hi Gerhard,
>
> Today I added Your patches to 6.7-stable and moved back LTE modem to USB 3.0.
> So, just waiting for… nothing or kernel panic. I’ll let you know.
>
>> On 8 Jun 2020, at 19:13, Patrick Wildt > <mailto:patr...@blueri.se>> wrote:
>>
>> On Mon, Jun 08, 2020 at 05:31:44PM +0200, Gerhard Roth wrote:
>>> On 2020-05-25 13:19, Martin Pieuchot wrote:
>>>> On 25/05/20(Mon) 12:56, Gerhard Roth wrote:
>>>>> On 5/22/20 9:05 PM, Mark Kettenis wrote:
>>>>>>> From: Łukasz Lejtkowski mailto:emig...@gmail.com>>
>>>>>>> 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 transaction leads to this panic is a bug though.
>>>>>>
>>>>>> And somebody just posted a very similar panic with ure(4). Something
>>>>>> in the network stack is holding a mutex when it shouldn't.
>>>>>
>>>>> I think that holding the mutex is ok. The bug is calling the stop
>>>>> routine in case of errors.
>>>>>
>>>>> This is what common foo_start() does:
>>>>>
>>>>> m_head = ifq_deq_begin(>if_snd);
>>>>> if (foo_encap(sc, m_head, 0)) {
>>>>> ifq_deq_rollback(>if_snd, m_head);
>>>>> ...
>>>>> return;
>>>>> }
>>>>> ifq_deq_commit(>if_snd, m_head);
>>>>>
>>>>> Here, ifq_deq_begin() grabs a mutex and it is held while
>>>>> calling foo_encap().
>>>>>
>>>>> For USB network interfaces foo_encap() mostly does this:
>>>>>
>>>>> err = usbd_transfer(sc->sc_xfer);
>>>>> if (err != USBD_IN_PROGRESS) {
>>>>> foo_stop(sc);
>>>>> return EIO;
>>>>> }
>>>>>
>>>>> And foo_stop() calls usbd_abort_pipe() -> xhci_command_submit(),
>>>>> which might sleep.
>>>>>
>>>>> How to fix? We could do the foo_encap() after the ifq_deq_commit(),
>>>>> possibly dropping the current mbuf if encap fails (who cares
>>>>> for the packets after foo_stop() anyway).
>>>>
>>>> That's the approach taken by drivers using ifq_dequeue(9) instead of
>>>> ifq_deq_begin/commit().
>>>>
>>>>> Or change all the drivers to follow the path that if_aue.c takes:
>>>>>
>>>>> err = usbd_transfer(c->aue_xfer);
>>>>> if (err != USBD_IN_PROGRESS) {
>>>>> ...
>>>>> /* Stop the interface from process context. */
>>>>> usb_add_task(sc->aue_udev, >aue_stop_task);
>>>>> return (EIO);
>>>>> }
>>>>
>>>> That's just trading the current problem for another one with higher
>>>> complexity.
>>>>
>>>>> Any ideas, what's better? Or alternative proposals?
>>>>
>>>> Using ifq_dequeue(9) would have the advantage of unifying the code base.
>>>> It introduces a behavior change. A simpler fix would be to call
>>>> foo_stop() in the error path after ifq_deq_rollback().
>>>>
>>>
>>> Hi,
>>>
>>> two weeks passed any nobody objected Martin's proposal. So I thought,
>>> we could try to move on this way.
>>>
>
Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
Hi Gerhard,
Today I added Your patches to 6.7-stable and moved back LTE modem to USB 3.0.
So, just waiting for… nothing or kernel panic. I’ll let you know.
> On 8 Jun 2020, at 19:13, Patrick Wildt wrote:
>
> On Mon, Jun 08, 2020 at 05:31:44PM +0200, Gerhard Roth wrote:
>> On 2020-05-25 13:19, Martin Pieuchot wrote:
>>> On 25/05/20(Mon) 12:56, Gerhard Roth wrote:
>>>> On 5/22/20 9:05 PM, Mark Kettenis wrote:
>>>>>> 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 transaction leads to this panic is a bug though.
>>>>>
>>>>> And somebody just posted a very similar panic with ure(4). Something
>>>>> in the network stack is holding a mutex when it shouldn't.
>>>>
>>>> I think that holding the mutex is ok. The bug is calling the stop
>>>> routine in case of errors.
>>>>
>>>> This is what common foo_start() does:
>>>>
>>>>m_head = ifq_deq_begin(>if_snd);
>>>>if (foo_encap(sc, m_head, 0)) {
>>>>ifq_deq_rollback(>if_snd, m_head);
>>>>...
>>>>return;
>>>>}
>>>>ifq_deq_commit(>if_snd, m_head);
>>>>
>>>> Here, ifq_deq_begin() grabs a mutex and it is held while
>>>> calling foo_encap().
>>>>
>>>> For USB network interfaces foo_encap() mostly does this:
>>>>
>>>>err = usbd_transfer(sc->sc_xfer);
>>>>if (err != USBD_IN_PROGRESS) {
>>>>foo_stop(sc);
>>>>return EIO;
>>>>}
>>>>
>>>> And foo_stop() calls usbd_abort_pipe() -> xhci_command_submit(),
>>>> which might sleep.
>>>>
>>>> How to fix? We could do the foo_encap() after the ifq_deq_commit(),
>>>> possibly dropping the current mbuf if encap fails (who cares
>>>> for the packets after foo_stop() anyway).
>>>
>>> That's the approach taken by drivers using ifq_dequeue(9) instead of
>>> ifq_deq_begin/commit().
>>>
>>>> Or change all the drivers to follow the path that if_aue.c takes:
>>>>
>>>>err = usbd_transfer(c->aue_xfer);
>>>>if (err != USBD_IN_PROGRESS) {
>>>>...
>>>>/* Stop the interface from process context. */
>>>>usb_add_task(sc->aue_udev, >aue_stop_task);
>>>>return (EIO);
>>>>}
>>>
>>> That's just trading the current problem for another one with higher
>>> complexity.
>>>
>>>> Any ideas, what's better? Or alternative proposals?
>>>
>>> Using ifq_dequeue(9) would have the advantage of unifying the code base.
>>> It introduces a behavior change. A simpler fix would be to call
>>> foo_stop() in the error path after ifq_deq_rollback().
>>>
>>
>> Hi,
>>
>> two weeks passed any nobody objected Martin's proposal. So I thought,
>> we could try to move on this way.
>>
>> Gerhard
>>
>
> From what I remember from various discussions, the goal should be to
> check if there's a buffer free in the ring, then dequeue and send, and
> it it can't be sent out, then drop it. With USB apparently those
> drivers "always" have an open buffer, so we can just dequeue and send,
> like you do in this diff. And if it gets dropped, that's fine.
>
> That said, I think IFQ_DEQUEUE() is old compat code, and we actually
> nowadays prefer:
>
> m_head = ifq_dequeue(>if_snd);
>
> If you look at the define for IFQ_DEQUEUE() you'll see it's marked
> as compat code. If you look at a new driver, like ixl(4), you'll
> see that it also uses ifq_dequeue().
>
> Sorry to to give you some work, but with that fixed: ok patrick@
>
> Patrick
>
>>
>> Index: sys/dev/usb/if_axe.c
>> ===
>> RCS file: /cvs/src/sys/dev/usb/if_axe.c,v
>> retrieving revision 1.139
>> diff -u -p -u -p -r1.139 if_axe.c
>> --- sys/dev/usb/if_axe.c 7 Jul 2019 06:40:10 - 1.139
>> +++ sys/dev/usb/if_axe
Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
LTE modem works correctly under usb 2.0(EHCI), no panics. Uptime almost 2 days.
Something is broken in xHCI (xhci.c?).
Any patch for 6.7 soon, or is it more complicated?
> On 27 May 2020, at 18:30, Łukasz Lejtkowski wrote:
>
> Right now LTE modem working on internal USB 2.0(EHCI). External is USB
> 3.0(xHCI). We will see… :)
>
> root@master[~]usbdevs -v
> Controller /dev/usb0:
> addr 01: 1022: AMD, xHCI root hub
>super speed, self powered, config 1, rev 1.00
>driver: uhub0
> Controller /dev/usb1:
> addr 01: 1022: AMD, EHCI root hub
>high speed, self powered, config 1, rev 1.00
>driver: uhub1
> addr 02: 0438:7900 Advanced Micro Devices, Hub
>high speed, self powered, config 1, rev 0.18
>driver: uhub2
> addr 03: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
>high speed, self powered, config 1, rev 1.02
>driver: cdce0
>driver: umass0
> root@master[~]
>
>
>> On 25 May 2020, at 13:19, Martin Pieuchot > <mailto:m...@openbsd.org>> wrote:
>>
>> On 25/05/20(Mon) 12:56, Gerhard Roth wrote:
>>> On 5/22/20 9:05 PM, Mark Kettenis wrote:
>>>>> From: Łukasz Lejtkowski mailto:emig...@gmail.com>>
>>>>> 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 transaction leads to this panic is a bug though.
>>>>
>>>> And somebody just posted a very similar panic with ure(4). Something
>>>> in the network stack is holding a mutex when it shouldn't.
>>>
>>> I think that holding the mutex is ok. The bug is calling the stop
>>> routine in case of errors.
>>>
>>> This is what common foo_start() does:
>>>
>>> m_head = ifq_deq_begin(>if_snd);
>>> if (foo_encap(sc, m_head, 0)) {
>>> ifq_deq_rollback(>if_snd, m_head);
>>> ...
>>> return;
>>> }
>>> ifq_deq_commit(>if_snd, m_head);
>>>
>>> Here, ifq_deq_begin() grabs a mutex and it is held while
>>> calling foo_encap().
>>>
>>> For USB network interfaces foo_encap() mostly does this:
>>>
>>> err = usbd_transfer(sc->sc_xfer);
>>> if (err != USBD_IN_PROGRESS) {
>>> foo_stop(sc);
>>> return EIO;
>>> }
>>>
>>> And foo_stop() calls usbd_abort_pipe() -> xhci_command_submit(),
>>> which might sleep.
>>>
>>> How to fix? We could do the foo_encap() after the ifq_deq_commit(),
>>> possibly dropping the current mbuf if encap fails (who cares
>>> for the packets after foo_stop() anyway).
>>
>> That's the approach taken by drivers using ifq_dequeue(9) instead of
>> ifq_deq_begin/commit().
>>
>>> Or change all the drivers to follow the path that if_aue.c takes:
>>>
>>> err = usbd_transfer(c->aue_xfer);
>>> if (err != USBD_IN_PROGRESS) {
>>> ...
>>> /* Stop the interface from process context. */
>>> usb_add_task(sc->aue_udev, >aue_stop_task);
>>> return (EIO);
>>> }
>>
>> That's just trading the current problem for another one with higher
>> complexity.
>>
>>> Any ideas, what's better? Or alternative proposals?
>>
>> Using ifq_dequeue(9) would have the advantage of unifying the code base.
>> It introduces a behavior change. A simpler fix would be to call
>> foo_stop() in the error path after ifq_deq_rollback().
>
Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
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 mi_switch+0x40
sleep_finish(8000225b8208,1) at sleep_finish+0x84
sleep_finish_all(8000225b8208,1) at sleep_finish_all+0x21
tsleep(800b1750,16,81c95c7d,33) at tsleep+0xd6
xhci_command_submit(8009c000,8000225b82f8,1dcd6500) at xhci_command
_submit+0x13f
xhci_abort_xfer(fd812e90c3c0,6) at xhci_abort_xfer+0x13a
usbd_abort_pipe(80bbe000) at usbd_abort_pipe+0x3d
cdce_stop(80bba800) at cdce_stop+0x46
cdce_encap(80bba800,fd80cf78c700,0) at cdce_encap+0xf7
cdce_start(80bba848) at cdce_start+0x84
if_qstart_compat(80bbaac0) at if_qstart_compat+0x2e
end trace frame: 0x8000225b8510, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
> On 22 May 2020, at 21:05, Mark Kettenis wrote:
>
>> 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 transaction leads to this panic is a bug though.
>
> And somebody just posted a very similar panic with ure(4). Something
> in the network stack is holding a mutex when it shouldn't.
>
>>> On 22 May 2020, at 20:05, Łukasz Lejtkowski wrote:
>>>
>>> 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() at assertwaitok+0xc7
>>> mi_switch() at mi_switch+0x40
>>> sleep_finish(8000225b8538,1) at sleep_finish+0x84
>>> sleep_finish_all(8000225b8538,1) at sleep_finish_all+0x21
>>> tsleep(800b1750,16,81c95c7d,33) at tsleep+0xd6
>>> xhci_command_submit(8009c000,8000225b8628,1dcd6500) at
>>> xhci_command
>>> _submit+0x13f
>>> xhci_abort_xfer(fd812e90c780,6) at xhci_abort_xfer+0x13a
>>> usbd_abort_pipe(8047b000) at usbd_abort_pipe+0x3d
>>> cdce_stop(8012d000) at cdce_stop+0x46
>>> cdce_encap(8012d000,fd80c0731d00,0) at cdce_encap+0xf7
>>> cdce_start(8012d048) at cdce_start+0x84
>>> if_qstart_compat(ffff8012d2c0) at if_qstart_compat+0x2e
>>> end trace frame: 0x8000225b8840, count: 0
>>> https://www.openbsd.org/ddb.html describes the minimum info required in bug
>>> reports. Insufficient info makes it difficult to find and fix bugs.
>>> ddb{2}>
>>>
>>>> On 22 May 2020, at 15:58, Łukasz Lejtkowski wrote:
>>>>
>>>> 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
>>>>
>>>> ddb{2}> trace
>>>> db_enter() at db_enter+0x10
>>>> panic(81c8ec25) at panic+0x128
>>>> assertwaitok() at assertwaitok+0xc7
>>>> mi_switch() at mi_switch+0x40
>>>> sleep_finish(8000225b8f88,1) at sleep_finish+0x84
>>>> sleep_finish_all(8000225b8f88,1) at sleep_finish_all+0x21
>>>> tsleep(800a5750,16,81c99248,33) at tsleep+0xd6
>>>> xhci_command_submit(8009,8000225b9078,1dcd6500) at
>>>> xhci_command
>>>> _submit+0x13f
>>>> xhci_abort_xfer(fd811e918690,6) at xhci_abort_xfer+0x13a
>>>> usbd_abort_pipe(8045f000) at usbd_abort_pipe+0x3d
>>>> cdce_stop(80119000) at cdce_stop+0x46
>>>> cdce_encap(80119000,fd80df8b8400,0) at cdce_encap+0xf7
>>>> cdce_start(80119048) at cdce_start+0x84
>>>> if_qstart_compat(801192c0) at if_qstart_compat+0x2e
>>>> ifq_serialize(801192c0,800
Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
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 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 mi_switch+0x40
> sleep_finish(8000225b8538,1) at sleep_finish+0x84
> sleep_finish_all(8000225b8538,1) at sleep_finish_all+0x21
> tsleep(800b1750,16,81c95c7d,33) at tsleep+0xd6
> xhci_command_submit(8009c000,8000225b8628,1dcd6500) at
> xhci_command
> _submit+0x13f
> xhci_abort_xfer(fd812e90c780,6) at xhci_abort_xfer+0x13a
> usbd_abort_pipe(8047b000) at usbd_abort_pipe+0x3d
> cdce_stop(8012d000) at cdce_stop+0x46
> cdce_encap(8012d000,fd80c0731d00,0) at cdce_encap+0xf7
> cdce_start(8012d048) at cdce_start+0x84
> if_qstart_compat(8012d2c0) at if_qstart_compat+0x2e
> end trace frame: 0x8000225b8840, count: 0
> https://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports. Insufficient info makes it difficult to find and fix bugs.
> ddb{2}>
>
>> On 22 May 2020, at 15:58, Łukasz Lejtkowski wrote:
>>
>> 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
>>
>> ddb{2}> trace
>> db_enter() at db_enter+0x10
>> panic(81c8ec25) at panic+0x128
>> assertwaitok() at assertwaitok+0xc7
>> mi_switch() at mi_switch+0x40
>> sleep_finish(8000225b8f88,1) at sleep_finish+0x84
>> sleep_finish_all(8000225b8f88,1) at sleep_finish_all+0x21
>> tsleep(800a5750,16,81c99248,33) at tsleep+0xd6
>> xhci_command_submit(8009,8000225b9078,1dcd6500) at
>> xhci_command
>> _submit+0x13f
>> xhci_abort_xfer(fd811e918690,6) at xhci_abort_xfer+0x13a
>> usbd_abort_pipe(8045f000) at usbd_abort_pipe+0x3d
>> cdce_stop(80119000) at cdce_stop+0x46
>> cdce_encap(80119000,fd80df8b8400,0) at cdce_encap+0xf7
>> cdce_start(80119048) at cdce_start+0x84
>> if_qstart_compat(801192c0) at if_qstart_compat+0x2e
>> ifq_serialize(801192c0,80119390) at ifq_serialize+0x103
>> taskq_thread(800290c0) at taskq_thread+0x4d
>> end trace frame: 0x0, count: -16
>>
>>
>>
>> PC Engines apu2
>> coreboot build 20202604
>> BIOS version v4.11.0.6
>> 4080 MB ECC DRAM
>> SeaBIOS (version rel-1.12.1.3-0-g300e8b70)
>>
>>
>> root@master[~]usbdevs -v
>> Controller /dev/usb0:
>> addr 01: 1022: AMD, xHCI root hub
>> super speed, self powered, config 1, rev 1.00
>> driver: uhub0
>> addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
>> high speed, self powered, config 1, rev 1.02
>> driver: cdce0
>> driver: umass0
>> Controller /dev/usb1:
>> addr 01: 1022: AMD, EHCI root hub
>> high speed, self powered, config 1, rev 1.00
>> driver: uhub1
>> addr 02: 0438:7900 Advanced Micro Devices, Hub
>> high speed, self powered, config 1, rev 0.18
>> driver: uhub2
>>
>>
>> root@master[~]usbdevs -vv
>> Controller /dev/usb0:
>> addr 01: 1022: AMD, xHCI root hub
>> super speed, self powered, config 1, rev 1.00
>> driver: uhub0
>> port 01: .02a0 power Rx.detect
>> port 02: .02a0 power Rx.detect
>> port 03: .0503 connect enabled recovery
>> port 04: .02a0 power Rx.detect
>> addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
>> high speed, self powered, config 1, rev 1.02
>> driver: cdce0
>> driver: umass0
>> Controller /dev/usb1:
>> addr 01: 1022: AMD, EHCI root hub
>> high speed, self powered, config 1, rev 1.00
>> driver: uhub1
>> port 01: .0503 connect enabled power
>> port 02: .0500 power
>> addr 02: 0438:7900 Advanced Micro Devices, Hub
>> high speed, self powered, config 1, rev 0.18
>> driver: uhub2
>>
Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
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() at assertwaitok+0xc7
mi_switch() at mi_switch+0x40
sleep_finish(8000225b8538,1) at sleep_finish+0x84
sleep_finish_all(8000225b8538,1) at sleep_finish_all+0x21
tsleep(800b1750,16,81c95c7d,33) at tsleep+0xd6
xhci_command_submit(8009c000,8000225b8628,1dcd6500) at xhci_command
_submit+0x13f
xhci_abort_xfer(fd812e90c780,6) at xhci_abort_xfer+0x13a
usbd_abort_pipe(8047b000) at usbd_abort_pipe+0x3d
cdce_stop(8012d000) at cdce_stop+0x46
cdce_encap(8012d000,fd80c0731d00,0) at cdce_encap+0xf7
cdce_start(8012d048) at cdce_start+0x84
if_qstart_compat(8012d2c0) at if_qstart_compat+0x2e
end trace frame: 0x8000225b8840, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{2}>
> On 22 May 2020, at 15:58, Łukasz Lejtkowski wrote:
>
> 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
>
> ddb{2}> trace
> db_enter() at db_enter+0x10
> panic(81c8ec25) at panic+0x128
> assertwaitok() at assertwaitok+0xc7
> mi_switch() at mi_switch+0x40
> sleep_finish(8000225b8f88,1) at sleep_finish+0x84
> sleep_finish_all(8000225b8f88,1) at sleep_finish_all+0x21
> tsleep(800a5750,16,81c99248,33) at tsleep+0xd6
> xhci_command_submit(8009,8000225b9078,1dcd6500) at
> xhci_command
> _submit+0x13f
> xhci_abort_xfer(fd811e918690,6) at xhci_abort_xfer+0x13a
> usbd_abort_pipe(8045f000) at usbd_abort_pipe+0x3d
> cdce_stop(80119000) at cdce_stop+0x46
> cdce_encap(80119000,fd80df8b8400,0) at cdce_encap+0xf7
> cdce_start(80119048) at cdce_start+0x84
> if_qstart_compat(801192c0) at if_qstart_compat+0x2e
> ifq_serialize(801192c0,80119390) at ifq_serialize+0x103
> taskq_thread(800290c0) at taskq_thread+0x4d
> end trace frame: 0x0, count: -16
>
>
>
> PC Engines apu2
> coreboot build 20202604
> BIOS version v4.11.0.6
> 4080 MB ECC DRAM
> SeaBIOS (version rel-1.12.1.3-0-g300e8b70)
>
>
> root@master[~]usbdevs -v
> Controller /dev/usb0:
> addr 01: 1022: AMD, xHCI root hub
>super speed, self powered, config 1, rev 1.00
>driver: uhub0
> addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
>high speed, self powered, config 1, rev 1.02
>driver: cdce0
>driver: umass0
> Controller /dev/usb1:
> addr 01: 1022: AMD, EHCI root hub
>high speed, self powered, config 1, rev 1.00
>driver: uhub1
> addr 02: 0438:7900 Advanced Micro Devices, Hub
>high speed, self powered, config 1, rev 0.18
>driver: uhub2
>
>
> root@master[~]usbdevs -vv
> Controller /dev/usb0:
> addr 01: 1022: AMD, xHCI root hub
>super speed, self powered, config 1, rev 1.00
>driver: uhub0
>port 01: .02a0 power Rx.detect
>port 02: .02a0 power Rx.detect
>port 03: .0503 connect enabled recovery
>port 04: .02a0 power Rx.detect
> addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
>high speed, self powered, config 1, rev 1.02
>driver: cdce0
>driver: umass0
> Controller /dev/usb1:
> addr 01: 1022: AMD, EHCI root hub
>high speed, self powered, config 1, rev 1.00
>driver: uhub1
>port 01: .0503 connect enabled power
>port 02: .0500 power
> addr 02: 0438:7900 Advanced Micro Devices, Hub
>high speed, self powered, config 1, rev 0.18
>driver: uhub2
>port 01: .0100 power
>port 02: .0100 power
>port 03: .0100 power
>port 04: .0100 power
>
>
> root@master[~]ifconfig cdce0
> cdce0: flags=8843 mtu 1500
> lladdr xx:xx:xx:xx:xx:xx
> index 6 priority 0 llprio 3
> inet 192.168.8.100 netmask 0xff00 broadcast 192.168.8.255
>
>
>
>
> root@master[~]dmesg
> OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
>
> r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4259880960 (4062MB)
> avail mem = 4118163456 (3927MB)
&g
OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
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
ddb{2}> trace
db_enter() at db_enter+0x10
panic(81c8ec25) at panic+0x128
assertwaitok() at assertwaitok+0xc7
mi_switch() at mi_switch+0x40
sleep_finish(8000225b8f88,1) at sleep_finish+0x84
sleep_finish_all(8000225b8f88,1) at sleep_finish_all+0x21
tsleep(800a5750,16,81c99248,33) at tsleep+0xd6
xhci_command_submit(8009,8000225b9078,1dcd6500) at xhci_command
_submit+0x13f
xhci_abort_xfer(fd811e918690,6) at xhci_abort_xfer+0x13a
usbd_abort_pipe(8045f000) at usbd_abort_pipe+0x3d
cdce_stop(80119000) at cdce_stop+0x46
cdce_encap(80119000,fd80df8b8400,0) at cdce_encap+0xf7
cdce_start(80119048) at cdce_start+0x84
if_qstart_compat(801192c0) at if_qstart_compat+0x2e
ifq_serialize(801192c0,80119390) at ifq_serialize+0x103
taskq_thread(800290c0) at taskq_thread+0x4d
end trace frame: 0x0, count: -16
PC Engines apu2
coreboot build 20202604
BIOS version v4.11.0.6
4080 MB ECC DRAM
SeaBIOS (version rel-1.12.1.3-0-g300e8b70)
root@master[~]usbdevs -v
Controller /dev/usb0:
addr 01: 1022: AMD, xHCI root hub
super speed, self powered, config 1, rev 1.00
driver: uhub0
addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
high speed, self powered, config 1, rev 1.02
driver: cdce0
driver: umass0
Controller /dev/usb1:
addr 01: 1022: AMD, EHCI root hub
high speed, self powered, config 1, rev 1.00
driver: uhub1
addr 02: 0438:7900 Advanced Micro Devices, Hub
high speed, self powered, config 1, rev 0.18
driver: uhub2
root@master[~]usbdevs -vv
Controller /dev/usb0:
addr 01: 1022: AMD, xHCI root hub
super speed, self powered, config 1, rev 1.00
driver: uhub0
port 01: .02a0 power Rx.detect
port 02: .02a0 power Rx.detect
port 03: .0503 connect enabled recovery
port 04: .02a0 power Rx.detect
addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
high speed, self powered, config 1, rev 1.02
driver: cdce0
driver: umass0
Controller /dev/usb1:
addr 01: 1022: AMD, EHCI root hub
high speed, self powered, config 1, rev 1.00
driver: uhub1
port 01: .0503 connect enabled power
port 02: .0500 power
addr 02: 0438:7900 Advanced Micro Devices, Hub
high speed, self powered, config 1, rev 0.18
driver: uhub2
port 01: .0100 power
port 02: .0100 power
port 03: .0100 power
port 04: .0100 power
root@master[~]ifconfig cdce0
cdce0: flags=8843 mtu 1500
lladdr xx:xx:xx:xx:xx:xx
index 6 priority 0 llprio 3
inet 192.168.8.100 netmask 0xff00 broadcast 192.168.8.255
root@master[~]dmesg
OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4259880960 (4062MB)
avail mem = 4118163456 (3927MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xcfe8d020 (13 entries)
bios0: vendor coreboot version "v4.11.0.6" date 04/26/2020
bios0: PC Engines apu2
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT HPET
acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4)
UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-64
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD GX-412TC SOC, 998.27 MHz, 16-30-01
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD GX-412TC SOC, 998.17 MHz, 16-30-01
cpu1:
