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: Thu, 2 Nov 2023 16:14:53 +0200
From: George Shuklin <george.shuklin@...il.com>
To: Pavan Chebbi <pavan.chebbi@...adcom.com>
Cc: netdev@...r.kernel.org, Andrew Gospodarek
 <andrew.gospodarek@...adcom.com>, Michael Chan <michael.chan@...adcom.com>
Subject: Re: [PATCH] [PATCH net] tg3: power down device only on
 SYSTEM_POWER_OFF

On 11/2/23 09:04, Pavan Chebbi wrote:
> On Thu, Nov 2, 2023 at 1:28 AM George Shuklin <george.shuklin@...il.com> wrote:
>> On 01/11/2023 17:20, Pavan Chebbi wrote:
>>> On Wed, Nov 1, 2023 at 6:34 PM George Shuklin <george.shuklin@...il.com> wrote:
>>>> Dell R650xs servers hangs if tg3 driver calls tg3_power_down.
>>>>
>>>> This happens only if network adapters (BCM5720 for R650xs) were
>>>> initialized using SNP (e.g. by booting ipxe.efi).
>>>>
>>>> This is partial revert of commit 2ca1c94ce0b.
>>>>
>>>> The actual problem is on Dell side, but this fix allow servers
>>>> to come back alive after reboot.
>>> How are you sure that the problem solved by 2ca1c94ce0b is not
>>> reintroduced with this change?
>> I contacted the author of original patch, no reply yet (1st day). Also,
>> I tested it on few generations of available Dell servers (R330, R340,
>> R350 and R650sx, for which this fix should help). It does produce log
>> message from
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1917471, but, at
>> least, it reboots without issues.
>>
>> Actually, original patch is regression: 5.19 rebooting just fine, 6.0
>> start to hang. I also reported it to dell support forum, but I'm not
>> sure if they pick it up or not.
>>
>> What would be the proper course of actions for such problem (outside of
>> fixing UEFI SNP, for which I don't have access to sources)?
>>
> Thanks for the explanation. I am not sure if we should make this
> change unless we are 100pc sure that this patch won't cause
> regression.
> I feel Dell is in the best position to debug this and they can even
> contact Broadcom if they see any problem in UEFI.

I'm right now with dell support, and what they asked is to 'try this on 
supported distros', which at newest are 5.15. I'll try to bypass their 
L1 with Ubuntu + HWE to get to 6+ versions...

I was able to reproduce hanging at reboot there (without ACPI messages), 
and patching helps there too.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ