**** BEGIN LOGGING AT Fri Jul 13 03:00:01 2018
Jul 13 08:19:48 <KanjiMonster> luaraneda: that slightly changed, 4.14 was announced as LTS at the beginning of the merge window ( http://kroah.com/log/blog/2017/09/06/4-dot-14-equals-equals-this-years-lts-kernel/ )
Jul 13 08:55:47 <jow> SQM is reportedly broken in 18.06.0-rc1
Jul 13 08:55:59 <jow> anyone able to test it? I never used SQM
Jul 13 09:09:13 <Tapper> jow How so mate I use SQM.
Jul 13 09:09:30 <Tapper> Is there a report?
Jul 13 09:10:23 <Tapper> I have limited skills, but I will give it a look.
Jul 13 09:18:00 <T-Bone> ldir: ping
Jul 13 09:22:30 <Tapper> found it on the forum.
Jul 13 09:23:17 <f00b4r0> blogic: out of curiosity, cross-arch dtsi isn't possible, right?
Jul 13 09:27:58 <Tapper> Looks like the sqm bug is in cake, that's as far as I can go with my crappy scills.
Jul 13 09:28:03 <Tapper> skills
Jul 13 09:28:13 <blogic> f00b4r0: ?
Jul 13 09:28:18 <blogic> it should be
Jul 13 09:28:27 <blogic> i know bsd uses our ralink dts files
Jul 13 09:30:26 <f00b4r0> no, I mean DTSIs that could be used across targets
Jul 13 09:30:31 <f00b4r0> arch == linux arch
Jul 13 09:31:14 <f00b4r0> mikrotik appears to expand into other platforms than just mips (ramips and ipq). And their hardware typically shares several common traits
Jul 13 09:31:56 <f00b4r0> I'm thinking a common dtsi for mikrotik hw would be convenient and prevent some odd things I'm seeing in the ramips routerboard DTS for instance
Jul 13 09:33:11 <ds_shadof> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=11d6547455e848efb4fac0b983a07b11be5caf25
Jul 13 09:34:27 <ds_shadof> So if i have small flash spi flash  then i don't need to enable swap at usb-flash for example
Jul 13 09:35:06 <f00b4r0> s/than just mips/than just ar71xx/
Jul 13 09:35:15 * f00b4r0 fixes himself
Jul 13 09:36:40 <f00b4r0> blogic: ^
Jul 13 09:51:43 <blogic> f00b4r0: not inside owrt right now
Jul 13 10:03:01 <f00b4r0> blogic: ok that's what I thought. Nevermind then. I'll prep up a standalone dts for the hap ac2
Jul 13 10:10:40 <DonkeyHotei> [Wed 2018-07-11 09:19:15 AM PDT] <rmilecki> DonkeyHotei: great, cc me <------- you requested, but you have not responded
Jul 13 10:11:36 <rmilecki> didn't find time yet
Jul 13 10:11:49 <DonkeyHotei> ok, just confirming you saw iy
Jul 13 10:11:49 <rmilecki> also we have to give luka some time anyway
Jul 13 10:11:51 <DonkeyHotei> *it
Jul 13 10:11:57 <rmilecki> not sure if he's going to look at it anyway
Jul 13 10:12:02 <rmilecki> but he's the maintainer
Jul 13 10:12:10 <rmilecki> so let's give him a chance as least :)
Jul 13 10:12:16 <rmilecki> DonkeyHotei: i saw, thank you
Jul 13 10:12:32 <DonkeyHotei> makefile says the maintainer is a marko ratkaj, not luka
Jul 13 10:12:55 <DonkeyHotei> did i ping the wrong person?
Jul 13 10:13:22 <blogic> DonkeyHotei: same company
Jul 13 10:13:31 <DonkeyHotei> ok
Jul 13 10:32:35 <DonkeyHotei> added a ping to luka just in case.
Jul 13 11:16:35 <shm0> hi
Jul 13 11:17:54 <shm0> is there a chance someone has experience with lsi megaraids? i had my raid 5 array failing over night. after fiddling around with cables and reflashing the bios, i got the raid controller to detect the drives properly again.
Jul 13 11:19:05 <shm0> The array shows up as optimal now. But i want to run a consistency check. but the software is telling me that the raid is not initialized... and if i want to initialize now
Jul 13 11:19:18 <shm0> i have the feeling that will wipe my data 8)
Jul 13 11:19:27 <Neighbor1111117> Hi all, could someone point me to where the wireless configuration script is generated
Jul 13 11:19:35 <Neighbor1111117> thanks
Jul 13 11:20:30 <azarus> shm0: doubt this is the right channel for it
Jul 13 11:21:38 <shm0> i know but maybe someone knows
Jul 13 11:22:11 <shm0> i'm also not sure if the controller is failing, the cable gone bad somehow, or the harddisk are bad.
Jul 13 11:23:25 <shm0> can you recommend a channel?
Jul 13 11:24:01 <azarus> maybe ask alis, I don't know, sadly
Jul 13 11:24:30 <shm0> oh yeah that feeling when you wake up check your server and there is a nice bluescreen
Jul 13 11:24:52 <DonkeyHotei> windows servers...
Jul 13 11:26:34 <shm0> yeah windows sucks, but in this case windows can't be blamed i think
Jul 13 11:27:03 <f00b4r0> windows can always be blamed.
Jul 13 11:28:36 <shm0> =)
Jul 13 12:39:03 * f00b4r0 has a nasty feeling mikrotik embraced DTS for the newer platforms and we will never see their files
Jul 13 12:48:04 * ldir sort of wanders in - but has been doing 0200-1200 shifts for the past 3 days and has had very little sleep.  And the football hasn't gone quite as well as hoped.  And Trump appears to be in this country.... and hasn't stumbled over any stray cans of Novichok....yet. 
Jul 13 12:48:23 <f00b4r0> :)
Jul 13 12:49:10 * ldir is also confused by these reports about cake.
Jul 13 12:49:20 <f00b4r0> the cake is a lie.
Jul 13 12:50:38 <ldir> f00b4r0: may I blame the French?  Your default position is to blame Microsoft.  We've had centuries of practice blaming the French :-)
Jul 13 12:50:47 <f00b4r0> of course ;)
Jul 13 12:50:50 <ldir> lol
Jul 13 12:50:53 <azarus> oui hon hon
Jul 13 12:51:05 <mamarley> f00b4r0: By this do you mean that cake isn't actually getting mainlined?
Jul 13 12:51:37 <ldir> f00b4r0: ha!  Now see what rumour you've started!!!!! :-)
Jul 13 12:51:59 <f00b4r0> ;^)
Jul 13 12:57:40 <f00b4r0> freenode is amazingly unstable for me
Jul 13 12:58:20 <Monkeh> f00b4r0: It's easier to just say 'freenode'
Jul 13 12:58:48 <f00b4r0> heh, fair enough ;)
Jul 13 14:03:18 <warrick_> Looking for some assistance/information on getting sshd set up on GPL firmware code for the Edimax BR6478V2
Jul 13 14:03:25 <warrick_> https://wikidevi.com/wiki/Edimax_BR-6478AC_v2
Jul 13 14:04:30 <warrick_> source code at bottom: https://www.edimax.com/edimax/download/download/data/edimax/global/download/
Jul 13 14:06:12 <warrick_> have looked at the generic instructions at https://wiki.openwrt.org/doc/devel/add.new.platform , but am not exactly competent enough to go it alone
Jul 13 14:13:00 <warrick_> It is on the openwrt site, but not yet detailed: https://openwrt.org/toh/edimax/edimax_br-6478ac_v2
Jul 13 14:29:50 <DonkeyHotei> warrick_: should be supportable; mostly just need to construct a proper .dts file
Jul 13 14:31:57 <DonkeyHotei> look at the examples in https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/ramips/dts
Jul 13 14:40:26 <nbd> russell--: pushed mt76 rx allocation rework as well
Jul 13 14:40:32 <nbd> i can't reproduce any leak anymore
Jul 13 14:47:01 <jow> good news, the zbt-wg2626 works (again) with 18.06 head
Jul 13 14:47:34 <jow> not sure waht exactly fixed it but its running happily now, its an mt7621 so might've been related to the bootloader lzma fix
Jul 13 14:48:34 <jwh> jow: so uh, before I decide whether to send to the list or not.. http://ix.io/1d3T thoughts? (ignore the obvious broken snprintf)
Jul 13 14:49:21 <jow> jwh: strictly speaking it should be something like check_loaded_kmod or similar but apart from that lgtm
Jul 13 14:49:31 <jwh> yeah
Jul 13 14:49:41 <jwh> I wasn't sure on the naming either, feature seems off
Jul 13 14:50:50 <DonkeyHotei> somebody in #openwrt keeps asking for code review of https://github.com/openwrt/packages/pull/5447
Jul 13 14:51:23 <jow> mkresin: ping
Jul 13 14:51:36 <f00b4r0> unchecking 'enable VLAN functionality' in Luci doesn't seem to alter swconfig 'enable_vlan", is this normal? (17.01)
Jul 13 14:57:38 <jow> this is not intended
Jul 13 14:57:48 <f00b4r0> ok
Jul 13 14:58:33 <f00b4r0> manually disabling doesn't seem to make a noticeable difference though
Jul 13 15:05:26 * jwh tries to remember how to send patches properly again
Jul 13 15:05:26 <jwh> :D
Jul 13 15:14:23 <jwh> jow: check_kmod_loaded?
Jul 13 15:14:31 <jwh> or just check_kmod?
Jul 13 15:20:49 <jow> jwh: check_kmod is okay too
Jul 13 15:21:22 <jwh> kk
Jul 13 15:22:44 <jwh> I'll rename *feature too
Jul 13 15:22:54 <jwh> seems more sane to just call it module
Jul 13 15:36:07 <blogic> nbd: lto :-D
Jul 13 15:44:39 <nbd> rmilecki: ping
Jul 13 15:45:51 <jwh> sent, think I may have even got it right irst time
Jul 13 15:45:54 <jwh> first
Jul 13 15:48:11 <jwh> actually
Jul 13 15:48:28 <jwh> why is e even passed to check_offloading()?
Jul 13 15:48:44 <jwh> oh
Jul 13 15:48:45 <jwh> blind
Jul 13 16:14:27 <warrick_> DonkeyHotei, or anyone with knowledge about it, how do I translate the OEM bootlog to appropriate settings in the dts WRT partitioning
Jul 13 16:14:46 <warrick_> 0x000000000000-0x000000030000 : "Bootloader" 0x000000030000-0x000000040000 : "Config" 0x000000040000-0x000000050000 : "Factory" 0x000000050000-0x000000070000 : "Cimage" 0x000000070000-0x000000190000 : "Kernel" 0x000000190000-0x0000007e0000 : "RootFS" 0x000000070000-0x0000007e0000 : "Uimage" 0x0000007e0000-0x000000800000 : "FreeSpace"
Jul 13 16:15:11 <warrick_> but existing dts files follow different naming and allocations
Jul 13 16:15:55 <warrick_> e.g. bootloader, config, and factory are in the dts, but Cimage, Kernel, RootFS, Uimage, and FreeSpace from OEM are seemingly grouped as 'devdata' and 'firmware' in the dts
Jul 13 16:21:24 <jwh> should try and clean up this package makefile before I send that too
Jul 13 16:36:10 <DonkeyHotei> warrick_: that may need to be a design decision for your port to the device
Jul 13 16:37:17 <warrick_> fair enough, thanks
Jul 13 16:38:16 <DonkeyHotei> just don't blow away needed data, like wifi calibration
Jul 13 16:46:35 <jwh> I suck at packaging (like everything else, ha!), can anyone see a way to make this "tidier"? http://ix.io/1d4a
Jul 13 16:47:36 <warrick_> newb question, how do I determine GPIO switch information?
Jul 13 16:48:19 <DonkeyHotei> from examining the vendor gpl source
Jul 13 16:48:23 <warrick_> roger
Jul 13 16:58:01 <blogic> warrick_: or using debugfs
Jul 13 16:58:28 <blogic> /sys/class/gpio + /sys/kernel/debug/gpio
Jul 13 17:01:48 <warrick_> so it is not necessary to, say, know the GPIO/led mappings until after I've loaded the firmware to get to that point?
Jul 13 17:02:22 <warrick_> alternatively, if I could alter the GPL code, get it to compile and flash, I could do it from the 'stock' firmware, correct?
Jul 13 17:02:28 <blogic> warrick_: you can use /sys/class/gpio to manually control gpios
Jul 13 17:02:31 <Borromini> hi guys
Jul 13 17:02:37 <blogic> and /sys/kernel/debug/gpio to monitor the state
Jul 13 17:02:40 <warrick_> ah ok
Jul 13 17:03:02 <blogic> warrick_: so yes, you can boot without knowing gpios and detect them at runtime from a booted image
Jul 13 17:03:30 <blogic> so "echo 123 > /sys/class/gpio/export" will create /sys/class/gpio/gpio123/*
Jul 13 17:03:53 <blogic> echo out > /sys/class/gpio/gpio123/direction    will make it an output gpio and echo in > ... input
Jul 13 17:04:11 <blogic> then you can read/write the state via /sys/class/gpio/gpio123/value
Jul 13 17:05:47 <warrick_> seems reasonable. thanks for the info
Jul 13 17:06:03 <blogic> :-)
Jul 13 17:06:34 <warrick_> saved for future reference. first, have to get openwrt onto the router
Jul 13 17:06:43 <blogic> also set all gpios to in, then before and after pressing a button cat /sys/kernel/debug/gpio to get a list off all GPIO incl the high/low state to find buttons
Jul 13 17:06:50 <blogic> good luck !
Jul 13 17:44:37 <jwh> Borromini: I gave up in the end, way too many half-merged patches upstream :D
Jul 13 17:44:46 <jwh> also supposedly 4.19 is the next lts, so may as well wait
Jul 13 17:46:07 <Borromini> well it's a lot of work, and if you don't know what code does what it's easy to make a rookie mistake (like me)
Jul 13 17:46:10 <jwh> time better spent getting some of my local patches into openwrt
Jul 13 17:46:30 <jwh> less conflicts to fix later :D
Jul 13 17:46:39 <jwh> yea
Jul 13 17:47:18 <jwh> I lack multiple displays as well now, so side by side comparisons are a chore
Jul 13 17:48:19 <jwh> sent fw3 patch in, gotta fix up this horribleness and then send that
Jul 13 17:49:20 <Borromini> i got a 27" 2560x1080 to be able to do such stuff comfortably
Jul 13 17:49:26 <jwh> yeah
Jul 13 17:49:39 <jwh> I used to have 3 27" displays, so...
Jul 13 17:49:51 <jwh> at the office that is, but I no longer work there :D
Jul 13 17:59:33 <Borromini> :) i have a small desk at my place, so two displays is out of the question
Jul 13 18:00:47 <jwh> heh
Jul 13 18:01:17 <jwh> makes it so much easier, feel much less irritated when I can span 100s of things across all screens :D
Jul 13 18:03:56 <Borromini> :)
Jul 13 18:05:05 <jwh> will see if I like the apartments I'm looking at next week, then I can get a decent workstation sorted again :D
Jul 13 18:06:21 <Borromini> moving places huh
Jul 13 18:06:44 <jwh> countries heh
Jul 13 18:07:00 <jwh> always on the move, gonna stay somewhere for a while
Jul 13 18:07:07 <Borromini> erm ok :P
Jul 13 18:08:30 <jwh> heh
Jul 13 18:16:39 <blogic> Hauke: sooo ... what ar ethe chances of getting cat.iq fossified ?
Jul 13 18:16:55 <blogic> Hauke: my uplink is getting switched to all-ip in 4 days
Jul 13 18:17:09 <blogic> right now i am using a fritz for isdn loop start
Jul 13 18:17:20 <blogic> and am considering options for the new sip setup
Jul 13 18:17:44 <blogic> and if $corp allows i'd invest time into an asterisk channel driver for cat.iq
Jul 13 18:18:06 <blogic> Hauke: do you see a chance and if so whom to i nudge ?
Jul 13 18:18:48 <blogic> i have a gigaset ip/dect base here that i'll use for the start but its sub optimal as it uses the "cloud" for config foo
Jul 13 18:25:24 <Hauke> blogic: so you would like to have the current cat.iq source kernel and user space source code and then you would try to get this working with the  asterisk channel driver in OpenWrt
Jul 13 18:37:40 <russell--> nbd: thanks!
Jul 13 18:37:52 <blogic> Hauke: and FW blob and permission to (l)gpl the resulting code
Jul 13 19:04:07 <mkresin> jow: pong
Jul 13 19:38:48 <rmilecki> nbd: pong
Jul 13 19:45:09 <ldir> mkresin: ping - query?
Jul 13 21:08:38 <greearb_> Hauke, you around?
Jul 13 21:36:18 <raynold> ahh it's a wonderful day
Jul 13 21:45:21 <raynold> ahh it's a wonderful day
Jul 13 22:42:04 <neoraider> nbd: the latest mt76 update broke build against kernel 4.9 (at least in 18.06, but I assume master is affected as well): http://paste.debian.net/plain/1033632
Jul 14 00:02:25 <whitewolf> TobleMiner: are you around? i'd like to talk to you about your ubnt work
Jul 14 00:05:22 <whitewolf> TobleMiner: hopefully a ping works; i was able to install the prerelease nanostation ac firmware onto the nanobeam ac gen2, everything works -- is there any information that would be useful in officially supporting it?
Jul 14 01:01:46 <DonkeyHotei> whitewolf: do you have a link/url for that?
Jul 14 01:02:09 <whitewolf> DonkeyHotei: specifically which? the product or the binary i flashed?
Jul 14 01:02:48 <DonkeyHotei> the porting effort, or the binary
Jul 14 01:03:02 <whitewolf> ah sure
Jul 14 01:03:18 <whitewolf> https://openwrt.org/inbox/ubiquiti/ubiquiti_nanostation_ac https://github.com/openwrt/openwrt/pull/1110 https://github.com/TobleMiner/openwrt-prereleases-bin
Jul 14 01:08:20 <DonkeyHotei> did you see the link to pr 1154 at the bottom of pr 1110?
Jul 14 01:08:56 <whitewolf> the nanobeam ac gen2 is closer to the nanostation ac
Jul 14 01:11:06 <DonkeyHotei> ahhh
Jul 14 01:11:55 <whitewolf> they're both "WA"
Jul 14 01:13:39 <whitewolf> dual port, poe
Jul 14 01:13:59 <whitewolf> i suspect the nanostation ac firmware isn't quite right, perhaps ram is different or i blew away something stupid
Jul 14 01:14:09 <whitewolf> i'm not really familiar with porting devices in this manner
Jul 14 01:14:27 <whitewolf> i did manage to hex edit the firmware updater on whatever version it came with to bypass the signature check
Jul 14 01:15:53 <whitewolf> hm, maybe all i need to do is the same as PR1154
Jul 14 01:16:01 <whitewolf> shrug, afk
**** ENDING LOGGING AT Sat Jul 14 03:00:00 2018