Date: Mon, 24 Nov 2014 16:22:23 -0700 From: Warner Losh <imp@bsdimp.com> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: arch@freebsd.org, Ian Lepore <ian@FreeBSD.org>, Mark R V Murray <mark@grondar.org> Subject: Re: svn commit: r274739 - head/sys/mips/conf Message-ID: <4C2BD093-BEA2-47F9-B575-90342712E9B2@bsdimp.com> In-Reply-To: <86wq6k9okk.fsf@nine.des.no> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <AE8F2D30-7F91-4C90-B79A-D99857D8AED8@grondar.org> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <F017033A-B761-4435-A7F8-264D2F4662A0@grondar.org> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <CC6B67E1-55A2-4952-AB43-5F6C787F629B@grondar.org> <86wq6k9okk.fsf@nine.des.no>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] > On Nov 24, 2014, at 4:16 PM, Dag-Erling Smørgrav <des@des.no> wrote: > > Mark R V Murray <mark@grondar.org> writes: > >>> On 24 Nov 2014, at 15:01, Ian Lepore <ian@FreeBSD.org> wrote: >>> >>> >>> The logging change was pretty simple: >>> >>> Index: kern/subr_bus.c >> >> Thanks. >> >>> The low number of devices is pretty typical. Sometimes there'll be >>> another uart. Sometimes an i2c eeprom. >> >> OK - a good example of a low-entropy system then. >> >>> I have no idea what's up with the first 3 unchanging numbers, but I >>> suspect a big part of the explanation for the other numbers is the 32KHz >>> clock it's getting the numbers from. There used to be a clock running >>> at about 2.8MHz, but the source code for that driver seems to have >>> disappeared from FreeBSD at some point between 8.x and -current. >> >> What really bothers me is that these should be the difference between >> 2 essentially similar numbers; times not all that far apart, yet some >> of the numbers are truly massive. > > They're not just massive, they're preposterous, as is the fact that most > of them are absolutely identical, or just one bit off, from one run to > the next. My best guess is that get_cyclecount() is broken. What’s the minimum specs required for get_cyclecount()? Not all of the boxes that Ian was posting about have high-resolution time-keeping counters in hardware… Maybe there’s some underlying expectation for this function that these systems either aren’t providing or can’t provide. Warner [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUc72wAAoJEGwc0Sh9sBEAeE8P/ibUhZZbEF1MhrNTZ0YbuDvf kLlRnnjz+UKUMSN9cQZQD2m+L1Y+rmHV7BLdcAFH2CiRF2pBXvkM/gnR8CWLSulC mFSyLWE77k56ko2cEOX/xTyyKV9laZGABtwts78GxXFAIhbvW1pqvqMGWMGJwZ4W Q6F6dr8PRCBCIKclK1jz1uV/3wRVPSxORRvmeL6N8deyeWtTE6G1qpAOlrk6A/DU aneDmOxZ48WVUie2u8NVPoGxLirTNK9kV/QojmYU93nWY2Jh+kLWy+2w6xd1wP/N G2kuCD8hxoQA6yRdov2KlvamSzeIgvmkPQCzN+WMWm5/bk0LbA5bEsjGAWtNm9BN cdEP3RjOBFmnSX5Sqq9Yrys0gaIVFvGzrG2v4IoZYvpgdB/Bg+y7IZ71hYPqfLWq Ck0ZbFY8rQavds7ZyxShbVrWGYnBWsmUAtmoWCMQCxgvWIl+ebSx5O5qg7b8h1fg Uqc2rPx7oEV1At2NyPut5a691tNMdlOQG9TUo0tAq4ptBKJMhXeH84JR8E3621IM /6qz9GqfNPmdg8v4IV7GtfPY+tQaaRIGsknsZWeyI0zvLBlR6B5JBOAYz7Nr+hYs ukAQvYl8G2IdQsZQqo6ZYfo78dSMTWf25Y+YEzabEnpNtz1BQ7YABTDERBxV10tm no5xGOcsGB1lq2stdg+A =9can -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C2BD093-BEA2-47F9-B575-90342712E9B2>