[regression, intrepid] Xorg servers broken "No core keyboard" and "failed to initialize core devices"

Me too. PPC Mac G4.
Build Operating System: Linux 2.6.15-51-powerpc64-smp ppc Ubuntu
(--) PCI:*(0@0:16:0) ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] rev 1, Mem @ 0x0f9f0374/0, 0x0f9f0374/0, I/O @ 0x0f9f0374/0, BIOS @ 0x????????/262079348

Exactly the same results.

Somewhat important, IMHO.

I have the same problem. If you want,I have the list of packages that have been upgraded.

that'd give me at least an idea which packages to downgrade in order to try to restore functionality and thus determine the culprit...

My PPC64 G5 machine is affected. Downgrading xserver-xorg-core from 2:1.5.1-1ubuntu3 to 2:1.5.1-1ubuntu2 fixes this for me. If your cache is still populated, try with:

sudo dpkg -i /var/cache/apt/archives/xserver-xorg-core_2%3a1.5.1-1ubuntu2_powerpc.deb

and restart gdm (sudo /etc/init.d/gdm restart).

alas I don't have it anymore in my cache; is there some package archive of old .deb's?

nevermind, just found:
http://launchpadlibrarian.net/18263482/xserver-xorg-core_1.5.1-1ubuntu2_powerpc.deb

Thank you for reporting this bug. I can confirm this problem on my iBook G4.

I skimmed quickly through the changes from 1.5.1-1ubuntu2 to 1.5.1-1ubuntu3, and they have occurences of swap{l,s}() and also some cast-trunking of integer pointers, which could be accountable for an endian issue we're experiencing here...

Can someone knowing X internals have a look at this? This bug should be raised to "critical" priority, since it makes the whole graphical system unusable (for normal users, that means: the whole system unusable).

Hi all,

I've also noticed this bug, it affects at least ppc, sparc, hppa.

It's also affecting xvfb obviously.

Milestoning for intrepid.

Cheers

Can someone please confirm that 2:1.5.1-1ubuntu2 doesn't suffer from this bug and that 2:1.5.1-1ubuntu3 does?

If someone experiencing the bug knows how to "git bisect", then it would be helpful to "git bisect" the failure to the upstream commit causing the regression; the Ubuntu package is kept in git in the ubuntu branch of <git://git.debian.org/git/pkg-xorg/xserver/xorg-server>.

You can also try from upstream git directly if you can reproduce with upstream tip.

i confirm 2:1.5.1-1ubuntu2 works on my ibook g4 and not ubuntu3

however, i have no keyboard
which is not quit pratical.
i should figure that out

Philippe, you're saying you have no keyboard with ubuntu2? When did you have keyboard last?

Could you attach a Xorg.log from ubuntu2 and ubuntu3? (sorry should have asked earlier, didn't think of it)

in fact, i installed
dpkg -i xserver-xorg-core_1.5.1-1ubuntu2_powerpc.deb

and haven't switch the other packets (xserver-xorg-input) to previeous versions
(installed packages depend on xorg-core 1.5.1 ubunut3)

that might conflict?

i'm now tryin to install the previous versions now

thought i don't think i had keyboard or nouse before with ubuntu3 version of xorg-core
as the xserver would startup with a certain xorg.conf, and i would get a black screen with no possibility to ctr-alt-backsapce or whatsoever

i'll send my xorg log files as soon as i'm home
thx

xorg ubuntu2 log

xorg ubuntu4 log (sorry couldn't reinstall ubuntu3)

Same thing here. Power G5. Stopped working after one of the recent upgrades

Bug confirmed here with iMac G4 flat panel. Argh!

That's odd, none of your logfiles have much about evdev. That should be used for keyboards as well. 'lshal' output, please.

Right I'm doing a bit of leg work on this. Reverting back these packages to these revisions brings back graphics and keyboard input:

xserver-xorg-core_1.5.1-1ubuntu2
xserver-xorg-input-evdev_2.0.99+git20080912-0ubuntu2

I'll be back with more info if I can find it.

Same problem here in ps3. 'lshal' output attached

ok, so the lshal output looks normal. Probably the three xkb related commits in 1.5.2 that broke it, but it needs to be verified and after that let upstream know about it.

Right, reverted these three commits

e88df87851232d6b6c8da5fff802b33f5275b050 xkb: squash canonical types into explicit ones on core reconstruction.
be3b3cb970d040f0db4bead018c338012547334f xkb: fix core keyboard map generation. #14373
3bf826f59013ec14fbcf19b85a03e2967a821661 xkb: fix use of uninitialized variable.

None of them fix the problem, even with all three reverted, no improvement.

The message in the log ... "No core keyboard" seems to originate from dix/devices.c on line 532 (post patching). The following commits between 1.5.1-1ubuntu2 and 1.5.1-1ubuntu3 affect this file:

b1b567e30678b6515ff3067ed7f1aae5f541c3ae Fix 137 backport, one line missing from XIGetDeviceProperty
a834ce903f4a2f54e1145336b331493c3b696501 Merge patches 138 and 139 into 137

These commits alter patch 137 which pulls in what seems to be called the XI API. I've tried reverting these patches but the really odd thing is once they have been removed the build fails due to undefined macro constant XI_PROP_ENABLED - seems include/xserver-properties.h file is missing from the earlier version of these patches???

I need to quit this for today. Do these last 2 commits look likely suspects? Is it worth continuing to try and revert them?

I can confirm that this bug exists for x86 too (fresh installed hardy then upgraded via update-manager -c -d to ibex).
Can anyone provide a link to an old xserver-xorg-core version until a fix is released?

you can find old builds of xserver-xorg-core by following the links for your architecture at the bottom of

https://launchpad.net/ubuntu/+source/xorg-server/2:1.5.1-1ubuntu2

(for instance, this could lead to
https://launchpad.net/ubuntu/intrepid/i386/xserver-xorg-core/2:1.5.1-1ubuntu2
and finally
http://launchpadlibrarian.net/18263189/xserver-xorg-core_1.5.1-1ubuntu2_i386.deb
)

@Giovanni: I also have an upgraded x86 machine - it's not affected. could you attach your Xorg.0.log?

I'm slowly narrowing this down now. I believe the problem lays somewhere between config/hal.c and NewInputDeviceRequest() in xf86XInput.c.

Upon initialization in config/hal.c a list of input devices is obtained by querying HAL. The device properties are parsed and then finally NewInputDeviceRequest() is called. The driver to load for the device is specified by the "input.x11_driver" property in HAL and on my PS3 system and my x86 desktop this is set to "evdev" . As far as I can see (from the code and the healthy Xorg.0.log on my x86 machine) the first call to NewInputDeviceRequest() is where evdev should be loaded, but in our failing logs it's not getting that far.

I'll continue investigation when I get home (where my PS3 is).

Here is the x86 Xorg.0.log. It seems similar to other one posted (complains about hal not giving X a valid core pointer and core keyboard)

@Giovanni. Thanks for the log. This bit ...

(II) Cannot locate a core pointer device.
(II) Cannot locate a core keyboard device.
(II) The server relies on HAL to provide the list of input devices.
 If no devices become available, reconfigure HAL or disable AllowEmptyInput.

... is nothing to worry about. Although it sounds like a failure it's actually just informational. It's saying that because no mouse or keyboard were found in the config file (if there was one) that the server will rely on HAL to find input devices later.

The signature of the bug we're dealing with here is a fatal error when no devices are actually found at this HAL configuration stage. Your log doesn't seem to be exhibiting that same problem. My instinct says you may have a slightly different issue. I recommend opening a new bug for yours just now, if later we find it is the same we can merge it in (by marking as a duplicate).

Thanks.

Giovanni, you probably don't have xserver-xorg-input-evdev installed.

Thanks Dan for working on this! I doubt it's the properties code that broke it, since the new stuff only removed a couple of functions.. but you seem to have found that out already :)

Dan, the problem might be in DeviceSetProperty() found on dix/devices.c (patch 137). This is a new function introduced in the current properties code, so the breakage could well be there.

Timo

Ok noted. Sorry couldn't get at my PS3 last night so no progress since
yesterday :(

10:15 < whot> tjaalton: i'd recompile the evdev driver without properties and then try that
10:16 < whot> tjaalton: ther's a good chance that a length field doesn't get swapped and corrupts memory
10:17 < whot> tjaalton: that should be easy to find by just running xinput --set-int-prop with a few varieties of format

So, try installing the evdev driver without properties support. To do that you have to disable patch 100 which removes the API checks.

This might be related to upstream bug http://bugs.freedesktop.org/show_bug.cgi?id=18111

Progress ...

See the above 2 logs. I added plenty of tracing output and recompiled.

It seems things probably go wrong somewhere in dix/devices.c in or below EnableDevice(). In the healthy log the second call to enable device seems to trigger the connect_hook() callback in config/hal.c. In the broken PS3 trace this never happens.

I investigated DeviceSetProperty() in dix/devices.c but it seemed to be behaving itself - returned Success on each call.

I will try recompiling the evdev driver without properties support, but looking at the logs I have it doesn't look like evdev is even loaded as that happens after the config/hal.c has done its work.

Continuing ...

What did you do to get the healthy trace, looks like the server version was the same?

On Wed, Oct 22, 2008, Timo Aaltonen wrote:
> What did you do to get the healthy trace, looks like the server version
> was the same?

 AIUI healthy one is on x86.

--
Loïc Minier

heh, silly me..

Healthy is from my x86.

Dan, try to ifdef 0 the three property calls in dix/devices.c:AddInputDevice().

The problem has likely been found:

17:30 < jcristau> tjaalton: dev->enabled is Bool, Bool is typedefed to int, so
                  *(CARD8*)(&dev->enabled) doesn't look at the right byte on big endian, aiui

And the upstream bug has a proposed fix for it, please test!

Fantastic. I'll test the patch as soon as I can.

Woooooohooooooo!

Fixed!

Updated the patch so it applies cleanly, and slotted into series at position 138 so it's near to the other Xi properties patches it relates to. Hope that's ok.

Let me know if there's anything else I can do.

Cheers

Dan

Uploading to ubuntu (via ftp to upload.ubuntu.com):
  xorg-server_1.5.2-2ubuntu3.dsc: done.
  xorg-server_1.5.2-2ubuntu3.diff.gz: done.
  xorg-server_1.5.2-2ubuntu3_source.changes: done.
Successfully uploaded packages.

This bug was fixed in the package xorg-server - 2:1.5.2-2ubuntu3

---------------
xorg-server (2:1.5.2-2ubuntu3) intrepid; urgency=low

  * 138_look_at_all_bytes_of_dev_enabled.diff: dev->enabled has type
    Bool, which is typedef'd to int, but is used in comparisons with
    CARD8 data, which gives incorrect logic on big endian systems,
    causing failure to initialize keyboard and mouse.
    (LP: #281610)

 -- Bryce Harrington <email address hidden> Thu, 23 Oct 2008 07:31:47 -0700

just confirming, that with the latest/current packages installed, the bug is gone here on apple-ppc hardware :-)

     "Me to." 1.25ghz G5, the 1.5.2-2ubuntu3 xserver-xorg-core and related xserver-xorg-....ubuntu3 packages fixed things up. Nice work!

"Me Too". Power G5. Thanks lads!