Messages in this thread | | | Date | Fri, 21 Jan 2011 14:15:56 -0500 | From | Mathieu Desnoyers <> | Subject | Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36 |
| |
* Mathieu Desnoyers (mathieu.desnoyers@efficios.com) wrote: > * Richard Mortimer (richm@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
| |