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