On 10/15/07, Alistair John Strachan [EMAIL PROTECTED] wrote:
On Sunday 14 October 2007 23:06:22 Stefan Heinrichsen wrote:
Hello,
I posted this question at comp.linux.misc and where told this would be a
better place therefore. I would like to do a internship in the field of the
Linux
Am 14.10.2007 19:46 schrieb Stefan Richter:
David Newall wrote:
That is so rude.
Such responses sometimes happen after provocative posts like the thread
starter's.
Provocation is often in the eye of the beholder, and basic manners
should be observed nevertheless.
He could have asked
On Sun, Oct 14, 2007 at 11:45:36PM +0300, Vitaliy Ivanov wrote:
Also, while I understand you would be very glad to get your work merged
(we all once had our first piece of code), I'd like to mention that you
seem to be the only user of this hardware under 2.4 (since it is currently
not
On Mon, Oct 15, 2007 at 12:06:22AM +0200, Stefan Heinrichsen wrote:
Hello,
I posted this question at comp.linux.misc and where told this would be a
better place therefore.
I would like to do a internship in the field of the Linux kernel.
Can someone tell me where to find a list of
On Mon, 15 Oct 2007, Stefan Heinrichsen wrote:
I posted this question at comp.linux.misc and where told this would be a
better place therefore. I would like to do a internship in the field of
the Linux kernel. Can someone tell me where to find a list of companies
(don't matter in which
On Fri, Oct 12, 2007 at 09:58:43AM -0700, Jeremy Fitzhardinge wrote:
Hi Dave other XFS folk,
I'm tracking down a bug which appears to be a bad interaction between XFS
and Xen. It looks like XFS is holding RW mappings on free pages, which Xen
is trying to get an exclusive RO mapping on so
David Chinner wrote:
You mean xfs_buf.c.
Yes, sorry.
And yes, we delay unmapping pages until we have a batch of them
to unmap. vmap and vunmap do not scale, so this is batching helps
alleviate some of the worst of the problems.
How much performance does it cost? What kind of
Hi linux-kernel,
[1.] One line summary of the problem:
kernel memory subsystem incorrectly invokes OOM killer under certain situations
[2.] Full description of the problem/report:
My guess is that whatever invokes the OOM killer is incorrectly
deciding that memory allocated for disk cache
Hi Casey,
On Sun, Oct 14, 2007 at 10:15:42AM -0700, Casey Schaufler wrote:
+
+CIPSO Configuration
+
+It is normally unnecessary to specify the CIPSO configuration. The default
+values used by the system handle all internal cases. Smack will compose CIPSO
+label values to match the Smack
On 10/14/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Sun, 2007-10-14 at 09:15 +0200, Manfred Spraul wrote:
Yinghai Lu wrote:
On 10/13/07, Manfred Spraul [EMAIL PROTECTED] wrote:
Someone around with a MSI capable board? The forcedeth driver does
dev-irq = pci_dev-irq
Add uio document to DocBook compilation target.
`make *docs' doesn't generate The Userspace I/O HOWTO, the user space
I/O document written in DocBook.
Signed-off-by: Satoru Takeuchi [EMAIL PROTECTED]
Index: linux/Documentation/DocBook/Makefile
Hi Arnd,
The code looks correct, but I think it would be nicer to change
hrtimer_nanosleep to take a kernel pointer and have all three
callers (common_nsleep, sys_nanosleep and compat_sys_nanosleep)
do the copy_to_user/put_compat_timespec in the caller.
Good idea, I had considered that
On Monday 15 October 2007 09:12, Jeremy Fitzhardinge wrote:
David Chinner wrote:
You mean xfs_buf.c.
Yes, sorry.
And yes, we delay unmapping pages until we have a batch of them
to unmap. vmap and vunmap do not scale, so this is batching helps
alleviate some of the worst of the
The kernel newbies community often gets inquiries from CS students who
need a project for their studies and would like to do something with
the Linux kernel, but would also like their code to be useful to the
community afterwards.
In order to make it easier for them, I am trying to put together a
On Sun, Oct 14, 2007 at 04:12:20PM -0700, Jeremy Fitzhardinge wrote:
David Chinner wrote:
You mean xfs_buf.c.
Yes, sorry.
And yes, we delay unmapping pages until we have a batch of them
to unmap. vmap and vunmap do not scale, so this is batching helps
alleviate some of the worst
On Sun, 2007-10-14 at 16:15 -0700, Yinghai Lu wrote:
On 10/14/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Sun, 2007-10-14 at 09:15 +0200, Manfred Spraul wrote:
Yinghai Lu wrote:
On 10/13/07, Manfred Spraul [EMAIL PROTECTED] wrote:
Someone around with a MSI capable
On Sunday 14 October 2007 12:46:12 pm Stefan Richter wrote:
David Newall wrote:
That is so rude.
When a reply contains as a reply to the first paragraph you're wrong with no
elaboration, and as a reply to the second paragraph nothing but expletives
and personal insults, I tend to stop
1. How are you forcing the drives into standby?
2. Have you reproduced this with a stock kernel.org kernel yet?
One possibility is that these drives may be the kind that
generate a spurious interrupt when they spin-down via the timer,
and perhaps libata is processing that interrupt and sending
On Sunday 14 October 2007 5:24:32 pm James Bottomley wrote:
On Sat, 2007-10-13 at 16:05 -0600, Matthew Wilcox wrote:
On Thu, Oct 11, 2007 at 08:11:21PM -0500, Rob Landley wrote:
My impression from asking questions on the linux-scsi mailing list is
that the scsi upper/middle/lower layers
Hi,
When using a NO_HZ kernel on ppc64, I noticed top gives some interesting
results:
Cpu0 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa,
On 10/14/07, Mark Lord [EMAIL PROTECTED] wrote:
1. How are you forcing the drives into standby?
hdparm -y
2. Have you reproduced this with a stock kernel.org kernel yet?
No; maybe later this week.
One possibility is that these drives may be the kind that
generate a spurious interrupt
You can pull the following nfs server changes from
git://linux-nfs.org/~bfields/linux.git nfs-server-stable
Nothing earth-shaking this time; mainly small bugfixes and cleanups.
--b.
Andrew Morton (1):
nfsd warning fix
Christoph Hellwig (1):
nfsd: fix horrible indentation in
On Wednesday October 10, [EMAIL PROTECTED] wrote:
On Tue, Oct 09, 2007 at 10:49:20AM -0600, Jonathan Corbet wrote:
Neil Brown [EMAIL PROTECTED] wrote:
+ (b) Any problems, concerns, or questions relating to the patch have
been
+ communicated back to the submitter. I am
On Tuesday October 9, [EMAIL PROTECTED] wrote:
Hi Neil.
From:The Author, Primary Author, or Authors of the patch.
Authors should also provide a Signed-off-by: tag.
Purpose: to give credit to authors
The SCM should include this info and we
--- James Bottomley [EMAIL PROTECTED] wrote:
On Sat, 2007-10-13 at 16:05 -0600, Matthew Wilcox wrote:
On Thu, Oct 11, 2007 at 08:11:21PM -0500, Rob Landley wrote:
My impression from asking questions on the linux-scsi mailing list is
that the
scsi upper/middle/lower layers doesn't use
This
+ if (get_user(len, (int __user *)arg))
+ return -EFAULT;
+ if (copy_to_user(*((__u8 **)(user_arg +
+ sizeof(__u32))),
+
Nick Piggin wrote:
Yes, as Dave said, vmap (more specifically: vunmap) is very expensive
because it generally has to invalidate TLBs on all CPUs.
I see.
I'm looking at some more general solutions to this (already have some
batching / lazy unmapping that replaces the XFS specific one),
On 10/14/07, Németh Márton [EMAIL PROTECTED] wrote:
From: Márton Németh [EMAIL PROTECTED]
As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending \n was added.
Signed-off-by: Márton Németh
Hi Linus,
This contains a major macro removal and ioctl related usercopy cleanups,
it also fixes a bug in the intel interrupt code with a dodgy calloc size.
Please pull the 'drm-patches' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
Dave.
Hi Linus,
Please pull from 'agp-patches' branch of
master.kernel.org:/pub/scm/linux/kernel/git/airlied/agp-2.6.git agp-patches
to receive the following updates:
drivers/char/agp/agp.h|7 +--
drivers/char/agp/ali-agp.c| 27 ---
On Sunday October 14, [EMAIL PROTECTED] wrote:
On Sunday 14 October 2007 12:46:12 pm Stefan Richter wrote:
David Newall wrote:
That is so rude.
When a reply contains as a reply to the first paragraph you're wrong with
no
elaboration, and as a reply to the second paragraph nothing but
ls --version
ls (GNU coreutils) 5.97
An fsck did it :) and had the source restored by checkout -f
Think Jan is right, there is a diff between the two...
On 10/15/07, Mark Lord [EMAIL PROTECTED] wrote:
Jan Engelhardt wrote:
On Oct 14 2007 09:27, Mark Lord wrote:
Jan-Benedict Glaw wrote:
On Sat, Oct 13, 2007 at 12:16:29AM +0200, Arnd Bergmann wrote:
This change seems rather bogus, you're changing the ABI just to work
around a bug in the compat_ioctl layer. Why not just do the compat
code the right way, like the patch below?
The underlying ABI is not changing, I hope - the
Hi, Peter and Andi,
Do you think this patch set is ready for merging? Otherwise what I can
do to make it ready?
Best Regards,
Huang Ying
On Fri, 2007-10-12 at 13:52 +0800, Huang, Ying wrote:
This patchset defines a 32-bit boot protocol for i386/x86_64 platform,
adds an extensible boot
On Sun, Oct 14, 2007 at 06:45:44PM -0500, Rob Landley wrote:
I admit a certain amount of personal annoyance that once the SCSI
layer consumes a category of device (USB, SATA, PATA), they can
often _only_ be used by going through the SCSI midlayer. (This
strikes me as analogous to TCP/IP
On Fri, Oct 12, 2007 at 05:05:24PM +0100, David Howells wrote:
diff --git a/fs/xfs/xfs_acl.c b/fs/xfs/xfs_acl.c
index 4ca4beb..a460508 100644
--- a/fs/xfs/xfs_acl.c
+++ b/fs/xfs/xfs_acl.c
@@ -383,7 +383,7 @@ xfs_acl_allow_set(
error = bhv_vop_getattr(vp, va, 0, NULL);
if (error)
AFAICS, videobuf-vmalloc use of mem-vma and mem-vmalloc is
bogus.
You obtain the latter with vmalloc_user(); so far, so good. Then you have
retval=remap_vmalloc_range(vma, mem-vmalloc,0);
where vma is given to you by mmap(); again, fine - we get the memory
pointed to be
On Monday 15 October 2007 10:57, Jeremy Fitzhardinge wrote:
Nick Piggin wrote:
Yes, as Dave said, vmap (more specifically: vunmap) is very expensive
because it generally has to invalidate TLBs on all CPUs.
I see.
I'm looking at some more general solutions to this (already have some
Hi Justin:
(added some CCs)
* Justin Piszcz [EMAIL PROTECTED] [2007-10-14 15:30:18 -0400]:
As a regular user, I cannot see the sensors on the A-bit board, but I can
see the CPU temperature, how come I can see one but not the other?
Kernel: $ uname -a
Linux mybox 2.6.23.1 #4 SMP PREEMPT
On Sun, Oct 14, 2007 at 11:28:46PM +0100, Alistair John Strachan wrote:
On Sunday 14 October 2007 23:06:22 Stefan Heinrichsen wrote:
Hello,
I posted this question at comp.linux.misc and where told this would be a
better place therefore. I would like to do a internship in the field of the
On Sun, 14 Oct 2007 19:52:12 +0200
Adrian Bunk [EMAIL PROTECTED] wrote:
The Coverity checker spotted that we have already oops'ed if dst
was NULL.
Since dst being NULL doesn't seem to be possible at this point this
patch removes the NULL check.
Signed-off-by: Adrian Bunk [EMAIL
Update to list - Ingo sent me offlist a broken out patch set of this
sched work, and I'm working with him to isolate the change that is
causing this problem.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson
On Monday 15 October 2007 12:01, Al Viro wrote:
AFAICS, videobuf-vmalloc use of mem-vma and mem-vmalloc is
bogus.
You obtain the latter with vmalloc_user(); so far, so good. Then you have
retval=remap_vmalloc_range(vma, mem-vmalloc,0);
where vma is given to you by mmap();
--- Ahmed S. Darwish [EMAIL PROTECTED] wrote:
Hi Casey,
On Sun, Oct 14, 2007 at 10:15:42AM -0700, Casey Schaufler wrote:
+
+CIPSO Configuration
+
+It is normally unnecessary to specify the CIPSO configuration. The default
+values used by the system handle all internal cases.
Nick Piggin wrote:
Yeah, it would be possible. The easiest way would just be to shoot down
all lazy vmaps (because you're doing the global IPIs anyway, which are
the expensive thing, at which point you may as well purge the rest of
your lazy mappings).
Sure.
If it is sufficiently rare,
On Mon, 15 Oct 2007 08:21:01 +0900 Satoru Takeuchi wrote:
Add uio document to DocBook compilation target.
`make *docs' doesn't generate The Userspace I/O HOWTO, the user space
I/O document written in DocBook.
Signed-off-by: Satoru Takeuchi [EMAIL PROTECTED]
Index:
Hi,
Mon, 15 Oct 2007 11:45:10 +0900
[Subject: Re: [2.6 patch] __inet6_csk_dst_store(): fix check-after-use]
Masahide NAKAMURA [EMAIL PROTECTED] wrote...
On Sun, 14 Oct 2007 19:52:12 +0200
Adrian Bunk [EMAIL PROTECTED] wrote:
The Coverity checker spotted that we have already oops'ed if
This is the accumulated updates queued for 2.6.24. It contains the
usual slew of driver updates, plus some gdth and advansys rewrites. We
still have some outstanding bugs in gdth and fc4 for which I'm hoping to
sweep fixes into the next update.
The patch is available here:
On Sun, Oct 14, 2007 at 08:42:34PM -0700, Jeremy Fitzhardinge wrote:
Nick Piggin wrote:
That's not going to
happen for at least a cycle or two though, so in the meantime maybe
an ifdef for that XFS vmap batching code would help?
For now I've proposed a patch to simply eagerly
David Chinner wrote:
With defaults - little effect as vmap should never be used. It's
only when you start using larger block sizes for metadata that this
becomes an issue. The CONFIG_XEN workaround should be fine until we
get a proper vmap cache
Hm, well I saw the problem with a
On Sun, Oct 14, 2007 at 09:18:17PM -0700, Jeremy Fitzhardinge wrote:
David Chinner wrote:
With defaults - little effect as vmap should never be used. It's
only when you start using larger block sizes for metadata that this
becomes an issue. The CONFIG_XEN workaround should be fine until we
Following are 5 minor patches for md in current -mm.
The first 4 are suitable to flow into 2.6.24.
The last fixes a small bug in Dan Williams' patches currently in -mm,
which are not scheduled for 2.6.24.
Thanks,
NeilBrown
[PATCH 001 of 5] md: Fix a bug in some never-used code.
[PATCH 002
http://bugzilla.kernel.org/show_bug.cgi?id=3277
There is a seq_printf here that isn't being passed a 'seq'.
Howeve as the code is inside #ifdef MD_DEBUG, nobody noticed.
Also remove some extra spaces.
Signed-off-by: Neil Brown [EMAIL PROTECTED]
### Diffstat output
./drivers/md/raid0.c | 10
When an array is started read-only, MD_RECOVERY_NEEDED can be set but
no recovery will be running. This causes 'sync_action' to report the
wrong value.
We could remove the test for MD_RECOVERY_NEEDED, but doing so would
leave a small gap after requesting a sync action, where 'sync_action'
would
From: Iustin Pop [EMAIL PROTECTED]
The 'degraded' attribute is useful to quickly determine if the array is
degraded, instead of parsing 'mdadm -D' output or relying on the other
techniques (number of working devices against number of defined devices, etc.).
The md code already keeps track of
Whenever a read error is found, we should attempt to overwrite with
correct data to 'fix' it.
However when do a 'check' pass (which compares data blocks that are
successfully read, but doesn't normally overwrite) we don't do that.
We should.
Signed-off-by: Neil Brown [EMAIL PROTECTED]
###
This kmem_cache_create is creating a cache that already exists. We
could us the alternate name, just like we do a few lines up.
Signed-off-by: Neil Brown [EMAIL PROTECTED]
Cc: Dan Williams [EMAIL PROTECTED]
### Diffstat output
./drivers/md/raid5.c |2 +-
1 file changed, 1 insertion(+), 1
this patchset (on hwmon-git) re-introduces superio_locks module,
previously RFC'd here, where I 'borrowed' another thread..
http://marc.info/?l=linux-kernelm=115821759424601w=2
The module shares out slots/shared-reservations containing
a mutex, so that multiple modules can coordinate access to
01 - adds superio_locks module
User-drivers specify the sio-port characteristics they can support
device-ids, sio-port-addrs, enter exit sequences, etc in
a struct superio_search (in __devinit, preferably).
superio_find() then searches existing slots/shared-reservations
for a matching
02 - use superio-locks in drivers/hwmon/w83627hf.c
tested on an AMD-Barton mobo.
Signed-off-by: Jim Cromie [EMAIL PROTECTED]
---
hwmon-superio-w83627hf
Kconfig|1
w83627hf.c | 140 -
2 files changed, 58 insertions(+), 83
03 - use superio-locks in drivers/hwmon/pc87360
this driver keeps the slot for only during __init, since it
only needs the sio-port to read the ISA addresses of the
Logical Devices in the chip, which are then used exclusively.
Signed-off-by: Jim Cromie [EMAIL PROTECTED]
---
04 - use superio-locks in drivers/char/pc8736x_gpio
this driver keeps the slot for the lifetime of the driver
( __init til __exit ), since the driver needs the sio-port
to change pin configurations.
patches 03,04 were tested on a soekris 4801 a year ago,
the box is currently busy. Together
05 - use superio-locks in rest of drivers/hwmon/*.c
this patch is compile-tested only, please review for sanity before you
try running them. Things to look for - missing superio_release(),
opportunities to use superio_devid(), superio_inw(), etc.
Signed-off-by: Jim Cromie [EMAIL PROTECTED]
When rounding a relative timeout we need to use round_jiffies_relative().
Signed-off-by: Anton Blanchard [EMAIL PROTECTED]
---
diff --git a/drivers/edac/edac_device.c b/drivers/edac/edac_device.c
index f3690a6..46400ec 100644
--- a/drivers/edac/edac_device.c
+++ b/drivers/edac/edac_device.c
@@
If memchr argument is longer than strlen(kp-name), there will be some weird
result.
It will casuse duplicate filenames in sysfs for the nousb. kernel
warning messages are as bellow:
sysfs: duplicate filename 'usbcore' can not be created
WARNING: at fs/sysfs/dir.c:416 sysfs_add_one()
[c01c4750]
When rounding a relative timeout we need to use round_jiffies_relative().
Signed-off-by: Anton Blanchard [EMAIL PROTECTED]
---
diff --git a/drivers/net/wireless/rt2x00/rt2x00lib.h
b/drivers/net/wireless/rt2x00/rt2x00lib.h
index 298faa9..06d9bc0 100644
---
When rounding a relative timeout we need to use round_jiffies_relative().
Signed-off-by: Anton Blanchard [EMAIL PROTECTED]
---
diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c
index 2d46a16..739d060 100644
--- a/drivers/net/wireless/ipw2100.c
+++
Rob Landley wrote:
I was at least attempting to ask a serious question.
...
Actually, I was going through Documentation/block thinking about making a
00-INDEX for it, but my earlier questions of the scsi guys left me with the
impression that the block layer is _not_ used by the SCSI layer.
When rounding a relative timeout we need to use round_jiffies_relative().
Signed-off-by: Anton Blanchard [EMAIL PROTECTED]
---
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index c141a26..41049a4 100644
--- a/drivers/net/wireless/b43/main.c
+++
On 10/14/07, Borislav Petkov [EMAIL PROTECTED] wrote:
Hi,
i get the following warning on yesterday's git tree (v2.6.23-2840-g752097c):
Oct 14 09:07:15 zmei kernel: [ 49.368030] sysfs: duplicate filename
'bInterfaceNumber' can not be created
Oct 14 09:07:15 zmei kernel: [ 49.368086]
401 - 470 of 470 matches
Mail list logo
