* Mathieu Desnoyers (mathieu.desnoy...@efficios.com) wrote: > * Richard Mortimer (ri...@oldelvet.org.uk) wrote: [...] > > I'm also getting a lot of Kernel unaligned access errors from the > > kernel. I don't know if they are related to this or not and this is the > > first time that I personally have got 2.6.37 to boot on sparc64. The > > messages that I am getting seem to be repeats of > > > > [ 4376.807811] Kernel unaligned access at TPC[456e94] > > try_to_wake_up+0x58/0xec > > [ 4376.807908] Kernel unaligned access at TPC[75541c] schedule+0x454/0x660 > > [ 4376.808044] Kernel unaligned access at TPC[75541c] schedule+0x454/0x660 > > [ 4376.808871] Kernel unaligned access at TPC[456e94] > > try_to_wake_up+0x58/0xec > > [ 4376.808965] Kernel unaligned access at TPC[75541c] schedule+0x454/0x660 > > [ 4381.813354] log_unaligned: 337 callbacks suppressed > > > > I have to go out now but will be around later/over the weekend.
OK, I pinpointed it to my use of the "packed" attribute. So within the structure: struct test { const char *a; int b; void *c; void *d; void *e; } __attribute__((packed, aligned(8))); (on sparc64) It provides the following offsets: 0 8 12 20 28 which is clearly wrong in terms of inner alignment: it removes the padding between b and c. I am really tempted to just remove the "packed" attribute from there: our goal is really to make sure the 8-byte accesses are all aligned after all. So theoretically gcc could decide to align all struct test arrays and pointers on an alignment larger than 8 if we just specify the aligned(8) type attribute (because the type attribute is just a minimum floor alignment value), but the only reason I would see for gcc to align these on larger alignment would be that the structures would contain a field that requires such largish alignment (which I doubt we have in the kernel). I'll prepare updated patches shortly. Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110121191556.GB13198@Krystal