On Thu, Feb 14, 2008 at 11:17:03PM -0800, Greg KH wrote:
> Hm, that's wierd. I thought I got something, until I realized that
> you are doing a lot of logic before you ever even determine that
> your hardware is present in the system. Why are you calling
> calgary_locate_bbars() and doing all
On Fri, Feb 15, 2008 at 08:33:06AM +0100, Sam Ravnborg wrote:
> On Fri, Feb 15, 2008 at 02:56:48AM +0200, Adrian Bunk wrote:
> > The pattern for making a config option on purpose not available is a
> > dependency on BROKEN.
> BROKEN says that what is selected by the cofig option
> is broken.
>
On Fri, 2008-02-15 at 08:08 +0100, Ingo Molnar wrote:
> * Huang, Ying <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2008-02-14 at 17:12 +0100, Ingo Molnar wrote:
> > > this is indeed a bug (we change the attributes for a larger area than
> > > needed), but your fix is unclean. Find below a cleaner
On Fri, Feb 15, 2008 at 02:56:48AM +0200, Adrian Bunk wrote:
> The pattern for making a config option on purpose not available is a
> dependency on BROKEN.
BROKEN says that what is selected by the cofig option
is broken.
This is not the case for DEBUG_SECTION_MISMATCH which is
why it was made
Hi all,
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git.
Between each merge, the tree was built with allmodconfig for both
powerpc and x86_64.
You can see which trees have been included by looking in the Trees file
in the source.
The
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> So *if* we care (I doubt we do, since EFI_PAGE_SHIFT at least right
> now matches PAGE_SHIFT on x86), you'd probably want to do something
> like
>
> static inline unsigned long efi_pages_to_native_pages(unsigned long
> efi_pages)
> {
> #if
On Wed, Feb 13, 2008 at 10:14:59AM -0800, Greg KH wrote:
> On Wed, Feb 13, 2008 at 07:47:11PM +0200, Muli Ben-Yehuda wrote:
> > On Wed, Feb 13, 2008 at 09:32:03AM -0800, Greg KH wrote:
> >
> > > Is there some reason you aren't using the "real" PCI driver api here
> > > and registering a pci
On Thu, Feb 14, 2008 at 01:11:42PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 14 February 2008, Andreas Jaeger wrote:
> > Greg KH <[EMAIL PROTECTED]> writes:
> >
> > > How does the patch below look? I didn't want to remove the whole config
> > > option, as there is more to the logic
* Huang, Ying <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-02-14 at 17:12 +0100, Ingo Molnar wrote:
> > this is indeed a bug (we change the attributes for a larger area than
> > needed), but your fix is unclean. Find below a cleaner solution.
> >
> > Ying, if you agree with this fix could you
On Wed, Feb 13, 2008 at 07:55:53PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, 13 of February 2008, Greg KH wrote:
> > On Wed, Feb 13, 2008 at 12:39:13PM +0100, Frans Pop wrote:
> > > On Tuesday 12 February 2008, Greg KH wrote:
> > > > On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote:
On Thu, Feb 14, 2008 at 03:38:13PM -0800, Yinghai Lu wrote:
> On Wed, Feb 13, 2008 at 8:58 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Feb 13, 2008 at 12:39:13PM +0100, Frans Pop wrote:
> > > On Tuesday 12 February 2008, Greg KH wrote:
> > > > On Tue, Feb 12, 2008 at 09:39:14PM +0100,
On Thu, Feb 14, 2008 at 03:38:13PM -0800, Yinghai Lu wrote:
> On Wed, Feb 13, 2008 at 8:58 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Feb 13, 2008 at 12:39:13PM +0100, Frans Pop wrote:
> > > On Tuesday 12 February 2008, Greg KH wrote:
> > > > On Tue, Feb 12, 2008 at 09:39:14PM +0100,
On my 16-core tigerton, kernel panic when I ran hackbench process testing. See
below log.
Commandline to start hackbench:
#./hackbench 150 process 2000
Kernel config options:
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
Kernel panic at line 1637 in
On Tue, 5 Feb 2008 18:44:32 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> This patch adds support for the framebuffers with non-native
> endianness. This is done via FBINFO_FOREIGN_ENDIAN flag that will
> be used by the drivers. Depending on the host endianness this flag
> will be
These special additional callbacks are required because XPmem (and likely
other mechanisms) do use their own rmap (multiple processes on a series
of remote Linux instances may be accessing the memory of a process).
F.e. XPmem may have to send out notifications to remote Linux instances
and receive
The invalidation of address ranges in a mm_struct needs to be
performed when pages are removed or permissions etc change.
If invalidate_range_begin() is called with locks held then we
pass a flag into invalidate_range() to indicate that no sleeping is
possible. Locks are only held for truncate
Two callbacks to remove individual pages as done in rmap code
invalidate_page()
Called from the inner loop of rmap walks to invalidate pages.
age_page()
Called for the determination of the page referenced status.
If we do not care about page referenced status then an age_page
The skeleton for the rmap notifier leaves the invalidate_page method of
the mmu_notifier empty and hooks a new invalidate_page callback into the
global chain for mmu_rmap_notifiers.
There are seveal simplifications in here to avoid making this too complex.
The reverse maps need to consit of
This is example code for a simple device driver interface to unmap
pages that were externally mapped.
Locking is simple through a single lock that is used to protect the
device drivers data structures as well as a counter that tracks the
active invalidates on a single address space.
The
MMU notifiers are used for hardware and software that establishes
external references to pages managed by the Linux kernel. These are
page table entriews or tlb entries or something else that allows
hardware (such as DMA engines, scatter gather devices, networking,
sharing of address spaces across
This is a patchset implementing MMU notifier callbacks based on Andrea's
earlier work. These are needed if Linux pages are referenced from something
else than tracked by the rmaps of the kernel (an external MMU). MMU
notifiers allow us to get rid of the page pinning for RDMA and various
other
On Thu, 14 Feb 2008 12:32:29 PST, Greg KH said:
> How about "weeks". Both Fedora and openSUSE's next release is going to
> be based on 2.6.25, and the first round of -rc1 kernels should be
> showing up in their trees in a few days. So for this instance, I think
> you will be fine :)
a few days
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
Do you also have a patch to update the boot protocol?
Looking for anything different than the root of this thread?
Yes, the patch for the Xen domain builder to boot a bzImage using the
Linux boot protocol rather than the Xen one. Ian's
scripts/checkpatch.pl
ERROR: do not initialise externals to 0 or NULL
#113: FILE: arch/x86/boot/video-mode.c:29:
+int do_restore = 0;/* Screen contents changed during mode flip */
WARNING: Use of volatile is usually wrong: see
Documentation/volatile-considered-harmful.txt
#644: FILE:
Hi Andrew.
DIO invalidates page cache through invalidate_inode_pages2_range().
invalidate_inode_pages2_range() sets ret=-EIO when invalidate_complete_page2()
fails, but this ret is cleared if do_launder_page() succeed on a page of next
index.
In this case, dio is carried out even if
On Fri, 2008-02-15 at 07:05 +0100, Eric Dumazet wrote:
> Zhang, Yanmin a �crit :
> > Comparing with kernel 2.6.24, tbench result has regression with
> > 2.6.25-rc1.
> >
> > 1) On 2 quad-core processor stoakley: 4%.
> > 2) On 4 quad-core processor tigerton: more than 30%.
> >
> > bisect located
On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said:
> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing
> to
> indicate its not a problem until some distro actually ships a kernel with the
> changes that broke it. That could be months or even a year plus.
Actually
On Thu, 2008-02-14 at 21:44 -0800, Linus Torvalds wrote:
>
> On Fri, 15 Feb 2008, Huang, Ying wrote:
> >
> > I think the patch following may be better, because it is possible that
> > the EFI_PAGE_SHIFT and PAGE_SHIFT are different.
>
> If this is a problem in practice, we'd be better off
On Tue, 05 Feb 2008 22:36:16 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> Just documentation updates, compared to the previous submission.
> Thanks to Serge for the relentless reviews :)
>
> Please consider for -mm, and then for 2.6.26.
Linus has just merged all the VFS renaming patches,
Hi Len,
On Thu, 14 Feb 2008 23:58:38 -0500 Len Brown <[EMAIL PROTECTED]> wrote:
>
> Rafael has it right, please add the branch above.
> It will include both the upcoming ACPI and suspend patches.
Added, thanks, with you as contact.
> Note that I reserve the right to re-base it from time to time
On Friday 15 February 2008 00:22, Thomas, Sujith wrote:
> From: Thomas Sujith <[EMAIL PROTECTED]>
Thanks Sujith, this patch series was a massive improvement over the last one --
checkpatch.pl clean and everything:-)
I think if you can get rid of the outlook-destroys-plain text via word-wrap
so
Zhang, Yanmin a écrit :
Comparing with kernel 2.6.24, tbench result has regression with
2.6.25-rc1.
1) On 2 quad-core processor stoakley: 4%.
2) On 4 quad-core processor tigerton: more than 30%.
bisect located below patch.
b4ce92775c2e7ff9cf79cca4e0a19c8c5fd6287b is first bad commit
commit
On Fri, 15 Feb 2008, Huang, Ying wrote:
>
> I think the patch following may be better, because it is possible that
> the EFI_PAGE_SHIFT and PAGE_SHIFT are different.
If this is a problem in practice, we'd be better off having a helper
function to do it, to avoid overflows. Right now, doing
>
From: Thomas Sujith <[EMAIL PROTECTED]>
Need to extract errors using PTR_ERR macro and
process accordingly.thermal_cooling_device_register
returning NULL means that CONFIG_THERMAL=n and in that
case no need to create symbolic links.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
---
On Thu, Feb 14, 2008 at 8:44 PM, Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Feb 14, 2008, at 12:14 PM, Dan Williams wrote:
>
> > On Wed, Feb 13, 2008 at 8:52 PM, Kumar Gala
> > <[EMAIL PROTECTED]> wrote:
> >> Dan,
> >>
> >> What's going on with the dma engine drivers for 2.6.25? We had a
From: Thomas Sujith <[EMAIL PROTECTED]>
Need to check whetherthermal_cooling_device_register
returned ERROR or not.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
---
drivers/acpi/video.c |3 +++
1 files changed, 3 insertions(+)
Index: linux-2.6.24/drivers/acpi/video.c
From: Thomas Sujith <[EMAIL PROTECTED]>
Need to return using ERR_PTR instead of NULL
in case of errors.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
---
drivers/thermal/thermal.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
Index:
From: Thomas Sujith <[EMAIL PROTECTED]>
Need to extract errors using PTR_ERR macro and
process accordingly.thermal_cooling_device_register
returning NULL means that CONFIG_THERMAL=n and in that
case no need to create symbolic links.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
---
From: Thomas Sujith <[EMAIL PROTECTED]>
Added sanity check to make sure that thermal zone
and cooling device exists.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
---
drivers/thermal/thermal.c | 13 -
1 files changed, 12 insertions(+), 1 deletion(-)
Index:
From: Thomas Sujith <[EMAIL PROTECTED]>
Need to extract errors using PTR_ERR macro and
process accordingly.thermal_cooling_device_register
returning NULL means that CONFIG_THERMAL=n and in that
case no need to create symbolic links.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
---
Roland Dreier wrote:
> Wow, good catch. How did you find this bug?
>
Just by accident, when I glanced down the code. ;)
> Anyway, thanks, applied.
>
> - R.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Greg KH wrote:
> On Thu, Feb 14, 2008 at 07:55:44PM +1030, David Newall wrote:
>
>> The current 2.6 driver maintains it's own buffer. I think that's a bad
>> thing: usbserial already buffers writes, and the extra buffer copy seems
>> unnecessary, however it does solve the putchar problem.
Wow, good catch. How did you find this bug?
Anyway, thanks, applied.
- R.
--
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
Alan Cox wrote:
>> byte of a packet is being thrown away about .1% of the time for the pl2303,
>> but I'm not sure if the FTDI driver still suffers from a similar rash. I
>>
>
> A 20 byte low speed message is too small for flow control to account for
> it.
I agree. I've observed the
On Thu, 2008-02-14 at 23:56 +, Ben Dooks wrote:
> On Thu, Feb 14, 2008 at 01:53:15PM -0800, Harvey Harrison wrote:
> > In C, signed 1-bit bitfields can only take the values 0 and -1, only
> > 0 and 1 are ever assigned in current code. Make them unsigned
> > bitfields.
> >
> > Fixes the
On Thursday 14 February 2008 10:00, Stephen Rothwell wrote:
> Hi Rafael,
>
> On Thu, 14 Feb 2008 15:45:55 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
> >
> > Perhaps you can add:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 test
>
> I would prefer that
rcu_batches_completed and rcu_patches_completed_bh are both declared
in rcuclassic.h and rcupreempt.h. This patch removes the extra
prototypes for them from rcupdate.h.
rcu_batches_completed_bh is defined as a static inline in the rcupreempt.h
header file. Trying to export this as
On Thu, 2008-02-14 at 17:12 +0100, Ingo Molnar wrote:
> this is indeed a bug (we change the attributes for a larger area than
> needed), but your fix is unclean. Find below a cleaner solution.
>
> Ying, if you agree with this fix could you please test and ACK it before
> we push it to Linus?
Sorry, try the attached file. I tried to send via IMAP draft, but I
suppose it is still not configured right.
Thanks,
-Andrew
On Thu, Feb 14, 2008 at 4:50 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
> On Sun, 10 Feb 2008 22:11:15 -0500
> "Andrew Paprocki" <[EMAIL PROTECTED]> wrote:
>
> > This
On Thu, Feb 14, 2008 at 6:14 PM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 14, 2008 at 3:48 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * Yinghai Lu <[EMAIL PROTECTED]> wrote:
> >
> > > after disable cpufreq, i got
> > >
> > > ACPI: Preparing to enter system sleep state
On Feb 14, 2008, at 12:14 PM, Dan Williams wrote:
On Wed, Feb 13, 2008 at 8:52 PM, Kumar Gala
<[EMAIL PROTECTED]> wrote:
Dan,
What's going on with the dma engine drivers for 2.6.25? We had a
Freescale dma driver from Zhang Wei queued up but seems to have been
lost.
I pulled it into my
Avi Kivity wrote:
> Ingo Molnar wrote:
>> * Balbir Singh <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Ingo, could you also please consider the KVM build fix at
>>> http://marc.info/?l=linux-kernel=120262794315024=2 which has been
>>> acked by Avi. I suspect this patch should be route through git-x86
>>>
Hi,
I am trying to optimize a driver for a slave only PCI device and am
having a lot of trouble getting any kind of PCI burst transactions in
either the read or the write direction. Using bcopy/memcpy or even a
hand-crafted while (len) { *pdst++ = *psrc++} (with pdst and psrc
unsigned long*) I
On Wed, Feb 13, 2008 at 3:58 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
> On Mon, 11 Feb 2008 17:57:54 +0200 Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
>
> > On Tuesday 06 November 2007, Alon Bar-Lev wrote:
> > > On 11/6/07, Dave Young <[EMAIL PROTECTED]> wrote:
> > > > Hi,
> > > > sorry for
On 15-02-08 00:20, David Newall wrote:
Arjan van de Ven wrote:
Bill Davidsen wrote:
Note that because the hardware is old, it's highly likely that most
of it will be retired before that sk98lin driver needs a change. I
can't see anyone using sk98lin on a new system, so it would be less
Andrew Morton wrote:
>> So, I guess it's NACK w/o suggested alternatives, right?
>
> I wouldn't nack without good reasons, and I have none here. I don't have
> very strong opinions either way.
I was just wondering whether I should just go with snprintf dancing in
eh_link_report, which does make
On Thu, 14 Feb 2008 21:53:48 -0500 Chris Snook wrote:
> Tony Breeds wrote:
> > On Thu, Feb 14, 2008 at 08:24:27PM -0500, Chris Snook wrote:
> >> Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Initial status can be seen here
> >>> http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a
On 13-02-08 23:22, Harvey Harrison wrote:
+---
+
+What: io_delay_type
+Where: arch/x86/kernel/io_delay.c
+When: 2.6.28
+Why: No in tree users
The entirety of io_delay.c should be gone long before .28. It's a short term
thing till the port 0x80 problems have been
Li Zefan wrote:
- snip -
>> +error1:
>> +kobject_put(capability_kobj);
>> +error0:
>> +printk(KERN_ERR "Unable to export capabilities\n");
>> +
>> +return 0;
>
> Should return -EFXXX ..
Oops,
I fixed it as follows. Thanks for your pointed out.
This patch enables to export
On Thu, 2008-02-14 at 19:38 +0100, Ingo Molnar wrote:
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > this is indeed a bug (we change the attributes for a larger area
> > > than needed), but your fix is unclean. Find below a cleaner
> > > solution.
> >
> > You're still ignoring the other
Tony Breeds wrote:
On Thu, Feb 14, 2008 at 08:24:27PM -0500, Chris Snook wrote:
Stephen Rothwell wrote:
Hi all,
Initial status can be seen here
http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better
URL soon). Suggestions for more compiler/config combinations are
welcome, but
On Fri, 15 Feb 2008 11:36:12 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> >>> printk is a special case, I think. It's the primary logging/debugging
> >>> method which can't fail and as it's mostly interpreted by human beings
> >>> (and developers in problematic cases), it
On Thu, 14 Feb 2008, Caitlin Bestler wrote:
> So any solution that requires the upper layers to suspend operations
> for a brief bit will require explicit interaction with those layers.
> No RDMA layer can perform the sleight of hand tricks that you seem
> to want it to perform.
Looks like it
Andrew Morton wrote:
>>> printk is a special case, I think. It's the primary logging/debugging
>>> method which can't fail and as it's mostly interpreted by human beings
>>> (and developers in problematic cases), it has different maneuvering room
>>> on errors - ie. it's far better to print
Hi, Ingo,
Please revert this patch. Because it does not work with 1GB pages.
Although the original implementation does not work with 1GB pages too,
it can be fixed easier than this one. I will compose a new patch to fix
the original implementation.
Best Regards,
Huang Ying
On Wed, 2008-02-13 at
On Fri, 15 Feb 2008 10:49:31 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote:
> > printk is a special case, I think. It's the primary logging/debugging
> > method which can't fail and as it's mostly interpreted by human beings
> > (and developers in problematic cases), it has different maneuvering
It's possible that the values used in and returned from jiffies_to_usecs() are
incorrect because of truncation when variables of type u64 are involved. So a
function specific to that type is used instead.
Diff'd against: linux/kernel/git/torvalds/linux-2.6.git
Signed-off-by: Jonathan Lim
Set ret to -ENOMEM when kobject_create_and_add() returns NULL.
Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
---
drivers/infiniband/core/sysfs.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/core/sysfs.c b/drivers/infiniband/core/sysfs.c
index
On Thu, 2008-02-14 at 13:06 +0100, Andi Kleen wrote:
> > For EFI runtime service in virtual mode, using direct mapping is mainly
> > for kexec, where EFI runtime memory area need to be mapped at same
> > virtual address across kexec.
>
> I see. I didn't consider this aspect.
>
> > - Use direct
> We *ought* to be safe after cpu_init() ... which is called from setup_arch(),
> which is several calls before sched_init().
Perhaps what is happening is that cpu0 comes online ... safely skips
over the early printk calls. Calls cpu_init() which sets up the resources
*it* needs (ar.k3 points to
On Thu, Feb 14, 2008 at 3:48 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
> > after disable cpufreq, i got
> >
> > ACPI: Preparing to enter system sleep state S5
> > Disabling non-boot CPUs ...
> > kvm: disabling virtualization on CPU1
> > CPU 1
Hi David,
On Fri, 15 Feb 2008 12:10:42 +1100 David Chinner <[EMAIL PROTECTED]> wrote:
>
> > I notice that the
> > MAINTAINERS file has a different contact for XFS.
>
> Yup - [EMAIL PROTECTED] If you want a real person
> on the end of problem reports feel free to leave me there,
> but you should
On Thu, Feb 14, 2008 at 08:24:27PM -0500, Chris Snook wrote:
> Stephen Rothwell wrote:
> >Hi all,
> >
> >Initial status can be seen here
> >http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better
> >URL soon). Suggestions for more compiler/config combinations are
> >welcome, but we
On (14/02/08 12:41), Mike Travis didst pronounce:
> Mel Gorman wrote:
> > On (13/02/08 10:45), Mike Travis didst pronounce:
> >> Mel Gorman wrote:
> >>> On (03/02/08 17:16), Andrew Morton didst pronounce:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24/2.6.24-mm1/
>
Kohei KaiGai wrote:
<...snip...>
> +static int __init capability_export_names(void)
> +{
> + /* make /sys/kernel/capability */
> + capability_kobj = kobject_create_and_add("capability", kernel_kobj);
> + if (!capability_kobj)
> + goto error0;
> +
> + /* make
Comparing with kernel 2.6.24, tbench result has regression with
2.6.25-rc1.
1) On 2 quad-core processor stoakley: 4%.
2) On 4 quad-core processor tigerton: more than 30%.
bisect located below patch.
b4ce92775c2e7ff9cf79cca4e0a19c8c5fd6287b is first bad commit
commit
Tejun Heo wrote:
> Hello,
>
> Andrew Morton wrote:
>> On Thu, 14 Feb 2008 09:40:51 +0900
>> Tejun Heo <[EMAIL PROTECTED]> wrote:
>>
>>> Can you please take a look at ata_eh_link_report() in
>>> drivers/ata/libata-eh.c?
>> I did. Punishment?
>
> Heh.. :-)
>
>>> Currently, it has some problems.
On Thu, 14 Feb 2008, David Rientjes wrote:
> We'll need to decide whether mpol_equal() is determining the equality of
> the currently effected mempolicy (whereas policy->user_nodemask is
> irrelevant) or the whole intended mempolicy overall.
>
I've done the latter in the latest patchset.
David Miller wrote:
From: Jozsef Kadlecsik <[EMAIL PROTECTED]>
Date: Thu, 14 Feb 2008 16:02:29 +0100 (CET)
Hi,
On Sun, 10 Feb 2008, Jeff Chua wrote:
Please note the lastest git commit is missing one part (which was in Jozsef's
original patch).
Sorry everyone, that's my fault: the patch I
This patch enables to export code/name of capabilities supported
on the running kernel.
A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN
at 2.6.25. However, we have no interface to disclose what capabilities
are supported on this kernel. Thus, we have to maintain libcap version
Not all architectures implement futex_atomic_cmpxchg_inatomic(). The
default implementation returns -ENOSYS, which is currently not handled
inside of the futex guts.
Futex PI calls and robust list exits with a held futex result in an
endless loop in the futex code on architectures which have no
> -Original Message-
> From: Christoph Lameter [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 14, 2008 2:49 PM
> To: Caitlin Bestler
> Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [ofa-general] Re:
Stephen Rothwell wrote:
Hi all,
Initial status can be seen here
http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better
URL soon). Suggestions for more compiler/config combinations are
welcome, but we can't necessarily commit to fulfilling all you
wishes. :-)
i386
Hi,
Just trying out 2.6.24.2 and in unloading some modules which I don't need
managed to generate kernel oopsii. My apologies if these had been reported,
I did a search and didn't see any other reports.
rmmod fan gives:
Feb 14 19:02:22 nike kernel: [ 150.012343] WARNING: at
When the futex init code fails to initialize the futex pseudo file
system it returns early without initializing the hash queues. Should
the boot succeed then a futex syscall which tries to enqueue a waiter
on the hashqueue will crash due to the unitilialized plist heads.
Initialize the hash
14 Şub 2008 Per tarihinde, Geert Uytterhoeven şunları yazmıştı:
> To me these constructs look like good candidates for replacement by
> printk_ratelimit()?
>
> Gr{oetje,eeting}s,
What about something like following?
Use printk_ratelimit() instead of jiffies based arithmetic, suggested by
On Thu, 14 Feb 2008, Andrew Morton wrote:
> > This patch is intended for easy backporting and needs to be cleaned up
> > further for current mainline.
>
> So...
>
> I queued up this version with a cc to stable under the assumption that this
> is the patch which should be applied to 2.6.x.y, but
Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
> schrieb Jan Engelhardt <[EMAIL PROTECTED]>:
>> There is a much more interesting 'problem' with a "/dev/null
>> directory".
>>
>> Q: Why would you need such a directory?
>> A: To temporarily fool a program into believing it wrote something.
>>
>> Q:
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Feb 2008 14:51:19 -0800
> Hiroshi Shimamoto <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I posted 2 patches to fix kernel panic and memory leak.
> > http://lkml.org/lkml/2008/2/14/282
> > http://lkml.org/lkml/2008/2/14/283
> >
> >
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Feb 2008, Stephen Rothwell wrote:
> >
> > Originally, I assumed the stable branch would be for our "usual" API
> > changes, but it appears we are not having any more of those. :-)
>
> It's not that we should _never_ have them, it's that
On Fri, Feb 15, 2008 at 11:50:40AM +1100, Stephen Rothwell wrote:
> Hi David,
>
> On Fri, 15 Feb 2008 10:17:02 +1100 David Chinner <[EMAIL PROTECTED]> wrote:
> >
> > The current XFS tree that goes into -mm is:
> >
> > git://oss.sgi.com:8090/xfs/xfs-2.6.git master
>
> Added, thanks.
>
> I have
On Fri, Feb 15, 2008 at 11:42:53AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Initial status can be seen here
> http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better
> URL soon). Suggestions for more compiler/config combinations are
> welcome, but we can't necessarily commit
Hi Roland,
On Thu, 14 Feb 2008 15:22:46 -0800 Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> For InfiniBand/RDMA, the tree is:
>
> master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-next
>
> or via git protocol:
>
>
On Thu, 14 Feb 2008 17:21:52 -0600 Olof Johansson <[EMAIL PROTECTED]> wrote:
>
> On Thu, Feb 14, 2008 at 02:58:22PM -0600, Becky Bruce wrote:
>
> > Thanks for picking up the patches from Kumar and myself and fitting
> > them into your series - this is much appreciated. FYI, I applied the
> >
The pattern for making a config option on purpose not available is a
dependency on BROKEN.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
79b6f4490cadd62b3601f653df8a27ec2295adf0 diff --git a/lib/Kconfig.debug
b/lib/Kconfig.debug
index a370fe8..9fad6da 100644
--- a/lib/Kconfig.debug
+++
Hi all,
Initial status can be seen here
http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better
URL soon). Suggestions for more compiler/config combinations are
welcome, but we can't necessarily commit to fulfilling all you
wishes. :-)
--
Cheers,
Stephen Rothwell
Hi David,
On Fri, 15 Feb 2008 10:17:02 +1100 David Chinner <[EMAIL PROTECTED]> wrote:
>
> The current XFS tree that goes into -mm is:
>
> git://oss.sgi.com:8090/xfs/xfs-2.6.git master
Added, thanks.
I have put you as the contact point - is this correct? I notice that the
MAINTAINERS file has
On Thu, 14 Feb 2008 14:51:19 -0800
Hiroshi Shimamoto <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I posted 2 patches to fix kernel panic and memory leak.
> http://lkml.org/lkml/2008/2/14/282
> http://lkml.org/lkml/2008/2/14/283
>
> But, I think this patch is better than old ones.
>
> ---
> From:
This patch finally removes the global list of PCI devices. We are
relying entirely on the list held in the driver core now, and do not
need a separate "shadow" list as no one uses it.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/pci/bus.c|4
drivers/pci/probe.c
This function was obviously never being used since early 2.5 days as any
device that it would try to remove would never really be removed from
the system due to the PCI device list being held in the driver core, not
the general list of PCI devices.
As we have not had a single report of a problem
1 - 100 of 1108 matches
Mail list logo
