Re: Unable to update my machine
On 8/31/07, Mitch Bradley [EMAIL PROTECTED] wrote: Sorry to Mitch for multiple, I forgot to reply to all. The problem is ostensibly fixed in a new version of firmware that will be released in the next couple of days. That would be great. I have a 2GB USB disk that used to be as a rescue boot disk. As syslinux doesn't support 1GB, I need to partition it into two FAT16. The olpc firmware doesn't seem to like it and every time I need to specify the boot-device under OK prompt to do the update. However, later I noticed that actually I only need to go to the OK prompt and type boot would be sufficient. (USB icon only appears if boot from OK prompt.) This makes me wonder that if the problem is due to the partitioning (I'd prefer to keep my present partitions) or the USB detection? The problem is actually a little more complicated than having a partition table or not. There was a situation where a disk could appear to both have a partition table, and also have a FAT file system starting in the first sector. The way that can happen is if you use mkdosfs on the raw disk (sda), and then change your mind and use fdisk to partition it and then do mkdosfs again on sda1. fdisk does not automatically erase the BIOS parameter block (the FAT equivalent of a super block) in the partition sector, so you end up with an ambiguous situation where the first sector looks like an unpartitioned FAT volume and also a partitioned volume at the same time. I tried to correct that problem, but in the process I managed to break the case where there is an unpartitioned FAT volume that has the extended form of BIOS parameter block. I think I have now fixed that breakage... At least I hope so. fdisk + mkdosfs is a mistake-prone combination. Philip Macpherson wrote: It now works. Jerub on the wiki helped me with this. [14:14] Jerub crazy_bus: I found just now that a drive with a partition table and a fat partition has that problem. [14:14] Jerub but one with no partition taboe, and /dev/sda itself formatted as FAT, did not have that problem. I formatted so I had no partition and then open firmware was able to read it. Maybe this should be mentioned on the wiki. Thanks for all your help, Philip ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Best regards, Yuan Chao ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Unable to update my machine
On 8/31/07, Mitch Bradley [EMAIL PROTECTED] wrote: The fact that it does work from the ok prompt suggests that the problem is indeed the USB detection instead of the partitioning. Is this a Mmm... originally, according to the wiki and previous discussions, most problem seems lead to partitioning. Maybe this slow detection issue should worth listed on wiki? FLASH device or a real disk? We have seen some USB disks that take several seconds to detect. It's a cheap and slow USB 2.0 flash drive. When you hold down the game key to get the ok prompt, that gives the USB device a longer time between when USB power is applied and when enumeration starts - power is applied before the Release the game key message and enumeration happens afterwards, so you can control the time delay by holding the key longer. It should be possible to auto-boot by holding the key, then releasing it, then letting the countdown expire without typing the game key. You can also hold down a different game key, not the X one. Any game key will trigger the Release the game key delay, but only the X key enables the OK prompt. Ok. I'll try how it works. I am hesitant to increase the USB enumeration time delay, because that would penalize the majority of systems that will boot nearly always from NAND FLASH. Sure. -- Best regards, Yuan Chao ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: EXA performance
Jim Gettys wrote: I'm worried about the fact that Cairo likes to do things 32 bits and they then have to be converted and composited at 16 bits; Here are results of two runs of the cairo's performance test suite, at 16 and 24 bpp. Test hardware is a B4, xserver-1.4-branch, cairo 1.4.10. This time 24 bpp is overall better. Only cairo_paint() is slower at 24, but not cairo_paint_with_alpha(), which is actually a lot faster. I oprofiled the whole runs, but haven't found significant differences between 16 and 24 bpp. Probably a profiling of the single tests could be more useful. Output of cairo-perf-diff (nicer html format attached): old: cairo-perf-16 new: cairo-perf-24 Speedups xlib-rgb paint-with-alpha_similar_rgb_over-512 192.24 0.06% - 47.68 0.16%: 4.04x speedup ███ xlib-rgb paint-with-alpha_similar_rgb_over-256 48.51 0.14% - 12.39 0.56%: 3.95x speedup ███ xlib-rgb paint-with-alpha_image_rgb_over-256 63.25 0.26% - 29.27 0.51%: 2.17x speedup █▏ xlib-rgb paint-with-alpha_image_rgb_over-512 250.25 1.01% - 122.63 2.40%: 2.09x speedup █▏ xlib-rgb paint-with-alpha_similar_rgba_over-512 180.26 0.08% - 86.75 0.10%: 2.08x speedup █▏ xlib-rgb paint-with-alpha_similar_rgba_over-256 45.66 0.13% - 22.17 0.34%: 2.07x speedup █▏ xlib-rgb fill_similar_rgb_over-256 16.43 0.52% - 9.66 0.95%: 1.71x speedup ▊ xlib-rgb paint-with-alpha_image_rgba_over-256 62.87 0.34% - 39.25 0.48%: 1.61x speedup ▋ xlib-rgb paint-with-alpha_image_rgba_over-512 248.95 0.32% - 159.74 0.45%: 1.56x speedup ▋ xlib-rgb stroke_similar_rgb_over-256 37.00 0.26% - 25.80 0.40%: 1.44x speedup ▌ xlib-rgb fill_similar_rgb_over-1285.71 1.08% - 4.05 1.88%: 1.42x speedup ▍ xlib-rgb fill_similar_rgba_over-256 17.66 0.52% - 12.71 0.61%: 1.40x speedup ▍ xlib-rgb paint-with-alpha_linear_rgb_over-256 88.94 0.21% - 65.39 0.27%: 1.36x speedup ▍ xlib-rgb paint-with-alpha_linear_rgba_over-256 88.53 0.24% - 64.95 0.26%: 1.36x speedup ▍ xlib-rgb paint-with-alpha_linear_rgb_over-512 354.73 0.19% - 265.89 0.47%: 1.34x speedup ▍ xlib-rgb paint-with-alpha_linear_rgba_over-512 352.53 0.24% - 264.01 0.46%: 1.34x speedup ▍ xlib-rgb fill_image_rgb_over-256 24.06 0.52% - 18.41 0.62%: 1.31x speedup ▍ xlib-rgbstroke_similar_rgba_over-256 37.82 0.26% - 29.30 0.33%: 1.30x speedup ▎ xlib-rgb fill_similar_rgba_over-1286.06 0.50% - 4.82 1.58%: 1.29x speedup ▎ xlib-rgbfill_image_rgba_over-256 26.38 0.46% - 21.45 0.44%: 1.23x speedup ▎ xlib-rgb stroke_similar_rgb_over-128 15.97 0.47% - 13.26 0.59%: 1.21x speedup ▎ xlib-rgb stroke_image_rgb_over-256 49.07 0.24% - 41.01 0.32%: 1.20x speedup ▎ xlib-rgbfill_linear_rgb_over-256 35.22 0.31% - 29.54 0.37%: 1.19x speedup ▎ xlib-rgb paint-with-alpha_radial_rgb_over-256 156.75 0.35% - 133.54 0.14%: 1.17x speedup ▏ xlib-rgb paint-with-alpha_radial_rgb_over-512 627.70 0.15% - 539.14 0.23%: 1.17x speedup ▏ xlib-rgb fill_similar_rgb_over-64 3.26 2.03% - 2.80 2.55%: 1.16x speedup ▏ xlib-rgb paint-with-alpha_radial_rgba_over-256 152.81 0.36% - 132.55 0.78%: 1.16x speedup ▏ xlib-rgb stroke_image_rgba_over-256 51.60 0.22% - 44.51 0.35%: 1.16x speedup ▏ xlib-rgbstroke_similar_rgba_over-128 16.21 0.49% - 14.10 0.46%: 1.15x speedup ▏ xlib-rgb fill_image_rgb_over-1288.01 0.79% - 6.92 0.62%: 1.15x speedup ▏ xlib-rgb stroke_linear_rgb_over-256 67.40 0.22% - 58.75 0.28%: 1.15x speedup ▏ xlib-rgb paint-with-alpha_radial_rgba_over-512 611.50 0.18% - 536.93 0.32%: 1.14x speedup ▏ xlib-rgb fill_similar_rgb_source-256 31.79 0.26% - 27.98 0.22%: 1.14x speedup ▏ xlib-rgb paint-with-alpha_similar_rgb_source-512 306.70 0.07% - 270.02 0.08%: 1.14x speedup ▏ xlib-rgb paint-with-alpha_similar_rgb_source-256 77.35 0.12% - 68.40 0.19%: 1.13x speedup ▏ xlib-rgbfill_linear_rgb_over-128 10.86 0.73% - 9.69 0.84%: 1.12x speedup ▏ xlib-rgb stroke_similar_rgb_source-256 62.25 0.14% - 55.66 0.20%: 1.12x speedup ▏ xlib-rgbfill_image_rgba_over-1288.54 0.66% - 7.66 0.62%: 1.12x speedup ▏ xlib-rgb fill_linear_rgba_over-256 40.03 0.27% - 35.93 0.31%: 1.12x speedup ▏ xlib-rgb stroke_image_rgb_over-128 19.33 0.44% - 17.38 0.53%: 1.11x speedup ▏ xlib-rgb fill_similar_rgba_over-64 3.32 2.15% - 2.99 2.47%: 1.11x speedup ▏ xlib-rgb paint-with-alpha_solid_rgba_source-512 157.75 0.14% - 142.45 0.13%: 1.11x speedup ▏ xlib-rgb paint-with-alpha_solid_rgb_source-512 157.67 0.13% - 142.39 0.13%: 1.11x speedup ▏ xlib-rgb paint-with-alpha_solid_rgba_source-256 39.69 0.24% - 35.98 0.29%: 1.10x speedup ▏ xlib-rgbfill_similar_rgba_source-256 30.51 0.28% - 27.70 0.25%: 1.10x speedup ▏ xlib-rgb fill_similar_rgb_source-1289.92 0.82% - 9.00 0.92%: 1.10x speedup ▏
Question about Libertas and anycast_mask
Dan, The Reliance team in India is having trouble getting the anycast_mask flag set. A mesh interface is configured and up and running. They echo 1 / sys/class/net/msh0/anycast_mask, but subsequent cat /sys/class/net/msh0/anycast_mask return 0. I've never run into this. Can anyone suggest why this is happening, and how to fix it ? John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Question about Libertas and anycast_mask
On Fri, 2007-08-31 at 10:03 -0400, John Watlington wrote: Dan, The Reliance team in India is having trouble getting the anycast_mask flag set. A mesh interface is configured and up and running. They echo 1 / sys/class/net/msh0/anycast_mask, but subsequent cat /sys/class/net/msh0/anycast_mask return 0. I've never run into this. Can anyone suggest why this is happening, and how to fix it ? We need the kernel version and firmware version they are using. Are they on an XO? A school server? Have they modified anything? What's the git commit hash of the kernel, or the version of the kernel RPM? Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Question about Libertas and anycast_mask
You nailed it. They had accidentally installed an old version of firmware, thanks to some out-of-date wiki instructions. Thanks, John On Aug 31, 2007, at 10:08 AM, Dan Williams wrote: On Fri, 2007-08-31 at 10:03 -0400, John Watlington wrote: Dan, The Reliance team in India is having trouble getting the anycast_mask flag set. A mesh interface is configured and up and running. They echo 1 / sys/class/net/msh0/anycast_mask, but subsequent cat /sys/class/net/msh0/anycast_mask return 0. I've never run into this. Can anyone suggest why this is happening, and how to fix it ? We need the kernel version and firmware version they are using. Are they on an XO? A school server? Have they modified anything? What's the git commit hash of the kernel, or the version of the kernel RPM? Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Please test Xorg 1.4
Yuan Chao wrote: On 8/28/07, Bernardo Innocenti [EMAIL PROTECTED] wrote: I got reports of corrupted scrollbars in the Web activity, but it turns out that it also happens with X 1.3, and only I also met the corrupted scrollbars in OS557. Is there a trac ticket for this bug? It's pretty ugly when you see it ;-) Except that the touch pad speed/acceleration is too fast to me. This makes the newly enabled tap-to-click in this version not very useful. Wondering how to adjust on this? In /home/olpc/.xinitrc, there's an xset m default line. You can edit it like this: To set mouse acceleration and threshold: m [acc_mult[/acc_div] [thr]]m default That line is pretty useless btw, I'd recommend removing it to save a few ms of boot time ;-) -- // Bernardo Innocenti - One Laptop Per Child \X/ http://www.codewiz.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
emergency server maintenance: 8/31
Public-facing development services (bugtracker, git, development hosting) are offline for emergency maintenance effective immediately, and for an expected duration of under 6 hours. Apologies for the inconvenience. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Build 542.3 out with local fixes
Please test as this will become the next stable build. Build 542.3 fixes sugar so that it installed the translation files and also fixes a Journal bug for the Spanish locale. http://olpc.download.redhat.com/olpc/streams/development/build542.3/ -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] emergency server maintenance: 8/31
On Aug 31, 2007, at 5:19 PM, Ivan Krstić wrote: Public-facing development services (bugtracker, git, development hosting) are offline for emergency maintenance effective immediately, and for an expected duration of under 6 hours. I'm extending this timeframe by up to another 12 hours, due to unexpected difficulties. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] emergency server maintenance: 8/31
On Aug 31, 2007, at 11:47 PM, Ivan Krstić wrote: I'm extending this timeframe by up to another 12 hours, due to unexpected difficulties. All services are up and looking good. If anyone notices something strange or broken, please let me know as soon as possible. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
