lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49C371F5.5010100@monstr.eu>
Date:	Fri, 20 Mar 2009 11:37:41 +0100
From:	Michal Simek <monstr@...str.eu>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	LKML <linux-kernel@...r.kernel.org>, john.williams@...alogix.com,
	John Stultz <johnstul@...ibm.com>
Subject: Re: [PATCH 08/57] microblaze_v7: Interrupt handling, timer support,
 selfmod code

Hi Thomas,
> On Fri, 20 Mar 2009, Michal Simek wrote:
> 
>> Thomas,
>>
>> just one other question.
>> For me will be useful to use second timer which is inside timer IP core.
>> There are two timers with one interrupt line. And I can of course resolve which
>> counter cause it. That's no problem.
>>
>> My question is about timer_irqaction where is dev_id. What should be there?
>> Point to clocksource structure or clockevent?
>>
>> static struct irqaction timer_irqaction = {
>> 	.handler = timer_interrupt,
>> 	.flags = IRQF_DISABLED | IRQF_TIMER,
>> 	.name = "timer",
>> 	.dev_id = &clocksource_microblaze,
>> };
> 
> The clockevent of course. It's the one which emits the interrupts.
> 
> Just for clarification. The clocksource is basically a counter to read
> out the current time. Such a counter usually does not deliver
> interrupts. It wraps at some point, but that is handled by the generic
> time keeping code. If you setup the 32 bit counter to count up and let
> it run free then the counter will wrap from 0xffffffff to 0. Nothing
> you have to worry about. You just provide a function to read it.

That's is crucial information which I haven't found.

> 
> The clockevent is the device which delivers either periodic or oneshot
> interrupts. Sa you dont have to worry about the shared interrupt line
> in that case.

I have working implementation. I just need to clear some thing relate with HW -
some checking mechanism that two timer must be there + some selfmod test. I'll
send it soon and do some LTP test too but I believe that I clean that code. I
take a look at irq code too.

Below is timer_list log.

I can paste current my code but people don't like it attachment and in-line
code.I'll do regular one patch with git and send it.

Why is my .resolution: 10000000 nsecs? It seems to me weird.

I'll wait for John's answer for fixing shift and rating values too.

Thanks a lot,
Michal

> 
> Thanks,
> 
> 	tglx

# cat /proc/timer_list
Timer List Version: v0.4
HRTIMER_MAX_CLOCK_BASES: 2
now at 193684779856 nsecs

cpu: 0
 clock 0:
  .base:       902774d0
  .index:      0
  .resolution: 10000000 nsecs
  .get_time:   ktime_get_real
active timers:
 clock 1:
  .base:       902774f4
  .index:      1
  .resolution: 10000000 nsecs
  .get_time:   ktime_get
active timers:
 #0: <9e2d3a48>, hrtimer_wakeup, S:01, <9e2d3a48>, inetd/54
 # expires at 194110626631-194111626591 nsecs [in 425846775 to 426846735 nsecs]
 #1: <9e0e5a48>, hrtimer_wakeup, S:01, <9e0e5a48>, thttpd/50
 # expires at 249711205338-249811205338 nsecs [in 56026425482 to 56126425482 nsecs]


Tick Device: mode:     0
Per CPU device: 0
Clock Event Device: microblaze_clockevent
 max_delta_ns:   2147483647
 min_delta_ns:   1000
 mult:           536870912
 shift:          32
 mode:           2
 next_event:     2147483646999999999 nsecs
 set_next_event: microblaze_timer_set_next_event
 set_mode:       microblaze_timer_set_mode
 event_handler:  tick_handle_periodic

# cat /proc/timer_list
Timer List Version: v0.4
HRTIMER_MAX_CLOCK_BASES: 2
now at 198714389017 nsecs

cpu: 0
 clock 0:
  .base:       902774d0
  .index:      0
  .resolution: 10000000 nsecs
  .get_time:   ktime_get_real
active timers:
 clock 1:
  .base:       902774f4
  .index:      1
  .resolution: 10000000 nsecs
  .get_time:   ktime_get
active timers:
 #0: <9e2d3a48>, hrtimer_wakeup, S:01, <9e2d3a48>, inetd/54
 # expires at 199160628442-199161628402 nsecs [in 446239425 to 447239385 nsecs]
 #1: <9e0e5a48>, hrtimer_wakeup, S:01, <9e0e5a48>, thttpd/50
 # expires at 249711205338-249811205338 nsecs [in 50996816321 to 51096816321 nsecs]


Tick Device: mode:     0
Per CPU device: 0
Clock Event Device: microblaze_clockevent
 max_delta_ns:   2147483647
 min_delta_ns:   1000
 mult:           536870912
 shift:          32
 mode:           2
 next_event:     2147483646999999999 nsecs
 set_next_event: microblaze_timer_set_next_event
 set_mode:       microblaze_timer_set_mode
 event_handler:  tick_handle_periodic

#






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ