00:29
fonz93 has quit [Remote host closed the connection]
01:21
ValicekB has quit [Ping timeout: 276 seconds]
01:21
ValicekB has joined #huawei-g300
01:54
subz3r0 has quit [Ping timeout: 256 seconds]
02:02
subz3r0 has joined #huawei-g300
02:02
subz3r0 has joined #huawei-g300
02:08
subz3r0 has quit [Ping timeout: 256 seconds]
02:14
subz3r0 has joined #huawei-g300
02:14
subz3r0 has joined #huawei-g300
03:09
subz3r0 has quit [Ping timeout: 256 seconds]
03:38
subz3r0 has joined #huawei-g300
03:58
subz3r0 has quit [Ping timeout: 256 seconds]
04:16
subz3r0 has joined #huawei-g300
04:42
subz3r0 has quit [Ping timeout: 256 seconds]
04:50
subz3r0 has joined #huawei-g300
04:50
subz3r0 has joined #huawei-g300
05:01
subz3r0 has quit [Ping timeout: 256 seconds]
05:16
subz3r0 has joined #huawei-g300
05:31
subz3r0 has quit [Ping timeout: 256 seconds]
05:38
subz3r0 has joined #huawei-g300
05:41
gregor160300 has joined #huawei-g300
06:42
moeter15 has joined #huawei-g300
06:43
moeter14 has quit [Ping timeout: 250 seconds]
07:14
fonz93 has joined #huawei-g300
07:26
<
fonz93 >
Dazzozo: we have selinux set to permissive right? why dmesg still shows some avc denial errors?
07:26
<
fonz93 >
there are many
07:26
<
fonz93 >
this is an example
07:26
<
fonz93 >
avc: denied { read write } for path="/dev/kgsl-3d0" dev="tmpfs" ino=3592 scontext=u:r:system_server:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
07:26
<
Dazzozo >
i suggest you read up on what permissive does :P
07:27
<
fonz93 >
so i shouldn't care about this error?
07:28
<
Dazzozo >
its not an error, its debug
07:28
<
Dazzozo >
if it was enforcing, it would be an error
07:28
<
Dazzozo >
its designed so you can fix up your sepolicy before you switch to enforcing
07:29
<
fonz93 >
oh so it's from there that all take sepolicies
07:29
<
Dazzozo >
if you switch to enforcing, you will crash the system
07:29
<
fonz93 >
i won't ahahahahaha
07:29
<
Dazzozo >
because of those warnings
07:30
<
Dazzozo >
it'll start blocking things that are system critical
07:30
<
Dazzozo >
without a proper sepolicy
07:30
<
Dazzozo >
and if you boot with enforcing it won't get very far
07:31
<
fonz93 >
i am pretty satisfied in the current state of cm12.1 anyway
08:18
<
luca020400 >
fonz93 : the call bug got fixed ?
08:34
<
luca020400 >
So everything was due a "fix" :p
08:35
luca020400 has joined #huawei-g300
09:13
<
fonz93 >
i have found the real reason of why the wifi issue happens
09:13
<
fonz93 >
maybe also the fix
09:14
<
luca020400 >
????????????????????????
09:15
<
fonz93 >
i have found a bug report
09:16
<
fonz93 >
they suggested to increase min_free_kbytes as a workaround until they update the kernel
09:16
<
Dazzozo >
its a fucking page allocation failure? we had one of those with the g300 module
09:16
<
fonz93 >
and the bug "disappeared"
09:16
<
fonz93 >
so i may need to follow their real fix
09:16
<
fonz93 >
instead of increasing min free kbytes
09:16
<
fonz93 >
there are common dmesg errors
09:16
<
luca020400 >
so kernel fault
09:16
<
luca020400 >
huawei
09:17
<
fonz93 >
witksdioirqd/mmc2: page allocation failure: order:0, mode:0x20
09:17
<
fonz93 >
and slub allocation failure
09:18
<
fonz93 >
what was happening on u8815 when getting the allocation failure?
09:19
<
Dazzozo >
9 times out of 10 it would hang the entire system for about a minute and then some watchdog would kick in and reboot it
09:19
<
Dazzozo >
and 1/10 of the time it would give us some crash output in dmesg
09:19
<
Dazzozo >
and then crash the system immediately
09:19
gregor160300 has quit [Ping timeout: 256 seconds]
09:19
<
fonz93 >
ok that's similar to the current situation
09:19
<
fonz93 >
i'll try that now
09:20
<
Dazzozo >
not the kernel
09:21
<
fonz93 >
oh yes thanks
09:22
<
fonz93 >
that issue can cause also swap errors right?
09:22
<
Dazzozo >
probably?
09:22
<
Dazzozo >
i mean, i guess
09:22
<
Dazzozo >
this isn't really a "fix"
09:22
<
Dazzozo >
but it was more reliable than fucking with min_free_kbytes
09:23
<
luca020400 >
*workaround everywhere*
09:23
<
Dazzozo >
as in: it stopped the crashing, which was good enough at the time
09:23
<
Dazzozo >
pretty much
09:23
<
fonz93 >
this is the other error that appears in dmesg: SLUB: Unable to allocate memory on node -1
09:26
Ghost|afk is now known as Shadowghoster
10:11
<
fonz93 >
the bug is evolvev now
10:12
<
fonz93 >
if you try to download a file
10:12
<
fonz93 >
the download stops and in dmesg appears the same allocation error
10:12
<
fonz93 >
but the wi-fi doesn't stop to work
10:13
<
fonz93 >
so the wi-fi issue is fixed but the allocation error not
10:13
<
luca020400 >
so try to chnge sysctl
10:13
<
fonz93 >
it's a bad solution because of our low RAM
10:13
<
luca020400 >
yes just try :p
10:14
<
Dazzozo >
to be fair
10:14
<
fonz93 >
i already did
10:14
<
Dazzozo >
android is a bad solution for that device
10:14
<
fonz93 >
and the bug is fixed but the system became really laggy
10:14
<
fonz93 >
yes Dazzozo you're right :P
10:20
<
fonz93 >
what ksdioirqd/mmc2 is?
10:24
<
Dazzozo >
fonz93: if i was to guess
10:24
<
Dazzozo >
kernel sdio interrupt request daemon?
10:27
<
Dazzozo >
wifi crap is often on an mmc bus
10:28
<
fonz93 >
just tried to debug again
10:28
<
fonz93 >
and the wifi issue happened
10:28
<
fonz93 >
spamming this like hell ksdioirqd/mmc2: page allocation failure: order:0, mode:0x20
10:29
<
fonz93 >
within all of the swap device errors lol
10:30
<
fonz93 >
it also gives me this
10:30
<
fonz93 >
<4>[ 572.528063] [<c0015494>] (unwind_backtrace+0x0/0x138) from [<c06da638>] (dump_stack+0x18/0x1c)
10:30
<
fonz93 >
<4>[ 572.528084] [<c06da638>] (dump_stack+0x18/0x1c) from [<c01403ec>] (warn_alloc_failed+0xec/0x124)
10:30
<
fonz93 >
<4>[ 572.528108] [<c01403ec>] (warn_alloc_failed+0xec/0x124) from [<c0140ac0>] (__alloc_pages_nodemask+0x608/0x7f4)
10:30
<
fonz93 >
<4>[ 572.528131] [<c0140ac0>] (__alloc_pages_nodemask+0x608/0x7f4) from [<c017f03c>] (new_slab+0x298/0x2a8)
10:30
<
fonz93 >
<4>[ 572.528154] [<c017f03c>] (new_slab+0x298/0x2a8) from [<c06dd9dc>] (__slab_alloc.isra.49.constprop.56+0x3cc/0x59c)
10:30
<
fonz93 >
<4>[ 572.528179] [<c06dd9dc>] (__slab_alloc.isra.49.constprop.56+0x3cc/0x59c) from [<c0181b6c>] (__kmalloc_track_caller+0xfc/0x1c0)
10:30
<
fonz93 >
<4>[ 572.528204] [<c0181b6c>] (__kmalloc_track_caller+0xfc/0x1c0) from [<c057790c>] (__alloc_skb+0x5c/0x104)
10:31
<
fonz93 >
<4>[ 572.528228] [<c057790c>] (__alloc_skb+0x5c/0x104) from [<c0577b04>] (dev_alloc_skb+0x20/0x44)
10:31
<
fonz93 >
<4>[ 572.528288] [<c0577b04>] (dev_alloc_skb+0x20/0x44) from [<bf0469f8>] (ath6kl_buf_alloc+0x14/0x38 [ar6000])
10:31
<
fonz93 >
<4>[ 572.528364] [<bf0469f8>] (ath6kl_buf_alloc+0x14/0x38 [ar6000]) from [<bf04dabc>] (ath6kl_rx_refill+0x60/0x114 [ar6000])
10:31
<
fonz93 >
<4>[ 572.528434] [<bf04dabc>] (ath6kl_rx_refill+0x60/0x114 [ar6000]) from [<bf03dc80>] (ath6kl_htc_rxmsg_pending_handler+0xd74/0xf20 [ar6000])
10:31
<
fonz93 >
<4>[ 572.528501] [<bf03dc80>] (ath6kl_htc_rxmsg_pending_handler+0xd74/0xf20 [ar6000]) from [<bf03a7c4>] (ath6kl_hif_intr_bh_handler+0x2f8/0x690 [ar6000])
10:31
<
fonz93 >
<4>[ 572.528571] [<bf03a7c4>] (ath6kl_hif_intr_bh_handler+0x2f8/0x690 [ar6000]) from [<bf0560f0>] (ath6kl_sdio_irq_handler+0x48/0xac [ar6000])
10:31
<
fonz93 >
<4>[ 572.528619] [<bf0560f0>] (ath6kl_sdio_irq_handler+0x48/0xac [ar6000]) from [<c051995c>] (sdio_irq_thread+0x208/0x39c)
10:31
<
fonz93 >
<4>[ 572.528644] [<c051995c>] (sdio_irq_thread+0x208/0x39c) from [<c00c9d5c>] (kthread+0x98/0x9c)
10:31
<
fonz93 >
<4>[ 572.528668] [<c00c9d5c>] (kthread+0x98/0x9c) from [<c0010284>] (kernel_thread_exit+0x0/0x8)
10:31
<
fonz93 >
it should be a backtrace?
10:31
<
Dazzozo >
ye, it is one
10:32
<
Dazzozo >
looks like ath6kl is allocating something itself?
10:32
<
Dazzozo >
and its choking on that
10:36
<
Dazzozo >
though, i don't know why this is going fatal
10:36
<
Dazzozo >
surely if the kernel can't allocate the memory it should kindly tell the requesting code to fuck off
10:36
<
Dazzozo >
and not die deep in alloc code
10:41
<
fonz93 >
weird things happen on this device
10:44
<
Dazzozo >
really, you shouldnt have to hack every allocation, because this issue will extend to other subsystems too
10:44
<
Dazzozo >
and you would be there all year
10:44
<
Dazzozo >
there's either some obvious misconfiguration or the kernel is very broken
10:48
<
fonz93 >
what if i add some code that cleares the atkh6l buffer before it gets full?
10:51
<
fonz93 >
what about this? just finding slub allocator commits in the kernel...
10:52
<
Dazzozo >
well, it could be anything, if you've changed the allocator you're using
10:52
<
Dazzozo >
try reverting it back to the original code
10:52
<
Dazzozo >
if the issue was there from CAF then that's going to be fun
10:53
<
Dazzozo >
im preeeetty sure the move to 3.4 fixed the issue with the G300
10:53
<
Dazzozo >
and I didn't need to hack it anymore
10:53
<
fonz93 >
well the kernel is a chil360-kernel fork
10:53
<
Dazzozo >
so it might be something you guys introduced
10:54
<
fonz93 >
changes on slub were introduced by that commit i linked and some others to update the kernel on 3.4.y versions
10:54
<
luca020400 >
so add chil360 patches to huawei kernel :p
10:55
<
fonz93 >
450+ commits :(
10:55
<
luca020400 >
not that difficult
10:55
<
fonz93 >
i think that he tried to do that already anyway
10:55
<
luca020400 >
I will do that
10:55
<
luca020400 >
squash
10:56
<
Dazzozo >
just restore slub to how it was in my 3.4 kernel
10:56
<
Dazzozo >
i don't think i modified it
10:56
<
fonz93 >
ok i'll try it right now
10:56
<
luca020400 >
90 kb/s
10:56
<
luca020400 >
download
10:56
<
Dazzozo >
yeah i didnt
10:57
<
luca020400 >
he did
11:01
<
luca020400 >
80000 lines of patch
11:04
<
fonz93 >
did you include KSGSL/ION/framebuffer patches only?
11:18
<
luca020400 >
seems like
11:18
<
luca020400 >
diff from a162fdd8e68b1e2aaafbc5f03df24aa4a8041961..7f517c19434902f6071d0a37f54ebe55c76f52ca
11:19
<
Dazzozo >
da fak is this
11:19
<
luca020400 >
gitignore is weird
11:23
<
luca020400 >
inverted patch xd
11:25
<
fonz93 >
just reverte slub to caf
11:25
<
fonz93 >
didn't solve the issue
11:31
<
fonz93 >
so what that diff contain?
11:39
<
luca020400 >
is broken xd
11:41
<
fonz93 >
no swap errors while using mobile data
11:42
<
fonz93 >
so i suppose the slub allocator goes crazy using wifi only
11:42
<
fonz93 >
no wait i didn't enalbe zRAM lol
12:07
<
fonz93 >
yes it happens only with wifi enabled
12:07
<
fonz93 >
oh god no it doesn't
12:14
<
luca020400 >
mobile data too ?
12:18
<
fonz93 >
also without any data
12:18
<
fonz93 >
switching between apps causes the swap error
12:29
<
luca020400 >
fonz93 : can you shut up users asking wifi fix ? thanks :p
12:51
gregor160300 has joined #huawei-g300
12:53
<
rymate1234 >
luca020400, you can't shut up used
12:54
<
rymate1234 >
you can ignore them until wifi is fixed
12:54
<
Dazzozo >
rymate1234: oh shit
12:54
<
Dazzozo >
theyre trying to make my hobby illegal
12:54
<
Dazzozo >
literally
12:54
<
Dazzozo >
3ds stuff in here
12:54
<
Dazzozo >
in the exhibits
12:58
<
rymate1234 >
Dazzozo, why is it that america hates fun
12:59
<
gregor160300 >
Dazzozo do you know why there is only one member left in androidarmv6 since you were also a member
13:01
<
Dazzozo >
fuck knows whats going on with them, i havent been affiliated with them for years
13:02
<
Dazzozo >
i figured the project was pretty dead?
13:02
<
Dazzozo >
what's your interest with them?
13:02
<
Dazzozo >
there were a lot more people at some point
13:02
<
Dazzozo >
either they were all kicked or they all left
13:02
<
Dazzozo >
and if they were all kicked i probably should've been kicked too
13:03
<
Dazzozo >
yeah, 3 people with private membership
13:03
<
Dazzozo >
you have to optionally publicise membership on github
13:03
<
gregor160300 >
But last week I saw more members not private
13:03
<
rymate1234 >
gregor160300, get with the times
13:03
<
rymate1234 >
all about the armv7 rpi2
13:04
<
gregor160300 >
I am still about armv6 one
13:04
<
rymate1234 >
i have the armv7 one
13:04
<
rymate1234 >
highly superior
13:04
<
Dazzozo >
honestly, i don't really know, you can basically consider me nothing to do with them
13:04
<
Dazzozo >
there was a brief period back in the 4.1 days
13:05
<
Dazzozo >
and thats when the project really sort of "existed"
13:05
<
gregor160300 >
I know you are with 3ds
13:05
<
Dazzozo >
well, that's before i started 3ds stuff
13:05
<
Dazzozo >
like, they still have their gerrit...
13:06
<
Dazzozo >
so i guess there's still some interest in it
13:06
<
gregor160300 >
I know but is there anything like it on github or so with cm 11 and cm 12 and androidarmv6 support
13:06
<
Dazzozo >
you'll struggle...
13:07
<
Dazzozo >
armv6 really should've died wrt android like 2+ years ago
13:07
<
gregor160300 >
Yes but I still need armv6 for rpi, I want android on it
13:07
<
Dazzozo >
i mean in here these guys are struggling getting armv7 devices to run android properly
13:07
<
Dazzozo >
well if you want it be prepared to put the work in ;)
13:08
<
Dazzozo >
you're probably not going to find somewhere that hands you that in a platter
13:08
<
gregor160300 >
I am prepared I found some good starts
13:08
<
rymate1234 >
gregor160300, easiest way is to not port the latest android on rpi
13:08
<
rymate1234 >
ice cream sandwich might be a good thing to start with
13:08
<
gregor160300 >
I am working on cm 11
13:08
<
gregor160300 >
I compiled razdroid but it didnt work and installation is too hard
13:09
<
Dazzozo >
honestly there might be small chance of getting gingerbread to go
13:09
<
Dazzozo >
if that doesnt already exist
13:09
<
gregor160300 >
It exists it is razdroid
13:09
<
rymate1234 >
CyanogenMOD 7.2 (based on Android 2.3): Boots, very slow, barely usable. (unstable)
13:09
<
gregor160300 >
But I couldnt install it properly
13:09
<
Dazzozo >
yeah... then no
13:10
<
gregor160300 >
I mostly use trevd on github and mozilla-b2g
13:10
<
Dazzozo >
at some point someone needs to realise its not capable
13:10
<
Dazzozo >
it also has no vendor support for android
13:10
<
rymate1234 >
gregor160300, your main issue is there's no hardware accelerated drivers for the Pi that work with android
13:10
<
gregor160300 >
It is capable but it requires a lot of work
13:10
<
Dazzozo >
no, it isnt
13:10
<
Dazzozo >
for reasons outside of the device itself
13:10
<
rymate1234 >
gregor160300, do you know how to write a graphics driver?
13:11
<
rymate1234 >
Framebuffer issues: possibly due to the lack of double buffering and/or page flipping in the bcm2708 framebuffer driver
13:11
<
rymate1234 >
Proper libEGL library not present: libraries
*are* available, but those are linked against glibc instead of android's bionic libc (issue filed here)
13:11
<
rymate1234 >
UI Crashes
13:11
<
gregor160300 >
There was someone with hw accelerated ics, so I mailed and asked for the sources
13:11
<
Dazzozo >
alternatively, you could buy a phone
13:11
<
gregor160300 >
I first need to build cm 11 properly and the I will see further
13:11
<
gregor160300 >
I have a phone moto g 2014
13:11
<
rymate1234 >
use that for android
13:12
<
rymate1234 >
android isn't really meant for a device like the raspberry pu
13:12
<
gregor160300 >
I don´t know what to use my pi for then
13:12
<
gregor160300 >
A webserver is too slow
13:13
<
rymate1234 >
well I have two
13:13
<
rymate1234 >
the armv7 rpi works exceptionally well as a web server
13:13
<
gregor160300 >
I could sell my B+ and buy B 2
13:13
<
rymate1234 >
the armv6 one I have is a pretty good print server
13:14
<
rymate1234 >
gregor160300, could use your armv6 one as a media centre
13:14
<
rymate1234 >
xbmc works quite well
13:14
<
gregor160300 >
I dont need a media centre
13:15
<
rymate1234 >
gregor160300, why did you buy it in the first place if you don't know what to do with it
13:15
<
Dazzozo >
i got one for free from my uni B)
13:15
<
Dazzozo >
>for free
13:15
<
Dazzozo >
£9000 a year
13:15
<
rymate1234 >
sounds like ur getting value for money Dazzozo
13:16
<
Dazzozo >
frankly i expect to be dead before i'll be concerned with paying that back so
13:17
TheFallingOne has joined #huawei-g300
13:46
TheFallingOne has joined #huawei-g300
13:46
TheFallingOne has quit [Client Quit]
14:00
<
fonz93 >
is he drunk?
14:01
<
luca020400 >
he's the community manager
14:22
gregor160300 has quit [Quit: Leaving]
14:24
gregor160300 has joined #huawei-g300
14:58
gregor160300 has quit [Quit: Leaving]
15:19
sunnyden has joined #huawei-g300
16:02
sunnyden has quit [Remote host closed the connection]
16:03
gregor160300-m has joined #huawei-g300
16:20
<
pyongyang >
You could turn the RasPi into a Wifi sniffer.
16:32
<
gregor160300-m >
Why would I
16:36
gregor160300-m has quit [Remote host closed the connection]
16:47
fonz93 has quit [Quit: Leaving]
16:54
fonz93 has joined #huawei-g300
17:04
TheFallingOne has joined #huawei-g300
17:06
TheFallingOne has quit [Client Quit]
17:41
Weritos has joined #huawei-g300
17:43
<
Weritos >
What else can be used in addition to these figures?
17:43
<
Weritos >
I have 768 RAM
17:57
fonz93 has quit [Quit: Leaving]
18:16
fonz93 has joined #huawei-g300
18:29
fonz93 has quit [Quit: Leaving]
19:06
gregor160300 has joined #huawei-g300
19:06
gregor160300 has quit [Client Quit]
19:46
gregor160300 has joined #huawei-g300
19:46
gregor160300 has quit [Client Quit]
20:15
luca020400 has quit [Quit: Leaving]
20:18
luca020400 has joined #huawei-g300
20:53
Shadowghoster is now known as Ghost|afk
20:54
Ghost|afk is now known as Shadowghoster
21:24
luca020400-m has joined #huawei-g300
21:24
luca020400 has quit [Read error: Connection reset by peer]
21:39
Shadowghoster is now known as Ghost|afk
23:19
luca020400-m has quit [Remote host closed the connection]