Bug#923346: updates

[Thomas, Paul]

OK, we did find the bug in the macb driver, the main thread on netdev is here:

https://lore.kernel.org/netdev/02874ece860811409154e81da85fbb5892325...@orsmsx121.amr.corp.intel.com/

For future reference, the main issue is that the driver was doing the 
timestamping for all socks, so when a sock had NOT requested 
SOF_TIMESTAMPING_TX_HARDWARE it was getting woken up anyway because the 
timestamp is available in the error queue.

This bug can be closed, I don't know if I need to do anything else?

Thanks,

Paul

-- 
"This e-mail message and any attachments are confidential and may be 
privileged. 
If you are not the intended recipient please notify AMSC 

immediately by replying to this message or by sending a message to 
postmas...@amsc.com 
and destroy all copies of 
this message and any attachments. 
Thank you."

Bug#923346: updates

[IOhannes m zmölnig]

On Thu, 28 Feb 2019 22:18:33 +0100 Tino Mettler 
wrote:
> 
> > Am 27.02.2019 um 22:31 schrieb Paul Thomas :
> > 
> > OK, a couple of updates.
> > 
> > First, I tracked down line ptp4l call that starts this off, it's the
> > ioctl(fd, SIOCSHWTSTAMP, &ifreq); line 88 in sk.c. I can see if a
> > standalone program that just does that ioctl has the same affect.
> > 
> > Second, I was able to reproduce this using the mainline 5.0-rc8 kernel.
> 
> Hi,
> 
> so this looks like a broken driver or buggy hardware and not like an issue 
> with ptp4l, as this ioctl() is a standard call to enable hardware 
> timestamping. Thanks for the analysis. You may get further help on the 
> linuxptp user mailing list.
> 

so if the issue is more likely outside of ptp4l, should we downgrade the
severity? else linuxptp will not be in the next Debian release.
(it will removed from Debian/testing in 10 days from now).

gfmdsf
IOhannes



signature.asc
Description: OpenPGP digital signature

Bug#923346: updates

[Tino Mettler]

> Am 27.02.2019 um 22:31 schrieb Paul Thomas :
> 
> OK, a couple of updates.
> 
> First, I tracked down line ptp4l call that starts this off, it's the
> ioctl(fd, SIOCSHWTSTAMP, &ifreq); line 88 in sk.c. I can see if a
> standalone program that just does that ioctl has the same affect.
> 
> Second, I was able to reproduce this using the mainline 5.0-rc8 kernel.

Hi,

so this looks like a broken driver or buggy hardware and not like an issue with 
ptp4l, as this ioctl() is a standard call to enable hardware timestamping. 
Thanks for the analysis. You may get further help on the linuxptp user mailing 
list.

Regards,
Tino

Bug#923346: updates

[Paul Thomas]

OK, a couple of updates.

First, I tracked down line ptp4l call that starts this off, it's the
ioctl(fd, SIOCSHWTSTAMP, &ifreq); line 88 in sk.c. I can see if a
standalone program that just does that ioctl has the same affect.

Second, I was able to reproduce this using the mainline 5.0-rc8 kernel.

-Paul