Hi All,

it turns out that not being able/willing to read can make you do busy work. It 
seems I forgot to add  "firmware" as device to my mtd invocation… I guess I 
would never have tried the GUI if I had gotten the mtd command right the first 
time :)


best
        Sebastian


On Nov 13, 2013, at 00:06 , Sebastian Moeller <sebastian.moel...@gmail.com> 
wrote:

> 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 <moell...@gmx.de> wrote:
> 
>> Hi Richard,
>> 
>> 
>> On Nov 12, 2013, at 18:26 , Richard E. Brown <richb.hano...@gmail.com> wrote:
>> 
>>>> On Nov 12, 2013, at 4:11 AM, Sebastian Moeller <moell...@gmx.de> 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
>> Cerowrt-devel@lists.bufferbloat.net
>> 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
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Reply via email to