Bug#607885: squeeze testing di beta2 amd64 installer kernel panic on xenserver vm
On Wed, 2011-01-19 at 01:50 +0100, Jacco Beije wrote: If there is anything else I can do/test to help please let me know. You could try adding xen_emul_unplug=never to the kernel command line. This will prevent the pvhvm drivers from initialising and may allow you to make progress using the emulated devices. You should also ensure you are running the most recent XenServer release. You could also consider running Squeeze in PV mode instead of PVonHVM. AIUI this is available as an experimental feature in the latest XenServer FP release. If that doesn't work then I think you need to contact XenServer support or make use of the XenServer forums. Ian. -- Ian Campbell It's the RINSE CYCLE!! They've ALL IGNORED the RINSE CYCLE!! signature.asc Description: This is a digitally signed message part
Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules that weren't built in-tree
On Sun, Jan 09, 2011 at 06:51:36AM +, Ben Hutchings wrote: I want to apply this to squeeze. I've seen one too many panics with VMware or VirtualBox modules in them, which appear to be worse than anything in drivers/staging. Don't forget to add it to the bug script. + intree = get_modinfo(sechdrs, infoindex, intree); + if (!intree) + add_taint_module(mod, TAINT_OOT_MODULE); Is there a reason for not doing this the following way except that you copied the staging check? | if (!get_modinfo(sechdrs, infoindex, intree)) | add_taint_module(mod, TAINT_OOT_MODULE); The resulting code should be the same[1]. And actually the staging test looks this way in .37. Bastian [1]: http://mirror.fem-net.de/CCC/27C3/mp4-h264-HQ/27c3-4096-en-code_deobfuscation_by_optimization.mp4 -- Where there's no emotion, there's no motive for violence. -- Spock, Dagger of the Mind, stardate 2715.1 -- 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/20110119085106.ga9...@wavehammer.waldi.eu.org
Bug#610507: squeeze/amd64 kernel: 180 seconds timeout when booting
On Wed, 2011-01-19 at 09:56 +0100, Aeschbacher, Fabrice wrote: Package: linux-image-2.6.32-5-amd64 Version: 2.6.32-30 When booting, there is a timeout of 180s between nouveau driver is initialized and swap activation. See attached dmesg output (see: line 961) [...] Most likely the TPM driver is having trouble. Try this: echo 'blacklist tpm_infineon' /etc/modprobe.d/blacklist-tpm.conf Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Processed: tagging 610507
Processing commands for cont...@bugs.debian.org: tags 610507 + moreinfo Bug #610507 [linux-image-2.6.32-5-amd64] squeeze/amd64 kernel: 180 seconds timeout when booting Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 610507: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610507 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.129544347614606.transcr...@bugs.debian.org
Processed: Re: Bug#610530: ocfs2-tools: BUG at fs/ocfs2/dlm/dlmmaster.c:2226! invalid opcode
Processing commands for cont...@bugs.debian.org: reassign 610530 linux-2.6 Bug #610530 [ocfs2-tools] ocfs2-tools: BUG at fs/ocfs2/dlm/dlmmaster.c:2226! invalid opcode Bug reassigned from package 'ocfs2-tools' to 'linux-2.6'. Bug No longer marked as found in versions ocfs2-tools/1.4.1-1. thanks Stopping processing here. Please contact me if you need assistance. -- 610530: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610530 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.12954473751012.transcr...@bugs.debian.org
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
* David Miller (da...@davemloft.net) wrote: From: Mathieu Desnoyers mathieu.desnoy...@efficios.com Date: Wed, 19 Jan 2011 00:08:45 -0500 The following works fine for me now. Comments are welcome. Thanks for doing this work Mathieu. - No aligned() type attribute nor variable attribute. I get a crash on x86_64 (NULL pointer exception when executing __trace_add_event_call, the 5th call). __alignof__(struct ftrace_event_call) is worth 8. This is really bizarre. Does it only happen on x86_64? Sadly, my ppc32 test machine is currently broken, so I could not check on other than x86 archs. I'm wondering if GCC does something bizarre like work with different default alignments based upon the section or something like that. If so, maybe adding the section attribute to the array definition will fix things? Well, I thought about it in my sleep, and it looks like gcc is within its rights to align these statically declared structures on a larger alignment: gcc has no clue that we're going to do tricks with the linker to access the structures as an array, so aligning on a larger alignment *should* be fine for the compiler, but we suffer because we're doing something non-standard. On 32-bit architectures, we really want a aligned(4), and on 64-bit architectures, aligned(8). Represent this by creating: #define __long_aligned __attribute__((__aligned__(__alignof__(long Do any of these datastructures have, or will have, u64 or long long types in them? If so, then we will need to use 8 unconditionally or __alignof__(long long). If my memory serves me correctly, I think long long is aligned on 4 bytes on ppc32, but on 8 bytes on x86_32 (yeah, that's weird). How about we create a #define __long_long_aligned __attribute__((__aligned__(__alignof__(long long ? Thanks, Mathieu I'll see if I can work out why using no align directive explodes on x86-64. -- Mathieu Desnoyers Operating System Efficiency RD 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/20110119151004.GA11022@Krystal
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
* David Miller (da...@davemloft.net) wrote: From: Mathieu Desnoyers mathieu.desnoy...@efficios.com Date: Wed, 19 Jan 2011 00:08:45 -0500 - No aligned() type attribute nor variable attribute. I get a crash on x86_64 (NULL pointer exception when executing __trace_add_event_call, the 5th call). __alignof__(struct ftrace_event_call) is worth 8. I think I figured it out. It's the static vs. non-static thing, or some other crazyness wrt. how x86-64 implements it's alignment rules. GCC on x86-64 uses a completely different policy for aligning local (ie. static) data objects vs. globally visible ones, for one thing. It also has different alignment policies for objects that are part of an array vs. those which are not. On both counts, we're lying to the compiler, so maybe it's sort of our fault. Yep, we're in strong agreement here. As far as GCC can see, the object is static and also not part of an array or any other C construct for which things like this could matter as long as the alignment it chooses meets the minimum alignment requirements of the ABI. So it doesn't let us do this trick where we put the individual event markers into a special section, yet mark it __used and static, then later access them as if they were part of a globally visible array. If you look these static objects, they are emitted with a leading .align 32 directive. This is what screws everything up. Ah, yep, good way to identify the culprit. When the linker sees this, it aligns the start of every individual _ftrace_events section, and that's where the gaps come from and the crashes. OK (more to come in the following email response). Mathieu -- Mathieu Desnoyers Operating System Efficiency RD 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/20110119151139.GB11022@Krystal
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
On 18/01/2011 06:08, David Miller wrote: From: David Millerda...@davemloft.net Date: Mon, 17 Jan 2011 22:00:39 -0800 (PST) ftrace: Remove unnecessary alignment tag from ftrace_event_call. It's completely unnecessary and causes problems on platforms where this tag down-aligns the structure's alignment. Signed-off-by: David S. Millerda...@davemloft.net ... Ok, unless we can explain why these alignments are needed at all, we should kill all of them: tracing: Remove unnecessary __aligned__(4) tag from trace data. It's completely unnecessary and causes problems on platforms where this tag down-aligns the structure's alignment. Signed-off-by: David S. Millerda...@davemloft.net For reference my build with the above patch completed last night. That does boot on my sparc64 Sun Fire V120 so at the very least the relocation issues go away. The machine wasn't very happy and networking/nfs was a little upset but I'll wait until the patchset is more refined before investigating further and trying to work out if it is related or not. Regards Richard -- 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/4d3702d5.5050...@oldelvet.org.uk
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
* David Miller (da...@davemloft.net) wrote:
From: David Miller da...@davemloft.net
Date: Tue, 18 Jan 2011 22:32:47 -0800 (PST)
As far as GCC can see, the object is static and also not part of an
array or any other C construct for which things like this could matter
as long as the alignment it chooses meets the minimum alignment
requirements of the ABI.
So it doesn't let us do this trick where we put the individual event
markers into a special section, yet mark it __used and static, then
later access them as if they were part of a globally visible array.
If you look these static objects, they are emitted with a leading
.align 32 directive. This is what screws everything up.
When the linker sees this, it aligns the start of every individual
_ftrace_events section, and that's where the gaps come from and
the crashes.
I've come up with one possible way to deal with this.
Put pointers to the trace objects into the special section, and
interate over those instead.
I was wondering why this x86-64 weird alignment behavior doesn't bite
us for our init funcs. And the reason is that all of these weird
alignment cases only trigger for aggregates (ie. structs and unions).
So we could do:
static struct ftace_event_call foo_event = { ... };
static struct ftrace_event_call * __used
__attribute__((section(_ftrace_event_ptrs)))
foo_event_ptr = foo_event;
and
extern struct ftrace_event_call *__start_ftrace_event_ptrs[];
extern struct ftrace_event_call *__end_ftrace_event_ptrs[];
struct ftrace_event_call **p = __start_ftrace_event_ptrs;
while (p __end_ftrace_event_ptrs[0]) {
struct ftrace_event_call *event = *p++;
__trace_add_event_call(event, ...);
}
you get the idea.
And we could mark this entire point section as initdata and thus
free'able after bootup and post module load.
There are three downsides to this approach compared to forcing both the type and
variable alignments with attributes:
1) It consumes extra space: This approach lets gcc align foo_event on 32-byte
boundaries, which is unneeded in this case. For structures repeated very
often, this is a bad thing.
2) It mixes .data and struct ftrace_event_call definitions, thus polluting .data
cache-lines (actually, the 32-byte alignment will leave some of these
cachelines partly unused). This would be fixable by specifying yet another
section name to hold the struct ftace_event_call definitions.
3) Freeing _ftrace_event_ptrs is only possible after init here because Ftrace
data layout is sub-optimal. The linked-list created at init time by Ftrace
kind of duplicates the arrays already implicit to the section. If we look at
Tracepoints for example, which present the exact same section alignment
problem, we iterate on the tracepoint section each time a tracepoint is
activated or deactivated. So we need to keep the section there after init.
Therefore, your indirection approach would grow the data footprint.
The trade-off here is that walking the table is a very rare operation that
does not need to be fast, so we accept the performance hit of walking the
tracepoint table for each enabled tracepoint to shrink the memory footprint.
Especially for reasons (1) and (2), I'd be tempted to go for the
__long_long_aligned type and variable attribute instead. Thoughts ?
I'm still unsure that __long_long_aligned is needed over __long_aligned though.
AFAIK, the only requirement we have for, e.g. tracepoints, is to align on the
pointer size (sizeof(long)), so RCU pointer updates are performed atomically.
Aligning on the pointer size also allows the architecture to efficiently read
the field content. What does aligning on sizeof(long long) bring to us ? Is it
that you are concerned about the fact that the aligned type attribute, when
applied to a structure, is only used as a lower-bound by the compiler ? In that
case, we might want to consider using packed too:
#define __long_packed_aligned __attribute__((__packed__,
__aligned__(__alignof__(long
I would just like to know if this attribute causes gcc to emit slower memory
access instructions on ppc/sparc/mips (I remember that at least one of these
emit slower instructions for unaligned read/writes, so I wonder if the compiler
uses them as soon as it sees the packed attribute, or if it is more clever
than that).
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency RD 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/20110119153326.GC11022@Krystal
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
After applying David's remove align patch, I got it to boot on x86_64
with the following two patches. I thought just adding the align to the
structure declaration would work, but it still failed on the syscall for
init_module. By removing the double declaration of event_exit_##sname,
removed this problem.
I'll test this on x86 32bit and PPC 64. If it works there, I'll push all
of them out for 38. Should these go to 37 stable too?
-- Steve
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index cacc27a..0e3bce6 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -142,8 +142,6 @@ extern struct trace_event_functions
exit_syscall_print_funcs;
#define SYSCALL_TRACE_EXIT_EVENT(sname)
\
static struct syscall_metadata \
__attribute__((__aligned__(4))) __syscall_meta_##sname; \
- static struct ftrace_event_call \
- __attribute__((__aligned__(4))) event_exit_##sname; \
static struct ftrace_event_call __used \
__attribute__((__aligned__(4))) \
__attribute__((section(_ftrace_events)))\
Index: linux-trace.git/include/linux/ftrace_event.h
===
--- linux-trace.git.orig/include/linux/ftrace_event.h
+++ linux-trace.git/include/linux/ftrace_event.h
@@ -194,7 +194,7 @@ struct ftrace_event_call {
int perf_refcount;
struct hlist_head __percpu *perf_events;
#endif
-};
+} __attribute__((__aligned__(32)));
#define PERF_MAX_TRACE_SIZE2048
--
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/1295451961.12215.1291.ca...@gandalf.stny.rr.com
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
* Steven Rostedt (rost...@goodmis.org) wrote:
After applying David's remove align patch, I got it to boot on x86_64
with the following two patches. I thought just adding the align to the
structure declaration would work, but it still failed on the syscall for
init_module. By removing the double declaration of event_exit_##sname,
removed this problem.
I'll test this on x86 32bit and PPC 64. If it works there, I'll push all
of them out for 38. Should these go to 37 stable too?
Please hold before adding these patches into git. They don't seem to address the
underlying problem correctly. See the latest exchanges between David Miller and
myself for more info.
We need to come up with something better than it boots as an explanation for
the fix.
Thanks,
Mathieu
-- Steve
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index cacc27a..0e3bce6 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -142,8 +142,6 @@ extern struct trace_event_functions
exit_syscall_print_funcs;
#define SYSCALL_TRACE_EXIT_EVENT(sname)
\
static struct syscall_metadata \
__attribute__((__aligned__(4))) __syscall_meta_##sname; \
- static struct ftrace_event_call \
- __attribute__((__aligned__(4))) event_exit_##sname; \
static struct ftrace_event_call __used \
__attribute__((__aligned__(4))) \
__attribute__((section(_ftrace_events)))\
Index: linux-trace.git/include/linux/ftrace_event.h
===
--- linux-trace.git.orig/include/linux/ftrace_event.h
+++ linux-trace.git/include/linux/ftrace_event.h
@@ -194,7 +194,7 @@ struct ftrace_event_call {
int perf_refcount;
struct hlist_head __percpu *perf_events;
#endif
-};
+} __attribute__((__aligned__(32)));
#define PERF_MAX_TRACE_SIZE 2048
--
Mathieu Desnoyers
Operating System Efficiency RD 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/20110119161534.GB15031@Krystal
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
* Sam Ravnborg (s...@ravnborg.org) wrote: If my memory serves me correctly, I think long long is aligned on 4 bytes on ppc32, but on 8 bytes on x86_32 (yeah, that's weird). How about we create a #define __long_long_aligned __attribute__((__aligned__(__alignof__(long long #define __u64_aligned __attribute__((__aligned__(__alignof__(long long A bit shorter but maybe less obvious. Yep, that would make sense. I'm tempted to try creating #defined __u64_packed_aligned __attribute__((__packed__, __aligned__(__alignof__(long long in the hope that gcc sees this as a strict alignment requirement (including a max bound) rather than just a hint. From what I gather in my reading of http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html The aligned attribute can only increase the alignment; but you can decrease it by specifying packed as well. See below. gcc seems to support having both specified. I think this would provide the kind of alignment guarantees we really need here: both specifying the minimum _and_ maximum alignment. Thoughts ? Mathieu Sam -- Mathieu Desnoyers Operating System Efficiency RD 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/20110119161857.GC15031@Krystal
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
If my memory serves me correctly, I think long long is aligned on 4 bytes on ppc32, but on 8 bytes on x86_32 (yeah, that's weird). How about we create a #define __long_long_aligned __attribute__((__aligned__(__alignof__(long long #define __u64_aligned __attribute__((__aligned__(__alignof__(long long A bit shorter but maybe less obvious. Sam -- 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/20110119161455.ga18...@merkur.ravnborg.org
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
On Wed, 2011-01-19 at 11:15 -0500, Mathieu Desnoyers wrote: * Steven Rostedt (rost...@goodmis.org) wrote: After applying David's remove align patch, I got it to boot on x86_64 with the following two patches. I thought just adding the align to the structure declaration would work, but it still failed on the syscall for init_module. By removing the double declaration of event_exit_##sname, removed this problem. I'll test this on x86 32bit and PPC 64. If it works there, I'll push all of them out for 38. Should these go to 37 stable too? Please hold before adding these patches into git. They don't seem to address the underlying problem correctly. See the latest exchanges between David Miller and myself for more info. We need to come up with something better than it boots as an explanation for the fix. Yes, I agree that we should solve this issue correctly. But if there is a work around to the problem, we could implement that if the real solution is not in our grasp yet. -- Steve -- 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/1295460822.12215.1389.ca...@gandalf.stny.rr.com
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
* Steven Rostedt (rost...@goodmis.org) wrote: On Wed, 2011-01-19 at 11:15 -0500, Mathieu Desnoyers wrote: * Steven Rostedt (rost...@goodmis.org) wrote: After applying David's remove align patch, I got it to boot on x86_64 with the following two patches. I thought just adding the align to the structure declaration would work, but it still failed on the syscall for init_module. By removing the double declaration of event_exit_##sname, removed this problem. I'll test this on x86 32bit and PPC 64. If it works there, I'll push all of them out for 38. Should these go to 37 stable too? Please hold before adding these patches into git. They don't seem to address the underlying problem correctly. See the latest exchanges between David Miller and myself for more info. We need to come up with something better than it boots as an explanation for the fix. Yes, I agree that we should solve this issue correctly. But if there is a work around to the problem, we could implement that if the real solution is not in our grasp yet. A known working workaround (used in tracepoints for a few years) is to align the type declaration on 32 bytes. It wastes space, but works. With this solution, you should remove all the per-variable alignment attributes. Now what I'm discussing with David Miller is if creating a __long_packed_aligned and using it for *both* type and variable alignment would be more palatable (it also works, and is more compact). David proposed a solution with an array of pointers (extra indirection) which I don't really like for 3 reasons I exposed in my reply to him. So it's not that the solution is not in our grasp yet, it's more that we have to choose the right one. Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency RD 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/20110119182052.GB18970@Krystal
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
From: Mathieu Desnoyers mathieu.desnoy...@efficios.com Date: Wed, 19 Jan 2011 10:33:26 -0500 I'm still unsure that __long_long_aligned is needed over __long_aligned though. AFAIK, the only requirement we have for, e.g. tracepoints, is to align on the pointer size (sizeof(long)), so RCU pointer updates are performed atomically. Aligning on the pointer size also allows the architecture to efficiently read the field content. What does aligning on sizeof(long long) bring to us ? Is it that you are concerned about the fact that the aligned type attribute, when applied to a structure, is only used as a lower-bound by the compiler ? In that case, we might want to consider using packed too: My concern is that if there is ever a u64 or similarly long long typed member in these tracing structures, it will not be aligned sufficiently to avoid unaligned access traps on 32-bit systems. If your suggestion defines the lowest possible alignment and GCC will do the right thing and up-align the structure if necessary, then fine. If you add packed it is going to screw everything up and we'll essentially be back to square one. On RISC like sparc64, packed causes even 16-bit words to be read and written a byte at a time. Never use packed under any circumstances unless absolutely unavoidable. -- 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/20110119.134047.232915743.da...@davemloft.net
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
From: Mathieu Desnoyers mathieu.desnoy...@efficios.com Date: Wed, 19 Jan 2011 13:20:53 -0500 Now what I'm discussing with David Miller is if creating a __long_packed_aligned and using it for *both* type and variable alignment would be more palatable (it also works, and is more compact). As I mentioned in another reply, we should not be using packed. Packed has other implications, which makes it use byte-at-a-time accesses for all parts of a structure when you tag it with 'packed'. GCC doesn't try to be clever and see that actually such accesses are safe. If plain __long_aligned works and, since you're tagging it to the structure definition, it only specifies a minimum-alignment, then I'm fine with using that to fix this. -- 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/20110119.134428.71569409.da...@davemloft.net
Bug#558316: works with r8169.ko from 2.6.32-30
i have exactly the same problem here, using the squeeze rc1 netinst iso for amd64 on a hp pavilion dv6: firmware is loaded if i provide it, but the network card doesn't work afterwards. after hints (and with help) from #debian-boot i managed to fudge a r8169.ko taken from linux-image-2.6.32-5-amd64_2.6.32-30_amd64.deb into the installer. this solves the problem for me. regards robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
On Wed, 2011-01-19 at 13:40 -0800, David Miller wrote: My concern is that if there is ever a u64 or similarly long long typed member in these tracing structures, it will not be aligned sufficiently to avoid unaligned access traps on 32-bit systems. The structure that gets placed in this section is the ftrace_event_call. It consists only of pointers, a struct list_head, a couple of int, and a struct trace_event, which consists of: a struct hlist_node, a struct list_head, an int, and a pointer. None of these are more than long and I don't foresee them needing a long long type. I think assuming that a long is the largest item should due. We can add a comment next to these structures specifying this dependency, and hopefully it would be updated if we ever do include a long long in them. -- Steve -- 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/1295474423.12215.1612.ca...@gandalf.stny.rr.com
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
From: Steven Rostedt rost...@goodmis.org Date: Wed, 19 Jan 2011 17:00:23 -0500 We can add a comment next to these structures specifying this dependency, and hopefully it would be updated if we ever do include a long long in them. Yes, I think a huge comment should be placed somewhere and also the commit message for the final version of this fix should be quite verbose :-) -- 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/20110119.140917.108794140.da...@davemloft.net
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
* David Miller (da...@davemloft.net) wrote:
From: Mathieu Desnoyers mathieu.desnoy...@efficios.com
Date: Wed, 19 Jan 2011 10:33:26 -0500
I'm still unsure that __long_long_aligned is needed over __long_aligned
though.
AFAIK, the only requirement we have for, e.g. tracepoints, is to align on
the
pointer size (sizeof(long)), so RCU pointer updates are performed
atomically.
Aligning on the pointer size also allows the architecture to efficiently
read
the field content. What does aligning on sizeof(long long) bring to us ? Is
it
that you are concerned about the fact that the aligned type attribute,
when
applied to a structure, is only used as a lower-bound by the compiler ? In
that
case, we might want to consider using packed too:
My concern is that if there is ever a u64 or similarly long long
typed member in these tracing structures, it will not be aligned
sufficiently to avoid unaligned access traps on 32-bit systems.
Hrm, I'd like to see what kind of ill-conceived 32-bit architecture would
generate a unaligned access for a 32-bit aligned u64. Do you have examples in
mind ? By definition, the memory accesses should be at most 32-bit, no ? AFAIK,
gcc treats u64 as two distinct reads on all 32-bit architectures.
If your suggestion defines the lowest possible alignment and GCC will
do the right thing and up-align the structure if necessary, then
fine.
Well, I must admit that my assumption is that aligning on the long size should
be the only alignment required, both on 32-bit and 64-bit. But I'm curious to
see if there are indeed architectures that break this assumption.
Ideally, I'd like to avoid letting gcc up-align a structure, because it is then
hard to know for sure what the alignment value of the section should be (in the
linker script, we can safely choose 32, but it's more a safe choice than
anything else). Moreover, I'm not convinced that gcc will choose to up-align the
structure with the exact same alignment values for both the type declaration and
the variable definition (I'm deeply distrusting gcc to do the right thing here).
If you add packed it is going to screw everything up and we'll
essentially be back to square one.
On RISC like sparc64, packed causes even 16-bit words to be read and
written a byte at a time.
Never use packed under any circumstances unless absolutely
unavoidable.
gcc on my sparc64 box (32-bit userland) disagrees with you here ;) Using
gcc (Debian 4.3.3-14) 4.3.3, here is a demonstration that, indeed, packed
generates aweful code, but that packed, aligned(4 or 8) generates pretty
decent code:
compiling for sparc32:
struct test {
unsigned long a;
unsigned long b;
};
Storing to test a field in a main() that returns 0, with -O0:
000104f0 main:
104f0: 9d e3 bf 90 save %sp, -112, %sp
104f4: 03 00 00 81 sethi %hi(0x20400), %g1
104f8: 84 10 63 9c or %g1, 0x39c, %g2 ! 2079c blah
104fc: 82 10 20 2a mov 0x2a, %g1
10500: c2 20 80 00 st %g1, [ %g2 ]
10504: 82 10 20 00 clr %g1
10508: b0 10 00 01 mov %g1, %i0
1050c: 81 e8 00 00 restore
10510: 81 c3 e0 08 retl
10514: 01 00 00 00 nop
__attribute__((packed))
000104f0 main:
104f0: 9d e3 bf 90 save %sp, -112, %sp
104f4: 03 00 00 81 sethi %hi(0x20400), %g1
104f8: 84 10 63 dc or %g1, 0x3dc, %g2 ! 207dc blah
104fc: c2 08 80 00 ldub [ %g2 ], %g1
10500: 82 08 60 00 and %g1, 0, %g1
10504: c2 28 80 00 stb %g1, [ %g2 ]
10508: c2 08 a0 01 ldub [ %g2 + 1 ], %g1
1050c: 82 08 60 00 and %g1, 0, %g1
10510: c2 28 a0 01 stb %g1, [ %g2 + 1 ]
10514: c2 08 a0 02 ldub [ %g2 + 2 ], %g1
10518: 82 08 60 00 and %g1, 0, %g1
1051c: c2 28 a0 02 stb %g1, [ %g2 + 2 ]
10520: c2 08 a0 03 ldub [ %g2 + 3 ], %g1
10524: 82 08 60 00 and %g1, 0, %g1
10528: 82 10 60 2a or %g1, 0x2a, %g1
1052c: c2 28 a0 03 stb %g1, [ %g2 + 3 ]
10530: 82 10 20 00 clr %g1
10534: b0 10 00 01 mov %g1, %i0
10538: 81 e8 00 00 restore
1053c: 81 c3 e0 08 retl
10540: 01 00 00 00 nop
__attribute__((packed, aligned(4)))
000104f0 main:
104f0: 9d e3 bf 90 save %sp, -112, %sp
104f4: 03 00 00 81 sethi %hi(0x20400), %g1
104f8: 84 10 63 9c or %g1, 0x39c, %g2 ! 2079c blah
104fc: 82 10 20 2a mov 0x2a, %g1
10500: c2 20 80 00 st %g1, [ %g2 ]
10504: 82 10 20 00 clr %g1
10508: b0 10 00 01 mov %g1, %i0
1050c: 81 e8 00 00 restore
10510: 81 c3 e0 08 retl
10514: 01 00 00 00 nop
__attribute__((packed, aligned(8)))
000104f0 main:
104f0: 9d e3 bf 90 save
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
* David Miller (da...@davemloft.net) wrote: From: Mathieu Desnoyers mathieu.desnoy...@efficios.com Date: Wed, 19 Jan 2011 13:20:53 -0500 Now what I'm discussing with David Miller is if creating a __long_packed_aligned and using it for *both* type and variable alignment would be more palatable (it also works, and is more compact). As I mentioned in another reply, we should not be using packed. Packed has other implications, which makes it use byte-at-a-time accesses for all parts of a structure when you tag it with 'packed'. GCC doesn't try to be clever and see that actually such accesses are safe. Please see my explanation about the difference between packed and packed, aligned(4 or 8) in the other thread. I share your concern about ugly code generated by packed, but my tests with a sparc32 gcc show that using both packed and aligned attributes generate nice code. If plain __long_aligned works and, since you're tagging it to the structure definition, it only specifies a minimum-alignment, then I'm fine with using that to fix this. I'd prefer to add the packed to ensure that gcc never decides for some odd reason to use an alignment larger than the one we specify in the linker script. Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency RD 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/20110119221538.GB23544@Krystal
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
From: Mathieu Desnoyers mathieu.desnoy...@efficios.com Date: Wed, 19 Jan 2011 17:13:27 -0500 Hrm, I'd like to see what kind of ill-conceived 32-bit architecture would generate a unaligned access for a 32-bit aligned u64. Do you have examples in mind ? By definition, the memory accesses should be at most 32-bit, no ? AFAIK, gcc treats u64 as two distinct reads on all 32-bit architectures. Sparc 32-bit has 64-bit loads and stores, GCC uses them because the ABI specifies that every structure is at least 8 byte aligned. gcc on my sparc64 box (32-bit userland) disagrees with you here ;) Using gcc (Debian 4.3.3-14) 4.3.3, here is a demonstration that, indeed, packed generates aweful code, but that packed, aligned(4 or 8) generates pretty decent code: Amazing, if this works then do it. But please document this fully with comments and such :-) -- 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/20110119.142137.184823805.da...@davemloft.net
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
From: Mathieu Desnoyers mathieu.desnoy...@efficios.com Date: Wed, 19 Jan 2011 17:15:38 -0500 * David Miller (da...@davemloft.net) wrote: If plain __long_aligned works and, since you're tagging it to the structure definition, it only specifies a minimum-alignment, then I'm fine with using that to fix this. I'd prefer to add the packed to ensure that gcc never decides for some odd reason to use an alignment larger than the one we specify in the linker script. Agreed. -- 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/20110119.142204.124077863.da...@davemloft.net
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
* Steven Rostedt (rost...@goodmis.org) wrote: On Wed, 2011-01-19 at 13:40 -0800, David Miller wrote: My concern is that if there is ever a u64 or similarly long long typed member in these tracing structures, it will not be aligned sufficiently to avoid unaligned access traps on 32-bit systems. The structure that gets placed in this section is the ftrace_event_call. It consists only of pointers, a struct list_head, a couple of int, and a struct trace_event, which consists of: a struct hlist_node, a struct list_head, an int, and a pointer. None of these are more than long and I don't foresee them needing a long long type. I think assuming that a long is the largest item should due. We can add a comment next to these structures specifying this dependency, and hopefully it would be updated if we ever do include a long long in them. I still wonder how a 32-bit system can generate an unaligned access trap for an access to a 64-bit variable aligned on 32-bit, given that there is, by definition, no 64-bit memory accesses available on the architecture ? Mathieu -- Mathieu Desnoyers Operating System Efficiency RD 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/20110119222144.GC23544@Krystal
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
From: Mathieu Desnoyers mathieu.desnoy...@efficios.com Date: Wed, 19 Jan 2011 17:21:44 -0500 I still wonder how a 32-bit system can generate an unaligned access trap for an access to a 64-bit variable aligned on 32-bit, given that there is, by definition, no 64-bit memory accesses available on the architecture ? Sparc 32-bit (and I believe MIPS 32-bit as well) have such 64-bit load and store instructions. -- 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/20110119.142348.186319799.da...@davemloft.net
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
I still wonder how a 32-bit system can generate an unaligned access trap for an access to a 64-bit variable aligned on 32-bit, given that there is, by definition, no 64-bit memory accesses available on the architecture ? From the SPARC V8 manual (this is the 32 bit version of SPARC): Load/Store Instructions ... Integer load and store instructions support byte (8-bit), halfword (16-bit), word (32-bit), and doubleword (64-bit) accesses. ... Alignment Restrictions Halfword accesses must be aligned on a 2-byte boundary, word accesses (which include instruction fetches) must be aligned on a 4-byte boundary, and doubleword accesses must be aligned on an 8-byte boundary. An improperly aligned address causes a load or store instruction to generate a mem_address_not_aligned trap. Sam -- 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/20110119223234.ga20...@merkur.ravnborg.org
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
* David Miller (da...@davemloft.net) wrote: From: Mathieu Desnoyers mathieu.desnoy...@efficios.com Date: Wed, 19 Jan 2011 17:13:27 -0500 Hrm, I'd like to see what kind of ill-conceived 32-bit architecture would generate a unaligned access for a 32-bit aligned u64. Do you have examples in mind ? By definition, the memory accesses should be at most 32-bit, no ? AFAIK, gcc treats u64 as two distinct reads on all 32-bit architectures. Sparc 32-bit has 64-bit loads and stores, GCC uses them because the ABI specifies that every structure is at least 8 byte aligned. Ah, that's the answer I was looking for, thanks! gcc on my sparc64 box (32-bit userland) disagrees with you here ;) Using gcc (Debian 4.3.3-14) 4.3.3, here is a demonstration that, indeed, packed generates aweful code, but that packed, aligned(4 or 8) generates pretty decent code: Amazing, if this works then do it. But please document this fully with comments and such :-) I will, I will! ;) So I guess we go for the following. Is it verbose enough ? /* * __u64_packed_aligned: * * Forces gcc to use the u64 type alignment, up-aligning or down-aligning the * target type if necessary. The memory accesses to the target structure are * efficient (does not require bytewise memory accesses) and the atomic pointer * update guarantees required by RCU are kept. u64 is considered as the largest * type that can generate a trap for unaligned accesses (u64 on sparc32 needs to * be aligned on 64-bit). * * Specifying both packed and aligned generates decent code (without the * bytewise memory accesses generated by simply using packed), and forces * gcc to down-align the structure alignment to the alignment of a u64 type. * * This alignment should be used for both structure definitions and declarations * (as *both* the type and variable attribute) when using the section * attribute to generate arrays of structures. */ #define __u64_packed_aligned \ __attribute__((__packed__, __aligned__(__alignof__(long long Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency RD 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/20110119223339.GD23544@Krystal
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
* Sam Ravnborg (s...@ravnborg.org) wrote: I still wonder how a 32-bit system can generate an unaligned access trap for an access to a 64-bit variable aligned on 32-bit, given that there is, by definition, no 64-bit memory accesses available on the architecture ? From the SPARC V8 manual (this is the 32 bit version of SPARC): Load/Store Instructions ... Integer load and store instructions support byte (8-bit), halfword (16-bit), word (32-bit), and doubleword (64-bit) accesses. ... Alignment Restrictions Halfword accesses must be aligned on a 2-byte boundary, word accesses (which include instruction fetches) must be aligned on a 4-byte boundary, and doubleword accesses must be aligned on an 8-byte boundary. An improperly aligned address causes a load or store instruction to generate a mem_address_not_aligned trap. Ah! There is always an odd case ;) Thanks! Mathieu -- Mathieu Desnoyers Operating System Efficiency RD 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/20110119223440.GE23544@Krystal
Bug#607885: squeeze testing di beta2 amd64 installer kernel panic on xenserver vm
I was running the lastest XenServer 5.6.0 However, I just upgraded one pool from XenServer 5.6.0 to 5.6.1 (Feature Pack 1) and this solves the problem, rc1 is booting normally now! Jacco On 2011-01-19 09:19, Ian Campbell wrote: On Wed, 2011-01-19 at 01:50 +0100, Jacco Beije wrote: If there is anything else I can do/test to help please let me know. You could try adding xen_emul_unplug=never to the kernel command line. This will prevent the pvhvm drivers from initialising and may allow you to make progress using the emulated devices. You should also ensure you are running the most recent XenServer release. You could also consider running Squeeze in PV mode instead of PVonHVM. AIUI this is available as an experimental feature in the latest XenServer FP release. If that doesn't work then I think you need to contact XenServer support or make use of the XenServer forums. Ian. -- Jacco Beije Redproc B.V. *M* +31-(0)6-54270076 *E* ja...@redproc.com mailto:ja...@redproc.com www.redproc.com http://www.redproc.com
Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
From: Mathieu Desnoyers mathieu.desnoy...@efficios.com Date: Wed, 19 Jan 2011 17:33:39 -0500 So I guess we go for the following. Is it verbose enough ? It's got all of the details that seem to matter, thanks. -- 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/20110119.164107.135521108.da...@davemloft.net
Bug#609538: r8169: long delay during resume
When resuming from suspended with 2.6.38-rc1 with my RTL8168d/8111d hardware, I see significant delays [1]. The only firmware I see in /lib/firmware is RTL8192E, thus it looks like this is due to it being not present. I see that Francois' patch is present in 2.6.38-rc1; is there a way to avoid this delay, or is this likely in request_firmware? Thanks, Daniel --- [1] [21786.797521] sdhci-pci :09:00.0: Will use DMA mode even though HW doesn't fully claim to support it. [21786.797530] sdhci-pci :09:00.0: setting latency timer to 64 [21847.280237] r8169 :0b:00.0: eth0: unable to apply firmware patch [21847.283688] PM: resume of devices complete after 61090.398 msecs [21848.934980] Synaptics Touchpad, model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04733/0xa4/0xa [21848.980306] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input12 [21850.886820] PM: Finishing wakeup. [21850.08] Restarting tasks ... done. [21851.384291] r8169 :0b:00.0: eth0: unable to apply firmware patch [21851.386090] r8169 :0b:00.0: eth0: link down [21853.324784] EXT4-fs (sda1): re-mounted. Opts: commit=0 -- Daniel J Blueman -- 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/AANLkTikxpOS2fJ1Sqv=lg6cx1te+1w-zxfv+ymoh1...@mail.gmail.com
Bug#609538: r8169: long delay during resume
On Thu, 2011-01-20 at 10:04 +0700, Daniel J Blueman wrote: When resuming from suspended with 2.6.38-rc1 with my RTL8168d/8111d hardware, I see significant delays [1]. The only firmware I see in /lib/firmware is RTL8192E, thus it looks like this is due to it being not present. If you're using Debian, the necessary blob is in the firmware-realtek package. I see that Francois' patch is present in 2.6.38-rc1; is there a way to avoid this delay, or is this likely in request_firmware? [...] It's a known problem with calls to request_firmware() when userland is not running (early initialisation or resume from sleep). It may be fixable. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#607885: marked as done (squeeze testing di beta2 amd64 installer kernel panic on xenserver vm)
Your message dated Thu, 20 Jan 2011 07:15:28 + with message-id 1295507728.3693.80.camel@localhost.localdomain and subject line Re: Bug#607885: squeeze testing di beta2 amd64 installer kernel panic on xenserver vm has caused the Debian Bug report #607885, regarding squeeze testing di beta2 amd64 installer kernel panic on xenserver vm to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 607885: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607885 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: installation-reports Boot method: cd Image version: http://cdimage.debian.org/cdimage/squeeze_di_beta2/amd64/iso-cd/debian-squeeze-di-beta2-amd64-netinst.iso Date: 2010-12-23 12:00 Machine: VM on XenServer 5.6 Processor: Intel Memory: 256 MB Partitions: lvm, seperate volumes for boot, root, home, var, usr, tmp, swap Output of lspci -knn (or lspci -nn): - (vm) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: After selecting which install (tried normal and expert) the kernel boots but hangs right away, only showing: [0.279513] Console: switching to colour frame buffer device 100x37 [0.280223] fb0: VESA VGA frame buffer device [0.280361] xen-platform-pci :00:03.0: PCI INT C - GSI 30 (level, low) - IRQ 30 [0.281238] Grant table initialized After 120s a kernel INFO message is shown (again at 240s and a final one at 360), about task swapper blocked for more than 120 seconds. (see also screendump) Note, beginning of september I created several VMs using the testing amd64 netinst available at that time, and it booted just fine, no problems installing or afterwards running of the VMs. Jacco ---End Message--- ---BeginMessage--- On Thu, 2011-01-20 at 00:41 +0100, Jacco Beije wrote: I was running the lastest XenServer 5.6.0 However, I just upgraded one pool from XenServer 5.6.0 to 5.6.1 (Feature Pack 1) and this solves the problem, rc1 is booting normally now! Excellent! Based on that I am closing this bug. Ian. -- Ian Campbell Money can't buy love, but it improves your bargaining position. -- Christopher Marlowe signature.asc Description: This is a digitally signed message part ---End Message---
