File Permissions for exported GPIO pins changed in Kernel 4.1.6 #1117

herbertkoenig · 2015-08-24T11:44:17Z

Hi,

before my latest update, when exporting a GPIO pin like:
echo 17 > /sys/class/gpio/export
the file /sys/class/gpio/gpio17/direction
would be read/writeable by owner root and group gpio. Same holds for the value file and the gpio17 folder.

In the 4.1.6 kernel this has changed as follows:
The gpio17 folder can be read an written by everyone.
The file /sys/class/gpio/gpio17/direction is now owned by root and in group root (not gpio) and is readable by everyone and changeable only by the owner. Same for the value file.

old kernel:
Linux herpi1 3.18.11+ #781 PREEMPT Tue Apr 21 18:02:18 BST 2015 armv6l GNU/Linux
new kernel:
Linux herpi4 4.1.6+ #810 PREEMPT Tue Aug 18 15:19:58 BST 2015 armv6l GNU/Linux

popcornmix · 2015-08-24T14:32:46Z

Looks like something may have changed in the later kernel where
/sys/devices/soc/*.gpio/gpio is now /sys/devices/platform/soc/*.gpio/gpio

Can you try editing:
/lib/udev/rules.d/60-python-pifacecommon.rules and
/lib/udev/rules.d/60-python3-pifacecommon.rules (if they both exist) to be:

KERNEL=="spidev*", GROUP="spi", MODE="0660"
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys/devices/platform/soc/*.gpio/gpio && chmod -R 770 /sys/devices/platform/soc/*.gpio/gpio'"

Reboot and report back if that fixes it.

herbertkoenig · 2015-08-24T15:07:30Z

Hi,

seems to work, I'll report back with more detail soon.

Thanks,

Herbert

Am 24.08.2015 um 16:33 schrieb popcornmix:

Looks like something may have changed in the later kernel where
|/sys/devices/soc/.gpio/gpio| is now
|/sys/devices/platform/soc/.gpio/gpio|

Can you try editing:
|/lib/udev/rules.d/60-python-pifacecommon.rules| and
|/lib/udev/rules.d/60-python3-pifacecommon.rules| (if they both exist)
to be:

|KERNEL=="spidev_", GROUP="spi", MODE="0660" SUBSYSTEM=="gpio_",
PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R
770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio &&
chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio
/sys/devices/platform/soc/.gpio/gpio && chmod -R 770
/sys/devices/platform/soc/.gpio/gpio'" |

Reboot and report back if that fixes it.

—
Reply to this email directly or view it on GitHub
#1117 (comment).

herbertkoenig · 2015-08-24T15:54:12Z

Hi,

I can confirm the fix solves my problem.

The differences in the file permissions of the folder
/sys/class/gpio/gpio17
I thought I still spotted were due to me misinterpreting the slightly
changed file permissions dialog in the new kernel.

Thanks for the fix, I'll report it in the Raspi Forum where I initially
raised the topic.

https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=118879

Cheers,

Herbert

Am 24.08.2015 um 16:33 schrieb popcornmix:

Looks like something may have changed in the later kernel where
|/sys/devices/soc/.gpio/gpio| is now
|/sys/devices/platform/soc/.gpio/gpio|

Can you try editing:
|/lib/udev/rules.d/60-python-pifacecommon.rules| and
|/lib/udev/rules.d/60-python3-pifacecommon.rules| (if they both exist)
to be:

|KERNEL=="spidev_", GROUP="spi", MODE="0660" SUBSYSTEM=="gpio_",
PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R
770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio &&
chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio
/sys/devices/platform/soc/.gpio/gpio && chmod -R 770
/sys/devices/platform/soc/.gpio/gpio'" |

Reboot and report back if that fixes it.

—
Reply to this email directly or view it on GitHub
#1117 (comment).

mauritslamers · 2015-10-09T10:18:55Z

I found that after upgrading to Raspian jessie the udev rules files mentioned above did not exist. Creating the first one and then doing a restart solved the issue.

popcornmix · 2015-10-09T12:02:54Z

@mauritslamers
How did you upgrade? Clean install or by changing apt sources and dist upgrade?
On a clean jessie image the permissions seem okay to me.

christophfroehlich · 2015-10-09T20:14:06Z

I updated via apt-get upgrade to 4.1.7+ and had the same problem. fixing 60-python-pifacecommon.rules did work for me.

mauritslamers · 2015-10-09T21:47:17Z

@popcornmix I upgraded by changing apt sources and then running an apt-get dist-upgrade.

popcornmix · 2015-10-10T12:18:50Z

I think you'll probably have to manually edit if you manually upgraded, but @XECDesign can confirm if an upgrade path is planned.
A clean install of jessie should have the correct udev rules.

mauritslamers · 2015-10-11T21:00:18Z

@popcornmix In order to edit, the file should exist in the first place. In my case it didn't, but creating it, adding the content as mentioned above fixed the problem of not being able to use the GPIO as the pi user.

XECDesign · 2015-10-12T11:03:38Z

I'm not sure that an upgrade path is planned for this particular issue. It would still require the user to install a package which would handle such things. However, we can create a raspberrypi-sys-mods package for future releases.

rpakdel · 2015-10-13T15:49:46Z

FYI, I did a clean install of Raspbian Jessie from https://www.raspberrypi.org/downloads/raspbian/ last week.

The permissions don't work (Node.js gpio access gives permission error when not run as root). The udev rules files also don't exist. I've added the files manually (copied from my working Wheezy install) and rebooted but they're still not working (I gave up quickly).

XECDesign · 2015-10-13T16:32:16Z

People looking at /lib/udev/rules.d/ and assuming the files are missing are looking in the wrong place.

The rules are in /etc/udev/rules.d/99-com.rules

I don't know anything about node.js or what exact method you're using to access GPIO. Perhaps it's a /dev/mem mmap method which will always need root?

rpakdel · 2015-10-14T12:00:32Z

Thanks for pointing me to the right direction. The 99-com.rules file is missing setting the group permissions on /sys/devices/soc. Appending the line below to PROGRAM fixes this

chown -R root:gpio /sys/devices/soc/*.gpio/gpio && chmod -R 770 /sys/devices/soc/*.gpio/gpio

Test:

pi@raspberrypi /sys/class/gpio $ ls -la
total 0
drwxrwx--- 2 root gpio 0 Oct 14 04:56 .
drwxr-xr-x 38 root root 0 Oct 14 04:46 ..
-rwxrwx--- 1 root gpio 4096 Oct 14 04:51 export
lrwxrwxrwx 1 root gpio 0 Oct 11 09:17 gpiochip0 -> ../../devices/soc/20200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Oct 14 04:56 unexport

pi@raspberrypi /sys/class/gpio $ echo 17 > export
pi@raspberrypi /sys/class/gpio $ ls -la gpio17/
total 0
drwxrwx--- 3 root gpio 0 Oct 14 04:56 .
drwxrwx--- 4 root gpio 0 Oct 14 04:56 ..
-rwxrwx--- 1 root gpio 4096 Oct 14 04:56 active_low
lrwxrwxrwx 1 root gpio 0 Oct 14 04:56 device -> ../../../20200000.gpio
-rwxrwx--- 1 root gpio 4096 Oct 14 04:56 direction
-rwxrwx--- 1 root gpio 4096 Oct 14 04:56 edge
drwxrwx--- 2 root gpio 0 Oct 14 04:56 power
lrwxrwxrwx 1 root gpio 0 Oct 14 04:56 subsystem -> ../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Oct 14 04:56 uevent
-rwxrwx--- 1 root gpio 4096 Oct 14 04:56 value

XECDesign · 2015-10-14T12:07:45Z

@rpakdel What does uname -a say?

rpakdel · 2015-10-14T12:23:55Z

Linux raspberrypi 3.18.0-trunk-rpi #1 PREEMPT Debian 3.18.5-1~exp1+rpi19 (2015-08-08) armv6l GNU/Linux

I had to switch to the Debian kernel so that I could compile USB wifi module. I wasn't about to try to get the 4.1.7 headers. Sorry.

XECDesign · 2015-10-14T13:29:05Z

Ah, then it's not supported here and isn't an issue as far as Raspbian's maintainer is concerned either. The reason this issue was raised was because the necessary rules changed with the move to 4.1.

jsiei97 · 2015-11-15T08:21:30Z

To sum up what the current state:

On 2015-05-05-raspbian-wheezy.zip using default kernel
Linux regulator 4.1.7+ #817 PREEMPT Sat Sep 19 15:25:36 BST 2015 armv6l GNU/Linux

Export works (since group is gpio)

cj@regulator ~ $ echo 27 > /sys/class/gpio/export
cj@regulator ~ $ ls -lh /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4.0K nov 15 09:02 export
lrwxrwxrwx 1 root gpio    0 nov 15 09:01 gpio27 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio27
lrwxrwxrwx 1 root gpio    0 jan  1  1970 gpiochip0 -> ../../devices/platform/soc/20200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4.0K nov 15 09:04 unexport

But when I look at the direction file, it is not ok, since it was created with group root.

cj@regulator ~ $ echo "out" > /sys/class/gpio/gpio27/direction
-bash: /sys/class/gpio/gpio27/direction: Permission denied
cj@regulator ~ $ ls -lh /sys/devices/platform/soc/20200000.gpio/gpio/gpio27
total 0
-rw-r--r-- 1 root root 4.0K nov 15 09:02 active_low
lrwxrwxrwx 1 root root    0 nov 15 09:02 device -> ../../../20200000.gpio
-rw-r--r-- 1 root root 4.0K nov 15 09:02 direction
-rw-r--r-- 1 root root 4.0K nov 15 09:02 edge
lrwxrwxrwx 1 root root    0 nov 15 09:02 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4.0K nov 15 09:02 uevent
-rw-r--r-- 1 root root 4.0K nov 15 09:02 value

So the default installation is broken and needs to be fixed.

Then on this system there is 3 files that does almost does the same thing.

/etc/udev/rules.d/99-com.rules
/lib/udev/rules.d/60-python-pifacecommon.rules
/lib/udev/rules.d/60-python3-pifacecommon.rules

@XECDesign from this point what was the recommended fix? Since @rpakdel was using a non default kernel this issue seems to be paused?

rpakdel · 2015-11-15T09:13:56Z

Coincidentally my SD card got corrupted and I reinstalled Raspian Jessie image with the Raspian kernel (no changes. I gave up on compiling wifi drivers). Export of GPIO pins as non-root works fine.

XECDesign · 2015-11-15T09:40:14Z

There are 2 separate issues here:

The paths have changed between the kernel versions
The custom udev rules don't currently belong to a package. They're just put there when creating the image. This means that they can't be updated automatically.

rpkadel was running into 1. @jsiei97, you're running into 2. The solution for that was given in the forum thread (https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=118879#p828766)

dlech · 2015-11-15T21:10:40Z

I would say that the issue 1) is not that the paths have changed - that is compliant with sysfs-rules.txt.

Position of devices along device chain can change.

Rather the issue is that the udev rules chooses to ignore the advice from sysfs-rules.txt.

Here is a udev rule that I came up with that does the same sort of thing. It uses the $devpath udev variable instead of explicitly specifying the path (which may change). https://github.com/ev3dev/ev3dev-rules/blob/ev3dev-jessie/debian/ev3dev-rules.ev3dev.udev

So, I think that this issue with regard to the kernel is invalid and can be closed.

XECDesign · 2015-11-15T21:13:32Z

thanks, that rule seems promising.

blubberblase · 2016-02-25T14:28:23Z

hey guys,

I recently did an $ apt-get update and $ apt-get upgrade
and I also somehow destroied my file, which was using the gpio "on/off"-module (which was working fine before).
So I tried make my setting's for using it again.
But I always run in an Error when I try to use the .write(..) function.

[Error: EPERM: operation not permitted, write] errno: -1, code: 'EPERM', syscall: 'write'

I check and only found this rules-document /etc/udev/rules.d/99-com.rules
which says
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys/devices/platform/soc/*.gpio/gpio && chmod -R 770 /sys/devices/platform/soc/*.gpio/gpio'" UBSYSTEM=="input", GROUP="input", MODE="0660" SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0660" SUBSYSTEM=="spidev", GROUP="spi", MODE="0660" SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"

I compared it with what you haven written here, but could find the difference.
And nop, on my system is no "/sys/devices/soc/*.gpio/gpio" path. so I didn't added this staff.

so can someone tell me what am I doing wrong or what I am missing?

XECDesign · 2016-03-24T08:28:16Z

The latest raspberrypi-ui-mods package uses $devpath. I haven't tested on 3.18 kernel, but it should work. Okay to close?

deadprogram · 2017-04-01T15:58:10Z

Seems like this problem still exists on the latest released Jessie Lite v4.4, from my testing.

Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov %rdx,%rsi f: 48 29 d0 sub %rdx,%rax 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl $0x3,%rax 1d: 48 01 c2 add %rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle 0xffffffffffffffe7 27: 48 8b 3a mov (%rdx),%rdi 2a:* 4c 8b 07 mov (%rdi),%r8 <-- trapping instruction 2d: 4c 89 02 mov %r8,(%rdx) 30: 49 89 50 08 mov %rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (bad) ... Code starting with the faulting instruction =========================================== 0: 4c 8b 07 mov (%rdi),%r8 3: 4c 89 02 mov %r8,(%rdx) 6: 49 89 50 08 mov %rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (bad) ... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] <TASK> [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_generic.c:1036) [ 88.810950] tbf_reset (./include/linux/timekeeping.h:169 net/sched/sch_tbf.c:334) sch_tbf [ 88.811208] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_generic.c:1036) [ 88.811484] netif_set_real_num_tx_queues (./include/linux/spinlock.h:396 ./include/net/sch_generic.h:768 net/core/dev.c:2958) [ 88.811870] __tun_detach (drivers/net/tun.c:590 drivers/net/tun.c:673) [ 88.812271] tun_chr_close (drivers/net/tun.c:702 drivers/net/tun.c:3517) [ 88.812505] __fput (fs/file_table.c:432 (discriminator 1)) [ 88.812735] task_work_run (kernel/task_work.c:230) [ 88.813016] do_exit (kernel/exit.c:940) [ 88.813372] ? trace_hardirqs_on (kernel/trace/trace_preemptirq.c:58 (discriminator 4)) [ 88.813639] ? handle_mm_fault (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/memcontrol.h:1022 ./include/linux/memcontrol.h:1045 ./include/linux/memcontrol.h:1052 mm/memory.c:5928 mm/memory.c:6088) [ 88.813867] do_group_exit (kernel/exit.c:1070) [ 88.814138] __x64_sys_exit_group (kernel/exit.c:1099) [ 88.814490] x64_sys_call (??:?) [ 88.814791] do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) [ 88.815012] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) [ 88.815495] RIP: 0033:0x7f44560f1975 Fixes: 175f9c1 ("net_sched: Add size table for qdiscs") Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Link: https://patch.msgid.link/20241007184130.3960565-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>

fivdi mentioned this issue Sep 9, 2015

permission denied fivdi/onoff#3

Closed

XECDesign closed this as completed Apr 8, 2016

thomaspasser mentioned this issue Jul 17, 2016

GPIO pin permission fix volumio/Build#75

Merged

pvizeli mentioned this issue Sep 30, 2017

Running addons with --privileged home-assistant/supervisor#201

Closed

imbashamba mentioned this issue Jun 1, 2018

Kernel oops or hard freeze when streaming video on Zero W (and Pi 3B+) #2555

Open

gourry mentioned this issue Jun 6, 2018

Kernel panic on Raspberry PI 3 B+ #2576

Closed

gourry mentioned this issue Jun 8, 2018

Network driver on RPi3 B Plus causing hung tasks when working on an NFS mount #2482

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

File Permissions for exported GPIO pins changed in Kernel 4.1.6 #1117

File Permissions for exported GPIO pins changed in Kernel 4.1.6 #1117

herbertkoenig commented Aug 24, 2015

popcornmix commented Aug 24, 2015

herbertkoenig commented Aug 24, 2015

herbertkoenig commented Aug 24, 2015

mauritslamers commented Oct 9, 2015

popcornmix commented Oct 9, 2015

christophfroehlich commented Oct 9, 2015

mauritslamers commented Oct 9, 2015

popcornmix commented Oct 10, 2015

mauritslamers commented Oct 11, 2015

XECDesign commented Oct 12, 2015

rpakdel commented Oct 13, 2015

XECDesign commented Oct 13, 2015

rpakdel commented Oct 14, 2015

XECDesign commented Oct 14, 2015

rpakdel commented Oct 14, 2015

XECDesign commented Oct 14, 2015

jsiei97 commented Nov 15, 2015

rpakdel commented Nov 15, 2015

XECDesign commented Nov 15, 2015

dlech commented Nov 15, 2015

XECDesign commented Nov 15, 2015

blubberblase commented Feb 25, 2016

XECDesign commented Mar 24, 2016

deadprogram commented Apr 1, 2017

File Permissions for exported GPIO pins changed in Kernel 4.1.6 #1117

File Permissions for exported GPIO pins changed in Kernel 4.1.6 #1117

Comments

herbertkoenig commented Aug 24, 2015

popcornmix commented Aug 24, 2015

herbertkoenig commented Aug 24, 2015

herbertkoenig commented Aug 24, 2015

mauritslamers commented Oct 9, 2015

popcornmix commented Oct 9, 2015

christophfroehlich commented Oct 9, 2015

mauritslamers commented Oct 9, 2015

popcornmix commented Oct 10, 2015

mauritslamers commented Oct 11, 2015

XECDesign commented Oct 12, 2015

rpakdel commented Oct 13, 2015

XECDesign commented Oct 13, 2015

rpakdel commented Oct 14, 2015

XECDesign commented Oct 14, 2015

rpakdel commented Oct 14, 2015

XECDesign commented Oct 14, 2015

jsiei97 commented Nov 15, 2015

rpakdel commented Nov 15, 2015

XECDesign commented Nov 15, 2015

dlech commented Nov 15, 2015

XECDesign commented Nov 15, 2015

blubberblase commented Feb 25, 2016

XECDesign commented Mar 24, 2016

deadprogram commented Apr 1, 2017