[Bug 289026] Re: X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC)
So a few days have gone by with no further comments. I think the correct way to address this problem is to take a more recent epoch of the upstream, open source ATI driver. Can someone point me to the relevant information so that I can begin making this happen, if not for everyone using Intrepid, at least for MIT until Jaunty is released? The hardware that stopped working at all is what MIT has standardized upon for all desktop purchases for the past year. So this is important to us. -- X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC) https://bugs.launchpad.net/bugs/289026 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 289026] Re: X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC)
Wow! Thank you very much Tormod! We'll test with the newer ATI driver and see if it fixes the problem for us. -- X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC) https://bugs.launchpad.net/bugs/289026 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless hpet=disable
Good news! Dell has released an updated BIOS that remedies the problem. Rev A03 for the Dell Optiplex 760 can be found at: http://ftp.us.dell.com/bios/O760-A03.EXE I have updated my test system to this revision, and confirmed that HPET interrupts now correctly reach the Linux kernel with C states enabled. This bug can now be CLOSED. -- Jaunty will not boot on Dell Optiplex 760 unless hpet=disable https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless hpet=disable
Luis: It was under Intrepid that I first noticed clock problems myself. In fact, the Intrepid LiveCD has an old enough version of the kernel that you may see what I call, "Infinite spew," where the HPET code prints a kernel oops on every clock tick. I read a lot of deltas on kernel.org dealing with HPET issues. Apparently it's very tricky to get everyting right for HPET. The current Intrepid kernel lacks several cleanups of HPET, and so its operation is erratic. Jaunty contains the cleanest HPET code available, and this enabled us to understand the root cause of the HPET problems for the Dell 760: Mis-directed clock interrupts when in the C3 energy saving CPU state. I would say that reliable HPET operation with C States emabled is not possible with the Intrepid kernel. Worse, there is HPET code that gets used even if you disable HPET. For Intrepid, go into the bios and disable C States. For Jaunty, the best work around is to set the boot option: 'acpi_skip_timer_override' -- Jaunty will not boot on Dell Optiplex 760 unless hpet=disable https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 332323] Re: vmware-user-suid-wrapper does not properly activate vmblock
Attached is a patch that adds in the necessary code for vmware-user-suid-wrapper to properly modprobe to remove and add the vmblock module. I tried very hard to follow the style conventions of the existing code. One thing that's a bit kludgy: The platform independent code thinks it should create the vmblock directory in /proc/fs. Under linux, that's done in the vmblock kernel module initialization. I chose to add a platform specific "if !defined(linux)" to the platform independent code in main. Others may want a different style. **IMPORTANT** NONE of this will work unless one more packaging mistake is corrected: vmware-user-suid-wrapper is currently not installed suid root. To do its work properly it must be installed suid root. ** Attachment added: "Patch to add vmblock load code to vmware-user-suid-wrapper" http://launchpadlibrarian.net/23087446/wdc-patch.diff -- vmware-user-suid-wrapper does not properly activate vmblock https://bugs.launchpad.net/bugs/332323 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 125297] Re: Confusing Xclient entry in session list
MIT just got bit by this bug. We're getting ready to roll out a big deployment of Ubuntu, and discovered the default session that users should use isn't called Default Session Script, it's called "Run Xclient script". We've done a diversion to rename the script. I've looked at the upstream bug. Where they ended up a year ago was, "Let distros define their own default script from an example. QUESTION: What is Ubuntu going to do for a default X session script going forward? Upstream agrees that naming the default as "Run Xclient script" is poor, but they're now delegating the work of crafting the default script to the distributions. If Ubuntu is going to stay with this script, could it PLEASE be renamed to, "System Default Session"? -- Confusing Xclient entry in session list https://bugs.launchpad.net/bugs/125297 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 335649] [NEW] Secure Remote Connection session mis-behaves when connecting to non-linux hosts.
Public bug reported: The X session labeled "Secure Remote Connection" should, perhaps, be more properly labeled: "Secure startup of /etc/X11/Xsession on remote host" In fact, that's what the script does is try to run /etc/X11/Xsession remotely. Contacting a remote host that doesn't have that script installed, will signal back to the user, and what the user will see on the gdm client host console may imply the system has mis-installed X. At least when you issue ssh -Y u...@host /etc/X11/Xsession on a command line, the error you get back "/etc/X11/Xsesssion command not found" makes sense in context. Perhaps the best thing to do is to name this session something a little less generic? ** Affects: gdm (Ubuntu) Importance: Undecided Status: New -- Secure Remote Connection session mis-behaves when connecting to non-linux hosts. https://bugs.launchpad.net/bugs/335649 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 335666] [NEW] libc6 integration gives way wrong error message to libc5 binaries.
Public bug reported: Binary package hint: libc6 I know from the start I'm asking for something that doesn't fit in a simple place. The problem goes like this: The way libc6 has been integrated, any libc5 binaries that are run will give a way wrong error message. For example, clueless users running old programs out of remotely mounted filesystems: WDC-ATHENA-2% which ez /mit/andrew/arch/i386_linux24/bin/ez WDC-ATHENA-2% ez ez: Command not found. The problem is NOT that the ez binary is not found. The problem is that there is no ld-linux.so.1 to help link in libc5. The reason for this is, sensibly, there IS no libc5 installed. What needs to happen is that the person running the program needs to be told that the binary is so old that it's linking against libc5 when it needs to be recompiled against libc6. Instead the user is told that the file that can be accessed from myriad file utilities does not exist. I suggest a work-around: a Recommends /lib/ld-linux.so.1 that gets installed if none is present that will at least print an error message that makes sense. Since Ubuntu is all about the usability experience, I hope I'm not off base here asking for this amendment. ** Affects: glibc (Ubuntu) Importance: Undecided Status: New -- libc6 integration gives way wrong error message to libc5 binaries. https://bugs.launchpad.net/bugs/335666 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 289026] Re: X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC)
Florian: I was under the impression that the stock radeonhd driver would also resolve the issue. I've been advocating for an updated radeon driver so that we continue to travel in the direction of the code base that is regarded as canon. (I still have the action item to try the back-ported radeon driver. Sigh.) -- X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC) https://bugs.launchpad.net/bugs/289026 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 289026] Re: X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC)
Ok, Here is what I did: Booted the Intrepid Live CD. Watched as X failed to configure. (See Xorg.0.log output attached above.) Hit to get a TTY Logged in, Configured the Network by hand (cuz I'm not registered for DHCP). Fetched Tormod's backport: xserver-xorg-video-radeon_6.10.0.99+git20090114.0e69068a-0ubuntu0tormod~intrepid_i386.deb (from http://ppa.launchpad.net/tormodvolden/ubuntu/pool/main/x/xserver-xorg-video-ati/) did dpkg -i to install solely that file. Hit to get the X connection. Hit to restart X. Watched as X configured and started up just fine. Attached is the Xorg.0.log file from the successful start-up, changing ONLY the rev of xserver-xorg-video-radeon ** Attachment added: "Successful config of X with updated xserver-xorg-video-radeon" http://launchpadlibrarian.net/21910022/Xorg.0.log.new-radeon -- X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC) https://bugs.launchpad.net/bugs/289026 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 289026] Re: X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC)
ajw107: If I understand how upstream is going, the radeon-hd driver replacement may solve your problem for now, but will not be the stable long term solution. I believe the world is trying to get all the latest and greatest stuff into the "radeon" code base. Timo: Even if jaunty fixed the problem, it's from a whole X universe that's rather irrelevant to solving the problem for Intrepid. Is there a newer upstream radeon driver that could be tried with Intrepid? -- X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC) https://bugs.launchpad.net/bugs/289026 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 289026] Re: X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC)
I burned a Jaunty Alpha DVD from from the 13-Jan-2009 snapshot, booted it, and it came up just fine. I'm typing this comment on that system. Attached is the Xorg.0.log file of the successful run. (Just in case someone wants it.) It shows that the Radeon HD 2400 XT chip is correctly detected, that the radeon driver is correctly started, that the EDID transfer of the monitor is correctly performed, and that the expected 1680x1050 resolution is set. (Although it is a mystery to me why it probes modes SO man times.) So, as expected, testing the exact same hardware with the "completely re-designed for Jaunty X configuration" code does NOT manifest the problem. What more do we need to investigate getting an update to Radeon and the Interpid X server so that it will work? ** Attachment added: "Output of /var/log/Xorg.0.log of successful Jaunty Live DVD start-up." http://launchpadlibrarian.net/21248234/Xorg.0.log -- X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC) https://bugs.launchpad.net/bugs/289026 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 289026] Re: X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC)
Using the Intrepid Live CD, I booted, and indeed the X server does not come up. A temporary kludge is to add the line: Driver "vesa" to the Device section. I have attached the Xorg.0.log file of the failed start-up under Intrepid to this comment. ** Attachment added: "Failed Intrepid radeon start-up." http://launchpadlibrarian.net/21248942/Xorg.0.log.intrepid -- X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC) https://bugs.launchpad.net/bugs/289026 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 289026] Re: X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC)
Now have Xorg.0.log output for identical hardware with Success under Jaunty Alpha and Failure under Intrepid. ** Changed in: xserver-xorg-video-ati (Ubuntu) Status: Incomplete => Confirmed -- X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC) https://bugs.launchpad.net/bugs/289026 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 289026] Re: X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC)
Bryce Harrington: I went to the xorg-edgers archive. There were no ATI driver updates labeled Intrepid. In fact the stuff there was almost exclusively jaunty and hardy. I'm PRETTY sure this is nothing more than getting a little more recent upstream version of the radeon driver. Red Hat Enterprise 5.3 doesn't have this problem. SURELY Ubuntu Intrepid can get a driver as good as what they are shipping. -- X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC) https://bugs.launchpad.net/bugs/289026 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 335666] Re: libc6 integration gives way wrong error message to libc5 binaries.
One other manifestation of the problem is that if you try and find out what libraries the binary wants by using ldd, you get the same wrong error mesage. Instead of saying it wants to link against libc5, it says the the binary being examined does not exist. Perhaps the place to address the issue is in the same realm that discovers we're not allowed to run sparc code on an i386? (I say that not having thought terribly hard about where that might be.) -- libc6 integration gives way wrong error message to libc5 binaries. https://bugs.launchpad.net/bugs/335666 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 333197] Re: openafs-modules 1.4.8 segfault after stop
This just happened to me in a VM. Alas, cut/paste wasn't available. But I WAS able to scroll back and get the ENTIRE back trace as a series of images. Start with afs-oops-9.png and work your way forward. ** Attachment added: "First screenful of dump." http://launchpadlibrarian.net/23566698/afs-oops-9.png -- openafs-modules 1.4.8 segfault after stop https://bugs.launchpad.net/bugs/333197 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 333197] Re: openafs-modules 1.4.8 segfault after stop
** Attachment added: "second screenful" http://launchpadlibrarian.net/23566705/afs-oops-8.png -- openafs-modules 1.4.8 segfault after stop https://bugs.launchpad.net/bugs/333197 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 333197] Re: openafs-modules 1.4.8 segfault after stop
** Attachment added: "#7, third screenful" http://launchpadlibrarian.net/23566733/afs-oops-7.png -- openafs-modules 1.4.8 segfault after stop https://bugs.launchpad.net/bugs/333197 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 333197] Re: openafs-modules 1.4.8 segfault after stop
** Attachment added: "#6 fourth screenful" http://launchpadlibrarian.net/23566738/afs-oops-6.png -- openafs-modules 1.4.8 segfault after stop https://bugs.launchpad.net/bugs/333197 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 333197] Re: openafs-modules 1.4.8 segfault after stop
** Attachment added: "#5 fifth screenful" http://launchpadlibrarian.net/23566756/afs-oops-5.png -- openafs-modules 1.4.8 segfault after stop https://bugs.launchpad.net/bugs/333197 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 333197] Re: openafs-modules 1.4.8 segfault after stop
** Attachment added: "#4 sixth screenful" http://launchpadlibrarian.net/23566768/afs-oops-4.png -- openafs-modules 1.4.8 segfault after stop https://bugs.launchpad.net/bugs/333197 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 333197] Re: openafs-modules 1.4.8 segfault after stop
** Attachment added: "#3, seventh screenful" http://launchpadlibrarian.net/23566785/afs-oops-3.png -- openafs-modules 1.4.8 segfault after stop https://bugs.launchpad.net/bugs/333197 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 333197] Re: openafs-modules 1.4.8 segfault after stop
** Attachment added: "#2 eighth screenful" http://launchpadlibrarian.net/23566804/afs-oops-2.png -- openafs-modules 1.4.8 segfault after stop https://bugs.launchpad.net/bugs/333197 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 333197] Re: openafs-modules 1.4.8 segfault after stop
Phew. Sorry for all the noise. ** Attachment added: "#1 last screenful." http://launchpadlibrarian.net/23566812/afs-oops-1.png -- openafs-modules 1.4.8 segfault after stop https://bugs.launchpad.net/bugs/333197 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 332323] [NEW] vmware-user-suid-wrapper does not properly activate vmblock
Public bug reported:
Bug #302226 gives the remedy for getting vmware-user to start, but once
started vmware-user is not fully functional.
This is because vmblock is not being properly started.
The man page of vmware-user-suid-wrapper leads me to believe it has
responsibility for this:
[The purpose of vmware-user-suid-wrapper is to] acquire a filesystem file
descriptor, drop
superuser privileges, and then execute vmware-user(1). In particular,
prepare the system for vmware-user means that it unmounts the vmblock
file system, unloads the vmblock module, then reloads the module,
mounts the file system, and opens a file descriptor that vmware-user
can use to add and remove blocks.
Although there is a directory /tmp/VMwareDndD there is no /proc/fs/vmblock
"lsmod | grep vm" shows the other open-vm kernel modules are loaded, but not
vmblock.
If I do "sudo modprobe vmblock"
The expected entries under /proc/fs/vmblock appear, and Drag and Drop
starts working.
I dug into the source of vmware-user-suid-wrapper, and I see that the code to
do the unload and reload
of the vmblock module is simply not there. wrapper.h defines TOGGLE_VMBLOCK
only for sun
and __FreeBSD__.
I then reviewed the source for what is going out for Jaunty. It too
lacks the code to toggle vmblock.
It looks to me like the remedy here is to add the following code:
in wrapper-linux.c:
UnmountVMBlock to call unmount(mountPoint)
UnloadModule to call modprobe -r
LoadVMBlock to call modprobe
MountVMBlock to call mount (mountPoint)
And then add linux to the list of platforms that define TOGGLE_VMBLOCK
Does anyone have this code laying around? (I'm a bit frightened of just
doing {system ("modprobe -r vmblock")}.
Or is there some very sensible reason why doing the toggle vmblock is
still inappropriate on the Linux platform?
** Affects: open-vm-tools (Ubuntu)
Importance: Undecided
Status: New
--
vmware-user-suid-wrapper does not properly activate vmblock
https://bugs.launchpad.net/bugs/332323
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 306835] Re: vmware-guestd crashing
I have tested Anders' package. It works for me and gets guestd working. It would be great to see this in Intrepid and Jaunty. We're VERY close to a fully working set of open-vm-tools for modern Ubuntu. -- vmware-guestd crashing https://bugs.launchpad.net/bugs/306835 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 306835] Re: vmware-guestd crashing
Oops: Clarification: I have tested Anders' package under Intrepid. I have confidence it will work under Jaunty, but have not tested it there. -- vmware-guestd crashing https://bugs.launchpad.net/bugs/306835 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 289921] Re: network interface does not come up after installing open-vm-tools
I have tested Anders's package under Intrepid and it fixes the reported problems. I'll note in passing that Reuban Laban's work around did not work for me, but the fix Anders incorporated to make open-vm-tools run at a different time from init.d DID. This seems like a pretty serious bug with a pretty simple fix. We go from, "install the package and lose the network" to "package installs and works". I'd very much like to see this in Intrepid, and the additional fixes pushed into Jaunty. -- network interface does not come up after installing open-vm-tools https://bugs.launchpad.net/bugs/289921 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 289921] Re: network interface does not come up after installing open-vm-tools
I have tested Anders's package under Intrepid and it fixes the reported problems. I'll note in passing that Reuban Laban's work around did not work for me, but the fix Anders incorporated to make open-vm-tools run at a different time from init.d DID. This seems like a pretty serious bug with a pretty simple fix. We go from, "install the package and lose the network" to "package installs and works". I'd very much like to see this in Intrepid, and the additional fixes pushed into Jaunty. -- network interface does not come up after installing open-vm-tools https://bugs.launchpad.net/bugs/289921 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 302226] Re: vmware-user doesn't autostart
I have tested Anders' package under Intrepid. It solves the problem of the failure of vmware-user to autostart. I'd very much like to see this fix make it into Intrepid and Jaunty. It's a one-line fix that takes us from, "You must start vmware-user by hand" to vmware-user starts up automatically like it's supposed to. -- vmware-user doesn't autostart https://bugs.launchpad.net/bugs/302226 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] [NEW] Jaunty will not boot on Dell Optiplex 760 unless acpi=off
Public bug reported: MIT is switching its standard recommended desktop configuration from the Dell Optiplex 755 which has reached end of life to the new Dell Optiplex 760. Unfortunately there seems to be a nasty kernel bug around HPET. Repeat by: Boot today's Jaunty Live CD. (I used 3/24/09 and also as another test 1/13/09) Select your language Choose "Try Ubuntu..." Actual results: Blank screen Expected results: Working Jaunty. Work-around: Select option ACPI=off We know from other bug reports for example, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515975 that there is a problem with HPET. That debian bug requests incorporation of a one-line kernel change that changes an oops message from displaying on every clock tick to one that only appears once. It does not, however get HPET working. This problem manifests under Intrepid with much spewage of kernel oops messages and/or terribly slow operation. Again the work-around of of turning off ACPI seems to help. The hardware has ICH10 motherboard chips. How new are they? Also I see a report that the PNP-BIOS is not working, but I do not know if this is relevant. ** Affects: ubuntu Importance: Undecided Status: New -- Jaunty will not boot on Dell Optiplex 760 unless acpi=off https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless acpi=off
I have done more testing and learned much. Setting kernel option hpet=disable works around the problem. Also, if you hit the power switch to create an interrupt, oh say about 40 times, you can get the bootstrap to the point where it sees the keyboard. At that point you can generate interrupts with the keyboard to the point where gdm starts, and sees the mouse. After that, unless YOU create interrupts, the system sees no clock interrupts, and does nothing. It's fun to type "ls" and have it produce no output till you move the mouse, or hit the ctrl key. -- Jaunty will not boot on Dell Optiplex 760 unless acpi=off https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless hpet=disable
Although Intrepid still runs through the HPET code path, setting hpet=disable is the smallest scope change to get Jaunty working. ** Summary changed: - Jaunty will not boot on Dell Optiplex 760 unless acpi=off + Jaunty will not boot on Dell Optiplex 760 unless hpet=disable -- Jaunty will not boot on Dell Optiplex 760 unless hpet=disable https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless hpet=disable
WOW! I was skeptical that "Load BIOS Defaults" was going to make any difference, but INDEED, Jaunty started right up. The image is the most recent one posted to cdimage.ubuntu.com/daily-live/current which is dated 24-Mar-2009, filename, "jaunty-desktop-i386.iso" QUESTION: Any suggestions on how we can track down what BIOS setting was trashed by whom? -- Jaunty will not boot on Dell Optiplex 760 unless hpet=disable https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless hpet=disable
The prospect of, flip a bios bit, boot CD, repeat for all bits seems rather daunting. On the assumption that it was an Intrepid post-install nastiness with some software MIT integrated, I used biosdecode, dmidecode, dumpCmos and dumpSmbios to take a snapshot of as much BIOS state as I could, and then did pretty much the same install I did that seemed to get me into this state of affairs. Well, the wipe and install went fine with no HPET problems. I did touch a couple BIOS settings, Changing boot order, and enabling PXE, but those changes didn't provoke any HPET problems. It is as if Dell, after installing the software, set some BIOS value different from what one gets when does "Load BIOS Defaults", and that THAT is the root of the problem. -- Jaunty will not boot on Dell Optiplex 760 unless hpet=disable https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless hpet=disable
Actually, I was the one who cut open the box. I also checked with the MIT folk who received the hardware from Dell. The settings are as they came from the factory. My current theory is that there are two defaults: "High Performance" defaults that are set at the factory before the system ships out, and "Always Works" defaults which are what you get when you choose the "Load BIOS Defaults". I've also got a call to my Dell inside rep to see if MIT has any Configure To Order BIOS customizations going in before the systems ship out of Dell. -- Jaunty will not boot on Dell Optiplex 760 unless hpet=disable https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless hpet=disable
Here is more information on the C States from the Dell Senior Tech: C3 Deep Sleep Stops all CPU internal and external clocks Pentium II and above, but not on Core 2 Duo E4000 and E6000; AMD Turion 64 http://www.hardwaresecrets.com/article/611/4 C4 Deeper Sleep Reduces CPU voltage Pentium M and above, but not on Core 2 Duo E4000 and E6000 series; AMD Turion 64 http://www.hardwaresecrets.com/article/611/5 When I read those hardwaresecrets articles, I didn't understand how a normally running CPU could get into state C3, but the Dell Senior Tech provided additional clarification and speculation: C3 is different from S3 (suspend / standby). C3 can be entered while the system is on and running the operating system (usually with no affect on system performance). The next state, Sleep (C3), cuts all internal clock signals from the CPU, including the clocks from the bus interface unit and from the APIC. This means that when the CPU is in the Sleep mode it can’t answer to important requests coming from the CPU external bus nor interruptions. That seems to mean that the CPU is not listening for interrupt requests over APIC which may be causing the HPET to malfunction. C4 is reached after further "idle" conditions, and has to transition to C3, then back up to C0, which could take longer for the APIC to allow interrupts. So I guess the question to ask the Linux HPET driver gurus is: What do you do when you've got a CPU that can stop listening to APIC interrupts behind your back? -- Jaunty will not boot on Dell Optiplex 760 unless hpet=disable https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless hpet=disable
It was suggested to me out of band to look at the output of powertop. So I enabled C States in the BIOS and got Jaunty running again (hitting the power switch 30-some times and the Ctrl key on the keyboard 500-some times to create interrupts to get it to where I could run powertop. powertop showed the system was in the C3 state some of the time. It reported interrupts from hpet3, hpet2, uhci_hcd:usb4, uhci_hcd:usb7, and Dell Laser mouse. But it ONLY would refresh when I did something with the keyboard or mouse to get interrupts. The HPET 3 and HPET 2 interrupts are NOT waking the system out of the C3 state. Once a keyboard or mouse actually DOES wake the system, the enqueued HPET interrupt is handled. When I boot the same Jaunty LiveCD and add "hpet=disable" the output of powertop seems quite sensible. It updates correctly. It says that the system is spending nearly all of its time in state C3 with 60% of the interrupts coming from something called, " extra timer interrupt". The next most frequent source of interrupts is "hr timer_start (tick_sched_timer)". Given this data from powertop, do you folks think we're talking a BIOS bug, a hardware bug, or a Linux bug? -- Jaunty will not boot on Dell Optiplex 760 unless hpet=disable https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless hpet=disable
Someone suggested out of band that I open a kernel.org bugzilla. By way of preparation for doing that, I searched the existing bugzilla for "ACPI CPU C3 interrupt" and turned up additional insight: In BZ 10409 http://bugzilla.kernel.org/show_bug.cgi?id=10409 it was suggested leaving HPET enabled, and applying boot option 'acpi_skip_timer_override' Running powertop with this option set, I am told the CPU is in C3 state 95.3% of the time, and that the wakeups are: 23% hpet3 18% hrtimer_start (tick_sched_timer) I suspect that to those who understand how HPET ACPI interrupts work, this is probably the key insight into understanding what to do next. Any suggestions for a next step for me to take? ** Bug watch added: Linux Kernel Bug Tracker #10409 http://bugzilla.kernel.org/show_bug.cgi?id=10409 -- Jaunty will not boot on Dell Optiplex 760 unless hpet=disable https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless hpet=disable
Fabián: Also make sure that the BIOS setting, "C States Control" under "Performance" is set in the BIOS. This setting is not enabled by default unless you go for an Energy Star Custom Factory Integration. As Mario said, the option is only available for higher end processors. -- Jaunty will not boot on Dell Optiplex 760 unless hpet=disable https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless hpet=disable
With the help of a senior Tech at Dell, the relevant BIOS bit has been identified: Under "Performance", the bit "C States Control" determines whether or not there will be a problem. If the additional processor sleep states are enabled by turning this option on, the HPET clock breaks. I have Dell checking in on where in the manufacturing cycle this bit gets turned on. It seems most likely that when MIT did "Custom Factory Integration" and enabled "Energy Star Setup" , we got this bit enabled. Mario: Armed with this bit of information, is there a clear way forward? -- Jaunty will not boot on Dell Optiplex 760 unless hpet=disable https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless hpet=disable
I have a Core 2 Duo E8400 CPU. The Dell Senior Tech said that the C States are available with CPU chips that have the "EIST" (for Enhanced Intel Speedstep Technology) processor option. He'd like to know which CPU he has to re-confirm that the option isn't present for your CPU. According to some google searching, the cpuinfo output should say "est" if that option is available. -- Jaunty will not boot on Dell Optiplex 760 unless hpet=disable https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 348694] Re: Jaunty will not boot on Dell Optiplex 760 unless hpet=disable
Thanks for the details, Mario. Apparently my CPU has the C States thing, but yours does not, but the clue as to who does and who does not isn't obvious. The Dell Tech is going to follow up to find out. So anybody wanting to reproduce my problem will need a fancier CPU than yours, but it isn't yet clear if the upgrade all the way up to the fanciness of mine is necessary. -- Jaunty will not boot on Dell Optiplex 760 unless hpet=disable https://bugs.launchpad.net/bugs/348694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 335666] Re: libc6 integration gives way wrong error message to libc5 binaries.
Which manpage should be improved?
Indeed you are technically correct that the obscure ld.so file is not
found.
It is too bad that the error message cannot tell the name of the file it
was looking for so as to provide both accurate and useful information.
Perhaps the fix is not to change a man page, and not to put a kludge
file in to patch around the problem but to change the kernel so "file
not found" becomes ("System library file %s not found", filename).
It would be really wonderful if we could evolve the kernel and other
subsystem code to be better at providing diagnostics that are useful and
correct, rather than continuing to rely on an oral tradition, or to
accept as complete a single line change in documentation that may not be
easily found when the problem occurs.
--
libc6 integration gives way wrong error message to libc5 binaries.
https://bugs.launchpad.net/bugs/335666
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"
I am trying to install Feisty on a Dell Optiplex 745 with a Radeon X1300 Pro. This bug prevents the installation from going forward because the X display starts up, but at 800x600, and starting with the VERY FIRST dialog of the installer, selection of the language, the "Next" button is further than 600 pixels down the page. The dialog cannot be resized any smaller. According to the Xorg.0.log file the DDC transfer that would ordinarily enable the X server to configure at higher resolution got NO data (but a successful transfer?). So Feisty is install is DEAD IN THE WATER on the popular Optiplex 745 line until this bug is fixed. (MIT was hoping to standardize on that Optiplex configuration but if we can't get past step one of the Ubuntu 7.04 install, it's bad both for the Dell config, and the support of Ubuntu at MIT. Attached is the Xorg.0.log I got. How can I help move this forward? William Cattey Linux Platform Coordinator Massachusetts Institute of Technology Cambridge, MA, USA ** Attachment added: "Xorg.0.log-ubuntu-7.04" http://librarian.launchpad.net/7731486/Xorg.0.log-ubuntu-7.04 -- [regression] 7.2 broke vesa: "No matching modes found" https://bugs.launchpad.net/bugs/89853 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"
I scrolled back a bit, and decided to try and follow the proffered procedure of running dpkg-reconfigure xserver-xorg Following that procedure, X is running off the Feisty Desktop Live CD at 1280x1024. Attached are the xorg.conf and Xorg.0.log files. The ones called "good" were after the reconfigure. THe ones called "old" are the ones from before running dpkg-reconfigure. (Presuming that the reconfigure made a backup file, and that the file xorg.conf.200705214138 is the backup. It appears so.) I note the following possibly very interesting observation: The Xorg.0.log file shows a SUCCESSFUL DDC transfer this time around. The xorg.conf file DELETES the line "load i2c". Does anyone else think this is significant? ** Attachment added: "Log of failed startup." http://librarian.launchpad.net/7731700/Xorg.0.log-ub-7.04-old -- [regression] 7.2 broke vesa: "No matching modes found" https://bugs.launchpad.net/bugs/89853 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"
One odd thing: That Xorg.0.log file I just attached was labeled Xorg.0.log.old, and to my mind, it should be the SAME as the Xorg.0.log-ubuntu-7.04 file I attached earlier. Oh! I forgot! I aborted the reconfigure-display once halfway through. This means that the xorg.conf.old I am about to attach may not be the old one. Sigh. ** Attachment added: "Successful startup after dpkg-reconfigure" http://librarian.launchpad.net/7731728/Xorg.0.log-ub-7.04-good -- [regression] 7.2 broke vesa: "No matching modes found" https://bugs.launchpad.net/bugs/89853 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"
** Attachment added: "xorg.conf that worked after dpkg-reconfigure" http://librarian.launchpad.net/7731737/xorg.conf-ub-7.04-good -- [regression] 7.2 broke vesa: "No matching modes found" https://bugs.launchpad.net/bugs/89853 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"
** Attachment added: "earlier version of xorg.conf that I think is valid." http://librarian.launchpad.net/7731738/Xorg.0.log-ub-7.04-old -- [regression] 7.2 broke vesa: "No matching modes found" https://bugs.launchpad.net/bugs/89853 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"
Sitsofe, in answer to your query: MIT, like many enterprises, standardizes on ONE hardware recommendation. Most customers buy it first and ask if Linux runs on it only later. We are following a successful multi-use recommendation of the Dell Optiplex GX 620 which served extremely well for both Windows and Linux use. MIT buys a LOT of Dell and a LOT of Optiplex, to the extent that at our recent Hardware Core Team meeting the discussion was, "Well, if Linux doesn't work on the Dell hardware we're buying this year, we'll just tell people to wait until next year to buy new desktop hardware. I.E. I don't get much choice about what hardwaqre we standardize upon. My job is "Make it work" whatever it is. -- [regression] 7.2 broke vesa: "No matching modes found" https://bugs.launchpad.net/bugs/89853 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"
The interpretation I make of your Xorg.log output, (and someone more knowledgable than I should correct me if I get this wrong) is: 1. You got a perfectly good EDID transfer that described your monitor. 2. Your monitor said the ONLY video mode it will accept is 1280x800. 3. The BIOS of the video card said it would accept 1280x1024, but made no mention 1280x800, and so the X server concluded it could not work. It looks like you're running an ATI Radeon X1400 on a widescreen laptop. -- [regression] 7.2 broke vesa: "No matching modes found" https://bugs.launchpad.net/bugs/89853 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"
Going back to Andrea Colangelo's comment, can someone who understands this better than I sanity check this? Xorg.0.log showed the monitor could support 1280x800: (II) VESA(0): Modeline "1280x800" 71.11 1280 1328 1360 1440 800 802 808 823 -hsync -vsync The bios returned SEVERAL 1280x1024 modes: Mode: 107 (1280x1024) Mode: 119 (1280x1024) Mode: 11a (1280x1024) Mode: 11b (1280x1024) Mode: 163 (1280x1024) Mode: 164 (1280x1024) Mode: 165 (1280x1024) Mode: 166 (1280x1024) Mode: 124 (1280x1024) but then it concluded: (II) VESA(0): Total Memory: 256 64KB banks (16384kB) (II) VESA(0): Generic Monitor: Using hsync range of 28.00-51.00 kHz (II) VESA(0): Generic Monitor: Using vrefresh range of 43.00-60.00 Hz (II) VESA(0): Not using built-in mode "1024x768" (no mode of this name) (II) VESA(0): Not using built-in mode "1024x768" (no mode of this name) (II) VESA(0): Not using built-in mode "800x600" (no mode of this name) (II) VESA(0): Not using built-in mode "800x600" (no mode of this name) (II) VESA(0): Not using built-in mode "640x480" (no mode of this name) (II) VESA(0): Not using built-in mode "640x480" (no mode of this name) (WW) VESA(0): No valid modes left. Trying less strict filter... Backtrace: 0: /usr/bin/X11/X(xf86SigHandler+0x81) [0x80c8641] 1: [0xe420] 2: /usr/bin/X11/X(InitOutput+0x9a4) [0x80a8304] 3: /usr/bin/X11/X(main+0x27b) [0x8076c7b] 4: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7d20030] 5: /usr/bin/X11/X(FontFileCompleteXLFD+0x1ed) [0x80761b1] Is that backtrace because of a possible bug in the "less strict filter"? It seems to me that an available 1280x1024 mode of the video card should be able to be masked off as a portal into a 1280x800 display, or am I just being silly? -- [regression] 7.2 broke vesa: "No matching modes found" https://bugs.launchpad.net/bugs/89853 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 107711] Re: Xorg does not detect Ati Radeon mobility x1300 during Ubuntu i386 7.04 install
*** This bug is a duplicate of bug 89853 *** https://bugs.launchpad.net/bugs/89853 One root cause of inability to find a proper X resolution is a flaky EDID transfer from the BIOS. This is due to code added to vm86.c to try and resolve noisy error messages from the auditing subsystem. This is not an issue on non-x86 systems which use the x86emu code instead of vm86 to talk to the BIOS of the ATI card. The definitive symptom here is if the EDID hex output in Xorg.0.log is missing, or mostly zeros. The definitive work-around until the vm86.c kernel bug is fixed, or a more clever approach to getting the EDID data is added to the X server, is to add the line: Option "Int10Backend" "x86emu" to the ServerLayout section of xorg.conf. -- Xorg does not detect Ati Radeon mobility x1300 during Ubuntu i386 7.04 install https://bugs.launchpad.net/bugs/107711 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"
With help from a friend, I built a test kernel that cuts out a change to vm86.c that silenced superfluous errors from the audit subsystem, but which messed with the registers on the return from the int10 call. That fixed the problem. We KNOW what the root cause is! ajackson from Red Hat also pointed out that one can do on the x86 platform what is done on the other platforms, use x86emu. So HERE is the bottom line: The definitive symptom here is if the EDID hex output in Xorg.0.log is missing, or mostly zeros. If you don't have this symptom, you're being bit by a different bug. The definitive work-around until the vm86.c kernel bug is fixed, or a more clever approach to getting the EDID data is added to the X server, is to add the line: Option "Int10Backend" "x86emu" to the ServerLayout section of xorg.conf. -- [regression] 7.2 broke vesa: "No matching modes found" https://bugs.launchpad.net/bugs/89853 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"
Wow! You're right. I should have gone back and reviewed the earlier log files. In the learning I've done since jumping into this situation, I think I understand what your problem is: In the situation when the EDID transfer is good, if the display offers a mode line that the BIOS does not support, you will lose. In the Xorg.log file you attached on 3/9/2007, indeed there's a good EDID transfer. A detailed modeline is supplied for 1280x800, but then there are no 1280x800 configurations offered by the BIOS. (If I've understood how the log file works, and my assumption that the detailed mode specs are from the BIOS, whereas the 1280x800 spec is from the monitor.) I have also been tracking my symptom in another bug. I apologize for inadvertently hijacking your bug. -Bill -- [regression] 7.2 broke vesa: "No matching modes found" https://bugs.launchpad.net/bugs/89853 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 121653] Re: [gutsy] fglrx breaks over suspend/resume
No ATI Catalyst 8 driver exists yet for the ATI Mobility FireGL V5200. The ati-driver-installer-8.443.1 run file creates an fglrx driver that does NOT work with the SLUB kernel. So on the IBM /Lenovo Thinkpad T61, suspend/resume wont work with the 2.6.23 kernel. I don't know if it's intentional, but when I upgraded from 7.04 to 7.10, a 2.6.20 kernel was left in place. Booting that kernel gives me a working suspend/resume, but the Mesa GL layer. (Probably because I didn't run the run file to create a kernel driver for the other kernel.) Two questions: 1. Can someone point me to the procedure to disable this driver and revert to the free driver? I thought I knew how to do it, but I kept coming up in 800x600, and I KNOW the free driver works better than that. 2. Can someone point me to where on the ATI web site I can vote, "PLEASE Hurry up and release Catalyst 8 for the FireGL V5200"? Or is there someone who has gotten this hardware to suspend / resume without rebuilding the kernel? -- [gutsy] fglrx breaks over suspend/resume https://bugs.launchpad.net/bugs/121653 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"
I just ran a new test case: I managed to run the version 6.8.2 X server under RHEL 5 which normally runs the 7.1.1 X server. I got it to go far enough to manifest the SAME "partial read with zero padding" flakiness that stock RHEL 5, and which Ubuntu 7.04 manifest. I conclude that this is a kernel problem. It seems to affect the VESA EDID fetch under Red Hat, Ubuntu, and perhaps SLED 10.1. I've never before submitted a bug to kernel.org, but that seems like the next step. Can anyone advise me the polite way to move this forward? Note that a stand alone utility, get-edid (which is actually available as the Debian read-edid package) is always 100% successful in the EDID transfer, and so part of the mystery is, "Why does X fail whereas the small stand-alone utility succeed?" Who wants to help resolve this mystery? Or are people going to say, "The reverse engineered Radeon Server is going to take care of this so we don't need to care." and wait for some OTHER manifestation of this bug to hurt people? -- [regression] 7.2 broke vesa: "No matching modes found" https://bugs.launchpad.net/bugs/89853 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"
S.Rey: Thanks very much for the clue of the keyboard accelerator to move the window. My problem was I could not find any way to do that. -- [regression] 7.2 broke vesa: "No matching modes found" https://bugs.launchpad.net/bugs/89853 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"
Folks, a friend helped me dig into the X server sources, and I now understand this situation much better. Many have suggested a work-around that involves setting explicit HorizSync and VertRefresh values. This will not help if your monitor is connected to the DVI port of the ATI Radeon X1300 series, (and probably related cards) because the DVI configuration carefully ignores any xorg.conf input, and goes with what is returned by the EDID BIOS transfer. The root cause here is flaky EDID BIOS transfer. My friend and I have posted up-to-date work on fault isolation on that EDID BIOS tranfer in Red Hat Bugzilla bug 236416 at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236416 By adding in a sleep(2) just before the EDID BIOS read, we get a partial or complete fetch of the monitor data. Apparently the latest 7.2 X server in use by Ubuntu 7.04 is able to time things differently by fiddling with the module load order. (I have Xorg.0.log file output showing failed or successful EDID transfers depending on the addition or deletion of a module load i2c line.) I've searched the x.org bug tree and found a relevant bug: https://bugs.freedesktop.org/show_bug.cgi?id=10238 But the understanding is not as detailed as what my friend and I have recorded n the Red Hat Bugzilla bug. I think that even the Fedora folks working this bug think the remedy is code to set explicit HorizSync and VertRefresh values, because that seems to be what is in the patch for Fedora 7 test3 which some people report as helpful. -- [regression] 7.2 broke vesa: "No matching modes found" https://bugs.launchpad.net/bugs/89853 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 107711] Re: Xorg does not detect Ati Radeon mobility x1300 during Ubuntu i386 7.04 install
*** This bug is a duplicate of bug 89853 *** https://bugs.launchpad.net/bugs/89853 Maarten: Could you attach /var/log/Xorg.0.log to this bug? I'm curious about details of what your X server has gotten from the EDID fetch. On my Dell Optiplex 745, the EDID fetch sometimes comes back all zeros, instead of actually providing the monitor config data. I have an xorg.conf that seems to more consistently fetch the EDID data, but I don't yet know why. Two differences are that the line: Load "i2c" is deleted and a line is added: Option "UseFBDev" "true" Things started working when I added these lines. They seem to have changed the timing of the EDID fetch such that it was successful more often. See also efforts to find the root cause of similar symptoms under Red Hat in the bug I opened there at: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236416 -wdc -- Xorg does not detect Ati Radeon mobility x1300 during Ubuntu i386 7.04 install https://bugs.launchpad.net/bugs/107711 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 107711] Re: Xorg does not detect Ati Radeon mobility x1300 during Ubuntu i386 7.04 install
*** This bug is a duplicate of bug 89853 *** https://bugs.launchpad.net/bugs/89853 I find your log output most interesting. Someone who understands the X configuration better than I should work on the question, "Why does the EDID data CLEARLY offer details for operation at 1280x800, but the X server configure itself down to 800x600?" The particular problem I'm working on has to do with the question, "How much of the EDID data block really SHOULD be coming up zeros?" If you look at your log output, you see the lines beginning, "EDID (in hex):" Those 128 bytes should ALWAYS be the same. If you're being bitten by the same bug that bites me, you will see them coming up randomly DIFFERENT with successive runs of the X server. This has the effect of only providing a partial fill-in of the data X wants in order to successfully configure the monitor. Something for you to try: Restart the X server several times, and watch that EDID output. See if it changes. Something that might get you going is to see if, in xorg.conf, you have 1280x1024 and 1024x768 in the "Modes" subsection of your "Screen" section, looking something like this: SubSection "Display" Depth 24 Modes "1280x1024" "1152x864" "1024x768" "800x600" "640x480" EndSubSection Maybe you're being bit by the bug I will get bit by in the FUTURE when the EDID transfer becomes successful, but the X server mis-applies the data. -- Xorg does not detect Ati Radeon mobility x1300 during Ubuntu i386 7.04 install https://bugs.launchpad.net/bugs/107711 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 107711] Re: Xorg does not detect Ati Radeon mobility x1300 during Ubuntu i386 7.04 install
*** This bug is a duplicate of bug 89853 *** https://bugs.launchpad.net/bugs/89853 Yes, I was playing with those lines in xorg.conf today, and they do not seem to be relevant to whether or not I get good EDID data. Sometimes my buffer is fully filled in. Sometimes it is only partiallly filled in. -- Xorg does not detect Ati Radeon mobility x1300 during Ubuntu i386 7.04 install https://bugs.launchpad.net/bugs/107711 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
