From: Rob Landley <[EMAIL PROTECTED]>
Add recommended section ID tags to deviceiobook.tmpl
Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
---
Because otherwise the link #anchors in the html vary from build to build.
Documentation/DocBook/deviceiobook.tmpl | 10 +-
1 file changed, 5 i
On Tuesday 09 October 2007 12:12, Mark Fasheh wrote:
> On Mon, Oct 08, 2007 at 05:47:52PM +1000, Nick Piggin wrote:
> > > block_page_mkwrite() is just using generic interfaces to do this,
> > > same as pretty much any write() system call. The idea was to make it
> > > as similar to the write() call
Eric W. Biederman wrote:
> Takenori Nagano <[EMAIL PROTECTED]> writes:
>
>> Hi,
>>
>> These patches add new notifier function and implement it to
>> panic_notifier_list.
>> We used the hardcoded notifier chain so far, but it was not flexible. New
>> notifier is very flexible, because user can cha
On Thursday 04 October 2007 01:21, Linus Torvalds wrote:
> On Wed, 3 Oct 2007, Nick Piggin wrote:
> > I don't know if Linus actually disliked the patch itself, or disliked
> > my (maybe confusingly worded) rationale?
>
> Yes. I'd happily accept the patch, but I'd want it clarified and made
> obviou
On Tuesday 09 October 2007 16:40, Huang, Ying wrote:
> +unsigned long copy_from_phys(void *to, unsigned long from_phys,
> + unsigned long n)
> +{
> + struct page *page;
> + void *from;
> + unsigned long remain = n, offset, trunck;
> +
> + while (remain) {
>
John Sigler wrote:
When I run 'halt' the kernel prints:
Halting.
Shutdown: hdc
ACPI: PCI interrupt for device :01:05.0 disabled
ACPI: PCI interrupt for device :01:04.0 disabled
ACPI: PCI interrupt for device :01:03.0 disabled
ACPI: PCI interrupt for device :01:02.0 disabled
Powe
On Mon, 2007-10-08 at 23:04 -0400, Steven Rostedt wrote:
> On Mon, Oct 08, 2007 at 11:45:23AM -0700, Mike Kravetz wrote:
> > On Fri, Oct 05, 2007 at 07:15:48PM -0700, Mike Kravetz wrote:
> > > After applying the fix to try_to_wake_up() I was still seeing some large
> > > latencies for realtime task
On Tue, 2007-10-09 at 01:25 +1000, Nick Piggin wrote:
> On Tuesday 09 October 2007 16:40, Huang, Ying wrote:
>
> > +unsigned long copy_from_phys(void *to, unsigned long from_phys,
> > +unsigned long n)
> > +{
> > + struct page *page;
> > + void *from;
> > + unsigned l
On Tue, Oct 09, 2007 at 06:17:43AM +0200, Sam Ravnborg wrote:
> >
> > What about, that this is the first ever prompt, that must be shown and
> > written to the .config?
> Two issues to fix before we can do this:
> 1) chocie values cannot have more than one prompt
what occupying all my time now is
On Tuesday 09 October 2007 18:22, Huang, Ying wrote:
> On Tue, 2007-10-09 at 01:25 +1000, Nick Piggin wrote:
> > On Tuesday 09 October 2007 16:40, Huang, Ying wrote:
> > > +unsigned long copy_from_phys(void *to, unsigned long from_phys,
> > > + unsigned long n)
> > I suppose t
Playing with the latest -mm kernel I stumbled upon the following compile
error:
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
:1389:2: warning: #warning syscall revokeat not implemented
:1393:2: warning: #warning syscall frevoke not imple
On Tue, 2007-10-09 at 02:06 +1000, Nick Piggin wrote:
> On Tuesday 09 October 2007 18:22, Huang, Ying wrote:
> > On Tue, 2007-10-09 at 01:25 +1000, Nick Piggin wrote:
> > > On Tuesday 09 October 2007 16:40, Huang, Ying wrote:
> > > > +unsigned long copy_from_phys(void *to, unsigned long from_phys,
Hello,
For those of you who like your wings to rotate, we have added a new World
Helicopter Operators section. This new section currently includes more than 500
international helicopter operators, covering air taxi, emergency services,
offshore, agriculture, survey, heavy lift operations, etc.
On Tuesday 09 October 2007 18:55, Huang, Ying wrote:
> On Tue, 2007-10-09 at 02:06 +1000, Nick Piggin wrote:
> > I'm just wondering whether you really need to access highmem in
> > boot code...
>
> Because the zero page (boot_parameters) of i386 boot protocol has 4k
> limitation, a linked list sty
Any reasons this didn't go into -mm? It's all straight-forward cleanup
and it would be a pity not to see it in 2.6.24
On Thu, Sep 27, 2007 at 04:12:00PM +0200, [EMAIL PROTECTED] wrote:
> This is a respin of the patch series Andreas posted last month. It leaves out
> the restructuring of the inten
> r-o-bind-mounts-filesystem-helpers-for-custom-struct-files.patch
> r-o-bind-mounts-rearrange-may_open-to-be-r-o-friendly.patch
> r-o-bind-mounts-give-permission-a-local-mnt-variable.patch
> r-o-bind-mounts-create-cleanup-helper-svc_msnfs.patch
<...>
> Doesn't seem ready yet
I guess we need s
On Tue, 2007-10-09 at 02:28 +1000, Nick Piggin wrote:
> On Tuesday 09 October 2007 18:55, Huang, Ying wrote:
> > On Tue, 2007-10-09 at 02:06 +1000, Nick Piggin wrote:
>
> > > I'm just wondering whether you really need to access highmem in
> > > boot code...
> >
> > Because the zero page (boot_para
On Fri, 05 Oct 2007 17:00:48 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> I think this definitely needs more discussion, so here we go...
I agree, so I'll give my 0.02 € here...
>
> Greg KH wrote:
> >> 1. What is a kobject?
> [--snip--]
> >> The functionality served by kobject can be broken dow
Dear all,
Would it be possible to include the patches (available on www.synce.org)
for WindowsMobile5, as most mobile phones are under Window$, and it is
very convenient to connect it to the laptop under Linux
http://www.synce.org/index.php/Connecting_your_Windows_Mobile_2005_device_via_USB_%28
On Die, 2007-10-09 at 12:20 +0300, Grosjo.net - jom wrote:
[...]
> Would it be possible to include the patches (available on www.synce.org)
> for WindowsMobile5, as most mobile phones are under Window$, and it is
> very convenient to connect it to the laptop under Linux
do {
Test them
review
Hi,
On 10/9/07, Grosjo.net - jom <[EMAIL PROTECTED]> wrote:
> Would it be possible to include the patches (available on www.synce.org)
> for WindowsMobile5, as most mobile phones are under Window$, and it is
> very convenient to connect it to the laptop under Linux
Sounds useful so please ask the
On Tue, 2007-10-09 at 11:32 +0200, Bernd Petrovitsch wrote:
> On Die, 2007-10-09 at 12:20 +0300, Grosjo.net - jom wrote:
> [...]
> > Would it be possible to include the patches (available on www.synce.org)
> > for WindowsMobile5, as most mobile phones are under Window$, and it is
> > very convenien
Sam Ravnborg <[EMAIL PROTECTED]> writes:
>
> -ARCH ?= $(SUBARCH)
> -CROSS_COMPILE?=
Can you do this in a way that there are still these ARCH/CROSS_COMPILE
lines that are just overriden when empty or have their default value?
This way defaults could be still patched in for speci
FWIW, the patch in question is a one-liner:
Yes, that is why it shall be probably possible to include it in the kernel ?
I do not have the contact with SynCE developers. Maybe one of you have.
Jom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Tue, Oct 09, 2007 at 08:03:33AM +0200, Sam Ravnborg wrote:
> On Mon, Oct 08, 2007 at 11:12:56PM +0200, Adrian Bunk wrote:
>...
> > BTW: I'm currently trying without success to understand why the
> > drivers/infiniband/{hw/amso1100,ulp/srp}/Kbuild files are not
> > named "Makefile".
> G
On Tue, Oct 09, 2007 at 11:39:21AM +0200, Andi Kleen wrote:
> Sam Ravnborg <[EMAIL PROTECTED]> writes:
> >
> > -ARCH ?= $(SUBARCH)
> > -CROSS_COMPILE ?=
>
> Can you do this in a way that there are still these ARCH/CROSS_COMPILE
> lines that are just overriden when empty or hav
Ingo has this already fixed in sched-devel (but he also adds
more parameters here). Since the fix is very simple I think it should
be fixed for .23. Especially cache_nice_tries is useful to tune
because it is very magic and the current values are a little dubious.
Fix holes in the scheduler
On Mon, 8 Oct 2007 19:30:54 -0400
"J. Bruce Fields" <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 08, 2007 at 04:43:10PM -0600, Jonathan Corbet wrote:
> > + (e) I understand and agree that this project and the contribution are
> > + public and that a record of the contribution (including my Reviewe
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> Ingo has this already fixed in sched-devel (but he also adds more
> parameters here). Since the fix is very simple I think it should be
> fixed for .23. Especially cache_nice_tries is useful to tune because
> it is very magic and the current values are
Morning,
Lately I've been having issues with one of my machines' CIFS mounts. Failure
seems rather random to me, but most often occurs after adding new torrents to
Azureus.
I see no irregular messages on my Samba server machine, and other machines can
access the server fine.
Dmesg:
CIFS VFS: se
This patch fixes the problem introduced by:
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/broken-out/x86-convert-cpuinfo_x86-array-to-a-per_cpu-array.patch
The problem is that every processor line in /proc/cpuinfo displays zero
on x86_64.
$ grep processor /p
On Tuesday 09 October 2007 12:26:32 Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > Ingo has this already fixed in sched-devel (but he also adds more
> > parameters here). Since the fix is very simple I think it should be
> > fixed for .23. Especially cache_nice_tries is us
On Tue, Oct 09, 2007 at 12:00:30PM +0200, Sam Ravnborg wrote:
> On Tue, Oct 09, 2007 at 11:39:21AM +0200, Andi Kleen wrote:
> > Sam Ravnborg <[EMAIL PROTECTED]> writes:
> > >
> > > -ARCH ?= $(SUBARCH)
> > > -CROSS_COMPILE?=
> >
> > Can you do this in a way that there are still th
> Care to add a line of documentation if you keep it in mm/memory.c?
It would be better to just use early_ioremap() (or ioremap())
That is how ACPI who has similar issues accessing its tables solves this.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
Hello again,
On Mon, 2007-10-08 at 21:45 +0200, Vegard Nossum wrote:
> These functions make it quite easy to make snprintf() automatically
> escape certain characters in string arguments, for example. I think they
> are also well suited to printing to variable-sized buffers, though the
> last tim
On Tue, 2007-10-09 at 02:30 +0100, Al Viro wrote:
> On Mon, Oct 08, 2007 at 06:15:51PM -0700, Tim Pepper wrote:
> >
> > When a read() requests an amount of data smaller than the amount of data
> > that the seq_file's foo_show() outputs, the output starts looping and
> > outputs the "stuck" element
From: Christian Borntraeger <[EMAIL PROTECTED]>
We have seen ramdisk based install systems, where some pages of mapped
libraries and programs were suddendly zeroed under memory pressure. This
should not happen, as the ramdisk avoids freeing its pages by keeping them
dirty all the time.
It turn
On Sat, Oct 06 2007, Arnd Bergmann wrote:
> This is my block ioctl series split up into managable chunks. I'm not
> really sure about the last two of these, I'd prefer to get a second
> opinion on those.
>
> Please apply once your tests have gone though.
Goodness, thanks a lot Arnd! Applied 1-7 (
On Tue, 2007-10-09 at 11:37 +0200, Xavier Bestel wrote:
> FWIW, the patch in question is a one-liner:
That's not a valid argument. This may work with a WM5 device, but looks
very dubious, wrt. other RNDIS devices. Why are these constants
hardcoded and not taken in some way from the descriptors?
On Mon, 8 Oct 2007 14:01:32 +0100
Denys Vlasenko <[EMAIL PROTECTED]> wrote:
> On Sunday 07 October 2007 17:47, Malte Schröder wrote:
> > Hello,
> > I am encountering some strange data corruption when transferring
> > data from one of my PCs that I use as a file-server.
> >
> > on the server:
> >
* Tue, 09 Oct 2007 16:55:23 +0800
>
> On Tue, 2007-10-09 at 02:06 +1000, Nick Piggin wrote:
>> On Tuesday 09 October 2007 18:22, Huang, Ying wrote:
[]
>> I'm just wondering whether you really need to access highmem in
>> boot code...
>
> Because the zero page (boot_parameters) of i386 boot protocol
On Tuesday 09 October 2007 12:25, Malte Schröder wrote:
> > Does it happen over loopback?
>
> I just tried a few times and yes, it also happens on loopback, but
> much less frequently. Now I am really confused ...
Actually, that eliminates a lot of cases.
Run memtest86 overnight ("bad hardware"
Hi Darrick:
* Darrick J. Wong <[EMAIL PROTECTED]> [2007-09-14 12:33:46 -0700]:
> Here's a fourth revision where I've tried to clean up the things that
> people complained about, as well as shifted the sysfs file names to
> match the spec that we've been drifting towards.
Sorry it took me so long
> I have now found what I think is another valid use. What I have done is
> to make xprintf() emit the output directly to the kernel ring-buffer.
Thats nice.
> There is only one very small caveat (that I can see) to be mentioned:
> You can still use multiple printk() calls to append new text to a
On Tue, Oct 09, 2007 at 01:55:42AM +0400, Dmitri Vorobiev wrote:
> Hi,
>
> The patch below contains a small code clean-up for the NTFS driver: all
> static char pointers to error message strings have been replaced by
> static char arrays.
>
Hi Dmitri,
Isn't the only difference between char *c
MCG_CAP never reports a negative count of available error-reporting banks.
Therefore, make it unsigned.
Check for MCA/MCE feature bits as early as possible.
Signed-off-by: Christoph Egger <[EMAIL PROTECTED]>
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/mcheck/mce.c |
Remove one indent level
Signed-off-by: Christoph Egger <[EMAIL PROTECTED]>
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/mcheck/mce.c | 40 ++--
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/i386/kernel/cpu/mchec
This patchset includes two patches.
1. Checks for the MCA fetures as early as possible.
2. Coding style cleanup.
-
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-inf
Hi Rob,
On Tue, Oct 09, 2007 at 01:25:18AM -0500, Rob Landley wrote:
[...]
> FILE * infile;
> +
> + srctree = getenv("SRCTREE");
> + if (!srctree) srctree = getcwd(NULL,0);
> if (argc != 3) {
> usage();
> exit(1);
$ man getcwd
char *getcwd(char *b
Soeren Sonnenburg wrote:
Fixing recursive fault but reboot is needed!
Hmmhh, so now I rebooted and again tried to
$ make
the new kernel which again triggered this(?) BUG:
I had a similar issue with 2.6.22.9, but as I had a proprietary nvidia
module loaded, I didn't report it. X was not en
Quoting Pierre Peiffer ([EMAIL PROTECTED]):
> From: Pierre Peiffer <[EMAIL PROTECTED]>
>
> Some comments about sem_undo_list seem wrong.
> About the comment above unlock_semundo:
> "... If task2 now exits before task1 releases the lock (by calling
> unlock_semundo()), then task1 will never call sp
The biggest actual changes are the support for tickless kernels on MIPS
and the rewrite for many of the timer devices previously used as
clocksources and clockevents. Various cleanups, including some moving
of code and support for 32-bit Broadcom BCM47XX processors, the return
of support for LASAT
On Tue, Oct 09, 2007 at 07:43:21PM +0900, Akinobu Mita wrote:
> This patch fixes the problem introduced by:
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/broken-out/x86-convert-cpuinfo_x86-array-to-a-per_cpu-array.patch
>
Link is dead, same patch in lkml.o
On Mon, 8 Oct 2007, Steve Wise wrote:
> The correct solution, IMO, is to enhance the core low level 4-tuple
> allocation services to be more generic (eg: not be tied to a struct
> sock). Then the host tcp stack and the host rdma stack can allocate
> TCP/iWARP ports/4tuples from this common ex
Hi list,
i'm developing an application (in C) which needs to write about
1Gbit/s (125Mb/s) to a disk array attached via U320 SCSI.
It runs on Dual Core 2 Xeons @2Ghz utilizing kernel 2.6.22.7.
I buffer the data in (currently 4) 400Mb buffers and use write(2) in a
dedicated thread to write them
On Tue, Oct 09, 2007 at 12:00:30PM +0200, Sam Ravnborg wrote:
> If it is OK to drop the $(SUBARCH) assingment like this then yes.
> ARCH ?=
> CROSS_COMPILE ?=
Does the UML build still work when you do that?
Jeff
--
Work email - jdike at linux dot intel d
On Tue, 2007-10-09 at 15:09 +0200, Tomasz Chmielewski wrote:
> Soeren Sonnenburg wrote:
>
> >> Fixing recursive fault but reboot is needed!
> >
> > Hmmhh, so now I rebooted and again tried to
> >
> > $ make
> >
> > the new kernel which again triggered this(?) BUG:
>
> I had a similar issue wi
El Tue, 09 Oct 2007 15:50:17 +0200
Michael Stiller <[EMAIL PROTECTED]> escribió:
> Hi list,
>
> i'm developing an application (in C) which needs to write about
> 1Gbit/s (125Mb/s) to a disk array attached via U320 SCSI.
> It runs on Dual Core 2 Xeons @2Ghz utilizing kernel 2.6.22.7.
>
> I buf
Roland Dreier wrote:
> No mention about the iwarp port space issue?
I don't think we're at a stage where I'm prepared to merge something--
we all agree the latest patch has serious drawbacks, and it commits us
to a suboptimal interface that is userspace-visible.
Fair enough.
> I'm at a
On 10/9/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > Care to add a line of documentation if you keep it in mm/memory.c?
>
> It would be better to just use early_ioremap() (or ioremap())
>
> That is how ACPI who has similar issues accessing its tables solves this.
Yes. That is another solution.
On Mon, 2007-10-08 at 10:31 -0700, Casey Schaufler wrote:
> --- "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
>
> > Quoting Casey Schaufler ([EMAIL PROTECTED]):
> > > ...
> > > Good suggestion. In fact, that is exactly how I approached my
> > > first two attempts at the problem. What you get if you
Steps to reproduce:
Server:
[EMAIL PROTECTED] ~]# cat /etc/exports
/export *(ro,insecure)
// there is insecure ... I am using ports like "1024 to 61000"
[EMAIL PROTECTED] ~] service nfs restart
Client:
[EMAIL PROTECTED] ~]# echo 32768 32768 >
/proc/sys/net/ipv4/ip_local_port_range
3276
On Tuesday 09 October 2007 16:00:57 huang ying wrote:
> On 10/9/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > > Care to add a line of documentation if you keep it in mm/memory.c?
> >
> > It would be better to just use early_ioremap() (or ioremap())
> >
> > That is how ACPI who has similar issue
Hi All,
The first two patches are from Mike and Steven on LKML, which the rest of my
series is dependent on. Patch #4 is a resend from earlier.
Series Summary:
1) Send IPI on overload regardless of whether prev is an RT task
2) Set the NEEDS_RESCHED flag on reception of RESCHED_IPI
3) Fix a mis
From: Mike Kravetz <[EMAIL PROTECTED]>
RESCHED_IPIs can be missed if more than one RT task is awoken simultaneously
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
kernel/sched.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Mike Kravetz <[EMAIL PROTECTED]>
x86_64 based RESCHED_IPIs fail to set the reschedule flag
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/smp.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
dif
Any number of tasks could be queued behind the current task, so direct the
balance IPI at all CPUs (other than current)
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
CC: Steven Rostedt <[EMAIL PROTECTED]>
CC: Mike Kravetz <[EMAIL PROTECTED]>
CC: Peter W. Morreale <[EMAIL PROTECTED]>
---
ker
The code currently blindly fires IPIs out whenever an overload occurs.
However, there are strict events that govern when a rt-overload exists
(e.g. RT task added to a RQ, or an RT task preempted). Therefore, we
attempt to efficiently track which CPUs are eligible for rebalancing, and we
only IPI t
The system currently evaluates all online CPUs whenever one or more enters
an rt_overload condition. This suffers from scalability limitations as
the # of online CPUs increases. So we introduce a cpumask to track
exactly which CPUs need RT balancing.
Signed-off-by: Gregory Haskins <[EMAIL PROTEC
On Tue, 9 Oct 2007, Tomasz Chmielewski wrote:
>
> I had a similar issue with 2.6.22.9, but as I had a proprietary nvidia module
> loaded, I didn't report it. X was not enabled, though.
There is indeed a strong likelihood that yours is
related to that nvidia(P): please take it to them.
Hugh
> Oc
On Tue, 9 Oct 2007, Nick Piggin wrote:
>
> I have done some tests which indicate a couple of very basic common tools
> don't do much zero-page activity (ie. kbuild). And also combined with some
> logical arguments to say that a "sane" app wouldn't be using zero_page much.
> (basically -- if the
Michael Stiller <[EMAIL PROTECTED]> writes:
>
> The write(2) performance is not good enough, the writer threads take to
> much time, and i ask you for ideas, howto to boost the write
> performance.
You could use an O_DIRECT write if the data is suitably aligned
and your IO sizes are big enough (
On Mon, 2007-10-08 at 22:01 +0200, Roel Kluin wrote:
> Greg KH wrote:
>
> @@ -477,10 +479,15 @@ nlmsvc_testlock(struct svc_rqst *rqstp,
>
> if (block == NULL) {
> struct file_lock *conf = kzalloc(sizeof(*conf), GFP_KERNEL);
> + struct nlm_host *host;
>
>
On Thu, Oct 04, 2007 at 10:54:51AM +0200, Heiko Carstens wrote:
> > i'm wondering about the following: could not (yet) existing UIDs be made
> > configurable too? I.e. if i do this in a bootup script:
> >
> > echo 2048 > /sys/kernel/uids/500/cpu_share
> >
> > this should just work too, regardl
On Tue, 2007-10-09 at 10:25 -0400, Gregory Haskins wrote:
> Hi All,
>
> The first two patches are from Mike and Steven on LKML, which the rest of my
> series is dependent on. Patch #4 is a resend from earlier.
>
> Series Summary:
>
> 1) Send IPI on overload regardless of whether prev is an RT t
--
On Tue, 9 Oct 2007, Gregory Haskins wrote:
> Hi All,
Hi Gregory,
>
> The first two patches are from Mike and Steven on LKML, which the rest of my
> series is dependent on. Patch #4 is a resend from earlier.
>
> Series Summary:
>
> 1) Send IPI on overload regardless of whether prev is an RT
The recent fix for a circular lock dependency unfortunately introduced a
potential memory leak in the event where the call to nlmsvc_lookup_host
fails for some reason.
Thanks to Roel Kluin for spotting this.
Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
---
fs/lockd/svclock.c |4 +++-
On Mon, Oct 08, 2007 at 11:06:33AM -0700, Greg KH wrote:
> From: Mark Lord <[EMAIL PROTECTED]>
>
> commit 4047727e5ae33f9b8d2b7766d1994ea6e5ec2991 from upstream
>
> We need to disable all CPUs other than the boot CPU (usually 0) before
> attempting to power-off modern SMP machines. This fixes th
On Tue, Oct 09, 2007 at 11:00:28AM -0400, Trond Myklebust wrote:
>
> On Mon, 2007-10-08 at 22:01 +0200, Roel Kluin wrote:
> > Greg KH wrote:
> >
> > @@ -477,10 +479,15 @@ nlmsvc_testlock(struct svc_rqst *rqstp,
> >
> > if (block == NULL) {
> > struct file_lock *conf = kzalloc(s
> Roland, I submitted an updated patch incorporating some of Sean's comments
> within
> a day or two. Rest of comments pertained to restructuring the code and
> adding
> some additional module parameters.
>
> This would require more discussions since some of these had been already
> di
On Tue, 2007-10-09 at 08:13 -0700, Greg KH wrote:
> On Tue, Oct 09, 2007 at 11:00:28AM -0400, Trond Myklebust wrote:
> >
> > On Mon, 2007-10-08 at 22:01 +0200, Roel Kluin wrote:
> > > Greg KH wrote:
> > >
> > > @@ -477,10 +479,15 @@ nlmsvc_testlock(struct svc_rqst *rqstp,
> > >
> > > if (bl
On Mon, Oct 08, 2007 at 10:40:44PM +0400, Alexey Dobriyan wrote:
> On Mon, Oct 08, 2007 at 10:05:40AM -0700, [EMAIL PROTECTED] wrote:
> > --- a/mm/fremap.c~fix-vm_can_nonlinear-check-in-sys_remap_file_pages
> > +++ a/mm/fremap.c
> > @@ -160,7 +160,7 @@ asmlinkage long sys_remap_file_pages(uns
> >
Why do you prefer request_firmware() vs something over sysfs ?
Does environments like the kdump kernel also have access to data needed
by request_firmware() ?
-- james s
Andrew Vasquez wrote:
On Mon, 08 Oct 2007, Darrick J. Wong wrote:
On Mon, Oct 08, 2007 at 03:48:32PM -0700, Andrew Vasque
On Tue, 2007-10-09 at 11:00 -0400, Steven Rostedt wrote:
>
Hi Steve, Peter,
> --
> On Tue, 9 Oct 2007, Gregory Haskins wrote:
> > Hi All,
>
> Hi Gregory,
>
> >
> > The first two patches are from Mike and Steven on LKML, which the rest of my
> > series is dependent on. Patch #4 is a resend fr
From: Randy Dunlap <[EMAIL PROTECTED]>
Mark the kbuild m-l as subscribers-only:
Your mail to 'kbuild-devel' with the subject
Re: [RFC/RFT] kbuild: save ARCH & CROSS_COMPILE
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member t
On Tue, 2007-10-09 at 11:33 -0400, Gregory Haskins wrote:
> On the flip side: Perhaps sending a reschedule-ipi that doesn't
> reschedule is simply misused, and the misuse should be cleaned up
> instead?
It basically does TIF_WORK_MASK and TIF_NEED_RESCHED is one of the most
frequently used of t
First, sorry for being so slow to respond. I was getting ill towards the end
of last week and am worse now. Brain is in total mush as a result. Thanks
Lee for finding this problem and thanks to Nish for investigating it properly.
Comments and candidate fix to one zonelist are below.
On (08/10/07
On Tue, Oct 09 2007 at 16:56 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Michael Stiller <[EMAIL PROTECTED]> writes:
>> The write(2) performance is not good enough, the writer threads take to
>> much time, and i ask you for ideas, howto to boost the write
>> performance.
>
> You could use an O
> Stop the EXT3 filesystem from using iget() and read_inode(). Replace
> ext3_read_inode() with ext3_iget(), and call that instead of iget().
> ext3_iget() then uses iget_locked() directly and returns a proper error code
> instead of an inode in the event of an error.
>
> ext3_fill_super() return
> Stop the EXT4 filesystem from using iget() and read_inode(). Replace
> ext4_read_inode() with ext4_iget(), and call that instead of iget().
> ext4_iget() then uses iget_locked() directly and returns a proper error code
> instead of an inode in the event of an error.
>
> ext4_fill_super() return
* Tue, 9 Oct 2007 14:49:55 +0200
[]
> @@ -33,9 +33,20 @@ void fastcall (*machine_check_vector)(struct pt_regs *,
> long error_code) = unexp
> /* This has to be run for each processor */
> void mcheck_init(struct cpuinfo_x86 *c)
> {
> + uint32_t mca, mce;
> +
> if (mce_disabled==1)
>
On Tue, 9 Oct 2007 15:03:15 +0200 Ahmed S. Darwish wrote:
> Hi Rob,
>
> On Tue, Oct 09, 2007 at 01:25:18AM -0500, Rob Landley wrote:
> [...]
> > FILE * infile;
> > +
> > + srctree = getenv("SRCTREE");
> > + if (!srctree) srctree = getcwd(NULL,0);
> > if (argc != 3) {
> > u
On Tue, 9 Oct 2007 01:25:18 -0500 Rob Landley wrote:
> From: Rob Landley <[EMAIL PROTECTED]>
>
> Prevent docproc from segfaulting when SRCTREE isn't set.
>
> Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
but needs 2 coding style fixes... see near end
On Mon, 8 Oct 2007, David Miller wrote:
> As coicidence would have it I finally found a recipe for triggering
> the issue, and it ties into what you're talking about here.
>
> It happens only if I make sure OHCI gets loaded first and then EHCI
> right afterwards.
>
> It seems that indeed it is i
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-08 at 10:31 -0700, Casey Schaufler wrote:
> > ...
> > I wouldn't expect the whole thing to be more than a couple week's
> > work for someone who really wanted to do it.
>
> Note that Serge said "SELinux re-written on top of Smack",
On Tue, Oct 09, 2007 at 06:04:48PM +0200, Oleg Verych wrote:
> * Tue, 9 Oct 2007 14:49:55 +0200
>
> []
> > @@ -33,9 +33,20 @@ void fastcall (*machine_check_vector)(struct pt_regs *,
> > long error_code) = unexp
> > /* This has to be run for each processor */
> > void mcheck_init(struct cpuinfo
On Tue, Oct 09, 2007 at 06:06:05PM +0200, Joerg Roedel wrote:
> > cpu_has() returns int,
> > but would it be better to have something like
> >
> > if (!mce_disabled &&
> > !(c->x86_capability & (X86_FEATURE_MCA | X86_FEATURE_MCE)) {
> > printk(KERN_INFO "CPU%i: No machine c
This patch fixes the problem introduced by:
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/broken-out/slub-place-kmem_cache_cpu-structures-in-a-numa-aware-way.patch
I got slub BUG report when I tried to do cpu hotplug/unplug
$ while true; do
echo 0 > /
On Mon, Oct 08, 2007 at 07:31:49PM -0400, Jun'ichi Nomura wrote:
> This patch fixes a bd_mount_sem counter corruption bug in device-mapper.
[summary of follow-up]
Affects 2.6.16 (and 2.6.15.5) upwards if someone removes a suspended device
(which shouldn't happen during normal lvm2 operation).
Al
On 09.10.2007 [16:40:53 +0100], Mel Gorman wrote:
> First, sorry for being so slow to respond. I was getting ill towards the end
> of last week and am worse now. Brain is in total mush as a result. Thanks
> Lee for finding this problem and thanks to Nish for investigating it properly.
>
> Comments
1 - 100 of 301 matches
Mail list logo
