On 5 Jul 2007, at 23:27, Rod Whitby wrote:
Alan Cox wrote:
Chipsets
ARTOP
No reports, but nobody appears to be using one
The NSLU2-Linux project (http://www.nslu2-linux.org) relies on the
pata-artop driver for the arm/ixp4xx-based Iomega NAS100d and D-Link
DSM-G600 NAS
On 5 Jul 2007, at 23:27, Rod Whitby wrote:
Alan Cox wrote:
Chipsets
ARTOP
No reports, but nobody appears to be using one
The NSLU2-Linux project (http://www.nslu2-linux.org) relies on the
pata-artop driver for the arm/ixp4xx-based Iomega NAS100d and D-Link
DSM-G600 NAS
Richard Purdie wrote:
> Index: linux-2.6.21/lib/Kconfig
> ===
> --- linux-2.6.21.orig/lib/Kconfig 2007-06-04 12:19:37.0 +0100
> +++ linux-2.6.21/lib/Kconfig 2007-06-04 12:19:46.0 +0100
> @@ -71,6 +71,11 @@ config
Richard Purdie wrote:
Index: linux-2.6.21/lib/Kconfig
===
--- linux-2.6.21.orig/lib/Kconfig 2007-06-04 12:19:37.0 +0100
+++ linux-2.6.21/lib/Kconfig 2007-06-04 12:19:46.0 +0100
@@ -71,6 +71,11 @@ config
Andrew Morton wrote:
> Lots of git goodies there - I didn't actually receive the patch: the parts
> which move files around were communicated via git metadata, not diffs.
> Presumably there's a way to tell git to not do that.
>
> But probably it's best that this change be merged via git anyway.
Satyam Sharma wrote:
> Ugh, I wish you had held on from this patch till the original thread
> discussing this reached some conclusion ... from Mark's response
> there it does seem PRESET_DICT is clearly an implementation
> (and not interface) detail -- which means to me that it must continue
> to
Andrew Morton wrote:
Lots of git goodies there - I didn't actually receive the patch: the parts
which move files around were communicated via git metadata, not diffs.
Presumably there's a way to tell git to not do that.
But probably it's best that this change be merged via git anyway.
Satyam Sharma wrote:
Ugh, I wish you had held on from this patch till the original thread
discussing this reached some conclusion ... from Mark's response
there it does seem PRESET_DICT is clearly an implementation
(and not interface) detail -- which means to me that it must continue
to live
zlib
header include/linux/zlib.h.
Conditional compile of only inflate or deflate code is
preserved by this patch. With a bit of luck, this version
won't be whitespace-damaged. Grumble.
Signed-off-by: Michael-Luke Jones <[EMAIL PROTECTED]>
diff --git a/fs/jffs2/compr_zlib.c b/fs/jffs2/compr_
zlib header
include/linux/zlib.h. This move is documented in comments.
Conditional compile of only inflate or deflate code is
preserved by this patch.
Signed-off-by: Michael-Luke Jones <[EMAIL PROTECTED]>
diff --git a/fs/jffs2/compr_zlib.c b/fs/jffs2/compr_zlib.c
index 2b87fcc..e2cc6c7
right now, unfortunately,
Michael-Luke Jones
[added David Whitehouse to cc]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Rafael J. Wysocki wrote:
On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
The shiny userspace firmware loading causes problems since it exists,
every second box has problems with it, in all sorts of situations. If
people are still sold to the idea of userspace firmware loading, why
don't we
On 29 May 2007, at 11:41, Satyam Sharma wrote:
This is syntactically correct (and wouldn't produce any build errors),
but it's quite ... strange, still. Why would I even want to /build/
the
compress code if all I selected was the decompress option?
Apologies, you gave me the answer I was
On 28 May 2007, at 15:34, Nitin Gupta wrote:
diff --git a/lib/Kconfig b/lib/Kconfig
index 2e7ae6b..eb95eaa 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -64,6 +64,12 @@ config ZLIB_INFLATE
config ZLIB_DEFLATE
tristate
+config LZO1X_COMPRESS
+ tristate
+
+config LZO1X_DECOMPRESS
+
On 28 May 2007, at 18:11, Adrian Bunk wrote:
I have not seen any explanations:
- Why did the upstream author write the code that way?
Apparently due to his requirement for extreme portability. The
original code was designed to work on everything from 16-bit DOS
through CRAY supercomputers
On 28 May 2007, at 18:11, Adrian Bunk wrote:
I have not seen any explanations:
- Why did the upstream author write the code that way?
Apparently due to his requirement for extreme portability. The
original code was designed to work on everything from 16-bit DOS
through CRAY supercomputers
On 28 May 2007, at 15:34, Nitin Gupta wrote:
diff --git a/lib/Kconfig b/lib/Kconfig
index 2e7ae6b..eb95eaa 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -64,6 +64,12 @@ config ZLIB_INFLATE
config ZLIB_DEFLATE
tristate
+config LZO1X_COMPRESS
+ tristate
+
+config LZO1X_DECOMPRESS
+
On 29 May 2007, at 11:41, Satyam Sharma wrote:
This is syntactically correct (and wouldn't produce any build errors),
but it's quite ... strange, still. Why would I even want to /build/
the
compress code if all I selected was the decompress option?
Apologies, you gave me the answer I was
Rafael J. Wysocki wrote:
On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
The shiny userspace firmware loading causes problems since it exists,
every second box has problems with it, in all sorts of situations. If
people are still sold to the idea of userspace firmware loading, why
don't we
, unfortunately,
Michael-Luke Jones
[added David Whitehouse to cc]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
zlib header
include/linux/zlib.h. This move is documented in comments.
Conditional compile of only inflate or deflate code is
preserved by this patch.
Signed-off-by: Michael-Luke Jones [EMAIL PROTECTED]
diff --git a/fs/jffs2/compr_zlib.c b/fs/jffs2/compr_zlib.c
index 2b87fcc..e2cc6c7 100644
zlib
header include/linux/zlib.h.
Conditional compile of only inflate or deflate code is
preserved by this patch. With a bit of luck, this version
won't be whitespace-damaged. Grumble.
Signed-off-by: Michael-Luke Jones [EMAIL PROTECTED]
diff --git a/fs/jffs2/compr_zlib.c b/fs/jffs2/compr_zlib.c
/ uevents, there is no such documentation. Thus, what
kernelspace / userspace interactions actually are and what they
should be is unclear, leading to confusion over corner cases, such as
this one.
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubscribe linux-k
On 28 May 2007, at 12:51, Kay Sievers wrote:
Either the whole idea of userspace firmware-loading should be
considered
as a problem impossible to do right because of its unsolvable side
effects. Or at least releasing loaded firmware should be the exception
for drivers which can be sure, that
...
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
of this API.
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
? Not on the surface, but if the device loads root
over this device, it suddenly is.
This functionality should also be written into the firmware-class
(and this fact *is* acknowledged in the sparse documentation).
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubs
On 28 May 2007, at 07:59, Nitin Gupta wrote:
If we get no perf. problems with this patch, then I beleive it is now
suitable to inclusion in mainline. Further cleanups and optimizations
can surely be done after that. It's still just ~500 LOC.
Before LZO code is sent to Linus, its selection in
this in an earlier email and suggested rejecting
this patchset on the grounds that it was another bodge covering over
a fundamentally broken area of the kernel :)
Kay
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
.
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 28 May 2007, at 08:43, Rafael J. Wysocki wrote:
Seems, that's just the broken synchronous firmware loading interface
with the useless timeout handling. The nowait version of the same
loader
doesn't time out, and should not have that problem. The sync version
should be removed from the
On 28 May 2007, at 08:43, Rafael J. Wysocki wrote:
Seems, that's just the broken synchronous firmware loading interface
with the useless timeout handling. The nowait version of the same
loader
doesn't time out, and should not have that problem. The sync version
should be removed from the
.
Michael-Luke Jones
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
this in an earlier email and suggested rejecting
this patchset on the grounds that it was another bodge covering over
a fundamentally broken area of the kernel :)
Kay
Michael-Luke Jones
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On 28 May 2007, at 07:59, Nitin Gupta wrote:
If we get no perf. problems with this patch, then I beleive it is now
suitable to inclusion in mainline. Further cleanups and optimizations
can surely be done after that. It's still just ~500 LOC.
Before LZO code is sent to Linus, its selection in
? Not on the surface, but if the device loads root
over this device, it suddenly is.
This functionality should also be written into the firmware-class
(and this fact *is* acknowledged in the sparse documentation).
Michael-Luke Jones
-
To unsubscribe from this list: send the line unsubscribe
of this API.
Michael-Luke Jones
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
...
Michael-Luke Jones
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 28 May 2007, at 12:51, Kay Sievers wrote:
Either the whole idea of userspace firmware-loading should be
considered
as a problem impossible to do right because of its unsolvable side
effects. Or at least releasing loaded firmware should be the exception
for drivers which can be sure, that
/ uevents, there is no such documentation. Thus, what
kernelspace / userspace interactions actually are and what they
should be is unclear, leading to confusion over corner cases, such as
this one.
Michael-Luke Jones
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
be preferred, and preferably
one which allows firmware loading to *actually* occur once userspace
has actually turned up and registered a handler :)
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
, and preferably
one which allows firmware loading to *actually* occur once userspace
has actually turned up and registered a handler :)
Michael-Luke Jones
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On 25 May 2007, at 11:42, Pavel Machek wrote:
What is the performance difference between safe and unsafe version?
On 24 May 2007, at 23:26, Richard Purdie wrote:
For my minilzo kernel patch, the safe version showed a 7.2%
performance
hit.
The conclusion seemed to be that we should drop
On 25 May 2007, at 11:42, Pavel Machek wrote:
What is the performance difference between safe and unsafe version?
On 24 May 2007, at 23:26, Richard Purdie wrote:
For my minilzo kernel patch, the safe version showed a 7.2%
performance
hit.
The conclusion seemed to be that we should drop
On 25 May 2007, at 12:45, Nitin Gupta wrote:
Hi,
This is kernel port of LZO1X compressor and LZO1X decompressor (safe
version only).
Hey there,
It's looking better now. Just wondering if you might want to separate
out the Kconfig options for lzo compress / decompress so that it's
On 25 May 2007, at 12:45, Nitin Gupta wrote:
Hi,
This is kernel port of LZO1X compressor and LZO1X decompressor (safe
version only).
Hey there,
It's looking better now. Just wondering if you might want to separate
out the Kconfig options for lzo compress / decompress so that it's
On 24 May 2007, at 19:50, Andrew Morton wrote:
On Thu, 24 May 2007 18:15:17 +0100
Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
Attached is a patch which may be desirable for -mm. It applies
directly to 2.6.22-rc2-mm1.
The patch removes the 'unsafe' LZO decompression function, lo
welcome :)
Michael-Luke Jones
lzo-remove-unsafe-decompressor.patch
Description: Binary data
welcome :)
Michael-Luke Jones
lzo-remove-unsafe-decompressor.patch
Description: Binary data
On 24 May 2007, at 19:50, Andrew Morton wrote:
On Thu, 24 May 2007 18:15:17 +0100
Michael-Luke Jones [EMAIL PROTECTED] wrote:
Attached is a patch which may be desirable for -mm. It applies
directly to 2.6.22-rc2-mm1.
The patch removes the 'unsafe' LZO decompression function, lowering
On 23 May 2007, at 15:21, Nitin Gupta wrote:
If somebody is up to including compression he must be having head
to use the right
decompress version depending on this scenario :-)
By that logic, experienced kernel dev Richard Purdie is not up to
using compression (?!)
To me, it looks like
On 23 May 2007, at 15:03, Nitin Gupta wrote:
Perhaps a rename is in order:
lzo1x_decompress() => lzo1x_decompress_unsafe()
lzo1x_decompress_safe => lzo1x_decompress()
Or perhaps make reiserfs use _safe() instead - I think Richard has
already submitted patch for same.
If someone's already
On 23 May 2007, at 12:39, Nitin Gupta wrote:
Hi Michael,
On 5/23/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
I understand that the 'safe' decompression code is 'somewhat slower'
and that decompressor performance is a key feature of this algorithm.
However, I am concerned
with
this one. To me, at least, even if the answer is 'no, there isn't a
problem' that's still a valuable clarification :)
Thanks,
Michael-Luke Jones
[please cc me on replies as I am not subscribed to lkml]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
with
this one. To me, at least, even if the answer is 'no, there isn't a
problem' that's still a valuable clarification :)
Thanks,
Michael-Luke Jones
[please cc me on replies as I am not subscribed to lkml]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On 23 May 2007, at 12:39, Nitin Gupta wrote:
Hi Michael,
On 5/23/07, Michael-Luke Jones [EMAIL PROTECTED] wrote:
I understand that the 'safe' decompression code is 'somewhat slower'
and that decompressor performance is a key feature of this algorithm.
However, I am concerned about the safety
On 23 May 2007, at 15:03, Nitin Gupta wrote:
Perhaps a rename is in order:
lzo1x_decompress() = lzo1x_decompress_unsafe()
lzo1x_decompress_safe = lzo1x_decompress()
Or perhaps make reiserfs use _safe() instead - I think Richard has
already submitted patch for same.
If someone's already made
On 23 May 2007, at 15:21, Nitin Gupta wrote:
If somebody is up to including compression he must be having head
to use the right
decompress version depending on this scenario :-)
By that logic, experienced kernel dev Richard Purdie is not up to
using compression (?!)
To me, it looks like
On 16 May 2007, at 10:41, Lennert Buytenhek wrote:
Making a driver work in both modes
of operation is generally not just an issue of adding a couple of
be32_to_cpu()s in the right places.
While this comment is technically correct, Christian's driver
achieves endian agnostic operation with
implementation LE implementation can be
viewed here:
http://www.hohnstaedt.de/ixp_npe/0.3.1/ixp4xx_npe_driver-0.3.1.diff
Search in this file for "swap the payload of the SKB" (it's in
mac_driver.c)
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubscri
implementation LE implementation can be
viewed here:
http://www.hohnstaedt.de/ixp_npe/0.3.1/ixp4xx_npe_driver-0.3.1.diff
Search in this file for swap the payload of the SKB (it's in
mac_driver.c)
Michael-Luke Jones
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On 16 May 2007, at 10:41, Lennert Buytenhek wrote:
Making a driver work in both modes
of operation is generally not just an issue of adding a couple of
be32_to_cpu()s in the right places.
While this comment is technically correct, Christian's driver
achieves endian agnostic operation with
On 9 May 2007, at 15:22, David Acker wrote:
Big endian is the natural setup for the NPEs on this hardware
according to the intel documentation. Please don't stop this
driver from moving forward so that a few folks can run their
hardware in slow mode.
No-one is saying that this driver
On 9 May 2007, at 15:22, David Acker wrote:
Big endian is the natural setup for the NPEs on this hardware
according to the intel documentation. Please don't stop this
driver from moving forward so that a few folks can run their
hardware in slow mode.
No-one is saying that this driver
On 8 May 2007, at 09:48, Alexey Zaytsev wrote:
I was always curious, why do people want to run ixp4xx in LE mode?
What
are the benefits that overweight the obvious performance degradation?
Debian.
http://www.debian.org/ports/arm/
Michael-Luke
-
To unsubscribe from this list: send the line
On 8 May 2007, at 09:26, Mikael Pettersson wrote:
On Tue, 8 May 2007 08:22:17 +0100, Michael-Luke Jones wrote:
AFAIK, it's a HW limitation of the IXP4xx NPEs, or
possibly Intel's microcode for them.
I run my IXP42x boxes big-endian and don't mind doing so.
/Mikael
*cough*
http
enable the
HssPacketized
+ operation for the flow specified by pPipe */
Greater-than-one-line comments not conforming to Kernel coding style
- someone much more angry than me will jump on that.
+#define PKT_PIPE_FLOW_ENABLE 0x50
+#define PKT_PIPE_FLOW_DISABLE
On 8 May 2007, at 01:46, Krzysztof Halasa wrote:
Adds a driver for built-in IXP4xx hardware Queue Manager.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
[snip]
diff --git a/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c b/arch/arm/mach-
ixp4xx/ixp4xx_qmgr.c
new file mode 100644
index
On 8 May 2007, at 01:36, Krzysztof Halasa wrote:
Adds a driver for built-in IXP4xx Network Processor Engines.
This patch requires IXP4xx Queue Manager driver and the "fuses" patch.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
[snip]
diff --git a/arch/arm/mach-ixp4xx/ixp4xx_npe.c
On 8 May 2007, at 01:36, Krzysztof Halasa wrote:
Adds a driver for built-in IXP4xx Network Processor Engines.
This patch requires IXP4xx Queue Manager driver and the fuses patch.
Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED]
[snip]
diff --git a/arch/arm/mach-ixp4xx/ixp4xx_npe.c
On 8 May 2007, at 01:46, Krzysztof Halasa wrote:
Adds a driver for built-in IXP4xx hardware Queue Manager.
Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED]
[snip]
diff --git a/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c b/arch/arm/mach-
ixp4xx/ixp4xx_qmgr.c
new file mode 100644
index
], *tx_skb_tab[TX_DESCS];
+ struct desc *desc_tab; /* coherent */
+ u32 desc_tab_phys;
+ sync_serial_settings settings;
+ int id;
+ u8 hdlc_cfg;
+};
+
[snip]
Again, looking good.
Michael-Luke Jones
-
To unsubscribe from this list: send the line unsubscribe linux
On 8 May 2007, at 09:26, Mikael Pettersson wrote:
On Tue, 8 May 2007 08:22:17 +0100, Michael-Luke Jones wrote:
AFAIK, it's a HW limitation of the IXP4xx NPEs, or
possibly Intel's microcode for them.
I run my IXP42x boxes big-endian and don't mind doing so.
/Mikael
*cough*
http
On 8 May 2007, at 09:48, Alexey Zaytsev wrote:
I was always curious, why do people want to run ixp4xx in LE mode?
What
are the benefits that overweight the obvious performance degradation?
Debian.
http://www.debian.org/ports/arm/
Michael-Luke
-
To unsubscribe from this list: send the line
[Added Lennert Buytenhek to CC list]
Hey again,
Code placement:
Queue Manager & NPE code => arch/arm/mach-ixp4xx
WAN driver code => drivers/net/wan
Eth code => drivers/net/arm
Why would you want such placement?
Potential problems: header files would have to be moved to
include/asm-arm =
in arch/arm/mach-
ixp4xx/Kconfig
Michael-Luke Jones
PS: Please cc me on replies as I only subscribe to l-a-k.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/major
[Added Lennert Buytenhek to CC list]
Hey again,
Code placement:
Queue Manager NPE code = arch/arm/mach-ixp4xx
WAN driver code = drivers/net/wan
Eth code = drivers/net/arm
Why would you want such placement?
Potential problems: header files would have to be moved to
include/asm-arm = headers
/net/arm
Kconfig:
I'm not convinced about 'config IXP4XX_NETDEVICES'. I'd lose it
together with the drivers/net/ixp4xx directory
Ethernet HSS code should probably select NPE and QMGR (rather than
depend) but these options should still be exposed in arch/arm/mach-
ixp4xx/Kconfig
Michael-Luke
But using 'fakeraid' (i.e. BIOS RAID) together with dmraid is
generally discouraged in favour of using the more stable and well
supported Linux Software RAID functionality.
Michael-Luke
On 24 Feb 2007, at 15:24, Bartlomiej Zolnierkiewicz wrote:
use device mapper and dmraid
But using 'fakeraid' (i.e. BIOS RAID) together with dmraid is
generally discouraged in favour of using the more stable and well
supported Linux Software RAID functionality.
Michael-Luke
On 24 Feb 2007, at 15:24, Bartlomiej Zolnierkiewicz wrote:
use device mapper and dmraid
NB: I'm not subscribed so please CC me in any reply! Thanks...
Updated bugzilla with x86 defconfig demonstrating similar breakage.
http://bugzilla.kernel.org/show_bug.cgi?id=8050
Both issues seem to demonstrate a problem with built-in NFS and
modular IPV6 together.
Michael-Luke Jones
On 21
NB: I'm not subscribed so please CC me in any reply! Thanks...
Updated bugzilla with x86 defconfig demonstrating similar breakage.
http://bugzilla.kernel.org/show_bug.cgi?id=8050
Both issues seem to demonstrate a problem with built-in NFS and
modular IPV6 together.
Michael-Luke Jones
On 21
Kernel Bugzilla bug created:
http://bugzilla.kernel.org/show_bug.cgi?id=8050
Michael-Luke Jones
On 21 Feb 2007, at 14:36, Michael-Luke Jones wrote:
Apologies for brain failure, below should read 2.6.21-rc1.
Everything else should be correct.
Michael-Luke Jones
On 21 Feb 2007, at 10:50, M.L
Apologies for brain failure, below should read 2.6.21-rc1.
Everything else should be correct.
Michael-Luke Jones
On 21 Feb 2007, at 10:50, M.L. Jones wrote:
NB: I'm not subscribed so please CC me in any reply! Thanks...
Hi there,
Just attempted a build of vanilla 2.6.20-rc1 and got
Apologies for brain failure, below should read 2.6.21-rc1.
Everything else should be correct.
Michael-Luke Jones
On 21 Feb 2007, at 10:50, M.L. Jones wrote:
NB: I'm not subscribed so please CC me in any reply! Thanks...
Hi there,
Just attempted a build of vanilla 2.6.20-rc1 and got
Kernel Bugzilla bug created:
http://bugzilla.kernel.org/show_bug.cgi?id=8050
Michael-Luke Jones
On 21 Feb 2007, at 14:36, Michael-Luke Jones wrote:
Apologies for brain failure, below should read 2.6.21-rc1.
Everything else should be correct.
Michael-Luke Jones
On 21 Feb 2007, at 10:50, M.L
86 matches
Mail list logo
