hwpmc support for Ivy Bridge Xeon
I've tried to update hwpmc by adding support for xeon class of Ivy bridge processors. Thanks Jim for pointing me to the correct document. (325462-045US Jan 2013) I do not have a reference machine to test with. Any help in that regard would be appreciated. Here are the diffs against head (245927): http://www.strugglingcoder.info/patches/hwpmc_ibx.txt Thanks, Hiren ___ 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"
some questions on kern_linker and pre-loaded modules
I. It seems that linker_preload checks a module for being a duplicate module only if the module has MDT_VERSION. This is probably designed to allow different version of the same module to co-exist (for some definition of co-exist)? But, OTOH, this doesn't work well if the module is version-less (no MODULE_VERSION in the code) and is pre-loaded twice (e.g. once in kernel and once in a preloaded file). At present a good example of this is zfsctrl module, which could be present both in kernel (options ZFS) and in zfs.ko. I haven't thought about any linker-level resolution for this issue. I've just tried a plug the ZFS hole for now. commit ed8b18f2d6c4d1be915bff94cdec0c51a479529f Author: Andriy Gapon Date: Wed Dec 19 23:29:23 2012 +0200 [bugfix] zfs: add MODULE_VERSION for zfsctrl This should allow the kernel linker to easily detect a situation when the module is present both in a kernel and in a preloaded file (zfs.ko). diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c index 10d28c2..5721010 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c @@ -5599,6 +5599,7 @@ static moduledata_t zfs_mod = { 0 }; DECLARE_MODULE(zfsctrl, zfs_mod, SI_SUB_VFS, SI_ORDER_ANY); +MODULE_VERSION(zfsctrl, 1); MODULE_DEPEND(zfsctrl, opensolaris, 1, 1, 1); MODULE_DEPEND(zfsctrl, krpc, 1, 1, 1); MODULE_DEPEND(zfsctrl, acl_nfs4, 1, 1, 1); II. It seems that linker_file_register_modules() for the kernel is called after linker_file_register_modules() is called for all the pre-loaded files. linker_file_register_modules() for the kernel is called from linker_init_kernel_modules via SYSINIT(SI_SUB_KLD, SI_ORDER_ANY) and that happens after linker_preload() which is executed via SYSINIT(SI_SUB_KLD, SI_ORDER_MIDDLE). Perhaps this is designed to allow modules in the preloaded files to override modules compiled into the kernel? But this doesn't seem to work well. Because modules from the kernel are not registered yet, linker_file_register_modules() would be successful for the duplicate modules in a preloaded file and thus any sysinits present in the file will also be registered. So, if the module is present both in the kernel and in the preloaded file and the module has a module event handler (modeventhand_t), then the handler will registered and called twice. I cobbled together the following hack, but I am not sure if it is OK or if it violates fundamental architecture/design of this subsystem. commit 14ebf07633d0f0ea393801c3e4161d6c37393661 Author: Andriy Gapon Date: Wed Dec 19 23:27:46 2012 +0200 [wip][experiment] kernel linker: register kernel modules before preloaded modules... Also, skip adding sysinit and sysctl stuff from preloaded modules if module registration fails. This should result in much saner behavior if a module is present in both the kernel and a preloaded file. Perhaps, the original intent was to allow the preloaded files to override modules present in kernel, but that was extremly fragile because of double sysinit registration. diff --git a/sys/kern/kern_linker.c b/sys/kern/kern_linker.c index b3ab4df..be46cdf 100644 --- a/sys/kern/kern_linker.c +++ b/sys/kern/kern_linker.c @@ -365,6 +365,7 @@ linker_file_register_modules(linker_file_t lf) return (first_error); } +#if 0 static void linker_init_kernel_modules(void) { @@ -374,6 +375,7 @@ linker_init_kernel_modules(void) SYSINIT(linker_kernel, SI_SUB_KLD, SI_ORDER_ANY, linker_init_kernel_modules, 0); +#endif static int linker_load_file(const char *filename, linker_file_t *result) @@ -1599,7 +1601,11 @@ restart: printf("KLD file %s is missing dependencies\n", lf->filename); linker_file_unload(lf, LINKER_UNLOAD_FORCE); } - +#if 1 + error = linker_file_register_modules(linker_kernel_file); + if (error) + printf("linker_file_register_modules(linker_kernel_file) failed: %d\n", error); +#endif /* * We made it. Finish off the linking in the order we determined. */ @@ -1642,13 +1648,15 @@ restart: * Now do relocation etc using the symbol search paths * established by the dependencies */ + error = linker_file_register_modules(lf); + if (error) + goto fail; error = LINKER_LINK_PRELOAD_FINISH(lf); if (error) { printf("KLD file %s - could not finalize loading\n", lf->filename); goto fail; } - linker_file_register_modules(lf); if (linker_file_lookup_set(lf, "sysinit_set", &si_start, &si_stop, NULL) == 0) sysinit_add(si_start, si_stop);
Re: hwpmc support for Ivy Bridge Xeon
On Sat, Jan 26, 2013 at 1:58 AM, hiren panchasara wrote: > I've tried to update hwpmc by adding support for xeon class of Ivy > bridge processors. > > Thanks Jim for pointing me to the correct document. (325462-045US Jan 2013) > > I do not have a reference machine to test with. Any help in that > regard would be appreciated. > > Here are the diffs against head (245927): > http://www.strugglingcoder.info/patches/hwpmc_ibx.txt > > Thanks, > Hiren > ___ > 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" >From a first look appears good -- I've a couple of observations though. I see your patch covers only core events -- am I missing something? Not really important, and I don't want to be pedantic here, but maybe this can be renamed to something less ugly: static int -iap_event_sb_sbx_ib_ok_on_counter(enum pmc_event pe, int ri) +iap_event_sb_sbx_ib_ibx_ok_on_counter(enum pmc_event pe, int ri) -- Davide ___ 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: acpi resume related patch
on 25/01/2013 18:08 Andriy Gapon said the following: > on 25/01/2013 15:51 John Baldwin said the following: >> On Friday, January 25, 2013 3:43:33 am Andriy Gapon wrote: >>> >>> If you have ACPI suspend/resume working, if it used to work but stopped >>> working >>> at some time, if it never worked, but you are still hoping, could you please >>> test the following patch and report back? >>> >>> http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch >> >> This will break systems not using the local APIC since you unconditionally >> call lapic_setup() on resume.This was part of the feature of the previous >> code that by using a dummy pic it could register it only when the local APIC >> was used. > > Thank you for drawing my attention to this. I will try to fix this issue. > The reason I want to remove lapic from 'pics' (and I already described it in a > private email) is that Local APIC is a special kind of PIC. It's already > explicitly initialized by APs. Putting it into 'pics' tailq just obfuscates > the code. > >> It should also be registered before any of the I/O APICs are by >> the design of the local_apic.c code. > > In fact, as I see in the code, Local APIC is always registered _after_ I/O > APICs. > And thus lapic_resume was called after ioapic_resume. > Additionally, currently there is no synchronization between initialization of > Local APICs on APs and initialization of I/O APICs at the wakeup/resume time. > Here is an updated version of the patch: http://people.freebsd.org/~avg/acpi-apic-wakeup.2.patch John, could you please review the PIC-related part? I decided to go back to the current approach while fixing the suspend/resume ordering and also order of registration for Local APIC. Must say that XEN special casing makes apic_setup_io a little bit untidy. Additionally this patch fixes AP Local APIC initialization ordering on i386. In the original patch I changed only amd64 code. -- Andriy Gapon ___ 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: ACPI panic on unplugging the power cord.
On Fri, Jan 25, 2013 at 04:19:44PM -0500, Jung-uk Kim wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2013-01-25 04:26:02 -0500, Pawel Jakub Dawidek wrote: > > On Thu, Jan 24, 2013 at 05:18:48PM +0100, Pawel Jakub Dawidek > > wrote: > >> One is when I leave laptop idle for some time (few hours?): > >> > >> http://people.freebsd.org/~pjd/misc/acpi_idle_panic_0.jpg > >> http://people.freebsd.org/~pjd/misc/acpi_idle_panic_1.jpg > > > > Small update. This panic doesn't happen when the system is idle, > > it happens we I close the lid to the point when display is turned > > off (which is almost closed, but not entirely closed). > > > > Closing lid doesn't trigger suspend or anything like that. It just > > turns off the display. > > Please try the attached patch (with my previous patch). Also, > available from here: > > http://people.freebsd.org/~jkim/acpi_exit.diff Your patch fixes panic triggered by unplugging power cable as well the one triggered by closing the lid. I haven't tried booting from battery and connecting power cable, but I expect happy end there as well. Thank you very much for the fix. BTW. When I'm closing the lid and opening it again (not cosing it entirely, just to the point when display is turned off) I see this message to be printed twice on the console: CPU0: local APIC error 0x80 Although I must admit I see this message from time to time, but I haven't found a pattern. Closing and opening the lid always make it appear. Not sure how much it is related to ACPI, though. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpgOFfnWqmSv.pgp Description: PGP signature
Re: hwpmc support for Ivy Bridge Xeon
Keeping sbruno in the chain. On Sat, Jan 26, 2013 at 5:41 AM, Davide Italiano wrote: > On Sat, Jan 26, 2013 at 1:58 AM, hiren panchasara > wrote: >> I've tried to update hwpmc by adding support for xeon class of Ivy >> bridge processors. >> >> Thanks Jim for pointing me to the correct document. (325462-045US Jan 2013) >> >> I do not have a reference machine to test with. Any help in that >> regard would be appreciated. >> >> Here are the diffs against head (245927): >> http://www.strugglingcoder.info/patches/hwpmc_ibx.txt >> >> Thanks, >> Hiren >> ___ >> 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" > > From a first look appears good -- I've a couple of observations though. > I see your patch covers only core events -- am I missing something? My bad, should've mentioned that diffs only has core events. I could not find uncore events clearly mentioned in the spec. > > Not really important, and I don't want to be pedantic here, but maybe > this can be renamed to something less ugly: > > static int > -iap_event_sb_sbx_ib_ok_on_counter(enum pmc_event pe, int ri) > +iap_event_sb_sbx_ib_ibx_ok_on_counter(enum pmc_event pe, int ri) Now when I look at this yes, we should change it. :-) Not sure about the new name. Thanks for looking into it, Hiren ___ 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"
looking for some help from ppp users
Can people that use PPP please review the following FAQs What do we care about? Is it factually correct? Does it use deprecated functionality? Is it completely outdated to the point we should remove it? Does it need better examples? Is it clear and concise? Does it have typos or spelling mistakes? Want to help with the patches? Install devel/subversion Install textproc/docproj-nojadetex svn checkout https://svn0.us-west.FreeBSD.org/doc/head edit en_US.ISO8859-1/books/faq/book.xml Test with running "make FORMATS=html" Send diffs ("svn diff") to d...@freebsd.org It isn't hard - its just like HTML. = http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#ppp-nodial-auto http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#ppp-drop-random http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#ppp-hangs-random http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#ppp-same-magic http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#ppp-lcp-constant http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#ppp-auto-noreasondial http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#ccp-errors http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#ppp-connectionspeed http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#ppp-ignores-backslash http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#ppp-autodialprocess-noconnect http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#fcs-errors -- Eitan Adler ___ 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"