linux-kbuild.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Marcel Holtmann <marcel@holtmann.org>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	TatriX <tatrics@gmail.com>,
	Masahiro Yamada <masahiroy@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Regressions <regressions@lists.linux.dev>,
	Linux Bluetooth <linux-bluetooth@vger.kernel.org>,
	Linux Kernel Build System <linux-kbuild@vger.kernel.org>
Subject: Fwd: Bluetooth LE scan doesn't show device name
Date: Tue, 8 Aug 2023 20:44:36 +0700	[thread overview]
Message-ID: <97224321-c839-c0a7-52dd-3fb6e52fc15e@gmail.com> (raw)

Hi,

I notice a regression report on Bugzilla [1]. Quoting from it:

> Hi!
> At some point after kernel 5.9 I started having issues with LE device scanning.
> Here's how it used to work:
> 
>     $ bluetoothctl
>     # power on
>     # scan on
>      ...
>     [NEW] Device 68:71:DD:73:97:D5 Playfinity-2
> 
> It successfully finds my device and it's name.
> On a newer kernel instead I'm getting no name:
> 
>     [NEW] Device 4D:18:19:A8:63:B5 4D-18-19-A8-63-B5
> 
> Here's corresponding btmon logs. First from kernel 5.9.12 that can see device's name:
> 
> ```5.9.12
>> HCI Event: LE Meta Event (0x3e) plen 33                  #118 [hci0] 5.607028
>       LE Extended Advertising Report (0x0d)
>         Num reports: 1
>         Entry 0
>           Event type: 0x0013
>             Props: 0x0013
>               Connectable
>               Scannable
>               Use legacy advertising PDUs
>             Data status:  [0;32mComplete [0m
>           Legacy PDU Type: ADV_IND (0x0013)
>           Address type: Random (0x01)
>           Address: 68:71:DD:73:97:D5 (Resolvable)
>           Primary PHY: LE 1M
>           Secondary PHY: No packets
>           SID: no ADI field (0xff)
>           TX power: 127 dBm
>           RSSI: -54 dBm (0xca)
>           Periodic advertising interval: 0.00 msec (0x0000)
>           Direct address type: Public (0x00)
>           Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
>           Data length: 0x07
>         02 01 06 03 02 f0 ff                             .......
>         Flags: 0x06
>           LE General Discoverable Mode
>           BR/EDR Not Supported
>         16-bit Service UUIDs (partial): 1 entry
>           Unknown (0xfff0)
>> HCI Event: LE Meta Event (0x3e) plen 49                  #119 [hci0] 5.608029
>       LE Extended Advertising Report (0x0d)
>         Num reports: 1
>         Entry 0
>           Event type: 0x001b
>             Props: 0x001b
>               Connectable
>               Scannable
>               Scan response
>               Use legacy advertising PDUs
>             Data status:  [0;32mComplete [0m
>           Legacy PDU Type: SCAN_RSP to an ADV_SCAN_IND (0x001b)
>           Address type: Random (0x01)
>           Address: 68:71:DD:73:97:D5 (Resolvable)
>           Primary PHY: LE 1M
>           Secondary PHY: No packets
>           SID: no ADI field (0xff)
>           TX power: 127 dBm
>           RSSI: -54 dBm (0xca)
>           Periodic advertising interval: 0.00 msec (0x0000)
>           Direct address type: Public (0x00)
>           Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
>           Data length: 0x17
>         0d 09 50 6c 61 79 66 69 6e 69 74 79 2d 32 02 0a  ..Playfinity-2..
>         00 05 12 50 00 68 00                             ...P.h.
>         Name (complete): Playfinity-2
>         TX power: 0 dBm
>         Peripheral Conn. Interval: 0x0050 - 0x0068
> ```
> 
> And from 6.4.8:
> 
> ```6.4.8
>> HCI Event: LE Meta Event (0x3e) plen 33                  #130 [hci0] 9.180207
>       LE Extended Advertising Report (0x0d)
>         Num reports: 1
>         Entry 0
>           Event type: 0x0013
>             Props: 0x0013
>               Connectable
>               Scannable
>               Use legacy advertising PDUs
>             Data status: �[0;32mComplete�[0m
>           Legacy PDU Type: ADV_IND (0x0013)
>           Address type: Random (0x01)
>           Address: 4D:18:19:A8:63:B5 (Resolvable)
>           Primary PHY: LE 1M
>           Secondary PHY: No packets
>           SID: no ADI field (0xff)
>           TX power: 127 dBm
>           RSSI: -53 dBm (0xcb)
>           Periodic advertising interval: 0.00 msec (0x0000)
>           Direct address type: Public (0x00)
>           Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
>           Data length: 0x07
>         02 01 06 03 02 f0 ff                             .......
>         Flags: 0x06
>           LE General Discoverable Mode
>           BR/EDR Not Supported
>         16-bit Service UUIDs (partial): 1 entry
>           Unknown (0xfff0)
> ```
> 
> I've tried compiling 5.9.12 to see if I can bissect, but it fails to compile with gcc12..
> 
> Is it expected that newer kernels can't get device name? Perhaps some additional action is needed fetch it?
>  
> Thanks!

See Bugzilla for the full thread.

TatriX: Can you also attach dmesg output to your Bugzilla report?
Since you also have kernel build problem, can you also attach build
log (``make 2>&1 | tee build.log``)?

Anyway, I'm adding this regression to be tracked by regzbot:

#regzbot introduced: v5.9..v6.4 https://bugzilla.kernel.org/show_bug.cgi?id=217773

Thanks.

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217773

-- 
An old man doll... just what I always wanted! - Clara

             reply	other threads:[~2023-08-08 19:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-08 13:44 Bagas Sanjaya [this message]
2023-08-09  8:16 ` Bluetooth LE scan doesn't show device name TatriX
2023-09-09  5:28 ` Fwd: " Bagas Sanjaya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=97224321-c839-c0a7-52dd-3fb6e52fc15e@gmail.com \
    --to=bagasdotme@gmail.com \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=masahiroy@kernel.org \
    --cc=regressions@lists.linux.dev \
    --cc=tatrics@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).