Hi, Am Samstag 23 Februar 2008 schrieb Tomasz Chmielewski: > Martin Steigerwald schrieb: > > (...) > > > And kernel 2.6.24 would be interesting in order to make WLAN work in > > case I want to have it. > > In case you don't know it already, see here: > > https://dev.openwrt.org/ticket/2035 > > Someone had this almost booting with 2.6.24, but I don't know what is > the state now. > > The good news is: BCM43XX boards are finally supported in 2.6.24 > kernel. The bad news is that only one BCM43XX device is supported > (Netgear WGT634U), and it's not our ASUS... Interesting to know. WLAN is no big priority for me, just nice to have in case I could put it to use on Linux User Group parties or maybe sometimes at home. I copied the system over to the cheaper / slower USB stick. Makes no difference on the ASUS. Now I already have a backup on my laptop HD ;-) What I like so far: 1) Fast boot times compared to the VIA box. Internet is available as soon as my laptop completed resuming from hibernation (TuxOnIce). This is how I wanted it. I could have optimized the boot times of the VIA box as well. It had an ext2 mit fsck fix option and thus bootet twice, but even when I changed to ext3 I think it would have been slower. That compact flash card did not do IDE, but thats not that much of an issue I think. I believe that the "BIOS" stuff on the ASUS is *way* faster. I wouldn't be surprised if the WL-500g is already booting the Linux kernel while the VIA box still does POST processing in the BIOS for seconds. 2) It works without swap space for my purpose. 3) Its so easy to make an backup or even exchange the Linux system by a different one. Which Linux do I want to plug in today? Sure that would have worked on the VIA box as well I think. At least its BIOS should support booting from USB. 4) WLAN is already integrated in case I ever want to activate it. Three hints I have for now: 1) I used commit=120 as ext3 mount option to reduce. No good idea. I good journal commit errors and after such one the box couldn't even open /bin/ls anymore. Ext3 was good and after a reboot it worked again for some time. Same with commit=30. Anyway according to vmstat 1 in my configuration the box just does not write to the USB stick during usual ADSL routing operation 2) Place RAMRUN=yes RAMLOCK=yes into /etc/default/rcS, in case you want to have /var/lock and /var/run on tmpfs automatically. You can specify a maximum size in /etc/default/tmpfs as follows: RUN_SIZE=500000 LOCK_SIZE=500000 3) In fstab I am using additionally: none /tmp tmpfs defaults,size=5M none /var/tmp tmpfs defaults,size=5M none /var/log tmpfs defaults,size=2M Appears to work like a charm. The box doesn't write that much logs. Could be a problem when running 24h a day, but right now I have connected it to the same mutiple socket outlet as my laptop and thus its switched of and on every now and then. At last I wonder why this doesn't work: # DSL auto dsl-provider iface dsl-provider inet ppp pre-up /sbin/ifconfig eth0 up # line maintained by pppoeconf post-up /usr/sbin/ntpdate-debian provider dsl-provider Time is not correct. I suspect some timing problem, i.e. ntpdate-debian is executed before ppp0 is really ready. Well the following appears to work: gayatri:/etc# cat rc.local #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. /usr/sbin/ntpdate-debian >>/tmp/ntpdate-debian /etc/init.d/openntpd restart exit 0 gayatri:/etc# cat /tmp/ntpdate-debian 23 Feb 11:17:42 ntpdate[966]: step time server 131.234.137.23 offset 257077012.342326 sec But its not optimal yet. I wonder if there is some standard mechanism for invoking ntpdate during startup. The existence of ntpdate-debian is a clear hint to me that there is. Well I think I shall read /usr/share/doc/ntpdate ;-) Enough for now. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: <http://lists.wpkg.org/pipermail/debian-non-standard/attachments/20080223/6096343b/attachment.pgp> |