Re: tap-to-click feedback

2009-10-22 Thread Deepak Saxena
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

2009-10-21 Thread Deepak Saxena
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: Disk layout for XO-1.5

2009-07-28 Thread Deepak Saxena
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: Disk layout for XO-1.5

2009-07-28 Thread Deepak Saxena
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


XO-1.5 Kernel Update (i.e My Weekly Status)

2009-07-20 Thread Deepak Saxena
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: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)

2009-07-20 Thread Deepak Saxena
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


Re: [PATCH] viafb: update driver to use both I2C Channels

2009-07-16 Thread Deepak Saxena
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

2009-07-15 Thread Deepak Saxena
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


Re: [Techteam] end-of-week

2009-07-13 Thread Deepak Saxena

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: New kernel branch for XO-1 and XO-1.5 development

2009-07-09 Thread Deepak Saxena
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


Re: [PATCH] build kernel-firmware rpms again

2009-07-09 Thread Deepak Saxena

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 @@ 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 

New kernel branch for XO-1 and XO-1.5 development

2009-07-08 Thread Deepak Saxena

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

2009-06-25 Thread Deepak Saxena
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


Re: equivalent copy-nand interface ideas for XO-1.5

2009-06-15 Thread Deepak Saxena
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


XO-1 2.6.30 kernel

2009-06-15 Thread Deepak Saxena

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: libertas private ioctls

2009-06-12 Thread Deepak Saxena
On Jun 11 2009, at 14:49, Daniel Drake was caught saying:
 On Thu, 2009-06-11 at 08:42 +, 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

2009-06-11 Thread Deepak Saxena
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

2009-01-08 Thread Deepak Saxena

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

2009-01-06 Thread Deepak Saxena
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


Re: Fedora Desktop on XO

2009-01-06 Thread Deepak Saxena
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


Building Custom Kernel RPMS

2008-12-19 Thread Deepak Saxena

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

2008-12-15 Thread Deepak Saxena
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: Joyride SD card corruption

2008-12-15 Thread Deepak Saxena
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: 8.2.1 Bug review meeting - 1 PM EST Friday 12/12/08

2008-12-11 Thread Deepak Saxena
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

2008-12-09 Thread Deepak Saxena
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.

2008-11-28 Thread Deepak Saxena
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

2008-11-25 Thread Deepak Saxena
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: RW Compressed FUSE FSs? (Re: XS - XO archiving and backup)

2008-11-10 Thread Deepak Saxena
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


ACPI on XO (was: Re: [Techteam] Weekend 10/31)

2008-11-03 Thread Deepak Saxena
[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: [Techteam] Weekend 10/31

2008-11-03 Thread Deepak Saxena
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


Re: ACPI on XO (was: Re: [Techteam] Weekend 10/31)

2008-11-03 Thread Deepak Saxena
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: ACPI on XO

2008-11-03 Thread Deepak Saxena
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: 2.6.27 artifact ?

2008-10-31 Thread Deepak Saxena
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

2008-10-30 Thread Deepak Saxena
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

2008-10-29 Thread Deepak Saxena
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


9.1 Proposal: Deailing with Low Memory/OOM

2008-10-22 Thread Deepak Saxena

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/pid/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


9.1 Proposal: Filesystems

2008-10-22 Thread Deepak Saxena

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


Re: Master kernel in Joyride.

2008-10-16 Thread Deepak Saxena
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: Master kernel in Joyride.

2008-10-16 Thread Deepak Saxena
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: Updated UBIFS 8.2 image

2008-10-14 Thread Deepak Saxena
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


Re: enabling and disabling file compression

2008-10-13 Thread Deepak Saxena
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


Updated UBIFS 8.2 image

2008-10-13 Thread Deepak Saxena

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


File systems usage patterns and NAND lifetime

2008-10-10 Thread Deepak Saxena

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


UBIFS 8.2 image

2008-10-10 Thread Deepak Saxena

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


Re: UBIFS 8.2 image

2008-10-10 Thread Deepak Saxena
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


Re: UBIFS todo

2008-10-06 Thread Deepak Saxena
[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

2008-10-06 Thread Deepak Saxena
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: 5 sec boot

2008-10-04 Thread Deepak Saxena
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: 5 sec boot

2008-10-04 Thread Deepak Saxena
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

2008-10-04 Thread Deepak Saxena
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

2008-10-04 Thread Deepak Saxena
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

2008-10-04 Thread Deepak Saxena
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: idea for running out of RAM

2008-09-23 Thread Deepak Saxena
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

2008-09-14 Thread Deepak Saxena
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

2008-09-12 Thread Deepak Saxena
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

2008-09-11 Thread Deepak Saxena
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: [Server-devel] Libertas firmware on F9 for the XS

2008-09-11 Thread Deepak Saxena
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]
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


Re: [Server-devel] Libertas firmware on F9 for the XS

2008-09-11 Thread Deepak Saxena
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]
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


Re: Libertas firmware on F9 for the XS

2008-09-10 Thread Deepak Saxena
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

2008-09-09 Thread Deepak Saxena
   * 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: Stability and Memory Pressure in 8.2

2008-09-09 Thread Deepak Saxena
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: Next joyride beta delayed.

2008-08-14 Thread Deepak Saxena
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: joyride images for downloading and installing them with a USB key

2008-08-14 Thread Deepak Saxena
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: urlopen error timed out
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: jackd on OLPC?

2008-08-13 Thread Deepak Saxena
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

2008-08-12 Thread Deepak Saxena
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!

rant
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.
/rant

~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

2008-08-12 Thread Deepak Saxena
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: First impressions of joyride-2280

2008-08-11 Thread Deepak Saxena
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

2008-08-10 Thread Deepak Saxena
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: comments on late joyrides re: rt performance

2008-08-07 Thread Deepak Saxena
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: New Trac Reports

2008-08-07 Thread Deepak Saxena
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: Empty neighborhood on joyride-2248 ?

2008-08-03 Thread Deepak Saxena
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


Re: New faster build 2242

2008-08-03 Thread Deepak Saxena
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: Libertas thinmac/hostmode driver for Joyride kernels

2008-08-03 Thread Deepak Saxena
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

2008-08-03 Thread Deepak Saxena
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


Libertas thinmac/hostmode driver for Joyride kernels

2008-08-01 Thread Deepak Saxena

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

2008-07-30 Thread Deepak Saxena
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: suspend oddities

2008-07-30 Thread Deepak Saxena
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: Cannot boot joyride-2200 from USB stick

2008-07-28 Thread Deepak Saxena
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

2008-07-25 Thread Deepak Saxena
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: Cannot boot joyride-2200 from USB stick

2008-07-24 Thread Deepak Saxena
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

2008-07-24 Thread Deepak Saxena
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

2008-07-23 Thread Deepak Saxena
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 module
 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: For review: NAND out of space patch.

2008-07-22 Thread Deepak Saxena
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 Full Requirement

2008-07-22 Thread Deepak Saxena
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: NAND out of space crash

2008-07-21 Thread Deepak Saxena
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: NAND out of space crash

2008-07-21 Thread Deepak Saxena
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: LZO support (was: [Re: low power actions?])

2008-07-14 Thread Deepak Saxena
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


Re: LZO support

2008-07-14 Thread Deepak Saxena
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


8.1 Kernel for touchpad testing

2008-07-10 Thread Deepak Saxena

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.

2008-07-09 Thread Deepak Saxena
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

2008-07-07 Thread Deepak Saxena
On Jul 07 2008, at 19:11, Dov Grobgeld was caught saying:
 I'm running one of the latest Joyrides and I was trying to put the laptop
 into sleep mode by a short press to the power button. It didn't put it to
 sleep, but it undid the keyboard remapping that I had done through xkbcomp.
 Is that supposed to be a bug or feature?? xev shows that the power button
 triggers a remapping event.

Certainly seems like a bug to me. Which specific joyride are you running?

~Deepak

-- 
Deepak Saxena [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 8.2 Kernel status update

2008-07-04 Thread Deepak Saxena
On Jul 02 2008, at 10:16, Jim Gettys was caught saying:
 The other issue it would be nice to get fixed is the jffs2 full
 performance falling off the wall cliff, for which there is a patch that
 the Nokia folks have deployed.  While in development we seldom run full,
 running full is likely the usual state in the field.
 
 Dave, have you had a chance to look at it?

Dave looked at it and doesn't like the implementation. I can 
throw it into our joyride along with the needed changes to
olpcrd to mount with a root reservation of 4M or so as a
stop-gap to a better solution until we have something better.
Note that both the patch and Dave's proposal of having a sysfs 
attribute for root reservation and other attributes don't 
really address the slow performance at full issue. They just 
keep the filesystem from being filled so we don't see the condition.

~Deepak

-- 
Deepak Saxena [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


8.2 Kernel status update

2008-07-02 Thread Deepak Saxena

Hi,

I'm out of town in meetings all day tommorrow so won't make it to 
the software status meeting. From a kernel POV, the biggest bugs 
in 8.2 AFAIK are touchpad issues (7341) and wireless suspend resume 
issues (7303). Dilinger has a patch for the former that disables pen 
tablet mode that will hopefuly help with a lot of the issue and I 
believe Richard is testing it (I would do it now if I didn't have
to jump on plane in 6 hours).  Andrey from Cozybits fixed up the 
wifi issue and build 2097 contains the appropriate bits.

The one major change I was hopeing to get into kernel for 8.2
is integrating intiramfs and kernel into one RPM but I think 
the probability of getting that done in next few days is not 
too high ATM.

~Deepak

-- 
Deepak Saxena [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Touchpad issues on joyride

2008-07-01 Thread Deepak Saxena
On Jul 01 2008, at 11:58, Daniel Drake was caught saying:
 On Mon, 2008-06-30 at 16:24 -0700, Deepak Saxena wrote:
  Hi,
  
  For those of you running into crazy pointer behavior on 
  the latest Joyride builds (2080+ with latest kernel), 
  can you please try the following in the terminal/console 
  and report back on if this helps at all after some extended 
  usage:
  
  echo 120  /sys/modules/psmouse/parameters/ignore_delta
 
 You meant
 echo 120  /sys/module/psmouse/parameters/ignore_delta
 (module, not modules)

Yep.

 I am still seeing the crazy mouse behavior quite often. It is perhaps
 occurring less often, but if there is any improvement it is only a small
 one.

Daniel,

Can you do:

echo 1 /sys/module/psmouse/parameters/tpdebug

And send me the data log for the time you start moving
around to a few seconds after you start seeing the 
bad behavior?

Easiest way to do this is edit /etc/rsyslog.d and update the
kern.* line to:

kern.*   /var/log/messages

Then restart rsyslogd. When done, just email me /var/log/messages.

Thanks,
~Deepak

-- 
Deepak Saxena [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: working gdb for recent joyride

2008-06-30 Thread Deepak Saxena
On Jun 30 2008, at 12:04, Daniel Drake was caught saying:
 gdb isn't working for most apps on joyride. It interrupts the app (and
 refuses to resume) with the following error:
 
   Couldn't read floating-point and SSE registers
 
 This is because of what seems to be a kernel bug introduced in 2.6.25:
 http://lkml.org/lkml/2008/6/30/7

I've merged this fix into our testing kernel and should be in next 
Joyride (assuming our auto kernel build magic is working).

~Deepak


-- 
Deepak Saxena [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Touchpad issues on joyride

2008-06-30 Thread Deepak Saxena

Hi,

For those of you running into crazy pointer behavior on 
the latest Joyride builds (2080+ with latest kernel), 
can you please try the following in the terminal/console 
and report back on if this helps at all after some extended 
usage:

echo 120  /sys/modules/psmouse/parameters/ignore_delta

Thanks!
~Deepak

-- 
Deepak Saxena [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Trac Usage Conventions

2008-06-27 Thread Deepak Saxena
On Jun 26 2008, at 20:48, Michael Stone was caught saying:
 On Fri, Jun 27, 2008 at 01:31:24AM +0200, Marco Pesenti Gritti wrote:
  On Fri, Jun 27, 2008 at 1:24 AM, Michael Stone [EMAIL PROTECTED] wrote:
   4. People should indicate the release they _wish_ that changes would
 land in via the Milestone field.
  
  I tend to think the Milestone should be set by the bug owner (or by
  other developers in its team) and not by the bug reporter. I'm not
  sure if that's what you mean with people or not.
 
 Your suggestion seems good; also, I was intentionally vague.
 
 What do others think?

I have a concern that non-developers will use the Milestone 
field to determine what we (OLPC as an organization) are planning 
on supporting in a given release and not as a wishlist item. 
I suggest this field should only be set by one of the release
release team members once the team is comfortable promissing 
a feature/bugfix to based on develper feedback and prioritization
based on end-user inputs.

~Deepak

-- 
Deepak Saxena [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


[RFC] Tracking upstream submissions

2008-06-27 Thread Deepak Saxena

Hi,

In going through various kernel bugs and check-ing in certain
changes such as the SD corruption fix (#6532) and support for
a link-layer TTL (#6211), I'm wanting to add a standard way
to track whether a patch has been pushed upstream that is 
independent of whether it has been fixed in the OLPC builds.

A good example of why we need this this is the SD bug. We now 
have a simple workaround that fixes the issue on the XO but the
fix is definetely not acceptable upstream and a proper fix requires
more time than I can invest at the moment due to the upcoming
release and higher priority fixes. From the perspective of 
OLPC and the XO users, this bug is fixed so the bug should
be closed out at some point. From my perspective as a developer,
I still need to fix this and I need a way to track this.

I imagine that I'm not the only developer who has to deal with
non-upstream patches so would like a standard way to track these
and they don't just get dropped and forgotten about.

The are a couple of options here:

- What we did at my previous job was to create a related incident
  by cloning the existing bug and marking the milestone as Upstream.
  We don't have cloning AFAICT with our trac, so an option suggested
  by Jim that would work is to create a new upstream bug and then
  mark the original bug as a blocker for the upstream bug (or the
  otherway around?)

- Another is to use to go ahead and close the bug and then use
  one of the following keywords:

  upstream:? Needs to be submitted upstream
  upstream:- Rejected or will never be pushed upstream
  upstream:+ Accepted upstream

- A third option is to use the Action Needed field and add
  a Sumbit Upstream option.

Thoughts? 

Tnx,
~Deepak

-- 
Deepak Saxena [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [RFC] Unscheduled Software Release for SD Card Corruption Workaround

2008-06-25 Thread Deepak Saxena
On Jun 25 2008, at 00:04, Kim Quirk was caught saying:
 Thanks Deepak.
 I'd love to see the SD card corruption fixed, but we are just about finished
 with testing and are now in the release process for 8.1.1... so i recommend
 that we schedule this fix for the 8.1.2 release (if we do this release) and
 make sure it gets into 8.2.0, which might be the next release we get out the
 door.

Ah, I didn't fully grok our release schedule and thought 8.1.1 was already
out the door.

 Other thoughts?

Eric and I talked about this a bit yesterday and we thought that doing
a full USR is probably not needed. What we're looking at doing to help
the G1G1 users who are impacted by this is to spin a kernel RPM and
initrd that they can install. 

~Deepak

-- 
Deepak Saxena [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: SuperUser permission for the Driver??

2008-06-24 Thread Deepak Saxena
On Jun 24 2008, at 17:35, shivaprasad javali was caught saying:
 Hi,
 
   I have USB devices (not storage devices, just some usb devices), which
 I can use along with my application on the olpc. The driver for these USB
 devices are third paty drivers so I have to detach the kernel usb driver so
 that I can use my own driver for that USB device. For this I need to have
 super user privileges while running my application.
 
  I am new to programming on Linux. Could anybody point me as to how I
 can give superuser privileges to my driver code.

See http://wiki.laptop.org/go/Su

I am not completely sure I grok what you need. Are you trying to load
a driver via insmod or run some installer for the driver?  Note that 
until two days ago, the USB driver was built into to the kernel, so
you can't unload it. What specific device and driver is this?

~Deepak

-- 
Deepak Saxena [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


  1   2   >