Jon Peatfield wrote:
> On Mon, 28 Apr 2008, John Summerfield wrote:
>
>> John Summerfield wrote:
>>> John Summerfield wrote:
>>>
>>> I have installed 64-bit SL5.1 on this machine
>>> > HP DC7700, Intel(R) Pentium(R) Dual CPU E2140 @ 1.60GHz, 5
>>> Gbytes, > 2x80 Gb (Windows XP on the first).
>>> > > _That_ is (almost) the worst.
>>> > > Additionally, I can't change consoles, either with the usual
>>> keyboard > magic or, having logged in remotely so as to look around,
>>> using the chvt > command.
>
> We have found that with the Intel chipsets an XFree86/Xorg you seem to
> have two options:
>
> use the intel driver and suffer problems with changing VT or restarting
> X causing problems and lock-ups
>
> use the vesa driver and have no/poor acceleration and a lack of some
> other features (like DPMS support).
On your advice, I switched from using i810 to vesa, and it looked good
for a while except that the active konsole window looked like I'd
pressed <enter> a hundred or more times.
Then, trying to quantify that, I reproduced the flashing blank screen.
Possibly the fact I wish to run xen is complicating things; a kernel
framebuffer (vesafb I think) works fine in the non-xen kernel, but not
at all in xen. On other systems I can modprobe intelfb and that works,
but it doesn't support this system.
>
> we try to avoid (where possible) using any (usually built-in) intel
> graphics chipset with X by adding a graphics card to all desktop machines.
That's on my mind. A complication is the low profile case, but I think I
have one or two salvaged from Dell GX270s that might serve.
>
> Of course the cards supported properly by Xorg in SL5 isn't a huge list
> we have had good experiences with the AIT X300/X600 cards but those are
> no longer commonly available.
>
> Any of the newer cards (X1300 etc) arn't supported by the ati/radeon
> driver so one is back to using vesa there.
>
> With the vesa driver these seems to be no simple way to tell if things
> like DPMS, DDC probing will actually work (reliably). I'm told that on
> some cards they do work but it doesn't seem to do so on the cards I've
> tested here...
Anything that works at all beats the current position.
>
>>> > In fact, the keyboard (an HP USB keyboard no less) seems to be
>>> locked > up.
>>>
>>> I installed the non-Xen kernel and X seemed okay with it, but I didn't
>>> test much. I rebooted to Xen and, again, X _looked_ okay.
>>>
>>> I could switch to tty1, but when i switched back X didn't reinitialise
>>> properly. Instead, it flashed between grey and black.
>>>
>>> control-alt-BS kills it, but on restarting the flashing resumes. Nor
>>> does
>>> this do better:
>>>
>>> [root@bobtail ~]# telinit 3
>>> [root@bobtail ~]# telinit 5
>>>
>>> I will now return to the non-Xen kernel and see what's what.
>>> <reboots>
>>> That problem does not occur. However, the login screen is displayed at
>>> 800x600. I logged in, and a couple of "xvidtune -next" command had
>>> it at
>>> 1280x1024 (the screen's resolution), but the desktop was an 800x600
>>> window
>>> the viewer's left, top and partly replicated (it extends off-screen)
>>> right, top.
>
> It probably isn't picking up the monitor data (DDC) properly so is
> running with the safest of all resolutions. You may be able to manually
> tell it the right data by specifying the exact monitor model in the
> advanced settings of system-config-display or manually editing the
> Xorg.conf
>
> Does it list anything interesting about the monitor or DDC in the xorg log?
I have X working at 1280x1024 and that's about as well as my eyes will
do (or the screens for that matter).
>
>>> From there, control-alt-BS killed X and it restarted at the correct
>>> resolution!
>>>
>>> <reboots>
>>> <shrug>
>>> Didn't happen this time.
>>> OTOH it's back to its flashing behaviour.
>>>
>>> I did this:
>>> telinit 3;sleep 20s;telinit 5
>>> and now the bottom of the login screen's at the top, the area from
>>> (about)
>>> username and down is light grey and the whole thing's flashing.
>>>
>>>
>>> I should also mention that every time, when X first starts there's a
>>> area
>>> of video corruption at the bottom ot the screen, 3 cm or so, briefly
>>> and
>>> then the screen (maybe) comes good.
>
> That is quite common. The video chipset gets re-programmed to the new
> video mode before the memory is cleared so you see junk based on what
> was displayed previously. e.g. on our Dell machines we see a corrupted
> version of the Dell boot logo flash past...
>
>>> I have an IBM Thinkcentre with this graphics card:
>>> 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated
>>> Graphics Controller (rev 02)
>>>
>>> as compared with HP's choice
>>> [root@bobtail ~]# lspci -s 00:02.0
>>> 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965
>>> Integrated Graphics Controller (rev 02)
>>> [root@bobtail ~]#
>>>
>>> I copied the Thinkcentre's configuration across, the result's the same.
>>>
>>> The vesa driver does not work at all. It gives lots of promising
>>> messages,
>>> a few warnings and no errors (EE messages).
>>>
>>> the intel driver doesn't support it.
>
> So if neither the intel nor vesa driver works what driver are you using
> to get anything displayed?
Evidently I've forgotten some of what I did.
There are three plausible X drivers.
"intel" doesn't support the chip
"i810" displays, but badly - I thought I had an almost usable display
(ie it could be read), but just now repeated efforts to use it just have
it flashing. (I rebooted to non-xen and got various behavious, all
flashing and all unusable. Sometimes part or all of the login screen is
visible).
Oh, maybe I've not lost all my marbles. With the non-Xen kernel and the
vesa driver, I get a blank screen. Switching beteeen runlevels 3 and
five, and use of chvt has no visible effect.
With the linux framebuffer, fbdev is an option. It's interesting. Not
useful, but interesting. It looks like a negative, the login panel (I'm
using kdm) is low on the screen, so a part of the "password" area is off
the bottom. Additionally, the panel wraps so that it splits between
"Welcome to Linux a" and "t bobtail." (actually, the "t" is split).
This has errors:
[root@bobtail ~]# grep -w EE /var/log/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(EE) FBDEV(0): FBIOBLANK: Invalid argument
(EE) FBDEV(0): FBIOBLANK: Invalid argument
[root@bobtail ~]#
chvt beteen 1 and 7 a few times seems harmless. Nor does telinit to
change runlevesl a few times do anything untoward.
"vesa" under Xen gets me a login screen.
"chvt 1;sleep 5s;chvt 7" a few times and I get the flicker.
A couple more and the flicker's gone.
>
>> Does nobody have an idea? The system's completely unusable at present.
>
> Add a different video card. I like ATI cards but I know that others
> prever nvidia models (which have the advantage of still being available
> though last time I checked we didn't get *good* acceleration with the
> 'nv' driver)...
>
> As a rule of thumb the older/cheaper the video card the more likely that
> Xorg actually supports it since it will probably have been out for
> longer and had many people trying to make it work.
I have another system, running Fedora 9 beta.Graphics is fine there
(including under Xen), so running newer X is a possibility. It doesn't
look like EPEL has it, so I might try building it myself.
>
> On laptops (or some desktops) where one can't alter the video hardware
> you can't add a new card so have to live with what is provided.
>
> On my (test) HP 6720s laptop which has an intel graphics chipset the
> Xorg in both ubuntu feisty (710) and hardy (804) seem to drive it ok
> with the intel driver. Of course I'm not doing anything complex there.
> Perhaps the chipsets in common models of laptop get more widely tested
> than those in desktop systems...
>
--
Cheers
John
-- spambait
[log in to unmask] [log in to unmask]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
|
