1. 05 May, 2014 1 commit
  2. 25 Mar, 2014 1 commit
  3. 20 Mar, 2014 1 commit
    • Srivatsa S. Bhat's avatar
      x86, hpet: Fix CPU hotplug callback registration · 9014ad2a
      Srivatsa S. Bhat authored
      
      
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      below:
      
      	get_online_cpus();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	register_cpu_notifier(&foobar_cpu_notifier);
      
      	put_online_cpus();
      
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      
      Instead, the correct and race-free way of performing the callback
      registration is:
      
      	cpu_notifier_register_begin();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	/* Note the use of the double underscored version of the API */
      	__register_cpu_notifier(&foobar_cpu_notifier);
      
      	cpu_notifier_register_done();
      
      Fix the hpet code in x86 by using this latter form of callback registration.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9014ad2a
  4. 18 Mar, 2014 1 commit
  5. 04 Mar, 2014 1 commit
  6. 28 Jan, 2013 1 commit
  7. 02 Nov, 2012 1 commit
  8. 25 May, 2012 1 commit
  9. 07 May, 2012 2 commits
  10. 22 Dec, 2011 1 commit
    • Kay Sievers's avatar
      driver-core: remove sysdev.h usage. · edbaa603
      Kay Sievers authored
      
      
      The sysdev.h file should not be needed by any in-kernel code, so remove
      the .h file from these random files that seem to still want to include
      it.
      
      The sysdev code will be going away soon, so this include needs to be
      removed no matter what.
      
      Cc: Jiandong Zheng <jdzheng@broadcom.com>
      Cc: Scott Branden <sbranden@broadcom.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: David Brown <davidb@codeaurora.org>
      Cc: Daniel Walker <dwalker@fifo99.com>
      Cc: Bryan Huntsman <bryanh@codeaurora.org>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: Wan ZongShun <mcuos.com@gmail.com>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: "Venkatesh Pallipadi
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Matthew Garrett <mjg@redhat.com>
      Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
      edbaa603
  11. 08 Dec, 2011 1 commit
  12. 05 Dec, 2011 1 commit
  13. 31 Oct, 2011 1 commit
    • Paul Gortmaker's avatar
      x86: Fix files explicitly requiring export.h for EXPORT_SYMBOL/THIS_MODULE · 69c60c88
      Paul Gortmaker authored
      
      
      These files were implicitly getting EXPORT_SYMBOL via device.h
      which was including module.h, but that will be fixed up shortly.
      
      By fixing these now, we can avoid seeing things like:
      
      arch/x86/kernel/rtc.c:29: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
      arch/x86/kernel/pci-dma.c:20: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
      arch/x86/kernel/e820.c:69: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL_GPL’
      
      [ with input from Randy Dunlap <rdunlap@xenotime.net> and also
        from Stephen Rothwell <sfr@canb.auug.org.au> ]
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      69c60c88
  14. 15 Jul, 2011 1 commit
  15. 13 Jul, 2011 1 commit
  16. 09 Jun, 2011 2 commits
  17. 05 Jun, 2011 1 commit
    • Andy Lutomirski's avatar
      x86-64: Map the HPET NX · d319bb79
      Andy Lutomirski authored
      
      
      Currently the HPET mapping is a user-accessible syscall
      instruction at a fixed address some of the time.
      
      A sufficiently determined hacker might be able to guess when.
      Signed-off-by: default avatarAndy Lutomirski <luto@mit.edu>
      Cc: Jesper Juhl <jj@chaosbits.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Jan Beulich <JBeulich@novell.com>
      Cc: richard -rw- weinberger <richard.weinberger@gmail.com>
      Cc: Mikael Pettersson <mikpe@it.uu.se>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Louis Rilling <Louis.Rilling@kerlabs.com>
      Cc: Valdis.Kletnieks@vt.edu
      Cc: pageexec@freemail.hu
      Link: http://lkml.kernel.org/r/ab41b525a4ca346b1ca1145d16fb8d181861a8aa.1307292171.git.luto@mit.edu
      
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d319bb79
  18. 19 May, 2011 1 commit
  19. 12 Mar, 2011 1 commit
  20. 13 Dec, 2010 1 commit
    • Thomas Gleixner's avatar
      x86: HPET: Chose a paranoid safe value for the ETIME check · f1c18071
      Thomas Gleixner authored
      commit 995bd3bb (x86: Hpet: Avoid the comparator readback penalty)
      chose 8 HPET cycles as a safe value for the ETIME check, as we had the
      confirmation that the posted write to the comparator register is
      delayed by two HPET clock cycles on Intel chipsets which showed
      readback problems.
      
      After that patch hit mainline we got reports from machines with newer
      AMD chipsets which seem to have an even longer delay. See
      http://thread.gmane.org/gmane.linux.kernel/1054283 and
      http://thread.gmane.org/gmane.linux.kernel/1069458
      
       for further
      information.
      
      Boris tried to come up with an ACPI based selection of the minimum
      HPET cycles, but this failed on a couple of test machines. And of
      course we did not get any useful information from the hardware folks.
      
      For now our only option is to chose a paranoid high and safe value for
      the minimum HPET cycles used by the ETIME check. Adjust the minimum ns
      value for the HPET clockevent accordingly.
      Reported-Bistected-and-Tested-by: default avatarMarkus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <alpine.LFD.2.00.1012131222420.2653@localhost6.localdomain6>
      Cc: Simon Kirby <sim@hostway.ca>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Andreas Herrmann <Andreas.Herrmann3@amd.com>
      Cc: John Stultz <johnstul@us.ibm.com>
      f1c18071
  21. 26 Oct, 2010 1 commit
  22. 12 Oct, 2010 1 commit
  23. 30 Sep, 2010 1 commit
  24. 18 Sep, 2010 1 commit
    • Thomas Gleixner's avatar
      x86: Hpet: Avoid the comparator readback penalty · 995bd3bb
      Thomas Gleixner authored
      
      
      Due to the overly intelligent design of HPETs, we need to workaround
      the problem that the compare value which we write is already behind
      the actual counter value at the point where the value hits the real
      compare register. This happens for two reasons:
      
      1) We read out the counter, add the delta and write the result to the
         compare register. When a NMI or SMI hits between the read out and
         the write then the counter can be ahead of the event already
      
      2) The write to the compare register is delayed by up to two HPET
         cycles in certain chipsets.
      
      We worked around this by reading back the compare register to make
      sure that the written value has hit the hardware. For certain ICH9+
      chipsets this can require two readouts, as the first one can return
      the previous compare register value. That's bad performance wise for
      the normal case where the event is far enough in the future.
      
      As we already know that the write can be delayed by up to two cycles
      we can avoid the read back of the compare register completely if we
      make the decision whether the delta has elapsed already or not based
      on the following calculation:
      
        cmp = event - actual_count;
      
      If cmp is less than 8 HPET clock cycles, then we decide that the event
      has happened already and return -ETIME. That covers the above #1 and
      #2 problems which would cause a wait for HPET wraparound (~306
      seconds).
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarNix <nix@esperi.org.uk>
      Tested-by: default avatarArtur Skawina <art.08.09@gmail.com>
      Cc: Damien Wyart <damien.wyart@free.fr>
      Tested-by: default avatarJohn Drescher <drescherjm@gmail.com>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Tested-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <alpine.LFD.2.00.1009151500060.2416@localhost6.localdomain6>
      995bd3bb
  25. 14 Sep, 2010 1 commit
    • Thomas Gleixner's avatar
      x86: hpet: Work around hardware stupidity · 54ff7e59
      Thomas Gleixner authored
      This more or less reverts commits 08be9796 (x86: Force HPET
      readback_cmp for all ATI chipsets) and 30a564be (x86, hpet: Restrict
      read back to affected ATI chipsets) to the status of commit 8da854cb
      (x86, hpet: Erratum workaround for read after write of HPET
      comparator).
      
      The delta to commit 8da854cb is mostly comments and the change from
      WARN_ONCE to printk_once as we know the call path of this function
      already.
      
      This needs really in depth explanation:
      
      First of all the HPET design is a complete failure. Having a counter
      compare register which generates an interrupt on matching values
      forces the software to do at least one superfluous readback of the
      counter register.
      
      While it is nice in theory to program "absolute" time events it is
      practically useless because the timer runs at some absurd frequency
      which can never be matched to real world units. So we are forced to
      calculate a relative delta and this forces a readout of the actual
      counter value, adding the delta and programming the compare
      register. When the delta is small enough we run into the danger that
      we program a compare value which is already in the past. Due to the
      compare for equal nature of HPET we need to read back the counter
      value after writing the compare rehgister (btw. this is necessary for
      absolute timeouts as well) to make sure that we did not miss the timer
      event. We try to work around that by setting the minimum delta to a
      value which is larger than the theoretical time which elapses between
      the counter readout and the compare register write, but that's only
      true in theory. A NMI or SMI which hits between the readout and the
      write can easily push us beyond that limit. This would result in
      waiting for the next HPET timer interrupt until the 32bit wraparound
      of the counter happens which takes about 306 seconds.
      
      So we designed the next event function to look like:
      
         match = read_cnt() + delta;
         write_compare_ref(match);
         return read_cnt() < match ? 0 : -ETIME;
      
      At some point we got into trouble with certain ATI chipsets. Even the
      above "safe" procedure failed. The reason was that the write to the
      compare register was delayed probably for performance reasons. The
      theory was that they wanted to avoid the synchronization of the write
      with the HPET clock, which is understandable. So the write does not
      hit the compare register directly instead it goes to some intermediate
      register which is copied to the real compare register in sync with the
      HPET clock. That opens another window for hitting the dreaded "wait
      for a wraparound" problem.
      
      To work around that "optimization" we added a read back of the compare
      register which either enforced the update of the just written value or
      just delayed the readout of the counter enough to avoid the issue. We
      unfortunately never got any affirmative info from ATI/AMD about this.
      
      One thing is sure, that we nuked the performance "optimization" that
      way completely and I'm pretty sure that the result is worse than
      before some HW folks came up with those.
      
      Just for paranoia reasons I added a check whether the read back
      compare register value was the same as the value we wrote right
      before. That paranoia check triggered a couple of years after it was
      added on an Intel ICH9 chipset. Venki added a workaround (commit
      8da854cb) which was reading the compare register twice when the first
      check failed. We considered this to be a penalty in general and
      restricted the readback (thus the wasted CPU cycles) to the known to
      be affected ATI chipsets.
      
      This turned out to be a utterly wrong decision. 2.6.35 testers
      experienced massive problems and finally one of them bisected it down
      to commit 30a564be
      
       which spured some further investigation.
      
      Finally we got confirmation that the write to the compare register can
      be delayed by up to two HPET clock cycles which explains the problems
      nicely. All we can do about this is to go back to Venki's initial
      workaround in a slightly modified version.
      
      Just for the record I need to say, that all of this could have been
      avoided if hardware designers and of course the HPET committee would
      have thought about the consequences for a split second. It's out of my
      comprehension why designing a working timer is so hard. There are two
      ways to achieve it:
      
       1) Use a counter wrap around aware compare_reg <= counter_reg
          implementation instead of the easy compare_reg == counter_reg
      
          Downsides:
      
      	- It needs more silicon.
      
      	- It needs a readout of the counter to apply a relative
      	  timeout. This is necessary as the counter does not run in
      	  any useful (and adjustable) frequency and there is no
      	  guarantee that the counter which is used for timer events is
      	  the same which is used for reading the actual time (and
      	  therefor for calculating the delta)
      
          Upsides:
      
      	- None
      
        2) Use a simple down counter for relative timer events
      
          Downsides:
      
      	- Absolute timeouts are not possible, which is not a problem
      	  at all in the context of an OS and the expected
      	  max. latencies/jitter (also see Downsides of #1)
      
         Upsides:
      
      	- It needs less or equal silicon.
      
      	- It works ALWAYS
      
      	- It is way faster than a compare register based solution (One
      	  write versus one write plus at least one and up to four
      	  reads)
      
      I would not be so grumpy about all of this, if I would not have been
      ignored for many years when pointing out these flaws to various
      hardware folks. I really hate timers (at least those which seem to be
      designed by janitors).
      
      Though finally we got a reasonable explanation plus a solution and I
      want to thank all the folks involved in chasing it down and providing
      valuable input to this.
      Bisected-by: default avatarNix <nix@esperi.org.uk>
      Reported-by: default avatarArtur Skawina <art.08.09@gmail.com>
      Reported-by: default avatarDamien Wyart <damien.wyart@free.fr>
      Reported-by: default avatarJohn Drescher <drescherjm@gmail.com>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: stable@kernel.org
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      54ff7e59
  26. 12 Aug, 2010 1 commit
  27. 27 Jul, 2010 1 commit
  28. 23 Jul, 2010 1 commit
  29. 29 Apr, 2010 1 commit
  30. 01 Apr, 2010 2 commits
    • Alok Kataria's avatar
      x86, hpet: Fix bug in RTC emulation · b4a5e8a1
      Alok Kataria authored
      
      
      We think there exists a bug in the HPET code that emulates the RTC.
      
      In the normal case, when the RTC frequency is set, the rtc driver tells
      the hpet code about it here:
      
      int hpet_set_periodic_freq(unsigned long freq)
      {
              uint64_t clc;
      
              if (!is_hpet_enabled())
                      return 0;
      
              if (freq <= DEFAULT_RTC_INT_FREQ)
                      hpet_pie_limit = DEFAULT_RTC_INT_FREQ / freq;
              else {
                      clc = (uint64_t) hpet_clockevent.mult * NSEC_PER_SEC;
                      do_div(clc, freq);
                      clc >>= hpet_clockevent.shift;
                      hpet_pie_delta = (unsigned long) clc;
              }
              return 1;
      }
      
      If freq is set to 64Hz (DEFAULT_RTC_INT_FREQ) or lower, then
      hpet_pie_limit (a static) is set to non-zero.  Then, on every one-shot
      HPET interrupt, hpet_rtc_timer_reinit is called to compute the next
      timeout.  Well, that function has this logic:
      
              if (!(hpet_rtc_flags & RTC_PIE) || hpet_pie_limit)
                      delta = hpet_default_delta;
              else
                      delta = hpet_pie_delta;
      
      Since hpet_pie_limit is not 0, hpet_default_delta is used.  That
      corresponds to 64Hz.
      
      Now, if you set a different rtc frequency, you'll take the else path
      through hpet_set_periodic_freq, but unfortunately no one resets
      hpet_pie_limit back to 0.
      
      Boom....now you are stuck with 64Hz RTC interrupts forever.
      
      The patch below just resets the hpet_pie_limit value when requested freq
      is greater than DEFAULT_RTC_INT_FREQ, which we think fixes this problem.
      Signed-off-by: default avatarAlok N Kataria <akataria@vmware.com>
      LKML-Reference: <201003112200.o2BM0Hre012875@imap1.linux-foundation.org>
      Signed-off-by: default avatarDaniel Hecht <dhecht@vmware.com>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      b4a5e8a1
    • Pallipadi, Venkatesh's avatar
      x86, hpet: Erratum workaround for read after write of HPET comparator · 8da854cb
      Pallipadi, Venkatesh authored
      On Wed, Feb 24, 2010 at 03:37:04PM -0800, Justin Piszcz wrote:
      > Hello,
      >
      > Again, on the Intel DP55KG board:
      >
      > # uname -a
      > Linux host 2.6.33 #1 SMP Wed Feb 24 18:31:00 EST 2010 x86_64 GNU/Linux
      >
      > [    1.237600] ------------[ cut here ]------------
      > [    1.237890] WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80()
      > [    1.238221] Hardware name:
      > [    1.238504] hpet: compare register read back failed.
      > [    1.238793] Modules linked in:
      > [    1.239315] Pid: 0, comm: swapper Not tainted 2.6.33 #1
      > [    1.239605] Call Trace:
      > [    1.239886]  <IRQ>  [<ffffffff81056c13>] ? warn_slowpath_common+0x73/0xb0
      > [    1.240409]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
      > [    1.240699]  [<ffffffff81056cb0>] ? warn_slowpath_fmt+0x40/0x50
      > [    1.240992]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
      > [    1.241281]  [<ffffffff81041ad0>] ? hpet_next_event+0x70/0x80
      > [    1.241573]  [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0
      > [    1.241859]  [<ffffffff81078e32>] ? tick_handle_oneshot_broadcast+0xe2/0x100
      > [    1.246533]  [<ffffffff8102a67a>] ? timer_interrupt+0x1a/0x30
      > [    1.246826]  [<ffffffff81085499>] ? handle_IRQ_event+0x39/0xd0
      > [    1.247118]  [<ffffffff81087368>] ? handle_edge_irq+0xb8/0x160
      > [    1.247407]  [<ffffffff81029f55>] ? handle_irq+0x15/0x20
      > [    1.247689]  [<ffffffff810294a2>] ? do_IRQ+0x62/0xe0
      > [    1.247976]  [<ffffffff8146be53>] ? ret_from_intr+0x0/0xa
      > [    1.248262]  <EOI>  [<ffffffff8102f277>] ? mwait_idle+0x57/0x80
      > [    1.248796]  [<ffffffff8102645c>] ? cpu_idle+0x5c/0xb0
      > [    1.249080] ---[ end trace db7f668fb6fef4e1 ]---
      >
      > Is this something Intel has to fix or is it a bug in the kernel?
      
      This is a chipset erratum.
      
      Thomas: You mentioned we can retain this check only for known-buggy and
      hpet debug kind of options. But here is the simple workaround patch for
      this particular erratum.
      
      Some chipsets have a erratum due to which read immediately following a
      write of HPET comparator returns old comparator value instead of most
      recently written value.
      
      Erratum 15 in
      "Intel I/O Controller Hub 9 (ICH9) Family Specification Update"
      (http://www.intel.com/assets/pdf/specupdate/316973.pdf
      
      )
      
      Workaround for the errata is to read the comparator twice if the first
      one fails.
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      LKML-Reference: <20100225185348.GA9674@linux-os.sc.intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@gmail.com>
      Cc: <stable@kernel.org>
      8da854cb
  31. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        bloc...
      5a0e3ad6
  32. 05 Feb, 2010 1 commit
  33. 23 Jan, 2010 1 commit
  34. 27 Nov, 2009 1 commit
  35. 27 Aug, 2009 1 commit
  36. 21 Aug, 2009 1 commit
    • Jan Beulich's avatar
      x86, hpet: Simplify the HPET code · 5946fa3d
      Jan Beulich authored
      
      
      On 64-bits, using unsigned long when unsigned int suffices
      needlessly creates larger code (due to the need for REX
      prefixes), and most of the logic in hpet.c really doesn't need
      64-bit operations.
      
      At once this avoids the need for a couple of type casts.
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Cc: Shaohua Li <shaohua.li@intel.com>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      LKML-Reference: <4A8BC9780200007800010832@vpn.id2.novell.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      5946fa3d
  37. 12 Aug, 2009 1 commit