Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 30

Thread: Fedora 20 Will Be Released Next Week

  1. #11
    Join Date
    Nov 2011
    Posts
    285

    Default

    Quote Originally Posted by Ericg View Post
    The post by Adam is: http://phoronix.com/forums/showthrea...068#post379068

    But keep in mind his wording is "I dont believe" and F20 is already shipping a Xorg 1.15 snapshot isnt it? So it may end up shipping regardless. Or they may selectively pull in the DRI3 and Present changes. Only time will tell right now

    Hold on, you were IN that thread, Bucic -_-
    No, Fedora 20 is shipping Xorg 1.14.
    I was, but I thought you speak of someone else by the name of Adam or that you have some info on the Adam's credibility.

    Quote Originally Posted by cynical View Post
    Distrowatch is great for getting info on versions of core packages, though I agree it's a nice thing to have on a distribution's website.
    Fedora packadges
    https://admin.fedoraproject.org/upda...5457102686f259
    http://phoronix.com/forums/showthrea...002#post379002
    https://fedoraproject.org/wiki/Releases/20/ChangeSet

  2. #12
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,876

    Default

    Quote Originally Posted by Bucic View Post
    or that you have some info on the Adam's credibility.
    Well as far as HIS credibility... He "works for Red Hat as the Fedora QA Community Monkey." lol

    https://fedoraproject.org/wiki/User:Adamwill

  3. #13
    Join Date
    Nov 2011
    Posts
    285

    Default

    Quote Originally Posted by Ericg View Post
    Well as far as HIS credibility... He "works for Red Hat as the Fedora QA Community Monkey." lol

    https://fedoraproject.org/wiki/User:Adamwill
    Well, at least RH has a community monkey I'm sure the Mutter guys have no QA monkeys.

    It would all mean that the only hope to get the tearing fixed is to report a bug against the Gnome-related issue on fedora's bugzilla. The only problem is my experience with such a scenario:
    Bug 977391 - Gnome Shell tearing on Sandy Bridge
    First, clueless about what is wrong with the animations, then - fails to connect the dots regarding the well known issue with mutter vs intel causing this, to finally abandon the bug altogether.

    Somewhat similar flow
    Bug 979551 - Disk produces regular clicking sound
    "this is just userspace" grinding your HDD mechanisms, I heard. Go figure.

  4. #14
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,876

    Default

    Quote Originally Posted by Bucic View Post
    Well, at least RH has a community monkey I'm sure the Mutter guys have no QA monkeys.

    It would all mean that the only hope to get the tearing fixed is to report a bug against the Gnome-related issue on fedora's bugzilla. The only problem is my experience with such a scenario:
    Bug 977391 - Gnome Shell tearing on Sandy Bridge
    First, clueless about what is wrong with the animations, then - fails to connect the dots regarding the well known issue with mutter vs intel causing this, to finally abandon the bug altogether.
    (I have a response to this, but im currently tracking down the source)

    Quote Originally Posted by Bucic;380527
    Somewhat similar flow
    [URL="https://bugzilla.redhat.com/show_bug.cgi?id=979551"
    Bug 979551 - Disk produces regular clicking sound [/URL]
    "this is just userspace" grinding your HDD mechanisms, I heard. Go figure.
    Well... Technically is probably buggy hard drive firmware that userspace is assuming is accurate. Time-to-spindown, at least in my experience, is measured in minutes. Like 5mniutes, 10 minutes and then it will spin down to conserve power. But in that bug the firmware is reporting a spin down time of (if we assume that its in seconds, and im not sure it is) 2 minutes and 43seconds.... Which is just odd. Its like when you see marker at a train station and its marked as platform "9 3/4" ( ) its just... wrong.

    So userspace is taking the firmware literally, the drive is spinning down. The heads are parking, hence the initial click. The heads spinback up when data is needed (which for a game installed on the hard drive, that would be... constantly) thats the second click. Firmware shuts down the drive again, click, powers it back up, click. Etc. TLP is trying to force a new value to the firmware, but the drive isnt accepting it. The safest thing for the user to do would be to turn off power-saving mode on the drive which can normally be done through hdparm, because obviously the firmware of the drive isn't responsible enough to handle it

  5. #15
    Join Date
    Nov 2011
    Posts
    285

    Default

    Quote Originally Posted by Ericg View Post
    (I have a response to this, but im currently tracking down the source)



    Well... Technically is probably buggy hard drive firmware that userspace is assuming is accurate. Time-to-spindown, at least in my experience, is measured in minutes. Like 5mniutes, 10 minutes and then it will spin down to conserve power. But in that bug the firmware is reporting a spin down time of (if we assume that its in seconds, and im not sure it is) 2 minutes and 43seconds.... Which is just odd. Its like when you see marker at a train station and its marked as platform "9 3/4" ( ) its just... wrong.

    So userspace is taking the firmware literally, the drive is spinning down. The heads are parking, hence the initial click. The heads spinback up when data is needed (which for a game installed on the hard drive, that would be... constantly) thats the second click. Firmware shuts down the drive again, click, powers it back up, click. Etc. TLP is trying to force a new value to the firmware, but the drive isnt accepting it. The safest thing for the user to do would be to turn off power-saving mode on the drive which can normally be done through hdparm, because obviously the firmware of the drive isn't responsible enough to handle it
    Technically I don't give a damn. Excuse my tone but IMO it's perfectly adequate to such attitude. Not yours, the maintainer's. I've reported the bug on Fedora's bugzilla, so if I have selected the wrong component a moderator (?) should change it, not ignore a bug that can damage hardware.

    Firmware? Bull. How many manhours does it take to implement a [Load_Cycle_Count delta > 5/min => disable power-saving mode] mechanism?

    Thanks for the hdparm tip. Your single post has been more helpful than the maintainers comments on the bug.

  6. #16
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,876

    Default

    Quote Originally Posted by Bucic View Post
    Technically I don't give a damn. Excuse my tone but IMO it's perfectly adequate to such attitude. Not yours, the maintainer's. I've reported the bug on Fedora's bugzilla, so if I have selected the wrong component a moderator (?) should change it, not ignore a bug that can damage hardware.

    Firmware? Bull. How many manhours does it take to implement a [Load_Cycle_Count delta > 5/min => disable power-saving mode] mechanism?

    Thanks for the hdparm tip. Your single post has been more helpful than the maintainers comments on the bug.
    No and I agree that the maintainer should've moved it to the proper category, but depending on the component's policy there may not be anything they can do. By that I mean, its the firmware's fault-- yell at the manufacturer. In the kernel you can post patches for Hardware Quirks, to compensate for buggy or inaccurate hardware (the laptop I am writing this from requires one such hardware quirk patch otherwise the backlight doesnt function correctly). But userspace... Maybe they wont accept hardware quirk patches, who knows.

    What it DOES come down to though is the firmware's fault. Linux adhere's to standards by default, so if the standard says XYZ then Linux assumes that anything claiming to be standards-complient will do XYZ, anything that breaks those assumptions is at fault. The one big exclusion to that I can think of is you can tell the kernel to report something other than Linux for ACPI, incase the hardware does one thing for Windows and another for Linux, and the Linux path is buggy.

  7. #17

    Default

    Quote Originally Posted by Ericg View Post
    The post by Adam is: http://phoronix.com/forums/showthrea...068#post379068

    But keep in mind his wording is "I dont believe" and F20 is already shipping a Xorg 1.15 snapshot isnt it?
    No. It includes xorg-x11-server-1.14.4. I don't think the graphics maintainers usually plan on major X or mesa version bumps within releases.

    Quote Originally Posted by Ericg View Post
    Or they may selectively pull in the DRI3 and Present changes. Only time will tell right now
    Backporting bugfixes is certainly something that happens, where it's practically possible and important enough to justify the time spent. Is there a clear bug report for whatever it is Bucic wants backported filed in bugzilla.redhat.com ?

  8. #18
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,876

    Default

    Quote Originally Posted by AdamW View Post
    No. It includes xorg-x11-server-1.14.4. I don't think the graphics maintainers usually plan on major X or mesa version bumps within releases.



    Backporting bugfixes is certainly something that happens, where it's practically possible and important enough to justify the time spent. Is there a clear bug report for whatever it is Bucic wants backported filed in bugzilla.redhat.com ?
    Bucic, and as a Sandy Bridge owner-- so do I, want the tearing fixed that occurs on Intel GPU's since the move to the Intel HD core. In order TO fix the tearing Fedora would have to backport all of the Present and DRI3 bits of both Mesa and Xorg 1.15, which honestly its really annoying that it didn't happen anyway because at the Xorg 1.15 Release Schedule planning meeting at XDC earlier this year the Fedora 20 release plan was specifically used as a reference point as to when Xorg 1.15 would have to be released by to get it into the F20 Beta in time.

    There's clutter and GTK environment variable workarounds available, but they dont work all the time to actually prevent the tearing that occurs.

    Bug Report: https://bugzilla.redhat.com/show_bug.cgi?id=977391

  9. #19
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,876

    Default

    Quote Originally Posted by Bucic View Post
    Well, at least RH has a community monkey I'm sure the Mutter guys have no QA monkeys.

    It would all mean that the only hope to get the tearing fixed is to report a bug against the Gnome-related issue on fedora's bugzilla. The only problem is my experience with such a scenario:
    Bug 977391 - Gnome Shell tearing on Sandy Bridge
    First, clueless about what is wrong with the animations, then - fails to connect the dots regarding the well known issue with mutter vs intel causing this, to finally abandon the bug altogether.
    Tracked down the source:

    Keith Packard-- Future Directions Of The X Window System -- Linux.conf.au 2013
    http://www.youtube.com/watch?v=u8gqB301PbY&html5=1

    Jump to the following timestamps:
    1) 04:20
    2) 21:00-22:00
    3) 48:10

    Tearing on Sandy Bridge, Ivy Bridge (not sure if Haswell) is caused by hardware engineers removing a feature related to Scan-Out during the jump to the "Intel HD" graphics core. The only REAL solution is DRI3 + Present

  10. #20
    Join Date
    Nov 2011
    Posts
    285

    Default

    Quote Originally Posted by Ericg View Post
    But userspace... Maybe they wont accept hardware quirk patches, who knows.
    Could you clarify, who do you mean by 'userspace' with regard to the case we discuss?

    Quote Originally Posted by Ericg View Post
    What it DOES come down to though is the firmware's fault. Linux adhere's to standards by default, so if the standard says XYZ then Linux assumes that anything claiming to be standards-complient will do XYZ, anything that breaks those assumptions is at fault. The one big exclusion to that I can think of is you can tell the kernel to report something other than Linux for ACPI, incase the hardware does one thing for Windows and another for Linux, and the Linux path is buggy.
    I get that, I do. But at the same time there's something like fail-safe mechanisms. In our case such mechanism would cost squat. The reason it's not implemented for the 'click-clack' is not high manhours but, most probably, that nobody gives a rats buttocks. As I see this is an issue that's known for years and across distributions
    http://forum.linuxmint.com/viewtopic.php?f=49&t=94336
    askubuntu.com/questions/82803/hard-drive-clicking-noise-on-acer-ao722
    askubuntu.com/questions/60078/laptops-hard-drive-doesnt-really-spin-down/

    Back to the fail-safe. Call it overly dramatic, but fail-safe is what actually kept alive anybody who took flight more than 50 times. What I'm saying here is that non-standard implementations happen and WILL happen. Linux devs can't just ignore the reality. Just watch some Matthew Garrett's presentations on UEFI.





    Quote Originally Posted by AdamW View Post
    Is there a clear bug report for whatever it is Bucic wants backported filed in bugzilla.redhat.com ?
    Reported both on gnome's and redhat's bugzilla (just as a reminder):
    Bug 977391 - Gnome Shell tearing ... - bugzilla.redhat.com
    Bug 711028 - Tearing on Intel GPU - the CLUTTER_PAINT workaround

    Please note that my hardware is not Sandy Bridge. I've misidentified my hardware. Since I was not getting any input on redhat's bugzilla I've updated only the bug description on bugzilla.gnome.org
    Also please do report back if you learn of anything new on the subject.

    Quote Originally Posted by Ericg View Post
    Bucic, and as a Sandy Bridge owner-- so do I, want the tearing fixed that occurs on Intel GPU's since the move to the Intel HD core. In order TO fix the tearing Fedora would have to backport all of the Present and DRI3 bits of both Mesa and Xorg 1.15, which honestly its really annoying that it didn't happen anyway because at the Xorg 1.15 Release Schedule planning meeting at XDC earlier this year the Fedora 20 release plan was specifically used as a reference point as to when Xorg 1.15 would have to be released by to get it into the F20 Beta in time.

    There's clutter and GTK environment variable workarounds available, but they dont work all the time to actually prevent the tearing that occurs.

    Bug Report: https://bugzilla.redhat.com/show_bug.cgi?id=977391
    I know the particular bug report and the workaround now. Isn't it grand? At least two generations of Intel graphics affected by a bug that is present for 12 months? This kind of stuff is exactly what makes me look like a damn fool when I advocate for Linux.

    On the workaround. It's exactly that, a workaround. It doesn't restore the proper performance and it isn't conservative on resources, since it redraws entire image every time.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •