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: <4aa4b757-13eb-4653-99eb-16aec7c8a3d9@tuxedocomputers.com>
Date: Thu, 21 Dec 2023 13:20:59 +0100
From: Werner Sembach <wse@...edocomputers.com>
To: Greg KH <greg@...ah.com>
Cc: Andreas Noever <andreas.noever@...il.com>,
 Michael Jamet <michael.jamet@...el.com>,
 Mika Westerberg <mika.westerberg@...ux.intel.com>,
 Yehezkel Bernat <YehezkelShB@...il.com>, linux-usb@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] thunderbolt: Reduce retry timeout to speed up boot for
 some devices


Am 20.12.23 um 17:04 schrieb Greg KH:
> On Wed, Dec 20, 2023 at 04:23:15PM +0100, Werner Sembach wrote:
>> Am 20.12.23 um 16:09 schrieb Werner Sembach:
>>> This is a followup to "thunderbolt: Workaround an IOMMU fault on certain
>>> systems with Intel Maple Ridge".
>>>
>>> It seems like the timeout can be reduced to 250ms. This reduces the overall
>>> delay caused by the retires to ~1s. This is about the time other things
>>> being initialized in parallel need anyway*, so like this the effective boot
>>> time is no longer compromised.
>>>
>>> *I only had a single device available for my measurements: A Clevo X170KM-G
>>> desktop replacement notebook.
>>>
>>> Signed-off-by: Werner Sembach <wse@...edocomputers.com>
>> I wonder if this could also land in stable? Or would it be to risky?
> If it's really a bugfix now, why would it _not_ be relevant for stable?

edit: Sorry if this is the 3rd time I send this, I got mail server 
errors (hopefully fixed now) and am not sure if it reached out

Because it changes a timeout that could cause issues if set to low: This 
Patch sets to to 250ms. Set to 50ms it causes issues, currently it's 
2000ms, 2 people tested that 250ms is enough, but i don't know if this 
is a big enough sample size for stable.

The advantage is significantly faster boot time on affected devices 
(~12s down to ~3s), however they do already work fine without it.

Kind regards,

Werner

>
> thanks,
>
> greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ