<philipp64>
I'm missing something... there's no multiline modifiled ('m') for patterns...
<dwfreed>
when you load multiple lines into the pattern space, then you'll have \n's to match
<dwfreed>
without using the 'append next line into pattern space' command, your pattern space never contains newlines, because it operates on a single line at a time; that command adds a newline and then the next line
<dwfreed>
if you append the whole rest of the file into the pattern space, then you can just do the regex you gave and it'll match like you expect
<dwfreed>
you can make it a bit more sane by dropping the search for the options section, because checkconf isn't going to produce a malformed result, and the only place listen-on-v6 can be is in an options block
<dwfreed>
in which case you only need to load one more line in each cycle
<dwfreed>
sed -ne '1N; N; /^\tlisten-on-v6 {\n\t\t"none";\n\t};$/{ p; q; }; D'
<dwfreed>
tested that with my own named-checkconf output; it will produce output if it matches (the only truly portable way) and nothing if it doesn't
<dwfreed>
explanation: we need to match 3 lines (just to be sure), but we only advance forward one line per cycle, so we need to prime another line, which is what the 1N is for (on the first line, append the next line to the pattern space)
<dwfreed>
then the other N runs every cycle and so you've always got 3 lines in the pattern space; when the regex matches, print the pattern space (p) and exit (q); otherwise, delete up to and including the first embedded newline in the pattern space (D), and then start the next cycle without reading a new line of input (that's why there's an unrestricted N at the start)
<dwfreed>
philipp64: ^
<philipp64>
okay, but if I was being extra-paranoid and wanted to anchor it with ^options {$
<philipp64>
would it be as easy as not including the 'D'?
AtomiclyCursed has joined #openwrt-devel
<dwfreed>
the regex isn't quite right for the actual match, but this is the idea: sed -ne ':a;N;$!ba; /(^|\n)options {\n(\t[^\n]\n)*\tlisten-on-v6 {\n\t\t"none";\n\t};(\n|$)/{ p; q; }'
<dwfreed>
the :a;N;$!ba; loads the whole file into pattern space
<dwfreed>
(it will fail on single line input, but that doesn't matter here)
shoragan has quit [Ping timeout: 480 seconds]
<dwfreed>
getting the full match properly anchored is going to be a lot more work than using the example I gave before that just looks for listen-on-v6
<dwfreed>
and I've read the entire bind9 Administrator Reference Manual from cover to cover, so I'm intimately familiar with the syntax of named.conf
<dwfreed>
and I can say with certainty that listen-on-v6 is only valid in an options block
<kopijahe>
Hi, is there any way to add vlan tag by default to one interface on mt7621-based board?
<kopijahe>
Turns out my board's LTE module is connected through ethernet after all, and some other person said that he successfully activated it by using VLAN 103 and 4094 in one of the interfaces.
<dwfreed>
just attach the wan interface to ethX.103
<dwfreed>
openwrt automatically makes vlan interfaces
<dwfreed>
if it goes through the switch, you do have to adjust the switch config to tag
<kopijahe>
dwfreed: Do I do it in the DTS file? or 02_network?
<dwfreed>
02_network
<kopijahe>
ok, gonna read some more
Misanthropos has quit [Ping timeout: 480 seconds]
<philipp64>
ynezz: so... what happens next on PR #9306 ?
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
kopijahe has quit [Read error: Connection reset by peer]
kopijahe has joined #openwrt-devel
ekathva has joined #openwrt-devel
omni has quit [Read error: Connection reset by peer]
<Grommish>
neggles: Autoloads fine, removes fine, try to put it back in and it panics and calls the watchdog
<neggles>
that doesn't shock me at all, it's not really meant to be a kmod
<Grommish>
But, when you remove the driver, the leak goes away ;p
<Grommish>
which is what I wanted to test
<neggles>
that's not exactly conclusive
<Grommish>
neggles: Of course not, but it's something more than "remove the driver and the leak stops because it certainly isn't the driver" response we did get
<aparcar[m]>
stintel: do you have ucode running on debian?
<stintel>
no
<stintel>
I don't use Debian
<stintel>
but I have it running on Gentoo
rua has joined #openwrt-devel
<aparcar[m]>
stintel: do you have it somewhere all put together?
<stintel>
no, it's patches for each dependency
<aparcar[m]>
all right thank you
<stintel>
I believe you will need it on Debian as it also uses lib64
<stintel>
but try without first of course :)
<stintel>
just wanted to share that in case you need it as I've already gone through this, I believe I talked to jow about this at some point and if it doesn't break building on OpenWrt it could even go in the main repos
<stintel>
I just never got around to that
<aparcar[m]>
stintel: all right thanks for letting me know!
valku has joined #openwrt-devel
ekathva_ has joined #openwrt-devel
ekathva_ has quit [Read error: Connection reset by peer]
ekathva__ has quit [Ping timeout: 480 seconds]
ekathva_ has joined #openwrt-devel
valku has quit [Quit: valku]
cmonroe has joined #openwrt-devel
cmonroe_ has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
MAbeeTT3 has joined #openwrt-devel
MAbeeTT2 has quit [Ping timeout: 480 seconds]
ekathva__ has joined #openwrt-devel
valku has joined #openwrt-devel
valku has quit []
ekathva_ has quit [Ping timeout: 480 seconds]
rsalvaterra_ has joined #openwrt-devel
rsalvaterra_ is now known as rsalvaterra
ekathva__ has quit [Read error: No route to host]
<stintel>
friend just confirmed he does not have IPv6 on his starlink :/
<cbeznea>
ynezz: a new at91 target (sama7g5) has been added recently but I don't see it in buildbot. I don't know what should be the flow so I'm asking here: should I do something myself to have it there or you will take care of it?
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<Ansuel>
jow: ignore if you are busy or something did you check that pr about the nl80211 rpcd module ?
<Ansuel>
i'm too curious to know if I totally screw up with your request
Piraty has quit [Remote host closed the connection]
Piraty has joined #openwrt-devel
cmonroe has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
Borromini has joined #openwrt-devel
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
<jow>
Ansuel: I've seen it but haven't had time to review it yet, sorry
_lore_ has quit [Ping timeout: 480 seconds]
<Ansuel>
jow: np the big question is if in the future there is an intention to drop the use of iwinfo for nl80211 and use a more ""direct"" approach
_lore_ has joined #openwrt-devel
gladiac has quit [Quit: k thx bye]
robje has quit [Quit: "reboot]
<philipp64>
jow: can my xtables-addons version bump be merged please?
Borromini has quit [Quit: Lost terminal]
robje has joined #openwrt-devel
Znullptr has joined #openwrt-devel
ldir has joined #openwrt-devel
<dansan>
Hello! It's been a little while since I needed to debug my kernel and I've forgotten how to disable the hardware watchdog on the mt7620. Does anybody know?
<dansan>
I have a comment in my gdb script that says # echo 10000120.watchdog > /sys/bus/platform/drivers/rt2880_wdt/unbind ... is an example of something that does not work
<dansan>
lol, so I'm guessing that's not it
<dansan>
I tried to ubus call system watchdog '{"Timeout":31556952}', and it claims to set that timeout, but it still reboots after too long in kgb
cmonroe_ has joined #openwrt-devel
<noahm>
philipp64: looking now...
<dansan>
Ah hah! This seems to work (probably just the "stop" part): ubus call system watchdog '{"frequency":86400,"timeout":31556925,"magicclose":true,"stop":true}'
<dansan>
ldir: thank you. I did run across that article, but it didn't mention how to completely disable it, only how to stop procd from managing it and getting it to release the /dev/watchdog file so you could "tickle" it via user space.
<dansan>
I'm honestly not sure which part of my solution was the answer. Did the watchdog hardware really accept a value of "one year's worth of seconds"? I dunno
<dansan>
Running kgdb essentially pauses the kernel -- or at least most of it
<dansan>
Not even jiffies ticks!
<dansan>
ldir: I appreciate the help though!!
<ldir>
np
<dansan>
Now if I can just fix my screwed up virtual serial port driver I implemented on top of pty
tmn505 has quit [Remote host closed the connection]
<Ansuel>
it looks like he knows a lot about that...
<robimarko>
Well he works or used to work for QCA
shibboleth has quit [Quit: shibboleth]
<Ansuel>
question is why he never cared to send a fix
<Ansuel>
also wonder if times are mature to finally push a cpufreq driver...
<f00b4r0>
Ansuel: just out of curiosity, what kernel are you experiencing these problems with?
<Ansuel>
we suffer from this from 4.19
<f00b4r0>
hmm ok.
<Ansuel>
in the old ipq806x days we didn't have this as we didn't have a cpufreq driver / we didn't scale the cache
<Ansuel>
aka run the router at 800mhz instead of 1.7
<Ansuel>
the strange thing is that some user have superb uptime like 60 days...
<Ansuel>
wonder if the reason is just defective power supply/cpu
<f00b4r0>
It's almost certainly something entirely different, but I'm chasing a very peculiar bug on armhf (raspi). I have completely random lockups with nothing in the logs. If the watchdog is enabled, it will kick. Now the really odd thing is: these lockups happen after a week or more on 5.10.63. They can happen within an hour on 5.10.105
<f00b4r0>
if the watchdog is not enabled, the system "comes back" after typically 1h or more, but is in a really trashed state with dead programs and even some threads within a single program killed. Completely crazy stuff.
<Ansuel>
mhh you are lucky that you have have a difference
<Ansuel>
very time consuming but you can find what kernel version cause the problem
<Ansuel>
and then investigate the changes
<Ansuel>
once you find the cause of the increased regression you just found the cause of the entire problem
<f00b4r0>
indeed. I've been deferring but eventually I'll have to dig ;P
<Ansuel>
anyway i need to check something else..
<Ansuel>
we have one workaround that is not present upstream
<slh>
I wouldn't blame the PSU, the issue is too common for that (I'm seeing it on nbgt6817/ ipq8065 and g10/ ipq8064, uptimes rarely exceeding 13-14 days, but often already rebooting after a day or two)
<Ansuel>
in the netgear code there are 4 cpu serial code that are set in a special voltage table where some freq are locked to a specific voltage
<Ansuel>
i need to check
<Ansuel>
what are the odds that i have that cpu o.O
<Ansuel>
case 0x511F04D0: /* KR28M2A20 */
<Ansuel>
case 0x511F04D1: /* KR28M2A21 */
<Ansuel>
case 0x510F06F0: /* KR28M4A10 */
<Ansuel>
these cpuid require a min vdd core of 1150000
<hauke>
A10, A20 and A21 sound like chip versions, with changes on some or all (photo)masks
<Ansuel>
so it can't happen that different version can be put on the same router
<hauke>
it can happen that the early devices have a A20 chip for example and then later they changed to A21
<hauke>
if the fix was not so important for them
<Ansuel>
well this is present in the netgear sourcecode... actually it's krait generic if a cpu have that id then the min voltage has to be 1150000
<Ansuel>
this is absent in our source so i should add this anyway... what i want to know is if i'm suffering from this...
<hauke>
Some of the lantiq VRX200 boxes we supprot in OpenWrt use a A1x chip and some use a A2x chip version. You can not see the difference from the outside of the box
<hauke>
it is also possible that these chips were never mass produced
<hauke>
that the KR28M4A10 chip was never mass produced
<Ansuel>
from cpuinfo mine looks very similar to 0x511F04D0
<Ansuel>
mhhh should i take my router and check this mhhhh
<robimarko>
Ansuel: Can you point me to the voltage table?
<robimarko>
Cause the SoC speec sheet actually has the VDD_APC compared to Frequency as well as KPVS fuse bits
<Ansuel>
sure give me a sec will provide a gist
<Ansuel>
also consider the current voltage we are using in opp are with +5% of voltage tollerance
<hauke>
I have no knowlage about the ipq series, this is just some general knowlage what sillicon vendors do
<Ansuel>
(also what if the pvs code is fked and we never notice that....)
<slh>
netgear appears to be a quite early accesss customer (see the rax120 v1 with first generation ipq8074 silicon), so quite possibly they do need to cater for more chipset revisions than some other vendors
<robimarko>
Ansuel: Ok, so you have 4 speed bins
<robimarko>
Thats correct only for IPQ8064
<Ansuel>
ipq8065 have 7 bin
<robimarko>
8065 actually has 7
<robimarko>
Yeah
<Ansuel>
yep
<Ansuel>
on mine i should be bin 4
<robimarko>
Yeah, IPQ8065 tables are correct
<Ansuel>
cpuid : 512f04d0
<robimarko>
BTW, Whats Akronite Lite?
<Ansuel>
so verything with CPU variant : 0x1 require the min vdd
<Ansuel>
should be ipq8062
<Ansuel>
lower clocked
<Ansuel>
we have one device on openwrt
<robimarko>
That table is incorrect
<Ansuel>
nope also the other router have cpu variant 2 so not affected by this min vdd
minimal has quit [Read error: Network is unreachable]
<Ansuel>
robimarko really ?
<robimarko>
Only the PVS=011 (Superfast) is correct
<robimarko>
Others are undervolted according to the recommended table
<robimarko>
I am sure it got updated after the code
minimal has joined #openwrt-devel
<Ansuel>
would be at least something to use the correct pvs table
<Ansuel>
meanwhile stephen answerd and he didn't remember :( but he suggested something about cpuidle...
<robimarko>
Il PM you tommorow on the forum after I look at all the tables
<Ansuel>
easy test in theory... just comment the node on the dts...
<Ansuel>
robimarko thx a lot
<mangix>
mmm krait. fun.
<robimarko>
I have random datasheets for IPQ806x but nothing voltage related other then stuff in the spec sheet
<Ansuel>
mangix i want that shit fixed... enought of these random crash
<Ansuel>
it's not possible that the original firmware doesn't suffer from it and we can't manage to find the cause...
<mangix>
I mean strictly speaking wouldn't lowering the clock to 800 fix it?
<robimarko>
Ansuel: From where is the PVS read?
<Ansuel>
efuse stuff
<mangix>
clock setup on these embedded devices is a mess. Reminds me of the broken mvebu patchset.
<robimarko>
AVS is controlled via SAW2 or?
<robimarko>
Cause, I am seeing a tons of AVS stuff in SAW2
<Ansuel>
AFAIK (but i could be wrong) that part is about cpuidle that in theory we never used clk is all controlled by hfpll mux and cpufreq driver
<Ansuel>
voltage are controlled via rpm
<robimarko>
Yeah
<robimarko>
But SAW2 regs have a ton of PMIC/RPM bits
<robimarko>
They even have a setting for 5 or 6 bit voltage depedning on what PMIC is used
<Ansuel>
also something to notice enabling cpuidle on ipq8065 makes the router never boot... but it does work on ipq8064 so something strange is present there
<Ansuel>
is it possible that is actually saw2 doing some strange stuff while clocking the cpu and doing voltage change?
<Ansuel>
stephen said exactly that that cpuidle could be doing things while we are scaling
<robimarko>
Is there a chance you can check whats the PMIC being used?
<robimarko>
8058 or 8091?
<Ansuel>
mhhh how?
<robimarko>
Look at the PCB, no other way
<Ansuel>
sure give me a sec so i can destroy the case :D
<robimarko>
You dont have to rush
<robimarko>
I am off to sleep anyway, just let me know tommorow
<Ansuel>
it's just 4 screw
<robimarko>
Ok, I will wait then
<robimarko>
Is VDD_CX being also scaled?
<robimarko>
It has a turbo setting as well
<Ansuel>
don't think so
<Ansuel>
where is that ?
<robimarko>
Well, thats like the voltage rail for everything else in the SoC except for NSS UBI cores which have their own rails as well
<philipp64>
mangix: any further comments about PR 18056?
<Grommish>
mangix: Uhh.. Yah.. Wouldn't the SDK/ImageBuilder actually want to use ccache since the packages don't really change?
<mangix>
philipp64: no
<philipp64>
It's not optimal hacking the top-level configure but... I've tried to work with the upstream folks to get everything working with Openwrt, but they didn't let me know about the RC before 4.4.3 was released... or I would have called out the failure.
Grommish has quit [Read error: Connection reset by peer]
<philipp64>
at this point, I don't think about release of isc-dhcp is coming out other than security patches...
<philipp64>
I'm not convinced I've ever used the backtrace feature in DHCP...
<philipp64>
mangix: there... just disabled it for all builds.
<mangix>
only other packages that uses libunwind is openvswitch. everyone else disables it.