Hi Richard, hi Dave, hi list,
so I could not resist the lure of 3.10.18-1 and upgraded my 3.10.11-2.; which
turned out to be slightly more involved than I had expected.
1) SYSUPGRADE
root@nacktmulle:/# sysupgrade -d 60 -n
/home/persistent/cerowrts/3.10.18-1/openwrt-ar71xx-generic-wndr3700v2-squashfs-sysupgrade.bin
killall: watchdog: no process killed
Sending TERM to remaining processes ... netifd dynamic_dns_upd sleep minissdpd
lighttpd crond lighttpd pimd snmpd xinetd dbus-daemon dnsmasq zebra babeld
watchquagga smbd nmbd avahi-daemon ahcpd rngd ntpd ubusd askfirst
Sending KILL to remaining processes ... ubusd askfirst
Switching to ramdisk...
mount: /proc is not a block device
umount: /tmp/root: not mounted
Failed to switch over to ramfs. Please reboot.
Rebooting still returned me back to 3.10.11-2
2) MTD
root@nacktmulle:/tmp# mtd -r write /tmp/firmware.img
Usage: mtd [<options> ...] <command> [<arguments> ...] <device>[:<device>...]
The device is in the format of mtdX (eg: mtd4) or its label.
mtd recognizes these commands:
unlock unlock the device
refresh refresh mtd partition
erase erase all data on device
write <imagefile>|- write <imagefile> (use - for stdin) to device
jffs2write <file> append <file> to the jffs2 partition on the
device
fixtrx fix the checksum in a trx header on first boot
Following options are available:
-q quiet mode (once: no [w] on writing,
twice: no status messages)
-n write without first erasing the blocks
-r reboot after successful command
-f force write without trx checks
-e <device> erase <device> before executing the command
-d <name> directory for jffs2write, defaults to "tmp"
-j <name> integrate <file> into jffs2 data when writing
an image
-p write beginning at partition offset
-o offset offset of the image header in the partition(for
fixtrx)
-F <part>[:<size>[:<entrypoint>]][,<part>...]
alter the fis partition table to create new
partitions replacing
the partitions provided as argument to the
write command
(only valid together with the write command)
Example: To write linux.trx to mtd4 labeled as linux and reboot afterwards
mtd -r write linux.trx linux
Still no upgrade performed, but at least it is clearer why, my command was
incomplete… BUT I seem to recall that it was exactly this command that actually
allowed me to install 3.10.11-2 in the first place, weird.
3) LUCI
(http://gw.home.lan:81/cgi-bin/luci/;stok=19113c7f25269daca52ed92ef4d4b802/admin/system/flashops/)
I disabled the Keep Settings checkbox, uploaded the image (after making sure
/tmp had enough space) followed the "flash image…" link e voila, 3.10.18-1 up
and running in no time
I have no idea what the GUI actually does differently from calling sysupgrade
on the command line.
So the upshot is Juergen Botz is right and the GUI seems to work, at least if
one does not keep the old configuration. (And for that problem I followed caves
advice and just saved /overlay before upgrading, so I could see the old
configuration files and compare.)
Since I am using cerowrt as secondary router I have no input on the PPPoE
issues….
best
Sebastian
On Nov 12, 2013, at 22:17 , Sebastian Moeller <[email protected]> wrote:
> Hi Richard,
>
>
> On Nov 12, 2013, at 18:26 , Richard E. Brown <[email protected]> wrote:
>
>>> On Nov 12, 2013, at 4:11 AM, Sebastian Moeller <[email protected]> wrote:
>>>
>>>>> - Had to enable and set AQM parameters, since they’re saved differently
>>>>> from the QoS settings in the 3.7.5-2 firmware. Set parameters to ~ 90% of
>>>>> link speeds
>>>>
>>>> Just curious, did you specify overhead and encapsulation?
>>
>> No, I simply used the defaults on that page.
>
> Ah, you might want to try setting the link layer adaptation mechanism
> to tc_stab, the link layer to adls or atm and the overhead to 40 (or look at
> http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ to figure out the fixed
> per packet overhead of your link). This should allow you to specify a larger
> percentage of your link rate as shaped rate… But see the attached screenshot
> of my AQM tab
>
>
> <PastedGraphic-1.tiff>
>
>>
>>>>> - The kernel.log shows lots of the stack traces below: 2-5 per second on
>>>>> a long-term basis.
>>>>
>>>> These look quite weird, the error is a slow patch warning from
>>>> hfsc_schedule_watchdog . But, hfsc is the queuing discipline used by stock
>>>> OpenWrt, cerowrt , so far, has only used HTB (last I checked was cerowrt
>>>> 3.10.11-3). So my guess is that you were running the default QOS system
>>>> instead (or worse in addition) to cerowrt's. It would be great to see the
>>>> output of:
>>>> tc -d qdisc ; tc -s class show dev ifb0 ; tc -s class show dev ge00
>>>> to check what is up with the AQM system...
>>>>
>>>> Did you by any change use the QOS tab in 3.7.5-2 instead of running AQM or
>>>> simple_qos.sh from rc.local/ifup? If so did you direct sys upgrade to keep
>>>> the old configuration files?
>>
>> Yes, I was using QoS in 3.7.5-2, and I kept the old configuration files (so
>> I didn’t have to re-enter credentials for my DSL link, etc.) I guess it
>> seems likely that I may have been running *both* (!)
>
> Probably just QOS, as I think both QOS and AQM start out by tearing
> down all discs… but the hfsc error should not affect AQM since it uses HTB.
>
>>
>> Would a better upgrade path be to start with 3.7.5-2, then disable the QoS,
>> then flash with 3.10.18-1? (My intuition tells me that this would remove the
>> QoS settings from the loop…)
>
> Mhhh, I guess that should work.
>>
>> It’s pretty easy to re-flash with 3.10.18-1 and run the tc commands. If
>> disabling QoS makes sense, then after I do the ’tc’ experiment, I’ll
>> re-flash with 3.7.5-2, turn off QoS, then reflash to 3.10.18-1.
>
> This should not fix your PPPoE issues though… so maybe it is not the
> best time to switch…
>
>> But it’ll have to wait ’til dark so no one else is using it. :-)
>
> Hihi, same issue on my side :) No "playing" with the network while my
> wife is using it
>
> Best
> Sebastian
>
>
>>
>> Rich
>>
>>
>
> _______________________________________________
> Cerowrt-devel mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Sandra, Okko, Joris, & Sebastian Moeller
Telefon: +49 7071 96 49 783, +49 7071 96 49 784, +49 7071 96 49 785
GSM: +49-1577-190 31 41
GSM: +49-1517-00 70 355
Moltkestrasse 6
72072 Tuebingen
Deutschland
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
