Ab - so - lu - te - ly

Rather dissapointing to see such a question asked here at Dev1.
But here we are.

A.

Hello:

Hmm ....
Maybe with some additional information?

For the sake of clarity/brevity I will skip the long story:

1.
Discovered the problem and rolled back to a VM snapshot from 30 days
ago, the oldest one I have.

Concurrently, rolled back to VBox (7.0.6) along with its
GuestAdditions 7.0.6. 

I thought that it would rule out (?) a VBox update or some corruption
in the XPSP3 VM as everything happened way after that date.   

At least I did not notice it as I do not use the XP VM often.

Problem did *not* go away.

2.
Removed VBox 7.0.6 / GuestAdditions 7.0.6, reinstalled the latest
available (7.0.12) along with GuestAdditions and the Extension Pack
which was missing.

Problem did *not* go away.

3.
Went back to the last snapshot and tried to fix things by mucking
around the XPSP3 installation but only managed to screw it up even
more.

The net result being that it is now on a 'black screen select how to
boot' and 'blue screen with whatever' loop.

4.
I attempted to add a new XP VM using three or four of the
downloadable XP isos I found on the web and was able to install one
of them as a VM.

Problem did *not* go away and shutdown does not work.
Not even shutting down X via ctrl+backspace.
Have to reboot my box.

TL;DR

The problem exists whether I use VirtualBox 7.06 or 7.0.12, with a
recovered version of the VM or the latest one.

Installing a new XPSP3 VM, whether in VirtualBox 7.0.6 or 7.0.12,
complete with GA+EP does not solve the problem.

In all cases, disconnecting the host from the web (cable and all)
does not solve the problem so phoning home does not seem to be a
posible cause.

This is (part of) what I get in a rolling dmesg screen:

------------[ cut here ]------------
--- snip ---

WARNING: CPU: 0 PID: 16511 at arch/x86/kernel/fpu/core.c:129 
kernel_fpu_begin_mask+0xc9/0xe0
--- snip ---
Call Trace:
[  +0.000031]  SUPR0FpuBegin+0x13/0x20 [vboxdrv]
[  +0.000006]  ? up+0x12/0x50
[  +0.000014]  ? VBoxHost_RTThreadCtxHookEnable+0x32/0x40 [vboxdrv]
[  +0.000012]  ? supdrvIOCtl+0xc5e/0x3650 [vboxdrv]
[  +0.000013]  ? rtR0MemAllocEx+0x57/0xd0 [vboxdrv]
[  +0.000012]  ? supdrvIOCtlFast+0x58/0xb0 [vboxdrv]
[  +0.000011]  ? VBoxDrvLinuxIOCtl_7_0_12+0x57/0x230 [vboxdrv]
[  +0.000003]  ? __x64_sys_ioctl+0x84/0xc0
[  +0.000004]  ? do_syscall_64+0x33/0x80
[  +0.000003]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  +0.000002] ---[ end trace 2d76295c57757cc8 ]---

The warning is always the same.
ie:
at arch/x86/kernel/fpu/core.c:129 kernel_fpu_begin_mask+0xc9/0xe0

The call trace starts with the same line.
ie:
SUPR0FpuBegin+0x13/0x20 [vboxdrv]

And it is all about the same module:
ie:

? VBoxHost_RTThreadCtxHookEnable+0x32/0x40 [vboxdrv]
? VBoxHost_RTThreadCtxHookEnable+0x32/0x40 [vboxdrv]
? supdrvIOCtlFast+0x58/0xb0 [vboxdrv]
? VBoxDrvLinuxIOCtl_7_0_12+0x57/0x230 [vboxdrv]

~$ lsmod | grep vbox
vboxnetadp             28672  0
vboxnetflt             32768  1
vboxdrv               589824  4 vboxnetadp,vboxnetflt   # <- this one
~$ 

One of the important packages updated lately was linux-kbuild.
ie: 5.10.179-5~deb10u1 to 5.10.197-1~deb10u1

I understand that it is closely related to module handling by the kernel.

If anyone has a clue as to what the trace in dmesg indicates, I'm
all ears.

Thanks in advance.

Best.

A.

Hello:

tl,dr
I was able to trace the issue to a power supply problem.
ie: I overestimated the power supplied by the lead to the now archived OEM DVD writer.
As a result, the installer checking the integrity of a large file made for a sustained peak that was not met by that lead.

That is why it repeatedly failed at the same place.
Once I removed the hardware causing this, that problem went away.

But another problem remains.

The process of copying from the USB installer media and writing to the destination USB drive seems to cause the same problem as it gets stuck at 32% when installing the base files which means I need to relocate the extra hardware feeding from the DVD power plug.

Best,

A.

Hello:

No problem.

Best,

A.

Hello:

Right.

--- snip ---
[  +8.930261] hub_port_connect: 5 callbacks suppressed
[  +0.000011] usb usb1-port5: connect-debounce failed

--- snip ---
[  +3.305752] usb 1-5: new full-speed USB device number 5 using xhci_hcd
[  +0.128088] usb 1-5: device descriptor read/64, error -71
[  +0.235964] usb 1-5: device descriptor read/64, error -71
[  +0.236013] usb 1-5: new full-speed USB device number 6 using xhci_hcd
[  +0.127984] usb 1-5: device descriptor read/64, error -71
[  +0.236036] usb 1-5: device descriptor read/64, error -71
[  +0.108093] usb usb1-port5: attempt power cycle
--- snip ---

HID devices need more power than a USB stick and from what dmesg says, it seems that (for whatever reason) they are not getting it from all the available ports.

Maybe these specific ports are disabled or asleep?
Is there a setting in the BIOS that has to do with enabling USB ports selectively or something related to power management or *wake up* settings?

From page 28 of the Asus CN62 manual:

We can find out some more by using a powered hub.

Try to borrow or purchase one and plug it into one of the non working USB sockets.

Once it is plugged in, plug in the mouse and then the kb (one at a time) into the hub.
Check the output of each step via ~$ sudo dmesg -wH.

Please post the results.

If it the kb and mouse work, it would rule out faulty USB socket problems and point us to a USB power/configuration issue.

Best,

A.

Hello:

You're welcome.
Once you've fixed things, please post steps taken, results, etc. so it will be available to all in the future.

Also, you may want to consider changing the title of your OP to reflect the hardware and Devuan version you were installing.

eg: Chromebox [model] with [Devuan version used here] - USB interfaces not working 

Best,

A.

Hello:

Indeed ...

Yes, that not happening is one of my pet peeves.
Specifically with the won't fix crowd.

In any case, at the time* I decided to add these lines to crontab:
* though I have not had time to follow up on whatever was causing the errors

# 1. For /home/groucho/.xsession-errors
# ---
0 */23 * * * [ $(du -k .xsession-errors | awk '{ print $1 }') -gt 2000 ] && tail -200 /home/$(whoami)/.xsession-errors > /home/$(whoami)/.xsession-$
# ---

When run, it will check and limit the .xsession-errors file to 2000 Kb while retaining the last 200 lines.
Check it here at crontab.guru.

2000 Kb is quite a bit of text in a logfile and from what I have seen, the entries in .xsession-errors have a very high rate of repetition.

eg:
Xlib because of missing "RANDR" extension, typical of Nvidia setups
Gtk warnings because of some deprecated whatever
Firefox-esr warnings because of deprecated GtkButton property and so on ...
Xfmw4 and xfdesktop warnings and fatal IO errors and such.

Best,

A.

Hello:

This is my box:

~$ uname -a
Linux devuan 5.10.0-0.deb10.16-amd64 #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64 GNU/Linux
~$
 

Got it from the repository:

~$ apt list | grep firefox-esr
--- snip ---
firefox-esr/oldoldstable-security,now 115.4.0esr-1~deb10u1 amd64 [installed]
~$ 

Thanks for your input.

Best,

A.

Hello:

Right.

Yes, that was not a problem.
What I was thinking was that the system would be nimbler.

Thank you both for your input.
It would seem that I'll keep using the standard kernel.

Best,

A.