Nicolas Pitre wrote:
> Actually, I'm not the author of this workaround. And looking at it
> closer, the current workaround is utterly buggy as it completely inhibit
> CRC error reporting for everything but the listed commands when the MSB
> of the response is a zero.
>
>
Your name popped up
On Sat, May 12, 2007 at 06:12:27PM +0200, Pierre Ossman wrote:
> Nicolas Pitre wrote:
> > Actually, I'm not the author of this workaround. And looking at it
> > closer, the current workaround is utterly buggy as it completely inhibit
> > CRC error reporting for everything but the listed commands
[Jan Engelhardt - Sat, May 12, 2007 at 05:01:19PM +0200]
|
| On May 12 2007 21:44, David Woodhouse wrote:
| >On Sat, 2007-05-12 at 17:19 +0400, Cyrill Gorcunov wrote:
| >> Actually I think it would be convenient if such tags (like
| >> v.2.6.21-git16) were in Linus' git tree too.
| >
| >Then there
> +++ b/arch/x86_64/kernel/signal.c
> @@ -411,7 +411,7 @@ static void do_signal(struct pt_regs *regs)
>
> signr = get_signal_to_deliver(&info, &ka, regs, NULL);
> if (signr > 0) {
> - /* Reenable any watchpoints before delivering the
> + /* Re-enable any watch
On Saturday, 12 May 2007 16:18, Oleg Nesterov wrote:
> On 05/12, Rafael J. Wysocki wrote:
> >
> > ... user space tasks that call deamonize() can also be frozen prematurely.
> > We didn't take this possibility into consideration before, which was
> > obviously
> > wrong.
>
> No, no, sorry for the
On Sat, May 12, 2007 at 08:24:28PM +0400, Cyrill Gorcunov wrote:
> [Jan Engelhardt - Sat, May 12, 2007 at 05:01:19PM +0200]
> |
> | On May 12 2007 21:44, David Woodhouse wrote:
> | >On Sat, 2007-05-12 at 17:19 +0400, Cyrill Gorcunov wrote:
> | >> Actually I think it would be convenient if such tag
While testing adding/deleting large numbers of interfaces, I found
rt_run_flush() was the #1 cpu user in a kernel profile by far.
The below patch changes rt_run_flush() to only take each spinlock
protecting the rt_hash_table once instead of taking a spinlock for
every hash table bucket (and endin
[Russell King - Sat, May 12, 2007 at 05:31:41PM +0100]
| On Sat, May 12, 2007 at 08:24:28PM +0400, Cyrill Gorcunov wrote:
| > [Jan Engelhardt - Sat, May 12, 2007 at 05:01:19PM +0200]
| > |
| > | On May 12 2007 21:44, David Woodhouse wrote:
| > | >On Sat, 2007-05-12 at 17:19 +0400, Cyrill Gorcunov
On Tue, 08 May 2007 18:52:31 +0100, David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-05-08 at 18:45 +0100, Maciej W. Rozycki wrote:
> > Well, my name has an acute above "o" and a dot above "z", but I do not
> > have such a high expectation as to have it correctly spelled in comments
>
On (12/05/07 10:11), Nicolas Mailhot didst pronounce:
> Le vendredi 11 mai 2007 à 21:36 +0100, Mel Gorman a écrit :
>
> > I'm pretty sure I have. I recreated the tree and reverted the same patch as
> > you and regenerated the diff below. I sent it to myself and it appeared ok
> > and another autom
On Sat, 12 May 2007 16:17:35 +0100 Richard Purdie <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-05-12 at 13:17 +0200, Adrian Bunk wrote:
> > On Wed, May 02, 2007 at 09:56:23AM +0100, Richard Purdie wrote:
> > >...
> > > I've asked the LZO author about the comments on lzo_copyright function
> > > but t
On Sat, 12 May 2007 13:44:13 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> lockdep complains about the lock nesting of clocksource and watchdog
> lock in the resume path. Move watchdog resume out of the clocksource
> lock.
>
> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
>
> Index: li
On Sat, 2007-05-12 at 09:51 -0700, Andrew Morton wrote:
> The locking in clocksource_resume_watchdog looks pretty pointless anyway.
> Can't we just delete it?
>
> The only thing it can race against is, conceivably,
>
> resumed = watchdog_resumed;
> if (unlikely(resumed))
>
On 05/12, Rafael J. Wysocki wrote:
>
> Ah, I see. We spawn a kernel thread from a code path that belongs to a
> user space task and we need to call deamonize() to make it become a
> 'real' kernel thread.
>
> Still, this means that is_user_space() may return 'true' for this thread
> before it call
On Sat, 2007-05-12 at 20:04 +0400, Oleg Nesterov wrote:
> On 05/12, Peter Zijlstra wrote:
> >
> > +static inline void rw_mutex_readers_dec(struct rw_mutex *rw_mutex)
> > +{
> > + percpu_counter_dec(&rw_mutex->readers);
> > + smp_wmb();
> > +}
> >
> > +void rw_mutex_read_unlock(struct rw_mutex *
On Mon, 7 May 2007 22:23:11 +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> We had this discussion before. Kernel sources should use utf-8 for
> comments where neccessary. Many names cannot be correctly represented in
> US ascii, and mangling them is just plain rude.
I have to disagree here. It is u
On Saturday, 12 May 2007 18:58, Oleg Nesterov wrote:
> On 05/12, Rafael J. Wysocki wrote:
> >
> > Ah, I see. We spawn a kernel thread from a code path that belongs to a
> > user space task and we need to call deamonize() to make it become a
> > 'real' kernel thread.
> >
> > Still, this means that
The mm snapshot broken-out-2007-05-12-10-16.tar.gz has been uploaded to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-05-12-10-16.tar.gz
It contains the following patches against 2.6.21:
origin.patch
loop_probe-fix-return-value.patch
fault-injection-disable-stacktrace-
On Sat, 12 May 2007 19:01:41 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Can you upload a snapshot of your current queue ?
Yeah, that's super-easy. It just happens that it all compiles
and runs at present ;)
The single-big-patch is at http://userweb.kernel.org/~akpm/tg.bz2
The broken-ou
On Sat, 12 May 2007 07:04:25 -0700 (PDT) Tear <[EMAIL PROTECTED]> wrote:
> Summary: If ACPI is not enabled but APIC is,
> then there is trouble on Dell Optiplex GX240.
> If both are enabled or if both are disabled, then
> everything is fine. The attached patch removes
> Dell Optiplex GX240 from th
I guess I should just shut up and listen to experts... ok, just my
0.02 roubles.
Again, I can't comment things like "we just should never touch kernel",
because I don't even remotely undestand the things which actually use
freezer. I can only talk about the current implementation of freezer.
On 0
Convert to generic boolean (+ some minor cleanup).
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with all(yes|mod|no)config on i386
Diffed against Linus' git-tree.
amd.c |2 --
cyrix.c |2 +-
generic.c | 20 +---
mtrr.h|5 -
4
On Sat, 12 May 2007, Russell King wrote:
> First submitted on 22 November 2004 by Nicolas. Went through a couple
> of revisions until 2271/3 which was committed on 27 November 2004. No
> indication that the code was done by anyone other than Nicolas, though
> maybe Nico didn't add appropriate cr
On Sat, 2007-05-12 at 13:00 +0200, Jan Engelhardt wrote:
> On May 11 2007 16:07, Arjan van de Ven wrote:
> >
> > A typical Linux distribution has many components that wake the processor up
> > frequently for no good reason. In our testing with PowerTOP, we have seen
> > many
> > cases where with s
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Fri, 11 May 2007 10:07:17 -0700 (PDT)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 11 May 2007, Andrew Morton wrote:
> >
> > > yipes. percpu_counter_sum() is expensive.
> >
> > Capable of triggering NMI watchdog on 4096+ processors
On 05/12, Peter Zijlstra wrote:
>
> On Sat, 2007-05-12 at 20:04 +0400, Oleg Nesterov wrote:
> >
> > this code roughly does (the only reader does unlock)
> >
> > READER WRITER
> >
> > readers = 0;state = 1;
> > wmb(); wmb();
> > CHECK(
Export pcmcia_bus_type so module-based drivers can register bus notifiers,
and add it to what seems to be the main include file.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
Missed the include file in the last patch.
Index: 2.6.21/drivers/pcmcia/ds.c
==
On 12 May 2007 20:55:28 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > On Fri, 11 May 2007 10:07:17 -0700 (PDT)
> > Christoph Lameter <[EMAIL PROTECTED]> wrote:
> >
> > > On Fri, 11 May 2007, Andrew Morton wrote:
> > >
> > > > yipes. percpu_counte
Hi Andrew,
i've been going over the interrupt-handling code and noticed that the SA_xxx
interrupt flags are scheduled for removal sometime in 9/2007 with a prior
grace period of 6 months for people to fix external stuff. In order to do so,
a __deprecated inline function wraps those fla
Stefan Richter wrote:
> H. Peter Anvin wrote:
> [slightly off topic: GCCisms in Linux kernel]
>> It contains *many* constructs that are not defined in, for
>> example, C99, and it would in fact be impossible to write the Linux
>> kernel using only C99-compliant constructs.
>
> True. On the other
Le samedi 12 mai 2007 à 17:42 +0100, Mel Gorman a écrit :
> order-2 (at least 19 pages but more are there) and higher pages were free
> and this was a NORMAL allocation. It should also be above watermarks so
> something screwy is happening
>
> *peers suspiciously*
>
> Can you try the following p
Eric W. Biederman wrote:
>
> HPA is both right and wrong on this. The safe sequence for entering
> protected mode requires a jump immediately after setting PE in %cr0.
> To serialize the instruction stream and to be on an execution that
> is tested and guaranteed to work in cpus.
>
Eric, that's
On Sat, 12 May 2007 11:06:24 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
> We could put a cpumask in percpu_counter, initialise it to
> cpu_possible_map. Then, those callsites which have hotplug notifiers can
> call into new percpu_counter functions which clear and set bits in that
> cpumask a
On Sat, 12 May 2007 20:07:04 +0200 Borislav Petkov <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
>i've been going over the interrupt-handling code and noticed that the
> SA_xxx
>interrupt flags are scheduled for removal sometime in 9/2007 with a prior
>grace period of 6 months for people
On 05/12, Andi Kleen wrote:
>
> --- linux-2.6.21-git2-net.orig/kernel/cpu.c
> +++ linux-2.6.21-git2-net/kernel/cpu.c
> @@ -26,6 +26,10 @@ static __cpuinitdata RAW_NOTIFIER_HEAD(c
> */
> static int cpu_hotplug_disabled;
>
> +/* Contains any CPUs that were ever online at some point.
> + No gu
Hi,
Having considered the issue of freezing (or not freezing) kernel threads for a
longer while I tend to agree with Linus that we shouldn't be freezing as many
kernel threads as we currently freeze, but there's one thing that he doesn't
seem to take into account. Namely, there may be some kernel
David Woodhouse wrote:
> On Sat, 2007-05-12 at 17:19 +0400, Cyrill Gorcunov wrote:
>> Actually I think it would be convenient if such tags (like
>> v.2.6.21-git16) were in Linus' git tree too.
>
> Then there would be _lots_ of tags in the master tree -- I'm not sure we
> want that.
>
> I suppose
Hi,
This has bothered me for a long time, and it just seems to be getting
worse. Can people please STOP defaulting non-essential stuff to 'y'?
Grrr.
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 58926da..adbb5ca 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macin
On Sat, 12 May 2007, Rafael J. Wysocki wrote:
>
> Of course, that would also require us to rewrite the freezer itself quite a
> bit, but IMO it's worthy of doing.
>
> Thoughts?
I'd much prefer it. One of the reasons I hate the freezer so much is that
it ends up affecting things it really has
On Fri, May 11 2007, Oliver Xymoron wrote:
> Tried to boot using SLUB under lguest with 2.6.21-mm2. Got the
> following:
>
> ...
> [0.388000] NET: Registered protocol family 17
> [0.388000] Using IPI Shortcut mode
> [0.42] EXT2-fs warning: mounting unchecked fs, running e2fsck
> is
if (!x) kfree(x); is not needed since kfree(NULL) is valid.
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64)
Diffed against Linus' git-tree.
diff --git a/sound/usb/usx2y/usbusx2yaudio.c b/sound/usb/usx2y/usbusx2yaudio.c
i
as i've lately been forced to see the following message, i decided to
report this. i hope it's the right place to do it.
kernel: [ cut here ]
kernel: Kernel BUG at [verbose debug info unavailable]
[...]
here is the latest bug message:
===
May 12 19:52:52
Bill Davidsen wrote:
Jonathan Corbet wrote:
+There are still a few rare situations where volatile makes sense in the
+kernel:
+
+ - The above-mentioned accessor functions might use volatile on
+architectures where direct I/O memory access does work.
Essentially,
+each accessor call
Gerhard Mack wrote:
On Wed, 9 May 2007, Robert Hancock wrote:
Gerhard Mack wrote:
On Wed, 9 May 2007, Jeff Garzik wrote:
Gerhard Mack wrote:
May 9 14:51:35 mgerhard kernel: ata1.00: exception Emask 0x0 SAct 0x0
SErr
0x180 action 0x2 frozen
May 9 14:51:35 mgerhard kernel: ata1.00: cmd
35
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> HPA is both right and wrong on this. The safe sequence for entering
>> protected mode requires a jump immediately after setting PE in %cr0.
>> To serialize the instruction stream and to be on an execution that
>> is te
Hi Andrej,
On 12/05/07, Andrej Hocevar <[EMAIL PROTECTED]> wrote:
as i've lately been forced to see the following message, i decided to
report this. i hope it's the right place to do it.
kernel: [ cut here ]
kernel: Kernel BUG at [verbose debug info unavailable]
[...]
h
On Sat, 2007-05-12 at 19:01 +0200, Thomas Gleixner wrote:
> On Sat, 2007-05-12 at 09:51 -0700, Andrew Morton wrote:
> > The locking in clocksource_resume_watchdog looks pretty pointless anyway.
> > Can't we just delete it?
> >
> > The only thing it can race against is, conceivably,
> >
> >
Fred Moyer wrote:
I just joined the list today so apologies if this email breaks any email
client post threading.
I have been seeing similar errors on two different systems. I applied
Robert's sata_nv patch posted to the list on May 5th, and approved today
by Jeff Garzik. I've taken several
Dear all,
I've realized using the great powertop ( http://www.linuxpowertop.org/ )
that loading the appletouch driver (and touching it once) makes consumes
about 0.3 W even when not touching the pad. As rmmod'ing appletouch
fixes this I wonder why the driver does not do this alone. So my
question
On Saturday 12 May 2007 17:43:46 Daniel Walker wrote:
> Considering that Andi has a similar patch, I'm going to assume there
> is already justification for this..
I just have a patch for sched_clock, which is somewhat different.
> What it ends up doing is allows the TSC to be used in cases which
On Saturday 12 May 2007 17:43:45 Daniel Walker wrote:
> Just passing a string to mark_tsc_unstable() doesn't allow real code to change
> based on the reason for the instablility. I changed mark_tsc_unstable()
> to accept a string and a flag which denotes a general reason why the tsc
> is unstable,
Eric W. Biederman wrote:
>
> Even on 386 and 486 class cpus?
>
Yes, even on 386 and 486 class CPUs. I have personally tested this on
machines as old as the original "double sigma" 386-16.
> To some extent if the rules don't change it makes sense for them to
> copy the information from one gene
On Thu, May 10, 2007 at 05:07:02PM -0700, Jeremy Fitzhardinge wrote:
> +#ifdef CONFIG_XEN
xenboot_console is only available with CONFIG_HVC_XEN.
> + } else if (!strncmp(buf, "xen", 3)) {
> + early_console = &xenboot_console;
> +#endif
-
To unsubscribe from this list: send the line
Robert Hancock wrote:
Fred Moyer wrote:
I just joined the list today so apologies if this email breaks any
email client post threading.
I have been seeing similar errors on two different systems. I applied
Robert's sata_nv patch posted to the list on May 5th, and approved
today by Jeff Garz
On Fri, 11 May 2007 19:12:15 -0700
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> > Following the principle of least astonishment, I think it seems
> > better to use high, out-of-the-way port numbers regardless of how
> > much RAM the system has. So, the following patch changes this
> > behavior sl
Mark Glines wrote:
>
> Well, in that case, is there anything wrong with just using the
> range IANA recommends, in all cases?
>
I think the IANA range is considered too small in most cases; I suspect
there is also a feeling that "there be dragons" near the very top.
-hpa
-
To unsubscrib
On Sat, 2007-05-12 at 20:56 +0200, Andi Kleen wrote:
> On Saturday 12 May 2007 17:43:45 Daniel Walker wrote:
> > Just passing a string to mark_tsc_unstable() doesn't allow real code to
> > change
> > based on the reason for the instablility. I changed mark_tsc_unstable()
> > to accept a string and
> Well, in that case, is there anything wrong with just using the
> range IANA recommends, in all cases?
>
> Please consider this patch instead of my previous one.
Please send this patch to the netdev list and CC the relevant networking
maintainer.
Alan
-
To unsubscribe from this list: send the
Hi!
> Having considered the issue of freezing (or not freezing) kernel threads for a
> longer while I tend to agree with Linus that we shouldn't be freezing as many
> kernel threads as we currently freeze, but there's one thing that he doesn't
> seem to take into account. Namely, there may be som
> This also allows us to de-uglify workqueue.c a little bit, it uses
> a home-grown cpu_populated_map.
It might be obsolete iff more and more architecture don't use NR_CPUS filled
possible_map anymore (haven't checked them all to know if it's true or not)
If not there are a couple of more optimiz
On May 12 2007 20:23, Jens Axboe wrote:
>Hi,
>
>This has bothered me for a long time, and it just seems to be getting
>worse. Can people please STOP defaulting non-essential stuff to 'y'?
>Grrr.
http://lkml.org/lkml/2007/5/8/76
Jan
--
-
To unsubscribe from this list: send the line "un
> I have to disagree here. It is using the native alphabet for the name
> which is very rude, because non-native hackers cannot read it. This is
I think you mean "non Amercian". The majority of the human race don't
speak English, and you could probably make a good case that kernel tree
should be i
On (12/05/07 20:58), Nicolas Mailhot didst pronounce:
> Le samedi 12 mai 2007 à 20:09 +0200, Nicolas Mailhot a écrit :
> > Le samedi 12 mai 2007 à 17:42 +0100, Mel Gorman a écrit :
> >
> > > order-2 (at least 19 pages but more are there) and higher pages were free
> > > and this was a NORMAL alloc
On Sat, 2007-05-12 at 20:58 +0200, Andi Kleen wrote:
> On Saturday 12 May 2007 17:43:46 Daniel Walker wrote:
> > Considering that Andi has a similar patch, I'm going to assume there
> > is already justification for this..
>
> I just have a patch for sched_clock, which is somewhat different.
>
> >
On Sat, May 12 2007, Jan Engelhardt wrote:
>
> On May 12 2007 20:23, Jens Axboe wrote:
> >Hi,
> >
> >This has bothered me for a long time, and it just seems to be getting
> >worse. Can people please STOP defaulting non-essential stuff to 'y'?
> >Grrr.
>
> http://lkml.org/lkml/2007/5/8/76
Sorry,
On Sat, 12 May 2007 12:12:38 -0700
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Mark Glines wrote:
> >
> > Well, in that case, is there anything wrong with just using the
> > range IANA recommends, in all cases?
> >
>
> I think the IANA range is considered too small in most cases; I
> suspect
On Sat, May 12, 2007 at 08:27:00PM +0100, Alan Cox wrote:
> > One peculiar thing I have observed is how all this "UTF-8 in names"
> > nonsense is being pushed by western Europeans. Why? That's because
> > their umlauts are grandfathered in, and because English speakers _can_
> > read their names ap
On Sat, 2007-05-12 at 10:23 -0700, Andrew Morton wrote:
> On Sat, 12 May 2007 19:01:41 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > Can you upload a snapshot of your current queue ?
>
> Yeah, that's super-easy. It just happens that it all compiles
> and runs at present ;)
Really ?
/h
Truxton Fulton wrote:
Hi,
I verified on my IDEQ210M that performing the old reboot sequence
followed by the new reboot sequence works for me, and I suspect that
it will work for Lee also. Like this :
/* old method, works on most machines */
for (i = 0; i < 100; i++) {
On Sat, May 12, 2007 at 08:17:31PM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> Having considered the issue of freezing (or not freezing) kernel threads for a
> longer while I tend to agree with Linus that we shouldn't be freezing as many
> kernel threads as we currently freeze, but there's one thing
On May 12 2007 21:27, Jens Axboe wrote:
>On Sat, May 12 2007, Jan Engelhardt wrote:
>>
>> On May 12 2007 20:23, Jens Axboe wrote:
>> >Hi,
>> >
>> >This has bothered me for a long time, and it just seems to be getting
>> >worse. Can people please STOP defaulting non-essential stuff to 'y'?
>> >Grr
On Sat, 12 May 2007, Pavel Machek wrote:
>
> If you fail to do that, we'll see freezer failure, quickly, and catch
> the simple bug.
"It's a feature to add crap to drivers and subsystems that don't care!"
That's a novel thing.
Maybe we could add other features too. Like a "IM_NOT_AN_IDIOT" fl
On Sat, May 12 2007, Jan Engelhardt wrote:
>
> On May 12 2007 21:27, Jens Axboe wrote:
> >On Sat, May 12 2007, Jan Engelhardt wrote:
> >>
> >> On May 12 2007 20:23, Jens Axboe wrote:
> >> >Hi,
> >> >
> >> >This has bothered me for a long time, and it just seems to be getting
> >> >worse. Can peop
Hi Jindrich,
On 5/12/07, Jindrich Makovicka <[EMAIL PROTECTED]> wrote:
On Sat, 12 May 2007 12:41:03 +0200
[EMAIL PROTECTED] wrote:
> oh - and think of linux software suspend.
> take a notebook with 2 GB of ram - that takes a while to write that
> to disk and read that back again. using lzo comp
On Sat, 2007-05-12 at 10:23 -0700, Andrew Morton wrote:
> The broken-out queue should turn up at
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/
> in a few minutes.
Sigh. I can't reproduce your lockdep problem :(
Can you send me your .config please ?
tglx
-
To unsubscribe from
* H. Peter Anvin ([EMAIL PROTECTED]) wrote:
> Satyam Sharma wrote:
> >
> > Because volatile is ill-defined? Or actually, *undefined* (well,
> > implementation-defined is as good as that)? It's *so* _vague_,
> > one doesn't _feel_ like using it at all!
> >
>
> Sorry, that's just utter crap. Linu
Bastian Blank wrote:
> On Thu, May 10, 2007 at 05:07:02PM -0700, Jeremy Fitzhardinge wrote:
>
>> +#ifdef CONFIG_XEN
>>
>
> xenboot_console is only available with CONFIG_HVC_XEN.
>
Good point. I added CONFIG_HVC_XEN, but forgot to update this.
J
-
To unsubscribe from this list: sen
On Sun, 13 May 2007, Gautham R Shenoy wrote:
>
> With the "freeze-limited-kernel-threads" scheme, we would still need
> to perform this audit, since we now have to freeze only those kernel
> threads which *may* end up calling foo().
What the *heck* is wrong with just adding proper locking or ot
On 12/05/07 19:23, Jens Axboe wrote:
Hi,
This has bothered me for a long time, and it just seems to be getting
worse. Can people please STOP defaulting non-essential stuff to 'y'?
Grrr.
Is there a reason why various 10/100/1000Mbit network cards are 'y' too?
There's even a default SCSI 'm' tha
On Sat, 12 May 2007, Soeren Sonnenburg wrote:
> Dear all,
>
> I've realized using the great powertop ( http://www.linuxpowertop.org/ )
> that loading the appletouch driver (and touching it once) makes consumes
> about 0.3 W even when not touching the pad. As rmmod'ing appletouch
> fixes this I wo
> > I think the IANA range is considered too small in most cases; I
> > suspect there is also a feeling that "there be dragons" near the very
> > top.
>
> Ok, thanks for the explanation. Sounds like we're using high port
> numbers in the "spirit" of the IANA recommendation, without using
> their
> Sorry, I don't buy that reason at all - it's a short term advantage,
> causing long term pain. It's not what we have done in the past, don't
> start doing crap like that now.
It doesn't really matter what it defaults too
cp .config somewheresafe
Install new kernel
cp it back
make oldconfig
On Sat, May 12 2007, Simon Arlott wrote:
> On 12/05/07 19:23, Jens Axboe wrote:
> >Hi,
> >
> >This has bothered me for a long time, and it just seems to be getting
> >worse. Can people please STOP defaulting non-essential stuff to 'y'?
> >Grrr.
>
> Is there a reason why various 10/100/1000Mbit net
Hello,
why the attached patch is still not included in mainline kernel? It fixes boot
problems after suspend to RAM.
--
Lukáš Hejtmánek
--- arch/i386/kernel/reboot.c.old 2006-06-18 03:49:35.0 +0200
+++ arch/i386/kernel/reboot.c 2006-07-01 17:29:23.0 +0200
@@ -31,6 +31,12 @@
#ifd
On Sat, May 12 2007, Alan Cox wrote:
> > Sorry, I don't buy that reason at all - it's a short term advantage,
> > causing long term pain. It's not what we have done in the past, don't
> > start doing crap like that now.
>
> It doesn't really matter what it defaults too
It does matter what it defa
Hello,
as of 2.6.21-git16, the bugs related to restoring PCI are still present. The
save pci function reads only -1 from the PCI config space and when restoring,
it messes up totaly most PCI devices. The attached patch is workaround only
until proper fix is found and included. Could it be included
On Sat, 12 May 2007, Linus Torvalds wrote:
>
> - make the rule be that you cannot sleep in the above macro, and make the
>rule be that CPU hotplug uses the same mechanisms that module unload
>already does!
Side note: we obviously already do the stop_machine_run thing for CPU
down, s
Hi Thomas,
Thanks for answering so quickly !
On 5/12/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
Francis,
On Sat, 2007-05-12 at 16:54 +0200, Francis Moreau wrote:
> I'm trying to use clocksource and clockevent new subsystem. My
> platform has a timer that I'd like to use both as a clocksour
Hi Linus,
>> >> On May 12 2007 20:23, Jens Axboe wrote:
>> >> >Hi,
>> >> >
>> >> >This has bothered me for a long time, and it just seems to be getting
>> >> >worse. Can people please STOP defaulting non-essential stuff to 'y'?
>> >> >Grrr.
>> >>
>> >> http://lkml.org/lkml/2007/5/8/76
>> >
>> >S
On Sat, 2007-05-12 at 22:13 +0200, Francis Moreau wrote:
> > Yes, it is correct. The generic timer code requests an event in the
> > future. It does not care, whether the hardware device can handle that or
> > not. So the clock event code limits the delta to the maximum delta the
> > device can han
On Sat, 2007-05-12 at 11:59 -0400, Robert P. J. Day wrote:
> On Sat, 12 May 2007, Antonino A. Daplas wrote:
>
> > On Sat, 2007-05-12 at 06:32 -0400, Robert P. J. Day wrote:
> ok, so is someone already fixing this?
Already sent Linus and akpm a patch.
Thanks.
Tony
-
To unsubscribe from this
On Sat, 2007-05-12 at 20:58 +0100, Simon Arlott wrote:
> On 12/05/07 19:23, Jens Axboe wrote:
> > Hi,
> >
> > This has bothered me for a long time, and it just seems to be getting
> > worse. Can people please STOP defaulting non-essential stuff to 'y'?
> > Grrr.
>
> Is there a reason why various
On Sat, 2007-05-12 at 09:47 -0700, Andrew Morton wrote:
> On Sat, 12 May 2007 16:17:35 +0100 Richard Purdie <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 2007-05-12 at 13:17 +0200, Adrian Bunk wrote:
> > > On Wed, May 02, 2007 at 09:56:23AM +0100, Richard Purdie wrote:
> > > >...
> > > > I've asked the
On Saturday, 12 May 2007 20:25, Linus Torvalds wrote:
>
> On Sat, 12 May 2007, Rafael J. Wysocki wrote:
> >
> > Of course, that would also require us to rewrite the freezer itself quite a
> > bit, but IMO it's worthy of doing.
> >
> > Thoughts?
>
> I'd much prefer it. One of the reasons I hate
On Fri, May 11, 2007 at 01:21:16PM +, Pavel Machek wrote:
> Hi!
>
> > > > > And how about serial terminals?
> > > >
> > > > It works fine over serial terminals. Why wouldn't it?
> > >
> > > He probably means serial terminals... like physical vt100. I used to
> > > have one (vt302 compatible
On Saturday 12 May 2007 00:07:18 Arjan van de Ven wrote:
> What's eating the battery life of my laptop? Why isn't it many more
> hours? Which software component causes the most power to be burned?
> These are important questions without a good answer... until now.
This is a really great tool and p
On 5/13/07, Simon Arlott <[EMAIL PROTECTED]> wrote:
On 12/05/07 19:23, Jens Axboe wrote:
> Hi,
>
> This has bothered me for a long time, and it just seems to be getting
> worse. Can people please STOP defaulting non-essential stuff to 'y'?
> Grrr.
Is there a reason why various 10/100/1000Mbit ne
On Sat, 12 May 2007, Alan Stern wrote:
> > While we are at it usb related powerhogs on this macbook pro are
> > uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func)
> > too...
> They would use less power if the UHCI host controller were suspended.
> But obviously it cannot be sus
On 05/12, Andi Kleen wrote:
>
> > This also allows us to de-uglify workqueue.c a little bit, it uses
> > a home-grown cpu_populated_map.
>
> It might be obsolete iff more and more architecture don't use NR_CPUS filled
> possible_map anymore (haven't checked them all to know if it's true or not)
>
On Saturday 12 May 2007 19:51:26 Soeren Sonnenburg wrote:
> Dear all,
>
> I've realized using the great powertop ( http://www.linuxpowertop.org/ )
> that loading the appletouch driver (and touching it once) makes consumes
> about 0.3 W even when not touching the pad. As rmmod'ing appletouch
> fixes
101 - 200 of 251 matches
Mail list logo
