xntpd - VERY old folks, how about updating? :-)
This is not a port, its part of the RELEASE! Its several YEARS old, and doesn't work right - you get lots of STEP changes instead of what you SHOULD get, which is a slew on the system clock. The new code (which has a current release date of this month) DOES appear to work correctly (I'm still verifying it, but it's certainly better than what is in the tree right now!) What does (someone) need to do to get this changed out/updated? I can't send it in as a port, since its part of the base package (setting it up as a port would be pretty trivial from what I can see) -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sat, Jan 01, 2000 at 09:33:31AM -0800, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Karl Denninger <[EMAIL PROTECTED]> wrote:
> >
> > What does (someone) need to do to get this changed out/updated? I can't
> > send it in as a port, since its part of the base package (setting
> > it up as a port would be pretty trivial from what I can see)
>
> There already _is_ a port of it (net/ntp). And there are hooks in
> /etc/rc.conf ("xntpd_program") to use the ports version instead of the
> one in the base system.
>
> John
Thanks; I just updated /usr/src and saw the changes.
This has been broken for a *long* time - at least since the 4.0 branch
began. Its definitely a kernel interface problem with the older code;
while the adjtime call is being made its not happening and eventually
the code executes a "step" instead (which is a bad news; those should
basically never happen once xntpd settles down in a day or three after
a cold start)
It looks like ntpd (the new one) works correctly; I grabbed the latest
from the official site last night and by this morning the dispersion
and offsets were stable.
Ntpd is the "official" code line now - the "x" line is considered deprecated
by the official maintainers, so if you're going to support the ntpd line in
the base system the other(s) should probably be removed entirely.
--
--
Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org
Isn't it time we started putting KIDS first? See the above URL for
a plan to do exactly that!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sat, Jan 01, 2000 at 11:11:51AM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Karl Denninger writes: > > >This is not a port, its part of the RELEASE! > > > >Its several YEARS old, and doesn't work right - you get lots of STEP changes > >instead of what you SHOULD get, which is a slew on the system clock. > > Remember to get the kernel code involved. To do this: > > create a driftfile containing "0 1\n" > start xntpd > > That will help. No it won't. I've been running xntpd for oh, four or five years now on various things. Yes, the drift file is there (and has been). Still got the step time messages. > The new ntpd is in -CURRENT. Ok. I built it as a local binary and install THAT, and the problem disappeared, so I assume the old "included" one had some kind of problem. Oh, BTW, Mutt is Y2K complient. I get no "odd" time displays with messages I send myself :-) -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 01:17:15AM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, John Polstra writes: > >In article <[EMAIL PROTECTED]>, > >Karl Denninger <[EMAIL PROTECTED]> wrote: > >> > >> It looks like ntpd (the new one) works correctly; I grabbed the latest > >> from the official site last night and by this morning the dispersion > >> and offsets were stable. > > > >BTW, you might want to add these lines (from LINT) to your kernel > >config if you haven't already: > > > ># > ># POSIX P1003.1B > > > ># Real time extensions added int the 1993 Posix > ># P1003_1B: Infrastructure > ># _KPOSIX_PRIORITY_SCHEDULING: Build in _POSIX_PRIORITY_SCHEDULING > ># _KPOSIX_VERSION: Version kernel is built for > > > >options "P1003_1B" > >options "_KPOSIX_PRIORITY_SCHEDULING" > >options "_KPOSIX_VERSION=199309L" > > > >Current versions of ntpd use these features if they're available. I > >think "_KPOSIX_VERSION=199309L" is the default, so that one probably > >isn't strictly necessary. > > I seriously doubt using these will do anything for NTPDs performance. It won't, but it will stop ntpd from bitching in the syslog about them being missing :-) - Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 01:15:13AM +0100, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Karl Denninger writes:
> >On Sat, Jan 01, 2000 at 11:11:51AM +0100, Poul-Henning Kamp wrote:
> >> In message <[EMAIL PROTECTED]>, Karl Denninger writes:
> >>
> >> >This is not a port, its part of the RELEASE!
> >> >
> >> >Its several YEARS old, and doesn't work right - you get lots of STEP changes
> >> >instead of what you SHOULD get, which is a slew on the system clock.
> >>
> >> Remember to get the kernel code involved. To do this:
> >>
> >>create a driftfile containing "0 1\n"
> >>start xntpd
> >>
> >> That will help.
> >
> >No it won't. I've been running xntpd for oh, four or five years now on
> >various things. Yes, the drift file is there (and has been). Still got the
> >step time messages.
>
> Uhm, Karl, please try to calm down, OK ?
>
> I didn't talk about having a driftfile, I talked about using the kernel
> PLL: ("Remember to get the kernel code involved.")
>
> With xntpd the kernel-pll is very optional, in fact only the source tells
> you that the magic secret second field in your driftfile controls if
> the kernel-PLL should be used or not.
Yes, and my driftfile had that parameter in there. Uhm, Poul, remember I've
been at this for just a LITTLE while. Xntpd is something I had deployed
back in my *Sun* days (back when FreeBSD was, well, non-existent)
> Anyway, ntpd4 is in CURRENT...
Now it is.
And it works correctly too.
Thanks anyway, even with the attitude.
--
--
Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org
Isn't it time we started putting KIDS first? See the above URL for
a plan to do exactly that!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 01:31:25AM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Karl Denninger writes: > > >Yes, and my driftfile had that parameter in there. Uhm, Poul, remember I've > >been at this for just a LITTLE while. Xntpd is something I had deployed > >back in my *Sun* days (back when FreeBSD was, well, non-existent) > > Karl, remember who was there too ? :-) > > >> Anyway, ntpd4 is in CURRENT... > > > >Now it is. > > > >And it works correctly too. > > In general yes, but not if you use the hardpps() with a refclock, > it works better after I fixed a couple of almost-mutually-canceling > sign-bugs, but the parameters of the hardpps() PLL relative to the > FLL are wrong. You're still a bunch of revs back - the current is either "h" or "i", and it has a bunch of fixes (including one here, I think) > >Thanks anyway, even with the attitude. > > Many happy returns :-) Thy be welcome. -- Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 01:41:08AM +0100, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, "Rodney W. Grimes" writes
> :
>
> >Does it help in the 3.4-stable version to set the second value in ntpdrift
> >to 1?
>
> Yes, although I have never checked all the boundary conditions
> to make sure the kernel-pll is stable over the entire envelope.
>
> I'm doing that for the NTPv4/nanokernel combo, and I'm resolving
> the problems I find with Dave Mills.
>
> >And why has the manual page never been updated, it is clearly wrong
> >when it talks about the contents of driftfile! :-(
>
> I updated neither the manpage nor the code because of the above.
>
> >> Anyway, ntpd4 is in CURRENT...
> >
> >Well... that won't help the 20 or so boxes here doing this all the
> >time:
> >Jan 1 11:26:46 gndrsh xntpd[133]: time reset (step) -0.217546 s
> >Jan 1 11:32:06 gndrsh xntpd[133]: time reset (step) 0.207523 s
>
> (-0.217546 - 0.207523) / (14 + 5 * 60 + 6) = -.001328340
>
> Your clock is too sick, (or our calibration of it is hosed), no
> version of {X}NTP will touch a clock which is outside +/- 500ppm.
>
> Could you try to measure the 14.31818... MHz base frequency and
> the 32768 kHz wristwatch xtal as well (I know you're RadioActive,
> so I pressume you have a counter ?)
>
> If they're both OK, then we have a code problem...
You have a code problem ;-)
I can confirm this behavior; its been consistent with xntpd for a LONG time,
which is why I raised the issue (it FINALLY got to the top of my "annoyance"
list).
--
--
Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org
Isn't it time we started putting KIDS first? See the above URL for
a plan to do exactly that!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 12:20:35PM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Karl Denninger writes: > > >> >> Anyway, ntpd4 is in CURRENT... > >> > > >> >Now it is. > >> > > >> >And it works correctly too. > >> > >> In general yes, but not if you use the hardpps() with a refclock, > >> it works better after I fixed a couple of almost-mutually-canceling > >> sign-bugs, but the parameters of the hardpps() PLL relative to the > >> FLL are wrong. > > > >You're still a bunch of revs back - the current is either "h" or "i", and it > >has a bunch of fixes (including one here, I think) > > No, the NTP distribution doesn't contain the kernel code, it only interfaces > to it. Well yes you're saying that the bug was *in* the kernel and not ntpd then? Ok.. > I'm sure Ollivier will upgrade us every so often now :-) No problem. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 12:22:38PM +0100, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Karl Denninger writes:
>
> >> >Well... that won't help the 20 or so boxes here doing this all the
> >> >time:
> >> >Jan 1 11:26:46 gndrsh xntpd[133]: time reset (step) -0.217546 s
> >> >Jan 1 11:32:06 gndrsh xntpd[133]: time reset (step) 0.207523 s
> >>
> >>(-0.217546 - 0.207523) / (14 + 5 * 60 + 6) = -.001328340
> >>
> >> Your clock is too sick, (or our calibration of it is hosed), no
> >> version of {X}NTP will touch a clock which is outside +/- 500ppm.
> >>
> >> Could you try to measure the 14.31818... MHz base frequency and
> >> the 32768 kHz wristwatch xtal as well (I know you're RadioActive,
> >> so I pressume you have a counter ?)
> >>
> >> If they're both OK, then we have a code problem...
> >
> >You have a code problem ;-)
>
> If you have access to a frequency counter, could you try to make the
> same measurements please ?
I don't have one handy, BUT I saw this SAME problem across oh, 20 machines.
Every one. Every time.
And oh, by the way, when one of them (mine) was upgraded to the newest ntpd,
it *WENT AWAY*. Thus, I think its quite reasonable to say its not the clock
and must be the code (since the hardware could not have magically changed
:-)
> Do you have any refclocks we can use to measure against ?
Had one at MCS (Spectracom WWV receiver), but its there and I'm here. It
appears from their strata change (from 1 to 2; I chime off them) that they
turned it off. I should have taken it with me when I left :-)
BTW, speaking of which, does anyone know of a reasonably-cheap GPS receiver
that (1) has an external-able antenna that will work with somewhere between
50 and 100 feet of lead, and (2) has the appropriate pps outputs and such
so it can be used for this?
--
--
Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org
Isn't it time we started putting KIDS first? See the above URL for
a plan to do exactly that!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 04:55:44PM +0100, Poul-Henning Kamp wrote: > > >BTW, speaking of which, does anyone know of a reasonably-cheap GPS receiver > >that (1) has an external-able antenna that will work with somewhere between > >50 and 100 feet of lead, and (2) has the appropriate pps outputs and such > >so it can be used for this? > > I will (as always) recommend the Motorola Oncore UT+. If you buy it > from syngergy-gps it comes mounted in their nice box and the cable > has the PPS on DCD and is ready to plug into a serial port. I paid > $605.73 for the one I'm delivering to the Danish Internet eXchange > point, that included antenna and 15m of cable. That's EXPENSIVE. Common handheld GPS units with NEMA outputs on them are well under $200 these days! -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
That sucks severely - NONE of the common units have the PPS output?! Barf. Oh well. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! On Sun, Jan 02, 2000 at 05:42:24PM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Karl Denninger writes: > >On Sun, Jan 02, 2000 at 04:55:44PM +0100, Poul-Henning Kamp wrote: > >> > >> >BTW, speaking of which, does anyone know of a reasonably-cheap GPS receiver > >> >that (1) has an external-able antenna that will work with somewhere between > >> >50 and 100 feet of lead, and (2) has the appropriate pps outputs and such > >> >so it can be used for this? > >> > >> I will (as always) recommend the Motorola Oncore UT+. If you buy it > >> from syngergy-gps it comes mounted in their nice box and the cable > >> has the PPS on DCD and is ready to plug into a serial port. I paid > >> $605.73 for the one I'm delivering to the Danish Internet eXchange > >> point, that included antenna and 15m of cable. > > > >That's EXPENSIVE. > > > >Common handheld GPS units with NEMA outputs on them are well under $200 > >these days! > > Common handheld GPS units are pointless as NTP refclocks because they > lack (a decent) PPS output. > > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 02:33:35PM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Karl Denninger writes: > : That's EXPENSIVE. > > Worth every penny. We've seen sub-micro second syncronization with > our unit on good hardware, and 1-2us on the 486 based hardware. > > : Common handheld GPS units with NEMA outputs on them are well under $200 > : these days! > > NEMA gives you only millisecond accuracy, if you are lucky. > > Warner Why spend twice what Mr. Schwartz seems to want to charge? For the Motorola name? Sorry, the Batwing Menace to employee's rights was long ago placed on my "do not buy, do not recommend, actively boycott" list. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 03:32:00PM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Karl Denninger writes: > : Why spend twice what Mr. Schwartz seems to want to charge? > > Because we need a PPS that is < 10nS from the true start of second for > our application? 1uS is really really bad for the timing geeks in the > audience. > > Warner And on what hardware do you think you can obtain 10ns resolution RELIABLY at the software level in the Unix environment and under FreeBSD? Answer: NONE! The actual usable resolution of a timing source is determined by the maximum slop in ANY part of the complete system. I challenge you to get actual REPEATABLE 10ns results while a multi-tasking anything is running on the recipient of that data. - -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 11:17:00PM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Karl Denninger writes: > > > >Why spend twice what Mr. Schwartz seems to want to charge? > > > >For the Motorola name? Sorry, the Batwing Menace to employee's rights was > >long ago placed on my "do not buy, do not recommend, actively boycott" list. > > Well, suit your own political manifests as you will, but the Motorola > unit is the best time receiver you can buy for humane amounts of money. > > You can see some of my measurements at http://phk.freebsd.dk Yeah, so what? Your system can't resolve events to that degree of accuracy, so the ability of the receiver to deliver them is irrelavent. More geek nonsense - about what I expected. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 03:42:24PM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Karl Denninger writes: > : And on what hardware do you think you can obtain 10ns resolution RELIABLY > : at the software level in the Unix environment and under FreeBSD? > : > : Answer: NONE! > > WRONG. > > : The actual usable resolution of a timing source is determined by the > : maximum slop in ANY part of the complete system. > : > : I challenge you to get actual REPEATABLE 10ns results while a multi-tasking > : anything is running on the recipient of that data. > > We have hardware timers that let us get into the pico second range on > a regular basis. > > Warner Yes, you have HARDWARE timers that do that. So what? I'm talking about TIME SERVERS on UNIX machines. You know, ntpd and friends? Yes, that. Now explain to me how stability of your timing source ON THOSE MACHINES is MATERIALLY different to any process WHICH THAT DEVICE MAY INTERACT WITH between 10ns and 1us, AS SEEN FROM THE UNIX MACHINE. I'm simply not interested in NON-GERMANE devices to the discussion; we were talking about FreeBSD on REAL computers, not specialty hardware for process control or nuclear physics experiments. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 11:49:08PM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Karl Denninger writes: > >On Sun, Jan 02, 2000 at 11:17:00PM +0100, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, Karl Denninger writes: > >> > >> >Why spend twice what Mr. Schwartz seems to want to charge? > >> > >> Well, suit your own political manifests as you will, but the Motorola > >> unit is the best time receiver you can buy for humane amounts of money. > >> > >> You can see some of my measurements at http://phk.freebsd.dk > > > >Yeah, so what? > > > >Your system can't resolve events to that degree of accuracy, so the ability > >of the receiver to deliver them is irrelavent. > > Karl, > > In fact I *do* have a computer that can resolve events to +/- 10nsec > (http://gps.freebsd.dk) so I need it. In fact that machine is > probably one of the best NTP servers in the entire world right now. > > >More geek nonsense - about what I expected. > > Call it "geek nonsense" if you want to. Warner is employed by the > company that builds the stuff which figures out what time it is > for NIST and although my professional affiliation isn't anywhere > near that level, I can claim to be the first person to truly split > the microsecond with a standard UNIX box. > > > Listen, it is really too bad that you didn't get that pony for > X-mas, and I can understand you why you are disappointed about it, > but when do you plan to stop being grumpy about it ? :-) > > If you intend to keep up this "sour grapes" attitude, despite all > the helpful answers you have gotten so far, you should consider > stopping before you have worn out your welcome. > > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! Go fuck yourself Poul. Yes, the "F-word". You have no ability to determine "my welcome". -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 03:50:35PM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Karl Denninger writes: > : Yes, you have HARDWARE timers that do that. > : > : So what? > : > : I'm talking about TIME SERVERS on UNIX machines. > > So am I. > > : You know, ntpd and friends? Yes, that. > > That's one of the things in our application. So what? > : Now explain to me how stability of your timing source ON THOSE MACHINES > : is MATERIALLY different to any process WHICH THAT DEVICE MAY INTERACT WITH > : between 10ns and 1us, AS SEEN FROM THE UNIX MACHINE. > > It is better because the variance in the measurements that we make is > much smaller than 1uS would give. Not possible without custom hardware. The inherent uncertainty in a PPS interface delivered through a parallel port in the interrupt context of a common grade-processor is greater than picosecond claims. Now the *integration* of many of these signals may not be, but the point still holds. That you FLUNKED your first science course where the uncertainty of measurements was discussed, and the boundaries on certainty were laid out, does not change those FACTS. You CANNOT declare a measurement (no matter what it is) to be more precise than the sum of ALL uncertainties in the measurement domain. This is a material FACT, and no amount of posturing changes it. PAYING for precision in a measurement source that is a few orders of magnitude beyond the response windows of what it is connected to is *STUPID*. This includes your claim of anything approaching 10ns resolution on consumer-grade computer hardware. > : I'm simply not interested in NON-GERMANE devices to the discussion; we were > : talking about FreeBSD on REAL computers, not specialty hardware for process > : control or nuclear physics experiments. > > Get a life Karl. I was telling you about my experiences and if you > don't like it, take a chill pill or go play in traffic. > > Warner Go stick your finger in a 220V socket, or sit on whatever Poul uses to do what I asked HIM to do just a few minutes ago. Perhaps that would reduce the population of this group by two people who don't deserve the term "scientist" applied to them. Scientists. BAH! You'd have to flunk first-semester physical science courses to not understand how the boundaries of uncertainty in measurements work, and why buying a reference source that is more precise than the LEAST PRECISE element in your entire measurement chain is almost always a COMPLETE waste of money. If you have two elements in a measurement chain, and one has 10ns repeatability and the other has 10us repeatability, the measurement you obtain is FOR ALL INTENTS AND PURPOSES equivalent to the 10us one. Even if the OTHER timebase is only accurate to 10us, the TOTAL inaccuracy is 20us MAXIMUM. What, Warner, is the INTERRUPT LATENCY (including processing time) specification on a Pentium? You know, the amount of time the chip requires to (1) recognize the INTERRUPT being dragged, (2) save the current context, (3) switch to the interrupt context, and (4) execute the FIRST instructions in that context. Now add to that the ACTUAL gate delays for ALL the gates between your piece of wire and the processor. Then tell me that this sums to ~10ns. You're smoking hard drugs - the processor cannot respond to the interrupt until (potentially) a multi-cycle instruction has been COMPLETED. Further, the act of responding itself requires several MORE cycles, as does the physical act (in the interrupt context) of reading the input latch. In fact, for an ISA parallel port, the speed involved in reading that latch is limited by ISA bus speed! Be careful with the pontification here Warner - some of us actually HAVE done hard real-time work and some of us also know a bit about how MPUs REALLY work in the REAL world. Posturing does NOT work with me on topics like this. You ain't getting no 10ns resolution off any production FreeBSD box without specialized timekeeping hardware that READS the pps output and has its OWN high-precision clock so it can tell the processor how many ticks elapsed from the time IT saw the PPS output until the processor got around to reading the latch. No way in hell. You want to claim otherwise? Fine - show me a gate analysis on the port you connect that clock to (from the wire to the processor's INTERRUPT pin), along with a gate propagation analysis on the processor and the execution path it must take, both worst and best case, from receipt of a signal on the interrupt pin until the FIRST instruction in the handler is executed. Have fun. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 03:13:10PM -0800, David O'Brien wrote: > On Sun, Jan 02, 2000 at 04:53:55PM -0600, Karl Denninger wrote: > > On Sun, Jan 02, 2000 at 11:49:08PM +0100, Poul-Henning Kamp wrote: > ..snip.. > > > If you intend to keep up this "sour grapes" attitude, despite all > > > the helpful answers you have gotten so far, you should consider > > > stopping before you have worn out your welcome. > > > > Go fuck yourself Poul. > > > > Yes, the "F-word". > > You have no ability to determine "my welcome". > > Karl you are one fscking asshole. As a member of this list, you *HAVE* > worn out your welcome in my inbox. So what? > You asked Poul-Henning about *good* timekeeping HW. He told you. $600 > isn't that much for computer server related hardware. Warner seconded > the recommendation. So what? > You pay less, you don't get the best. Its up to you to weigh your needs > vs. what you are willing to pay. Shilling for a difference that is irrelavent is horseshit. It amounts to lying. Statistically these two time sources are almost EXACTLY equivalent. > And you want to bitch?? What is your fscking problem? Its a bullshit argument David and is nothing other than BLATENT shilling for Motorola - at someone else's expense! Without a specialized board that counts these nanosecond ticks from the time it gets the PPS signal to the time the latch is read this kind of accuracy claim is worth exactly NOTHING. WITHOUT it, which is EXACTLY what REAL WORLD use of these devices is going to be running under, the impact is ZERO. Further, the ACTUAL impact in the real world of time stability to the dozen-nanosecond-range is ALSO zero, with the possible exception of physical control processes in the nuclear research field (such applications are NOT running on "standard" Unix machines!) Finally, in the world of sync'ing time between systems (say, in a multiple server cluster) that kind of precision is ALSO worth ZERO! NOBODY with off-the-shelf hardware can obtain repeatable 10ns results from a standard Unix machine. NOBODY. And THAT is a fact, easily determined through nothing more than Intel's databooks on their processors and the interrupt response time they exhibit. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 06:17:59PM -0500, Chuck Robey wrote: > On Sun, 2 Jan 2000, Karl Denninger wrote: > > > > If you intend to keep up this "sour grapes" attitude, despite all > > > the helpful answers you have gotten so far, you should consider > > > stopping before you have worn out your welcome. > > > > > > -- > > > Poul-Henning Kamp FreeBSD coreteam member > > > > > > > > Yes, the "F-word". > > > > You have no ability to determine "my welcome". > > Karl, you've now managed to irritate a lot of folks. Jumping on Steve, > who is normally a huge worker, and totally inoffensive, was really pushing > things, but then jumping on Poul, who is somewhat easier to touch off, > well, you have been just about advertising "I want a fight!", although no > one's really given you much reason for it. > > Poul's response was right, you should come back in a few days, when you've > had time to cool off. No one else really wants to keep the fight going. I don't give a shit what Poul wants - or what you want. Corporate shilling does NOT go past me without a response, and Paol is completely full of shit in the context (time servers used by HUMANS for ORDINARY uses) that we were discussing at the time. Sticking custom PCI boards into a PC that count nanosecond-level clock transitions before the processor can get around to reading the input latch (at a cost of several hundred dollars MORE as a one-off science project) *DOES NOT COUNT*. Since I see the FreeBSD "treehouse" mentality hasn't changed, I guess my ORIGINAL assessment was correct. Duplicity and bullshit still rule the roost, just as they did a couple of years ago. Why the hell Walnut Creek wastes their money on your type REMAINS beyond my comprehension. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 03:05:49PM -0800, David Schwartz wrote: > > > Now explain to me how stability of your timing source ON THOSE MACHINES > > is MATERIALLY different to any process WHICH THAT DEVICE MAY INTERACT WITH > > between 10ns and 1us, AS SEEN FROM THE UNIX MACHINE. > > A battle you would win is if you said, "synchronizing the time of other > UNIX machines without specialized hardware over a LAN or WAN". :) Of course, which is my point. > You can see 2 microsecond differences inside a single machine with no > specialized hardware. MICROseconds. *NOT* NANOseconds, which is what Paol was claiming! > You can see 5 microseconds over a good LAN. For > example, youknow.youwant.to is synchronized to both tick.gpsclock.com and > tock.gpsclock.com through a full-duplex 100Mbps LAN switch. Watch this: > > > ntpdate -q -p 8 209.133.29.16 209.133.29.20 > server 209.133.29.16, stratum 1, offset -0.000298, delay 0.02579 > server 209.133.29.20, stratum 1, offset -0.000302, delay 0.02579 > 2 Jan 15:01:01 ntpdate[2491]: adjust time server 209.133.29.20 > offset -0.000302 sec > > Note that it claims that Tick and Tock agree with each other to 5 > microseconds. But it has been unable to keep its own time to any better than > 300 microseconds (it's been under heavy load, swapping in fact). Correct. And the issue there is that its the COMPLETE timekeeping environment, not some bullshit-manufacturered claim of 10ns time stability that is CLEARLY bogus. As soon as you put a REAL workload on the machine(s) involved interrupt latency starts to cause trouble. Hell, just READING THE FRIGGING PORT to SEE the PPS output involves interrupt latency which is INDETERMINATE beyond a LOT more elapsed time than 10ns! > In actual reality, the GPSClock 200 is better than the specifications > indicate. If it really did alternate between 1us early pulses and 1us late > pulses, stability would be measurably impacted. NTP is very good at > smoothing things out anyway, especially since it only probes the clock every > 64 seconds or so. > > David Schwartz > http://www.gpsclock.com/ Yep. My entire point, David, is that there is ZERO actual, real-world difference between your reasonably-priced receiver and the shilled-for Motorola receiver that Poul and others like to promote at twice the price. Now if you're willing to stuff a custom PCI board (that in and of itself probably violates all manner of FCC regulations in terms of emissions) to keep nanosecond-level track of the number of "ticks" between seeing a PPS signal and the processor getting around to reading the latch, then Poul and the shills might be right on a TECHNICAL level - as long as they never actually USE that computer for anything, never access a disk, and never hit any other I/O port. But that's not the real world, its not a real application, and geeking-up something just to prove you can (while probably breaking the law in terms of emissions - the clock rates to get nanosecond timing accuracy are non-trivial, and that board would need FCC appoval here in the states) doesn't count. It also has ZERO relavence to those of us who want to keep time on our networks. It is precisely this kind of elitism and bullshit that I continually run into when trying to deal with the "treehouse" FreeBSD kids, and in this particular instance its so blatent that I simply refuse to shut up about it. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 06:31:22PM -0500, Bill Fumerola wrote: > On Sun, 2 Jan 2000, Karl Denninger wrote: > > > Why the hell Walnut Creek wastes their money on your type REMAINS beyond > > my comprehension. > > It really hasn't been a problem for anyone but you. It's more successful, > then say, alternative top level domain projects that have gone nowhere. > > -- > - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - > - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - Really? How many millions does Paol have to count in HIS bank as a result of this shilling and "advocacy"? SOME OF US have *REAL* successes to point to - not just bullshit pats on the back. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 06:37:31PM -0500, Bill Fumerola wrote:
> On Sun, 2 Jan 2000, Karl Denninger wrote:
>
> > How many millions does Paol have to count in HIS bank as a result of this
> > shilling and "advocacy"?
> >
> > SOME OF US have *REAL* successes to point to - not just bullshit pats on the
> > back.
>
> Like eDNS, right?
>
> --
> - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp -
> - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] -
>
>
> PS. Some of us aren't in it for the money.
No, you're in it to pat yourself on the back and play "treehouse".
We can point to the Internet's evolution of these "treehouse" organizations
and show off how PROUD we are of them and those who support them.
Let's start a nice short list, shall we?
Network Solutions.
ARIN.
FreeBSD-CORE.
Shall I keep going?
.At least the folks in it for the money are honest - you know exactly
what their goals are. With the rest you have real trouble figuring
out exactly what REALLY drives them.
I prefer my cards face up, thank you very much.
--
--
Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org
Isn't it time we started putting KIDS first? See the above URL for
a plan to do exactly that!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
[Majordomo@FreeBSD.ORG: Majordomo results: which]
Oh, so the treehouse maggots continue to fester, eh? Nice move shitheads. Do you intend to continue? Consider this forwarded to Steve, a withdrawal of my port, and notice of my intent to post it along with a transcript on my web page for HomeDaemon. Who is the two-bit-peckerhead who removed my subscription to several of the lists? -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! - Forwarded message from [EMAIL PROTECTED] - To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: Majordomo results: which Reply-To: [EMAIL PROTECTED] Date: Sun, 2 Jan 2000 15:52:37 -0800 (PST) -- >>>> which denninger.net NOTE: the "which" command does not show subscriptions to either freebsd-arch or freebsd-security-notifications The string 'denninger.net' appears in the following entries in lists served by [EMAIL PROTECTED]: ListAddress === freebsd-hackers [EMAIL PROTECTED] freebsd-ports [EMAIL PROTECTED] freebsd-scsi[EMAIL PROTECTED] freebsd-security[EMAIL PROTECTED] >>>> - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 04:58:57PM -0700, Warner Losh wrote: > Karl, I was my hands of this conversation. You aren't listening. > > We have custom hardware. We're a control and measurement system. The > <10ns is needed for that control and measurement part. The sync we > get of the system clock, like I said before, is on the order of a few > hundred ns on pentium hardware and a few us on 486 hardware. > > That's why we spend more $$ on the hardware. If you don't like it, > forget the chill pill and just play in traffic. > > I'm done with this conversation. > > Warner That's fine Warner, but isn't germane to the point. Poul claimed that his favorite device was *superior* in *ordinary* use. Then he admitted that he needed custom hardware (as you do as well) to get that kind of accuracy. Recommending something that is twice as expensive for people trying to keep network time when the INHERENT stability of the system clock is at least a couple orders of magnitude worse than the proclaimed PPS stability is just flat STUPID. Maintaining and defending that position when it is pointed out in bold letters that the uncertainty on the system clock and interrupt latency is FAR greater than the claimed 10ns resolution has only three possible explainations: 1. The poster has an interest in the device being shilled for. 2. The poster has an IQ below that of tap water's temperature in Celcius. 3. The poster has never in their life had to specify an uncertainty with a measurement, which in and of itself disqualifies them for the discussion at hand. As for whoever the person is who force-removed me from the list, trust me on this - I won't forget that act, and until you're identified and permanently removed from both the list and the entire project you'll have no contributions from me to your little treehouse project in any way, shape or form. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Majordomo@FreeBSD.ORG: Majordomo results: which]
Uh, Matthew, I have the system logs here. I'm root. There was no bounce. And yes, I do know how SMTP works too. Nice try though. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! On Sun, Jan 02, 2000 at 04:05:22PM -0800, Matthew Jacob wrote: > > Uh, Karl, sometimes majordomo will get rampant and pull one w/o warning if > there was a mail bounce. > > It may be a stupid mail robot problem, not a human out to get you. If so, > you've directed your vituperation at the wrong ip address/port combo- try > port 9 instead of port 25. > > On Sun, 2 Jan 2000, Karl Denninger wrote: > > > Oh, so the treehouse maggots continue to fester, eh? > > > > Nice move shitheads. > > > > Do you intend to continue? > > > > Consider this forwarded to Steve, a withdrawal of my port, and notice of my > > intent to post it along with a transcript on my web page for HomeDaemon. > > > > Who is the two-bit-peckerhead who removed my subscription to several of > > the lists? > > > > -- > > -- > > Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org > > Isn't it time we started putting KIDS first? See the above URL for > > a plan to do exactly that! > > > > > > - Forwarded message from [EMAIL PROTECTED] - > > > > To: [EMAIL PROTECTED] > > From: [EMAIL PROTECTED] > > Subject: Majordomo results: which > > Reply-To: [EMAIL PROTECTED] > > Date: Sun, 2 Jan 2000 15:52:37 -0800 (PST) > > > > -- > > > > >>>> which denninger.net > > > > > > NOTE: the "which" command does not show subscriptions > >to either freebsd-arch or freebsd-security-notifications > > > > > > The string 'denninger.net' appears in the following > > entries in lists served by [EMAIL PROTECTED]: > > > > ListAddress > > === > > freebsd-hackers [EMAIL PROTECTED] > > freebsd-ports [EMAIL PROTECTED] > > freebsd-scsi[EMAIL PROTECTED] > > freebsd-security[EMAIL PROTECTED] > > > > >>>> > > > > - End forwarded message - > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Majordomo@FreeBSD.ORG: Majordomo results: which]
Doesn't change the facts Gary. This isn't the first time either Gary. Plausable deniability isn't going to wash here. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! On Sun, Jan 02, 2000 at 07:33:10PM -0500, Gary Palmer wrote: > Karl Denninger wrote in message ID > <[EMAIL PROTECTED]>: > > Uh, Matthew, I have the system logs here. I'm root. There was no bounce. > > Wrong side of the SMTP transaction Karl. Logs on the receiver mean > *NOTHING*. And you don't have an account, or root, or access to the > majordomo bounce mailbox on hub, so your claim isn't worth the > electrons you used to send it. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
One final note and a "bite me" to you
Just for those of you who think this whole "magical unsubscribe" is a "fluke"; All unsubscribes and subscribes to FreeBSD's lists must be authenticated. Majordomo is set to confirm all transactions. Whoever did this did it directly by logging into Freefall and editing the mailing list files themselves, or otherwise forged the request so as to get the "key" for the response. Have a nice year folks. THIS time, with only other people to benefit from my participation here, I'm not willing to play. Some of you will remember that about two years ago a SIMILAR forged unsubscribe was sent in for me during a heated discussion right here on this list. Theo was right in splitting off from you folks. I should have followed him a couple of years ago and done my own split. Now, its simply not worth it. This makes twice - and that's enough for me. As for you Paol, perhaps some day you'll stop trying to bullshit people. Occasionally when you do that you run into someone who has AT LEAST a single class in physical science and understands the uncertainty of measurements. -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Your misleading, no, LYING message to me
On Sun, Jan 02, 2000 at 06:55:50PM -0800, Jonathan M. Bresler wrote:
> From: "Jonathan M. Bresler" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> In-reply-to: <[EMAIL PROTECTED]> (message from Karl
> Denninger on Sun, 2 Jan 2000 18:50:17 -0600)
> Subject: Recent cat fighting in the FreeBSD mailing lists.
> Message-Id: <[EMAIL PROTECTED]>
> Date: Sun, 2 Jan 2000 18:50:01 -0800 (PST)
> Sender: [EMAIL PROTECTED]
>
>
> Karl,
>
> Hi, my name is Jonathan Bresler. I am the postmaster for
> FreeBSD. Usually, I tend to stay in the background and do the
> postmastering. The recent fractious behavior in the mailing lists has
> become so galling that I am forced to "come out from behind the
> curtain."
>
> Lets set the record straight on a couple items:
>
> 1. Karl, you are still subscribed to both of the "missing" mailing
> lists. I disabled the "which" command for those two lists:
> freebsd-arch and freebsd-security-notifications. That is why your
> subscription to those two lists did not appear when you sent the
> "which " request to majordomo.
That's not the issue.
Someone logged into HUB the EDITED me out of the CURRENT mailing list.
You are mis-representing the facts. Exactly what I expect from CORE.
> 2. I remove people that bounce mail. I dont send them email to tell
> them that I am reomving them for bouncing mailI sincerely expect
> that the notification email would bounce. A bounced email is one that
> appears in the list(s)-owners mailbox on hub. So, sites with problems
> that do *not* result in immediate bounces and that fix their mail
> problems before the email is aged out of the queue, dont have to
> worry. If you suspect that you have been removed, or that I might
> remove you, send me an email...explain that you have been having a
> mail problem and when you expect the problem to be resolved.
That's not the issue either. Again, someone logged into HUB and
removed me.
Again, who was su'd or logged into the majordomo account (or any account
with write access to the list directories) a few hours ago?
> 3. Everyone, the FreeBSD mailing lists are a community resource.
> While there are many lists. There is only one set of lists. We all
> share in that set of lists. When one or more people significantly
> degrade the quality of the lists, the only option is to remove that
> person from the lists. I have done this about six times in my role as
> postmaster these past 5 or 6 years.
Yeah, so who's the asshole who signed in and removed me?
> 4. Core recently published guidelines for committers. These
> guidelines included a minimal acceptable behavior standard. The recent
> emails fail to come within a country mile of meeting those standards.
> Which perhaps does not matter as the author is not a committer.
> Nonetheless, the author is degrading our mailing lists and I am
> empowered to act on behalf to the project to prevent people from
> degrading the quality of the lists.
>
> It seems that today around 4:51pm PST, Karl unsubscribed from
> freebsd-{security,hackers,ports,scsi}.
Yes, *AFTER* I was removed by a fraud who signed into HUB. *I* unsubscribed
from those lists LATER, after resubscribing to current, posting my "where"
command, and making it known that someone else had been tampering.
Go look at the DATE AND TIME STAMPED messages, AND the logs on hub.
Or would you prefer to protect the GUILTY?
> So what's the upshot of all this?
>
> Karl, take a two week sabbatical from the FreeBSD mailing lists.
> Consider it enforced leave. I will remove you from the remaining two
> mailing lists: freebsd-{announce,security-notifications}.
Jonathan, two words for you: Go Stuff.
Got it?
It ain't a two-week sabbatical. Its a permanent one. You and your
blow-hard assholes can go shove this "enforced leave" up your puny pucker
and leave it there until it explodes. I beg in front of NOBODY, and
that goes double for puny-brained cowards such as yourself who try to
deliberately cover up for the unethical and inappropriate actions of
other "annointed ones".
You DISGUST me.
I've had it.
You Lord-Mighty-and-all-things-shitheaded have pulled this crap before.
Yes, YOU. YOU is a plural Jonathan, for YOU speak for CORE.
YOU identify as CORE and Postmaster. I want to know who the person was
who su'd on Hub and removed me from the lists.
I want that person ejected from your systems and publically called out for
what they did. IN PUBLIC.
I know damn well you won't do it, but the call remains the same, and until
and unless you *DO* take this action your posting here is nothing other than
YET A
Re: Survey results very helpful, thanks!
Doug Hardie wrote: > On 8 March 2010, at 06:53, Robert Watson wrote: > > >> On Sun, 7 Mar 2010, Robert Watson wrote: >> >> >>> If your system shows a non-zero value, please send me a *private e-mail* >>> with the output of that command, plus also the output of "sysctl kern.smp", >>> "uptime", and a brief description of the workload and network interface >>> configuration. For example: it's a busy 8-core web server with roughly X >>> connections/second, and that has three em network interfaces used to load >>> balance from an upstream source. IPSEC is used for management purposes >>> (but not bulk traffic), and there's a local MySQL database. >>> >> I've now received a number of reports that confirm our suspicion that the >> race does occur, albeit very rarely, and particularly on systems with many >> cores or multiple network interfaces. Fixing it is definitely on the TODO >> for 9.0, both to improve our ability to do multiple virtual network stacks, >> but with an appropriately scalable fix in mind given our improved TCP >> scalability for 9.0 as well. >> > > I run a number of 4 core systems with em interfaces. These are production > systems that are unmanned and located a long way from me. Under unusual > conditions it can take up to 6 hours to get there. I have been waiting to > switch to 8.0 because of the discussions on the em device and now it sounds > like I had better just skip 8.x and wait for 9. 7.2 is working just > fine.___ > I don't think its that simple. I run a number of production systems with "em" interfaces, and they get POUNDED. None have had any trouble with 8.x. $ ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:d2:5a:24 inet 67.23.181.70 netmask 0xff00 broadcast 67.23.181.255 media: Ethernet autoselect (100baseTX ) status: active $ uptime 3:27PM up 61 days, 22:34, 1 user, load averages: 5.08, 4.48, 4.28 That's one of the busier ones; it's kinda loafing right now on network I/O (running about 3mbps sustained) but typically operates in the 15-20mbps range to the wild wild net for 6-8 hours in the evening doing what its doing now (handling a very busy forum) plus a few hundred videocast streams The last reboot was to replace a power strip in the colo rack with one that had remote management capability. It hasn't actually crashed since, well, pretty much forever (it was running 7.x before 8.x went to production status) The box is a dual quad-core Xeon running the amd64 codebase. -- Karl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Compaq Presario 2140US w/Current - no mouse/pointpad?!
Hi folks; I've got an odd one here... Trying to run 5.1-RELEASE on a Presario 2140-US laptop (4.x locks up in an odd way on boot, and I can't get into the user config - that goes into an infinite keyboard read loop at boot when you use the "-c" option?!) Anyway, the "-c" option appears to have been removed from the kernel boot on 5.x (so I can't look for possible conflicts before startup), and the mouse doesn't initialize. Booting verbose says that the IRQ cannot be allocated (irq 12), but a careful persusal of the boot log shows no other devices attempting to attach to, or actually attached to, that interrupt. Any ideas? I'd like to get the X-server and KDE running on this thing, and shed the borg (XP) if I can I'm not new at FreeBSD in any way, but things appear to have changed significantly in the user config area with 5.x, and I've run out of "self-help" ideas on this one... Other than the mouse (touchpad) not initializing with this error, and some niggling ACPI issues (apparently the Compaq has some ACPI capabilities that 5.x doesn't, and there is some kind of clash causing error messages once in a while during state changes such as from battery to AC) everything ELSE appears to work properly. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netTired of spam at your company? LOOK HERE! http://childrens-justice.orgWorking for family and children's rights http://diversunion.org LOG IN AND GET YOUR TANK STICKERS TODAY! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Compiling under 5.x for 4.x releases?
Can it be done with a command-line switch to the compiler or gcc, or am I consigned to dual-booting? I know the libraries are there for runtime, but can you build executables for them? -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netTired of spam at your company? LOOK HERE! http://childrens-justice.orgWorking for family and children's rights http://diversunion.org LOG IN AND GET YOUR TANK STICKERS TODAY! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Compiling under 5.x for 4.x releases?
On Sat, Jun 14, 2003 at 09:43:01AM -0700, Doug White wrote: > On Sat, 14 Jun 2003, Karl Denninger wrote: > > > Can it be done with a command-line switch to the compiler or gcc, or am I > > consigned to dual-booting? > > You mean building apps linked against 4.X libs vs. 5.X? With some creative > -L flags you might be able to get it to not use /usr/lib/libc* and use > /usr/lib/compat/libc* instead, which has copies of certain 4.X libs in it. > > Let us know if you get it working :) Will play with that one > > I know the libraries are there for runtime, but can you build executables > > for them? > > The executables are the exact same format. The problem is that I have a lot of users on the 4.x release(s) of the OS, and have binary apps that I'm supporting for them. Linking static is an option, but does ugly things to the file sizes. Thus, wondering if I can link the other way and still have it run on a 4.x box. I guess it depends on what the application is and what dependancies there are. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netTired of spam at your company? LOOK HERE! http://childrens-justice.orgWorking for family and children's rights http://diversunion.org LOG IN AND GET YOUR TANK STICKERS TODAY! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Compiling under 5.x for 4.x releases?
Thanks; I guess that means that for now I keep the production build machine is 4.8-STABLE, and I keep 5.x as a "play" environment until people move over. The fun will begin when migration begins in significant numbers, but I still need to support both! -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant & Kids Rights Activist http://www.denninger.netTired of spam at your company? LOOK HERE! http://childrens-justice.orgWorking for family and children's rights http://diversunion.org LOG IN AND GET YOUR TANK STICKERS TODAY! On Sat, Jun 14, 2003 at 12:28:11PM -0500, Dan Nelson wrote: > In the last episode (Jun 14), Karl Denninger said: > > On Sat, Jun 14, 2003 at 09:43:01AM -0700, Doug White wrote: > > > On Sat, 14 Jun 2003, Karl Denninger wrote: > > > > > > > Can it be done with a command-line switch to the compiler or gcc, > > > > or am I consigned to dual-booting? > > > > > > You mean building apps linked against 4.X libs vs. 5.X? With some > > > creative -L flags you might be able to get it to not use > > > /usr/lib/libc* and use /usr/lib/compat/libc* instead, which has > > > copies of certain 4.X libs in it. > > > > > > Let us know if you get it working :) > > > > Will play with that one > > That won't work. The reason shared libraries get their versions bumped > and the old ones move into compat is that the ABI changes. Unless you > kept the headers for those old shlibs laying around someplace, gcc will > compile programs using the ABI for the libs in /usr/lib. > > > The problem is that I have a lot of users on the 4.x release(s) of > > the OS, and have binary apps that I'm supporting for them. Linking > > static is an option, but does ugly things to the file sizes. > > That will break the first time a 5.0-compiled library decides to use a > syscall not in 4.x. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-CURRENT "installworld" fails if not upgrading (e.g. building via Crochet)
svn updated this morning Attempting to build 12 via Crochet fails with an error about the "ntpd" user being missing during install. Setting "-DDB_FROM_SRC" allows the install to complete. I'm not sure where it's getting the base check from since this is a new build into "empty" media (not an upgrade) -- should the "DB_FROM_SRC" be detected on its own or is this just a Crochet screwball thing? -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 1/19/2019 10:32, Rodney W. Grimes wrote: >> .. > The BIOS does NOT do what our boot0 does, I have seen no BIOS that > well allow me to select a partition on a drive, you can only select > the drive. > > I think this is the feature that Lev is missing, and I am sure > others shall miss it to. > > IIRC whistle used a version of this so you could install a new system > to partion 2, keeping your current system in partion 1, and changing the > active back and forth. If we have lost that basic functionality with > the growth of GPT and UEFI that is a sad day. It is indeed, especially for embedded applications. I really, really like the fact that NanoBSD (on an MBR boot) can have two partitions and mark the "other one" as active; this then lets you update the code "in place" and as long as you are paying attention to what goes into the volatile overlays (specifically although not exclusively don't let /etc/fstab with a hard-coded filesystem reference get into there!) then you can "warm update" a running system and reboot into the new code. If something goes wrong re-marking the old partition active is not terribly hard, so there's a *reasonable* recovery path available. I've not found a reliable way to do that sort of thing with many of the "newer" small-board devices and I really like it on, for example, my apu2 firewall appliances that I and others are using all over the place in that being able to put together a code-fix update is of material value. -- Karl Denninger k...@denninger.net /The Market Ticker/ smime.p7s Description: S/MIME Cryptographic Signature
Re: FreeBSD and Coreboot
On 5/27/2019 10:13, Eric McCorkle wrote: > Hello everyone, > > I'm through enough of my job change that I can start working on FreeBSD > again. One thing I've had on my list to examine is using FreeBSD with > coreboot, so I wanted to put out a call for anyone who has done work on > this, or knows anything about it. > > Here is what I know: > > * Coreboot _can_ boot kernels directly, but this requires two things: 1) > you must flash your BIOS every time you update a kernel, 2) the kernel > must be able to work without the usual device initialization that the > BIOS does. > > * Coreboot has two significant payload options beyond a kernel: Seabios > and GRUB (supposedly Tianocore EFI is an option, but it apparently > doesn't really work). > > * Scrounging the coreboot wiki seems to produce some conflicting > information. One page claims that the FreeBSD kernel can boot directly > as a coreboot payload; another claims GRUB or Seabios to be the only > options. > > * The PC Engines boards evidently use coreboot, and I've heard multiple > reports of them running FreeBSD systems without a problem. I don't know > whether they use GRUB or Seabios. (Aside: I'm thinking about ordering > some of these boards for my own use, so I'm generally interested in how > well they function with FreeBSD) > PCEngines machines run just fine with FreeBSD; I use and support a bunch of them around here for various purposes, mostly as edge firewall and gateway devices. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: UEFI firmware and getting FreeBSD recognized by default: who to talk to?
On 6/22/2019 13:34, Rebecca Cran wrote: > I just upgraded my UEFI system firmware, and not unexpectedly lost the > "FreeBSD" boot manager entry after the settings got reset to default. I > was left with "Windows", "opensuse" and two "UEFI OS" entries. > > The "opensuse-secureboot" entry wasn't automatically recreated, but > since the "opensuse" entry uses the shim > (https://github.com/rhboot/shim) it will be created when I boot "opensuse". > > > I'm wondering if anyone knows who we should talk to in order to get > \EFI\FreeBSD\loader.efi recognized by firmware as something to be added > as a boot option by default? I plan to import the shim into the tree > sometime so that we too can automatically recreate boot manager entries > if they're deleted. I use Refind for this sort of thing and it has (thus far!) survived upgrades. The only "gotcha" is that I had a Windows 10 "Feature" upgrade that reset the default boot in the firmware to Windows; it didn't damage anything but did require that I go reset the UEFI default to boot the Refind EFI loader instead of the Windows one. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: UEFI firmware and getting FreeBSD recognized by default: who to talk to?
On 6/22/2019 14:05, Rebecca Cran wrote: > On 2019-06-22 12:59, Karl Denninger wrote: >> I use Refind for this sort of thing and it has (thus far!) survived >> upgrades. The only "gotcha" is that I had a Windows 10 "Feature" >> upgrade that reset the default boot in the firmware to Windows; it >> didn't damage anything but did require that I go reset the UEFI default >> to boot the Refind EFI loader instead of the Windows one. > > I do like that rEFInd knows about FreeBSD, and it's one of the "UEFI OS" > entries that remains. But I'd prefer it if a "FreeBSD" entry was > automatically created! It is. All I had to do was put the EFI loader in a directory under the UEFI partition and Refind found it. I didn't have to specifically tell it that it was there. The explicit "set" command (which I issued under Windows) is to tell the firmware what the default is; you do it once on original installation of Refind. The Windows 10 feature update set it back to default to Windows, which was quite annoying but not really a big deal. One command, once, from the Windows command line (same as the one to set it in the first place) was all that was required. The danger with tampering with where Windows 10 puts its EFI loader (e.g. copying Refind there after moving it somewhere else) is that Bitlocker may throw up on you if you do that. In fact you do have to do things in the right order or Bitlocker's default configuration (at least on a TPM equipped machine) will have a hissy fit -- you cannot change anything in the EFI partition after initializing Bitlocker, including the Refind configuration file (this most-specifically applies to the "wait for boot time"; I find the default obnoxiously long) so you have to make that edit and put the other stuff in the UEFI partition (e.g. FreeBSD's EFI loader and Refind) BEFORE turning Bitlocker on. I've been running this way since 12.x showed up since 12.x can boot a geli-encrypted system directly on my laptop. Works nicely. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: UEFI firmware and getting FreeBSD recognized by default: who to talk to?
On 6/22/2019 20:16, Thomas Mueller wrote: > from Karl Denninger: > >> On 6/22/2019 14:05, Rebecca Cran wrote: >>> On 2019-06-22 12:59, Karl Denninger wrote: >>>> I use Refind for this sort of thing and it has (thus far!) survived >>>> upgrades. The only "gotcha" is that I had a Windows 10 "Feature" >>>> upgrade that reset the default boot in the firmware to Windows; it >>>> didn't damage anything but did require that I go reset the UEFI default >>>> to boot the Refind EFI loader instead of the Windows one. >>> I do like that rEFInd knows about FreeBSD, and it's one of the "UEFI OS" >>> entries that remains. But I'd prefer it if a "FreeBSD" entry was >>> automatically created! > >> It is. >> All I had to do was put the EFI loader in a directory under the UEFI >> partition and Refind found it. I didn't have to specifically tell it >> that it was there. >> The explicit "set" command (which I issued under Windows) is to tell the >> firmware what the default is; you do it once on original installation of >> Refind. The Windows 10 feature update set it back to default to >> Windows, which was quite annoying but not really a big deal. One >> command, once, from the Windows command line (same as the one to set it >> in the first place) was all that was required. >> The danger with tampering with where Windows 10 puts its EFI loader >> (e.g. copying Refind there after moving it somewhere else) is that >> Bitlocker may throw up on you if you do that. In fact you do have to do >> things in the right order or Bitlocker's default configuration (at least >> on a TPM equipped machine) will have a hissy fit -- you cannot change >> anything in the EFI partition after initializing Bitlocker, including >> the Refind configuration file (this most-specifically applies to the >> "wait for boot time"; I find the default obnoxiously long) so you have >> to make that edit and put the other stuff in the UEFI partition (e.g. >> FreeBSD's EFI loader and Refind) BEFORE turning Bitlocker on. > >> I've been running this way since 12.x showed up since 12.x can boot a >> geli-encrypted system directly on my laptop. Works nicely. > This is scary (Bitlocker), sent me to Wikipedia to look up Bitlocker. > > Can you turn Bitlocker off after turning it on and get your system back? You SHOULD (better have!) kept the recovery key. If you have it, you can boot with it. Then turn it off and back on, and it will generate a new key. > Now I am even more scared to ever get a computer with MS-Windows! > > One think on my mind is if I need a new motherboard, would it have the > undesired Secure Boot? I guess I'd have to ask the seller and look on the > motherboard manufacturer's website (MSI, ASRock, Asus, Gigabyte, or other). > > I have no Secure Boot now. Probably. But you can shut THAT off (and should) provided you wish to dual boot. The exception is ARM-based systems, many of which are secure-boot ONLY. For Intel machines I've never run into one that can't have it turned off (and I'd return it immediately if I found one.) > I am trying to set up UEFI to boot my FreeBSD and NetBSD installations, and > later, Linux. > > Tom Easy. Refind should do that and allow selection from a menu. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: UEFI firmware and getting FreeBSD recognized by default: who to talk to?
On 6/23/2019 02:36, Thomas Mueller wrote: > from Karl Denninger and my previous post: > >>> This is scary (Bitlocker), sent me to Wikipedia to look up Bitlocker. >>> >>> Can you turn Bitlocker off after turning it on and get your system back? >> You SHOULD (better have!) kept the recovery key. If you have it, you >> can boot with it. Then turn it off and back on, and it will generate a >> new key. >>> Now I am even more scared to ever get a computer with MS-Windows! Bitlocker is optional and in fact defaults off. >>> One think on my mind is if I need a new motherboard, would it have the >>> undesired Secure Boot? I guess I'd have to ask the seller and look on the >>> motherboard manufacturer's website (MSI, ASRock, Asus, Gigabyte, or other). >>> I have no Secure Boot now. >> Probably. But you can shut THAT off (and should) provided you wish to >> dual boot. The exception is ARM-based systems, many of which are >> secure-boot ONLY. For Intel machines I've never run into one that can't >> have it turned off (and I'd return it immediately if I found one.) >>> I am trying to set up UEFI to boot my FreeBSD and NetBSD installations, and >>> later, Linux. >>> >> Tom >> >> Easy. Refind should do that and allow selection from a menu. > Can one recover after losing the recovery key? I think I would want to avoid > Bitlocker from the outset (malware!). No. You can't recover in FreeBSD if you lose the Geli key either. That's the entire point of disk encryption; no key, no data. End of discussion. Bitlocker has TWO keys (one normal one, which can either be TPM-only if you have one in the machine or TPM + PIN, or, if there is no TPM, a password) and a recovery key which is a very long set of octal digit groups. It will insist you save that recovery key somewhere NOT on the encrypted volume (e.g. to a USB key, to a network drive, printed, etc) during setup. It also (stupidly, in my opinion) allows you to save it to your "Microsoft account" which is IMHO exactly identical to giving it to Microsoft, the NSA, and probably China's Communist Party too. I recommended against that option, obviously. Geli has two key slots too, and you can set both, and allows a "randomization source" (e.g. key file), that plus a password, or just a password. But if, in any encrypted disk environment, you lose the keys for any reason you're screwed -- I hope you have backups! :) Geli by default only sets one key; the other has to be set manually. Oh, Geli also has a "duress" command (I don't know of one for Bitlocker) that instantly destroys the key blocks on the disk. If you use that then it's bye-bye even WITH the key unless you have backed them up to some sort of other media (it does save the key blocks off during initialization so you *can* back them up.) It would be rather pointless to call a disk "encrypted" if, absent the authentication means, you could manage to get into it. > I was thinking about AMD Ryzen if I need to replace motherboard. I would > need a new CPU with any new motherboard, Intel or AMD-compatible, would also > need new RAM (DDR4, I now have DDR3), and probaby a new case. > > But I would keep and transfer any hard drives that are still good. > > Can rEFInd find and boot FreeBSD, NetBSD, Haiku, etc? Yes. > I don't see any refind, however partially capitalized, in FreeBSD base system > or ports, or NetBSD base system or pkgsrc. I find efibootmgr now in FreeBSD, > but not NetBSD, base system. It's not a port or package; the software is not in any way FreeBSD-specific. > I would want to label boot options with the partition label (like WD2G18, > WD2G19, WD2G20, WD2G21, and others) so I can see on the boot menu. Refind automatically figures it out -- it "knows" what FreeBSD and Windows are, for example. > I also notice it is difficult to choose the root partition when booting UEFI. > I could create a zero-byte or very small file in root directory with the > partition label name, like /WD2G18 on partition WD2G18 just to show up with > ls. > > Tom That's a function of the actual EFI loader in question for the specific OS and is beyond the scope of UEFI itself. In point of fact UEFI BIOS implementations are *supposed* to implement a reasonable "boot manager" option to select from whatever various UEFI loaders are installed on the machine. In actual practice most of them I've run into on various motherboards bite big ones and either their alleged "manager" is worthless or nearly so; thus tools like Refind. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found
BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Am Wed, 21 Aug 2019 22:34:21 +0300 > Toomas Soome schrieb: > > >> On 21 Aug 2019, at 22:30, O. Hartmann wrote: > >> > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA256 > >> > >> Am Wed, 21 Aug 2019 22:14:46 +0300 > >> Toomas Soome mailto:tso...@me.com>> schrieb: > >> > >>> If you drop into efi shell, can you start efi/boot/bootx64.efi > manually? you should have > >>> fs0: or like for ESP. > >>> > >>> rgds, > >>> toomas > >> > >> Hello, > >> > >> I can't even stop to gain access to the shell; there is no > timeframe to hit any key to > >> stop by and access the efi shell. > >> > >> Kind regards, > >> oh > > > > hm? efi shell should be available from boot device menu, so you > mean, you can not even get > > into firmware setup? > > > rgds, > > toomas > > Sorry, > I confused loader prompt and EFI shell. > > I do not have a EFI shell on that type of laptop, not to know about > it. I can access the > firmware setup and already performed a reset and switched back to > default settings. No effect. > > I just downloaded the newest CURRENT mem stick and extracted both > boot1.efi and loader.efi and > installed those into the ESP as described, setting the efibootmgr env > accordingly. Still the > same error. > > It seems that there is indeed no EFI/UEFI shell. There are Lenovo > specific EFI boot options, > like "diagnostics" and so on, if selected, the UEFI boots into a > firmware embedded diagnostic > menu. I tried several from the list given via efibootmgr show -v, but > there is no shell from > which I could access/boot an alternative loader. > > How I'm supposed to achive the access to this EFI shell? I doubt that > on the E540 (beware of > the E, it is not a L or T model) does have such a shell. > > Regards, > oh I would see if you can get REFIND loaded and use that. I have a Lenovo X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot (e.g. Win10 and FreeBSD) easily. I've not had trouble with 12.x on it, and I do use the geli-encrypted-aware loader.efi. If there's a way to get into the EFI shell on Lenovo's laptops from the BIOS during the boot I've not found it yet. There's supposed to be on all EFI devices, but you know how "supposed to" works in many cases, right? -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109
erating host.conf. Creating and/or trimming log files. Starting syslogd. Clearing /tmp (X related). Updating motd:. Mounting late filesystems:. Starting powerd. cpufreq0: rejecting change, SMP not started yet Configuring vt: blanktime. Generating RSA host key. cpufreq0: rejecting change, SMP not started yet cpufreq0: rejecting change, SMP not started yet cpufreq0: rejecting change, SMP not started yet cpufreq0: rejecting change, SMP not started yet cpufreq0: rejecting change, SMP not started yet cpufreq0: rejecting change, SMP not started yet 2048 SHA256:UFglYtdXWLG/Va5zmZ0OoGMhnvYiNyGDqEUkas7PZVs root@rpi3 (RSA) Generating ECDSA host key. cpufreq0: rejecting change, SMP not started yet 256 SHA256:XPQnIwHtB3Aau3jSQDitlqDZxF8hPLji5VpjOkJ3xqI root@rpi3 (ECDSA) Generating ED25519 host key. cpufreq0: rejecting change, SMP not started yet 256 SHA256:cVSnpBc4G0NX7+I3yUWiTa4YyYroJdbS0aKqdFky3a0 root@rpi3 (ED25519) Performing sanity check on sshd configuration. cpufreq0: rejecting change, SMP not started yet sdhci_bcm0-slot0: Controller timeout sdhci_bcm0-slot0: == REGISTER DUMP == sdhci_bcm0-slot0: Sys addr: 0x006d8000 | Version: 0x9902 sdhci_bcm0-slot0: Blk size: 0x0200 | Blk cnt: 0x0015 sdhci_bcm0-slot0: Argument: 0x000af240 | Trn mode: 0x193a sdhci_bcm0-slot0: Present: 0x01ff0506 | Host ctl: 0x0003 sdhci_bcm0-slot0: Power:0x000f | Blk gap: 0x sdhci_bcm0-slot0: Wake-up: 0x | Clock:0x0307 sdhci_bcm0-slot0: Timeout: 0x000e | Int stat: 0x0010 sdhci_bcm0-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff0089 sdhci_bcm0-slot0: AC12 err: 0x | Slot int: 0x sdhci_bcm0-slot0: Caps: 0x | Max curr: 0x0001 sdhci_bcm0-slot0: === mmcsd0: Error indicated: 1 Timeout g_vfs_done():mmcsd0s2a[WRITE(offset=314343424, length=16384)]error = 5 mmcsd0: Error indicated: 1 Timeout g_vfs_done():mmcsd0s2a[READ(offset=1695514624, length=32768)]error = 5 vm_fault: pager read error, pid 626 (sshd) mmcsd0: Error indicated: 1 Timeout g_vfs_done():mmcsd0s2a[WRITE(offset=314343424, length=16384)]error = 5 Smmcsd0: Error indicated: 1 Timeout g_vfs_done():mmcsd0s2a[WRITE(offset=15509504, length=512)]error = 5 panic: brelse: inappropriate B_PAGING or B_CLUSTER bp 0x53280d60 cpuid = 3 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0x005b76ac lr = 0x00086048 sp = 0x40328990 fp = 0x40328ba0 db_trace_self_wrapper() at vpanic+0x170 pc = 0x00086048 lr = 0x002f41b4 sp = 0x40328bb0 fp = 0x40328c30 vpanic() at kassert_panic+0x164 pc = 0x002f41b4 lr = 0x002f4040 sp = 0x40328c40 fp = 0x40328d00 kassert_panic() at brelse+0x7c4 pc = 0x002f4040 lr = 0x0038e804 sp = 0x40328d10 fp = 0x40328d70 brelse() at bufwrite+0x338 pc = 0x0038e804 lr = 0x0038bb7c sp = 0x40328d80 fp = 0x40328dc0 bufwrite() at softdep_process_journal+0x714 pc = 0x0038bb7c lr = 0x00547e7c sp = 0x40328dd0 fp = 0x40328e70 softdep_process_journal() at flush_deplist+0xb4 pc = 0x00547e7c lr = 0x0054d34c sp = 0x40328e80 fp = 0x40328eb0 There's not a lot changed between 313109 and 313441 in the loader.efi and arm64 pieces of sys.. any ideas what boogered it? (Also have posted on this in -arm, but since it's Pi3 specific and that machine is -HEAD dependent is this the better place for it?) -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109
On 2/8/2017 16:18, Karl Denninger wrote: > r313441 blows up on the Pi3 in /boot/loader.efi with: > > FreeBSD/arm64 EFI loader, Revision 1.1 > (Tue Feb 7 15:15:52 CST 2017 free...@newfs.denninger.net) > Failed to start image provided by UFS (14) > "Synchronous Abort" handler, esr 0x9604 > ELR: 3af62cec > LR: 3af61d60 > x0 : 0001 x1 : 0001 > x2 : 3afeb000 x3 : 003f > x4 : 0020 x5 : 0010 > x6 : x7 : 39b260a4 > x8 : 3af61d48 x9 : 000d > x10: 0030 x11: > x12: x13: 0002 > x14: x15: > x16: x17: > x18: 3ab30df8 x19: 37a16008 > x20: x21: > x22: 39b28000 x23: 39b1d49c > x24: 39b28850 x25: 3ab3d740 > x26: 3af839a0 x27: 39b2e3e8 > x28: x29: 3ab2ef60 > > Resetting CPU ... > > If you copy in a loader.efi from an earlier build (e.g. r313109) then the > system boots but complains about SMP problems, fails to start any of the > other CPUs (although it sees them) and panics before it reaches a login > prompt with what appears to be a problem reading the SD card (I also get a > couple of lor's in here too. not sure if those are "real" or false > positives) > > B This has been isolated to r31 in sys/boot/efi; reverting the EFI loader to a previous revision stops the crash. Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109
On 2/9/2017 08:58, Toomas Soome wrote: >> On 9. veebr 2017, at 16:36, Karl Denninger wrote: >> >> >> On 2/8/2017 16:18, Karl Denninger wrote: >>> r313441 blows up on the Pi3 in /boot/loader.efi with: >>> >>> FreeBSD/arm64 EFI loader, Revision 1.1 >>> (Tue Feb 7 15:15:52 CST 2017 free...@newfs.denninger.net) >>> Failed to start image provided by UFS (14) >>> "Synchronous Abort" handler, esr 0x9604 >>> ELR: 3af62cec >>> LR: 3af61d60 >>> x0 : 0001 x1 : 0001 >>> x2 : 3afeb000 x3 : 003f >>> x4 : 0020 x5 : 0010 >>> x6 : x7 : 39b260a4 >>> x8 : 3af61d48 x9 : 000d >>> x10: 0030 x11: >>> x12: x13: 0002 >>> x14: x15: >>> x16: x17: >>> x18: 3ab30df8 x19: 37a16008 >>> x20: x21: >>> x22: 39b28000 x23: 39b1d49c >>> x24: 39b28850 x25: 3ab3d740 >>> x26: 3af839a0 x27: 39b2e3e8 >>> x28: x29: 3ab2ef60 >>> >>> Resetting CPU ... >>> >>> If you copy in a loader.efi from an earlier build (e.g. r313109) then the >>> system boots but complains about SMP problems, fails to start any of the >>> other CPUs (although it sees them) and panics before it reaches a login >>> prompt with what appears to be a problem reading the SD card (I also get a >>> couple of lor's in here too. not sure if those are "real" or false >>> positives) >>> >>> B >> This has been isolated to r31 in sys/boot/efi; reverting the EFI >> loader to a previous revision stops the crash. >> >> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 >> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940> >> > Does it still crash with r313442? I think it does and this is why: > > From your log above, the hint is "Failed to start image provided by UFS > (14)”, so what we can guess here is that for some reason the loader.efi > main() failed to detect the boot device, and did return back to boot1. > > Boot1 did print out this error message and did call panic(). So, the question > is, why it is failing to detect the root fs handle. I’ll try to check if I > can replicate the issue with x86 + ufs. > > BTW: sorry for trouble:) > > rgds, > toomas > Yes. It's isolated to that particular revision, which appears to have reworked the enumeration of the available devices to boot from. Reverting only sys/boot/efi to anything before 31 (e.g. "svn update -r 313332 ." in src/sys/boot/efi) and rebuilding results in a loader.efi that successfully loads and starts the kernel. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109
On 2/9/2017 15:39, Oleksandr Tymoshenko wrote: > Toomas Soome (tso...@me.com) wrote: >>> On 9. veebr 2017, at 17:05, Karl Denninger wrote: >>> >>> >>> On 2/9/2017 08:58, Toomas Soome wrote: >>>>> On 9. veebr 2017, at 16:36, Karl Denninger >>>>> <mailto:k...@denninger.net> wrote: >>>>> >>>>> >>>>> On 2/8/2017 16:18, Karl Denninger wrote: >>>>>> r313441 blows up on the Pi3 in /boot/loader.efi with: >>>>>> >>>>>> FreeBSD/arm64 EFI loader, Revision 1.1 >>>>>> (Tue Feb 7 15:15:52 CST 2017 free...@newfs.denninger.net >>>>>> <mailto:free...@newfs.denninger.net>) >>>>>> Failed to start image provided by UFS (14) >>>>>> "Synchronous Abort" handler, esr 0x9604 >>>>>> ELR: 3af62cec >>>>>> LR: 3af61d60 >>>>>> x0 : 0001 x1 : 0001 >>>>>> x2 : 3afeb000 x3 : 003f >>>>>> x4 : 0020 x5 : 0010 >>>>>> x6 : x7 : 39b260a4 >>>>>> x8 : 3af61d48 x9 : 000d >>>>>> x10: 0030 x11: >>>>>> x12: x13: 0002 >>>>>> x14: x15: >>>>>> x16: x17: >>>>>> x18: 3ab30df8 x19: 37a16008 >>>>>> x20: x21: >>>>>> x22: 39b28000 x23: 39b1d49c >>>>>> x24: 39b28850 x25: 3ab3d740 >>>>>> x26: 3af839a0 x27: 39b2e3e8 >>>>>> x28: x29: 3ab2ef60 >>>>>> >>>>>> Resetting CPU ... >>>>>> >>>>>> If you copy in a loader.efi from an earlier build (e.g. r313109) then >>>>>> the system boots but complains about SMP problems, fails to start any of >>>>>> the other CPUs (although it sees them) and panics before it reaches a >>>>>> login prompt with what appears to be a problem reading the SD card (I >>>>>> also get a couple of lor's in here too. not sure if those are "real" >>>>>> or false positives) >>>>>> >>>>>> B >>>>> This has been isolated to r31 in sys/boot/efi; reverting the EFI >>>>> loader to a previous revision stops the crash. >>>>> >>>>> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 >>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940> >>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940> >>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940> >>>>> >>>> Does it still crash with r313442? I think it does and this is why: >>>> >>>> From your log above, the hint is "Failed to start image provided by UFS >>>> (14)”, so what we can guess here is that for some reason the loader.efi >>>> main() failed to detect the boot device, and did return back to boot1. >>>> >>>> Boot1 did print out this error message and did call panic(). So, the >>>> question is, why it is failing to detect the root fs handle. I’ll try to >>>> check if I can replicate the issue with x86 + ufs. >>>> >>>> BTW: sorry for trouble:) >>>> >>>> rgds, >>>> toomas >>>> >>> Yes. >>> >>> It's isolated to that particular revision, which appears to have reworked >>> the enumeration of the available devices to boot from. Reverting only >>> sys/boot/efi to anything before 31 (e.g. "svn update -r 313332 ." in >>> src/sys/boot/efi) and rebuilding results in a loader.efi that successfully >>> loads and starts the kernel. >>> >> Well, the x86 version does not appear to have problems with finding the ufs >> devices. So this has to be some sort of corner case related to arm:( >> unfortunately I do not have much variants to test arm, except qemu… so some >> help would be needed there. Since the only crash is from boot1 call to >> panic, I am pretty sure the disk detection and setup was ok, so we should >> get disk list if we insert something like: >> &
Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error
On 12/23/2017 05:25, O. Hartmann wrote: > Am Thu, 14 Dec 2017 12:05:20 +0100 > Willem Jan Withagen schrieb: > >> On 13/12/2017 17:47, Rodney W. Grimes wrote: >>>> On Tue, 12 Dec 2017 14:58:28 -0800 >>>> Cy Schubert wrote: >>>> I think people responding to my thread made it clear that the WD Green >>>> isn't the first-choice-solution for a 20/6 (not 24/7) duty drive and >>>> the fact, that they have serviced now more than 25000 hours, it would >>>> be wise to replace them with alternatives. >>> I think someone had an apm command that turns off the head park, >>> that would do wonders for drive life. On the other hand, I think >>> if it was my data and I saw that the drive had 2M head load cycles >>> I would be looking to get out of that driv with any data I could >>> not easily replace. If it was well backed up or easily replaced >>> my worries would be less. >> WD made their first series of Green disks green by aggressively turning >> them into sleep state. Like when few secs there was nog activity they >> would park the head, spin it down, and sleep the disk... >> Access would need to undo the whole series of command. >> >> This could be reset by writing in one of the disks registers. I remember >> doing that for my 1,5G WDs (WD15EADS from 2009). That saved a lot of >> startups. I still have 'm around, but only use them for things that are >> not valuable at all. Some have died over time, but about half of them >> still seem to work without much trouble. >> >> WD used to have a .exe program to actually do this. But that did not >> work on later disks. And turning things of on those disks was >> impossible/a lot more complex. >> >> This type of disk worked quite a long time in my ZFS setup. Like a few >> years, but I turned parking of as soon as there was a lot of turmoil >> about this in the community. >> Now I using WD reds for small ZFS systems, and WD red Pro for large >> private storage servers. Professional server get HGST He disks, a bit >> more expensive, but very little fallout. >> >> --WjW > Hello fellows. > > First of all, I managed it over the past week+ to replace all(!) drives with > new ones. I > decided to use this time HGST 4TB Deskstar NAS (HGST HDN726040ALE614) instead > of WD RED > 4TB (WDC WD40EFRX-68N32N0). The one WD RED is about to be replaced in the > next days. > > Apart from the very long resilvering time (the first drive, the Western > Digital WD RED > 4TB with 64MB cache and 5400 rpm) took 11 h, all HGST drives, although > considered faster > (7200 rpm, 128 MB cache) took 15 - 16 h), everything ran smoothly - except, > as mentioned, > the exorbitant times of recovery. > > A very interesting point in this story is: as you could see, the WD Caviar > Green 3TB > drives suffered from a high "193 Load_Cycle_Count" - almost 85 per hour. When > replacing > the drives, I figured out, that one of the four drives was already a Western > Digital RED > 3TB NAS drive, but investigating its "193 Load_Cycle_Count" revealed, that > this drive > also had a unusual high reload count - see "smartctl -x" output attached. It > seems, as > you already stated, that the APM feature responsible for this isn't > available. The drive > has been purchased Q4/2013. > > The HGST drives are very(!) noisy, th ehead movement induces a notable > ringing, while the > WD drive(s) are/were really silent. The power consumption of the HGST drives > is higher. > But apart from that, I'm disappointed about the fact that WD has also > implemented this > "timebomb" Load_Cycle_Count issue. > > Thanks a lot for your help and considerations! > > Kind regards, > Oliver I have a fairly large number of HGST "NAS" drives in service across multiple locations (several dozens units total.) I don't like their 5Tb models much (they're slow comparatively for an unknown reason) but the 4Tb and 6Tb models I have in the field, while noisy and somewhat more power-hungry (the latter comes from the 7200 rpm speed) have yet to suffer a failure. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Recent commits to -HEAD blow up cross-compile for PI3 (and possibly others)
There has been trouble cross-compiling for the RPI3 for a while now,
which I have filed a report on with the Crochet people here:
https://github.com/freebsd/crochet/issues/222
This stemmed from an older LLVM version on my 11.1 box, which I rolled
forward -- and resulted in blowups claiming that there was a permission
problem with posix_spawn (!)
Now, having tried to roll my -HEAD repo forward it's failing *much*
earlier, starting with warnings about ATOMIC_ASM:
--- getarg.o ---
cc -O2 -pipe -I/pics/CrossBuild-Head/src/crypto/heimdal/lib/roken -I.
-DHAVE_C
ONFIG_H -I/pics/CrossBuild-Head/src/kerberos5/include -MD
-MF.depend.getarg.o -
MTgetarg.o -std=gnu99 -Qunused-arguments
-I/pics/Crochet-work-HEAD/obj/pics/Cr
ossBuild-Head/src/arm64.aarch64/tmp/legacy/usr/include -c
/pics/CrossBuild-Head/
src/crypto/heimdal/lib/roken/getarg.c -o getarg.o
--- _bootstrap-tools-usr.bin/localedef ---
In file included from
/pics/CrossBuild-Head/src/usr.bin/localedef/collate.c:50:
In file included from
/pics/CrossBuild-Head/src/lib/libc/locale/collate.h:44:
/pics/CrossBuild-Head/src/lib/libc/locale/xlocale_private.h:170:18:
warning: pas
sing 'long *' to parameter of type 'volatile u_long *' (aka 'volatile
unsigned l
ong *') converts between pointers to integer types with different sign
[-Wpointe
r-sign]
atomic_add_long(&(obj->retain_count), 1);
^~~~
/usr/include/machine/atomic.h:467:1: note: passing argument to parameter
'p' her
e
ATOMIC_ASM(add, long, "addq %1,%0", "ir", v);
^
/usr/include/machine/atomic.h:141:43: note: expanded from macro 'ATOMIC_ASM'
atomic_##NAME##_##TYPE(volatile u_##TYPE *p, u_##TYPE v)\
And then failing to build llvm entirely starting here:
===> lib/clang/libllvm (all)
llvm-tblgen -gen-dag-isel -I
/pics/CrossBuild-Head/src/contrib/llvm/include -I
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64 -d
AArch64GenDAGISel.inc.d -o AArch64GenDAGISel.inc
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64.td
FCVTZSv8f16: (set V128:v16i16:$Rd, (fp_to_sint: V128:v1f32:$Rn))
Included from
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64.td:178:
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64InstrInfo.td:2951:1:
error: In FCVTZSv8f16: Type inference contradiction found, forcing
'{v16i8:v32i8:v8i16:v16i16:v4i32:v8i32:v2i64:v4i64:nxv4i1:nxv8i1:nxv16i1:nxv32i1:nxv32i8:nxv16i16:nxv8i32:nxv4i64}'
to have same number elements as 'v1f32'
defm FCVTZS : SIMDTwoVectorFPToInt<0, 1, 0b11011, "fcvtzs", fp_to_sint>;
^
Included from
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64.td:178:
Included from
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64InstrInfo.td:337:
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64InstrFormats.td:5092:3:
note: instantiated from multiclass
def v8f16 : BaseSIMDTwoSameVector<1, U, {S,1}, opc, 0b11, V128,
^
FCVTZUv8f16: (set V128:v16i16:$Rd, (fp_to_uint: V128:v1f32:$Rn))
Included from
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64.td:178:
/pics/CrossBuild-Head/src/contrib/llvm/lib/Target/AArch64/AArch64InstrInfo.td:2952:1:
error: In FCVTZUv8f16: Type inference contradiction found, forcing
'{v16i8:v32i8:v8i16:v16i16:v4i32:v8i32:v2i64:v4i64:nxv4i1:nxv8i1:nxv16i1:nxv32i1:nxv32i8:nxv16i16:nxv8i32:nxv4i64}'
to have same number elements as 'v1f32'
defm FCVTZU : SIMDTwoVectorFPToInt<1, 1, 0b11011, "fcvtzu", fp_to_uint>;
Off -HEAD revision 328011
attempting to build with:
FreeBSD 11.1-STABLE #21 r327332M: Thu Dec 28 20:54:24 CST 2017
k...@newfs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP
--
Karl Denninger
k...@denninger.net <mailto:k...@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
Apparently FIXED: Re: Pkg repository is broken...
On 3/7/2020 05:56, Michael Gmelin wrote: > > On Sat, 07 Mar 2020 10:10:43 +0100 > "Ronald Klop" wrote: > >> On Sat, 07 Mar 2020 01:38:55 +0100, Greg 'groggy' Lehey >> wrote: >> >>> On Friday, 6 March 2020 at 12:29:44 +0100, Lars Engels wrote: >>>> On Wed, Mar 04, 2020 at 03:16:14PM +1100, Greg 'groggy' Lehey >>>> wrote: >>>>> Any workarounds in the meantime? This must affect a lot of >>>>> people, including those who use 12-: >>>>> >>>>> pkg: wrong architecture: FreeBSD:12.0:amd64 instead of >>>>> FreeBSD:12:amd64 >>>>> pkg: repository FreeBSD contains packages with wrong ABI: >>>>> FreeBSD:12.0:amd64 >>>> Still broken for me on 12.1. >>> Strange. Mine cleared up automatically the following day. >>> >>> It's also strange how few replies I have received. Two private >>> messages (why?), yours, and that was it. You'd think that people >>> would be screaming. >>> >>> Greg >> >> I'm not screaming because I'm settling with the situation and >> starting to make workarounds. >> And wondering where the official communication of the community is. >> Nothing about this situation on www.freebsd.org. All information >> about the situation seems scattered through the mailinglists. >> >> Things are working for me on 13-CURRENT again, but still broken on >> 12.1-RELEASE. See attachment. >> > I worked around the situation locally by setting ALTABI > on `pkg update': > > # ALTABI=FreeBSD:12.0:amd64 pkg update -f > > This allowed me to run > > # pkg upgrade > > without any issues, so I assume none of the about 30 packages I updated > contained a wrong ABI/architecture. > > I verified this by checking: > > # pkg query "%q" | sort | uniq -c >112 FreeBSD:12:* >219 FreeBSD:12:amd64 > > Note that you could also export ALTABI to the environment or set it > in /usr/local/etc/pkg.conf, but I figured that I might forget it in > there. > > Also, it seems like none of my packages were affected and not setting > it on `pkg upgrade' meant that pkg checks for that (at least that's > what I assume it does) and therefore I won't have to deal with > different ABIs in my installed packages later. > > All of this should be really temporary anyway and hopefully be resolved > soon. > > Cheers, > Michael As of this morning it appears to be fixed for me. "pkg update -f" no longer returns the error, and I can now run an upgrade. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: what 3rd party boot mgr is required to boot multiple freebsd versions?
On 3/16/2020 17:23, Chris wrote: > I'm attempting to boot multiple versions of FreeBSD. > I started with an install of older 11 with a (u)efi > boot partition installed. I then grabbed an current 11 > usbstick, and installed that. Which stated it needed to > install a (u)efi boot partition. I let it do it. But the > new (additional) install doesn't show up at boot. Altho > my UEFI BIOS sees it. > I guess there are just too many uefi bios versions, > and too many changes in the FreeBSD uefi boot code > to expect consistent results over the long haul. > Should I just convert the 1st efi (GPT) boot partition > to a PMBR, and delete the second efi partition. Or is > there a recommended bootmanager I can use to boot multiple > versions of FreeBSD? Windows? > > Thank you! > > --Chris > Refind perhaps? -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
Re: what 3rd party boot mgr is required to boot multiple freebsd versions?
On 3/16/2020 17:33, Chris wrote: > On Mon, 16 Mar 2020 17:24:24 -0500 Karl Denninger k...@denninger.net said > >> On 3/16/2020 17:23, Chris wrote: >> > I'm attempting to boot multiple versions of FreeBSD. >> > I started with an install of older 11 with a (u)efi >> > boot partition installed. I then grabbed an current 11 >> > usbstick, and installed that. Which stated it needed to >> > install a (u)efi boot partition. I let it do it. But the >> > new (additional) install doesn't show up at boot. Altho >> > my UEFI BIOS sees it. >> > I guess there are just too many uefi bios versions, >> > and too many changes in the FreeBSD uefi boot code >> > to expect consistent results over the long haul. >> > Should I just convert the 1st efi (GPT) boot partition >> > to a PMBR, and delete the second efi partition. Or is >> > there a recommended bootmanager I can use to boot multiple >> > versions of FreeBSD? Windows? >> > >> > Thank you! >> > >> > --Chris >> > >> Refind perhaps? > Thanks for the reply, Karl! :) > I've used that before for FreeBSD/MacOS combos. I'll look at it again. > > For the record. I'm *only* using FreeBSD in this situation. I > only mentioned Windows above, for the use of it's boot manager. > > Thanks again! > Refind will find all the bootable EFI "elements" in the EFI partition and menu them. The question then becomes whether multiple efi loaders can be told to each use a *different* partition to load the kernel from (and thus the loader file, which in turn can tell it where the root filesystem is.) Reading through the man page it appears they may not be. You could of course interrupt it and manually select that, but I suspect that's not what you want to have to do. I use refind on a dual-boot (win10/FreeBSD) system but not with multiple independent FreeBSD versions. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ smime.p7s Description: S/MIME Cryptographic Signature
