Kernel-Crash when working with ubt0

Thu Aug 29 02:57:49 UTC 2019

On Thu, 29 Aug 2019 at 03:48, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Wed, Aug 28, 2019, 4:34 PM mms.vanbreukelingen at gmail.com <
> mms.vanbreukelingen at gmail.com> wrote:
>
>> @Maksim, I first did a "git apply -R bt.diff" and then
>>
>> root at freeBSD13:/usr/src # git apply --stat --check --ignore-whitespace
>> ng_btsocket_hci_raw.c.diff.txt
>> error: patch failed:
>> head/sys/netgraph/bluetooth/socket/ng_btsocket_hci_raw.c:1156
>> error: head/sys/netgraph/bluetooth/socket/ng_btsocket_hci_raw.c: patch
>> does not apply
>>
>
> patch -p1 worked for me to apply it.
>
> And it worked just fine for everything once I rebooted. The patch looked
> fine to my eye.
>
> Warner
>
>
> Rebuilding with MTX_SPIN=y (withouth patch)...
>> On Wed, 28 Aug 2019 at 19:10, Maksim Yevmenkin <
>> maksim.yevmenkin at gmail.com> wrote:
>>
>> > > > Hmm... interesting....
>> > > >
>> > > > I only took a brief look at it. I suppose I can ensure user space
>> address is wired and then copyout() can be called with mutex held
>> > >
>> > > >No, you cannot do this, at least without making the kernel to panic.
>> > > User might unmap the wired mapping at any time still.
>> >
>> > Kostik,
>> >
>> > i was thinking along the lines of vslock/vsunlock and copyout_nofault.
>> > basically similar to the sysctl code. do you think this would not
>> > work?
>>
>> actually, i dont think i need to hold lock over copyout. attached is
>> my version of the patch (untested)
>>
>> thank
>> max
>>
>>

oh, didn't patch it with the -p1 option, maybe this is why. I rebuild the
kernel and removed the WITNESS option,
option                 MTX_SPIN                   # is an illtusion for not
locking yourself out

and it does work. When using the built-in-adapter you not just have to
reboot but to turn it off for at least 10 secs., and then reboot into
freeBSD again. Here's what I'm having right now:

/etc/rc.d/bluetooth start ubt0
/etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0

*root at freeBSD13:/usr/home/miranda # /etc/rc.d/bluetooth start ubt0
root at freeBSD13:/usr/home/miranda # *

 So, you got to tell it at least twice because of dmesg often calling:
*ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command
OGF=0x3, OCF=0x3. Timeout*

The ubt0 is the Asus stack, I can't setup the internal ubt1 anymore at all.
Maybe I'm gonna patch with the -p1 flag tomorrow.

@warner Is there a way to patch a running kernel and just reboot or is it
always in a new buildkernel environment? I did "patch   bt.diff";

@maksim; special way to patch correctly?

*bluetooth-config scan Scanning for new Bluetooth devices (Attempt 1 of 5)
... done. Found 1 new bluetooth device (now scanning for names): [ 1]
c0:7a:a5:00:c7:11  "Ubittek MagicBox" (Ubittek_MagicBox) *

*Select device to pair with [1, or 0 to rescan]: 1 *

*Warning: An entry for device c0:7a:a5:00:c7:11 is already present in
/etc/bluetooth/hcsecd.conf. To modify pairing information, edit this file
and run  service hcsecd restart Continue? [yes]: yes *
Entry in /etc/bluetooth/hcsecd.conf:

*device {        bdaddr  c0:7a:a5:00:c7:11;        name    "Ubittek
MagicBox";        key     nokey;        pin     nopin; }*

l2ping:
*l2ping -a c0:7a:a5:00:c7:11 *
*16 bytes from Ubittek_MagicBox seq_no=0 time=2611.842 ms result=0  *
*16 bytes from Ubittek_MagicBox seq_no=1 time=6.274 ms result=0  *
*16 bytes from Ubittek_MagicBox seq_no=2 time=6.862 ms result=0 *
[not 0 bytes??]

*but*, and this is the status for now:

*l2control -a c0:7a:a5:00:c7:11 read_channel_list l2control: Could not bind
socket, bdaddr=c0:7a:a5:00:c7:11: Network is down *
I think it is paired correctly but doesn't know how to connect; in linux
with bluethothctl I get normally "device paired" ---- self-connection-trial
---- "device connected" and 5 secs later "device disconnected". It has to
do a salvating "bip" at the box and then it's connected.

kldstat:

*Id Refs Address                Size Name 1   87 0xffffffff80200000
 2288f58 kernel 2    1 0xffffffff824ad000     3170 splash_bmp.ko 3    1
0xffffffff824b1000     a468 ng_ubt.ko 4    3 0xffffffff824bc000    12d10
ng_hci.ko 5    4 0xffffffff824cf000     2dc0 ng_bluetooth.ko 6    7
0xffffffff824d2000    18d50 netgraph.ko *

* 7    1 0xffffffff824eb000    18c28 ng_l2cap.ko 8    1 0xffffffff82504000
   68840 if_em_updated.ko 9    1 0xf**fffffff8256d000    96fa0 linux64.ko *

*10    3 0xffffffff82604000     b760 linux_common.ko 11    1
0xffffffff82610000    b4bf0 linux.ko 12    1 0xffffffff826c5000     2a78
ubtbcmfw.ko 13    1 0xffffffff82d18000    7b040 i915kms.ko 14    1
0xffffffff82d94000    3d9e8 drm2.ko 15    4 0xffffffff82dd2000     1f40
iicbus.ko 16    1 0xffffffff82dd4000      f70 iic.ko 17    1
0xffffffff82dd5000     1570 iicbb.ko 18    1 0xffffffff82dd7000    15720
if_iwm.ko 19    1 0xffffffff82ded000    e045f iwm3160fw.ko 20    1
0xffffffff82ece000     1840 uhid.ko 21    1 0xffffffff82ed0000     2928
ums.ko *

*22    1 0xffffffff82ed3000    19690 ng_btsocket.ko 23    1
0xffffffff82eed000     20f0 ng_socket.ko 24    1 0xffffffff82ef0000
    4570 autofs.ko 25    1 0xffffffff82ef5000      acf mac_ntpd.ko *

*26    1 0xffffffff82ef6000    19738 ext2fs.ko 27    1 0xffffffff82f10000
    3a8c geom_linux_lvm.ko*

13 and 14 is new here with llvm-devel!

*hccontrol -n ubt0hci read_connection_list            Remote BD_ADDR
   Handle Type Mode Role Encrypt Pending Queue State Ubittek_MagicBox
     12  ACL    0 MAST    NONE       0     0 OPEN*

*btsockstat  Active L2CAP sockets PCB      Recv-Q Send-Q Local address/PSM
      Foreign address   CID   State fffff8000331db00      0      0 *
               /1     *                 0     LISTEN*

So it's now a problem with the L2CAP and there's no A2DP-fix anymore for
BSD, AFAIK. Suggestions?

Miranda