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]
Message-ID: <d095bcbe-af0c-4eb3-99c8-32371136dd2c@molgen.mpg.de>
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.)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ