1. 01 Aug, 2014 1 commit
  2. 10 Mar, 2014 1 commit
  3. 04 Mar, 2014 5 commits
  4. 24 Feb, 2014 1 commit
    • Alan Stern's avatar
      USB: complain if userspace resets an active endpoint · f080a51b
      Alan Stern authored
      
      
      It is an error for a driver to call usb_clear_halt() or
      usb_reset_endpoint() while there are URBs queued for the endpoint,
      because the end result is not well defined.  At the time the endpoint
      gets reset, it may or may not be actively running.
      
      As far as I know, no kernel drivers do this.  But some userspace
      drivers do, and it seems like a good idea to bring this error to their
      attention.
      
      This patch adds a warning to the kernel log whenever a program invokes
      the USBDEVFS_CLEAR_HALT or USBDEVFS_RESETEP ioctls at an inappropriate
      time, and includes the name of the program.  This will make it clear
      that any subsequent errors are not due to the misbehavior of a kernel
      driver.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Suggested-by: default avatarBjørn Mork <bjorn@mork.no>
      CC: Stanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f080a51b
  5. 07 Jan, 2014 1 commit
  6. 16 Oct, 2013 2 commits
  7. 25 Sep, 2013 1 commit
    • Kurt Garloff's avatar
      usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit · 831abf76
      Kurt Garloff authored
      Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
      [1] with the Windows App (EasyNote) works natively but fails when
      Windows is running under KVM (and the USB device handed to KVM).
      
      The reason is a USB control message
       usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008
      This goes to endpoint address 0x01 (wIndex); however, endpoint address
      0x01 does not exist. There is an endpoint 0x81 though (same number,
      but other direction); the app may have meant that endpoint instead.
      
      The kernel thus rejects the IO and thus we see the failure.
      
      Apparently, Linux is more strict here than Windows ... we can't change
      the Win app easily, so that's a problem.
      
      It seems that the Win app/driver is buggy here and the driver does not
      behave fully according to the USB HID class spec that it claims to
      belong to.  The device seems to happily deal with that though (and
      seems to not really care about this value much).
      
      So the question is whether the Linux kernel should filter here.
      Rejecting has the risk that somewhat non-compliant userspace apps/
      drivers (most likely in a virtual machine) are prevented from working.
      Not rejecting has the risk of confusing an overly sensitive device with
      such a transfer. Given the fact that Windows does not filter it makes
      this risk rather small though.
      
      The patch makes the kernel more tolerant: If the endpoint address in
      wIndex does not exist, but an endpoint with toggled direction bit does,
      it will let the transfer through. (It does NOT change the message.)
      
      With attached patch, the app in Windows in KVM works.
       usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81
      
      I suspect this will mostly affect apps in virtual environments; as on
      Linux the apps would have been adapted to the stricter handling of the
      kernel. I have done that for mine[2].
      
      [1] http://www.pegatech.com/
      [2] https://sourceforge.net/projects/notetakerpen/
      
      Signed-off-by: default avatarKurt Garloff <kurt@garloff.de>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      831abf76
  8. 17 Sep, 2013 1 commit
  9. 25 Jul, 2013 1 commit
    • Hans de Goede's avatar
      usbfs: Allow printer class 'get_device_id' without needing to claim the intf · 5dc50c35
      Hans de Goede authored
      
      
      For certain (HP) printers the printer device_id does not only contain a
      static part identifying the printer, but it also contains a dynamic part
      giving printer status, ink level, etc.
      
      To get to this info various userspace utilities need to be able to make a
      printer class 'get_device_id' request without first claiming the interface
      (as that is in use for the actual printer driver).
      
      Since the printer class 'get_device_id' request does not change interface
      settings in anyway, allowing this without claiming the interface should not
      cause any issues.
      
      CC: Sanjay Kumar <sanjay.kumar14@hp.com>
      CC: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5dc50c35
  10. 29 May, 2013 1 commit
  11. 17 May, 2013 3 commits
  12. 17 Apr, 2013 1 commit
  13. 22 Feb, 2013 1 commit
  14. 06 Feb, 2013 1 commit
  15. 17 Oct, 2012 1 commit
  16. 10 Sep, 2012 1 commit
    • Hans de Goede's avatar
      usbfs: Add a new disconnect-and-claim ioctl (v2) · 0837e7e5
      Hans de Goede authored
      
      
      Apps which deal with devices which also have a kernel driver, need to do
      the following:
      1) Check which driver is attached, so as to not detach the wrong driver
         (ie detaching usbfs while another instance of the app is using the device)
      2) Detach the kernel driver
      3) Claim the interface
      
      Where moving from one step to the next for both 1-2 and 2-3 consists of
      a (small) race window. So currently such apps are racy and people just live
      with it.
      
      This patch adds a new ioctl which makes it possible for apps to do this
      in a race free manner. For flexibility apps can choose to:
      1) Specify the driver to disconnect
      2) Specify to disconnect any driver except for the one named by the app
      3) Disconnect any driver
      
      Note that if there is no driver attached, the ioctl will just act like the
      regular claim-interface ioctl, this is by design, as returning an error for
      this condition would open a new bag of race-conditions.
      
      Changes in v2:
      -Fix indentation of if blocks where the condition spans multiple lines
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0837e7e5
  17. 06 Jul, 2012 3 commits
    • Hans de Goede's avatar
      usbdevfs: Use scatter-gather lists for large bulk transfers · 3d97ff63
      Hans de Goede authored
      
      
      When using urb->transfer_buffer we need to allocate physical contiguous buffers
      for the entire transfer, which is pretty much guaranteed to fail with large
      transfers.
      
      Currently userspace works around this by breaking large transfers into multiple
      urbs. For large bulk transfers this leads to all kind of complications.
      
      This patch makes it possible for userspace to reliable submit large bulk
      transfers to scatter-gather capable host controllers in one go, by using a
      scatterlist to break the transfer up in managable chunks.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d97ff63
    • Hans de Goede's avatar
      usbdevfs: Add a USBDEVFS_GET_CAPABILITIES ioctl · 19181bc5
      Hans de Goede authored
      
      
      There are a few (new) usbdevfs capabilities which an application cannot
      discover in any other way then checking the kernel version. There are 3
      problems with this:
      1) It is just not very pretty.
      2) Given the tendency of enterprise distros to backport stuff it is not
      reliable.
      3) As discussed in length on the mailinglist, USBDEVFS_URB_BULK_CONTINUATION
      does not work as it should when combined with USBDEVFS_URB_SHORT_NOT_OK
      (which is its intended use) on devices attached to an XHCI controller.
      So the availability of these features can be host controller dependent,
      making depending on them based on the kernel version not a good idea.
      
      This patch besides adding the new ioctl also adds flags for the following
      existing capabilities:
      
      USBDEVFS_CAP_ZERO_PACKET,        available since 2.6.31
      USBDEVFS_CAP_BULK_CONTINUATION,  available since 2.6.32, except for XHCI
      USBDEVFS_CAP_NO_PACKET_SIZE_LIM, available since 3.3
      
      Note that this patch only does not advertise the USBDEVFS_URB_BULK_CONTINUATION
      cap for XHCI controllers, bulk transfers with this flag set will still be
      accepted when submitted to XHCI controllers.
      
      Returning -EINVAL for them would break existing apps, and in most cases the
      troublesome scenario wrt USBDEVFS_URB_SHORT_NOT_OK urbs on XHCI controllers
      will never get hit, so this would break working use cases.
      
      The disadvantage of not returning -EINVAL is that cases were it is causing
      real trouble may go undetected / the cause of the trouble may be unclear,
      but this is the best we can do.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19181bc5
    • Hans de Goede's avatar
      usbdevfs: Correct amount of data copied to user in processcompl_compat · 2102e06a
      Hans de Goede authored
      
      
      iso data buffers may have holes in them if some packets were short, so for
      iso urbs we should always copy the entire buffer, just like the regular
      processcompl does.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2102e06a
  18. 18 May, 2012 1 commit
    • Huajun Li's avatar
      USB: Remove races in devio.c · 4e09dcf2
      Huajun Li authored
      
      
      There exist races in devio.c, below is one case,
      and there are similar races in destroy_async()
      and proc_unlinkurb().  Remove these races.
      
       cancel_bulk_urbs()        async_completed()
      -------------------                -----------------------
       spin_unlock(&ps->lock);
      
                                 list_move_tail(&as->asynclist,
      		                    &ps->async_completed);
      
                                 wake_up(&ps->wait);
      
                                 Lead to free_async() be triggered,
                                 then urb and 'as' will be freed.
      
       usb_unlink_urb(as->urb);
       ===> refer to the freed 'as'
      Signed-off-by: default avatarHuajun Li <huajun.li.lee@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Oncaphillis <oncaphillis@snafu.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e09dcf2
  19. 29 Apr, 2012 2 commits
  20. 12 Jan, 2012 1 commit
  21. 22 Dec, 2011 1 commit
    • Sarah Sharp's avatar
      usbfs: Fix oops related to user namespace conversion. · 1b41c832
      Sarah Sharp authored
      When running the Point Grey "flycap" program for their USB 3.0 camera
      (which was running as a USB 2.0 device for some reason), I trigger this
      oops whenever I try to open a video stream:
      
      Dec 15 16:48:34 puck kernel: [ 1798.715559] BUG: unable to handle kernel NULL pointer dereference at           (null)
      Dec 15 16:48:34 puck kernel: [ 1798.719153] IP: [<ffffffff8147841e>] free_async+0x1e/0x70
      Dec 15 16:48:34 puck kernel: [ 1798.720991] PGD 6f833067 PUD 6fc56067 PMD 0
      Dec 15 16:48:34 puck kernel: [ 1798.722815] Oops: 0002 [#1] SMP
      Dec 15 16:48:34 puck kernel: [ 1798.724627] CPU 0
      Dec 15 16:48:34 puck kernel: [ 1798.724636] Modules linked in: ecryptfs encrypted_keys sha1_generic trusted binfmt_misc sha256_generic aesni_intel cryptd aes_x86_64 aes_generic parport_pc dm_crypt ppdev joydev snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi snd_hda_intel snd_hda_codec snd_hwdep snd_pcm thinkpad_acpi mac80211 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer btusb uvcvideo snd_seq_device bluetooth videodev psmouse snd v4l2_compat_ioctl32 serio_raw tpm_tis cfg80211 tpm tpm_bios nvram soundcore snd_page_alloc lp parport i915 xhci_hcd ahci libahci drm_kms_helper drm sdhci_pci sdhci e1000e i2c_algo_bit video
      Dec 15 16:48:34 puck kernel: [ 1798.734212]
      Dec 15 16:48:34 puck kernel: [ 1798.736162] Pid: 2713, comm: FlyCap2 Not tainted 3.2.0-rc5+ #28 LENOVO 4286CTO/4286CTO
      Dec 15 16:48:34 puck kernel: [ 1798.738148] RIP: 0010:[<ffffffff8147841e>]  [<ffffffff8147841e>] free_async+0x1e/0x70
      Dec 15 16:48:34 puck kernel: [ 1798.740134] RSP: 0018:ffff88005715fd78  EFLAGS: 00010296
      Dec 15 16:48:34 puck kernel: [ 1798.742118] RAX: 00000000fffffff4 RBX: ffff88006fe8f900 RCX: 0000000000004118
      Dec 15 16:48:34 puck kernel: [ 1798.744116] RDX: 0000000001000000 RSI: 0000000000016390 RDI: 0000000000000000
      Dec 15 16:48:34 puck kernel: [ 1798.746087] RBP: ffff88005715fd88 R08: 0000000000000000 R09: ffffffff8146f22e
      Dec 15 16:48:34 puck kernel: [ 1798.748018] R10: ffff88006e520ac0 R11: 0000000000000001 R12: ffff88005715fe28
      Dec 15 16:48:34 puck kernel: [ 1798.749916] R13: ffff88005d31df00 R14: ffff88006fe8f900 R15: 00007f688c995cb8
      Dec 15 16:48:34 puck kernel: [ 1798.751785] FS:  00007f68a366da40(0000) GS:ffff880100200000(0000) knlGS:0000000000000000
      Dec 15 16:48:34 puck kernel: [ 1798.753659] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      Dec 15 16:48:34 puck kernel: [ 1798.755509] CR2: 0000000000000000 CR3: 00000000706bb000 CR4: 00000000000406f0
      Dec 15 16:48:34 puck kernel: [ 1798.757334] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      Dec 15 16:48:34 puck kernel: [ 1798.759124] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Dec 15 16:48:34 puck kernel: [ 1798.760871] Process FlyCap2 (pid: 2713, threadinfo ffff88005715e000, task ffff88006c675b80)
      Dec 15 16:48:34 puck kernel: [ 1798.762605] Stack:
      Dec 15 16:48:34 puck kernel: [ 1798.764297]  ffff88005715fe28 0000000000000000 ffff88005715fe08 ffffffff81479058
      Dec 15 16:48:34 puck kernel: [ 1798.766020]  0000000000000000 ffffea0000004000 ffff880000004118 0000000000000000
      Dec 15 16:48:34 puck kernel: [ 1798.767750]  ffff880000000001 ffff88006e520ac0 fffffff46fd81180 0000000000000000
      Dec 15 16:48:34 puck kernel: [ 1798.769472] Call Trace:
      Dec 15 16:48:34 puck kernel: [ 1798.771147]  [<ffffffff81479058>] proc_do_submiturb+0x778/0xa00
      Dec 15 16:48:34 puck kernel: [ 1798.772798]  [<ffffffff8147a5fd>] usbdev_do_ioctl+0x24d/0x1200
      Dec 15 16:48:34 puck kernel: [ 1798.774410]  [<ffffffff8147b5de>] usbdev_ioctl+0xe/0x20
      Dec 15 16:48:34 puck kernel: [ 1798.775975]  [<ffffffff81189259>] do_vfs_ioctl+0x99/0x600
      Dec 15 16:48:34 puck kernel: [ 1798.777534]  [<ffffffff81189851>] sys_ioctl+0x91/0xa0
      Dec 15 16:48:34 puck kernel: [ 1798.779088]  [<ffffffff816247c2>] system_call_fastpath+0x16/0x1b
      ec 15 16:48:34 puck kernel: [ 1798.780634] Code: 51 ff ff ff e9 29 ff ff ff 0f 1f 40 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 89 fb 48 8b 7f 18 e8 a6 ea c0 ff 4
      8 8b 7b 20 <f0> ff 0f 0f 94 c0 84 c0 74 05 e8 d3 99 c1 ff 48 8b 43 40 48 8b
      Dec 15 16:48:34 puck kernel: [ 1798.783970] RIP  [<ffffffff8147841e>] free_async+0x1e/0x70
      Dec 15 16:48:34 puck kernel: [ 1798.785630]  RSP <ffff88005715fd78>
      Dec 15 16:48:34 puck kernel: [ 1798.787274] CR2: 0000000000000000
      Dec 15 16:48:34 puck kernel: [ 1798.794728] ---[ end trace 52894d3355f88d19 ]---
      
      markup_oops.pl says the oops is in put_cred:
      
       ffffffff81478401:      48 89 e5                mov    %rsp,%rbp
       ffffffff81478404:      53                      push   %rbx
       ffffffff81478405:      48 83 ec 08             sub    $0x8,%rsp
       ffffffff81478409:      e8 f2 c0 1a 00          callq  ffffffff81624500 <mcount>
       ffffffff8147840e:      48 89 fb                mov    %rdi,%rbx   |  %ebx => ffff88006fe8f900
              put_pid(as->pid);
       ffffffff81478411:      48 8b 7f 18             mov    0x18(%rdi),%rdi
       ffffffff81478415:      e8 a6 ea c0 ff          callq  ffffffff81086ec0 <put_pid>
              put_cred(as->cred);
       ffffffff8147841a:      48 8b 7b 20             mov    0x20(%rbx),%rdi |  %edi => 0  %ebx = ffff88006fe8f900
        */
       static inline int atomic_dec_and_test(atomic_t *v)
       {
              unsigned char c;
      
              asm volatile(LOCK_PREFIX "decl %0; sete %1"
      *ffffffff8147841e:      f0 ff 0f                lock decl (%rdi)   |  %edi = 0 <--- faulting instruction
       ffffffff81478421:      0f 94 c0                sete   %al
       static inline void put_cred(const struct cred *_cred)
       {
              struct cred *cred = (struct cred *) _cred;
      
              validate_creds(cred);
              if (atomic_dec_and_test(&(cred)->usage))
       ffffffff81478424:      84 c0                   test   %al,%al
       ffffffff81478426:      74 05                   je     ffffffff8147842d <free_async+0x2d>
                      __put_cred(cred);
       ffffffff81478428:      e8 d3 99 c1 ff          callq  ffffffff81091e00 <__put_cred>
              kfree(as->urb->transfer_buffer);
       ffffffff8147842d:      48 8b 43 40             mov    0x40(%rbx),%rax
       ffffffff81478431:      48 8b 78 68             mov    0x68(%rax),%rdi
       ffffffff81478435:      e8 a6 e1 ce ff          callq  ffffffff811665e0 <kfree>
              kfree(as->urb->setup_packet);
       ffffffff8147843a:      48 8b 43 40             mov    0x40(%rbx),%rax
       ffffffff8147843e:      48 8b b8 90 00 00 00    mov    0x90(%rax),%rdi
       ffffffff81478445:      e8 96 e1 ce ff          callq  ffffffff811665e0 <kfree>
              usb_free_urb(as->urb);
       ffffffff8147844a:      48 8b 7b 40             mov    0x40(%rbx),%rdi
       ffffffff8147844e:      e8 0d 6b ff ff          callq  ffffffff8146ef60 <usb_free_urb>
      
      This bug seems to have been introduced by commit
      d178bc3a
      
       "user namespace: usb: make usb
      urbs user namespace aware (v2)"
      
      I'm not sure if this is right fix, but it does stop the oops.
      
      Unfortunately, the Point Grey software still refuses to work, but it's a
      closed source app, so I can't fix it.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1b41c832
  22. 18 Nov, 2011 3 commits
    • Alan Stern's avatar
      USB: make the usbfs memory limit configurable · 3f5eb8d5
      Alan Stern authored
      
      
      The 16-MB global limit on memory used by usbfs isn't suitable for all
      people.  It's a reasonable default, but there are applications
      (especially for SuperSpeed devices) that need a lot more.
      
      This patch (as1498) creates a writable module parameter for usbcore to
      control the global limit.  The default is still 16 MB, but users can
      change it at runtime, even after usbcore has been loaded.  As a
      special case, setting the value to 0 is treated the same as the hard
      limit of 2047 MB.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      3f5eb8d5
    • Alan Stern's avatar
      USB: change the memory limits in usbfs URB submission · add1aaea
      Alan Stern authored
      
      
      For a long time people have complained about the limitations imposed
      by usbfs.  URBs coming from userspace are not allowed to have transfer
      buffers larger than a more-or-less arbitrary maximum.
      
      While it is generally a good idea to avoid large transfer buffers
      (because the data has to be bounced to/from a contiguous kernel-space
      buffer), it's not the kernel's job to enforce such limits.  Programs
      should be allowed to submit URBs as large as they like; if there isn't
      sufficient contiguous memory available then the submission will fail
      with a simple ENOMEM error.
      
      On the other hand, we would like to prevent programs from submitting a
      lot of small URBs and using up all the DMA-able kernel memory.  To
      that end, this patch (as1497) replaces the old limits on individual
      transfer buffers with a single global limit on the total amount of
      memory in use by usbfs.  The global limit is set to 16 MB as a nice
      compromise value: not too big, but large enough to hold about 300 ms
      of data for high-speed transfers.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      add1aaea
    • Alan Stern's avatar
      USB: unify some error pathways in usbfs · 52fb743d
      Alan Stern authored
      
      
      This patch (as1496) unifies the error-return pathways of several
      functions in the usbfs driver.  This is not a very important change by
      itself; it merely prepares the way for the next patch in this series.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      52fb743d
  23. 29 Sep, 2011 1 commit
    • Serge Hallyn's avatar
      user namespace: usb: make usb urbs user namespace aware (v2) · d178bc3a
      Serge Hallyn authored
      
      
      Add to the dev_state and alloc_async structures the user namespace
      corresponding to the uid and euid.  Pass these to kill_pid_info_as_uid(),
      which can then implement a proper, user-namespace-aware uid check.
      
      Changelog:
      Sep 20: Per Oleg's suggestion: Instead of caching and passing user namespace,
      	uid, and euid each separately, pass a struct cred.
      Sep 26: Address Alan Stern's comments: don't define a struct cred at
      	usbdev_open(), and take and put a cred at async_completed() to
      	ensure it lasts for the duration of kill_pid_info_as_cred().
      Signed-off-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      d178bc3a
  24. 26 Sep, 2011 2 commits
  25. 23 Mar, 2011 1 commit
  26. 17 Nov, 2010 1 commit
  27. 11 Nov, 2010 1 commit