On 09/01/2011 17:15, omalleys@xxxxxxx wrote: > Quoting Gordan Bobic<gordan@xxxxxxxxxx>: > >> 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 (might as well be garbage). Somebody please correct me if I'm wrong here. > The logistics of fixing all of them even for large projects is going > to take a long time unless someone has a killer compiler that can do > like a direct download from git, compile it, find the errors, fix the > errors and submit the patches back that make sense. :P In fairness, not that much is actually broken, at least not that I've found so far. Certainly not enough to totally cripple things. So far, the things I've bumped into personally are: udisks source-highlight dietlibc used to be problematic (that's kind of where this thread started), but the maintainer is really responsive, I've been testing the new patches for the last day and a half, and there has been considerable progress. I'm really, really impressed. Somebody mentioned PHP. I'm sure there are other things remaining, but so far it's not actually too bad. I'm sure a lot of work will be needed - I spent several hours/day for the last few days just testing and filing bug reports on this; but it isn't an unfeasibly large effort if the package developers show a willingness to address the issue (like the dietlibc maintainer has). Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
