Re: problem about the smispv.c
Paolo Mantegazza <[email protected]> Fri, 20 Oct 2017 11:01:32 +0200
| Newsgroups | gmane.linux.real-time.rtai |
|---|---|
| Message-ID | <[email protected]> |
Thanks again, we'll fix it too.
Meanwhile can you have a check with what attached and see if it causes
troubles under virtualbox?
Simply overwrite smi-module.c in base/arch/x86/calibrate with it and
"make install" whithin the diredtory.
Then exec ./setsmi and ./rstsmi within the RTAI instaldir, checking the
outcome with dmsg.
Paolo.
On 10/20/2017 09:29 AM, Tom wrote:
> hi list,
>
> I got the contribution version tarball of rtai-5.0.1, and in smispv.c
> , line : 347
>
> when run in virtualbox, it crashed. because there is no smi-enabled
> device. that is, find_smi_device returns 0.
>
> so I think there should be a null pointer guard.
>
> dev = find_smi_device(pacc);
> if (!dev)
> {
> return;
> }
> smi_en_addr[0] = get_smi_en_addr(dev, 0);
> smi_en_addr[1] = get_smi_en_addr(dev, 1);
>
> tom@shanghai
>
> At 2017-10-19 23:36:17, [email protected] wrote:
> >Send Rtai mailing list submissions to
> > [email protected]
> >
> >To subscribe or unsubscribe via the World Wide Web, visit
> > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
> >or, via email, send a message with subject or body 'help' to
> > [email protected]
> >
> >You can reach the person managing the list at
> > [email protected]
> >
> >When replying, please edit your Subject line so it is more specific
> >than "Re: Contents of Rtai digest..."
> >
> >
> >Today's Topics:
> >
> > 1. Re: RTAI 5.0.1 calibrate program: BUG: unable to handle
> > kernel paging request at 00007ffe78e450f0 (Paolo Mantegazza)
> > (Paolo Mantegazza)
> >
> >
> >----------------------------------------------------------------------
> >
> >Message: 1
> >Date: Thu, 19 Oct 2017 11:02:39 +0200
> >From: Paolo Mantegazza <[email protected]>
> >To: Samuel R <[email protected]>
> >Cc: Vivian McPhail <[email protected]>, "[email protected]"
> > <[email protected]>
> >Subject: Re: [Rtai] RTAI 5.0.1 calibrate program: BUG: unable to
> > handle kernel paging request at 00007ffe78e450f0 (Paolo Mantegazza)
> >Message-ID: <[email protected]>
> >Content-Type: text/plain; charset="utf-8"; Format="flowed"
> >
> >Thanks for pointing out the segfault of the calibration helper.
> >The problem is? just that there should not be such a helper anymore,
> >nonetheless it has been left in the distribution.
> >The reason is that the calibration is carried out as explained in the
> >RTAI config help lines, with due length in my opinion. Have a look at
> >it, either by reading the Kconfig file or under menuconfig.
> >Such a calibration is carried out, automatically, the very first time
> >you run rtai_sched and it does not find the file
> >"rtai-installdir/calibration/latencies", creates and uses it in
> >subsequent runs.
> >If you want to tune it further your way just run the latency checkers in
> >the installed testsuite, then edit that file by hand.
> >
> >If rdmsr gives an increasing SMI count then there should be a problem
> >for sure. I'd like to add your troubling chipset to the smi-module.c
> >list, but you say that it did not work. Then before doing it I need to
> >understand what's wrong.
> >
> >To help me (and you as well, hopefully), you should try the other SMI
> >diagnostic tool found in RTAI, i.e. smispv. It is made within RTAI but
> >is a stand alone code you can run anyway, as described in README.SMISPV.
> >If you'll do I'd like to know the outcome and, once you succeeded with
> >smispv, try setsmi and see if it is ok or fails.
> >
> >My way to use it is to launch smispv, an interactive tool, execute a
> >latency test, wait for a high latency overrun, play with smispv till the
> >current latency remains acceptable, while the overall max stay high.
> >Then stop latency, rerun it and see that the latency is ok, cross check
> >using smispv again to reenable smi and witness the latency skyrocketing.
> >Once what must be done to set smi so to avoid troubles, verify that
> >running setsmi obtains the same result. Eventually, production work will
> >begin by using setsmi before insmodig rtai_hal.ko and the rest.
> >
> >Paolo.
> >
> >
> >On 10/19/2017 04:01 AM, Samuel R wrote:
> >> Hi Paolo,
> >>
> >> Let me resume a few things:
> >>
> >> - the tscdeadline option should work in RTAI;
> >>
> >>
> >> Yes, this is not related to our problem. Sorry for the confusion.
> >>
> >> - the calibration problem must not exist, if you downloaded RTAI
> >> from the user contributions;
> >>
> >> The calibration program does work with the rtaicontrib version,
> >> although there is a segmentation fault when it is called with the
> >> --help flag, i.e. `./calibrate --help`. This is not really an issue
> >> since it appears that the actual calibration works without problems.
> >>
> >> - as for the missing? smi chipset? send me an email with the
> >> missing one, even if it will just confirm the one you mentioned
> >> already; I'll add it to the list in the approaching 5.1;
> >>
> >>
> >> Intel Corporation Sunrise Point-H LPC Controller (8086:a149)
> >>
> >> - If you have an smi problem, before trying a fix, try to diagnose
> >> it using the interactive graphic tool which come with RTAI;
> >> - as a further help for possible smi problems download what found
> >> at "01.org/msr-tools <http://01.org/msr-tools>" and use rdmsr to
> >> see if there are smi interrupts (there is a register counting
> >> them, if the count increases then you have smi problems);
> >>
> >>
> >> Right now we do think that the problem is related to SMI. We have used
> >> the `rdmsr 0x34` command and the SMI count increases by ~60 counts
> >> every second (see video below).
> >>
> >> - last option, give me root access to it, so that I can see what
> >> happens first hand; due to the time difference at Italy's antipode
> >> it can be impracticable, as there must be someone to push the hard
> >> reset in case of locks.
> >>
> >>
> >> This is probably not possible, since we are behind a university
> >> firewall... However, I have created a short video to illustrate what I
> >> have been trying with the smispv utility, and to show the rdmsr counts
> >> and measured kernel latencies. At the end I also show that the rtai
> >> calibration works. Hopefully this can adequately show what we are
> >> seeing from our side:
> >> https://www.youtube.com/watch?v=zC73JI4puMI
> >>
> >> Sam
> >>
> >>
> >> Paolo.
> >>
> >>
> >>
> >> On 10/18/2017 02:12 AM, Vivian McPhail wrote:
> >>> Hi Paolo and list,
> >>>
> >>> My colleague, Sam, who has been helping me, has done the following:
> >>> To follow up on this:
> >>>
> >>> >>> Have you diagnosed SMI with the graphic tool found in RTAI?
> >>> >>
> >>> >> We have tried using the smispv utility, however it seems to have no
> >>> >> effect.
> >>> >
> >>> > Please be more specific. What did you try to do, what were you expecting,
> >>> > and what happened, exactly?
> >>>
> >>> While running the latency program we also run smispv, however attempting to change the SMI bits appears to do nothing (the bitmask just goes back to the original values when we try to set it).
> >>>
> >>> > For example, if you tried to disable some SMI bit, and after issuing the
> >>> > command the bit is still there, then it is likely that the SMI_LOCK is set,
> >>> > preventing any change to the SMI bits.
> >>> >
> >>> > Check e.g. the intel's io-controller-hub-10-family-datasheet.pdf manual
> >>>
> >>> This SMI_LOCK bit sounds like it may be at least part of our problem. Our hardware contains a Intel Corporation Sunrise Point-H LPC Controller (8086:a149), and by reading 100-series-chipset-datasheet-vol-2.pdf we find some information on SMI_LOCK in the GEN_PMCON_A register (offset 0xA0). Is there an easy way to read the contents of this register so we can check whether this bit is indeed set?
> >>>
> >>> >> When we try to use the setsmi utility found in
> >>> >> /usr/src/rtai-5.0.1/base/arch/x86/calibration, we see the following:
> >>> >>
> >>> >> insmod: ERROR: could not insert module /usr/realtime/modules/rtai_smi.ko: Invalid parameters
> >>> >> setsmi: rmmod /usr/realtime/modules/rtai_smi.ko failed
> >>> >
> >>> > Have you an idea of what is the wrong parameter?
> >>>
> >>> The problem was that our controller was not defined in smi-module.c, so we were getting the following error in dmesg:
> >>> [ 179.583365] RTAI: Intel chipset not found.
> >>>
> >>> I have edited smi-module.c as follows to include our device (0x8086, 0xa149), which prevented this error.
> >>>
> >>> static struct pci_device_id hal_smi_pci_tbl[] = {
> >>> { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xa149) },
> >>> { 0, },
> >>> };
> >>>
> >>> However as with the smispv utility there is no noticeable change, either to the latencies, or to the apparent bits set as read from the smispv utility. Unfortunately I haven't had time to look further into the problem.
> >>>
> >>> Also, regarding Vivian's previous email, we did try adding `lapic=notscdeadline` to the kernel parameters based on an idea another colleague had, however this didn't improve our situation, so please ignore this point.
> >>>
> >>> Sam
> >>>
> >>> On 18 October 2017 at 09:28, Vivian McPhail
> >>> <[email protected] <mailto:[email protected]>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> We have added `lapic=notscdeadline` to the kernel command line.
> >>>
> >>> When attempting to run the `calibrate --help` program we get:
> >>>
> >>> sc-qi4 /usr/realtime/calibration # ./calibrate --help
> >>> Segmentation fault (core dumped)
> >>>
> >>> sc-qi4 /usr/realtime/calibration # dmesg
> >>> ...
> >>> [ 3847.540947] calibrate[4426]: segfault at 0 ip
> >>> 00007f1eb14e2ec6 sp 00007ffc486cba90 error 4 in libc-2.23.so
> >>> <http://libc-2.23.so>[7f1eb14ac000+190000]
> >>>
> >>> setsmi now runs and enables SMI workaround but our latencies
> >>> are still high:
> >>>
> >>> RTAI Testsuite - KERNEL space latency test (output data in
> >>> nanoseconds)
> >>>
> >>> *** latency verification tool with RTAI own real time kernel
> >>> tasks ***
> >>> ***??? period = 100000 (ns),? avrgtime = 1 (s)??? ***
> >>>
> >>> RTH|??? lat min|??? ovl min|??? lat avg| lat max|??? ovl
> >>> max|?? overruns
> >>> RTD|????? -1927|????? -1927|????? -1250| 150816|????
> >>> 150816|???????? 58
> >>> RTD|????? -1927|????? -1927|????? -1189| 172686|????
> >>> 172686|???????? 93
> >>> RTD|????? -1927|????? -1927|????? -1204| 146525|????
> >>> 172686|??????? 122
> >>> RTD|????? -1926|????? -1927|????? -1202| 149990|????
> >>> 172686|??????? 154
> >>> RTD|????? -1926|????? -1927|????? -1214| 150550|????
> >>> 172686|??????? 184
> >>> RTD|????? -1927|????? -1927|????? -1170| 151197|????
> >>> 172686|??????? 220
> >>> RTD|????? -1927|????? -1927|????? -1224| 148891|????
> >>> 172686|??????? 245
> >>> RTD|????? -1927|????? -1927|????? -1217| 149949|????
> >>> 172686|??????? 275
> >>> RTD|????? -1926|????? -1927|????? -1194| 150291|????
> >>> 172686|??????? 309
> >>> RTD|????? -1926|????? -1927|????? -1182| 144404|????
> >>> 172686|??????? 334
> >>> RTD|????? -1927|????? -1927|????? -1124| 153671|????
> >>> 172686|??????? 366
> >>> RTD|????? -1927|????? -1927|????? -1157| 151099|????
> >>> 172686|??????? 395
> >>> RTD|????? -1927|????? -1927|????? -1142| 157766|????
> >>> 172686|??????? 428
> >>> RTD|????? -1927|????? -1927|????? -1175| 154312|????
> >>> 172686|??????? 456
> >>> RTD|????? -1927|????? -1927|????? -1154| 150821|????
> >>> 172686|??????? 486
> >>> RTD|????? -1926|????? -1927|????? -1166| 149945|????
> >>> 172686|??????? 516
> >>> RTD|????? -1927|????? -1927|????? -1147| 174795|????
> >>> 174795|??????? 547
> >>> RTD|????? -1927|????? -1927|????? -1140| 189067|????
> >>> 189067|??????? 580
> >>> RTD|????? -1927|????? -1927|????? -1150| 150254|????
> >>> 189067|??????? 614
> >>> RTD|????? -1927|????? -1927|????? -1201| 162253|????
> >>> 189067|??????? 646
> >>> RTD|????? -1927|????? -1927|????? -1144| 157433|????
> >>> 189067|??????? 681
> >>> RTH|??? lat min|??? ovl min|??? lat avg| lat max|??? ovl
> >>> max|?? overruns
> >>> RTD|????? -1927|????? -1927|????? -1199| 147787|????
> >>> 189067|??????? 708
> >>>
> >>> Vivian
> >>>
> >>> On 6 October 2017 at 21:23, Paolo Mantegazza
> >>> <[email protected]
> >>> <mailto:[email protected]>> wrote:
> >>>
> >>> On 10/06/2017 03:32 AM, Vivian McPhail wrote:
> >>>> Hi list,
> >>>>
> >>>> Here is some more information:
> >>>> > An i3-6xxx was the cpu that first lead to the calibration problem. Which, in fact, was not a calibration problem but a memory protection that did not exist on previous generations, i.e for about more than 10 years of RTAI existence.
> >>>> >In any case, once the problem was solved, through the contribution release you mention, to my knowledge, the friendly user that helped me in the fix has not signaled any latency problem.
> >>>> >That said, can you tell us a few things more?.
> >>>>
> >>>> We are using rtai-5.0.1 contributed version with linux
> >>>> kernel 4.4.43
> >>>> Linux sc-qi4 4.4.43-rtaicontrib-5.0.1 #23 SMP PREEMPT
> >>>> Fri Oct 6 12:26:42 NZDT 2017 x86_64 Intel(R) Core(TM)
> >>>> i3-6100 CPU @ 3.70GHz GenuineIntel GNU/Linux
> >>>> Motherboard SuperMicro MBD-X11SSA-F-0
> >>>>
> >>>> >For example, what are the latency values you have, found with what test?
> >>>>
> >>>> Using RTAI kernel latency test, found at
> >>>> /usr/realtime/testsuite/kern/latency/run. We find
> >>>> similar results for userspace test
> >>>>
> >>>> RTAI Testsuite - KERNEL space latency test (output data in nanoseconds)
> >>>>
> >>>> *** latency verification tool with RTAI own real time kernel tasks ***
> >>>> *** period = 100000 (ns), avrgtime = 1 (s) ***
> >>>>
> >>>> RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
> >>>> RTD| -2070| -2070| -1206| 151372| 151372| 64
> >>>> RTD| -2107| -2107| -1207| 150895| 151372| 94
> >>>> RTD| -2061| -2107| -1202| 151300| 151372| 127
> >>>> RTD| -2073| -2107| -1212| 166180| 166180| 157
> >>>> RTD| -2082| -2107| -1185| 153918| 166180| 189
> >>>> RTD| -2132| -2132| -1195| 151415| 166180| 221
> >>>> RTD| -2043| -2132| -1216| 149363| 166180| 251
> >>>> RTD| -2057| -2132| -1201| 151410| 166180| 283
> >>>> RTD| -2042| -2132| -1201| 153008| 166180| 315
> >>>> RTD| -2071| -2132| -1194| 157882| 166180| 346
> >>>> RTD| -2075| -2132| -1205| 152579| 166180| 379
> >>>> RTD| -2088| -2132| -1208| 153254| 166180| 409
> >>>> RTD| -2110| -2132| -1205| 151180| 166180| 441
> >>>> RTD| -2086| -2132| -1202| 150438| 166180| 473
> >>>> RTD| -2064| -2132| -1190| 151402| 166180| 507
> >>>> RTD| -2076| -2132| -1199| 150358| 166180| 538
> >>>> RTD| -2079| -2132| -1215| 159729| 166180| 568
> >>>> RTD| -2048| -2132| -1189| 154771| 166180| 602
> >>>> RTD| -2060| -2132| -1205| 150056| 166180| 633
> >>>> RTD| -2084| -2132| -1198| 150029| 166180| 666
> >>>> RTD| -2075| -2132| -1207| 150878| 166180| 698
> >>>> RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
> >>>> RTD| -2076| -2132| -1212| 151351| 166180| 725
> >>>> RTD| -2074| -2132| -1200| 156473| 166180| 755
> >>>> RTD| -2081| -2132| -1218| 155487| 166180| 784
> >>>> RTD| -2077| -2132| -1205| 150254| 166180| 816
> >>>> RTD| -2072| -2132| -1205| 146909| 166180| 848
> >>>> RTD| -2084| -2132| -1196| 149810| 166180| 882
> >>>> RTD| -2062| -2132| -1197| 149134| 166180| 915
> >>>> RTD| -2074| -2132| -1223| 148643| 166180| 943
> >>>> RTD| -2075| -2132| -1210| 150753| 166180| 976
> >>>> RTD| -2064| -2132| -1138| 176904| 176904| 1009
> >>>> RTD| -2055| -2132| -1165| 175403| 176904| 1036
> >>>> RTD| -2058| -2132| -1142| 156620| 176904| 1066
> >>>> RTD| -2061| -2132| -1155| 151707| 176904| 1095
> >>>> RTD| -2086| -2132| -1129| 149400| 176904| 1130
> >>>> RTD| -2174| -2174| -1135| 150516| 176904| 1164
> >>>> RTD| -2139| -2174| -1139| 154105| 176904| 1196
> >>>> RTD| -2073| -2174| -1161| 160744| 176904| 1222
> >>>> RTD| -2073| -2174| -1151| 150689| 176904| 1252
> >>>> RTD| -2179| -2179| -1153| 152630| 176904| 1283
> >>>> RTD| -2053| -2179| -1157| 149657| 176904| 1314
> >>>> RTD| -2080| -2179| -1143| 150982| 176904| 1346
> >>>> RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
> >>>> RTD| -2070| -2179| -1029| 1246807| 1246807| 1391
> >>>> RTD| -2061| -2179| -1069| 948621| 1246807| 1431
> >>>> RTD| -2064| -2179| -1084| 650913| 1246807| 1469
> >>>> RTD| -2103| -2179| -1114| 359612| 1246807| 1502
> >>>> RTD| -2067| -2179| -1146| 161471| 1246807| 1535
> >>>> RTD| -2097| -2179| -1166| 150333| 1246807| 1566
> >>>> RTD| -2042| -2179| -1165| 151437| 1246807| 1597
> >>>> RTD| -2125| -2179| -1185| 148318| 1246807| 1626
> >>>> RTD| -2094| -2179| -1168| 150301| 1246807| 1656
> >>>> RTD| -2068| -2179| -1150| 150114| 1246807| 1689
> >>>> RTD| -2070| -2179| -1159| 150924| 1246807| 1720
> >>>> RTD| -2057| -2179| -1167| 156776| 1246807| 1751
> >>>> RTD| -2048| -2179| -1153| 155397| 1246807| 1783
> >>>> RTD| -2092| -2179| -1189| 150488| 1246807| 1812
> >>>> RTD| -2087| -2179| -1144| 150824| 1246807| 1846
> >>>> RTD| -2087| -2179| -1163| 151215| 1246807| 1877
> >>>> RTD| -2062| -2179| -1149| 151667| 1246807| 1909
> >>>> RTD| -2056| -2179| -1148| 155952| 1246807| 1943
> >>>> RTD| -2063| -2179| -1144| 150308| 1246807| 1977
> >>>> RTD| -2068| -2179| -1160| 157204| 1246807| 2009
> >>>> RTD| -2073| -2179| -1165| 151223| 1246807| 2039
> >>>> >Moreover are you sure they are due to SMI and not to other Linux config params (see the suggestions below)?
> >>>>
> >>>> We are not 100% sure on what the issue is, however we
> >>>> have used the command `rdmsr 0x34`, which returns the
> >>>> count of SMI since boot, and we observe that this
> >>>> register increases by ~60 counts every second (see, e.g.
> >>>> https://xenomai.org/2014/06/dealing-with-x86-smi-troubles/
> >>>> <https://xenomai.org/2014/06/dealing-with-x86-smi-troubles/>)
> >>>>
> >>>>
> >>>> We believe that our issues are not related to kernel
> >>>> configuration, however we are not experts in this domain
> >>>> so we may have made a mistake somewhere... Here is our
> >>>> current kernel configuration. We have tried many other
> >>>> possibilities, such as disabling legacy USB, and also
> >>>> video drivers with no difference to the latency. Note
> >>>> that we have disabled almost all bios options as well.
> >>>>
> >>>> Have you diagnosed SMI with the graphic tool found in RTAI?
> >>>>
> >>>> We have tried using the smispv utility, however it seems
> >>>> to have no effect.
> >>>>
> >>> Please be more specific. What did you try to do, what
> >>> were you expecting, and what happened, exactly?
> >>>
> >>> For example, if you tried to disable some SMI bit, and
> >>> after issuing the command the bit is still there, then it
> >>> is likely that the SMI_LOCK is set, preventing any change
> >>> to the SMI bits.
> >>>
> >>> Check e.g. the intel's
> >>> io-controller-hub-10-family-datasheet.pdf manual
> >>>>
> >>>> When we try to use the setsmi utility found in
> >>>> /usr/src/rtai-5.0.1/base/arch/x86/calibration, we see
> >>>> the following:
> >>>>
> >>>> insmod: ERROR: could not insert module /usr/realtime/modules/rtai_smi.ko: Invalid parameters
> >>>> setsmi: rmmod /usr/realtime/modules/rtai_smi.ko failed
> >>> Have you an idea of what is the wrong parameter?
> >>>
> >>> Paolo.
> >>>> Paolo,
> >>>> Thanks,
> >>>>
> >>>> Vivian
> >>>>
> >>>> On 6 October 2017 at 11:21, Paolo Mantegazza
> >>>> <[email protected]
> >>>> <mailto:[email protected]>> wrote:
> >>>>
> >>>> An i3-6xxx was the cpu that first lead to the
> >>>> calibration problem. Which, in fact, was not a
> >>>> calibration problem but a memory protection that did
> >>>> not exist on previous generations, i.e for about
> >>>> more than 10 years of RTAI existence.
> >>>> In any case, once the problem was solved, through
> >>>> the contribution release you mention, to my
> >>>> knowledge, the friendly user that helped me in the
> >>>> fix has not signaled any latency problem.
> >>>> That said, can you tell us a few things more?. For
> >>>> example, what are the latency values you have, found
> >>>> with what test? Moreover are you sure they are due
> >>>> to SMI and not to other Linux config params (see the
> >>>> suggestions below)? Have you diagnosed SMI with the
> >>>> graphic tool found in RTAI?
> >>>>
> >>>> Paolo,
> >>>>
> >>>> REMARKS-SUGGESTIONS ABOUT CONFIGURING LINUX AND RTAI
> >>>>
> >>>> < LINUX kernel related >
> >>>> - Under SMP set the number of CPUs equal to the real
> >>>> ones and have it matched in RTAI,
> >>>> ? no hyperthreading intended (see below)
> >>>> - Some peripherals, e.g. video cards, may stall CPUs
> >>>> attempting to access IO space.
> >>>> ? Verify "what ifs" related to graphic acceleration,
> >>>> likely better if disabled.
> >>>> ? Consider also if X term usage is really needed. If
> >>>> possible avoid it, especially
> >>>> ? in production work.
> >>>> - LINUX use of DMA can add latency, especially when
> >>>> it is supported in burst mode.
> >>>> - Cached memory disruption can add significant
> >>>> latencies, as experienced in a
> >>>> ? controller, after a far jump in the code and data,
> >>>> till the cache becomes hot
> >>>> ? again.
> >>>> - Power management, see CONFIG_CPU_FREQ and
> >>>> CONFIG_CPU_IDLE below; on portables
> >>>> ? battery management too.
> >>>> - Recent Intel SpeedStepping and Boosting.
> >>>> - Disable AUDITSYSCALLS.
> >>>> - Disable CPU_FREQ.
> >>>> - Disable CPU_IDLE and INTEL_IDLE, or boot with
> >>>> "intel_idle.max_cstate=0". If you
> >>>> ? want to be sure to have a never sleeping CPU
> >>>> execute, at the lowest priority,
> >>>> ? your own, per cpu, idle task, i.e. just doing
> >>>> "while(1);".
> >>>> - Disable APM and ACPI_Processor, but not everything
> >>>> related to power management.
> >>>> ? Take also into account that without ACPI enabled
> >>>> you might not see more than
> >>>> ? a single CPU.
> >>>> - Do not enable IPIPE legacy support. As a safety
> >>>> measure against such a choice,
> >>>> ? RTAI build is inhibited at the making of rtai_hal.ko.
> >>>> - Do not disable USB, but just any legacy support,
> >>>> possibly in the BIOS also. Once
> >>>> ? upon a time USB was a source of high RTAI
> >>>> latencies. Now that should happen with
> >>>> ? just legacy support enabled.
> >>>> - Try to configure the CPU type to be as close as
> >>>> possible to the one you have.
> >>>> - If unsure on the CPU to choose, care of setting
> >>>> one featuring a Time Stamp Clock
> >>>> ? (TSC), which means no 486 and "false" i586, as
> >>>> generic INTEL i586 compatibles
> >>>> ? often do not have a TSC, while true INTEL ones do
> >>>> have it.
> >>>> - If you are using a UniProcessor (UP) compile RTAI
> >>>> against a UP configured kernel.
> >>>> ? In fact RTAI compiled for SMP may not work when
> >>>> used on a UP machine. An issue
> >>>> ? to be fixed, sooner or later. In any case having
> >>>> everything UP for UP is always
> >>>> ? the more efficient solution.
> >>>> - If it is of no interest to you, disable any kernel
> >>>> debug support. Generally speaking,
> >>>> ? most RTAI users are not expected to debug the
> >>>> kernel, so it is suggested to always do
> >>>> ? so for production work. In any case, even if there
> >>>> should be no trouble in keeping it,
> >>>> ? except for some overhead more and an increase of
> >>>> latency here and there, it may happen
> >>>> ? that tracing could affect RTAI parts having some
> >>>> commonality with the kernel, e.g.
> >>>> ? though trace points missing symbols. If that
> >>>> happens you should either disable, at
> >>>> ? least, the trace option in "Kernel hacking", or
> >>>> add the exporting of the related
> >>>> ? symbols, which appear missing at insmoding any
> >>>> RTAI module.
> >>>> - If you witness a stack protector crash, disable
> >>>> stack protector support, at the
> >>>> ? bottom of the kernel config General Setup. There
> >>>> are 3 choices, "None" will work
> >>>> ? with RTAI for sure. It is possible that the
> >>>> "Regular" one could also be OK, while
> >>>> ? "Strong" will fail, always.
> >>>>
> >>>>
> >>>> < RTAI related >
> >>>> - Even if RTAI can work with hyperthreading enabled,
> >>>> such an option is deprecated
> >>>> ? as a possible cause of latency; in any case try
> >>>> and verify if it is acceptable,
> >>>> ? with your hardware and for your applications.
> >>>> - Any initialization of the device drivers, or
> >>>> anything related to the hardware,
> >>>> ? may lead to high latencies, e.g., but not always.
> >>>> doing "startx &" while a real
> >>>> ? time application is running. Once it is started
> >>>> there should be no major problems.
> >>>> ? If the truoble persists and you really need X,
> >>>> concurrently with you RTAI tasks, try
> >>>> ? disabling hardware graphic acceleration.? The best
> >>>> latencies usually come with no
> >>>> ? graphic application running.
> >>>> - A sizable part of the latency you see in RTAI hard
> >>>> timed programs can mature as
> >>>> ? an interrupt latency, little can be done to avoid
> >>>> that. Recall that, for shared pieces
> >>>> ? of hardware, e.g APIC, LINUX is left with the
> >>>> capability of using a few hard interrupts
> >>>> ? disable/enable. Moreover the processing of LINUX
> >>>> interrupts, during hard real time
> >>>> ? RTAI activities, are delayed but must be pended to
> >>>> be processed later on anyhow.
> >>>> ? A thing which requires keeping interrupts disabled
> >>>> for a, hopefully short, while.
> >>>> - If SMI is enabled and latencies are high, often
> >>>> appearing periodic also, use the
> >>>> ? RTAI tools to monitor and, possibly, fix it.
> >>>>
> >>>>
> >>>> ________________________________________
> >>>> From: Rtai [[email protected]
> >>>> <mailto:[email protected]>] on behalf of Vivian
> >>>> McPhail [[email protected]
> >>>> <mailto:[email protected]>]
> >>>> Sent: Thursday, October 5, 2017 7:14 PM
> >>>> To: [email protected] <mailto:[email protected]>
> >>>> Subject: Re: [Rtai] RTAI 5.0.1 calibrate program:
> >>>> BUG: unable to handle kernel paging request at
> >>>> 00007ffe78e450f0 (Paolo Mantegazza)
> >>>>
> >>>> Hi List,
> >>>>
> >>>> With respect to the below problem.? We have used the
> >>>> CONTRIB branch which Paolo mentioned (I had thought
> >>>> he pointed to the same tarball as the release).
> >>>>
> >>>> We are getting unacceptably high latencies with an
> >>>> i3 6100 7th generation CPU and are wondering whether
> >>>> we should downgrade to a CPU that doesn't have SMI.
> >>>>
> >>>> Has anyone else encountered latency issues like this?
> >>>>
> >>>> We can provide more information if required.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Vivian
> >>>>
> >>>>
> >>>> Message: 1
> >>>> Date: Tue, 19 Sep 2017 17:42:43 +0200
> >>>> From: Paolo Mantegazza <[email protected]
> >>>> <mailto:[email protected]><mailto:[email protected]
> >>>> <mailto:[email protected]>>>
> >>>> To: Rtai <[email protected]
> >>>> <mailto:[email protected]><mailto:[email protected]
> >>>> <mailto:[email protected]>>>
> >>>> Subject: Re: [Rtai] RTAI 5.0.1 calibrate program:
> >>>> BUG: unable to
> >>>> ? ? ? ? handle kernel paging request at 00007ffe78e450f0
> >>>> Message-ID:
> >>>> <[email protected]
> >>>> <mailto:[email protected]><mailto:[email protected]
> >>>> <mailto:[email protected]>>>
> >>>> Content-Type: text/plain; charset="utf-8";
> >>>> Format="flowed"
> >>>>
> >>>> Ciao,
> >>>> please, beware of trolls. They are amusing, at
> >>>> times, but often they do
> >>>> not know what they are talking about.
> >>>>
> >>>> The problem of calibration faults has been solved by
> >>>> the end of
> >>>> May-2017, thanks to a cooperation with Josef (A?falg).
> >>>> The fix is
> >>>> in"https://www.rtai.org/userfiles/downloads/RTAICONTRIB/rtai-5.0.1.tar.bz2
> >>>> <https://www.rtai.org/userfiles/downloads/RTAICONTRIB/rtai-5.0.1.tar.bz2>",
> >>>> to be 5.1, when we'll get a new RTAI repository,
> >>>> hopefully soon.
> >>>>
> >>>> If you want to know more about it have a look at the
> >>>> following May-2017
> >>>> threads on the RTAI mailing list:
> >>>> https://mail.rtai.org/pipermail/rtai/2017-May/027461.html
> >>>> <https://mail.rtai.org/pipermail/rtai/2017-May/027461.html>
> >>>> https://mail.rtai.org/pipermail/rtai/2017-May/027502.html
> >>>> <https://mail.rtai.org/pipermail/rtai/2017-May/027502.html>
> >>>>
> >>>> Paolo
> >>>>
> >>>> On 09/19/2017 05:01 AM, Alec Ari wrote:
> >>>> > I'm not sure why Paolo treats his RTAI 5.0.1
> >>>> release like gold. It's got tons of issues,
> >>>> everything from hard-locks, overruns, and extreme
> >>>> latency spikes. Not sure where he got the idea that
> >>>> it's so brilliant and to always grab the latest
> >>>> versions of his (ripped-off) code. RTAI 4.0.1 which
> >>>> I've based my stable tree of off has absolutely no
> >>>> issues.
> >>>> >
> >>>> > Myself and many others (LinuxCNC) have been using
> >>>> this tree for the past few years and it's fine:
> >>>> >
> >>>> >
> >>>> > https://github.com/NTULINUX/RTAI
> >>>> <https://github.com/NTULINUX/RTAI>
> >>>> >
> >>>> > Don't use the drop-legacy branch, it's not ready
> >>>> and I'm still ironing out all the bugs that Paolo
> >>>> introduced into the scheduler and self-calibration.
> >>>> The old calibration code worked so much better,
> >>>> literally "just works." RTAI 5 is not ready for
> >>>> production and is not stable by any means. I highly
> >>>> suggest avoiding anything above 5.0 until there's
> >>>> some more confirmed cases of it working in upcoming
> >>>> releases.
> >>>> >
> >>>> > I've been doing kernel development for over a
> >>>> decade and this is not user-error.
> >>>> > _______________________________________________
> >>>> > Rtai mailing list
> >>>> > [email protected]
> >>>> <mailto:[email protected]><mailto:[email protected]
> >>>> <mailto:[email protected]>>
> >>>> > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
> >>>> <https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai>
> >>>> -------------- next part --------------
> >>>> An HTML attachment was scrubbed...
> >>>> URL:
> >>>> <http://mail.rtai.org/pipermail/rtai/attachments/20170919/5adf2dc1/attachment-0001.html
> >>>> <http://mail.rtai.org/pipermail/rtai/attachments/20170919/5adf2dc1/attachment-0001.html>>
> >>>>
> >>>> ------------------------------
> >>>>
> >>>> Message: 2
> >>>> Date: Tue, 19 Sep 2017 22:04:56 +0000 (UTC)
> >>>> From: Alec Ari <[email protected]
> >>>> <mailto:[email protected]><mailto:[email protected]
> >>>> <mailto:[email protected]>>>
> >>>> To: Rtai <[email protected]
> >>>> <mailto:[email protected]><mailto:[email protected]
> >>>> <mailto:[email protected]>>>
> >>>> Subject: Re: [Rtai] RTAI 5.0.1 calibrate program:
> >>>> BUG: unable to
> >>>> ? ? ? ? handle kernel paging request at 00007ffe78e450f0
> >>>> Message-ID:
> >>>> <[email protected]
> >>>> <mailto:[email protected]><mailto:[email protected]
> >>>> <mailto:[email protected]>>>
> >>>> Content-Type: text/plain; charset=UTF-8
> >>>>
> >>>> I'm lost for words, Paolo actually replied to
> >>>> something I said.
> >>>>
> >>>>
> >>>> So use the RTAI 5.0.1 tarball from the users
> >>>> repository instead of the one in the releases, you
> >>>> say? The one with "ifdef CONFIG_RTAI_USE_STACK_ARGS"
> >>>> scattered about? You do realize that
> >>>> CONFIG_RTAI_USE_STACK_ARGS is an undefined config
> >>>> option that has no meaning, not in Kconfig or
> >>>> configure.in
> >>>> <http://configure.in><http://configure.in
> >>>> <http://configure.in>> anywhere?
> >>>>
> >>>>
> >>>> If you think I'm trolling, you should look at
> >>>> yourself. Stealing my code and writing the sloppiest
> >>>> crap to almost purposely make it confusing.
> >>>>
> >>>> Like what the hell is this, seriously:
> >>>>
> >>>> { if (ipipe_notifier_enabled_p(current)) return
> >>>> ((int (*)(unsigned long, void
> >>>> *))ipipe_root_domain->legacy.handlers[exception])(exception,
> >>>> regs); } {
> >>>>
> >>>> I've said it before and I'll say it again; your work
> >>>> really belongs in the obfuscated C code contest.
> >>>> This project would be dead without me and ShabbyX,
> >>>> but you're too arrogant to give anyone else credit.
> >>>> Everything that hasn't been done by myself or
> >>>> Shahbaz doesn't work. He left the project and moved
> >>>> on to other things but I remember the countless
> >>>> hours we spent into revamping the entire tree. You
> >>>> tell me who the troll is, or just go hide off in
> >>>> your corner again like you always do.
> >>>>
> >>>>
> >>>> Alec Ari
> >>>>
> >>>>
> >>>> ------------------------------
> >>>>
> >>>> Subject: Digest Footer
> >>>>
> >>>> _______________________________________________
> >>>> Rtai mailing list
> >>>> [email protected]
> >>>> <mailto:[email protected]><mailto:[email protected]
> >>>> <mailto:[email protected]>>
> >>>> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
> >>>> <https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai>
> >>>>
> >>>> ------------------------------
> >>>>
> >>>> End of Rtai Digest, Vol 117, Issue 8
> >>>> ************************************
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Vivian McPhail
> >>>> PhD Candidate
> >>>> Department of Physics
> >>>> University of Auckland
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Vivian McPhail
> >>>> PhD Candidate
> >>>> Department of Physics
> >>>> University of Auckland
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Vivian McPhail
> >>> PhD Candidate
> >>> Department of Physics
> >>> University of Auckland
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Vivian McPhail
> >>> PhD Candidate
> >>> Department of Physics
> >>> University of Auckland
> >>
> >>
> >>
> >> _______________________________________________
> >> Rtai mailing list
> >> [email protected] <mailto:[email protected]>
> >> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
> >> <https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai>
> >>
> >>
> >
> >-------------- next part --------------
> >An HTML attachment was scrubbed...
> >URL: <http://mail.rtai.org/pipermail/rtai/attachments/20171019/8d3460e2/attachment.html>
> >
> >------------------------------
> >
> >Subject: Digest Footer
> >
> >_______________________________________________
> >Rtai mailing list
> >[email protected]
> >https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
> >
> >------------------------------
> >
> >End of Rtai Digest, Vol 118, Issue 15
> >*************************************
> >
>
>
> 【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>
> <http://you.163.com/item/detail?id=1165011&from=web_gg_mail_jiaobiao_9>
>
>
> _______________________________________________
> Rtai mailing list
> [email protected]
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
smi-module.c
(text/x-csrc, 11.4 KB)
/* * SMI workaround for x86. * * Cut/Pasted from Vitor Angelo "smi" module. * Adapted by Gilles Chanteperdrix <[email protected]>. * Further adaptation by Alberto Sechi <[email protected]>. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, Inc., 675 Mass Ave, Cambridge MA 02139, * USA; either version 2 of the License, or (at your option) any later * version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ #include <linux/version.h> #include <linux/kernel.h> #include <linux/module.h> #include <linux/pci.h> #include <linux/pci_ids.h> #include <linux/reboot.h> #include <rtai_wrappers.h> /* set these as you need */ #define CONFIG_RTAI_HW_SMI_ALL 0 #define CONFIG_RTAI_HW_SMI_INTEL_USB2 0 #define CONFIG_RTAI_HW_SMI_LEGACY_USB2 0 #define CONFIG_RTAI_HW_SMI_PERIODIC 0 #define CONFIG_RTAI_HW_SMI_TCO 1 #define CONFIG_RTAI_HW_SMI_MC 0 #define CONFIG_RTAI_HW_SMI_APMC 0 #define CONFIG_RTAI_HW_SMI_LEGACY_USB 0 #define CONFIG_RTAI_HW_SMI_BIOS 0 #ifndef PCI_DEVICE_ID_INTEL_ICH7_0 #define PCI_DEVICE_ID_INTEL_ICH7_0 0x27b8 #endif #ifndef PCI_DEVICE_ID_INTEL_ICH7_1 #define PCI_DEVICE_ID_INTEL_ICH7_1 0x27b9 #endif #ifndef PCI_DEVICE_ID_INTEL_ICH8_4 #define PCI_DEVICE_ID_INTEL_ICH8_4 0x2815 #endif #ifndef PCI_DEVICE_ID_INTEL_ICH10_1 #define #define PCI_DEVICE_ID_INTEL_ICH10_1 0x3a16 #endif #ifndef PCI_DEVICE_ID_INTEL_ICH9_1 #define PCI_DEVICE_ID_INTEL_ICH9_1 0x2917 #endif #ifndef PCI_DEVICE_ID_INTEL_ICH9_5 #define PCI_DEVICE_ID_INTEL_ICH9_5 0x2919 #endif #ifndef PCI_DEVICE_ID_INTEL_PCH_LPC_MIN #define PCI_DEVICE_ID_INTEL_PCH_LPC_MIN 0x3b00 #endif #ifndef PCI_DEVICE_ID_INTEL_ESB2_0 #define PCI_DEVICE_ID_INTEL_ESB2_0 0x2670 #endif #ifndef PCI_DEVICE_ID_INTEL_H77_EXPRESS_CHIPSET_LPC #define PCI_DEVICE_ID_INTEL_H77_EXPRESS_CHIPSET_LPC 0x1e4a #endif #ifndef PCI_DEVICE_ID_INTEL_SUNRISE_POINT_H_LPC #define PCI_DEVICE_ID_INTEL_SUNRISE_POINT_H_LPC 0xa149 #endif #ifndef PCI_DEVICE_ID_INTEL_CELERON_J1900 #define PCI_DEVICE_ID_INTEL_CELERON_J1900 0x0f1c #endif static struct pci_device_id hal_smi_pci_tbl[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AA_0) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AB_0) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_0) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_10) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801E_0) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_0) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_12) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_0) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_12) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801EB_0) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_0) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_2) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_0) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_1) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_4) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH10_1) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_1) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_5) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PCH_LPC_MIN) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB2_0) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_H77_EXPRESS_CHIPSET_LPC) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SUNRISE_POINT_H_LPC) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_CELERON_J1900) }, { 0, }, }; #define DEVFN 0xf8 /* device 31, function 0 */ #define PMBASE_B0 0x40 #define PMBASE_B1 0x41 #define SMI_CTRL_ADDR 0x30 #define SMI_STATUS_ADDR 0x34 #define SMI_MON_ADDR 0x40 /* SMI_EN register: ICH[0](16 bits), ICH[2-5](32 bits) */ #define INTEL_USB2_EN_BIT (0x01 << 18) /* ICH4, ... */ #define LEGACY_USB2_EN_BIT (0x01 << 17) /* ICH4, ... */ #define PERIODIC_EN_BIT (0x01 << 14) /* called 1MIN_ in ICH0 */ #define TCO_EN_BIT (0x01 << 13) #define MCSMI_EN_BIT (0x01 << 11) #define SWSMI_TMR_EN_BIT (0x01 << 6) #define APMC_EN_BIT (0x01 << 5) #define SLP_EN_BIT (0x01 << 4) #define LEGACY_USB_EN_BIT (0x01 << 3) #define BIOS_EN_BIT (0x01 << 2) #define GBL_SMI_EN_BIT (0x01 << 0) /* This is reset by a PCI reset event! */ unsigned long hal_smi_masked_bits = 0x1 #if 0 #if CONFIG_RTAI_HW_SMI_ALL | GBL_SMI_EN_BIT #else #if CONFIG_RTAI_HW_SMI_INTEL_USB2 | INTEL_USB2_EN_BIT #endif #if CONFIG_RTAI_HW_SMI_LEGACY_USB2 | LEGACY_USB2_EN_BIT #endif #if CONFIG_RTAI_HW_SMI_PERIODIC | PERIODIC_EN_BIT #endif #if CONFIG_RTAI_HW_SMI_TCO | TCO_EN_BIT #endif #if CONFIG_RTAI_HW_SMI_MC | MCSMI_EN_BIT #endif #if CONFIG_RTAI_HW_SMI_APMC | APMC_EN_BIT #endif #if CONFIG_RTAI_HW_SMI_LEGACY_USB | LEGACY_USB_EN_BIT #endif #if CONFIG_RTAI_HW_SMI_BIOS | BIOS_EN_BIT #endif #endif #endif ; RTAI_MODULE_PARM(hal_smi_masked_bits, ulong); static unsigned long original_smi_value; static unsigned long hal_smi_saved_bits; static unsigned short hal_smi_en_addr; static struct pci_dev *smi_dev; #define mask_bits(v, p) outl(inl(p) & ~(v), (p)) #define set_bits(v, p) outl(inl(p) | (v), (p)) static int rtai_smi_notify_reboot(struct notifier_block *nb, unsigned long event, void *p) { switch (event) { case SYS_DOWN: case SYS_HALT: case SYS_POWER_OFF: if (hal_smi_en_addr) { set_bits(hal_smi_saved_bits, hal_smi_en_addr); } } return NOTIFY_DONE; } static struct notifier_block rtai_smi_reboot_notifier = { .notifier_call = &rtai_smi_notify_reboot, .next = NULL, .priority = 0 }; static void hal_smi_restore(void) { if (hal_smi_en_addr) { set_bits(hal_smi_saved_bits, hal_smi_en_addr); pci_dev_put(smi_dev); unregister_reboot_notifier(&rtai_smi_reboot_notifier); } } static void hal_smi_disable(void) { if (hal_smi_en_addr) { original_smi_value = inl(hal_smi_en_addr); hal_smi_saved_bits = original_smi_value & hal_smi_masked_bits; mask_bits(hal_smi_masked_bits, hal_smi_en_addr); register_reboot_notifier(&rtai_smi_reboot_notifier); } } static unsigned short get_smi_en_addr(struct pci_dev *dev) { u_int8_t byte0, byte1; pci_read_config_byte(dev, PMBASE_B0, &byte0); pci_read_config_byte(dev, PMBASE_B1, &byte1); return SMI_CTRL_ADDR + (((byte1 << 1) | (byte0 >> 7)) << 7); //bits 7-15 } static int hal_smi_init(void) { struct pci_dev *dev = NULL; struct pci_device_id *id; /* * Do not use pci_register_driver, pci_enable_device, ... * Just register the used ports. */ for (id = &hal_smi_pci_tbl[0]; dev == NULL && id->vendor != 0; id++) { dev = pci_get_device(id->vendor, id->device, NULL); } if (dev == NULL || dev->bus->number || dev->devfn != DEVFN) { pci_dev_put(dev); printk("RTAI: Intel chipset not found.\n"); return -ENODEV; } printk("RTAI: Intel chipset found, enabling SMI workaround.\n"); hal_smi_en_addr = get_smi_en_addr(dev); smi_dev = dev; hal_smi_disable(); return 0; } /************************************************************************/ static void reminders(unsigned long smi_value) { char echo[200] = "Bits enabled:"; int i; for (i = 0; i < 19; i++) { if (smi_value & (1 << i)) { switch(i) { case 0: { strcat(echo, " GBL_SMI,"); break; } case 1: { strcat(echo, " EOS (special),"); break; } case 2: { strcat(echo, " BIOS,"); break; } case 3: { strcat(echo, " LEGACY_USB,"); break; } case 4: { strcat(echo, " SLP,"); break; } case 5: { strcat(echo, " APMC,"); break; } case 6: { strcat(echo, " SWSMI_TMR,"); break; } case 11: { strcat(echo, " MCSMI,"); break; } case 13: { strcat(echo, " TCO,"); break; } case 14: { strcat(echo, " PERIODIC,"); break; } case 17: { strcat(echo, " LEGACY_USB2,"); break; } case 18: { strcat(echo, " INTEL_USB2,"); break; } } } } printk("%s\b.\n", echo); return; } int init_module(void) { int retval; if (!(retval = hal_smi_init())) { unsigned long smi_value; smi_value = inl(hal_smi_en_addr); reminders(original_smi_value); printk("Original SMI configuration value %lx has been cleared with mask = %lx (saved mask setting %lx), new value %lx.\n", original_smi_value, hal_smi_masked_bits, hal_smi_saved_bits, smi_value); reminders(smi_value); } return retval; } void cleanup_module(void) { unsigned long smival; smival = inl(hal_smi_en_addr); hal_smi_restore(); printk("SMI configuration value %lx has been reset to its original value %x, saved mask used = %lx.\n", smival, inl(hal_smi_en_addr), hal_smi_saved_bits); return; } MODULE_LICENSE("GPL"); /**************************************************************************/ /* FIXME: there are many more SMI sources than those of the SMI_EN register. From http://www.intel.com/design/chipsets/datashts/252516.htm there are at least the following other sources : pages 377, 386, 388, 389; Power management register GEN_PMCON1, bit SMI_LOCK, locks GLB_SMI_EN bits PER_SMI_SEL, allow selection of the periodic SMI registers PM1_STS, PM1_EN, PM1_CNT bit SCI_EN, if cleared generates SMI for power management events. pages 173, 381, 400; GPIOs register GPI[0-15]_ROUT allow routing each GPIO to SMI or SCI register ALT_GP_SMI_EN, ALT_GP_SMI_STS, allow masking SMIs for GPIOs pages 184, 188, 402; legacy devices emulation (ATA, floppy, parallel, UARTs, keyboard). I/O to specified ports may cause events, which can generate an SMI, depending on registers configuration : register DEVTRAP_EN, DEVTRAP_STS BIG FAT WARNING : globally disabling SMI on a box with SATA disks and SATA controller in "legacy" mode, probably prevents disks from working. pages 382, 383, 400; Monitors ? seem to be a generic legacy device emulation (like previous), registers MON[4-7]_FWD_EN, enables forwarding of I/O to LPC MON[4-7]_TRP_RNG, address of the emulated devices MON[4-7]_TRP_MSK and MON_SMI (registers MON[4-7]_TRAP_EN and MON[4-7]_TRAP_STS) page 407: TCO register TCO1_CNT, bit NMI2SMI_EN, enables TCO to use SMI instead of NMI, bit TCO_TMR_HLT, should be cleared to avoid being rebooted when the TCO timer expires. Dangerous bit: TCO_LOCK locks the TCO timer until reboot. register used by Linux drivers/char/watchdog/i8xx_tco.c page 492, 493: USB EHCI legacy support and SPECIAL SMI, i.e Intel Specific USB 2.0 SMI register. page 520, SMBus may be disabled by clearing register HOSTC, bit SMB_SMI_EN register used by Linux driver drivers/i2c/busses/i2c-i801.c */