Bug 493156 - "Switch User" functionality broken [NEEDINFO]
"Switch User" functionality broken
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
rawhide
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-31 15:58 EDT by Neil
Modified: 2009-04-06 17:44 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-06 17:44:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mcepl: needinfo? (nchannen)


Attachments (Terms of Use)

  None (edit)
Description Neil 2009-03-31 15:58:44 EDT
Description of problem:
Selecting System/Log Out <user>, then pressing "Switch User" flashes the screen a few times, then asks for my password to resume the current session.  Oddly, the mouse isn't fully functional in this window (e.g. hitting the "Unlock" button doesn't work, but pressing the Enter key does).

Version-Release number of selected component (if applicable):
Fedora 10 alpha; GNOME 2.26.0

How reproducible:
Always

Steps to Reproduce:
1. Select "Switch User" button
2.
3.
  
Actual results:
As above; no choose-user dialog, just asks me for my password to resume existing session

Expected results:
Get to log in as another user

Additional info:
Kernel 2.6.29-16.fc11.x86_64

I presume that there is a log file somewhere which shows an actual error mesage; please let me know where to find it.
Comment 1 Matthias Clasen 2009-04-01 00:08:36 EDT
Hmm, works fine here. Your description sounds more like your X server may have problems. Can you run two X servers on two vts manually ?

Ie when in X, switch to vt2 with C-A-F2, log in and run X :1
Comment 2 Neil 2009-04-01 00:47:24 EDT
Yup, that fails!  Should GNOME have been able to detect the error (e.g. non-zero return code) and show a useful error message?

Anyways, here are the X errors; feel free to forward this issue to the appropriate server people.  Server is version xorg-x11-server-Xorg-1.6.0-15.fc11.x86_64, although I just the same problem with the -16 version.

------------------------------------------------------------------------------

X.Org X Server 1.6.0

Release Date: 2009-2-25

X Protocol Version 11, Revision 0

Build Operating System: Linux 2.6.18-128.1.1.el5 x86_64 

Current Operating System: Linux mars.rvacrosscanada.com 2.6.29-16.fc11.x86_64 #1

 SMP Fri Mar 27 21:08:09 EDT 2009 x86_64

Build Date: 25 March 2009  02:54:55AM

Build ID: xorg-x11-server 1.6.0-15.fc11 

        Before reporting problems, check http://wiki.x.org

        to make sure that you have the latest version.

Markers: (--) probed, (**) from config file, (==) default setting,

        (++) from command line, (!!) notice, (II) informational,

        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.

(==) Log file: "/var/log/Xorg.1.log", Time: Tue Mar 31 21:32:09 2009

(==) Using config file: "/etc/X11/xorg.conf"

(EE) [drm] Could not set DRM device bus ID.

(EE) RADEON(0): [dri] DRIGetVersion failed to open the DRM

[dri] Disabling DRI.

(EE) RADEON(0): Kernel modesetting setup failed

(EE) Screen(s) found, but none have a usable configuration.



Fatal server error:

no screens found



Please consult the The X.Org Foundation support 

         at http://wiki.x.org

 for help. 

Please also check the log file at "/var/log/Xorg.1.log" for additional informati

on.

------------------------------------------------------------------------------

and the last bit of /var/log/Xorg.1.log looks like:

------------------------------------------------------------------------------

(II) RADEON(0): Creating default Display subsection in Screen section

        "Default Screen Section" for depth/fbbpp 24/32

(==) RADEON(0): Depth 24, (--) framebuffer bpp 32

(II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)

(==) RADEON(0): Default visual is TrueColor

(==) RADEON(0): RGB weight 888

(II) RADEON(0): Using 8 bits per RGB (8 bit DAC)

(--) RADEON(0): Chipset: "ATI Radeon XPRESS 200M 5955 (PCIE)" (ChipID = 0x5955)

(II) RADEON(0): PCI card detected

drmOpenDevice: node name is /dev/dri/card0

drmOpenDevice: open result is 10, (OK)

drmOpenDevice: node name is /dev/dri/card0

drmOpenDevice: open result is 10, (OK)

drmOpenByBusid: Searching for BusID pci:0000:01:05.0

drmOpenDevice: node name is /dev/dri/card0

drmOpenDevice: open result is 10, (OK)

drmOpenByBusid: drmOpenMinor returns 10

drmOpenByBusid: drmGetBusid reports pci:0000:01:05.0

(II) [drm] DRM interface version 1.0

(EE) [drm] Could not set DRM device bus ID.

(EE) RADEON(0): [dri] DRIGetVersion failed to open the DRM

[dri] Disabling DRI.

(EE) RADEON(0): Kernel modesetting setup failed

(II) UnloadModule: "radeon"

(EE) Screen(s) found, but none have a usable configuration.

------------------------------------------------------------------------------
Comment 3 Matthias Clasen 2009-04-01 10:25:18 EDT
Ok, moving this over to the X side then.
Comment 4 Neil 2009-04-03 16:32:14 EDT
xorg-x11-drv-ati-6.12.1-2.fc11.x86_64 seems to fix this, however it is constantly syslogging "reserve_memtype: calling reserve_ram_pages_type for 0x33a4e000 0x33a4f000 8" over and over, while a second X server is running.

Since the original problem is fixed, can we use this ticket to remove this continual syslog message?

Apr  3 13:28:59 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3823a000 0x3823b000 8
Apr  3 13:28:59 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3823a000 0x3823b000 8
Apr  3 13:28:59 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3823a000 0x3823b000 8
Apr  3 13:29:00 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3823a000 0x3823b000 8
Apr  3 13:29:00 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3823a000 0x3823b000 8
Apr  3 13:29:00 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3823a000 0x3823b000 8
Apr  3 13:29:01 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3823a000 0x3823b000 8
Apr  3 13:29:01 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3823a000 0x3823b000 8
Apr  3 13:29:01 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3823a000 0x3823b000 8
Apr  3 13:29:01 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3823d000 0x3823e000 8
Apr  3 13:29:01 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3823d000 0x3823e000 8
Apr  3 13:29:02 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3824f000 0x38250000 8
Apr  3 13:29:02 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3824f000 0x38250000 8
Apr  3 13:29:02 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3824f000 0x38250000 8
Apr  3 13:29:02 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x38255000 0x38256000 8
Apr  3 13:29:02 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x38255000 0x38256000 8
Apr  3 13:29:03 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3824f000 0x38250000 8
Apr  3 13:29:03 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3824f000 0x38250000 8
Apr  3 13:29:03 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3824f000 0x38250000 8
Apr  3 13:29:04 mars kernel: reserve_memtype: calling reserve_ram_pages_type for 0x3824f000 0x38250000 8
Comment 5 Matěj Cepl 2009-04-06 17:44:16 EDT
(In reply to comment #4)
> xorg-x11-drv-ati-6.12.1-2.fc11.x86_64 seems to fix this, however it is
> constantly syslogging "reserve_memtype: calling reserve_ram_pages_type for
> 0x33a4e000 0x33a4f000 8" over and over, while a second X server is running.
> 
> Since the original problem is fixed, can we use this ticket to remove this
> continual syslog message?

Please a file a new bug for xorg-x11-server component, please.

Thank you

Note You need to log in before you can comment on or make changes to this bug.