WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Recent Posts

Pages: 1 ... 7 8 [9] 10
81
Off-Topic - Tiny Core Lounge / Re: TCL desktop display
« Last post by Juanito on September 27, 2026, 10:14:46 AM »
If you get this
Code: [Select]
readlink /etc/sysconfig/tcedir
/tmp/tce

It means that you have a read-only iso installation equivalent to a cd/dvd and you are using Xfbdev by default.

You should be able to load the tc-install-GUI extension so that you can make a standard installation to usb stick/hd. This will enable you to use Xorg-7.7 instead of Xfbdev, which will probably use your monitors native resolution by default
82
Off-Topic - Tiny Core Lounge / Re: TCL desktop display
« Last post by vinceASPECT on September 27, 2026, 09:58:37 AM »
Hi forum,

Tried all the posted ideas here.............nothing works.

Rich, i tried your command and got back

=======
/tmp/tce
=======

i don't have any persistence .....or the tce forced to a real permanent memory store

i tried all the recommended bootcodes , ........nothing works
i tried the free SCRIPT about resolutions..........it does not work....it can't find "Xrandr" so throws an error..........is that script for 32 bit TCL?


i would have hoped this screen size issue could have been simply solved in moments.......... but no.

...... perhaps i must go away from 64 bit TCL to 32 bit.........it may be that 64 bit has had it's graphical initialisation and default method and drivers changed from what 32 bit defaults to and what  WORKS right..........64 bit graphics doesn't work for many brands of  "certain aged hardware" by default....

It's a 64 bit machine and cpu.

C

Perhaps the creator of the 64 bit TCL is not  able to support this screen size issue.....?
==
==
==
==
==
==

Ai  reply to the screen issue below............it'  *** significantly ****  more clear than anything in this OP and found in 20 seconds.
======================================================

Why has Tinycore 64 bit booted with GAPS at the edges of my screen on a HP compaq 6910p?


The gaps around the edges of your Tiny Core screen on the HP Compaq 6910p are almost certainly caused by the default Xvesa video driver not using your laptop's native widescreen resolution.
🖥️ The Root Cause: Resolution Mismatch

The HP Compaq 6910p typically has a native resolution of 1280x800 or 1440x900 (a 16:10 widescreen aspect ratio). However, the default Tiny Core Xvesa driver is often limited to a maximum of 1024x768 (a 4:3 aspect ratio).

When a 4:3 image is displayed on a 16:10 screen, you get black bars or gaps on the sides because the aspect ratios don't match. The system is essentially "letterboxing" the desktop to fit the smaller resolution.
🛠️ How to Fix It

You have two main options to resolve this, both of which involve moving away from the limited Xvesa driver.

Option 1: Install Xorg (Recommended)
This is the most reliable fix. Xorg is a more advanced display server that can load specific drivers for your laptop's Intel graphics chip, allowing it to use the native widescreen resolution automatically.

    Use the Tiny Core Apps browser to install Xorg-7.7.tcz (or the latest version).

    It is also a good idea to install the Intel-specific driver: xf86-video-intel.tcz.

    Reboot. Xorg should now detect your screen correctly and fill the display.

Option 2: Force a VESA Framebuffer Mode
If you prefer to avoid Xorg, you can try forcing the console and Xvesa to use a widescreen resolution using a boot code.

    Edit your bootloader configuration file (e.g., extlinux.conf or syslinux.cfg).

    Find the APPEND line and add a vga= code for a widescreen resolution. For example, to request 1280x800 at 16-bit color, you would add vga=794.

    Save the file and reboot.

Given the age of the HP 6910p, installing Xorg is the cleaner and more permanent solution, as it is designed to handle the specific quirks of laptop displays.

How can i fix it if i don't have any persistance and the TCE directory is not remembered over reboots?
Found 20 web pages

You can't fix this from within the running Tiny Core session because the system is running entirely in RAM and has no memory of your previous choices. The key is to fix it before you boot, by editing the bootloader configuration file on your pen drive from another computer.
🔧 The Fix: Edit the Bootloader Config

The bootloader is what reads the boot codes and decides where your tce directory is. You need to add a tce= boot code pointing to your pen drive.

1. Find the Configuration File
Plug the pen drive into a working computer (Windows, Mac, or Linux). Look for a file named syslinux.cfg or extlinux.conf (usually in a boot or syslinux folder, or the root directory).

2. Add the tce= Boot Code
Open the file in a text editor. Find the line that starts with APPEND or append. At the end of that line, add a space and then the tce= code.

The best approach is to use the UUID of your pen drive's partition. This is more reliable than /dev/sdX names, which can change. The syntax is:

tce=UUID="your-actual-uuid-here"

For example, your APPEND line might look like this:

APPEND initrd=/boot/core.gz quiet waitusb=5 tce=UUID="F0BC-3CAF"

If you can't find the UUID, you can try a simple label-based code, like tce=LABEL=PENDRIVE (replace PENDRIVE with the drive's label) .

3. Save and Boot
Save the file, safely eject the drive, and boot your HP laptop from it. Tiny Core should now find the tce directory on the pen drive and automatically load Xorg and any other extensions you've saved there .
💡 Why This Works

Tiny Core is designed to run from RAM, so by default it forgets everything on shutdown . The tce= boot code is the instruction that tells it where to look for and store permanent files, including your installed extensions and the backup of your personal settings . Once this code is in the bootloader config, the system will remember the location automatically every time.
🛠️ If You Already Have Extensions Installed

If you previously installed Xorg and saved it, the fix above will make Tiny Core load it on the next boot. If you never successfully saved the extension, you'll need to boot with the new tce= code, install Xorg again, and then it will be saved to the pen drive.

Let me know if you need help finding the UUID on your specific system
83
Well... some major update!

The short story:
My application clearly crashes on write() and almost not crashes on send()
With help of chatgpt I found a change between TC15 and TC17 in the Realtek network driver that looked suspicious.
As I learned how to built my own kernel few month ago, I reverted that driver-change (removed 3 lines, added 1 line) and made a custom TC17.1 kernel.
I also included "netdev_err(dev, "8139too: TX TIMEOUT TASK ENTERED\n")" at the start of the modified function to get diagnostics whether that part of code is executed.

And now things run smooth. No crash with custom kernel with reverted patch
But......... the modified code does not seem to be touched. I do not see the diagnostic message with dmesg.
I will keep testing over coming days to see whether this really holds.

I'm now comparing: custom_kernel_with_patch_revert to downloaded kernel.
As I donot see the changed piece of code executed I will after some solid test-stretch make a custom kernel from original source and see how that holds.

Testdata, all while running stress program in parallel:

Code: [Select]
Using standard TC17.1 kernel from tinycore download location:
Changed application to use
j = send(..., ..., ..., MSG_NOSIGNAL) instead dof write
45hr run without crash, stopped manually

Change application back to:
j = write(..., ..., ...);
Crash after 1hr 15min
Crash after 0hr 12min

Change to:
j = send(..., ..., ..., 0)
Crash after 1hr 25min
No crash over 16hr, manually stopped
Crash after 5hr

Change to:
Start program with: signal(SIGPIPE, SIG_IGN);
j = write(..., ..., ...);
Crash after 1 minute
Crash after 2 minutes

26-sep: Updated and made custom TC17.1 kernel with patch revert using source files from tinycore download location:
Reverted 19e612c47f4 change in rtl8139_tx_timeout_task() in drivers/net/ethernet/realtek/8139too.c

Changed application to:
Start program with: signal(SIGPIPE, SIG_IGN);
j = write(..., ..., ...);
No crash over 1hour 45min, manually stopped
Big improvement over "crash after 2 minutes before patch revert"

Change application to:
j = write(..., ..., ...);
Running for 19 hours now, still running

So... "what does patch 19e612c47f4 do"?
d19e612c47f4 — eth: 8139too: fix calling napi_enable() in atomic context
It was authored by Jakub Kicinski and submitted in January 2025. It was one of a group of seven driver fixes because a kernel-wide NAPI change had exposed the same problem in several older drivers.

Motivation is that such was deemed necessary because of kernel change kernel change 413f0271f396

The 8139too patch was not based on an observed RTL8139 hardware crash. It was a static locking analysis finding. The patch was compile-tested, and the cover letter says the fixes were "compile tested only."

History:
Code: [Select]
kernel change 413f0271f396
        ↓
NAPI enablement becomes protected by netdev_lock()
        ↓
napi_enable() may sleep
        ↓
old drivers calling it under spinlocks become invalid
        ↓
Dan Carpenter identifies several drivers
        ↓
January 2025:
8139too patch d19e612c47f4
        ↓
Linux 6.14


Code changes I did in reverting the patch:
Code: [Select]
TC17.1 version
netdev_lock(dev);
spin_lock_bh(&tp->rx_lock);
...
spin_lock_irq(&tp->lock);
rtl8139_tx_clear(tp);
spin_unlock_irq(&tp->lock);

napi_enable_locked(&tp->napi);
rtl8139_hw_start(dev);
netif_wake_queue(dev);

Reverted patch on TC17.1
spin_unlock_bh(&tp->rx_lock);
netdev_unlock(dev);

spin_lock_bh(&tp->rx_lock);
...
spin_lock_irq(&tp->lock);
rtl8139_tx_clear(tp);
spin_unlock_irq(&tp->lock);

napi_enable(&tp->napi);
rtl8139_hw_start(dev);
netif_wake_queue(dev);

spin_unlock_bh(&tp->rx_lock);

Conclusion:
- The suspicion under test is that the patch probably fixed something, but as a collateral damage created a new vulnerability that causes my crashing behavior.
- The custom kernel with reverted path behaves massively better BUT the updated code is not touched which makes the results quite non understandable
- I keep testing and will after this test with custom kernel with original code
84
Tiny Core on Virtual Machines / Re: I would like to enable 1080p resolution
« Last post by gadget42 on September 26, 2026, 12:02:36 PM »
this may or may-not be food-for-thought for your specifics

https://forum.tinycorelinux.net/index.php?topic=28281.0
87
Tiny Core on Virtual Machines / I would like to enable 1080p resolution
« Last post by MaxFury on September 26, 2026, 10:58:45 AM »
Hi all!
I am using TinyCorePure64-17.1.iso and I would like to change the screen resolution to 1920x1080.
How can I do that?

-thanks!
88
More data, still testing, but its getting evening here so I kind of call it a day, will continue tomorrow.
But.. some remarkable results so far...

Summarizing

23-sep, complete rewrite:
NO select()
NO check pipe errors before calling write/send
j = send(..., ..., ..., MSG_NOSIGNAL) instead of write
Full error handling of all calls, Syslog voor alle errors
45hr run without crash, stopped manually

Almost no errors, only:
send(): 111 connection refused
read(): 104 SSL_ERROR_SYSCALL, socket reset during call
During 1minute service interval of solaredge inverter

25-sep:
Change to:
j = write(..., ..., ...);
1st run: Crash after 1hr 15min
2nd run: Crash after 0hr 12min

Change to:
j = send(..., ..., ..., 0)
1st run: Crash after 1hr 25min
2nd run: running now

Change to:
Start program with: signal(SIGPIPE, SIG_IGN);
j = write(..., ..., ...);
1st run: Crash after 1 minute
2nd run: Crash after 2 minutes

All in all...
I think that after finalizing the 2nd run for "j = send(..., ..., ..., 0)" I will go to the "j = send(..., ..., ..., MSG_NOSIGNAL)" config again and try to run that for multiple days.

All in all this definitely indicates a linux error. This is not as it should be at all.
I doubt tinycore packaging is causing this, more likely to be deep into the real kernel source.

Questions I have:
- does anybody has any idea on "whether tinycore could cause this"?
- does anybody have an idea how to bring this to the linux team?


I myself will be fully ok with running with the "j = send(..., ..., ..., MSG_NOSIGNAL)" command assuming that survives the multiday test.
89
BAM... an other crash in just 12 minutes.

I restarted.
Modified: j = write(..., ..., ...);
to: j = send(..., ..., ..., 0);

As we know: j = send(..., ..., ..., MSG_NOSIGNAL); is working
So this further narrows down whether its the MSG_NOSIGNAL or de send() versus write() call
90
and BAM... crash after 1 hour and 15 minutes

So...
with: send(file_descriptor, &buffer, buffer_length, MSG_NOSIGNAL);
45 hr run without crash and manually stopped

with: write(file_descriptor, &buffer, buffer_length);
crash after 1 hour and 15 minutes

In both situations INcluding running stress program in parallel that drives cpu use to 80% and network use to 90%.
- I'll give it a 2nd try.
- I also think I will try: "use the write() and start program with  signal(SIGPIPE, SIG_IGN)"

Note...
- It is "normal behavior" that a "broken pipe signal" during write() terminates the program
- This however should NOT crash the full linux.
- Using send(..., ..., ..., MSG_NOSIGNAL) does not generate a "broken pipe signal" but only returns a "broken pipe" error code.

But... I can use some help:
If further testing remains like this I can easily fix my application by using the send() but:
- Is there anything special in tinycore packaging of linux that could have mis-used the broken pipe signal?
- If not, Any suggestions on how to bring this to the linux board?
Pages: 1 ... 7 8 [9] 10