rmilecki has quit [Quit: Konversation terminated!]
Tapper has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
nitroshift has joined #openwrt-devel
plntyk has quit []
Tapper has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
Tapper has quit [Ping timeout: 482 seconds]
Tapper has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<Tusker>
heya guys, if earlcon is working, but as soon as it switches to console, it no longer prints anything, how can I debug it when it looks the same config between the two ?
<Tusker>
actually, that's a bad example of failure, because I've already fixed "gsbi 16600000.gsbi: missing mode configuration". It is still not printing anything afterwards
<PaulFertser>
Tusker: you have earlycon=msm_serial_dm,0x16640000 but [ 2.387784] 16340000.serial: ttyMSM0 at MMIO 0x16340000 (irq = 37, base_baud = 1562500) is a MSM
<PaulFertser>
Tusker: doesn't look same to me
<Tusker>
16340000 and 16640000 are two serial lines
<PaulFertser>
Tusker: and HSL0 is not mentioned at all in the log
<PaulFertser>
(I see, it's ignored, right)
<PaulFertser>
Tusker: you're using one range for earlycon but then tell the kernel to switch to another range, no wonder it doesn't work.
<PaulFertser>
And "ttyMSM1 at MMIO 0x12490000" which is yet another base address
<Tusker>
ah, yeah, weird, I wonder where I have 16340000 defined
<Tusker>
https://termbin.com/bnns is what I have now, where I switch to using MSM1 instead of MSM0 which does have a different address
<PaulFertser>
Tusker: it's odd it helped but seems to be working
<Tusker>
I am going to disable the gsbi4_serial, to see if that gets rid of 16340000
<PaulFertser>
Tusker: do you have a datasheet for the SoC?
<PaulFertser>
Tusker: I mean what does memory map say about all those addresses?
rmilecki has joined #openwrt-devel
<Tusker>
16340000 is a normal UART on a lot of IPQ boards, but not this one
<Tusker>
but it seems like it enabled by default in the included dtsi
<PaulFertser>
rmilecki: hey :) was there any update regarding your mt7628 situation? Where do I find the follow up?
<rmilecki>
PaulFertser: i verified EEPROM, it looks good
<rmilecki>
PaulFertser: i pinged nbd again yesterday but no response
<PaulFertser>
Tusker: in other words, the official manual is not available at all?
<Tusker>
I can try and find it on the Extreme portal if you want it ?
<PaulFertser>
rmilecki: do you probably have a bug filed on mt76 github where you collect all the information including kernel messages and "eeprom" contents?
<rmilecki>
PaulFertser: i did another test yesterday: upgraded OpenWrt, moved router to another flat, switched channel 11 do 1, switched laptopt for a different one
<rmilecki>
PaulFertser: problem still occures
<PaulFertser>
Tusker: you're porting to this device, not me :) I'm just asking what I think is a very relevant question.
<PaulFertser>
rmilecki: hm, is it a single device or have you tried reproducing on another? Also, as silly as it may sound but have you tried putting the board under a fan, does it affect the outcome anyhow?
<rmilecki>
PaulFertser: i have only one 4C device but there are multiple reports of unstable WiFi
<PaulFertser>
rmilecki: so sad to hear your first experience with mt76 is _that_ problematic
<rmilecki>
PaulFertser: i've ordered 2 x Netgear R6220 today, they will arrive tomorrow
<rmilecki>
PaulFertser: i can understand there are bugs, i'm just getting disappointed by developers ignoring the report :(
<PaulFertser>
I mean if some RF part is overheating that might produce similar symptoms I guess.
<rmilecki>
PaulFertser: i'll check on evening if it overheats and try the fan, i'm not expecting much, but it's a simple test, why not
<nbd>
rmilecki: sorry for the lack of response, i simply don't have much time on my hands at the moment
<Tusker>
PaulFertser: any ideas why it fails just after qcom_rpm in my latest log ?
<rmilecki>
nbd: if you find a moment, i'll appreciate any hints on that, I can ship you that unit if needed
<rmilecki>
nbd: still there are other developers and Mediatek's ML, I hoped someone may reply
<PaulFertser>
Tusker: looks like it's disabling some voltage regulators at that moment
<Tusker>
yeah, I'll have to dig in the factory dmesg and see if I can spot anything
<nbd>
rmilecki: you could check if the issues are triggered by or happen around mac resets
<rmilecki>
nbd: can you paste a function name I should check (put some debugging in it)?
<rmilecki>
i'm not familiar with mt76 code (yet?)
<rmilecki>
ah, there is something like mt7603_mac_reset_counters
<rmilecki>
ok, that should be enough, I can track the rest
<rmilecki>
nbd: thanks, i'll do some debugging tomorrow or on Saturday
<nbd>
mt7603_mac_watchdog_reset
<nbd>
you can trigger reset by writing 1 to the debugfs reset_test file
<nbd>
to see if it triggers the issue or maybe brings the hw back out of the stuck state
<rmilecki>
nbd: thank you!
<Tusker>
PaulFertser: OK, cool, have a shell prompt now
<PaulFertser>
Tusker: nice
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
aleasto has joined #openwrt-devel
<Tusker>
PaulFertser: what about "qcom_nand.0: the ECC used on your system is too weak compared to the one required by the NAND chip" any ideas? :)
goliath has joined #openwrt-devel
Rentong has joined #openwrt-devel
<PaulFertser>
Tusker: oh, ECC on NAND is tricky business. And bad block markings. There're different ways to implement that and to store that (bad blocks tables and out of band data) and it should generally match between the kernel and bootloader; and in this case it seems NAND chip recommends some more redudant encoding than you specify in DT. But probably that's just the way it is _if_ it matches what
<PaulFertser>
bootloader does.
Tapper has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<Tusker>
PaulFertser: OK, I'll try and dig some more
<rsalvaterra>
ldir: Yeah, as I suspected, --bind-dynamic makes my configuration much, much more verbose. I really need the --bind-interfaces behaviour.
* ldir
finishes writing long email
nlowe has joined #openwrt-devel
nlowe has quit [Read error: Connection reset by peer]
<rsalvaterra>
xdarklight: Well, but that basically breaks hw flow offloading everywhere else, if I'm reading correctly. :)
aleksander has joined #openwrt-devel
<xdarklight>
rsalvaterra: I am not arguing with that :). I wanted to point out that Pablo's finding on the netfilter mailing list seems to be correct
<rsalvaterra>
xdarklight: Sure, which is why I pinged nbd, since he's the original author of the xt_FLOWOFFLOAD target.
SamantazFox has joined #openwrt-devel
<rsalvaterra>
What it seems is that it isn't such trivial fix. :)
<xdarklight>
I looked at the xt_FLOWOFFLOAD code myself and it raised more questions than I had before looking at the code. so I decided to wait for someone with better knowledge to look into that issue :)
<rsalvaterra>
Same here. I just went "oh, this requires divine intervention" and set it aside. :P
<nbd>
xdarklight: which finding did you mean?
<xdarklight>
nbd: "The xt_flowoffload module is inconditionally setting on the hardware offload flag" [...] flowtable[1].ft.flags = NF_FLOWTABLE_HW_OFFLOAD;
<rsalvaterra>
xdarklight: I don't think it's a no-op, otherwise he wouldn't carry it in his tree… maybe something's wrong in the table selection? table = &flowtable[!!(info->flags & XT_FLOWOFFLOAD_HW)]; does look correct, though.
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Rentong has quit [Remote host closed the connection]
lynxis has quit [Remote host closed the connection]
Tapper has quit [Ping timeout: 480 seconds]
lynxis has joined #openwrt-devel
Rentong has joined #openwrt-devel
<nbd>
xdarklight: well, it's not a no-op if the issue was reproduced with option flow_offloading_hw 1 in the config
<rsalvaterra>
nbd: Uh… If he has option flow_offloading_hw '1' on a system which doesn't support hw flow offloading… he gets to keep the pieces, right?
<nbd>
it shouldn't break
<nbd>
and normally i'd expect the generic flow offload api to be able to deal with it without attempting to re-enable hw offload over and over again
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Rentong_ has joined #openwrt-devel
Rentong_ has quit [Remote host closed the connection]
Rentong has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
SamantazFox has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Slimey_ has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
silver has quit [Quit: One for all, all for One (2 Corinthians 5)]
silver has joined #openwrt-devel
silver has quit []
Tapper has joined #openwrt-devel
silver has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
look has joined #openwrt-devel
look has quit []
look has joined #openwrt-devel
look has left #openwrt-devel [#openwrt-devel]
why has joined #openwrt-devel
why has quit []
nbd168 has joined #openwrt-devel
Tapper has joined #openwrt-devel
nbd168 has quit []
svanheule has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]