I can confirm that with 7-STABLE as of this writing, the USB problems
with amd64 and Xorg appear to be fixed.
The key requirements are a 7-STABLE tree from *now*, a fresh
buildworld+buildkernel, and a forced rebuild of libpciaccess to pick up
PCIOCGETBAR. I can now run both scanpci and Xorg
Dan Allen wrote:
While this enabled the mouse (without HAL), it did nothing good about:
a. The bogus keyboard scans.
Everyone is talking about an xorg.conf
The new X.org 7.4 upgrade hit me too: no keyboard no mouse! Bummer.
I found that if I simply added to /etc/rc.conf:
hald_enable=YES
On 2009-02-19 13:21, Stephen Clark wrote:
(II) Loading /usr/local/lib/xorg/modules/extensions//vnc.so
dlopen: /usr/local/lib/xorg/modules/extensions//vnc.so: Undefined symbol
NumCurrentSelections
This is a VNC problem, it uses an old API which has been removed in
newer X.org servers:
On Thu, 2009-02-19 at 16:39 +0100, Dimitry Andric wrote:
On 2009-02-19 13:21, Stephen Clark wrote:
(II) Loading /usr/local/lib/xorg/modules/extensions//vnc.so
dlopen: /usr/local/lib/xorg/modules/extensions//vnc.so: Undefined symbol
NumCurrentSelections
This is a VNC problem, it uses an
On Thu, 19 Feb 2009 12:22:03 -0600
Robert Noland rnol...@freebsd.org wrote:
On Thu, 2009-02-19 at 16:39 +0100, Dimitry Andric wrote:
On 2009-02-19 13:21, Stephen Clark wrote:
(II) Loading /usr/local/lib/xorg/modules/extensions//vnc.so
dlopen:
I've just upgraded to the latest xorg on my amd64 box
7.1-STABLE FreeBSD 7.1-STABLE #0: Fri Jan 16 07:33:20 PST 2009
I have a radeon graphics card,
drm0: ATI Radeon RV280 9250 on vgapci0
- had to add the option mentioned in UPDATING
Section ServerLayout
Option AllowEmptyInput off
...
Robert Noland wrote:
...
Ok, lets try another test... There is a scanpci util in the
libpciaccess port. We don't install it, but it does get built. Build
the port and run scanpci -v as root from the console. That should poke
all the pci devices on the box and tell you about them. See if
On Tue, 2009-02-10 at 17:57 +, Bruce M. Simpson wrote:
Robert Noland wrote:
...
Ok, lets try another test... There is a scanpci util in the
libpciaccess port. We don't install it, but it does get built. Build
the port and run scanpci -v as root from the console. That should poke
Robert,
First, thanks for all your dedicated work so far on the Xorg ports.
I realize this upgrade has been somewhat fraught with unexpected issues.
FWIW, things are not greener on the Linux side of the fence; many Ubuntu
and Debian users have reported issues with the newer Xorg and in
On Mon, 2009-02-09 at 19:26 +, Bruce M. Simpson wrote:
Robert,
First, thanks for all your dedicated work so far on the Xorg ports.
I realize this upgrade has been somewhat fraught with unexpected issues.
FWIW, things are not greener on the Linux side of the fence; many Ubuntu
and
09.02.09, 09:00, Robert Noland rnol...@freebsd.org:
On Mon, 2009-02-09 at 02:08 +, Bruce M. Simpson wrote:
Bruce M. Simpson wrote:
S.N.Grigoriev wrote:
I thank you for your response. I've applied the patch to pci.c from
kern/130957. Unfortunately there are no positive results.
Robert Noland wrote:
...
Ok, that is odd... Once drm is loaded and X opens it, the ddx driver
should request that the irq handler be installed. At that point, dmesg
should show something resembling the following.
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] AGP at 0xc000
On Mon, 2009-02-09 at 23:30 +, Bruce M. Simpson wrote:
Robert Noland wrote:
...
Ok, that is odd... Once drm is loaded and X opens it, the ddx driver
should request that the irq handler be installed. At that point, dmesg
should show something resembling the following.
vgapci0:
Bruce M. Simpson wrote:
S.N.Grigoriev wrote:
I thank you for your response. I've applied the patch to pci.c from
kern/130957. Unfortunately there are no positive results. USB is still
unreachable with X.
Just following up to confirm that you are seeing exactly the same
symptoms with USB and
On Mon, 2009-02-09 at 02:08 +, Bruce M. Simpson wrote:
Bruce M. Simpson wrote:
S.N.Grigoriev wrote:
I thank you for your response. I've applied the patch to pci.c from
kern/130957. Unfortunately there are no positive results. USB is still
unreachable with X.
Just following up to
On Mon, 2009-02-09 at 02:08 +, Bruce M. Simpson wrote:
Bruce M. Simpson wrote:
S.N.Grigoriev wrote:
I thank you for your response. I've applied the patch to pci.c from
kern/130957. Unfortunately there are no positive results. USB is still
unreachable with X.
Just following up to
On Sunday 01 February 2009 13:11:21 Alex Goncharov wrote:
On Sun, 1 Feb 2009 12:33:56 + I wrote:
| That is not to say the new Xorg doesn't work. The only problems I've
| seen on Radeons needed a couple of options lines in xorg.conf due to
| the hald/dbus/xorg race and an fdi to make the
,--- I/Alex (Sun, 01 Feb 2009 08:11:21 -0500) *
| Knowing about specific things now fixed for specific users is very
| encouraging.
|
| Thanks a lot!
`-*
,--- You/Matt (Sun, 1 Feb 2009 14:17:16 +) *
| I had better post to the lists
On Sat, 2009-01-31 at 16:25 -0500, Alex Goncharov wrote:
,--- You/vehemens (Sat, 31 Jan 2009 11:53:58 -0800) *
| In general when upgrading, you take your chances. If a port upgrade
| fails, you should fall back to what worked.
So, a *fundamental* (practically an OS component) port is
,--- Alexandre \ (Sun, 01 Feb 2009 12:03:06 -0500) *
| When I install the old packages, I can no longer rebuild and install
| new (say `csup'ed on 2009-03-01) port components, as one whole -- I
| can only do it selectively, excluding from the upgrade most
| X-dependent things. That sucks
,--- You/Matthew (Sun, 1 Feb 2009 14:48:15 -0600) *
| On Sat, Jan 31, 2009 at 04:25:21PM -0500 I heard the voice of
| Alex Goncharov, and lo! it spake thus:
| Csup can only go forward -- or can it go back?)
|
| You can specify a date in a supfile since, like, ever.
On Sat, Jan 31, 2009 at 04:25:21PM -0500 I heard the voice of
Alex Goncharov, and lo! it spake thus:
Csup can only go forward -- or can it go back?)
You can specify a date in a supfile since, like, ever.
--
Matthew Fuller (MF4839) | fulle...@over-yonder.net
Systems/Network
As a general note, this is the second time in a row that an X.org
upgrade broke X for a significant number of people. IMO, this
suggests that our approach to X.org upgrades needs significant changes
(see below). X11 is a critical component for anyone who is using
FreeBSD as a desktop and
On Fri Jan 30 11:53:16 PST 2009, Peter Jeremy wrote:
As a general note, this is the second time in a row that an X.org
upgrade broke X for a significant number of people. IMO, this
suggests that our approach to X.org upgrades needs significant changes
(see below). X11 is a critical component for
,--- You/vehemens (Sat, 31 Jan 2009 11:53:58 -0800) *
| In general when upgrading, you take your chances. If a port upgrade
| fails, you should fall back to what worked.
So, a *fundamental* (practically an OS component) port is brought in
-- and it disables my system. What is my way of
On Saturday 31 January 2009 01:25:21 pm Alex Goncharov wrote:
,--- You/vehemens (Sat, 31 Jan 2009 11:53:58 -0800) *
| In general when upgrading, you take your chances. If a port upgrade
| fails, you should fall back to what worked.
So, a *fundamental* (practically an OS component) port
,--- You/vehemens (Sat, 31 Jan 2009 13:54:42 -0800) *
| On Saturday 31 January 2009 01:25:21 pm Alex Goncharov wrote:
| So, a *fundamental* (practically an OS component) port is brought in
| -- and it disables my system. What is my way of action? Right --
| install the old packages, taken
Alex Goncharov wrote:
,--- You/Peter (Sat, 31 Jan 2009 06:53:11 +1100) *
| X11 is a critical component for anyone who is using FreeBSD as a
| desktop and having upgrades fail or come with significant POLA
| violations and regressions for significant numbers of people is not
| acceptable.
On Fri, Jan 30, 2009 at 10:25:09PM +0200, Kostik Belousov wrote:
In contrast, 1.5.3 upgraded and I observed two issues, one was the
Xorg sleeping in ttyin, that was promptly fixed.
What was this one about? I just had the weird experience (after
upgrading with much manual intervention) of X
Hi list,
after upgrading to Xorg 7.4 from the FreebSD ports tree
I've got my USB stack completely unusable. If Xorg is started
(manually or via xdm) my USB printer and external HDD become
unreachable (timeouts). It is not enough to kill Xorg to restore
the USB functionality. FreeBSD has to be
Am 30.01.2009 um 10:16 schrieb S.N.Grigoriev:
after upgrading to Xorg 7.4 from the FreebSD ports tree
I've got my USB stack completely unusable. If Xorg is started
(manually or via xdm) my USB printer and external HDD become
unreachable (timeouts). It is not enough to kill Xorg to restore
the
30.01.09, 12:59, Markus Hitter m...@jump-ing.de:
Am 30.01.2009 um 10:16 schrieb S.N.Grigoriev:
after upgrading to Xorg 7.4 from the FreebSD ports tree
I've got my USB stack completely unusable. If Xorg is started
(manually or via xdm) my USB printer and external HDD become
unreachable
I have to agree with you that this latest update was most problematic for me. I
keep my system very up-to-date, usually every 3-5 days. FreeBSD 7.1 RELENG
(Which is stable at the moment) on Toshiba X200-AX1
Two major problems both noted in UPDATING but still cause of a huge number of
problems
As a general note, this is the second time in a row that an X.org
upgrade broke X for a significant number of people. IMO, this
suggests that our approach to X.org upgrades needs significant changes
(see below). X11 is a critical component for anyone who is using
FreeBSD as a desktop and having
On Sat, Jan 31, 2009 at 06:53:11AM +1100, Peter Jeremy wrote:
As a general note, this is the second time in a row that an X.org
upgrade broke X for a significant number of people. IMO, this
suggests that our approach to X.org upgrades needs significant changes
(see below). X11 is a critical
,--- You/Peter (Sat, 31 Jan 2009 06:53:11 +1100) *
| X11 is a critical component for anyone who is using FreeBSD as a
| desktop and having upgrades fail or come with significant POLA
| violations and regressions for significant numbers of people is not
| acceptable.
Fully agree with this.
|
S.N.Grigoriev wrote:
I thank you for your response. I've applied the patch to pci.c from
kern/130957. Unfortunately there are no positive results. USB is still
unreachable with X.
Just following up to confirm that you are seeing exactly the same
symptoms with USB and Xorg 7.4 as I see on my
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
,--- You/Bruce (Thu, 29 Jan 2009 12:06:45 +) *
| 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
On Thu, 2009-01-29 at 07:46 -0500, Alex Goncharov wrote:
,--- You/Bruce (Thu, 29 Jan 2009 12:06:45 +) *
| 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
,--- You/Robert (Thu, 29 Jan 2009 08:40:11 -0500) *
| I've had patches available for probably a couple of months now posted to
| freebsd-...@. For the few people who tested it, I had no real issues
| reported. We were stalled for a long time, While X kept moving, so the
| amount of change
On Thu, 2009-01-29 at 08:58 -0500, Alex Goncharov wrote:
,--- You/Robert (Thu, 29 Jan 2009 08:40:11 -0500) *
| I've had patches available for probably a couple of months now posted to
| freebsd-...@. For the few people who tested it, I had no real issues
| reported. We were stalled for a
Alex Goncharov wrote:
,--- You/Bruce (Thu, 29 Jan 2009 12:06:45 +) *
| 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
,--- You/Robert (Thu, 29 Jan 2009 09:12:47 -0500) *
| Problem is, it isn't just the Xserver... All of the pieces are
| intertwined and so in many cases to update Xserver you also need to
| update some/several libraries as well as all of your drivers. Xorg is
| about 60 or 70 ports now.
That
On Thu, 2009-01-29 at 08:16 -0500, Stephen Clark wrote:
Alex Goncharov wrote:
,--- You/Bruce (Thu, 29 Jan 2009 12:06:45 +) *
| 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
|
On Thu, 2009-01-29 at 09:25 -0500, Alex Goncharov wrote:
,--- You/Robert (Thu, 29 Jan 2009 09:12:47 -0500) *
| Problem is, it isn't just the Xserver... All of the pieces are
| intertwined and so in many cases to update Xserver you also need to
| update some/several libraries as well as all
On January 28, 2009 10:10 pm Larry Baird wrote:
Initially thought this upgrade was a mistake, until I found out about
hald_enable and dbus_enable. Upgrade would have be a lot easier if
they were mentioned in /usr/ports/UPDATING. I would have found these
knobs more quickly if mentioned in
Thanks to Robert for pointing out a few things to me.
I have run
portupgrade -rf libxcb
and it rebuilt quite a few pieces that had not been rebuilt in the
standard portupgrade that gave me X.org 7.4 in the first place.
After rebuilding firefox and a bunch of smaller libraries, my
Dan Allen wrote:
Thanks to Robert for pointing out a few things to me.
I have run
portupgrade -rf libxcb
I normally run portupgrade -WrRpPa
This is what I ran and it totally hosed my system.
I had to revert back to an earlier version to be able to
bring X back up.
This should have
On Thu, 2009-01-29 at 16:45 -0500, Stephen Clark wrote:
Dan Allen wrote:
Thanks to Robert for pointing out a few things to me.
I have run
portupgrade -rf libxcb
I normally run portupgrade -WrRpPa
This is what I ran and it totally hosed my system.
I had to revert back to an
While this enabled the mouse (without HAL), it did nothing good about:
a. The bogus keyboard scans.
Everyone is talking about an xorg.conf
The new X.org 7.4 upgrade hit me too: no keyboard no mouse! Bummer.
I found that if I simply added to /etc/rc.conf:
hald_enable=YES
that things now
Although the hald_enable in /etc/rc.conf worked, I noticed that a lot
of other demons get running. I needed to add dbus_enable as well.
That fix is too intrusive in my book.
In any event Firefox is now broken and does not run at all.
I backed out the /etc/rc.conf changes and generated an
On Wed, 2009-01-28 at 21:11 -0700, Dan Allen wrote:
Although the hald_enable in /etc/rc.conf worked, I noticed that a lot
of other demons get running. I needed to add dbus_enable as well.
That fix is too intrusive in my book.
In any event Firefox is now broken and does not run at all.
,--- You/Dan (Wed, 28 Jan 2009 20:39:10 -0700) *
| While this enabled the mouse (without HAL), it did nothing good about:
|
| a. The bogus keyboard scans.
You are quoting me and I need to clarify...
| Everyone is talking about an xorg.conf
| The new X.org 7.4 upgrade hit me too: no
,--- You/Robert (Wed, 28 Jan 2009 23:16:11 -0500) *
| Now I can use X again BUT... Firefox 3.0.5 is still broken. It has =20
| worked fine until this new Xorg.
|
| Firefox not working is one of the symptoms of a botched upgrade. If you
| ldd firefox-bin you will likely find that it is
In article e1lspcl-0005kq...@daland.home you wrote:
,--- You/Robert (Wed, 28 Jan 2009 23:16:11 -0500) *
| Now I can use X again BUT... Firefox 3.0.5 is still broken. It has =20
| worked fine until this new Xorg.
|
| Firefox not working is one of the symptoms of a botched upgrade. If
56 matches
Mail list logo
