Date: Thu, 29 Jan 2009 12:06:45 +0000 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Alex Goncharov <alex-goncharov@comcast.net> Cc: Dan Allen <danallen46@airwired.net>, freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Unhappy Xorg upgrade Message-ID: <49819BD5.5040709@FreeBSD.org> In-Reply-To: <E1LSP0B-0003Ds-H8@daland.home> References: <6B7ABE80-35AB-4C44-B5A4-200E10DCC3AC@airwired.net> <E1LSP0B-0003Ds-H8@daland.home>
next in thread | previous in thread | raw e-mail | index | archive | help
Alex Goncharov wrote:
> I hate to say this, but the new X (as exists in the current FreeBSD
> ports) sucks and gets in the way of work big time.
>
>
There are definitely issues with xorg-7.4 at the moment.
The root issue seems to be that USB mice simply don't work for me,
and running Xorg appears to destabilise the 7-STABLE USB stack in some
way which I just don't understand. The condition isn't recoverable
without a reboot. I am the only person who's reported these symptoms in
any great detail yet.
I spent a lot of time yesterday debugging with rnoland@ the USB
problem I've been having. He sent me a patch, however, it doesn't solve
the problem.
My understanding is that a lot has changed in this Xorg release to
do with input drivers, specifically mouse -- and that platform specific
code got shuffled off out of the server itself, and into the drivers.
Good from an academic software engineering point of view, but if this is
the cause, not good from a regression point of view.
Whilst bisecting all the conditions, and tracing it back to this
upgrade is easy to do, I can't readily identify the causal relationship
-- I don't know what's going on which has broken Xorg for me in this
way, and haven't seen anything like this before.
Since upgrading, I've seen stability problems with hald enabled. I
have had to turn off hald mode on both my laptop and desktop 7-STABLE
machines, as it can totally hang the machine, no DDB break, etc.
Scanning SVN, nothing appears to have changed in the 7-STABLE train
in terms of USB, moused, the ums driver, or anything else. A ktrace of
the moused process bound to ums0 goes dead (no I/O, no syscalls) after X
is started.
One theory is that somehow the mouse driver ioctls which are passed
to ums, are somehow hosing USB, although why that would be, I don't
understand. ums currently doesn't have driver instrumentation in that path.
I pulled a fairly detailed IRC log of my collaborative debugging
session with Robert, please ping me if you need details of this.
thanks
BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49819BD5.5040709>