**** BEGIN LOGGING AT Sat Dec 01 03:00:01 2018
**** BEGIN LOGGING AT Sat Dec 01 08:39:33 2018
Dec 01 11:46:36 <micmac1> Hello :)
Dec 01 11:54:13 <micmac1> Did anybody figure out a way to setup the ath9k gpio controller outside the wifi node to make the controller work again?
Dec 01 15:08:23 <rmilecki> karlp: we get event about block device disappear from kernel I think
Dec 01 15:08:31 <rmilecki> that event is handled by hotplug.d
Dec 01 15:08:37 <rmilecki> and script triggers "block"
Dec 01 15:08:46 <rmilecki> block has to cleanup after block device disappear
Dec 01 15:08:54 <rmilecki> read: it has to remove mounting points
Dec 01 15:09:12 <rmilecki> removing mounting points should also result in "mount" removal events
Dec 01 19:05:03 <mangix> jow: ping
Dec 01 19:19:02 <micmac1> Pretty quiet here, I don't think he's around :)
Dec 01 19:40:52 <mangix> nope
Dec 01 20:52:05 <karlp> rmilecki: yeah, that's what's _meant_ to happen, I just had serious problems with it in the past, I'll going to have a new play with it :)
Dec 01 21:51:06 <rmilecki> karlp: mountd was improved by me to be very reliable with "mount" events
Dec 01 21:51:18 <rmilecki> karlp: block improvements are on their way
Dec 01 22:00:23 <russell--> rmilecki: one curiosity i noticed while looking at the ubifs problem was the unnecessary copying of files to the overlayfs at firstboot.
Dec 01 22:04:18 <rmilecki> russell--: i won't have time to look at that anytime soon, sorry
Dec 01 22:04:24 <rmilecki> sound incorrect indeed
Dec 01 22:06:18 <russell--> rmilecki: no problem, thought i'd mention it though as you were in the vicinity
Dec 01 22:22:52 <karlp> the co-existing of block and mountd was poorly defined then, have you written up any new wiki pages on what you've been fixing up support for?
Dec 01 22:49:45 <rmilecki> karlp: no, i started with writing my personal document summarizing mountd & block & blockd
Dec 01 22:50:07 <rmilecki> any help in writing nice wiki page is appreciated
Dec 01 22:57:43 <blogic> rmilecki: nudge me tomorrow night, had a long day and am heading to bed now
Dec 01 22:57:57 <blogic> but i'll be online after 5pm tomorrow
Dec 02 00:00:20 <Olipro> I have an R7800 and a relatively "fat" image and I'm getting "vmalloc: allocation failure: 307200 bytes, mode:0x14000c0(GFP_KERNEL), nodemask=(null)" since I have a good amount of kernel modules
Dec 02 00:00:33 <Olipro> where is the default vmalloc allocation set and how can I increase it?
Dec 02 01:12:10 <pkgadd> Olipro: you not only have to consider the total RAM usage, but also RAM fragmentation - so modules may need to allocate larger than usual chunks of continuous memory, which will bite you before the total RAM usage would. however, the r7800 has plenty of RAM, so you need to check which module is failing for you and work on getting that fixed upstream (helping to reduce the continuous RAM allocations)
Dec 02 01:12:31 <pkgadd> Olipro: but there is no magic switch to "increase" values here or there
Dec 02 01:13:39 <pkgadd> that said, my own not-that-small image on the nbg6817 just needs ~60 MB RAM, leaving ~420 MB free to use - so even getting close to the limit of 512 MB RAM is... ambitious
Dec 02 01:14:49 <pkgadd> at some point you might want to either split services over multiple systems or look at x86_64 and "dozens" of GB of RAM
**** ENDING LOGGING AT Sun Dec 02 03:00:01 2018