4 ms·

This version has got to be the worst kernel released in a while in terms of regression, from AMDGPU null pointer dereference crash[0] to f2fs data corruption bu

by esgwpl 6y ago

This version has got to be the worst kernel released in a while in terms of regression, from AMDGPU null pointer dereference crash[0] to f2fs data corruption bug[1] and now this. Fixes for these are on their way as far as I can tell but since the stable team are probably on Christmas vacation it might take a while. [0] https://bbs.archlinux.org/viewtopic.php?pid=1943906#p1943906 https://bbs.archlinux.org/viewtopic.php?pid=1943906#p1943906 [1] https://bugzilla.kernel.org/show_bug.cgi?id=210765 https://bugzilla.kernel.org/show_bug.cgi?id=210765

gregkh 6y ago
I get a vacation? Hah!
- nasir_hm 6y ago
  Thank You very much for the hard work you do Greg, You're awesome :D
- mr_sturd 6y ago
  Merry Christmas, Greg!
- muxator 6y ago
  Thanks for your work, Greg!
- tuldia 6y ago
  Every software has bugs, and is easier to criticize than to help. Don't focus on the negativity of HN and keep it up! Thanks for your hard work, Greg!
  - gregkh 6y ago
    If people don't report bugs, we don't know they are there as it "works for me!". This isn't "negativity", this is people not understanding how the process works :) And you're welcome!
    - Skunkleton 6y ago
      These are some attitude goals for me. It's so easy to take things personally. Being able to take things constructively even when they might be personal is a great skill.
    - mike256 6y ago
      As every patch nowadays means that yet another symbol gets his gpl-only tag, no I don't report bugs...
- gruturo 6y ago
  Thank you for your hard work Greg, it is very much appreciated. Merry Christmas/Isaac Newton's Birthday!
- esgwpl 6y ago
  Sorry if my post sounds like a jab, it wasn't meant to be, thanks for your work and Merry Christmas.
- fatboy93 6y ago
  You should a small vacation sometime ;) Bugs can always be fixed, mental health can't. Thanks for all the awesome work Greg!
- GayChromulent 6y ago
  Hahaha, found the faggots. Everyone knows that anyone who cheers greg croan heartman is a faggot, exept his well established wife. What linus and he does in the sauna is not up to us, but, I mean everyone who comments under here is a full blooded faggot. Which is not wrong.
- malikolivier 6y ago
  Merry Christmas, Greg! Thanks for all the hard work!
tremon 6y ago
And the fstrim issue: http://lkml.iu.edu/hypermail/linux/kernel/2012.1/01288.html http://lkml.iu.edu/hypermail/linux/kernel/2012.1/01288.html Which triggered an immediate 5.10.1 release: http://lkml.iu.edu/hypermail/linux/kernel/2012.1/07005.html http://lkml.iu.edu/hypermail/linux/kernel/2012.1/07005.html
diegocg 6y ago
5.10 is a Long Term Support release that is going to get used by many distros for a long time. Maintainers might have tried (unsurprisingly) to get some interesting features merged.
est31 6y ago
On the bright side updating to 5.10 fixed a regression of a 5.4 to 5.8 kernel upgrade to me. The fix might have been in 5.9 but I only got the idea of upgrading after the 5.10 release. Anyways, Linux needs some more CI so that such bugs can be found during the RC phase.
- gregkh 6y ago
  Where in the current CI that we have today is lacking that needs to be improved? We always want more testing and testers, what is preventing everyone from helping with this?
  - dlgeek 6y ago
    I'll bite: How can I help? I'm a software engineer who's not involved in Linux Kernel Dev... but I've got a stack of old laptops that I'd be happy to set up to run automated CI if that'd be helpful. Is there a webpage or doc somewhere I can look at? (I'm not trying to snark - the fact that you're you and you're here asking for help is making me want to dip my toe in).
    - gregkh 6y ago
      Simplest thing to do, just run Linus's latest releases (the -rc releases), or from his git tree, on your machine and report any problem. Second-simplest thing to do is to run the linux-next branch/tree on your machines and report any build warnings and runtime issues you find. That's what will be the "next" kernel releases and is where all of the developer/maintainer trees are merged together before they are sent to Linus. Both of those should be very easy to do, and any problems found there should be easy to fix and resolve before they get to a "real" release.
  - nitrogen 6y ago
    I haven't been following kernel dev for years; what does the CI setup look like? Did the Phoronix Test Suite ever find its way into widespread use? Back when I was building kernels for embedded hardware (Sheevaplug) in the 2.6.33 timeframe, I found a USB audio regression between 2.6.33.7 and later versions. If there were a semi-turnkey way to set up a testbench that could automatically reboot hardware in every new kernel, run through some basic tests, and report any deviation, I probably would have been more likely to do so. At the time I was working solo trying to release a polished consumer product (sadly though the product was released the business didn't work out) and didn't have time to dig into and report bugs.
fluffy87 6y ago
How is the kernel tested ? There weren’t any tests covering any of this ?
- rstuart4133 6y ago
  > How is the kernel tested ? There weren’t any tests covering any of this ? Despite appearances, "the kernel" is not a single monolithic thing. There is a about a 100 kloc core (but I haven't looked up that number in years). The rest, hardware drivers, network protocols, file systems, crypto, raid ... bolt on as modules. Those modules are maintained separate teams. They are as related to the kernel as the phone dialler app is related to Android. The quality of each module is the responsibility of that team, not "the kernel" team. And that applies to testing the module as well. In a sense, "the kernel" team is more like debian or redhat than developers. What they have done is develop a framework that lets them take bits created and maintained by a cast of thousands, and bolt it together into what appears to be a single coherent thing from the outside. So the answer to "how is the kernel tested" is "it's complex, and not centrally planned". The other answer is what you are seeing is in fact part of the testing process. Most people use kernels packaged by their distribution. kernel.org releases are more like Microsoft's pre-releases of Windows. Most Debian users for example won't see it until it gets to Debian testing. To get there it must pass through Debian experimental (which is where 5.10 sits now) then sit in Debian unstable without bug reports for a while. Those release names should give you a hint about the anticipated stability of the kernel version. I personally won't use it until it takes another step, which is from Debian testing to Debian backports (which is when it because available to Debian stable users who are willing to risk compatibility issues). This means that for for most users, 5.10 it's done yet as it has barely begun it's testing regime.

by esgwpl 6y ago

gregkh 6y ago

I get a vacation? Hah!

nasir_hm 6y ago
Thank You very much for the hard work you do Greg, You're awesome :D
mr_sturd 6y ago
Merry Christmas, Greg!
muxator 6y ago
Thanks for your work, Greg!
tuldia 6y ago
Every software has bugs, and is easier to criticize than to help. Don't focus on the negativity of HN and keep it up! Thanks for your hard work, Greg!
- gregkh 6y ago
  If people don't report bugs, we don't know they are there as it "works for me!". This isn't "negativity", this is people not understanding how the process works :) And you're welcome!
  - Skunkleton 6y ago
    These are some attitude goals for me. It's so easy to take things personally. Being able to take things constructively even when they might be personal is a great skill.
  - mike256 6y ago
    As every patch nowadays means that yet another symbol gets his gpl-only tag, no I don't report bugs...
gruturo 6y ago
Thank you for your hard work Greg, it is very much appreciated. Merry Christmas/Isaac Newton's Birthday!
esgwpl 6y ago
Sorry if my post sounds like a jab, it wasn't meant to be, thanks for your work and Merry Christmas.
fatboy93 6y ago
You should a small vacation sometime ;) Bugs can always be fixed, mental health can't. Thanks for all the awesome work Greg!
GayChromulent 6y ago
Hahaha, found the faggots. Everyone knows that anyone who cheers greg croan heartman is a faggot, exept his well established wife. What linus and he does in the sauna is not up to us, but, I mean everyone who comments under here is a full blooded faggot. Which is not wrong.
malikolivier 6y ago
Merry Christmas, Greg! Thanks for all the hard work!

tremon 6y ago

And the fstrim issue: http://lkml.iu.edu/hypermail/linux/kernel/2012.1/01288.html http://lkml.iu.edu/hypermail/linux/kernel/2012.1/01288.html Which triggered an immediate 5.10.1 release: http://lkml.iu.edu/hypermail/linux/kernel/2012.1/07005.html http://lkml.iu.edu/hypermail/linux/kernel/2012.1/07005.html

diegocg 6y ago

5.10 is a Long Term Support release that is going to get used by many distros for a long time. Maintainers might have tried (unsurprisingly) to get some interesting features merged.

est31 6y ago

On the bright side updating to 5.10 fixed a regression of a 5.4 to 5.8 kernel upgrade to me. The fix might have been in 5.9 but I only got the idea of upgrading after the 5.10 release. Anyways, Linux needs some more CI so that such bugs can be found during the RC phase.

gregkh 6y ago
Where in the current CI that we have today is lacking that needs to be improved? We always want more testing and testers, what is preventing everyone from helping with this?
- dlgeek 6y ago
  I'll bite: How can I help? I'm a software engineer who's not involved in Linux Kernel Dev... but I've got a stack of old laptops that I'd be happy to set up to run automated CI if that'd be helpful. Is there a webpage or doc somewhere I can look at? (I'm not trying to snark - the fact that you're you and you're here asking for help is making me want to dip my toe in).
  - gregkh 6y ago
    Simplest thing to do, just run Linus's latest releases (the -rc releases), or from his git tree, on your machine and report any problem. Second-simplest thing to do is to run the linux-next branch/tree on your machines and report any build warnings and runtime issues you find. That's what will be the "next" kernel releases and is where all of the developer/maintainer trees are merged together before they are sent to Linus. Both of those should be very easy to do, and any problems found there should be easy to fix and resolve before they get to a "real" release.
- nitrogen 6y ago
  I haven't been following kernel dev for years; what does the CI setup look like? Did the Phoronix Test Suite ever find its way into widespread use? Back when I was building kernels for embedded hardware (Sheevaplug) in the 2.6.33 timeframe, I found a USB audio regression between 2.6.33.7 and later versions. If there were a semi-turnkey way to set up a testbench that could automatically reboot hardware in every new kernel, run through some basic tests, and report any deviation, I probably would have been more likely to do so. At the time I was working solo trying to release a polished consumer product (sadly though the product was released the business didn't work out) and didn't have time to dig into and report bugs.

fluffy87 6y ago

How is the kernel tested ? There weren’t any tests covering any of this ?

rstuart4133 6y ago
> How is the kernel tested ? There weren’t any tests covering any of this ? Despite appearances, "the kernel" is not a single monolithic thing. There is a about a 100 kloc core (but I haven't looked up that number in years). The rest, hardware drivers, network protocols, file systems, crypto, raid ... bolt on as modules. Those modules are maintained separate teams. They are as related to the kernel as the phone dialler app is related to Android. The quality of each module is the responsibility of that team, not "the kernel" team. And that applies to testing the module as well. In a sense, "the kernel" team is more like debian or redhat than developers. What they have done is develop a framework that lets them take bits created and maintained by a cast of thousands, and bolt it together into what appears to be a single coherent thing from the outside. So the answer to "how is the kernel tested" is "it's complex, and not centrally planned". The other answer is what you are seeing is in fact part of the testing process. Most people use kernels packaged by their distribution. kernel.org releases are more like Microsoft's pre-releases of Windows. Most Debian users for example won't see it until it gets to Debian testing. To get there it must pass through Debian experimental (which is where 5.10 sits now) then sit in Debian unstable without bug reports for a while. Those release names should give you a hint about the anticipated stability of the kernel version. I personally won't use it until it takes another step, which is from Debian testing to Debian backports (which is when it because available to Debian stable users who are willing to risk compatibility issues). This means that for for most users, 5.10 it's done yet as it has barely begun it's testing regime.