error: no symbol table

[Mintywav]

Ok that dmsg maybe what was needed. I thought I had done that before but I do not recall seeing the following.

Code: Select all

[   21.605999] caller os_map_kernel_space+0x86/0xb0 [nvidia] mapping multiple BARs
[   25.793652] Bluetooth: RFCOMM TTY layer initialized
[   25.793661] Bluetooth: RFCOMM socket layer initialized
[   25.793673] Bluetooth: RFCOMM ver 1.11
[   29.311023] r8169 0000:04:00.0 enp4s0: link up
[   29.311039] IPv6: ADDRCONF(NETDEV_CHANGE): enp4s0: link becomes ready
[  858.055285] perf: interrupt took too long (2506 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
[ 1234.991128] perf: interrupt took too long (3137 > 3132), lowering kernel.perf_event_max_sample_rate to 63750
[ 1384.783204] perf: interrupt took too long (3927 > 3921), lowering kernel.perf_event_max_sample_rate to 50750
[ 1692.722639] perf: interrupt took too long (4918 > 4908), lowering kernel.perf_event_max_sample_rate to 40500

Just what do the numbers in brackets mean?? Looks like a big jump here!!
BTW that is also what I see rught after the black screen. Now that I am thinking , assuming I am seeing the whole of what I get with dmesg at boot the black screen would be right at the beginning (OR before).

Code: Select all

[    0.000000] microcode: microcode updated early to revision 0x5d, date = 2010-10-02
[    0.000000] Linux version 4.15.0-33-generic (buildd@lcy01-amd64-024) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 (Ubuntu 4.15.0-33.36-generic 4.15.18)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-33-generic root=UUID=86d2e32b-2b49-4f19-85ce-82a3223b6300 ro verbose video=SVIDEO-1:d
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] x86/fpu: x87 FPU will use FXSAVE
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007fedffff] usable
[    0.000000] BIOS-e820: [mem 0x000000007fee0000-0x000000007fee2fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x000000007fee3000-0x000000007feeffff] ACPI data
[    0.000000] BIOS-e820: [mem 0x000000007fef0000-0x000000007fefffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000ffffffff] reserved
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.4 present.

Does anything make sense to you ?

[gm10]

The numbers at the front are time stamps. You can use dmesg -H for a more human-readable version, but there's nothing wrong with the numbers or the log contents you posted.

One thing I noticed I forgot was to ask you to post the output of

Code: Select all

xrandr

There might be another port to disable other than SVIDEO-1.

[Mintywav]

Code: Select all

xrandr
Screen 0: minimum 8 x 8, current 1024 x 768, maximum 8192 x 8192
DVI-I-0 connected primary 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1024x768      60.00*+
   1600x900      59.82  
   1400x900      59.88  
   1368x768      59.88    59.85  
   1360x768      59.96    59.80  
   1280x800      59.91    59.81  
   1280x720      59.86    59.74  
   1152x864      60.00  
   1024x576      59.90    59.82  
   960x540       59.82    59.63  
   864x486       59.92    59.57  
   800x600       72.19    60.32    56.25  
   800x450       59.82  
   700x450       59.88  
   684x384       59.88    59.85  
   680x384       59.96    59.80  
   640x480       59.94  
   640x400       59.98    59.88  
   640x360       59.86    59.83  
   512x384       60.00  
   512x288       60.00    59.92  
   480x270       59.82    59.63  
   432x243       59.92    59.57  
   400x300       72.19  
   320x240       60.05  
DVI-I-1 disconnected (normal left inverted right x axis y axis)
TV-0 disconnected (normal left inverted right x axis y axis)
DVI-I-2 disconnected (normal left inverted right x axis y axis)
DVI-I-3 disconnected (normal left inverted right x axis y axis)

??

[gm10]

??

It means your SVIDEO port is actually called TV-0, so let's modify the boot parameters I previously gave you - see previous page for the instructions, same thing except made it look like this:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=TV-0:d"

Don't forget to update GRUB and then I'll keep my fingers crossed for the next reboot.

[Mintywav]

No luck with that.
BTW I am thinking the "verbose" parameter squashed the logo.

SVIDEO port is actually called TV-0

What does that mean? I see I do have an svideo connection on my card as well as the 2 DVI ports one of which is in use.

And what does the parameter

Code: Select all

video=TV-0:d

actually do ?
BTW I spent a couple of hours trying to find some understandable documentation on this and finally have given up.

I am thinking on installing a grub theme so at least I wouldn't be just looking at a blank screen.

[gm10]

The parameter is to disable that output at boot. My assumption was that the detection of displays connected to that output was causing the delay.

The documentation could have been found here:
https://www.kernel.org/doc/Documentation/fb/modedb.txt

I am thinking on installing a grub theme so at least I wouldn't be just looking at a blank screen.

Or you could instead try forcing GRUB to text-mode by uncommenting this line in /etc/default/grub, maybe it helps:

Code: Select all

#GRUB_TERMINAL=console

[Mintywav]

The parameter is to disable that output at boot. My assumption was that the detection of detected displays to that output was causing the delay.

The documentation could have been found here:
https://www.kernel.org/doc/Documentation/fb/modedb.txt

I am thinking on installing a grub theme so at least I wouldn't be just looking at a blank screen.

Or you could instead try forcing GRUB to text-mode by uncommenting this line in /etc/default/grub, maybe it helps:

Code: Select all

#GRUB_TERMINAL=console

Thanks for that link, I understand a bit more now. I will try text-mode.

[Mintywav]

Text mode a nogo too.
I am thinking this is just one of those things and will remain a mystery.

Thanks for your help.

[gm10]

You're welcome. There certainly is a solution, but I'm afraid I lack the expertise. But hey, I only came here for the symbol table, and that I could help with.

[Mintywav]

Just for kicks I am going to use the eSATA connection on my dock to see if I get a change. I will keep this topic posted with any change!

Ok that sped things up, I need to analyze a couple of things before I post exactly what...

[Mintywav]

Ok using the eSATA connection the boot is fast. I have a background in Grub, nice mountains . I get the grub menu on the back ground and then the splash(logo) . This is with splash and verbose set in GRUB_CMDLINE_LINUX_DEFAULT=. If I leave out the splash I get the menu on the background and then the boot text flashes by but w/o a big delay.

I do not know if there is a delay caused by Linux getting cozy with the USB to SATA connection of the dock or that the USB 2 is much slower than SATA 3GB, I suspect the former as the disk activity light on the dock was not showing activity during the 'black screen' time just the onboard light and then only for 10-12 seconds.

Again Thanks for you efforts
David

[gm10]

I do not know if there is a delay caused by Linux getting cozy with the USB to SATA connection of the dock or that the USB 2 is much slower than SATA 3GB, I suspect the former as the disk activity light on the dock was not showing activity during the 'black screen' time just the onboard light and then only for 10-12 seconds.

Thanks for the follow-up, interesting find. USB2 is indeed much slower than a SATA 3GB/s connection, but slow disk access shouldn't cause the long black screen delay you're describing. So your assumption about the cause is probably correct. Maybe your kernel logs allow you to confirm that, although I'm not sure that logging is even active yet at the time you black screen.

[Mintywav]

Maybe your kernel logs allow you to confirm that, although I'm not sure that logging is even active yet at the time you black screen.

I think you are correct there, this occurs before the logs as far as I have been able to determine.