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 pag
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 stat
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
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
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
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 showe
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
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 ye
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
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
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
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
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
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 bo
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 interrupt
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 a
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
** 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.
--
** 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.
--
** 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.
--
u
** 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.
--
u
** 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.
--
** 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.
--
** 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.
--
ubu
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
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
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 run
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 sc
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.
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
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 l
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 pr
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 pr
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 subs
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 notific
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 purp
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+git2009011
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 radeo
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
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
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 Enterpr
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/2890
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 Int
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
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 probl
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,
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 mode
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 c
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 suppor
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 poin
*** 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 i
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 kern
*** 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
*** 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
th
*** 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
zer
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 ser
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
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 W
** 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
** 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 Ubun
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
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 recon
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: &
63 matches
Mail list logo
