#include
* Alan Cox [Fri, Mar 30 2007, 07:10:38PM]:
> >If there is a simple way to get the mapping between the sg and sr
> >devices that would be great and almost solve the problems, but I
> >cannot discover a such thing in the kernel.
>
> You can go trying to match bus values but we
On Fri, Mar 30, 2007 at 02:15:24PM -0700, Andrew Morton wrote:
> On Fri, 30 Mar 2007 02:25:37 -0700
> "Ken Chen" <[EMAIL PROTECTED]> wrote:
>
> > -module_param(max_loop, int, 0);
> > -MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)");
>
> So.. this change will cause a fatal
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
Ideally, this would go into linux-2.6.21.
Preserve the LBA bit in the DevSel/Head register for HDIO_DRIVE_TASK.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- linux/drivers/ata/libata-scsi.c.orig2007-03-21
13:35:02.0 -0400
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> >
> > Right, but clock - sources/events need to be extremly late suspended and
> > early resumed. How can we ensure this ?
[...]
> So the only thing that needs to be done is to make sure that we add
>
On Sat, Mar 31, 2007 at 06:12:01AM -0400, Robert P. J. Day wrote:
> = SH_KGDB =
> ./arch/sh/kernel/Makefile:obj-$(CONFIG_SH_KGDB) += kgdb_stub.o
> kgdb_jmp.o
> ./arch/sh/Makefile:cflags-$(CONFIG_SH_KGDB) += -g
These are fixed in my 2.6.22 queue.
-
To unsubscribe from
On Sat, Mar 31, 2007 at 09:52:30PM +0800, Cong WANG wrote:
> 2007/3/31, Pedram M <[EMAIL PROTECTED]>:
> >Ok thanks,
> >
> >I've sent one already, could you please double check:
> >
> >@@ -4590,7 +4590,7 @@
> >printk("stli_findpcibrds()\n");
> > #endif
> >
> >- while ((dev =
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
>
> Right, but clock - sources/events need to be extremly late suspended and
> early resumed. How can we ensure this ?
Make them be at the top of the device tree by adding them early. That's
the whole point of the device tree after all - we have an
On Saturday 31 March 2007 18:51:11 Thomas Gleixner wrote:
> On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
> > Subject: Add suspend/resume for HPET
> > This adds support of suspend/resume on i386 for HPET
> > Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
> >
> > +static struct
Tejun Heo wrote:
Mark Lord wrote:
Ideally, this would go into linux-2.6.21.
Preserve the LBA bit in the DevSel/Head register for HDIO_DRIVE_TASK.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- linux/drivers/ata/libata-scsi.c.orig2007-03-21
13:35:02.0 -0400
+++
* Kay Sievers <[EMAIL PROTECTED]> wrote:
> > I bet if you build that code as a module, it will work just fine,
> > can you try it?
> >
> > Kay, did you ever get a chance to look into this reference counting
> > issue?
>
> Does the attached work for you?
yeah, this fixed the hangs!
please
* Chris Wright <[EMAIL PROTECTED]> wrote:
> > hm, neat - did you take a look at the x86_64 clockevents code that
> > is in -rt and that has been there for a year or so and has been
> > tested quite extensively?
>
> Yes, that's what I started with. [...]
ok :)
> [...] It was only partially
On Sat, Mar 31, 2007 at 05:01:23PM +0200, Adrian Bunk wrote:
> On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote:
> > On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> > >
> > > Subject: kernels fail to boot with drives on ATIIXP controller
> > >
On Sat, Mar 31, 2007 at 06:33:20PM +0200, Thomas Gleixner wrote:
> On Sat, 2007-03-31 at 09:09 -0700, Linus Torvalds wrote:
> >
> > On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> > >
> > > While I agree in principle with the patch, I'm a bit uncomfortable. The
> > > sys device suspend / resume
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> * Chris Wright <[EMAIL PROTECTED]> wrote:
> > This series converts x86_64 timers to clockevents drivers and then
> > enables dynticks. There's some minor cleanups along the way. The
> > lapic broadcast mechanism is untested, I'm sure it still needs
On Sat, 2007-03-31 at 09:09 -0700, Linus Torvalds wrote:
>
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> >
> > While I agree in principle with the patch, I'm a bit uncomfortable. The
> > sys device suspend / resume ordering is not guaranteed and relies on the
> > registering order.
>
> Well,
* Greg KH <[EMAIL PROTECTED]> wrote:
> Something has grabbed a reference to the driver...
>
> Oh wait, is this code a module or built into the kernel?
>
> If it's built in, there's still a reference counting bug in the
> module/driver hookup logic as we really don't have a "module" yet we
>
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
>
> While I agree in principle with the patch, I'm a bit uncomfortable. The
> sys device suspend / resume ordering is not guaranteed and relies on the
> registering order.
Well, this is why we probably should try to get away from the "system
device"
Cornelia Huck wrote:
On Sat, 31 Mar 2007 12:12:48 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
Hm, but as long as dk0 is registered, it can be looked up and someone
could get a reference on it.
Yeah, exactly. That's why any getting any kobject reference backed by a
module must be accompanied
Hi,
On Sat, 31 Mar 2007, Sam Ravnborg wrote:
> The problem is that tristate symbol represent three values.
> =n => CONFIG_SYMBOL is undefined
> =y => CONFIG_SYMBOL is defined
> =m => COMFIG_SYMBOL_MODULE is defined
>
> The function split_config does not take into account the
> different values
On Sun, 2007-04-01 at 00:01 +0800, Jeff Chua wrote:
> On 3/31/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
> > caused by time keeping / tick management resume happening before the
> > HPET resume.
>
>
> me>Confirmed
I'm getting this Oops when booting an 2.6.21-rc5-mm1 or 2.6.21-rc5-mm2 on an
Acer Aspire 1501 LMi in 32 bit mode (2.6.21-rc4-mm1 + hotfixes works
perfectly):
xor: automatically using best checksumming function: pIII_sse
BUG: unable to handle kernel NULL pointer dereference at virtual address
On Sat, 31 Mar 2007 12:12:48 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> > Hm, but as long as dk0 is registered, it can be looked up and someone
> > could get a reference on it.
>
> Yeah, exactly. That's why any getting any kobject reference backed by a
> module must be accompanied by
On 3/31/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
caused by time keeping / tick management resume happening before the
HPET resume.
me>Confirmed that suspend/resume disk/ram works on X60s with
me>CONFIG_HPET_TIMER=y
On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
> Subject: Add suspend/resume for HPET
> This adds support of suspend/resume on i386 for HPET
> Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
>
> +static struct sysdev_class hpet_class = {
> + set_kset_name("hpet"),
> + .suspend
Pedram M wrote:
Hi,
I've seen this around, and have heard about it in forums and else-where,
could somebody enlighten me with more information or with experiences
they have had. Looks like kswapd begins to eat CPU dramatically till the
box eventually locks up.
You'll want to contact your
Have you got sick of fixing your sources CodingStyle by hand? Are you
reintroducing violations because you've always programmed in a certain style
and those kernel hacker have dictated an insane one which you'll never learn?
Stop that, the spamful company "BlaisorBlade Inc. " has the right
On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote:
> On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> >
> > Subject: kernels fail to boot with drives on ATIIXP controller
> > (ACPI/IRQ related)
> > References :
On Sat, 31 Mar 2007, Nicolas Mailhot wrote:
[adding some people in CC that expressed interest in the problem before]
I'm crazy enough to test a patch if someone cooks it, but I'm way out of
my depth there :)
After struggling with totally broken kernels for the whole morning I got the
HPET
On Sat, Mar 31, 2007 at 09:23:29AM +0800, Antonino A. Daplas wrote:
> On Mon, 2007-03-19 at 10:22 +0100, Adrian Bunk wrote:
> > The Coverity checker spotted the following two array overruns in
> > drivers/video/aty/atyfb_base.c:
> >
> > <-- snip -->
> >
> > ...
> > static const u32
On Saturday 31 March 2007 10:45, Zachary Amsden wrote:
> So lazy MMU mode is vulnerable to interrupts coming in and issuing
> kmap_atomic, which does not work when under lazy MMU mode. The window
> for this is small, but it means highmem kernels, especially with heavy
> network, USB, or AIO
On Fri, 2007-03-30 at 15:21 -0700, Ed Lin wrote:
> The internal id/lun mapping of st_vsc and st_vsc1 controllers is different
> from st_shasta. The original driver code can only map first 16 'entities'
> for st_vsc and st_vsc1 while there are actually 128 available.
>
> Also the
On giovedì 29 marzo 2007, Jeff Dike wrote:
> On Thu, Mar 29, 2007 at 02:36:43AM +0200, Blaisorblade wrote:
> > > Sometimes you need to. I'd probably just remove the do_ubd check and
> > > always recall the request function when handling completions, it's
> > > easier and safe.
>
> If I'm
On Sat, Mar 31, 2007 at 10:11:27AM +0200, Toralf Förster wrote:
> Am Freitag, 30. März 2007 21:47 schrieb Adrian Bunk:
> >
> >
> > No, the code is correct and it's impossible that the variable ever gets
> > read uninitialized.
> >
> > And BTW, i386 gcc 4.1 doesn't give me a warning for this.
>
- consolidate duplicate code in all arch_prepare_kretprobe instances
into common code
- replace various odd helpers that use hlist_for_each_entry to get
the first elemenet of a list with either a hlist_for_each_entry_save
or an opencoded access to the first element in the caller
-
Remove superflous braces and fix indentation aswell as comments.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: linux-2.6/kernel/kprobes.c
===
--- linux-2.6.orig/kernel/kprobes.c 2007-03-31 14:48:57.0 +0200
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: linux-2.6/kernel/kprobes.c
===
--- linux-2.6.orig/kernel/kprobes.c 2007-03-31 14:15:39.0 +0200
+++ linux-2.6/kernel/kprobes.c 2007-03-31 14:20:29.0
2007/3/31, Pedram M <[EMAIL PROTECTED]>:
Ok thanks,
I've sent one already, could you please double check:
@@ -4590,7 +4590,7 @@
printk("stli_findpcibrds()\n");
#endif
- while ((dev = pci_find_device(PCI_VENDOR_ID_STALLION,
+ while ((dev =
2007/3/31, Pedram M <[EMAIL PROTECTED]>:
Do i submit that here?
-
No. Please submit by <[EMAIL PROTECTED]>.
--
So Dark The Con Of Man.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Do i submit that here?
-
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/
Currently all avr32 and sparc64 don't support kretprobes unlike all
other kprobes supporting architectures. This is not nice from the
user interface point of view and from the ugly ifdefs point of view.
Is there a reason these ports can't support kretprobes or was this
simply an oversight /
On 31/03/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Were there any strange binutils in use, Michal?
I don't remember when I had problems with this compiler.
^^^
(sorry, to many bottles of beer)
ld --version
GNU ld version 2.17.50.0.6-2.fc6 20061020
Regards,
Michal
--
Michal K. K.
On Fri, Mar 23, 2007 at 11:12:22AM -0700, Stone, Joshua I wrote:
> The ability to disable/reenable kprobes would be an interesting
> enhancement. However, unregister_disabled_kprobes() shouldn't have a
> global effect, because there might be a concurrent kprobes user that
> disabled a probe with
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Yes, I agree - I don't think we presently have a way of avoiding having
> to send all of that uninteresting data down the pipe.
Have the kernel fork and exec a debug program "just in time" with the dying
process ptrace-attached in advance. That program
On Fri, Mar 23, 2007 at 02:22:48PM -0400, Frank Ch. Eigler wrote:
> Really? What possible problems can occur? The worst that occurs to
> me is that if someone forgets to call the commit function, the kprobes
> will still be disabled, but memory won't be recycled for a while.
Exactly. It's a
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> No, I think that's wrong: whereas the binfmt_elf one did its
> page_cache_release down below at the bottom of the block, this
> version does it in each subblock,
All but the first, which is why there's not a common one post if-complex.
> so there you're
Andrew Morton <[EMAIL PROTECTED]> wrote:
> again?>
I can guess. And it's very probably right. Macros containing return
statements like that are dodgy as they help people screw up the error handling.
However, ...
Andrew Morton <[EMAIL PROTECTED]> wrote:
> -
Mark Rustad wrote:
On Mar 27, 2007, at 1:38 PM, Jeff Garzik wrote:
Mark Rustad wrote:
reorder any queued operations. Of course if you really care about
your data, you don't really want to turn write cache on.
That's a gross exaggeration. FLUSH CACHE and FUA both ensure data
integrity as
> > Well in drivers/net are the network drivers but not the irda and bluetooth
> > drivers,
> > those are located in different folders in drivers/ so I think misc would be
> > the most
> > suitable location.
>
> We could also consider the ./net itself. rfkill is not a driver, it is
> a
Hello,
i got oops on unsing UMTS - hsdpa card merlin xu870 using ppp.
attached you can find the syslog and kernel-config
System is an Acer 5610 with intel core-duo t2300
Greetings
Stephan
Mar 31 14:11:52 localhost pppd[3680]: pppd 2.4.4 started by melvin, uid 1000
Mar 31 14:12:39 localhost
Hi Peter,
On 3/31/07, Peter Samuelson <[EMAIL PROTECTED]> wrote:
...and here it hangs. This happened between 2.6.17-git21 and -git22.
.config is attached. I'd be happy to test patches and provide more
information.
You could try git bisect to find the exact commit that broke your kernel:
[adding some people in CC that expressed interest in the problem before]
Le samedi 31 mars 2007 à 12:37 +0200, Krzysztof Halasa a écrit :
> Nicolas Mailhot <[EMAIL PROTECTED]> writes:
>
> > Oh, is looks so close to my system
> >
> > 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev
Andi Kleen napisał(a):
>> BUG: NMI Watchdog detected LOCKUP on CPU0, eip c014ce9c, registers:
>
> I suspect it is just because his console is too slow and then unwinding
> took too long and it happened to hit the unwinder.
>
> You did use a slow console, right?
console=ttyS0,115200n8
>
> I
On Sat, Mar 31 2007, Adrian Bunk wrote:
> On Sat, Mar 31, 2007 at 10:52:59AM +0800, Jeff Chua wrote:
> > On 3/31/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > >Subject: ThinkPad doesn't resume from suspend to RAM
> > >References : http://lkml.org/lkml/2007/2/27/80
> > >
On Fri, Mar 30, 2007 at 09:04:16PM +0200, Jan Engelhardt wrote:
>
> On Mar 30 2007 15:38, Bharata B Rao wrote:
> >
> >In union mount approach we maintain this stacking information in the
> >dentry structure. When a filesytem is union mounted on a mountpoint,
> >the dentry of the mount root
Clean up ROUND_?UP, Use ALIGN where ever appropriate.
Signed-off-by: Milind Arun Choudhary <[EMAIL PROTECTED]>
---
ccio-dma.c |8
iommu-helpers.h |4 ++--
sba_iommu.c |6 ++
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git
On Sat, 31 Mar 2007, Andreas Schwab wrote:
> "Robert P. J. Day" <[EMAIL PROTECTED]> writes:
>
> > = MACHINE =
> > ./arch/ppc/boot/simple/Makefile:# zimage-$(CONFIG_MACHINE) and
> > zimagerd-$(CONFIG_MACHINE) to the target
> > ./arch/ppc/boot/simple/Makefile:# that produces the desired
Nicolas Mailhot <[EMAIL PROTECTED]> writes:
> Oh, is looks so close to my system
>
> 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
> 00: de 10 50 00 0f 00 a0 00 a3 00 01 06 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00
"Robert P. J. Day" <[EMAIL PROTECTED]> writes:
> = MACHINE =
> ./arch/ppc/boot/simple/Makefile:# zimage-$(CONFIG_MACHINE) and
> zimagerd-$(CONFIG_MACHINE) to the target
> ./arch/ppc/boot/simple/Makefile:# that produces the desired image and they
> must set end-$(CONFIG_MACHINE)
>
On Sat, 2007-03-31 at 19:15 +0900, Satoru Takeuchi wrote:
> It seems to highly depend on # of processes and at present, Ingo's patch
> looks better.
Yeah, Ingo's patch forces the array switch where I try to avoid it if at
all possible. I'm looking ways to know for sure that you just have to
Hi Mike,
> I puttered around with your testcase a bit, and didn't see interactive
> tasks starving other interactive tasks so much as plain old interactive
> tasks starving expired tasks, which they're supposed to be able to do,
I inserted a trace code observing all context switches into the
based on the previous list posted, and some feedback, the updated
list of CONFIG_ variables that exist in Makefiles for which there is
no corresponding Kconfig definition *anywhere* in the source tree.
drivers/:
= L7200_KEYB =
./drivers/acorn/char/Makefile:obj-$(CONFIG_L7200_KEYB) +=
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > also, could you possibly try these workloads you described with
> > Mike's latest patch too? Thanks,
>
> i.e. the one below.
plus the small patch below too.
Ingo
Index: linux/kernel/sched.c
Xenofon,
could you tell us a bit more about the specs of your system? What CPU
speed for example? (i suspect it's a single-CPU box, right?)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
> I am not interested in older processors, but I think for all recent Intel
> processors, there is a fairly simple algorithm to get the frequency using
> a couple of MSRs (including MSR_IA32_EBL_CR_POWERON or MSR_FSB_FREQ).
Hmm, maybe make it an own driver that creates the sysfs entries
On Fri, Mar 30, 2007 at 14:06:34 -0400, Chuck Ebbert wrote:
> Tino Keitel wrote:
> > On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote:
> >> Hello,
> >>
> >> the patches attached to six following emails implement some cleanup and
> >> fixes in the UDF code. The main two fixes are:
> >>
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> also, could you possibly try these workloads you described with Mike's
> latest patch too? Thanks,
i.e. the one below.
Ingo
->
Subject: [patch] sched: improve fairness, v3
From: Mike Galbraith <[EMAIL PROTECTED]>
track
* Xenofon Antidides <[EMAIL PROTECTED]> wrote:
> [...] I cannot play wine games with audio, I cannot sample video, I
> cannot use skype, I cannot play midi. And even linux only things I try
> do I cannot share my X, I cannot use more than one vmware. [...]
strange - i can do such things (and
On Saturday 31 March 2007 08:36, Jeremy Fitzhardinge wrote:
> When I run 2.6.21-rc5 + Andi's x86 patches + paravirt_ops patches, I've
> been getting my machine shut down with critical thermal shutdown messages:
Hmm, don't think there's anything either in x86 that would touch this code.
But can
--- Mike Galbraith <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-03-30 at 22:41 -0700, Xenofon Antidides
> wrote:
>
> > Patch makes X yuck with any load. I stick with SD.
>
> Shrug. My milage is different, but hey, it's a work
> in progress. If SD
> ever gets to the point that it actually
On Fri, Mar 30, 2007 at 03:21:33PM -0700, Ed Lin wrote:
> + if (hba->cardtype == st_shasta) {
> req->lun = lun;
> req->target = id;
> + } else if (hba->cardtype == st_yosemite){
> + req->lun = id * ST_MAX_LUN_PER_TARGET + lun;
> +
* Chris Wright <[EMAIL PROTECTED]> wrote:
> This series converts x86_64 timers to clockevents drivers and then
> enables dynticks. There's some minor cleanups along the way. The
> lapic broadcast mechanism is untested, I'm sure it still needs work,
> there's still some cruft in
Hello,
today I noticed that kernel with 64bit I/O resources reports
incorrect /proc/iomem due to resource_size_t => int => resource_size_t
conversion in drivers/pnp/system.c, turning addresses 2-4GB into
very huge addresses at the top of 64bit address space.
Differences between old and new
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > [] ret_from_fork+0x6/0x1c
>
> Hmpf. I saw it once in child_rip here too. Then I wanted to reproduce
> it to report properly and couldn't again. I had a few other backtraces
> that were all non stuck with child_rip then on essentially the same
>
Everything is in place, so give the CONFIG_NO_HZ option.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: john stultz <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/Kconfig |2 ++
1 file
This is how it's done on i386, and it makes one less bit
of code to trim from main_timer_handler() when converting
to clockevents.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: john stultz <[EMAIL PROTECTED]>
Cc:
Convert lapic, pit and hpet based timers to clockevents.
This brings x86_64 in line with i386. And it is needed
to enable dynticks.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: john stultz <[EMAIL PROTECTED]>
Cc:
Add tick_nohz_{stop,restart}_sched_tick to idle
loop in prepartion for turning on dynticks. These
are just noops until NO_HZ is enabled in next patch.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: john stultz
This series converts x86_64 timers to clockevents drivers
and then enables dynticks. There's some minor cleanups along
the way. The lapic broadcast mechanism is untested, I'm sure it
still needs work, there's still some cruft in lapic_setup_timer.
This is just for comments at this point, now
When making changes to x86_64 timers, I noticed that touching
hpet.h triggered an unreasonably large rebuild. Untangling
it from timex.h quiets the extra rebuild quite a bit.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
---
drivers/char/rtc.c |2
Jeremy Fitzhardinge wrote:
The comment only talks about disabling interrupts for lazy_mmu, but this
seems to do it for lazy_cpu as well. Is that OK? What happens if
someone wants to change interrupt states under lazy_cpu; I can't think
of an inherent reason why that wouldn't be allowed
Hi Ingo,
> > > Hi Ingo and all,
> > >
> > > When I was executing massive interactive processes, I found that some
> > > of them occupy CPU time and the others hardly run.
> >
> > yeah.
> >
> > > I also attach the test program which easily recreates this problem.
> >
> > thanks, this is
Andi,
On Sat, Mar 31, 2007 at 04:31:29AM +0200, Andi Kleen wrote:
> Stephane Eranian <[EMAIL PROTECTED]> writes:
>
> > It seems that the kernel does not expose the Front-Side Bus (FSN) Clock
> > speed to user applications.
>
> You mean the APIC timer frequency which happens to match the FSB
>
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Sat, 31 Mar 2007 09:12:20 +0200 Helge Hafting <[EMAIL PROTECTED]> wrote:
>
>> A new error for me:
>>
>> loading 2.6.21rc5mm3
>> Bios data check successful
>> Destination address not 2M aligned
>> -- System halted
>>
>>
>> This is using the same
Hi,
I've seen this around, and have heard about it in forums and else-where,
could somebody enlighten me with more information or with experiences
they have had. Looks like kswapd begins to eat CPU dramatically till the
box eventually locks up.
Thanks,
Pedram
-
To unsubscribe from this list:
Am Freitag, 30. März 2007 21:47 schrieb Adrian Bunk:
>
>
> No, the code is correct and it's impossible that the variable ever gets
> read uninitialized.
>
> And BTW, i386 gcc 4.1 doesn't give me a warning for this.
> Toralf, which gcc version and architecture did you see this with?
> cu
>
Andrew Morton wrote:
> On Sat, 31 Mar 2007 00:45:59 -0800 Zachary Amsden <[EMAIL PROTECTED]> wrote:
>
>
>> +static void vmi_set_lazy_mode(int new_mode)
>> +{
>> +static DEFINE_PER_CPU(int, mode);
>> +static DEFINE_PER_CPU(unsigned long, flags);
>> +int cpu = smp_processor_id();
>>
Zachary Amsden wrote:
> Critical bugfix; when using software RAID, potentially USB or AIO in
> highmem configurations, drivers are allowed to use kmap_atomic from
> interrupt context. This is incompatible with the current implementation
> of lazy MMU mode, and means the kmap will silently fail,
On Fri, 30 Mar 2007 01:05:59 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/
Somebody is confused (possibly me). Running an x86_64 kernel, and I have:
% cat /proc/acpi/processor/CPU0/power
active state:C0
On Sat, 31 Mar 2007 00:45:59 -0800 Zachary Amsden <[EMAIL PROTECTED]> wrote:
> +static void vmi_set_lazy_mode(int new_mode)
> +{
> + static DEFINE_PER_CPU(int, mode);
> + static DEFINE_PER_CPU(unsigned long, flags);
> + int cpu = smp_processor_id();
That will cause upset if
On Sat, 31 Mar 2007, Nicolas Mailhot wrote:
Le samedi 31 mars 2007 à 01:09 +0300, Mikko Tiihonen a écrit :
Anyone got the same thing for CK804? I had my hopes high, and then I saw
the DECLARE_PCI_FIXUP_HEADER values [and the thread title was misleading]
I have an A8N-E motherboard with
On Sat, 31 Mar 2007 09:12:20 +0200 Helge Hafting <[EMAIL PROTECTED]> wrote:
> A new error for me:
>
> loading 2.6.21rc5mm3
> Bios data check successful
> Destination address not 2M aligned
> -- System halted
>
>
> This is using the same lilo that loads 2.6.18rc5mm1 fine.
> x86-64
>
That's
On Fri, 30 Mar 2007 00:05:39 +0200, Andi Kleen wrote
> On Thursday 29 March 2007 23:16, Linus Torvalds wrote:
> >
> > On Thu, 29 Mar 2007, Andi Kleen wrote:
> > >
> > > Here's a patch. I don't have a system with C1E, so i only tested that
> > > the apic timer still works on a older AMD box.
> >
So lazy MMU mode is vulnerable to interrupts coming in and issuing
kmap_atomic, which does not work when under lazy MMU mode. The window
for this is small, but it means highmem kernels, especially with heavy
network, USB, or AIO workloads are vulnerable to getting invariably
fatal pagefaults
>From bbc89026f3e5d9e437ce4cd26d3013fe226103e2 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <[EMAIL PROTECTED]>
Date: Sat, 31 Mar 2007 09:34:46 +0200
Subject: [PATCH] kconfig/kbuild: fix dependency problem
Commit 2e3646e51b2d6415549b310655df63e7e0d7a080 changed the way
the split config tree is
>From e9fcc3bf8d1c71df1ae650d5291c5d4b15d71656 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <[EMAIL PROTECTED]>
Date: Sat, 31 Mar 2007 09:15:12 +0200
Subject: [PATCH] kconfig: factor out code in conf_spilt_config
This patch simply factor out code and
do not introduce any functional changes.
From: Divy Le Ray <[EMAIL PROTECTED]>
Run the watchdog task when the link is up.
Flush the XGMAC Tx FIFO when the link drops.
Also remove a statistics update that should have gone
in the previous modification of xgmac.c.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
From: Divy Le Ray <[EMAIL PROTECTED]>
Introduce FW micro version.
Bump up FW version to 3.3.0
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_main.c |4 ++--
drivers/net/cxgb3/version.h|5 -
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git
From: Divy Le Ray <[EMAIL PROTECTED]>
Ensure that the TCAM active region size is at least 16.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h|3 +++
drivers/net/cxgb3/cxgb3_main.c|7 +--
drivers/net/cxgb3/cxgb3_offload.c |4 +++-
3
From: Divy Le Ray <[EMAIL PROTECTED]>
Differentiate NIC only adapters from RNICs.
Initialize offload capabilities for RNICs only.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h |6 +++---
drivers/net/cxgb3/cxgb3_main.c |8
A new error for me:
loading 2.6.21rc5mm3
Bios data check successful
Destination address not 2M aligned
-- System halted
This is using the same lilo that loads 2.6.18rc5mm1 fine.
x86-64
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
101 - 200 of 402 matches
Mail list logo
