**** BEGIN LOGGING AT Tue Mar 24 02:59:57 2020 Mar 24 06:33:22 Hello. Does anybody know how to disable the hardware watchdog on the mt7620? I haven't debugged the kernel in a while and I guess I forgot how I did it -- can't get very far in kgdb before it reboots :) Mar 24 06:33:30 :( Mar 24 06:34:35 obj-$(CONFIG_MT7621_WDT) += mt7621_wdt.o Mar 24 06:34:52 build_dir/target-...../linux-4.19.108/drivers/watchdog/Makefile Mar 24 06:34:58 delete that line and rebuild Mar 24 06:35:07 its a crude way but will work Mar 24 06:36:26 blogic: thanks! I was hoping to do it at run time, but that'll work Mar 24 06:36:42 actually, this is 4.14.162, so it's rt2800_wdt.c Mar 24 06:36:54 rt2880 I mean Mar 24 06:38:06 I'm wondering what echo 1 > /sys/devices/platform/10000000.palmbus/10000120.watchdog/driver_override does... Mar 24 06:38:54 lol! nothing :) Mar 24 06:39:04 I'll do it your way Mar 24 10:01:21 well that pipeline failed quickly. Hmm. No c compiler? !! What! Mar 24 10:03:46 Is here some regex pro? Mar 24 10:03:46 grep -oP "DISTRIB_ARCH='\K(\w*)" /etc/openwrt_release Mar 24 10:03:46 I have no -P option in openwrt... But I have egrep? But, egrep seems not to work? Mar 24 10:05:12 distrib_arch=$(source /etc/openwrt_release; echo $DISTRIB_ARCH) Mar 24 10:07:59 thanks ;) thats easier! Mar 24 10:44:25 Ha! Right, so adding an extra check line for 'gcc10' to include/prereq-build.mk has gone beyond some limit which means the check for clang is no longer done, so builds on apple no longer work. Mar 24 10:45:35 ldir: uhm yeah... these macros only support a limited amount of arguments Mar 24 10:45:46 not sure if it was 10 or 15 Mar 24 10:46:23 so do we really need to explicitely check for all those gcc versions? Mar 24 10:47:04 probably not any more? I guess it was originally to block 4.7 known breaagkages? Mar 24 10:47:43 and is it installed as the suffix everywhere anyway? Mar 24 10:48:06 you're talking about SetupHostCommand right? Mar 24 10:48:12 yes Mar 24 10:48:38 * karlp isn't even sure any of the version suffixed lines are useful. what distro is doing that with the suffixes that they need to be separate like that? Mar 24 10:49:05 I'd delete gcc48 down to gcc10 lines, but hey, peanut gallery, I didn't add any of it. Mar 24 10:49:18 gccXY aliases were for FreeBSD Mar 24 10:49:47 we can probably drop most of them Mar 24 10:50:32 python is similar, but not as far gone Mar 24 10:50:49 sheamless plug https://patchwork.ozlabs.org/patch/1193826/ (build: make GCC version 6+ minimal host build requirement) Mar 24 10:50:52 :D Mar 24 10:52:22 why isn't it committed? Mar 24 10:52:52 because it doesn't amtter for most people, and it just makes it happen again at gcc 14 :) Mar 24 10:53:16 which is "later" enough for most purposes I'd agree :) Mar 24 10:54:46 ok stupid question - if we're aware of $(CC) env var, could the freebsd people just set that to 'gccver' ? Mar 24 10:55:20 ldir: yes, most likely. It just needs to be sensibly set the first time the prerq-build stuff runs Mar 24 10:55:32 ldir:not stupid question :) Mar 24 10:55:36 afterwards the proper gcc is symlinked and should just work Mar 24 10:56:52 Do we actually know of anyone who builds on freebsd ? Mar 24 10:57:47 ldir: I don't think anyone does Mar 24 10:58:02 it was me giving it a spin a few years back Mar 24 10:58:09 I suppose many things broke again in the meanwhile Mar 24 10:58:09 ldir: you're probably closest Mar 24 10:59:55 I'm tempted to drop all the explicit gcc'n' checks. Mar 24 11:00:12 ldir: I agree, feel free to add my acked-by Mar 24 11:01:37 One or two weirdo exceptions for the weirdo OSs (ldir puts hand up) are fine IMO Mar 24 11:18:47 * ldir invokes the macbot Mar 24 11:21:04 :) Mar 24 11:21:28 mailing still preferred channel for submitting patches? Mar 24 11:26:17 yes Mar 24 11:26:44 thx Mar 24 11:27:48 You've had an identity crisis again - overtaken by virus? Mar 24 11:36:13 ldir: do you know the 'midlife-crysis'? Mar 24 11:36:27 i own a perfect midlife-crysis-compensator Mar 24 11:36:35 a Yamaha XJR 1300 Mar 24 11:37:22 midlife crysis? with UHD graphics? ;D Mar 24 11:37:47 hm.. that reminds me... didn't play crysis for a while Mar 24 11:37:56 a Yamaha XJR 1300 is being used in the VR Game: Real Reality Mar 24 11:38:11 Perfect Graphics but bad GamePlay Mar 24 11:38:31 f00b4r0: hehe Mar 24 11:42:28 no save poitns either, permadeath :| Mar 24 11:44:02 I have a Kawasaki ZX636 already :-) Mar 24 11:44:28 a baby Ninja? Mar 24 11:45:07 yeah Mar 24 11:45:27 i need to look at my Yamaha - maybe such a Pocketbike may be a part of the onboard-toolset Mar 24 11:45:33 *eg* Mar 24 11:45:50 i think your baby runs much more than 240km/h? Mar 24 11:46:50 mine also does - but only on the speedometer - not in real - up to 220 km/h are possible but its some kind of 'windy' then Mar 24 11:47:49 i have no wind protection on my bike Mar 24 12:03:47 i have a development question openwrt: i'm using a gps stick on my fritzbox4040 (openwrt) as time receiver. will there be ootb support if gpsd-time information in the package ntp ever? Mar 24 12:12:39 hrm, fresh master x86/64 isn't building me any output images? I see root.ext4 and root.squashfs in build_dir/target-x86_64_musl/linux-x86_64/ but it never ends up in bin/targets/x86/64, I just get a manifest, a kernel debug, and packages? Mar 24 12:16:46 tried another 5.4 kernel image on ath79 tplink wdr3600 and saw this again: [ 0.107073] Kernel panic - not syncing: Unexpected DSP exception Mar 24 12:17:13 aparcar[m]: is this related to your switch image generation stuff? Mar 24 12:17:21 do you get files generated in bin after that? Mar 24 12:24:12 karlp: that sounds familiar ;-) Mar 24 12:26:23 very. Mar 24 12:28:01 * karlp jumps back a few commits and rebuilds Mar 24 12:30:05 I was able to build x86/64 6f01d3334ef3834d888dc91b35e51524439b34d1 Mar 24 12:30:07 make dirclean world didn't fix my wdr3600 build, still panic'ing with the same message Mar 24 12:30:39 but I had to nuke my build_dir Mar 24 12:31:32 well, I only just cloned this this morning Mar 24 12:31:35 and it builds just fine Mar 24 12:31:42 I just don't get any images in bin/targets/x86/64 Mar 24 12:34:53 weirdly, 12423-g0493d57e04 worked fine on the same hardware with 5.4 from just a few weeks ago Mar 24 13:06:45 well, I reverted back to e6e1e12dc3 and I get images in the bin dir again. Mar 24 13:08:40 aparcar[m]:how exactly was this tested? Mar 24 13:10:11 tmn505: ^^^ Mar 24 13:10:59 what images are you missing 'cos I have x86/64 combined image no problem. Mar 24 13:11:28 I've got _none_ in the bin dir. Mar 24 13:11:53 oh :-( Mar 24 13:11:56 karlp: what is selected in your config? Mar 24 13:12:56 added ext4, turned off gzip of images. Mar 24 13:13:36 works again if I go back before "cb007a7bf6 x86: switch image generation to new cod" Mar 24 13:14:10 here's a full diffconfig, but it's got lots of unrelated: https://paste.centos.org/view/f23235dc Mar 24 13:15:54 off to take one of the girls for some exercise, back later. Mar 24 13:15:58 dammit, forgot I'd just done a make dirclean - will take me a while to rebuild & see if I can replicate :-) Mar 24 13:32:22 karlp: did You remove $(TOPDIR)/tmp? buildroot doesn't seem to pick the changes. Mar 24 13:55:48 xback: that whole routerboot code is really crappy. I'm writing a proper sysfs driver which I hope will provide a better interface going forward. Meanwhile I guess a quick workaround for your case is to check if the resulting string is empty Mar 24 13:56:04 (*tag = '\0' should work) Mar 24 13:56:09 == Mar 24 13:57:02 note that rbextract.c is just as bad, sadly :/ Mar 24 15:09:04 tmn505: it was a brand new clone Mar 24 15:13:24 that's strange, openwrt snapshots are there. Mar 24 15:14:31 I'm building 64 bit images now tye'll be ready in half hour, will see if there's some issue. Mar 24 15:15:53 karlp: intrigued that you have 'multi profile' enabled (target profile -> multiple devices) Mar 24 15:16:46 probably from having my config for an ath79, and switching to x86? Mar 24 15:17:15 could be, it's certainly different from my (working) config Mar 24 15:18:01 well, I tested what I needed on near-master for my own things, i'm not poking this further, I'm back to 1907 for other things Mar 24 15:18:33 ok, trying to help Mar 24 15:23:36 it's probably related to CONFIG_TARGET_IMAGES_GZIP Mar 24 15:23:58 it's enabled by default, so probably untested when disabled Mar 24 15:28:19 ldir: yeah, I know, just limited time to muck aroudn with kids home these days Mar 24 15:29:33 * karlp turns on gzip and pulls and rebuilds Mar 24 15:45:24 * karlp thinks this is having multi targets, and then having it default to none. Mar 24 15:50:34 yep, that works. but why did it work before the image changes... Mar 24 15:52:30 ah, because in the old tree, that multi profile didn't do anything. Mar 24 15:52:43 in the new code, it takes affect, and makes you fall into a new option with no images selected. Mar 24 15:53:02 so.... works.... I guess. Mar 24 15:53:20 just have to reselsect targets if you're switching arches Mar 24 16:16:42 f00b4r0: The patch is ok so r2 boards dont get broken on update, but it should just use tag 05 Mar 24 16:16:49 f00b4r0: agreed on the code status Mar 24 16:17:16 all code on the flash is also little endian, but I dont see any le16_to_cpu to ensure it works on BE archs too Mar 24 16:18:46 also the code fetches a u32 without checking alignment etc Mar 24 16:19:20 xback: moments, on the phone, will explain Mar 24 16:34:32 xback: in a nutshell, whoever wrote that code had no understanding of endianness and embedded devices. Mar 24 16:34:56 xback: as you would expect, the data on the flash is cpu-endian. The get_32 routine is totally useless. Mar 24 16:35:14 all tags are aligned (luckily) Mar 24 16:37:04 get32 is not only useless, it's very inefficient too. Mar 24 16:39:47 xback: if one defines RB_MAGIC_HARD like so: #define RB_MAGIC_HARD (('H') | ('a' << 8) | ('r' << 16) | ('d' << 24)) then it can be read natively as a u32 in LE and BE for instance Mar 24 16:40:55 I've written a mtd parser for the routerboot segment which has been tested on BE, if you have access to LE RB hw (rbm11 or rbm33) to test that would be most helpful. Mar 24 16:41:45 xback: as for the sysfs driver, it's also coming along nicely. I'm trying to simplify the code and make it more robust (and upstreamable) Mar 24 16:42:49 my goal is to get rid of rbextract, and eventually entirely rewrite rbcfg in a simpler, much shorter and more robust way Mar 24 16:47:57 f00b4r0: hooray for just using shifts as intended, instead of trying to "be clever and understand endians" Mar 24 16:48:03 note that the transition to ath79 might be a nice opportunity to get stuff set up there nice and clean, particularly since not so many devices have been ported yet Mar 24 16:48:15 "not so many" ?! Mar 24 16:48:23 karlp: yeah, it's amazing the number of people who just don't get it ;) Mar 24 16:48:53 not so many mikrotik devices Mar 24 16:49:06 i.e. 2, iirc Mar 24 16:49:43 adrianschmutzler: my point exactly. I'd rather do this before too much damage is done. that's why I wasn't so eager to start that port: there's quite a bit of plumbing cleanup to do. Mar 24 16:49:58 adrianschmutzler: meanwhile I have 3 of such cleanup patches waiting in patchwork ;) Mar 24 16:50:32 f00b4r0: I'm more than willing to aid as much as possible. I have a ton of different MikroTik devices laying around Mar 24 16:50:51 ha! Mar 24 16:51:08 that's good to hear :) Mar 24 16:51:30 do you have ramips ones? Mar 24 16:52:05 chances are pretty high. will take a look in stock asap Mar 24 16:52:27 (I'm only working 3 days / week currently with all the corona stuff going on ..) Mar 24 16:54:12 f00b4r0: if possible, also try to included in sysfs if tags have been found which are not known yet. + their length Mar 24 16:54:24 this should aid in supporting more and more details easily in the future Mar 24 17:02:04 sounds tricky but feasible Mar 24 17:02:49 i'll put that on the TODO, maybe for once the working code is accepted. Baby steps :) Mar 24 17:03:15 ofc :-) I just like to ask it soon enough, than 2 minutes late ;-) Mar 24 17:03:22 from a local debugger here: Mar 24 17:03:26 Remote debugging from host 10.0.253.99, port 55300 Mar 24 17:03:27 ID: 26 Len: 4 Mar 24 17:03:29 ID: 4 Len: 8 Mar 24 17:03:30 ID: 14 Len: 4 Mar 24 17:03:32 ID: 10 Len: 4 Mar 24 17:03:33 ID: 13 Len: 4 Mar 24 17:03:35 ID: 19 Len: 4 Mar 24 17:03:36 ID: 18 Len: 4 Mar 24 17:03:38 ID: 20 Len: 4 Mar 24 17:03:39 ID: 21 Len: 4 Mar 24 17:03:41 ID: 27 Len: 4 Mar 24 17:03:42 ID: 11 Len: 16 Mar 24 17:03:44 ID: 5 Len: 16 Mar 24 17:03:45 ID: 33 Len: 12 Mar 24 17:06:09 19, 18, 20, 27 are unknown Mar 24 17:08:42 * f00b4r0 thinks that after writing a few hundred lines of driver code, it might be time to test it actually builds ^o^ Mar 24 17:33:04 f00b4r0: I have dumps of the flash of a hap-ac² (which is ipq4018, and LE iirc) Mar 24 17:33:28 zorun: I have that too, thanks. What I need now is live code testing :) Mar 24 17:33:38 at least it was not the same endianness compared to the ar71xx/ath79 boards I used before :) Mar 24 17:33:41 ok Mar 24 17:33:59 hap-ac² is still unsupported and it requires too much knowledge for me, I've given up :( Mar 24 17:34:24 zorun: i bought one. As I don't plan to ever use routerOS, let's say I have an incentive :) Mar 24 17:34:41 cool :) Mar 24 17:51:00 karlp: sorry, got distracted by some things. Anyway tested, and images are there. I also saw it sometimes with switching arches when mandatory packages weren't selected for device. Mar 24 18:19:21 Are we likely to see cyrus back again ? Mar 24 18:21:27 he is marked as maintainer for libnftnl 6rd ds-lite omcproxy nftables bzip2 Mar 24 18:21:54 ldir: very unlikely Mar 24 18:23:49 I'm not volunteering, well not particularly, but having him marked as maintainer sets unrealistic expectations. Mar 24 18:46:52 ldir: It would be nice if yomeone could make a patch removing everyone as maintainer who did not contribute to a package for lets says 1.5 years Mar 24 18:46:57 *someone Mar 24 18:47:24 please send this to the mailling list first so the people are aware of this Mar 24 19:45:51 karlp: Sorry about the images, I tested gzipped images and new images where created, but maybe I messed up some cache, I'll look into that again Mar 24 19:46:25 ynezz: regarding the missing kernel, I see a generic-kernel.bin for x86/64, what exactly is missing here? Mar 24 20:06:02 aparcar[m]: it seems to be that the CONFIG_TARGET_MULTI_PROFILE=y didn't matter for x86 before, but afte ryour change, if you switch arches, that kicks in, and you get no selected profiles to build, Mar 24 20:55:26 aparcar[m]: no proper padding was ever applied, necessary for squashfs images: https://paste.debian.net/1136407 Mar 24 21:08:59 tmn505: do you mind creating a patch? Mar 24 21:09:30 karlp: sorry I wasn't aware of that. Do you think it requires additional fixups now? Mar 24 21:10:23 will do tomorrow Mar 24 21:10:58 tmn505: thank you Mar 24 21:12:40 aparcar: eh, nah,not sure what it should do honestly. it's from having a multi profile with devices selected for ath79, and then switching to x86 Mar 24 21:13:00 but, x86, at least 64 only has _one_ multi profile anyway. Mar 24 21:15:22 it _could_ autoselect them, but not sure that's really helpful down the road really. Mar 24 21:16:20 could log things or fail builds with nothing selected perhaps, but again, not sure if that's really helpful Mar 24 21:18:10 karlp: thats kind of strange because I keep switching around targets all the time and did have any problems with x86/x at all Mar 24 21:19:12 do you use multi_profile on the _other_ targets? Mar 24 21:30:41 if you just do menuconfig, ath79, target profile (multiple) and choose a target image, then switch to target=x86, subtarget x86_64, and _don't do anything else_ you'll be left on multiple devices, but target devices will have none selected,if you're trying to see it yourself. Mar 24 21:32:31 xback: the PR has code that is plain wrong and will break shit Mar 24 21:40:16 karlp: right I did not test with multi device. Thanks for the info. Mhhh not sure what do to with it, maybe the build system requires either a reset when switching targets or automatically select the first profile if none is selected. Which is Default/Generic in most cases Mar 24 21:40:55 * f00b4r0 finds it amazing how easy it is to get crap into openwrt and how hard it is to fix it afterwards Mar 24 21:40:57 *sigh* Mar 24 21:43:56 aparcar: I'd just leave it for now. Mar 24 21:44:25 it's an uncommon case really, Mar 24 21:45:12 and it's not Default/Generic on the target devices list on ath79 for instance, Mar 24 21:45:31 default/generic is first if you choose a profile _other_ than multiple devices. Mar 24 21:45:55 not first on allwinner either, so not sure that path would even be viable. Mar 24 21:46:03 karlp: okay Mar 24 21:46:12 anyway thanks for the explaination Mar 24 22:32:59 We get more people twetting about (CVE-2020-7982) then when we put out a new release Mar 24 23:05:59 aparcar: just compare 19.07.2 with snapshot, you'll notice ext4 and squashfs images missing Mar 24 23:08:00 aparcar: if one would like to use QEMU's -append (adjust kernel's cmdline), then you need kernel+rootfs, not combined image Mar 24 23:08:27 in combined image, you would need to change the kernel's cmdline in grub Mar 24 23:58:47 ynezz: ack, have to do some homework but will work on that later today Mar 25 02:23:54 jow: what is date -k and does it actually work? **** ENDING LOGGING AT Wed Mar 25 02:59:57 2020