On Sat, Mar 24, 2007 at 01:41:28PM -0800, Andrew Morton wrote:
> > On Fri, 23 Mar 2007 11:32:44 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > I'm not as concerned about the contended performance of spinlocks
> >
>
> The contended case matters. Back in 2.5.something I screwed up the debug
> > +++ linux-2.6/drivers/s390/char/sclp_confmgm.c
>
> Can we get less cyptic name?
Would you like to see sclp_configuration_management.c?
> > +static void sclp_conf_receiver_fn(struct evbuf_header *evbuf)
> > +{
> > + struct conf_mgm_data *cdata;
> > +
> > + cdata = (struct conf_mgm_data
Hi,
If a Linux process opens and reads a file A, then it closes the file.
Will Linux keep the file A's data in cache for a while in case another
process opens and reads the same in a short time? I think that is what
I heard before.
But after I digged into the kernel code, I am confused.
When a
On Sat, Mar 24, 2007 at 06:29:59PM +0100, Ingo Molnar wrote:
>
> * Nikita Danilov <[EMAIL PROTECTED]> wrote:
>
> > Indeed, this technique is very well known. E.g.,
> > http://citeseer.ist.psu.edu/anderson01sharedmemory.html has a whole
> > section (3. Local-spin Algorithms) on them, citing
On Wed, Mar 28, 2007 at 03:18:58PM +0900, Simon Horman wrote:
> Currently the size of the per-cpu region reserved to save crash
> notes is set by the per-architecture value MAX_NOTE_BYTES. Which
> in turn is currently set to 1024 on all supported architectures.
>
> While testing ia64 I recently
Michael Ellerman <[EMAIL PROTECTED]> writes:
> It's an arch detail whether MSI irqs need to be masked using the PCI
> MSI registers.
Agreed. It isn't an arch detail that they need to be unmasked in
the pci configuration space.
I assume this patch is motivated just to make arch support easier
Michael Ellerman <[EMAIL PROTECTED]> writes:
> The msi descriptors are linked together with what looks a lot like
> a linked list, but isn't a struct list_head list. Make it one.
>
> The only complication is that previously we walked a list of irqs, and
> got the descriptor for each with
Hi all,
The CELF Embedded Linux Conference is less than a month away!
The conference is coming up on April 17, 18, and 19 in San Jose, California.
If you haven't already done so, PLEASE visit the conference website -
http://www.celinux.org/elc2007/ - to check out the session list and
register
From: Pekka Enberg <[EMAIL PROTECTED]>
As NOMMU does not include fs/revoke.c, we need to provide a stub for
generic_file_revoke() so that filesystems using it compile.
Cc: Bryan Wu <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
include/linux/fs.h |4
1 file
There is a tiny probability that the return value from vtime(time_t *t) is
different than the value stored in *t
Using a temporary variable solves the problem and gives a faster code.
17: 48 85 fftest %rdi,%rdi
1a: 48 8b 05 00 00 00 00mov0(%rip),%rax#
Currently the size of the per-cpu region reserved to save crash
notes is set by the per-architecture value MAX_NOTE_BYTES. Which
in turn is currently set to 1024 on all supported architectures.
While testing ia64 I recently discovered that this value is
in fact too small. The particular setup I
Jay Cliburn wrote:
From: Jay Cliburn <[EMAIL PROTECTED]>
The original vendor driver contained a private ether_crc_le() function
that produced an inverted crc. When we changed to the kernel version of
ether_crc_le(), we neglected to undo the inversion. Let's do it now.
Discovered by and patch
On Mon, 2007-03-26 at 15:12 +0300, Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> There's just no sane way to revoke shared memory mappings for NOMMU so lets
> disable the thing completely when CONFIG_MMU=n.
>
> Cc: Bryan Wu <[EMAIL PROTECTED]>
> Cc: David Howells <[EMAIL
Michael Ellerman <[EMAIL PROTECTED]> writes:
> When freeing an MSI-X in msi_free_irq(), the irq must have already been
> free'd (otherwise we'd hit the BUG_ON), and in the process will have been
> masked or otherwise disabled by the irq chip methods. So there's no
> reason to mask again in the
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Consolidate precondition checks into a single if statement.
Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Add an arch_msi_supported(), which gives archs a chance to check the input
> to pci_enable_msi/x. For MSI-X this routine might need the entry array, so
> pass it in. For plain MSI, NULL is passed, the arch routine needs to cope
> with that. Propagate
On Tue, 2007-03-27 at 23:20 -0600, Eric W. Biederman wrote:
> Michael Ellerman <[EMAIL PROTECTED]> writes:
>
> > I don't think it's that confusing. I agree it was a bit weird that
> > previously it was explicitly checking for < 0, so I fixed that.
>
> The previous case was clearer. This isn't a
On another thought if we want to keep the return code we should
probably rename it pci_msi_verify(). Or something like that
so it is clear we are not asking if it is supported a question
with a boolean answer. But merely verifying that it is supported.
At which point if the verification
Michael Ellerman <[EMAIL PROTECTED]> writes:
> I don't think it's that confusing. I agree it was a bit weird that
> previously it was explicitly checking for < 0, so I fixed that.
The previous case was clearer. This isn't a please do some work
for me function, where we expect occasional failure
On Tue, 2007-03-27 at 22:45 -0600, Eric W. Biederman wrote:
> Michael Ellerman <[EMAIL PROTECTED]> writes:
>
> > pci_enable_msi() and pci_enable_msix() both search for the MSI/MSI-X
> > capability, we can fold this into pci_msi_supported() by passing the
> > type in.
> >
> > Update the code to
Michael Ellerman <[EMAIL PROTECTED]> writes:
> pci_enable_msi() and pci_enable_msix() both search for the MSI/MSI-X
> capability, we can fold this into pci_msi_supported() by passing the
> type in.
>
> Update the code to match the comment for pci_msi_supported(). That is
> it returns 0 on
Michael Ellerman <[EMAIL PROTECTED]> writes:
> We don't need a special cache just for msi descriptors. They're not
> particularly large, under 100 bytes for sure, and don't seem to require any
> special alignment etc. On most systems there will be relatively few MSIs,
> and hence we waste most of
On Tue, Mar 27, 2007 at 02:27:45PM -0400, Jeff Dike wrote:
> These are all 2.6.22 material.
err, I meant 2.6.21...
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Michael Ellerman <[EMAIL PROTECTED]> writes:
> When freeing MSIs and MSI-Xs, we BUG_ON() if the irq has not been
> freed, ie. if it still has an action. We can consolidate all of these
> BUG_ON()s into msi_free_irqs() as all the code paths lead there almost
> immediately anyway.
Acked-by: "Eric
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Move EXPORT_SYMBOL()s near their definition.
Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Michael Ellerman <[EMAIL PROTECTED]> writes:
> For the MSI-X case we do exactly the same logic in pci_disable_msix() and
> msi_remove_pci_irq_vectors(), so consolidate them.
>
> msi_remove_pci_irq_vectors() wasn't setting dev->first_msi_irq to 0, but
> I think it should have been, so the
On Tue, Mar 27, 2007 at 11:17:43PM -0400, Bill Nottingham wrote:
> Kay Sievers ([EMAIL PROTECTED]) said:
> > >If you *do* try to use one of these names, the rename will succeed...
> > >partway. The link in /sys/class/net is renamed, the directory is
> > >not (as it obviously can't rename on top
On Wed, Mar 28, 2007 at 04:26:05AM +0100, Sid Boyce wrote:
> Eric W. Biederman wrote:
> >Sid Boyce <[EMAIL PROTECTED]> writes:
> >
> >
> >>This is what I've got so far on the first boot, I shall have to check the
> >>manpage for git-bisect again to see if there is anything else to be added,
>
On Wed, Mar 28, 2007 at 02:16:08AM +0100, Matthew Garrett wrote:
> It's ata_read_native_max_address_ext failing, and it's fine if I use
> ahci rather than ata_piix, so I'll just chalk this up to Apple's
> firmware being broken (again) and putting the hardware into some sort of
> "I can't
On Tuesday 27 March 2007 23:28, Len Brown wrote:
> Thomas,
>
> Is this failure specific to NO_HZ, and that is why the "nolapic_timer" fix is
> i386 only?
> I'm running 2.6.21-rc5 an nx6325 here in 64-bit mode and I don't see the
> dramatic
> boot failure described earlier in this thread.
>
>
I am not sure where to post this, maybe you can direct me what to do, if
anything.
We have two computers running slackware for amd64 version 11.0.
Tonight we compiled mplayer on each of the systems.
On the first, everything compiled fine--it has a core 2 duo cpu and is
running a stock kernel
Thomas,
Is this failure specific to NO_HZ, and that is why the "nolapic_timer" fix is
i386 only?
I'm running 2.6.21-rc5 an nx6325 here in 64-bit mode and I don't see the
dramatic
boot failure described earlier in this thread.
However, I have observed that when running on battery,
the LOC falls
BIT macro cleanup,now in bitops.h
Signed-off-by: Milind Arun Choudhary <[EMAIL PROTECTED]>
---
arch/ppc/platforms/chestnut.c |1
drivers/edac/edac_mc.h |2 -
drivers/i2c/busses/i2c-pxa.c| 55 ++--
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Although it might be nice to do a printk before BUG'ing, it's really not
> necessary, and it complicates the code.
>
> The behaviour has changed slightly, in that before we set a flag if the irq
> had an action, and continued freeing the other irqs.
Eric W. Biederman wrote:
Sid Boyce <[EMAIL PROTECTED]> writes:
This is what I've got so far on the first boot, I shall have to check the
manpage for git-bisect again to see if there is anything else to be added,
nothing enlightening seen so far - further reboots to be done.
I'm a
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Although it might be nice to do a printk before BUG'ing, it's really not
> necessary, and it complicates the code.
Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Kay Sievers ([EMAIL PROTECTED]) said:
> >If you *do* try to use one of these names, the rename will succeed...
> >partway. The link in /sys/class/net is renamed, the directory is
> >not (as it obviously can't rename on top of whatever is already there.)
> >Various networking tools then break in
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Although it might be nice to do a printk before BUG'ing, it's really not
> necessary, and it complicates the code.
>
> The behaviour has changed slightly, in that before we set a flag if the irq
> had an action, and continued freeing the other irqs.
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Although it might be nice to do a printk before BUG'ing, it's really not
> necessary, and it complicates the code.
>
Acked-by: Eric W. Biederman <[EMAIL PROTECTED]>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> ---
>
> drivers/pci/msi.c
On Tuesday 27 March 2007 17:34, johann deneux wrote:
> What about adding a member to ff_effect which would be the number of the
> motor?
> We can't change the layout of ff_effect too much though, so we have to
> find unused bits and put them to work.
>
> For instance, we could replace
>
> __u16
黃建興-Jesse wrote:
> Dear Sirs,
>
> I have got the status.
> I appreciate your contribution to this driver.
> And if anything I can help or any update, please let me know.
Someone needs to send me a signed-off patch.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe
>> Tue, 27 Mar 2007 15:51:39 -0700
>> [Subject: (usagi-core 32652) Re: [linux-usb-devel] [PATCH 0/2] [SERIAL]
>> [USB] fixed to skip NULL entry in struct serial usb_serial_port.]
>> Greg KH <[EMAIL PROTECTED]> wrote...
> > I think so. But I wonder if usb_get_serial_port_data() should check
> >
Andi Kleen wrote:
> init functions should only ever be called from other init functions.
>
> So this should not happen. If it happens the annotations need to be fixed.
>
I've seen some versions of gcc inline weak functions too.
J
-
To unsubscribe from this list: send the line "unsubscribe
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
drivers/char/Kconfig | 33 +
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 3429ece..d0c978f 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -386,6 +386,39 @@ config
On Tuesday 27 March 2007 18:16, Len Brown wrote:
> On Tuesday 27 March 2007 17:34, Linus Torvalds wrote:
> >
> > On Tue, 27 Mar 2007, Len Brown wrote:
> > >
> > > I think the only fool-proof way to do this automatically is to
> >
> > Why not just take the known-good CPUID signature?
> >
> >
On Tuesday March 27, [EMAIL PROTECTED] wrote:
> On Tue, Mar 27, 2007 at 11:40:48AM -0700, Phy Prabab wrote:
> > Hello,
> >
> > I am currently running 2.6.21-rc5 and I am seeing quite a bit of this
> > message in my log files:
> > kernel: rpcsvc: received unknown control message:-2144992132/-1
> >
In that case, Bryan may like to know that git, mercurial (IIRC),
and quilt have patchbomb tools. Also GregKH has one somewhere (he
can tell you where). And Paul Jacksone has one at
http://www.speakeasy.org/~pj99/sgi/sendpatchset
Thanks a lot, I will try on my side. And one more
On Tue, 2007-03-27 at 08:34 -0700, Randy Dunlap wrote:
> On Tue, 27 Mar 2007 13:40:45 +0800 Wu, Bryan wrote:
>
> > On Mon, 2007-03-26 at 22:27 -0700, Randy Dunlap wrote:
> > > On Tue, 27 Mar 2007 01:17:06 -0400 Mike Frysinger wrote:
> > >
> > > > On 3/27/07, Paul Mundt <[EMAIL PROTECTED]> wrote:
On Mar 27 2007 17:07, Paweł Sikora wrote:
>
> The recent gcc (3.4/4.x) optimizer inlines functions across
> sections which is definitely not we want, e.g. inlining
> functions from .init.text section.
>
> I think, the `__init' macro needs `noinline' attribute and all
An function from the .init
[ This patch needs to get into 2.6.21, as it fixes a serious bug
introduced soon after 2.6.20 ]
Commit 62f96cb01e8de7a5daee472e540f726db2801499 introduced per-devices
queues and locks, which was fine as far as it went, but left in place
a global which controlled access to submitting requests to
Marcel Holtmann wrote:
> please don't take the transport layers into account when designing the
> HID bus. They have nothing to do with the upper layer. Especially the
> upper layer shouldn't care at all if the actual HID reports are sent
> over USB or Bluetooth.
>
>
I am sorry for I see this
> Linux _will_ write all modified data to permanent storage locations.
> Since 2.6.17 it will do this regardless of msync(). Before 2.6.17 you
> do need msync() to enable data to be written back.
>
> But it will not start I/O immediately, which is not a requirement in
> the standard, or at least
On Mar 27, 2007, at 12:04 PM, Adam Belay wrote:
On Mon, 2007-03-26 at 13:36 +0800, Shaohua Li wrote:
Hi,
On Sat, 2007-03-24 at 03:47 -0400, Adam Belay wrote:
This patch adds the 'menu' governor, as was described in my first
email.
+/**
+ * menu_select - selects the next idle state to
So I've been putting off this change for awhile since there's been so
much churn in the timekeeping code, but now looking at both -mm and -rt
it seems there is only a minimal amount of timekeeping changes pending,
so I wanted to send this out there for comments before pushing it to -mm
On Tue, Mar 27, 2007 at 07:17:49PM +0200, Cornelia Huck wrote:
> On Tue, 27 Mar 2007 11:25:57 +0200,
> "Kay Sievers" <[EMAIL PROTECTED]> wrote:
> > Checking the uevent return value, will not prevent any malfunction,
> > usually this kind of "error handling" just prevents bringing up a
> > whole
Herbert Poetzl wrote:
On Sat, Mar 24, 2007 at 12:19:06PM -0800, Andrew Morton wrote:
Or change the reclaim code so that a page which hasn't
been referenced from a process within its hardware
container is considered unreferenced (so it gets reclaimed).
that might easily lead to some
Hi Ingo,
At Tue, 27 Mar 2007 21:14:20 +0200,
Ingo Molnar wrote:
>
>
> * Satoru Takeuchi <[EMAIL PROTECTED]> wrote:
>
> > 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
On Wed, Mar 28, 2007 at 01:16:10AM +0100, Matthew Garrett wrote:
> comment seems to be wrong (or, alternatively, it's the
> ata_read_native_max_address_ext call that's failing and returning
> garbage? I'll look into that)
It's ata_read_native_max_address_ext failing, and it's fine if I use
"Williams, Mitch A" <[EMAIL PROTECTED]> writes:
> Doh! I was reading the code wrong. We only mask if we're still
> handling a previous interrupt on the same vector. My bad.
>
> However, I can't really see where mask() is used outside of that
> instance. Which then leads us back to the
On Wed, 28 Mar 2007 01:00:24 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Subject: atl1 net driver: problem with sockets
> References : http://lkml.org/lkml/2007/3/21/248
> Submitter : Jose Alberto Reguero <[EMAIL PROTECTED]>
> Patch :
From: Jay Cliburn <[EMAIL PROTECTED]>
The original vendor driver contained a private ether_crc_le() function
that produced an inverted crc. When we changed to the kernel version of
ether_crc_le(), we neglected to undo the inversion. Let's do it now.
Discovered by and patch proffered by Jose
On Wed, Mar 28, 2007 at 01:08:52AM +0100, Matthew Garrett wrote:
> ata3.01: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 0
^
Does this just indicate the lack of an hpa? If so, the
/* if no hpa, both should be equal */
On Fri, Mar 23, 2007 at 07:13:21PM +, Alan Cox wrote:
> For reference this is what I am currently using with 2.6.21-rc4-mm1 and
> it is working for all my test cases so far: Its basically Kyle's patch
> with a libata switch to turn it on/off and some minor fixups from
> the original patch as
On Mon, Mar 26, 2007 at 07:32:00PM -0400, Robert P. J. Day wrote:
>
> the output from a short script i wrote, locating all CONFIG_
> variables in makefiles that don't appear to exist in any Kconfig file
> anywhere in the source tree.
>
> first, from the drivers/ directory:
>...
> = ZS
On Tue, Mar 27, 2007 at 03:44:01PM -0700, Zach Brown wrote:
> The user can generate console output if they cause do_mmap() to fail during
> sys_io_setup(). This was seen in a regression test that does exactly that by
> spinning calling mmap() until it gets -ENOMEM before calling io_setup().
>
>
On Tuesday 27 March 2007 20:05:24 Pete Zaitcev wrote:
> On Tue, 27 Mar 2007 13:15:14 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]>
> wrote:
>
> > > Suspend to disk still causes "virtual replugging" and I think that
> > > controller is reset and will unplug/replug devices anyway
> > > Resolving
Andrew Morton wrote:
On Tue, 27 Mar 2007 23:29:34 +0200
Eric Dumazet <[EMAIL PROTECTED]> wrote:
Andrew Morton a écrit :
The wheel spins around, slows then settles on
time-smp-friendly-alignment-of-struct-clocksource.patch!
Presumably because the cacheline_aligned made
On Tue, Mar 27, 2007 at 01:03:51PM +0200, Cornelia Huck wrote:
> On Tue, 27 Mar 2007 03:02:51 +0200,
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > This patch removes the PCI_MULTITHREAD_PROBE option that had already
> > been marked as broken.
> >
> > Signed-off-by: Adrian Bunk <[EMAIL
On Mon, Mar 26, 2007 at 09:38:15AM +0900, Noriaki TAKAMIYA wrote:
> Hi,
>
> >> Sun, 25 Mar 2007 08:55:21 -0700
> >> [Subject: (usagi-core 32640) Re: [linux-usb-devel] [PATCH 0/2] [SERIAL]
> >> [USB] fixed to skip NULL entry in struct serial usb_serial_port.]
> >> Greg KH <[EMAIL PROTECTED]>
On Wednesday, 28 March 2007 01:00, Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20
> with patches available.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver,
> > > > > For each fd the information is provided in the following format:
> > > > >
> > > > > pos: 1234
> > > > > flags:012
> > > >
> > > > Octal? Maybe we should use more traditional hex here?
> >
> > It's octal in , so it's easier for a human to read.
> >
> > > Good point. The
+#define pipe_kmap_atomic(page, type) pipe_kmap(page)
+#define pipe_kunmap(page) do { } while (0)
+#define pipe_kunmap_atomic(page, type) do { } while (0)
Please don't drop arguments in stubs. It can let completely broken
code compile, like:
Pavel Machek napisał(a):
> Hi!
>>> There's various fixes here, ranging from some architecture updates (ia64,
>>> ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
>>>
>> Suspend to disk doesn't work for me with this patch. It hangs after
>> PM: Preparing devices for restore.
>>
We don't need this printk all, just remove it.
("at all". Sigh.)
- z
-
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
[PATCH] [qla2xxx] Remove duplicate pci_disable_device() call
On the path qla2x00_probe_one() -> probe_failed -> qla2x00_free_device(),
pci_disable_device() is executed twice, once in qla2x00_free_device()
and once in qla2x00_probe_one().
This patch removes the unnecessary call.
Signed-off-by:
Adrian Bunk schrieb:
> It's now in Linus' tree.
>
> Thomas (Meyer), are there any regressions left with the latest -git tree
> plus the MSI fix?
>
No, not for me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Randy Dunlap wrote:
> func() or ??
> and what does "nearly ready" mean?
>
Sorry, I forgot to include your doc updates from last time.
"nearly ready" means that its just about to call the function, but
hasn't necessarily done so.
J
-
To
aio: remove bare user-triggerable error printk
The user can generate console output if they cause do_mmap() to fail during
sys_io_setup(). This was seen in a regression test that does exactly that by
spinning calling mmap() until it gets -ENOMEM before calling io_setup().
We don't need this
On Tue, 27 Mar 2007 15:13:29 -0700 Jeremy Fitzhardinge wrote:
> smp_call_function and smp_call_function_single are almost complete
> duplicates of the same logic. This patch combines them by
> implementing them in terms of the more general
> smp_call_function_mask().
>
> [ Jan, Andi: This only
On Wed, Mar 28, 2007 at 02:22:27AM +0400, Oleg Nesterov wrote:
> On 03/27, Venki Pallipadi wrote:
> >
> > @@ -368,7 +368,7 @@
> >
> > for (;;) {
> > tvec_base_t *prelock_base = timer->base;
> > - base = timer_get_base(timer);
> > + base =
Hi!
> > > > For each fd the information is provided in the following format:
> > > >
> > > > pos:1234
> > > > flags: 012
> > >
> > > Octal? Maybe we should use more traditional hex here?
>
> It's octal in , so it's easier for a human to read.
>
> > Good point. The O_foo flags are
On 03/28, Oleg Nesterov wrote:
>
> looks a little bit ugly, but may be this is just me. How about
>
> void timer_set_base(struct timer_list *timer, struct tvec_t_base_s
> *new_base)
> {
> timer->base = (struct tvec_t_base_s *)
> ((unsigned
On Tuesday 27 March 2007 17:34, Linus Torvalds wrote:
>
> On Tue, 27 Mar 2007, Len Brown wrote:
> >
> > I think the only fool-proof way to do this automatically is to
>
> Why not just take the known-good CPUID signature?
>
> Screw firmware or ACPI tables. They're going to be occasionally wrong.
Hi!
> >There's various fixes here, ranging from some architecture updates (ia64,
> >ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
> >
>
> Suspend to disk doesn't work for me with this patch. It hangs after
> PM: Preparing devices for restore.
> Suspending console(s)
> during
On Tue, Mar 27, 2007 at 12:09:13PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, 27 March 2007 03:59, Adrian Bunk wrote:
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> >
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs,
If we're about to enter a prolonged period in which we know we're
going to hold off scheduler ticks, then disable the CPU's softlockup
watchdog for the duration. This avoids having to repeatedly touch the
timestamp, or conversely, risk having the watchdog timeout in the
middle of your long
Jeff Garzik <[EMAIL PROTECTED]> :
> Jesse Huang wrote:
> >Dear all:
> >
> >Would someone tell me the current status of IP1000A Linux Driver?
> >Would it be putted into Linux Kernel or not?
>
> I forgot what the status of this was? Didn't it need some cleanups?
More cleanups than what it already
On a NO_HZ system, there may be an arbitrarily long delay between
ticks on a CPU. When we're disabling ticks for a CPU, also disable
the softlockup watchdog timer.
This makes the touch_softlockup_watchdog() interface redundant; if a
piece of code knows its going to be holding off timer
Some machine-wide activities can cause spurious softlockup watchdog
warnings, so add a mechanism to allow the watchdog to be disabled.
The most obvious activity is suspend/resume, but long sysrq output can
also stall the system long enough to cause problems.
Signed-off-by: Jeremy Fitzhardinge
The softlockup watchdog is currently a nuisance in a virtual machine,
since the whole system could have the CPU stolen from it for a long
period of time. While it would be unlikely for a guest domain to be
denied timer interrupts for over 10s, it could happen and any softlockup
message would be
Hi Ingo,
This series of patches implements a number of improvements to the
softlockup watchdog and its users.
They are:
1. Make the watchdog ignore stolen time
When running under a hypervisor, the kernel may lose an arbitrary amount
of time as "stolen time". This may cause the softlockup
On 03/27, Venki Pallipadi wrote:
>
> Incremental patch below eliminates this race.
>
> Index: new/kernel/timer.c
> ===
> --- new.orig/kernel/timer.c 2007-03-26 15:19:35.0 -0800
> +++ new/kernel/timer.c2007-03-27
smp_call_function and smp_call_function_single are almost complete
duplicates of the same logic. This patch combines them by
implementing them in terms of the more general
smp_call_function_mask().
[ Jan, Andi: This only changes arch/i386; can x86_64 be changed in the
same way? ]
[ Rebased
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.
Turning
Jeremy Fitzhardinge wrote:
> [ Andrew: Patch is based on 2.6.21-rc5-mm1 + the pda->percpu patch I
> posted the other day. It will have a minor context conflict without
> that patch, but is otherwise standalone. ]
>
Sorry, it also depends on simplify-smp_call_function.patch, which I'll
Add a smp_ops interface. This abstracts the API defined by
for use within arch/i386. The primary intent is that it
be used by a paravirtualizing hypervisor to implement SMP, but it
could also be used by non-APIC-using sub-architectures.
This is related to CONFIG_PARAVIRT, but is implemented
On Sun, 2007-03-25 at 15:45 -0800, Andrew Morton wrote:
> On Sat, 24 Mar 2007 23:04:09 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > This patch adds support for finding out the current file position,
> > open flags and possibly other info in the future.
> >
> > These new entries are
On Wed, Mar 28, 2007 at 01:11:45AM +0400, Oleg Nesterov wrote:
> On 03/27, Venki Pallipadi wrote:
> >
> > for (;;) {
> > - base = timer->base;
> > + tvec_base_t *prelock_base = timer->base;
> > + base = timer_get_base(timer);
> > if (likely(base !=
On Tue, 27 Mar 2007, Len Brown wrote:
>
> I think the only fool-proof way to do this automatically is to
Why not just take the known-good CPUID signature?
Screw firmware or ACPI tables. They're going to be occasionally wrong.
If we know that "Core 2, version X" has a good local APIC timer,
Eric W. Biederman wrote:
>> However the mask function is called at EVERY interrupt,
>> so this change would be VERY expensive.
>
>If true I think that would be bad. However I don't see it.
>Where in handle_edge_irq do we mask the interrupt?
>The only place I see us calling ->mask is from
1 - 100 of 676 matches
Mail list logo
