Re: How to tell users that ia32-libs will go away
* Ben Hutchings b...@decadent.org.uk [120209 20:45]: There is a similar issue with linux-image-*-amd64, which I would definitely like to remove from i386 as soon as possible. We have metapackages to help with this already, but we still need users to add amd64 as a foreign architecture before upgrading. From a user's point of view I'd really appreciate if that package could be kept. Needing multi-arch enabled (with all the dangers of getting the wrong packages installed or the additional index files to download) just to have a suiteable kernel would be quite a burden. Bernhard R. Link -- 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/20120210120049.ga2...@client.brlink.eu
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
* David Miller da...@davemloft.net [110117 07:07]:
Although I've seen commentary to the contrary, in fact using a too-small
__attribute__((aligned())) directive will lower the alignment of data
members, and yes that means it will lower the alignemnt to be below the
natural and required alignment for the given type.
So if you have, on 64-bit:
struct foo {
void *bar;
};
static struct foo test __attribute__((__aligned__(4)));
The compiler will emit test with 4-byte alignment into the data
section, even though 8-byte alignment is required for test.bar
Assuming we wanted that to actually happen, the GCC manual is very
explicit to state that in order for this to work, such down-aligned
data structures must also use the packed attribute.
The manual seems to have changed in that regard.
http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Variable-Attributes.html
and earlier versions say:
The aligned attribute can only increase the alignment; but you can
decrease it by specifying packed as well. See below.
but http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Variable-Attributes.html
and later versions say:
When used on a struct, or struct member, the aligned attribute can only
increase the alignment; in order to decrease it, the packed attribute
must be specified as well. When used as part of a typedef, the aligned
attribute can both increase and decrease alignment, and specifying the
packed attribute will generate a warning.
And seems to still be a bit confusing, as an attribute in a
variable declaration seems to count as typedef:
| struct foo {
| void *bar;
| };
|
| static struct foo a __attribute__((__aligned__(2)));
| static struct foo b;
|
| struct foo2 {
| void *bar;
| } __attribute__((__aligned__(2)));
|
| static struct foo2 c __attribute__((__aligned__(2)));
| static struct foo2 d;
|
| struct foo3 {
| void *bar;
| } __attribute__((__aligned__(2))) __attribute__((__packed__));
|
| static struct foo3 e;
|
| int main() {
| printf(a: %d, b: %d, c: %d, d: %d, e: %d\n,
| __alignof__(a), __alignof__(b),
| __alignof__(c), __alignof__(d),
| __alignof__(e)
| );
| return 0;
| }
gives something like:
a: 2, b: 4, c: 2, d: 4, e: 2
or on sparc64:
a: 2, b: 8, c: 2, d: 8, e: 2
I think we want none of this, and I think we should elide the align
directives entirely, or at least fix them so we don't get unaligned
stuff on 64-bit.
One fix might be to move the __attribute__ from include/trace/ftrace.h
(and from include/linux/syscalls.h) to include/linux/ftrace_event.h
and attach it to the struct there. This way it should only increase it.
Ugh, and I just noticed that include/linux/klist.h does this fixed
alignment of 4 too, where is this stuff coming from? It's
wrong on 64-bit, at best. But I can't see the impetus behind doing
this at all in the first place.
Is that actually misaligned? Unless I still mix things up, that is in the
struct thus should be fine (i.e. the d case in my example above).
Bernhard R. Link
--
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/20110117143954.ga17...@pcpool00.mathematik.uni-freiburg.de
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
* David Miller da...@davemloft.net [110116 20:39]: From: Richard Mortimer ri...@oldelvet.org.uk Date: Sun, 16 Jan 2011 14:17:49 + I'm wondering if gcc is just getting better at honouring the source code. The DEFINE_EVENT macros in include/trace/ftrace.h have a __aligned__(4) attribute in them. Maybe that should be 8 on sparc64 systems. The aligned 4 seems to be unchanged since include/trace/ftrace.h was created in f42c85e74faa422cf0bc747ed808681145448f88 in April 2009. That needs to be at least 8 on 64-bit systems. Why is this aligned directive there at all? Why has this align any effect at all? gcc's documentation says: The `aligned' attribute can only increase the alignment; but you can decrease it by specifying `packed' as well. And as the struct has pointers in it, I'd guess it already had a 64-bit alignment unless there is some packed hidden somewhere. Bernhard R. Link -- 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/20110116210924.ga3...@pcpool00.mathematik.uni-freiburg.de
Bug#569797: misaligned signal stack on sparc
Package: linux-image-2.6.32-2-sparc64-smp Version: 2.6.32-8 Severity: serious On my sid sparc box I can reproducibly cause a shell getting in a state where the kernel soft-locks and one cpu is only occupied py this process. kill -KILL does not work, sync does not work, restarting the computer needs reboot -n -f and so on. I think this is due to some misalignment of signal stacks, as described in http://marc.info/?l=linux-sparcm=126576299426902w=2 (at least the hanging cpu hangs in the area this patch touches and the process seems to be hanging in some fault handler occouring in a fault handler occouring in some signal stuff as far as I can tell, my sparc assembler skills are quite limited). Note that the patch given in the mail has still a typo described in http://marc.info/?l=linux-sparcm=126592005119857w=2 See also http://marc.info/?l=linux-sparcm=126592110921290w=2 (Though I do not know if this fix for the patch is needed for 32 bit sparc kernels Debian afaik no longer has or for 32 bit user space, but I guess adding both is safest in any case). Hochachtungsvoll, Bernhard R. Link This bug also effects (at least) 2.6.32-3 and 2.6.32-5, but I have no idea how to tell this the bts as the binary package name changed. -- 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/20100214113651.ga13...@pcpool00.mathematik.uni-freiburg.de
Bug#507557: linux-image-2.6.26-1-r4k-ip22: hangs early at boot on Indigo2
* Martin Michlmayr t...@cyrius.com [090922 12:00]: * Thomas Bogendoerfer tsbog...@alpha.franken.de [2009-09-21 22:39]: If so, have you made any progress on this, or should we turn off CONFIG_EARLY_PRINTK for the IP22 kernel? no progress in fixing the problem itself, so turning off EARLY_PRINTK would be the best workaround. Julien, Bernhard: can you please test the following kernel: http://merkel.debian.org/~tbm/tmp/kernel/linux-image-2.6.26-2-r4k-ip22_2.6.26-20_mips.deb Seems to work fine here. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507557: same hang as 507557 on SGI Indy
* Julien BLACHE jbla...@debian.org [081202 13:26]: The kernel hangs early at boot on an Indigo2: [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.26-1-r4k-ip22 (Debian 2.6.26-11) (wa...@debian.org) (gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 Thu Nov 27 03:36:47 UTC 2008 [0.00] ARCH: SGI-IP22 [0.00] PROMLIB: ARC firmware Version 1 Revision 10 [0.00] console [early0] enabled [0.00] CPU revision is: 0460 (R4400SC) [0.00] FPU revision is: 0500 [0.00] Checking for the multiply/shift bug... no. [0.00] Checking for the daddiu bug... no. [0.00] MC: SGI memory controller Revision 3 [0.00] MC: Probing memory configuration: [0.00] bank0: 128M @ 0800 [0.00] bank1: 128M @ 1000 [0.00] Determined physical RAM map: [0.00] memory: 1000 @ 0800 (usable) [0.00] Wasting 1835008 bytes for tracking 32768 unused pages [0.00] Initrd not found or empty - disabling initrd [0.00] Zone PFN ranges: [0.00] Normal 32768 -98304 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:32768 -98304 I'm experience a similar hand at the same place on a SGI Indy (with r5k processor). It hangs at the same place, still outputting to the PROM console and not yet switched to framebuffer. (From memory, that messages looks quite like that. Only difference I see is one instead of two banks of memory). Etch's 2.6.18 luckily still works. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#344767: same here with linux-image-2.6.14-2-sparc64
I've the same behaviour here with the linux-image-2.6.14-2-sparc64, everything works but when purging it hangs. Adding some print STDERR into the postrm, it hangs in the line my $ret = purge(); Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
