When resuming from hibernation via tuxonice suspend-to-RAM via hibernate-script, openntpd keeps logging "sendto: Invalid argument" instead of "reply from <Server IP address>: offset 0.333002 delay 0.032849, next query 6s" messages. The same messages are logged when the network interface is down, but recovers to normal operation when its brought back up. Reproducible: Always Steps to Reproduce: 1. run hibernate-ram 2. resume the system Motherboard: Gigabyte Technology Co., Ltd. Product Name: GA-880GM-D2H Serial Number: BIOS: Award Software International, Inc. Version: F6 Release Date: 08/31/2010 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03) openntpd-20080406-r8 with default ntpd.conf
Created attachment 380128 [details] sys-power/hibernate-script common.conf and tuxonice.conf
This is with the 3.14.7-tuxonice kernel.
Please post your `emerge --info' output in a comment.
Created attachment 380188 [details] emerge --info
I am using openntpd with hibernate from the mainline kernel for years on different machines (2x amd64, 1x x86) without a problem. I guess this issue is tuxonice specific.
Further inspection of older logs reveals that this is reproducible less often than I originally thought. In fact it only happened twice last week. It would be helpful if I could get it to output less cryptic messages. (In reply to Christoph Junghans from comment #5) > I am using openntpd with hibernate from the mainline kernel for years on > different machines (2x amd64, 1x x86) without a problem. > > I guess this issue is tuxonice specific. I always suspend, never hibernate.
(In reply to Dimitri Semitsoglou-Tsiapos from comment #6) > Further inspection of older logs reveals that this is reproducible less > often than I originally thought. In fact it only happened twice last week. > > It would be helpful if I could get it to output less cryptic messages. sendto is called in ntp_msg.c line 75. However it seems that is a system message (see man 2 sendto, search for EINVAL). Maybe there is a check missing for errno==EINVAL. > > (In reply to Christoph Junghans from comment #5) > > I am using openntpd with hibernate from the mainline kernel for years on > > different machines (2x amd64, 1x x86) without a problem. > > > > I guess this issue is tuxonice specific. > I always suspend, never hibernate. Huh, you reported a hibernation problem. (In reply to Dimitri Semitsoglou-Tsiapos from comment #0) > When resuming from hibernation... Anyhow, I use standby half of the time and have never seen this error before. so still seems tuxonice specific to me.
(In reply to Christoph Junghans from comment #7) > > (In reply to Christoph Junghans from comment #5) > > > I am using openntpd with hibernate from the mainline kernel for years on > > > different machines (2x amd64, 1x x86) without a problem. > > > > > > I guess this issue is tuxonice specific. > > I always suspend, never hibernate. > Huh, you reported a hibernation problem. > > (In reply to Dimitri Semitsoglou-Tsiapos from comment #0) > > When resuming from hibernation... Sorry about that. The title of the report is correct, not that line.
Not to minimize a potential bug, but why do you use tuxonice rather than the in-kernel suspend? I've used in-kernel suspend on my notebooks for years with no problems, and I've never seen this ntpd issue. Per the man page: EINVAL Invalid argument passed. It seems tuxonice is breaking either the fd or the struck sockaddr? I dunno. You say it never recovers, you have to completely restart it? I could try reproducing the network interface down failure, but you say that fixes itself when the network comes back up. I don't really think I'll have the time to try and setup a notebook to use tuxonice rather than kernel suspend to reproduce it that way. We could add an exception for EINVAL to match the others like Christoph mentioned, but that would just mean it would be broken forever after a resume but not complain about it 8-/. Again sorry to go kludgy on you ;), but what if you configure tuxonice to shut down ntpd before a suspend and bring it back up after a resume? That would presumably workaround this issue.
(In reply to Paul B. Henson from comment #9) > Not to minimize a potential bug, but why do you use tuxonice rather than the > in-kernel suspend? I've used in-kernel suspend on my notebooks for years > with no problems, and I've never seen this ntpd issue. Per the man page: > > EINVAL Invalid argument passed. I must admit that I have not tested in-kernel suspend much, but tuxonice does very fast IO and I have began to put trust in its integrity checks. Additionaly, only with tuxonice could I get suspend with a ZFS root to work. > It seems tuxonice is breaking either the fd or the struck sockaddr? I dunno. > You say it never recovers, you have to completely restart it? I could try > reproducing the network interface down failure, but you say that fixes > itself when the network comes back up. I don't really think I'll have the > time to try and setup a notebook to use tuxonice rather than kernel suspend > to reproduce it that way. Yes, I had to restart ntpd. > We could add an exception for EINVAL to match the others like Christoph > mentioned, but that would just mean it would be broken forever after a > resume but not complain about it 8-/. > > Again sorry to go kludgy on you ;), but what if you configure tuxonice to > shut down ntpd before a suspend and bring it back up after a resume? That > would presumably workaround this issue. hibernate-script actually stops the network when it begins suspending the system, which in turn stops ntpd. Unfortunately(?) I have not been able to reproduce this bug since I filed this report.
(In reply to Dimitri Semitsoglou-Tsiapos from comment #10) > Unfortunately(?) I have not been able to reproduce this bug since I filed > this report. Re-open when reproducible.
