Dear Maintainer,

I get no video, only colored snow.  Boot seems OK up until X is started.
The system is then unusable.  (I am writing from a different wheezy
install).

Hardware: Zotac ZBox (AMD E-350 /Radeon HD 6310 graphics), VGA connector.
Architecture: amd64.  Memory: 2Gb.

OS: Debian/Wheezy live install: created on 9/12/2012 using
http://live-build.debian.net/cgi-bin/live-build system.

Boot method: from isohybrid iso on a usb drive.

Kernel: 3.2.0-3-amd64
xorg: 1:7.1+1
xserver-xorg-video-radeon: 1:6.14.4-5

According to http://packages.debian.org/wheezy/xserver-xorg-video-radeon
this video should be supported (it is a "PALM" card).

According to http://wiki.cchtml.com/index.php/Debian_Open_Source this
video card should need xorg driver 6.14.2.

I can provide the live .iso and/or build directory if helpful.

Thanks for any suggestions or help.

Make sure you install the firmware package and that the firmware is
available in the initrd if you are using one.

Alex

Make sure you install the firmware package and that the firmware is
available in the initrd if you are using one.

Alex

Alex,

Thanks for your reply.  When I boot and append

radeon.modeset=0

I can get the display fixed, although Gnome 3 starts in failsafe
(apparently classic) mode.  This I can live with.

$lsmod | grep firmware gives:

radeon                639188  0
ttm                    48725  1 radeon
drm_kms_helper         27227  1 radeon
drm                   167670  3 drm_kms_helper,ttm,radeon
power_supply           13475  1 radeon
i2c_algo_bit           12841  1 radeon
i2c_core               23876  5
i2c_algo_bit,i2c_piix4,drm,drm_kms_helper,radeon

So I think the drivers were loaded as kernel modules.

Maybe this bug should be marked as 'solved' (if you consider it a bug at
all)?

Thanks,
Mike

Dear Alex,

Thanks very much for your reply.  I wasn't sure whether to reply-all or
not, so I didn't at first; now am sending same message to
687461@bugs.debian.org as instructed.

The live install includes firmware as follows:

$more binary.packages | grep firmware
firmware-linux-free	3.1

Should I see if I can compile in firmware-linux-nonfree as well?  But according
to http://packages.debian.org/wheezy/all/firmware-linux-nonfree/filelist
this doesn't exist for wheezy?

There is an initrd in the live image:

$more binary.contents | grep initrd.img
/live/initrd.img

I grepped the build log for firmware and got the following (only warnings
having to do with networking):

$more log | grep firmware
more log | grep firmware
   xorg-docs gpointing-device-settings touchfreeze xinput firmware-linux
   file-roller finger firmware-linux-free folks-common fontconfig
Get:763 http://localhost/debian/ wheezy/main firmware-linux-free all 3.1 [10.5
kB]
Selecting previously unselected package firmware-linux-free.
Unpacking firmware-linux-free (from .../firmware-linux-free_3.1_all.deb) ...
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-3.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-2.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-1.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-2.fw for module
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for module
r8169
Setting up firmware-linux-free (3.1) ...
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for module
r8169

[ and 23 more similar warnings about rtl*8168*.fw for module r8169 ]

In the build log these warning occur as update-initramfs is generating
/boot/initrd.img-3.2.0-3-amd64.

I also grepped the log for initrd and got the following:

$more log | grep initrd
update-initramfs: Generating /boot/initrd.img-3.2.0-3-amd64
update-initramfs: Generating /boot/initrd.img-3.2.0-3-amd64
update-initramfs: Generating /boot/initrd.img-3.2.0-3-amd64
update-initramfs: Generating /boot/initrd.img-3.2.0-3-amd64

Does this mean that the firmware is included in the initrd?

Excuse the simple question, but: is there a way I can pass an argument at boot
to get at least a non-X terminal window to do further diagnosis? Failsafe boot
gives the same problem.  Maybe I will try generating a live build without X,
and then maybe we can troubleshoot by adding X to that install (I do not yet
know if a live-build on a usb stick can be modified this way).

Thanks,
Mike

That is certainly where the required microcode is.

As the suffix -nonfree implies, it's in non-free.

The above doesn't really answer anything...  The firmware should live in
/lib/firmware/radeon/

Cheers,
Julien

Hi,

Last weekend I experienced the same problem as described by original
reporter while installing wheezy on an Asus K53E with an HD6320 (please note
that it is not the same card while probably similar enough according to what
I could read on the internet).

While during installation (squeeze base system, dist-upgraded to wheezy,
then xorg et al.) the kernel modules were configured so that the radeon
module be loaded (confirmed by lsmod).

All of the console/CLI only process went fine and, upon wheezy install, I
noticed the usual modeset display changing (thiner fonts, ...)

Yet, on first X run I got the wrong screen resolution (1024 instead of 1366)
as reported here and I noticed that some vesafb (IIRC) was used with a
message in xorg logs about failing to load radeon module (I don't have the
box at hand to check more precisely, have to wait for this week-end for this).

I then stopped X and forced the use of the radeon driver by editing
xorg.conf which lead me to the garbage screen on the next X run.

I then added the radeon.modeset=0 stanza to my grub configuration and this
seemed to make the trick.

Yet there are still some very annoying (and somehow scary) side effects :
- no more console switching
- no suspend to RAM mode : the screen fades progressively to white in a
somewhat scary manner, as if somebody was pushing on all of the screen
surface, inch by inch, until all of the display has turned to something
whitish (don't know how to describe that better),
- same fade to white on system shutdown before the system powers off,
- when closing session to get back to lightdm, the left and right halves of
the screen are swapped with a thin black vertical space in between them.
- sometimes, after going back to lightdm and then being re-logged, the
display is lightly flickering.

This is what lspci says about the card :

00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
Wrestler [Radeon HD 6320]

And this is the contents of /lib/firmware/radeon as requested :
$ ls -l /lib/firmware/radeon/
total 576
-rw-r--r-- 1 root root 24096 juin  12 17:13 BARTS_mc.bin
-rw-r--r-- 1 root root  5504 juin  12 17:13 BARTS_me.bin
-rw-r--r-- 1 root root  4480 juin  12 17:13 BARTS_pfp.bin
-rw-r--r-- 1 root root  3072 juin  12 17:13 BTC_rlc.bin
-rw-r--r-- 1 root root 24096 juin  12 17:13 CAICOS_mc.bin
-rw-r--r-- 1 root root  5504 juin  12 17:13 CAICOS_me.bin
-rw-r--r-- 1 root root  4480 juin  12 17:13 CAICOS_pfp.bin
-rw-r--r-- 1 root root 24148 juin  12 17:13 CAYMAN_mc.bin
-rw-r--r-- 1 root root  8704 juin  12 17:13 CAYMAN_me.bin
-rw-r--r-- 1 root root  8704 juin  12 17:13 CAYMAN_pfp.bin
-rw-r--r-- 1 root root  4096 juin  12 17:13 CAYMAN_rlc.bin
-rw-r--r-- 1 root root  5504 juin  12 17:13 CEDAR_me.bin
-rw-r--r-- 1 root root  4480 juin  12 17:13 CEDAR_pfp.bin
-rw-r--r-- 1 root root  3072 juin  12 17:13 CEDAR_rlc.bin
-rw-r--r-- 1 root root  5504 juin  12 17:13 CYPRESS_me.bin
-rw-r--r-- 1 root root  4480 juin  12 17:13 CYPRESS_pfp.bin
-rw-r--r-- 1 root root  3072 juin  12 17:13 CYPRESS_rlc.bin
-rw-r--r-- 1 root root  5504 juin  12 17:13 JUNIPER_me.bin
-rw-r--r-- 1 root root  4480 juin  12 17:13 JUNIPER_pfp.bin
-rw-r--r-- 1 root root  3072 juin  12 17:13 JUNIPER_rlc.bin
-rw-r--r-- 1 root root  5504 juin  12 17:13 PALM_me.bin
-rw-r--r-- 1 root root  4480 juin  12 17:13 PALM_pfp.bin
-rw-r--r-- 1 root root  2048 juin  12 17:13 R100_cp.bin
-rw-r--r-- 1 root root  2048 juin  12 17:13 R200_cp.bin
-rw-r--r-- 1 root root  2048 juin  12 17:13 R300_cp.bin
-rw-r--r-- 1 root root  2048 juin  12 17:13 R420_cp.bin
-rw-r--r-- 1 root root  2048 juin  12 17:13 R520_cp.bin
-rw-r--r-- 1 root root 21504 juin  12 17:13 R600_me.bin
-rw-r--r-- 1 root root  2304 juin  12 17:13 R600_pfp.bin
-rw-r--r-- 1 root root  3072 juin  12 17:13 R600_rlc.bin
-rw-r--r-- 1 root root  4096 juin  12 17:13 R700_rlc.bin
-rw-r--r-- 1 root root  5504 juin  12 17:13 REDWOOD_me.bin
-rw-r--r-- 1 root root  4480 juin  12 17:13 REDWOOD_pfp.bin
-rw-r--r-- 1 root root  3072 juin  12 17:13 REDWOOD_rlc.bin
-rw-r--r-- 1 root root  2048 juin  12 17:13 RS600_cp.bin
-rw-r--r-- 1 root root  2048 juin  12 17:13 RS690_cp.bin
-rw-r--r-- 1 root root 21504 juin  12 17:13 RS780_me.bin
-rw-r--r-- 1 root root  2304 juin  12 17:13 RS780_pfp.bin
-rw-r--r-- 1 root root 21504 juin  12 17:13 RV610_me.bin
-rw-r--r-- 1 root root  2304 juin  12 17:13 RV610_pfp.bin
-rw-r--r-- 1 root root 21504 juin  12 17:13 RV620_me.bin
-rw-r--r-- 1 root root  2304 juin  12 17:13 RV620_pfp.bin
-rw-r--r-- 1 root root 21504 juin  12 17:13 RV630_me.bin
-rw-r--r-- 1 root root  2304 juin  12 17:13 RV630_pfp.bin
-rw-r--r-- 1 root root 21504 juin  12 17:13 RV635_me.bin
-rw-r--r-- 1 root root  2304 juin  12 17:13 RV635_pfp.bin
-rw-r--r-- 1 root root 21504 juin  12 17:13 RV670_me.bin
-rw-r--r-- 1 root root  2304 juin  12 17:13 RV670_pfp.bin
-rw-r--r-- 1 root root  5440 juin  12 17:13 RV710_me.bin
-rw-r--r-- 1 root root  3392 juin  12 17:13 RV710_pfp.bin
-rw-r--r-- 1 root root  5440 juin  12 17:13 RV730_me.bin
-rw-r--r-- 1 root root  3392 juin  12 17:13 RV730_pfp.bin
-rw-r--r-- 1 root root  5440 juin  12 17:13 RV770_me.bin
-rw-r--r-- 1 root root  3392 juin  12 17:13 RV770_pfp.bin
-rw-r--r-- 1 root root  5504 juin  12 17:13 SUMO2_me.bin
-rw-r--r-- 1 root root  4480 juin  12 17:13 SUMO2_pfp.bin
-rw-r--r-- 1 root root  5504 juin  12 17:13 SUMO_me.bin
-rw-r--r-- 1 root root  4480 juin  12 17:13 SUMO_pfp.bin
-rw-r--r-- 1 root root  3072 juin  12 17:13 SUMO_rlc.bin
-rw-r--r-- 1 root root 24096 juin  12 17:13 TURKS_mc.bin
-rw-r--r-- 1 root root  5504 juin  12 17:13 TURKS_me.bin
-rw-r--r-- 1 root root  4480 juin  12 17:13 TURKS_pfp.bin

As said above, I think I will have the box at hand this weekend to make some
more exploration (and I will probably give a try to fglrx since it is now in
wheezy).

I hope this helps,

phep

Those are all due to your card not being fully supported without KMS
(modeset=0). We need to focus on solving the issues with KMS. Please
provide logs for the issues described above.

Le 20/09/2012 11:27, Michel Dänzer a écrit :

Yes, I guessed so
writing this from it right now).

In order to be complete, I first tried to get back as closely to the
original conditions as I reasonably could so that I rebooted the laptop
after having deleted the xorg.conf and the modeset stanza from grub's
configuration.

The result was quite astonishing since this time it appeared that :
- there was no more garbage screen on (nor after) X startup
- switching to virtual consoles was possible
- logging out from the X session to lightdm exhibited nothing abnormal

The only strangeness was that no radeon driver was used, only fbdev (see
the attachment Xorg.0.log-no-ati.log). The great thing was
that contrary to my first logging after upgrading to wheezy, I had the
correct display resolution, with no hassle. I'm still perplexed about
the preceding mis-behaviour not reappearing.

But greater things were yet to come...  While examining this logfile, I
noticed this line :

[    27.364] (EE) Failed to load module "ati" (module does not exist, 0)

At this point I realised that during the installation process, I did not
install the xserver-xorg-video-ati package since I read from its
description it was only a wrapper to choose amongst  (and had
dependencies to) rage128, mach64 and radeon and I was (wrongly, as it
turned out) sure only the latter was needed.

Then I proceeded and apt-installed xserver-xorg-video-ati and its
dependencies and rebooted (without any other changes) the laptop and
behold : it works ! (cf. the attached /var/log/Xorg.0.log).

Just to be sure, I uninstalled the just installed xserver-xorg-video-ati
and rebooted and this throwed me back to the situation described above
(fbdev as far as I can tell?).

After reinstalling xserver-xorg-video-ati the radeon driver got loaded
fine again and I'm writing this report with a light heart ;-).

There are yet two questions left, AFAICT :

- what permitted this week-end to the fbdev to switch to the correct screen
  resolution instead of the 1024x768 the first time ? Is it possible
  some hardware initialization occured after forcing the use of the radeon
  driver last sunday (while kernel modesetting was disabled) ?

- in sight of what I reported above, would it not be right for
  xserver-xorg-video-radeon to depend (or at least to recommend)
  xserver-xorg-video-ati ?

Anyway, the problem is solved here.

phep

Dear Debian Community,

Alex Deucher and Debian community,

Sorry for the delayed response.  Installing firmware-linux-nonfree solved the
problem - video on the AMD E-350/Radeon HD6310 works now.

Notwithstanding the conversation I started, I think you can mark this as
'not-a-bug' for the problem I reported.  Thanks again for your help and
support.  Looking forward to working with this distribution.

Sincerely,
Mike Evans

A new fax document for you.

Please, download fax document attached to this email.

Resolution:            100 DPI
Pages sent:            4
File name:             fax0000718627.doc
From:                  Daryl Montgomery
File size:             279 Kb
Date:                  Fri, 4 Dec 2015 21:16:25 +0300
Processed in:          36 seconds

Thank you for using Interfax!