Core v16.0beta1

[Knoppix1337]

Ok, after a short hiatus, I'm back

History; TC16 Alpha release posts, https://forum.tinycorelinux.net/index.php/topic,27517.0.html

I've done many hours of testing to narrow down the problems I've had on running TC16 on various VIA Technologies C7 single core x86 32bit microprocessor based machines

Rich mentioned;

Just my opinion, but unless you have some compelling reason to
move to TC16, you might want to consider sticking with TC15 if
it works on your system.

Which is a valid suggestion, but it doesn't quite fit my situation because;

1: TCL is one of the few 32bit distros remaining, and these are all x86 based machines, so I don't have many choices left. I don't know why or when x86 became a dirty word.

2: I am the sole beta tester for the VIA graphics Openchrome project, and I work with the sole developer of Openchrome Linux video drivers, so...

3: I have a vested interest in being able to put these machines to good use, and...

4: It would be a shame to not have a whole series of machines be able to take advantage of the work and updates TC16 provides.

That being said, I have narrowed down my problems.

1: The TC16 Kernel used always locks up, only the printk modified Kernel; vmlinuz-6.12.11-printkdelay from http://tinycorelinux.net/16.x/x86/debug/ works properly

2: I have had no problems using the printk Kernel, except as follows:

3: Using the printk Kernel, coreutils.tcz causes the eventual lockup of the machine, running a loop using echo and sleep from coreutils.tcz, I haven't tested other utilities from that package.

I don't know how y'all want to proceed, possibly replace the TC16 Kernel with the printkdelay version, at minimum I would hope that the printk Kernel remains available for people with affected machines, along with release notes to let them know.

As far as coreutils goes, there is a newer version available.

I don't know what the root cause of the lockups are, perhaps toolchain or cross compiler options. I am not sure what the difference between the compilation of Rich's printkdelay Kernel, and the original TC16 Kernel.

I know the forum rules forbid the asking of hardware, but doesn't say anything about the offering of hardware. Due to my vested interests, I have made a few bulk purchases of these machines for development and testing purposes. I would be willing to donate a machine or 2 if it would help, as they are doorstops without working software. I am located in Chicago, IL so I'm not above bribing y'all. Please contact me off-list and I'll see what I can do.

Eric.

[CNK]

FWIW I've got a HP 2533t with a VIA C7-M. I can try booting TC16 on it if that's any use. The service manual lists the full processor spec as: "Via C7-M Ultra-Low Voltage (ULV) 1.00-GHz, 128-KB L2 cache, 400-MHz front side bus (FSB)"

[Rich]

Hi CNK

TC16 does boot on my Pentium 1 PC with 80MB RAM. I'll see if I can install more RAM in the 486 laptop to see whether CPU or RAM is the problem there.

Unpack core.gz to the hard drive like you did for the 486.
Then try booting with this boot code included:

Code: [Select]

mem=16M

[CNK]

TC16 does boot on my Pentium 1 PC with 80MB RAM. I'll see if I can install more RAM in the 486 laptop to see whether CPU or RAM is the problem there.

Unpack core.gz to the hard drive like you did for the 486.
Then try booting with this boot code included:

Code: [Select]

mem=16M

I gave that a try on the Intel Celeron laptop. TC16 fails then too, but with loads of error messages not shown on the 486. On TC15 it boots further, but doesn't get through tc-config (killed due to low RAM) and then doesn't activate the swap partition (I moved that step right after udev start in my custom tc-config), which does work on the 486 with real 16MB RAM.

So yeah it might just be a RAM issue, but nothing quite matches up with mem=16 on newer hardware Vs physical 16MB on the 486. RAM use might depend on what kernel built-in drivers are used. I use the Pentium 1 PC every day (writing this on it), so I prefer to test these things on other computers that don't have to be reassembled immediately.

Of three 486 laptops I have, the only one taking standard RAM sticks has too low-spec of a 486. I'll see if I can set up a 486 desktop PC with more RAM, or upgrade that 486 laptop if it's possible.

[gadget42]

FWIW I've got a HP 2533t with a VIA C7-M. I can try booting TC16 on it if that's any use. The service manual lists the full processor spec as: "Via C7-M Ultra-Low Voltage (ULV) 1.00-GHz, 128-KB L2 cache, 400-MHz front side bus (FSB)"

i am interested in the results of this test. thanks.

[CNK]

I tested TC16 on a desktop PC with an AM486DX2-66 and 20MB of RAM. The system reboots at the same point when the kernel should start. TC15 boots fine (in under 40 seconds with my stripped-down tc-config) and doesn't even use the swap space.

I'll see if I can find some bigger RAM sticks to increase the RAM more significantly above 16MB (might take a while, RAM was even more poorly labeled in those days) in case the TC16 kernel needs way more for some reason. But I'm more convinced that it's a processor compatibility problem with the new kernel.

Will test on the HP 2533t too once I sort out how to get TC16 onto it. Some of the features I've tried disabling on the kernel command line for the 486 might be worth trying with that as well:

Code: [Select]

highres=off mitigations=off nosmp nosmt acpi=off


[Rich]

To anyone following this thread, posts relating to updating
fluff, flit, and flpicsee have been split off to their own thread:
https://forum.tinycorelinux.net/index.php/topic,27574.0.html

[Leee]

To anyone following this thread, posts relating to updating
fluff, flit, and flpicsee have been spit off to their own thread:
https://forum.tinycorelinux.net/index.php/topic,27574.0.html

Thanks, Rich.  That makes sense.

FWIW, I've been doing all my fluff testing on Core 16.0beta1 / x86_64 and the RC seems rock solid on my laptop.  I haven't been back to 15.0 since 16.0apha1 was posted except for once when I wanted to verify something.  (mind you, I have backups, just in case.)

[CNK]

Will test on the HP 2533t too once I sort out how to get TC16 onto it. Some of the features I've tried disabling on the kernel command line for the 486 might be worth trying with that as well:

Code: [Select]

highres=off mitigations=off nosmp nosmt acpi=off


Regardless of those options the boot process hangs on my HP 2533t with the standard TC16 kernel. It always hangs either immediately after the "run /sbin/init" message, or at some random point during tc-config. The vmlinuz-6.12.11-printkdelay kernel boots fine. Tried booting from USB and from its PATA flash drive with all peripherals disabled in the BIOS, but same issue with the standard TC16 kernel.

It's curious that the standard kernel never hangs before the init process is started. I wonder if it's something to do with the task scheduler? I'll try some scheduler-related kernel boot commands when I get the time/energy.

Dmesg shows a message suggesting that "tsc=unstable" be added to the kernel command line (in TC15 and TC16), but adding that doesn't help the TC16 kernel boot. Maybe use "clocksource=hpet" instead of default "clocksource=tsc"? No time to dig deeper, I should be working now...