deadlock

[mczerski]

tty0tty/module/tty0tty.c

Line 282 in 9452a60

usleep_range(delay-1, delay);

I think that calling sleeep with locked semaphore is not a good idea. I experience deadlocks when using the latest version, and if I remove this sleep - no deadlocks.

[mczerski]

i'm trying to debug this but I have very wierd behaviour out of this. unlocking semaphore before sleep does not solve the issue. I can see that when the deadlock happens the tty0tty_write function returns 0 which does not makes sense for me ...

[stappersg]

On Tue, Nov 12, 2024 at 12:52:07AM -0800, Marek Czerski wrote: i'm trying to debug this but I have very wierd behaviour out of this. unlocking semaphore before sleep does not solve the issue. I can see that when the deadlock happens the tty0tty_write function returns 0 which does not makes sense for me ...

When there is a reproducer, say so. Groeten Geert Stappers -- Silence is hard to parse

[sfantree]

I also meet a similar problem that minicom is not responding when open uart, then i simply git reset to old commit f1afc6 by commit date, it works

[stappersg]

6 characters @sfantree f1afc6
6 characters @stappersg 9452a6
7 characters @stappersg 9452a60

Point I want to make: A short commit hash is at least seven character long.

[stappersg]

> When there is a reproducer, say so.

seven weeks later popy32 wrote:

I also meet a similar problem that minicom is not responding when open uart,

Please make some effort to describe how to reproduce.

then i simply git reset to old commit f1afc6 by commit date, it works

(-: Groeten Geert Stappers -- Silence is hard to parse

[jschwartzenberg]

I ran into this yesterday. I ran 86Box against /dev/tnt0 (had it symlinked to /dev/ttyS31 to let it show up) and tried to set up a getty on /dev/tnt1. Then both 86Box and the getty became unkillable.

Please let it know if I could provide more info!

[stappersg]

Please let it know if I could provide more info!

Describe how to reproduce the issue. Just "I ran 86Box against /dev/tnt0 (had it symlinked to /dev/ttyS31 to let it show up) and tried to set up a getty on /dev/tnt1" is too terse.

[jschwartzenberg]

Let's see if this works out, I hope it'll be reproducible this way:

1. Get the AppImage of 86Box from here: https://github.com/86Box/86Box/releases (I used 86Box-Linux-x86_64-b6130.AppImage)
2. Run 86Box and click on Tools -> Settings...
3. In 86Box settings configure a serial port:
4. Point it to ttyS31
5. Quit 86Box
6. Compile & load the tty0tty kernel module
7. cd /dev
8. sudo chmod a+rw tnt*
9. sudo mv ttyS31 ttyS31-orig
10. sudo ln -s tnt0 ttyS31
11. Run 86Box

With these steps 86Box hangs for me, right after executing step 11.

[stappersg]

With these steps 86Box hangs for me

(.........some self censoring.........) Retry at least with Host Serial Device /dev/tnt0 in step 4, go for a serious attempt on a reproducer of the presumed deadlock issue on tty0tty.

[jschwartzenberg]

It's not possible to select /dev/tnt0 in step 4 as the drop-down doesn't allow that. This seems an arbitrary limitation of 86Box. Note that something connecting to /dev/tnt1 hangs along when performing this procedure.
I'll see if I can get an easier reproduction path. Maybe I should first try with just a getty and minicom/PuTTY and work from there. If that doesn't trigger it, I will modify 86Box to add /dev/tnt* to that list.

[stappersg]

On Tue, Aug 19, 2025 at 03:31:33AM -0700, Julius Schwartzenberg wrote: I'll see if I can get an easier reproduction path. Maybe I should first try with just a getty and minicom/PuTTY and work from there.

Graag

If that doesn't trigger it, I will modify 86Box to add `/dev/tnt*` to that list.

Goed plan Groeten Geert Stappers -- Silence is hard to parse

[jschwartzenberg]

Met getty & plink krijg ik de boel op gang, maar het werkt niet zomaar.

1. Ik start sudo /sbin/getty -L tnt1 115200 vt100
2. Ik start (in een andere shell): plink -serial /dev/tnt0
3. Druk op allerlei toetsen, gebeurt niets.
4. Ga terug naar de shell met getty en druk op Ctrl+z, daarna fg
5. Nu verschijnt de prompt in plink en kan ik inloggen en alles doen.

Niet duidelijk waarom die stap 4 een verschil maakt. Ik hoop dat ik m'n echte nullmodem kabel kan vinden om meer te testen :)

Ik zal ook verder kijken naar 86Box.

Edit: inmiddels meer getest met een echte nullmodem kabel krijg ik getty helemaal niet op gang. Aan beide kanten plink -serial /dev/poort draaien werkt wel. En ook

1. plink -serial /dev/tnt0
2. plink -serial /dev/tnt1

Daarmee kunnen beide plinks elkaar zonder problemen bereiken, dus dat lijkt in orde.

[jschwartzenberg]

Ik heb de 86Box sources aangepast om de /dev/tnt* devices te laten verschijnen. Dit moest ik aanpassen.

[julius@elleboog 86Box]$ git diff
diff --git a/debian/rules b/debian/rules
old mode 100644
new mode 100755
diff --git a/src/qt/qt_deviceconfig.cpp b/src/qt/qt_deviceconfig.cpp
index 33572c99c..234e086ff 100644
--- a/src/qt/qt_deviceconfig.cpp
+++ b/src/qt/qt_deviceconfig.cpp
@@ -78,7 +78,7 @@ EnumerateSerialDevices()
     QDir dev_dir("/dev/");
     ttyEntries = class_dir.entryList(QDir::Dirs | QDir::NoDotAndDotDot | QDir::System, QDir::SortFlag::Name);
     for (int i = 0; i < ttyEntries.size(); i++) {
-        if (class_dir.exists(ttyEntries[i] + "/device/driver/") && dev_dir.exists(ttyEntries[i])
+        if (dev_dir.exists(ttyEntries[i])
             && QFileInfo(dev_dir.canonicalPath() + '/' + ttyEntries[i]).isReadable()
             && QFileInfo(dev_dir.canonicalPath() + '/' + ttyEntries[i]).isWritable()) {
             serialDevices.push_back("/dev/" + ttyEntries[i]);

Bij andere seriele apparaten zie ik dat dit pad bestaat, maar bij de tnt? apparaten mist de device directory:

[julius@elleboog ~]$ ls /sys/class/tty/ttyS0/
close_delay   console         dev     flags       iomem_reg_shift  irq   port   subsystem  uartclk  xmit_fifo_size
closing_wait  custom_divisor  device  iomem_base  io_type          line  power  type       uevent
[julius@elleboog ~]$ ls /sys/class/tty/ttyS0/device
driver  driver_override  modalias  power  subsystem  tty  uevent
[julius@elleboog ~]$ ls /sys/class/tty/ttyS0/device/driver
bind  serial8250  uevent  unbind
[julius@elleboog ~]$ ls /sys/class/tty/tnt0
dev  power  subsystem  uevent

Met die aanpassing en het kiezen van /dev/tnt0 uit de lijst, hangt 86Box bij het starten.
Als het dan lukt om 86Box te killen, dan werkt daarna het verhaal met plink -serial /dev/tnt0 en plink -serial /dev/tnt1 niet meer. Daarna krijg ik de plink -serial /dev/tnt0 niet meer gekilled, zelfs niet met -9.

[jschwartzenberg]

Found out that git revert ac540b84b5ae5f9c6805d80ec69e0bec9ffc79a3 lets 86Box work correctly without hanging. So ac540b8 does seem to be the culprit.