|
From: Hans de G. <hde...@re...> - 2019-04-18 13:09:25
|
Hi, On 09-04-19 17:31, Andy Shevchenko wrote: > On Mon, Apr 08, 2019 at 08:43:10PM +0200, Hans de Goede wrote: >> On 08-04-19 19:21, Andy Shevchenko wrote: >>> On Thu, Apr 04, 2019 at 04:43:03PM +0200, Hans de Goede wrote: >>>> On 29-03-19 16:53, Hans de Goede wrote: >>>>> On 3/29/19 2:59 PM, Семен Верченко wrote: >>> >>>>> Hmm, so 4 ethernet cards and 4 enabled / marked as critical clocks. >>>>> >>>>> Supporting this through get_clk is going to require a DMI table in the igb driver >>>>> combined with checking which PCI "slot" the card is to get the correct clock >>>>> for each ethernet controller. >>>>> >>>>> I believe tht just restoring the old behavior to mark all clocks enabled >>>>> on boot as critical, but then limited to this system based on a dmi match, >>>>> is the best solution here. >>>>> >>>>> Andy? >>>> >>>> Andy? Now that we've the patch ready for the other system which needs to >>>> have the CLK_IS_CRITICAL workaround and enables this based on DMI info, >>>> I believe the best fix for this system is to simply add it to that DMI >>>> table? >>> >>> I reviewed v4, supposed to go via CLK tree. >> >> Right, but that patch adds the quirk for the system with the USB hub, >> do you agree, that given that each ethernet controller seems to be >> using its own clock, it is best to use a DMI quirk for this case too? >> >> If you agree then someone needs to prepare a follow-up patch on top of >> v4 which adds the DMI info for this board to the table. > > I hope we may find a better solution in the future, but for now as a quick fix > the proposed can be done. Ok. Семен Верченко, this means that we are going to need DMI info from the board in question. I thought we already had that, but I now see that you original report did not have that a Please run as root: dmidecode &> dmidecode.log And then reply to this email with the generated dmidecode.log file attached. Once I have that file I can prepare a patch fixing this. Regards, Hans |