Announcement

Collapse
No announcement yet.

System Freeze on Switch user

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Still happens in fglrx 9.1. Switch user and you go straight to hard-lock hell.

    Hey, bridgeman. Would you be kind and pass this information to the fglrx-developers. I can't see no explanation other than they don't know about this bug.

    Comment


    • #12
      Just to be clear, a problem with VT switch or user switch is usually not a driver bug per se; this is one of the ugly weaknesses of the current Linux graphics model which KMS is intended to fix.

      When you do a user switch you are handing off control from one driver to another (in this case to a kernel driver we didn't write and which varies from distro to distro) and if the N drivers don't all treat the hardware in the same way then "unspecified bad things" happen. It's not a question of "fixing the bug", but more of stuffing the driver full of tweaks and workarounds for each problematic distro and kernel you encounter.

      I have to think that eventually we will be able to duplicate all of the problem situations and put in tweaks for all of them (there are only so many different ways to run graphics drivers in the kernel). The open source drivers seem to be ahead in that respect because they bring the source code to the system that is having problems; in the closed source case we need to be able to reproduce the problem you are seeing on a system our developers can touch, which is much more difficult than you might imagine. Most of the posts here assume that every bug visible on user X's system also occurs on our development and test systems, but that is simply not the case.
      Last edited by bridgman; 31 January 2009, 12:10 PM.
      Test signature

      Comment


      • #13
        Ok, so you say that this is not a bug in the fglrx driver, although it's only happening when the fglrx driver is in use? All the other drivers are able to switch user without any problem. Did I understand you correctly?

        Then the question is: What the h-ll can I do to help fix this?

        Comment


        • #14
          Pretty much. I guess the two main points I am trying to make are :

          1. This isn't something you fix once, it's more like cutting the grass; new combinations of other components keep showing up and every time they do you need to tweak the driver to deal with the new quirks

          2. This isn't something that happens on our systems and we ignore; each time there's a problem we need to pretty much duplicate the user's system in house to repro the problem so that a developer can do something about it. We usually pick off a couple of these problems every month but there's no "magic fix" that will make all the problems go away; you just accumulate the tweaks over time.

          Make sense ? AFAIK these kind of problems usually need to be addressed by changing fglrx, at least that's what is done today. I have a nagging feeling that this is one of those "chasing a problem around the room" issues which would be better solved by changing the kernel drivers to make them more consistent (and consistent with our drivers) but I haven't had a chance to look into that.

          In terms of helping to fix it, I think the best thing is making sure that when our devs have time to pick off a few more VT issues that the information in the informal bugzilla is clear and complete. Notes about whether the problem occurs with the open source drivers (and which version of the drivers you were using) is probably also a big help, but I need to confirm that with the devs.
          Last edited by bridgman; 31 January 2009, 01:00 PM.
          Test signature

          Comment


          • #15
            I'm struggling to understand your point here.

            If I switch user, I am going from an X-session using fglrx to another X-session using fglrx (or I would be if it didn't lockup). Where is the other driver involvement you speak of?

            I don't have any problem going from X-session to VT and back again, just when trying to start an additional X-session.

            I've never heard of any other driver being unable to do this, and I've tried quite a few over the 10 years I've been using Linux. It works fine with radeonhd, but last time I tried that driver I couldn't watch video so it was no use to me.

            Do you know of anyone who can successfully switch user using the fglrx driver? Lots of people have mentioned here that they can't do it, and I've never seen anyone say that it works for them.

            I've tried on Debian and Ubuntu with 2 different ATI cards, and it didn't work on any setup I've attempted it on.
            Last edited by duffster; 31 January 2009, 01:42 PM.

            Comment


            • #16
              Originally posted by bridgman View Post
              Just to be clear, a problem with VT switch or user switch is usually not a driver bug per se; this is one of the ugly weaknesses of the current Linux graphics model which KMS is intended to fix.

              When you do a user switch you are handing off control from one driver to another (in this case to a kernel driver we didn't write and which varies from distro to distro) and if the N drivers don't all treat the hardware in the same way then "unspecified bad things" happen. It's not a question of "fixing the bug", but more of stuffing the driver full of tweaks and workarounds for each problematic distro and kernel you encounter.

              I have to think that eventually we will be able to duplicate all of the problem situations and put in tweaks for all of them (there are only so many different ways to run graphics drivers in the kernel). The open source drivers seem to be ahead in that respect because they bring the source code to the system that is having problems; in the closed source case we need to be able to reproduce the problem you are seeing on a system our developers can touch, which is much more difficult than you might imagine. Most of the posts here assume that every bug visible on user X's system also occurs on our development and test systems, but that is simply not the case.
              Bridgman, this appears to be a fairly common bug amongst Ubuntu users. Perhaps the AMD driver team could fix this problem for the most common distros? (ie. Ubuntu and Fedora 32 and 64 bit). All my Ubuntu systems using fglrx are certainly affected by this nasty bug; however, the OSS drivers are not.

              Comment


              • #17
                Originally posted by duffster View Post
                I don't have any problem going from X-session to VT and back again, just when trying to start an additional X-session.
                Yes, exactly. From X to VT, no problemo. To new x-session: Hard Lock Hell. Not even SysRq RSEIUB works. And I can't even SSH in to the box. Nothing works, not even Caps-lock or Num-lock leds.

                Before I bought my HD3870 I had a X600 which had no problem with switching users. But ever since that card went bananas and I bought my new card (I stayed with ATI because my X600 was so problem free) I ran in to this situation. Nothing else has changed on my systems hardware. Just the graphics card.

                Comment


                • #18
                  duffster; as I understand it doing an X switch actually goes through the VT switch path on the way; not 100% sure of that but it's what I took away from the discussion. It sounds like some of you are having success with VT switch but not user switch, so let me check that internally.

                  gururise; I think we are testing and fixing this on supported versions of Ubuntu, RHEL and SLES/SLED/OpenSuSE. The open source drivers tended to get tested and fixed on a broader range of distros (by virtue of being open source, so the source code and the failing system could be in the same place) which I think accounts for their better behaviour on other distros.
                  Last edited by bridgman; 31 January 2009, 02:13 PM.
                  Test signature

                  Comment


                  • #19
                    Originally posted by bridgman View Post
                    duffster; as I understand it doing an X switch actually goes through the VT switch path on the way; not 100% sure of that but it's what I took away from the discussion. It sounds like some of you are having success with VT switch but not user switch, so let me check that internally.
                    That sounds possible. The X switch makes the screen flicker during the change exactly the same way as switching to VT does - even when switching to another X session with the same resolution.

                    I've not seen anyone complaining that VT switches don't work - in fact I'd be surprised if an X session could start at all if it couldn't do a switch successfully.

                    I'm not going to pretend to know how any of this works, but is it possible the problem is related to the issue that prevented logging out/restarting X sessions with fglrx that was fixed a few releases ago? Perhaps that fix needs extending to cover more than one X session?

                    Comment


                    • #20
                      VT switching works just fine. Restarting the X server is what locks up the machine. (Press CTRL+ALT+Backspace in X. Viola, bye bye system. Needs hard reset.)

                      Comment

                      Working...
                      X