Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

2020-06-17 Thread Łukasz Lejtkowski 
> 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 >> > 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 >>> > 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
>>

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

2020-06-15 Thread Gerhard Roth 

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 > 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 > 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.c7 Jul 2019 06:40:10 -1.139
+++ sys/dev/usb/if_axe.c8 Jun 2020 15:13:25 -
@@ -1223,6 +1223,7 @@ axe_encap(struct axe_softc *sc, struct m
/* Transmit */
err = usbd_transfer(c->axe_xfer);
if (err != USBD_IN_PROGRESS) {
+c->axe_mbuf = NULL;
axe_stop(sc);
return(EIO);
}
@@ -1246,16 +1247,15 @@ axe_start(struct ifnet *ifp)
if (ifq_is_oactive(>if_snd))
return;

-m_head = ifq_deq_begin(>if_snd);
+IFQ_DEQUEUE(>if_snd, m_head);
if (m_head == NULL)
return;

if (axe_encap(sc,

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

2020-06-12 Thread Łukasz Lejtkowski 
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 > > 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.
>>> 
>>> 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.c7 Jul 2019 06:40:10 -   1.139
>>> +++ sys/dev/usb/if_axe.c8 Jun 2020 15:13:25 -
>>> @@ -1223,6 +1223,7 @@

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

2020-06-11 Thread Łukasz Lejtkowski 
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.c 8 Jun 2020 15:13:25 -
>> @@ -1223,6 +1223,7 @@ axe_encap(struct axe_softc *sc, struct m
>>  /* Transmit */
>>  err = usbd_transfer(c->axe_xfer);
>>  if (err != USBD_IN_PROGRESS) {
>> +c->axe_mbuf = NULL;
>>  axe_stop(sc);
>>  return(EIO);
>>  }
>> @@ -1246,16 +1247,15 @@ axe_start(struct ifnet *ifp)
>>  if (ifq_is_oactive(>if_snd))
>>  return;
>> 
>> -m_head = ifq_deq_begin(>if_snd);
>> +IFQ_DEQUEUE(>if_snd, m_head);
>>  if (m_head == NULL)
>>  return;
>> 
>>  if (axe_encap(sc, m_head, 0)) {
>> -ifq_deq_rollback(>if_snd, m_head);
>> +m_freem(m_head);
>>  ifq_set_oactive(>if_snd);
>>  return;
>>  }
>> -ifq_deq_commit(>if_snd, m_head);
>> 
>>  /*
>>   * If there's a BPF listener, bounce a copy of this frame
>> Index: sys/dev/usb/if_axen.c
>> ===
>> RCS file:

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

2020-06-08 Thread Patrick Wildt 
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.c  8 Jun 2020 15:13:25 -
> @@ -1223,6 +1223,7 @@ axe_encap(struct axe_softc *sc, struct m
>   /* Transmit */
>   err = usbd_transfer(c->axe_xfer);
>   if (err != USBD_IN_PROGRESS) {
> + c->axe_mbuf = NULL;
>   axe_stop(sc);
>   return(EIO);
>   }
> @@ -1246,16 +1247,15 @@ axe_start(struct ifnet *ifp)
>   if (ifq_is_oactive(>if_snd))
>   return;
> 
> - m_head = ifq_deq_begin(>if_snd);
> + IFQ_DEQUEUE(>if_snd, m_head);
>   if (m_head == NULL)
>   return;
> 
>   if (axe_encap(sc, m_head, 0)) {
> - ifq_deq_rollback(>if_snd, m_head);
> + m_freem(m_head);
>   ifq_set_oactive(>if_snd);
>   return;
>   }
> - ifq_deq_commit(>if_snd, m_head);
> 
>   /*
>* If there's a BPF listener, bounce a copy of this frame
> Index: sys/dev/usb/if_axen.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_axen.c,v
> retrieving revision 1.27
> diff -u -p -u -p -r1.27 if_axen.c
> --- sys/dev/usb/if_axen.c 7 Jul 2019 06:40:10 -   1.27
> +++ sys/dev/usb/if_axen.c 8 Jun 2020 14:49:26 -
> @@ -1186,6 +1186,7

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

2020-06-08 Thread Gerhard Roth 

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


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.c7 Jul 2019 06:40:10 -   1.139
+++ sys/dev/usb/if_axe.c8 Jun 2020 15:13:25 -
@@ -1223,6 +1223,7 @@ axe_encap(struct axe_softc *sc, struct m
/* Transmit */
err = usbd_transfer(c->axe_xfer);
if (err != USBD_IN_PROGRESS) {
+   c->axe_mbuf = NULL;
axe_stop(sc);
return(EIO);
}
@@ -1246,16 +1247,15 @@ axe_start(struct ifnet *ifp)
if (ifq_is_oactive(>if_snd))
return;

-   m_head = ifq_deq_begin(>if_snd);
+   IFQ_DEQUEUE(>if_snd, m_head);
if (m_head == NULL)
return;

if (axe_encap(sc, m_head, 0)) {
-   ifq_deq_rollback(>if_snd, m_head);
+   m_freem(m_head);
ifq_set_oactive(>if_snd);
return;
}
-   ifq_deq_commit(>if_snd, m_head);

/*
 * If there's a BPF listener, bounce a copy of this frame
Index: sys/dev/usb/if_axen.c
===
RCS file: /cvs/src/sys/dev/usb/if_axen.c,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 if_axen.c
--- sys/dev/usb/if_axen.c   7 Jul 2019 06:40:10 -   1.27
+++ sys/dev/usb/if_axen.c   8 Jun 2020 14:49:26 -
@@ -1186,6 +1186,7 @@ axen_encap(struct axen_softc *sc, struct
/* Transmit */
err = usbd_transfer(c->axen_xfer);
if (err != USBD_IN_PROGRESS) {
+   c->axen_mbuf = NULL;
axen_stop(sc);
return EIO;
}
@@ -1209,16 +1210,15 @@ axen_start(struct ifnet *ifp)
if (ifq_is_oactive(>if_snd))
return;

-   m_head = ifq_deq_begin(>if_snd);
+   IFQ_DEQUEUE(>if_snd, m_head);
if (m_head == NULL)
return;

if (axen_encap(sc, m_head, 0)) {
-   ifq_deq_rollback(>if_snd, m_head);
+   m_freem(m_head);
ifq_set_oactive(>if_snd);
return;
}
-   ifq_deq_commit(>if_snd, m_head);

/*
 * If there's a BPF listener, bounce a copy of this frame
Index: sys/dev/usb/if_cdce.c
===
RCS file: /cvs/src/sys/dev/usb/if_cdce.c,v
retrieving revision 1.76
diff -u -p -u -p -r1.76 if_cdce.c
--- sys/dev/usb/if_cdce.c   14 Nov 2019 13:50:55 -  1.76
+++

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

2020-05-29 Thread Łukasz Lejtkowski 
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 > > 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

2020-05-25 Thread Martin Pieuchot 
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().

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

2020-05-25 Thread Gerhard Roth 

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).

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);
}

Any ideas, what's better? Or alternative proposals?


Gerhard




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

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

2020-05-22 Thread Łukasz Lejtkowski 
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(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

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

2020-05-22 Thread Mark Kettenis 
> 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(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

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

2020-05-22 Thread Łukasz Lejtkowski 
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
>>   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)
>>

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

2020-05-22 Thread Łukasz Lejtkowski 
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)
> 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

OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

2020-05-22 Thread Łukasz Lejtkowski 
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: