3 ms·

Ok, I'll bite, here's a good example... Working for a large institution that heavily employs the latest hardware we stumbled upon an issue with tsc calibration

Ok, I'll bite, here's a good example... Working for a large institution that heavily employs the latest hardware we stumbled upon an issue with tsc calibration on skylake platforms with overclocked BCLK. The issue stemmed from the fact that cpuid for our particular SKU returned nominal instead of actual tsc frequency. We submitted a simple patch that just introduced a kcmdline parameter to disable cpuid based calibration and fall back to msr-based method that works fine. The maintainer shot it down only because _in theory_ the cpuid method should work even for over clocked cases. In practice an Intel person admitted that the firmware for our particular SKU should be updated to fix this. Over two years later Intel still didn't release fw update and our simple patch hasn't been accepted because the maintainer sees the world as a perfect place. You know who helped us? RedHat. They saw the value of adding this workaround to allow their users use Linux even if it was the cpu vendor that messed up. Now tell me, how is this welcoming attitude on Linux kernel part? How can you blame me for my opinion when a partial fix to a real problem gets rejected for completely academic reasons?

encryptluks2 5y ago
Where is the mailing list thread discussing the fix? I'd need more context. It does sound like Intel admitted that they need to update the firmware to resolve this. Are you loading the Intel microcode? I found a related patch here: https://lkml.org/lkml/2008/9/29/178 https://lkml.org/lkml/2008/9/29/178
- bitcharmer 5y ago
  Skylake was launched in 2015. Why someone would think we submitted a patch 7 years before that date is beyond me. Maybe you haven't read my comment after all, I get that impression on LKML sometimes... Anyway, here it is: https://lkml.org/lkml/2018/7/13/631 https://lkml.org/lkml/2018/7/13/631
  - encryptluks2 5y ago
    I didn't think that was you, I just thought it was related and an example of how a similar patch could get approved. I looked at your example, and I'm sorry that you thought I was doubting you but it looks like that everything was resolved satisfactorily based on what I read for you. I didn't get the impression they were saying no, just that there was other ways to do it.
    - bitcharmer 5y ago
      > everything was resolved satisfactorily What part of "our fix was not accepted" do you deem as "resolved satisfactory". I provided you with a broad context and a reference to the original discussion that clearly shows there was opposition against a practical solution and a lack of promised fix on the hw-side, and you still have the audacity to say it was "resolved". The patch was not accepted into the mainline, so please explain what you mean when you say the problem was resolved? Resolved how? This is exactly what drives practitioners like myself away from contributing to the kernel.
      - janto 5y ago
        It doesn't look like you're that good at "reducing tension", as you describe it in your initial post. Maybe you should not be contributing to the kernel then?

encryptluks2 5y ago

Where is the mailing list thread discussing the fix? I'd need more context. It does sound like Intel admitted that they need to update the firmware to resolve this. Are you loading the Intel microcode? I found a related patch here: https://lkml.org/lkml/2008/9/29/178 https://lkml.org/lkml/2008/9/29/178

bitcharmer 5y ago
Skylake was launched in 2015. Why someone would think we submitted a patch 7 years before that date is beyond me. Maybe you haven't read my comment after all, I get that impression on LKML sometimes... Anyway, here it is: https://lkml.org/lkml/2018/7/13/631 https://lkml.org/lkml/2018/7/13/631
- encryptluks2 5y ago
  I didn't think that was you, I just thought it was related and an example of how a similar patch could get approved. I looked at your example, and I'm sorry that you thought I was doubting you but it looks like that everything was resolved satisfactorily based on what I read for you. I didn't get the impression they were saying no, just that there was other ways to do it.
  - bitcharmer 5y ago
    > everything was resolved satisfactorily What part of "our fix was not accepted" do you deem as "resolved satisfactory". I provided you with a broad context and a reference to the original discussion that clearly shows there was opposition against a practical solution and a lack of promised fix on the hw-side, and you still have the audacity to say it was "resolved". The patch was not accepted into the mainline, so please explain what you mean when you say the problem was resolved? Resolved how? This is exactly what drives practitioners like myself away from contributing to the kernel.
    - janto 5y ago
      It doesn't look like you're that good at "reducing tension", as you describe it in your initial post. Maybe you should not be contributing to the kernel then?