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"
