Re: Request for Testing: TCP RACK
On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote: >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: >> >> Hello all! >> >> It works just fine! >> System performance is OK. >> Using patch on main-n268841-b0aaf8beb126(-dirty). >> >> --- >> net.inet.tcp.functions_available: >> Stack D AliasPCB count >> freebsd freebsd 0 >> rack* rack 38 >> --- >> >> It would be so nice that we can have a sysctl tunnable for this patch >> so we could do more tests without recompiling kernel. > Thanks for testing! > > @gallatin: can you come up with a patch that is acceptable for Netflix > and allows to mitigate the performance regression. Ideally, tcphpts could enable this automatically when it starts to be used (enough?), but a sysctl could select auto/on/off. Mike > Best regards > Michael >> >> Thanks all! >> Really happy here :) >> >> Cheers, >> >> Nuno Teixeira escreveu (domingo, 17/03/2024 à(s) >> 20:26): >>> >>> Hello, >>> >>>> I don't have the full context, but it seems like the complaint is a >>>> performance regression in bonnie++ and perhaps other things when tcp_hpts >>>> is loaded, even when it is not used. Is that correct? >>>> >>>> If so, I suspect its because we drive the tcp_hpts_softclock() routine >>>> from userret(), in order to avoid tons of timer interrupts and context >>>> switches. To test this theory, you could apply a patch like: >>> >>> It's affecting overall system performance, bonnie was just a way to >>> get some numbers to compare. >>> >>> Tomorrow I will test patch. >>> >>> Thanks! >>> >>> -- >>> Nuno Teixeira >>> FreeBSD Committer (ports) >> >> >> >> -- >> Nuno Teixeira >> FreeBSD Committer (ports)
Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b
On 31 Jan 2024, at 7:18, Olivier Cochard-Labbé wrote: > On Tue, Jan 30, 2024 at 3:50 PM David Wolfskill > wrote: > >> The machines where I track head (& stable/14) daily get powered off once >> they have finished their work for the day; this is done via "poweroff". >> >> I noticed (this morning) that one of them never actually powered off >> yesterday. After today's exercises (including the reboot & subsequent >> poweroff), I saw on the (serial) console: >> >> > Same problem here. I would check 9cdf326b4faef97f0d3314b5dd693308ac494d48, it changed shutdown ordering. Mike
Re: noatime on ufs2
On 30 Jan 2024, at 15:48, Cy Schubert wrote: > In message om> > , Rick Macklem writes: >> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wrot= >> e: >>> >>> On 30 Jan 2024, at 3:00, Olivier Certner wrote: >>> >>>> Hi Warner, >>>> >>>>> I strongly oppose this notion to control this from loader.conf. Root i= >> s >>>>> mounted read-only, so it doesn't matter. That's why I liked Mike's >>>>> suggestion: root isn't special. >>>> >>>> Then in fact there is nothing to oppose. You've just said yourself tha= >> t root is mounted first read-only. As Mike already said, it is remounted r= >> /w in userland later in the boot process. I just re-checked the code, beca= >> use I only had a vague recollection of all this, and can confirm. >>>> >>>> I mentioned the need to modify '/etc/loader.conf' as a possible consequ= >> ence, not as a goal. Given what we have established, there is no need to c= >> hange it at all. >>>> >>>> The root FS is thus in no way more special in the sysctl proposal than = >> with Mike's (assuming it doesn't rely on sysctl), this is an independent pr= >> operty due to the boot process design. >>> >>> With the possible exception that the sysctl mechanism might then have to >>> apply to mount update. >>> >>>>>>> It also seems undesirable to add a sysctl to control a value that th= >> e >>>>>>> kernel doesn't use. >>>>>> >>>>>> The kernel has to use it to guarantee some uniform behavior irrespect= >> ive >>>>>> of the mount being performed through mount(8) or by a direct call to >>>>>> nmount(2). I think this consistency is important. Perhaps all >>>>>> auto-mounters and mount helpers always run mount(8) and never deal wi= >> th >>>>>> nmount(2), I would have to check (I seem to remember that, a long tim= >> e ago, >>>>>> when nmount(2) was introduced as an enhancement over mount(2), the st= >> ance >>>>>> was that applications should use mount(8) and not nmount(2) directly)= >> . >>>>>> Even if there were no obvious callers of nmount(2), I would be a bit >>>>>> uncomfortable with this discrepancy in behavior. >>> >>> Based on a quick git grep, it looks like most of the things in base use >>> nmount(2), not mount(2). If they use mount(8), then it's not a problem >>> because mount(8) would be the first thing to get things right. If, by >>> mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8= >> ) >>> uses them rather than the reverse. I also don't remember any admonition >>> not to use nmount(2). mount(8) has a limited set of file system types th= >> at >>> it handles directly. >>> >>>>> I disagree. I think Mike's suggestion was better and dealt with POLA a= >> nd >>>>> POLA breaking in a sane way. If the default is applied universally in = >> user >>>>> space, then we need not change the kernel at all. >>>> >>>> I think applying the changes to userland only is really a bad idea. I'= >> ve already explained why, but going to do it again in case you missed that.= >> If you have counter-arguments, fine, but I would like to see them. >>>> >>>> Changing userland only causes a discrepancy between mount(8) and nmount= >> (2). Even if the project would take a stance that nmount(2) is not a publi= >> c API and mount(8) must always be used, the system call will still be there= >> And if it's not supposed to be used, what's the problem with changing it= >> as well? >>> >>> I don't think that stance has been taken; nmount(2) is certainly document= >> ed. >>> But I think that user level changes are required in both cases. First, f= >> or >>> the kernel to do the right thing, it needs to know if either noatime or a= >> time >>> has been specified explicitly, or if the default should apply. Otherwise= >> , the >>> kernel can only force noatime to be used in all cases or none, which I be= >> lieve >>> is a non-starter. Second, for anything using mount(2), the flags include= >> only >>> MNT_NOATIME, which can only include two options, not the required three. = >> It >>> would be possible to add another flag meaning to actually use the state o= >> f the >>> MNT_NOATIME flag, b
Re: noatime on ufs2
On 30 Jan 2024, at 3:00, Olivier Certner wrote:
> Hi Warner,
>
>> I strongly oppose this notion to control this from loader.conf. Root is
>> mounted read-only, so it doesn't matter. That's why I liked Mike's
>> suggestion: root isn't special.
>
> Then in fact there is nothing to oppose. You've just said yourself that root
> is mounted first read-only. As Mike already said, it is remounted r/w in
> userland later in the boot process. I just re-checked the code, because I
> only had a vague recollection of all this, and can confirm.
>
> I mentioned the need to modify '/etc/loader.conf' as a possible consequence,
> not as a goal. Given what we have established, there is no need to change it
> at all.
>
> The root FS is thus in no way more special in the sysctl proposal than with
> Mike's (assuming it doesn't rely on sysctl), this is an independent property
> due to the boot process design.
With the possible exception that the sysctl mechanism might then have to
apply to mount update.
>>>> It also seems undesirable to add a sysctl to control a value that the
>>>> kernel doesn't use.
>>>
>>> The kernel has to use it to guarantee some uniform behavior irrespective
>>> of the mount being performed through mount(8) or by a direct call to
>>> nmount(2). I think this consistency is important. Perhaps all
>>> auto-mounters and mount helpers always run mount(8) and never deal with
>>> nmount(2), I would have to check (I seem to remember that, a long time ago,
>>> when nmount(2) was introduced as an enhancement over mount(2), the stance
>>> was that applications should use mount(8) and not nmount(2) directly).
>>> Even if there were no obvious callers of nmount(2), I would be a bit
>>> uncomfortable with this discrepancy in behavior.
Based on a quick git grep, it looks like most of the things in base use
nmount(2), not mount(2). If they use mount(8), then it's not a problem
because mount(8) would be the first thing to get things right. If, by
mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8)
uses them rather than the reverse. I also don't remember any admonition
not to use nmount(2). mount(8) has a limited set of file system types that
it handles directly.
>> I disagree. I think Mike's suggestion was better and dealt with POLA and
>> POLA breaking in a sane way. If the default is applied universally in user
>> space, then we need not change the kernel at all.
>
> I think applying the changes to userland only is really a bad idea. I've
> already explained why, but going to do it again in case you missed that. If
> you have counter-arguments, fine, but I would like to see them.
>
> Changing userland only causes a discrepancy between mount(8) and nmount(2).
> Even if the project would take a stance that nmount(2) is not a public API
> and mount(8) must always be used, the system call will still be there. And
> if it's not supposed to be used, what's the problem with changing it as well?
I don't think that stance has been taken; nmount(2) is certainly documented.
But I think that user level changes are required in both cases. First, for
the kernel to do the right thing, it needs to know if either noatime or atime
has been specified explicitly, or if the default should apply. Otherwise, the
kernel can only force noatime to be used in all cases or none, which I believe
is a non-starter. Second, for anything using mount(2), the flags include only
MNT_NOATIME, which can only include two options, not the required three. It
would be possible to add another flag meaning to actually use the state of the
MNT_NOATIME flag, but that would require user-level changes. Third, if I
understand correctly, mount(8) parses the options and condenses the standard
boolean options like {,no}atime into a bit, preserving the last option
specified. E.g. if the fstab lists noatime for a file system, and "mount -o
atime ..." is given on the command line, noatime will not be included in
the kernel options. The kernel can't tell why, whether nothing was specified
or the option was explicit. In theory, three states can be encoded using
nmount; options could include "atime", "noatime", or neither. But that's
not what the current user level does, so changes are required. Given that,
it makes the most sense to have mount(8) and others to incorporate the
default into their operation, and just give the kernel the answer. btw,
see mntopts(3) for where this code would go.
> Second, we can control what is in the base system, but not other
> applications, so we can't really prevent nmount(2) to be used.
>
> Some of the goals of my proposal include to simplifying things, both in terms
> of administration but also in terms of t
Re: noatime on ufs2
Not responding to a specific message, but following up on the thread:
I am not sure a sysctl is a good mechanism for setting the mount default,
especially if it is to be set via the kernel environment from
/boot/loader.conf. That's an obscure place to find file system defaults.
It also seems undesirable to add a sysctl to control a value that the
kernel doesn't use. Instead, I'd like to propose that the default be
specified in a new entry in /etc/fstab, where it would be much more obvious.
For example, a line could be placed at the beginning like:
# DeviceMountpoint FStype Options
default nonedefault noatime,...
It could be retrieved with getfsspec("default") in the fs_mnntops field.
I wouldn't include this entry when iterating through the whole file with
getfsent() to avoid confusing existing programs. Then mount, and other
utilities such as zfs create, could check it explicitly. It should be
placed in /etc/fstab when it is created: by bsdinstall when it is used,
preferably by having the user select this explicitly, but probably with
noatime being the default. It would be in the pre-configured fstab used
for VM images and SD card images. Anyone building a root file system by
hand would have to deal with this to set a default.
Note that the root file system is mounted specially in the kernel, but the
noatime option doesn't need to be set at first while the root is read-only.
It could be updated by mount when remounting read-write from the startup
scripts.
I would then have the mount program look up and apply the default for things
like mounting a file system manually. Perhaps it could have a -D option
to ignore defaults, e.g. for scripts that don't want to be subject to local
settings.
It would be plausible to set the default(s) in rc.conf instead, although
that is more convenient for shell scripts than C programs. It would be
possible to read output from something like "sysrc filesystem_defaults".
It would also not be as obvious when setting or checking file system
configuration.
btw, I think there is consensus that noatime is the most useful setting for
most systems and users. However, I don't think there is consensus that the
default should be changed for things like mount with no options. I think
that putting a default somewhere fairly obvious could make it more palatable
(less POLA violation). Opinions may vary, though.
Mike
Re: Removing fdisk and bsdlabel (legacy partition tools)
On 24 Jan 2024, at 12:50, Rodney W. Grimes wrote: >> On Wed, Jan 24, 2024 at 8:45?AM Ed Maste wrote: >> >>> MBR (PC BIOS) partition tables were historically maintained with >>> fdisk(8), but gpart(8) has long been the preferred method for working >>> with partition tables of all types. fdisk has been declared as >>> obsolete in the man page since 2015. Similarly BSD disklabels were >>> historically maintained with bsdlabel. It does not yet have a >>> deprecation notice - I have proposed a man page addition in >>> https://reviews.freebsd.org/D43563. > > man page additions are not going to reach the people who may be > using this. This should be a gonein(15) added to the binary. > I also suspect that all of the people doing ufs installs > are doing so via bsdlabel, not gpart. I suspect that more ufs installs are done with bsdinstall than with bsdlabel. The interactive mode is much easier to use than bsdlabel -e, where you have to do your own arithmetic. A couple of wrappers around bsdinstall could make it a much better replacement for bsdlabel -e, etc. (No criticism of bsdlabel, but it's so old I don't remember if I wrote it; I think I did.) I have a number of test systems using ufs, and I do my modifications with gpart, which accepts humanized numbers and does the arithmetic. Mike
Re: noatime on ufs2
On 11 Jan 2024, at 7:30, Miroslav Lachman wrote: > On 11/01/2024 09:54, Tomoaki AOKI wrote: >> On Thu, 11 Jan 2024 08:36:24 +0100 >> Alexander Leidinger wrote: > > [..] > >>> There's one possibility which nobody talked about yet... changing the >>> default to noatime at install time in fstab / zfs set. >>> >>> I fully agree to not violate POLA by changing the default to noatime in >>> any FS. I always set noatime everywhere on systems I take care about, no >>> exceptions (any user visible mail is handled via maildir/IMAP, not >>> mbox). I haven't made up my mind if it would be a good idea to change >>> bsdinstall to set noatime (after asking the user about it, and later >>> maybe offer the possibility to use relatime in case it gets >>> implemented). I think it is at least worthwile to discuss this >>> possibility (including what the default setting of bsdinstall should be >>> for this option). > > [..] > >> A different aspect of view. >> Nowadays, storages are quickly moving from HDD, aka spinning rust, to >> SSD. >> And SSD has a risk of sudden-death of wearing out. In ancient days, HDD >> dies not suddenly and at least some cases admins could have time to >> replace suspicious drives. But SSD dies basically suddenly. >> >> IMHO, this could be a valid reason to violate POLA. In limited use >> cases, atime is useful, at the cost of amplified write accesses. >> But in most cases, it doesn't have positive functionality nowadays. >> >> Anyway, we should have time to discuss whether it should be done or not >> until upcoming stable/15 branch. stable/14 is already here and it >> wouldn't be a good thing to MFC. Only *.0-RELEASE should be the point >> to introduce this, unlike discussion about vi and ee on forums. > > The default values change over time as the needs of people, programs and > hardware change. Many values for sysctls changed over time. > If "noatime" can help people to not trash SSD / SD storage, I can imagine > that bsdinstall will detect the storage type (simple guess can be made by > diskinfo -v) and offer a "noatime" option that the user can check/uncheck. > This option can be pre-selected for flash based storage. > I don't care defaults for my-self, I can change them, but sane defaults > should be beneficial for new users without much background knowledge. > > Kind regards > Miroslav Lachman I like the idea of an option in bsdinstall, but I don't think it is necessary to check the storage type. It could simply default to noatime. I think we should automatically use noatime on SD card images (where bsdinstall doesn't get used). Separately, I think a relatime option would be a good compromise, and I would probably use it. Mike
Re: Proposal: Disable compression of newsyslog by default
On 25 Dec 2023, at 2:12, Xin Li wrote: > On 2023-12-23 14:17, Mike Karels wrote: >> On 23 Dec 2023, at 15:23, Craig Leres wrote: >> >>> On 12/23/23 06:52, Konstantin Belousov wrote: >>>> This is strange change at best. I have no opinion about the disabling >>>> of compression of the rotated logs by default, but we already have knobs >>>> to do that. Adding a knob that disables (or enables) other knobs to work >>>> is weird. >>> >>> I totally agree. This moves the compression knob from the config file to >>> the command line. And what if the user wants some but not all files to be >>> compressed? Or wants to use different compression with different log files? >> >> Another possibility would be to introduce some simple form of variables in >> newsyslog.conf, replacing J by a variable reference, with the variable >> being set near the beginning. E.g. >> >> V=zstd (or just V= for none?) >> ... $V >> ... $V >> >> Then there would be one global change, and much easier changing of the >> default. >> >> It would also be possible to add /etc/newsyslog.local.conf at the >> beginning, and set variables there, making changes to the default file less >> painful in the future. > > I've implemented support of in https://reviews.freebsd.org/D43174 > . Let's don't add macro or variables to newsyslog.conf as it would be a > nightmare for compatibility with other newsyslog variants of other BSDs. Looks like there is a fair amount of divergence from NetBSD, at least; I don't think compatibility with other BSDs is a significant factor. Compatibility with older FreeBSD is a bigger consideration. An intermediate possibility would be to add an option letter for the default compression to be used in each entry, and use to set that default. It seems wrong to attempt to use zstd with option letters like J; it's contradictory, if not confusing. It's still a knob to disable other knobs, although it is in the right file. Mike
Re: Proposal: Disable compression of newsyslog by default
On 23 Dec 2023, at 15:23, Craig Leres wrote: > On 12/23/23 06:52, Konstantin Belousov wrote: >> This is strange change at best. I have no opinion about the disabling >> of compression of the rotated logs by default, but we already have knobs >> to do that. Adding a knob that disables (or enables) other knobs to work >> is weird. > > I totally agree. This moves the compression knob from the config file to the > command line. And what if the user wants some but not all files to be > compressed? Or wants to use different compression with different log files? Another possibility would be to introduce some simple form of variables in newsyslog.conf, replacing J by a variable reference, with the variable being set near the beginning. E.g. V=zstd (or just V= for none?) ... $V ... $V Then there would be one global change, and much easier changing of the default. It would also be possible to add /etc/newsyslog.local.conf at the beginning, and set variables there, making changes to the default file less painful in the future. >> If you want to change the compression, update the default configuration file. > > I also think this is the best approach. > > Given the current freebsd-update workflow, users will get to deal with > changes to the default newsyslog.conf via mergemaster. > > And having converted a number of systems from newsyslog compression to zfs > compression, just changing the config file is not the only change needed, > users will still need to compress/uncompress existing log files. Good point. Although newsyslog could be smart enough to recognize alternate suffixes (or none), and rotate the files anyway. Short of that, this suggests that a new default config file should specify bzip2, but it would be easy to localize. Mike
Re: NFS exports of ZFS snapshots broken
On 18 Nov 2023, at 21:19, Rick Macklem wrote: > On Sat, Nov 18, 2023 at 4:43 PM Mike Karels wrote: >> >> On 18 Nov 2023, at 17:23, Rick Macklem wrote: >> >>> On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote: >>>> >>>> On 18 Nov 2023, at 15:58, Rick Macklem wrote: >>>> >>>>> On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem >>>>> wrote: >>>>>> >>>>>> On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: >>>>>>> >>>>>>> On 17 Nov 2023, at 22:14, Mike Karels wrote: >>>>>>> >>>>>>>> On 17 Nov 2023, at 21:24, Rick Macklem wrote: >>>>>>>> >>>>>>>>> Most of the changes in stable/13 that are not in releng/13.2 >>>>>>>>> are the "make it work in a jail" stuff. Unfortunately, they are >>>>>>>>> a large # of changes (mostly trivial edits adding vnet macros), >>>>>>>>> but it also includes export check changes. >>>>>>>>> >>>>>>>>> I have attached a trivial patch that I think disables the export >>>>>>>>> checks for jails. If either of you can try it and see if it fixes >>>>>>>>> the problem, that would be great. >>>>>>>>> (Note that this is only for testing, although it probably does not >>>>>>>>> matter unless you are running nfsd(8) in vnet jails.) >>>>>>>> >>>>>>>> Yes, I can see snapshots with the patch. This system is just a test >>>>>>>> system that doesn't normally run ZFS or NFS, so no problem messing >>>>>>>> with permissions. It's a bhyve VM, so I just added a small disk and >>>>>>>> enabled ZFS for testing. >>>>>>> >>>>>>> btw, you might try to get mm@ or maybe mav@ to help out from the ZFS >>>>>>> side. It must be doing something differently inside a snapshot than >>>>>>> outside, maybe with file handles or something like that. >>>>>> Yes. I've added freebsd-current@ (although Garrett is not on it, he is >>>>>> cc'd) and these guys specifically... >>>>>> >>>>>> So, here's what appears to be the problem... >>>>>> Commit 88175af (in main and stable/13, but not 13.2) added checks for >>>>>> nfsd(8) running in jails by filling in mnt_exjail with a reference to >>>>>> the cred >>>>>> used when the file system is exported. >>>>>> When mnt_exjail is found NULL, the current nfsd code assumes that there >>>>>> is no access allowed for the mount. >>>>>> >>>>>> My vague understanding is that when a ZFS snapshot is accessed, it is >>>>>> "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that >>>>>> mnt_exjail is NULL as a result. >>>>>> Since I do not know the ZFS code and don't even have an easy way to >>>>>> test this (thankfully Mike can test easily), I do not know what to do >>>>>> from >>>>>> here? >>>>>> >>>>>> Is there a "struct mount" constructed for this pseudo mount >>>>>> (or it actually appears to be the lookup of ".." that fails, so it >>>>>> might be the parent of the snapshot subdir?)? >>>>>> >>>>>> One thought is that I can check to see if the mount pointer is in the >>>>>> mountlist (I don't think the snapshot's mount is in the mountlist) and >>>>>> avoid the jail test for this case. This would assume that snapshots are >>>>>> always within the file system(s) exported via that jail (which includes >>>>>> the case of prison0, of course), so that they do not need a separate >>>>>> jail check. >>>>>> >>>>>> If this doesn't work, there will need to be some sort of messing about >>>>>> in ZFS to set mnt_exjail for these. >>>>> Ok, so now onto the hard part... >>>>> Thanks to Mike and others, I did create a snapshot under .zfs and I can >>>>> see the problem. It is that mnt_exjail == NULL. >>>>> Now, is there a way that this "struct mount" can be recognized as >>>>> "special"
Re: NFS exports of ZFS snapshots broken
On 18 Nov 2023, at 17:23, Rick Macklem wrote: > On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote: >> >> On 18 Nov 2023, at 15:58, Rick Macklem wrote: >> >>> On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem wrote: >>>> >>>> On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: >>>>> >>>>> On 17 Nov 2023, at 22:14, Mike Karels wrote: >>>>> >>>>>> On 17 Nov 2023, at 21:24, Rick Macklem wrote: >>>>>> >>>>>>> Most of the changes in stable/13 that are not in releng/13.2 >>>>>>> are the "make it work in a jail" stuff. Unfortunately, they are >>>>>>> a large # of changes (mostly trivial edits adding vnet macros), >>>>>>> but it also includes export check changes. >>>>>>> >>>>>>> I have attached a trivial patch that I think disables the export >>>>>>> checks for jails. If either of you can try it and see if it fixes >>>>>>> the problem, that would be great. >>>>>>> (Note that this is only for testing, although it probably does not >>>>>>> matter unless you are running nfsd(8) in vnet jails.) >>>>>> >>>>>> Yes, I can see snapshots with the patch. This system is just a test >>>>>> system that doesn't normally run ZFS or NFS, so no problem messing >>>>>> with permissions. It's a bhyve VM, so I just added a small disk and >>>>>> enabled ZFS for testing. >>>>> >>>>> btw, you might try to get mm@ or maybe mav@ to help out from the ZFS >>>>> side. It must be doing something differently inside a snapshot than >>>>> outside, maybe with file handles or something like that. >>>> Yes. I've added freebsd-current@ (although Garrett is not on it, he is >>>> cc'd) and these guys specifically... >>>> >>>> So, here's what appears to be the problem... >>>> Commit 88175af (in main and stable/13, but not 13.2) added checks for >>>> nfsd(8) running in jails by filling in mnt_exjail with a reference to the >>>> cred >>>> used when the file system is exported. >>>> When mnt_exjail is found NULL, the current nfsd code assumes that there >>>> is no access allowed for the mount. >>>> >>>> My vague understanding is that when a ZFS snapshot is accessed, it is >>>> "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that >>>> mnt_exjail is NULL as a result. >>>> Since I do not know the ZFS code and don't even have an easy way to >>>> test this (thankfully Mike can test easily), I do not know what to do from >>>> here? >>>> >>>> Is there a "struct mount" constructed for this pseudo mount >>>> (or it actually appears to be the lookup of ".." that fails, so it >>>> might be the parent of the snapshot subdir?)? >>>> >>>> One thought is that I can check to see if the mount pointer is in the >>>> mountlist (I don't think the snapshot's mount is in the mountlist) and >>>> avoid the jail test for this case. This would assume that snapshots are >>>> always within the file system(s) exported via that jail (which includes >>>> the case of prison0, of course), so that they do not need a separate >>>> jail check. >>>> >>>> If this doesn't work, there will need to be some sort of messing about >>>> in ZFS to set mnt_exjail for these. >>> Ok, so now onto the hard part... >>> Thanks to Mike and others, I did create a snapshot under .zfs and I can >>> see the problem. It is that mnt_exjail == NULL. >>> Now, is there a way that this "struct mount" can be recognized as "special" >>> for snapshots, so I can avoid the mnt_exjail == NULL test? >>> (I had hoped that "mp->mnt_list.tqe_prev" would be NULL, but that is not >>> the case.) >> >> Dumb question, is the mount point (mp presumably) different between the >> snapshot and the main file system? > Not a dump question and the answer is rather interesting... > It is "sometimes" or "usually" according to my printf(). > It seems that when you first "cd where mnt_exjail == NULL.. Then when you look at directories within the > snapshot, you get the mp of the file system that .zfs exists in, which does > have mnt_exjail set non-NULL. > > There is this snipp
Re: [Intel AlderLake] Read files to FAT32 or UFS partition cause data corrupt due to P-Core-Core
On 18 Sep 2023, at 10:38, Michael Butler wrote: > On 8/8/23 13:50, Michael Butler wrote: >> On 8/8/23 10:56, Tomoaki AOKI wrote: >>> On Tue, 8 Aug 2023 17:02:32 +0300 >>> Konstantin Belousov wrote: >> >> [ .. snip .. ] >> >>>> The workaround is switched on automatically, when kernel detects 'small >>>> cores' >>>> reported by CPUID. >>> >>> If I read the code correctly, vm.pmap.pcid_invlpg_workaround >>> (precicely, the corresponding variable) is set to non-zero when the >>> workaround is enabled. Not sure it was detected correctly at the >>> original reporter's environment, but forcibly setting the tunable to 1 >>> didn't reported to help sufficiently. >>> Currently, only setting tunable vm.pmap.pcid_enabled to 0 could help. >> >> I'm seeing similar stability problems on an N95-based device. This too is an >> Alderlake-N device with only E-cores although I'm running it with a >> compilation with CPUTYPE=tremont .. from an older, verbose start-up .. >> >> PPIM 0: PA=0x40, VA=0x8271, size=0x1d5000, mode=0x1 >> pmap: large map 8 PML4 slots (4096 GB) >> VT(efifb): resolution 800x600 >> Preloaded elf kernel "/boot/kernel.new/kernel" at 0x8234e000. >> Preloaded boot_entropy_cache "/boot/entropy" at 0x82357d08. >> Preloaded cpu_microcode "/boot/firmware/intel-ucode.bin" at >> 0x82357d60. >> Preloaded hostuuid "/etc/hostid" at 0x82357dc0. >> Preloaded TSLOG data "TSLOG" at 0x82357e10. >> CPU: Intel(R) N95 (1689.60-MHz K8-class CPU) >> Origin="GenuineIntel" Id=0xb06e0 Family=0x6 Model=0xbe Stepping=0 >> >> Features=0xbfebfbff >> >> Features2=0x7ffafbbf >> AMD Features=0x2c100800 >> AMD Features2=0x121 >> Structured Extended >> Features=0x239ca7eb >> Structured Extended >> Features2=0x98c007bc >> Structured Extended >> Features3=0xfc184410 >> XSAVE Features=0xf >> IA32_ARCH_CAPS=0x180fd6b >> VT-x: Basic Features=0x3da0500 >> Pin-Based Controls=0xff >> Primary Processor >> Controls=0xfffbfffe >> Secondary Processor >> Controls=0x75d7fff >> Exit Controls=0x3da0500 >> Entry Controls=0x3da0500 >> EPT Features=0x6f34141 >> VPID Features=0xf01 >> TSC: P-state invariant, performance statistics >> 64-Byte prefetching >> L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line >> real memory = 17179869184 (16384 MB) >> Physical memory chunk(s): >> 0x0001 - 0x0009dfff, 581632 bytes (142 pages) >> 0x0009f000 - 0x0009, 4096 bytes (1 pages) >> 0x0010 - 0x5fff, 1609564160 bytes (392960 pages) >> 0x62401000 - 0x7264dfff, 270848000 bytes (66125 pages) >> 0x75fff000 - 0x75ff, 4096 bytes (1 pages) >> 0x00011000 - 0x000462497fff, 14533881856 bytes (3548311 pages) >> 0x00047fa0 - 0x00047fb68fff, 1478656 bytes (361 pages) >> avail memory = 16363008000 (15604 MB) >> CPU microcode: updated from 0xc to 0x10 > > With the most recent microcode update, this device reports .. > > CPU microcode: updated from 0xc to 0x11 > > .. and is now stable with vm.pmap.pcid_enabled=0, > vm.pmap.pcid_invlpg_workaround=1, and CPUTYPE?=alderlake set in > /etc/make.conf over multiple full system builds. > > I have not tested with vm.pmap.pcid_invlpg_workaround=0. I believe that vm.pmap.pcid_invlpg_workaround does not matter if vm.pmap.pcid_enabled=0. Enabling the workaround or disabling pcid should be basically the same for this CPU, so I don't understand why that isn't true. It might be interesting to test with pcid enabled with the new microcode, although I don't see why that would affect the results (pcid should still not be used on any CPU). The CPUTYPE for the compiler should not affect the pcid vm issues, just change the optimization by the compiler. Mike >> On start-up, vm.pmap.pcid_invlpg_workaround=1 but seemingly random faults >> still occurred under load, for example, 'make buildworld'. Apparent misreads >> of source-files resulting in syntax errors were the most common symptom. >> Compilation reattempts (mostly) succeed. >> >> Initially, I put this down to an inadequate power-supply but setting >> vm.pmap.pcid_enabled=0 seems to have stabilised it. >> >> I guess there's another dragon in there .. :-( >> >> Michael
Re: Looks like the kyua zfs tests likely are not used on aarch64 or other contexts with unsigned char
On 10 Sep 2023, at 2:31, Mark Millard wrote:
> kyua tests that use the:
>
> /usr/tests/sys/cddl/zfs/bin/mkfile
>
> program like so (for example):
>
> mkfile 500M /testpool.1861/bigfile.0
>
> (which should be valid) end up with mkfile
> instead reporting:
>
> Standard error:
> Usage: mkfile [-nv] [e|p|t|g|m|k|b] ...
>
> which prevent the kyua test involved from working.
>
> Turns out this is from expecting char to be always
> signed (so a -1 vs. 255 distinction, here in an
> aarch64 context):
>
> . . .
> (gdb) list
> 179 /* Options. */
> 180 while ((ch = getopt(argc, argv, "nv")) != -1) {
> 181 switch (ch) {
> 182 case 'n':
> 183 nofill = 1;
> 184 break;
> 185 case 'v':
> (gdb) print ch
> $16 = 255 '\377'
> (gdb) print/x -1
> $17 = 0x
> (gdb) print/x ch
> $18 = 0xff
> . . .
>
> With the mix of unsigned and signed it ends up
> being a 0xffu != 0xu test, which is
> always true.
mkfile is broken. getopt returns an int, and -1 on end.
It never returns 0xff. But mkfile declares ch as char,
which truncates the return value -1. ch is a bad (misleading)
variable name, although getopt(3) uses it as well (but declared
as int).
Mike
> So the switch is reached as if a "-" prefix was
> present (that is not). Then the "option" is classified
> as invalid and the usage message is produced.
>
> Apparently no one had noticed. That, in turn, suggests a
> lack of inspected testing on aarch64, powerpc64,
> powerpc64le, armv7, powerpc, and powerpcspe. That, in
> turn, suggests that kyua test inspection for the likes
> of aarch64 is not historically a part of the release
> process for openzfs or for operating systems that include
> openzfs.
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
On 13 Aug 2023, at 15:19, Juraj Lutter wrote:
>> On 13 Aug 2023, at 21:13, Mark Millard wrote:
>>
>> But the offical CI builds on amd64 do not have the problem.
>>
>> We still have not found what is different about your context from the
>> standard context used for CI builds and snapshot builds, all of which
>> have worked find building on amd64 to target aarch64 with armv7 support.
>
> My src.conf:
>
> WITHOUT_PROFILE=yes
> WITHOUT_TESTS=yes
> WITHOUT_STATIC=yes
>
> WITHOUT_LLVM_TARGET_ALL=yes
>
> .if "${TARGET}" == "arm64" && "${TARGET_ARCH}" == "aarch64"
> KERNCONF?=GENERIC-MMCCAM
> REPODIR?=/data/poudriere/packages/pkgbase
> MODULES_EXTRA="rpi_ft5406"
> WITH_LLVM_TARGET_AARCH64=yes
> WITH_LLVM_TARGET_ARM=yes
> .else
> KERNCONF?=GENERIC-NODEBUG
> REPODIR?=/data/poudriere/packages/pkgbase
> WITH_LLVM_TARGET_AARCH64=yes
> WITH_LLVM_TARGET_X86=yes
> .endif
I'm guessing that the problem is in the last section. When building
to run on amd64, arm may not be included. I'd try adding
WITH_LLVM_TARGET_ARM=yes there as well.
Mike
> make.conf is empty, git workdir has `main’ checked out, without any
> modifications (git status reports clean workdir)
>
> otis
>
> —
> Juraj Lutter
> o...@freebsd.org
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
On 13 Aug 2023, at 10:00, Juraj Lutter wrote: >> On 13 Aug 2023, at 16:55, Mike Karels wrote: >> >> >> lib32 is not built until stage 4.3.1, after build and cross tools. I tested >> a build just now on amd64 with empty /usr/obj, and it worked (make -j$NCU >> buildworld TARGET=arm64 TARGET_ARCH=aarch64). However, the host was >> approximately at the level of ALPHA1, and the first lines of the output >> showed that a cross-compiler was not needed. However, my earlier builds >> that required a cross-compiler worked fine. >> > > Earlier builds worked for me as well. I use it for “make packages” that I use > to upgrade my RPi. > > It definitely worked on 20230712 when I did the build last time. That was before the lib32 addition went in (20230725). Mike >> Yes, lib32 is supposed to be built on aarch64 as of a few weeks ago. >> >>> So it seems that “native-xtools” and associated targets are not being built. >>> If I do “make TARGET=arm64 TARGET_ARCH=aarch64 native-xtools”, cross tools >>> are >>> being built and lib32 is built, in turn, also. >> >> I don't see native-xtools built either. but the build worked. >> >> Have you checked src.conf? > > Yes, I only have KERNCONF there. I will try with > eafd028327cee688b54bc526e088c2a3b98f94e0 backed out > to see if it will make any difference. > > otis > > > — > Juraj Lutter > o...@freebsd.org
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
On 13 Aug 2023, at 9:25, Juraj Lutter wrote: >> On 13 Aug 2023, at 14:42, Juraj Lutter wrote: >> >> Hi, >> >>> On 13 Aug 2023, at 00:17, Mike Karels wrote: >>> >>> On 12 Aug 2023, at 15:32, Juraj Lutter wrote: >>> >>> Did the buildworld start out by building a cross-compiler? >>> >>> Have you tried without meta mode? With a clean objdir, I don't see how >>> it would matter, but I'm not sure I've tried it. >>> >>> The ALPHA1 builds seem to have worked, but I think they run on arm64. >>> >> >> See here: https://files.wilbury.net/s/bJKKB5Kbta6DNqB for the full log. >> >> As I read it, lib32 is being built before crosscompiler. Is lib32 supposed >> to be built on aarch64? lib32 is not built until stage 4.3.1, after build and cross tools. I tested a build just now on amd64 with empty /usr/obj, and it worked (make -j$NCU buildworld TARGET=arm64 TARGET_ARCH=aarch64). However, the host was approximately at the level of ALPHA1, and the first lines of the output showed that a cross-compiler was not needed. However, my earlier builds that required a cross-compiler worked fine. Yes, lib32 is supposed to be built on aarch64 as of a few weeks ago. > So it seems that “native-xtools” and associated targets are not being built. > If I do “make TARGET=arm64 TARGET_ARCH=aarch64 native-xtools”, cross tools are > being built and lib32 is built, in turn, also. I don't see native-xtools built either. but the build worked. Have you checked src.conf? Mike > The commit I suspect that lead into this was > eafd028327cee688b54bc526e088c2a3b98f94e0 (there sees > to not be any other related changes fiddling with make targets). > > otis > > > — > Juraj Lutter > XMPP: juraj (at) lutter.sk > GSM: +421907986576
Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64
On 12 Aug 2023, at 15:32, Juraj Lutter wrote: > Hi, > > recent 14.0-ALPHA1 sources is giving an error: > > Building > /usr/obj/usr/src/arm64.aarch64/obj-lib32/lib/libssp_nonshared/libssp_nonshared.o > Building /usr/obj/usr/src/arm64.aarch64/obj-lib32/lib/libgcc_eh/int_util.o > error: unable to create target: 'No available targets are compatible with > triple "armv7-unknown-freebsd14.0-gnueabihf"' > 1 error generated. > error: unable to create target: 'No available targets are compatible with > triple "armv7-unknown-freebsd14.0-gnueabihf"' > *** [libssp_nonshared.o] Error code 1 > > Commandline: > make -j`sysctl -n hw.ncpu` WITH_META_MODE=1 TARGET=arm64 TARGET_ARCH=aarch64 > buildworld buildkernel > > The build runs in clean objdir, src git hash > 220427da0e9b2c1d8e964120becc17eb7524e46f > > Host runs 14.0-CURRENT 28d2e3b5dedf > > Am I missing something obvious? > Thanks. Did the buildworld start out by building a cross-compiler? Have you tried without meta mode? With a clean objdir, I don't see how it would matter, but I'm not sure I've tried it. The ALPHA1 builds seem to have worked, but I think they run on arm64. Mike > — > Juraj Lutter > o...@freebsd.org
Re: confusion about root partition causes panic during startup
Are you planning to commit the change to mountroot?
Mike
On 20 Jul 2023, at 21:37, Mike Karels wrote:
> Mateusz Guzik wrote:
>> On 7/20/23, Mike Karels wrote:
>>> I installed an additional NVME drive on a system, and then booted. It
>>> turns
>>> out that the new drive became nda0, renumbering the other drives. The
>>> loader
>>> found the correct partition to boot (the only choice), and loaded the
>>> kernel
>>> correctly. However, /etc/fstab still had the old name (nvd1p2), which is
>>> now drive 2. I expected it to drop into single user, but instead the
>>> system
>>> panicked in vfs_mountroot_shuffle trying to switch root devices (see
>>> below).
>>> It doesn't seem that having the wrong root device in /etc/fstab should
>>> cause
>>> a panic; it makes it harder to patch the system. I was unable to get the
>>> system to boot using boot-to-single-user or setting currdev, but I managed
>>> to remember doing "boot -a" from a loader prompt to get the system to ask
>>> the root device before mounting it. I can easily reproduce this to test.
>>> Probably the NDFREE_PNBUF() shouldn't happen if namei() returned an error.
>>>
>
>> ye, this should do it (untested):
>
>> diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c
>> index 956d29e3f084..85398ff781e4 100644
>> --- a/sys/kern/vfs_mountroot.c
>> +++ b/sys/kern/vfs_mountroot.c
>> @@ -352,13 +352,13 @@ vfs_mountroot_shuffle(struct thread *td, struct
>> mount *mpdevfs)
>> NDINIT(, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, fspath);
>> error = namei();
>> if (error) {
>> - NDFREE_PNBUF();
>> fspath = "/mnt";
>> NDINIT(, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE,
>> fspath);
>> error = namei();
>> }
>> if (!error) {
>> + NDFREE_PNBUF();
>> vp = nd.ni_vp;
>> error = (vp->v_type == VDIR) ? 0 : ENOTDIR;
>> if (!error)
>> @@ -376,7 +376,6 @@ vfs_mountroot_shuffle(struct thread *td, struct
>> mount *mpdevfs)
>> } else
>> vput(vp);
>> }
>> - NDFREE_PNBUF();
>
>> if (error)
>> printf("mountroot: unable to remount previous root "
>> @@ -387,6 +386,7 @@ vfs_mountroot_shuffle(struct thread *td, struct
>> mount *mpdevfs)
>> NDINIT(, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, "/dev");
>> error = namei();
>> if (!error) {
>> + NDFREE_PNBUF();
>> vp = nd.ni_vp;
>> error = (vp->v_type == VDIR) ? 0 : ENOTDIR;
>> if (!error)
>
> That was missing the last change, and tabs were expanded. I put it in
> by hand, and the patch works, at least to avoid this panic. It still
> insisted on remounting root on nda1p2, which is not a root file system.
> Remounting /dev still failed without panicking, then it panicked because
> there was no /sbin/init. Apparently it is necessary to use "boot -a"
> in this situation. Too bad the loader option menu doesn't include that.
>
> Just to be clear what I tested, my patch follows.
>
> Mike
>
> diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c
> index 956d29e3f084..b08b2a3200f8 100644
> --- a/sys/kern/vfs_mountroot.c
> +++ b/sys/kern/vfs_mountroot.c
> @@ -352,13 +352,13 @@ vfs_mountroot_shuffle(struct thread *td, struct mount
> *mpdevfs)
> NDINIT(, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, fspath);
> error = namei();
> if (error) {
> - NDFREE_PNBUF();
> fspath = "/mnt";
> NDINIT(, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE,
> fspath);
> error = namei();
> }
> if (!error) {
> + NDFREE_PNBUF();
> vp = nd.ni_vp;
> error = (vp->v_type == VDIR) ? 0 : ENOTDIR;
> if (!error)
> @@ -376,7 +376,6 @@ vfs_mountroot_shuffle(struct thread *td, struct mount
> *mpdevfs)
> } else
> vput(vp);
>
Re: confusion about root partition causes panic during startup
Mateusz Guzik wrote:
> On 7/20/23, Mike Karels wrote:
> > I installed an additional NVME drive on a system, and then booted. It
> > turns
> > out that the new drive became nda0, renumbering the other drives. The
> > loader
> > found the correct partition to boot (the only choice), and loaded the
> > kernel
> > correctly. However, /etc/fstab still had the old name (nvd1p2), which is
> > now drive 2. I expected it to drop into single user, but instead the
> > system
> > panicked in vfs_mountroot_shuffle trying to switch root devices (see
> > below).
> > It doesn't seem that having the wrong root device in /etc/fstab should
> > cause
> > a panic; it makes it harder to patch the system. I was unable to get the
> > system to boot using boot-to-single-user or setting currdev, but I managed
> > to remember doing "boot -a" from a loader prompt to get the system to ask
> > the root device before mounting it. I can easily reproduce this to test.
> > Probably the NDFREE_PNBUF() shouldn't happen if namei() returned an error.
> >
> ye, this should do it (untested):
> diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c
> index 956d29e3f084..85398ff781e4 100644
> --- a/sys/kern/vfs_mountroot.c
> +++ b/sys/kern/vfs_mountroot.c
> @@ -352,13 +352,13 @@ vfs_mountroot_shuffle(struct thread *td, struct
> mount *mpdevfs)
> NDINIT(, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, fspath);
> error = namei();
> if (error) {
> - NDFREE_PNBUF();
> fspath = "/mnt";
> NDINIT(, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE,
> fspath);
> error = namei();
> }
> if (!error) {
> + NDFREE_PNBUF();
> vp = nd.ni_vp;
> error = (vp->v_type == VDIR) ? 0 : ENOTDIR;
> if (!error)
> @@ -376,7 +376,6 @@ vfs_mountroot_shuffle(struct thread *td, struct
> mount *mpdevfs)
> } else
> vput(vp);
> }
> - NDFREE_PNBUF();
> if (error)
> printf("mountroot: unable to remount previous root "
> @@ -387,6 +386,7 @@ vfs_mountroot_shuffle(struct thread *td, struct
> mount *mpdevfs)
> NDINIT(, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, "/dev");
> error = namei();
> if (!error) {
> + NDFREE_PNBUF();
> vp = nd.ni_vp;
> error = (vp->v_type == VDIR) ? 0 : ENOTDIR;
> if (!error)
That was missing the last change, and tabs were expanded. I put it in
by hand, and the patch works, at least to avoid this panic. It still
insisted on remounting root on nda1p2, which is not a root file system.
Remounting /dev still failed without panicking, then it panicked because
there was no /sbin/init. Apparently it is necessary to use "boot -a"
in this situation. Too bad the loader option menu doesn't include that.
Just to be clear what I tested, my patch follows.
Mike
diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c
index 956d29e3f084..b08b2a3200f8 100644
--- a/sys/kern/vfs_mountroot.c
+++ b/sys/kern/vfs_mountroot.c
@@ -352,13 +352,13 @@ vfs_mountroot_shuffle(struct thread *td, struct mount
*mpdevfs)
NDINIT(, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, fspath);
error = namei();
if (error) {
- NDFREE_PNBUF();
fspath = "/mnt";
NDINIT(, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE,
fspath);
error = namei();
}
if (!error) {
+ NDFREE_PNBUF();
vp = nd.ni_vp;
error = (vp->v_type == VDIR) ? 0 : ENOTDIR;
if (!error)
@@ -376,7 +376,6 @@ vfs_mountroot_shuffle(struct thread *td, struct mount
*mpdevfs)
} else
vput(vp);
}
- NDFREE_PNBUF();
if (error)
printf("mountroot: unable to remount previous root "
@@ -387,6 +386,7 @@ vfs_mountroot_shuffle(struct thread *td, struct mount
*mpdevfs)
NDINIT(, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, "/dev");
error = namei();
if (!error) {
+ NDFREE_PNBUF();
vp = nd.ni_vp;
error = (vp->v_type == VDIR) ? 0 : ENOTDIR;
confusion about root partition causes panic during startup
I installed an additional NVME drive on a system, and then booted. It turns
out that the new drive became nda0, renumbering the other drives. The loader
found the correct partition to boot (the only choice), and loaded the kernel
correctly. However, /etc/fstab still had the old name (nvd1p2), which is
now drive 2. I expected it to drop into single user, but instead the system
panicked in vfs_mountroot_shuffle trying to switch root devices (see below).
It doesn't seem that having the wrong root device in /etc/fstab should cause
a panic; it makes it harder to patch the system. I was unable to get the
system to boot using boot-to-single-user or setting currdev, but I managed
to remember doing "boot -a" from a loader prompt to get the system to ask
the root device before mounting it. I can easily reproduce this to test.
Probably the NDFREE_PNBUF() shouldn't happen if namei() returned an error.
Mike
Trying to mount root from ufs:/dev/nvd1p2 [rw]...
WARNING: WITNESS option enabled, expect reduced performance.
mountroot: unable to remount devfs under /dev (error 2)
panic: Assertion _ndp->ni_cnd.cn_pnbuf != NULL failed at
../../../kern/vfs_mountroot.c:416
cpuid = 19
time = 11
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe006d3bac40
vpanic() at vpanic+0x149/frame 0xfe006d3bac90
panic() at panic+0x43/frame 0xfe006d3bacf0
vfs_mountroot() at vfs_mountroot+0x1bf7/frame 0xfe006d3bae60
start_init() at start_init+0x23/frame 0xfe006d3baef0
fork_exit() at fork_exit+0x82/frame 0xfe006d3baf30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe006d3baf30
--- trap 0x5c035c02, rip = 0x680c680c680c680c, rsp = 0x1b6b1f6b1b6b1b6b, rbp =
0x4eb54eb54eb54eb5 ---
KDB: enter: panic
[ thread pid 1 tid 12 ]
Stopped at kdb_enter+0x32: movq$0,0xde7643(%rip)
Re: Does kyua based testing need some hazmat/bindings/_openssl.abi3.so related updating?: Undefined symbol "ERR_GET_FUNC"
On 10 Jul 2023, at 10:56, Mark Millard wrote: > The subject line's question was prompted by > . . ./hazmat/bindings/_openssl.abi3.so related notices > in a kyua report: > > # kyua report --verbose > --results-file=usr_obj_DESTDIRs_main-CA7-chroot_usr_tests.20230710-064632-752785 > 2>&1 | grep "Undefined symbol" | sort -u > +ImportError: > /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: > Undefined symbol "ERR_GET_FUNC" > ImportError: > /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: > Undefined symbol "ERR_GET_FUNC" > ImportError: > /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so: > Undefined symbol "ERR_GET_FUNC" > > It is possible that this is related to some oddities of my > context for this. But I figured I'd ask the general question > anyway. I haven't seen this. My v7 environments (chroot and /usr/lib32) have only libssl.so.3, not .111, so they must be using OpenSSL 3.0. Which version of kyua is this running (32 or 64 bit)? Mike > === > Mark Millard > marklmi at yahoo.com
Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot
On 7 Jul 2023, at 11:38, Mark Millard wrote: > On Jul 7, 2023, at 07:36, Mark Millard wrote: > >> On Jul 7, 2023, at 06:50, Mike Karels wrote: >> >>> On 7 Jul 2023, at 6:06, John F Carr wrote: >>> >>>> On Jul 6, 2023, at 20:42, Mike Karels wrote: >>>>> >>>>> >>>>> Thanks for isolating this. Let me know when you have the bug number. >>>>> I just tested a fix (the compat code drops the reference on the current >>>>> address space an extra time, probably freeing it). >>>>> >>>>> Mike >>> >>> The fix is in >>> https://cgit.freebsd.org/src/commit/?id=be30fd3ab2e8418a696e69f54a91a7e2db5962de. >>> >>>> The bug was introduced in January, 2022. It allows 32 bit binaries to >>>> crash a 64 bit system when COMPAT_FREEBSD32 is on. Test coverage of the >>>> buggy function (sysctl_kern_proc_vm_layout) was added at the same time. >>>> >>>> There should be routine runs of 32 bit test suites on 64 bit systems. >>>> Although i386 and armv7 are tier 2 systems, the tier 1 COMPAT_FREEBSD32 >>>> kernel code needs to be exercised. This bug was only discovered by >>>> manually running tests in the right environment, 17 months after automated >>>> testing could have discovered it. >>> >>> That is not so simple currently, as the shared libraries for the >>> test environment are not part of 32-bit compatibility package. >>> The required bits could be extracted from the corresponding 32-bit >>> build, but that isn't easy to automate. Fortunately, I think that >>> very few of the tests exercise any 32-bit-specific code paths. >> >> One way that I demonstrated this problem on an aarch64 system >> that supports aarch32/armv7 in user space was via the use of >> an official snapshot armv7 image. In my case I: >> >> A) dd'd the image to USB3 media (after downloading it) >> B) mounted the ufs file system on the media to a mount point > > I forgot to mention an important step: before chroot is > used, I preload various kernel modules that are used in > the Kyuafile tests --because the chroot'd activity will > not cause the loads of themsleves but will use the > modules if they have already been loaded. > >> C) used a chroot into that mount point to run the: >>"kyua test -k /usr/tests/Kyuafile" >> >> (I happened to do all that as root.) >> >> There may be viable alternatives to dd'ing to allow an analogy to >> (B) for (C) to use. I've not experimented with using a jail >> instead of a chroot. >> >> One can also install an armv7 world into a local directory tree >> and then use chroot (or analogous). >> >> How far off is an analogous sort of procedure from being reasonable >> to automate? It would be easier to use the packages rather than the full image (base.txz and tests.txz). But doing this as part of a CI setup would mean fetching things from a different source from the install image, and then of course doing various configuration. It's always a Small Matter of Programming. Doing a full chroot gets into some other problems, e.g. mdconfig doesn't currently work in compatibility mode. It doesn't seem that automating all this would yield much; it's hard enough to do manually. >> i386, of course, also has lib32 and independently testing that is >> a messier issue, including trying to use /usr/tests/Kyuafile based >> testing that avoids use of chroot (or analogous). I'm not claiming >> lib32 has as simple of a potential path to automated testing. I think the problem is essentially the same. A chroot could be used or a 32-bit library setup (which would test the libraries as well). >> I do not know if FreeBSD has powerpc64 hardware able to use a >> powerpc world directory tree analogously. Such hardware may be too >> old and otherwise problematical, making it not viable to automate >> testing. Powerpc supports 32-bit libraries, unlike arm (so far). Mike
Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot
On 7 Jul 2023, at 6:06, John F Carr wrote: > On Jul 6, 2023, at 20:42, Mike Karels wrote: >> >> >> Thanks for isolating this. Let me know when you have the bug number. >> I just tested a fix (the compat code drops the reference on the current >> address space an extra time, probably freeing it). >> >> Mike The fix is in https://cgit.freebsd.org/src/commit/?id=be30fd3ab2e8418a696e69f54a91a7e2db5962de. > The bug was introduced in January, 2022. It allows 32 bit binaries to crash > a 64 bit system when COMPAT_FREEBSD32 is on. Test coverage of the buggy > function (sysctl_kern_proc_vm_layout) was added at the same time. > > There should be routine runs of 32 bit test suites on 64 bit systems. > Although i386 and armv7 are tier 2 systems, the tier 1 COMPAT_FREEBSD32 > kernel code needs to be exercised. This bug was only discovered by manually > running tests in the right environment, 17 months after automated testing > could have discovered it. That is not so simple currently, as the shared libraries for the test environment are not part of 32-bit compatibility package. The required bits could be extracted from the corresponding 32-bit build, but that isn't easy to automate. Fortunately, I think that very few of the tests exercise any 32-bit-specific code paths. Mike
Re: For snapshot builds: armv7 chroot on aarch64 has kyua test -k /usr/tests/Kyuafile sys/kern/kern_copyin hung up [in getpid?], unkillable, prevents reboot
On 6 Jul 2023, at 18:53, John F Carr wrote:
> The hang is caused by the sysctl call in tests/sys/kern/kern_copyin.c. The
> function below hangs when called in a 32 bit ARM process running in a chroot
> environment on a 64 bit ARM system. I will write up a bug report.
>
> static int
> get_vm_layout(struct kinfo_vm_layout *kvm)
> {
> size_t len;
> int mib[4];
>
> mib[0] = CTL_KERN;
> mib[1] = KERN_PROC;
> mib[2] = KERN_PROC_VM_LAYOUT;
> mib[3] = getpid();
> len = sizeof(*kvm);
>
> return (sysctl(mib, nitems(mib), kvm, , NULL, 0));
> }
Thanks for isolating this. Let me know when you have the bug number.
I just tested a fix (the compat code drops the reference on the current
address space an extra time, probably freeing it).
Mike
Re: Surprise null root password
On 26 May 2023, at 21:28, bob prohaska wrote:
> It turns out all seven hosts in my cluster report
> a null password for root in /usr/src/etc/master.passwd:
> root::0:0::0:0:Charlie &:/root:/bin/sh
>
> Is that intentional?
Well, it has been that way in FreeBSD since 1993, and in BSD since
1980 (4.0BSD). I guess you would say that it is intentional. The
alternative would be to have a well-known password like root, but
then it wouldn’t be as obvious that a local password had not been
set.
Mike
> Thanks for reading,
>
> bob prohaska
Re: Surprise null root password
On 26 May 2023, at 12:35, bob prohaska wrote: > While going through normal security email from a Pi2 > running -current I was disturbed to find: > > Checking for passwordless accounts: > root::0:0::0:0:Charlie &:/root:/bin/sh > > The machine had locked up on a -j4 buildworld since > sending the mail, so it was taken off the net, power > cycled and started single-user. > > Sure enough, /etc/master.passwd contained a > null password for root, but the last modification > to the file was two weeks ago according to ls -l. > > Stranger still, when fsck'd and brought up multi-user, > the normal password was still honored and a null > password rejected for both regular and root account. > > AFAIK, /etc/master.passwd is _the_ password repository, > but clearly I'm wrong. /etc/master.passwd is the source, but the operational database is /etc/spwd.db. You should check the date on it as well. You can rebuild it with “pwd_mkdb -p /etc/master.passwd”. Mike > If somebody can tell me what's going on and what to > check for before placing the machine back on line > it would be much appreciated. > > Thanks for reading, > > bob prohaska
Re: FreeBSD wont boot on AMD Ryzen 9 7950X
Yuri, That did the job! I assume this could be set in sysctl.conf or something similar post-install? Thanks! On Sat, May 20, 2023 at 4:49 PM Yuri wrote: > Mike Jakubik wrote: > > Hello, > > > > Thanks for the info. At least I know it's not specific to my parts. Is > > there any knob one can turn in the BIOS to enable/disable this feature? > > iirc UART is old school serial ports? Wonder if removing UART support > > from the kernel would be a workaround. > > Try the following from the loader prompt (option 3 from the beastie menu): > > set hint.uart.0.disabled=1 > set hint.uart.1.disabled=1 > boot > >
Re: FreeBSD wont boot on AMD Ryzen 9 7950X
Hello, Thanks for the info. At least I know it's not specific to my parts. Is there any knob one can turn in the BIOS to enable/disable this feature? iirc UART is old school serial ports? Wonder if removing UART support from the kernel would be a workaround. Thanks. On Sat, May 20, 2023 at 4:23 PM Spotlight wrote: > Hi, > > I have a Ryzen 7 7700X with an ASRock X670E Pro RS (a similar board) and > it appears to encounter the same issue across 12/13/14. I narrowed it down to > an issue possibly involving UART initialization - modifying source to have > uart_bus_probe/ns8250_probe immediately return ENXIO allowed boot to > continue without further issue. > > Unfortunately I have been too busy to further debug why, or properly file > an issue. OpenBSD, NetBSD and DragonFly BSD do not encounter this problem > like FreeBSD does. Hopefully these details can help to better pinpoint :) > > Best, > Spotlight > > On May 20, 2023, at 14:28, Mike Jakubik wrote: > > Hi, > > I have a new desktop built with a Ryzen 9 7950X CPU, ASRock X670E Taichi > MB (Latest BIOS), 64GB G.Skill DDR5 mem, and an AMD Radeon RX 7900 XTX. I > have tried both snapshots of 13 and 14, and they both lock up in the same > area when booting (cpu0: on acpi0). No crashes or errors, but I > need to hit the reset button. It works with Windows 11 just fine. Any > ideas? Below is a link to a screenshot of the boot screen and where it > stops. > > https://photos.app.goo.gl/V6zMs58Qd66qeaQr6 > > Thanks. > > >
FreeBSD wont boot on AMD Ryzen 9 7950X
Hi, I have a new desktop built with a Ryzen 9 7950X CPU, ASRock X670E Taichi MB (Latest BIOS), 64GB G.Skill DDR5 mem, and an AMD Radeon RX 7900 XTX. I have tried both snapshots of 13 and 14, and they both lock up in the same area when booting (cpu0: on acpi0). No crashes or errors, but I need to hit the reset button. It works with Windows 11 just fine. Any ideas? Below is a link to a screenshot of the boot screen and where it stops. https://photos.app.goo.gl/V6zMs58Qd66qeaQr6 Thanks.
Re: ntpd fails on recent -current/arm64
On 23 Apr 2023, at 6:47, Peter Jeremy wrote: > Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, > some change in the kernel has made ntpd stop working on my arm64 test > box. (My amd64 test box is a couple of days behind so I'm not sure if > it's arm-specific). > > What I've identified so far: > * The problem is in the kernel, not userland. > * The impact seems to be limited to ntpd (in particular, ntpdate works). > * ntpd appears to be correctly exchanging NTP packets with peers. > * ntpd is not responding to "ntpq -p" queries > * ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime I updated an amd64 system yesterday, and it is broken too. > I've looked through the commits and, beyond much of netinet being > roto-tilled, I can't see anything obvious. The netinet changes seem likely to be the culprit. ntpd seems to be receiving the requests but isn’t responding. Trivial testing indicates that named is working, so UDP isn’t completely broken. > Is anyone else seeing anything similar? Can anyone suggest where > to look next? Mark may have an idea. Finding a simpler example would be helpful, but I’m not sure what we’re looking for. Mike
Re: Status of Alder and Raptor lake on FreeBSD Current
On 12 Apr 2023, at 9:59, Dries Michiels wrote: > Hello current mailing list, > > I was wondering what the status of Alder/Raptor lake support is on FreeBSD? > Does it boot? Integrated graphics are supported from what I recall with the > newest drm drivers. -current and 13.2 boot and run on Alder Lake, and probably Raptor Lake (I haven’t heard of any tests). There is a bug, probably in hardware, that affects page invalidation on E-cores, but a workaround changes the mechanism on the E-cores to compensate. I have no information on graphics, maybe someone else does. > Are there any plans for changes to our scheduler to account for efficiency > and performance cores? > Are there real world downsides of not having such a scheduler when running > an Alder or Raptor lake CPU? I have been working on scheduler changes, but slowly. Things work surprisingly well without them though. An E-core is slower than the first thread on a P-core, but faster than the second thread. The scheduler puts fewer processes on the E-cores because of the shared cache in groups of 4 CPUs (vs 2 for SMT on the P-cores). Of course, with enough processes, they all get used. > Interested to hear from users using these CPU's right now in there system! > The Reason I ask is that I'm interested in upgrading my home server > hardware :-). I’m running -current on an i7-12700K, and it feels fast compared to my i7-10700K. Mike
Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot
On 25 Feb 2023, at 11:02, bob prohaska wrote: > On Sat, Feb 25, 2023 at 10:33:23AM -0600, Mike Karels wrote: >> On 25 Feb 2023, at 10:16, bob prohaska wrote: >> >>> On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote: >>>> >>>> UFS stores the current timestamp in the superblock of the FS on clean >>>> shutdown/unmount. On boot it reads the time from the timestamp in the >>>> superblock of the root FS. Of coarse this timestamp is behind for the >>>> duration that the machine was off or rebooting so you need to adjust that >>>> using ntp. For ZFS root you can use the fakertc port to do something >>>> similar. >>>> >>>> >>> Mark Millard points out: >>> /etc/localtimeCurrent zoneinfo file, see tzsetup(8) and zic(8). >>> >>> /etc/wall_cmos_clock Empty file. Its presence indicates that the >>>machine's CMOS clock is set to local time, while >>>its absence indicates a UTC CMOS clock. >>> >>> Since there is no /etc/wall_cmos_clock on the newly-installed filesystem >>> it appears the superblock timestamp is then interpreted as UTC when a Pi >>> boots, using whatever happens to be set in /etc/localtime. My confusion >>> is reduced somewhat. On first boot, what is the state of /etc/localtime? >>> >>> I've neglected to run tzsetup immediately on many previous installations >>> and not noticed any complaints about mis-set clocks in buildworld. Is this >>> new behavior? >> >> /etc/localtime is used in formatting dates (e.g. for ls), but is not >> involved in storage of timestamps. Timestamps on files, system time, etc, >> are all in UTC. So the system should act normally if there is no >> /etc/localtime, and after one is added. > > Does formatting include calculating offsets from UTC for display? Yes, I was referring to the process of converting from a binary timestamp in seconds since the epoch to a string with day/month/year/hour/minute etc in the local timezone. > On at least a couple of installs I've observed date reporting UTC time. > After running tzsetup, set to PST, date then reported the same numerical > time with a PST time zone. This happened very early in an installation > lifecycle and seemed to just "go away" after a few reboots, though I > never paid close attention since it caused no complaints. I have never seen such a thing. On the contrary, I have noticed files with timestamps that seemed to be in the future, then realized that they were in UTC; I set the timezone, and then they appeared to have recent times. I’d expect similar behavior from date unless the -u flag was used or the timezone was different in the environment. Mike
Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot
On 25 Feb 2023, at 10:16, bob prohaska wrote: > On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote: >> >> UFS stores the current timestamp in the superblock of the FS on clean >> shutdown/unmount. On boot it reads the time from the timestamp in the >> superblock of the root FS. Of coarse this timestamp is behind for the >> duration that the machine was off or rebooting so you need to adjust that >> using ntp. For ZFS root you can use the fakertc port to do something >> similar. >> >> > Mark Millard points out: > /etc/localtimeCurrent zoneinfo file, see tzsetup(8) and zic(8). > > /etc/wall_cmos_clock Empty file. Its presence indicates that the >machine's CMOS clock is set to local time, while >its absence indicates a UTC CMOS clock. > > Since there is no /etc/wall_cmos_clock on the newly-installed filesystem > it appears the superblock timestamp is then interpreted as UTC when a Pi > boots, using whatever happens to be set in /etc/localtime. My confusion > is reduced somewhat. On first boot, what is the state of /etc/localtime? > > I've neglected to run tzsetup immediately on many previous installations > and not noticed any complaints about mis-set clocks in buildworld. Is this > new behavior? /etc/localtime is used in formatting dates (e.g. for ls), but is not involved in storage of timestamps. Timestamps on files, system time, etc, are all in UTC. So the system should act normally if there is no /etc/localtime, and after one is added. Mike > Thanks to both Mark and Ronald! > > bob prohaska
Re: An idea for swap partition size vs. swap space size in use handling
On 22 Jan 2023, at 2:42, Mark Millard wrote: > On Jan 22, 2023, at 00:21, Mark Millard wrote: > >> On Jan 21, 2023, at 23:17, Poul-Henning Kamp wrote: >> >>> >>> Mark Millard writes: >>> >>>> It would be nice if I could have just one swap partition >>>> on a given boot media, one that is more than sufficient >>>> in size for all but the biggest RAM system --but to then >>>> be able to tell the system to just use up to the >>>> recommended swap space size and to ignore any extra swap >>>> space in the swap partition. Why not just reduce the size of the swap partition to the desired size with “gpart resize”? Granted, that requires manual intervention. Mike >>> Last I looked at that code, that is precisely what happens >>> if you add a too big swap-device ? >> >> It produces a notice reporting how much bigger what it is >> using is than what is recommended, if I understand the >> message right. Here is an example were the difference was >> small for an armv7 context: >> >> warning: total configured swap (1003519 pages) exceeds maximum recommended >> amount (1003072 pages). >> >> Another from a context with a much bigger difference: >> >> warning: total configured swap (2097152 pages) exceeds maximum recommended >> amount (916632 pages). >> >> These sort of messages are followed by: >> >> warning: increase kern.maxswzone or reduce amount of swap. >> >> But, as I understand, increasing kern.maxswzone makes >> tradoffs with other kernel memory use. man 8 loader >> reports: > > All my references to "man 8 loader" should have been to > "man 8 loader_simp" these days. (Old habit, not yet > replaced.) > >> kern.maxswzone >> Limits the amount of KVM to be used to hold swap metadata, >> which directly governs the maximum amount of swap the >> system can support . . . >> . . . >> Note that swap metadata can be fragmented, which means that >> the system can run out of space before it reaches the >> theoretical limit. Therefore, care should be taken to not >> configure more swap than approximately half of the >> theoretical maximum. >> >> (Note: My understanding is that an "approximately half" is the >> figure shown as the "recommended amount" in the warnings.) >> >> Running out of space for swap metadata can leave the system >> in an unrecoverable state. Therefore, you should only >> change this parameter if you need to greatly extend the KVM >> reservation for other resources such as the buffer cache or >> kern.ipc.nmbclusters. Modifies kernel option >> VM_SWZONE_SIZE_MAX. >> >> The wording in man 8 loader is about decreasing kern.maxswzone > > Again. > >> in order to make room for other resources. But the implication >> is that increases leave less room than normal for other >> resources. I try to avoid getting the warnings as I do not have >> knowledge/context to make well-guided tradeoffs for the >> resources. >> >> As I understand, the 2097152 pages vs. 916632 pages example means >> that it was operating with the referenced fragmentation problems >> being more likely. That would not be true if it was just using >> more like the 916632 pages and ignoring the rest. >> >> (I was not suggesting changes to default behavior. I was only >> suggesting being able to put it in a mode where it would have >> used, for example, just around 916632 pages of the swap space.) >> >> >> (Note: Some of the detailed man 8 loader claims that I left out > > Again. > >> seem to not be general to all platforms, despite the wording >> giving no hint of that issue.) > > > > > === > Mark Millard > marklmi at yahoo.com
Re: ULE realtime scheduler advice needed
On 11/22/2022 5:00 PM, Tomoaki AOKI wrote:
A long shot, but I am curious if by chance you have hwpstate_intel for
your cpu frequency driver. If so, does setting
dev.hwpstate_intel.0.epp=0 make any difference ?
Yes, I have four of those, set to 50 by default. Let me try.
--HPS
FYI: I habitally run below manually (as root) when I'm on AC powerline.
sysctl -aN | fgrep dev.hwpstate | fgrep epp | while read OID ; do ; \
sysctl ${OID}=0 ; done
It was a bit of a POLA the first time I encountered this driver going
from 12 to RELENG_13. Same hardware behaved rather differently as its a
different power profile default than what I expected and for my use case
(firewall and router) it was causing dropped packets
---Mike
Re: ULE realtime scheduler advice needed
On 11/17/2022 11:47 PM, Hans Petter Selasky wrote: Hi, I'm doing some work with audio and have noticed some problems with the ULE scheduler. I have a program that generate audio based on key-presses. When no keys are pressed, the load is near 0%, but as soon as you start pressing keys, the load goes maybe to 80% of a CPU core. This program I run with rtprio 8 xxx. The issue I observe or hear actually, is that it takes too long until the scheduler grasps that this program needs it's own CPU core and stops time-sharing the program. When I however use cpuset -l xxx rtprio 8 yyy everything is good, and the program outputs realtime audio in-time. Or is this perhaps a CPU frequency stepping issue? Any advice on where to look? A long shot, but I am curious if by chance you have hwpstate_intel for your cpu frequency driver. If so, does setting dev.hwpstate_intel.0.epp=0 make any difference ? ---Mike
Re: dmesg content lifetime
On 22 Nov 2022, at 9:34, Dan Mack wrote: > It disappears a piece at a time - the oldest entries disappear first. > However, it vanishes even when there are only 2-3 lines in it so I didn't > think capacity was in play as I expected. > > So for example I might see a rate-limit entry from someone spamming the > system and then it will usually be gone in a couple days and the buffer is > completely empty. Similarly if I do something like ifconfig em0 down; > ifconfig em0 up ; it's logged but disappears after a day or so. > > I'm looking to see if this is just a cron job or something clearing it as it > might be user-error on my part. Also this is an older system so I'll > probably look at it again after I update. I noticed this too, but discovered with “dmesg -a” that the buffer was full of syslog messages, so dmesg without -a showed nothing. It seems unfortunate that syslog messages logged in the message buffer, at least once syslogd is running. Apparently this happens because they are output to /dev/console. Mike > Thank you, > > Dan > > > On Tue, 22 Nov 2022, Warner Losh wrote: > >> On Tue, Nov 22, 2022 at 8:13 AM Dan Mack wrote: >> >>> It seems like dmesg content ages out over time. Is there a way to leave >>> the contents based on a fixed memory size instead? >>> >> >> It already is a fixed memory size. Do you see it all disappear at once, or >> over time? >> >> Warner >>
Re: How to disable ACPI? (on FreeBSD14 CURRENT)
On 6 Nov 2022, at 16:47, Alexander Motin wrote: > Hi Louis, > > You should not try to disable ACPI these days. It was a recommendation in > some cases probably ~15 years ago, but for many years now modern systems > depend on ACPI for proper operation. I have no idea what causes crash in > your case, but I would not expect it to end up good any way. > > I know nothing about GNOME, haven't touched it for many years, but it must be > it what makes your laptop to sleep. FreeBSD itself does not implement such > automatic policies. It could the BIOS also if this is a laptop. Mike > On 06.11.2022 09:04, louis.free...@xs4all.nl wrote: >> I need to disable acpi and the indicated method for that is to add >> ^hint.acpi.0.disabled="1"^ in /boot/loader.conf . >> >> However that crashes my system !! >> >> Not only that, to make it work again I have to edit loader.conf on a system >> which does ^not start^. >> >> After a lot of searching Internet came to the help with, I could start the >> system again: >> >> 1. Select 3. Escape to loader prompt at the splash screen >> >> 2. Type set hint.acpi.0.disabled="0" on the loader prompt >> >> 3. Then type boot on the loader prompt >> >> edit the loader.conf >> >> Very very glad with that fix however >> >> However the problem is still there, no idea how to prevent the system from >> going to sleep (after about 10 minutes). >> >> No idea how to change those 10 minutes to a much longer time as well >> >> Note that I have gnome as gui and use the system more or less as server and >> manage the machine partly local via the GUI and partly remote via SSH. >> >> Related to GNOME I did try ^gsettings set >> org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, >> however that did not solve the problem as well. >> >> In the end there seems to two problems >> >> a) A BSD-issue ACPI-turn off in the bootloader is crashing the system ! ! and >> >> b) a GNOME issue (switching the system off during user inactivity, which is >> bullshit for a server / for ssh-login / with multiple users). >> >> What IMHO apart from the screen lock, this is not a GNOME task but an OS >> function to be configured by the system administrator. >> >> A third problem, not to be addressed here, is that recovery from sleep mode >> does not work on my system as well (even not S1). >> >> Most important for the moment is that the system keeps running / is not >> going down after x-time ! > > -- > Alexander Motin
Re: trpt(8) to be decomissioned
On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote: > Hi, > > trpt(8) is utility to pull TCP debugging data from the kernel > in 4.2BSD. We still have it in the base, with corresponding > TCPDEBUG option in the kernel and SO_DEBUG socket option. > > At the same time we have much more powerful debugging facilities > for TCP, e.g. the Dtrace probing, the TCP black box logging and > siftr. These are the tools that modern developers use. > > Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@. > None of them new what trpt(8) is :) Looks like a good justification > to me. I have used trpt, but not for many years. It was done before tcpdump as well. Its time has long since gone. Mike > -- > Gleb Smirnoff
Re: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake) support
On 26 Oct 2022, at 22:29, Chen, Alvin W wrote:
> Any body know the status to support P Core and E Core?
> Now WA is: disable PCID.
Disabling vm.pmap.pcid_enabled is the best workaround for now.
There has been some progress in investigations in the background, but I
don’t think there is a permanent solution yet.
btw, I haven’t heard reports about Raptor Lake yet. Do you know if it has
the same problems as Alder Lake on hybrids? I would guess it does.
Mike
>
> Regards,
> Alvin Chen
> Dell ThinOS | Dell - Comercial Client Group
> Teams/Zoom: weike_c...@dell.com<mailto:weike_c...@dell.com>
>
>
>
> Internal Use - Confidential
make install[kernel|world] from read only /usr/obj possible ?
On RELENG_12, I was able to mount via NFS /usr/obj and src and do an
installworld on read only mounts. However, with RELENG_13 and above, I
get permission denied errors. The install seems to continue just fine,
but I am not sure if something subtle is being missed. Looking at what
gets installed, the kernel modules get installed just fine. However, it
seems installworld has some problems with static libs (.a files). They
dont seem to get re-installed. However, not sure if thats by design as
doing a quick checksum, there is no difference on the build server and
target of the ~ 700 .a files I checked in /usr/lib32 and /usr/lib. So
despite the time stamps being off, maybe it just does not bother to
update the target if they have not changed?
e.g.
make KERNCONF=vtnet installkernel
make warning: /usr/obj/usr/src: Permission denied.
make[1] warning: /usr/src/: Permission denied.
make[2] warning: /usr/obj/usr/src/amd64.amd64: Permission denied.
--
>>> Install check kernel
--
--
>>> Installing kernel vtnet on Tue May 24 13:50:52 EDT 2022
--
cd /usr/obj/usr/src/amd64.amd64/sys/vtnet; MACHINE_ARCH=amd64
MACHINE=amd64 CPUTYPE= CC="cc -target x86_64-unknown-freebsd13.1
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="c++ -target
x86_64-unknown-freebsd13.1 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CPP="cpp -target
x86_64-unknown-freebsd13.1 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" AS="as" AR="ar"
ELFCTL="elfctl" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy"
RANLIB=ranlib STRINGS= SIZE="size" STRIPBIN="strip"
PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
make KERNEL=kernel install
make[2] warning: /usr/obj/usr/src/amd64.amd64/sys/vtnet: Permission denied.
thiskernel=`sysctl -n kern.bootfile || echo /boot/kernel/kernel` ; if [
! "`dirname "$thiskernel"`" -ef /boot/kernel ] ; then chflags -R noschg
/boot/kernel ; rm -rf /boot/kernel ; rm -rf /usr/lib/debug/boot/kernel
; else if [ -d /boot/kernel.old ] ; then chflags -R noschg
/boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv /boot/kernel
/boot/kernel.old ; if [ -n "/usr/lib/debug" -a -d
/usr/lib/debug/boot/kernel ]; then rm -rf
/usr/lib/debug/boot/kernel.old ; mv /usr/lib/debug/boot/kernel
/usr/lib/debug/boot/kernel.old ; fi ; sysctl
kern.bootfile=/boot/kernel.old/"`basename "$thiskernel"`" ; fi
kern.bootfile: /boot/kernel/kernel -> /boot/kernel.old/kernel
mkdir -p /boot/kernel
install -p -m 555 -o root -g wheel kernel /boot/kernel/
mkdir -p /usr/lib/debug/boot/kernel
install -p -m 555 -o root -g wheel kernel.debug /usr/lib/debug/boot/kernel/
cd /usr/src/sys/modules;
MAKEOBJDIRPREFIX=/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules
KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 MACHINE=amd64
MACHINE_ARCH=amd64 MODULES_EXTRA="" WITHOUT_MODULES="" ARCH_FLAGS=""
DEBUG_FLAGS="-g" __MPATH=""
KERNBUILDDIR="/usr/obj/usr/src/amd64.amd64/sys/vtnet"
SYSDIR="/usr/src/sys" MODULE_TIED=yes WITH_CTF="1" KCSAN_ENABLED="yes"
COMPAT_FREEBSD32_ENABLED="yes" make install
make[3] warning:
/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules:
Permission denied.
===> aac (install)
make[4] warning:
/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/aac:
Permission denied.
install -T release -o root -g wheel -m 555 aac.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555 aac.ko.debug
/usr/lib/debug/boot/kernel/
===> aacraid (install)
make[4] warning:
/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/aacraid:
Permission denied.
install -T release -o root -g wheel -m 555 aacraid.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555 aacraid.ko.debug
/usr/lib/debug/boot/kernel/
===> accf_data (install)
make[4] warning:
/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/accf_data:
Permission denied.
eg.
0{git}% ls -l /usr/lib32/libhei*
-r--r--r-- 1 root wheel - 53622 Mar 17 20:02 /usr/lib32/libheimbase.a
lrwxr-xr-x 1 root wheel - 17 May 24 17:11
/usr/lib32/libheimbase.so -> libheimbase.so.11
-r--r--r-- 1 root wheel - 13224 May 24 17:11 /usr/lib32/libheimbase.so.11
-r--r--r-- 1 root wheel - 54966 Mar 17 20:02 /usr/lib32/libheimbase_p.a
-r--r--r-- 1 root wheel - 67598 Mar 17 20:02 /usr/lib32/libheimntlm.a
lrwxr-xr-x 1 root wheel - 17 May 24 17:11
Re: [Intel AlderLake] Read files to FAT32 or UFS partition cause data corrupt due to P-Core-Core
On 18 Feb 2022, at 20:55, Tomoaki AOKI wrote: > Just a thought, but can it be the reason with timing (e.g., rendezvous > within (i)threads, hardware controlls without using hardware timer) > problem? > > On FreeBSD, IIUC, multi processor (multi core) implementation assumes > SMP (differs only clock speed) and end up with difference of > performance at same clock speed within P-core and E-core, possibly. Another possibility is that the system is confused by having hyperthreading on the P cores but not the E cores. > BTW, how aarch64 guys implement big.Little support to avoid such a case? > Or are they simply disable all Little cores and use big only? Are there supported arm64 systems with asymmetric processors yet? Mike > On Fri, 18 Feb 2022 15:36:27 -0500 > Alexander Motin wrote: > >> This looks pretty weird to me, but I don't think it is specific to the >> FAT32. Just today I've first noticed that booting TrueNAS 12.0-U8 >> (http://download.freenas.org/12.0/STABLE/U8/x64/TrueNAS-12.0-U8.iso) >> (based on FreeBSD 12.2 with many backports) from NVMe SSD (I don't >> insist on NVMe so far) and ZFS almost never completes successfully, >> ending up in hangs or random stack corruption panics in ZFS threads as >> soon as at least one E core is enabled of my i7-12700K. Disabling all E >> cores fixes the problem. Updated to TrueNAS 13.0-BETA1 (based on >> FreeBSD 13.0-STABLE from few weeks ago) it does not demonstrate the >> problem any more. The same TrueNAS 12.0-U8 kernel booted from NFS does >> not seem to demonstrate the problem with ZFS mounting, but I haven't >> stressed it much so far. >> >> There are seem to be dragons somewhere... >> >> On 15.02.2022 22:29, Chen, Alvin W wrote: >>> Hi Guys, >>> Any updates to support Intel P-core + E-core? >>> I have filed a bug: PR 261169 >>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261169> , but no updates. >>> Does anybody know the progress? >>> >>> For Intel Adler Lake P core + E core processor (i7-12700T), copying >>> files to FAT32 partition, the file corrupted (50%), but ZFS is fine. >>> After disabling E core in the code by restrict the max cpu number, this >>> issue is gone. And No E core processor has no such issue, like i7-12400. >>> >>> HW ENV: >>> CPU: Intel AlderLake 12th Gen i7-12700T >>> Disk: NVME SSD >>> >>> There are 3 methods to reproduce this issue: >>> 1. Make FreeBSD 13 USB disk installer, install FreeBSD with UFS, and >>> select install source and ports, the txz package checking will be failed. >>> >>> 2. Boot to shell by USB disk installer, and mount a FAT32 partition (on >>> SSD), and copy a 300MB file to the FAT32, compare the sha256 checksums >>> for the source file and the dst file, the checksum are different (50%). >>> Or if there is a 300MB file in FAT32 partition, mount the partition, and >>> for the first time check the sha256 value by running 'sha256 file.tgz', >>> the checksum is wrong, but the second time, the checksum is correct. >>> >>> 3. Install FreeBSD 13 with ZFS, and it can work well. And boot into >>> FreeBSD, disable swap, and format the SWAP partition to FAT32. Do the >>> testing as above. >>> >>> Regards, >>> >>> Alvin Chen >>> >>> Dell | Comercial Client Group >>> >>> office +86-10-82862506, fax +86-10-82861554, Dell Lync 8672506 >>> weike_c...@dell.com <mailto:weike_c...@dell.com> >>> >>> Internal Use - Confidential >>> >> >> -- >> Alexander Motin >> > > > -- > 青木 知明 [Tomoaki AOKI]
randomdev hangs during initial boot of -current on Raspberry Pi
I hadn't updated my Raspberry Pi 4B running -current for a couple of
months, so I booted the latest snapshot (Jan 27). It hangs when it
does the "growfs" step, expanding the root partition and fs to fill
the SD card. When it hangs, it prints this every 10 seconds or so:
random: randomdev_wait_until_seeded unblock wait
I waited several minutes the first time, and 20 minutes on another trial.
If I hold down the return key on the serial console, the device unblocks
and the boot continues. This only happens on the initial boot, when the
growfs script runs. The hang happens on a Raspberry Pi 3B+ as well.
It also happens with the two-week-old snapshot, but not the Nov 25
snapshot. The program that's running during the hang is awk, doing
a read, according to ^T; the script uses awk to parse output from
mount, glabel, and sysctl.
It sounds like there is no source of entropy at this point, and there
was no cache. I don't see any changes to the random device since this
was working. Does anyone have a guess what to look for? A bisect
would be rather laborious, building a modified SD card each time,
even if just testing kernel changes. Any other suggestions?
An excerpt from /var/log/messages during this time is appended.
Mike
Jan 27 10:38:48 generic kernel: umass0 on uhub0
Jan 27 10:38:48 generic kernel: umass0: on usbus0
Jan 27 10:38:48 generic kernel: umass0: SCSI over Bulk-Only; quirks = 0x8100
Jan 27 10:38:48 generic kernel: umass0:0:0: Attached to scbus0
Jan 27 10:38:48 generic kernel: da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
Jan 27 10:38:48 generic kernel: da0: Fixed Direct Access
SPC-4 SCSI device
Jan 27 10:38:48 generic kernel: da0: Serial Number 40118905201B
Jan 27 10:38:48 generic kernel: da0: 400.000MB/s transfers
Jan 27 10:38:48 generic kernel: da0: 228936MB (468862128 512 byte sectors)
Jan 27 10:38:48 generic kernel: da0: quirks=0x2
Jan 27 10:38:48 generic kernel: random: randomdev_wait_until_seeded unblock wait
Jan 27 10:38:48 generic syslogd: last message repeated 48 times
Jan 27 10:38:48 generic kernel: random: unblocking device.
Jan 27 10:38:48 generic kernel: GEOM_PART: mmcsd0s2 was automatically resized.
Jan 27 10:38:48 generic kernel: Use `gpart commit mmcsd0s2` to save changes
or `gpart undo mmcsd0s2` to revert them.
Jan 27 10:38:48 generic kernel: lo0: link state changed to UP
Re: observations on Ryzen 5xxx (Zen 3) processors
On 1/4/2022 11:56 AM, tech-lists wrote: On Tue, Jan 04, 2022 at 02:06:43PM +, tech-lists wrote: Hello, On Wed, Dec 22, 2021 at 02:42:48PM +0200, Andriy Gapon wrote: There have been some reports on strange / unexpected things with Ryzen 5xxx processors. I think I have seen 5950X, 5900X and 5800X mentioned, not sure about others. Thanks for this. I'm evaluating a ryzen 5600G. Here's hwinfo: https://bsd-hardware.info/?probe=e67007df20 I've noticed a couple of oddities: 1. some ports won't build, but world builds and installs just fine (current/14) Can't build lang/perl5.32. I have many vms running perl5.32 and they're not seeing any issues. There's nothing in bugs suggesting there's an issue with this port right now. I would for sure try a clean src.conf first and use that as a baseline. Also, someome mentioned trying machdep.idle=spin In /boot/loader.conf But removing your src.conf optimizations would be the first place to try ---Mike
Re: [HEADSUP] making /bin/sh the default shell for root
On Wed, Sep 22, 2021 at 10:00:49AM -0300, Renato Botelho wrote: > +1 for keeping this behavior on default config -1 for this. Things should be as default-as-possible, so that the behaviour of /bin/sh as root on FreeBSD is unsuprising to someone used to /bin/sh on other systems or users, because they won't be used to the magic config. I have no problem with a section of root's .profile having the approprate magic commented out so that folk who want this can easily have it, of course. Cheers, Mike -- Mike Bristow m...@urgle.com
Re: ZFS feature compatibility?
On 1/25/2021 4:51 PM, John Kennedy wrote: > On Mon, Jan 25, 2021 at 04:17:18PM -0500, mike tancsa wrote: >> Is there a way to check from the bin if its the right version ? strings >> of the file doesnt seem to show anything useful. I wonder if its the >> UEFI boot that got missed ? Just >> >> gpart bootcode -p /boot/boot1.efifat -i 1ada8 >> gpart bootcode -p /boot/boot1.efifat -i 1ada9 >> >> I take it ? > I don't think that is the way to update UEFI anymore (although last time I > looked it was still documented that way in one place). > > For my last bootcode (which had UEFI & BIOS) update, I basically did this: > > gpart show nvd0 > => 40 976773088 nvd0 GPT (466G) >40 409600 1 efi (200M) >409640 1024 2 freebsd-boot (512K) >410664984- free - (492K) >411648 16777216 3 freebsd-swap (8.0G) > 17188864 959584256 4 freebsd-zfs (458G) > 976773120 8- free - (4.0K) > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 nvd0 > partcode written to nvd0p2 > bootcode written to nvd0 > > mount -vt msdosfs /dev/nvd0p1 /mnt > /dev/nvd0p1 on /mnt (msdosfs, local, writes: sync 1 async 0, > reads: sync 13 async 0, fsid 5c003200) > install -p -m755 /boot/loader.efi /mnt/efi/boot/BOOTx64.efi > umount -v /mnt > /dev/nvd0p1: unmount from /mnt Thanks, I am new to the EFI world. Does the name now have to be BOOTx64.efi ? root@zoo2:/boot # ls -l /mnt/EFI/freebsd/ total 824 -rwxr-xr-x 1 root wheel 843776 Nov 21 10:50 loader.efi root@zoo2:/boot # ---Mike > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS feature compatibility?
On 1/25/2021 4:03 PM, Toomas Soome wrote:
>
>
>> On 25. Jan 2021, at 22:15, mike tancsa > <mailto:m...@sentex.net>> wrote:
>>
>> On 1/25/2021 2:37 PM, Toomas Soome via freebsd-current wrote:
>>>
>>>> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current
>>>> mailto:freebsd-current@freebsd.org>>
>>>> wrote:
>>>>
>>>> I have a few machines on which I've been hesitant to run 'zpool
>>>> upgrade' as I'm not sure of the (boot?) implications. They report
>>>> like this ..
>>>>
>>>> imb@toshi:/home/imb> uname -a
>>>> FreeBSD toshi.auburn.protected-networks.net
>>>> <http://toshi.auburn.protected-networks.net> 14.0-CURRENT FreeBSD
>>>> 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021
>>>> r...@toshi.auburn.protected-networks.net
>>>> <mailto:r...@toshi.auburn.protected-networks.net>:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
>>>> amd64
>>>>
>>>> imb@toshi:/home/imb> zpool status
>>>> pool: zroot
>>>> state: ONLINE
>>>> status: Some supported features are not enabled on the pool. The
>>>> pool can
>>>> still be used, but some features are unavailable.
>>>> action: Enable all features using 'zpool upgrade'. Once this is done,
>>>> the pool may no longer be accessible by software that does
>>>> not support
>>>> the features. See zpool-features(5) for details.
>>>>
>>>> Is it safe to upgrade the root pool?
>>>>
>>>> imb
>>> We can not boot from encrypted pool and draid. Rest is all ok.
>>> Please note, you may need to update the bootblocks.
>>>
>> last Friday on zoo.freebsd.org
>> <http://zoo.freebsd.org/>, m...@freebsd.org
>> <mailto:m...@freebsd.org> and I could not boot
>> again because v2 bookmarks were on the boot pool. I had to boot from
>> another disk, remove the bookmarks and then boot. This was on RELENG_13
>> (stable/13-c256203-g51d73a3e46c)
>>
>> —Mike
>
> /*
> * List of ZFS features supported for read
> */
> static const char *features_for_read[] = {
> "org.illumos:lz4_compress",
> "com.delphix:hole_birth",
> "com.delphix:extensible_dataset",
> "com.delphix:embedded_data",
> "org.open-zfs:large_blocks",
> "org.illumos:sha512",
> "org.illumos:skein",
> "org.zfsonlinux:large_dnode",
> "com.joyent:multi_vdev_crash_dump",
> "com.delphix:spacemap_histogram",
> "com.delphix:zpool_checkpoint",
> "com.delphix:spacemap_v2",
> "com.datto:encryption",
> "com.datto:bookmark_v2",
> "org.zfsonlinux:allocation_classes",
> "com.datto:resilver_defer",
> "com.delphix:device_removal",
> "com.delphix:obsolete_counts",
> "com.intel:allocation_classes",
> "org.freebsd:zstd_compress",
> "com.delphix:bookmark_written",
> NULL
> };
>
> Are you sure you have bootblocks updated? ESP for UEFI boot and
> freebsd-boot for BIOS boot.
>
>
mjg did them IIRC. I just checked to make sure both were done and they
seem identical
root@zoo2:/home/mdtancsa # dd if=/dev/ada8p2 of=/tmp/8
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.046479 secs (11280092 bytes/sec)
root@zoo2:/home/mdtancsa # dd if=/dev/ada9p2 of=/tmp/9
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.054717 secs (9581751 bytes/sec)
root@zoo2:/home/mdtancsa # md5 /tmp/8 /tmp/9
MD5 (/tmp/8) = e294b1344cbb49c751474facc39998ec
MD5 (/tmp/9) = e294b1344cbb49c751474facc39998ec
root@zoo2:/home/mdtancsa #
Is there a way to check from the bin if its the right version ? strings
of the file doesnt seem to show anything useful. I wonder if its the
UEFI boot that got missed ? Just
gpart bootcode -p /boot/boot1.efifat -i 1ada8
gpart bootcode -p /boot/boot1.efifat -i 1ada9
I take it ?
MD5 (/tmp/81) = ff8762fa2b885347a0030b45b0f3844e
MD5 (/tmp/91) = e0fa5369ddb0471373bca6b29e027680
MD5 (/boot/boot1.efi) = c023e2c74479b2f0710ab0337a7bab4f
root@zoo2:/boot # dd if=/dev/ada9p1 of=/tmp/91 bs=1m
200+0 records in
200+0 records out
209715200 bytes transferred in 0.557007 secs (376503669 bytes/sec)
root@zoo2:/boot # dd if=/dev/ada8p1 of=/tmp/81 bs=1m
200+0 records in
200+0 records out
209715200 bytes transferred in 0.475806 secs (440757874 bytes/sec)
root@zoo2:/boot # md5 /tmp/81 /tmp/91 /boot/boot1
boot1 boot1.efi*
root@zoo2:/boot # md5 /tmp/81 /tmp/91 /boot/boot1.efi
MD5 (/tmp/81) = ff8762fa2b885347a0030b45b0f3844e
MD5 (/tmp/91) = e0fa5369ddb0471373bca6b29e027680
MD5 (/boot/boot1.efi) = c023e2c74479b2f0710ab0337a7bab4f
I am guessing they extracted boot blocks should match, no ?
---Mike
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS feature compatibility?
On 1/25/2021 2:37 PM, Toomas Soome via freebsd-current wrote: > >> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current >> wrote: >> >> I have a few machines on which I've been hesitant to run 'zpool upgrade' as >> I'm not sure of the (boot?) implications. They report like this .. >> >> imb@toshi:/home/imb> uname -a >> FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD >> 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 >> r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI >> amd64 >> >> imb@toshi:/home/imb> zpool status >> pool: zroot >> state: ONLINE >> status: Some supported features are not enabled on the pool. The pool can >>still be used, but some features are unavailable. >> action: Enable all features using 'zpool upgrade'. Once this is done, >>the pool may no longer be accessible by software that does not support >>the features. See zpool-features(5) for details. >> >> Is it safe to upgrade the root pool? >> >> imb > We can not boot from encrypted pool and draid. Rest is all ok. Please note, > you may need to update the bootblocks. > last Friday on zoo.freebsd.org, m...@freebsd.org and I could not boot again because v2 bookmarks were on the boot pool. I had to boot from another disk, remove the bookmarks and then boot. This was on RELENG_13 (stable/13-c256203-g51d73a3e46c) ---Mike ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS feature compatibility?
I ran into an issue not being able to boot because of v2 bookmarks on the boot pool on RELENG_13 just last Friday. ---Mike On 1/25/2021 2:31 PM, Michael Butler via freebsd-current wrote: > I have a few machines on which I've been hesitant to run 'zpool > upgrade' as I'm not sure of the (boot?) implications. They report like > this .. > > imb@toshi:/home/imb> uname -a > FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD > 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 > r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI > amd64 > > imb@toshi:/home/imb> zpool status > pool: zroot > state: ONLINE > status: Some supported features are not enabled on the pool. The pool can > still be used, but some features are unavailable. > action: Enable all features using 'zpool upgrade'. Once this is done, > the pool may no longer be accessible by software that does not > support > the features. See zpool-features(5) for details. > > Is it safe to upgrade the root pool? > > imb > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 11/9/2020 7:32 AM, Lev Serebryakov wrote:
> On 07.11.2020 2:46, Eric Joyner wrote:
>
>> The other issue is that I still don't know which devices need a
>> restart / which devices do not, or whether a restart is strictly
>> necessary and if there is another way to do this without worrying
>> about restarting the device.
> Could this be copied from pre-iflib driver? It did right things
> without unneeded resets, including some `em` chips.
>
> BTW, I'm surprised, that pre-iflib drivers still available on Intel
> site and in ports. And sometimes works better :-(
>
For my specific case (no DHCLIENT and I210 chipset), I just used
--- if_em.c 2020-09-26 07:46:16.474942000 -0400
+++ /tmp/if_em.c 2020-11-09 08:13:55.888378000 -0500
@@ -4047,6 +4047,7 @@
{
switch (event) {
case IFLIB_RESTART_VLAN_CONFIG:
+ return (false);
default:
return (true);
}
And that seems to work for my particular chipset and use case.
---Mike
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 11/6/2020 5:32 PM, Eric Joyner wrote:
> Could you reply to that issue with what you've found?
>
> Though, as far as I can recall, igb(4) devices are not supposed to do
> the iflib reset talked about in the bug, so I wouldn't expect to see a
> link flap on those.
>
Hi Eric,
I have added my findings to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
I tried it on 3 different vendor's boards. All I210 variants it seems.
I am testing with
--- if_em.c 2020-11-06 15:00:22.120953000 -0500
+++ /tmp/if_em.c 2020-11-06 14:59:55.678195000 -0500
@@ -4047,6 +4047,7 @@
{
switch (event) {
case IFLIB_RESTART_VLAN_CONFIG:
+ return (false);
default:
return (true);
}
And if fixes the problem, but not quite sure if it introduces any
regressions or other issues ?
---Mike
> - Eric
>
> On Fri, Nov 6, 2020 at 12:48 PM mike tancsa <mailto:m...@sentex.net>> wrote:
>
> On 11/6/2020 2:17 PM, mike tancsa wrote:
> > On 5/31/2020 5:39 PM, Lev Serebryakov wrote:
> >> Hello Ian,
> >>
> >> Thursday, May 28, 2020, 2:45:48 AM, you wrote:
> >>
> >>> I noticed that my VLAN interfaces stopped working after a
> recent build.
> >>> tcpdump showed traffic leaving leaving and entering the
> interface but no
> >>> host on the network actually received any packets from this
> host. A
> >>> binary search led me to r360902 and indeed the following
> change fixed
> >>> the issue for me:
> >> Problem is, this change will return terrible situation when
> adding new VLAN
> >> will flap connection status.
> >>
> >> It all worked before iflib: hardware VLAN filtering worked, and
> >> adding/removing new VLAN didn't cause link to flap.
> >>
> >> Now, with iflib, looks like we can not have all good things at
> once :(
>
>
> Looks like this is captured in
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818>
>
>
> > Hi All,
> >
> > Just came across this thread as I am running into this behaviour on
> > RELENG_12. Adding a new vlan causes all vlans on the parent
> interface
> > to flap. Not the greatest thing as it bounces a LOT of traffic
> > potentially, flaps routing etc. Is there a way around this ?
> >
> > This is on r367411 releng12
> >
> > igb0@pci0:2:0:0: class=0x02 card=0x153315d9
> chip=0x15338086
> > rev=0x03 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'I210 Gigabit Network Connection'
> > class = network
> > subclass = ethernet
> >
> > eg. just something simple like
> >
> > ifconfig vlan16 create 10.1.2.3/29 <http://10.1.2.3/29> vlandev
> igb1 vlan 16
> >
> > # dmesg | tail -8
> > igb1: link state changed to DOWN
> > vlan16: link state changed to DOWN
> > vlan2049: link state changed to DOWN
> > vlan15: link state changed to DOWN
> > igb1: link state changed to UP
> > vlan16: link state changed to UP
> > vlan2049: link state changed to UP
> > vlan15: link state changed to UP
> >
> >
> > ---Mike
> >
> >
> >
> >
> > ___
> > freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>
> mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
> > To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org
> <mailto:freebsd-current-unsubscr...@freebsd.org>"
> >
> ___
> freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>
> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org
> <mailto:freebsd-current-unsubscr...@freebsd.org>"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 11/6/2020 2:17 PM, mike tancsa wrote: > On 5/31/2020 5:39 PM, Lev Serebryakov wrote: >> Hello Ian, >> >> Thursday, May 28, 2020, 2:45:48 AM, you wrote: >> >>> I noticed that my VLAN interfaces stopped working after a recent build. >>> tcpdump showed traffic leaving leaving and entering the interface but no >>> host on the network actually received any packets from this host. A >>> binary search led me to r360902 and indeed the following change fixed >>> the issue for me: >> Problem is, this change will return terrible situation when adding new VLAN >> will flap connection status. >> >> It all worked before iflib: hardware VLAN filtering worked, and >> adding/removing new VLAN didn't cause link to flap. >> >> Now, with iflib, looks like we can not have all good things at once :( Looks like this is captured in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818 > Hi All, > > Just came across this thread as I am running into this behaviour on > RELENG_12. Adding a new vlan causes all vlans on the parent interface > to flap. Not the greatest thing as it bounces a LOT of traffic > potentially, flaps routing etc. Is there a way around this ? > > This is on r367411 releng12 > > igb0@pci0:2:0:0: class=0x02 card=0x153315d9 chip=0x15338086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'I210 Gigabit Network Connection' > class = network > subclass = ethernet > > eg. just something simple like > > ifconfig vlan16 create 10.1.2.3/29 vlandev igb1 vlan 16 > > # dmesg | tail -8 > igb1: link state changed to DOWN > vlan16: link state changed to DOWN > vlan2049: link state changed to DOWN > vlan15: link state changed to DOWN > igb1: link state changed to UP > vlan16: link state changed to UP > vlan2049: link state changed to UP > vlan15: link state changed to UP > > > ---Mike > > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 5/31/2020 5:39 PM, Lev Serebryakov wrote: > Hello Ian, > > Thursday, May 28, 2020, 2:45:48 AM, you wrote: > >> I noticed that my VLAN interfaces stopped working after a recent build. >> tcpdump showed traffic leaving leaving and entering the interface but no >> host on the network actually received any packets from this host. A >> binary search led me to r360902 and indeed the following change fixed >> the issue for me: > Problem is, this change will return terrible situation when adding new VLAN > will flap connection status. > > It all worked before iflib: hardware VLAN filtering worked, and > adding/removing new VLAN didn't cause link to flap. > > Now, with iflib, looks like we can not have all good things at once :( Hi All, Just came across this thread as I am running into this behaviour on RELENG_12. Adding a new vlan causes all vlans on the parent interface to flap. Not the greatest thing as it bounces a LOT of traffic potentially, flaps routing etc. Is there a way around this ? This is on r367411 releng12 igb0@pci0:2:0:0: class=0x02 card=0x153315d9 chip=0x15338086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I210 Gigabit Network Connection' class = network subclass = ethernet eg. just something simple like ifconfig vlan16 create 10.1.2.3/29 vlandev igb1 vlan 16 # dmesg | tail -8 igb1: link state changed to DOWN vlan16: link state changed to DOWN vlan2049: link state changed to DOWN vlan15: link state changed to DOWN igb1: link state changed to UP vlan16: link state changed to UP vlan2049: link state changed to UP vlan15: link state changed to UP ---Mike ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Deprecating ftpd in the FreeBSD base system?
On 9/16/2020 2:07 PM, sth...@nethelp.no wrote: > # override default of no subsystems > -Subsystemsftp/usr/libexec/sftp-server > +Subsystemsftpinternal-sftp -l INFO Hi, What is the difference between these two ? Is it not all OpenSSH ? ---Mike ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Current panics on connecting disks to a LSI-3108 controller
On 7/14/2020 5:14 AM, Willem Jan Withagen wrote: > On 14-7-2020 07:45, Andriy Gapon wrote: >> On 14/07/2020 03:39, Willem Jan Withagen wrote: >>> And what I read from the manual page, mrsas plays even nicer with >>> CAM which is a >>> plus. >> If by "nicer" you mean that mfi does not integrate with CAM at all, >> then you are >> right :-) >> Also, last I looked mfi has some pretty serious bugs in its direct >> interface to >> GEOM. We've seen all kinds of crashes with mfi at work. > Right that was what I meant. > Disadvantage is that mfiutil no longer works. > But then if you JBOD, it does not really matter. > Unless it still uses caching for JBODs and then I'd like to know the > state of the > battery. > Take a look from the ports storcli or MegaCli You can do pretty well everything you need with those 2 tools to talk to mrsas attached disks eg MegaCli -CfgEachDskRaid0 WT NORA Direct CachedBadBBU -Automatic -a0 or storcli /c0 show all storcli /c0 show help storcli /c0 set jbod=on (enable jbod mode for drives) storcli /c0/e252/s0 set jbod (sets a disk into jbod mode) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Which AMD CPUs are supported -- temperature
On 2/13/2020 2:22 AM, Peter Jeremy wrote: > On 2020-Feb-12 15:23:51 -0500, mike tancsa wrote: >> Not sure about the older Athlon CPUs, but the 2 generations of Ryzen's I >> have seem correct as well as an APU >> >> CPU: AMD GX-412TC SOC (998.17-MHz K8-class >> CPU) > OTOH, I'm not confident about temperatures on my APU. The publicly > >> And on a fanless APU >> >> # sysctl -a dev.cpu.0.temperature >> dev.cpu.0.temperature: 62.6C >> >> # sysctl -a dev.amdtemp.0.core0.sensor0 >> dev.amdtemp.0.core0.sensor0: 63.1C > At what ambient temperature? I see a similar value from my (idle) APU3 > but don't believe the (implied) ~35K junction-to-ambient difference. Actually, it does seem a bit high. This is read from a PCEngines APU3. Since the CPU dissipates heat off the bottom metal case, I cant point my thermal laser temp reader directly at the CPU. Reading the temp off the top of the mother board with the top of the case off, I cant find any spots hotter than 35C... So 62C is probably a lot higher than it actually is. ---Mike ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Which AMD CPUs are supported -- temperature
On 2/12/2020 1:39 PM, Chris wrote: > Hard as I try I can not get anything close to the actual temperature > of the CPUs or cores while running on FreeBSD. > Family: Athlon X4 > Manufacturer: AuthenticAMD > Not sure about the older Athlon CPUs, but the 2 generations of Ryzen's I have seem correct as well as an APU CPU: AMD GX-412TC SOC (998.17-MHz K8-class CPU) CPU: AMD Ryzen 7 3700X 8-Core Processor (3593.33-MHz K8-class CPU) CPU: AMD Ryzen 7 2700X Eight-Core Processor (3693.17-MHz K8-class CPU) e.g. at idle # sysctl -a dev.cpu.0.temperature dev.cpu.0.temperature: 31.1C then start up # cat /dev/urandom | openssl sha256 # sysctl -a dev.cpu.0.temperature dev.cpu.0.temperature: 57.1C It agrees with what IPMI reports too from the MB # ipmitool sensor | grep "CPU Temp" CPU Temp | 31.000 | degrees C | ok | na | na | na | 93.000 | 94.000 | na And on a fanless APU # sysctl -a dev.cpu.0.temperature dev.cpu.0.temperature: 62.6C # sysctl -a dev.amdtemp.0.core0.sensor0 dev.amdtemp.0.core0.sensor0: 63.1C ---Mike ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6/ppp: FreeBSD obtains linklocal on tun0 only
On 11/30/2018 7:12 AM, O. Hartmann wrote: > > For IPv6, I only see my local linklocal address, fe80::... > > Checking the log of ppp (/var/log/ppp.log), there is also a fe80:: > linklocal address > assigned to the variable HISADDR. Somehow, the tun0 never obtains a > IPv6 aprefix so far. > > Can someone give a tip? What does you ppp.conf look like ? -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot message: sendmsg on igb0: No buffer space available
On 10/20/2018 4:31 AM, Dave Cottlehuber wrote: > On Fri, 19 Oct 2018, at 19:46, Mike Tancsa wrote: >> Feeding entropy: . >> lo0: link state changed to UP >> sendmsg on igb0: No buffer space available >> igb0: link state changed to UP >> cxl1: link state changed to UP >> Starting Network: lo0 igb0 cxl0 cxl1. > I’m reasonably sure that this occurs when dhclient is trying before the > interface is available for use - is that likely in your case? Perhaps, but why the difference previous versions? Should not the interface be up'd before starting dhclient ? ---Mike ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
boot message: sendmsg on igb0: No buffer space available
Since starting to test HEAD, I noticed at bootup time I get the message in dmesg sendmsg on igb0: No buffer space available It seems innocuous enough in that I dont see any obvious issues. Is it a symptom of some misconfiguration ? This originally was a releng11 box that I upgraded via source so /etc/ still has all the old bootup stuff. Speaking of which, what is the best way to update all the bootup scripts. It seems to have all changed since 11. Setting up harvesting: PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED Feeding entropy: . lo0: link state changed to UP sendmsg on igb0: No buffer space available igb0: link state changed to UP cxl1: link state changed to UP Starting Network: lo0 igb0 cxl0 cxl1. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot hang at r339386 (solved)
On 10/18/2018 2:50 PM, Mike Tancsa wrote: > On 10/18/2018 2:26 PM, Konstantin Belousov wrote: >> On Thu, Oct 18, 2018 at 11:12:11AM -0400, Mike Tancsa wrote: >>> On r339386 I am seeing a 100% hang at boot up time. Boot ends at >>> >>> Going back to r339385 works. But going to the next commit hangs the box >>> >>> https://lists.freebsd.org/pipermail/svn-src-head/2018-October/118853.html >> Try the patch at https://reviews.freebsd.org/D17612 >> >> > Looks good both on my Ryzen and EPYC based boards! Thanks > Also tested on a PCEngines APU and looks good. ---<>--- Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-ALPHA10 #4 r339418M: Thu Oct 18 14:37:48 EDT 2018 mdtan...@nanobsd2.sentex.ca:/pxe/12/obj/pxe/12/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) VT(vga): resolution 640x480 CPU: AMD GX-412TC SOC (998.15-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x730f01 Family=0x16 Model=0x30 Stepping=1 Features=0x178bfbff Features2=0x3ed8220b AMD Features=0x2e500800 AMD Features2=0x1d4037ff Structured Extended Features=0x8 XSAVE Features=0x1 SVM: NP,NRIP,AFlush,DAssist,NAsids=8 TSC: P-state invariant, performance statistics real memory = 2012930048 (1919 MB) avail memory = 1909755904 (1821 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) random: unblocking device. ioapic1: Changing APIC ID to 5 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-55 on motherboard Launching APs: 1 2 3 Timecounter "TSC" frequency 998147285 Hz quality 1000 random: entropy device external interface netmap: loaded module [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0x8112ec50, 0) error 19 kbd0 at kbdmux0 nexus0 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot hang at r339386 (solved)
On 10/18/2018 2:26 PM, Konstantin Belousov wrote: > On Thu, Oct 18, 2018 at 11:12:11AM -0400, Mike Tancsa wrote: >> On r339386 I am seeing a 100% hang at boot up time. Boot ends at >> >> Going back to r339385 works. But going to the next commit hangs the box >> >> https://lists.freebsd.org/pipermail/svn-src-head/2018-October/118853.html > Try the patch at https://reviews.freebsd.org/D17612 > > Looks good both on my Ryzen and EPYC based boards! Thanks Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: sys/amd64/amd64/pmap.c |=== |--- sys/amd64/amd64/pmap.c |+++ sys/amd64/amd64/pmap.c -- Patching file sys/amd64/amd64/pmap.c using Plan A... Hunk #1 succeeded at 637. Hunk #2 succeeded at 7099. Hunk #3 succeeded at 7143. Hunk #4 succeeded at 7156. Hunk #5 succeeded at 7325. Hunk #6 succeeded at 7448. Hunk #7 succeeded at 7478. Hunk #8 succeeded at 7506. Hunk #9 succeeded at 7521. Hunk #10 succeeded at 7530. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |Index: sys/amd64/include/pmap.h |=== |--- sys/amd64/include/pmap.h |+++ sys/amd64/include/pmap.h -- Patching file sys/amd64/include/pmap.h using Plan A... Hunk #1 succeeded at 430. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |Index: sys/amd64/pci/pci_cfgreg.c |=== |--- sys/amd64/pci/pci_cfgreg.c |+++ sys/amd64/pci/pci_cfgreg.c -- Patching file sys/amd64/pci/pci_cfgreg.c using Plan A... Hunk #1 succeeded at 271. done ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
boot hang at r339386
On r339386 I am seeing a 100% hang at boot up time. Boot ends at Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-ALPHA10 r339415 GENERIC amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 CPU: AMD Ryzen 5 1600X Six-Core Processor (3593.34-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x1007 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33255837696 (31715 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs FreeBSD/SMP: 1 package(s) x 2 cache groups x 3 core(s) x 2 hardware threads random: unblocking device. Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x/0x1 (20181003/tbfadt-796) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-55 on motherboard Launching APs: 10 1 2 3 9 11 8 5 7 6 4 Timecounter "TSC-low" frequency 1796668938 Hz quality 1000 random: entropy device external interface module_register_init: MOD_LOAD (vesa, 0x810e6a80, 0) error 19 kbd1 at kbdmux0 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" netmap: loaded module [ath_hal] loaded nexus0 vtvga0: on motherboard aesni0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard Adding boot verbose, shows the lines below before the hang. ACPI: 7 ACPI AML tables successfully acquired and loaded PCIe: Memory Mapped configuration base @ 0xf800 The box is hard locked up and I cannot break to debugger either. Going back to r339385 works. But going to the next commit hangs the box https://lists.freebsd.org/pipermail/svn-src-head/2018-October/118853.html ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Strange panic at boot with vmm in loader.conf vs manually loading it
On 10/14/2018 2:19 PM, Mateusz Guzik wrote: > On 10/14/18, Mike Tancsa wrote: >> On 10/13/2018 12:48 PM, Allan Jude wrote: >>> Strange that your crash is in ZFS here... >>> >>> Can you take a crash dump? >>> >>> It looks like something is trying to write to uninitialized memory here. >> I will need to pop in another drive or can I do a netdump at this point ? >> > This should be fixed with https://svnweb.freebsd.org/changeset/base/339355 > i.e. just update. > Thanks, just tried and all is good! ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Strange panic at boot with vmm in loader.conf vs manually loading it
On 10/13/2018 12:48 PM, Allan Jude wrote: > > Strange that your crash is in ZFS here... > > Can you take a crash dump? > > It looks like something is trying to write to uninitialized memory here. I will need to pop in another drive or can I do a netdump at this point ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 10G performance regression / difference cxl and ix RELENG11 vs HEAD
On 10/12/2018 12:52 PM, Navdeep Parhar wrote: > > The number of retries (the "Retr" column) should have been 0 in a > controlled test like this. Is this the default stack with all default > parameters or have you tuned TCP and/or sockets in any way? No tuning at all. After a reboot and one test, I am seeing a bunch of overflows. I am going to netboot back to RELENG_11 to confirm sysctl -a dev.cxl.1.stats dev.cxl.1.stats.rx_tls_octets: 0 dev.cxl.1.stats.rx_tls_records: 0 dev.cxl.1.stats.tx_tls_octets: 0 dev.cxl.1.stats.tx_tls_records: 0 dev.cxl.1.stats.rx_trunc3: 0 dev.cxl.1.stats.rx_trunc2: 12 dev.cxl.1.stats.rx_trunc1: 0 dev.cxl.1.stats.rx_trunc0: 0 dev.cxl.1.stats.rx_ovflow3: 0 dev.cxl.1.stats.rx_ovflow2: 58 dev.cxl.1.stats.rx_ovflow1: 0 dev.cxl.1.stats.rx_ovflow0: 0 dev.cxl.1.stats.rx_ppp7: 0 dev.cxl.1.stats.rx_ppp6: 0 dev.cxl.1.stats.rx_ppp5: 0 dev.cxl.1.stats.rx_ppp4: 0 dev.cxl.1.stats.rx_ppp3: 0 dev.cxl.1.stats.rx_ppp2: 0 dev.cxl.1.stats.rx_ppp1: 0 dev.cxl.1.stats.rx_ppp0: 0 dev.cxl.1.stats.rx_pause: 0 dev.cxl.1.stats.rx_frames_1519_max: 0 dev.cxl.1.stats.rx_frames_1024_1518: 6169625 dev.cxl.1.stats.rx_frames_512_1023: 473 dev.cxl.1.stats.rx_frames_256_511: 133 dev.cxl.1.stats.rx_frames_128_255: 150 dev.cxl.1.stats.rx_frames_65_127: 1015832 dev.cxl.1.stats.rx_frames_64: 4 dev.cxl.1.stats.rx_runt: 0 dev.cxl.1.stats.rx_symbol_err: 0 dev.cxl.1.stats.rx_len_err: 0 dev.cxl.1.stats.rx_fcs_err: 0 dev.cxl.1.stats.rx_jabber: 0 dev.cxl.1.stats.rx_too_long: 0 dev.cxl.1.stats.rx_ucast_frames: 7186215 dev.cxl.1.stats.rx_mcast_frames: 0 dev.cxl.1.stats.rx_bcast_frames: 2 dev.cxl.1.stats.rx_frames: 7186217 dev.cxl.1.stats.rx_octets: 9437149499 dev.cxl.1.stats.tx_ppp7: 0 dev.cxl.1.stats.tx_ppp6: 0 dev.cxl.1.stats.tx_ppp5: 0 dev.cxl.1.stats.tx_ppp4: 0 dev.cxl.1.stats.tx_ppp3: 0 dev.cxl.1.stats.tx_ppp2: 0 dev.cxl.1.stats.tx_ppp1: 0 dev.cxl.1.stats.tx_ppp0: 0 dev.cxl.1.stats.tx_pause: 222 dev.cxl.1.stats.tx_drop: 0 dev.cxl.1.stats.tx_frames_1519_max: 0 dev.cxl.1.stats.tx_frames_1024_1518: 5409152 dev.cxl.1.stats.tx_frames_512_1023: 11968 dev.cxl.1.stats.tx_frames_256_511: 162 dev.cxl.1.stats.tx_frames_128_255: 26 dev.cxl.1.stats.tx_frames_65_127: 3095205 dev.cxl.1.stats.tx_frames_64: 210 dev.cxl.1.stats.tx_error_frames: 0 dev.cxl.1.stats.tx_ucast_frames: 8516714 dev.cxl.1.stats.tx_mcast_frames: 0 dev.cxl.1.stats.tx_bcast_frames: 9 dev.cxl.1.stats.tx_frames: 8516945 dev.cxl.1.stats.tx_octets: 8434330861 dev.cxl.1.stats.tx_parse_error: 0 > Regards, > Navdeep > > > -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Strange panic at boot with vmm in loader.conf vs manually loading it
dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=55 powerspec 3 supports D0 D3 current D0 MSI supports 32 messages, 64 bit, vector masks MSI-X supports 40 messages in map 0x20 pci0:9:0:5: reprobing on driver added found-> vendor=0x1425, dev=0x5601, revid=0x00 domain=0, bus=9, slot=0, func=6 class=0c-04-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=52 powerspec 3 supports D0 D3 current D0 MSI supports 32 messages, 64 bit, vector masks MSI-X supports 40 messages in map 0x20 pci0:9:0:6: reprobing on driver added pci10: driver added pci11: driver added found-> vendor=0x1022, dev=0x145a, revid=0x00 domain=0, bus=11, slot=0, func=0 class=13-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 pci0:11:0:0: reprobing on driver added found-> vendor=0x1022, dev=0x1456, revid=0x00 domain=0, bus=11, slot=0, func=2 class=10-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=36 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, 64 bit MSI-X supports 2 messages in map 0x24 pci0:11:0:2: reprobing on driver added pci12: driver added found-> vendor=0x1022, dev=0x1455, revid=0x00 domain=0, bus=12, slot=0, func=0 class=13-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 pci0:12:0:0: reprobing on driver added AMD-Vi: IVRS Info VAsize = 64 PAsize = 48 GVAsize = 2 flags:0 ivhd: ivhd0 already exists; skipping it ACPI: Processor \134_PR_.P00C (ACPI ID 13) ignored Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 ACPI: Processor \134_PR_.P00D (ACPI ID 14) ignored Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 ACPI: Processor \134_PR_.P00E (ACPI ID 15) ignored Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 ACPI: Processor \134_PR_.P00F (ACPI ID 16) ignored Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 ppc: ppc-1 already exists; skipping it driver bug: Unable to set devclass (class: ppc devname: (unknown)) Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 Table 'FACP' at 0xb5adbcb0 FACP: Found table at 0xb5adbcb0 ivhd0: on acpi0 ivhd0: Flag:b0 ivhd0: Features(type:0x11) MsiNumPPR = 0 PNBanks= 2 PNCounters= 0 ivhd0: Extended features[31:0]:22294ada HATS = 0x2 GATS = 0x0 GLXSup = 0x1 SmiFSup = 0x1 SmiFRC = 0x2 GAMSup = 0x1 DualPortLogSup = 0x2 DualEventLogSup = 0x2 ivhd0: Extended features[62:32]:f77ef Max PASID: 0x2f DevTblSegSup = 0x3 MarcSup = 0x1 ivhd0: supported paging level:7, will use only: 4 ivhd0: device range: 0x0 - 0x ivhd0: PCI cap 0x190b640f@0x40 feature:19 msi: routing MSI IRQ 305 to local APIC 12 vector 52 ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
10G performance regression / difference cxl and ix RELENG11 vs HEAD
I was doing a quick iperf test with r339328 GENERIC-NODEBUG amd64, and noticed I can no longer saturate a 10G nic with iperf3. I tried first with the ix adapter, but was not sure if it was the driver or not. I tried as well with a Chelsio and got similar numbers. # iperf3 -c 192.168.242.3 Connecting to host 192.168.242.3, port 5201 [ 5] local 192.168.242.2 port 50474 connected to 192.168.242.3 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 997 MBytes 8.36 Gbits/sec 717 175 KBytes [ 5] 1.00-2.00 sec 975 MBytes 8.18 Gbits/sec 668 41.1 KBytes [ 5] 2.00-3.00 sec 880 MBytes 7.38 Gbits/sec 846 25.6 KBytes [ 5] 3.00-4.00 sec 523 MBytes 4.39 Gbits/sec 802 59.8 KBytes [ 5] 4.00-5.00 sec 520 MBytes 4.36 Gbits/sec 882 48.4 KBytes [ 5] 5.00-6.00 sec 543 MBytes 4.55 Gbits/sec 838 56.9 KBytes [ 5] 6.00-7.00 sec 556 MBytes 4.66 Gbits/sec 850 11.4 KBytes [ 5] 7.00-8.00 sec 538 MBytes 4.51 Gbits/sec 795 39.9 KBytes [ 5] 8.00-9.00 sec 540 MBytes 4.53 Gbits/sec 853 57.0 KBytes [ 5] 9.00-10.00 sec 503 MBytes 4.22 Gbits/sec 814 59.8 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 6.42 GBytes 5.52 Gbits/sec 8065 sender [ 5] 0.00-10.00 sec 6.42 GBytes 5.52 Gbits/sec receiver If I do a parallel transfer I get closer to the max. However, on RELENG11 I could do pretty close to a full 10G no problem with just a single stream. This is with a GENERIC-NODEBUG kernel using a couple of T520s back to back t5iov1@pci0:9:0:1: class=0x02 card=0x1425 chip=0x50011425 rev=0x00 hdr=0x00 vendor = 'Chelsio Communications Inc' device = 'T520-CR Unified Wire Ethernet Controller' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xf668, size 524288, enabled bar [18] = type Memory, range 64, base 0xf660, size 524288, enabled bar [20] = type Memory, range 64, base 0xf688a000, size 8192, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 8 messages, 64 bit, vector masks cap 10[70] = PCI-Express 2 endpoint max data 512(2048) FLR RO NS link x8(x8) speed 8.0(8.0) -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Good motherboard for Ryzen (first-gen)
On 9/21/2018 10:53 PM, Eric van Gyzen wrote: > I would like to build a Ryzen desktop. Can anyone recommend a good > motherboard? I like the ASUS X370-PRO (currently BIOS 04/19/2018). igb0 for the onboard nic igb0@pci0:7:0:0:class=0x02 card=0x85f01043 chip=0x15398086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I211 Gigabit Network Connection' and its been VERY stable since the various microcode updates and OS updates went in. (0x8001137) CPU: AMD Ryzen 5 1600X Six-Core Processor(3593.34-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x1007 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33226657792 (31687 MB) ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sharing compiled builds between multiple 12-CURRENT boxes.
On Sat, Aug 18, 2018 at 5:34 PM, Dhananjay Balan wrote: > Hi, > > I run 12-CURRENT on few machines, some more powerful that other (all > of them x86_64, march varies). > > Is there is a way to avoid building CURRENT on all machines? Rather > than building everywhere, can I just build it on the big server that I > have and copy and update my laptop? > I've never actually tried it myself, but the following section of the handbook outlines one possibility for doing this via NFS: https://www.freebsd.org/doc/handbook/small-lan.html ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-current Digest, Vol 768, Issue 3
unsubscribe On Wed, Jul 18, 2018 at 5:01 AM wrote: > Send freebsd-current mailing list submissions to > freebsd-current@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.freebsd.org/mailman/listinfo/freebsd-current > or, via email, send a message with subject or body 'help' to > freebsd-current-requ...@freebsd.org > > You can reach the person managing the list at > freebsd-current-ow...@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-current digest..." > > > Today's Topics: > >1. Re: top -n -o res shows empty output (Ali Abdallah) > > > -- > > Message: 1 > Date: Wed, 18 Jul 2018 11:34:39 +0200 > From: Ali Abdallah > To: freebsd-current@freebsd.org > Subject: Re: top -n -o res shows empty output > Message-ID: > < > cao3okx934ekt9p8o5ja1bocb-pwbgpmgm-k-r4tw1nfqsxu...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > I have submitted a bug report with a patch > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229842 > > Best, > Ali > > On Tue, Jul 17, 2018 at 1:41 PM Ali Abdallah wrote: > > > Hello, > > > > From around the revision r334918, the command 'top -n -o res' shows empty > > output. > > > > With best regards, > > Ali > > > > > -- > > Subject: Digest Footer > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > -- > > End of freebsd-current Digest, Vol 768, Issue 3 > *** > -- [image: New Context] <https://www.newcontext.com/> Mike Bergfors Director of Operations ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
On 6/13/2018 6:35 AM, Konstantin Belousov wrote:
>
> Please report the results. If the script helps, I will code the kernel
> change to apply the workarounds.
The hard lockups I was seeing on Ryzen and Epyc boxes are now gone with
the microcode and script below.
Not sure if its one or some combo of the settings, but all the steps
below have made my 2 test systems stable on RELENG_11 anyways.
This was on a Ryzen 5 1600X (ASUS PRIME X370-PRO BIOS from 04/19/2018)
CPU Microcode patch level: 0x8001137
And
EPYC 7281 16-Core (Supermicro H11SSL-i BIOS 04/27/2018 )
Microcode patch level: 0x8001227
Details of the issue were discussed at
https://lists.freebsd.org/pipermail/freebsd-virtualization/2018-March/006187.html
and
https://lists.freebsd.org/pipermail/freebsd-stable/2018-January/088174.html
TL;DR : Generating traffic via iperf3 between VMs either on bhyve or
VirtualBox would make the box lockup-- no crash, just a blank screen
---Mike
>
> #!/bin/sh
>
> # Enable workarounds for erratas listed in
> # https://developer.amd.com/wp-content/resources/55449_1.12.pdf
>
> # 1057, 1109
> sysctl machdep.idle_mwait=0
> sysctl machdep.idle=hlt
>
> for x in /dev/cpuctl*; do
> # 1021
> cpucontrol -m '0xc0011029|=0x2000' $x
> # 1033
> cpucontrol -m '0xc0011020|=0x10' $x
> # 1049
> cpucontrol -m '0xc0011028|=0x10' $x
> # 1095
> cpucontrol -m '0xc0011020|=0x200' $x
> done
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
>
--
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas (and Epyc ?)
On 6/14/2018 11:03 AM, Konstantin Belousov wrote: > I am not sure about only microcode update. Depending on the BIOS > vendor and current BIOS, you may need all three: BIOS update, microcode > update using cpucontrol/devcpu-data, and running the script I posted. > In the best case, some of this is just redundand. OK, before and after shows the same microcode rev CPU: AMD EPYC 7281 16-Core Processor (2100.06-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f12 Family=0x17 Model=0x1 Stepping=2 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x1007 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics # x86info -a | grep -i micro Microcode patch level: 0x8001227 # I then ran the fix script. I will let the box grind away over the weekend to see if it survives. Previously, a couple of hours would lock it up. I am running it now. One thing I did notice is a bunch of these showing up Jun 14 17:11:18 r11epyc kernel: fpudna: fpcurthread == curthread ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
On 6/14/2018 11:03 AM, Konstantin Belousov wrote:
> I am not sure about only microcode update. Depending on the BIOS
> vendor and current BIOS, you may need all three: BIOS update, microcode
> update using cpucontrol/devcpu-data, and running the script I posted.
> In the best case, some of this is just redundand.
Thanks, I will run the tests on the Epyc system over the next few days.
It took a little longer to crash the Epyc than the Ryzen. The Ryzen is
still going now for 20hrs. Previously 5-10 min were enough to trigger
the hard lockup.
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
On 6/14/2018 9:36 AM, Eric van Gyzen wrote: > On 06/13/2018 05:35, Konstantin Belousov wrote: >> Today I noted that AMD published the public errata document for Ryzens, >> https://developer.amd.com/wp-content/resources/55449_1.12.pdf >> >> Some of the issues listed there looks quite relevant to the potential >> hangs that some people still experience with the machines. I wrote >> a script which should apply the recommended workarounds to the erratas >> that I find interesting. >> >> To run it, kldload cpuctl, then apply the latest firmware update to your >> CPU, then run the following shell script. Comments indicate the errata >> number for the workarounds. >> >> Please report the results. If the script helps, I will code the kernel >> change to apply the workarounds. > Kostik: This thread on the -stable list has a lot of positive feedback: > > https://lists.freebsd.org/pipermail/freebsd-stable/2018-June/089110.html I have a couple of Epyc boxes that showed the same lockup behaviour. I will re-install FreeBSD on them and see if their microcode updates fix this issue as well... Should I run the same cpuctl commands on those CPUs ? BTW, I am happy to loan one out to you in the FreeBSD netperf cluster for a few weeks ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen public erratas
On 6/13/2018 6:35 AM, Konstantin Belousov wrote: > Today I noted that AMD published the public errata document for Ryzens, > https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > Some of the issues listed there looks quite relevant to the potential > hangs that some people still experience with the machines. I wrote > a script which should apply the recommended workarounds to the erratas > that I find interesting. > > To run it, kldload cpuctl, then apply the latest firmware update to your > CPU, then run the following shell script. Comments indicate the errata > number for the workarounds. Hi, tl;dr: The Microcode changes seem to fix a hard lockup I was able to reliable reproduce back in Feb. The BIOS on my AMD is pretty up to date. I think it has the same microcode as whats in the ports. x86info -a shows root@ryzenbsd11:/home/mdtancsa # x86info -a | grep -i microc Microcode patch level: 0x8001137 root@ryzenbsd11:/home/mdtancsa # after running the microcode update and root@ryzenbsd11:/home/mdtancsa # /usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Done. root@ryzenbsd11:/home/mdtancsa # x86info -a | grep -i microc Microcode patch level: 0x8001137 root@ryzenbsd11:/home/mdtancsa # However, the dmesg after the microcode update adds this line AMD Extended Feature Extensions ID EBX=0x1007 CPU: AMD Ryzen 5 1600X Six-Core Processor(3593.36-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics I ran the script root@ryzenbsd11:/home/mdtancsa # cat fix.sh #!/bin/sh # Enable workarounds for erratas listed in # https://developer.amd.com/wp-content/resources/55449_1.12.pdf # 1057, 1109 sysctl machdep.idle_mwait=0 sysctl machdep.idle=hlt for x in /dev/cpuctl*; do # 1021 cpucontrol -m '0xc0011029|=0x2000' $x # 1033 cpucontrol -m '0xc0011020|=0x10' $x # 1049 cpucontrol -m '0xc0011028|=0x10' $x # 1095 cpucontrol -m '0xc0011020|=0x200' $x echo $x done root@ryzenbsd11:/home/mdtancsa # sh ./fix.sh machdep.idle_mwait: 1 -> 0 machdep.idle: acpi -> hlt /dev/cpuctl0 /dev/cpuctl1 /dev/cpuctl10 /dev/cpuctl11 /dev/cpuctl2 /dev/cpuctl3 /dev/cpuctl4 /dev/cpuctl5 /dev/cpuctl6 /dev/cpuctl7 /dev/cpuctl8 /dev/cpuctl9 root@ryzenbsd11:/home/mdtancsa # Using a FreeBSD stable from back in Feb, I was able to crash Ryzen and Epyc based systems (https://lists.freebsd.org/pipermail/freebsd-stable/2018-February/088439.html) by generating a lot of traffic between the hypervisor and guests. The same tests on an intel based box ran just fine. e.g. start 3 guests in bhyve (amd64) and run combos of iperf3 between them. It would not take too long, but the box would hard lock-- i.e. blank screen, no crash dump etc. With the latest micro code update, I have been running the same sort of tests and so far so good. I will let them run overnight to see if things are now stable on STABLE. ---Mike > > Please report the results. If the script helps, I will code the kernel > change to apply the workarounds. > > #!/bin/sh > > # Enable workarounds for erratas listed in > # https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > # 1057, 1109 > sysctl machdep.idle_mwait=0 > sysctl machdep.idle=hlt > > for x in /dev/cpuctl*; do > # 1021 > cpucontrol -m '0xc0011029|=0x2000' $x > # 1033 > cpucontrol -m '0xc0011020|=0x10' $x > # 1049 > cpucontrol -m '0xc0011028|=0x10' $x > # 1095 > cpucontrol -m '0xc0011020|=0x200' $x > done > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ryzen specific issues
On 1/31/2018 8:37 AM, Mike Tancsa wrote: > Hi folks, > I have been running into some deadlock issues on Ryzen boards. The > most easy way to trigger the problem is to compile net/samba47 from the > ports. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584 > > Varying the load sometimes allows the compile to finish, but most of the > time the compile deadlocks. I have seen this both on RELENG_11 as well > as HEAD from r328611 > > Any ideas how to possibly work around this ? sysctl kern.eventtimer.periodic=1 doesnt seem to help on HEAD First build attempt and it hangs in a similar / same way G -D_SAMBA_BUILD_=4 -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1 -D_XOPEN_SOURCE_EXTENDED=1 default/source4/heimdal/lib/hx509/asn1_ocsp_asn1.c -c -o default/source4/heimdal/lib/hx509/asn1_ocsp_asn1_92.o [1008/3804] Compiling source4/heimdal/lib/hcrypto/libtommath/bncore.c runner cc -pipe -g -ggdb -gdwarf-2 -gstrict-dwarf -DLIBICONV_PLUG -fno-color-diagnostics -D_FUNCTION_DEF -g -fstack-protector -DLDAP_DEPRECATED -fno-strict-aliasing -fno-omit-frame-pointer -fPIC -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DSTATIC_tommath_MODULES=NULL -DSTATIC_tommath_MODULES_PROTO=extern void __tommath_dummy_module_proto(void) -MD -Idefault/source4/heimdal_build -I../source4/heimdal_build -Idefault/source4/heimdal/lib/hcrypto/libtommath -I../source4/heimdal/lib/hcrypto/libtommath -Idefault/include/public -I../include/public -Idefault/source4 -I../source4 -Idefault/lib -I../lib -Idefault/source4/lib -I../source4/lib -Idefault/source4/include -I../source4/include -Idefault/include -I../include -Idefault/lib/replace -I../lib/replace -Idefault -I.. -I/usr/local/include -I/usr/local/include -DLIBICONV_PLUG -D_SAMBA_BUILD_=4 -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1 -D_XOPEN_SOURCE_EXTENDED=1 ../source4/heimdal/lib/hcrypto/libtommath/bncore.c -c -o default/source4/heimdal/lib/hcrypto/libtommath/bncore_83.o ctrl+t load: 3.14 cmd: sh 94611 [wait] 490.27r 0.00u 0.00s 0% 2240k make: Working in: /usr/ports/net/samba47 make[1]: Working in: /usr/ports/net/samba47 load: 3.14 cmd: sh 94611 [wait] 490.27r 0.00u 0.00s 0% 2240k make: Working in: /usr/ports/net/samba47 make[1]: Working in: /usr/ports/net/samba47 root@amdtestr12:/tmp # procstat -kk 14062 PIDTID COMMTDNAME KSTACK 14062 100933 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101206 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_lock_umutex+0x6e3 __umtx_op_wait_umutex+0x48 amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101207 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101208 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101209 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101210 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101211 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101212 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101213 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101214 python2.7 - mi_switch+0x18c sleepq_switch+0x10d sleepq_catch_signals+0x300 sleepq_wait_sig+0xf _sleep+0x359 umtxq_sleep+0x163 do_sem2_wait+0x426 __umtx_op_sem2_wait+0x4b amd64_syscall+0x79b fast_syscall_common+0xfc 14062 101215 python2.7 - mi_switch+0x18c sleepq_swi
Ryzen specific issues
Hi folks, I have been running into some deadlock issues on Ryzen boards. The most easy way to trigger the problem is to compile net/samba47 from the ports. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584 Varying the load sometimes allows the compile to finish, but most of the time the compile deadlocks. I have seen this both on RELENG_11 as well as HEAD from r328611 Any ideas how to possibly work around this ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832
On 1/12/2018 11:58 AM, Sean Bruno wrote: >> > > Probably, update your port of x86info. I pushed an update for this and > it might work better for you. Thanks, I tried it but still generates the error / warning. What does it mean ? (CPU0: local APIC error 0x80) It does however get rid of the "Unknown CPU family" error. root@testamd:/usr/ports/sysutils/devcpu-data # x86info -a | head x86info v1.31pre Found 12 identical CPUs Extended Family: 8 Extended Model: 0 Family: 15 Model: 1 Stepping: 1 CPU Model (x86info's best guess): AMD Zen Series Processor (ZP-B1) Processor name string (BIOS programmed): AMD Ryzen 5 1600X Six-Core Processor Number of reporting banks : 7 MCG_CTL: Data cache check enabled root@testamd:/usr/ports/sysutils/devcpu-data # >> >> Also your diff is based on a previous version of the port. There was an >> update since, with new microcode from Intel that gets clobbered in your >> diffs. >> >> > > The update to Intel microcode was reverted. So, possibly the tree you > are using is out of date? Ahh, yes. I must have grabbed the ports just before you backed it out https://lists.freebsd.org/pipermail/svn-ports-all/2018-January/171209.html Thanks! ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832
On 1/11/2018 6:03 PM, Sean Bruno wrote: > https://reviews.freebsd.org/D13832 <--- test this update > > I'd like to get some feedback from AMD cpu users on this update. I've > restructured and undone a few things that may have been keeping folks > using this port from getting their runtime cpu microcode updates. Hi, I am trying out on RELENG_11 on a Ryzen CPU Without kib's commits at https://lists.freebsd.org/pipermail/svn-src-stable-11/2018-January/005320.html I get root@testamd:/usr/ports/sysutils/devcpu-data # /usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Re-evalutation of CPU flags Failed. root@testamd:/usr/ports/sysutils/devcpu-data # with r327597, root@testamd:/home/mdtancsa # /usr/local/etc/rc.d/microcode_update onestart Updating CPU Microcode... Done. root@testamd:/home/mdtancsa # running x86info -a also generates this error / warning ? CPU0: local APIC error 0x80 root@testamd:/home/mdtancsa # x86info -a | grep -i microco Microcode patch level: 0x8001129 root@testamd:/home/mdtancsa # x86info -a | head -20 x86info v1.31pre Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Unknown CPU family: 0x17 Found 12 identical CPUs Extended Family: 8 Extended Model: 0 Family: 15 Model: 1 Stepping: 1 CPU Model (x86info's best guess): Processor name string (BIOS programmed): AMD Ryzen 5 1600X Six-Core Processor Number of reporting banks : 7 root@testamd:/home/mdtancsa # Also your diff is based on a previous version of the port. There was an update since, with new microcode from Intel that gets clobbered in your diffs. Thanks! ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The future of the roff toolchain
On 21 May 2017, at 15:36, Benjamin Kaduk wrote: On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote: What I want to propose now, it to render them as PDF (html?) once and push them somewhere (to be defined) as static document on our documentation website. Please doceng@ provide me a location where to push them. And then remove bsd.doc.mk from FreeBSD 12.0 along with the removal of groff. I also want to remove most of roff related tools (the one provided by toolchains available in ports) for which we kept a BSD version (not really maintained in base): namely: - checknr - vgrind - colcrt Only keeping: - col (useful in other places than roff) - soelim (also used for manpages and we have a clean BSD licensed version which is also now parts of mandoc) That sounds like a good plan to me. Thank you for putting in all the time trying out the alternate roff toolchains! +1. I agree that /usr/share/doc is strictly legacy; only the man pages matter for base. ___ freebsd-a...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI SAS 3108 RAID Controller
On 2/3/2016 9:20 AM, krad wrote:
>
> If zfs you probably want the reflash the card the the relevant HBA firmware
> rather the the raid firmware. This will expose the disks nativly which is
> best for zfs.
The version of card I have allows you to expose the individual disks as
JBODs out of the box.
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI SAS 3108 RAID Controller
On 2/2/2016 12:06 PM, Zara Kanaeva wrote:
> Dear list,
>
> I have one Fujitsu server with LSI SAS 3108 RAID Controller. These LSI
> SAS 3108 RAID Controller is supported by the mpr driver
Try and attach the mrsas driver to the card. I had a similar problem
with an onboard variant. Either compile the kernel without the mfi
driver, or force the kernel to assign the mrsas driver to it instead of
the mfi driver.
hw.mfi.mrsas_enable=1
in /boot/loader.conf
# pciconf -lv mrsas0
mrsas0@pci0:1:0:0: class=0x010400 card=0x080915d9 chip=0x005d1000
rev=0x02 hdr=0x00
vendor = 'LSI Logic / Symbios Logic'
device = 'MegaRAID SAS-3 3108 [Invader]'
class = mass storage
subclass = RAID
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[no subject]
___ 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
Re: mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i
On 4/7/2015 3:04 PM, Garrett Cooper wrote: Hi, I just tried to upgrade my system from a Nehalem style era CPU/motherboard (a W series Xeon/P6T-WS) to a Haswell style CPU/motherboard (an E-series Haswell/Z97 motherboard), and I’ve run into some fun issues with my LSI 9240-4i controller. In particular, it’s timing out because of issues noted similar to here: https://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064404.html . I’ve done the following so far to try and diagnose the issue: - Upgraded the firmware on the card and in the BIOS Does anyone have any thoughts or hints on this issue? What firmware are you running on the card ? What does mfiutil show firmware give you ? I am running with good results so far 3 cards with on RELENG10 and RELENG9 (well, FreeNAS) mfi0 Firmware Package Version: 20.13.1-0208 mfi0 Firmware Images: Name Version Date Time Status BIOS 4.38.02.2_4.16.08.00_0x06060A05 07/23/2014 07/23/2014 active PCLI 03.02-020:#%9May 07 2012 13:21:53 active BCON 4.0-61-e_50-Rel Sep 09 2014 11:45:57 active NVDT 3.09.03-0064 Oct 06 2014 12:00:15 active APP 2.130.404-3836 Oct 16 2014 06:50:12 active BTBL 2.02.00.00-0001 Aug 18 2010 11:44:44 active -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ 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
Re: mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i
On 4/7/2015 4:25 PM, NGie Cooper wrote: Hi Mike! That's the version I'm running too. Do you have the same model motherboard (there are a couple Z97s, I don't think it matters which one as long as it's the same family)? If so, it's probably something to do with the state of the volume, i.e. I might need to export and reimport it. Thanks for the feedback :)! Hi, All are Intel MB S1200RP_SE. Sorry :( I will take a quick look in the lab to see if there are any ASUS boards around, but I dont think so. BIOS Information Vendor: Intel Corp. Version: S1200RP.86B.02.01.0004.051320141432 Release Date: 05/13/2014 ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ 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
Re: mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i
On 4/7/2015 3:14 PM, Mike Tancsa wrote: On 4/7/2015 3:04 PM, Garrett Cooper wrote: Hi, I just tried to upgrade my system from a Nehalem style era CPU/motherboard (a W series Xeon/P6T-WS) to a Haswell style CPU/motherboard (an E-series Haswell/Z97 motherboard), and I’ve run into some fun issues with my LSI 9240-4i controller. In particular, it’s timing out because of issues noted similar to here: https://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064404.html . I’ve done the following so far to try and diagnose the issue: - Upgraded the firmware on the card and in the BIOS Probably not related to your issue, but another trick with this card that was helpful for me https://lists.freebsd.org/pipermail/freebsd-questions/2014-December/262744.html ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ 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
Re: SSH hung with an OpenSSH_6.6.1p1 -- OpenSSH_5.8p2_hpn13v11
On 3/26/2015 2:44 AM, Wu ShuKun wrote: OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 failed with Latest SSH: % ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 Hi, The latest is 1.0.1m, no? }# ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1m-freebsd 19 Mar 2015 What version of FreeBSD are you using ? Ssh and Openssl from the ports ? or in the base ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ 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
Re: default pager (csh)
Kim Shrier k...@westryn.net wrote: On Feb 18, 2015, at 4:41 PM, Xin Li delp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/18/15 15:18, Davide Italiano wrote: Hi, one of the first things I do when I install FreeBSD is to switch the default PAGER from more(1) to less(1). This is particularly convenient, e.g. while using git diff, to show something more readable. Just out of curiosity, is there a reason why more(1) is still the default, and/or is this just historical? The _only_ reason that I can think of is that more(1) does not clear screen for certain terminals (done with 'ti' and 'te' sequences), while less(1) when running as less does. The less(1) behavior can be annoying to some people (sometimes even myself when using less to show contents of a file and ^Z to paste them), and unfortunately quite a few of them also happen to be the more vocal ones when it comes to a change. Being one of those people who strongly prefer using more, I vote against this change. Also, it is easier to scroll back in a terminal window using more. Every system I use, if it defaults the PAGER to less, I change it to more. I think the defaults of both programs on FreeBSD are suboptimal. I prefer more with MORE=-eF, which fixes the man page issue mentioned earlier. This is clearly a personal preference item; we won't get it right for everyone. However, anyone who can use git can definitely switch pagers. Trivia: the version of more on BSD systems actually is derived from less, not the original version of more. Mike ___ 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
Re: i915kms.ko regression?
Am 2015-02-05 09:46, schrieb Lutz Bichler: Hi Johannes, i am experiencing a similar behavior on an Asus UX31A. The display is active but brightness seems to be near 0 and unchangeable. Reverting https://svnweb.freebsd.org/changeset/base/277959 made me get full brightness again. Unfortunately, brightness changing does not work. Me too for my Asus UX32VD Notebook. Greetings --- Michael Reifenberger ___ 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
Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0
On 1/8/2015 1:21 PM, Benjamin Kaduk wrote: I have no specific data about this specific case, but the advertised procedure for upgrading between major branches is to update to the tip of the starting branch before attempting the major version jump, i.e., update to the tip of stable/9 before attempting to go to stable/10 or head. Actually, there seems to be a new caveat to this discussed in https://lists.freebsd.org/pipermail/freebsd-stable/2015-January/081521.html ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ 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
Re: simple task to speed up booting
On Sun, 2014-12-14 at 10:32 +, Poul-Henning Kamp wrote:
The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
large part of our boot time on systems with slow-ish serial consoles.
I think right now it takes a step for each 512 byte read, reducing that
to once every 64kB or even 1MB would be an improvement with the kind of
kernel sizes we have today.
I experimented with that a while ago using the attached patch and was
disappointed with the results. As I vaguely remember it, a divisor of 8
looked fine, but had no significant speedup. With a divisor of 32 the
difference was measureable (only like 1.5 seconds or so faster), but it
gave the impression that something was wrong, and the overall perception
was that it was slower rather than faster, despite what a stopwatch
said.
I was testing at 115kbps, maybe at 9600 it would be significant. I
don't understand why anything these days is still defaulting to 9600.
It's the 21st century, but we never got the George Jetson flying cars we
were promised, and apparently we're never going to break loose from the
standards set by accoustic-coupled modems.
AFAIK, accoustic-coupled modems topped out at 300 baud; that's the fastest
one I've used, anyway.
Defaults are hard to change, though.
Mike
___
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
Re: Looping during boot-up process in FreeBSD-11 current
On 10/5/2014 at 1:57 AM Alexander V. Chernikov wrote: |On 01.10.2014 02:02, Mike. wrote: | On 9/30/2014 at 7:25 PM José Pérez Arauzo wrote: | | | |[snip] | |Try the 271146, | |[snip] | = | |This might be related with r271207. |Can you try r271206 (or any recent HEAD with reverted r271207) ? | = Thanks for the reply. Apologies for the delay in responding, I've been off the grid since last Thursday. I tried r271206 and r271207. They both worked. The boot sequence progressed up to and including the login prompt. If there's anything else you'd like me to try, let me know. Thanks, Mike ___ 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
Re: Looping during boot-up process in FreeBSD-11 current
On 9/29/2014 at 11:04 PM José Pérez Arauzo wrote: |This encoded message has been converted to an attachment. | |Hi Mike, | |On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote [...] |So that should put a time bracket on the issue, |roughly the first half of 2014. | |can you boot 271146? Just buildkernel and installkernel. Thank |you. = There doesn't seem to be much, if any, interest on the part of the FreeBSD developers in fixing this recently-introduced issue with booting up FreeBSD. Since I experience the problem only on the one notebook of mine, I'll just re-purpose that notebook for OpenBSD and try to find another old notebook that works with FreeBSD. Seems like the path of least resistance for me ___ 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
Re: Looping during boot-up process in FreeBSD-11 current
On 9/30/2014 at 9:57 AM Garrett Cooper wrote: |Did you boot with boot -d, using a stripped down kernel, |and without SMP like I suggested in another post? = Unfortunately, this is the first message of yours that I've seen on this topic. I even checked the mailing list archives ( http://lists.freebsd.org/pipermail/freebsd-current/2014-September/auth or.html ) and I did not see any other message from you. Can you resend it? (I just tried boot -d and found myself in strange territory, a debugger?) thx. ___ 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
Re: Looping during boot-up process in FreeBSD-11 current
On 9/30/2014 at 7:25 PM José Pérez Arauzo wrote: |[snip] |Try the 271146, |[snip] = I installed the 10.0 release CD. Then (after installing pkg, svn, etc.): cd /usr/src svn update -r271146 make buildkernel make installkernel reboot I got to the login prompt, so it did not exhibit the looping issue I've experienced. /usr/src/UPDATING shows 20140708 p7 as the latest patch for the source. dmesg (with boot -v) follows: (note: when I boot 11.0-current with boot -v, the looping begins right after the place where the GEOM: new disk cd0 line appears in the dmesg below) Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-RELEASE-p7 #0 r271146: Tue Sep 30 16:38:12 EDT 2014 root@a31pf:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Preloaded elf kernel /boot/kernel/kernel at 0xc1678000. Calibrating TSC clock ... TSC clock: 1698592154 Hz CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz (1698.59-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Family = 0xf Model = 0x2 Stepping = 4 Features=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PG E,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 64 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64 byte line size real memory = 1073741824 (1024 MB) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x01826000 - 0x3ee0efff, 1029607424 bytes (251369 pages) avail memory = 1029230592 (981 MB) XEN: CPU 0 has VCPU ID 4294967295 bios32: Found BIOS32 Service Directory header at 0xc00f7030 bios32: Entry = 0xfd7e0 (c00fd7e0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd770+0x18e pnpbios: Found PnP BIOS data at 0xc00f7090 pnpbios: Entry = f:9d76 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: ULE: setup cpu 0 wlan: 802.11 Link Layer snd_unit_init() u=0x00ff8000 [512] d=0x7c00 [32] c=0x03ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 Hardware, VIA Nehemiah Padlock RNG: VIA Padlock RNG not present Hardware, Intel IvyBridge+ RNG: RDRAND is not present kbd: new array size 4 kbd1 at kbdmux0 mem: memory Pentium Pro MTRR support enabled nfslock: pseudo-device null: null device, zero device Falling back to Software, Yarrow random adaptor random: Software, Yarrow initialized VESA: INT 0x10 vector 0xc000:0x206c VESA: information block 56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 0010 00 01 ff 03 00 01 19 01 00 01 2f 01 00 01 34 01 0020 00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 0030 94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01 0040 b2 01 b3 01 b4 01 b5 01 b6 01 c2 01 c3 01 c4 01 0050 c5 01 c6 01 00 01 83 01 84 01 85 01 86 01 01 01 0060 10 01 11 01 12 01 21 01 03 01 13 01 14 01 15 01 0070 22 01 05 01 16 01 17 01 18 01 23 01 07 01 19 01 0080 1a 01 1b 01 24 01 40 01 41 01 42 01 43 01 44 01 0090 72 01 73 01 74 01 75 01 76 01 ff ff 00 00 00 00 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 41 54 49 20 4d 4f 42 49 4c 49 54 59 20 52 41 44 0110 45 4f 4e 20 37 35 30 30 00 41 54 49 20 54 65 63 0120 68 6e 6f 6c 6f 67 69 65 73 20 49 6e 63 2e 00 50 0130 37 20 20 00 30 31 2e 30 30 00 00 00 00 00 00 00 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 60 mode(s) found VESA: v2.0, 65472k memory, flags:0x1, mode table:0xe3ee6022 (122) VESA: ATI MOBILITY RADEON 7500 VESA: ATI Technologies Inc. P7 01.00 io: I/O hpt27xx: RocketRAID 27xx
Re: Looping during boot-up process in FreeBSD-11 current
On 9/29/2014 at 2:15 AM José Pérez Arauzo wrote: |This encoded message has been converted to an attachment. | |Hi Mike, |It looks like we are hitting the same problem. If we find a |third person with the same issue we can fund a club. :) |Interesting to note: | 1) we both run FBSD on small netbooks which usually get | equipped with crappy ^D^D^D^D^D^D^D cheap hardware. | 2) yours seems to be an Intel-only box, mine is an AMD-only, | so the problem is not there (I mean, it's not the graphic | chip). | 3) we both have an Atheros wifi, whose driver has been updated | recently, maybe this is the issue? The notebook in question is a circa-2002 IBM Thinkpad A31p (of the workstation replacement genre of the day). If you're curious, here's more info on it: http://www.tomsguide.com/us/ibm-thinkpad-a31p,review-42.html The Atheros WiFi is a SMC PC-Card adapter. I can unplug it to see if it has any effect on the issue. I'll do that later today when the compiling finishes. :) [snip] |I will keep you posted, in the meantime you can try and | boot your pc from 271146, it works for me. Once I figure out how to do that, I'll give it a try. :) Meanwhile, make buildkernel with 270327 should finish compiling in a few hours Thanks. Mike. ___ 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
Re: Looping during boot-up process in FreeBSD-11 current
On 9/28/2014 at 5:01 PM Steven Hartland wrote: |The only recent ATAPI change I recall is 270327, does it still occur |if you revert that? | = I downloaded 11-current via svn, then copied over the pre-270327 version of ata_xpt.c. make buildworld make buildkernel make installkernel reboot The looping still occurs. I haven't checked it character for character, but it the display looks to have the same or very similar information during the looping as the two pictures I posted yesterday. Thanks. Mike. btw, the Atheros WiFi card was removed, with no change in outcome. ___ 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
Re: Looping during boot-up process in FreeBSD-11 current
On 9/28/2014 at 5:01 PM Steven Hartland wrote: |The only recent ATAPI change I recall is 270327, does it still occur |if you revert that? | |Regards |Steve = Another data point. I just downloaded the image: FreeBSD-10.1-BETA3-i386-disc1 The looping occurs also with that CD. Perhaps this is not caused by a recent change? ___ 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
Re: Looping during boot-up process in FreeBSD-11 current
On 9/28/2014 at 5:01 PM Steven Hartland wrote: |The only recent ATAPI change I recall is 270327, does it still occur |if you revert that? | |Regards |Steve = Yet another data point (actually two data points). I had an older STABLE image sitting around. FreeBSD-10.0-STABLE-i386-20140712-r268571-disc1 The looping occurs also with that CD. And, finally, the looping does not occur with 10.0-RELEASE. This release seems to be able to recover from the timeouts. So that should put a time bracket on the issue, roughly the first half of 2014. ___ 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
