On Thu, 2008-08-07 at 21:58 +, bruce robson wrote:
>
> (II) intel(0): Fixed memory allocation layout:
> (II) intel(0): 0x-0x0001: ring buffer (128 kB)
> (II) intel(0): 0x0002-0x00024fff: HW cursors (20 kB)
> (II) intel(0): 0x00025000-0x0002cfff: logical 3D context (32 kB)
> (II
Evgeny M. Zubok wrote:
> I've searched in Google the similar bug reports and found that there was
> the problems with Trio64 on Alphas. More frequent advice to reporters
> was to enable "no_pci_disconnect" driver's option (you can type
> "no_pci_disconnect" in Google and read these bug reports). Bu
Doug Larrick wrote:
> Package: xserver-xorg-video-intel
> Version: 2:2.3.2-2+lenny2
> Severity: normal
>
>
> On my system (Asus P5E-VM HDMI, with onboard Intel G35 graphics),
> after a suspend-to-RAM cycle I cannot restart the X server -- it
> fails to find the graphics controller. I should note t
Package: xserver-xorg-video-intel
Version: 2:2.4.0-1
Followup-For: Bug #475112
Another lockup using 2.4.0 and xserver 1.4.99. This time there's a backtrace.
Here's the log:
(WW) Failed to open protocol names file /etc/X11/xserver/protocol.txt
This is a pre-release version of the X server from
Kai Hendry wrote:
> Currently debian live seems to use a 1:7.3+5 deprecated way of setting
> the resolution:
> http://git.debian.net/?p=live-initramfs.git;a=blob;f=scripts/live-bottom/21xvidemode;h=a11dc77a47f5d70f610b380a9ad5bcedd1c427db;hb=HEAD#l41
>
> Use debconf from which dexconf generated the
Currently debian live seems to use a 1:7.3+5 deprecated way of setting
the resolution:
http://git.debian.net/?p=live-initramfs.git;a=blob;f=scripts/live-bottom/21xvidemode;h=a11dc77a47f5d70f610b380a9ad5bcedd1c427db;hb=HEAD#l41
Use debconf from which dexconf generated the xorg.conf with the wanted
> I can put the S3 back in and get the lspci output for you, but it will
> be a few days before I can do so. The card itself and the bus it goes
> into is working, as OpenVMS on the same system does correctly
> initialize and use the display with the S3 card in place.
I've searched in Google the
I tried running with the NoDRI option in xorg.conf, but it still crashed
unexpectedly and unrecoverably. I have never experienced a crash when
not using firefox. Or, to put it differently, this has only ever
happened when firefox is running (both version 2 and 3, oh and by
firefox I mean iceweasel)
Package: libosmesa6
Version: 7.1~rc3-1
Severity: normal
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US
Package: xvfb
Version: 2:1.4.2-2
Severity: important
I run tests of a project that needs an X server on a nightly basis. For
years I've been running them off-screen using Xvfb. I start an
instance:
Xvfb :52 -screen 0 1024x768x24 -fbdir /tmp/xvfb.52 -ac
and then run tests with "DISPLAY=:52".
On Wed, 2008-08-06 at 13:31 +, bruce robson wrote:
>
> (==) intel(0): VideoRam: 131072 KB
FWIW, this doesn't necessarily mean it's actually using that much
memory. There should be a line in the log file like
(II) intel(0): Fixed memory allocation layout:
Followed by the memory blocks actua
On Thu, 2008-08-07 at 01:02 +0200, Frans Pop wrote:
>
> On possibly interesting thing about the lockup. When I noticed it the
> monitor was in powersave mode (i.e. black), but I could hear from the
> noise of the system's fan that screensaver was still running.
> Normally the screensaver will stop
12 matches
Mail list logo
