[fedora-arm] Samsung Chromebook 2 (Peach Pi), nv u-boot, kernel and initrd
Hi, Has anybody managed to get this to work? I can get to work with a custom kernel, but only using vboot and only without initrd. As soon as I add the initramfs into the .its file, the resulting image doesn't work. Is there a specific load/entry address that has to be used for the initramfs? I tried using 0x5000 which works on my Chromebook 1 (snow), but it doesn't make any difference. I also built a mainline u-boot which supposedly supports the peach pi chromebook, but I cannot get that to boot anything at all. The kernel fit image (kernel+dtb) that boots fine using vboot (signed for vboot using vbutil_kernel) loads fine in nv u-boot, but the boot gets stuck at Starting kernel ... I am using load address 0x4200 in u-boot (since that works on snow. Is the memory map on the peach pi radically different? I tried a few different ranges but nothing results in the boot completing. Has anyone managed to get this to work using either nv u-boot or a fit image containing the initramfs? I even tried building the initramfs cpio into the kernel, but that also causes it to stop booting with vboot. The only thing I can think of is the load/entry addresses being very picky for both and some FDT disagreement between nv u-boot and the kernel (u-boot has exynos5800-peach-pi.dts and the chromeos kernel sources use exynos5422-peach-pi.dts). I am running out of ideas of what else to try. :-( Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Re: armhf dnf is not working on aarch64 kernel
On 2016-04-27 14:09, Chanho Park wrote: Hi Peter, On Wednesday, April 27, 2016, Peter Robinson wrote: On Wed, Apr 27, 2016 at 1:18 PM, Chanho Park wrote: Hi all, I want to use the armhf fedora rootfs on the aarch64 bit kernel. You can't, it's not a use case we support. Why not? All arm binaries can be runnable on aarch32 mode of aarch64 kernel. When I ran the dnf command on the armhf image with aarch64 kernel, the dnf command was failed with below error. dnf -v install mesa cachedir: /var/cache/dnf DNF version: 1.1.6 Failed to synchronize cache for repo 'rpmfusion-free-updates' from 'http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-released-22&arch=aarch64': Cannot prepare internal mirrorlist: No URLs in mirrorlist, disabling. repo: using cache for: fedora not found updateinfo for: Fedora 22 - aarch64 repo: using cache for: updates not found deltainfo for: Fedora 22 - aarch64 - Updates not found updateinfo for: Fedora 22 - aarch64 - Updates Actually, armhf binaries/rootfs can be executed even aarch64 kernel(fully compatible with armhf). Maybe the dnf command tries to find its repo from uname call. $ uname -m aarch64 The rpm install was also failed because fedora doesn't have any rpm platform file So, I added below file. It is able to install armhf rpm file even aarch64 kernel. cat /etc/rpm/platform armv7hl-fedora-linux-gnu The question is 'how can I run 'dnf' command on armhf fedora with aarch64 kernel?' No, the ARMv7 and aarch64 ABI aren't compatible, the only way we support ARMv7 on aarch64 is via virtualisation. We will not be supporting this or a "multilib" usecase. The aarch64 kernel can execute both aarch64 and aarch32(fully compatible armv7) binaries. For example, the kernel of raspberry pi 3 is aarch64 and fedora arm version can't run on rpi3. Even all binaries can run on it but only dnf command can't do that. I can confirm that armv7hl (and armv5tel) userspace DOES work in a chroot on aarch64 provided you use a sensible kernel (specifically meaning that it uses 4KB memory pages rather than 64KB memory pages). I am running CentOS 7 armv7hl in a chroot and LXC/docker containers on CentOS 7 aarch64 (with aarch64 kernel configured for 4KB pages and backward compatibility enabled). So if the above doesn't work (with /etc/rpm/platform configured), it has to be considered a bug. Gordan ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: armhf dnf is not working on aarch64 kernel
On 2016-04-27 14:17, Peter Robinson wrote: On Wed, Apr 27, 2016 at 2:09 PM, Chanho Park wrote: Hi Peter, On Wednesday, April 27, 2016, Peter Robinson wrote: On Wed, Apr 27, 2016 at 1:18 PM, Chanho Park wrote: > Hi all, > > I want to use the armhf fedora rootfs on the aarch64 bit kernel. You can't, it's not a use case we support. Why not? All arm binaries can be runnable on aarch32 mode of aarch64 kernel. Not exactly actually, it's possible to have aarch64/ARMv8 CPUs that don't have the 32 bit components. That this is not the case here, though. So the answer doesn't seem to answer the question. > The question is 'how can I run 'dnf' command on armhf fedora with > aarch64 kernel?' No, the ARMv7 and aarch64 ABI aren't compatible, the only way we support ARMv7 on aarch64 is via virtualisation. We will not be supporting this or a "multilib" usecase. The aarch64 kernel can execute both aarch64 and aarch32(fully compatible armv7) binaries. For example, the kernel of raspberry pi 3 is aarch64 and fedora arm version can't run on rpi3. Even all binaries can run on it but only dnf command can't do that. Actually that isn't entirely true. The kernel that's currently shipped in raspbian for RPi3 is actually an ARMv7 kernel where the firmware boots the ARM cores as v7 cores. The kernel code that's running there is ARMv7 code not cortex-a53 code paths. That is a fairly special usecase and you can actually do that on Fedora ARMv7 with a Fedora ARMv7 kernel, not a aarch64 kernel. Again, this doesn't answer the question and ignored the most obvious and common case, where we have ARMv8 hardware (e.g. X-Gene) that fully supports ARMv7 instruction set for backward compatibility, running an aarch64 kernel with 4KB memory pages (the sensible size) and backward compatibility option enabled (no detriment to doing so). You can then run an armv7hl (or armv5tel) userspace in a chroot with no ill effects. I run a setup like this where I run hard-float and soft-float 32-bit userspace docker containers even though the host userspace and kernels are aarch64. I see no sane reason why this would not be a supported configuration, since the usefulness of it seems very obvious. ARM multilib is something we explicitly decided not to support when we were dealing with that. Multilib is a mess on x86, it's not a mess we need on ARM. We aren't talking about multilib here, we are talking about chroots/containers which are a very separate use case. But since you mentioned it, if we don't have multilib because it's a mess, why is it that aarch64 Fedora still uses lib64 rather than lib directories? I don't see how this is less of a mess than what we have on x86 at all. It seems we have just as big a mess but without the feature benefits. Gordan ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: armhf dnf is not working on aarch64 kernel
On 2016-04-27 14:45, Peter Robinson wrote: > I want to use the armhf fedora rootfs on the aarch64 bit kernel. You can't, it's not a use case we support. Why not? All arm binaries can be runnable on aarch32 mode of aarch64 kernel. Not exactly actually, it's possible to have aarch64/ARMv8 CPUs that don't have the 32 bit components. That this is not the case here, though. So the answer doesn't seem to answer the question. Actually it does answer the question. The question is about "32 bit binaries on aarch64" and there are cases when they can't run. And that justified not caring about all other cases? > The question is 'how can I run 'dnf' command on armhf fedora with > aarch64 kernel?' No, the ARMv7 and aarch64 ABI aren't compatible, the only way we support ARMv7 on aarch64 is via virtualisation. We will not be supporting this or a "multilib" usecase. The aarch64 kernel can execute both aarch64 and aarch32(fully compatible armv7) binaries. For example, the kernel of raspberry pi 3 is aarch64 and fedora arm version can't run on rpi3. Even all binaries can run on it but only dnf command can't do that. Actually that isn't entirely true. The kernel that's currently shipped in raspbian for RPi3 is actually an ARMv7 kernel where the firmware boots the ARM cores as v7 cores. The kernel code that's running there is ARMv7 code not cortex-a53 code paths. That is a fairly special usecase and you can actually do that on Fedora ARMv7 with a Fedora ARMv7 kernel, not a aarch64 kernel. Again, this doesn't answer the question and ignored the most obvious and common case, where we have ARMv8 hardware (e.g. X-Gene) that fully supports ARMv7 instruction set for backward compatibility, running an aarch64 kernel with 4KB memory pages (the sensible size) and backward compatibility option enabled (no detriment to doing so). What about Seattle that explicitly needs a kernel with 64K pages? Does one broken implementation justify a decision detrimental to all other uses? Linus himself has had some choice words over time about defaulting to large pages: http://yarchive.net/comp/linux/page_sizes.html Are there some specific new developments that fundamentally deprecate those words of wisdom? Additionally, are you saying that 64KB page size support is mandatory on ARMv8 but 4KB is not? I cannot seem to find any documentation from ARM stating this explicitly, the closest I can find is that either/both can be available. You can then run an armv7hl (or armv5tel) userspace in a chroot with no ill effects. I run a setup like this where I run hard-float and soft-float 32-bit userspace docker containers even though the host userspace and kernels are aarch64. I see no sane reason why this would not be a supported configuration, since the usefulness of it seems very obvious. Sure, but we made a decision that our kernels would be 64K pages on aarch64 some time ago. We need to make a decision that is not easy to change to be compatible moving forward for a new architecture that is evolving. Sure right at THIS VERY MOMENT the hardware that YOU'RE using might support that configuration but there is HW that is available right now that needs a configuration that you don't currently have and there could well be HW soon (I don't know, and if I did it's very likely I couldn't comment anyway) that doesn't have the optional bits needed for aarch32. And the advantage of not anti-supporting it while and where it is available is? So while it's easy to say "it works for me" sure, you can hack things how ever you like and sit back from the edges commenting, we need to make a decisions such as page sizes that we'll need to support for years to come based on the information we have at the time. Other distros have made similar decisions, others haven't, that's their choices. Decisions to support for years on a distro with an estimated 13 month shelf life? Either way if you need to build a custom kernel for a ARMv7 userspace it's up to you and that use case is fine, it's your decision to make. ARM multilib is something we explicitly decided not to support when we were dealing with that. Multilib is a mess on x86, it's not a mess we need on ARM. We aren't talking about multilib here, we are talking about chroots/containers which are a very separate use case. It might be a separate usecase but it doesn't make it less relevant for reasons why we don't support the usecase. If it is because ARM32 support is optional in ARMv8, then why bring up multilib at all? But since you mentioned it, if we don't have multilib because it's a mess, why is it that aarch64 Fedora still uses lib64 rather than lib directories? I don't see how this is less of a mess than what Because lib64 is a directory that all current 64 bit architectures that Fedora supports uses. It's about consistency rather than multilib. How is dnf being the seemingly only thing that breaks in this case while all other binaries work fine in line wi
[fedora-arm] Re: armhf dnf is not working on aarch64 kernel
On 2016-04-27 16:38, Dennis Gilmore wrote: On Wednesday, April 27, 2016 1:37:35 PM CDT Peter Robinson wrote: On Wed, Apr 27, 2016 at 1:18 PM, Chanho Park wrote: > Hi all, > > I want to use the armhf fedora rootfs on the aarch64 bit kernel. You can't, it's not a use case we support. To further this piece, you would need to have code changes in rpm, dnf, yum, packagekit, mock and everything else dealing with rpm installation and removal. none of the tooling supports what you are asking. That must be some very recent code. I can confirm that CentOS 7 armv7hl works just fine with just the /etc/rpm/platform configured appropriately in the chroot on an aarch64 host (with a non-default kernel built with 4KB pages). No dnf, granted, since that is more recent than F19, but all the rest of it works just fine. So unless there has been a lot of bit rot since F19, it seems unlikely any of the rest of it would need fixing. Some aarch64 hardware will not run 32 bit binaries at all. when we started on the path of supporting aarch64 we mad a concious decision not to support running armhfp or arm 32 bit binaries on 64 bit environments. the supported way to run 32 bit binaries is to do so in a 32 bit vm. Unless I am missing something, even ignoring the very non-trivial performance hit of running in a VM, if the hardware doesn't support the 32-bit instruction set, then the VMs won't work either, so I'm not sure what the point being made here is. Gordan ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: armhf dnf is not working on aarch64 kernel
On 2016-04-27 16:56, Peter Robinson wrote: On Wed, Apr 27, 2016 at 1:18 PM, Chanho Park wrote: > Hi all, > > I want to use the armhf fedora rootfs on the aarch64 bit kernel. You can't, it's not a use case we support. To further this piece, you would need to have code changes in rpm, dnf, yum, packagekit, mock and everything else dealing with rpm installation and removal. none of the tooling supports what you are asking. That must be some very recent code. I can confirm that CentOS 7 armv7hl works just fine with just the /etc/rpm/platform configured appropriately in the chroot on an aarch64 host (with a non-default kernel built with 4KB pages). No dnf, granted, since that is more recent than F19, but all the rest of it works just fine. Maybe that's something that CentOS have added (don't know, haven't looked), RHELSA doesn't support it that I'm aware of and they're definitely only 64K page size. The biggest change is in rpm and the arch mappings there. They might not support it, but it most certainly works. There are no changes specific to this that I can find in CentOS. All I changed was rebuilt the host kernel with 4KB pages and ARM32 support (still an aarch64 kernel). C7 armv7hl guest is completely unmodified apart from the /etc/rpm/platform being set explicitly. The main point being that the original assertion that making this work would require rpm, yum, packagekit, mock and other code changes doesn't seem to be correct based on empirical evidence. So unless there has been a lot of bit rot since F19, it seems unlikely any of the rest of it would need fixing. Maybe, early Fedora on aarch64 was 4K pages during bringup but it became clear early on that various orgs wanted 64K pages so the decision was made to move. Despite Linus' words of wisdom to the contrary over the years. :-( Some aarch64 hardware will not run 32 bit binaries at all. when we started on the path of supporting aarch64 we mad a concious decision not to support running armhfp or arm 32 bit binaries on 64 bit environments. the supported way to run 32 bit binaries is to do so in a 32 bit vm. Unless I am missing something, even ignoring the very non-trivial performance hit of running in a VM, if the hardware doesn't support the 32-bit instruction set, then the VMs won't work either, so I'm not sure what the point being made here is. Yes, because the instructions can be dealt with by the hypervisor whether through emulation, or some other mechanism. If it's going to run in emulation you might as well run it on some highest end possible x86 hardware, it'll be slightly less excruciatingly slow. And last I checked, that still had issues with availability of kernels and architectures emulated. Gordan ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: armhf dnf is not working on aarch64 kernel
On 2016-04-27 19:12, John Dulaney wrote: On Wed, Apr 27, 2016 at 05:04:38PM +0100, Gordan Bobic wrote: > >Maybe that's something that CentOS have added (don't know, haven't >looked), RHELSA doesn't support it that I'm aware of and they're >definitely only 64K page size. The biggest change is in rpm and the >arch mappings there. They might not support it, but it most certainly works. There are no changes specific to this that I can find in CentOS. All I changed was rebuilt the host kernel with 4KB pages and ARM32 support (still an aarch64 kernel). C7 armv7hl guest is completely unmodified apart from the /etc/rpm/platform being set explicitly. The main point being that the original assertion that making this work would require rpm, yum, packagekit, mock and other code changes doesn't seem to be correct based on empirical evidence. It may work with rpm, but, as per the original post, dnf does not support it, and dnf should not support it as long as Fedora does not support a 32 bit userspace on aarch64. That sounds an awful lot like trying to justify what is arguably a bug in dnf, specifically, that unlike yum that it is replacing, it ignores /etc/rpm/platform. Despite Linus' words of wisdom to the contrary over the years. :-( Linus is not God, and we'd rather support as broad as possible a range of hardware. 1) He is not God, but he is smarter and better informed than most on the subject at hand. Can you link to an overwhelming counter-argument from someone even remotely similarly qualified? 2) Nobody has yet pointed at ARM's own documentation (I did ask earlier) that says that 4KB memory page support is optional rather than mandatory. The closest I can find on this from ARM are the following: http://infocenter.arm.com/help/topic/com.arm.doc.den0024a/ch12s04.html https://www.arm.com/files/downloads/ARMv8_white_paper_v5.pdf https://www.arm.com/files/downloads/ARMv8_Architecture.pdf and all of the above list that ARMv8 should support both 4KB and 64KB memory pages. And if 4KB support is in fact mandatory, then arguably the decision to opt for 64KB for the sake of supporting Seattle was based on wanting to support broken hardware that turned out to be too little too late anyway. >Yes, because the instructions can be dealt with by the hypervisor >whether through emulation, or some other mechanism. If it's going to run in emulation you might as well run it on some highest end possible x86 hardware, it'll be slightly less excruciatingly slow. And last I checked, that still had issues with availability of kernels and architectures emulated. Actually, with kvm, you get pretty much the same speed as native aarch64 vms. Running armv7hl VMs on ARMv8 hardware without ARM32 support? (Ignoring for the moment the fact that even when running the same guest and host architectures in a VM comes with a much greater impact than "pretty much the same speed as native".) Also, server grade aarch64 h/w will give you pretty decent performance. I'm less sure about SBCs; they're dependent on the SoC used. I am quite aware. I am very pleased with my Gigabyte MP30-AR0 with an X-Gene and 128GB of RAM. But that I can buy off the shelf right now, whereas standard form factor Seattles that were promised a couple of years ago are still nowhere to be seen (what I was referring to by too little too late above). On the whole, 32 bit arm vms are going to have the same performance on aarch64 as i686 on x86_64. Are you saying that on hardware that is lacking the optional ARM32 support a VM running ARM32 binaries is going to run with approximately same performance as if it were running an aarch64 OS? If so, how? I am specifically interested because a part of this debate is hinging on the statement that 32-bit guests are only supported in VMs rather than chroots because on ARMv8 32-bit support is optional, but it is not at all clear or demonstrated that running a 32-bit ARM guest on ARMv8 without 32-bit native support will not suffer the same hit as running it in QEMU emulation on any other CPU architecture. So either something magical happens that means that the missing 32-bit support doesn't have to be fully emulated in software, or the entire argument being made for VMs instead of chroots is entirely erroneous. Gordan ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: armhf dnf is not working on aarch64 kernel
On 2016-04-28 19:49, Jon Masters wrote: Hi Gordan, Peter, all, On 04/27/2016 03:39 PM, Gordan Bobic wrote: On 2016-04-27 19:12, John Dulaney wrote: On Wed, Apr 27, 2016 at 05:04:38PM +0100, Gordan Bobic wrote: > >Maybe that's something that CentOS have added (don't know, haven't >looked), RHELSA doesn't support it that I'm aware of and they're >definitely only 64K page size. The biggest change is in rpm and the >arch mappings there. They might not support it, but it most certainly works. There are no changes specific to this that I can find in CentOS. All I changed was rebuilt the host kernel with 4KB pages and ARM32 support (still an aarch64 kernel). C7 armv7hl guest is completely unmodified apart from the /etc/rpm/platform being set explicitly. First of all, Jon, thank you for your thoughts on this matter. Allow me to add a few thoughts. I have been working with the ARM vendors (as well as the ARM Architecture Group) since before the architecture was announced, and the issue of page size and 32-bit backward compatibility came up in the earliest days. I am speaking from a Red Hat perspective and NOT dictating what Fedora should or must do, but I do strongly encourage Fedora not to make a change to something like the page size simply to support a (relatively) small number of corner cases. IMO, the issue of backward compatibility is completely secondary to the issue of efficiency of memory fragmentation/occupancy when it comes to 64KB pages. And that isn't a corner case, it is the overwhelmingly primary case. It is better to focus on the longer term trajectory, which the mobile handset market demonstrates: the transition to 64-bit computing hardware will be much faster than people thought, and we don't need to build a legacy (we don't a 32-bit app store filled with things that can't easily be rebuilt, and all of them have been anyway). I think going off on a tangent about the mobile devices needlessly muddies the water here. 64-bitness is completely independent of memory page size and pros and cons of different sizes. If anything on mobile devices where memory is scarcer, smaller pages will result in lower fragmentation and less wasted memory. That doesn't mean we shouldn't love 32-bit ARM devices, which we do. In fact, there will be many more 32-bit ARM devices over coming years. This is especially true for IoT clients. But there will also be a large (and rapidly growing) number of very high performance 64-bit systems. Many of those will not have any 32-bit backward compatibility, or will disable it in the interest of reducing the amount of validation work. Having an entire separate several ISAs just for the fairly nonexistent field of proprietary non-recompilable third party 32-bit apps doesn't really make sense. Sure, running 32-bit via multilib is fun and all, but it's not really something that is critical to using ARM systems. Except where there's no choice, such as closed source applications (Plex comes to mind) or libraries without appropriate ARM64 implementation such as Mono. I'm sure pure aarch64 will be supported by it all at some point, but the problem is real today. But OK, for the sake of this discussion let's completely ignore the 32-bit support to simplify things. The mandatory page sizes in the v8 architecture are 4K and 64K, with various options around the number of bits used for address spaces, huge pages (or ginormous pages), and contiguous hinting for smaller "huge" pages. There is an option for 16K pages, but it is not mandatory. In the server specifications, we don't compel Operating Systems to use 64K, but everything is written with that explicitly in mind. By using 64K early we ensure that it is possible to do so in a very clean way, and then if (over the coming years) the deployment of sufficient real systems proves that this was a premature decision, we still have 4K. The real question is how much code will bit-rot due to not being tested with 4KB pages, and how difficult it will be to subsequently push through patches all the way from upstream projects down to the level of the distros we are all fans of here. And even then, the consequence will be software that is broken for anyone who has a need to do anything but the straight-and-narrow case that the distro maintainers envisaged. The choices for preferred page size were between 4K and 64K. In the interest of transparency, I pushed from the RH side in the earliest days (before public disclosure) to introduce an intentional break with the past and support only 64K on ARMv8. Breaking with the past is all well and good, but I am particularly interested in the technical reasons for doing so. What benefits exceed the drawbacks of the significant increase in fragmentation in the general case (apart from databases - and for that we have huge pages regardless).
[fedora-arm] Re: armhf dnf is not working on aarch64 kernel
On 2016-04-28 22:26, Jon Masters wrote: Hi Gordan, On 04/28/2016 05:00 PM, Gordan Bobic wrote: On 2016-04-28 19:49, Jon Masters wrote: First of all, Jon, thank you for your thoughts on this matter. No problem :) Allow me to add a few thoughts. I have been working with the ARM vendors (as well as the ARM Architecture Group) since before the architecture was announced, and the issue of page size and 32-bit backward compatibility came up in the earliest days. I am speaking from a Red Hat perspective and NOT dictating what Fedora should or must do, but I do strongly encourage Fedora not to make a change to something like the page size simply to support a (relatively) small number of corner cases. IMO, the issue of backward compatibility is completely secondary to the issue of efficiency of memory fragmentation/occupancy when it comes to 64KB pages. And that isn't a corner case, it is the overwhelmingly primary case. Let's keep to the memory discussion then, I agree. On the fragmentation argument, I do agree this is an area where server/non-server uses certainly clash. It might well be that we later decide in Fedora that 4K is the right size once there are more 64-bit client devices. As an additional factoid to throw into this, one obvious case where large pages can be beneficial is databases. But speaking as a database guy who measured the positive impact of using huge pages on MySQL, I can confirm that the performance improvement arising from putting the buffer pool into 1MB huge pages instead of 4KB pages is in the 3% range. And that is when using 1MB pages instead of 4KB pages. While I haven't measured it, it doesn't seem unreasonable to extrapolate the following: 1) 4KB -> 64KB pages will make less difference than 4KB -> 1MB pages in this case this use case that is supposed to be the prime example where larger memory pages make a measurable difference. 2) Regardless of whether we use 4KB or 64KB standard pages, we can still use huge pages anyway, further minimizing the usefulness of the 64KB compromise. Having an entire separate several ISAs just for the fairly nonexistent field of proprietary non-recompilable third party 32-bit apps doesn't really make sense. Sure, running 32-bit via multilib is fun and all, but it's not really something that is critical to using ARM systems. Except where there's no choice, such as closed source applications (Plex comes to mind) or libraries without appropriate ARM64 implementation such as Mono. I'm sure pure aarch64 will be supported by it all at some point, but the problem is real today. It's definitely true that there are some applications that aren't yet ported to ARMv8, though that list is fairly small (compared with IA32). But OK, for the sake of this discussion let's completely ignore the 32-bit support to simplify things. OK :) The mandatory page sizes in the v8 architecture are 4K and 64K, with various options around the number of bits used for address spaces, huge pages (or ginormous pages), and contiguous hinting for smaller "huge" pages. There is an option for 16K pages, but it is not mandatory. In the server specifications, we don't compel Operating Systems to use 64K, but everything is written with that explicitly in mind. By using 64K early we ensure that it is possible to do so in a very clean way, and then if (over the coming years) the deployment of sufficient real systems proves that this was a premature decision, we still have 4K. The real question is how much code will bit-rot due to not being tested with 4KB pages With respect, I think it's the other way around. We have another whole architecture targeting 4K pages by default, and (regretfully perhaps, though that's a personal opinion) it's a pretty popular choice that many people are using in Fedora today. So I don't see any situation in which 4K bitrots over 64K. I did see the opposite being very likely if we didn't start out with 64K as the baseline going in on day one. Perhaps. Hopefully this won't be an issue at least as long as Fedora ships both 32-bit and 64-bit ARM distros. I also asked a few of the chip vendors not to implement 32-bit execution (and some of them have indeed omitted it after we discussed the needs early on), and am aggressively pushing for it to go away over time in all server parts. But there's more to it than that. In the (very) many early conversations with various performance folks, the feedback was that larger page sizes than 4K should generally be adopted for a new arch. Ideally that would have been 16K (which other architectures than x86 went with also), but that was optional. Optionally necessarily means "does not exist". My advice when Red Hat began internal work on ARMv8 was to listen to the experts. Linus is not an expert? Note that I never said he isn't an expe
[fedora-arm] SheevaPlug / Fedora 12
Hi,
I'm trying to get Fedora 12 working on the SheevaPlug and I'm having a
fair number of problems. After several hours of trial and error and
different u-boot images, I'm now pretty convinced that ext2ls doesn't
actually properly understand the ext2 file system. Creating the ext2 FS
on the SD card with non-standard parameters (e.g. different block size
and/or -E stride/stripe-width/resize parameters seems to confuse it
quite badly. It starts to list files for specified directories that are
most definitely not in the directory specified. The boot loader also
seems to have issues finding the kernel image.
I finally got it to the point where it almost boots, but then the screen
fills up with garbage and the only cure is a hard-reset. I have created
the ext2 fs on an SD card, and put the uimage under /boot on it. In the
boot loader, I did the following:
setenv mainlineLinux yes
setenv arcNumber 2097
setenv bootargs_console console=ttyS0,115200
setenv bootargs_root 'rw root=/dev/mmcblk0p1 rootdelay=10 rootfstype=ext2'
setenv bootcmd_mmc 'mmcinit; ext2load mmc 0 0x80
/boot/uImage-2.6.30-sheevaplug'
setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root);
run bootcmd_mmc; bootm 0x080'
saveenv
reset
(Please excuse the line wrapping above.)
When it comes to the point where it boots, I get this (trailing garbage
is what comes up):
U-Boot 1.1.4 (Dec 27 2009 - 22:03:21) Marvell version: 3.4.27
U-Boot code: 0060 -> 0067FFF0 BSS: -> 006CFEE0
Soc: 88F6281 A1 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz
DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x size 256MB
DRAM CS[1] base 0x1000 size 256MB
DRAM Total size 512MB 16bit width
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:512 MB
Flash: 0 kB
CPU : Marvell Feroceon (Rev 1)
Streaming disabled
Write allocate disabled
USB 0: host mode
PEX 0: interface detected no Link.
Net: egiga0 [PRIME]
Hit any key to stop autoboot: 0
SDHC found. Card desciption is:
Manufacturer: 0x02, OEM "TM"
Product name: "SA32G", revision 0.6
Serial number: 55312
Manufacturing date: 10/2010
CRC:0x00, b0 = 0
2096012 bytes read
## Booting image at 0080 ...
Image Name: Linux-2.6.30-0-v2.6.30
Created: 2009-06-26 5:29:13 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:2095948 Bytes = 2 MB
Load Address: 8000
Entry Point: 8000
Verifying Checksum ... OK
OK
F
Starting kernel ...
6
�
Uncompressing
Linux.D�q)i-�:4URz2,#U&(J-(5��i�]PH.Rj0Z(�J�i��da).�Jew��].�
d��q�Je5gAZ�x�B0��eV�N ��KAz:I:�JQ�jEPke;�eA�zZ( ^ �
�
�
-
-
-
+
�Ip(UKY�7 b��W]u(U+A2-��jx(�A,��T�Y3.�vAx��A2�;-J]s(Q�]3fdF_V�Ip-We�wa�{Q{�
bTB:�gS7+�JV(�] &BZ,R�H,
I0��]V�Ip-We��S3,'�]
T
�
�
(
�
�
�
f
�f4[-i@)��F4[��
�d1�]z-�wI9��t*�Q2.
F^��WY7;�i8�WeP�ej(5qXҕD9V�I:�$�z��Umhttps://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
Sorry, just remembered that this might be useful to add: Marvell>> printenv baudrate=115200 loads_echo=0 rootpath=/mnt/ARM_FS/ console=a e=ttyS0,115200 mtdparts=nand_mtd:0xc0...@0(uboot)ro,0x1ff00...@0x10(root) CASset=min MALLOC_len=1 ethprime=egiga0 image_name=uImage standalone=fsload 0x200 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end); ethmtu=1500 mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500 usb0Mode=host yuk_ethaddr=00:00:00:EE:51:81 nandEcc=1bit netretry=no rcvrip=169.254.100.100 loadaddr=0x0200 autoload=no ethact=egiga0 netmask=255.255.255.0 ethaddr=F0:AD:4E:00:06:54 run_diag=no serverip=10.2.252.2 ipaddr=10.2.100.200 gatewayip=10.2.255.254 filesize=73b20 fileaddr=200 bootargs=console=ttyS0,115200 mtdparts=nand_mtd:0x400...@0x10(uImage),0x1fb00...@0x50(rootfs) rw root=/dev/mtdblock1 rw ip=e bootargs_end=:::DB88FXX81:eth0:none naMonExt=no arcNumber=2097 bootargs_console=console=ttyS0,115200 bootargs_root=rw root=/dev/mmcblk0p1 rootdelay=10 rootfstype=ext2 bootcmd_mmc=mmcinit; ext2load mmc 0 0x80 /boot/uImage-2.6.30-sheevaplug bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_mmc; bootm 0x080 stdin=serial stdout=serial stderr=serial nandEnvBase=enaCpuStream=no mainlineLinux=yes enaMonExt=no enaCpuStream=no enaWrAllo=no pexMode=RC disL2Cache=no setL2CacheWT=yes disL2Prefetch=yes enaICPref=yes enaDCPref=yes sata_dma_mode=yes netbsd_en=no vxworks_en=no bootdelay=3 disaMvPnp=no enaAutoRecovery=yes pcieTune=no Environment size: 1636/131068 bytes My first assumption given the doubt over the sheeva's understanding of the ext2 fs is that it's not getting the right file contents for the kernel, but since it has found the kernel, verified the checksum and decompressed it, that clearly isn't the case. So what else could be the problem here? TIA Gordan On 12/18/2010 07:29 PM, Gordan Bobic wrote: > Hi, > > I'm trying to get Fedora 12 working on the SheevaPlug and I'm having a > fair number of problems. After several hours of trial and error and > different u-boot images, I'm now pretty convinced that ext2ls doesn't > actually properly understand the ext2 file system. Creating the ext2 FS > on the SD card with non-standard parameters (e.g. different block size > and/or -E stride/stripe-width/resize parameters seems to confuse it > quite badly. It starts to list files for specified directories that are > most definitely not in the directory specified. The boot loader also > seems to have issues finding the kernel image. > > I finally got it to the point where it almost boots, but then the screen > fills up with garbage and the only cure is a hard-reset. I have created > the ext2 fs on an SD card, and put the uimage under /boot on it. In the > boot loader, I did the following: > > setenv mainlineLinux yes > setenv arcNumber 2097 > setenv bootargs_console console=ttyS0,115200 > setenv bootargs_root 'rw root=/dev/mmcblk0p1 rootdelay=10 rootfstype=ext2' > setenv bootcmd_mmc 'mmcinit; ext2load mmc 0 0x80 > /boot/uImage-2.6.30-sheevaplug' > setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); > run bootcmd_mmc; bootm 0x080' > saveenv > reset > > (Please excuse the line wrapping above.) > > When it comes to the point where it boots, I get this (trailing garbage > is what comes up): > > U-Boot 1.1.4 (Dec 27 2009 - 22:03:21) Marvell version: 3.4.27 > > U-Boot code: 0060 -> 0067FFF0 BSS: -> 006CFEE0 > > Soc: 88F6281 A1 (DDR2) > CPU running @ 1200Mhz L2 running @ 400Mhz > SysClock = 400Mhz , TClock = 200Mhz > > DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 > DRAM CS[0] base 0x size 256MB > DRAM CS[1] base 0x1000 size 256MB > DRAM Total size 512MB 16bit width > Addresses 8M - 0M are saved for the U-Boot usage. > Mem malloc Initialization (8M - 7M): Done > NAND:512 MB > Flash: 0 kB > > CPU : Marvell Feroceon (Rev 1) > > Streaming disabled > Write allocate disabled > > > USB 0: host mode > PEX 0: interface detected no Link. > Net: egiga0 [PRIME] > Hit any key to stop autoboot: 0 > SDHC found. Card desciption is: > Manufacturer: 0x02, OEM "TM" > Product name: "SA32G", revision 0.6 > Serial number: 55312 > Manufacturing date: 10/2010 > CRC:0x00, b0 = 0 > > 2096012 bytes read > ## Booting image at 0080 ... > Image Name: Linux-2.6.30-0-v2.6.30 > Created: 2009-06-26 5:29:13 UTC > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size:2095948 Bytes = 2 MB > Load Address:
Re: [fedora-arm] SheevaPlug / Fedora 12
On 12/18/2010 08:03 PM, Andy Green wrote: > On 12/18/10 19:29, Somebody in the thread at some point said: > > Hi - > � >> Uncompressing >> Linux.D�q)i-�:4URz2,#U&(J-(5��i�]PH.Rj0Z(�J�i��da).�Jew��].� >> > > Presumably it started booting fine... stick a 'scope on the serial and > confirm the duration of one bit-time after "Uncompressing Linux" really > is ~8.7us as it should be for 115200bps. No way to really tell if it started booting fine, over and above the output I pasted. I don't have a scope to test, and I don't think that'd work on a USB port, would it? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
On 12/18/2010 08:23 PM, Chris Tyler wrote: > On Sat, 2010-12-18 at 19:36 +0000, Gordan Bobic wrote: >> Sorry, just remembered that this might be useful to add: >> >> Marvell>> printenv >> baudrate=115200 >> loads_echo=0 >> rootpath=/mnt/ARM_FS/ >> console=a >> e=ttyS0,115200 >> mtdparts=nand_mtd:0xc0...@0(uboot)ro,0x1ff00...@0x10(root) >> CASset=min >> MALLOC_len=1 >> ethprime=egiga0 >> image_name=uImage >> standalone=fsload 0x200 $(image_name);setenv bootargs $(console) >> root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end); >> ethmtu=1500 >> mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs >> mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500 >> usb0Mode=host >> yuk_ethaddr=00:00:00:EE:51:81 >> nandEcc=1bit >> netretry=no >> rcvrip=169.254.100.100 >> loadaddr=0x0200 >> autoload=no >> ethact=egiga0 >> netmask=255.255.255.0 >> ethaddr=F0:AD:4E:00:06:54 >> run_diag=no >> serverip=10.2.252.2 >> ipaddr=10.2.100.200 >> gatewayip=10.2.255.254 >> filesize=73b20 >> fileaddr=200 >> bootargs=console=ttyS0,115200 >> mtdparts=nand_mtd:0x400...@0x10(uImage),0x1fb00...@0x50(rootfs) >> rw root=/dev/mtdblock1 rw ip=e >> bootargs_end=:::DB88FXX81:eth0:none >> naMonExt=no >> arcNumber=2097 >> bootargs_console=console=ttyS0,115200 >> bootargs_root=rw root=/dev/mmcblk0p1 rootdelay=10 rootfstype=ext2 >> bootcmd_mmc=mmcinit; ext2load mmc 0 0x80 /boot/uImage-2.6.30-sheevaplug >> bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); run >> bootcmd_mmc; bootm 0x080 >> stdin=serial >> stdout=serial >> stderr=serial >> nandEnvBase=enaCpuStream=no >> mainlineLinux=yes >> enaMonExt=no >> enaCpuStream=no >> enaWrAllo=no >> pexMode=RC >> disL2Cache=no >> setL2CacheWT=yes >> disL2Prefetch=yes >> enaICPref=yes >> enaDCPref=yes >> sata_dma_mode=yes >> netbsd_en=no >> vxworks_en=no >> bootdelay=3 >> disaMvPnp=no >> enaAutoRecovery=yes >> pcieTune=no >> >> Environment size: 1636/131068 bytes >> >> >> >> My first assumption given the doubt over the sheeva's understanding of >> the ext2 fs is that it's not getting the right file contents for the >> kernel, but since it has found the kernel, verified the checksum and >> decompressed it, that clearly isn't the case. So what else could be the >> problem here? > > For for uBoot access to ext2, I've found best success putting the kernel > in the root directory. I thought about that but considering the output up to the point where it all dies: Hit any key to stop autoboot: 0 SDHC found. Card desciption is: Manufacturer: 0x02, OEM "TM" Product name: "SA32G", revision 0.6 Serial number: 55312 Manufacturing date: 10/2010 CRC:0x00, b0 = 0 2096012 bytes read ## Booting image at 0080 ... Image Name: Linux-2.6.30-0-v2.6.30 Created: 2009-06-26 5:29:13 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2095948 Bytes = 2 MB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK OK Starting kernel ... � � Uncompressing Linux. The kernel got found, and whatever was found is almost certainly the kernel since the checksum checks out, and the decompression stage doesn't die, either. So the chances are - it found the kernel OK. > Also, which of your messages has the correct > printenv output? They seem to differ WRT the console settings. Not sure what you mean, they seem the same to me in the printenv and in the commands I ran. What am I missing? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
On 12/18/2010 11:37 PM, Andrew Burgess wrote: > another tack is to change the baudrate in minicom. try 9600 to start, > it's common. > > the theory (i think) is that your kernel reprogrammed the serial > port baudrate. That would imply that the kernel acquired from here: http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-2.6.30-sheevaplug does that. Surely, if it does, somebody else would have noticed before me? I just tried booting the same kernel off tftp and if I do: setenv bootargs console=ttyS0,115200 tftpboot 0x640 uimage.bin bootm 0x640 The same thing happens - the server gets as far as decompressing OK, and then the console gets garbaged. If I don't setenv bootargs with the console setting, the console stays silent after the kernel decompresses, which implies that the problem is indeed connected to the kernel doing something wrong with the serial console settings. Is there an alternative kernel I could try? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
On 12/19/2010 12:02 AM, Gordan Bobic wrote: > On 12/18/2010 11:37 PM, Andrew Burgess wrote: > >> another tack is to change the baudrate in minicom. try 9600 to start, >> it's common. >> >> the theory (i think) is that your kernel reprogrammed the serial >> port baudrate. > > That would imply that the kernel acquired from here: > http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-2.6.30-sheevaplug > > > does that. Surely, if it does, somebody else would have noticed before me? > > I just tried booting the same kernel off tftp and if I do: > > setenv bootargs console=ttyS0,115200 > tftpboot 0x640 uimage.bin > bootm 0x640 > > The same thing happens - the server gets as far as decompressing OK, and > then the console gets garbaged. > > If I don't setenv bootargs with the console setting, the console stays > silent after the kernel decompresses, which implies that the problem is > indeed connected to the kernel doing something wrong with the serial > console settings. Is there an alternative kernel I could try? Sorry, replying to my own post again. OK, it's _definitely_ the kernel that is broken. How nobody noticed that I've no idea, but I just tried this kernel: http://fedora.danny.cz/arm/kirkwood/2.6.32/uImage-2.6.32.2-kw and that boots fine. Is it really, and I mean REALLY possible that nobody else noticed this before? The 2.6.30 kernel I linked earlier is the one referenced all over the place in all the different writeups and documentation I've seen. How can it possibly be broken? Is this some kind of a weird bug triggered by specific hardware? My sheevaplug is about a week old, so I suppose it is plusible that the latest batch is somehow subtly different. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] cpuspeed and power management on ARM
Hi, Can somebody point me in the direction of any documentation on how the CPU power management works on the ARM from the clock speed throttling when idle point of view? I notice there is no cpuspeed package available. On x86 there is acpi-cpufreq and the different governors (ondemand, conservative). Is there something equivalent available on the ARM? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] uboot-tools
Is there a particular reason why uboot-tools package isn't available in the F12 armv5tel repository? I just built it from the F12 src.rpm and it seems to work fine (just booted the kernel I made with it). Is this just a distro maintenance oversight or is there a specific reason why it's not included? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] uboot-tools
Dan Horák wrote: > Gordan Bobic píše v Po 20. 12. 2010 v 12:11 +: >> Is there a particular reason why uboot-tools package isn't available in >> the F12 armv5tel repository? I just built it from the F12 src.rpm and it >> seems to work fine (just booted the kernel I made with it). Is this just >> a distro maintenance oversight or is there a specific reason why it's >> not included? > > What F-12 repository are you talking about? It can't be in the old one, > because the package didn't exist in Fedora in the time when the repo was > composed. Now it's present in koji > http://arm.koji.fedoraproject.org/koji/packageinfo?packageID=10329 and > surely will be in the repos created from the koji. The yum repository referenced in the most recent rootfs tar ball here: http://ftp.linux.org.uk/pub/linux/arm/fedora/rootfs/rootfs-f12.tar.bz2 Is there a different yum repository that should be used? There definitely is a F12 uboot-tools package, but it only appears to be in the x86/x86_64 repositories. It seems like a reasonably important package to have in the repository for the architecture that requires it. :) Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
Derek Atkins wrote: > Hi, > > Gordan Bobic writes: > >> That would imply that the kernel acquired from here: >> http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-2.6.30-sheevaplug > > I've always acquired by Sheeva kernels from: > > http://sheeva.with-linux.com/sheeva/ > > The directions on the wiki works great, and my Sheeva is happily running > off an SD card. Thanks, I'll check those out. Perhaps that link should be on the wiki? I'm just hoping the recent kernels there have ramzswap modules built (Sheeva CPU is more than fast enough, but swapping to SD would be quite painful). On a related subject - perhaps some kernel rpm packages would be useful? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] ARMv7 rootfs/repository?
Is there such a thing available? So far I have been working with a Sheeva Plug which is ARMv5 (Marvell Kirkwood) based, so the armv5tel was a good match. But this morning, my Genesi Efika Smartbook arrived in the post, which is ARMv7 (Freescale i.MX515 Cortex-A8), and I think there might be considerably more performance to be extracted from it if an ARMv7 compiled distro is used. I have found mentions of a F10 armv7l build for a Beagle Board, but I was hoping for a more recent distro. Is there such a thing available with a recent version of Fedora (ideally F12)? Or am I going to have to build one myself? Thanks. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv7 rootfs/repository?
Chris Tyler wrote: > On Wed, 2010-12-22 at 14:19 +0000, Gordan Bobic wrote: >> Is there such a thing available? So far I have been working with a >> Sheeva Plug which is ARMv5 (Marvell Kirkwood) based, so the armv5tel was >> a good match. >> >> But this morning, my Genesi Efika Smartbook arrived in the post, which >> is ARMv7 (Freescale i.MX515 Cortex-A8), and I think there might be >> considerably more performance to be extracted from it if an ARMv7 >> compiled distro is used. I have found mentions of a F10 armv7l build for >> a Beagle Board, but I was hoping for a more recent distro. Is there such >> a thing available with a recent version of Fedora (ideally F12)? Or am I >> going to have to build one myself? > > There are two separate issues involved in going to armv7l from armv5tel > -- first, optimizing for the arm v7 architecture, and secondly, > switching from softfp (optional use of the FPU with fp function > arguments passed in CPU registers) to hardfp (mandatory use of the FPU > with fp function arguments passed in FPU registers). > > I just recently got a report from a Seneca student studying the arm v5 > vs. arm v7 (softfp) performance on a BeagleBoard xM, and his conclusion > was that there is little or no appreciable performance gain. That is interesting. Presumably this is with a recent (CodeSourcery?) GCC? Is the lack of obvious improvement down to a GCC deficiency? > There is an expected performance gain with the switch to hardfp, but > that's a big challenge: you can't mix softfp and hardfp Ah - I hadn't realized that. I thought a hardfp binary could work on a softfp distro with a hardfp kernel. > so switching to > hardfp is like bootstrapping an entirely new architecture. Just out of interest, is there documentation on how to do that for RPM based distros? Or is it just he obvious packageless cross-build, then packaged re-build? > The other > challenge is that the gcc used in Fedora does not yet support hardfp > with vfp; using another compiler might be possible, but could lead to > compatibility challenges with the primary arch. Undoubtedly. I've been playing with rolling my own repository for ICC build x86 RPMs (because I have recently seen ICC produce up to 8x performance improvements compared to GCC produced code when it comes to number crunching). The performance is quite spectacular in some cases. On the other hand, I don't think anyone has yet managed to get glibc to build with anything other than GCC. One encouraging thing is that there is now some success with getting the kernel to build using ICC. The reason I mention this is because given the relative maturity of ICC in this sense with such major outstanting issues, it will likely be some years before a whole distro will build with the likes of RVCT or TI compilers. The performance improvements aren't as great compared to ICC on x86, but probably still worthwhile. But I'm not going to hold my breath. > Thus, my leaning is to hold off on the armv7l move until our gcc > provides arm v7 hardfp+vfp, which is probably F15 territory. I think you're right. Trying to build a GNU/Linux distro with something other than GCC isn't really plausible at the moment. Pitty - the lack of workable hardfp is really going to cripple things like my Efika and the Toshiba AC100. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv7 rootfs/repository?
Andrew Burgess wrote: > On 12/22/2010 06:30:13 AM, Chris Tyler wrote: > >> There is an expected performance gain with the switch to hardfp, but >> that's a big challenge: you can't mix softfp and hardfp, so switching >> to >> hardfp is like bootstrapping an entirely new architecture. > > Since fedora has no problem mixing 32 and 64 bit executables it > seems like there's alot of infrastructure already done for this. > Just saying... I've not looked at it all the way down to binary level, but I have a feeling the problem is NOT quite analogous to mixing x86 with x86_64 or x86 softfp/hardfp. But I'd love to hear otherwise. :) Has anyone got any links to information on the subject of why missing softfp and hardfp on ARMv7 isn't as straightforward as on x86? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv7 rootfs/repository?
Chris Tyler wrote: > On Wed, 2010-12-22 at 08:01 -0800, Andrew Burgess wrote: >> On 12/22/2010 06:30:13 AM, Chris Tyler wrote: >> >>> There is an expected performance gain with the switch to hardfp, but >>> that's a big challenge: you can't mix softfp and hardfp, so switching >>> to >>> hardfp is like bootstrapping an entirely new architecture. >> Since fedora has no problem mixing 32 and 64 bit executables it >> seems like there's alot of infrastructure already done for this. >> Just saying... > > It's not a Fedora infrastructure issue, the ABIs are incompatible. I > wish you could mix'n'match but that doesn't look possible. What about kernel level FPU emulation? Is there such a thing? I could have sworn there used to be something that could be used as such. And it might be possible to make it quite transparent if it isn't required (so you can always have it in the kernel). Have the kernel trap the exception on the missing FPU instructions, save state, and then pass the to an emulation library. When that returns, restore state and resume. It would mean much slower performance than softfp on FPU-less hardware, but it would allow for a transitional period where only VFP distro needs to be maintained, which still works (albeit slowly) on a non-VFP processor. Then again, I'm not volunteering to add such a feature to the Linux kernel. :) Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv7 rootfs/repository?
Gordan Bobic wrote: > Chris Tyler wrote: >> On Wed, 2010-12-22 at 08:01 -0800, Andrew Burgess wrote: >>> On 12/22/2010 06:30:13 AM, Chris Tyler wrote: >>> >>>> There is an expected performance gain with the switch to hardfp, but >>>> that's a big challenge: you can't mix softfp and hardfp, so >>>> switching to >>>> hardfp is like bootstrapping an entirely new architecture. >>> Since fedora has no problem mixing 32 and 64 bit executables it >>> seems like there's alot of infrastructure already done for this. >>> Just saying... >> >> It's not a Fedora infrastructure issue, the ABIs are incompatible. I >> wish you could mix'n'match but that doesn't look possible. > > What about kernel level FPU emulation? Is there such a thing? I could > have sworn there used to be something that could be used as such. And it > might be possible to make it quite transparent if it isn't required (so > you can always have it in the kernel). Have the kernel trap the > exception on the missing FPU instructions, save state, and then pass the > to an emulation library. When that returns, restore state and resume. > > It would mean much slower performance than softfp on FPU-less hardware, > but it would allow for a transitional period where only VFP distro needs > to be maintained, which still works (albeit slowly) on a non-VFP processor. > > Then again, I'm not volunteering to add such a feature to the Linux > kernel. :) And just as I hit send, I found this: http://netwinder.osuosl.org/users/s/scottb/public_html/notes/FP-Notes-all.html No idea how relevant it might still be - the article is about 11 years old. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv7 rootfs/repository?
Peter Robinson wrote: >> are you sure the fp arg style is a kernel issue? >> are there system calls that take floats (not in structs or arrays >> but as a single argument)? > >>From all the documentation about it seems so. You need to remember > there's a lot of mainline distros (and I'm not talking about small > embedded ones) looking to move to arm7 + hardfp but none that have yet > done so. There's lots of notes and people that have done customer > recompiles etc for testing and eval purposes but none that have > actually done it yet across the entire mainline distro to run > everything from apache to gnome. > >> i could be totally wrong. it just seems almost there... > > Its is but that doesn't mean there's still not a lot of work to do. > The Fedora ARM team has had issues with gcc / glibc etc just trying to > get Fedora 13 compiled on on arm5tel. I've seen mention in the thread > "but it works great with ICC" but you have to remember Fedora is an > open distro so we're not going to be using a closed compiler to fix > the problem. ICC is x86 only. I mentioned it to illustrate that there is so much GCC specific stuff in important core libraries like glibc that it is unlikely we will get it working with any other compiler any time soon. There are actually two problems regarding this: 1) People shouldn't be writing code that isn't portable across compilers. 2) GCC isn't a very good compiler performance-wise - not by a long way. Once the GCC hardfp issue is resolved (I'm not going to hold my breath - I've moaned in the past about various areas of GCC's uselessness (e.g. vectorization) and in the past 3 years no meaningful movement has been achieved to close the <= 800% FPU performance gap with ICC), I suspect it'll lead to having two ARM distros. armv5tel for ARMs without FPU and arm7vfp for FPU enabled ARMs. Similar to what we currently have with x86 and x86_64, only if the ABI is different, arm5tel and arm7 will be pretty much distinct separate architectures in terms of software target. > At the moment we're concentrating on arm5tel as it works > and we need to get Fedora 14 and rawhide there and its the combination > that can support the broadest amount of hardware, one that's on the > road to completion people can and will start looking at a version > optimised for newer more power HW. Its only in the last week or so the > team have managed to get enough of F-13 built to be able to compose a > rootfs for testing it. Ooo! Any chance of a link to this rootfs and the F13 arm5tel yum repository? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv7 rootfs/repository?
Peter Robinson wrote: are you sure the fp arg style is a kernel issue? are there system calls that take floats (not in structs or arrays but as a single argument)? >>> >From all the documentation about it seems so. You need to remember >>> there's a lot of mainline distros (and I'm not talking about small >>> embedded ones) looking to move to arm7 + hardfp but none that have yet >>> done so. There's lots of notes and people that have done customer >>> recompiles etc for testing and eval purposes but none that have >>> actually done it yet across the entire mainline distro to run >>> everything from apache to gnome. >>> i could be totally wrong. it just seems almost there... >>> Its is but that doesn't mean there's still not a lot of work to do. >>> The Fedora ARM team has had issues with gcc / glibc etc just trying to >>> get Fedora 13 compiled on on arm5tel. I've seen mention in the thread >>> "but it works great with ICC" but you have to remember Fedora is an >>> open distro so we're not going to be using a closed compiler to fix >>> the problem. >> ICC is x86 only. I mentioned it to illustrate that there is so much GCC >> specific stuff in important core libraries like glibc that it is >> unlikely we will get it working with any other compiler any time soon. >> There are actually two problems regarding this: > > I thought you were referring to ImageCraft C Compiler which arm and others > http://www.imagecraft.com/ No, I was refering to Intel C Compiler: http://software.intel.com/en-us/articles/intel-compilers/ >> 1) People shouldn't be writing code that isn't portable across compilers. > > I don't disagree. > >> 2) GCC isn't a very good compiler performance-wise - not by a long way. > > It doesn't matter, its currently the core compiler that Fedora uses > and hence it what we need to get to work. When upstream Fedora changes > to something else so can we but I don't see that happening in the > short to medium term. In fact I suspect that its more likely to get > upstream gcc integrate some LLVM perf improvements before that > happens. Maybe, maybe not. I'm planning to put up a yum repository of ICC-built RHEL6 RPMs. Not everything will build. Not everything that builds will work. Not everything that works will necessarily bring performance advantages - for example, on RHEL5, after extensive testing and a lot of attempts at tweaks, perl's performance just wouldn't budge - it's as slow when built using ICC as with GCC, and it took a lot of trial and error to just get it to build at all, let alone pass the test suite. But of the things that do, build and work, the improvement is definitely worth having. Of course I don't expect Fedora to switch to a commercial, non-GPL compiler. But considering that GCCs performance has degraded as often as it has improved between releases, I'm not too hopeful about the gap closing any time soon. >>> At the moment we're concentrating on arm5tel as it works >>> and we need to get Fedora 14 and rawhide there and its the combination >>> that can support the broadest amount of hardware, one that's on the >>> road to completion people can and will start looking at a version >>> optimised for newer more power HW. Its only in the last week or so the >>> team have managed to get enough of F-13 built to be able to compose a >>> rootfs for testing it. >> Ooo! Any chance of a link to this rootfs and the F13 arm5tel yum repository? > > It was on planet Fedora in the last week or so posted by Paul W (of > Fedora ARM fame @ Seneca college). It might be linked on the Fedora > ARM wiki page too (sorry, don't have my browser history to hand). Thanks, that was enough to find it. :) http://paulfedora.wordpress.com/2010/12/15/fedora-13-arm-alpha-root-file-system/ Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Xorg Keyboard Problem on Toshiba AC100
Hi, I'm having severe keyboard issues on the Toshiba AC100 under Xorg. Keyboard doesn't work _at all_. In xorg.conf, everything seems to be OK, it finds the keyboard and the mouse. The only odd thing is that it also detects the webcam and says it thinks it is a keyboard. I have removed the /dev/input/event3 node that the webcam uses and added a fdi policy file to ensure that HAL ignores it (and verified that it is in fact ignoring it). So I am reasonably confident that this isn't the core of the problem. Unfortunately, since there are no obvious errors in the Xorg log, I'm not sure where to look for the problem next. The text mode console works fine, but Xorg seems to ignore the keyboard inputs. I have looked at the wiki page here on the subject http://fedoraproject.org/wiki/Features/EvdevInputDriver and that says that situations like this should be deemed critical bugs. How can I get to the bottom of what is actually causing the problem? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] OpenOffice RPMs
Are there OpenOffice RPMs available for Fedora 12? I'm trying to build the src.rpm from RHEL6b2 on F12 ARM, but the machine has only 450MB of RAM, so it OOMs during the build. Are there any pre-built binary RPMs available? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] OpenOffice RPMs
omall...@msu.edu wrote: > It doesn't look like there is. > > I'm not saying you are wrong or it wont work to use the RHEL6b2 > version, but if I was going to build them from scratch, I would > probably use the f12 src. OO has a lot of dependencies. I already resolved the dependencies. F12 was 3.1.0, and RHEL6b2 was 3.2.1, so I went with the latter. Speaking of dependencies - there is a package build circular dependency. Not sure if this should be reported as a bug: openssl needs krb5-devel to build krb5 needs openssl-devel to build I'm pretty sure that can't be right since one has to be built first. In this case I could rpm -ivh --nodeps, but I shouldn't really have to do that. Speaking of bugs, do ARM Fedora bugs go into the bugzilla.redhat.com or into a different bugzilla? > To get around the OOM issue, just add a swap file. Here is a quick > how-to if you aren't familiar. I'm prefectly aware of how to add a swap file, thanks. I've only been doing this for 20 years or so. :p > It is probably going to take quite a bit of time to compile. Given > there isn't a compiled version for arm, it will probably take more > work then just a recompile. Well: 1st attempt: OOM-ed with only 512MB of RAM (I wanted to avoid swapping onto SD, it's painful enough without the extra disk I/O it causes). 2nd attempt: Failed because the build process used up all 8GB of space on the SD card and died. Going through the 3rd attempt now. Let's hope the 16GB USB stick proves to be big enough to hold the build directory... Considering how much I've had to build from src.rpms (shockingly, I've not yet found anything that actually failed to build cleanly), I'm half-tempted to put up a repository of my own when I'm done. Given that ARM netbooks are becoming more popular I'm sure I won't be the only one looking for these. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] OpenOffice RPMs
omall...@msu.edu wrote: > Quoting Gordan Bobic : > >> Speaking of dependencies - there is a package build circular dependency. >> Not sure if this should be reported as a bug: >> openssl needs krb5-devel to build >> krb5 needs openssl-devel to build >> >> I'm pretty sure that can't be right since one has to be built first. In >> this case I could rpm -ivh --nodeps, but I shouldn't really have to do >> that. > > It probably should be reported to the mainline but Im not sure it can be > fixed either.. :) But isn't F12 deprecated now? We're so far behind with the ARM port that by the time it's there, it's already deprecated by a Fedora version 2 versions newer. > You can probably do a rpm -ivh openssl-devel krb5-devel IIRC, the reason why I couldn't do that was because krb5 was missing from the F12 ARM repository I had to build it, but IIRC, openssl-devel wasn't there, either. Looking at the timestamps, I had to rebuild openssl from src.rpm to get the openssl-devel, then krb5. Needed krb5 for some KDE deppendencies, in order to build konversation. I'm more than a little surprised that ARM Fedora is so neglected. The build is very incomplete. This is particularly odd considering that all the src.rpm packages seem to build just fine. Ubuntu, OTOH, seem to have much better support for ARM. Are there plans to catch up? > then rebuild one and install, then rebuild the other and install and > then rebuild the first one again.. that seems convoluted, but you have > to recompile gcc 3 times in order to get the bootstrap right too. Yeah, I know. :( > Im not sure exactly how important it is given usually you are using the > shared libs anyway. It's not really an issue, there's always a way around it, but I thought that there should be no circular dependencies in either the binary or source packages. >> Speaking of bugs, do ARM Fedora bugs go into the bugzilla.redhat.com or >> into a different bugzilla? > > no idea. I was trying to figure that out as well. > It seems like they need to be reported in both places since they need to > be fixed eventually by the official package maintainer Oh, OK. I thought it was the same bugzilla. Doesn't the ARM one feed to the main one? Why are they even separate? Have you got a URL handy for the Fedora ARM bugzilla? >>> It is probably going to take quite a bit of time to compile. Given >>> there isn't a compiled version for arm, it will probably take more >>> work then just a recompile. >> >> Well: >> >> 1st attempt: >> OOM-ed with only 512MB of RAM (I wanted to avoid swapping onto SD, it's >> painful enough without the extra disk I/O it causes). > > fwiw, when i did kernel build time testing with the guruplug. I tried > nfs, and a usb/esata drive plugged into either port. nfs with the nosync > option was the fastest (50 minutes) and both esata and usb2 were roughly > the same time at 60 minutes. Yeah, I can believe that. NFS over GbE with async is pretty quick. Build performance on the Toshiba AC100 is quite good when I LD_PRELOAD libeatmydata.so (eats all the fsyncs - I know, I know, at my peril), even onto a slow SD card or USB stick. I figured that 2x Cortex A9 @ 1GHz would build it quicker than 1x Feroceon @ 1.2GHz. Then again, with it taking so long, distcc is rapidly becoming tempting. Since I'm very much meaning to get a lot more involved in this, I'm pondering cramming a pile of Panda Boards into a 3U chassis I have lying around. >> 2nd attempt: >> Failed because the build process used up all 8GB of space on the SD card >> and died. > > Im surprised at this.. it doesn't -seem- like it should be quite that big. By my reckoning in terms of how long I think it should take to build (18 hours or so), it was only about half way through by the time it ran out of disk space. So I expect it to be significantly bigger than this. >> Considering how much I've had to build from src.rpms (shockingly, I've >> not yet found anything that actually failed to build cleanly), I'm >> half-tempted to put up a repository of my own when I'm done. Given that >> ARM netbooks are becoming more popular I'm sure I won't be the only one >> looking for these. > > I was hoping the f13 would be released for xmas. :) but it appears like > f12 is going to be around a bit longer.. I am reasonably eagerly awaiting F13, but will that build be any more complete than the F12 build is? If not, I need to be thinking about a rack of Sheeva Plugs (or maybe Panda Boards) for building the missing packages. :) In all seriousness, though - it seems that ARM netbooks (and servers!) are very much imminently coming in numbers, and I think there should at least exist a possibility of a comfortable and complete RH/Fedora experience. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] OpenOffice RPMs
>> 1st attempt: >> OOM-ed with only 512MB of RAM (I wanted to avoid swapping onto SD, it's >> painful enough without the extra disk I/O it causes). >> >> 2nd attempt: >> Failed because the build process used up all 8GB of space on the SD card >> and died. >> >> Going through the 3rd attempt now. Let's hope the 16GB USB stick proves >> to be big enough to hold the build directory... > > IIRC a build of OO.org needs more than 30GB of free disk space, few gigs > can be saved when the langpacks are not built *blinks* OOohkay... NFS on the SheevaPlug it is! Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] OpenOffice RPMs
On 12/29/2010 06:47 PM, omall...@msu.edu wrote: Speaking of dependencies - there is a package build circular dependency. Not sure if this should be reported as a bug: openssl needs krb5-devel to build krb5 needs openssl-devel to build I'm pretty sure that can't be right since one has to be built first. In this case I could rpm -ivh --nodeps, but I shouldn't really have to do that. >>> >>> It probably should be reported to the mainline but Im not sure it can be >>> fixed either.. :) >> >> But isn't F12 deprecated now? We're so far behind with the ARM port that >> by the time it's there, it's already deprecated by a Fedora version 2 >> versions newer. > > The plan is to finish 13, do 14, then 15. As I believe some or most of > the bugs if they are getting pushed upstream should be worked out.? The point I was making was that by the time we report bugs to the mainline Fedora, the version of Fedora we are reporting against is already EOL-ed, because there is such a huge gap betwen a Fedora release becoming available for x86 and the ARM rootfs (not even a complete port) being available. This typically means the bugs immediately get marked as WONTFIX with a note saying "check the latest release and raise a new bug against that" - which we can't do because we're too far behind in the ARM land. > There may be a branch at f15 at or around the cortex processors. Yes, so I hear - the hardfp branch. Having said that, according to some benchmarks, even softfp armv7l target yields decent performance improvements over armv5tel in some applications, e.g. audio/video codecs and databases: http://global.phoronix-test-suite.com/?k=profile&u=robertcnelson-3173-25135-22766 >> Looking at the timestamps, I had to rebuild openssl from src.rpm to get >> the openssl-devel, then krb5. Needed krb5 for some KDE deppendencies, in >> order to build konversation. > > I kind of wonder why openssl needs krb5. OpenSSH i can see needing krb5 > and openssl. And I can see krb5 needing openssl for gssapi... Beats me. >> I'm more than a little surprised that ARM Fedora is so neglected. The >> build is very incomplete. This is particularly odd considering that all >> the src.rpm packages seem to build just fine. > > I was trying to figure this one out too. I'll get building and see what comes out. Will set up a repository with packages that aren't in the main Fedora repository when I have a reasonable amount. It'll take a while, though - my main build box is a Sheeva Plug! :-O It would also be really nice if we were to establish a selection of proper rpm kernel packages for at least the most common platforms, e.g.: - Marvell Kirkwood for the Sheeva Plug - Freescale i.MX515 for the Genesi Efika - nVidia Tegra 2 for the Toshiba AC100 and no doubt others, too. I mention the above specifically because I own these devices and thus intend to have a go at building the suitable packages for them. It is after all, a community effort, right? ;) >> Ubuntu, OTOH, seem to have much better support for ARM. Are there plans >> to catch up? > > Ubuntu is further because it is really Debian unstable. (although I > think debian is better..) Sure - but Fedora is "RHEL unstable". I really don't think we have an excuse for being this far behind them. >>> Im not sure exactly how important it is given usually you are using the >>> shared libs anyway. >> >> It's not really an issue, there's always a way around it, but I thought >> that there should be no circular dependencies in either the binary or >> source packages. > > Ideally there shouldn't be. :) Since F13 is just around the corner, I'll revisit the issue as soon as the rootfs for that is ready. Speaking of bugs, do ARM Fedora bugs go into the bugzilla.redhat.com or into a different bugzilla? >>> >>> no idea. I was trying to figure that out as well. >>> It seems like they need to be reported in both places since they need to >>> be fixed eventually by the official package maintainer >> >> Oh, OK. I thought it was the same bugzilla. Doesn't the ARM one feed to >> the main one? Why are they even separate? > >> Have you got a URL handy for the Fedora ARM bugzilla? > > I'm not sure there is one, or whether it is part of the bugzilla. The > only things I have really found are local to the arm project. I would > rather send an email then fill out a form. lol > > I can seem to use my fedora account to login to the arm koji. > Im getting https://arm.koji.fedoraproject.org/koji/login is handing me > back a > (Error code: ssl_error_handshake_failure_alert) I was referring to http://bugzilla.redhat.com. Interestingly, there are options for target platforms based on ARM. But there are several that should arguably be collapsed together because there is only one supported target. The list contains: arm7 arm9 strongarm xscale Those should really all be collapsed down to armv5tel for now, since that is the only target available. Where
Re: [fedora-arm] OpenOffice RPMs
On 12/29/2010 10:39 PM, Rich Mattes wrote: >>> The plan is to finish 13, do 14, then 15. As I believe some or most of >>> the bugs if they are getting pushed upstream should be worked out.? >> The point I was making was that by the time we report bugs to the >> mainline Fedora, the version of Fedora we are reporting against is >> already EOL-ed, because there is such a huge gap betwen a Fedora release >> becoming available for x86 and the ARM rootfs (not even a complete port) >> being available. >> >> This typically means the bugs immediately get marked as WONTFIX with a >> note saying "check the latest release and raise a new bug against that" >> - which we can't do because we're too far behind in the ARM land. >> > > Fedora 12 is what's currently available, from a previous ARM port > effort. It's not supported anymore. The ARM SIG is targeting F13 (now > bootable: > http://paulfedora.wordpress.com/2010/12/15/fedora-13-arm-alpha-root-file-system/) > and onward. OK, downloading now. I'm guessing that it'd be more fruitful at the moment to be working on things for F13 than on F12. I'm more than a little surprised that ARM Fedora is so neglected. The build is very incomplete. This is particularly odd considering that all the src.rpm packages seem to build just fine. >>> I was trying to figure this one out too. > >> I'll get building and see what comes out. Will set up a repository with >> packages that aren't in the main Fedora repository when I have a >> reasonable amount. It'll take a while, though - my main build box is a >> Sheeva Plug! :-O >> >> It would also be really nice if we were to establish a selection of >> proper rpm kernel packages for at least the most common platforms, e.g.: >> >> - Marvell Kirkwood for the Sheeva Plug >> - Freescale i.MX515 for the Genesi Efika >> - nVidia Tegra 2 for the Toshiba AC100 >> >> and no doubt others, too. I mention the above specifically because I own >> these devices and thus intend to have a go at building the suitable >> packages for them. It is after all, a community effort, right? ;) > > I think the plan is to eventually get ARM kernels based on the Fedora > kernel sources built for many different development boards. Currently, > all effort is focused on getting the F13 package collection built. Your > efforts would certainly be welcome should you try to tackle kernel builds. Indeed, I need to do this anyway. I will share results I think will be useful. What I am ideally hoping to do is come up with just two kernel packages, an armv5tel and an armv7l one, that will cover most things. Whether that will turn out to be possible remains to be seen. > I'll also note that the latest F13 koji builds are already available in > a repo: http://arm.koji.fedoraproject.org/repos/dist-f13-build/latest/ > That's the repo that was used to generate the F13 rootfs. As packages > are built, this repo should approach the coverage of the primary > architectures' repositories. Wasn't that the theory with the F12 build, too? Ubuntu, OTOH, seem to have much better support for ARM. Are there plans to catch up? >>> Ubuntu is further because it is really Debian unstable. (although I >>> think debian is better..) >> Sure - but Fedora is "RHEL unstable". I really don't think we have an >> excuse for being this far behind them. >> > Ubuntu and Debian have been working on this for a much longer time. The > current Fedora effort is only several months old, and builds off of the > incomplete F12 package collection. Further, we only got F13's gcc and > glibc working on ARM two months ago, which held up pretty much all > progress. Most of the big problems have been knocked out, and things are > indeed progressing. I don't really understand the pessimism, my > perception is that things are going quite well (it's taken under two > months to get a working F13 rootfs!) I don't think that ARM fedora is > being neglected at all, it's just a young effort and the results aren't > immediately apparent yet. I wouldn't call it pessimism at all. I'm surprised more than anything. But I am certainly willing to stick my ore in and help shift things along in whatever way I can. It's not really an issue, there's always a way around it, but I thought that there should be no circular dependencies in either the binary or source packages. >>> Ideally there shouldn't be. :) >> Since F13 is just around the corner, I'll revisit the issue as soon as >> the rootfs for that is ready. > > Alpha-quality rootfs is available for you to play with: see above. krb5 > can be built without OpenSSL for bootstraping, the option is at the top > of the krb5 specfile. Several packages need to be bootstrapped in a > similar fashion: Mono requires mono-devel for instance. Hmm... Is there anything that can be done about this? It seems conceptually broken. Oh, OK. I thought it was the same bugzilla. Doesn't the ARM one feed to the main one? Why are they even separate?
Re: [fedora-arm] OpenOffice RPMs
On 12/29/2010 10:39 PM, Rich Mattes wrote: >>> The plan is to finish 13, do 14, then 15. As I believe some or most of >>> the bugs if they are getting pushed upstream should be worked out.? >> The point I was making was that by the time we report bugs to the >> mainline Fedora, the version of Fedora we are reporting against is >> already EOL-ed, because there is such a huge gap betwen a Fedora release >> becoming available for x86 and the ARM rootfs (not even a complete port) >> being available. >> >> This typically means the bugs immediately get marked as WONTFIX with a >> note saying "check the latest release and raise a new bug against that" >> - which we can't do because we're too far behind in the ARM land. >> > > Fedora 12 is what's currently available, from a previous ARM port > effort. It's not supported anymore. The ARM SIG is targeting F13 (now > bootable: > http://paulfedora.wordpress.com/2010/12/15/fedora-13-arm-alpha-root-file-system/) > and onward. It seems the metadata is broken on some of the packages in the F13 koji repository. The URLs list a host as "hongkong" which is clearly not going to resolve. Any chance of a fix? The packages in question are pretty important for a usable build system. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] OpenOffice RPMs
On 12/30/2010 04:43 AM, omall...@msu.edu wrote: > Quoting Gordan Bobic : > >> On 12/29/2010 10:39 PM, Rich Mattes wrote: >> >>>>> The plan is to finish 13, do 14, then 15. As I believe some or most of >>>>> the bugs if they are getting pushed upstream should be worked out.? >>>> The point I was making was that by the time we report bugs to the >>>> mainline Fedora, the version of Fedora we are reporting against is >>>> already EOL-ed, because there is such a huge gap betwen a Fedora >>>> release >>>> becoming available for x86 and the ARM rootfs (not even a complete >>>> port) >>>> being available. >>>> >>>> This typically means the bugs immediately get marked as WONTFIX with a >>>> note saying "check the latest release and raise a new bug against that" >>>> - which we can't do because we're too far behind in the ARM land. >>>> >>> >>> Fedora 12 is what's currently available, from a previous ARM port >>> effort. It's not supported anymore. The ARM SIG is targeting F13 (now >>> bootable: >>> http://paulfedora.wordpress.com/2010/12/15/fedora-13-arm-alpha-root-file-system/) >>> >>> and onward. >> >> It seems the metadata is broken on some of the packages in the F13 koji >> repository. The URLs list a host as "hongkong" which is clearly not >> going to resolve. Any chance of a fix? The packages in question are >> pretty important for a usable build system. > > I put it on Paul Whalen blog like a week ago. I just overrode it. > in /etc/hosts put > 142.204.133.150 arm.koji.fedoraproject.org hongkong Hmm... Not so good if you're behind a transparent proxy... :( Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F14 qemu arm default board
omall...@msu.edu wrote: > In F14 x86, we finally have the ability to add an ARM based VM via the > libvirt management tool!! IE you can go through the GUI and set up an > qemu based arm VM*. What's the performance like? Is there multi-core capability? I'm wondering if a 3+GHz Core2 can emulate an ARM fast enough to be faster than native. I very much doubt it, but it'd be a real boon for large cross-building. > It defaults to the integratorcp board. But our image/kernel for F12 is > for the versatile board.) This is something I'll be looking into soon. I really want to try to come up with the smallest possible number of kernels that will support the biggest range of devices. I'm not sure yet how plausible that is on the ARM, though. > The physical specs for the integrator board support a max of 256 megs > of ram and only support the arm9 processors. I assume qemu only > supports this, or at least I ran into issues when i tried to bump up > the ram for the versatile boards. > > I am -assuming- this isn't the fastest board/processor combo... Does > anyone have a clue what is? Then we can change it upstream and make a > f13-alpha image for it. Is it armv5tel or something else? I can confirm that the f13 alpha image works fine on my Toshiba AC100. Haven't tried it on the Sheeva yet. > *since we don't seem to support kickstart, What's wrong with kickstart? Doesn't it work? > and we don't have an > installer, you can really only import in an existing image. But hey it > is better then what we had! My understanding is that the bigger problem is that a lot of ARM devices can't network boot. Some, like my AC100 don't even have an ethernet port (built in 3G, wifi, and USB ethernet bridge). Sheeva can TFTP boot a kernel, though. The other complication is that boot-loaders are all over the place. Efika Genesi has a nice setup with a new uboot that looks for boot.scr in the root of the first partition and boots accordingly. I've not yet found any docs on doing that on the sheeva, but I'm hoping to reverse engineer the setup for it from the Genesi laptop, maybe next weekend. The Toshiba AC100 uses something different again. I have no idea whether any of them will boot off a CD, but that might be an interesting experiment. If they can (they all have USB ports, so USB CD-ROM drives are a distinct possibility), then that would give a reasonably universal way of installing, but there'd be a real mess of custom boot-loader setups for all the different devices. Not sure there's a way around that at the moment. I certainly plan to try to get all of mine working in the same way with the same boot loader, but I'm not sure if I will succeed. Plus, it'd be _REALLY_ nice if uboot were able to provide a boot menu and boot multiple kernels via boot.scr. It'd make botched kernel images much less problematic. But I'm not sure if it contains enough functionality for that. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F14 qemu arm default board
Chris Tyler wrote: >> *since we don't seem to support kickstart, and we don't have an >> installer, you can really only import in an existing image. But hey it >> is better then what we had! > > The concept of an "installer" in ARM land is pretty limited. There is a > graphical installer for Sheeva/Guruplugs, but it's primarily a tool for > installing a kernel and prebuilt rootfs (it would be hard to package for > Fedora, too, since it contains an entire prebuilt Linux image for use > during bootstrapping, and building that from source would be Big). Sheeva can get a kernel image to boot via TFTP, so making an "installer" kickstart a base image shouldn't be too difficult. the problem is booting the installer in the first place. Having said that - it would be much, much more efficient if the Fedora/RH installer installed the minimum build from a single tar ball (i.e. the rootfs). The extra disk I/O required by maintaining the RPM database at every step really slows things down on cheap flash, not to mention that it wastes an awful lot of life of a SD/CF card with all those small writes. Installing a gig of packages onto an SD card on the Sheeva can take literally hours. The only way I have managed to make this sort of thing bearable is by LD_PRELOAD=libeatmydata.so before I run yum. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F14 qemu arm default board
On 12/30/2010 05:44 PM, Chris Tyler wrote: > On Thu, 2010-12-30 at 16:51 +0000, Gordan Bobic wrote: >> Chris Tyler wrote: >> >>>> *since we don't seem to support kickstart, and we don't have an >>>> installer, you can really only import in an existing image. But hey it >>>> is better then what we had! >>> >>> The concept of an "installer" in ARM land is pretty limited. There is a >>> graphical installer for Sheeva/Guruplugs, but it's primarily a tool for >>> installing a kernel and prebuilt rootfs (it would be hard to package for >>> Fedora, too, since it contains an entire prebuilt Linux image for use >>> during bootstrapping, and building that from source would be Big). >> >> Sheeva can get a kernel image to boot via TFTP, so making an "installer" >> kickstart a base image shouldn't be too difficult. the problem is >> booting the installer in the first place. > > You could boot an installer via TFTP, but why? These systems aren't > really strong for running software interactively -- you'd probably end > up on the serial console (which you have to use to get the TFTP boot > configured anyway). Sure, for some things, but there is a growing number of netbooks based on ARM coming out, from the tiny ones with 128MB of RAM that go on ebay for £30, up to really decent ones like the Genesi Efika and Toshiba AC100. For these, an x86-style installer would easily be justifiable (if only their flash disk subsystem wasn't woefully slow - but as I said, that can be addressed by LD_PRELOAD-ing libeatmydata during the install, and syncing at the end. Or have the installer do the minimum install by extracting a tar ball and taking it from there with RPM for the extra packages. > I think that installing a rootfs via SD/microSD is a much lower-pain > option, and the right way forward is unifying the rootfs tools across > the various archs. A rootfs and a live CD/live USB image are pretty much > the same thing; we're currently using different tools on different > archs, and the current tools are broken in various ways (LiveUSB with > overlays stops with no notice and unrecoverable errors once the overlay > is full -- a big problem for Sugar on a Stick -- and the rootfs tools > for the secondary archs are different, many of them not using > kickstarts) -- it's time to refactor and unify. Definitely agreeing on unifying the approach. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] dietlibc port?
Hi,
I'm trying to get dietlibc to build on ARM F12, and the build fails with
a segfault. The last bit is:
snip
bin-arm/diet gcc -D__dietlibc__ -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -march=armv5te -fomit-frame-pointer
-fno-exceptions -fno-asynchronous-unwind-tables -fno-stack-protector -Os
-g3 -Werror-implicit-function-declaration -o bin-arm/elftrunc
contrib/elftrunc.c
make: *** [bin-arm/elftrunc] Segmentation fault
error: Bad exit status from /var/tmp/rpm-tmp.sNdS8b (%build)
snap
This happens with all 0.31 and 0.32 versions of the src.rpm all the way
back fo F9.
I tried with 0.30 going back to F5, but that seems to die with a patch
failure.
Digging a bit more, it seems that bin-arm/diet segfaults when executed
without any parameters, so it seems that this is the bit that
miscompiled somewhere.
It turns out that the problem is actually to do witha GCC bug. When it
is building bin-arm/diet with -Ox (x = {s,2,3}) , the resulting binary
segfaults. When the binary is built with -O1 or -O0, it works fine.
There also seem to be a few other binaries produced in this package that
have a similar problem. Thankfully, dietlibc comes with a test suite of
it's own that showed these issues up. It makes me wonder how much of the
rest of the distribution packages (the ones without test suites) end up
being silently broken by GCC.
So I would like to ask how we go about doing fixes on a level as
fundamental as the compiler on a distribution level? Do I file a bug on
bugzilla.redhat.com against distro=F12, platform=arm, package=gcc?
Gordan
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] dietlibc port?
Andy Green wrote:
> On 01/06/11 16:17, Somebody in the thread at some point said:
>
> Hi -
>
>> Digging a bit more, it seems that bin-arm/diet segfaults when executed
>> without any parameters, so it seems that this is the bit that
>> miscompiled somewhere.
>
> Did you try running it in gdb and get a clue about what blows?
Not yet, no.
>> It turns out that the problem is actually to do witha GCC bug. When it
>> is building bin-arm/diet with -Ox (x = {s,2,3}) , the resulting binary
>> segfaults. When the binary is built with -O1 or -O0, it works fine.
>
> Is there a particular gcc bug you traced it down to? Because it does
> not follow that all changes to program behaviour with different
> optimization options are necessarily gcc bugs; it can show up
> broken-ness in code that happens to not show symptoms according to how
> it is compiled.
That's fair, but an awful lot seems to break. If dietlibc really is that
broken, I have to question how it ever worked for anyone reliably. I'm
also wondering if it might be some of the Fedora patches that are
breaking it. I'll try it without any post-0.32 patches.
Gordan
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] dietlibc port?
On 01/06/2011 11:15 PM, Rich Mattes wrote: >> I am slowly shifting things over to F13, but there is a lot to DIY >> build. For example, things like Firefox don't work because of an API >> version mismatch with xulrunner. And it helps to have a relatively >> usable system to do development on. :) >> >> Besides, the reason I need dietlibc is because util-vserver requires >> it and I want to work on F13 stuff in a vserver chroot in order to >> ensure that the host system remains operational even if I badly break >> important low-level things. >> > Ah, I see. I've just been using a plain chroot into the f13 rootfs with > /proc bind mounted to the rootfs /proc, but it looks like vserver has > some more features. Indeed, it is much safer and better insulated. >>> If it helps, you should be able to override the CFLAGS and CXXFLAGS >>> in the dietlibc specfile before calling make in order to lower the >>> optimization level. >> >> The problem with that is two-fold: >> >> 1) It seems a lot (most?) of spec files don't actually set CC, CXX, >> CPP, CFLAGS, CXXFLAGS, etc. accordoing to the rpmrc. I'm currently in >> the process of going through most of the packages in RHEL6 (building >> for x86 using ICC for a bit of extra speed) and F12/F13 (to build the >> missing ones for the ARM port), and it seems that this happens all >> over the place, and inconsistently to boot. For example, bzip2 sets >> the variables according to rpmrc, but gzip doesn't. It is really >> frustrating to find that the package management functionality is >> ignored so frequently. >> >> 2) Ironically, having said 1), it seems that dietlibc introduces it's >> optimization flags of -Os/-O2 _regardless_ of what the CFLAGS in the >> environment says. I haven't checked the patches in the src.rpm yet, >> but it is _probably_ coming from the upstream tar ball. Which is not >> good, because it means chasing such dubious Makefile behaviour >> upstream with developers who think "they know better" because "it >> works for them". >> >> Gordan > The %configure macro is where the flags are set. You can run rpm --eval > %configure to see what's going on there. It looks like the CPPFLAGS > exported in gzip are in addition to the default CPPFLAGS, which are > appended when %configure is called. No, my point is that the CC, CXX and CPP environment variables aren't getting set. This doesn't seem to get passed in by default and it is pretty important if a different compiler is to be used. The real problem here is lack of consistency. There are four cases: 1) CC variables get set from %__cc. This is the way all package spec files should do it, IMO. 2) CC variables don't get set at all. The build will hopefully default to gcc/cc, and it could be easily overriden by exporting the CC environment variable before running the build process. Great in theory, but since some packages set it, either to %__cc or hard-code it, not really a solution. 3) CC variables get hard-coded in the spec file. Almost the worst possible case. This really, REALLY should never happen. 4) CC variables get hard-coded in the build source. I don't even want to go there. > As for the bzip2 spec, it looks like > there isn't a configure script, so the maintainer had to manually set > all the variables that %configure would have taken care of. I guess > bzip2 is actually the anomaly here. bzip2 spec file sets CC to %__cc, which is, IMO, the correct thing to do. My point was that all package spec files should do this. > As for -O2 and -Os slipping in, you'll have to patch or sed them out. A > lot of the time upstream will hard code flags, but since -O2 is the > Fedora default nobody really removes them when they pop up. -O2 only > appears in about 7 files, so it shouldn't be too hard to eliminate. This is what I am doing, but considering that I am planning to do this for most of the packages in the distribution, that's going to be a LOT of bugzilla reports. So many, in fact, that I wouldn't be surprised if someboy closes them as NOTABUG/WONTFIX because non-gcc compilers "aren't supported". I've had this "not supported" line used a justification for all sorts of horrible bodges in the distro, with the solution being "we'll document it's broken". Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] dietlibc port?
On 01/06/2011 11:15 PM, Rich Mattes wrote:
>>> Andy Green wrote:
>>> > On 01/06/11 16:17, Somebody in the thread at some point said:
>>> >
>>> > Hi -
>>> >
>>> >> Digging a bit more, it seems that bin-arm/diet segfaults when
>>> executed
>>> >> without any parameters, so it seems that this is the bit that
>>> >> miscompiled somewhere.
>>> >
>>> > Did you try running it in gdb and get a clue about what blows?
>>>
>>> Not yet, no.
>>>
>>> >> It turns out that the problem is actually to do witha GCC bug.
>>> When it
>>> >> is building bin-arm/diet with -Ox (x = {s,2,3}) , the resulting
>>> binary
>>> >> segfaults. When the binary is built with -O1 or -O0, it works fine.
>>> >
>>> > Is there a particular gcc bug you traced it down to? Because it does
>>> > not follow that all changes to program behaviour with different
>>> > optimization options are necessarily gcc bugs; it can show up
>>> > broken-ness in code that happens to not show symptoms according
>>> to how
>>> > it is compiled.
>>>
>>> That's fair, but an awful lot seems to break. If dietlibc really is that
>>> broken, I have to question how it ever worked for anyone reliably. I'm
>>> also wondering if it might be some of the Fedora patches that are
>>> breaking it. I'll try it without any post-0.32 patches.
>>>
>>> You should also probably try the F13 gcc. Bugs reported against the
>>> F12 gcc are going to be ignored, since nobody is working on any F12
>>> stuff anymore.
>>
>> I am slowly shifting things over to F13, but there is a lot to DIY
>> build. For example, things like Firefox don't work because of an API
>> version mismatch with xulrunner. And it helps to have a relatively
>> usable system to do development on. :)
>>
>> Besides, the reason I need dietlibc is because util-vserver requires
>> it and I want to work on F13 stuff in a vserver chroot in order to
>> ensure that the host system remains operational even if I badly break
>> important low-level things.
>>
> Ah, I see. I've just been using a plain chroot into the f13 rootfs with
> /proc bind mounted to the rootfs /proc, but it looks like vserver has
> some more features.
OK, I have tried F13 gcc. It turns out that dropping in the koji
repository and doing yum update gcc does the trick without clobbering
too much, and without causing the whole of F12 to fall over. This is a
good sign. :)
It is only a small update, it seems, from 4.4.2 to 4.4.4.
It also makes absolutely no difference. The same thing happens. The
build fails with segfaults during the build (the "diet" binary built
during the build gets used) with -On, n={s,2,3}. The build succeeds with
-On, n={0,1}. However, even with -O0 about half of the tests fail with
segfaults.
I also tried a vanilla dietlibc 0.32 build from a tarball, and
predictably, that doesn't work any better at all.
gdb reveals the following:
# gdb atexit
(gdb) run
Starting program: /usr/src/redhat/BUILD/dietlibc-0.32/test/atexit
Program received signal SIGSEGV, Segmentation fault.
0x8230 in ?? ()
(gdb) backtrace
Cannot access memory at address 0x0
#0 0x8230 in ?? ()
#1 0x81dc in __libc_exit (code=0) at lib/atexit.c:25
#2 0x8104 in _start () at arm/start.S:34
So the problem seems to be in arm/start.S on line 34.
_start:
mov fp, #0 @ clear the frame pointer
ldr a1, [sp], #4@ argc
mov a2, sp @ argv
ldr ip, .L3
add a3, a2, a1, lsl #2 @ &argv[argc]
add a3, a3, #4 @ envp
str a3, [ip, #0]@ environ = envp
bl main
@
@ The exit status from main() is already in r0.
@ We need to branch to 'exit' in case we have linked with 'atexit'.
@
bl exit
Line 34 is the one with "bl exit" on it. My ARM assembly isn't really up
to the task of debugging this further at the moment.
Has anyone ever managed to get dietlibc to build on ARM Linux before?
Having said that, I just tried building the F12 and F14 dietlibc
packages from src.rpms on a RHEL6b2 machine (x86-64), and some of the
tests fail with segfaults there, too...
It's almost half tempting to install the broken build for dependency's
sake and see if util-vserver actually trips any of it at run-time. But I
am a little concerned WRT whether this actually works and passes all
self-tests even on x86 Fedora.
Gordan
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] dietlibc port?
Andy Green wrote: > On 01/07/11 00:34, Somebody in the thread at some point said: > > Hi - > >> Program received signal SIGSEGV, Segmentation fault. >> 0x8230 in ?? () >> (gdb) backtrace >> Cannot access memory at address 0x0 >> #0 0x8230 in ?? () >> #1 0x81dc in __libc_exit (code=0) at lib/atexit.c:25 >> #2 0x8104 in _start () at arm/start.S:34 >> >> So the problem seems to be in arm/start.S on line 34. > > No, the backtrace starts with the deepest call. D'oh! Caffeine underflow error. :'( > The problem is inside __libc_exit we end up at 0x8230 and then jump to > 0x0. 0x8230 looks fairly sane as an address so you need to disassemble > from a bit before there and see what you see. > >> It's almost half tempting to install the broken build for dependency's >> sake and see if util-vserver actually trips any of it at run-time. But I >> am a little concerned WRT whether this actually works and passes all >> self-tests even on x86 Fedora. > > It might be worth asking the dietlibc dude if the tests are even > expected to work OK on ARM. I saw he has a FAQ explaining why "this > variable may be used uninitialized" warnings are WONTFIX because he > thinks they save a byte or two, that is not the best sign. That doesn't sound too promising. My motivation to debug code of that nature is rapidly fading, not least because it turns out that the reason I needed dietlibc has disappeared - it turns out util-vserver package that I need it for will happily build against the standard full-fat libc. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] dietlibc port?
Andy Green wrote: > On 01/07/11 10:02, Somebody in the thread at some point said: > >> That doesn't sound too promising. My motivation to debug code of that >> nature is rapidly fading, not least because it turns out that the reason >> I needed dietlibc has disappeared - it turns out util-vserver package >> that I need it for will happily build against the standard full-fat libc. > > Sounds like you found a solution ^^ It's a solution for me, but from tthe philosophical point of view, there is probably the greater issue of the distribution to consider. Is dietlibc really that useful on a non-embedded distribution (yes, I know I'm referring to the ARM port of something as non-embedded)? What really concerns me is that it doesn't build on x86 either, at which point I can't but question what the point of having it in the current state is at all. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Broken sha512sum in coreutils
It would appear that sha512sum is broken, at least in the F12 distro (coreutils-7.6-5.fc12.fa1.armv5tel). It is producing a different hash for the same file compared to what my x86 machines produce. This is quite worrying and a potentially dangerous crypto-security issue. The only thing that comes to mind as a potential cause (other than a bug) is that I am using gcc/libgcc from F13 with F12 coreutils. I just updated coreutils to the F13 package (coreutils-8.4-5.fc13.armv5tel), and that produces the correct hashes. Can anybody with a clean F12 vanilla copy check if they can reproduce the problem? Thanks. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] dietlibc port?
Andy Green wrote: >>> Sounds like you found a solution ^^ >> >> It's a solution for me, but from tthe philosophical point of view, there >> is probably the greater issue of the distribution to consider. Is >> dietlibc really that useful on a non-embedded distribution (yes, I know >> I'm referring to the ARM port of something as non-embedded)? What really > > Well a major reason to rely on a distro with a well-stocked repo of > binaries is that you can just use them, and other people have been > banging on them and fixing them too. The prebuilt stuff is all built > against glibc so that's a strong reason to stick with that. The point I was getting to was that the stock of packages at least in the base distro should be consistent across platforms, except in very hardware-specific cases (e.g. there's probably no point in having grub on ARM or uboot on x86). >> concerns me is that it doesn't build on x86 either, at which point I >> can't but question what the point of having it in the current state is >> at all. > > Dunno. However I do know that there is a lot of politics at least in > the past around glibc > > http://www.google.com/#hl=en&source=hp&q=glibc+drepper+arrogant > > ... so it wouldn't surprise me if it's in the distro as a hedge on that > as much as anything else. It seriously makes you wonder how come there isn't a better, less politically encumbered libc around. The really vexing thing about the situation is that both glibc and dietlibc are very gcc specific. This rather precludes the possibility of having an entire distro built with another (better) compiler. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
Andy Green wrote: > On 01/07/11 10:40, Somebody in the thread at some point said: >> It would appear that sha512sum is broken, at least in the F12 distro >> (coreutils-7.6-5.fc12.fa1.armv5tel). It is producing a different hash >> for the same file compared to what my x86 machines produce. This is >> quite worrying and a potentially dangerous crypto-security issue. >> >> The only thing that comes to mind as a potential cause (other than a >> bug) is that I am using gcc/libgcc from F13 with F12 coreutils. I just >> updated coreutils to the F13 package (coreutils-8.4-5.fc13.armv5tel), >> and that produces the correct hashes. >> >> Can anybody with a clean F12 vanilla copy check if they can reproduce >> the problem? > > No problem here. > > ARM: coreutils-7.6-5.fc12.fa1.armv5tel > > [r...@ivmon ~]# dd if=/dev/zero of=/tmp/z bs=512 count=10 > 10+0 records in > 10+0 records out > 5120 bytes (5.1 kB) copied, 0.000959 s, 5.3 MB/s > [r...@ivmon ~]# sha512sum /tmp/z > 1f1e6f098e99bb0ab52c3142f0fb545b00470d267823d44fd609fdaae1a6f45fb437de931fa16bbb4a702c0cba7abb9954b737ff4edb30f16ae39a2c67ee6bb7 > > /tmp/z > [r...@ivmon ~]# > > > x86_64: coreutils-8.8-2.fc15.x86_64 > > [agr...@otae Downloads]$ dd if=/dev/zero of=/tmp/z bs=512 count=10 > 10+0 records in > 10+0 records out > 5120 bytes (5.1 kB) copied, 7.6686e-05 s, 66.8 MB/s > [agr...@otae Downloads]$ sha512sum /tmp/z > 1f1e6f098e99bb0ab52c3142f0fb545b00470d267823d44fd609fdaae1a6f45fb437de931fa16bbb4a702c0cba7abb9954b737ff4edb30f16ae39a2c67ee6bb7 > > /tmp/z > [agr...@otae Downloads]$ > > Check with ldd what it is linking to. Thanks for that. I'll check as soon as I get my vserver chroots going. I'll put a clean F12 from the backup I took in there and see what it does. Hopefully it's just a libgcc mismatch issue - which would be worrying, but it'd only arise in a franken-distro half way between F12 and F13 (which is, sadly, all I have handy at the moment). Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
Gordan Bobic wrote: > Andy Green wrote: >> On 01/07/11 10:40, Somebody in the thread at some point said: >>> It would appear that sha512sum is broken, at least in the F12 distro >>> (coreutils-7.6-5.fc12.fa1.armv5tel). It is producing a different hash >>> for the same file compared to what my x86 machines produce. This is >>> quite worrying and a potentially dangerous crypto-security issue. >>> >>> The only thing that comes to mind as a potential cause (other than a >>> bug) is that I am using gcc/libgcc from F13 with F12 coreutils. I just >>> updated coreutils to the F13 package (coreutils-8.4-5.fc13.armv5tel), >>> and that produces the correct hashes. >>> >>> Can anybody with a clean F12 vanilla copy check if they can reproduce >>> the problem? >> No problem here. >> >> ARM: coreutils-7.6-5.fc12.fa1.armv5tel >> >> [r...@ivmon ~]# dd if=/dev/zero of=/tmp/z bs=512 count=10 >> 10+0 records in >> 10+0 records out >> 5120 bytes (5.1 kB) copied, 0.000959 s, 5.3 MB/s >> [r...@ivmon ~]# sha512sum /tmp/z >> 1f1e6f098e99bb0ab52c3142f0fb545b00470d267823d44fd609fdaae1a6f45fb437de931fa16bbb4a702c0cba7abb9954b737ff4edb30f16ae39a2c67ee6bb7 >> >> /tmp/z >> [r...@ivmon ~]# >> >> >> x86_64: coreutils-8.8-2.fc15.x86_64 >> >> [agr...@otae Downloads]$ dd if=/dev/zero of=/tmp/z bs=512 count=10 >> 10+0 records in >> 10+0 records out >> 5120 bytes (5.1 kB) copied, 7.6686e-05 s, 66.8 MB/s >> [agr...@otae Downloads]$ sha512sum /tmp/z >> 1f1e6f098e99bb0ab52c3142f0fb545b00470d267823d44fd609fdaae1a6f45fb437de931fa16bbb4a702c0cba7abb9954b737ff4edb30f16ae39a2c67ee6bb7 >> >> /tmp/z >> [agr...@otae Downloads]$ >> >> Check with ldd what it is linking to. > > Thanks for that. I'll check as soon as I get my vserver chroots going. > I'll put a clean F12 from the backup I took in there and see what it > does. Hopefully it's just a libgcc mismatch issue - which would be > worrying, but it'd only arise in a franken-distro half way between F12 > and F13 (which is, sadly, all I have handy at the moment). OK, this is deeply weird. My F12 rootfs in a chroot is again showing the broken behaviour: [r...@sheeva /]# sha512sum /vservers/f12/test-file 9d5f70ef2b126ada3750027b5cd8d2a97c96c66d334385ffea5ae1e7cfd596e1e5ac6930f47b95c5b5b916a3709ba1e1ed3be5e0e47d0327f873ea84bedab2fa /vservers/f12/test-file [r...@sheeva /]# vserver f12 enter [r...@f12 /]# sha512sum /test-file 3e6984afdbbdc6012df975d70ddbde5166dd216271387a89c4970d6927b461adeb5815453bd994a24566cb9bd04910f62850e1b9f922d7ec4d28b7ef0629e61b /test-file It's the same file, but the computed hash is different. That indicates that it's not a mismatched libgcc linking issue (*phew*). On the broken machine: [r...@f12 /]# rpm -qa | grep -i coreutils coreutils-libs-7.6-5.fc12.fa1.armv5tel coreutils-7.6-5.fc12.fa1.armv5tel [r...@f12 /]# ldd /usr/bin/sha512sum libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40241000) libc.so.6 => /lib/libc.so.6 (0x40254000) /lib/ld-linux.so.3 (0x40092000) On the working machine: [r...@sheeva /]# rpm -qa | grep coreutils coreutils-8.4-5.fc13.armv5tel coreutils-libs-8.4-5.fc13.armv5tel [r...@sheeva /]# ldd /usr/bin/sha512sum libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x401c2000) libc.so.6 => /lib/libc.so.6 (0x401d5000) /lib/ld-linux.so.3 (0x4008d000) So the linking seems to be the same. The only packages that are different between the two are the gcc stuff updated to f13 (which didn't cause the problem in the first place) and the coreutils. The fc13 coreutils package fixed it. Have you god an md5sum of the sha512 binary? Mine is: [r...@sheeva ~]# md5sum /vservers/f12/usr/bin/sha512sum 7667ac4b53249e53533860518e916719 /vservers/f12/usr/bin/sha512sum It's the only thing I can think of right now, since your coreutils version is exactly the same as mine, and mine is verifiably and consistently producing wrong hashes. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
Andy Green wrote: > On 01/07/11 14:51, Somebody in the thread at some point said: > > Can anybody with a clean F12 vanilla copy check if they can reproduce > the problem? No problem here. > >> Have you god an md5sum of the sha512 binary? Mine is: >> [r...@sheeva ~]# md5sum /vservers/f12/usr/bin/sha512sum >> 7667ac4b53249e53533860518e916719 /vservers/f12/usr/bin/sha512sum > > [r...@ivmon ~]# md5sum `which sha512sum` > 0b45bcdf989568fc1dfcc38a7063651a /usr/bin/sha512sum > [r...@ivmon ~]# ls -l `which sha512sum` > -rwxr-xr-x 1 root root 103456 Oct 8 2009 /usr/bin/sha512sum On the face of the checksum I thought it was just a corrupted binary. But the size is different, too! [r...@sheeva ~]# ls -l /vservers/f12/usr/bin/sha512sum -rwxr-xr-x 1 root root 100636 Oct 8 2009 /vservers/f12/usr/bin/sha512sum This makes me wonder where my binary came from. So I re-downloaded the rootfs from here: http://ftp.linux.org.uk/pub/linux/arm/fedora/rootfs/rootfs-f12.tar.bz2 (because it's linked from here: http://fedoraproject.org/wiki/Architectures/ARM/BeagleBoardxMSDCard ) extracted it, and: [r...@sheeva /usr/src/arm/rootfs-f12]# ls -la usr/bin/sha512sum -rwxr-xr-x 1 root root 100636 Oct 8 2009 usr/bin/sha512sum [r...@sheeva /usr/src/arm/rootfs-f12]# md5sum usr/bin/sha512sum 7667ac4b53249e53533860518e916719 usr/bin/sha512sum That means that the sha512sum binary that ships in the f12 rootfs is broken. Where did your rootfs-f12 image come from? Did you build the coreutils yourself? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
Andy Green wrote: > On 01/07/11 15:11, Somebody in the thread at some point said: > >> That means that the sha512sum binary that ships in the f12 rootfs is >> broken. Where did your rootfs-f12 image come from? Did you build the >> coreutils yourself? > > No, I build my images from packages, not using the tarball. I have a > script based off mkrootfs-f12 that uses yum and some magic to fetch from > the normal repo and builds a rootfs purely from packages. > > Maybe it means the stuff in the f12 tarball is broken but I am not sure > you proved that yet. You just show that the version in the f12 tarball > has different size (so naturally different md5sum). The breakage could > still be in some other library from the tarball environment. That seems unlikely, because with everything else remaining the same, a new coreutils package (from F13 repository) fixes it. And coreutils doesn't bring any libs with it, from what I can see. So since the new, working coreutils links against all the same libraries it doesn't bring with it, that indicates that the coreutils in the rootfs tar ball is at fault here. Or am I missing something? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
Andy Green wrote: > On 01/07/11 15:29, Somebody in the thread at some point said: > >>> Maybe it means the stuff in the f12 tarball is broken but I am not sure >>> you proved that yet. You just show that the version in the f12 tarball >>> has different size (so naturally different md5sum). The breakage could >>> still be in some other library from the tarball environment. >> >> That seems unlikely, because with everything else remaining the same, a >> new coreutils package (from F13 repository) fixes it. And coreutils >> doesn't bring any libs with it, from what I can see. So since the new, >> working coreutils links against all the same libraries it doesn't bring >> with it, that indicates that the coreutils in the rootfs tar ball is at >> fault here. Or am I missing something? > > Correct me if I am wrong but you mention that for the first time now :-) It is not at all unlikely that I unintentionally ommited some of these important details. :-/ > In any event I cannot reproduce your problem just by bringing over > sha512sum from the rootfs tarball: > > 1) download > > http://ftp.linux.org.uk/pub/linux/arm/fedora/rootfs/rootfs-f12.tar.bz2 > > 2) untar, scp rootfs-f12/usr/bin/sha512sum :/tmp > > 3) On mybox, > > [r...@ivmon ~]# /tmp/sha512sum /tmp/z > 1f1e6f098e99bb0ab52c3142f0fb545b00470d267823d44fd609fdaae1a6f45fb437de931fa16bbb4a702c0cba7abb9954b737ff4edb30f16ae39a2c67ee6bb7 > > /tmp/z > > ie, the same result as > > [r...@ivmon ~]# sha512sum /tmp/z > 1f1e6f098e99bb0ab52c3142f0fb545b00470d267823d44fd609fdaae1a6f45fb437de931fa16bbb4a702c0cba7abb9954b737ff4edb30f16ae39a2c67ee6bb7 > > /tmp/z OK, that IS weird, because I can! [r...@sheeva /usr/src/arm/rootfs-f12]# usr/bin/sha512sum /bin/bash 8b7116b3000e68623d6182b5d8f4f72a3189b7c0019eea036bf8aa41248198e1fc631d9e6709458d5d4eeb4790613964a53610713701d7e7fc4651e26dbd4615 /bin/bash [r...@sheeva /usr/src/arm/rootfs-f12]# sha512sum /bin/bash c3a60b82648493a99f39aa229810cb03c1ef9cb842bf3f69cb093005b95c6c5b4cbf3f92d9c679bca560c0fa280e54cbe789cf8f89f6e4e4522ca0bbf7658610 /bin/bash [r...@sheeva /usr/src/arm/rootfs-f12]# The results are definitely different when using the sha512sum from the tar ball. (/usr/src/arm/rootfs-f12 is a fresh, pristine tarball extract) Where are our methods diverging? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] dietlibc port?
omall...@msu.edu wrote: > Sounds like you found a solution ^^ It's a solution for me, but from tthe philosophical point of view, there is probably the greater issue of the distribution to consider. Is dietlibc really that useful on a non-embedded distribution (yes, I know I'm referring to the ARM port of something as non-embedded)? What really >>> >>> Well a major reason to rely on a distro with a well-stocked repo of >>> binaries is that you can just use them, and other people have been >>> banging on them and fixing them too. The prebuilt stuff is all built >>> against glibc so that's a strong reason to stick with that. >> >> The point I was getting to was that the stock of packages at least in >> the base distro should be consistent across platforms, except in very >> hardware-specific cases (e.g. there's probably no point in having grub >> on ARM or uboot on x86). > > uboot on x86 would be nice... :P Although so would a shipping A9MP > chip... :) And I was just thinking grub would be nice on ARM. :) > I agree with the jist of what you are saying. > > I also understand the first time you work through the code, you are > going to find arch specific bugs, that aren't easy to solve and need to > be pushed upstream to the source to get fixed and I am guessing most > projects don't have a lot of ARM support. If that were the case - fine. But dietlibc has claimed ARM support since at least v0.30. The really staggering part is that it fails on x86-64, too, and failing the test suite it brings with itself seems to be deemed the norm. concerns me is that it doesn't build on x86 either, at which point I can't but question what the point of having it in the current state is at all. >>> >>> Dunno. However I do know that there is a lot of politics at least in >>> the past around glibc >>> >>> http://www.google.com/#hl=en&source=hp&q=glibc+drepper+arrogant >>> >>> ... so it wouldn't surprise me if it's in the distro as a hedge on that >>> as much as anything else. > > Debian/Ubuntu switched to eglibc which is a "variant" of glibc for > embedded systems. They tend to accept more patches. It is compatible > wherever possible and they do push changes to the mainline glibc. > > I think it started mainly because they couldnt get patches put in > mainline fast enough and they needed less bloat for embedded like dietlibc. Much as I hate to say this, but I think they did the right thing. What are the chances of the same happening in Fedora? > I thought Damn Small Linux, and the Linux router project used dietlibc > but I could be wrong or they may have switched to eglibc too. Maybe > dietglibc is abandon or folded into eglibc. Doesn't seem to be abandoned, from what I can tell. >> It seriously makes you wonder how come there isn't a better, less >> politically encumbered libc around. The really vexing thing about the >> situation is that both glibc and dietlibc are very gcc specific. This >> rather precludes the possibility of having an entire distro built with >> another (better) compiler. > > The Intel compiler's performance boosts of 800% you are seeing are > really the SSE optimisation routines. Which Intel is insanely good at it > and kudos to them, but they also make the hardware. Of course. Disappointingly, though most programmers don't use a decent vectorizing compiler, so they don't bother making sure that their loops vectorize nicely, which limits the effectiveness of a good compiler. It's not a replacement for good programming. :( > If you DO find places in the code where gcc doesn't autovectorize the > code properly, please report the code segments as bugs to the gcc group. > They need to be aware of the issue so it can be fixed it. I have done that to some length in the past, and the "better vectorizer" is always "due in the next version, just a couple of months away". After 3 years of no obvious improvement, I gave up. > GCC supports a lot more platforms and it might not be the fastest > compiler on a specific platform. But it isn't a complete dog either. It could be argued that this is because most of the competition is totally useless. Have a look at the article I wrote on the subject here, originally some 3 years ago: http://www.altechnative.net/?p=58 Having re-run the tests for ICC and GCC the other day with the latest versions, the ICC speed-up is virtually identical. Now if only we could get OSS developers to test that their code works correctly with something other than GCC and make sure that their loops are written in such a way that they vectorize, there would be a LOT of potential performance to be gained. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
Andy Green wrote: > On 01/07/11 15:58, Somebody in the thread at some point said: > >> The results are definitely different when using the sha512sum from the >> tar ball. >> >> (/usr/src/arm/rootfs-f12 is a fresh, pristine tarball extract) >> >> Where are our methods diverging? > > Dunno, kernel is different though. > > [r...@ivmon ~]# /tmp/sha512sum /bin/bash > ceea8800ab1258468c76839e42b1457bff8b4888766758420612dc991c04c46ef0f8fc0ea6d0fd0132f00a9666086d18900514632c0f2afe428302e2b2b5b384 > > /bin/bash > [r...@ivmon ~]# /usr/bin/sha512sum /bin/bash > ceea8800ab1258468c76839e42b1457bff8b4888766758420612dc991c04c46ef0f8fc0ea6d0fd0132f00a9666086d18900514632c0f2afe428302e2b2b5b384 > > /bin/bash > [r...@ivmon ~]# ls -l /tmp/sha512sum > -rwxr-xr-x 1 root root 100636 Jan 11 00:41 /tmp/sha512sum > [r...@ivmon ~]# ls -l /usr/bin/sha512sum > -rwxr-xr-x 1 root root 103456 Oct 8 2009 /usr/bin/sha512sum > > Is your alignment stuff all zeroes still? > > [r...@ivmon ~]# cat /proc/cpu/alignment > User:0 > System:0 > Skipped:0 > Half:0 > Word:0 > DWord:0 > Multi:0 > User faults:0 (ignored) You may be on to something here: [r...@sheeva ~]# uname -a Linux sheeva 2.6.36.2-vs2.3.0.36.38.2-kw #1 Wed Jan 5 17:54:59 GMT 2011 armv5tel armv5tel armv5tel GNU/Linux [r...@sheeva ~]# cat /proc/cpu/alignment User: 12230853 System: 1 Skipped:0 Half: 0 Word: 0 DWord: 1 Multi: 0 User faults:0 (ignored) What does that imply, then? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
Gordan Bobic wrote: > Andy Green wrote: >> On 01/07/11 16:15, Somebody in the thread at some point said: >> >>> [r...@sheeva ~]# cat /proc/cpu/alignment >>> User: 12230853 >>> System: 1 >>> Skipped:0 >>> Half: 0 >>> Word: 0 >>> DWord: 1 >>> Multi: 0 >>> User faults:0 (ignored) >> >> I wrote about the alignment issue here on ARM: >> >> http://warmcat.com/_wp/2007/05/25/the-alignment-monster/ >> >> If I understood it, you have a bazillion alignment faults in your user >> code that aren't being fixed up, which will cause exactly this kind of >> symptom with sha512sum. >> >> Try >> >> echo 2 > /proc/cpu/alignment >> >> (take care to keep the spaces as shown) and try the tests again. > > Yup, that fixes it! :) > > So what is the correct/permanent solution to avoid problems like this? > > *goes to RTFA* ;) > > Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
Gordan Bobic wrote: > Andy Green wrote: >> On 01/07/11 16:15, Somebody in the thread at some point said: >> >>> [r...@sheeva ~]# cat /proc/cpu/alignment >>> User: 12230853 >>> System: 1 >>> Skipped:0 >>> Half: 0 >>> Word: 0 >>> DWord: 1 >>> Multi: 0 >>> User faults:0 (ignored) >> >> I wrote about the alignment issue here on ARM: >> >> http://warmcat.com/_wp/2007/05/25/the-alignment-monster/ > > Aha, I know what you are talking about now, and I am aware of such > issues. Here is a similar article a friend of mine wrote: > > http://www.altechnative.net/?p=48 Does changing the /proc/cpu/alignment setting from 0 (ignored) to 2 (fixup) come with a noticeable performance penalty? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] dietlibc port?
omall...@msu.edu wrote: >> concerns me is that it doesn't build on x86 either, at which point I >> can't but question what the point of having it in the current >> state is >> at all. > > Dunno. However I do know that there is a lot of politics at least in > the past around glibc > > http://www.google.com/#hl=en&source=hp&q=glibc+drepper+arrogant > > ... so it wouldn't surprise me if it's in the distro as a hedge on > that > as much as anything else. >>> >>> Debian/Ubuntu switched to eglibc which is a "variant" of glibc for >>> embedded systems. They tend to accept more patches. It is compatible >>> wherever possible and they do push changes to the mainline glibc. >>> >>> I think it started mainly because they couldnt get patches put in >>> mainline fast enough and they needed less bloat for embedded like >>> dietlibc. >> >> Much as I hate to say this, but I think they did the right thing. What >> are the chances of the same happening in Fedora? > > It sounds like they did the right thing.. I think what they do is they > take mainline glibc and fold their patches into it and release it as a > version. > > I think you almost have to fork fedora for a bit and see if you can get > everything built, fix everything that doesn't and get those bugs fixed > upstream then propose it as a major change for 16. Forking a distro is a bit too much for me to chew at the moment. Just fixing up the packages I actually need to use is enough work as it is, without taking on all the rest as well. :) >>> I thought Damn Small Linux, and the Linux router project used dietlibc >>> but I could be wrong or they may have switched to eglibc too. Maybe >>> dietglibc is abandon or folded into eglibc. >> >> Doesn't seem to be abandoned, from what I can tell. > > It just hasn't been updated in a year and if 64-bit doesnt work right, > that is kind of a red flag to me. Maybe, but the person whose email address is all over the spec file responded to the RH bugzilla ticket pretty quickly. :) It seriously makes you wonder how come there isn't a better, less politically encumbered libc around. The really vexing thing about the situation is that both glibc and dietlibc are very gcc specific. This rather precludes the possibility of having an entire distro built with another (better) compiler. >>> >>> The Intel compiler's performance boosts of 800% you are seeing are >>> really the SSE optimisation routines. Which Intel is insanely good at it >>> and kudos to them, but they also make the hardware. >> >> Of course. Disappointingly, though most programmers don't use a decent >> vectorizing compiler, so they don't bother making sure that their loops >> vectorize nicely, which limits the effectiveness of a good compiler. >> It's not a replacement for good programming. :( > > No but a lot of times if you point it out to them they will fix it. :P > However I'm not sure most distributions by default have vectorization on. I suspect the reason it's not on is because: 1) Most code hasn't been written with it in mind 2) Vectorizer is not working well enough to make a difference worth pursuing even on the code that has been written with it in mind. 3) Because it's not widely used, it is probably deemed insufficiently tested. GCC seems to miscompile at lesser provocations (see earlier in this thread about binaries that segfault when -O > 1 is used. >>> If you DO find places in the code where gcc doesn't autovectorize the >>> code properly, please report the code segments as bugs to the gcc group. >>> They need to be aware of the issue so it can be fixed it. >> >> I have done that to some length in the past, and the "better vectorizer" >> is always "due in the next version, just a couple of months away". After >> 3 years of no obvious improvement, I gave up. > > I just report them and let them put it on their toDo list, or fix them. :P > It depends on the project whether it gets put at a high enough priority > to get done. Yes, I get depressed every time I look at the ver-growing list of open bugs I have filed on RH bugzilla... >>> GCC supports a lot more platforms and it might not be the fastest >>> compiler on a specific platform. But it isn't a complete dog either. >> >> It could be argued that this is because most of the competition is >> totally useless. Have a look at the article I wrote on the subject here, >> originally some 3 years ago: >> >> http://www.altechnative.net/?p=58 >> >> Having re-run the tests for ICC and GCC the other day with the latest >> versions, the ICC speed-up is virtually identical. >> >> Now if only we could get OSS developers to test that their code works >> correctly with something other than GCC and make sure that their loops >> are written in such a way that they vectorize, there would be a LOT of >> potential performance to be gained. > > hmm how are the loops written so they didn't vectorize with gcc in your >
Re: [fedora-arm] Broken sha512sum in coreutils
Andy Green wrote: > On 01/07/11 16:52, Somebody in the thread at some point said: > I wrote about the alignment issue here on ARM: http://warmcat.com/_wp/2007/05/25/the-alignment-monster/ >>> >>> Aha, I know what you are talking about now, and I am aware of such >>> issues. Here is a similar article a friend of mine wrote: >>> >>> http://www.altechnative.net/?p=48 > > No, it's not the same issue. > > On x86 as described on your link, it's just a performance penalty if > your members are not aligned. On ARM without fixup, you read actual > garbage as described on my article. Yup, I was more referring to the data not aligning when unioning structures with an array, for example. But yes, I totally get what your article is saying. >> Does changing the /proc/cpu/alignment setting from 0 (ignored) to 2 >> (fixup) come with a noticeable performance penalty? > > Yeah it is expensive. Something else is up, probably with your kernel, > that you have so many userland alignment faults at all. > > As you saw, I don't have any. What kernel are you using? As you may have inferred, I use 2.6.36.2 with the vserver patches. Do you know what configuration options on the kernel could be causing problems like this? Optimize for size, perhaps? And these alignment error counters (I'm assuming that is what those large numbers in /proc/cpu/alignment are) - do they implicitly mean actual calculation errors? Or are they generally harmless? I ask because I haven't actually had anything crash (apart from the dietlibc related stuff. But since the box had spent most of yesterday compiling and testing dietlibc, it is plausible that a lot of the counts came from then. I'll keep an eye on it and see if I can find what causes it. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
On 01/07/2011 05:25 PM, Andy Green wrote: > On 01/07/11 17:17, Somebody in the thread at some point said: > >>> No, it's not the same issue. >>> >>> On x86 as described on your link, it's just a performance penalty if >>> your members are not aligned. On ARM without fixup, you read actual >>> garbage as described on my article. >> >> Yup, I was more referring to the data not aligning when unioning > > That's nothing to do with this issue. > > With this issue, a correct structure in a typedef or a struct with > correct alignment padding turns to crap because the structure pointed to > is not on a u32 boundary for example. I see. But shouldn't the compiler be taking care of that? -malign? >> And these alignment error counters (I'm assuming that is what those >> large numbers in /proc/cpu/alignment are) - do they implicitly mean >> actual calculation errors? Or are they generally harmless? I ask because > > They're not harmless if you don't fix them up and you're going to use > the misaligned data for something: the data is corrupted. If you read > the data and didn't do anything important with it then you won't see any > problem. > > What gcc did you cook your kernel with? The F12 repository kernel. I am currently building a new one (needed a few extra options) with the F13 gcc and bintools. But all these errors appear to be under User rather than System, so is it really the kernel? Since over the past hour of kernel recompiling the counters haven't increased at all, my guess is that it all happened last night when I was building/testing dietlibc stuff. I'll test that hypothesis when the new kernel is built. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
On 01/07/2011 06:52 PM, Andrew Haley wrote: > No, it's not the same issue. > > On x86 as described on your link, it's just a performance penalty if > your members are not aligned. On ARM without fixup, you read actual > garbage as described on my article. Yup, I was more referring to the data not aligning when unioning >>> >>> That's nothing to do with this issue. >>> >>> With this issue, a correct structure in a typedef or a struct with >>> correct alignment padding turns to crap because the structure pointed to >>> is not on a u32 boundary for example. >> >> I see. But shouldn't the compiler be taking care of that? -malign? > > The compiler will always take care of that, unless someone does > something really evil in either the code or the gcc options. s/will/should/ and I might agree. :) Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
On 01/07/2011 06:29 PM, Andrew Haley wrote: > [r...@sheeva ~]# cat /proc/cpu/alignment > User: 12230853 > System: 1 > Skipped:0 > Half: 0 > Word: 0 > DWord: 1 > Multi: 0 > User faults:0 (ignored) I wrote about the alignment issue here on ARM: http://warmcat.com/_wp/2007/05/25/the-alignment-monster/ If I understood it, you have a bazillion alignment faults in your user code that aren't being fixed up, which will cause exactly this kind of symptom with sha512sum. Try echo 2> /proc/cpu/alignment (take care to keep the spaces as shown) and try the tests again. >>> >>> Yup, that fixes it! :) >>> >>> So what is the correct/permanent solution to avoid problems like this? > > That was a fantastic piece of detective work! > > This must be a bug in sha512sum -- it shouldn't be affected by alignment. I am inclined to think it might be compiler related. Andy's package is the same version as mine, his works, mine does not. The only thing that is likely to be different is the build environment. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
On 01/07/2011 07:46 PM, Jitesh Shah wrote: > ..snip.. > >>> >>> This must be a bug in sha512sum -- it shouldn't be affected by alignment. >> >> I am inclined to think it might be compiler related. Andy's package is >> the same version as mine, his works, mine does not. The only thing that >> is likely to be different is the build environment. > > That and the development board. You are using a sheevaplug. > It is also likely that Andy's hardware does fixups for misaligned accesses. That can be done transparently in hardware without a performance hit? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
On 01/07/2011 06:45 PM, Gordan Bobic wrote: >>> And these alignment error counters (I'm assuming that is what those >>> large numbers in /proc/cpu/alignment are) - do they implicitly mean >>> actual calculation errors? Or are they generally harmless? I ask because >> >> They're not harmless if you don't fix them up and you're going to use >> the misaligned data for something: the data is corrupted. If you read >> the data and didn't do anything important with it then you won't see any >> problem. >> >> What gcc did you cook your kernel with? > > The F12 repository kernel. I am currently building a new one (needed a > few extra options) with the F13 gcc and bintools. > > But all these errors appear to be under User rather than System, so is > it really the kernel? Since over the past hour of kernel recompiling the > counters haven't increased at all, my guess is that it all happened last > night when I was building/testing dietlibc stuff. I'll test that > hypothesis when the new kernel is built. Update: Building the kernel produced no further alignment errors. The machine, however, just after boot: #cat /proc/cpu/alignment Fri Jan 7 20:08:51 2011 User: 24 System: 1 Skipped:0 Half: 0 Word: 0 DWord: 1 Multi: 0 User faults:0 (ignored) So something in the startup is still broken. Will test dietlibc build next. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
On 01/07/2011 08:13 PM, Andy Green wrote: >> counters haven't increased at all, my guess is that it all happened last >> night when I was building/testing dietlibc stuff. I'll test that >> hypothesis when the new kernel is built. > > Fine but what has happened with your sha512sum then? That didn't cause thousands of errors, only a handful - it wasn't being used much. The only thing I can think if that could have produced that may alignment errors (and segfaults to go with them, as it happens) was what I was doing with dietlibc. > Is it the case that > somehow the shared libc in memory is the dietlibc one? Maybe if you > reboot without touching anything that touches dietlibc you won't see > this issue again and the whole thing is a painful lesson to leave > dietlibc the hell alone ^^ I don't really see how. As I said, dietlibc is long uninstalled and the boot-up still trips this 24+1 times. I think the coreutils bug was a separate one. Now I just need to find what is causing the remaining few alignment issues. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
On 01/07/2011 08:27 PM, Andy Green wrote: On 01/07/11 20:17, Somebody in the thread at some point said: On 01/07/2011 08:13 PM, Andy Green wrote: counters haven't increased at all, my guess is that it all happened last night when I was building/testing dietlibc stuff. I'll test that hypothesis when the new kernel is built. Fine but what has happened with your sha512sum then? That didn't cause thousands of errors, only a handful - it wasn't being used much. The only thing I can think if that could have produced that So both sha512sum binaries are giving correct results now or what? No. The broken one is still broken if I disable alignment fix-ups. may alignment errors (and segfaults to go with them, as it happens) was what I was doing with dietlibc. Is it the case that somehow the shared libc in memory is the dietlibc one? Maybe if you reboot without touching anything that touches dietlibc you won't see this issue again and the whole thing is a painful lesson to leave dietlibc the hell alone ^^ I don't really see how. As I said, dietlibc is long uninstalled and the boot-up still trips this 24+1 times. I think the coreutils bug was a separate one. Now I just need to find what is causing the remaining few alignment issues. What you should do about that is set alignment=3 on your kernel commandline. That'll then be the default reaction to the alignment fault and it should give some logging about who is the process with the alignment faults. Ooo, thanks for that. :) I've attached the dmesg output. All the errors on boot seem to be coming from /lib/udev/devkit-disks-part-id. # rpm -qf /lib/udev/devkit-disks-part-id DeviceKit-disks-009-3.fc12.armv5tel yum updating this (and the 13 dependencies it has) from the F13 repository doesn't make the problem go away. :( Thankfully, though, nothing on the Sheeva uses this. I'll try rebuilding the latest version of DeviceKit from source and see if that makes the problem go away. Gordan Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.36.2-vs2.3.0.36.38.2-kw (r...@sheeva) (gcc version 4.4.4 20100713 (Red Hat 4.4.4-14) (GCC) ) #1 Fri Jan 7 19:15:14 GMT 2011 CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 CPU: VIVT data cache, VIVT instruction cache Machine: Marvell SheevaPlug Reference Board Memory policy: ECC disabled, Data cache writeback On node 0 totalpages: 131072 free_area_init_node: node 0, pgdat c03c1ec8, node_mem_map c0462000 Normal zone: 1024 pages used for memmap Normal zone: 0 pages reserved Normal zone: 130048 pages, LIFO batch:31 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: console=ttyS0,115200 ro root=/dev/mmcblk0p2 selinux=0 elevator=deadline alignment=3 PID hash table entries: 2048 (order: 1, 8192 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) allocated 2621440 bytes of page_cgroup please try 'cgroup_disable=memory' option if you don't want memory cgroups Memory: 256MB 256MB = 512MB total Memory: 512748k/512748k available, 11540k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xe080 - 0xfe80 ( 480 MB) lowmem : 0xc000 - 0xe000 ( 512 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .init : 0xc0008000 - 0xc0028000 ( 128 kB) .text : 0xc0028000 - 0xc038a000 (3464 kB) .data : 0xc03a - 0xc03c32a0 ( 141 kB) SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:114 Console: colour dummy device 80x30 Calibrating delay loop... 1192.75 BogoMIPS (lpj=5963776) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 Initializing cgroup subsys ns Initializing cgroup subsys cpuacct Initializing cgroup subsys memory Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys blkio CPU: Testing write buffer coherency: ok regulator: core version 0.5 NET: Registered protocol family 16 Kirkwood: MV88F6281-A1, TCLK=2. Feroceon L2: Enabling L2 Feroceon L2: Cache support initialised. initial MPP regs: 0111 3322 0010 final MPP regs: 0111 3322 bio: create slab at 0 vgaarb: loaded SCSI subsystem initialized NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default Switching to clocksource orion_clocksource NET: Registered protocol family 2 IP route cache hash table entries: 4096 (order:
Re: [fedora-arm] Broken sha512sum in coreutils
On 01/07/2011 09:32 PM, Andy Green wrote: > On 01/07/11 21:30, Somebody in the thread at some point said: >> for points of reference.. qemu f12 with a different kernel and the >> default gurplug install >> >> results from qemu f12 with new kernel: > >> [r...@fedora-arm ~]# ./x >> 0x65646362 >> [r...@fedora-arm ~]# cat /proc/cpu/alignment >> User:0 > > Nice, the hardware really did take care of it! Err, wasn't that in a qemu VM? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
On 01/07/2011 09:25 PM, Gordan Bobic wrote: > On 01/07/2011 08:27 PM, Andy Green wrote: >> On 01/07/11 20:17, Somebody in the thread at some point said: >>> On 01/07/2011 08:13 PM, Andy Green wrote: >>> >>>>> counters haven't increased at all, my guess is that it all happened >>>>> last >>>>> night when I was building/testing dietlibc stuff. I'll test that >>>>> hypothesis when the new kernel is built. >>>> >>>> Fine but what has happened with your sha512sum then? >>> >>> That didn't cause thousands of errors, only a handful - it wasn't being >>> used much. The only thing I can think if that could have produced that >> >> So both sha512sum binaries are giving correct results now or what? > > No. The broken one is still broken if I disable alignment fix-ups. > >>> may alignment errors (and segfaults to go with them, as it happens) was >>> what I was doing with dietlibc. >>> >>>> Is it the case that >>>> somehow the shared libc in memory is the dietlibc one? Maybe if you >>>> reboot without touching anything that touches dietlibc you won't see >>>> this issue again and the whole thing is a painful lesson to leave >>>> dietlibc the hell alone ^^ >>> >>> I don't really see how. As I said, dietlibc is long uninstalled and the >>> boot-up still trips this 24+1 times. I think the coreutils bug was a >>> separate one. Now I just need to find what is causing the remaining few >>> alignment issues. >> >> What you should do about that is set >> >> alignment=3 >> >> on your kernel commandline. That'll then be the default reaction to the >> alignment fault and it should give some logging about who is the process >> with the alignment faults. > > Ooo, thanks for that. :) > I've attached the dmesg output. > > All the errors on boot seem to be coming from > /lib/udev/devkit-disks-part-id. > > # rpm -qf /lib/udev/devkit-disks-part-id > DeviceKit-disks-009-3.fc12.armv5tel > > yum updating this (and the 13 dependencies it has) from the F13 > repository doesn't make the problem go away. :( > > Thankfully, though, nothing on the Sheeva uses this. I'll try rebuilding > the latest version of DeviceKit from source and see if that makes the > problem go away. Bah. The F14 DeviceKit src.rpm doesn't build. :( /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.4/../../../libgirepository-1.0.so: undefined reference to `g_malloc0_n' collect2: ld returned 1 exit status Traceback (most recent call last): File "/usr/bin/g-ir-scanner", line 38, in sys.exit(scanner_main(sys.argv)) File "/usr/lib/python2.6/site-packages/giscanner/scannermain.py", line 313, in scanner_main glibtransformer.get_get_type_functions()) File "/usr/lib/python2.6/site-packages/giscanner/dumper.py", line 231, in compile_introspection_binary return dc.run() File "/usr/lib/python2.6/site-packages/giscanner/dumper.py", line 132, in run self._link(bin_path, o_path) File "/usr/lib/python2.6/site-packages/giscanner/dumper.py", line 226, in _link subprocess.check_call(args) File "/usr/lib/python2.6/subprocess.py", line 488, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['/bin/sh', '../libtool', '--mode=link', '--tag=CC', '--silent', 'gcc', '-o', '/usr/src/redhat/BUILD/UPower-0.9.0/devkit-power-gobject/tmp-introspectz_WQKT/DeviceKitPowerGlib-1.0', '-O2', '-g', '-march=armv5te', '-L.', 'libdevkit-power-gobject.la', '-pthread', '-Wl,--export-dynamic', '-lgio-2.0', '-lgirepository-1.0', '-lgobject-2.0', '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lffi', '-lglib-2.0', '/usr/src/redhat/BUILD/UPower-0.9.0/devkit-power-gobject/tmp-introspectz_WQKT/DeviceKitPowerGlib-1.0.o']' returned non-zero exit status 1 make[2]: *** [DeviceKitPowerGlib-1.0.gir] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/UPower-0.9.0/devkit-power-gobject' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/UPower-0.9.0' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.C7DE1t (%build) In the end, I just gave up and did rpm -e DeviceKit-disks since I don't actually need it. Works fine now, but it looks like DeviceKit needs fixing. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
On 01/07/2011 10:08 PM, Andy Green wrote: > On 01/07/11 22:05, Somebody in the thread at some point said: > >> /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.4/../../../libgirepository-1.0.so: >> >> undefined reference to `g_malloc0_n' > > Sounds like your F13 transplant adventures might have trashed something > important. It certainly looks like it. Maybe it's time to yum update everything that is available to F13... >> In the end, I just gave up and did >> rpm -e DeviceKit-disks since I don't actually need it. Works fine now, >> but it looks like DeviceKit needs fixing. > > That part of DeviceKit became udisks in F15 rawhide (or maybe earlier) > anyway. Ah, OK. I'll try fighting that a bit later when I get more important things working. :) Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Alignment and dietlibc
Guys, it is as I suspected: Before building dietlibc (with my patches (posted to bugzilla), without which it won't build at all): User: 0 System: 1 Skipped:0 Half: 0 Word: 0 DWord: 1 Multi: 0 User faults:3 (fixup+warn) After building dietlibc and running it's test suite: User: 1012877 System: 1 Skipped:0 Half: 0 Word: 0 DWord: 1 Multi: 0 User faults:3 (fixup+warn) I don't think there can be any doubt any more about where the previos astronomically high number of misalignments came from. This also means that the chances of properly running dietlibc on ARM, at least with decent performance without hardware alignment fixing are pretty low. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
On 01/08/2011 02:49 AM, Chris Tyler wrote: > On Fri, 2011-01-07 at 20:23 +, Andy Green wrote: >> On 01/07/11 19:46, Somebody in the thread at some point said: >>> ..snip.. >>> > > This must be a bug in sha512sum -- it shouldn't be affected by alignment. I am inclined to think it might be compiler related. Andy's package is the same version as mine, his works, mine does not. The only thing that is likely to be different is the build environment. >>> >>> That and the development board. You are using a sheevaplug. >>> It is also likely that Andy's hardware does fixups for misaligned accesses. >> >> It's an NXP LPC3250, ARM926EJ-S. I have no idea if the hardware is >> handling the alignment issue but that would explain why everything is >> exactly zero on that box's alignment error stats. Searching the >> datasheet for 'alignment' doesn't tell anything relevant. > > As I understant it, the 'A' profile for armv7 includes mandatory > alignment fixup. Thus, if your CPU is armv7 it should do fixups in > hardware -- with cost, but transparent. Most armv5 does not appear to do > this. > > (Did the PHP 2.5*5 bug come up in this discussion? On a machine without > hardware fixup, PHP prints 5.3114652946464E-315 as the answer for 2.5*5 > with 0 in /proc/cpu/alignment, but prints 5 when fixups are enabled. > This seems to be a useful quick test). > > Related proposal: I think we should have the startup scripts > set /proc/cpu/alignment to 3 (warn+fixup) by default in Fedora-ARM (we > do this on the Koji builder image). I don't see a downside, and there's > a definite upside on armv5 systems. I see a number of downsides to this: 1) There is a performance hit. 2) It 's a workaround, not an actual fix. The code causing these problems should be fixed properly. I would like to offer a counter-proposal - no package is accepted into Fedora (ARM?) until it stops generating misalignment warnings. That way there might actually be some effort toward getting things fixed rather than just glazing over the problem. From what I can see, relatively few things in the base distribution do actually trip the problem (one exception being DeviceKit-disks package that I mentioned earlier - will file a bugzilla on that later). Additionally, in case things are missed in rudimentary pre-testing (and let's face it, they will be), alignment should be set to 1 (warn only), and these should be hooked into abrt so that bug reports can be auto-filed for all the broken packages (send the warnings, package version, and binary that caused the error). No packages showing up these should then be included in the next release until the problem is fixed. I cannot stress enough how strongly I am against the concept of glazing over the problem by setting alignment to 2 or 3. That's a short-term workaround, not a fix. And if it gets set as default that will never change again and a lot of the motivation and drive for a proper fix will go away. Crap solutions for the sake of paths of least resistance are not the way forward and should not be encouraged. I hope I'm not alone in this view. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
On 01/08/2011 10:02 AM, Jon Masters wrote: > On Sat, 2011-01-08 at 09:54 +0000, Gordan Bobic wrote: > >> I would like to offer a counter-proposal - no package is accepted into >> Fedora (ARM?) until it stops generating misalignment warnings. That way >> there might actually be some effort toward getting things fixed rather >> than just glazing over the problem. From what I can see, relatively few >> things in the base distribution do actually trip the problem (one >> exception being DeviceKit-disks package that I mentioned earlier - will >> file a bugzilla on that later). > > This proposal sounds far more reasonable, and it has the added benefit > that other similar architectures in future won't have to worry about > alignment biting - and besides, while ARMv7 is pretty much safe, there's > a lot of older stuff out there (ARMv4 is now officially deprecated, but > that leaves several other architecture revisions in current use). Not to mention that the performance hit is an issue - anything that makes everything go slower for the sake of fixing bugs in a few problematic packages is a very bad idea. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] uImage-2.6.30-sheevaplug is definitely broken
On 01/08/2011 05:20 PM, Chris Tyler wrote: > On Sat, 2011-01-08 at 12:28 +, Richard W.M. Jones wrote: >> Just a note to say that I'm having the precise same problem described >> here: >> >> http://lists.fedoraproject.org/pipermail/arm/2010-December/thread.html#786 >> >> 'Mojibake' after the kernel is uncompressed. No tty settings seem to >> fix it[*]. >> >> The wiki links to the uImage-2.6.30-sheevaplug image all over, but it >> is definitely broken either inherently or just with the latest >> SheevaPlug hardware. > > We should probably update these wiki links to point to a common 'ARM > Kernel' page, which we can then use as a trampoline to a > currently-recommended kernel or a collection of kernels, and later > change to point to an RPM-based kernel solution. Any takers for this bit > of wiki gardening? I do seem to remember running into this issue of the 2.6.30 kernel linked on the wiki. > (Speaking of kernels, I'm going to get a couple students looking at > doing RPM-based kernels for ARM this semester. Some things from primary > archs won't apply, e.g., updating grub boot menus -- I think ARM with > uBoot will probably need some ugly pieces like a hard link to the > "current" kernel, at least to start. I'd be careful with that. U-boot has a very tentative understanding of the ext2 file system. For example, I know for a fact that if you use block alignment mkfs parameters (-E stride=[blocks],stripe-width=[blocks]) it ceases to be able to handle it. I'm not sure if that includes any weirdness around hard-links. A straight copy might be safer. > We also need to do an inventory to > figure out the smallest number of kernels necessary to support common > hardware). If you're interested, I can provide you with a 2.6.36.2 .config I use that is designed to be used with minimal changes on the Sheeva Plug and the Toshiba AC100. I'm hoping I can get away with the only build change being the target hardware (Tegra 2 vs. Feroceon). Another thing worth mentioning that I've found is that the latest u-boot is a bit broken when handling high-speed MMC cards. With a normal no-name card it was fine, but with a high-speed SanDisk Class 10, it fails to initialize properly the first time, and the kernel load fails. The bodge solution I've applied is to run mmc_init twice - that makes it work, but it is probably something that needs fixing in uboot sooner rather than later. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] uImage-2.6.30-sheevaplug is definitely broken
On 01/08/2011 05:36 PM, Dan Horák wrote: > Chris Tyler píše v So 08. 01. 2011 v 12:20 -0500: >> On Sat, 2011-01-08 at 12:28 +, Richard W.M. Jones wrote: >>> Just a note to say that I'm having the precise same problem described >>> here: >>> >>> http://lists.fedoraproject.org/pipermail/arm/2010-December/thread.html#786 >>> >>> 'Mojibake' after the kernel is uncompressed. No tty settings seem to >>> fix it[*]. >>> >>> The wiki links to the uImage-2.6.30-sheevaplug image all over, but it >>> is definitely broken either inherently or just with the latest >>> SheevaPlug hardware. >> >> We should probably update these wiki links to point to a common 'ARM >> Kernel' page, which we can then use as a trampoline to a >> currently-recommended kernel or a collection of kernels, and later >> change to point to an RPM-based kernel solution. Any takers for this bit >> of wiki gardening? >> >> (Speaking of kernels, I'm going to get a couple students looking at >> doing RPM-based kernels for ARM this semester. Some things from primary >> archs won't apply, e.g., updating grub boot menus -- I think ARM with >> uBoot will probably need some ugly pieces like a hard link to the >> "current" kernel, at least to start. We also need to do an inventory to >> figure out the smallest number of kernels necessary to support common >> hardware). > > We have a student in Red Hat Brno who will work on RPM-based kernels as > his bachelor thesis and it should include an improvement in grubby to > use the flash-kernel utility > (https://bugzilla.redhat.com/show_bug.cgi?id=548422) Debian is > developing and using to actually flash the kernel to a supported range > of devices. We think the kernel installation workflow could be very > similar to the one used on x86. So what exactly do you do when the flashed kernel turns out to be broken and doesn't boot? It also sounds ill advised to be burning things that are supposed to get updated relatively frequently (kernels DO get updated) to non-replaceable flash. Keeping the kernel with the rest of the distro on the easily removable/replaceable flash media is probably a more reasonable long-term solution. Using built in flash is fine for embedded appliances that only see 1-2 updates/year, but not necessarily for bleeding edge desktop distributions like Fedora. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils / forcing alignment fixup and logging in initscripts
On 01/08/2011 11:10 AM, Jon Masters wrote: > On Sat, 2011-01-08 at 10:30 +, Andy Green wrote: >> On 01/08/11 09:54, Somebody in the thread at some point said: >>> On 01/08/2011 02:49 AM, Chris Tyler wrote: > >>> I would like to offer a counter-proposal - no package is accepted into >>> Fedora (ARM?) until it stops generating misalignment warnings. That way >> >> I think your proposal is a bad idea. > > FWIW I think you're talking at cross-purposes. There's no reason there > can't be a policy favoring stuff that doesn't generate miss-alignment > warnings (whether outright denial, or just some kind of part of package > reviews, and no reason this isn't a generic Fedora problem rather than > being ARM specific), have software like abrt pick it up, and still do a > fixup+warn setting in the kernel. You won't get silent breakage, and > you'll send a message that software needs to be fixed. Yup, exactly what Jon said. Such things need to be reported as bugs. Running with fixup should be something used only on development/test systems. It shouldn't be the norm for a live deployed system (and thus, implicitly, shouldn't be the norm for a stable distribution release). It must stop being acceptble for code to rely on this for correct functioning. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils / forcing alignment fixup and logging in initscripts
On 01/08/2011 11:14 AM, Andy Green wrote: > Having a policy that alignment faults should be avoided itself is fine, > but it is not a replacement for the good assertive action made by > changing the runtime policy. To some extent I agree. But the policy should be aimed toward finding and reporting these bugs, not toward glazing over the problem. To that end, I am in favour of setting alignment to 1 rather than 3 as default. > In fact I don't think we get to this point > with so few fixups unless that was already the general policy not just > here but in the upstreams. Any policy of not fixing things like this should arguably be grounds for excluding the package from the distribution. > When the initscripts set the runtime action to be fixup + log, those > faults will actually become more visible to everyone and help detection > and removal of faults overall. As I said, I was suggesting warn rather than fixup+warn for the extra pressure to get such things fixed. I definitely agree with increasing the visibility either way. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils / forcing alignment fixup and logging in initscripts
On 01/08/2011 11:37 AM, Jon Masters wrote: > On Sat, 2011-01-08 at 11:14 +, Andy Green wrote: >> On 01/08/11 11:10, Somebody in the thread at some point said: >>> On Sat, 2011-01-08 at 10:30 +, Andy Green wrote: On 01/08/11 09:54, Somebody in the thread at some point said: > On 01/08/2011 02:49 AM, Chris Tyler wrote: >>> > I would like to offer a counter-proposal - no package is accepted into > Fedora (ARM?) until it stops generating misalignment warnings. That way I think your proposal is a bad idea. >>> >>> FWIW I think you're talking at cross-purposes. There's no reason there >>> can't be a policy favoring stuff that doesn't generate miss-alignment >>> warnings (whether outright denial, or just some kind of part of package >>> reviews, and no reason this isn't a generic Fedora problem rather than >>> being ARM specific), have software like abrt pick it up, and still do a >>> fixup+warn setting in the kernel. You won't get silent breakage, and >>> you'll send a message that software needs to be fixed. >> >> As a "counter proposal" as it was introduced, instead of Chris' scheme, >> it's a bad idea. > > Agreed. It should be "in addition", not a counter proposal. See my argument for 1 vs 3. It's easy enough for the user to change this themselves, but defaults should be providing more pressure for fixing things, not less compare to the current default (0). >> Having a policy that alignment faults should be avoided itself is fine, >> but it is not a replacement for the good assertive action made by >> changing the runtime policy. In fact I don't think we get to this point >> with so few fixups unless that was already the general policy not just >> here but in the upstreams. > > I think that might be more luck than intention. A lot of stuff is being > developed on three main architectures that take care of miss-alignment. Maybe so, but that shouldn't be an excuse for not fixing this sort of thing, especially since ARM looks set to become much more popular as a desktop and server platform. >> When the initscripts set the runtime action to be fixup + log, those >> faults will actually become more visible to everyone and help detection >> and removal of faults overall. > > This is true. Warnings will motivate fixing stuff. Still, doesn't hurt > to have some kind of "policy" to promote this. I'm only really concerned > because none of the primary Fedora arches are bitten by this, so it's > easy for this to continue slipping under the radar. Agreed - and such a policy would probably benefit from not having the issue silently fixed. Silently fixing the issue at a performance penalty as a policy, taken to it's final logical conclusion, means that you might just as well just tell the user to run it in a qemu VM on x86. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] uImage-2.6.30-sheevaplug is definitely broken
On 01/08/2011 07:33 PM, Chris Tyler wrote: > On Sat, 2011-01-08 at 19:05 +0000, Gordan Bobic wrote: >> It also sounds ill advised to be burning things that are supposed to get >> updated relatively frequently (kernels DO get updated) to >> non-replaceable flash. Keeping the kernel with the rest of the distro on >> the easily removable/replaceable flash media is probably a more >> reasonable long-term solution. Using built in flash is fine for embedded >> appliances that only see 1-2 updates/year, but not necessarily for >> bleeding edge desktop distributions like Fedora. > > Well, there's a huge difference between putting / on NAND and the kernel > on NAND. Assuming just a 10,000-write-cycle durability, updating the > kernel every 3-4 days (100x/year) gives you 100 years of life. Assuming you actually get your 10,000 erase cycles out of it - and that is a big assumotion. I have seen a lot of consumer grade MLC flash fail after a few dozen erases (USB sticks, CF cards). In general, if it survives the first 20 or so I find it does last fine, but assuming that you will get 10,000 erase cycles out of it seems like an unnecessary risk when you will actually end up bricking the device permanently. An SD card, OTOH, is easy to replace. Advantages of keeping it on the same media as the rest of the distro include but are not limited to: 1) It makes the kernel image easily available and accessible without any additional magic. 2) It is what anybody who has used Fedora on a different distro will intuitively expect. 3) It makes sense to keep the kernel in the same place as /lib/modules, as the chances are that you won't get very far if they don't match, especially on a distro like Fedora where just about everything is a module. What are the percieved advantages of having the kernel image on built in nand? The only advantage is for devices that for some reason aren't supported by u-boot or another similar boot loader. AC100 is one such device, but u-boot support is being worked on. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils / forcing alignment fixup and logging in initscripts
On 01/08/2011 07:59 PM, Chris Tyler wrote:
> On Sat, 2011-01-08 at 19:27 +0000, Gordan Bobic wrote:
>> See my argument for 1 vs 3. It's easy enough for the user to change this
>> themselves, but defaults should be providing more pressure for fixing
>> things, not less compare to the current default (0).
>>
>>>> Having a policy that alignment faults should be avoided itself is fine,
>>>> but it is not a replacement for the good assertive action made by
>>>> changing the runtime policy. In fact I don't think we get to this point
>>>> with so few fixups unless that was already the general policy not just
>>>> here but in the upstreams.
>>>
>>> I think that might be more luck than intention. A lot of stuff is being
>>> developed on three main architectures that take care of miss-alignment.
>>
>> Maybe so, but that shouldn't be an excuse for not fixing this sort of
>> thing, especially since ARM looks set to become much more popular as a
>> desktop and server platform.
>>
>>>> When the initscripts set the runtime action to be fixup + log, those
>>>> faults will actually become more visible to everyone and help detection
>>>> and removal of faults overall.
>>>
>>> This is true. Warnings will motivate fixing stuff. Still, doesn't hurt
>>> to have some kind of "policy" to promote this. I'm only really concerned
>>> because none of the primary Fedora arches are bitten by this, so it's
>>> easy for this to continue slipping under the radar.
>>
>> Agreed - and such a policy would probably benefit from not having the
>> issue silently fixed. Silently fixing the issue at a performance penalty
>> as a policy, taken to it's final logical conclusion, means that you
>> might just as well just tell the user to run it in a qemu VM on x86.
>
> (1) I think we're agreed that silence (mode 0, ignore), the current
> default, is probably the worst possible value.
>
> (2) It's going to be really, really hard to [i] identify and [ii]
> convince upstreams to fix all alignment issues. Where alignment traps
> may be data-triggered, it will be nearly impossible to have confidence
> that all corner cases have been tested.
>
> I also think that it's unnecessary to eliminate all alignment issues --
> in many cases, kernel fixups may actually be cheaper to run than the
> defensive code necessary to avoid them, and hardware fixups are even
> cheaper. Furthermore, running on an armv7 or higher processor won't
> trigger the alignment traps at all, so we won't even know that there are
> issues (just as we don't know, nor care, in an x86 context).
It is plausible that defensively redesigned code may incur a similar
performance hit, but philosophically, we shouldn't be aiming for
complacency by just glazing over the issue and pretending it isn't an
issue. ARMv5 and ARMv6 are quite capable processors and are going to be
around for quite a while yet.
> Thus my recommendation that we warn and fix up the alignment, rather
> than warn and produce wrong results. (If you really want to force
> someone to deal with these issues, you'd want warn+signal, and I would
> strongly oppose making that the default).
I think we'll just have to agree to disagree on this, but it is probably
not that big a deal if things go the way you suspect it might (that
fixes will be forthcoming). There is, however, enough politics and
ego-waving in the software development world ("my software is fine, your
platform is broken") that I would rather take a hardline stance
initially and then relax it if necessary in compromise than compromise
pre-emptively and get nowhere as a result.
Gordan
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils / forcing alignment fixup and logging in initscripts
On 01/08/2011 08:04 PM, Chris Tyler wrote: > On Sat, 2011-01-08 at 14:59 -0500, Chris Tyler wrote: >> I also think that it's unnecessary to eliminate all alignment issues -- >> in many cases, kernel fixups may actually be cheaper to run than the >> defensive code necessary to avoid them, and hardware fixups are even >> cheaper. Furthermore, running on an armv7 or higher processor won't >> trigger the alignment traps at all, so we won't even know that there are >> issues (just as we don't know, nor care, in an x86 context). > > (Let me clarify that an app that's generating thousands of alignment > traps a second should get some attention! I'm talking about the more > typical case of a handful of traps a day). If it's only a handful per day, then that's a good argument for a fixup+signal - get the core dump so you can actually find out what the data that caused the problem was. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] DeviceKit-disks Alignment Errors (Was: Broken sha512sum in coreutils)
> On 01/07/2011 10:08 PM, Andy Green wrote: >>> In the end, I just gave up and did >>> rpm -e DeviceKit-disks since I don't actually need it. Works fine now, >>> but it looks like DeviceKit needs fixing. >> >> That part of DeviceKit became udisks in F15 rawhide (or maybe earlier) >> anyway. I just did a bit of digging and it turns out that DeviceKit-disks became udisks in F13. Yet, DeviceKit-disks is in the fedora-arm-koji repository that the F13 image uses. There is also no udisks package in the fedora-arm-koji repository. This probably needs fixing because there is no DeviceKit-disks in the released F13 distributions for other platforms. The udisks src.rpm package from F13 builds without any problems on the ARM build, but it still throws alignment errors. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils / forcing alignment fixup and logging in initscripts
On 01/09/2011 10:55 AM, Andy Green wrote: > On 01/08/11 19:59, Somebody in the thread at some point said: > >> (1) I think we're agreed that silence (mode 0, ignore), the current >> default, is probably the worst possible value. >> >> (2) It's going to be really, really hard to [i] identify and [ii] >> convince upstreams to fix all alignment issues. Where alignment traps >> may be data-triggered, it will be nearly impossible to have confidence >> that all corner cases have been tested. >> >> I also think that it's unnecessary to eliminate all alignment issues -- >> in many cases, kernel fixups may actually be cheaper to run than the >> defensive code necessary to avoid them, and hardware fixups are even >> cheaper. Furthermore, running on an armv7 or higher processor won't >> trigger the alignment traps at all, so we won't even know that there are >> issues (just as we don't know, nor care, in an x86 context). >> >> Thus my recommendation that we warn and fix up the alignment, rather >> than warn and produce wrong results. (If you really want to force >> someone to deal with these issues, you'd want warn+signal, and I would >> strongly oppose making that the default). > > Sounds right. The user is going to google why his log is filling with > these warnings if he cares and the problem is bad, and this covers his > code as well as distro code (with the small window where the alignment > policy is still 0 from running init through actually setting the > alignment policy to fix+log if he doesn't know about the kernel parameter). > > If he doesn't use Fedora initscripts, then he's at the mercy of the > kernel default alignment policy of "mangle data silently" but that's not > a Fedora problem. In can, however, see one good argument for warn+signal, and that is that abrt already picks up crashes for reporting so no change would be required there. Also a core dump would be useful to pin down the errors that aren't trivial to reproduce. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] uImage-2.6.30 / updating kernels on arbitrary boards
On 01/09/2011 11:18 AM, Andy Green wrote: > On 01/08/11 19:48, Somebody in the thread at some point said: >> On 01/08/2011 07:33 PM, Chris Tyler wrote: >>> On Sat, 2011-01-08 at 19:05 +, Gordan Bobic wrote: >>>> It also sounds ill advised to be burning things that are supposed to >>>> get >>>> updated relatively frequently (kernels DO get updated) to >>>> non-replaceable flash. Keeping the kernel with the rest of the >>>> distro on >>>> the easily removable/replaceable flash media is probably a more >>>> reasonable long-term solution. Using built in flash is fine for >>>> embedded >>>> appliances that only see 1-2 updates/year, but not necessarily for >>>> bleeding edge desktop distributions like Fedora. >>> >>> Well, there's a huge difference between putting / on NAND and the kernel >>> on NAND. Assuming just a 10,000-write-cycle durability, updating the >>> kernel every 3-4 days (100x/year) gives you 100 years of life. >> >> Assuming you actually get your 10,000 erase cycles out of it - and that >> is a big assumotion. I have seen a lot of consumer grade MLC flash fail >> after a few dozen erases (USB sticks, CF cards). In general, if it > > Actually with USB Sticks and CF cards you have no idea what you saw > "fail", since you are not talking to the flash directly, but through a > controller handling ECC and wear levelling. Sure, so the bad sector might actually move around, which makes it harder to detect. I have, however, seen an issue where some sectors simply will not accept further writes - the data always remains the same. > If in fact an erase sector going bad is the problem it should be swapped > out by the controller with a spare sector logically mapped in place of it. Most cheap CF/SD cards and USB sticks don't actually come with any spare sectors. > In the typical emebedded Linux case with raw NAND people are using jffs2 > or yaffs to take care of that, hiding individual sectors on the raw nand > from the filesystem. Except that flashing a kernel image to raw NAND won't be on top of yaffs. > Raw NAND is very ugly to work with, but with ECC and bad block lists and > remapping by the time Linux gets to see it as a block device it is fine > for updating the kernel how you like... otherwise just running the > rootfs would be so fragile it would all turn to crap in minutes and my > android phone with its many updates would be impractical ^^ Sure, but in that intensive an environment it'd be picked up well within the warranty period. :) And as I said, I don't think the discussion here was about having a kernel on a file system but on the raw NAND. > There is a variety of ways of storing the kernel in embedded systems > though, not always in /boot on the same filesystem as /. > > For example, I have done it myself with at least > > - stick it in RAW NAND at a magic offset after the bootloader > - stick it in Serial NOR flash at a magic offset after the bootloader > - stick it on its own VFAT partition on sd card > - stick it on the rootfs partition on sd card Sure - I always use a seaprate /boot partition, especially on flash media, because of the block alignment issues and bootloader issues. 1) The first partition loses 16KB, so everything after that is misaligned if you are trying to make thing optimal for erase block sizes > 16KB (and no consumer grade device I've heard of uses erase block sizes that small). Typically I align things to 512KB (mkfs.ext[234] -b 4096 -E stripe-width=128), except where the erase block size is known (IIRC Intel disks use 128KB erase blocks). > Also, it may not make sense to use an initrd in many cases, and if you > do use it you also have the problem of what to do with it to store it > accessibly to the bootloader. I don't that's more of a problem than with the kernel itself. Is it? > Maybe a plan is just have the kernel package stick it in /boot as usual, > and as part of its %post look for and if it exists run a script like > "local-kernel-update.sh" or whatever. It can copy the newly installed > kernel file down /boot using whatever means are appropriate for that > particular board. Personally I think just putting the kernel, initrd and boot.scr (for uboot) in /boot and having /boot on a separate partition is the way forward. The majority of ARM devices in use today seem to either be already well supported by uboot (Sheeva/Guru Plugs, Egika Genesi MX), or at least have rudimentary support that is being further worked on (Toshiba AC100). Can anyone think of any ARMv5 or later devices that have no uboot support and are unlikely to have uboot support in the future that would be plausible candidates for running Fedora on? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils / forcing alignment fixup and logging in initscripts
On 01/09/2011 12:29 PM, Andy Green wrote: > On 01/09/11 12:09, Somebody in the thread at some point said: > >>> Sounds right. The user is going to google why his log is filling with >>> these warnings if he cares and the problem is bad, and this covers his >>> code as well as distro code (with the small window where the alignment >>> policy is still 0 from running init through actually setting the >>> alignment policy to fix+log if he doesn't know about the kernel >>> parameter). >>> >>> If he doesn't use Fedora initscripts, then he's at the mercy of the >>> kernel default alignment policy of "mangle data silently" but that's not >>> a Fedora problem. >> >> In can, however, see one good argument for warn+signal, and that is that >> abrt already picks up crashes for reporting so no change would be >> required there. Also a core dump would be useful to pin down the errors >> that aren't trivial to reproduce. > > Signal is pretty violent if, for example, once in a blue moon even init > or sshd can blow an alignment fault for some reason. It'd be very > interesting to find it in the logs but less interesting to find your > embedded Fedora device at the bottom of the ocean can't be logged into > any more for no real reason. I understand your point, but we're talking about defaults here, not specialist defices that were deployed by people knowledgeable of what they are doing. Fedora is a development/testing distribution, no a production/stable/enterprise one. Whould there ever be a release of RHEL for ARM, then that should perhaps have alignment=3 as default, and perhaps Fedora should have alignment=5 as default. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] DeviceKit-disks Alignment Errors (Was: Broken sha512sum in coreutils)
On 01/09/2011 03:54 PM, Peter Robinson wrote: > On Sat, Jan 8, 2011 at 10:48 PM, Gordan Bobic wrote: >>> On 01/07/2011 10:08 PM, Andy Green wrote: >>>>> In the end, I just gave up and did >>>>> rpm -e DeviceKit-disks since I don't actually need it. Works fine now, >>>>> but it looks like DeviceKit needs fixing. >>>> >>>> That part of DeviceKit became udisks in F15 rawhide (or maybe earlier) >>>> anyway. >> >> I just did a bit of digging and it turns out that DeviceKit-disks became >> udisks in F13. Yet, DeviceKit-disks is in the fedora-arm-koji repository >> that the F13 image uses. There is also no udisks package in the >> fedora-arm-koji repository. This probably needs fixing because there is >> no DeviceKit-disks in the released F13 distributions for other platforms. >> >> The udisks src.rpm package from F13 builds without any problems on the >> ARM build, but it still throws alignment errors. > > The DeviceKit* packages have all been replaced and are obsolete. > DeviceKit-power has also been replaced by upower. I'm aware of that now, but as I said, udisks package has the exact same unaligned data access issues. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils / forcing alignment fixup and logging in initscripts
On 09/01/2011 17:15, omall...@msu.edu wrote: > Quoting Gordan Bobic: > >> On 01/09/2011 12:29 PM, Andy Green wrote: >>> On 01/09/11 12:09, Somebody in the thread at some point said: >>> >>>>> Sounds right. The user is going to google why his log is filling with >>>>> these warnings if he cares and the problem is bad, and this covers his >>>>> code as well as distro code (with the small window where the alignment >>>>> policy is still 0 from running init through actually setting the >>>>> alignment policy to fix+log if he doesn't know about the kernel >>>>> parameter). >>>>> >>>>> If he doesn't use Fedora initscripts, then he's at the mercy of the >>>>> kernel default alignment policy of "mangle data silently" but that's not >>>>> a Fedora problem. >>>> >>>> In can, however, see one good argument for warn+signal, and that is that >>>> abrt already picks up crashes for reporting so no change would be >>>> required there. Also a core dump would be useful to pin down the errors >>>> that aren't trivial to reproduce. >>> >>> Signal is pretty violent if, for example, once in a blue moon even init >>> or sshd can blow an alignment fault for some reason. It'd be very >>> interesting to find it in the logs but less interesting to find your >>> embedded Fedora device at the bottom of the ocean can't be logged into >>> any more for no real reason. >> >> I understand your point, but we're talking about defaults here, not >> specialist defices that were deployed by people knowledgeable of what >> they are doing. Fedora is a development/testing distribution, no a >> production/stable/enterprise one. Whould there ever be a release of RHEL >> for ARM, then that should perhaps have alignment=3 as default, and >> perhaps Fedora should have alignment=5 as default. > > What you are talking about is a Segfault release. like make rawhide, > alpha, beta, releases default to segfaults or at least proficiency log > and report accurately enough to be able to find the errors to be fixed. > > Then for the actual release change the default so they get fixed up. > We don't want to alienate people from the project and have it called > buggy because it keeps crashing. The buggyness would be the same. What we are debating there is buggy-and-crashing vs buggy-and-not-crashing. The correct solution to buggy software is bug free software. I'm not sure reducing the visibility of the problem is the way forward on a mainline following distribution. Anybody running Fedora should be aware that it is not a stable distribution, and shouldn't be used in production without extensive testing by the end user. That's not to say there's anything wrong with Fedora, but it really shouldn't be expected to "just work" for everyone. It never did, it never will, that is the nature of bleeding edge distributions. I just think it would be more useful WRT to actually producing a stable, bug free code base to optimize toward providing good, useful information for fixing things - and core dumps caused by unaligned data access would go further toward this than just fixing it up transparently and pretending it never happened. Having said that, I think what you suggested is a reasonable compromise (I know I'm unlikely to win this argument. ;) ) - until it is release, have the default set to warn+signal in rawhide and next/alpha/beta, and when it is cooked enough for a release, relax it to fixup+warn. Still, at this point, the warnings should be picked up by abrt. Which gets us to the next question - what configuration changes do we need for abrt for it to pick up the warnings and submit them to bugzilla? > Does Neon, vFPU or any other simd besides sse< 2, actually do > alignment fixups? > Can tree-autovec handle unaligned data? I don't think SIMD is possible on unaligned data. What you CAN do is loop peeling. Unroll the first few entries in the loop until the data aligns and then vectorize from then on. This is strictly a compile time thing, though. Note that from what I understand, this isn't an issue for compile time assigned structures (compiler sorts this out). The problem with unaligned access in otherwise OK code comes from user-data processing, e.g. if you have data in a buffer, you're scanning it, and find where what you're looking for starts, and then just set a pointer to the starting point, you have to make sure that that pointer aligns to a boundary. If it doesn't you'll get unaligned access and read in data that is truncated (mig
[fedora-arm] Alignment - proposed rc.sysinit patch and sysconfig file
Since we've been discussing it recently, how does this look? Attached are: patch against F13 /etc/rc.sysinit /etc/sysconfig/alignment It is the first thing that runs in rc.sysinit. Provided that bash, echo, uname and grep aren't having alignment issues, it should be OK. And if those were buggy we'd have much bigger problems. Comments? Gordan --- rc.sysinit.orig 2011-01-10 11:53:11.846625231 + +++ rc.sysinit 2011-01-10 12:00:41.358428301 + @@ -5,6 +5,15 @@ # Taken in part from Miquel van Smoorenburg's bcheckrc. # +if (uname -m | grep '^armv[0-9]' > /dev/null); then + . /etc/sysconfig/alignment + if [ -n "$ALIGNMENT" ]; then + if ( echo "$ALIGNMENT" | grep '^[0-5]$' > /dev/null ); then + echo $ALIGNMENT > /proc/cpu/alignment + fi + fi +fi + HOSTNAME=$(/bin/hostname) set -m # Default alignment setting for ARM CPUs. # 0 - ignore unaligned accesses silently (kernel's default policy) # 1 - warn on unaligned accesses in kernel log # 2 - fixup unaligned accesses silently # 3 - fixup+warn on unaligned accesses # 4 - signal on unaligned accesses (core dump the offending program) # 5 - signal+warn on unaligned accesses ALIGNMENT=3 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Broken sha512sum in coreutils
Chris Tyler wrote: > (Did the PHP 2.5*5 bug come up in this discussion? On a machine without > hardware fixup, PHP prints 5.3114652946464E-315 as the answer for 2.5*5 > with 0 in /proc/cpu/alignment, but prints 5 when fixups are enabled. > This seems to be a useful quick test). I just tried this on the Sheevaplug, and I cannot reproduce it on the F13's build of PHP: # uname -a Linux sheeva 2.6.36.2-vs2.3.0.36.38.2-kw #1 Fri Jan 7 19:15:14 GMT 2011 armv5tel armv5tel armv5tel GNU/Linux # rpm -qa | grep php php-cli-5.3.1-2.fc13.armv5tel php-common-5.3.1-2.fc13.armv5tel php-5.3.1-2.fc13.armv5tel # cat test.php # php test.php 12.5 No warnings of alignment mismatch. Has this been fixed upstream or only in Fedora? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] New Packages and Policy Questions
I have a question on policies of how and whether Fedora-ARM patches are rolled back into rawhide. The reason I ask is because I see overlap between the required ARM specific patches between F11 and F12. What is the policy for rolling these patches back into upstream and (more importantly in case upstream is slow/reluctant to accept them) rawhide? Also, what is the policy on new packages? Specifically, I found myself in need of openssl098k compatibility package (need to run some binaries from F11). This is pretty trivial to come up with (change the package name from openssl-0.9.8k to openssl098k-0.9.8k in the spec file and re-tar the openssl tar ball to extract to openssl098k-0.9.8k directory instead of openssl-0.9.8k directory), but what I wanted to ask if whether there is some kind of a policy for including things like this in the main distro. It is likely that this would be useful to other people who are less willing/able to roll their own packages. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] New Packages and Policy Questions
Peter Robinson wrote: > On Thu, Jan 13, 2011 at 10:22 AM, Gordan Bobic wrote: >> I have a question on policies of how and whether Fedora-ARM patches are >> rolled back into rawhide. The reason I ask is because I see overlap >> between the required ARM specific patches between F11 and F12. What is >> the policy for rolling these patches back into upstream and (more >> importantly in case upstream is slow/reluctant to accept them) rawhide? > > In a lot of cases the people dealing with the issues have the ability > to commit the fixes themselves so as to be able to push them directly > upstream where necessary. Is there a formal procedure for that? My concern is that this process doesn't seem to work out in a timely and positive fashion in a significant number of cases (otherwise we wouldn't have that big a required patch overlap between Fedora releases on ARM). >> Also, what is the policy on new packages? Specifically, I found myself >> in need of openssl098k compatibility package (need to run some binaries >> from F11). This is pretty trivial to come up with (change the package >> name from openssl-0.9.8k to openssl098k-0.9.8k in the spec file and >> re-tar the openssl tar ball to extract to openssl098k-0.9.8k directory >> instead of openssl-0.9.8k directory), but what I wanted to ask if >> whether there is some kind of a policy for including things like this in >> the main distro. It is likely that this would be useful to other people >> who are less willing/able to roll their own packages. > > The policy on new packages is that they have to be in upstream Fedora. How does one get a package into upstream Fedora? Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] New Packages and Policy Questions
On 01/13/2011 02:35 PM, omall...@msu.edu wrote: Also, what is the policy on new packages? Specifically, I found myself in need of openssl098k compatibility package (need to run some binaries from F11). This is pretty trivial to come up with (change the package name from openssl-0.9.8k to openssl098k-0.9.8k in the spec file and re-tar the openssl tar ball to extract to openssl098k-0.9.8k directory instead of openssl-0.9.8k directory), but what I wanted to ask if whether there is some kind of a policy for including things like this in the main distro. It is likely that this would be useful to other people who are less willing/able to roll their own packages. > > Will your packages compile against openssl 1.0.0x? The package in question won't compile at all on F13, it seems: # rpmbuild --rebuild xorg-x11-server-1.6.1.901-1.fc11.src.rpm ... libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../include -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -DDBUS_API_SUBJECT_TO_CHANGE -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../include -I../include -I../Xext -I../composite -I../damageext -I../xfixes -I../Xi -I../mi -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb "-DVENDOR_NAME=\"The X.Org Foundation\"" "-DVENDOR_RELEASE=(((1) * 1000) + ((6) * 10) + ((1) * 1000) + 901)" -O2 -g -march=armv5te -Wstrict-overflow -rdynamic -c dispatch.c -fPIC -DPIC -o .libs/dispatch.o In file included from ../Xext/panoramiX.h:44, from dispatch.c:134: /usr/include/X11/extensions/panoramiXext.h:49: error: expected ')' before '*' token /usr/include/X11/extensions/panoramiXext.h:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XPanoramiXQueryVersion' /usr/include/X11/extensions/panoramiXext.h:64: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XPanoramiXGetState' /usr/include/X11/extensions/panoramiXext.h:70: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XPanoramiXGetScreenCount' /usr/include/X11/extensions/panoramiXext.h:76: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XPanoramiXGetScreenSize' make[2]: *** [dispatch.lo] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/xorg-server-1.6.1.901/dix' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/xorg-server-1.6.1.901/dix' make: *** [all-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.dnujZU (%build) Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] New Packages and Policy Questions
Andy Green wrote: > On 01/13/11 21:45, Somebody in the thread at some point said: > >> The package in question won't compile at all on F13, it seems: >> >> # rpmbuild --rebuild xorg-x11-server-1.6.1.901-1.fc11.src.rpm > > I don't know what the actual problem is from the error, but are all the > dependencies in that filesystem also f11-vintage? If everything else > down /usr/include is f13-vintage, it's quite possible f11 sources or > spec might choke on considerably newer dependent includes. Most of the system is the F13 rawhide. It's yum updated from the F12 release since an awful lot in the F13 alpha is still missing or broken (e.g. firefox). So there are still a number of F12 vintage packages that aren't in the koji repository yet. Interestingly, F11 libxinerama packages that contain the headers where the compile breaks don't even include those header files. > What're you trying to achieve by recooking f11 xorg server on f13? Maybe > there's a different way to come at your overall goal. I very much doubt it. The machine I'm working on is a Toshiba AC100. The only kernel available for it with working keyboard/mouse support is 2.6.29 provided by Toshiba as part of the open source code they wrote for Android (the machine comes pre-loaded with Android). Unfortunately, Toshiba have in their infinite wisdom decided to put the keyboard and mouse behind proprietary interfaces, rather than USB HID (the machine does have full featured master and slave USB, which makes the decision particularly retarded). The drivers haven't yet been ported to later kernels. Further, the only way to eccelerated graphics on it is using the nvidia closed source tegra xorg driver. Since only 2.6.29 kernel works, only the tegra driver that is compatible with the interface of the kernel module for 2.6.29 works. That driver is sufficiently old that it is based on the xorg ABI from version 1.6.x, i.e. of the F11 vintage. That means that the only way to get accelerated drivers is using the 2.6.29 kernel and Xorg 1.6. Xorg binaries from F11 require libssl.so.8 which means openssl 0.9.8k. F11 xorg src.rpm won't build on F12/F13, as explained earlier. I put just the three libraries it depends on in the relevant places, and that works fine, but by far the easiest way to solve this problem would be using an openssl098k compatibility package. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] New Packages and Policy Questions
Peter Robinson wrote: >> >> The package in question won't compile at all on F13, it seems: >> >> >> >> # rpmbuild --rebuild xorg-x11-server-1.6.1.901-1.fc11.src.rpm >> > >> > I don't know what the actual problem is from the error, but are all the >> > dependencies in that filesystem also f11-vintage? If everything else >> > down /usr/include is f13-vintage, it's quite possible f11 sources or >> > spec might choke on considerably newer dependent includes. >> >> Most of the system is the F13 rawhide. It's yum updated from the F12 >> release since an awful lot in the F13 alpha is still missing or broken >> (e.g. firefox). So there are still a number of F12 vintage packages that >> aren't in the koji repository yet. >> >> Interestingly, F11 libxinerama packages that contain the headers where >> the compile breaks don't even include those header files. > > fbdev works fine for me for the AC100, I don't think its accelerated > but it auto detects and just works, not had enough time to play with > it further and see what works and what doesn't. Indeed, I'm aware that fbdev just works. Ironically, the "accelerated" driver doesn't support most of the useful acceleration APIs (e.g. XV). It only supports GL ES. If I understood what I read in the mailing list archives correctly, Mesa as of recently has support for implementing a full GL API based on GL ES APIs. But as far as I can tell, that version of Mesa isn't in F13. The accelerated driver also has some interesting dependencies (kernel module and a userspace daemon). It's also not as reliable and can cause a few other quirks (e.g. random case of caps lock being stuck on and the only cure I've found is a reboot). Plus, text mode console switch no longer works one you get into X. There was, however, some success recently in getting one of acceleration APIs working with mplayer, based on hardware acceleration of the Tegra. Are you on the AC100 IRC channel? >> > What're you trying to achieve by recooking f11 xorg server on f13? Maybe >> > there's a different way to come at your overall goal. >> >> I very much doubt it. The machine I'm working on is a Toshiba AC100. The >> only kernel available for it with working keyboard/mouse support is >> 2.6.29 provided by Toshiba as part of the open source code they wrote >> for Android (the machine comes pre-loaded with Android). Unfortunately, >> Toshiba have in their infinite wisdom decided to put the keyboard and >> mouse behind proprietary interfaces, rather than USB HID (the machine >> does have full featured master and slave USB, which makes the decision >> particularly retarded). The drivers haven't yet been ported to later >> kernels. > > Interesting, I'm looking at this closer as I have one of these devices > myself. The keyboard/mouse reports its attached to the old style ps2 > keyboard/mouse interfaces. AFAIK they are attached to the NvEc interfaces. One of the people on the mailing list was working on getting these to work on a more recent kernel, but with limited success so far - it isn't as trivial as one might hope. There is some hope that Toshiba will provide Android 2.2 for the AC100 in the near future which should come, in theory, with a 2.6.32.x kernel, which will hopefully make things a little easier for us WRT nvidia driver compatibility, but Toshiba's interest in supporting the AC100 seems to be diminishing by the day. >> Further, the only way to eccelerated graphics on it is using the nvidia >> closed source tegra xorg driver. Since only 2.6.29 kernel works, only >> the tegra driver that is compatible with the interface of the kernel >> module for 2.6.29 works. That driver is sufficiently old that it is >> based on the xorg ABI from version 1.6.x, i.e. of the F11 vintage. > > Works fine with the fbdev on the 2.6.29 kernel using the F-13 and the > fbdev X driver. In the 2.6.37 and already pending for the .38 series > there's been a lot of tegra drivers make it to the mainline kernel so > it will be interesting to see what's missing / remaining / different > on the toshiba side of development. As I said, last I checked the keyboard/mouse didn't work with newer kernels at the moment, and carrying an USB mouse/keyboard isn't really an acceptable solution for a netbook. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] New Packages and Policy Questions
Peter Robinson wrote: >> Thus, the only kernel module for the Tegra driver that can be used is also >> the same one. >> >> The Nvidia Tegra driver that is old enough to have a compatible interface >> with the kernel driver only has Xorg ABI 5, which means it won't work on >> Fedora versions later than F11. > > hmm. > >> So, I have to have Xorg and associated drivers from F11 in order to get >> accelerated graphics working on this machine. > > What X driver do you use for accel X? The one bundled with the oldest downloadable L4T distribution from nvidia. I think this is the same as what is bundled in a rootfs tarball one of he other guys on the IRC channel cooled up (look for Ubuntu5.tar.lzma, IIRC). This is the only known version to work on the AC100. Note that you will also need nvrm_daemon, the kernel module, and a few dependencies for those. >> Xorg binary links against libssl.so.8/libcrypto.so.8, which means it >> requires openssl 0.9.8k, so the simplest solution is binaries from F11 for >> Xorg with the openssl098k compatibility package. > > Yea, I don't think you'll get that into Fedora mainline primarily > because openssl inherently has security issues. AFAIK, security issues get patches while remaining major version compatibility and APIs. >> While I'm sure the old Xorg could be compiled up for F13, building it would >> probably lead to dependency hell on a Fedora 2 versions newer. Using the old >> binaries seems a lot less intrusive at a glance. > > Can you link to where you get the X drivers etc from. I'm going to be > looking at this more closely. Have a look here: http://gitorious.org/ac100/pages/Installation The Ubuntu5 tar ball has everything you will need in it. > With luck the problem of older kernels > should disappear for most of the issues before long as the CE industry > is moving towards standardising on 2.6.35.x for their kernel so nvidia > I suspect will be already in process of upgrading to this as its > what's needed for Honeycomb tablets and the like. As to when the > source is released though is anyones guess. The problem isn't with the nvidia L4T, the problem is that Toshiba chose to use a really obscure interface for the keyboard and mouse in this machine. This also isn't the full extent of the obscure sabotages/boobytraps that Toshiba have performed on this model. I recently tried upgrading the TFT panel in it, and it looks like they implemented an intercept and override of EDID coming from the panel to always report 1024x600, but even if you override the modeline in xorg.conf (note: this only makes sense when using the accelerated tegra driver, not fbdev, as fbdev isn't actually a fully implemented mode switch-capable driver on the AC100), instead of using the mode as provided. Worse, something will intercept the mode provided when ignoring EDID, and scale the image down to 1024x600, rather than using the full screen. If you put in a higher-res panel, it will never use more than the 1024x600 area in the top left of the panel. Whether the sabotage in question is out of lazyness, incompetencec or malice I don't know, but so far I'm pretty convinced that getting anything except 1024x600 to work is going to be sufficiently difficult to not be worth the effort without detailed explanation and specifications of this "feature" from Toshiba. Needless to say, the input from nvidia forums on non-trivial issues like this has been predictably non-existant. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] New Packages and Policy Questions
Peter Robinson wrote: >> Plus, text mode console switch no longer works one you get into X. >> >> There was, however, some success recently in getting one of acceleration >> APIs working with mplayer, based on hardware acceleration of the Tegra. >> >> Are you on the AC100 IRC channel? > > No (not sure what it is) but I am on #fedora-arm and #fedora-mobility Try #ac100 on freenode. The people there are quite helpful. Just /ignore the occasional Atom troll(s?). ;) > What're you trying to achieve by recooking f11 xorg server on f13? Maybe > there's a different way to come at your overall goal. I very much doubt it. The machine I'm working on is a Toshiba AC100. The only kernel available for it with working keyboard/mouse support is 2.6.29 provided by Toshiba as part of the open source code they wrote for Android (the machine comes pre-loaded with Android). Unfortunately, Toshiba have in their infinite wisdom decided to put the keyboard and mouse behind proprietary interfaces, rather than USB HID (the machine does have full featured master and slave USB, which makes the decision particularly retarded). The drivers haven't yet been ported to later kernels. >>> Interesting, I'm looking at this closer as I have one of these devices >>> myself. The keyboard/mouse reports its attached to the old style ps2 >>> keyboard/mouse interfaces. >> AFAIK they are attached to the NvEc interfaces. One of the people on the >> mailing list was working on getting these to work on a more recent >> kernel, but with limited success so far - it isn't as trivial as one >> might hope. >> >> There is some hope that Toshiba will provide Android 2.2 for the AC100 >> in the near future which should come, in theory, with a 2.6.32.x kernel, >> which will hopefully make things a little easier for us WRT nvidia >> driver compatibility, but Toshiba's interest in supporting the AC100 >> seems to be diminishing by the day. > > Well there was an update to the toshiba update utility this week so > with luck that's the prep for 2.2, then someone will need to chase > them for that code drop. In fairness, they were reasonably OK WRT providing the GPL based code so far. I certainly hope the update will be arriving soon - it would make life a lot easier with a few things. Further, the only way to eccelerated graphics on it is using the nvidia closed source tegra xorg driver. Since only 2.6.29 kernel works, only the tegra driver that is compatible with the interface of the kernel module for 2.6.29 works. That driver is sufficiently old that it is based on the xorg ABI from version 1.6.x, i.e. of the F11 vintage. >>> Works fine with the fbdev on the 2.6.29 kernel using the F-13 and the >>> fbdev X driver. In the 2.6.37 and already pending for the .38 series >>> there's been a lot of tegra drivers make it to the mainline kernel so >>> it will be interesting to see what's missing / remaining / different >>> on the toshiba side of development. >> As I said, last I checked the keyboard/mouse didn't work with newer >> kernels at the moment, and carrying an USB mouse/keyboard isn't really >> an acceptable solution for a netbook. > > Nope, and esp with only one usb port. That's really a negligible problem relative to the rest - a number of keyboards come with a built in USB hub with an extra port. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Trying to run Fedora-ARM as a virtual machine
On 29/01/2011 17:05, Niels de Vos wrote: > Hi there! > > I'm looking into getting an ARM system as small home-server. Of course > I'd like to run Fedora on it, but unfortunately it seems that current > Fedora releases are not completely ready for this yet. It's probably ready enough. F12 is the stable one, and F13 alpha rootfs is available. A few things are missing (a few important KDE parts, but they do build OK on F12), and a few things are broken and unstable (Firefox of the F12 vintage isn't of generically good enough quality to handle bug-free running on ARM), but overall it's more than usable enough. I run a F12/F13 hybrid (F12 rootfs yum updated to F13 alpha from the koji repository where packages update cleanly) on my Sheevaplug (Kirkwood ARMv5) and on my Toshiba AC100 (Tegra 2 ARMv7), and they work quite well - certainly well enough for any common server tasks. You may want to check the archives and sign up to the redhat bugzilla where bugs are tracked. I submitted a patch recently to add a feature to rc.sysinit that changes the default kernel behaviour about alignment errors. I suggest you apply it and set the default to fix+warn and file bugzilla reports for all the apps that cause these warnings. Here's a direct link to the bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=673691 > I'd like to help with this, and as a start I am trying to get a fully > functioning VM up and running. Obviously there are issues to overcome > with this too. Many thanks for documenting the issues in the wiki! > Before I decide to buy myself a Pandaboard or similar, I'd like to get > some more experience with Fedora on ARM. My first personal project > will be getting libvirt work with ARM out of the box. I hope that this > attracts some more interested parties and lowers the barrier for > contributions. I'd suggest starting with something self-contained and well supported, such as the Sheevaplug. It's quite speedy (not as fast as the Pandaboard, but fast enough and better for development because it's ARMv5, which means you'll get to see the alignment errors when they occur rather than them being silently fixed up. Better for testing, IMO. I have a Mk1 Sheevaplug and it's quite well supported by the community. > While I am checking the details of qemu and libvirt, I am wondering if > there is a kernel available that has virtio support. If not, I will > need to compile my own kernel, which feels a little silly. > https://arm.koji.fedoraproject.org does only seem to have one kernel > package available, and that is kernel-headers which I hardly can use > for booting. I am wondering if there are any scratch-builds available > that have a functioning vmlinz. You will almost certainly need to build your own kernel anyway, because kernels on ARM are pretty CPU specific. While it has recently been mentioned that there is a project underway to provide a small-ish set of kernels to try to cover a majority of popular ARM devices, right now you will almost certainly want to build your own kernel. ARM emulation using qemu on x86 is OK for minor things to begin with, but performance is quite crippling. As for development on ARM and virtualization - I suggest you look at Linux vserver. I have it pretty much working, but there are a couple of bugs in the tools stemming from the fact that dietlibc isn't quite bug free on ARM yet, but it's getting close (see this bug: https://bugzilla.redhat.com/show_bug.cgi?id=667852 ) That means that you'll have to create your /etc/vserver entries for the VMs manually, but it's not that hard, and I can provide you with some working examples if you decide to go that way. libvirt/qemu on ARM may be too slow for any sensible work - I am not sure what the status with KVM is on ARM, but I wouldn't bet on it working on most (if any) ARM hardware. Vserver, OTOH, comes with just about no overhead at all, if you want a jail for testing and developing things. Of course, this assumes you already have an ARM device already set up and working. > Furthermore I'd like to know what the best way is to follow the status > of the current ARM builds, and where to find out where help is most > needed? This list and the RedHat bugzilla are a good place to start. :) Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Trying to run Fedora-ARM as a virtual machine
On 31/01/2011 21:03, Niels de Vos wrote: >>> I'm looking into getting an ARM system as small home-server. Of course >>> I'd like to run Fedora on it, but unfortunately it seems that current >>> Fedora releases are not completely ready for this yet. >> >> It's probably ready enough. F12 is the stable one, and F13 alpha rootfs >> is available. A few things are missing (a few important KDE parts, but >> they do build OK on F12), and a few things are broken and unstable >> (Firefox of the F12 vintage isn't of generically good enough quality to >> handle bug-free running on ARM), but overall it's more than usable >> enough. I run a F12/F13 hybrid (F12 rootfs yum updated to F13 alpha from >> the koji repository where packages update cleanly) on my Sheevaplug >> (Kirkwood ARMv5) and on my Toshiba AC100 (Tegra 2 ARMv7), and they work >> quite well - certainly well enough for any common server tasks. >> >> You may want to check the archives and sign up to the redhat bugzilla >> where bugs are tracked. I submitted a patch recently to add a feature to >> rc.sysinit that changes the default kernel behaviour about alignment >> errors. I suggest you apply it and set the default to fix+warn and file >> bugzilla reports for all the apps that cause these warnings. >> >> Here's a direct link to the bugzilla report: >> https://bugzilla.redhat.com/show_bug.cgi?id=673691 > > Cool! I'm complete unaware what makes ARM a special architecture, so > this is quite interesting. I've added some notes/thoughts to the bug, > maybe it helps to get it included ;) Thanks. I won't hold my breath for it, though. :) >>> While I am checking the details of qemu and libvirt, I am wondering if >>> there is a kernel available that has virtio support. If not, I will >>> need to compile my own kernel, which feels a little silly. >>> https://arm.koji.fedoraproject.org does only seem to have one kernel >>> package available, and that is kernel-headers which I hardly can use >>> for booting. I am wondering if there are any scratch-builds available >>> that have a functioning vmlinz. >> >> You will almost certainly need to build your own kernel anyway, because >> kernels on ARM are pretty CPU specific. While it has recently been >> mentioned that there is a project underway to provide a small-ish set of >> kernels to try to cover a majority of popular ARM devices, right now you >> will almost certainly want to build your own kernel. > > Hmm, thats good to know. I was just hoping that there is something > like a general basic arm kernel with all the modules, which boots on > most boards, but would run sub-optimal. No such thing at the moment. If you look through the kernel configuration options, there is no "generic" option - you have to select pretty specifically what you want it to run on, and there's no multi-choice on CPU selection. >> ARM emulation using qemu on x86 is OK for minor things to begin with, >> but performance is quite crippling. >> >> As for development on ARM and virtualization - I suggest you look at >> Linux vserver. I have it pretty much working, but there are a couple of >> bugs in the tools stemming from the fact that dietlibc isn't quite bug >> free on ARM yet, but it's getting close (see this bug: >> https://bugzilla.redhat.com/show_bug.cgi?id=667852 ) > > Well, my laptop runs libvirt and I m quite happy with that. I'll stick > with libvirt/qemu as that does not interfere with my 'production' VMs. > > Maybe you understood my question wrong... Gol i to do some > development/tests on my x86_64 laptop, and then run the resulting > packages on the hardware ARM. I get it, but ARM emulated on x86 will run at a tiny fraction of native speed. You may well find it completely unusable. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Trying to run Fedora-ARM as a virtual machine
On 31/01/2011 21:45, omall...@msu.edu wrote: ARM emulation using qemu on x86 is OK for minor things to begin with, but performance is quite crippling. As for development on ARM and virtualization - I suggest you look at Linux vserver. I have it pretty much working, but there are a couple of bugs in the tools stemming from the fact that dietlibc isn't quite bug free on ARM yet, but it's getting close (see this bug: https://bugzilla.redhat.com/show_bug.cgi?id=667852 ) >>> >>> Well, my laptop runs libvirt and I m quite happy with that. I'll stick >>> with libvirt/qemu as that does not interfere with my 'production' VMs. >>> >>> Maybe you understood my question wrong... Gol i to do some >>> development/tests on my x86_64 laptop, and then run the resulting >>> packages on the hardware ARM. >> >> I get it, but ARM emulated on x86 will run at a tiny fraction of native >> speed. You may well find it completely unusable. > > It is very slow compared to real hardware. However, some of the > performance issue is the fact the default kernel and the default board > only uses 128M of ram at least in F12. > > Also, iirc we didn't find any alignment errors with the qemu-arm test. The emulation probably transparently fixes them. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] 1ghz ARM Laptop (12in 1280x800 LCD)
On 31/01/2011 21:51, Luke Kenneth Casson Leighton wrote: > folks, hi, > > i'm contacting people on all of the ARM linux distribution lists to > find out if anyone is interested in bringing about the creation of a > decent, useful and useable ARM-based Laptop. i've been researching > CPUs and how to go about this with a minimum of risk and cost, > learning from the experiences of the openpandora for example. all of > the enquiries that i've made, for about a year, all point towards a > minimum spec of at least a 1ghz CPU, 1gb of RAM and a 12in screen > (below those specs is too little, and above them is too costly). does > such a machine exist? in one word: no. there are plenty of machines > with 1024x600 screens (the toshiba AC100, the Genesi-USA Ekiga and the > AlwaysInnovating Touchbook) - i wish them every success in their niche > markets that are catered for by 1024x600 screens. Genesi Efika MX can take a 1280x720 screen. I've had Genesi confirm this and I'll be fitting it as soon as my Efika MX is back (sent off for a repair). > for everyone else, who wants to see full documents and full web pages > *without* having to press page-up, page-down, there literally is not a > single ARM-based (or MIPS-based) product in existence, commercially > available, anywhere in the world, despite a lot of talk from ARM, and > also from the major ARM licensees, and despite the production cost of > ARM-based and MIPS-based laptops being lower than that of an > equivalent intel-based system. You'd be forgiven for not noticing the difference. Genesi Efika MX and Toshiba AC100 both cost me as much as a similarly specced Atom netbook. They just have 2-4x the battery life and 1/2 the weight and thickness, no moving parts (especially fans), etc. > so the question i have, for the people on this list is: given that > nobody else is taking any initiative, would _you_ like to be part of a > project that takes the initiative to create a low-cost, high-end > ARM-based laptop? like the OpenPandora, except... done with far less > risk and a lot less cost. one absolute key part in reducing risk and > cost is to utilise existing casework from a no-brand OEM laptop. all > that's then required is to create the motherboard to fit. more info > here: > > http://lkcl.net/laptop.html > > a rough guide i've received from a chinese embedded systems designer > is that a design using a Samsung S5PV210 will be about $USD 10,000, > and a design using a TI DM3730 or DM3725 will be about $20,000 (TI's > CPUs are a bit more complex, and the DM37xx series is newer than > Samsung's S5 range)... but that's *it*. that's all it costs, to > create the motherboard for fitting into an existing 12in laptop > chassis. excluding a DVD or Hard Drive, the BOM (Bill of Materials) > will come to somewhere around $150, which translates loosely into $240 > to $300 after tax, customs, shipping etc. etc. > > i'm still investigating ways to get that price down even further, and > i'm really really interested to hear from people who may know of other > CPUs. i've just heard today about the ZMS-08 for example, and > creativelabs have a SoM (system-on-module) which sounds like a perfect > fit: the only bug-bear being the proprietary libraries and > creativelab's fear over being swamped by developer wannabes asking for > help on how to program one of the most complex Cell Processor Units in > existence outside of IBM's and other obscure labs. the proprietary > libraries aren't so much the problem as the lack of documentation on > the Cell Processor. > > so - please do discuss amongst yourselves, or feel free to contact me > directly. i'm maintaining a list of links to all the other forums > this is going out on, at the bottom of http://lkcl.net/laptop.html - > if you would like to recommend an alternative CPU please do review > and/or edit http://libreplanet.org/wiki/Group:Hardware/Processors > first (either the page itself or the discussion page). Funnily enough, I was thinking about something very similar to this just yesterday. My thoughts are as follows: - Chassis I was was actually pondering using an existing Clevo chassis. I thought about using an M860TU because that has a 1920x1200 (15.4in) screen available, but this is unfortunately only available with a fluorescent backlight. That means inverters for the backlight and high power consumption. So now I am pondering using a slightly newer yet very similar W860CU. That is available with a 1920x1080 LED backlit panel (15.6in). It wouldn't make much sense to use a higher drain screen when low power is a key part of the appeal. Looking at my M860TU, any suitably small motherboard could be made to fit with a bit of cutting and gluing, and I expect a W860CU would be similar. There is loads of space available in these machines, and they were designed to be easy to work on rather than compact. This makes them lend themselves well to prototyping. - Motherboard I cannot emphasise enough th
Re: [fedora-arm] 1ghz ARM Laptop (12in 1280x800 LCD)
Luke Kenneth Casson Leighton wrote: > On Mon, Jan 31, 2011 at 10:25 PM, Gordan Bobic wrote: > >>> with 1024x600 screens (the toshiba AC100, the Genesi-USA Ekiga and the >>> AlwaysInnovating Touchbook) - i wish them every success in their niche >>> markets that are catered for by 1024x600 screens. >> Genesi Efika MX can take a 1280x720 screen. > > really? hoooraaay! wow, wow, and they cost about... $50 instead of > $30. i so don't understand why these aren't fitted as standard. > still, bless 'em. 10in LCD, 800mhz CPU and 512mb RAM - it's... > pushing your luck as a "main development machine"... I, too, am puzzled by the choice of a low res screen. I suspect the reasons are: 1) $20 extra profit per machine is noticeable and/or reduced sales from a price tag of an extra $20 would be noticeable. The Efika MX Smartbook is already $350 which is quite expensive for a netbook. 2) Most people (the average users - I am not talking about the present audience of geeks who know what they are doing) simply expect a netbook to have a 9-10in panel that is 1024x600. Not out of technical merit, but because that's what all the ones you'll see at a shop will have. As for "main development machine" - even 1366x768 would be pushing it for development. I wouldn't consider anything lower res than 1920x1080 to be suitable for a dev machine nowdays. My main work laptop is 2048x1536 (homebrew Thinkpad with a non-standard screen, google about it to get details on what to do and how if you're interested), but that panel is out of production and hard to get hold of at the moment, and it's fluorescent backlit, which means a >= 15W power budget just for the screen. :'( Then again, 15W is less than 1/2 of the power draw at idle when you have the rest of a Core2 system to keep powered up. >>> for everyone else, who wants to see full documents and full web pages >>> *without* having to press page-up, page-down, there literally is not a >>> single ARM-based (or MIPS-based) product in existence, commercially >>> available, anywhere in the world, despite a lot of talk from ARM, and >>> also from the major ARM licensees, and despite the production cost of >>> ARM-based and MIPS-based laptops being lower than that of an >>> equivalent intel-based system. >> You'd be forgiven for not noticing the difference. Genesi Efika MX and >> Toshiba AC100 both cost me as much as a similarly specced Atom netbook. They >> just have 2-4x the battery life and 1/2 the weight and thickness, no moving >> parts (especially fans), etc. > > i know, damnit!!! and the OLPC XO-1.75, which admittedly uses a > 1.2ghz marvell "superscalar" CPU (which makes a biiig difference), > reports are in that running Fedora it *outperforms* an intel atom > laptop. Yeah, the Marvell Armada (I bet Intel are kicking themselves for having sold their XScale ARM business to Marvell only a few years ago) is pretty good. My 1.2GHz Sheevaplug (Marvell Kirkwood) gives my Atom N450 servers a serious run for their money at 1/4 the power budget. >> So now I am pondering using a slightly newer yet very similar >> W860CU. That is available with a 1920x1080 LED backlit panel (15.6in). It >> wouldn't make much sense to use a higher drain screen when low power is a >> key part of the appeal. > > yes. that will mean that it probably requires a 3x LVDS IC [big, fat > cable, at least 40 wires] do you have a datasheet around? unless it > runs at 30hz refresh rate, in which case they *might* have only the > one LVDS channel... yep, need a datasheet on the LCD panel. I suspect (it's just a guess, but an educated one) the panel they use is an AUO (AU Optronics) B156HW01 or B156HW02. There are almost certainly several interchangeable variants of each, with possibly slightly different LVDS plug locations. Here is a spec sheet for one of the variants: www.yslcd.com.tw/docs/product/B156HW01%20V.3.pdf [Clevo W860CU chassis: good] [Tegra bad: bad] >> The closest I have been able to get to finding a decent solution is the >> Pandaboard (OMAP4 - Cortex A9 / PowerVR SGX). It has a PowerVR GPU which is >> reasonably well understood, there is working XV video acceleration, and >> decently working OpenGL ES drivers. > > _proprietary_ OpenGL drivers. Which is better than _no_ OpenGL drivers (or OpenGL capability). Having said that, I don't actually care too much if there is working 3D acceleration, so OpenGL is definitely optional. But if there is OpenGL it should be the real thing, not ES. 2D acceleration with XV should be perfectly sufficient for the sort of thing we are discussing here. >> With some luck we might get full OpenGL &g
Re: [fedora-arm] 1ghz ARM Laptop (12in 1280x800 LCD)
Luke Kenneth Casson Leighton wrote: [B156HW01: good] [OMAP4 export restrictions] >>> now i _have_ been advised of another two CPUs - one is the nusmart >>> 2816 and the other is the ziilabs ZMS-08. the nice thing about the >>> ZMS-08 is that it is *already* available in a "system-on-module" >>> format: >>> http://www.ziilabs.com/products/platforms/zms08som.aspx >>> >>> use of this module would mean zero SO-DIMM development costs, meaning >>> that all that would be required would be a motherboard, and that's >>> only about $2k-$3k! >> What is the CPU on that? Cortex could mean anything from Cortex M0 to Cortex >> A9. > > A8. OK, now I'm _seriously_ wondering why you don't just get an Efika MX and drop a 1280x720 screen into it. That sounds like it'll cover just about all of your requirements: Cortex A8, 1280x720 display. Only 512MB of RAM, but that's the only thing not matching your requirements. Seems a reasonable trade-off for something you can buy off the peg right now vs. 10s of 000s of $ in development costs. >> I don't see anything about a cell vector processor listed in the spec. > > no - and the reason for that is precisely because they DO NOT want > people ringing up even _asking_ for "free" support as they believe it > is a total waste of their time. > > their primary customers have been companies who are basically > incompetent at software development, and expect to be spoon-fed full > solutions, or they will go elsewhere. so creativelabs have developed > ready-made (proprietary) OpenGL and MPEG proprietary libraries, and > that keeps these drone-clone companies happy. I'd say forget it. This will come to rear it's ugly head as soon as a new version of Xorg is released and the drivers stop working. >> And I only say PowerVR because I'm not aware of more supportable >> alternatives at the moment. > > it's non-free, and... yes, hm. > > you're aiming for a market segment a bit higher than i have been > planning. not that that rules out covering both, but i have some > other markets that can be covered, and if the BOM comes to $300 that > means a $600 to $800 price-tag, which is wayy outside of the consumer > mass-market price range i'm also looking at. > Pandaboard: 1GB >>> POP - this will be eeexpensiiive. >> $175/board doesn't sound that expensive in the grand scheme of things, >> unless you are referring to other potential issues (e.g. import/export >> licencing you mentioned). > > i'm thinking and have been planning along the lines of a BOM *under* > that cost of $175/board - just for that board! As I said, it sounds like what you're aiming for is already covered by the Efika MX + TFT panel upgrade. [SODIMM SoC standards or lack thereof] >> I'm all for a project like this, but I suspect the volume will be quite low. >> That means high unit cost, and in that case it makes more sense to aim for >> the high end, since there is a higher chance of being competitive there. It >> will be easier to come up with a very low power and adequate performance >> 15.6in 1920x1080 laptop with 20 hours battery life for $1500 than a slightly >> better 10in 1280x720 laptop that has to be competitive against the $350 >> offerings. >> >> Having said all that, it may be worthwhile having a word with Genesi. They >> are probably already working on the next gen of Efika MX. > > i already asked. they already told me they had made their decisions > (for the next generation) and were not in the slightest bit interested > in changing their minds to expand the market opportunities for the new > product. I'm not yet convinced that your requirements aren't covered well enough by their current product. [Commercialization] > also - an established manufacturer is the absolute last thing that's > needed. they will add a large markup/premium, apart from anything > else. but think about this: ARM CPUs capable of running laptops have > been available since early 2009 (and one or two even before that). > you'd think that, by now, one of the "established" manufacturers would > come up with the goods, neh? it doesn't take 6 months to put a design > together if you've got the money, and they've got the money. so where > _are_ these magic low-power, lower-cost high-end ARM and MIPS laptops, > from the established manufacturers? The problem is two-fold: 1) Lack of perception of a market for the product. There's a lot of money to be made on x86 laptops since the market is so much bigger. More users, more sales, it is as simple as that. For ARM you pretty much have to create the market. To do that, you have to make a product that is sufficiently better to make people say "WTF?! Can that be right?!" to get them to consider moving off the straight and narrow. 2) Lack of software. We all know that Fedora is not yet fit for desktop/laptop use on ARM. It's out of date before it's even released, and the bug count even on x86 is dangerously close to the "enthusiast-only" territory. Where'
Re: [fedora-arm] 1ghz ARM Laptop (12in 1280x800 LCD)
On 02/01/2011 06:17 PM, Luke Kenneth Casson Leighton wrote: I don't see anything about a cell vector processor listed in the spec. >>> >>> no - and the reason for that is precisely because they DO NOT want >>> people ringing up even _asking_ for "free" support as they believe it >>> is a total waste of their time. >>> >>> their primary customers have been companies who are basically >>> incompetent at software development, and expect to be spoon-fed full >>> solutions, or they will go elsewhere. so creativelabs have developed >>> ready-made (proprietary) OpenGL and MPEG proprietary libraries, and >>> that keeps these drone-clone companies happy. >> >> I'd say forget it. This will come to rear it's ugly head as soon as a new >> version of Xorg is released and the drivers stop working. > > tell me about it. it's why i will be speaking to ziilabs to obtain > details of the Cell's assembly language etc. i have to come up with a > convincing and reassuring strategy as to why they should do exactly > that. You should also consider that getting FSF drivers for this is of very limited usefulness. This DSP is very proprietary. It would be far more valuable (if more difficult) to get the PowerVR drivers as that would cover the majority of ARM based SoC modules. I don't think it'd be worth the effort, especially for a CPU (A8) that is already on the verge of deprecation. Gordan ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
