Date: Thu, 4 Jul 2013 13:37:03 +0800 From: Jia-Shiun Li <jiashiun@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, avg@freebsd.org Subject: Re: cpufreq not working as module on i386/amd64 Message-ID: <CAHNYxxM%2B%2BgCFS=H%2Bvc6hWYPXkYBp%2Bw29cwL_zdHTVjU824_w_w@mail.gmail.com> In-Reply-To: <20130108150155.GF82219@kib.kiev.ua> References: <AANLkTi=Ln7f9tWt=OqZa9eZ-ZAVBfQSC-y_=8c-6zwAd@mail.gmail.com> <20110129084125.GA54969@freebsd.org> <CAHNYxxPZMUMDMBo0tRSSjJZWqDD7BNR7BdadcVfZk5nDHS2c1A@mail.gmail.com> <CAHNYxxOCDMzumJS9S9=tmrwdjunrp6wsH5TOgLO6EEU9OAkhaQ@mail.gmail.com> <20130108150155.GF82219@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--089e0160c35a9ddd6c04e0a8f975 Content-Type: text/plain; charset=UTF-8 ok anyone can help test and review this patch? It will allow cpufreq to be removed from kernel conf, loaded and function correctly as kernel module. I've tested it ok on my own i5-3450. It removes get_features method definition from acpi_if.m and corresponding implementations from est, p4tcc, & hwpstate. Feature flags are set directly in acpi_cpu.c omitting previous procedure of querying cpufreq drivers. After this, I'd like to find some ways to feed CPU loading info directly in kernel to cpufreq for finer & quicker control of frequencies. On Tue, Jan 8, 2013 at 11:01 PM, Konstantin Belousov <kostikbel@gmail.com> wrote: > On Tue, Jan 08, 2013 at 01:15:59PM +0800, Jia-Shiun Li wrote: >> Hi all, >> >> move to -hackers as it seems a better place to discuss. >> >> Turns out, at acpi_cpu_attach(), the bus probe will query >> ACPI_GET_FEATURES() to get cpu_features flags from each cpufreq >> drivers. Since it is only executed once at booting, subsequent module >> loading after booting will not be called get_features() and will not >> be able to express interests in terms of ACPI_CAP_* flags. And if >> these flags were not set first, acpi_perf won't get attached. Later >> when loading cpufreq.ko, est_attach(), etc. will not be able to find >> acpi_perf and thus failed to attach. >> >> After referred to Intel doc. #302223 mentioned in >> dev/acpica/acpivar.h, I got confused by the meaning of these bits. >> According to the document, capability bits probably should be set as >> long as OSPM is *capable* of using them, no matter when they will be >> used. I am not familiar with ACPI, but I suppose it will expose >> states/methods to OSPM according to these bits? >> >> To confirm this, I add a line to simply OR'd (ACPI_CAP_PERF_MSRS | >> ACPI_CAP_C1_IO_HALT) to sc->cpu_features after the loop calling >> ACPI_GET_FEATURES(). And then I am able to load cpufreq.ko after boot. >> powerd also works fine with it. >> >> If this is true, then probably we don't need get_features() for acpi >> interface/drivers. It is sufficient to just turn on proper bits >> directly for acpi_cpu when related code is added to repository. >> >> Any comments? >> >> ----->8----->8----->8----- >> # svn diff >> Index: sys/dev/acpica/acpi_cpu.c >> =================================================================== >> --- sys/dev/acpica/acpi_cpu.c (revision 245148) >> +++ sys/dev/acpica/acpi_cpu.c (working copy) >> @@ -350,6 +350,7 @@ >> sc->cpu_features |= features; >> } >> free(drivers, M_TEMP); >> + sc->cpu_features |= ACPI_CAP_PERF_MSRS | ACPI_CAP_C1_IO_HALT; >> } > I had almost word-to-word identical conversation with Andrey Gapon, > might be a year ago. I Cc:ed him. > >> >> /* >> >> ----->8----->8----->8----- >> >> >> Jia-Shiun >> >> On Wed, Dec 26, 2012 at 2:10 AM, Jia-Shiun Li <jiashiun@gmail.com> wrote: >> > I was cleaning up hard drive and found these old logs. Anyway I added >> > some printf() >> > and saw the process failed at device_find_child(..., "acpi_perf", ...) >> > of est_acpi_info() i.e. it cannot find acpi_perf device. >> > >> > devinfo did confirmed the absence of acpi_perf. Comparing the dmesgs >> > revealed the main difference: IST (i-state?) OEM tables in SSDT seems >> > not loaded if cpufreq was not compiled into kernel, as it shows below. >> > >> > Before I diving into the ACPI part, can anyone familiar with how ACPI >> > works shed me some light? >> > >> > ----->8----->8----->8----- >> > % diff -bu cpufreq-nb.log cpufreq-no.log >> > ... >> > @@ -158,17 +158,11 @@ >> > acpi0: Power Button (fixed) >> > cpu0: Processor \\_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 >> > cpu0: <ACPI CPU> on acpi0 >> > -ACPI: SSDT 0xbfd8dc98 00223 (v01 PmRef Cpu0Ist 00003000 INTL 20051117) >> > -ACPI: Dynamic OEM Table Load: >> > -ACPI: SSDT 0 00223 (v01 PmRef Cpu0Ist 00003000 INTL 20051117) >> > ACPI: SSDT 0xbfd8b598 00537 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) >> > ACPI: Dynamic OEM Table Load: >> > ACPI: SSDT 0 00537 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) >> > cpu1: Processor \\_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 >> > cpu1: <ACPI CPU> on acpi0 >> > -ACPI: SSDT 0xbfd8ce18 001CF (v01 PmRef ApIst 00003000 INTL 20051117) >> > -ACPI: Dynamic OEM Table Load: >> > -ACPI: SSDT 0 001CF (v01 PmRef ApIst 00003000 INTL 20051117) >> > ACPI: SSDT 0xbfd8df18 0008D (v01 PmRef ApCst 00003000 INTL 20051117) >> > ACPI: Dynamic OEM Table Load: >> > ACPI: SSDT 0 0008D (v01 PmRef ApCst 00003000 INTL 20051117 >> > >> > On Sat, Jan 29, 2011 at 4:41 PM, Alexander Best <arundel@freebsd.org> wrote: >> >> On Sat Jan 29 11, Jia-Shiun Li wrote: >> >>> Hi all, >> >>> >> >>> I found that cpufreq driver failed to attach when compiled as module >> >>> and loaded, but it works fine when compiled into kernel. I am >> >>> wondering if this is due to some kind of limitation, or can be fixed? >> >> >> >> that's rather odd. for me neither the module nor the kernel code works, since >> >> my cpu isn't supported by sys/x86/cpufreq/est.c. actually only pentium mobile >> >> cpus seem to be supported. >> >> >> >> maybe you can add some printf's to est.c:est_get_info() to identify at which >> >> point error gets set. also you might want to make >> >> >> >> "est: cpu_vendor %s, msr %0jx\n", cpu_vendor, msr); >> >> >> >> non-conditional. maybe the output differy in kernel/module mode. >> >> >> >> cheers. >> >> alex >> >> >> >>> >> >>> Tested on a Pentium E5200 desktop (i386) and a Pentium T4200 laptop >> >>> (amd64). Both got the same result. dmesg of T4200 attached. >> >>> >> >>> kldload module: >> >>> ----->8----->8----->8----- >> >>> est0: <Enhanced SpeedStep Frequency Control> on cpu0 >> >>> est: CPU supports Enhanced Speedstep, but is not recognized. >> >>> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a >> >>> device_attach: est0 attach returned 6 >> >>> est1: <Enhanced SpeedStep Frequency Control> on cpu1 >> >>> est: CPU supports Enhanced Speedstep, but is not recognized. >> >>> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a >> >>> -----8<-----8<-----8<----- >> >>> (repeated 6 times, kldload retries?) >> >>> >> >>> compiled into kernel: >> >>> ----->8----->8----->8----- >> >>> ... >> >>> fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 >> >>> uart1: <ns8250> failed to probe at port 0x2f8-0x2ff irq 3 on isa0 >> >>> isa_probe_children: probing PnP devices >> >>> coretemp0: <CPU On-Die Thermal Sensors> on cpu0 >> >>> coretemp0: Setting TjMax=104 >> >>> p4tcc0: <CPU Frequency Thermal Control> on cpu0 >> >>> est0: <Enhanced SpeedStep Frequency Control> on cpu0 >> >>> coretemp1: <CPU On-Die Thermal Sensors> on cpu1 >> >>> coretemp1: Setting TjMax=104 >> >>> p4tcc1: <CPU Frequency Thermal Control> on cpu1 >> >>> est1: <Enhanced SpeedStep Frequency Control> on cpu1 >> >>> Device configuration finished. >> >>> procfs registered >> >>> ... >> >>> -----8<-----8<-----8<----- >> >>> >> >>> Jia-Shiun. >> >> >> >> >> >> -- >> >> a13x >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --089e0160c35a9ddd6c04e0a8f975 Content-Type: application/octet-stream; name="cpufreq-module.patch" Content-Disposition: attachment; filename="cpufreq-module.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hipirp8a1 SW5kZXg6IHN5cy9kZXYvYWNwaWNhL2FjcGlfY3B1LmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9h Y3BpY2EvYWNwaV9jcHUuYwkocmV2aXNpb24gMjUyNTM3KQorKysgc3lzL2Rldi9hY3BpY2EvYWNw aV9jcHUuYwkod29ya2luZyBjb3B5KQpAQCAtMjc5LDkgKzI3OSw3IEBACiAgICAgc3RydWN0IGFj cGlfY3B1X3NvZnRjICpzYzsKICAgICBzdHJ1Y3QgYWNwaV9zb2Z0YwkgICphY3BpX3NjOwogICAg IEFDUElfU1RBVFVTCQkgICBzdGF0dXM7Ci0gICAgdV9pbnQJCSAgIGZlYXR1cmVzOwotICAgIGlu dAkJCSAgIGNwdV9pZCwgZHJ2X2NvdW50LCBpOwotICAgIGRyaXZlcl90IAkJICAqKmRyaXZlcnM7 CisgICAgaW50CQkJICAgY3B1X2lkOwogICAgIHVpbnQzMl90CQkgICBjYXBfc2V0WzNdOwogCiAg ICAgLyogVVVJRCBuZWVkZWQgYnkgX09TQyBldmFsdWF0aW9uICovCkBAIC0zNDQsMTMgKzM0Miwx MiBAQAogICAgICAqIFNNUCBjb250cm9sIHdoZXJlIGVhY2ggQ1BVIGNhbiBoYXZlIGRpZmZlcmVu dCBzZXR0aW5ncy4KICAgICAgKi8KICAgICBzYy0+Y3B1X2ZlYXR1cmVzID0gQUNQSV9DQVBfU01Q X1NBTUUgfCBBQ1BJX0NBUF9TTVBfU0FNRV9DMzsKLSAgICBpZiAoZGV2Y2xhc3NfZ2V0X2RyaXZl cnMoYWNwaV9jcHVfZGV2Y2xhc3MsICZkcml2ZXJzLCAmZHJ2X2NvdW50KSA9PSAwKSB7Ci0JZm9y IChpID0gMDsgaSA8IGRydl9jb3VudDsgaSsrKSB7Ci0JICAgIGlmIChBQ1BJX0dFVF9GRUFUVVJF Uyhkcml2ZXJzW2ldLCAmZmVhdHVyZXMpID09IDApCi0JCXNjLT5jcHVfZmVhdHVyZXMgfD0gZmVh dHVyZXM7Ci0JfQotCWZyZWUoZHJpdmVycywgTV9URU1QKTsKLSAgICB9CisgICAgLyogZXN0ICov CisgICAgc2MtPmNwdV9mZWF0dXJlcyB8PSBBQ1BJX0NBUF9QRVJGX01TUlMgfCBBQ1BJX0NBUF9D MV9JT19IQUxUOworICAgIC8qIHA0dGNjICovCisgICAgc2MtPmNwdV9mZWF0dXJlcyB8PSBBQ1BJ X0NBUF9USFJfTVNSUzsKKyAgICAvKiBod3BzdGF0ZSAqLworICAgIHNjLT5jcHVfZmVhdHVyZXMg fD0gQUNQSV9DQVBfUEVSRl9NU1JTOwogCiAgICAgLyoKICAgICAgKiBDUFUgY2FwYWJpbGl0aWVz IGFyZSBzcGVjaWZpZWQgaW4KSW5kZXg6IHN5cy9kZXYvYWNwaWNhL2FjcGlfaWYubQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSBzeXMvZGV2L2FjcGljYS9hY3BpX2lmLm0JKHJldmlzaW9uIDI1MjUzNykKKysrIHN5 cy9kZXYvYWNwaWNhL2FjcGlfaWYubQkod29ya2luZyBjb3B5KQpAQCAtMTU5LDE5ICsxNTksNiBA QAogfTsKIAogIwotIyBRdWVyeSBhIGdpdmVuIGRyaXZlciBmb3IgaXRzIHN1cHBvcnRlZCBmZWF0 dXJlKHMpLiAgVGhpcyBzaG91bGQgYmUKLSMgY2FsbGVkIGJ5IHRoZSBwYXJlbnQgYnVzIGJlZm9y ZSB0aGUgZHJpdmVyIGlzIHByb2JlZC4KLSMKLSMgZHJpdmVyX3QgKmRyaXZlcjogIGNoaWxkIGRy aXZlcgotIwotIyB1X2ludCAqZmVhdHVyZXM6ICByZXR1cm5lZCBiaXRtYXNrIG9mIGFsbCBzdXBw b3J0ZWQgZmVhdHVyZXMKLSMKLVNUQVRJQ01FVEhPRCBpbnQgZ2V0X2ZlYXR1cmVzIHsKLQlkcml2 ZXJfdAkqZHJpdmVyOwotCXVfaW50CQkqZmVhdHVyZXM7Ci19OwotCi0jCiAjIFJlYWQgZW1iZWRk ZWQgY29udHJvbGxlciAoRUMpIGFkZHJlc3Mgc3BhY2UKICMKICMgZGV2aWNlX3QgZGV2OiAgRUMg ZGV2aWNlCkluZGV4OiBzeXMveDg2L2NwdWZyZXEvZXN0LmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL3g4 Ni9jcHVmcmVxL2VzdC5jCShyZXZpc2lvbiAyNTI1MzcpCisrKyBzeXMveDg2L2NwdWZyZXEvZXN0 LmMJKHdvcmtpbmcgY29weSkKQEAgLTg5OSw3ICs4OTksNiBAQAogfTsKIAogc3RhdGljIHZvaWQJ ZXN0X2lkZW50aWZ5KGRyaXZlcl90ICpkcml2ZXIsIGRldmljZV90IHBhcmVudCk7Ci1zdGF0aWMg aW50CWVzdF9mZWF0dXJlcyhkcml2ZXJfdCAqZHJpdmVyLCB1X2ludCAqZmVhdHVyZXMpOwogc3Rh dGljIGludAllc3RfcHJvYmUoZGV2aWNlX3QgcGFyZW50KTsKIHN0YXRpYyBpbnQJZXN0X2F0dGFj aChkZXZpY2VfdCBwYXJlbnQpOwogc3RhdGljIGludAllc3RfZGV0YWNoKGRldmljZV90IHBhcmVu dCk7CkBAIC05MjgsOSArOTI3LDYgQEAKIAlERVZNRVRIT0QoY3B1ZnJlcV9kcnZfdHlwZSwJZXN0 X3R5cGUpLAogCURFVk1FVEhPRChjcHVmcmVxX2Rydl9zZXR0aW5ncywJZXN0X3NldHRpbmdzKSwK IAotCS8qIEFDUEkgaW50ZXJmYWNlICovCi0JREVWTUVUSE9EKGFjcGlfZ2V0X2ZlYXR1cmVzLAll c3RfZmVhdHVyZXMpLAotCiAJezAsIDB9CiB9OwogCkBAIC05NDMsMTggKzkzOSw2IEBACiBzdGF0 aWMgZGV2Y2xhc3NfdCBlc3RfZGV2Y2xhc3M7CiBEUklWRVJfTU9EVUxFKGVzdCwgY3B1LCBlc3Rf ZHJpdmVyLCBlc3RfZGV2Y2xhc3MsIDAsIDApOwogCi1zdGF0aWMgaW50Ci1lc3RfZmVhdHVyZXMo ZHJpdmVyX3QgKmRyaXZlciwgdV9pbnQgKmZlYXR1cmVzKQotewotCi0JLyoKLQkgKiBOb3RpZnkg dGhlIEFDUEkgQ1BVIHRoYXQgd2Ugc3VwcG9ydCBkaXJlY3QgYWNjZXNzIHRvIE1TUnMuCi0JICog WFhYIEMxICJJL08gdGhlbiBIYWx0IiBzZWVtcyBuZWNlc3NhcnkgZm9yIHNvbWUgYnJva2VuIEJJ T1MuCi0JICovCi0JKmZlYXR1cmVzID0gQUNQSV9DQVBfUEVSRl9NU1JTIHwgQUNQSV9DQVBfQzFf SU9fSEFMVDsKLQlyZXR1cm4gKDApOwotfQotCiBzdGF0aWMgdm9pZAogZXN0X2lkZW50aWZ5KGRy aXZlcl90ICpkcml2ZXIsIGRldmljZV90IHBhcmVudCkKIHsKSW5kZXg6IHN5cy94ODYvY3B1ZnJl cS9od3BzdGF0ZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy94ODYvY3B1ZnJlcS9od3BzdGF0ZS5jCShy ZXZpc2lvbiAyNTI1MzcpCisrKyBzeXMveDg2L2NwdWZyZXEvaHdwc3RhdGUuYwkod29ya2luZyBj b3B5KQpAQCAtMTEyLDcgKzExMiw2IEBACiBzdGF0aWMgaW50CWh3cHN0YXRlX3NldHRpbmdzKGRl dmljZV90IGRldiwgc3RydWN0IGNmX3NldHRpbmcgKnNldHMsIGludCAqY291bnQpOwogc3RhdGlj IGludAlod3BzdGF0ZV90eXBlKGRldmljZV90IGRldiwgaW50ICp0eXBlKTsKIHN0YXRpYyBpbnQJ aHdwc3RhdGVfc2h1dGRvd24oZGV2aWNlX3QgZGV2KTsKLXN0YXRpYyBpbnQJaHdwc3RhdGVfZmVh dHVyZXMoZHJpdmVyX3QgKmRyaXZlciwgdV9pbnQgKmZlYXR1cmVzKTsKIHN0YXRpYyBpbnQJaHdw c3RhdGVfZ2V0X2luZm9fZnJvbV9hY3BpX3BlcmYoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBwZXJm X2Rldik7CiBzdGF0aWMgaW50CWh3cHN0YXRlX2dldF9pbmZvX2Zyb21fbXNyKGRldmljZV90IGRl dik7CiBzdGF0aWMgaW50CWh3cHN0YXRlX2dvdG9fcHN0YXRlKGRldmljZV90IGRldiwgaW50IHBz dGF0ZV9pZCk7CkBAIC0xMzYsOSArMTM1LDYgQEAKIAlERVZNRVRIT0QoY3B1ZnJlcV9kcnZfc2V0 dGluZ3MsCWh3cHN0YXRlX3NldHRpbmdzKSwKIAlERVZNRVRIT0QoY3B1ZnJlcV9kcnZfdHlwZSwJ aHdwc3RhdGVfdHlwZSksCiAKLQkvKiBBQ1BJIGludGVyZmFjZSAqLwotCURFVk1FVEhPRChhY3Bp X2dldF9mZWF0dXJlcywJaHdwc3RhdGVfZmVhdHVyZXMpLAotCiAJezAsIDB9CiB9OwogCkBAIC00 OTMsMTIgKzQ4OSwzIEBACiAJLyogaHdwc3RhdGVfZ290b19wc3RhdGUoZGV2LCAwKTsgKi8KIAly ZXR1cm4gKDApOwogfQotCi1zdGF0aWMgaW50Ci1od3BzdGF0ZV9mZWF0dXJlcyhkcml2ZXJfdCAq ZHJpdmVyLCB1X2ludCAqZmVhdHVyZXMpCi17Ci0KLQkvKiBOb3RpZnkgdGhlIEFDUEkgQ1BVIHRo YXQgd2Ugc3VwcG9ydCBkaXJlY3QgYWNjZXNzIHRvIE1TUnMgKi8KLQkqZmVhdHVyZXMgPSBBQ1BJ X0NBUF9QRVJGX01TUlM7Ci0JcmV0dXJuICgwKTsKLX0KSW5kZXg6IHN5cy94ODYvY3B1ZnJlcS9w NHRjYy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy94ODYvY3B1ZnJlcS9wNHRjYy5jCShyZXZpc2lvbiAy NTI1MzcpCisrKyBzeXMveDg2L2NwdWZyZXEvcDR0Y2MuYwkod29ya2luZyBjb3B5KQpAQCAtNjks NyArNjksNiBAQAogI2RlZmluZSBUQ0NfUkVHX09GRlNFVAkJMQogI2RlZmluZSBUQ0NfU1BFRURf UEVSQ0VOVCh4KQkoKDEwMDAwICogKHgpKSAvIFRDQ19OVU1fU0VUVElOR1MpCiAKLXN0YXRpYyBp bnQJcDR0Y2NfZmVhdHVyZXMoZHJpdmVyX3QgKmRyaXZlciwgdV9pbnQgKmZlYXR1cmVzKTsKIHN0 YXRpYyB2b2lkCXA0dGNjX2lkZW50aWZ5KGRyaXZlcl90ICpkcml2ZXIsIGRldmljZV90IHBhcmVu dCk7CiBzdGF0aWMgaW50CXA0dGNjX3Byb2JlKGRldmljZV90IGRldik7CiBzdGF0aWMgaW50CXA0 dGNjX2F0dGFjaChkZXZpY2VfdCBkZXYpOwpAQCAtOTMsOSArOTIsNiBAQAogCURFVk1FVEhPRChj cHVmcmVxX2Rydl90eXBlLAlwNHRjY190eXBlKSwKIAlERVZNRVRIT0QoY3B1ZnJlcV9kcnZfc2V0 dGluZ3MsCXA0dGNjX3NldHRpbmdzKSwKIAotCS8qIEFDUEkgaW50ZXJmYWNlICovCi0JREVWTUVU SE9EKGFjcGlfZ2V0X2ZlYXR1cmVzLAlwNHRjY19mZWF0dXJlcyksCi0KIAl7MCwgMH0KIH07CiAK QEAgLTEwOCwxNSArMTA0LDYgQEAKIHN0YXRpYyBkZXZjbGFzc190IHA0dGNjX2RldmNsYXNzOwog RFJJVkVSX01PRFVMRShwNHRjYywgY3B1LCBwNHRjY19kcml2ZXIsIHA0dGNjX2RldmNsYXNzLCAw LCAwKTsKIAotc3RhdGljIGludAotcDR0Y2NfZmVhdHVyZXMoZHJpdmVyX3QgKmRyaXZlciwgdV9p bnQgKmZlYXR1cmVzKQotewotCi0JLyogTm90aWZ5IHRoZSBBQ1BJIENQVSB0aGF0IHdlIHN1cHBv cnQgZGlyZWN0IGFjY2VzcyB0byBNU1JzICovCi0JKmZlYXR1cmVzID0gQUNQSV9DQVBfVEhSX01T UlM7Ci0JcmV0dXJuICgwKTsKLX0KLQogc3RhdGljIHZvaWQKIHA0dGNjX2lkZW50aWZ5KGRyaXZl cl90ICpkcml2ZXIsIGRldmljZV90IHBhcmVudCkKIHsK --089e0160c35a9ddd6c04e0a8f975--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHNYxxM%2B%2BgCFS=H%2Bvc6hWYPXkYBp%2Bw29cwL_zdHTVjU824_w_w>