BionicDog (updated: 2018-06-04)

[rcrsn51]

Run Bionic again and look in /var/log/Xorg.0.log.

Try to identify the actual Xorg driver that was loaded. (This file is a mystery to me.)

I looked at the firmware package but I can't see anything specific to your video card.

[Mike Walsh]

@ rcrsn51:-

OK; will do.

I'll have to get back to you a bit later on this, Bill; family's just turned up. I'll let you have the readout from that file as soon as...all right?


Mike.

[Mike Walsh]

@ rcrsn51:-

One Xorg.0.log, as requested.

I've had a quick look through it; it appears to be loading both 'ati' and 'radeon' modules, I did see that much. Not certain which one it's attempting to use, though.

Perhaps some peculiarity of this particular kernel? (*shrug*)


Mike.

[fredx181]

@ Mike, Bill

From what I see in it's description, the (installed) package "xserver-xorg-video-radeon" should support the RS480 chip :

X.Org X server -- AMD/ATI Radeon display driver

This package provides the 'radeon' driver for the AMD/ATI cards. The
following chips should be supported: R100, RV100, RS100, RV200, RS200,
RS250, R200, RV250, RV280, RS300, RS350, RS400/RS480, R300, R350, R360,
RV350, RV360, RV370, RV380, RV410, R420, R423/R430, R480/R481,
RV505/RV515/RV516/RV550, R520, RV530/RV560, RV570/R580,
RS600/RS690/RS740, R600, RV610/RV630, RV620/RV635, RV670, RS780/RS880,
RV710/RV730, RV740/RV770/RV790, CEDAR, REDWOOD, JUNIPER, CYPRESS,
HEMLOCK, PALM, SUMO/SUMO2, BARTS, TURKS, CAICOS, CAYMAN, ARUBA, TAHITI,
PITCAIRN, VERDE, OLAND, HAINAN, BONAIRE, KABINI, MULLINS, KAVERI, HAWAII.

Fred

[Mike Walsh]

@ Fred:-

The silly thing is, it's not the desktop that's freezing-up; that still responds!

It's just the individual applications that are seizing solid. Figure that one out, if you can.....


Mike.

[fredx181]

@ Fred:-

The silly thing is, it's not the desktop that's freezing-up; that still responds!

It's just the individual applications that are seizing solid. Figure that one out, if you can.....


Mike.

Weird..., let me understand exactly "it's not the desktop that's freezing-up".
You mean mouse and keyboard are still working, but that's all.. or... ?

Fred

[LateAdopter]

I've had a quick look through it; it appears to be loading both 'ati' and 'radeon' modules, I did see that much. Not certain which one it's attempting to use, though.

As I understand it, ati is just a loader that determines which, out of radeon, r300g, r600g, radeonSI... to load, according to the gpu that is present. Radeon is the driver being used.

[tlchost]

Thanks...it did not see my adapter...went to the iogear website ...

I also have an IOGear adapter and it works. It identifies in lsusb as a Broadcom BCM20702A0.

How do you know that your adapter is not working? Do you get the initial pop-up message about the BlueAlsa daemon not starting? That may be a separate issue.

yes....not starting

Type: hcitool dev
Does that see the adapter?

If not, type: hciconfig hci0 up , then hcitool dev
Does that see the adapter?

yes
Devices:
hci0 5C:F3:70:85:1D:A7

Type: busybox ps | grep blue
Is the bluetoothd process running?

27818 root 0:00 grep blue

and then "the bluealsa daemon did not start.

What am I missing?


This works by plug-and-play. When you plug in an adapter, the process should start.

Have you done a frugal install? Or are you running off a disc?

I also have the linux-firmware package installed. You can get the whole thing through apt-get or load Fred's squashfs module. But I don't think that's the problem.[/quote]

[rcrsn51]

Mike: From the Xorg.0.log, it looks like the Radeon driver was loaded. I'm guessing that the RS480 card doesn't need any additional firmware, so X was able to start on its own.

Since you've got the right video driver, I don't know what else to suggest.

LateAdopter: Thanks. I didn't understand that either.

[rcrsn51]

27818 root 0:00 grep blue

That indicates that the bluetoothd daemon didn't start. In my setups, it always starts as soon as you plug in an adapter.

If it doesn't start first, the bluealsa daemon probably won't start either.

Type: /etc/init.d/bluetooth start
What happens?

Which Bionic Dog version are you running? 32 or 64bit?

[Mike Walsh]

@ Fred:-

The silly thing is, it's not the desktop that's freezing-up; that still responds!

It's just the individual applications that are seizing solid. Figure that one out, if you can.....


Mike.

Weird..., let me understand exactly "it's not the desktop that's freezing-up".
You mean mouse and keyboard are still working, but that's all.. or... ?

Fred

Let me try to be a bit more descriptive. Mouse and keyboard still function, yes. I can click on things, and they respond, yes. I can open new applications. But after a minute or two of anything being opened, it ceases to respond to any controls.....including the window manager.

I've lost count of the number of things I've had to kill, because they refuse to close. I've never had anything like this happen before, which is why I'm so puzzled.....


Mike.

[Mike Walsh]

Mike: From the Xorg.0.log, it looks like the Radeon driver was loaded. I'm guessing that the RS480 card doesn't need any additional firmware, so X was able to start on its own.

Since you've got the right video driver, I don't know what else to suggest.

LateAdopter: Thanks. I didn't understand that either.

Hi, Bill.

Mm. I'm stumped, too. I do hope this isn't a sign of things to come...

I know I've heard of situations where a certain piece of hardware works perfectly for dozens, if not 100's of kernel 'point' releases.....then all of a sudden, it quits (or starts behaving in a totally different way.) Lots of people complain; within a couple of releases, someone at kernelHQ has got his wrists slapped for changing things that didn't need changing, and.....hey presto! things are back to how they were before.

Perhaps a kernel change would help. How do you actually do that with these 'Dogs'.....or can you perform the same 'manual' swap we do in Puppies?


Mike.

[fredx181]

Perhaps a kernel change would help. How do you actually do that with these 'Dogs'.....or can you perform the same 'manual' swap we do in Puppies?

Yes, worth trying, if you have time can you try this 4.4 kernel ? (it's from Xenial) EDIT: 32 bit
https://dl.dropboxusercontent.com/s/b18 ... ar.gz?dl=1
Contents of this archive:
- 00-kernel-4.4.0-124.squashfs
- initrd1.xz
- vmlinuz
Just put these in the "casper" folder.
Replace original initrd1.xz and vmlinuz with the ones from the archive.
(better make backup of original files first by renaming them).

I'd appreciate if you test this, then we possibly know if the problem is because of the 4.15 kernel or not .

EDIT: Ooops, I realize now that I don't know if you used 32 or 64 bit.
Anyway this is for 32 bit.

Fred

[Mike Walsh]

Hi, Fred.

Yeah, no worries, mate; be happy to. Won't be till the morning, though; it's 2.30 am here in the UK, and I'm more than ready for some shut-eye...

Bear with me, and I'll let you know what happens sometime tomorrow. We'll see if it makes any difference.

(BTW; I am using 32-bit, yes; it's my usual preference if I have a choice.)


Mike.

[zagreb999]

REGARDS

WHO KNOWS TO CREATE
OKULAR GTK IN BIONIC?

THANKS!

[Mike Walsh]

Morning, Fred.

Well, I don't know if this is what you were expecting, but this is what happened:-

Swapped over initrd1.xz and vmlinuz. Booted up. The boot process went OK, right up until the end.....then there was a load of stuff about the X server, amongst which was

Code: Select all

...Fatal server error. No screens found.....

.....and which ended up with

Code: Select all

...terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server. Connection refused.
xinit: server error
root@live: ~#

Attached is the current contents of /var/log/Xorg.0.log. Remove the fake .gz, of course.

I'll leave it with ya.


Mike.

[fredx181]

Hi Mike,

Looks like you did something wrong, I tested this and it should work booting with the 4.4. kernel.

Code: Select all

root@live:~# uname -a
Linux live 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:01:51 UTC 2018 i686 i686 i686 GNU/Linux

In your Xorg.log I see you are still booting the 4.15.0-15 kernel

Code: Select all

[    35.627] Current Operating System: Linux live 4.15.0-15-generic #16-Ubuntu SMP Wed Apr 4 13:58:15 UTC 2018 i686

Ok, so you replaced vmlinuz and initrd1.xz with the ones from the archive, but did you also add "00-kernel-4.4.0-124.squashfs" in the casper folder ?

If you didn't, can you try again ? No need to hurry

EDIT: Oh, I see just now that your attached xorg.log is from yesterday... confused...

Code: Select all

[    35.641] (==) Log file: "/var/log/Xorg.0.log", Time: Sun May 13 11:38:45 2018

Fred

[tlchost]

27818 root 0:00 grep blue

That indicates that the bluetoothd daemon didn't start. In my setups, it always starts as soon as you plug in an adapter.

If it doesn't start first, the bluealsa daemon probably won't start either.

Type: /etc/init.d/bluetooth start
What happens?

Which Bionic Dog version are you running? 32 or 64bit?

Didn't start....Maybe it's because I'm running on a usb drive and it's the 18.5 pae version?

Sorry to have troubled you....I don't think I'll chase after bluetooth any more...taking up too much of my time and yours.

[rcrsn51]

I released this project back in January. Since then, there have been many anonymous downloads and zero feedback.

So I can't say if your situation is the exception or the rule.

18.5 pae version

I don't know what that is.

[tlchost]

I released this project back in January. Since then, there have been many anonymous downloads and zero feedback.

So I can't say if your situation is the exception or the rule.

18.5 pae version

I don't know what that is.

UPup Bionic Beaver (upupbb) 18.05 (May 2018)

Not a problem...Glad it works for others...thankfully I have decent speakers that do not require bluetooth.