11-15-2024, 11:18 PM
(This post was last modified: Yesterday, 12:22 AM by Cactus2580.
Edit Reason: dissected DMESG, very confused.
)
Another update:
Moved /usr/lib/firmware over to the DSL2024 reroll, no effect on rainbow snow. Unsure why this is the case.
Moved /antiX/vmlinuz from AntiX23.2 runit core to DSL2024 reroll, no effect on rainbow snow, wouldnt boot either. (Duh)
Whatever the issue is, it "strikes" right as ISOLINUX gives control over to the bootup process. I can't seem to figure out what the issue here is. AntiX itself works just fine, moving over the /usr/lib/firmware directory should have brought all of the firmware from AntiX into DSL, yet no change. I do notice a difference in size between the kernel for Antix23.2 core and DSL2024, with DSL being a little bit smaller in size. I wonder, is there some driver compiled directly into the kernel of AntiX23.2 which allows for the display to work on AO722 which is not present within DSL? I have been looking into the initrd file from DSL2024, and it appears I may be able to move modules from the linuxfs file into the initrd file and repack, maybe this is what is required?
It seems that the more I mess with this, the less it makes sense. Firmware would be loaded from the /usr/lib/firmware area only after the system managed to Unsquashfs the entire linuxfs image. This does not occur as the first step of the bootup process. Initrd should be loaded first? So I put the firmware and module files into the initrd. Still does not work. Whatever the issue is, it seems to affect the initial console of the computer. Antix23 core goes directly into a normal looking console window upon bootup, shows init process, etc. No issues. DSL2024 goes directly into rainbow snow, and never comes out. So whatever it is appears to be an issue literally right at the moment of first booting. Even without Xorg installed on AntiX, lsmod does show Radeon as the driver active.
Checking DMESG soon, will update once I reinstall Xorg on Antix23
It appears that early on in the boot process, when the kernel is "paravirtualized on bare hardware" it states it's got a [ 0.219929] Console: colour VGA+ 80x25\
Next thing pertaining to graphics at all is [ 0.334940] smpboot: CPU0: AMD C-60 APU with Radeon HD Graphics (family: 0x14, model: 0x2, stepping: 0x0)
[ 0.335500] Performance Events: AMD PMU driver.
[ 0.335515] ... version: 0
[ 0.335519] ... bit width: 48
[ 0.335522] ... generic registers: 4
[ 0.335526] ... value mask: 0000ffffffffffff
[ 0.335529] ... max period: 00007fffffffffff
[ 0.335532] ... fixed-purpose events: 0
[ 0.335536] ... event mask: 000000000000000f
[ 0.335576] rcu: Hierarchical SRCU implementation.
[ 0.336374] smp: Bringing up secondary CPUs ...
[ 0.336870] x86: Booting SMP configuration:
Then theres:
[ 0.374003] ACPI: Added _OSI(Module Device)
[ 0.374010] ACPI: Added _OSI(Processor Device)
[ 0.374014] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.374018] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.374023] ACPI: Added _OSI(Linux-Dell-Video)
[ 0.374028] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[ 0.374033] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[ 0.391362] ACPI: 3 ACPI AML tables successfully acquired and loaded
[ 0.394252] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
and
[ 0.532742] pci 0000:00:01.0: vgaarb: setting as boot VGA device
[ 0.532742] pci 0000:00:01.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[ 0.532742] pci 0000:00:01.0: vgaarb: bridge control possible
[ 0.532742] vgaarb: loaded
and
[ 0.540675] amd_nb: x86/cpu/AMD: CPU erratum 688 worked around
and
[ 0.712503] pci 0000:00:01.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[ 0.712625] pci 0000:00:01.1: D0 power state depends on 0000:00:01.0
[ 0.725978] pci 0000:00:12.0: quirk_usb_early_handoff+0x0/0x680 took 12978 usecs
[ 0.739987] pci 0000:00:12.2: quirk_usb_early_handoff+0x0/0x680 took 13591 usecs
[ 0.752989] pci 0000:00:13.0: quirk_usb_early_handoff+0x0/0x680 took 12622 usecs
[ 0.766985] pci 0000:00:13.2: quirk_usb_early_handoff+0x0/0x680 took 13545 usecs
[ 0.767169] pci 0000:06:00.0: [Firmware Bug]: disabling VPD access (can't determine size of non-standard VPD format)
[ 0.767258] PCI: CLS 64 bytes, default 64
Next thing it does after this is unpack the Initramfs
Nothing related to graphics appears to happen in between loading the initrd and actually starting the Init process.
Then:
[ 35.846638] ACPI: Video Device [VGA] (multi-head: yes rom: no post: no)
and
[ 35.938165] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input6
and
[ 38.266199] [drm] radeon kernel modesetting enabled.
[ 38.269252] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 38.269268] cfg80211: failed to load regulatory.db
[ 38.275064] radeon 0000:00:01.0: vgaarb: deactivate vga console
[ 38.276390] Console: switching to colour dummy device 80x25
[ 38.293067] [drm] initializing kernel modesetting (PALM 0x1002:0x9807 0x1025:0x0598 0x00).
[ 38.293608] resource sanity check: requesting [mem 0x000c0000-0x000dffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000c3fff window]
[ 38.293624] caller pci_map_rom+0x65/0x200 mapping multiple BARs
[ 38.302763] ATOM BIOS: Acer
[ 38.302894] radeon 0000:00:01.0: VRAM: 256M 0x0000000000000000 - 0x000000000FFFFFFF (256M used)
[ 38.302904] radeon 0000:00:01.0: GTT: 1024M 0x0000000010000000 - 0x000000004FFFFFFF
[ 38.302928] [drm] Detected VRAM RAM=256M, BAR=256M
[ 38.302933] [drm] RAM width 32bits DDR
[ 38.304909] [TTM] Zone kernel: Available graphics memory: 433188 KiB
[ 38.304917] [TTM] Zone highmem: Available graphics memory: 889530 KiB
[ 38.304921] [TTM] Initializing pool allocator
[ 38.304942] [TTM] Initializing DMA pool allocator
[ 38.305007] [drm] radeon: 256M of VRAM memory ready
[ 38.305014] [drm] radeon: 1024M of GTT memory ready.
[ 38.305063] [drm] Loading PALM Microcode
and
[ 38.489071] [drm] radeon: dpm initialized
and
[ 38.716959] [drm] PCIE GART of 1024M enabled (table at 0x0000000000162000).
[ 38.717253] radeon 0000:00:01.0: WB enabled
[ 38.717265] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000010000c00
[ 38.717272] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000010000c0c
[ 38.718722] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000072118
[ 38.771551] radeon 0000:00:01.0: radeon: MSI limited to 32-bit
[ 38.771701] radeon 0000:00:01.0: radeon: using MSI.
[ 38.771763] [drm] radeon: irq initialized.
and
[ 39.743476] [drm] radeon atom DIG backlight initialized
[ 39.743490] [drm] Radeon Display Connectors
[ 39.743495] [drm] Connector 0:
[ 39.743498] [drm] LVDS-1
[ 39.743501] [drm] HPD1
[ 39.743508] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
[ 39.743511] [drm] Encoders:
[ 39.743514] [drm] LCD1: INTERNAL_UNIPHY
[ 39.743518] [drm] Connector 1:
[ 39.743521] [drm] HDMI-A-1
[ 39.743523] [drm] HPD2
[ 39.743529] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
[ 39.743532] [drm] Encoders:
[ 39.743535] [drm] DFP1: INTERNAL_UNIPHY
[ 39.743538] [drm] Connector 2:
[ 39.743541] [drm] VGA-1
[ 39.743547] [drm] DDC: 0x64d8 0x64d8 0x64dc 0x64dc 0x64e0 0x64e0 0x64e4 0x64e4
[ 39.743549] [drm] Encoders:
[ 39.743552] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 39.797171] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input7
[ 40.578374] [drm] fb mappable at 0x80366000
[ 40.578383] [drm] vram apper at 0x80000000
[ 40.578387] [drm] size 4325376
[ 40.578390] [drm] fb depth is 24
[ 40.578393] [drm] pitch is 5632
[ 40.582804] fbcon: radeondrmfb (fb0) is primary device
[ 40.774650] Console: switching to colour frame buffer device 170x48
[ 40.786806] radeon 0000:00:01.0: [drm] fb0: radeondrmfb frame buffer device
[ 40.806530] [drm] Initialized radeon 2.50.0 20080528 for 0000:00:01.0 on minor 0
[ 41.785594] wl: loading out-of-tree module taints kernel.
[ 41.785613] wl: module license 'MIXED/Proprietary' taints kernel.
[ 41.785617] Disabling lock debugging due to kernel taint
Now if only I could manage to get a DMESG from DSL2024, although at that point I wouldn't need one as it would be booted into usable graphics.
I have no idea if anything from the dmesg above is at -all- helpful, but my intuition suggests that the issue I'm having here is related to something compiled(or not) into the kernel itself, as it won't even proceed to the point of loading the initrd or what not without going all rainbow. Is it picking the wrong framebuffer device? I have literally no idea at this point, especially considering that the AntiX23 core image is much smaller than the DSL2024 image. The AntiX23 kernel is slightly larger than the DSL2024 kernel. I have no idea why this is, but it seems to be an important difference considering moving all of the firmware from AntiX to DSL does... nothing. Is there a way for me to attempt to recompile the kernel with the Radeon drivers inside? (I don't think this is how drivers such as that work, but maybe it's possible to statically compile it in instead of attempting to load a module?)
I am fairly well out of my zone of understanding on why there's a major failure to output anything but rainbow snow in DSL. Whatever the issue is, it happens basically the very moment that any selection chosen proceeds past the "loading kernel....100%" message. Straight to rainbow. Never comes out of it.
On AntiX, it goes directly to a very readable console display, then about halfway through booting (as shown in Dmesg above) video drivers kick in and it redisplays in a higher res format. Even without Xorg, it displays text just fine, can run AntiX-cli-cc Curses type menu, even browse the internet with Elinks. Upon installing Xorg, using startx causes it to again change resolution to the proper 1366x768, which honestly makes terminal windows pretty hard to read, tiny text.
I am completely stumped. Any ideas?
Moved /usr/lib/firmware over to the DSL2024 reroll, no effect on rainbow snow. Unsure why this is the case.
Moved /antiX/vmlinuz from AntiX23.2 runit core to DSL2024 reroll, no effect on rainbow snow, wouldnt boot either. (Duh)
Whatever the issue is, it "strikes" right as ISOLINUX gives control over to the bootup process. I can't seem to figure out what the issue here is. AntiX itself works just fine, moving over the /usr/lib/firmware directory should have brought all of the firmware from AntiX into DSL, yet no change. I do notice a difference in size between the kernel for Antix23.2 core and DSL2024, with DSL being a little bit smaller in size. I wonder, is there some driver compiled directly into the kernel of AntiX23.2 which allows for the display to work on AO722 which is not present within DSL? I have been looking into the initrd file from DSL2024, and it appears I may be able to move modules from the linuxfs file into the initrd file and repack, maybe this is what is required?
It seems that the more I mess with this, the less it makes sense. Firmware would be loaded from the /usr/lib/firmware area only after the system managed to Unsquashfs the entire linuxfs image. This does not occur as the first step of the bootup process. Initrd should be loaded first? So I put the firmware and module files into the initrd. Still does not work. Whatever the issue is, it seems to affect the initial console of the computer. Antix23 core goes directly into a normal looking console window upon bootup, shows init process, etc. No issues. DSL2024 goes directly into rainbow snow, and never comes out. So whatever it is appears to be an issue literally right at the moment of first booting. Even without Xorg installed on AntiX, lsmod does show Radeon as the driver active.
Checking DMESG soon, will update once I reinstall Xorg on Antix23
It appears that early on in the boot process, when the kernel is "paravirtualized on bare hardware" it states it's got a [ 0.219929] Console: colour VGA+ 80x25\
Next thing pertaining to graphics at all is [ 0.334940] smpboot: CPU0: AMD C-60 APU with Radeon HD Graphics (family: 0x14, model: 0x2, stepping: 0x0)
[ 0.335500] Performance Events: AMD PMU driver.
[ 0.335515] ... version: 0
[ 0.335519] ... bit width: 48
[ 0.335522] ... generic registers: 4
[ 0.335526] ... value mask: 0000ffffffffffff
[ 0.335529] ... max period: 00007fffffffffff
[ 0.335532] ... fixed-purpose events: 0
[ 0.335536] ... event mask: 000000000000000f
[ 0.335576] rcu: Hierarchical SRCU implementation.
[ 0.336374] smp: Bringing up secondary CPUs ...
[ 0.336870] x86: Booting SMP configuration:
Then theres:
[ 0.374003] ACPI: Added _OSI(Module Device)
[ 0.374010] ACPI: Added _OSI(Processor Device)
[ 0.374014] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.374018] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.374023] ACPI: Added _OSI(Linux-Dell-Video)
[ 0.374028] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[ 0.374033] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[ 0.391362] ACPI: 3 ACPI AML tables successfully acquired and loaded
[ 0.394252] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
and
[ 0.532742] pci 0000:00:01.0: vgaarb: setting as boot VGA device
[ 0.532742] pci 0000:00:01.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[ 0.532742] pci 0000:00:01.0: vgaarb: bridge control possible
[ 0.532742] vgaarb: loaded
and
[ 0.540675] amd_nb: x86/cpu/AMD: CPU erratum 688 worked around
and
[ 0.712503] pci 0000:00:01.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[ 0.712625] pci 0000:00:01.1: D0 power state depends on 0000:00:01.0
[ 0.725978] pci 0000:00:12.0: quirk_usb_early_handoff+0x0/0x680 took 12978 usecs
[ 0.739987] pci 0000:00:12.2: quirk_usb_early_handoff+0x0/0x680 took 13591 usecs
[ 0.752989] pci 0000:00:13.0: quirk_usb_early_handoff+0x0/0x680 took 12622 usecs
[ 0.766985] pci 0000:00:13.2: quirk_usb_early_handoff+0x0/0x680 took 13545 usecs
[ 0.767169] pci 0000:06:00.0: [Firmware Bug]: disabling VPD access (can't determine size of non-standard VPD format)
[ 0.767258] PCI: CLS 64 bytes, default 64
Next thing it does after this is unpack the Initramfs
Nothing related to graphics appears to happen in between loading the initrd and actually starting the Init process.
Then:
[ 35.846638] ACPI: Video Device [VGA] (multi-head: yes rom: no post: no)
and
[ 35.938165] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input6
and
[ 38.266199] [drm] radeon kernel modesetting enabled.
[ 38.269252] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 38.269268] cfg80211: failed to load regulatory.db
[ 38.275064] radeon 0000:00:01.0: vgaarb: deactivate vga console
[ 38.276390] Console: switching to colour dummy device 80x25
[ 38.293067] [drm] initializing kernel modesetting (PALM 0x1002:0x9807 0x1025:0x0598 0x00).
[ 38.293608] resource sanity check: requesting [mem 0x000c0000-0x000dffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000c3fff window]
[ 38.293624] caller pci_map_rom+0x65/0x200 mapping multiple BARs
[ 38.302763] ATOM BIOS: Acer
[ 38.302894] radeon 0000:00:01.0: VRAM: 256M 0x0000000000000000 - 0x000000000FFFFFFF (256M used)
[ 38.302904] radeon 0000:00:01.0: GTT: 1024M 0x0000000010000000 - 0x000000004FFFFFFF
[ 38.302928] [drm] Detected VRAM RAM=256M, BAR=256M
[ 38.302933] [drm] RAM width 32bits DDR
[ 38.304909] [TTM] Zone kernel: Available graphics memory: 433188 KiB
[ 38.304917] [TTM] Zone highmem: Available graphics memory: 889530 KiB
[ 38.304921] [TTM] Initializing pool allocator
[ 38.304942] [TTM] Initializing DMA pool allocator
[ 38.305007] [drm] radeon: 256M of VRAM memory ready
[ 38.305014] [drm] radeon: 1024M of GTT memory ready.
[ 38.305063] [drm] Loading PALM Microcode
and
[ 38.489071] [drm] radeon: dpm initialized
and
[ 38.716959] [drm] PCIE GART of 1024M enabled (table at 0x0000000000162000).
[ 38.717253] radeon 0000:00:01.0: WB enabled
[ 38.717265] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000010000c00
[ 38.717272] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000010000c0c
[ 38.718722] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000072118
[ 38.771551] radeon 0000:00:01.0: radeon: MSI limited to 32-bit
[ 38.771701] radeon 0000:00:01.0: radeon: using MSI.
[ 38.771763] [drm] radeon: irq initialized.
and
[ 39.743476] [drm] radeon atom DIG backlight initialized
[ 39.743490] [drm] Radeon Display Connectors
[ 39.743495] [drm] Connector 0:
[ 39.743498] [drm] LVDS-1
[ 39.743501] [drm] HPD1
[ 39.743508] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
[ 39.743511] [drm] Encoders:
[ 39.743514] [drm] LCD1: INTERNAL_UNIPHY
[ 39.743518] [drm] Connector 1:
[ 39.743521] [drm] HDMI-A-1
[ 39.743523] [drm] HPD2
[ 39.743529] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
[ 39.743532] [drm] Encoders:
[ 39.743535] [drm] DFP1: INTERNAL_UNIPHY
[ 39.743538] [drm] Connector 2:
[ 39.743541] [drm] VGA-1
[ 39.743547] [drm] DDC: 0x64d8 0x64d8 0x64dc 0x64dc 0x64e0 0x64e0 0x64e4 0x64e4
[ 39.743549] [drm] Encoders:
[ 39.743552] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 39.797171] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input7
[ 40.578374] [drm] fb mappable at 0x80366000
[ 40.578383] [drm] vram apper at 0x80000000
[ 40.578387] [drm] size 4325376
[ 40.578390] [drm] fb depth is 24
[ 40.578393] [drm] pitch is 5632
[ 40.582804] fbcon: radeondrmfb (fb0) is primary device
[ 40.774650] Console: switching to colour frame buffer device 170x48
[ 40.786806] radeon 0000:00:01.0: [drm] fb0: radeondrmfb frame buffer device
[ 40.806530] [drm] Initialized radeon 2.50.0 20080528 for 0000:00:01.0 on minor 0
[ 41.785594] wl: loading out-of-tree module taints kernel.
[ 41.785613] wl: module license 'MIXED/Proprietary' taints kernel.
[ 41.785617] Disabling lock debugging due to kernel taint
Now if only I could manage to get a DMESG from DSL2024, although at that point I wouldn't need one as it would be booted into usable graphics.
I have no idea if anything from the dmesg above is at -all- helpful, but my intuition suggests that the issue I'm having here is related to something compiled(or not) into the kernel itself, as it won't even proceed to the point of loading the initrd or what not without going all rainbow. Is it picking the wrong framebuffer device? I have literally no idea at this point, especially considering that the AntiX23 core image is much smaller than the DSL2024 image. The AntiX23 kernel is slightly larger than the DSL2024 kernel. I have no idea why this is, but it seems to be an important difference considering moving all of the firmware from AntiX to DSL does... nothing. Is there a way for me to attempt to recompile the kernel with the Radeon drivers inside? (I don't think this is how drivers such as that work, but maybe it's possible to statically compile it in instead of attempting to load a module?)
I am fairly well out of my zone of understanding on why there's a major failure to output anything but rainbow snow in DSL. Whatever the issue is, it happens basically the very moment that any selection chosen proceeds past the "loading kernel....100%" message. Straight to rainbow. Never comes out of it.
On AntiX, it goes directly to a very readable console display, then about halfway through booting (as shown in Dmesg above) video drivers kick in and it redisplays in a higher res format. Even without Xorg, it displays text just fine, can run AntiX-cli-cc Curses type menu, even browse the internet with Elinks. Upon installing Xorg, using startx causes it to again change resolution to the proper 1366x768, which honestly makes terminal windows pretty hard to read, tiny text.
I am completely stumped. Any ideas?