http://bugzilla.suse.com/show_bug.cgi?id=1075876 http://bugzilla.suse.com/show_bug.cgi?id=1075876#c8 --- Comment #8 from Benjamin Poirier --- I also started to look at this case. The problem is that tc->cc is null. We have the following disasembly: Upon entering timecounter_read() rdi contains struct timecounter *tc 50 cycle_now = tc->cc->read(tc->cc); 0xffffffff81105096 <+6>: mov (%rdi),%rax offsetof(struct timecounter, cc) = 0 rax contains tc->cc, 0 61 62 return ns_offset; 63 } 64 65 u64 timecounter_read(struct timecounter *tc) 66 { 0xffffffff81105099 <+9>: mov %rdi,%rbx We get the saved value of rdi (tc) in rbx, ffff88025476b7a0 50 cycle_now = tc->cc->read(tc->cc); 0xffffffff8110509c <+12>: mov %rax,%rdi 0xffffffff8110509f <+15>: callq *(%rax) offsetof(struct cyclecounter, read) = 0 This is the null deref (deref of cc), tc->cc->read We already know that cc is null. The crash occurs after 4 hours because of: \ e1000e_ptp_init INIT_DELAYED_WORK schedule_delayed_work(..., 4hours) tc should be initialized by: \ e1000_probe \ e1000e_reset \ e1000e_systim_reset timecounter_init(&adapter->tc, &adapter->cc, ktime_to_ns(ktime_get_real())); This kernel includes a backport of aa524b66c5ef e1000e: don't modify SYSTIM registers during SIOCSHWTSTAMP ioctl (v4.7-rc1) This was backported for SLE12SP3.

From this commit we can see that e1000e_systim_reset() may exit before timecounter_init() if ret_val. Indeed, in the log from comment 4 we see Feb 04 15:49:22 fphnbam3 kernel: e1000e 0000:00:1f.6: Failed to restore TIMINCA clock rate delta: -22 which explains that e1000e_systim_reset() exited early and tc is not initialized.

I'm not sure where the -EINVAL comes from, how come it only occurs sometimes (according to the launchpad report linked to in comment 4) and why it seems this only affects 4.4 stable kernels (I didn't find reports on other versions). -- You are receiving this mail because: You are on the CC list for the bug.