On Tue, Feb 01, 2011 at 06:11:16AM +0100, David Miller wrote:
Jesper, could you please review this?
Looks good!
Acked-by: Jesper Nilsson jesper.nils...@axis.com
klist: Fix object alignment on 64-bit.
Commit c0e69a5bbc6fc74184aa043aadb9a53bc58f953b (klist.c: bit 0 in
From: Jesper Nilsson jesper.nils...@axis.com
Date: Mon, 17 Jan 2011 10:05:57 +0100
On Mon, Jan 17, 2011 at 07:07:55AM +0100, David Miller wrote:
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
On 21/01/2011 22:50, Richard Mortimer wrote:
On 21/01/2011 20:40, Mathieu Desnoyers wrote:
* Richard Mortimer (ri...@oldelvet.org.uk) wrote:
Thanks for the info! At first glance, it does not seem to contradict my
findings. When you find time, can you have a try at v3 I just posted ?
I'm
* Richard Mortimer (ri...@oldelvet.org.uk) wrote:
On 21/01/2011 22:50, Richard Mortimer wrote:
On 21/01/2011 20:40, Mathieu Desnoyers wrote:
* Richard Mortimer (ri...@oldelvet.org.uk) wrote:
Thanks for the info! At first glance, it does not seem to contradict my
findings. When you find
On 21/01/2011 00:04, Mathieu Desnoyers wrote:
* David Miller (da...@davemloft.net) wrote:
From: Mathieu Desnoyersmathieu.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,
* Richard Mortimer (ri...@oldelvet.org.uk) wrote:
On 21/01/2011 00:04, Mathieu Desnoyers wrote:
* David Miller (da...@davemloft.net) wrote:
From: Mathieu Desnoyersmathieu.desnoy...@efficios.com
Date: Wed, 19 Jan 2011 17:33:39 -0500
So I guess we go for the following. Is it verbose enough ?
* 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
On 21/01/2011 18:52, Mathieu Desnoyers 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
* Richard Mortimer (ri...@oldelvet.org.uk) wrote:
[...]
P.S. I saw your followup mail so hopefully this matches what you have found!
Thanks for the info! At first glance, it does not seem to contradict my
findings. When you find time, can you have a try at v3 I just posted ?
Make sure to start
On 21/01/2011 20:40, Mathieu Desnoyers wrote:
* Richard Mortimer (ri...@oldelvet.org.uk) wrote:
[...]
P.S. I saw your followup mail so hopefully this matches what you have found!
Thanks for the info! At first glance, it does not seem to contradict my
findings. When you find time, can you
* David Miller (da...@davemloft.net) wrote:
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.
I'm letting people following this
* 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.
* 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
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
* 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
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
* 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
* 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
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
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
* 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
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
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
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
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
* 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
* 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
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
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
* 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
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
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):
* 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
* 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
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
On Tue, Jan 18, 2011 at 06:24:44AM +0100, David Miller wrote:
From: Bernhard R. Link brl+ccmadn...@pcpool00.mathematik.uni-freiburg.de
Date: Mon, 17 Jan 2011 15:39:54 +0100
* David Miller da...@davemloft.net [110117 07:07]:
Ugh, and I just noticed that include/linux/klist.h does this fixed
* David Miller (da...@davemloft.net) wrote:
From: David Miller da...@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
On Mon, 2011-01-17 at 22:27 -0800, David Miller wrote:
I'm beginning to think that the align directive is there purposely to
down-align the structure so that the amount of space that tracing
information consumes is minimized.
I honestly can't tell, only Steven Rostedt can tell us for sure,
On Mon, 2011-01-17 at 22:35 -0800, David Miller wrote:
From: Steven Rostedt rost...@goodmis.org
Date: Mon, 17 Jan 2011 09:15:41 -0500
Again, this is to help the linker keep arrays in tacked. Tracepoints are
allocated into the tracepoint section, and then read like an array. If
the linker
On Tue, 2011-01-18 at 11:46 -0500, Mathieu Desnoyers wrote:
* David Miller (da...@davemloft.net) wrote:
From: David Miller da...@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
On Tue, 2011-01-18 at 12:33 -0500, Steven Rostedt wrote:
On Tue, 2011-01-18 at 11:46 -0500, Mathieu Desnoyers wrote:
Also align TRACE_PRINTKS on 8 bytes to make sure the beginning of the
section is
aligned on pointer size.
If I can make it crash without the alignments and this fixes
On Tue, 2011-01-18 at 13:16 -0500, Steven Rostedt wrote:
On Tue, 2011-01-18 at 12:33 -0500, Steven Rostedt wrote:
On Tue, 2011-01-18 at 11:46 -0500, Mathieu Desnoyers wrote:
Also align TRACE_PRINTKS on 8 bytes to make sure the beginning of the
section is
aligned on pointer size.
* Steven Rostedt (rost...@goodmis.org) wrote:
On Tue, 2011-01-18 at 13:16 -0500, Steven Rostedt wrote:
On Tue, 2011-01-18 at 12:33 -0500, Steven Rostedt wrote:
On Tue, 2011-01-18 at 11:46 -0500, Mathieu Desnoyers wrote:
Also align TRACE_PRINTKS on 8 bytes to make sure the beginning of
On Tue, 2011-01-18 at 15:13 -0500, Mathieu Desnoyers wrote:
* Steven Rostedt (rost...@goodmis.org) wrote:
On Tue, 2011-01-18 at 13:16 -0500, Steven Rostedt wrote:
On Tue, 2011-01-18 at 12:33 -0500, Steven Rostedt wrote:
On Tue, 2011-01-18 at 11:46 -0500, Mathieu Desnoyers wrote:
* Steven Rostedt (rost...@goodmis.org) wrote:
On Tue, 2011-01-18 at 15:13 -0500, Mathieu Desnoyers wrote:
* Steven Rostedt (rost...@goodmis.org) wrote:
On Tue, 2011-01-18 at 13:16 -0500, Steven Rostedt wrote:
On Tue, 2011-01-18 at 12:33 -0500, Steven Rostedt wrote:
On Tue,
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
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)
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
On Mon, Jan 17, 2011 at 07:07:55AM +0100, David Miller wrote:
From: David Miller da...@davemloft.net
Date: Sat, 15 Jan 2011 21:17:22 -0800 (PST)
[ Please, everyone, retain the full CC: on all replies, thanks. Some
people are replying only into the debian bug alias, and that loses
On Sun, 2011-01-16 at 22:07 -0800, David Miller wrote:
From: David Miller da...@davemloft.net
Date: Sat, 15 Jan 2011 21:17:22 -0800 (PST)
I think the problem we have here is that the _ftrace_events section is
not aligned sufficiently. That .align 4 mnemonic is a good indication
of this.
[ Added Mathieu on Cc, since he likes alignments ;-) ]
On Sun, 2011-01-16 at 11:39 -0800, David Miller wrote:
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
On Mon, 2011-01-17 at 10:22 +, Richard Mortimer wrote:
On Sun, 2011-01-16 at 22:07 -0800, David Miller wrote:
From: David Miller da...@davemloft.net
Date: Sat, 15 Jan 2011 21:17:22 -0800 (PST)
I think the problem we have here is that the _ftrace_events section is
not aligned
On Mon, Jan 17, 2011 at 09:11:26AM -0500, Steven Rostedt wrote:
The problem comes when the linker puts these sections together. We read
all the sections as one big array. If the linker puts in holes, then
this breaks the array, and the kernel crashes while reading the section.
I think this are
* 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
* Steven Rostedt (rost...@goodmis.org) wrote:
[ Added Mathieu on Cc, since he likes alignments ;-) ]
Oh yes, alignments are so much fun! (for some definitions of fun) ;)
On Sun, 2011-01-16 at 11:39 -0800, David Miller wrote:
From: Richard Mortimer ri...@oldelvet.org.uk
Date: Sun, 16 Jan
On Mon, 2011-01-17 at 10:22 +, Richard Mortimer wrote:
On Sun, 2011-01-16 at 22:07 -0800, David Miller wrote:
From: David Miller da...@davemloft.net
Date: Sat, 15 Jan 2011 21:17:22 -0800 (PST)
I think the problem we have here is that the _ftrace_events section is
not aligned
From: Bernhard R. Link brl+ccmadn...@pcpool00.mathematik.uni-freiburg.de
Date: Mon, 17 Jan 2011 15:39:54 +0100
* David Miller da...@davemloft.net [110117 07:07]:
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
From: Steven Rostedt rost...@goodmis.org
Date: Mon, 17 Jan 2011 09:11:26 -0500
The problem comes when the linker puts these sections together. We read
all the sections as one big array. If the linker puts in holes, then
this breaks the array, and the kernel crashes while reading the section.
From: David Miller da...@davemloft.net
Date: Mon, 17 Jan 2011 21:34:48 -0800 (PST)
Where are these holes coming from? Reading the commit message for
the change that introduced this problem
(86c38a31aa7f2dd6e74a262710bf8ebf7455acc5), it seems like the issue is
coming from the compiler, and
From: David Miller da...@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.
From: Bernhard R. Link brl+ccmadn...@pcpool00.mathematik.uni-freiburg.de
Date: Mon, 17 Jan 2011 15:39:54 +0100
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
From: Steven Rostedt rost...@goodmis.org
Date: Mon, 17 Jan 2011 09:15:41 -0500
Again, this is to help the linker keep arrays in tacked. Tracepoints are
allocated into the tracepoint section, and then read like an array. If
the linker adds holes as it links sections into one big one, then the
From: Mathieu Desnoyers mathieu.desnoy...@efficios.com
Date: Mon, 17 Jan 2011 14:35:25 -0500
Steven, what were you trying to fix in the first place when you added the
aligned(4) to the definition ? It might have just been that the _ftrace_events
section needed to be aligned on at least 8 bytes
On Sat, 2011-01-15 at 21:17 -0800, David Miller wrote:
From: Richard Mortimer ri...@oldelvet.org.uk
Date: Fri, 14 Jan 2011 16:08:30 +
[ Frederic, Steven, Ingo, the short version of the story is that we
need to make it such that the _ftrace_events section is aligned
properly for
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.
* 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)
From: Bernhard R. Link brl...@debian.org
Date: Sun, 16 Jan 2011 22:09:24 +0100
* 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.
From: David Miller da...@davemloft.net
Date: Sat, 15 Jan 2011 21:17:22 -0800 (PST)
[ Please, everyone, retain the full CC: on all replies, thanks. Some
people are replying only into the debian bug alias, and that loses
information and exposure for fixing this bug. ]
I think the problem we
On Fri, Jan 14, 2011 at 11:38:28AM -0800, David Miller wrote:
From: Richard Mortimer ri...@oldelvet.org.uk
So that means that the kernel is complaining about type 54 which is
R_SPARC_UA64. That matches with the objdump output which doesn't list
R_SPARC_LM22 for scsi_mod.ko
Indeed, good
Hi,
On 15/01/2011 10:00, Bastian Blank wrote:
On Fri, Jan 14, 2011 at 11:38:28AM -0800, David Miller wrote:
From: Richard Mortimerri...@oldelvet.org.uk
So that means that the kernel is complaining about type 54 which is
R_SPARC_UA64. That matches with the objdump output which doesn't list
From: Bastian Blank wa...@debian.org
Date: Sat, 15 Jan 2011 11:00:11 +0100
On Fri, Jan 14, 2011 at 11:38:28AM -0800, David Miller wrote:
From: Richard Mortimer ri...@oldelvet.org.uk
So that means that the kernel is complaining about type 54 which is
R_SPARC_UA64. That matches with the
From: Richard Mortimer ri...@oldelvet.org.uk
Date: Fri, 14 Jan 2011 16:08:30 +
[ Frederic, Steven, Ingo, the short version of the story is that we
need to make it such that the _ftrace_events section is aligned
properly for 64-bit systems, and in particular that GCC can see this
too.
On 13/01/2011 23:57, David Miller wrote:
From: Richard Mortimerri...@oldelvet.org.uk
Date: Thu, 13 Jan 2011 23:34:01 +
On Wed, 2011-01-12 at 00:37 +, Ben Hutchings wrote:
On Wed, 2011-01-12 at 00:27 +, Richard Mortimer wrote:
On 09/01/2011 03:46, David Miller wrote:
From: Ben
I've been looking at the contents of scsi_mod.ko at bit more and it
looks like this is related to ftrace.
All of the R_SPARC_UA64 records are in section _ftrace_events and the
R_SPARC_13 records are located at/near __tracepoint_* symbol uses
RELOCATION RECORDS FOR [_ftrace_events]:
OFFSET
From: Richard Mortimer ri...@oldelvet.org.uk
Date: Fri, 14 Jan 2011 10:53:35 +
On 13/01/2011 23:57, David Miller wrote:
Relocation type 36 is R_SPARC_LM22.
I'm confused now! Maybe I've missed something but looking at
arch/sparc/kernel/module.c it seems that the 36 is hexadecimal.
On Wed, 2011-01-12 at 00:37 +, Ben Hutchings wrote:
On Wed, 2011-01-12 at 00:27 +, Richard Mortimer wrote:
On 09/01/2011 03:46, David Miller wrote:
From: Ben Hutchingsb...@decadent.org.uk
Date: Sun, 09 Jan 2011 03:00:40 +
On Sun, 2011-01-09 at 01:05 +, Richard
From: Richard Mortimer ri...@oldelvet.org.uk
Date: Thu, 13 Jan 2011 23:34:01 +
On Wed, 2011-01-12 at 00:37 +, Ben Hutchings wrote:
On Wed, 2011-01-12 at 00:27 +, Richard Mortimer wrote:
On 09/01/2011 03:46, David Miller wrote:
From: Ben Hutchingsb...@decadent.org.uk
Date:
On 09/01/2011 03:46, David Miller wrote:
From: Ben Hutchingsb...@decadent.org.uk
Date: Sun, 09 Jan 2011 03:00:40 +
On Sun, 2011-01-09 at 01:05 +, Richard Mortimer wrote:
Package: linux-2.6
Version: 2.6.37-1~experimental.1
Severity: normal
Boot of linux-image-2.6.37-trunk-sparc64
On Wed, 2011-01-12 at 00:27 +, Richard Mortimer wrote:
On 09/01/2011 03:46, David Miller wrote:
From: Ben Hutchingsb...@decadent.org.uk
Date: Sun, 09 Jan 2011 03:00:40 +
On Sun, 2011-01-09 at 01:05 +, Richard Mortimer wrote:
Package: linux-2.6
Version:
Package: linux-2.6
Version: 2.6.37-1~experimental.1
Severity: normal
Boot of linux-image-2.6.37-trunk-sparc64 fails to find the disks and drops
to the initramfs prompt. When I try to load the sym53c8xx driver it fails
as follows
(initramfs) modprobe sym53c8xx
[ 122.470284] module scsi_mod:
On Sun, 2011-01-09 at 01:05 +, Richard Mortimer wrote:
Package: linux-2.6
Version: 2.6.37-1~experimental.1
Severity: normal
Boot of linux-image-2.6.37-trunk-sparc64 fails to find the disks and drops
to the initramfs prompt. When I try to load the sym53c8xx driver it fails
as follows
From: Ben Hutchings b...@decadent.org.uk
Date: Sun, 09 Jan 2011 03:00:40 +
On Sun, 2011-01-09 at 01:05 +, Richard Mortimer wrote:
Package: linux-2.6
Version: 2.6.37-1~experimental.1
Severity: normal
Boot of linux-image-2.6.37-trunk-sparc64 fails to find the disks and drops
to the
82 matches
Mail list logo
