On Thu, 25 Jun 2015 21:15:18 +0200 "Johannes Bauer" <[email protected]> wrote:
> Hi list, > > I'm seeing a very odd issue with udev and I'm not really sure which > component could/would be responsible -- udev is pretty much my only > hope. > > Here's the situation: I have a USB/serial converter attached to my > computer. It's detected as /dev/ttyUSB0. A program is started as my > local user (UID 1000) and forks into the background. Every now and > then it sends one of four characters to this device and reads a bit > of data back. So far, so good, everything working as expected. > > Now the odd thing: When I put my computer into suspend-to-RAM, I'm > seeing something very odd when the thing wakes back up (about 3 in 4 > times this happens, nondeterministically). The character device > /dev/ttyUSB0 is replaced by a regular file with 0644 permissions which > is owned by root:root: > > joequad joe [~]: ls /dev/ttyUSB0 > -rw-r--r-- 1 root root 1 25.06.2015 18:09:29 /dev/ttyUSB0 > joequad joe [~]: cat /dev/ttyUSB0 | hexdump -C > 00000000 24 |$| > 00000001 > > It's one byte long and this one byte is exactly the data that my > userspace program tried to send. But obviously my user space program > could not have created that node (no permission to write in /dev, > obviously, and my program has no suid or anything, runs just as UID > 1000). > > Here's what dmesg says when suspending/waking up: > > [...] lots of output [...] > [186649.272605] ark3116 ttyUSB0: ark3116 converter now disconnected > from ttyUSB0 > [186649.272619] ark3116 7-2.2:1.0: device disconnected > [186650.452061] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300) > [186650.888603] ACPI Error: [DSSP] Namespace lookup failure, > AE_NOT_FOUND (20131115/psargs-359) > [186650.888605] ACPI Error: Method parse/execution failed > [\_SB_.PCI0.SAT1.SPT2._GTF] (Node ffff880893e1ae38), AE_NOT_FOUND > (20131115/psparse-536) > [186651.030846] ACPI Error: [DSSP] Namespace lookup failure, > AE_NOT_FOUND (20131115/psargs-359) > [186651.030849] ACPI Error: Method parse/execution failed > [\_SB_.PCI0.SAT1.SPT2._GTF] (Node ffff880893e1ae38), AE_NOT_FOUND > (20131115/psparse-536) > [186651.031003] ata7.00: configured for UDMA/133 > [186651.031097] sd 6:0:0:0: [sdc] Starting disk > [186652.988078] ata6: link is slow to respond, please be patient > (ready=0) [186655.676059] ata6: SATA link up 3.0 Gbps (SStatus 123 > SControl 300) [186655.679062] ACPI Error: [DSSP] Namespace lookup > failure, AE_NOT_FOUND (20131115/psargs-359) > [186655.679069] ACPI Error: Method parse/execution failed > [\_SB_.PCI0.SAT1.SPT1._GTF] (Node ffff880893e1adc0), AE_NOT_FOUND > (20131115/psparse-536) > [186655.712350] ACPI Error: [DSSP] Namespace lookup failure, > AE_NOT_FOUND (20131115/psargs-359) > [186655.712356] ACPI Error: Method parse/execution failed > [\_SB_.PCI0.SAT1.SPT1._GTF] (Node ffff880893e1adc0), AE_NOT_FOUND > (20131115/psparse-536) > [186655.712521] ata6.00: configured for UDMA/133 > [186655.712640] sd 5:0:0:0: [sdb] Starting disk > [186655.720875] PM: resume of devices complete after 8128.520 msecs > [186655.720895] ark3116 7-2.2:1.0: ark3116 converter detected > [186655.721740] usb 7-2.2: ark3116 using RS232 mode > [186655.721822] usb 7-2.2: ark3116 converter now attached to ttyUSB0 > [186655.722165] PM: Finishing wakeup. > > My userspace program happens to hang in a call to write(2) when the PC > is put in suspend. The write returns with errno = 5 (I/O error) when > the PC comes back up. > > Another clue is here: I've seen this issue with my old (much slower > PC) before. But it happened very sporadically, about once every 30 > suspend/wakeup-cycles. I thought this was odd, but blamed some weird > random component to do this. Now I've switched to a much faster > computer and am seeing this issue in around 75% of all > suspend/wakeup-cycles and it's really annoying the hell out of me. So > I'm guessing there's some kind of race condition involved which hits > much more often now that my PC is fast enough. > > Oh, I'm running Linux Mint on x86_64. udev is version 204. > > If you have any hints whatsoever on how I could debug this really > weird issue, please let me know. I really just don't have a clue how > to debug udev/this weird phaenomenon. > Don't think udev is creating those char devices in such a new version. I think is handled by the kernel. I've seen such a bug once, but it was related to /dev/null, some script or app was remove /dev/null and creating a normal file, don't know why. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
