Return-Path: MIME-Version: 1.0 In-Reply-To: References: <00A3687E-050A-469F-98B0-C42F872EFE1C@holtmann.org> <115EE599-9710-437B-9AA8-C4CD8360EF3F@holtmann.org>

From: Peter Robinson Date: Wed, 20 Sep 2017 10:33:24 +0100 Message-ID: Subject: Re: Fedora 27 kernel and RPi3 Bluetooth oops To: Marcel Holtmann Cc: "bluez mailin list (linux-bluetooth@vger.kernel.org)" , Loic Poulain Content-Type: text/plain; charset="UTF-8" List-ID: On Tue, Sep 19, 2017 at 11:07 AM, Marcel Holtmann wro= te: > Hi Peter, > >>>>>>> the latest Fedora 27 kernel which has all the RPi3 patches applied = doesn=E2=80=99t actually work. It provides this backlog. >>>>>>> >>>>>>> [ 229.162921] CPU: 1 PID: 582 Comm: kworker/u9:1 Not tainted 4.13.= 2-300.fc27.armv7hl #1 >>>>>>> [ 229.171285] Hardware name: Generic DT based system >>>>>>> [ 229.176774] Workqueue: hci0 hci_cmd_work [bluetooth] >>>>>>> [ 229.176774] Workqueue: hci0 hci_cmd_work [bluetooth] >>>>>>> [ 229.182117] [] (unwind_backtrace) from [] (s= how_stack+0x18/0x1c) >>>>>>> [ 229.190374] [] (show_stack) from [] (dump_st= ack+0xa0/0xd8) >>>>>>> [ 229.198122] [] (dump_stack) from [] (registe= r_lock_class+0x298/0x514) >>>>>>> [ 229.206835] [] (register_lock_class) from []= (__lock_acquire+0xe4/0x1608) >>>>>>> [ 229.215952] [] (__lock_acquire) from [] (loc= k_acquire+0x280/0x2dc) >>>>>>> [ 229.224386] [] (lock_acquire) from [] (_raw_= read_lock+0x4c/0x5c) >>>>>>> [ 229.232740] [] (_raw_read_lock) from [] (hci= _uart_tx_wakeup+0x1c/0x98 [hci_uart]) >>>>>>> [ 229.242725] [] (hci_uart_tx_wakeup [hci_uart]) from [<= bf47a0e0>] (hci_uart_send_frame+0x54/0x6c [hci_uart]) >>>>>>> [ 229.254485] [] (hci_uart_send_frame [hci_uart]) from [= ] (hci_send_frame+0xc8/0xf4 [bluetooth]) >>>>>>> [ 229.266157] [] (hci_send_frame [bluetooth]) from [] (hci_cmd_work+0xa8/0x124 [bluetooth]) >>>>>>> [ 229.277005] [] (hci_cmd_work [bluetooth]) from [] (process_one_work+0x43c/0x83c) >>>>>>> [ 229.286689] [] (process_one_work) from [] (w= orker_thread+0x290/0x40c) >>>>>>> [ 229.295355] [] (worker_thread) from [] (kthr= ead+0x14c/0x168) >>>>>>> [ 229.303195] [] (kthread) from [] (ret_from_f= ork+0x14/0x24) >>>>>>> >>>>>>> It results in the first HCI command going through and then every ot= her failing. >>>>>>> >>>>>>> =3D Index Info: 00:00:00:00:00:00 (Broadcom Corporation) >>>>>>> < HCI Command: Broadcom Update UART Baud Rate (0x3f|0x0018) plen 6 >>>>>>> Encoded baud rate: Not used (0x0000) >>>>>>> Explicit baud rate: 2000000 Mbps >>>>>>>> HCI Event: Command Complete (0x0e) plen 4 >>>>>>> Broadcom Update UART Baud Rate (0x3f|0x0018) ncmd 1 >>>>>>> Status: Success (0x00) >>>>>>> < HCI Command: Reset (0x03|0x0003) plen 0 >>>>>>> >>>>>>> The HCI Reset command actually times out. >>>>>>> >>>>>>> [ 231.349802] Bluetooth: hci0 command 0x0c03 tx timeout >>>>>>> >>>>>>> What we really need is some kernel specific debug tracing when driv= er change baud rate etc. to show up in btmon. Drivers need the capability t= o insert HCI transport level specifics into monitoring interface. >>>>>> >>>>>> Thanks for noticing this, I've have that exact backlog sitting there >>>>>> to send out but I'd just not got to it yet, let me know if there's >>>>>> anything that needs tweaking on the Fedora side or patch. >>>>> >>>>> does it actually work for you? I didn=E2=80=99t get it running with t= he F27 kernel. I had issues with the initial baud rate using btattach in so= me cases. Does this go away if you use 115200 as max baud rate? >>>> >>>> No, not yet, I got to the point it would see an interface but that >>>> didn't have a MAC address, the patch series has also done something >>>> weird with serial consoles that I need to debug. I was wondering if it >>>> still needs the newer firmware rev that various distros have pulled >>>> in. >>> >>> is that the AA:AA:AA.. address? If so, we really need to blacklist that= one and mark it with quirk for invalid BD_ADDR. However I am not even gett= ing that far since the command above is the first command send to the hardw= are. >> >> No, it's all zeros, I'll try and spend some time on it this afternoon >> to reproduce what I was getting. > > please check if using 115200 baud rate does anything to make this work. A= t least that is what I had when testing this with btattach. It needed to be= 115200 and otherwise it would fail. > > We can load the firmware at 115200 and only switch later to a higher rate= . Maybe there are subtle difference in the default firmwares of the Bluetoo= th controller in the RPi3. > > Loic said that he had it working with a bluetooth-next and his patches. T= hat is something I have not succeeded with yet. So testing on a 32 bit image bluetoothctl doesn't see a controller, but hciconfig shows a controller with a zero mac, on a 64 bit image I see nothing using either method. # hciconfig hci0: Type: Primary Bus: UART BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0 DOWN RX bytes:14 acl:0 sco:0 events:1 errors:0 TX bytes:14 acl:0 sco:0 commands:2 errors:0 Hans added a script to automatically btattch some bcm controllers for atom devices, maybe we need to add more IDs for udev, not sure if there's a means of making that generic and upstreamable. Also some of the other distro patches I've seen had a different BT firmware, not sure if Loic needed that or not. https://src.fedoraproject.org/rpms/bluez/c/9089a629a195699747b1da0fa712e7ae= e76d7a90?branch=3Dmaster