Qubes-R4.2.4-rc1-x86_64 fails on DELL T7500, kernel panic, wired floppy seek on grub

Testing Team
1

Hi,

I took an old T7500 from DELL which should be able to run qubes and found wired behavior. I need to to verify the usb stick, but as dd did not throw write errors the writing should have been correct.
I said sync after dd and waited for the root prompt again #

What happened?
After long time wait for huge ecc ram to be initialized the machine booted from usb stick and started grub. Here I got a floppy seek (!) two times and an error about two missing files.

IMG_20250208_211616
IMG_20250208_2116161920Ă—2560 105 KB

missing files:

IMG_20250208_211651
IMG_20250208_2116511920Ă—1440 102 KB

looking for trouble:
IMG_20250208_211705
IMG_20250208_2117051920Ă—1440 79.6 KB

Long time with black screen and fat blinking _ cursor, then cursor disappeared and re-appeared.
Then black screen with fat blinking _ cursor.

Badumm Tss. Kernel Panic.

As this panic is only displayed shortly I had to rush to take the photo, it does not look good but it is readable. A problem with XEN as it seems to me.

IMG_20250208_211841
IMG_20250208_2118411920Ă—1440 166 KB

The machine rebooted quickly after displaying the panic.

@developers:
What about printf- / echo logging to line printer or rs232?

What about writing out numbers or text at the time when only the cursor can be seen.
I guess this is all XEN trying to do something.

Checks to be done, (but will not help much):
I need to run older qubes, memtest86 on the machine, also I need to verify the stick for errors.

Is there ioport 80 debugging sent while early booting? Need to grab a port 80 board somewhere.

Update:
looking for xen issues with the processor arch and ICH10 I only found this very old post.
https://lists.xen.org/archives/html/xen-devel/2011-08/msg00893.html

1 Like
2

@luja, maximum respect to someone who daily drives a machine with a floppy drive :sunglasses:

Sounds like your BIOS likes to “be its own boss”… Typical server hardware…

Dumb question. You’re sure your BIOS is configured properly, and that it’s not denying anything, right?

Is there any chance of seeing what showed up before the ---[ start trace ]--- line?

That’s the kernel trace, which looks like a memory paging error when Xen tries to load the Xen kernel. Something is being referenced that either isn’t where it thinks it is, or isn’t responding as expected.

Has this machine worked with other versions of Qubes OS?

If I could make a suggestion, if you can take a video of the kernel panic with a high framerate, you might have a better chance of getting a clear shot of the entire text. Maybe give that a go.

Or maybe keep Scroll Lock on so you can read it.

2 Likes
3

Yes, all fine. It is this qubes proven machine running older qubes and now it was time to schedule for an upgrade.

"
Dell Precision WorkStation T7500
Xeon L5638 Tylersburg FirePro W5100 ](Hardware compatibility list (HCL) | Qubes OS)
"

Maybe it somehow got broken, but this is very unlikely. Screaming for ECC errors or chipset errors sounds differently and the machine would then hang somewhere in bios self test.

Update:
The machine is still alive and kicking booting its old Qubes 4.0 with 12 cores and 196G RAM.

Next days I try the Qubes 4.2.3 from my laptop DELL m6800 by just swapping disks. Maybe the problem also persists with Qubes 4.2.3 as the machine was not upgraded all the time (except template VMs) because back up was a bit of a pain and the electricity bill is smaller with the laptop.

So the laptop will get a try with Qubes 4.2.4-rc1 and install Qubes to the test ssd.

PS: The old pig machine is optimized for low consumption in its class: L5638 is a rare Telco-Xeon with only 2.0GHz and 6 cores, the W5100 Graphics has 4 dp ports with 4 screens but is not so power hungry as other graphics boards while having some graphics power. It was chosen for quality not for graphics performance.

BTW: Any good ideas besides rsync to synchronize qubes across different machines?

2 Likes
4

New test result:
The 32nm Xeon is too old again with Xen :frowning:

I installed the sata ssd of my m6800 laptop, 22nm Core i7 with recent stable Qubes R4.2.3.
Here the machine booted until the “base system” step. So one could enter HDD mantra for Luks but sys-net, sys-usb, sys-firewall do not get started.

So this is a Xen-Issue with the old machine.

The question arises what exactly in Xen is not liked here.
Having once tried to use Qubes on a HP Z600 it boiled down to the pci id of the northbridge which was hard coded into Xen to throw an error. “I dont like you”. Here I wanted to code a patch but was to lazy to test it, where / why it did not work.

(Machine could be hacked into hackintosh: GitHub - huytbt/Hackintosh-HP-Z600-OpenCore: Hackintosh HP Workstation Z600 OpenCore Bootloader)

So is there any Xen-Debugging with Qubes?

What about scalability to use older Xen / older Xen features with Qubes to allow for older hardware which once worked with Qubes?
I know, security could be at risc but, using old CPUs one also has risks like rowhammer and other CPU bugs.
From security point of view best would be the newest AMD ZEN arch, which is ZEN 5 at the moment. So a Workstation with a new AMD EPIC CPU is quite costly, but wold be a solution, but is out of budget.

Nobody needs 128 cores with qubes :slight_smile:

But for poor hobby scientists a way to use their vintage HW with new qubes should be developed. It is an issue connected with XEN. So it can be insulated and done as a sub project.

Maybe it should be stated “22nm or smaller features only” with this qubes version, but the impacts are comming closer to people using older hardware.

Also about the 32nm out issue:
Has someone tested qubes with ASUS KGPE-D16 and 32nm Opteron which is/was a good qubes workstation candidate?

Here one wants the 2nd gen of matching Opteron CPU w/o PSP. The last opteron having AES acceleration and NO Spy engine called PSP (the ME in AMD arch).

1 Like