Karl Dahlke wrote:
> Meantime, I pulled the emails out of the headers and pasted them in.
> Hope that reasonably works.
Well, you're still breaking the thread by starting a new one.
Guess when you're implementing reply-to-all, you should also think about
implementing support for In-Reply-To: and
Karl Dahlke wrote:
Meantime, I pulled the emails out of the headers and pasted them in.
Hope that reasonably works.
Well, you're still breaking the thread by starting a new one.
Guess when you're implementing reply-to-all, you should also think about
implementing support for In-Reply-To: and
On Tuesday 19 February 2008, Adrian Bunk wrote:
> The "or any other emulator" is exactly where my question is directed at.
>
> Xen, KVM or even qemu come into my mind, but considering how loudly you
> complained about a temporary breakage for VirtualBox there must be a
> reason why your work on
On Sunday 17 February 2008, Arjan van de Ven wrote:
> On Sun, 17 Feb 2008 14:38:51 -0600 Paul Jackson <[EMAIL PROTECTED]> wrote:
> > Adrian wrote:
> > > So let's fix the problem (kernel lacks functionality)
> >
> > That's the problem as understood by Adrian.
> >
> > I hear another problem as well
On Sunday 17 February 2008, Adrian Bunk wrote:
> The real problem is that the kernel seems to lack functionality you
> require for doing some work.
Not sure how you reached that conclusion.
> Why does your work on the Debian Installer depend on VirtualBox and
> can't be done with what the kernel
On Sunday 17 February 2008, Adrian Bunk wrote:
The real problem is that the kernel seems to lack functionality you
require for doing some work.
Not sure how you reached that conclusion.
Why does your work on the Debian Installer depend on VirtualBox and
can't be done with what the kernel
On Sunday 17 February 2008, Arjan van de Ven wrote:
On Sun, 17 Feb 2008 14:38:51 -0600 Paul Jackson [EMAIL PROTECTED] wrote:
Adrian wrote:
So let's fix the problem (kernel lacks functionality)
That's the problem as understood by Adrian.
I hear another problem as well ...
Frans
On Tuesday 19 February 2008, Adrian Bunk wrote:
The or any other emulator is exactly where my question is directed at.
Xen, KVM or even qemu come into my mind, but considering how loudly you
complained about a temporary breakage for VirtualBox there must be a
reason why your work on the
Jeff Garzik wrote:
> Two x86-64 boxes here lock up here on 2.6.25-rc2, shortly after boot.
> One running Fedora 8 + X (GNOME) and one a headless file server.
> configs and lspci attached. Unable to capture any splatter so far.
Sounds like it may be http://lkml.org/lkml/2008/2/17/78.
Suggest you
On Monday 18 February 2008, Mike Galbraith wrote:
> On Mon, 2008-02-18 at 09:46 +0100, Frans Pop wrote:
> > Joerg Schilling wrote:
> > > This fragment is much too short to allow to judge on possible
> > > reasons. There is a high probability that your problem is caused
Joerg Schilling wrote:
> This fragment is much too short to allow to judge on possible reasons.
> There is a high probability that your problem is caused by the cdrecord
> fork called "wodim".
There is also the 100% certainty that this reply was from a known troll and
should just be ignored.
--
Joerg Schilling wrote:
This fragment is much too short to allow to judge on possible reasons.
There is a high probability that your problem is caused by the cdrecord
fork called wodim.
There is also the 100% certainty that this reply was from a known troll and
should just be ignored.
--
To
On Monday 18 February 2008, Mike Galbraith wrote:
On Mon, 2008-02-18 at 09:46 +0100, Frans Pop wrote:
Joerg Schilling wrote:
This fragment is much too short to allow to judge on possible
reasons. There is a high probability that your problem is caused by
the cdrecord fork called wodim
Jeff Garzik wrote:
Two x86-64 boxes here lock up here on 2.6.25-rc2, shortly after boot.
One running Fedora 8 + X (GNOME) and one a headless file server.
configs and lspci attached. Unable to capture any splatter so far.
Sounds like it may be http://lkml.org/lkml/2008/2/17/78.
Suggest you
On Sunday 17 February 2008, Daniel Barkalow wrote:
> On Sun, 17 Feb 2008, Frans Pop wrote:
> > Daniel Barkalow wrote:
> > > For some reason I can't see and don't know how to debug, in 2.6.23 on
> > > my server I don't get the vga console, but only get the dummy
> >
Yesterday, after spending quite a few hours over the last days on bisecting
some serious regressions and finding workarounds for them, I thought I
could start using 2.6.25-rc2 as the new kernel for my desktop.
Unfortunately I found that I cannot because it would make my other main
activity -
Yesterday, after spending quite a few hours over the last days on bisecting
some serious regressions and finding workarounds for them, I thought I
could start using 2.6.25-rc2 as the new kernel for my desktop.
Unfortunately I found that I cannot because it would make my other main
activity -
On Sunday 17 February 2008, Daniel Barkalow wrote:
On Sun, 17 Feb 2008, Frans Pop wrote:
Daniel Barkalow wrote:
For some reason I can't see and don't know how to debug, in 2.6.23 on
my server I don't get the vga console, but only get the dummy
console.
Please check if this bug
Daniel Barkalow wrote:
> For some reason I can't see and don't know how to debug, in 2.6.23 on my
> server I don't get the vga console, but only get the dummy console.
Please check if this bug report matches the issue you are seeing:
http://bugzilla.kernel.org/show_bug.cgi?id=9310
Cheers,
FJP
--
Daniel Barkalow wrote:
For some reason I can't see and don't know how to debug, in 2.6.23 on my
server I don't get the vga console, but only get the dummy console.
Please check if this bug report matches the issue you are seeing:
http://bugzilla.kernel.org/show_bug.cgi?id=9310
Cheers,
FJP
--
On Friday 15 February 2008, Greg KH wrote:
> I swear someone sent this patch in before. Can you try this one below,
> there seems to be an imbalance with kobject_get and _put.
I did remember seeing this patch before [1] and can confirm that it does
indeed fix the issue: with this patch applied
On Friday 15 February 2008, Greg KH wrote:
I swear someone sent this patch in before. Can you try this one below,
there seems to be an imbalance with kobject_get and _put.
I did remember seeing this patch before [1] and can confirm that it does
indeed fix the issue: with this patch applied to
On Thursday 14 February 2008, Thomas Gleixner wrote:
> futex_lock_pi is called with an absolute timeout, which is based on
> CLOCK_REALTIME. Nothing wrong with that, but the clockevents WARN_ON
> might trap over a false positive, when the expiry value is less than
> base->offset. This was
On Thursday 14 February 2008, Thomas Gleixner wrote:
futex_lock_pi is called with an absolute timeout, which is based on
CLOCK_REALTIME. Nothing wrong with that, but the clockevents WARN_ON
might trap over a false positive, when the expiry value is less than
base-offset. This was intentional
On Wednesday 13 February 2008, Thomas Gleixner wrote:
> can you please apply the following patch ? I really should have
> thought about that, when I fixed the above one.
I still get the bug with this patch. At least I'm now certain it happens
during glibc compilation and that I can reproduce it.
On Wednesday 13 February 2008, Greg KH wrote:
> > So, just on the off chance, I applied the patch below and bingo, the
> > system powers off again. I doubt this will be the correct solution, but
> > just in case it is, here's my signed off. A comment why the double put
> > is needed would probably
From: Frans Pop <[EMAIL PROTECTED]>
Hook scripts in the default directory /etc/kernel are also
executed by packages created using make-kpkg (including official
Debian kernels). Allow to specify an alternative hook scripts
directory by exporting the environment variable KERNELDEBHOOK
On Tuesday 12 February 2008, Greg KH wrote:
> On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote:
> > On Monday 11 February 2008, Frans Pop wrote:
> > > In general 2.6.25 if looking quite good on my desktop, but there's
> > > one important issue: the system
From: Frans Pop <[EMAIL PROTECTED]>
Allow to specify a custom revision for the generated .deb package
by exporting the environment variable KERNELDEBREVISION.
Signed-off-by: Frans Pop <[EMAIL PROTECTED]>
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index ba6b
On Wednesday 13 February 2008, you wrote:
> On Tue, 12 Feb 2008 22:45:09 +0100 Frans Pop <[EMAIL PROTECTED]> wrote:
> > Symptom is that the system shuts down normally and completely, it just
> > does not power off.
>
> I've been struggling with an identically-manifestin
On Wednesday 13 February 2008, Thomas Gleixner wrote:
> On Tue, 12 Feb 2008, Andrew Morton wrote:
> > On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop <[EMAIL PROTECTED]> wrote:
> > the hrtimer code is preparing an invalid ktime_t. Note that
> > clockevents_program_
On Monday 11 February 2008, Frans Pop wrote:
> In general 2.6.25 if looking quite good on my desktop, but there's one
> important issue: the system no longer powers off after shutdown.
> This works fine with 2.6.24.
I was wrong :-(
I'd not really done any real wor under 2.6.25 yet
On Monday 11 February 2008, Frans Pop wrote:
In general 2.6.25 if looking quite good on my desktop, but there's one
important issue: the system no longer powers off after shutdown.
This works fine with 2.6.24.
I was wrong :-(
I'd not really done any real wor under 2.6.25 yet, but now
On Wednesday 13 February 2008, Thomas Gleixner wrote:
On Tue, 12 Feb 2008, Andrew Morton wrote:
On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop [EMAIL PROTECTED] wrote:
the hrtimer code is preparing an invalid ktime_t. Note that
clockevents_program_event() actually fails when this happens - I
On Wednesday 13 February 2008, you wrote:
On Tue, 12 Feb 2008 22:45:09 +0100 Frans Pop [EMAIL PROTECTED] wrote:
Symptom is that the system shuts down normally and completely, it just
does not power off.
I've been struggling with an identically-manifesting regression on one of
my test
From: Frans Pop [EMAIL PROTECTED]
Allow to specify a custom revision for the generated .deb package
by exporting the environment variable KERNELDEBREVISION.
Signed-off-by: Frans Pop [EMAIL PROTECTED]
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index ba6bf5d..2577dec 100644
On Tuesday 12 February 2008, Greg KH wrote:
On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote:
On Monday 11 February 2008, Frans Pop wrote:
In general 2.6.25 if looking quite good on my desktop, but there's
one important issue: the system no longer powers off after shutdown
From: Frans Pop [EMAIL PROTECTED]
Hook scripts in the default directory /etc/kernel are also
executed by packages created using make-kpkg (including official
Debian kernels). Allow to specify an alternative hook scripts
directory by exporting the environment variable KERNELDEBHOOKDIR
so
On Wednesday 13 February 2008, Greg KH wrote:
So, just on the off chance, I applied the patch below and bingo, the
system powers off again. I doubt this will be the correct solution, but
just in case it is, here's my signed off. A comment why the double put
is needed would probably be good
On Wednesday 13 February 2008, Thomas Gleixner wrote:
can you please apply the following patch ? I really should have
thought about that, when I fixed the above one.
I still get the bug with this patch. At least I'm now certain it happens
during glibc compilation and that I can reproduce it.
On Tuesday 12 February 2008, Greg KH wrote:
> On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote:
> > On Monday 11 February 2008, Frans Pop wrote:
> > > In general 2.6.25 if looking quite good on my desktop, but there's
> > > one important issue: the system
On Tuesday 12 February 2008, Greg KH wrote:
On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote:
On Monday 11 February 2008, Frans Pop wrote:
In general 2.6.25 if looking quite good on my desktop, but there's
one important issue: the system no longer powers off after shutdown
On Sunday 10 February 2008, Frans Pop wrote:
> I have no idea yet what triggers it and am unsure if I'll be able to
> reproduce.
I think I know at least _when_ it happens: during compilation of glibc.
This was almost certainly while compiling in the normal amd64 environment:
> Pid: 2
Kernel: vanilla 2.6.24 x86_64 SMP
Environment: Debian unstable
Processor: Intel(R) Pentium(R) D CPU 3.20GHz (dual core)
I've been running this kernel without problems since its release, but
yesterday evening I suddenly got the following error, and this afternoon it
was repeated (below). The
Kernel: vanilla 2.6.24 x86_64 SMP
Environment: Debian unstable
Processor: Intel(R) Pentium(R) D CPU 3.20GHz (dual core)
I've been running this kernel without problems since its release, but
yesterday evening I suddenly got the following error, and this afternoon it
was repeated (below). The
On Sunday 10 February 2008, Frans Pop wrote:
I have no idea yet what triggers it and am unsure if I'll be able to
reproduce.
I think I know at least _when_ it happens: during compilation of glibc.
This was almost certainly while compiling in the normal amd64 environment:
Pid: 2210, comm: ld
Sam Ravnborg wrote:
> The apm module were renamed to apm_32 during the merge of 32 and 64 bit
> x86 which is unfortunate.
> As apm is 32 bit specific we like to keep the _32 in the filename
> but the module should be named apm.
>
> Fix this in the Makefile.
> Reported by "A.E.Lawrence" <[EMAIL
Sam Ravnborg wrote:
The apm module were renamed to apm_32 during the merge of 32 and 64 bit
x86 which is unfortunate.
As apm is 32 bit specific we like to keep the _32 in the filename
but the module should be named apm.
Fix this in the Makefile.
Reported by A.E.Lawrence [EMAIL PROTECTED]
Sam Ravnborg wrote:
> --- a/scripts/setlocalversion
> +++ b/scripts/setlocalversion
> @@ -45,3 +45,18 @@ if hgid=`hg id 2>/dev/null`; then
> # All done with mercurial
> exit
> fi
> +
> +# Check for svn and a svn repo.
> +if rev=`svn info 2>/dev/null | grep '^Revision' | awk '{print $NF}'` ; then
>
Peter Teoh wrote:
> In include/linux/init.h, it is documented that all __xxxinitdata
> declaration must not have constant, as show below:
See: http://lkml.org/lkml/2008/1/26/182
There's a fairly major cleanup happening at the moment as you could see from
the mailing list archives for the past
Peter Teoh wrote:
In include/linux/init.h, it is documented that all __xxxinitdata
declaration must not have constant, as show below:
See: http://lkml.org/lkml/2008/1/26/182
There's a fairly major cleanup happening at the moment as you could see from
the mailing list archives for the past week
Sam Ravnborg wrote:
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -45,3 +45,18 @@ if hgid=`hg id 2/dev/null`; then
# All done with mercurial
exit
fi
+
+# Check for svn and a svn repo.
+if rev=`svn info 2/dev/null | grep '^Revision' | awk '{print $NF}'` ; then
+
Forward to netdev list.
--- Forwarded message (begin)
Subject: Typo in net/netfilter/xt_iprange.c (git tree)
From: Jiri Moravec <...>
Date: Fri, 01 Feb 2008 15:50:15 +0100
Function iprange_mt4 belong to IPv4 family - AF_INET. Right?
.name = "iprange",
.revision
Forward to netdev list.
--- Forwarded message (begin)
Subject: Typo in net/netfilter/xt_iprange.c (git tree)
From: Jiri Moravec ...
Date: Fri, 01 Feb 2008 15:50:15 +0100
Function iprange_mt4 belong to IPv4 family - AF_INET. Right?
.name = iprange,
.revision =
Adrian Bunk wrote:
>> Jeff, Auke, would something like this be acceptable? It makes it very
>> obvious in the driver table which entries are for the PCIE versions that
>> would be handled by the E1000E driver if it is enabled..
>
> I don't like it:
> We should aim at having exactly one driver for
Adrian Bunk wrote:
Jeff, Auke, would something like this be acceptable? It makes it very
obvious in the driver table which entries are for the PCIE versions that
would be handled by the E1000E driver if it is enabled..
I don't like it:
We should aim at having exactly one driver for one
Frans Pop wrote:
> The help should probably be a bit more verbose as this does not tell
> anybody much who has not already read the documentation.
>
> Maybe something like:
>
> This device-mapper target allows to define how the
> available bandwith of a storage device shoul
On Saturday 26 January 2008, Bartlomiej Zolnierkiewicz wrote:
> On Saturday 26 January 2008, Jan Engelhardt wrote:
> > On Jan 26 2008 21:31, Frans Pop wrote:
> > >> config BLK_DEV_IDE_PMAC
> > >> - bool "Builtin PowerMac IDE support"
> >
Frans Pop wrote:
The help should probably be a bit more verbose as this does not tell
anybody much who has not already read the documentation.
Maybe something like:
snip
This device-mapper target allows to define how the
available bandwith of a storage device should be
shared between
> config BLK_DEV_IDE_PMAC
> - bool "Builtin PowerMac IDE support"
> + tristate "Builtin PowerMac IDE support"
This does not seem to make sense: if the option is now tristate, it is no
longer "Builtin", so probably s/Builtin // in the description.
Cheers,
FJP
--
To unsubscribe from
config BLK_DEV_IDE_PMAC
- bool Builtin PowerMac IDE support
+ tristate Builtin PowerMac IDE support
This does not seem to make sense: if the option is now tristate, it is no
longer Builtin, so probably s/Builtin // in the description.
Cheers,
FJP
--
To unsubscribe from this list:
On Friday 25 January 2008, Jochen Friedrich wrote:
> > Jochen Friedrich wrote:
> >> +++ b/drivers/net/fec.c
> >> @@ -23,6 +23,9 @@
> >> *
> >> * Bug fixes and cleanup by Philippe De Muyter ([EMAIL PROTECTED])
> >> * Copyright (c) 2004-2006 Macq Electronique SA.
> >> + *
> >> + * This driver
Jochen Friedrich wrote:
> +++ b/drivers/net/fec.c
> @@ -23,6 +23,9 @@
> *
> * Bug fixes and cleanup by Philippe De Muyter ([EMAIL PROTECTED])
> * Copyright (c) 2004-2006 Macq Electronique SA.
> + *
> + * This driver is now only used on ColdFire processors. Remove conditional
> + * Powerpc
Jochen Friedrich wrote:
+++ b/drivers/net/fec.c
@@ -23,6 +23,9 @@
*
* Bug fixes and cleanup by Philippe De Muyter ([EMAIL PROTECTED])
* Copyright (c) 2004-2006 Macq Electronique SA.
+ *
+ * This driver is now only used on ColdFire processors. Remove conditional
+ * Powerpc code.
On Friday 25 January 2008, Jochen Friedrich wrote:
Jochen Friedrich wrote:
+++ b/drivers/net/fec.c
@@ -23,6 +23,9 @@
*
* Bug fixes and cleanup by Philippe De Muyter ([EMAIL PROTECTED])
* Copyright (c) 2004-2006 Macq Electronique SA.
+ *
+ * This driver is now only used on
Hi,
I'm not qualified to comment on the code, but here are some suggestions on
config option and comments.
Cheers,
FJP
Ryo Tsuruta wrote:
> +config DM_BAND
> + tristate "I/O band width control "
s/band width/bandwidth/
(it seems to be used correctly elsewhere, but you may want to
Hi,
I'm not qualified to comment on the code, but here are some suggestions on
config option and comments.
Cheers,
FJP
Ryo Tsuruta wrote:
+config DM_BAND
+ tristate I/O band width control
s/band width/bandwidth/
(it seems to be used correctly elsewhere, but you may want to double-check)
Andi Kleen wrote:
> My workstation running 2.6.24-rc8 just hung during shutdown with an
> endless (or rather I didn't wait more than a few minutes) loop of
>
> unregister_netdev: waiting for ppp-device to become free. Usage count = 1
Same as http://lkml.org/lkml/2008/1/20/27? See also follow-up
Andi Kleen wrote:
My workstation running 2.6.24-rc8 just hung during shutdown with an
endless (or rather I didn't wait more than a few minutes) loop of
unregister_netdev: waiting for ppp-device to become free. Usage count = 1
Same as http://lkml.org/lkml/2008/1/20/27? See also follow-up to
Dave Young wrote:
> I noticed the port number changed to 40 in 2.6.24-rc8, but it's not
> enough for me still.
Same here, though the extreme noise has gone.
>From /proc/ioports and dmesg it looks like I'm short by either 1, or 3 :-(
Cheers,
FJP
--
To unsubscribe from this list: send the line
Dave Young wrote:
I noticed the port number changed to 40 in 2.6.24-rc8, but it's not
enough for me still.
Same here, though the extreme noise has gone.
From /proc/ioports and dmesg it looks like I'm short by either 1, or 3 :-(
Cheers,
FJP
--
To unsubscribe from this list: send the line
On Thursday 17 January 2008, David Miller wrote:
> From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
>
> > We spent Wednesday trying to reproduce (without the patch) these issues
> > without much luck, and have applied the patch cleanly and will continue
> > testing it. Given the simplicity of the
[EMAIL PROTECTED] wrote:
>8472457 Total 30486950 +259% 30342823 +258%
Hmmm. The table for previous versions looked a lot more impressive.
now:8472457 Total+22014493 +259% +21870366 +258%
V2 :7172678 Total+23314404 +325% -147590 -2%
On Wednesday 16 January 2008, David Miller wrote:
> Ok, here is the patch I'll propose to fix this. The goal is to make
> it as simple as possible without regressing the thing we were trying
> to fix.
Looks good to me. Tested with -rc8.
Cheers,
FJP
--
To unsubscribe from this list: send the
On Wednesday 16 January 2008, David Miller wrote:
Ok, here is the patch I'll propose to fix this. The goal is to make
it as simple as possible without regressing the thing we were trying
to fix.
Looks good to me. Tested with -rc8.
Cheers,
FJP
--
To unsubscribe from this list: send the line
[EMAIL PROTECTED] wrote:
8472457 Total 30486950 +259% 30342823 +258%
Hmmm. The table for previous versions looked a lot more impressive.
now:8472457 Total+22014493 +259% +21870366 +258%
V2 :7172678 Total+23314404 +325% -147590 -2%
On Tuesday 15 January 2008, David Miller wrote:
> From: Frans Pop <[EMAIL PROTECTED]>
> > kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
>
> Does this make the problem go away?
Yes, it very much looks like that solves it.
I ran with the patch for 6 hours or
On Tuesday 15 January 2008, David Miller wrote:
From: Frans Pop [EMAIL PROTECTED]
kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Does this make the problem go away?
Yes, it very much looks like that solves it.
I ran with the patch for 6 hours or so without any errors. I
Wow. That's fast! :-)
On Tuesday 15 January 2008, David Miller wrote:
> From: Frans Pop <[EMAIL PROTECTED]>
>
> > kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
>
> Does this make the problem go away?
I'm compiling a kernel with the patch now. Will let
After compiling v2.6.24-rc7-163-g1a1b285 (x86_64) yesterday I suddenly see this
error
repeatedly:
kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
kernel: Tx Queue <0>
kernel: TDH
kernel: TDT
kernel: next_to_use
After compiling v2.6.24-rc7-163-g1a1b285 (x86_64) yesterday I suddenly see this
error
repeatedly:
kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
kernel: Tx Queue 0
kernel: TDH a
kernel: TDT a
kernel: next_to_use a
Wow. That's fast! :-)
On Tuesday 15 January 2008, David Miller wrote:
From: Frans Pop [EMAIL PROTECTED]
kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Does this make the problem go away?
I'm compiling a kernel with the patch now. Will let you know the result.
May take
James Kosin wrote:
> Anyone remember the patch / patches done for the 2.6 series that related
> to top reporting > 100% CPU usage?
Do you mean these perhaps?
- 73a2bcb0edb9ffb0b007b3546b430e2c6e415eee
- 9301899be75b464ef097f0b5af7af6d9bd8f68a7
Cheers,
FJP
--
To unsubscribe from this list: send
James Kosin wrote:
Anyone remember the patch / patches done for the 2.6 series that related
to top reporting 100% CPU usage?
Do you mean these perhaps?
- 73a2bcb0edb9ffb0b007b3546b430e2c6e415eee
- 9301899be75b464ef097f0b5af7af6d9bd8f68a7
Cheers,
FJP
--
To unsubscribe from this list: send the
Len Brown wrote:
>> > Well, yes, the warning is actually new as well. Previously your kernel
>> > just silently ignored 8 more mem resources than it does now it seems.
>> >
>> > Given that people are hitting these limits, it might make sense to just
>> > do away with the warning for 2.6.24 again
Len Brown wrote:
Well, yes, the warning is actually new as well. Previously your kernel
just silently ignored 8 more mem resources than it does now it seems.
Given that people are hitting these limits, it might make sense to just
do away with the warning for 2.6.24 again while waiting
(Mail below was sent to me privately, forwarding to the lists.)
On Mon, 2008-01-07 at 00:48 +0100, Frans Pop wrote:
> (Adding the kernel list back. Any reason you did not send the reply
> there?)
>
> Sorry for the late reply: Christmas, New Year, the flue, etc.
> Thank
(Mail below was sent to me privately, forwarding to the lists.)
On Mon, 2008-01-07 at 00:48 +0100, Frans Pop wrote:
(Adding the kernel list back. Any reason you did not send the reply
there?)
Sorry for the late reply: Christmas, New Year, the flue, etc.
Thank you for caring this problem
(Adding the kernel list back. Any reason you did not send the reply there?)
Sorry for the late reply: Christmas, New Year, the flue, etc.
On Friday 28 December 2007, Zhao Yakui wrote:
> On Mon, 2007-12-24 at 06:12 +0100, Frans Pop wrote:
> > During boot with v2.6.24-rc6-125-g5356
On Sunday 06 January 2008, Eric W. Biederman wrote:
> Short of two programs coming in and simultaneously trying to claim
> the parallel port and there being not exclusion in ppdev.c I don't
> have a clue what could cause the reported error.
That could well be the root cause as the full log shows:
(Adding the kernel list back. Any reason you did not send the reply there?)
Sorry for the late reply: Christmas, New Year, the flue, etc.
On Friday 28 December 2007, Zhao Yakui wrote:
On Mon, 2007-12-24 at 06:12 +0100, Frans Pop wrote:
During boot with v2.6.24-rc6-125-g5356f66 on my Toshiba
On Sunday 06 January 2008, Eric W. Biederman wrote:
Short of two programs coming in and simultaneously trying to claim
the parallel port and there being not exclusion in ppdev.c I don't
have a clue what could cause the reported error.
That could well be the root cause as the full log shows:
(Resending as there were no replies on my first post mid December; issue
is still there with -rc6.)
This is the first time I've seen this error. Last time I used the printer
was with 2.6.24-rc3 and that time this error did not occur.
The error occurs when I start a print job, not when I turn the
(Resending as there were no replies on my first post mid December; issue
is still there with -rc6.)
This is the first time I've seen this error. Last time I used the printer
was with 2.6.24-rc3 and that time this error did not occur.
The error occurs when I start a print job, not when I turn the
On Thursday 20 December 2007, Alan Cox wrote:
> The kernel printk messages are sentences.
I'm afraid that I completely and utterly disagree. Kernel messages are _not_
sentences. The vast majority is not well-formed and does not contain any of
the elements that are required for a proper
On Thursday 20 December 2007, Alan Cox wrote:
The kernel printk messages are sentences.
I'm afraid that I completely and utterly disagree. Kernel messages are _not_
sentences. The vast majority is not well-formed and does not contain any of
the elements that are required for a proper sentence.
On Tuesday 18 December 2007, Glauber de Oliveira Costa wrote:
> On Dec 18, 2007 6:54 PM, Frans Pop <[EMAIL PROTECTED]> wrote:
> > Glauber de Oliveira Costa wrote:
> > > What's left in processor_32.h and processor_64.h cannot be cleanly
> > > integrated. However,
Glauber de Oliveira Costa wrote:
> What's left in processor_32.h and processor_64.h cannot be cleanly
> integrated. However, it's just a couple of definitions. They are moved
> to processor.h around ifdefs, and the original files are deleted. Note
> that there's much less headers included in the
Glauber de Oliveira Costa wrote:
What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are moved
to processor.h around ifdefs, and the original files are deleted. Note
that there's much less headers included in the final
On Tuesday 18 December 2007, Glauber de Oliveira Costa wrote:
On Dec 18, 2007 6:54 PM, Frans Pop [EMAIL PROTECTED] wrote:
Glauber de Oliveira Costa wrote:
What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions
1 - 100 of 263 matches
Mail list logo
