---1736217751-826265848-921803012=:644
Content-Type: TEXT/PLAIN; charset=US-ASCII
Abstract:
After running the attached program and breaking it with ^C open calls on
/dev/ttyS0 are blocking forever. No way to return to original state of ttyS0
exept reboot was found. Both 2.0.37pre8 and 2.2.3 kernels are affected. In
2.0.37pre8 the wchan points around serial.c:2487.
Experiment and results:
gcc -o demo demo.c
[root@crds pcontrol-parport]# strace ./demo
execve("./demo", ["./demo"], [/* 33 vars */]) = 0
[...]
open("/dev/ttyS0", O_RDWR|O_NOCTTY) = 3
gettimeofday({921790934, 786136}, NULL) = 0
ioctl(3, TCFLSH, TCIFLUSH) = 0
ioctl(3, SNDCTL_TMR_START, {B19200 -opost -isig icanon -echo ...}) = 0
write(3, "PR13", 4) = 4
read(3, <unfinished ...> /* Ctrl-C pressed*/
running it (or any other program opening /dev/ttyS0) again:
[root@crds pcontrol-parport]# strace ./demo
execve("./demo", ["./demo"], [/* 33 vars */]) = 0
[...]
open("/dev/ttyS0", O_RDWR|O_NOCTTY <unfinished ...> /* Ctrl-C pressed*/
strace cat /dev/ttyS0
[...]
open(ptrace: umoven: I/O error
0xbffffc50, O_RDONLY <unfinished ...> /* Ctrl-C pressed here */
strace cat /dev/ttyS1 before running demo was looking like:
open(ptrace: umoven: I/O error
0xbffffc50, O_RDONLY) = 3
fstat(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(4, 65), ...}) = 0
brk(0x8051000) = 0x8051000
read(3, <unfinished ...> /* Ctrl-C pressed*/
where is it waiting:
ps axlwwwww | grep cat
100000 0 930 784 3 0 936 284 block_til_r S p3 0:00 cat /dev/ttyS0
ps axlwwwwwn | grep cat
100000 0 930 784 1 0 936 284 18a791 S 0303 0:00 cat /dev/ttyS0
System.map :
0018a500 T rs_hangup
0018a5a8 t block_til_ready
0018a808 T rs_open
18A791-18A5A8 == 1E9
if (current->signal & ~current->blocked) {
000033c8 <block_til_ready+1d4> movl 0x0,%edx
000033ce <block_til_ready+1da> movl 0x10(%edx),%eax
000033d1 <block_til_ready+1dd> notl %eax
000033d3 <block_til_ready+1df> testl %eax,0xc(%edx)
000033d6 <block_til_ready+1e2> jne 000033e0 <block_til_ready+1ec>
/mnt/motyl/usr/src/20/linux/drivers/char/serial.c:2486
retval = -ERESTARTSYS;
break;
}
#ifdef SERIAL_DEBUG_OPEN
printk("block_til_ready blocking: ttys%d, count = %d\n",
info->line, info->count);
#endif
schedule(); /* HERE ??????? <<<<<<<<------------------- */
000033d8 <block_til_ready+1e4> call 000033d9 <block_til_ready+1e5>
/mnt/motyl/usr/src/20/linux/drivers/char/serial.c:2487
}
000033dd <block_til_ready+1e9> jmp 00003364 <block_til_ready+170>
000033df <block_til_ready+1eb> nop
Discussion:
My program is partially based on serial-programmming-howto. May still contain
some bugs. But it should not result in such a state of /dev/ttyS0. In my
opinion serial.c uses too much undocumented features of Linux scheduler.
More details available on request.
Please reply to motyl@tichy.ch.uj.edu.pl, since switch.ch may have some
problems with intercontinental connectivity.
-- Tomasz Motylewski---1736217751-826265848-921803012=:644 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="demo.c" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.96.990319012332.644B@crds.chemie.unibas.ch> Content-Description:
I2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5jbHVkZSA8c3RkbGliLmg+DQojaW5j bHVkZSA8bWF0aC5oPg0KI2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KI2luY2x1 ZGUgPGZjbnRsLmg+DQojaW5jbHVkZSA8bGltaXRzLmg+DQojaW5jbHVkZSA8 dGVybWlvcy5oPg0KI2luY2x1ZGUgPHVuaXN0ZC5oPg0KI2luY2x1ZGUgPHN5 cy9pb2N0bC5oPg0KI2luY2x1ZGUgPHN5cy9tbWFuLmg+DQojaW5jbHVkZSA8 c3lzL3RpbWUuaD4NCiNpbmNsdWRlIDxzY2hlZC5oPg0KDQovLyNpbmNsdWRl ICJjcmRzLXNobS5oIg0KDQpjaGFyICpkZXZuYW1lID0gIi9kZXYvdHR5UzAi Ow0KI2RlZmluZSBBQ0tfQ0hBUiAnXDAwNicgLyogQUNLbm93bGVkZ2UgKi8N Cg0KaW50IHNobWluaXQoKSB7DQoJdm9sYXRpbGUgY2hhciBncm93X3N0YWNr WzY0KjEwMjRdOw0KCXZvbGF0aWxlIGludCB0bXA7DQoJaW50IGksajsNCglz ZXRldWlkKGdldHVpZCgpKTsNCglyZXR1cm4oMCk7DQp9DQoNCmludCBmZGFk YzsgLyogc2VyaWFsIHBvcnQgZmlsZSBkZXNjcmlwdG9yIChmZCkgKi8NCnN0 cnVjdCB0ZXJtaW9zIHNlcmlhbF9wYXJhbTsgLyogc2VyaWFsIHBvcnQgc2V0 dGluZ3MgKi8NCg0KaW50IGFkY19pbml0KCkJew0KCWludCBpOw0KDQoJaWYo IChmZGFkYz1vcGVuKGRldm5hbWUsT19SRFdSIHwgT19OT0NUVFkpKSA8IDAp IHsNCgkJcGVycm9yKGRldm5hbWUpOw0KCQlleGl0KDIpOw0KCX0NCglhZGNf c2V0KCk7DQoJcmV0dXJuKDApOw0KfQ0KaW50IGFkY19zZXQoKSB7DQoJaW50 IGk7DQoJc3RhdGljIGRvdWJsZSBsYXN0dGltZT0wLjA7DQoJc3RydWN0IHRp bWV2YWwgdHY7DQoJDQoJZ2V0dGltZW9mZGF5KCAmdHYsIE5VTEwpOw0KCWlm KHR2LnR2X3NlYyt0di50dl91c2VjLzEwMDAwMDAuMDxsYXN0dGltZSsyLjAp DQoJCXJldHVybigwKTsNCglsYXN0dGltZT10di50dl9zZWMrdHYudHZfdXNl Yy8xMDAwMDAwLjA7DQoJYnplcm8oKGNoYXIqKSZzZXJpYWxfcGFyYW0sc2l6 ZW9mKHNlcmlhbF9wYXJhbSkpOw0KCWNmbWFrZXJhdygmc2VyaWFsX3BhcmFt KTsNCgljZnNldG9zcGVlZCgmc2VyaWFsX3BhcmFtLEIxOTIwMCk7DQoJc2Vy aWFsX3BhcmFtLmNfaWZsYWcgPSBJR05DUiB8IElHTlBBUjsgIC8qaWdub3Jl IENSIG9uIGlucHV0ICovDQoJc2VyaWFsX3BhcmFtLmNfb2ZsYWcgPSBDTE9D QUw7IC8qaWdub3JlIG1vZGVtIGNvbnRyb2wgbGluZXMgKi8NCglzZXJpYWxf cGFyYW0uY19sZmxhZyA9IElDQU5PTjsgLypjYW5vbmljYWwgbW9kZSAtIGJ1 ZmZlciBieSBsaW5lcyAqLw0KLy8Jc2VyaWFsX3BhcmFtLmNfY2NbVkVPTF0g PSBMRl9DSEFSOyAvKiBMRiBpcyB0aGUgZGVmYXVsdCBFT0wgKi8NCglzZXJp YWxfcGFyYW0uY19jY1tWTUlOXSA9IDE7DQoJdGNmbHVzaChmZGFkYywgVENJ RkxVU0gpOw0KCXRjc2V0YXR0cihmZGFkYywgVENTQU5PVywgJnNlcmlhbF9w YXJhbSk7DQoJcmV0dXJuKDApOw0KfQ0KI2RlZmluZSBCX0JVRlMgMjU2DQpk b3VibGUgYmFsemVyc19nZXRfcChpbnQgY2huKSB7DQoJY2hhciBvdXRidWZb Ql9CVUZTXSwgaW5idWZbQl9CVUZTXTsNCglpbnQgaW47DQoNCglzbnByaW50 ZihvdXRidWYsQl9CVUZTLTEsIlBSJWRcbiIsY2huKTsNCgl3cml0ZShmZGFk YyxvdXRidWYsNCk7DQoJaW49MDsNCglpbj1yZWFkKGZkYWRjLGluYnVmLDEw KTsNCglpZihpbmJ1ZlswXSAhPSBBQ0tfQ0hBUikgew0KCQlwcmludGYoImNv bW0uIGVycm9yLCByZWNlaXZlZCA6JXM6XG4iLGluYnVmKTsNCgkJc2xlZXAg KDEpOw0KCQlyZXR1cm4gLTEuMDsgLyogd2FybmluZzogdGhlIGNhbGxlciBt YXkgYWNjZXB0IG9ubHkgcmV0dXJuIHZhbHVlcyA+PSAwICovDQoJfQ0KCXdy aXRlKGZkYWRjLCJcMDA1XG4iLDIpOw0KCWluPXJlYWQoZmRhZGMsaW5idWYs Ql9CVUZTLTEpOw0KCWlmKGluPj0wKSB7DQoJCWluYnVmW2luXT0nXDAnOw0K CQlwcmludGYoImdvdCAlZDolczpcbiIsY2huLGluYnVmKTsNCgl9IGVsc2Ug ew0KCQlwZXJyb3IoInJlYWQ6Iik7DQoJfQ0KCXJldHVybiAwLjAwMDAwMTsN Cn0NCgkJDQoNCiN1bmRlZiBERUJVRw0KLyogRE1BIGhhcyBiZWVuIHNldCB0 byBkZWxpdmVyIGRhdGEgdG8gZG1hYnVmLCB3ZSBqdXN0IHByb2Nlc3MgaXQs IHNsZWVwaW5nDQpmb3IgMiBtcyB3aGVuIGFsbCBkYXRhIGlzIHByb2Nlc3Nl ZC4gT3RoZXIgcHJvY2Vzc2VzIHJlYWQgc29ydGVkIHNhbXBsZXMNCm9yIGF2 ZXJhZ2VzIGZyb20gc2hhcmVkIG1lbW9yeSBidWZmZXIgc2hkICovDQppbnQg Z2V0X2RhdGFfbG9vcCgpIHsNCglpbnQgbnJlYWQ7DQoJc3RhdGljIGludCBj bnQ9MCwgaT0wOw0KCWludCBjaG4sIGNoc24sIHZhbDsNCglkb3VibGUgcDEs cDI7DQoNCgl3aGlsZSAoMSkgeyANCgkJdmFsPWJhbHplcnNfZ2V0X3AoY2hu KTsNCgkJfQ0KCXJldHVybigwKTsNCn0JCQ0KI2RlZmluZSBUUlVFIDENCiNk ZWZpbmUgRkFMU0UgMA0KDQppbnQgbWFpbihpbnQgYXJnYywgY2hhciAqYXJn dltdKSB7DQoJaW50IGk7DQoNCglzaG1pbml0KCk7DQoJYWRjX2luaXQoKTsN CglnZXRfZGF0YV9sb29wKCk7IC8qIHNob3VsZCBsb29wIGZvcmV2ZXIgKi8N CglyZXR1cm4oMCk7DQp9DQo= ---1736217751-826265848-921803012=:644--
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/