linux-kernel - Re: Regression: Inoperative bluetooth, Intel chipset, mainline kernel 6.6.2+

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 1 Dec 2023 09:27:47 +0100
From:   Paul Menzel <pmenzel@...gen.mpg.de>
To:     "Kris Karas (Bug Reporting)" <bugs-a21@...nlit-rail.com>
Cc:     Bagas Sanjaya <bagasdotme@...il.com>,
        linux-bluetooth@...r.kernel.org, regressions@...ts.linux.dev,
        linux-kernel@...r.kernel.org,
        Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        Zach <zacheryvig@...look.com>
Subject: Re: Regression: Inoperative bluetooth, Intel chipset, mainline kernel
 6.6.2+

Dear Kris,


Am 01.12.23 um 09:19 schrieb Kris Karas (Bug Reporting):
> Bagas Sanjaya wrote:
>> Kris Karas (Bug Reporting) wrote:
>>> I have a regression going from mainline kernel 6.1.62 to 6.1.63, and 
>>> also
>>> from kernel 6.6.1 to 6.6.2; I can bisect if patch authors can't 
>>> locate the
>>> relevant commit.  In the most recent kernels mentioned, bluetooth won't
>>> function.
>>
>> Then please do bisection; without it, nobody will look into this 
>> properly.
> 
> As only a few people are reporting this, it must be pretty 
> hardware-specific (or perhaps Kconfig/firmware specific).  I'll do a 
> bisect.  A bit too late here in Boston (03:00), and kiddo's birthday 
> "later today", so will probably get to this on the weekend.
> 
>> You may also want to check current mainline (v6.7-rc3) to see if this
>> regression have already been fixed.
> 
> Just tried 6.7.0-rc3, and it is also affected.
> 
> I hadn't git-pulled my linux-stable since May, so that gave me a good 
> chance to test the very latest.  :-)  And conveniently I'm now set for 
> the bisect.

Nice, that is often the fastest way to fix something.

To avoid the time rebooting the system, you could try to expose the 
drive to a virtual machine [1].


Kind regards,

Paul


[1]: 
https://lore.kernel.org/all/331ae35c-7d48-46fc-c4ae-1e60cb0f3378@molgen.mpg.de/
      (The failure in the VM was due to another regression in the Linux 
kernel, so the how-to actually worked for me.)