Changing from X11 to console and back with F keys may disable Keyboard

[hruodr]

What is written above happened me twice with FreeBSD 14.0:
"Changing from X11 to console and back with F keys may disable Keyboard".
I had to press the power button, I do not like to do that.
Does someone had the same problem.

I know, the forums are not for development, reporting bugs, but perhaps to discuss a possible bug before reporting?
That is why I put this under: "Feedback (about the forums)".

 

[Emrion]

First, it's for sure the wrong forum to post such thing. Here, it's about the behavior of the XenForo software, the one by which we can write there. Anyway, a moderator will move this topic.

Second, I tried to shift several times between X and other consoles. Nothing happened, of course; keyboard is still there. So, at least, you have to specify your video driver and hardware because this problem is unlike to be generalized to all 14.0-RELEASE users.

I think you have to dig a little more in order someone can reproduce what you're noticing.

 

[hruodr]

That is from dmesg:

[drm] radeon kernel modesetting enabled.
drmn0: <drmn> on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
[drm] initializing kernel modesetting (PALM 0x1002:0x9802 0x1043:0x84A5 0x00).
[drm ERROR :radeon_atombios_init] Unable to find PCI I/O BAR; using MMIO for ATO
M IIO
ATOM BIOS: Ontario
drmn0: VRAM: 384M 0x0000000000000000 - 0x0000000017FFFFFF (384M used)
drmn0: GTT: 1024M 0x0000000018000000 - 0x0000000057FFFFFF
[drm] Detected VRAM RAM=384M, BAR=256M
[drm] RAM width 32bits DDR
[drm] radeon: 384M of VRAM memory ready
[drm] radeon: 1024M of GTT memory ready.
[drm] Loading PALM Microcode
drmn0: successfully loaded firmware image 'radeon/PALM_pfp.bin'
drmn0: successfully loaded firmware image 'radeon/PALM_me.bin'
drmn0: successfully loaded firmware image 'radeon/SUMO_rlc.bin'
[drm] Internal thermal controller without fan control
[drm] Found smc ucode version: 0x00010601
[drm] radeon: dpm initialized
drmn0: successfully loaded firmware image 'radeon/SUMO_uvd.bin'
[drm] GART: num cpu pages 262144, num gpu pages 262144
[drm] PCIE GART of 1024M enabled (table at 0x0000000000162000).
drmn0: WB enabled
drmn0: fence driver on ring 0 use gpu addr 0x0000000018000c00
drmn0: fence driver on ring 3 use gpu addr 0x0000000018000c0c
drmn0: fence driver on ring 5 use gpu addr 0x0000000000072118
drmn0: radeon: MSI limited to 32-bit
drmn0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 3 usecs
[drm] ring test on 5 succeeded in 1 usecs
[drm] UVD initialized successfully.
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] ib test on ring 5 succeeded
lkpi_iicbb0: <LinuxKPI I2CBB> on drmn0
iicbb0: <I2C bit-banging driver> on lkpi_iicbb0
iicbus0: <Philips I2C bus> on iicbb0 addr 0xff
iic0: <I2C generic I/O> on iicbus0
lkpi_iicbb1: <LinuxKPI I2CBB> on drmn0
iicbb1: <I2C bit-banging driver> on lkpi_iicbb1
iicbus1: <Philips I2C bus> on iicbb1 addr 0xff
iic1: <I2C generic I/O> on iicbus1
lkpi_iicbb2: <LinuxKPI I2CBB> on drmn0
iicbb2: <I2C bit-banging driver> on lkpi_iicbb2
iicbus2: <Philips I2C bus> on iicbb2 addr 0xff
iic2: <I2C generic I/O> on iicbus2
lkpi_iicbb3: <LinuxKPI I2CBB> on drmn0
iicbb3: <I2C bit-banging driver> on lkpi_iicbb3
iicbus3: <Philips I2C bus> on iicbb3 addr 0xff
iic3: <I2C generic I/O> on iicbus3
lkpi_iicbb4: <LinuxKPI I2CBB> on drmn0
iicbb4: <I2C bit-banging driver> on lkpi_iicbb4
iicbus4: <Philips I2C bus> on iicbb4 addr 0xff
iic4: <I2C generic I/O> on iicbus4
lkpi_iicbb5: <LinuxKPI I2CBB> on drmn0
iicbb5: <I2C bit-banging driver> on lkpi_iicbb5
iicbus5: <Philips I2C bus> on iicbb5 addr 0xff
iic5: <I2C generic I/O> on iicbus5
lkpi_iicbb6: <LinuxKPI I2CBB> on drmn0
iicbb6: <I2C bit-banging driver> on lkpi_iicbb6
iicbus6: <Philips I2C bus> on iicbb6 addr 0xff
iic6: <I2C generic I/O> on iicbus6
lkpi_iicbb7: <LinuxKPI I2CBB> on drmn0
iicbb7: <I2C bit-banging driver> on lkpi_iicbb7
iicbus7: <Philips I2C bus> on iicbb7 addr 0xff
iic7: <I2C generic I/O> on iicbus7
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] HDMI-A-1
[drm] HPD1
[drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
[drm] Encoders:
[drm] DFP1: INTERNAL_UNIPHY
[drm] Connector 1:
[drm] DVI-D-1
[drm] HPD2
[drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
[drm] Encoders:
[drm] DFP2: INTERNAL_UNIPHY
[drm] Connector 2:
[drm] VGA-1
[drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
[drm] Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] fb mappable at 0xC0366000
[drm] vram apper at 0xC0000000
[drm] size 4325376
[drm] fb depth is 24
[drm] pitch is 5632
VT: Replacing driver "vga" with new "fb".
start FB_INFO:
type=11 height=768 width=1366 depth=32
pbase=0xc0366000 vbase=0xfffff800c0366000
name=drmn0 flags=0x0 stride=5632 bpp=32
end FB_INFO
[drm] Initialized radeon 2.50.0 20080528 for drmn0 on minor 0

 

[Cath O'Deray]

After you switch back to ttyv8 using (Alt-F9), is there no response to Control-Alt-F2?

Is behaviour any different if you switch repeatedly between ttyv0 and ttyv1 before the switch back to ttyv8?

What's the graphics hardware?

14.0

Which version of FreeBSD, exactly?

Packages of ports from quarterly, or latest?

freebsd--version -kru ; uname -aKU

pkg -vv | grep -B 1 -e url -e priority

Also:

pkg prime-origins | uniq | sort

 

[hruodr]

After you switch back to ttyv8 using (Alt-F9), is there no response to Control-Alt-F2?

That is, what I said.

Is behaviour any different if you switch repeatedly between ttyv0 and ttyv1 before the switch back to ttyv8?

I was able to come back to X, I suppose I was also able to schitch other consoles.

What's the graphics hardware?

From this old motherboard:

E35M1-I DELUXE - Support

www.asus.com

Was the dmesg not enough?

# uname -aKU
FreeBSD fbsd.local 14.0-RELEASE-p6 FreeBSD 14.0-RELEASE-p6 #0: Tue Mar 26 20:26:20 UTC 2024 root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1400097 1400097

Do you really want that I make public everything installed?!

My system is very modest, no nudist.

 

[Cath O'Deray]

Was the dmesg not enough?

No.

Do you really want that I make public everything installed?!

No.

I wanted something more support-friendly than a PDF from which text can not be copied after trudging through a dozen steps, after which I still do not know the PCI ID of the graphics hardware.

 

[hruodr]

I wanted something more support-friendly than a PDF from which text can not be copied after trudging through a dozen steps, after which I still do not know the PCI ID of the graphics hardware.

Was not here:

# dmesg | grep vga
VT(vga): resolution 640x480
vtvga0: <VT VGA driver>
vgapci0: <VGA-compatible display> port 0xf000-0xf0ff mem 0xc0000000-0xcfffffff,0xfeb00000-0xfeb3ffff irq 18 at device 1.0 on pci0
vgapci0: Boot video device
drmn0: <drmn> on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
VT: Replacing driver "vga" with new "fb".

Or here:

# pciconf -l
hostb0@pci0:0:0:0: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x1510 subvendor=0x1043 subdevice=0x84a5
vgapci0@pci0:0:1:0: class=0x030000 rev=0x00 hdr=0x00 vendor=0x1002 device=0x9802 subvendor=0x1043 subdevice=0x84a5
...

More info would be on /var/log/Xorg.0.log

 

[Cath O'Deray]

… vendor=0x1002 device=0x9802 subvendor=0x1043 subdevice=0x84a5

PCI 1002:9802:1043:84a5

AMD Wrestler, Radeon HD 6310.

In the absence of package information, I can't guess which driver-related packages you installed.