On Sunday 13 May 2007 07:33:14 Yinghai Lu wrote:
> please check the patch.
Can you please give a little more description on why you think the patch
is needed? Also we need a Signed-off-by line.
Thanks,
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On 5/12/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
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
Please don't use my work email address unless I _really_ need to be
wearing my tinfoil hat when I read it.
On Sat, 2007-05-12 at 09:35 -0700, Pete Zaitcev wrote:
> 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.
please check the patch.
YH
[PATCH]x86_64: build and use GDT on copied compressed kernel
Build and use GDT on copied compressed kernel postion, instead of using GDT
in data segment of loaded compressed kernel. Otherwise decompressing
compressed kernel image later in 64bit longmode, will
> "Andi" == Andi Kleen <[EMAIL PROTECTED]> writes:
>> -/* Reenable any watchpoints before delivering the
>> +/* Re-enable any watchpoints before delivering the
Andi> reenable gets >140k google hits so it seems to be an really
Andi> used word.
Essentially all commonly
On Sun, 2007-05-13 at 01:20 +0200, Pavel Machek wrote:
> > It was °C, and that's IMHO better readable than some kind of
> > "degrees C".
>
> It is more readable for you, and more readable on me while in desktop
> X. But on Zaurus and on console I see "???C", and I definitely prefer
> "degrees C"
On Sun, 13 May 2007, Nick Piggin wrote:
> On Fri, May 11, 2007 at 02:15:03PM +0100, Hugh Dickins wrote:
>
> > Hmm, well, I think that's fairly horrid, and would it even be
> > guaranteed to work on all architectures? Playing with one char
> > of an unsigned long in one way, while playing with
And Dmitry Torokhov writes:
> Have you tried any other -mm? Also, does it help if you stick
> ps2_command(>ps2dev, NULL, PSMOUSE_CMD_SETSTREAM);
> at the very beginning of psmouse_initialize() in
> drivers/input/mouse/psmouse-base.c?
Seems to fix it for me on a D620.
Bisecting on
On Sun, 2007-05-13 at 13:52 +1000, Rusty Russell wrote:
> --- a/drivers/net/lguest_net.c
> +++ b/drivers/net/lguest_net.c
...
> if (dma.used_len != skb->len) {
> dev->stats.tx_carrier_errors++;
> - pr_debug("Bad xfer to peer %i: %i of %i (dma %p/%i)\n",
> +
On Fri, 2007-05-11 at 11:23 +1000, Rusty Russell wrote:
> 1) Use new dma wrapper functions, and handle bind failure (may happen
>in future)
> 2) Use new lgdev_irq() "get me a good interrupt number" function.
> 3) __force the ioremap: guests can use it as normal memory.
And here is the update
On Fri, 2007-05-11 at 11:19 +1000, Rusty Russell wrote:
> 1) Sam Ravnborg says lg-objs is deprecated, use lg-y.
> 2) Sparse: page_tables.c unnecessary initialization
> 3) Lots of __force to shut sparse up: guest "physical" addresses are
>userspace virtual.
> 4) Change prototype of run_lguest
On Fri, 2007-05-11 at 11:22 +1000, Rusty Russell wrote:
> Feedback from Jeff Garzik:
> 1) Use netdev_priv instead of dev->priv.
> 2) Check for ioremap failure
> 3) iounmap on failure.
> 4) Wrap SEND_DMA and BIND_DMA calls
> 5) Don't set NETIF_F_SG unless we set NETIF_F_NO_CSUM
> 6) Use
On Fri, 2007-05-11 at 07:56 +0100, Christoph Hellwig wrote:
> On Fri, May 11, 2007 at 11:21:30AM +1000, Rusty Russell wrote:
> > 1) send-dma and bind-dma hypercall wrappers for drivers to use,
> > 2) formalization of the convention that devices can use the irq
> >corresponding to their index
On Fri, May 11, 2007 at 02:15:03PM +0100, Hugh Dickins wrote:
> On Fri, 11 May 2007, Nick Piggin wrote:
> >
> > Don't worry, I'm only just beginning ;) Can we then do something crazy
> > like this? (working on x86-64 only, so far. It seems to eliminate
> > lat_pagefault and lat_proc regressions
Ok, the merge window has closed, and 2.6.22-rc1 is out there.
The diffstat and shortlogs are way too big to fit under the kernel mailing
list limits, and the changes are all over the place. Almost seven thousand
files changed, and that's not double-counting the files that got moved
around.
... and make it depend on the response flag instead of the command type.
Signed-off-by: Nicolas Pitre <[EMAIL PROTECTED]>
---
On Sat, 12 May 2007, Pierre Ossman wrote:
> Nicolas Pitre wrote:
> > Please apply the following patch. It is compile tested only as I don't
> > have PXA27x hardware
Lukas Hejtmanek wrote:
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
Robert Hancock wrote:
Fred Moyer wrote:
This appears to be a different problem. Something is issuing
SMART-related commands (smartd or smartctl perhaps) which the drive
seems to be reacting strangely to. It apparently completed the
command but never raised DRQ to request any data being
On Sat, May 12, 2007 at 12:48:59PM -0600, 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
On Sat, 12 May 2007 21:56:10 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> 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
Fred Moyer wrote:
This appears to be a different problem. Something is issuing
SMART-related commands (smartd or smartctl perhaps) which the drive
seems to be reacting strangely to. It apparently completed the command
but never raised DRQ to request any data being transferred even though
we
On Sat, 12 May 2007 21:35:58 +0200 Lee Garrett <[EMAIL PROTECTED]> wrote:
> 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 :
On Fri, 2007-05-11 at 08:40 +0100, Christoph Hellwig wrote:
> On Fri, May 11, 2007 at 05:31:06PM +1000, Rusty Russell wrote:
> > Hi Christoph!
>
> > I enjoy a good Hellwigging as much as anyone, but your aim is off.
>
> Please stop this crap. I know who I am, so there's no need to waste
> mail
Hi Jan,
All the submenus bellow are dependent of VIDEO_DEV (Video4Linux core).
If someone wants V4L, it is very likely that he will select a radio or a
video adapter, since the subsystem is useless without the drivers (*).
(*) Except if you are using an out-of-tree driver.
> diff --git
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Peter Anvin wrote:
> Kevin Winchester wrote:
>> Not sure if you were looking for testing, but I fuzzed it to apply to
>> 2.6.21-git and gave it a spin. Worked just like a normal boot (which I
>> assume was the point).
>
> That would be the point,
Satyam Sharma <[EMAIL PROTECTED]> wrote:
> In fact you can't really say the same for
> volatile. We already assume the compiler _actually_ took some
> pains to stuff meaning into C's (lack of) definition of volatile and
> implement it -- but in what sense, nobody knows (the C standard
On Sun, 2007-05-13 at 03:18 +0400, Stas Sergeev wrote:
> Hello.
>
> Without the attached patch, I wasn't able
> to get the PIT to work as a clocksource for
> high-res timers.
> I don't know whether the patch is correct,
> but I tested it and it works.
> Can someone please tell me what exactly
>
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 or something). Most emulators still
> > > > emulate
Hello.
Without the attached patch, I wasn't able
to get the PIT to work as a clocksource for
high-res timers.
I don't know whether the patch is correct,
but I tested it and it works.
Can someone please tell me what exactly
does this flag mean? google reveals nothing
sensible to me, sorry...
---
Hello,
I tested cfs v11 on 2.6.20.10 and here are my results:
I started 6 md5sum /dev/urandom and 3 glxgears
with 2 glxgears X was still very responsive...but after starting the
third one there where noticeable lags when using X... so I reniced it
to -10 and its very smooth again.
I am now
Move definition of .text section to asm-generic.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
As-is this patch looks pointless but I need
to add another section in parallel with .text
so this patch allows me to do so in one place
instead of touching all .lds files.
Question: Some arch's
Hi!
> > 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" flag that
> every driver
Eric W. Biederman wrote:
> Ok. If you have tested on a wide variety of machines then I won't
> worry about it.
>
> I guess if a cr0 write has always been synchronizing things should be
> a safe practice. The practical danger is if you write to cr0 and the
> pipeline is not flushed and the
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> 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.
Ok. If you have tested on a wide variety of
Hi,
On Saturday, 12 May 2007 21:17, Pavel Machek 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
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
>
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 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
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
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
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 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 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
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 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 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
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
>> >
>>
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
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
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,
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 @@
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
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
> > 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 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'
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
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
* 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.
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:
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
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
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
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"
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
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'?
>>
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 ?
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
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, 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 (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
> 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
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
> 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
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
> 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
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
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
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
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
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 = _console;
> +#endif
-
To unsubscribe from this list: send the line
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
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,
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
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
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
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,
> >
> >
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. 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
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
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
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
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
>
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
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
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
+++
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,
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
1 - 100 of 491 matches
Mail list logo
