Re: Kernel Oops

On 03/31/2016 01:35 PM, Bunjes Friedemann wrote:
> Hi,
>
> I disabled the high precision timer in my bios and recompiled a fresh 
> patched 3.16 kernel not in preemtible, but in desktop mode.
> Now the module seems to load, but the latency test hangs due to a 
> non-responding module (?):
>
Do not stay hanged on a single task. Try the user latency also and report.
Paolo

> [   74.567982] RTAI[malloc]: global heap size = 2097152 bytes, <BSD>.
> [   74.595871] , kstacks pool size = 524288 bytes.
> [   74.595873] RTAI[sched]: hard timer type/freq = APIC/99748998(Hz); 
> default timing: periodic; linear timed lists.
> [   74.595875] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq 
> = 3191992000 hz.
> [   74.595877] RTAI[sched]: timer setup = 10 ns, resched latency = 
> 3933 ns.
>
> *
> *
> * Type ^C to stop this application.
> *
> *
> Warning: Error opening /proc/rtai/latency_calibrate
>          Couldn't get infos about the module's state.
> RTAI Testsuite - KERNEL latency (all data in nanoseconds)
> RTH|    lat min|    ovl min|    lat avg|    lat max|    ovl max|   
> overruns
>
>
> What might be the reason for this and how can I debug?
>
> Cheers,
>
> Friedemann
>
>> Am 30.03.2016 um 23:55 schrieb Paolo Mantegazza 
>> <[email protected] <mailto:[email protected]>>:
>>
>> Unfortunately this thread went on privately. Likely because of a 
>> wrong answer click of mine, apologies.
>>
>> In any case it gives me the chance of remarking a few things related 
>> to the support of Linux-3.x.x and now 4.x.x.
>> - RTAI-4 onward) is based on the oneshot mode timing only. I still 
>> use periodic timers on data acquisition card to time specific tasks . 
>> whituout charging the scheduler with their pacing.
>> - from RTAI-5, i.e the actual VULCANO to be released shortly,  there 
>> starting/stopping_rt_timer, it is done by rtai_sched onyhow.
>> - in such a view the setting of the hard timer mode its start/stop, 
>> both in periodic and oneshot mode, will do nothing; they are just 
>> kept for compatibility, so that there is no need to change any 
>> existing code
>> - HPET is not used by RTAI but 8259/54 is used in UP mode, even if it 
>> is strongly suggested to enable the APIC if available
>> - RTAI does not use the second channel of 8259/54 to emulate a 
>> continuously running clock, so  a _TSC_is_needed
>>
>> In practice what above restricts the newest RTAI versions to true 
>> 586s and onward. For fake 586s and 486 earlier version of RTAI should 
>> be used.
>>
>> That said there is no need to disable NO_HZ and high 
>> precision/resolution timers if they are available in Linux.
>>
>> Paolo
>>
>> ________________________________________
>> From: Rtai [[email protected] <mailto:[email protected]>] on 
>> behalf of Alec Ari [[email protected] <mailto:[email protected]>]
>> Sent: Wednesday, March 30, 2016 10:37 PM
>> To: RTAI Mailing List
>> Subject: Re: [Rtai] Kernel Oops
>>
>> RTAI should be able to use the 8259/8254 timers unless that's now 
>> broken? It's never _needed_ APIC or HPET in the past. If it's broken 
>> or not working (buggy hardware / BIOS) try disabling high precision + 
>> high resolution event timers in kernel config and BIOS if applicable. 
>> Also, to avoid NULL pointer issues, set CONFIG_LSM_MMAP_MIN_ADDR to 
>> value 65536.
>>
>> Alec Ari
>> _______________________________________________
>> Rtai mailing list
>> [email protected] <mailto:[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
>
> -- 
> Dr. rer. nat. Friedemann Bunjes
> EDV Entwicklung und Koordination
> Hertie-Institut für Klinische Hirnforschung
> Zentrum für Neurologie
> Universitätsklinikum Tübingen
> Otfried-Müller-Str. 25
> 72076 Tübingen
> Tel. +49-7071-29-81999
> Fax +49-7071-29-25010
>

_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai