Date: Mon, 27 Oct 2014 14:22:52 +0100 From: Svatopluk Kraus <onwahe@gmail.com> To: Alan Cox <alc@rice.edu> Cc: alc@freebsd.org, FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: vm_page_array and VM_PHYSSEG_SPARSE Message-ID: <CAFHCsPV1H6XsOoDFitQFgJOP6u%2BgiEM=N--_7Q9uoWbYnAaeYQ@mail.gmail.com> In-Reply-To: <544DED4C.3010501@rice.edu> References: <CAFHCsPWkq09_RRDz7fy3UgsRFv8ZbNKdAH2Ft0x6aVSwLPi6BQ@mail.gmail.com> <CAJUyCcPXBuLu0nvaCqpg8NJ6KzAX9BA1Rt%2BooD%2B3pzq%2BFV%2B%2BTQ@mail.gmail.com> <CAFHCsPWq9WqeFnx1a%2BStfSxj=jwcE9GPyVsoyh0%2Bazr3HmM6vQ@mail.gmail.com> <5428AF3B.1030906@rice.edu> <CAFHCsPWxF0G%2BbqBYgxH=WtV%2BSt_UTWZj%2BY2-PHfoYSLjC_Qpig@mail.gmail.com> <54497DC1.5070506@rice.edu> <CAFHCsPVj3PGbkSmkKsd2bGvmh3%2BdZLABi=AR7jQ4qJ8CigE=8Q@mail.gmail.com> <544DED4C.3010501@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--001a11c2d8ba8f4c290506676df8 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 27, 2014 at 7:59 AM, Alan Cox <alc@rice.edu> wrote: > On 10/24/2014 06:33, Svatopluk Kraus wrote: > > > On Fri, Oct 24, 2014 at 12:14 AM, Alan Cox <alc@rice.edu> wrote: > >> On 10/08/2014 10:38, Svatopluk Kraus wrote: >> > On Mon, Sep 29, 2014 at 3:00 AM, Alan Cox <alc@rice.edu> wrote: >> > >> >> On 09/27/2014 03:51, Svatopluk Kraus wrote: >> >> >> >> >> >> On Fri, Sep 26, 2014 at 8:08 PM, Alan Cox <alan.l.cox@gmail.com> >> wrote: >> >> >> >>> >> >>> On Wed, Sep 24, 2014 at 7:27 AM, Svatopluk Kraus <onwahe@gmail.com> >> >>> wrote: >> >>> >> >>>> Hi, >> >>>> >> >>>> I and Michal are finishing new ARM pmap-v6 code. There is one problem >> >>>> we've >> >>>> dealt with somehow, but now we would like to do it better. It's about >> >>>> physical pages which are allocated before vm subsystem is >> initialized. >> >>>> While later on these pages could be found in vm_page_array when >> >>>> VM_PHYSSEG_DENSE memory model is used, it's not true for >> >>>> VM_PHYSSEG_SPARSE >> >>>> memory model. And ARM world uses VM_PHYSSEG_SPARSE model. >> >>>> >> >>>> It really would be nice to utilize vm_page_array for such >> preallocated >> >>>> physical pages even when VM_PHYSSEG_SPARSE memory model is used. >> Things >> >>>> could be much easier then. In our case, it's about pages which are >> used >> >>>> for >> >>>> level 2 page tables. In VM_PHYSSEG_SPARSE model, we have two sets of >> such >> >>>> pages. First ones are preallocated and second ones are allocated >> after vm >> >>>> subsystem was inited. We must deal with each set differently. So >> code is >> >>>> more complex and so is debugging. >> >>>> >> >>>> Thus we need some method how to say that some part of physical memory >> >>>> should be included in vm_page_array, but the pages from that region >> >>>> should >> >>>> not be put to free list during initialization. We think that such >> >>>> possibility could be utilized in general. There could be a need for >> some >> >>>> physical space which: >> >>>> >> >>>> (1) is needed only during boot and later on it can be freed and put >> to vm >> >>>> subsystem, >> >>>> >> >>>> (2) is needed for something else and vm_page_array code could be used >> >>>> without some kind of its duplication. >> >>>> >> >>>> There is already some code which deals with blacklisted pages in >> >>>> vm_page.c >> >>>> file. So the easiest way how to deal with presented situation is to >> add >> >>>> some callback to this part of code which will be able to either >> exclude >> >>>> whole phys_avail[i], phys_avail[i+1] region or single pages. As the >> >>>> biggest >> >>>> phys_avail region is used for vm subsystem allocations, there should >> be >> >>>> some more coding. (However, blacklisted pages are not dealt with on >> that >> >>>> part of region.) >> >>>> >> >>>> We would like to know if there is any objection: >> >>>> >> >>>> (1) to deal with presented problem, >> >>>> (2) to deal with the problem presented way. >> >>>> Some help is very appreciated. Thanks >> >>>> >> >>>> >> >>> As an experiment, try modifying vm_phys.c to use dump_avail instead of >> >>> phys_avail when sizing vm_page_array. On amd64, where the same >> problem >> >>> exists, this allowed me to use VM_PHYSSEG_SPARSE. Right now, this is >> >>> probably my preferred solution. The catch being that not all >> architectures >> >>> implement dump_avail, but my recollection is that arm does. >> >>> >> >> Frankly, I would prefer this too, but there is one big open question: >> >> >> >> What is dump_avail for? >> >> >> >> >> >> >> >> dump_avail[] is solving a similar problem in the minidump code, hence, >> the >> >> prefix "dump_" in its name. In other words, the minidump code >> couldn't use >> >> phys_avail[] either because it didn't describe the full range of >> physical >> >> addresses that might be included in a minidump, so dump_avail[] was >> created. >> >> >> >> There is already precedent for what I'm suggesting. dump_avail[] is >> >> already (ab)used outside of the minidump code on x86 to solve this same >> >> problem in x86/x86/nexus.c, and on arm in arm/arm/mem.c. >> >> >> >> >> >> Using it for vm_page_array initialization and segmentation means that >> >> phys_avail must be a subset of it. And this must be stated and be >> visible >> >> enough. Maybe it should be even checked in code. I like the idea of >> >> thinking about dump_avail as something what desribes all memory in a >> >> system, but it's not how dump_avail is defined in archs now. >> >> >> >> >> >> >> >> When you say "it's not how dump_avail is defined in archs now", I'm not >> >> sure whether you're talking about the code or the comments. In terms >> of >> >> code, dump_avail[] is a superset of phys_avail[], and I'm not aware of >> any >> >> code that would have to change. In terms of comments, I did a grep >> looking >> >> for comments defining what dump_avail[] is, because I couldn't remember >> >> any. I found one ... on arm. So, I don't think it's a onerous task >> >> changing the definition of dump_avail[]. :-) >> >> >> >> Already, as things stand today with dump_avail[] being used outside of >> the >> >> minidump code, one could reasonably argue that it should be renamed to >> >> something like phys_exists[]. >> >> >> >> >> >> >> >> I will experiment with it on monday then. However, it's not only about >> how >> >> memory segments are created in vm_phys.c, but it's about how >> vm_page_array >> >> size is computed in vm_page.c too. >> >> >> >> >> >> >> >> Yes, and there is also a place in vm_reserv.c that needs to change. >> I've >> >> attached the patch that I developed and tested a long time ago. It >> still >> >> applies cleanly and runs ok on amd64. >> >> >> >> >> >> >> > >> > >> > Well, I've created and tested minimalistic patch which - I hope - is >> > commitable. It runs ok on pandaboard (arm-v6) and solves presented >> problem. >> > I would really appreciate if this will be commited. Thanks. >> >> >> Sorry for the slow reply. I've just been swamped with work lately. I >> finally had some time to look at this in the last day or so. >> >> The first thing that I propose to do is commit the attached patch. This >> patch changes pmap_init() on amd64, armv6, and i386 so that it no longer >> consults phys_avail[] to determine the end of memory. Instead, it calls >> a new function provided by vm_phys.c to obtain the same information from >> vm_phys_segs[]. >> >> With this change, the new variable phys_managed in your patch wouldn't >> need to be a global. It could be a local variable in vm_page_startup() >> that we pass as a parameter to vm_phys_init() and vm_reserv_init(). >> >> More generally, the long-term vision that I have is that we would stop >> using phys_avail[] after vm_page_startup() had completed. It would only >> be used during initialization. After that we would use vm_phys_segs[] >> and functions provided by vm_phys.c. >> > > I understand. The patch and the long-term vision are fine for me. I just > was not to bold to pass phys_managed as a parameter to vm_phys_init() and > vm_reserv_init(). However, I certainly was thinking about it. While reading > comment above vm_phys_get_end(), do we care of if last usable address is > 0xFFFFFFFF? > > > > To date, this hasn't been a problem. However, handling 0xFFFFFFFF is > easy. So, the final version of the patch that I committed this weekend > does so. > > Can you please try the attached patch? It replaces phys_avail[] with > vm_phys_segs[] in arm's busdma. > It works fine on arm-v6 pandaboard. I have no objection to commit it. However, it's only 1:1 replacement. In fact, I still keep the following pattern in my head: present memory in system <=> all RAM and whatsoever nobounce memory <=> addressable by DMA managed memory by vm subsystem <=> i.e. kept in vm_page_array available memory for vm subsystem <=> can be allocated So, it's no problem to use phys_avail[], i.e. vm_phys_segs[], but it could be too much limiting in some scenarios. I would like to see something different in exclusion_bounce_check() in the future. Something what reflects NOBOUNCE property and not NOALLOC one like now. > > > > Do you think that the rest of my patch considering changes due to your > patch is ok? > > > > > Basically, yes. I do, however, think that > > +#if defined(__arm__) > + phys_managed = dump_avail; > +#else > + phys_managed = phys_avail; > +#endif > > should also be conditioned on VM_PHYSSEG_SPARSE. > So I've prepared new patch. phys_managed[] is passed to vm_phys_init() and vm_reserv_init() as a parameter and small optimalization is made in vm_page_startup(). I add VM_PHYSSEG_SPARSE condition to place you mentioned. Anyhow, I still think that this is only temporary hack. In general, phys_managed[] should always be distinguished from phys_avail[]. > > >> > >> > BTW, while I was inspecting all archs, I think that maybe it's time to >> do >> > what was done for busdma not long ago. There are many similar codes >> across >> > archs which deal with physical memory and could be generalized and put >> to >> > kern/subr_physmem.c for utilization. All work with physical memory >> could be >> > simplify to two arrays of regions. >> > >> > phys_present[] ... describes all present physical memory regions >> > phys_exclude[] ... describes various exclusions from phys_present[] >> > >> > Each excluded region will be labeled by flags to say what kind of >> exclusion >> > it is. The flags like NODUMP, NOALLOC, NOMANAGE, NOBOUNCE, NOMEMRW >> could >> > be combined. This idea is taken from sys/arm/arm/physmem.c. >> > >> > All other arrays like phys_managed[], phys_avail[], dump_avail[] will be >> > created from these phys_present[] and phys_exclude[]. >> > This way bootstrap codes in archs could be simplified and unified. For >> > example, dealing with either hw.physmem or page with PA 0x00000000 >> could be >> > transparent. >> > >> > I'm prepared to volunteer if the thing is ripe. However, some tutor >> will be >> > looked for. >> >> >> I've never really looked at arm/arm/physmem.c before. Let me do that >> before I comment on this. >> >> No problem. This could be long-term aim. However, I hope the > VM_PHYSSEG_SPARSE problem could be dealt with in MI code in present time. > In every case, thanks for your help. > > > > > --001a11c2d8ba8f4c290506676df8 Content-Type: application/octet-stream; name="phys_managed2.patch" Content-Disposition: attachment; filename="phys_managed2.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i1rurru11 SW5kZXg6IHN5cy92bS92bV9wYWdlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL3ZtL3ZtX3BhZ2UuYwko cmV2aXNpb24gMjczNzM0KQorKysgc3lzL3ZtL3ZtX3BhZ2UuYwkod29ya2luZyBjb3B5KQpAQCAt MjkwLDYgKzI5MCw3IEBACiAJdm1fcGFkZHJfdCBwYTsKIAl2bV9wYWRkcl90IGxhc3RfcGE7CiAJ Y2hhciAqbGlzdDsKKwl2bV9wYWRkcl90ICpwaHlzX21hbmFnZWQ7CgogCS8qIHRoZSBiaWdnZXN0 IG1lbW9yeSBhcnJheSBpcyB0aGUgc2Vjb25kIGdyb3VwIG9mIHBhZ2VzICovCiAJdm1fcGFkZHJf dCBlbmQ7CkBAIC0zMDEsMzEgKzMwMiwzOSBAQAogCWJpZ2dlc3RvbmUgPSAwOwogCXZhZGRyID0g cm91bmRfcGFnZSh2YWRkcik7CgotCWZvciAoaSA9IDA7IHBoeXNfYXZhaWxbaSArIDFdOyBpICs9 IDIpIHsKLQkJcGh5c19hdmFpbFtpXSA9IHJvdW5kX3BhZ2UocGh5c19hdmFpbFtpXSk7Ci0JCXBo eXNfYXZhaWxbaSArIDFdID0gdHJ1bmNfcGFnZShwaHlzX2F2YWlsW2kgKyAxXSk7CisjaWYgZGVm aW5lZChWTV9QSFlTU0VHX1NQQVJTRSkgJiYgZGVmaW5lZChfX2FybV9fKQorCXBoeXNfbWFuYWdl ZCA9IGR1bXBfYXZhaWw7CisjZWxzZQorCXBoeXNfbWFuYWdlZCA9IHBoeXNfYXZhaWw7CisjZW5k aWYKKworCWxvd193YXRlciA9IHJvdW5kX3BhZ2UocGh5c19tYW5hZ2VkWzBdKTsKKwloaWdoX3dh dGVyID0gcm91bmRfcGFnZShwaHlzX21hbmFnZWRbMV0pOworCWZvciAoaSA9IDI7IHBoeXNfbWFu YWdlZFtpICsgMV07IGkgKz0gMikgeworCQlwaHlzX21hbmFnZWRbaV0gPSByb3VuZF9wYWdlKHBo eXNfbWFuYWdlZFtpXSk7CisJCXBoeXNfbWFuYWdlZFtpICsgMV0gPSB0cnVuY19wYWdlKHBoeXNf bWFuYWdlZFtpICsgMV0pOworCQlpZiAocGh5c19tYW5hZ2VkW2ldIDwgbG93X3dhdGVyKQorCQkJ bG93X3dhdGVyID0gcGh5c19tYW5hZ2VkW2ldOworCQlpZiAocGh5c19tYW5hZ2VkW2kgKyAxXSA+ IGhpZ2hfd2F0ZXIpCisJCQloaWdoX3dhdGVyID0gcGh5c19tYW5hZ2VkW2kgKyAxXTsKIAl9Cgot CWxvd193YXRlciA9IHBoeXNfYXZhaWxbMF07Ci0JaGlnaF93YXRlciA9IHBoeXNfYXZhaWxbMV07 CisjaWZkZWYgWEVOCisJbG93X3dhdGVyID0gMDsKKyNlbmRpZgoKIAlmb3IgKGkgPSAwOyBwaHlz X2F2YWlsW2kgKyAxXTsgaSArPSAyKSB7Ci0JCXZtX3BhZGRyX3Qgc2l6ZSA9IHBoeXNfYXZhaWxb aSArIDFdIC0gcGh5c19hdmFpbFtpXTsKKwkJdm1fcGFkZHJfdCBzaXplOwoKKwkJcGh5c19hdmFp bFtpXSA9IHJvdW5kX3BhZ2UocGh5c19hdmFpbFtpXSk7CisJCXBoeXNfYXZhaWxbaSArIDFdID0g dHJ1bmNfcGFnZShwaHlzX2F2YWlsW2kgKyAxXSk7CisJCXNpemUgPSBwaHlzX2F2YWlsW2kgKyAx XSAtIHBoeXNfYXZhaWxbaV07CiAJCWlmIChzaXplID4gYmlnZ2VzdHNpemUpIHsKIAkJCWJpZ2dl c3RvbmUgPSBpOwogCQkJYmlnZ2VzdHNpemUgPSBzaXplOwogCQl9Ci0JCWlmIChwaHlzX2F2YWls W2ldIDwgbG93X3dhdGVyKQotCQkJbG93X3dhdGVyID0gcGh5c19hdmFpbFtpXTsKLQkJaWYgKHBo eXNfYXZhaWxbaSArIDFdID4gaGlnaF93YXRlcikKLQkJCWhpZ2hfd2F0ZXIgPSBwaHlzX2F2YWls W2kgKyAxXTsKIAl9CgotI2lmZGVmIFhFTgotCWxvd193YXRlciA9IDA7Ci0jZW5kaWYKLQogCWVu ZCA9IHBoeXNfYXZhaWxbYmlnZ2VzdG9uZSsxXTsKCiAJLyoKQEAgLTM5Myw4ICs0MDIsOCBAQAog CWZpcnN0X3BhZ2UgPSBsb3dfd2F0ZXIgLyBQQUdFX1NJWkU7CiAjaWZkZWYgVk1fUEhZU1NFR19T UEFSU0UKIAlwYWdlX3JhbmdlID0gMDsKLQlmb3IgKGkgPSAwOyBwaHlzX2F2YWlsW2kgKyAxXSAh PSAwOyBpICs9IDIpCi0JCXBhZ2VfcmFuZ2UgKz0gYXRvcChwaHlzX2F2YWlsW2kgKyAxXSAtIHBo eXNfYXZhaWxbaV0pOworCWZvciAoaSA9IDA7IHBoeXNfbWFuYWdlZFtpICsgMV0gIT0gMDsgaSAr PSAyKQorCQlwYWdlX3JhbmdlICs9IGF0b3AocGh5c19tYW5hZ2VkW2kgKyAxXSAtIHBoeXNfbWFu YWdlZFtpXSk7CiAjZWxpZiBkZWZpbmVkKFZNX1BIWVNTRUdfREVOU0UpCiAJcGFnZV9yYW5nZSA9 IGhpZ2hfd2F0ZXIgLyBQQUdFX1NJWkUgLSBmaXJzdF9wYWdlOwogI2Vsc2UKQEAgLTQ0NSw3ICs0 NTQsNyBAQAogCS8qCiAJICogSW5pdGlhbGl6ZSB0aGUgcGh5c2ljYWwgbWVtb3J5IGFsbG9jYXRv ci4KIAkgKi8KLQl2bV9waHlzX2luaXQoKTsKKwl2bV9waHlzX2luaXQocGh5c19tYW5hZ2VkKTsK CiAJLyoKIAkgKiBBZGQgZXZlcnkgYXZhaWxhYmxlIHBoeXNpY2FsIHBhZ2UgdGhhdCBpcyBub3Qg YmxhY2tsaXN0ZWQgdG8KQEAgLTQ3Miw3ICs0ODEsNyBAQAogCS8qCiAJICogSW5pdGlhbGl6ZSB0 aGUgcmVzZXJ2YXRpb24gbWFuYWdlbWVudCBzeXN0ZW0uCiAJICovCi0Jdm1fcmVzZXJ2X2luaXQo KTsKKwl2bV9yZXNlcnZfaW5pdChwaHlzX21hbmFnZWQpOwogI2VuZGlmCiAJcmV0dXJuICh2YWRk cik7CiB9CkluZGV4OiBzeXMvdm0vdm1fcGh5cy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy92bS92bV9w aHlzLmMJKHJldmlzaW9uIDI3MzczNCkKKysrIHN5cy92bS92bV9waHlzLmMJKHdvcmtpbmcgY29w eSkKQEAgLTM2MCwyMiArMzYwLDIyIEBACiAgKiBJbml0aWFsaXplIHRoZSBwaHlzaWNhbCBtZW1v cnkgYWxsb2NhdG9yLgogICovCiB2b2lkCi12bV9waHlzX2luaXQodm9pZCkKK3ZtX3BoeXNfaW5p dCh2bV9wYWRkcl90ICpyZWdpb25zKQogewogCXN0cnVjdCB2bV9mcmVlbGlzdCAqZmw7CiAJaW50 IGRvbSwgZmxpbmQsIGksIG9pbmQsIHBpbmQ7CgotCWZvciAoaSA9IDA7IHBoeXNfYXZhaWxbaSAr IDFdICE9IDA7IGkgKz0gMikgeworCWZvciAoaSA9IDA7IHJlZ2lvbnNbaSArIDFdICE9IDA7IGkg Kz0gMikgewogI2lmZGVmCVZNX0ZSRUVMSVNUX0lTQURNQQotCQlpZiAocGh5c19hdmFpbFtpXSA8 IDE2Nzc3MjE2KSB7Ci0JCQlpZiAocGh5c19hdmFpbFtpICsgMV0gPiAxNjc3NzIxNikgewotCQkJ CXZtX3BoeXNfY3JlYXRlX3NlZyhwaHlzX2F2YWlsW2ldLCAxNjc3NzIxNiwKKwkJaWYgKHJlZ2lv bnNbaV0gPCAxNjc3NzIxNikgeworCQkJaWYgKHJlZ2lvbnNbaSArIDFdID4gMTY3NzcyMTYpIHsK KwkJCQl2bV9waHlzX2NyZWF0ZV9zZWcocmVnaW9uc1tpXSwgMTY3NzcyMTYsCiAJCQkJICAgIFZN X0ZSRUVMSVNUX0lTQURNQSk7Ci0JCQkJdm1fcGh5c19jcmVhdGVfc2VnKDE2Nzc3MjE2LCBwaHlz X2F2YWlsW2kgKyAxXSwKKwkJCQl2bV9waHlzX2NyZWF0ZV9zZWcoMTY3NzcyMTYsIHJlZ2lvbnNb aSArIDFdLAogCQkJCSAgICBWTV9GUkVFTElTVF9ERUZBVUxUKTsKIAkJCX0gZWxzZSB7Ci0JCQkJ dm1fcGh5c19jcmVhdGVfc2VnKHBoeXNfYXZhaWxbaV0sCi0JCQkJICAgIHBoeXNfYXZhaWxbaSAr IDFdLCBWTV9GUkVFTElTVF9JU0FETUEpOworCQkJCXZtX3BoeXNfY3JlYXRlX3NlZyhyZWdpb25z W2ldLCByZWdpb25zW2kgKyAxXSwKKwkJCQkgICAgVk1fRlJFRUxJU1RfSVNBRE1BKTsKIAkJCX0K IAkJCWlmIChWTV9GUkVFTElTVF9JU0FETUEgPj0gdm1fbmZyZWVsaXN0cykKIAkJCQl2bV9uZnJl ZWxpc3RzID0gVk1fRlJFRUxJU1RfSVNBRE1BICsgMTsKQEAgLTM4MiwyMSArMzgyLDIxIEBACiAJ CX0gZWxzZQogI2VuZGlmCiAjaWZkZWYJVk1fRlJFRUxJU1RfSElHSE1FTQotCQlpZiAocGh5c19h dmFpbFtpICsgMV0gPiBWTV9ISUdITUVNX0FERFJFU1MpIHsKLQkJCWlmIChwaHlzX2F2YWlsW2ld IDwgVk1fSElHSE1FTV9BRERSRVNTKSB7Ci0JCQkJdm1fcGh5c19jcmVhdGVfc2VnKHBoeXNfYXZh aWxbaV0sCisJCWlmIChyZWdpb25zW2kgKyAxXSA+IFZNX0hJR0hNRU1fQUREUkVTUykgeworCQkJ aWYgKHJlZ2lvbnNbaV0gPCBWTV9ISUdITUVNX0FERFJFU1MpIHsKKwkJCQl2bV9waHlzX2NyZWF0 ZV9zZWcocmVnaW9uc1tpXSwKIAkJCQkgICAgVk1fSElHSE1FTV9BRERSRVNTLCBWTV9GUkVFTElT VF9ERUZBVUxUKTsKIAkJCQl2bV9waHlzX2NyZWF0ZV9zZWcoVk1fSElHSE1FTV9BRERSRVNTLAot CQkJCSAgICBwaHlzX2F2YWlsW2kgKyAxXSwgVk1fRlJFRUxJU1RfSElHSE1FTSk7CisJCQkJICAg IHJlZ2lvbnNbaSArIDFdLCBWTV9GUkVFTElTVF9ISUdITUVNKTsKIAkJCX0gZWxzZSB7Ci0JCQkJ dm1fcGh5c19jcmVhdGVfc2VnKHBoeXNfYXZhaWxbaV0sCi0JCQkJICAgIHBoeXNfYXZhaWxbaSAr IDFdLCBWTV9GUkVFTElTVF9ISUdITUVNKTsKKwkJCQl2bV9waHlzX2NyZWF0ZV9zZWcocmVnaW9u c1tpXSwgcmVnaW9uc1tpICsgMV0sCisJCQkJICAgIFZNX0ZSRUVMSVNUX0hJR0hNRU0pOwogCQkJ fQogCQkJaWYgKFZNX0ZSRUVMSVNUX0hJR0hNRU0gPj0gdm1fbmZyZWVsaXN0cykKIAkJCQl2bV9u ZnJlZWxpc3RzID0gVk1fRlJFRUxJU1RfSElHSE1FTSArIDE7CiAJCX0gZWxzZQogI2VuZGlmCi0J CXZtX3BoeXNfY3JlYXRlX3NlZyhwaHlzX2F2YWlsW2ldLCBwaHlzX2F2YWlsW2kgKyAxXSwKKwkJ dm1fcGh5c19jcmVhdGVfc2VnKHJlZ2lvbnNbaV0sIHJlZ2lvbnNbaSArIDFdLAogCQkgICAgVk1f RlJFRUxJU1RfREVGQVVMVCk7CiAJfQogCWZvciAoZG9tID0gMDsgZG9tIDwgdm1fbmRvbWFpbnM7 IGRvbSsrKSB7CkluZGV4OiBzeXMvdm0vdm1fcGh5cy5oCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy92bS92 bV9waHlzLmgJKHJldmlzaW9uIDI3MzczNCkKKysrIHN5cy92bS92bV9waHlzLmgJKHdvcmtpbmcg Y29weSkKQEAgLTgwLDcgKzgwLDcgQEAKIHZtX3BhZ2VfdCB2bV9waHlzX2ZpY3RpdGlvdXNfdG9f dm1fcGFnZSh2bV9wYWRkcl90IHBhKTsKIHZvaWQgdm1fcGh5c19mcmVlX2NvbnRpZyh2bV9wYWdl X3QgbSwgdV9sb25nIG5wYWdlcyk7CiB2b2lkIHZtX3BoeXNfZnJlZV9wYWdlcyh2bV9wYWdlX3Qg bSwgaW50IG9yZGVyKTsKLXZvaWQgdm1fcGh5c19pbml0KHZvaWQpOwordm9pZCB2bV9waHlzX2lu aXQodm1fcGFkZHJfdCAqcmVnaW9ucyk7CiB2bV9wYWdlX3Qgdm1fcGh5c19wYWRkcl90b192bV9w YWdlKHZtX3BhZGRyX3QgcGEpOwogdm9pZCB2bV9waHlzX3NldF9wb29sKGludCBwb29sLCB2bV9w YWdlX3QgbSwgaW50IG9yZGVyKTsKIGJvb2xlYW5fdCB2bV9waHlzX3VuZnJlZV9wYWdlKHZtX3Bh Z2VfdCBtKTsKSW5kZXg6IHN5cy92bS92bV9yZXNlcnYuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvdm0v dm1fcmVzZXJ2LmMJKHJldmlzaW9uIDI3MzczNCkKKysrIHN5cy92bS92bV9yZXNlcnYuYwkod29y a2luZyBjb3B5KQpAQCAtODE1LDcgKzgxNSw3IEBACiAgKiBSZXF1aXJlcyB0aGF0IHZtX3BhZ2Vf YXJyYXkgYW5kIGZpcnN0X3BhZ2UgYXJlIGluaXRpYWxpemVkIQogICovCiB2b2lkCi12bV9yZXNl cnZfaW5pdCh2b2lkKQordm1fcmVzZXJ2X2luaXQodm1fcGFkZHJfdCAqcmVnaW9ucykKIHsKIAl2 bV9wYWRkcl90IHBhZGRyOwogCWludCBpOwpAQCAtODI0LDkgKzgyNCw5IEBACiAJICogSW5pdGlh bGl6ZSB0aGUgcmVzZXJ2YXRpb24gYXJyYXkuICBTcGVjaWZpY2FsbHksIGluaXRpYWxpemUgdGhl CiAJICogInBhZ2VzIiBmaWVsZCBmb3IgZXZlcnkgZWxlbWVudCB0aGF0IGhhcyBhbiB1bmRlcmx5 aW5nIHN1cGVycGFnZS4KIAkgKi8KLQlmb3IgKGkgPSAwOyBwaHlzX2F2YWlsW2kgKyAxXSAhPSAw OyBpICs9IDIpIHsKLQkJcGFkZHIgPSByb3VuZHVwMihwaHlzX2F2YWlsW2ldLCBWTV9MRVZFTF8w X1NJWkUpOwotCQl3aGlsZSAocGFkZHIgKyBWTV9MRVZFTF8wX1NJWkUgPD0gcGh5c19hdmFpbFtp ICsgMV0pIHsKKwlmb3IgKGkgPSAwOyByZWdpb25zW2kgKyAxXSAhPSAwOyBpICs9IDIpIHsKKwkJ cGFkZHIgPSByb3VuZHVwMihyZWdpb25zW2ldLCBWTV9MRVZFTF8wX1NJWkUpOworCQl3aGlsZSAo cGFkZHIgKyBWTV9MRVZFTF8wX1NJWkUgPD0gcmVnaW9uc1tpICsgMV0pIHsKIAkJCXZtX3Jlc2Vy dl9hcnJheVtwYWRkciA+PiBWTV9MRVZFTF8wX1NISUZUXS5wYWdlcyA9CiAJCQkgICAgUEhZU19U T19WTV9QQUdFKHBhZGRyKTsKIAkJCXBhZGRyICs9IFZNX0xFVkVMXzBfU0laRTsKSW5kZXg6IHN5 cy92bS92bV9yZXNlcnYuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvdm0vdm1fcmVzZXJ2LmgJKHJldmlz aW9uIDI3MzczNCkKKysrIHN5cy92bS92bV9yZXNlcnYuaAkod29ya2luZyBjb3B5KQpAQCAtNTIs NyArNTIsNyBAQAogCQkgICAgdm1fcGFnZV90IG1wcmVkKTsKIHZvaWQJCXZtX3Jlc2Vydl9icmVh a19hbGwodm1fb2JqZWN0X3Qgb2JqZWN0KTsKIGJvb2xlYW5fdAl2bV9yZXNlcnZfZnJlZV9wYWdl KHZtX3BhZ2VfdCBtKTsKLXZvaWQJCXZtX3Jlc2Vydl9pbml0KHZvaWQpOwordm9pZAkJdm1fcmVz ZXJ2X2luaXQodm1fcGFkZHJfdCAqcmVnaW9ucyk7CiBpbnQJCXZtX3Jlc2Vydl9sZXZlbF9pZmZ1 bGxwb3Aodm1fcGFnZV90IG0pOwogYm9vbGVhbl90CXZtX3Jlc2Vydl9yZWFjdGl2YXRlX3BhZ2Uo dm1fcGFnZV90IG0pOwogYm9vbGVhbl90CXZtX3Jlc2Vydl9yZWNsYWltX2NvbnRpZyh1X2xvbmcg bnBhZ2VzLCB2bV9wYWRkcl90IGxvdywK --001a11c2d8ba8f4c290506676df8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPV1H6XsOoDFitQFgJOP6u%2BgiEM=N--_7Q9uoWbYnAaeYQ>