Re: Kernel-Crash when working with ubt0

From: <mms.vanbreukelingen_at_gmail.com>
Date: Thu, 29 Aug 2019 05:34:28 +0000 (UTC)
On Thu, 29 Aug 2019 at 6:04, Warner Losh

<imp_at_bsdimp.com> wrote:   

On Wed, Aug 28, 2019, 8:57 PM Miranda Maria Sophie Van den Breukelingen <mms.vanbreukelingen_at_gmail.com> wrote:



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:

_at_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. 
_at_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"; 
_at_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 0xffffffff8256d000    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?


https://wiki.freebsd.org/SteveWills/BTSpeaker

Might be interesting. I've not tried this yet, so I don't know if it is too old, but it references bluetooth-config, which is fairly new...
My goals are more modest: I just want to get the keyboard I have working, with the modified keypad I have... :)
Warner

Miranda
THX for the Tipp with bluetooth-config,  gotta try.  When I do patch -p1 bt.diff there's an everlasting thinking without output no matter if done in /usr/src or /usr/src/head... 
When you do a pkg search bluetooth you'd probably desiluded. 

I have some BT-keyboard,  too,  switching between usb-stack and ubs-stack with Combo,  but not even working with Linux,  well,  let's see what's happening,  when I attach and a Q13 Bluetooth in-ear-headphone,  just for trying out the stack and maybe,  maybe one day we all get rid of those cabels. Salad? 
Miranda
  
Received on Thu Aug 29 2019 - 03:34:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC