Kernel 4.9

[Srtest]

Is that card the same as the R9 series especially the bigger ones? no. Ask Hans. Eventually more users will come to this situation and then maybe it will get fixed. I have the same X1k as everyone with a most generic 8GB CF card to boot from. If everything works perfectly (except for issues that plague everyone who have similiar configs) and then from a certain kernel it does not then do not look at me. I'm fine using 4.7 as long as it works with my Lubuntu-LXQt installation.

Edit:

Ok, here that last possible difference I can think of: a Catweasel MK2 AmigaKit put together with the X1k at my request. From what I know about it it can't be the cause as it isn't recognizable if not enabled by software. Bear in mind it doesn't even get to the part where it can get stuck at those places like maybe a bad hd or connector. It gets stuck at the beginning which can only mean either the graphics card or something early in the boot process.

Its not the Catweasel, as I have one of those in my machine, they don't cause problems.
I don't think it is the graphics card either, The hang is happening right after the kernel quieses the open firmware. This is similar to the boot problem we had when they switched kernel addresses from constants to variables.

To see what's going on I need to either reproduce it (I can't) or see a serial boot log, which ATM only you can get for me as only you are affected.

Debugging kernel boot problems is tricky when you have an affected machine in front of you, almost impossible when you don't, I won't be able to look into this further until I have more info.

Regards
Darren

Suppose I go do that whole serial thing which I need to learn and buy something I guess, I need at least to understand why I'm doing it and in why I don't mean the reason you can't figure it out without watching a serial output but what changed after 4.7 that could have caused it, given that X1k systems are very similar and other users have SI cards that work with 4.8. I mean, what else could it be other than the graphics card in a perfectly working X1k machine? my only other guess is something that was patched out that didn't include all conditions. I remember a case when on the AmigaOS side the guy who made the new JIT E-UAE emulator wanted to produce a version specifically for the X1k and couldn't do it, yet a more generic approach such as something that works on a G5 - was enough to get it done.

[xeno74]

Hi All,

Today, I have released two RC6 kernels for testing. A default kernel with Radeon support and a kernel with amdgpu support for SI graphics cards. (DRM_AMDGPU_SI)
I successfully tested the default kernel with Radeon support on my AmigaOne X1000 today. The second kernel with amdgpu support for SI graphics cards is untested.

Further news:

• Driver for Realtek RTL8712 USB wireless network adapters as kernel module
• PowerPC updates (powerpc-4.9-5)
• The 4.9-rc6 announcement
• Linux 4.9-rc6 Released, Final Might Be Pushed Back By Another Week -- phoronix
• Linux Git log
• Phoronix articles, reviews and news stories covering Linux 4.9

Download: vmlinux-4.9-rc6-AmigaONE_X1000.tar.gz

Screenshot of ubuntu MATE 16.04.1 LTS PowerPC with the kernel 4.9-rc6 and Cool-Retro-Term:



@zappa2009
Please test the RC6 with your Edimax EW7612 UAn V2 USB wireless network adapter. You need to copy the kernel modules directory 4.9.0-rc6_A-EON_AmigaONE_X1000_Nemo to /lib/modules.

@All
Please test the RC6.

Thanks,
Christian

[Srtest]

I don't know how to say it one more time: no kernel works for me since 4.7. That darren patch that fixed things for all of you NI guys didn't do so for me with a R9-270 GCN 1.0. It goes to a very early boot stage when it says - "boots something something ........" and then nothing. It is similiar to the way the microcode didn't work a few kernels back until it was reverted.

I have finally made progress and what I mean by progress is getting closer to know what is this situation. Xeno's split kernels between RADEON and AMDGPU provided more information as there is a difference for me between the 2:

When I boot with the "normal" modules of RADEON I get to that early message and it gets stuck. However, when booting with the AMDGPU modules I get past that message yet get a black screen (of death?) that is exactly the same screen and the same behaviour I got last time when the microcodes didn't work for SI users. I guess now it is the same situation that doesn't affect all users of SI (from what I read the users who reported back didn't have a R9 card) or at least most importantly - a graphics card situation. Debian have recently updated their AMD microcode I guess it is time to check a different microcode with my card via the early boot microcode/modules and continue from there. My guess it is exactly the same situation as last time.

[xeno74]

FYI

powerpc: disable IDE subsystem in pasemi_defconfig

[zappa2009]

@zappa2009
Please test the RC6 with your Edimax EW7612 UAn V2 USB wireless network adapter. You need to copy the kernel modules directory 4.9.0-rc6_A-EON_AmigaONE_X1000_Nemo to /lib/modules.

@All
Please test the RC6.

Thanks,
Christian

Hi Xeno74

I tested the New Kernel 4.9-rc6 with my USB-Wlan-Stick. It don't connect to my Wlan.
And with my R7 250x I cannot get a Screen with vmlinux-4.9-rc6 and the same with vmlinux-4.9-rc6-amdgpu. ( I changed the Xorg bevor i boot).

[xeno74]

Hi Xeno74

I tested the New Kernel 4.9-rc6 with my USB-Wlan-Stick. It don't connect to my Wlan.
And with my R7 250x I cannot get a Screen with vmlinux-4.9-rc6 and the same with vmlinux-4.9-rc6-amdgpu. ( I changed the Xorg bevor i boot).

Many thanks for testing.

OK, we know, that the AMDGPU SI driver doesn't work but it is very strange that the default kernel doesn't work with zappa2009's R7 250x.

@Srtest
Any hints?

@zappa2009
Have you seen any error messages?

The new Realtek RTL8712 driver is still in the staging tree of the Linux kernel. Maybe it's not stable or reliable.

The Linux Staging Tree, what it is and is not.

Code: Select all

What the Linux Staging tree is:
  The Linux Staging tree (or just "staging" from now on) is used to hold
  stand-alone[1] drivers and filesystems that are not ready to be merged into
  the main portion of the Linux kernel tree at this point in time for various
  technical reasons.  It is contained within the main Linux kernel tree so
  that users can get access to the drivers much easier than before, and to
  provide a common place for the development to happen, resolving the
  "hundreds of different download sites" problem that most out-of-tree drivers
  have had in the past.

What the Linux Staging tree is not:
  The staging tree is not a place to dump code and run away, hoping that
  someone else will to the cleanup work for you.  While there are developers
  available and willing to do this kind of work, you need to get them to agree
  to "babysit" the code in order for it to be accepted.

Location and Development:
  The staging tree is now contained within the main Linux kernel source tree
  at the location drivers/staging/.  All development happens within the main
  kernel source tree, like any other subsystem within the kernel.  This means:
	- the linux-next tree contains the latest version of the staging tree,
	  with bugfixes that are about to be merged into Linus's tree, as well
	  as the patches that are to be merged into the next major kernel
	  release.
	- if you wish to do work on the staging tree, checkout the linux-next
	  tree and send patches based on that.

Runtime:
  When code from the staging tree is loaded in the kernel, a warning message
  will be printed to the kernel log saying:
    MODULE_NAME: module is from the staging directory, the quality is unknown, you have been warned.
  and the kernel will be tainted with the TAINT_CRAP flag.  This flag shows up
  in any kernel oops that might be produced after the driver has been loaded.

  Note, most kernel developers have expressed the warning that they will not
  work on bugs for when this taint flag has happened, so if you run into a
  kernel problem after loading such a module, please work to reproduce the
  issue without a staging module loaded in order to be able to get help from
  the community.

[xeno74]

@zappa2009

Maybe the BusID isn't correct for your R7 250x. I have figured out, that it is very important to set the BusID correctly. Without the BusID or with the incorrect BusID, Xorg doesn't start with my Radeon HD6870.

Code: Select all

BusID "PCI:1:0:0"

Sometimes I have to set

Code: Select all

Option "RenderAccel" "false"

additionally.

[zappa2009]

BUSID and RenderAccellerate=False done but anyway noscreen.

I have attach Output from lspci and inxi.

[xeno74]

BUSID and RenderAccellerate=False done but anyway noscreen.

I have attach Output from lspci and inxi.

Thank you. Could you please post the dmesg output and the Xorg.0.log?

[zappa2009]

Sure here it is.

Xorg.logs_Debian9_Lubuntu.zip

Look inside ;)

(50.12 KiB) Downloaded 242 times

Lubuntu: I habe the Xorg.0.log only because it hangs bevor i get a console.
Debian9: I have dmesg output and Xorg.0.log

Its all in the zip attached.

Boot with initrd-4.9-rc6 bootargs /dev/sda4(or sda6) and kernel4.9-amdgpu with R7-250X 1GB DDR5 Club3D