Ok... lots to say...Yesterday I was off. Today the crash program was still running. I manually stopped it
mon day: 5 10 | hh:mm:ss: 13:49:56 | Still alive after 0k + 1 loops
.....
mon day: 5 14 | hh:mm:ss: 13:19:37 | Still alive after 878k + 109 loopsSo:
- with crashprogram that no longer has "stress inducing interrupts" and "TC17 with text boot option" I see no crash in 4 days.
Next step I tried:- install TC16
However... Install worked, but I did not get it running.
I tried TC16.0 and TC16.1 but for some reason I could not get them to run.
syslog did start but it looks like it stalls when trying to load core.gz.
I noticed that on my MacBook TC16 core.gz is downloaded as core.cpio. I tried booting core.cpio but without success.
I changed name in syslog.conf to core.cpio; I also tried renaming core.cpio to core.gz but neither worked.
>> I abandon that path.
Next step..I downloaded sources from TC15, TC16 and TC17 and looked into ./drivers/usb/serial
I did run a diff on usb-serial.c
>> note, I have no clue whether this is the file I need, I just guessed based on filename.
The most suspicious difference I did see:
TC15:
> tty = tty_port_tty_get(&port->port);
> if (tty) {
> tty_vhangup(tty);
> tty_kref_put(tty);
> }
TC17:
< tty_port_tty_vhangup(&port->port);This (I think) means that TC15 is testing tty to be valid before doing tty_vhangup() by calling tty while TC17 directly closes the port without testing whether the associated tty exists.
I did some google and found on
https://docs.kernel.org/driver-api/tty/tty_port.html:
The tty port has a different lifetime to the tty so must be kept apart. In addition be careful as tty -> port mappings are valid for the life of the tty object but in many cases port -> tty mappings are valid only until a hangup so don’t use the wrong path.
please understand, I have no clue about the logic of this code, but I "can" imagine a hangup_command that is run in kernel mode on a non-existant port to cause a crash.
Next.....
- for now I started the crash-test again including stress commands and including gui. With a little luck it fails again in 45hr and than I can see whether I can jump out the gun with CNTR-ALT-F1 as suggested by @Rich.
Followup, and I could use some help here...1/
It would be nice if I could understand why TC16 does not run. The diff between TC16 and TC17 on usb-serial.c is almost nothing.
> its above mention tty check
> and also use of "guard" instead of "spin_lock"
So if TC16 runs without crash it is a further evidence that the issue is in one of above 2 changes.
So... any advice on "why boot gets stuck on TC16" is welcome
2/
would there be any way that I could recompile the core with usb-serial.c fixed for the tty check?
Please understand that I have zero experience in compiling core.
I would also be very happy to test a core that someone prepared for me.
3/
Can anyone confirm that usb-serial-6.18.2-tinycore.tcz is indeed the usb-serial.c file??
Note,... would simply using usb-serial-6.6.8-tinycore.tcz (TC15) or usb-serial-6.12.11-tinycore.tcz (TC16) have any potential to work??
Especially the TC16 should have potential as the only difference is in the tty_vhangup() and the spinlock.
And/or... any way I could get a usb-serial-x.y.z-tinycore.tcz compiled for TC17 based on TC16 usb-serial.c?
For informationdiff of usb-serial.c TC17 TC15
$$ TC17 crash work % diff TC17_drivers_usb_serial/usb-serial.c TC15_drivers_usb_serial/usb-serial.c
709c709
< guard(mutex)(&usb_dynids_lock);
---
> spin_lock(&drv->dynids.lock);
711a712
> spin_unlock(&drv->dynids.lock);
714a716
> spin_unlock(&drv->dynids.lock);
1178a1181
> struct tty_struct *tty;
1193c1196,1200
< tty_port_tty_vhangup(&port->port);
---
> tty = tty_port_tty_get(&port->port);
> if (tty) {
> tty_vhangup(tty);
> tty_kref_put(tty);
> }
1455c1462
< * __usb_serial_register_drivers - register drivers for a usb-serial module
---
> * usb_serial_register_drivers - register drivers for a usb-serial module
1457d1463
< * @owner: owning module
1464,1466c1470,1472
< int __usb_serial_register_drivers(struct usb_serial_driver *const serial_drivers[],
< struct module *owner, const char *name,
< const struct usb_device_id *id_table)
---
> int usb_serial_register_drivers(struct usb_serial_driver *const serial_drivers[],
> const char *name,
> const struct usb_device_id *id_table)
1511d1516
< (*sd)->driver.owner = owner;
1519c1524
< rc = driver_attach(&udriver->driver);
---
> rc = driver_attach(&udriver->drvwrap.driver);
1530c1535
< EXPORT_SYMBOL_GPL(__usb_serial_register_drivers);
---
> EXPORT_SYMBOL_GPL(usb_serial_register_drivers);diff of usb-serial.c TC17 TC16
$$ diff TC17_drivers_usb_serial/usb-serial.c TC16_drivers_usb_serial/usb-serial.c
709c709
< guard(mutex)(&usb_dynids_lock);
---
> spin_lock(&drv->dynids.lock);
711a712
> spin_unlock(&drv->dynids.lock);
714a716
> spin_unlock(&drv->dynids.lock);
1178a1181
> struct tty_struct *tty;
1193c1196,1200
< tty_port_tty_vhangup(&port->port);
---
> tty = tty_port_tty_get(&port->port);
> if (tty) {
> tty_vhangup(tty);
> tty_kref_put(tty);
> }
Welcome
FAQ
Downloads
Wiki
