Re: tap-to-click feedback
On Oct 22 2009, at 13:10, Chris Ball was caught saying: > Hi, > >> so: to eliminate tap-to-click, someone needs to build a new >> kernel with the synaptics driver enabled (maybe just the module >> can be built), then they need to figure out how to make it all >> work well. > > I might be wrong, but I think we just need the X driver -- yum install > xorg-x11-drv-synaptics. Xorg drivers are generally not layered on top > of kernel drivers, outside of the case of DRI. I recalled that I poked at this last year and there is a series of bugs I opened in trac around synaptics issues. See http://dev.laptop.org/ticket/9101. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] first play with new XO 1.5 machines
On Oct 20 2009, at 19:04, Tabitha Roder was caught saying: > no mesh network showing in neighbourhood My understanding is that mesh is not currently supported in the WLAN firmware for the new chips. I am not sure what the plan of action is in regards to mesh support for 1.5. > the new record activity has no camera, only audio! > camera issues... video for linux working but doesnt like what it > finds, a driver issue? doesnt know about the camera? tried looking for > it, lspci, lshal, lsmod, no luck The camera driver is still being worked on. > question - why is there a /media/boot in the frame next to the battery > indicator and volume indicator, The media is split into a /boot ext2 partition with the rest setup as ext4 so that OFW can read olpc.fth and do other operations without needing to have support for ext4. I noticed the inidicator too and find it very confusing from an end-user UI perspective. One should not be able to use the UI to unmount a device that one cannot get access to w/o taking the laptop apart. :) We probably want to either disable auto-mounting it or want to find someway to keep the sugar shell from displaying the icon. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OFW access from linux
On Sep 15 2009, at 17:31, Paul Fox was caught saying: > john wrote: > > > there's no SysRq key on the XO keyboard, so you'll need to use a > > > break on the serial console to invoke it... > > > > Please. If you're going to put this hook in, which I think is a great > > idea, at least make it work on the standard hardware! And when the > > operating system is not very responsive. That's when you'll need it > > for debugging or resetting the system. Without taking the plastic > > apart, finding a part with no known suppliers, and soldering it to > > your motherboard. > > i agree. getting the hook in place was a first step, and > satisfies my immediate need for wanting to be able to look at and > modify h/w registers during development -- the /proc trigger > is sufficient for that. we have a constant tension between "just > make it work on the XO" and "make it so we have a prayer of > merging it upstream without lots of pushback", and i confess i > erred towards the latter, this time. custom key combinations > would require more extensive changes to the input drivers than i > was willing to take on last night. ... > > > > There are some pretty obscure keys on the XO keyboard -- howabout > > something like holding down the leftmost and rightmost "gradually > > increasing sized dots" keys in the top row, and then pressing the > > M-for-Mitch key? > > i would applaud, encourage, and otherwise buy beer for anyone that > could help out in making something like this happen. (i might get > to it someday, myself, but that will no doubt be _after_ i need it.) I disagree. sysrq is the standard way of trapping keyboard sequences to cause special kernel actions. If you want another set of key sequences to make this happen, you probably want to trap it in X and have that send the proper sequnce to the /proc. I guess don't see the benefit of moving from a simple two key combination to some multi-key command. In the case that the kernel is hung to the point that we can't talk to it at all, if the hang is caused by an oops, we can have a patch that traps calls to die() and bug() and jumps to OFW. This is what KGDB does, so there is some precedent. We could also have some magic in the EC to look for a sequence of keys that signals a low-level handler to kick into OFW in the case of major lockup (assuming there's enough space in EC code space to do this...). I've not seen many total hangs that can't be fixed with some printk debugging + KGDB when it works. Or a JTAG unit, but I don't think we can do that on the XO, right? ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Disk layout for XO-1.5
On Jul 27 2009, at 13:27, Mitch Bradley was caught saying: > The filesystem is no longer internally compressed. The current size for > the XO-1.5 system is 1.1 GB. 2 GB gives some headroom for growth and > for temporary overages during updates. Chris, Are we stuck with 1.1GiB or do we think we can reduce that further? ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Disk layout for XO-1.5
On Jul 27 2009, at 12:17, Mitch Bradley was caught saying: > > / - 2 GB - ext4 > Contains system files How about having 2x1GiB system partitions so that instead of doing the symlink stuff we do right now, we can just mount the appropriate system parition as the root partition? Metadata for which partition contains the most recent OS image could be stored in /boot. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
On Jul 20 2009, at 16:49, Chris Ball was caught saying: > Hi, > >> perhaps this should be obvious, but can it handle S-states as >> well? because i believe that's the goal -- freeze the display >> and then go into S3. > > Looks like no. We could invent a C-state that traps to SMI and goes > to S3 except I hate this idea already. We can use a custom userspace governor that when switching states also freezed DCON. It's been a while since I looked at cpuidle but is on the queue of things to poke at. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO-1.5 Kernel Update (i.e My Weekly Status)
Last week was a busy week in XO-1.5 kernel land. * Attacked the DCON driver and it is now 75% functional. We can freeze/unfreeze, set brightness, and switch between color and monochrome mode via the syfs attributes. In the process of getting the DCON working, I broke USB and spent a day hunting down why. It turns out that the DCON interrupt line is connected to the SMBUS# signal which in turn generates an SCI (IRQ 3). This is the same IRQ that is used by ACPI and even though I did not configure the SMBUS alert IRQ, simply grabbing that irq via request_irq() causes USB device insertion (and other things?) to break. For now I've just disabled interrupts on the XO-1.5 build and I don't think that is a major issue as all we really do on XO-1 is dump a warning to the console in the case of a missed interrupt. I will have to revisit this later if we actually want to use the interrupt to sync frames. So far our minimal testing shows that we may be able to freeze on 5 seconds of inactivity instead of 30 and not see a glitch in the screen contents. The 25% that is not working is the irq mentioned above, getting sleep mode to work, and suspend/resume. * Started working on Linux Suspend/Resume. We are currently getting all the way up to USB resume and then locking up as we're going to sleep for 8ms but never waking up as our interrupts are not working. In the process of debuging Suspend/Resume, noticed that for some reason we were using the old kernel IDE stack instead of libata for our SSD device and I've switched the kernel over to the new code as it is more tested and maintained. This Week: * Primary task is to continue work on Suspend/Resume. * Spending Thursday flying back home from 1CC and will be taking Friday off. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] viafb: update driver to use both I2C Channels
On Jul 15 2009, at 22:17, Harald Welte was caught saying: > Hi Deepak, > > as I have pointed out a couple of times to some OLPC folks (not sure if you > were included), there is a via-viafb-i2c tree in my git tree > (http://git.gnumonks.org/cgi-bin/gitweb.cgi?p=linux-2.6-via.git;a=shortlog;h=refs/heads/via-viafb-i2c) > that tries to clean up the i2c mess (after cleaning up a lot of other mess). Hi Harald, I pulled in these patches and they look great but I'm seeing an additional 3 second delay during bootup (even after removing the KERN_DEBUG printk in via_i2c_setscl). I'll work on investigating why later as I'm focused on functionality at right now. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] viafb: update driver to use both I2C Channels
On Jul 15 2009, at 22:17, Harald Welte was caught saying: > Hi Deepak, > > as I have pointed out a couple of times to some OLPC folks (not sure if you > were included), there is a via-viafb-i2c tree in my git tree > (http://git.gnumonks.org/cgi-bin/gitweb.cgi?p=linux-2.6-via.git;a=shortlog;h=refs/heads/via-viafb-i2c) > that tries to clean up the i2c mess (after cleaning up a lot of other mess). > > I've submitted a long series of those viafb patches some time ago, but somehow > none of them was merged mainline yet :( > > Were you aware of this? If yes, then it means that you're reluctant to merge > the tons of not-yet-mainline cleanup code from my tree, which I could > understand, too. Nope, was not aware of this. Will grab that tree and take a look at it. Thanks, ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH] viafb: update driver to use both I2C Channels
The Chrome chip has two serial I2C channels and the
driver currently only exposes one of them. This patch
exposes both of them and also cleans up some structure
naming to be be less confusing.
This is specifically needed on the XO-1.5 platform as
the DCON chip is connected via Chrome I2C channel 0
and the current driver only exploses channel 1.
Signed-off-by: Deepak Saxena
---
This patch is not the cleanest way to export the second port, but
in my opinion the whole via_i2c code and its users need a rewrite
to use the driver model instead of what we're doing right now,
which is to have the chip drivers directly call the I2C read/write
functions after poking at the adapter's I/O address. This patch is
meant as a stop gap until that happens since I don't currently have
time to do a full cleanup and I need the both ports working ASAP. :)
Patch is against top of Linus' tree (e9e961)
drivers/video/via/chip.h |4 +-
drivers/video/via/dvi.c | 20
drivers/video/via/lcd.c | 10 ++--
drivers/video/via/via_i2c.c | 120 ++---
drivers/video/via/via_i2c.h |7 ++-
drivers/video/via/viafbdev.h |3 +-
drivers/video/via/vt1636.c |4 +-
7 files changed, 101 insertions(+), 67 deletions(-)
diff --git a/drivers/video/via/chip.h b/drivers/video/via/chip.h
index dde95ed..442cd8a 100644
--- a/drivers/video/via/chip.h
+++ b/drivers/video/via/chip.h
@@ -107,7 +107,7 @@ struct tmds_chip_information {
int dvi_panel_id;
int data_mode;
int output_interface;
- int i2c_port;
+ int i2c_ioport;
int device_type;
};
@@ -116,7 +116,7 @@ struct lvds_chip_information {
int lvds_chip_slave_addr;
int data_mode;
int output_interface;
- int i2c_port;
+ int i2c_ioport;
};
struct chip_information {
diff --git a/drivers/video/via/dvi.c b/drivers/video/via/dvi.c
index d696544..f826aaf 100644
--- a/drivers/video/via/dvi.c
+++ b/drivers/video/via/dvi.c
@@ -96,7 +96,7 @@ int viafb_tmds_trasmitter_identify(void)
viaparinfo->chip_info->tmds_chip_info.tmds_chip_name = VT1632_TMDS;
viaparinfo->chip_info->
tmds_chip_info.tmds_chip_slave_addr = VT1632_TMDS_I2C_ADDR;
- viaparinfo->chip_info->tmds_chip_info.i2c_port = I2CPORTINDEX;
+ viaparinfo->chip_info->tmds_chip_info.i2c_ioport = I2CPORT1INDEX;
if (check_tmds_chip(VT1632_DEVICE_ID_REG, VT1632_DEVICE_ID) != FAIL) {
/*
* Currently only support 12bits,dual edge,add 24bits mode later
@@ -107,10 +107,10 @@ int viafb_tmds_trasmitter_identify(void)
DEBUG_MSG(KERN_INFO "\n %2d",
viaparinfo->chip_info->tmds_chip_info.tmds_chip_name);
DEBUG_MSG(KERN_INFO "\n %2d",
- viaparinfo->chip_info->tmds_chip_info.i2c_port);
+ viaparinfo->chip_info->tmds_chip_info.i2c_ioport);
return OK;
} else {
- viaparinfo->chip_info->tmds_chip_info.i2c_port = GPIOPORTINDEX;
+ viaparinfo->chip_info->tmds_chip_info.i2c_ioport =
GPIOPORTINDEX;
if (check_tmds_chip(VT1632_DEVICE_ID_REG, VT1632_DEVICE_ID)
!= FAIL) {
tmds_register_write(0x08, 0x3b);
@@ -120,7 +120,7 @@ int viafb_tmds_trasmitter_identify(void)
tmds_chip_info.tmds_chip_name);
DEBUG_MSG(KERN_INFO "\n %2d",
viaparinfo->chip_info->
- tmds_chip_info.i2c_port);
+ tmds_chip_info.i2c_ioport);
return OK;
}
}
@@ -160,8 +160,8 @@ int viafb_tmds_trasmitter_identify(void)
static void tmds_register_write(int index, u8 data)
{
- viaparinfo->i2c_stuff.i2c_port =
- viaparinfo->chip_info->tmds_chip_info.i2c_port;
+ viaparinfo->i2c_port1.i2c_ioport =
+ viaparinfo->chip_info->tmds_chip_info.i2c_ioport;
viafb_i2c_writebyte(viaparinfo->chip_info->tmds_chip_info.
tmds_chip_slave_addr, index,
@@ -172,8 +172,8 @@ static int tmds_register_read(int index)
{
u8 data;
- viaparinfo->i2c_stuff.i2c_port =
- viaparinfo->chip_info->tmds_chip_info.i2c_port;
+ viaparinfo->i2c_port1.i2c_ioport =
+ viaparinfo->chip_info->tmds_chip_info.i2c_ioport;
viafb_i2c_readbyte((u8) viaparinfo->chip_info->
tmds_chip_info.tmds_chip_slave_addr,
(u8) index, &data);
@@ -182,8 +182,8 @@ static int tmds_register_read(int index)
static int tmds_register_read_bytes(int index, u8 *buff, int buff_len)
{
- viaparinfo->
Re: [Techteam] end-of-week
Last week: * Major task was finishing up merge of XO-1 and XO-1.5 kernel. See posting on olpc-devel [1] for details. * Worked on some minor bugs and cleanup. * Helped Richard a bit with debugging USB serial issues related to Linux driver that talks to multi-battery charger. * Worked on DCON code. There was some confusion on my end on whether Harald was doing the DCON work an after talking to him it appears that he is not and is pretty swamped with other things right now. He has agreed to look at the viafb bugs. This week: * Primary task is DCON driver. ~Deepak [1] http://lists.laptop.org/pipermail/devel/2009-July/024939.html , tested, and published a new kernel for XO-development ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] build kernel-firmware rpms again
applied, tnx.
~Deepak
On Jul 09 2009, at 17:17, Martin Dengler was caught saying:
> ---
> olpc/SPECS/kernel-xo1.5.spec | 37 +++--
> olpc/SPECS/kernel-xo1.spec | 37 +++--
> 2 files changed, 70 insertions(+), 4 deletions(-)
>
> diff --git a/olpc/SPECS/kernel-xo1.5.spec b/olpc/SPECS/kernel-xo1.5.spec
> index 32f2c3f..67615ac 100644
> --- a/olpc/SPECS/kernel-xo1.5.spec
> +++ b/olpc/SPECS/kernel-xo1.5.spec
> @@ -14,6 +14,8 @@ Summary: The Linux kernel (the core of the Linux operating
> system)
> %define builddoc 0
> %define buildkdump 0
> %define buildheaders 1
> +# kernel-firmware
> +%define with_firmware %{?_with_firmware: 1} %{?!_with_firmware: 0}
> %define _enable_debug_packages 0
>
> # Versions of various parts
> @@ -54,6 +56,7 @@ Summary: The Linux kernel (the core of the Linux operating
> system)
> %define buildxen 0
> %define buildkdump 0
> %define all_arch_configs $RPM_SOURCE_DIR/kernel-xo1.5-custom.config
> +%define with_firmware 1
> %endif
> # Don't build 586 kernels for RHEL builds.
> %if 0%{?rhel}
> @@ -73,6 +76,7 @@ Summary: The Linux kernel (the core of the Linux operating
> system)
> %define buildup 0
> %define buildheaders 0
> %define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-*.config
> +%define with_firmware 0
> %endif
>
> # kdump only builds on i686, x86_64, ppc64 ...
> @@ -215,7 +219,7 @@ Summary: The Linux kernel (the core of the Linux
> operating system)
> # Packages that need to be installed before the kernel is, because the %post
> # scripts use them.
> #
> -%define kernel_prereq fileutils, module-init-tools, initscripts >=
> 8.11.1-1, dracut, dracut-modules-olpc >= 0.2.0
> +%define kernel_prereq fileutils, module-init-tools, initscripts >=
> 8.11.1-1, kernel-firmware >= %{rpmversion}-%{pkg_release}, dracut,
> dracut-modules-olpc >= 0.2.0
>
> Name: kernel
> Group: System Environment/Kernel
> @@ -323,6 +327,21 @@ header files define structures and constants that are
> needed for
> building most standard programs and are also needed for rebuilding the
> glibc package.
>
> +
> +%package firmware
> +Summary: Firmware files used by the Linux kernel
> +Group: Development/System
> +# This is... complicated.
> +# Look at the WHENCE file.
> +License: GPL+ and GPLv2+ and MIT and Redistributable, no modification
> permitted
> +%if "x%{?variant}" != "x"
> +Provides: kernel-firmware = %{rpmversion}-%{pkg_release}
> +%endif
> +%description firmware
> +Kernel-firmware includes firmware files required for some devices to
> +operate.
> +
> +
> %prep
> #if a rhel kernel, apply the rhel config options
> %if 0%{?rhel}
> @@ -518,7 +537,9 @@ Config=kernel-xo1.5-custom.config
> fi
>
> mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
> -make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
> KERNELRELEASE=$KernelVer
> +# Override $(mod-fw) because we don't want it to install any firmware
> +# We'll do that ourselves with 'make firmware_install'
> +make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
> KERNELRELEASE=$KernelVer mod-fw=
>
> # And save the headers/makefiles etc for building modules against
> #
> @@ -805,6 +826,11 @@ rm -f $RPM_BUILD_ROOT/usr/include/asm*/atomic.h
> rm -f $RPM_BUILD_ROOT/usr/include/asm*/io.h
> rm -f $RPM_BUILD_ROOT/usr/include/asm*/irq.h
> %endif
> +
> +%if %{with_firmware}
> +make INSTALL_FW_PATH=$RPM_BUILD_ROOT/lib/firmware firmware_install
> +%endif
> +
> ###
> ### clean
> ###
> @@ -888,6 +914,13 @@ fi
> /usr/include/*
> %endif
>
> +%if %{with_firmware}
> +%files firmware
> +%defattr(-,root,root)
> +/lib/firmware/*
> +%doc linux-%{kversion}.%{_target_cpu}/firmware/WHENCE
> +%endif
> +
> # only some architecture builds need kernel-doc
>
> %if %{builddoc}
> diff --git a/olpc/SPECS/kernel-xo1.spec b/olpc/SPECS/kernel-xo1.spec
> index feb2b65..46b3f5d 100644
> --- a/olpc/SPECS/kernel-xo1.spec
> +++ b/olpc/SPECS/kernel-xo1.spec
> @@ -14,6 +14,8 @@ Summary: The Linux kernel (the core of the Linux operating
> system)
> %define builddoc 0
> %define buildkdump 0
> %define buildheaders 1
> +# kernel-firmware
> +%define with_firmware %{?_with_firmware: 1} %{?!_with_firmware: 0}
> %define _enable_debug_packages 0
>
> # Versions of various parts
> @@ -54,6 +56,7 @@ Summary: The Linux kernel (the core of the Linux operating
> system)
> %define buildxen 0
> %define buildkdump 0
> %define all_arch_configs $RPM_SOURCE_DIR/kernel-xo1-custom.config
> +%define with_firmware 1
> %endif
> # Don't build 586 kernels for RHEL builds.
> %if 0%{?rhel}
> @@ -73,6 +76,7 @@ Summary: The Linux kernel (the core of the Linux operating
> system)
> %define buildup 0
> %define buildheaders 0
> %define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-*.config
> +%define with_firmware 0
> %endif
>
> # kdump only builds on i686, x86_64, ppc64 ...
> @@ -215,7 +219,7 @@ Summa
Re: New kernel branch for XO-1 and XO-1.5 development
On Jul 08 2009, at 22:27, John Gilmore was caught saying: > Congratulations on the merge. > > > Note that currently there is nothing keeping anyone from installing a > > kernel meant for one gen machine on a different gen machine. Just > > don't do that. :) > > Eventually if both machines are going to run a standard Fedora > release, the same binary kernel will have to be able to run on both > (and figure it out at runtime, like it does with most other x86-based > systems). I'm presuming from your message that that's scheduled to > happen some time ... later ... What I plan on doing is adding something to the pre-install section of the RPM to check for the proper generation of board. Given that we are building the for completely different CPU core, we will need different kernel RPMs to make sure our kernel is optimized for the given machine. This will not affect our ability to run the standard Fedora userland on top of our kernel. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New kernel branch for XO-1 and XO-1.5 development
I've spent some time merging the XO-1 and XO-1.5 kernels into a new
branch and made some tweaks to the in-kernel RPM build scripts. From
now on, all development for both XO-1 and XO-1.5 will be done on the
olpc-2.6.30 branch of the olpc-2.6 repository [1]. As Linus releases
new kernels, I will be rebasing [2] the OLPC changes on top of Linus'
releases and creating new olpc-${kernelversion} branches to make it
easier to move our code forward and upstream.
Since the kernels for the two generations of XO boards have been
merged, I've had to change the commands for building RPMs and
kernels. These are:
make xo_1_defconfig: configure kernel for OLPC XO-1
make xo_1.5_defconfig : configure kernel for OLPC XO-1.5
make xo_1-kernel-rpm : build XO-1 kernel RPM
make xo_1_5-kernel-rpm : build XO-1.5 kernel RPM
make olpc-kernel-rpm : build both XO-1 and XO-1.5 kernel RPMs
To differentiate between an XO-1 and XO-1.5 RPM, the generation
name is now inserted into the RPM name. For example:
kernel-2.6.30_xo1-20090708.1.olpc.1fd3a66.i586.rpm <- XO-1 RPM
kernel-2.6.30_xo1.5-20090708.1.olpc.1fd3a66.i586.rpm <- XO-1.5 RPM
Note that currently there is nothing keeping anyone from installing a
kernel meant for one gen machine on a different gen machine. Just
don't do that. :)
I've also added the ability to build RPMs from trees that have
non-commited changes. If this is done, the RPM will be tagged
as dirty:
kernel-2.6.30_xo1-20090708.1.olpc.1fd3a66_DIRTY.i586.rpm
I will update wiki with this information.
Enjoy,
~Deepak
[1] dev.laptop.org:/git/olpc-2.6
[2] http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
for manpage, http://www.eecs.harvard.edu/~cduan/technical/git/git-5.shtml
for a quick summary.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: 1.5 power management, input events, wakeup events
On Jun 25 2009, at 09:49, Chris Ball was caught saying: > The complexity of implementation is real, but it turned out that Mitch > had to do the work of adding ACPI tables for Windows anyway. Being > able to suspend/resume on unmodified distro kernels (and not having to > constantly maintain and forward-port "the OLPC suspend/resume patch" > every release) will be a big win, worth some hours of our time in > setting up ACPI. I'd like to second Chris on the benefits of running something that is already well supported under Linux and allows us to use standard PM tools. One concern I have is whether ACPI provides the granular control over wakeup events that we desire. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO-1 2.6.30 kernel
I've updated the OLPC git tree with a new xo-v2.6.30 branch. Please use this for an XO-1 development and testing. We're currently are not auto building RPMs out of this branch and this is not currently a priority for me. For those on XO-1.5, I will update that kernel in the next few days. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: equivalent copy-nand interface ideas for XO-1.5
On Jun 14 2009, at 11:00, Paul Fox was caught saying: > i won't quote anything you wrote, because i have nothing to > add to your lists of pros and cons of those methods. Ditto. +1 on the original proposal. > another possibility: size the original fs image to the size of > the data it will hold: i.e., create a filesystem with no free > space. this will eliminate the sparseness issue when > distributing. use OFW to write this in a raw, filesystem-unaware > manner. mark the file system in such a way that the initrd will > know (or perhaps it will simply guess, based on sizing) to resize > the filesystem before mounting, in order that it fill the > available space. my impression is that the extN filesystems are > fairly easy to grow in place? EXT2+ can be grown in place. My concerns with this approach are: It would add more delay to initial post-flash bootup. This could be trivial and not noticeable so we should measure it. More importantly, if we encounter powerfail or some other scenario that causes the resize to not complete, we will probably end up with an unuseable filesystem. I suppose this is no different of a concern than powerfail in the middle of OFW updating the system. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: libertas private ioctls
On Jun 11 2009, at 14:49, Daniel Drake was caught saying: > On Thu, 2009-06-11 at 08:42 +0000, Deepak Saxena wrote: > > My quick answer is to move these forward from our old kernel. We can try > > pushing them upstream too but I would like to understand why we need them > > and if there are alternatives such as sysfs that we could use. > > Would it be appropriate to include that specific command (ledgpio 1 1 2 > 12 3 16, whatever it is) in the kernel so that no userspace intervention > is needed to turn the LEDs on? I'm a little aprehensive about that option. Where would the command go? I'm wondering if this would be a good place for using platform device data? ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: libertas private ioctls
On Jun 10 2009, at 11:48, Daniel Drake was caught saying: > Hi Deepak, > > In OLPC OS 8.2, libertas had private ioctls > which /etc/init.d/olpc-configure used to configure the LEDs: > iwpriv eth0 ledgpio 1 1 2 12 3 16 > > These aren't present in the 2.6.30-rc5 kernel I am running on my XO-1, > and presumably neither on the xo-1.5 kernel. > > I think the ledgpio command is needed for correct behavior of the LEDs > on the mesh. I have mesh working with NM-0.7/F11 but the LEDs are > silent. How should we solve this? My quick answer is to move these forward from our old kernel. We can try pushing them upstream too but I would like to understand why we need them and if there are alternatives such as sysfs that we could use. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Bye Bye For Now
Hi all, Tommorrow is my last day as an employee with OLPC and I am sad to be leaving this amazing project. It's been fun and educational to be involved in working on full product as opposed to just working with other low level developers. I hope to be able to give back as a volunteer in the future but in the near term I need to go focus on finding new work. Thanks and Good Luck, ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Jan 06 2009, at 14:42, Chris Ball was caught saying: > Hi, > >> I think I missed the previous conversation, re: estimate , but I'm >> thinking that swap will have significant impact on the lifetime of >> the flash chip. With only 256MiB of RAM, we are bound to swap a >> lot. I'd feel more comfortable if we did flash-wide wear leveling >> using UBI and created a swap partition on to pof that. > > That's fine with me too. Are we still planning on moving to UBI for > 9.1? If not, maybe we can work out how to get swap files working on > JFFS2 (where they would be wear-leveled)? At this point, with < 2 months to desired release date, I do not support changing the filesystem. If we think a new filesystem is a priority (and not everyone does from other conversations I've had), we can intergrate it into joyride as soon as 9.1 is out the door so we have plenty of time to do formal testing and get end-user feedback. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Jan 06 2009, at 14:23, Chris Ball was caught saying: > Hi, > >> Now, the question I have is why we would chose GNOME over XFCE. I >> think there are significant differences in system resource >> consumption. > > We had a long thread about whether to use GNOME or XFCE on devel@ last > month. I suggested XFCE, and was persuaded that the disk image size > of DebXO+GNOME is not significantly different than DebXO+XFCE, and that > both run fine without swap, suggesting that we might be able to pull off > GNOME on Fedora. If we find it unbearable, I'm fine with using XFCE > instead, but my impression was that GNOME is preferred. > > (For the record, I'm not against investigating adding some swap for 9.1 > now that we have NAND partitioning available. We'd have to be more sure > of our estimate that it won't significantly shorten the lifespan of the > flash chip, though. What do people think?) I think I missed the previous conversation, re: estimate , but I'm thinking that swap will have significant impact on the lifetime of the flash chip. With only 256MiB of RAM, we are bound to swap a lot. I'd feel more comfortable if we did flash-wide wear leveling using UBI and created a swap partition on to pof that. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Building Custom Kernel RPMS
Hi, I've added a new feature to the OLPC kernel tree that should make building custom kernel RPMs from our git tree a bit simpler for anyone who wants to do so. Basically once you have the git tree checked out and have commited your changes, you can run 'make olpc-kernel-rpm' from the top of the kernel directory to build src, binary kernel, debuginfo, devel, and kernel-header RPMs that will be found in the "olpc/RPMs" directory of the kernel. Note that you must commit changes first and the command will not run if you have uncommited changes or untracked files in your repository. This is done b/c the script uses the tree's HEAD commit ID for naming the kernel and w/o this precaution, we could end up with two kernel RPMs floating around that have the same commit ID but differing source trees. Note also that this command only works on testing (8.2) and master (joyride) kernel branches and not the stable (8.1) branch. Note that this still requires a Fedora/RHEL system to build kernels, or a functioning mock/chroot setup (untested so far). I have tested on F10 and FC6 systems. Please let me know if you have any problems on other systems. I will update Wiki with these directions. # make olpc-kernel-rpm HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # NOTE: You can ignore the following error...I need to make # it not run a silentdefconfig first. # scripts/kconfig/conf -s -o arch/x86/Kconfig *** *** You have not yet configured your kernel! *** (missing kernel .config file) *** *** Please run some configurator (e.g. "make oldconfig" or *** "make menuconfig" or "make xconfig"). *** make[2]: *** [silentoldconfig] Error 1 make[1]: *** [silentoldconfig] Error 2 CLEAN scripts/basic CLEAN scripts/kconfig CLEAN include/config ... Wrote: /mnt/filer/dsaxena/olpc-2.6/olpc/SRPMS/kernel-2.6.25-20081219.1.olpc.deab9f6.src.rpm Wrote: /mnt/filer/dsaxena/olpc-2.6/olpc/RPMS/i586/kernel-2.6.25-20081219.1.olpc.deab9f6.i586.rpm Wrote: /mnt/filer/dsaxena/olpc-2.6/olpc/RPMS/i586/kernel-devel-2.6.25-20081219.1.olpc.deab9f6.i586.rpm Wrote: /mnt/filer/dsaxena/olpc-2.6/olpc/RPMS/i586/kernel-headers-2.6.25-20081219.1.olpc.deab9f6.i586.rpm Wrote: /mnt/filer/dsaxena/olpc-2.6/olpc/RPMS/i586/kernel-debuginfo-common-2.6.25-20081219.1.olpc.deab9f6.i586.rpm Wrote: /mnt/filer/dsaxena/olpc-2.6/olpc/RPMS/i586/kernel-debuginfo-2.6.25-20081219.1.olpc.deab9f6.i586.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.60442 + umask 022 + cd /mnt/filer/dsaxena/olpc-2.6/olpc/BUILD + cd kernel-2.6.25 + rm -rf /var/tmp/kernel-2.6.25-20081219.1.olpc.deab9f6-root + exit 0 Thanks, ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride SD card corruption
On Dec 15 2008, at 08:23, Deepak Saxena was caught saying: > nn Dec 12 2008, at 11:34, Mikus Grinbergs was caught saying: > > WARNING -- since about build 2590 I can get my "permanent" SD card > > (ext2 filesystem) completely corrupted - I've had to restore it > > twice. [This is a regression - with 2583 and earlier I never saw > > any SD corruption. Note that my systems have multiple USB devices.] > > Hi Mikus, > > Can you re-test with 2586 and then 2587? 2587 brought in a I mean 2588 insted of 2587 here if you decide to do a full build update. I miss-read the logs. Thanks, ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride SD card corruption
nn Dec 12 2008, at 11:34, Mikus Grinbergs was caught saying: > WARNING -- since about build 2590 I can get my "permanent" SD card > (ext2 filesystem) completely corrupted - I've had to restore it > twice. [This is a regression - with 2583 and earlier I never saw > any SD corruption. Note that my systems have multiple USB devices.] Hi Mikus, Can you re-test with 2586 and then 2587? 2587 brought in a kernel configuration change (CONFIG_USB_SUSPEND) and I'm wondering if it is the root cause. You can just update the kernels if you feel comfortable updating kernel RPMS as per http://wiki.laptop.org/go/Kernel#Installing_OLPC_kernel_RPMs. 2587: http://dev.laptop.org/~dilinger/master/kernel-2.6.27-20081210.1.olpc.05aa2d840dc7b96.i586.rpm pre-2587: http://dev.laptop.org/~dilinger/master/kernel-2.6.27-20081201.1.olpc.672cde9409f412e.i586.rpm Thanks, ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 8.2.1 Bug review meeting - 1 PM EST Friday 12/12/08
On Dec 11 2008, at 13:38, p...@laptop.org was caught saying: > ed wrote: > > Folks - > > > > We?re trying to get a very focused 8.2.1 release wrapped up to address a > > small number of problems affecting or blocking key country deployments of > > 8.2. A few bugs have been tagged for an 8.2.1 milestone (fifteen of them), > > i went looking for a canned report to find those 15 tickets for > me. i found two: http://dev.laptop.org/report/34 and 35. > > clearly i don't understand how reports work, because they each > return 323 tickets, in different orderings, 8 of which are marked > as blockers. My interpreation of Ed's email was that we are to review all 323 8.2.1 tickets tommorrow(!), not just the 15. Ed, can you clarify? Thanks, ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] cafe_nand: remove busy-wait loop
On Dec 09 2008, at 16:05, Daniel Drake was caught saying: > This patch enables interrupts for DMA and command completion events, and > uses them to determine when commands and transfers have completed. > > This avoids a busy-wait loop which was a waste of CPU time. > > Signed-off-by: Daniel Drake <[EMAIL PROTECTED]> Looks good, but since we're just checking for one bit, I think we can we just use an atomic_t instead of needing a whole spinlock. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power Management plan for December.
On Nov 28 2008, at 16:18, Chris Ball was caught saying: > Hi, > > This e-mail describes the work plan for power management during December. > I've filed bugs for each item, so this plan is the list of bugs that > should be fixed during December. Thanks for putting this together. > Bugs I will need significant help to fix: > > * #6818 -- Make the multicast wakeup filter work with collaboration > (Ricardo Carrano?) > * #7958 -- DCON flicker on resume > (kernel regression; perhaps Deepak, Andres, Mitch, or Adam Jackson?) > * #9054 -- Speed up USB resume > (kernel) ... > Comments welcome. Are there important power management bugs that I've > left out? #7458 -- Intermittent timeouts during WOL suspend/resume stress. We need to solve this if we want to implement more aggressive suspend/resume. My suggestion for this one is to get Javier, Richard, and either myself or Andres in the same room so we can simultaneously trace the issue at kernel, network, EC, and WLAN firmware levels. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch pads
On Nov 25 2008, at 18:13, Richard A. Smith was caught saying: > Touchpad problems are listed in many deployments. Our biggest hurdle to > fixing it having reliable way to duplicate the problem. It seems to > happen lots out in the wild its very hard to reproduce on demand and its > pretty rare here at 1cc. > > The 8.2 kernel has a bunch of stuff to try to help but without solid > test cases its a bit of guess work to see what difference the new > changes have. > > We have a new touchpad that queued up for production. That will hit > sometime next year when the current supply is out. Initial reports are > that its much better than the current model. However see my next, post. > That may not solve it 100% Can we get some of the new touchpad laptops out to locations that have reported issues due to heat/moisture to see how they respond? It would good to get some data and fix any issues before we roll these out en masse. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Module loading problem in joyride?
On Nov 22 2008, at 08:40, Mitch Bradley was caught saying: > There are two things that could have changed - either RTIME compression > was added to the mkfs.jffs2 configuration, or it was removed from the > kernel configuration (or both). My best guess is that it was removed > from the kernel at some point, because I know that, at least at one > point in OLPC's past, RTIME compression was enabled. I know this > because there was an OFW bug in which OFW encountered an > RTIME-compressed node and couldn't handle it. OFW now supports RTIME > decompression. Your guess is correct. I got overzealous when I disabled LZO and disabled RTIME in the config. > The best solution would be: > > a) In mkfs.jffs2, turn off RTIME compression so it is never used in > pristine filesystems > b) In the kernel, enable both CONFIG_JFFS2_RTIME and JFFS2_CMODE_PRIORITY > > The suggested kernel setting makes the RTIME decompressor available if > needed, but ensures that when zlib (higher priority) succeeds, the > kernel won't waste time on RTIME. There's still some time wasted when > zlib can't reduce the size - instead of just punting and storing an > uncompressed node, it will try RTIME. Ideally, it would be better to > disable RTIME decompression entirely, so as not to waste that time. > While there is a #define to do that - JFFS2_RTIME_DISABLED - I see no > Kconfig option to control it at that .config level. There is CONFIG_JFFS2_RTIME option. Will re-enable it and and push to master. I agree that ideally we should just disable it but as per Daniel's experience this will break unless we change the mkfs.jffs2 option. Even if we do the later, it will lead to issues if someone tries to mix and match new kernels with older builds. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: RW Compressed FUSE FSs? (Re: XS - XO archiving and backup)
On Nov 10 2008, at 11:08, Martin Langhoff was caught saying: > On Mon, Nov 10, 2008 at 10:49 AM, Greg Smith <[EMAIL PROTECTED]> wrote: > > On backup and restore, aside from the comments already mentioned, I > > suggest you pay careful attention to the available space on your XS. You > > should have about 2GB free space on your XS for each XO. If you don't > > have enough space it may move some of the files over your wireless LAN > > then not save them on the XS. > > Excellent point. Which leads to a request - good references on a well > behaved compressed FUSE FS that > > - supports RW > - behaves well with rsync (which I presume mmaps files liberally) > - supports hardlinks and ACLs > > As a happy user of large hard drives, I haven't needed a compressed FS > since the unhappy days of DRDOS so I'm rusty on this front. There's a > listing at http://fuse.sourceforge.net/wiki/index.php/CompressedFileSystems > but I know nothing about the quality, reliability and performance. I took a look at these and in summary, only the following options seem useable for the XS scenario as the remainder are for cramfs, loopback, read-only or other non-general purpose use. compFUSEd Not 100% of status. Last update was May 1, 2007. LZOlayerFS Has not been updated since Feb 2006 so I say that is an immediate NO IMHO unless we want to take over the project. fuseCompress Looks to be in active development. Last Git update was 11/02 and there is a steady stream of updates for the last two months. > I care mainly about the reliability -- but it better be fast too. > Compression ratio is perhaps more negotiable, the other two arent :-) I think the next step in determing which (if any) of the above would meet the XS needs is to start pounding on them with LTP, iozone and other performance/stress/compliance tests to see how well they all work. Beyond performance, I'm worried about stability/maintainability. Regular filesytems get a lot of testing by a whole lot of people and when a major bug hits, we know it will be fixed ASAP. I don't know if the same can be said of externally maintained filesystems. I suggest we also engage with the developers of the three alternatives above and let them know that we're considering deploying them on the XS. Note that there is also an ext3 compression extension that is probably worth investigating, though this requires custom kernel packaging. That being said, I think we also need to get a really good idea of just how much data is already compressed. (We need same data to determine whether to enable or disable compression on /home/olpc on the XO itself). Running a FUSE layer will defintely result in performance degradation (which also means increased power consumption) and to go through the whole process of compressing blocks to discard the results for the majority of blocks would be a resource waste. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ACPI on XO
On Nov 03 2008, at 17:11, Richard A. Smith was caught saying: > Jordan Crouse wrote: > >> appropriate hook. But if we want to suspend on idle, then we need to >> do it while are... you know... idle - so something has to live there. >> >> I think we are basically saying the same thing here - userspace needs >> to give us the go-ahead to suspend, and we need to have the right >> latency programmed so that if all is well, we just suspend. Or at least, >> we'll try to suspend and hope like heck it works. > > I appear to have completely the wrong idea of what cpuidle would do for > us then wrt suspend decisions. I thought that cpuidle had the ability > to report that the _system_ was idle. For example if we are doing lots > of DMA the cpu usage is very low but the system is far from idle. Only > the kernel has the proper knowledge of everything thats going on under > the hood. So CPUIdle can theoretically do things like change cpu idle states based on DMA latency requirements that are programmed via the new PM QOS interface; however, that interface is not too well defined. I just had a conversation with one of the TI-OMAP Linux developers and they have hooks in their CPUidle code to detect bus master activity to determine what state they can be in. On their end this is done by using the clock framework in the kernel to see if any bus master devices are in use and whether it is safe to go into full idle state (C6, which on their chip is == OFF). We could do something similar by having a C state that is full suspend and doing simple checks like "is the audio device open", but this requires trusting applications to not open a device and just keep it open while it is not in use. Or we could add a "cpuidle" state to /sys/power/state and when OHM knows that it is safe for us to suspend on idle, it can write that to the file. > Where the ultimate decision to suspend is made doesn't seem to so > important as the getting the inputs to that decision correct. We don't > appear to have a plan on how to get all the inputs. Do we? No we don't and I really need to help out with the kernel side of things but I'm not sure I knows all the requirements and use cases which is the first step. We need to list out all the decision criteria then figure out: 1. Where that information is currently stored 2. Where it needs to go for the suspend decision (OHM, an in-kernel structure, ?) 3. How to get it there (uevent, in-kernel callback, userspace helper, ?) ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ACPI on XO (was: Re: [Techteam] Weekend 10/31)
On Nov 03 2008, at 13:41, Jordan Crouse was caught saying: > The concept of suspend is muddled greatly with kernel and userspace folks > both participating in the discussion and coming at the problem from > different directions. As Deepak says, the dream is to put the whole system > to sleep on a very long idle interval where other processors would be in a > deeper C state. To do this, we need to know certain kernel timing > information that we can compare to our worse case suspend/resume time and > make a reasonable choice to attempt to enter a suspended state. So in > that regard, it does help us determine if we want to try to sleep, but its > only one of a number of inputs into the black box - some of which are > determined in userspace through OHM, and others which are determined > by the kernel. > > Presumably the cpuidle code would kick into XO specific code at some point > which would check that all of the other suspend inputs are green before > doing the deed. The funny thing is that this isn't so dissimilar from how > ACPI works. Right, and at that point, we're not doing "cpuidle", we're doing full system state assesment and I don't think doing that in the kernel in the middle of the idle loop is the best thing to do and we would probably have to add a lot of interfaces into the kernel to manage all that information. We could alternative add a callback into a userpsace helper in an OLPC-specific cpuidle governer but jumping back into userspace from this deep in the idle path is probably very unsafe to do. The simplest thing to do would be to have our device present a state that has a very long latency value corresponding to full system suspend so that the existing framework can just work. I'm not sure how well the kernel would handle us triggering a suspend from within the kernel either, but only one way to find out. :) ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] Weekend 10/31
On Nov 03 2008, at 12:45, Richard A. Smith was caught saying: > > drivers/acpi/processor_core.c: > result = cpuidle_register_driver(&acpi_idle_driver); > > looking at this file I see that its called from > > static int __init acpi_processor_init(void) > > This is the same routine that creates a /proc/acpi directory which does > not exist on the XO so that plus the fact that I know we have ACPI > disabled I'm assuming that this routine is not called. > > Further greping for 'cpuidle_' I find that the only places cpuidle_ > functions are called is in drivers/acpi/processor_core.c and > driver/acpi/processor_idle.c . > > If its used in another archs besides x86 can you point me to the code? > Perhaps I'm not grepping for the right thing? drivers/acpi/processor_idle.c:acpi_processor_power_init() calls driver/cpuidle/cpuidle.c:cpuidle_register_device(). This in turn calls cpuidle_install_idle_handler() which sets the pm_idle pointer to cpuidle_idle_call(). pm_idle() is called by arch.x86/kernel/proccess_32.c:cpu_idle(). cpu_idle_call() calls the governor's select() function which pokes at various the bits int the cpuidle_device structure and the current system state to determine the next state and returns an index into the cpuidle_device's state table. We then index into the state table, and call the state's enter() function to perform the actual CPU swtich. It looks like to make it work with a non-x86 arch, one would have to hook the pm_idle() call into the the cpu_idle() routine, for example arch/arm/kernel/process.c:cpu_idle() on ARM. In our case, we would want to register an olpc_idle_driver and an olpc_idle_device that exports the known states. Once those are in place, the generic x86 cpu_idle() call will call into them via the framework. > [1] cpuidle is very hard to google for usage info. There is lots of > unrelated hits that use the term cupidle. Is there a good reference for > the stuff thats exposed to userspace other than whats in the kernel docs? I haven't found anything super useful except for reading the code. linux-pm list is probably the best place to go for more details. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
ACPI on XO (was: Re: [Techteam] Weekend 10/31)
[cc:ing devel] My understanding of cpuidle is that it is designed to be fairly CPU/system agnostic with a clean driver interface to allow for tweaking the CPU/SOC idle control. There is even an ARM port [1] but as you will see in that email, the nomenclature for CPU idle states has been heavily borrowed from the ACPI definition (C-states) as that is what the X86 world uses everywhere. If we dont' want to use ACPI (my vote), I'm thinking we can write a a low level driver that talks directly to the HW to move us between "C-states". Looking at the Geode documentation [2], it only seems to support running, halt, and sleep state (Jordan, is this correct?) and I can't imagine it being difficult to write a driver to switch between these if the raw HW is documented. I want to make sure everyone understand what CPUIdle does as I've heard some comments that lead me to believe people expect more out of it. It is meant as a framework to help move the CPU between high and low latency idle states based on recent CPU usage patterns, latency requiremenents and any other things that we care about in the heureistic algorithm (the governor). We still have to things like keep track of how long it has been since a user interacted with the device and whether the audio devide is open, etc to determine whether we want to do a full system suspend or not. While we could push all that into the governor, I think it would be massively overiding the framework. I want to clarify this b/c I recall someone saying something along the lines that cpuidle will help us figure when to suspend and that is not the case. It is meant only for CPU idle state management, In our case, when the system is fairly idle, we want to put the whole system to sleep, not just the CPU. ~Deepak [1] https://lists.linux-foundation.org/pipermail/linux-pm/2008-February/016546.html [2] May 2008 version, Page 599, Power State Parameter Definitions On Nov 03 2008, at 10:11, Adam M Belay was caught saying: > Hi Richard, > > That's correct, there shouldn't be any hard dependencies with ACPI. > However, it > was the first interface supported, so there could be some cruft > remaining. I'd > be interested in hearing more about the issue. > > Thanks, > Adam > > Quoting "Richard A. Smith" <[EMAIL PROTECTED]>: > >> Jim Gettys wrote: >>> CPU idle shouldn't be entangled with ACPI. People on non-x86 will care. >>> >>> So think your proposed "fix" is wrong; but should go into trac against >>> the kernel, and a patch for the fundamental kernel fix developed >>> - Jim >>> >> >> I hope that indeed I'm incorrect on this but when I tried to follow >> the code init/working path for cpuidle thats where I wound up. >> >> If the kernel hackers can give me a quick 2nd opinion I'll be happy to >> file a bug with the results. >> >> -- >> Richard Smith <[EMAIL PROTECTED]> >> One Laptop Per Child >> > -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 2.6.27 artifact ?
On Oct 31 2008, at 22:10, Mikus Grinbergs was caught saying: > Joyride 2521. When as root I type in the 'passwd' command (in > Terminal) and it asks me for the new UNIX password, I see 14 > repetitions of the message: >(data fread failed): Input/output error That looks like a library/application message as there are no kernel timestamps; however, certainly could be something underneath that is bork. Running with strace/ltrace would be useful. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On Oct 30 2008, at 10:05, Erik Garrison was caught saying: > Deepak, > > Did you continue down this path (auto-saving application state to NAND > when we run out of memory)? How tenable is the idea of saving > application state to NAND on our system? No I haven't. :( > Could the oom-killer have a hook to enable this functionality to be > invoked instead of simply killing the application? Yes, the question is what is the proper interface back to user space. In talking to some upstream kernel developers,this type of interface has been desired by others but nothing has been accepted upstream. Next step in this process is research what has been proposed so far, why they've all failed, and figure out what we want to do. One such interface is proposed at http://lwn.net/Articles/267013/. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] Postponement of XOCamp Event to January
On Oct 29 2008, at 21:52, Ed McNierney was caught saying: > Folks - > > The OLPC XOCamp event being planned for November 17  21 is being postponed > until January, 2009. The Fedora FUDCON conference is in Boston on January 9 > - 11 , and we will be rescheduling to dates either immediately before or > immediately after that event. I¹d like to make that decision as soon as > possible, so if anyone knows of major reasons to choose one over the other, > please let me know. I think the week after would best. If we go with the week before, that is right after new year's which means more expensive flights and a higher chance of folks still travelling. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Allowing an activity to be launched multiple times in parallel
On Oct 29 2008, at 19:40, Benjamin M. Schwartz was caught saying: > Asheesh Laroia wrote: > > I have a general sugar UI question: My activity, "License", a simple comic > > book reader <http://wiki.laptop.org/go/License> that has a license chooser > > aspect to it, can be launched multiple times if clicked multiple times > > from the activity launcher. > > > > To me, that seems silly. Is it normal for Sugar activities to be able to > > be launched multiple times like this? > > I don't understand. Why are you surprised? This is how every multitasking > OS works*. What the underlying OS does and what the application framework chooses to do are separate things. My Palm phone and the Google Android phones are both running Linux at its core but I can only run one instance of and application in each of those. I think our usage model should more closely resemble that of cellphone/MID device than the desktop model. > Under Gnome, if I launch Totem twice, I get two Totem windows. Under > Windows, if I launch IE twice, I get two IE windows. Under Sugar, if I > launch Write twice, I get two Write windows. On my KDE3 desktop, If I launch Kontact and then launch Kontact again, I don't get another window b/c it makes no sense for that application. On the XO, if we try to edit two documents concurrently on Write, we should in my opinion only have on instance of write running which can switch quickly between document objects so the user percieves it as two separate instances. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
9.1 Proposal: Filesystems
Hi, As has been discussed on the list many times, we need to replace JFFS2 ASAP, and ideally on the 9.1 release. I will like to provide an overview of the issues we've seen, a summary of the alternatives, where we are at in testing those, and how this change will impact the software stack from kernel up through Sugar. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
9.1 Proposal: Deailing with Low Memory/OOM
I would like to present a short session and faciliate the follow up discussion on and dealing with the memory constraints on our system at an application framework level. >From my understanding, there are two situations we are running into with low memory that need separate solutions: 1) A single running application, Browse for example, chews up lots of memory. The only real solution I can think of to this is to make the applications and underlying libraries leaner and smarter. :) 2) End users run multiple applications or multiple instances of the same application, quickly chewing up system resources. I would like to primarilly focus on dealing with (2). I've done a bit of reading on how other low memory systems (cell phones for example) handle running multiple tasks and would like to propose we borrow some of these ideas for Sugar. In Android for example, when a user switches between tasks, the framework will tell switched out task to save enough state such that it can handle being killed while in the background. The user does not know that a background application is dead and on task switch back to that application, the framework will restart the application and tell it that it should restore state and not do a cold startup. I need to read more of the Android and Sugar docs before I can have a detailed proposal but at a high level my proposal is to add similar smarts to our framework. This includes, but is not limited to: - Adding Sugar APIs to handle cold activity start vs restart from saved state and modifying activites to support these APIs. - Make the Sugar framework (or some other system component) talk to the kernel's OOM interface (/proc//oom) to manage what tasks should be killed and ensure the foreground process does not get killed. What I'm proposing is a form of cooperative multitasking managed at the application framework level instead of the core OS level. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Master kernel in Joyride.
On Oct 16 2008, at 20:18, Chris Ball was caught saying: > Hi Deepak/Andres, > > Now that the Joyride floodgates are open, which kernel branch do you > recommend we start testing in Joyride for the 9.1 release? If the > master branch, are there any regressions in it compared to the testing > branch? Which of 2.6.2[567] should we aim to ship with 9.1? See Jeremy's message for kernel version. For now let's just stick to testing branch as master is still on 2.6.26, not been updated since july, and does not have various things from testing in it. I'll work with Dilinger on getting 2.6.27 + testing forward ports next week. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Master kernel in Joyride.
On Oct 16 2008, at 21:11, Jeremy Katz was caught saying: > On Thu, 2008-10-16 at 20:18 -0400, Chris Ball wrote: > > Now that the Joyride floodgates are open, which kernel branch do you > > recommend we start testing in Joyride for the 9.1 release? If the > > master branch, are there any regressions in it compared to the testing > > branch? Which of 2.6.2[567] should we aim to ship with 9.1? > > If 9.1 isn't going to be released for about six months, I'd suggest > actually waiting and picking a later kernel -- at least 2.6.28 (likely > release in January), possibly 2.6.29 (probably April) depending on the > exact schedule for 9.1. Ack. But to get there, we definetely want to get k.org latest into testing so we find issues in conjunction with changes to kernel.org ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Updated UBIFS 8.2 image
On Oct 14 2008, at 15:13, John Watlington was caught saying: > > I get 898,452 KiB free, on several machines. > How did you get 921,000 KiB free ? My bad, accidently used 'df -H' instead of '-h' in my initial check. So we now have ~878MiB available instead of 822. That's better but that is still 71Mib (~8%) overhead for the filesystem. 8Mib of that (~1%) is reserved for the journal, and the rest is being used for index data (as UBI keeps the fs index on-flash which is one way it decreases boot time vs jffs2) or not properly accounted for. I'll keep working with Artem upstream on understanding the overhead and where we can tweak it. One obvious way to do this is to decrease the journal size at the expense of some performance as we have to commit more often. There is also an index fanout option to mkfs.ubifs that I need to understand a bit better. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Updated UBIFS 8.2 image
Hi, I have updated the UBIFS 8.2 image on d.l.o with a new kernel that includes various backports from kernel.org. One major change that is noticeable is that the free space calculation reports 921MiB free instead of 822MiB due to improved df reporting. I've also disabled debug messages and this will improve performance (UBI attach time dropped from 50s to < 2s). Directions for installation: * Make sure your XO has security disabled * Make sure your XO is running the latest OFW. The best way to do this is to update it to 8.2.0. * Download the following files to a USB stick: http://dev.laptop.org/~dsaxena/ubi_test/data.img http://dev.laptop.org/~dsaxena/ubi_test/nand.img * Boot the laptop with USB stick and escape into the OFW prompt. * Run: ok dev nand : write-blocks write-pages ; dend write-blocks isn't unique # You can ignore this ok update-nand u:\data.img * At this point OFW will erase the flash and copy the contents of the nand.img file to flash. When complete you can simply reboot the system. Thanks to Artem Bityutskiy for backporting the changes. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: enabling and disabling file compression
On Oct 13 2008, at 14:59, Tomeu Vizoso was caught saying: > Hi Chris and Deepak, > > in Ubifs, I have tried unsetting the compression xattr on files, but > reads were equally slow so I guess the contents weren't actually > uncompressed. Even tried dd'ing to an empty existing file without the > c attribute, but the result was the same. Any idea what I'm doing > wrong? I _think_ the slowness we are seeing might be a side effect of me having enabled various debug messages in both the UBI and UBIFS layer. I am rebuilding the image with a new kernel and will post after I do some testing here. > Chris, I think you worked on improving the control of on-the-fly > compression in jffs2, can we control it using the c attribute as in > ubifs? I've talked to David Woodhouse about this in the past and it shouldn't be too hard to do as the ioctl() handler is already in place, it just means adding a flag to the inode (and each block?) and a check at read()/write() time. One question I've wondered about is what is the meaning of disabling compression on a file that has already been written to flash compressed? Do we decompress the file and re-write it to flash or do we just wait until an update that touches the data? ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: UBIFS 8.2 image
On Oct 10 2008, at 16:26, John Watlington was caught saying: > > Still trying to reproduce the first weirdness I saw, but I've already > run into pretty much the same problem with my standard test. > > I installed UbiFS as indicated. > > I installed 16 files of size 32 MB in the root partition. > df indicated around 50 MB free. > > I started a loop of reading two files and comparing them, > then writing two 10MB files, reading them back (and > comparing them), then deleting them. Repeat ad-infinitum. > After 11 cycles, writing files to the file system started failing. > (Read-only file system) Making sure I grok. You got an error saying that the filesystem was read-only? ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
UBIFS 8.2 image
Hi, I have created an initial UBIFS 8.2 image that can be used for testing and playing with. See http://wiki.laptop.org/go/UBIFS_initial_experiments for information on how this was created and some of my intial notes. If you just want to download and run: * Make sure your XO has security disabled * Make sure your XO is running the latest OFW. The best way to do this is to update it to 8.2.0. * Download the following files to a USB stick: http://dev.laptop.org/~dsaxena/ubi_test/data.img http://dev.laptop.org/~dsaxena/ubi_test/nand.img * Boot the laptop with USB stick and escape into the OFW prompt. * Run: ok dev nand : write-blocks write-pages ; dend write-blocks isn't unique # You can ignore this ok update-nand u:\data.img * At this point OFW will erase the flash and copy the contents of the nand.img file to flash. When complete you can simply reboot the system. If you want to know a bit more about UBIFS, why we're looking at it, and the overall impact a switch over would have, see the following page that is still under development: http://wiki.laptop.org/go/UBIFS_on_XO Thanks to Mitch Bradley for his help with OFW and Erik Garrison for his OFW image builder script. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
File systems usage patterns and NAND lifetime
I attended and Embedded Linux Conference [1] last week at which I saw a great talk on "Managing NAND Over A Product Lifecycle" [2]. The speaker presented the case of determining whether a choosen NAND HW and SW combination will survive the estimated lifecycle of a product. As an example, he used a GPS device his firm worked on in which they had some very specific usage data such as: - The average runtime for the device is 4 hours a day, during which we will see 100bytes/second of application logs written, 2300 bytes written for the addressbook, 1KiB/second used for temporary storage as mapes are decompressed. - The user will on average update the map data from his/her PC every such that it requires 3GiB writes/quarter. - OS and application updates require 32MiB/quarter. There were many other data points, please refer to the slides for full details. With this data, they were able to generate an I/O model of the application that was used to drive nandsim, an in-kernel NAND device simulator. By doing this, they were to replicate the product's expected lifetime before user replacement (3 years) in a matter of a few days. nandsim + the UBI reporting mechanisms were used to generate detailed reports of the wear leveling behaviour of the system, how the filesystem reacted to bitflips, bad pages, etc. Using this they were able to determine how to layout their filesystem and to meet the lifecylce requirement. After this was done, they used the same I/O model was used to rapidly drive a real device toward failure modes to see how it would react. If it didn't survive for the expected lifecycle, they could analyze the data and figure out what settings to tweak. In this talk I also learned about the MLC NAND property of "read disturbance", where a read to one page can cause a bit-flip on an adjacent page. I found the talk fascinating and it has made me wonder if we have any idea what our typical deployed usage patterns might look like? How often does the journal write to disk and how big is each write write? How often do systems reboot and require a full filesystem read vs simply suspending/resuming? Related to this topicm I am also wondering what is the expected usable life of the XO? We're used to product replacement every few years, sometimes faster depending on the product segment, but I doubt countries that are investing $millions expect to only get 2-3 years of use out of the XO. ~Deepak [1] http://mvista.com/vision/ [2] http://www.mvista.com/download/fetchdoc.php?docid=329 -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: UBIFS todo
On Oct 06 2008, at 19:12, Michael Stone was caught saying: > On Mon, Oct 06, 2008 at 02:46:58PM -0700, Deepak Saxena wrote: >> - Get ubi-utils into our buildsystem so that we can use it for building >> official UBI images. This means either doing our own builds, or >> preferrably, packaging it into fedora as an official package. > > I think this might be spelled 'mtd-utils-ubi' in Fedora? (It's available > for F9 and F10 as a binary subpackage of the mtd-utils source package.) /me not being a regular fedora user, I'm not sure how to grab a sub-package, but I did install mtd-utils and while it does have some ubitools, it seems out of date as it is missing ubinize and mkfs.ubifs. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Oct 05 2008, at 10:50, Jim Gettys was caught saying: > On Sat, 2008-10-04 at 16:32 -1000, Mitch Bradley wrote: > > > I have considered something like that off and on. It's sort of nice to > > have a definite length for the images. There are ways around that, but > > they are a bit ugly at some level. It's sort of a tossup at some level. > > > > One difficultly with having a lot of partitions is that it makes it more > > likely that you will encounter the resizing issue. > > > > > Ubifs is built on the Ubi layer, which handles resizing (and does so in > the face of flash errors). UBI may handle resizeable volumes but I think for our use case, we want static volume sizes. > http://www.linux-mtd.infradead.org/doc/ubi.html#L_autoresize > > Then again, since ubifs mounts quickly, the largest reason for > partitioning we've had (to reduce boot time) evaporates. There may be > other reasons to want partitioning, given dynamic resizing a'la lvm, > however. > > If we go to non-bare flash, of course, other solutions will have to be > found. We'll still need to support existing deployed laptops so I see the what type of flash do we use in future updates problem as orthogonal to replacing the filesystem on current HW. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: UBIFS todo
[cc:ing devel to keep everyone in the loop] On Oct 06 2008, at 13:01, Erik Garrison was caught saying: > 1) drop ubifs module into initramfs > > 2) take initramfs and build ubifs image of / into redboot partitioned image I'm working on the updates to the initramfs, getting a kernel image, and a script that will take a tar.bz2 of a given build and turn it into the appropriate ubi + jffs2 images which can then be fed into your script [1] to generate the proper bits for the OFW flash updater [2]. I hope to have all this done by late this week and have a booting 8.2 running UBI. This will just be a 32MiB jffs2 with the rest of the flash devoted to the system partition. Beyond that, other work that needs to be done: - Get ubi-utils into our buildsystem so that we can use it for building official UBI images. This means either doing our own builds, or preferrably, packaging it into fedora as an official package. - Update our official biuld scripts with my script above and your script so that we can spit out UBI images at build time. - Figure out a proper partitioning scheme. I don't think just having a boot partition one UBI volume are what we want to do for long term and I'll outline reasoning and proposal in another email. - Add UBI support to OFW. I keep being convinced that this is not needed, but if we want to support flashing over an existing UBI image, I think we really want to do it the right way and not loose the UBI metadata between updates. Mitch, your thoughts here? - Figure out how to handle the case of upgrading from 8.x to a UBI-enabled 9.x. > 3) test > > repeat on errors. [1] http://dev.laptop.org/git?p=users/erik/olpc-image-tools;a=summary [2] http://wiki.laptop.org/go/OFW_NAND_FLASH_Updater ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Oct 04 2008, at 16:32, Mitch Bradley was caught saying: >> We can probably just get away with making all of /boot into a >> romfs; however, do we even need to bother with a filesystem >> representation of the images? We could have four partions (kernel0, >> kernel1, initrd0, initrd1) that contain the binary data for current and >> alternate images and some sort of way >> to tell which one is current and which one is alternate. >> >> ~Deepak >> >> > I have considered something like that off and on. It's sort of nice to > have a definite length for the images. There are ways around that, but > they are a bit ugly at some level. It's sort of a tossup at some level. > > One difficultly with having a lot of partitions is that it makes it more > likely that you will encounter the resizing issue. +1. I'm also thinking that romfs overhead is minimal enough that it is not going to hurt boottime. > On a related topic, I would like to see us start bundling the initrd > into the kernel image. It's certainly possible to do that with existing > kernel mechanisms. The two pieces are interdependent enough that they > really have to be updated together, at which point it's really better to > have them in the same image. This is on the packaging todo list; however, if we move to a non-module kernel, then the initramfs contents will be completely independent of the kernel build so we may want to just keep them as separate packages? ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Oct 04 2008, at 19:24, Deepak Saxena was caught saying: > On Oct 04 2008, at 15:49, Mitch Bradley was caught saying: > > c) Raw FLASH read time maxes out at 20 MB/sec. But you don't get that > > speed from the filesystem; JFFS2 is good for between 5 and 10 MB/sec. > > > > Considering all the intricacies of JFFS2, my best guess is that it's > > going to be close to a wash whether the kernel + initrd is stored in > > compressed or uncompressed form. > > > > OTOH, if the kernel + initrd were in a separate partition in e.g. romfs > > format, where OFW could just blast them into memory without doing JFFS2 > > node processing, we could probably get close to the 20 MB/sec speed. > > We can probably just get away with making all of /boot into a > romfs; however, do we even need to bother with a filesystem > representation of the images? We could have four partions > (kernel0, kernel1, initrd0, initrd1) that contain the binary s/binary/raw/ > data for current and alternate images and some sort of way > to tell which one is current and which one is alternate. > > ~Deepak > > -- > Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Oct 04 2008, at 15:49, Mitch Bradley was caught saying: > c) Raw FLASH read time maxes out at 20 MB/sec. But you don't get that > speed from the filesystem; JFFS2 is good for between 5 and 10 MB/sec. > > Considering all the intricacies of JFFS2, my best guess is that it's > going to be close to a wash whether the kernel + initrd is stored in > compressed or uncompressed form. > > OTOH, if the kernel + initrd were in a separate partition in e.g. romfs > format, where OFW could just blast them into memory without doing JFFS2 > node processing, we could probably get close to the 20 MB/sec speed. We can probably just get away with making all of /boot into a romfs; however, do we even need to bother with a filesystem representation of the images? We could have four partions (kernel0, kernel1, initrd0, initrd1) that contain the binary data for current and alternate images and some sort of way to tell which one is current and which one is alternate. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Oct 03 2008, at 07:34, Mitch Bradley was caught saying: > > > > Could somebody explain me whether [the 5 second boot] results are > > applicable to the > > XO, and how far are we from it, please? > > > > > > Ticket http://dev.laptop.org/ticket/4349 details my and codyl's > experiments with speeding up boot. Some other ideas: - Right now the firmware copies the uncompressed kernel and initrd to memory and then the kernel and initrd decompressor has to re-read it from memory and write it back out in decompressed format. If it is stored deocompressed to begin with on the filesystem, we can simply read it into mem from flash and run. This would require a few extra MiB of flash. Granted, reading from flash is slower than reading from memory, so we may not see a a net benefit. Easy enough to test... - Embedded systems often use a suspend image to speedup boottime. Basically load an image into memory and then jump into the kernel as if we are resuming from firmware. Another approach if we can't do a full suspend image this is to use the new container code and save the runtime of the user session so we can just reload it. Both these methods require flash space... ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Oct 03 2008, at 08:08, Mitch Bradley was caught saying: > > > > neither of these require any changes to the Fedora stuff (I do this on > > every system that I run, have done so with many different distros, and > > never run into problems) > > > > remember that you can still have modules for USB devices, but not need > > to use any of them at boot time (if there are no USB devices plugged in) > > As mentioned, our wireless module is on an internal USB port. To what > extent does that complicate the situation? With the module_init_deffered() stuff we can move the init of the libertas out of the critical path. The reason we modularized USB AFAIK is to keep it out of the resume path when not in used but I forget that there is also a bind/unbind to driver functionality that can be used to to achieve the same. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On Sep 23 2008, at 03:40, Albert Cahalan was caught saying:
> Determining the RAM requirement for an activity goes something like
> the following:
>
> awk '/Dirty/{x+=$2} END{print x}' < /proc/12345/smaps
>
> (after exercising all functionality)
I like the idea overall but this part worries me. An activity such
as etoys has a lot of functionality.
> We can refine that, remembering that it will never be perfect.
> Adding a bit more (5 megabytes?) to avoid the slows is important.
>
> If an activity has lied, there isn't much that can be done. Oh well.
> If the lie is caught before the system gets horribly slow, the OS
> can simply increase the reservation for that activity. (either just
> for that session, or persistently) The OS can log the problem, allowing
> the activity developer to be flamed. Killing the lying activity is not
> a good option, but it could be done, especially if some other activity
> is already running. Once the slows hit, it's back to the power button.
> BTW, the alternative is far more harsh yet easier for kids to deal with.
> We just ditch the whole idea of letting activities run concurrently. :-)
> Seriously, consider it. We're really short on RAM, and activity switching
> is not at all easy for kids.
I've been thinking to myself that this might be the right approach. While
we may think of that as limiting, for a child who has never used a computer
before, it might help focus their attention and be less confusing to
simply allow one instance of any activity to run.
We can also play tricks like saving state of an activity to flash on
alt-tab and quickly restoring it when tabbing back. This is common
in the mobile space where we want an illusion of being able to switch
between running applications. Your cellphone will most probably
never crash due to OOM, but you can often run multiple applications
on it. This won't work with shared activities or activities that
have any network sockets open, but for purely local applications
it should be do-able (though non-trivial).
Something else I am looking into for helping with memory on 8.2.1 and
9.1 is compressed caching. We can still OOM with this, but my experience
with my little playing I've done with it is that it drastically helps
keep the system useable as memory footprint increases.
~Deepak
--
Deepak Saxena - Kernel Developer - [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Libertas firmware on F9 for the XS
On Sep 14 2008, at 18:36, Martin Langhoff was caught saying: > On Sat, Sep 13, 2008 at 12:30 PM, Deepak Saxena <[EMAIL PROTECTED]> wrote: > > Well, my job description is simply "kernel guy", not tied to XO > > or XS, so I will build something against your F9 kernel that you > > can test and will volunteer myself to keep XS libertas in sync > > with XO libertas until we get our kernel in sync with Fedora. > > That sounds fantastic. From what I see, we'll have to be wired to > supply a complete kernel rpm, as the libertas driver comes with the > kernel rpm. It it possible for you to build kernels in a reasonably > timely fashion following Fedora's security updates? Doesn't have to be > immediate, but the XS has more "internet exposure" than the XO. Hmm, that's a bummer. I was hopeing I could package the driver modules separately. I'll talk to Dave Jones, the Fedora kernel maintainer this week and see if this is doable. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Libertas firmware on F9 for the XS
On Sep 12 2008, at 17:08, Martin Langhoff was caught saying: > On Fri, Sep 12, 2008 at 4:42 PM, Deepak Saxena <[EMAIL PROTECTED]> wrote: > > On Sep 12 2008, at 14:12, Martin Langhoff was caught saying: > >> On this same thread, yesterday... Deepak Saxena <[EMAIL PROTECTED]> wrote: > >> > For the XO 8.2 kernel we had to pull forward some patches from the stable > >> > 2.6.22 branch that are not upstream to get multicast RX to work properly > >> > (#7319). > > > > Some clarifcation. The issue is not the firmware, but the kernel driver > > itself as there are pieces from the 2.6.22 driver that never made it > > upstream. > > Yup it's an incompatibility between the stock F9 kernel and the recent > firmwares. > > > My suggestion is to run the same driver and firmware on both XS and XO > > so we do not have multiple variables to deal with. > > I generally agree, but unfortunately, that adds significant work (of > carrying custom-compiled drivers) to a tiny team of 2. We don't have a > kernel maintainer in the XS team :-/ Well, my job description is simply "kernel guy", not tied to XO or XS, so I will build something against your F9 kernel that you can test and will volunteer myself to keep XS libertas in sync with XO libertas until we get our kernel in sync with Fedora. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Libertas firmware on F9 for the XS
On Sep 12 2008, at 14:12, Martin Langhoff was caught saying: > On Fri, Sep 12, 2008 at 1:49 PM, Ricardo Carrano <[EMAIL PROTECTED]> wrote: > >> In short, I need an overview of what works and what doesn't with F9 > >> stock kernel and 22.p18. So far: > >> > >> - Deepak mentions issues w/multicast > > > > I'm not sure exactly of what we're talking about here. Could you or > > Deepak clarify what are these issues? > > On this same thread, yesterday... Deepak Saxena <[EMAIL PROTECTED]> wrote: > > For the XO 8.2 kernel we had to pull forward some patches from the stable > > 2.6.22 branch that are not upstream to get multicast RX to work properly > > (#7319). Some clarifcation. The issue is not the firmware, but the kernel driver itself as there are pieces from the 2.6.22 driver that never made it upstream. My suggestion is to run the same driver and firmware on both XS and XO so we do not have multiple variables to deal with. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Libertas firmware on F9 for the XS
On Sep 10 2008, at 11:04, Martin Langhoff was caught saying: > Now that I have a F9-based XS build, I've dropped the custom-compiled > driver and the firmware for Libertas, hoping to use the stock standard > F9. > > But that might be a bit optimistic :-) > > After a quick check it looks like the XO images are shipping newer > Libertas firmware as you can see below. The XO builds also have a few > problems with the Firmware too, so I'm not entirely sure what to do... > > - F9 libertas-usb8388-firmware-5.111.20.p49-1 > - F9/XO (8.2-759) libertas-usb8388-firmware-5.111.22.p18-1 > > The main question for Libertas experts from the POV of the XS is: what > firmware is most stable? On the XS power consumption and sleep are not > high priority. Stability and performance over long periods of time is. > > Also - should I look at replacing / recompiling the driver that F9 > ships? (Hoping not...) If you say yes, be aware it is a major > maintenance hassle for the already short-handed XS team, so I'll want > to know what benefits it brings. I think for both FW and kernel driver, it depends on what features you need. For the XO 8.2 kernel we had to pull forward some patches from the stable 2.6.22 branch that are not upstream to get multicast RX to work properly (#7319). Firmware wise, .22 includes a fix for #7973. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On Tue, Sep 09, 2008 at 05:10:41PM +, Deepak Saxena wrote: > > * We need to find out why the oom-killer is not killing things fast > > enough. Based on our results, we might consider configuring > > /proc/$pid/oom_adj to preferentially kill some processes (e.g., the > > foreground [or background?] activities.) > > In the cases I've been playing with, browse is the only activity that > is running. Will try bumping its oom_adj to see if this improves OOM > kill latency. Did 'echo 15 > /proc/pid/oom_adj`' and this does not help much. The system starts getting laggy at the point we reach about 3M remaining memory (according to top) but the OOM killer does not actually kick in until we fail an allocation which happens sometime in later. Need to capture what is happening at the kernel level during this window though I don't think that fixing this at the OOM killer layer is doable for 8.2. > I have yet to see an actual deadlock. What I saw when trying to > reproduce #3816 is that the OOM killer just takes a very very long > time to kick in. > > > - whether our kernel "overcommits" when allocation requests are made? > > By default vm.overcommit_memory is set to 0 which will refuse "Obvious > overcommits of address space". I will try setting this to 3 along with > vm.overcommit_ratio to 0 to force no overcommit at all and see how the > system reacts. This didn't quite do what I expected as I missread the docs. If we set overcommit_ratio=100 and overcommit_memory=3, the kernel will not overcommit memory and we end up with Browse crashing "gracefully" w/o bogging down the whole system or with Browse just "gracefully" ignoring any user input in the address bar due to probably a failed allocation of some sort when creating a new webpage instance. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
> * We need to find out why the oom-killer is not killing things fast > enough. Based on our results, we might consider configuring > /proc/$pid/oom_adj to preferentially kill some processes (e.g., the > foreground [or background?] activities.) In the cases I've been playing with, browse is the only activity that is running. Will try bumping its oom_adj to see if this improves OOM kill latency. > * We need to determine whether the oom-killer is killing the right > processes. (sysctl's vm.oom_dump_tasks can be set to 1 in order to > get more verbosity from the oom-killer when it fires). >From watching top, it appears that we're killing the correct process. For example, when running the test case from #8316, OOM killer does not kill browse, but just kills the gnash instance which is chewing up RAM. > - the warnings in the ramfs and tmpfs code about the deadlocks that > tmpfsen can generate under low- or no-memory conditions. I have yet to see an actual deadlock. What I saw when trying to reproduce #3816 is that the OOM killer just takes a very very long time to kick in. > - whether our kernel "overcommits" when allocation requests are made? By default vm.overcommit_memory is set to 0 which will refuse "Obvious overcommits of address space". I will try setting this to 3 along with vm.overcommit_ratio to 0 to force no overcommit at all and see how the system reacts. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride images for downloading and installing them with a USB key
On Aug 14 2008, at 21:35, Bastien was caught saying: > Chris Ball <[EMAIL PROTECTED]> writes: > > > Hi, > > > >> Hi list, where can I find images of the latest joyride for > >> installing it with a USB key? Something similar to these images: > > > > http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/devel_ext3/ > > Anything under this directory is now emtpy: > > http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/ > > 2302 is not empty, but 2303 is since midday. Something wrong? Fedora's Koji build system that is used for some of our components is currently down (See mstone's prior email to this list from a few hours back.) From bottom of http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/build2303/devel_jffs2/build.log: http://koji.fedoraproject.org/static-repos/dist-olpc3-build-current/i386/repodata/repomd.xml: [Errno 12] Timeout: Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: olpc_development. Please verify its path and try again * Unmounting special file systems from install root * Detaching disk and partition 1 (/dev/loop5 and /dev/loop6) - Cleaning up connections to loop devices * Deleting incomplete OS image -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Next joyride beta delayed.
On Aug 13 2008, at 20:35, Michael Stone was caught saying: > Folks, > > We began considering joyride-2294 for this week's beta selection process > this morning and, this evening, Joe discovered some interesting hangs on > laptops running the sugar activity updater. We believe that these hangs > may be correlated with wireless activity and with the onset of > idlesuspend; however, since we decided today that we're not ready to > ship idlesuspend, Kim has requested that we generate a new build with > idlesuspend disabled by default for this week's testing effort. > > More news tomorrow when our story continues. > > Michael > > P.S. - Kernel folks -- I'm beginning to worry that convincing ourselves > that our kernel is stable enough ship is going to be... difficult. Your > advice would be appreciated. I think we have a gaggle of bugs with workarounds; however, until the above issue (#7954), we had only seen deadly hangs on suspend/resume under deep stress testing, not under any sort of real usage scenario. We really need to continue to reproduce this and gather more data. I'd also like to see us try to reproduce this with the new EC code in place. The issues reported with the touchpad (#7788) are also a bit worrysome but until we have a way to reproduce that can be reproduced on any laptop, I'm not going to consider it a show stopper. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: jackd on OLPC?
On Aug 13 2008, at 17:10, victor was caught saying: > Thanks for your response. It would be perhaps a good idea > to put together a working group to discuss audio infrastructure > matters. Any chance you can make the Linux Plumber's Conf [1] in about a month? :) There are a few OLPC folks headed this way (myself, cjb, dilinger, dsd possibly) and there's a whole miniconf dedicated to future audio directions in Linux headed up by Lennart Poettering, the lead developer of PulseAudio. ~Deepak [1] http://linuxplumbersconf.org/ -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
On Aug 13 2008, at 03:27, Ricardo Carrano was caught saying: > But the important result is that collaboration does not seem to be > working in infra mode. Irrespective of the filter status, no icon is > being presented in the mesh view of the other XO. Does anyone else > experienced this? Would this be considered a blocker for 8.2 or do we primarilly care about collaboration in mesh mode for deployments? ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
On Aug 12 2008, at 11:44, Deepak Saxena was caught saying: > > Marvell will implement the new wow-signature API with the next > > firmware release (22p18) > > OK, so I'll not push the existing patches into 8.2 and we can roll > this into 8.2.1 when all the bits are ready. Hmm, I think I was a bit overzealous here. :( I've committed the existing Marvell patch that works with the current firmware and we can live with it for now and if needed, do a fw/driver update in the future for 8.2.1 to be in sync with upstream. I've tested that simple wake on all ARP works but haven't done anything more with it. This should show up in a joyride sometime today, once the kernel autobuild kicks off. Note that with the patch in the kernel we stll need changes to userspace to properly setup the filters. At the minimum, we should enable wake-up on all ARP packets as the default? ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
On Aug 12 2008, at 12:19, Javier Cardona was caught saying: > > So it doesn't look like Javier's patch actually went into one of our > > official > > branches (stable/testing/master). I'm also not sure we need it b/c testing > > and stable have the following commit that came in 6 days after Javier's > > patch > > on trac and it seems to deal with the same issue: > > > > commit c16eba59c2183f9d4952eca4d720982cfbe8e031 > > Author: David Woodhouse <[EMAIL PROTECTED]> > > Date: Mon May 19 18:47:52 2008 +0100 > > > >libertas: fix multicast handling on eth and msh interfaces > > You are correct. The patch that I sent is unnecessary, as David > Woodhouse rewrote it in a much better way. > I tested his implementation and it passed all our test cases. So you > can ignore my patch. > (In case anyone needs them, our tests for this are here: > http://dev.laptop.org/~javier/misc/olpc-mcast-stable-tests.tar.gz) Great! Ricardo, when you get a chance, can you validate on latest joyride that everything is working OK? > We are waiting for Marvell for an updated firmware that implements a > simpler API to configure wake-on-wlan signatures. The proposed API > was really hard to use and would require additional changes to support > IPv6. Before pushing this upstream we wanted to have a cleaner > driver/fw interface. > > Marvell will implement the new wow-signature API with the next > firmware release (22p18) OK, so I'll not push the existing patches into 8.2 and we can roll this into 8.2.1 when all the bits are ready. Thanks! ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #5144 HIGH 8.2.0 (: [firmware] Marvell firmware should default to mesh off, and have controls for turning mesh on and off
On Aug 12 2008, at 08:19, Michail Bletsas was caught saying: > Given that such a modification requires extensive driver patching, I don't > think we should pursue it for this release. +1 I must be missing something, b/c shouldn't the mesh just be disabled until we do "ifconfig msh0 up" and then disabled via "ifconfig msh0 down"? I'm not sure why we need a bunch of iwpriv calls for this. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend vs Network Traffic - blockers
On Aug 12 2008, at 12:22, Ricardo Carrano was caught saying: > Dear all, > > It is very important to correctly approach the interactions between > suspend/resume and network traffic. > > There are at least two mechanisms that need to be in place for both > things to be able to operate together without causing major issues: > > 1 - The multicast address populating on the firmware, that is needed > for collaboration to work: http://dev.laptop.org/ticket/6818 So it doesn't look like Javier's patch actually went into one of our official branches (stable/testing/master). I'm also not sure we need it b/c testing and stable have the following commit that came in 6 days after Javier's patch on trac and it seems to deal with the same issue: commit c16eba59c2183f9d4952eca4d720982cfbe8e031 Author: David Woodhouse <[EMAIL PROTECTED]> Date: Mon May 19 18:47:52 2008 +0100 libertas: fix multicast handling on eth and msh interfaces We weren't properly handling multicast on the mesh interface. Fix that, which involves setting up the hardware to use the union of dev->mc_list for both eth%d and msh%d devices. This means we can't do it directly from ->set_multicast_list() because we'd need to lock the other device to read its list, and we can't do that because it might deadlock. So punt the actual work to keventd. Also, invoke the same when taking an interface down; for some reason the core calls ->set_multicast_list while IFF_UP is still set in dev->flags when we're taking it down, so its addresses don't get removed then. We also convert MAC_MULTICAST_ADR to a direct command while we're at it, removing one more entry from the big switch statement in the deprecated lbs_prepare_and_send_command() function. Change the priority of the 'unknown command' warnings in that switch statement too, because we really do want to know about it if it happens. Signed-off-by: David Woodhouse <[EMAIL PROTECTED]> Ricardo, have you reproduced the issues with the latest kernels? > 2 - The signature based filter, that is needed for ARP to work > (keeping in mind that no ARP, no unicast traffic, nothing): > http://dev.laptop.org/ticket/6993#comment:2 This patch applies cleanly and if we need this for 8.2 mesh to work properly, I'm OK pushing it in (depending on how our discussion on change control ends up) but would like to see us vet this upstream for the future. Instead of iwpriv, we could theoretically extend the ethtool interface to support this if we think more HW in the future will support this sort of filtering. Javier, can you work on push to upstream? Have we already tried and been NACKed? Thanks for point these out Ricardo! This is not the first set of issues that have come up due to out-of-tree, non-upstream development that was stuck in one of our trees or trac and we need to work on reducing our differences from upstream. Our delta is just going to get bigger and unmaintainble with regressions constantly popping up as patches get dropped. For 9.1 (9.2 more realistically?) I highly suggest one of our priorities be that a stock kernel.org kernel just works out of the box on our lovely little laptop, even if that means rewriting parts of drivers, firmware, etc. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First impressions of joyride-2280
On Aug 11 2008, at 11:09, Ton van Overbeek was caught saying: > - TamTam sound seems to work OK for me. No hic-ups or noise. Odd given that we have yet to commit the changes for #7603. > - After suspending with the power button however (screen goes off) > and resuming with the power button, eth0 is down and does not > come up automatically. Manually bringing it up with ifconfig and > assigning it the same ip4 address as before allows to continue > the external ssh session. Reproduced this here. I was able to just do an "ifconfig up eth0" after resume and NM reinstantiated the connection to my AP and my TCP sessions stayed up but this obviously wrong behaviour. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: inhibiting suspend via dbus
On Aug 09 2008, at 19:35, Mikus Grinbergs was caught saying: > One possibility -- OFW already tests for "is the XO plugged in?". > Maybe Ohm can test for that, and decide that suspend is not needed > when the battery is fully charged, and is not being drained. I don't think this would work for us as in some locations electrical power is expensive and we want to conserve as much power as possible. It could be made into a user-configurable setting via the control panel for those situations where we do want this behaviour. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: inhibiting suspend via dbus
On Aug 09 2008, at 15:34, John Gilmore was caught saying: > > As it turns out, the activity update control panel needs to inhibit > > suspend, too, otherwise we go to sleep in the middle of downloading > > large activities (Firefox, TamTam, etc). > > > > Chris, could you make a little wiki page explaining how to interact w/ > > ohm via dbus to temporarily inhibit suspend, and send me the [[link]]? > > I figure other people who want to do other long-lived tasks could use > > this information, too; it should perhaps be included in the activity > > API docs. (Does Browse properly inhibit suspend during download? It > > probably should.) > > No, this is the wrong approach. > > We shouldn't be patching every program to "avoid suspending" at various > times. We should be improving the heuristic that the system (Ohm) uses > to decide when to suspend. Once we have better information from the > kernel about what the running processes are doing, we'd just have to > rip out all the little kludges inserted into every program. I don't think we want kludged in every program, but I also think that for power management to work efficiently and for us to be able to enable/disable the right HW at the right time, we need a way for applications to be involved. > Normally, when a TCP connection is active, even a suspended XO should > break out of suspend when the next packet arrives from the other end. > Only if it happens to suspend in the brief interval between receiving > that packet and asking for the next one, will such a suspend persist > indefinitely. But there may be bugs there (e.g. #6528). The fact that we're dropping packets that wake us up is a bug, but orthogonal to how we implement a system-wide power management policy and interfaces to change that policy at runtime. > We already have bugs because Read was hacked to force suspends, and it > turns out it's suspending at the wrong times (#6645, #6684). Let's > not add more bugs by hacking more activities to force or unforce > suspends. Looking at the #6645, I agree we need some better way of dealing with this. The problem with the pure hereustic approach is that there may be times when we don't have enough knowledge about the system state and more importantly the user's behaviour to really make a decision without information from the application. For example, if I am streaming music on my computer, and I walk away for sometime, it may be perfectly OK to go to do a full suspend, or it maybe the case that I don't want to go to sleep but it's OK for me to shutdown the screen. Simply looking at what is the current process doing (using network and audio resources) is not enough to make a smart judgement on what to do in this situation. There must be a way for the user to tell the application what to do and a way for the application to pass that information into the system power manager. > We should understand why ohm isn't noticing that the activity updater > isn't idle. Should Ohm be looking for a higher cpu idle% in the > seconds before it suspends? Should it be looking for minimal numbers > of context switches per second before it suspends? What does the > system look like when the updater is running? If we can confine our > suspend-kludge patches to one place (ohm) we'll be much better off in > the medium and long term. What happens when the updater is modified? Do we have to reanalyze the behaviour pattern everyime we have chage the updater and then rewrite the heurestic code in OHM? What if I'm doing something else at the same time as running the updater which completely modifies the behaviour? And what about when we change to a new kernel and the scheduler behaviour changes (see #7603)? ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New Trac Reports
On Aug 08 2008, at 00:13, Michael Stone was caught saying: > Friends, > > I took a few minutes today to piece together two new Trac reports which > I hope will aid us in reaching our 8.2.0 goals: > > http://dev.laptop.org/report/24 - Bugs blocking 8.2.0 Release Contracts Is #6211 (Per-packet mesh ttl) really considered a blocker to the release? ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: comments on late joyrides re: rt performance
On Aug 07 2008, at 21:45, victor was caught saying: > a few ms. I wondered about a change in > preemption settings in the kernel that comes with the new OS. > For some reason, 2263 seems slightly better than 2232, but I have > to test more (I only updated it this evening) As noted in #7603, the issues are most probably due to a major scheduler rewrite from 2.6.22 -> 2.6.25. Please try the kernel I've pointed out in that trac. > I will keep testing, but I expect that this will also have an impact > on TamTam. I wonder if more 'aggressive' RT preemption patches > (Ingo Molnar's ones come to mind) would be something worth > considering. I am not sure whether OLPC would entertain the idea, > but I would very much like to see the RT performance improved > one way or another. I'm very open to including Ingo's -rt patches in our kernel for a future release if we see that it improves overall responsiveness of the system. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: kernel preemption
On Aug 07 2008, at 15:07, Victor Lazzarini was caught saying: > Hi all, > > a question for the OS people: what is the level of preemption > in the olpc supplied kernel? We're running the "Low-Latencty Preemption" mode which makes all of the kernel pre-emptable except for critical sections. This is stock kernel.org code and not the -rt patch. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New faster build 2242
On Aug 03 2008, at 21:07, Deepak Saxena was caught saying: > On Aug 01 2008, at 23:57, C. Scott Ananian was caught saying: > > 2008/8/1 Build Announcer v2 <[EMAIL PROTECTED]>: > > > http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build2242 > > > > I've unretired the faster branch temporarily to collect some > > measurements on the costs of adding xfce to our builds. I also added > > some patches from my local git to sugar-artwork for #7641 (fixing some > > broken icons in xfce) and to sugar for #7495 and #7685 for my own > > testing and development. > > Can we separate the build numbers for faster and joyride builds since > they are different build streams? > > I just spent 5 minutes trying to figure out why "olpc-update joyride-2250" > does not work before realizing that it was faster build. Not a lot > of time wasted, but it seems confusing to me. Nevermind, they are different stream numbers, just -EUSERERROR. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Libertas thinmac/hostmode driver for Joyride kernels
On Aug 02 2008, at 11:12, Andres Salomon was caught saying: > On Fri, 1 Aug 2008 11:22:51 -0700 > Deepak Saxena <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > Cozybit has been working on new thinmac firmware for the Libertas > > chip that allows use of the chip in hostmode and I've built it > > against our Joyride kernels so that others can play around with it > > and provide feedback. > > > > Is there a public git repo with the code? dev.laptop.org:/git/users/javier/libertastf -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New faster build 2242
On Aug 01 2008, at 23:57, C. Scott Ananian was caught saying: > 2008/8/1 Build Announcer v2 <[EMAIL PROTECTED]>: > > http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build2242 > > I've unretired the faster branch temporarily to collect some > measurements on the costs of adding xfce to our builds. I also added > some patches from my local git to sugar-artwork for #7641 (fixing some > broken icons in xfce) and to sugar for #7495 and #7685 for my own > testing and development. Can we separate the build numbers for faster and joyride builds since they are different build streams? I just spent 5 minutes trying to figure out why "olpc-update joyride-2250" does not work before realizing that it was faster build. Not a lot of time wasted, but it seems confusing to me. Tnx, ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Empty neighborhood on joyride-2248 ?
On Aug 03 2008, at 22:49, Gary C Martin was caught saying: > Just moved from joyride-2241 to 2248, any one else seeing an empty > neighborhood and no network access (just my XO icon in the centre)? > ifconfig shows eth0 is up, but has no inet address associated with it. > Wanted to check before I open another new ticket. Booting back to 2241 > shows the neighborhood working again. I haven't updated from 2170 yet, but Ricardo submitted #7776 which is similar, but he still sees the Mesh entries in the network view. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Libertas thinmac/hostmode driver for Joyride kernels
Hi, Cozybit has been working on new thinmac firmware for the Libertas chip that allows use of the chip in hostmode and I've built it against our Joyride kernels so that others can play around with it and provide feedback. You will need to do the following: Install a recent joyrid. Latest is best and as of 2239, the kernel include network bridging enabled as a module, which is useful for WiFi <-> Wired Download libertastf and helper modules from http://dev.laptop.org/~dsaxena/libertastf_modules/ and copy these on the XO to /root/libertastf On the XO (mostly copied from wiki:Libertas_Thinfirmware_HOWTO): # cd /lib/firmware # wget http://dev.laptop.org/pub/firmware/libertas/thinfirm/lbtf_usb-5.132.2.p3.bin # ln -s lbtf_usb-5.132.2.p3.bin lbtf_usb.bin # rmmod usb8xxx # rmmod libertastf # cd /root/libertastf # insmod cfg80211.ko # insmod mac80211.ko # insmod libertastf.ko # insmod libertastf_usb.ko # ifconfig wlan0 up At this point network manager should take over and associate with your network of choice. Note that suspend/resume does not work with the thinmac driver and if you do suspend/resume, you will need to rmmod the libertas_usb driver and then reload it. To use the XO as an AP (I haven't tested this yet), see wiki:XO_as_AP. If you want to just boot to the libertastf driver by default, you can do: # mv /root/libertastf /lib/modules/`uname -r`/kernel/drivers/net/wireless # mv /lib/modules/`uname -r`/kernel/drivers/net/wireless/libertas /root # depmod -a On reboot, the libertastf driver will load and manage the card. To return to previous state of using the fullmac driver: # mv /lib/modules/`uname -r`/kernel/drivers/net/wireless/libertastf /root # mv /root/libertas /lib/modules/`uname -r`/kernel/drivers/net/wireless # depmod -a I know this is not the most user-friendly method of using the driver but should let folks play with it until I figure out a better way to package it. The issue is that the driver requires the latest mac80211 codebase and backporting this to our 2.6.25 kernel turned out to be a massive nightmare. I ended up using the compat-wireless package [1] to build the lateset 802.11 codebase out-of-tree from our kernel. We need create a separate RPM or a set of scripts that end-users can use to install the drivers on their systems. Enjoy, ~Deepak [1] http://linuxwireless.org/en/users/Download -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend oddities
On Jul 30 2008, at 15:45, Richard A. Smith was caught saying: > Deepak Saxena wrote: > > > >The gamekeys go through PS2 so I'm guessing the EC is queeing that event > >for > >us. I can reproduce the same sort of behaviour with by switching to > >console on the XO, sleeping via /sys/power/state on serial console, and > >then hitting > >a keyboard key to wake up. On wakeup, the character appears on the shell. > > > > Gamekeys show up as virtual keys. They should behave identical to the > keyboard. The EC reads them and injects them into the keyboard stream. > > >However, I just did the following here: > > > >echo 0 > /sys/power/wakeup_events/ps2event > >echo mem > /sys/power/state > >hit a key > >hit power button > > Why did you need to hit the power button? B/c I disabled wakeup on ps2event. > >And I don't see the character on console, which means it did not get > >queued during suspend when wakeup on keypress is disabled. > > > > The process is the same. If you get a wakeup from gamekey then the > keypress should follow. Turn on your ps2 debugging and verify that > indeed you do not get key events. Right, but in this case I had disabled the wakeup on gamekey. From what I can tell, everything is working as expected. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend oddities
On Jul 30 2008, at 14:17, [EMAIL PROTECTED] was caught saying: > since i'm not sure which of these are known/expected/ > alreadyfixed/beingignored, here are a few things i've noticed > with suspend. i'll trac any that people think should, or comment > existing trac if appropriate. > > disclaimer: some of this testing has been on my g1g1 machine, > running 2159, XFCE (not sugar), with a USB keyboard. > > - gamepad keypresses aren't ignored during suspend. whether or > not the gamepad is selected as a candidate wakeup event > (via /sys/power/wakeup_events/gamekey), those keys will > be queued for tty input while we're suspended. test by > starting hexdump (or other key capture program), suspending, > pushing any of the 8 keys on the bezel, and then resuming. > note that the keys have registered. (this is/was true in 708 > as well.) The gamekeys go through PS2 so I'm guessing the EC is queeing that event for us. I can reproduce the same sort of behaviour with by switching to console on the XO, sleeping via /sys/power/state on serial console, and then hitting a keyboard key to wake up. On wakeup, the character appears on the shell. However, I just did the following here: echo 0 > /sys/power/wakeup_events/ps2event echo mem > /sys/power/state hit a key hit power button And I don't see the character on console, which means it did not get queued during suspend when wakeup on keypress is disabled. How are you trigerring resume? (FYI, gamekey has been renamed ps2event in latest kernels) > - the camera LED flashes while suspended. suspend the laptop, > use the touchpad or a keyboard key. observe camera indicator > blinking. also true on 708. The way suspend currently works is that we actually go all the way back to userland and OHM makes a decision on whether we actually want to wake up or not based on our current state and what triggered the wakeup. I'm guessing the flashing is the camera driver resuming the device. If you're running XFCE on top of our OHM, you should see the same behaviour. The wakeup_event interface was put in place to stop this by allowing OHM to specify when we want to actually be woken up. > - this got me thinking about wakeups and keypresses in general. >if we're configured to wake up on keypresses or gamepad >presses (something i've not seen work yet, btw), then the >keypress causing the wake should be suppressed. don't know >whether that's the case or not. >From both our tests, it does not appear to be the case ATM. Whether this is intended or not, someone who's been around longer needs to answer. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot boot joyride-2200 from USB stick
On Jul 26 2008, at 21:44, Ton van Overbeek was caught saying: > Deepak Saxena wrote: > >Sigh++ Bought a 1G microSD with a usb adapter and it happens to be one > >that OpenFirmware cannot talk to so I can't boot off it. Just wanted > >to give you an update that this is still on my plate, just seems to be > >hitting every roadblock in the way of solving it. :O > > > >~Deepak > > > One more data point. > After some initial peeking in the ramdisk, I copied the 2212 ext3 image > to a SD card, > inserted it in the XO and tried to boot from it. > That works !!! > Of course, no activities since /home/olpc is also on the SD card and the > jffs does not get mounted. > So it seems USB is the problem. There is one warning message early in > the boot at approximately > 2 seconds about using an obsolete function in the sd driver, to use > bus-methods instead. > I am writing from memory, so this is not exact. Could this have > something to do with it, since the > sd driver is needed for USB? USB needs sd_mod which is still built into the kernel. Issue ended up being that we need to load ohci-hcd, not ehci-scd. Working ramdisk @: http://dev.laptop.org/~dsaxena/olpcrd-2200-fixup.img ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] NAND full issue
On Jul 25 2008, at 20:00, Daniel Drake was caught saying: > So unionfs is the "formal bug fix for 8.2 going forward", or is it a > Uruguay-specific thing? > > unionfs will involve a kernel change. Are we planning to shift them from > 2.6.22 to 2.6.25 where unionfs has been included, or are we going to > backport unionfs to 2.6.22? > > Also, I am a little wary of unionfs, I have used it in the past and > found it to be buggy and unreliable. It may be better now, but we should > be cautious. I've done an analysis of the UFS code and it may be possible to have a standalone unionfs module w/o changes to core kernel. See [1] for my email sent to UFS maintainers and list. My concern is that by forking the code this way, we're introducing another variable. However... Erik has been using AUFS[2] as UFS was crashing badly and not allowing sugar to boot. AUFS is completely standalone and requires no changes to the deployed kernel. This is also non-upstream so we should run it through some form of stress test in our desired configuration. ~Deepak [1] http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2008-July/005895.html [2] http://aufs.sourceforge.net/ -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: odd yum dependency issues in joyride
On Jul 25 2008, at 18:33, NoiseEHC was caught saying: > > > With 2181 this worked: > yum install mc > yum install make gcc I reproduced what pgf is seeing and the above doesn't work. I still get gkibc-common dependency isue. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot boot joyride-2200 from USB stick
On Jul 24 2008, at 08:07, Deepak Saxena was caught saying: > On Jul 24 2008, at 09:37, Ton van Overbeek was caught saying: > > I did *not* copy it to /versions/boot/current/boot, since it never > > completed the > > boot from the USB stick. > > > > I copied your modified ramdisk to /boot on the USB disk, renamed it to > > olpcrd-2.6.25-deepak-fix.img and changed the olpcrd.img sym link to > > point to it. > > > > The USB boot still does not succed, but we are a bit further. > > Now it is complaining about a missing libusual.ko: > > WARNING: Could not open > > '/lib/modules/2.6.25-20080722.2.olpc.d86980aeb8d0adb/kernel/drivers/usb/storage/libusual.ko': > > > > No such file or directory > > I get fewer warnings about missing symbols in usb-storage (now only four): > > storage_usb_ids, usb_usual_clear_presetn, usb_usual_check_type and > > usb_usual_set_present. > > But the end result is still the same: cannot mount /dev/sda1 on /sysroot. > > > > Could you make (yet) an other fixed ram disk which I can try? > > Yep. OK, I've uploaded a new olpcrd with libusual to the same URL. > > Other question, should this be entered in trac, and is it blocking for > > 8.2.0 ? > > I've opened #7620 to track this. Definetely a blocker. Scott has added the missing modules and we should see it fixed in the next joyride. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot boot joyride-2200 from USB stick
On Jul 24 2008, at 09:37, Ton van Overbeek was caught saying: > I did *not* copy it to /versions/boot/current/boot, since it never > completed the > boot from the USB stick. > > I copied your modified ramdisk to /boot on the USB disk, renamed it to > olpcrd-2.6.25-deepak-fix.img and changed the olpcrd.img sym link to > point to it. > > The USB boot still does not succed, but we are a bit further. > Now it is complaining about a missing libusual.ko: > WARNING: Could not open > '/lib/modules/2.6.25-20080722.2.olpc.d86980aeb8d0adb/kernel/drivers/usb/storage/libusual.ko': > > No such file or directory > I get fewer warnings about missing symbols in usb-storage (now only four): > storage_usb_ids, usb_usual_clear_presetn, usb_usual_check_type and > usb_usual_set_present. > But the end result is still the same: cannot mount /dev/sda1 on /sysroot. > > Could you make (yet) an other fixed ram disk which I can try? Yep. > Other question, should this be entered in trac, and is it blocking for > 8.2.0 ? I've opened #7620 to track this. Definetely a blocker. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot boot joyride-2200 from USB stick
On Jul 23 2008, at 22:30, Ton van Overbeek was caught saying:
> Hello,
>
> My xo-1 is currently on build 708.
> For testing joyride-2200 I did not want to reflash yet, but boot from a
> USB stick instead.
> So I downloaded the image from
> http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/build2200/devel_ext3/xo-1-olpc-stream-joyride-devel_ext3.img.bz2,
>
>
> unzipped it and copied it to a 1 GB Sandisk USB stick.
> Booting with extended messages (X game key pressed) shows that OFW finds
> my developer key
> in the main flash, finds the OS on the USB, does not update the firmware
> (no external power)
> and then loads the ramdisk.
>
> Booting starts, but mounting /dev/sda1 on /sysroot fails because the
> usbcore.ko module
> needed by usb-storage.ko cannot be found.
>
> Some of the messages are (copying manually from the xo-1 screen and
> skipping the stack depth messages):
> --
> FATAL: Error inserting usb-storage
> (/lib/modules/2.6.25-20080722.2.olpc.d86980aeb8d0adb/kernel/drivers/usb/storage/usb-storage.ko):
>
> Unknown symbol in module, or unknown parameter (see dmesg)
> mount: mounting /dev/sda1 on /sysroot failed: No such device or address
> Traceback (most recent call last):
> File "/init", line 131, in
> lease_writer, run_init)
> File "/antitheft.py", line 31, in run
> return run_init_callback()
> File */init", line 103, in run_init
> root_mounted(xo, boothpath).__enter__() # hack to re-mount root
> File "/initutil.py", line 120, in __enter__
> check_call({'/bin/mount','-n','-o',access]+extra+[dev,'/sysroot'])
> File "/usr/lib/python2.5/subprocess.py", line 461, in check_call
> raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command '['/bin/mount, '-n', '-o', 'ro',
> '/dev/sda1', '/sysroot']' returned non-zero exit status 255
> ----
>
> Is this (booting from USB) supposed to work? Has it ever worked?
> Or am I missing something?
> It seems that usbcore.ko has to be available early in the boot, but
> cannot be found.
USB boot should work and has worked in the past. I'll look into this.
~Deepak
--
Deepak Saxena - Kernel Developer - [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: NAND Full Requirement
On Jul 22 2008, at 16:16, Erik Garrison was caught saying: > See: http://dev.laptop.org/ticket/7587#comment:4 > > On boot, check NAND discomfort level. If high, use unionfs(4) to mount > a read/write tmpfs over top of a read-only jffs2 rootfs. Set unionfs > flags to enable file deletion from the 'ro' root partition (or if this > is impossible, mount the fs in another location to allow deletions). > Set a flag to tell olpc-session or Sugar to enter into a deletion > dialog. I'm wondering if we should/can implement the file deletion UI as a small standalone app that can be launched from the intramfs itself? This would allow us to solve the the issues on deployed systems by just updating the olpcrd file? > Benefits: > This solution theoretically allows all software to run an a NAND-full > machine. Thus students who arrive at school with a NAND-full machine > could still work with their XO through lessons and manage flash cleanup > as time is available. Requires minimal code-level changes to enable. One issue here is that if the user launches an activity and changes to documents go to the tmpfs, they are lost at boot up unless there is an explicit sync to the real filesystem; however, that sync can't happen until space has been cleared. ~Deepak -- Deepak Saxena <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: For review: NAND out of space patch.
On Jul 22 2008, at 11:36, Chris Ball was caught saying: > During this reboot is where we delete some files. I think the > deployments probably run pretty-boot and don't see text messages, > so these users won't see anything different at all. If they did > see text messages during boot, they would see: > >Not enough disk space. >Deleting /home/olpc/.sugar/default/datastore/store/XXX-XXX >(repeated if necessary) > > .. scroll past on the Linux console. Can these be logged somehow so that when the GUI starts, users with pretty boot can get a dialog that lists what files were deleted? ~Deepak -- Deepak Saxena <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NAND out of space crash
On Jul 21 2008, at 13:55, Jim Gettys was caught saying: > > #6480 is fixed as of yesterday, should be in next joyride. > > > > I'll be re-doing Nokia's patches so that they go upstream if we still want > > them after 8.2 is out; however, I don't think the approach used by them > > actually > > helps us. We already have a very limited amount of storage space and > > reserving > > space for the root user just reduces what the end user can actually use. > > IIRC, the issue is the GC runs more and more often the closer to full > you run. By reserving some space, you avoid the performance cliff. > > Since we expect to be running nearly full most of the time, it would > seem to me avoiding this cliff is important. I can go ahead and apply the existing Nokia patch into the 8.2 kernel as a short-term measure but don't want to arbitrarilly choose a reservation size. Dave, do you have a suggestion as to what percentage should be reserved to keep the GC from going out of control? If not, we'll need to run some performance tests to find the sweet spot. ~Deepak -- Deepak Saxena <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NAND out of space crash
On Jul 21 2008, at 13:39, C. Scott Ananian was caught saying: > > 2) JFFS2's behavior when the file system is almost full. When it gets > > almost full, it can spend all its time trying to garbage collect, and > > you can lose completely (the system sort of gets the "slows", and grinds > > to a halt). > > > > As to 2), there are patches done by Nokia (deployed on the N800 and > > similar devices) that reserve some extra space and report out of space > > before the system "gets the slows". These are in Dave's incoming queue > > to merge into JFFS2 the last I heard. I don't know if he's merged them. > > These are less critical, IMO. I have filled up NAND, and "the slows" > are not debilitating. The issues above are. We should encourage Dave > to fix this issue and the other known JFFS2 bugs (trac #6480, for > instance) -- or get dsaxena to do so -- for 9.1. #6480 is fixed as of yesterday, should be in next joyride. I'll be re-doing Nokia's patches so that they go upstream if we still want them after 8.2 is out; however, I don't think the approach used by them actually helps us. We already have a very limited amount of storage space and reserving space for the root user just reduces what the end user can actually use. I think analyzing performance of non-JFFS2 file systems and picking a replacement should be a high-priority item for 9.1 update. ~Deepak -- Deepak Saxena <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: LZO support
On Jul 14 2008, at 12:19, Chris Ball was caught saying:
> Hi,
>
>> Based on some very provisional testing, I believe that the extremely
>> long save times we're seeing in EToys are at least partly related
>> to our use of zlib compression for data nodes in the filesystem.
>> We could switch to LZO compression for a 500% speedup in
>> compression (write), a 50% speedup in decompression (read), and a
>> slight (but significant) decrease in compression ratio.
>
> I prefer aiming at #2886 ("Some files shouldn't be compressed by
> jffs2"), which goes a long way to solving the user problems without
> introducing the logistical cost of LZO support in OFW or partitions.
I've been thinking about this a bit and there are all sorts of issues
involved here. The patches I know of that that exist to disable compression
on cramfs are for use at file system creation time, where we know exactly
what data we're stuffing into the system. These are primarilly used
to disable compression on executables and allow XIP.
If we want to do this at runtime, we have to figure out how to tell the
the kernel not to compress a file?
- One option, as suggested in the trac, is to have the kernel trap file
extensions and disable compression based on that. Doable, but I expect
a rather large hack to VFS to do this. An extension to this idea is
to look for specific signatures in files that disable compression.
- Another option is to provide a one-time flag passed at file creation
time (O_CREAT) to enable/disable compression. This would also require
VFS changes but I think would be simpler; however, this case has the
problem that all applications that may at one time write a file that
does not need compression need to be modified to support this extension.
> Saving a movie would be faster still than LZO if we could just tell
> jffs2 that we're giving it compressed data that it shouldn't recompress.
Do we have some idea of how much of our data in general is compressed
and how much is not? If most our compressed data is small text files
and the majority or our data is large compressed files, maybe we can
drop the compression requirement all together?
If we look beyond jffs2 and consider yaffs as an alternative (not upstream
but has been actively used in the embedded world for years), it does no
compression whatsoever at the filesystem level.
~Deepak
--
Deepak Saxena <[EMAIL PROTECTED]>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: LZO support (was: [Re: low power actions?])
On Jul 14 2008, at 12:07, Erik Garrison was caught saying: > There is an existing ticket to address this issue > (http://dev.laptop.org/ticket/2072). This ticket suggests that we could > add LZO support to OFW in order to implement LZO-compressed data nodes > in the filesystem. > > In this scheme OFW would require LZO support to boot a kernel which > resides on an LZO-compressed fs. But an alternative is to implement a > partitioning scheme in which user data resides on a LZO-compressed > partition and the system data resides on a zlib-compressed partition. > This would provide us with good compression for system components > (saving space) but would also allow users to write data much more > quickly. That said, implementing LZO compression across the entire > system might improve system responsiveness by a noticeable margin, so it > might be worthwhile. Testing is required. Partitioning is already on our roadmap, so if we just put /boot and other OFW needed data in a non-LZO partition, we can live w/o needing to update OFW to handle LZO. ~Deepak -- Deepak Saxena <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
8.1 Kernel for touchpad testing
Hi, Richard pointed out on IRC that that our largest userbase is not running Joyride builds and that we should provide the updated touchpad driver that we are planning on shipping with 8.2 to increase our test coverage. I have built an RPM with the 2.6.22 kernel + driver backport that folks running <= 703 can use for this purpose: http://dev.laptop.org/~dsaxena/kernel-2.6.22-20080710.1.olpc.0.i586.rpm See http://wiki.laptop.org/go/Kernel#Installing_OLPC_kernel_RPMs for information on how to install this update. Please provide feedback on the mouse behaviour if you decide to install this. Thanks, ~Deepak -- Deepak Saxena <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: qemu on Kubuntu - error regarding 3dnow support.
On Jul 09 2008, at 15:14, Torello Querci was caught saying: > The ext2 image, I suppose, is oriented to be used in external device or > virtualization system. If qemu, vmware and virtualbox are not able to handle > 3dnow extension, since I suppose to be run on more power system like AMD64 or > IntelCore3, I think that is better if this option is not enbaled on this > image type. Currently we do not build different kernel configs or have an easy method to do so automatically. I'll add it to my todo list to build a kernel RPM w/o 3dNow support but if you you have an F9 system and want something right away, you can follow the directions at [1] to rebuild the RPM yourself. ~Deepak [1] http://wiki.laptop.org/go/Rebuilding_OLPC_kernel -- Deepak Saxena <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power on button remaps the keyboard
On Jul 07 2008, at 20:55, Dov Grobgeld was caught saying: > I'm running joyride-2097. Should I open an issue? Is it one or two bugs? One > bug is the remapping. And the second is that it does not go into sleep mode? I think OHM bits might not have been in place in 2097. Suspend/resume works in the latest builds (2123). Please try your remaping again with this build and file a bug if you still see the problem. ~Deepak -- Deepak Saxena <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
