Solved No virtual console after switch to EFI

mro

mro

After switching from BIOS to EFI as of https://forums.freebsd.org/threads/...scii-after-upgrade-to-14-2.96771/#post-692344
I have no more virtual consoles.

When booting the screen shortly turns black when switching to X11/lightdm. Ctrl-Alt-F1-6 shows a read-only echo of the last visible screen.

Code: 
$ inxi -SG
System:
  Host: mx250.local Kernel: FreeBSD 14.2-RELEASE-p1 amd64 bits: 64
    Desktop: i3 4.24 OS: FreeBSD 14.2-RELEASE-p1
Graphics:
  Device-1: Intel HD Graphics 5500 driver: vgapci
  Display: x11 server: X.Org 1.21.1.14 driver: loaded: intel
    unloaded: modesetting,vesa resolution: 1: 1366x768~60Hz 2: 1920x1080~60Hz
  OpenGL: renderer: Mesa Intel HD Graphics 5500 (BDW GT2)
    v: 4.6 Mesa 24.1.7

$ kldstat | grep -E "i915|drm"
25    1 0xffffffff83f8b000   1e2228 i915kms.ko
26    2 0xffffffff8416e000    86090 drm.ko

$ pkg info | grep -E "i915|drm"
drm-61-kmod-6.1.92.1401000_3   DRM drivers modules
gpu-firmware-kmod-20241114,1   Firmware modules for the drm-kmod drivers
libdrm-2.4.123,1               Direct Rendering Manager library and headers

Feels related to https://forums.freebsd.org/threads/ctrl-alt-fn-from-x-leads-to-blank-screen.96660/#post-688684

How can I diagnose what's going on and get the VTs back?
 
oh, there's dmesg:

Code: 
…
[drm] Initialized i915 1.6.0 20201103 for drmn0 on minor 0
VT: Driver priority 0 too low. Current 101
 fbd0: not attached to vt(4) console; another device has precedence (err=17)
em0: link state changed to UP
hdac0: Unexpected unsolicited response from address 0: 00000000
hdac0: Unexpected unsolicited response from address 0: 00000000
hdac0: Unexpected unsolicited response from address 0: 00000000
hdac0: Unexpected unsolicited response from address 0: 00000000
hdac0: Unexpected unsolicited response from address 0: 00000000
hdac0: Unexpected unsolicited response from address 0: 00000000
…
hdac0: Command 0x00270d01 timeout on address 0
hdac0: Command 0x00270610 timeout on address 0
hdac0: Command 0x00272d01 timeout on address 0
…
hdac0: Reset setting timeout
hdac0: Command 0x00270d00 timeout on address 0
hdac0: Command 0x00270600 timeout on address 0
 
NapoleonWils0n

Thread 'fix for hdac0: Command timeout on address, with the i915 driver and intel'

i started to get these errors today with Freebsd 14.1 p5
using i915 on my Macbook pro retina during boot

Code: 
hdac0: Command timeout on address 2

the fix was to edit

Code: 
/boot/loader.conf

and add the following code

Code: 
compat.linuxkpi.i915_disable_power_well="0"

reboot and no more errors

229190 – hdac0: Command timeout on address 2 (Intel Kabylake HDA CODEC)

bugs.freebsd.org bugs.freebsd.org
  • Thanks
made the errors go away burt the VTs still aren't there:

Code: 
$ dmesg | tail -5
iic6: <I2C generic I/O> on iicbus6
[drm] Initialized i915 1.6.0 20201103 for drmn0 on minor 0
VT: Driver priority 0 too low. Current 101
 fbd0: not attached to vt(4) console; another device has precedence (err=17)
em0: link state changed to UP
 
Depending of what CPU/GPU you actually have that may include also some 14.2 specific firmware:
Code: 
# pkg search  '\.1402' | egrep 'firmware.*(amd|intel)'
gpu-firmware-amd-kmod-aldebaran-20230625.1402000_2 Firmware modules for aldebaran AMD GPUs
gpu-firmware-intel-kmod-skylake-20230625.1402000 Firmware modules for skylake Intel GPUs
 
Erichans said:
Depending of what CPU/GPU you actually have that may include also some 14.2 specific firmware:
Code: 
# pkg search  '\.1402' | egrep 'firmware.*(amd|intel)'
gpu-firmware-amd-kmod-aldebaran-20230625.1402000_2 Firmware modules for aldebaran AMD GPUs
gpu-firmware-intel-kmod-skylake-20230625.1402000 Firmware modules for skylake Intel GPUs
Click to expand...
hm, strange:

Code: 
$ doas pkg remove gpu-firmware-intel-kmod-skylake
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 2 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
    gpu-firmware-intel-kmod-skylake: 20230625.1401000
    gpu-firmware-kmod: 20241114,1

Number of packages to be removed: 2

Proceed with deinstalling packages? [y/N]: 
$ pkg search  '\.1402' | egrep 'firmware.*(amd|intel)'
<tumbleweed>
 
mro settle down. Stop adding the same/similar questions in different threads. Take a deep breath, and read T-Aoki 's post I linked to in post #6 again.
 
Erichans said:
Depending of what CPU/GPU you actually have that may include also some 14.2 specific firmware:
Code: 
# pkg search  '\.1402' | egrep 'firmware.*(amd|intel)'
gpu-firmware-amd-kmod-aldebaran-20230625.1402000_2 Firmware modules for aldebaran AMD GPUs
gpu-firmware-intel-kmod-skylake-20230625.1402000 Firmware modules for skylake Intel GPUs
Click to expand...
The command itself may well have been confusing; it works when you have a working 'kmods' set-up. Building the relevant packages from the ports' sources yourself without setting up the 'kmods' in a .conf file will not get this output from the command.
Sorry for the confusion.


mro said:
$ pkg search '\.1402' | egrep 'firmware.*(amd|intel)'
Click to expand...
Please also take into account that pkg commands where the local pkg repository catalogues are attempted to be updated only succeed in that attempt when sufficient write privileges are present, pkg-search(8):
Rich (BB code): 
DESCRIPTION
   [...]
       Package repository catalogues will be  automatically  updated  whenever
       pkg  search  is run by a    user ID    with write access to the package data-
       base, unless disabled by    the -U flag or setting REPO_AUTOUPDATE    to  NO
       in pkg.conf(5).

There may well be a significant and unexpected difference between #1 versus #2-4
  1. $ pkg search drm-61-kmod - ordinary user without write access
  2. # pkg search drm-61-kmod - root, with the necessary write access
  3. $ doas pkg search drm-61-kmod - elevated execution
  4. $ sudo pkg search drm-61-kmod - elevated execution
I'll admit this may be rather uncommon but, I tripped over this during the pkg sequence of 2.0.0-2.0.-2.0.2-2.0.3-2.0.4. I was on pkg v.2.0.2 and was waiting for 2.0.4 to appear (awaiting the FreeBSD package build servers); I used repeatedly:
$ pkg search '^pkg-2'
and then it was reported that pkg 2.0.4 had arrived, and ... I didn't see that because I should have used:
# pkg search '^pkg-2'

Note: when pkg search does not have sufficient write access to update its local pkg repository catalogues with the newer version remotely available (including the anxiously expected new version of a certain package :)):
the update fails silently
and pkg search uses the local existing data (that is: not updated) without any notification.

With these pkg processes it is important to realise that all searches are done locally, for example:
  • pkg query '%v-%n' -n drm-61-kmod
  • pkg rquery '%v-%n' -n drm-61-kmod
both of these searches are executed locally. The first is executed locally against the collection of only installed packages, whereas the second is executed locally against all available packages.

Note that for pkg-rquery(8), again, the necessary write access privileges are necessary to load the most recent remotely available data about all available packages in the form of pkg repository catalogues.

Edit: Note that this is at least documented. IMO, users would nevertheless benefit from a modest warning, something like:
Code: 
Warning: update of local repository catalogues failed due to the lack of the necessary write access.
Using the currently present local repository catalogues.
 
You must log in or register to reply here.
Back
Top