| From | Subject | Date |
|---|---|---|
| David Brownell | [patch 2.6.26-rc3] gpio: build fixes (mostly potential)
This fixes various gpio-related build errors (mostly potential)
reported in part by Russell King and Uwe Kleine-König.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
Refreshed version -- should apply OK on top of the gpio sysfs support
include/asm-generic/gpio.h | 6 +++++-
include/linux/gpio.h | 3 +++
2 files changed, 8 insertions(+), 1 deletion(-)
--- a/include/asm-generic/gpio.h 2008-05-20 11:46:13.000000000 -0700
+++ ...
| May 20, 4:17 pm 2008 |
| Andi Kleen | [PATCH] Fix incorrect comment in io_apic_64.c
Fix incorrect comment in io_apic_64.c
No broadcasting happens.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
arch/x86/kernel/io_apic_64.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux/arch/x86/kernel/io_apic_64.c
===================================================================
--- linux.orig/arch/x86/kernel/io_apic_64.c
+++ linux/arch/x86/kernel/io_apic_64.c
@@ -911,8 +911,7 @@ static void __init setup_IO_APIC_irqs(vo
}
/*
- * Set up the ...
| May 20, 4:42 pm 2008 |
| David Miller | [GIT]: Networking
A lot of small stuff:
1) Pull in wireless bug fixes from John Linville.
2) Kill CVS keywords from ATM code, from Adrian Bunk and ACK'd by
ATM maintainer.
3) skb->truesize not maintained properly my l2tp code, fix from
James Chapman.
4) IPSEC can crash on output path due to wrong output routine
usage, fix from Herbert Xu.
5) Fix pktgen shutdown race, from Denis Lunev.
6) Zap cli/sti from hysdn driver, and no longer mark broken on SMP.
From Mark Asselstine and Andrew ...
| May 20, 4:11 pm 2008 |
| Christian Kujau | kswapd busy but not swapping
Hi,
I noticed that the [kswapd0] thread was eating 3-7% cpu time but no
swapspace has been used yet. This is with a just booted 2.6.25.4 system,
currently with some disk i/o going on.
So I figured that kswapd might not be responsible for "swapping" after
all, although the name suggests it. Grep'ing Documentation/ for kswapd did
not reveal much. Is the paper from Kanoj[0] still valid for 2.6 kernels?
The SGI page referenced in Documentation/kernel-docs.txt is down, but
there's a .txt ...
| May 20, 4:04 pm 2008 |
| David Miller | [GIT]: Sparc
Two things going on here:
1) Add a "sysrq y" global register dumping facility that
works even when CPUs are stuck with interrupts disabled.
I've used this often enough myself, and given it to
users to debug problems, that it deserves to be upstream.
2) Patches from Adrian Bunk to delete all the old CVS Id
tags, I've been doing them gradually when touching specific
files, but it's just as good to kill them all if he's done
the work already.
Please pull, thanks a ...
| May 20, 4:04 pm 2008 |
| Arjan van de Ven | [PATCH] ata: fix sleep-while-holding-spinlock in sata_nv
From: Arjan van de Ven <arjan@linux.intel.com>
Subject: [PATCH] ata: fix sleep-while-holding-spinlock in sata_nv
blk_queue_bounce_limit() is a sleeping function, so reorganize
the code a little to not call it while holding a spinlock.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
drivers/ata/sata_nv.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/sata_nv.c b/drivers/ata/sata_nv.c
index 858f706..a7bc56d 100644
--- ...
| May 20, 3:58 pm 2008 |
| Joel Becker | Re: [2.6 patch] ocfs2: rename user_stack{,_ops}
Thanks for reporting this. Al already reported it and a fix is
in ocfs2.git. We change the name entirely so that grep of user_stack
doesn't match it at all.
Joel
--
"Nobody loves me,
Nobody seems to care.
Troubles and worries, people,
You know I've had my share."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
--
| May 20, 4:53 pm 2008 |
| Adrian Bunk | [2.6 patch] ocfs2: rename user_stack{,_ops}
On frv and ia64 asm/ptrace.h offers a different user_stack resulting in
compile errors like the following:
<-- snip -->
...
CC [M] fs/ocfs2/stack_user.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/ocfs2/stack_user.c:156: error: 'user_stack' redeclared as different kind of symbol
include2/asm/ptrace.h:77: error: previous declaration of 'user_stack' was here
make[3]: *** [fs/ocfs2/stack_user.o] Error 1
<-- snip -->
This patch therefore prefixes the user_stack{,_ops} names with ...
| May 20, 3:55 pm 2008 |
| Adrian Bunk | [2.6 patch] UML: remove the dead TTY_LOG code
This patch removes the dead CONFIG_TTY_LOG (no kconfig option).
Reported-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
arch/um/kernel/exec.c | 12 --
arch/um/os-Linux/Makefile | 3
arch/um/os-Linux/tty_log.c | 217 -------------------------------------
3 files changed, 232 deletions(-)
531b7c113d8deed217fb800cdd3f610899fbc0d9 diff --git a/arch/um/kernel/exec.c b/arch/um/kernel/exec.c
index f5d7f45..598711c 100644
--- ...
| May 20, 3:54 pm 2008 |
| Nicholas A. Bellinger | LIO-Target Core v3.0.0 imported in k.o git
Greetings all,
The LIO-Target Core v3.0.0 tree has been imported from v2.9-STABLE from
Linux-iSCSI.org source tree repositories into kernel.org git, and is
building w/ v2.6.26-rc3. It can be found at:
http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=summary
I will be continuing the cleanup activies for upstream, which so far has
included the removal of legacy unused engine level mirroring/replication
bits (as we are using LIO-DRBD or LIO-NR1 w/ MD for this now), and a ...
| May 20, 3:48 pm 2008 |
| Greg KH | [GIT PATCH] USB fixes for 2.6.26-rc3
Here are some USB patches for your 2.6.25-git tree.
They include:
- bugfixes
- new device ids
- removing a device id from one driver and putting it in the
correct one.
- a new driver, cdc-wdm, for wireless USB modems and phones.
This driver is self-contained and should cause no new
problems. This is the majority of the diffstat below.
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/
All of these patches have been in the -mm tree for a ...
| May 20, 3:32 pm 2008 |
| Greg Kroah-Hartman | [PATCH 06/13] LEDS: fix race in device_create
There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.
This patch fixes the problem by using the new function,
device_create_drvdata().
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/leds/led-class.c | 6 ++----
...
| May 20, 3:34 pm 2008 |
| Greg Kroah-Hartman | [PATCH 12/13] USB: Core: fix race in device_create
There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.
This patch fixes the problem by using the new function,
device_create_drvdata().
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/usb/core/hcd.c | 6 +++---
1 files changed, 3 insertions(+), 3 ...
| May 20, 3:34 pm 2008 |
| Greg Kroah-Hartman | [PATCH 01/13] Driver core: add device_create_vargs and d ...
We want to have the drvdata field set properly when creating the device
as sysfs callbacks can assume it is present and it can race the later
setting of this field.
So, create two new functions, deviec_create_vargs() and
device_create_drvdata() that take this new field.
device_create_drvdata() will go away in 2.6.27 as the drvdata field will
just be moved to the device_create() call as it should be.
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman ...
| May 20, 3:34 pm 2008 |
| Greg KH | [GIT PATCH] driver core fixes against 2.6.26-rc3
Here are some patches against your 2.6.26-rc3-git tree.
They fix a race condition when device_create is called. At that point
in time sysfs files can be created automatically by the class or the
driver subsystem, and if those files are opened before the device
specific data is set, oopses can happen. This was found and reported
for the bdi subsystem by Arthur Jones and he verified that these patches
fix the problem.
I then went and audited all users of the api and found other places
where ...
| May 20, 3:32 pm 2008 |
| Greg Kroah-Hartman | [PATCH 11/13] USB: Phidget: fix race in device_create
There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.
This patch fixes the problem by using the new function,
device_create_drvdata(). It fixes all 3 phidget drivers, which all have
the same problem.
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Sean Young <sean@mess.org>
Signed-off-by: Greg Kroah-Hartman ...
| May 20, 3:34 pm 2008 |
| Greg Kroah-Hartman | [PATCH 13/13] SCSI: fix race in device_create
There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.
This patch fixes the problem by using the new function,
device_create_drvdata(). It fixes the problem in all of the scsi
drivers that need it.
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Doug Gilbert <dgilbert@interlog.com>
Cc: James E.J. Bottomley ...
| May 20, 3:35 pm 2008 |
| Greg Kroah-Hartman | [PATCH 09/13] SOUND: fix race in device_create
There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.
This patch fixes the problem by using the new function,
device_create_drvdata().
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
sound/core/sound.c | 8 +++-----
1 ...
| May 20, 3:34 pm 2008 |
| Greg Kroah-Hartman | [PATCH 03/13] fbdev: fix race in device_create
There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.
This patch fixes the problem by using the new function,
device_create_drvdata().
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/video/display/display-sysfs.c ...
| May 20, 3:34 pm 2008 |
| Greg Kroah-Hartman | [PATCH 08/13] UIO: fix race in device_create
There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.
This patch fixes the problem by using the new function,
device_create_drvdata().
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Hans J. Koch <hjk@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/uio/uio.c | 7 +++----
1 files ...
| May 20, 3:34 pm 2008 |
| Greg Kroah-Hartman | [PATCH 04/13] ide: fix race in device_create
There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.
This patch fixes the problem by using the new function,
device_create_drvdata().
Cc: Kay Sievers <kay.sievers@vrfy.org>
Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/ide/ide-probe.c ...
| May 20, 3:34 pm 2008 |
| Greg Kroah-Hartman | [PATCH 10/13] s390: fix race in device_create
There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.
This patch fixes the problem by using the new function,
device_create_drvdata().
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Cornelia Huck ...
| May 20, 3:34 pm 2008 |
| Greg Kroah-Hartman | [PATCH 07/13] Power Supply: fix race in device_create
There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.
This patch fixes the problem by using the new function,
device_create_drvdata().
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Anton Vorontsov <cbou@mail.ru>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
...
| May 20, 3:34 pm 2008 |
| Greg Kroah-Hartman | [PATCH 05/13] IB: fix race in device_create
There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.
This patch fixes the problem by using the new function,
device_create_drvdata().
Cc: Kay Sievers <kay.sievers@vrfy.org>
Reviewed-by: Roland Dreier <rolandd@cisco.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: Hal Rosenstock ...
| May 20, 3:34 pm 2008 |
| Greg Kroah-Hartman | [PATCH 02/13] mm: bdi: fix race in bdi_class device creation
There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.
This patch fixes the problem by using the new function,
device_create_vargs().
Many thanks to Arthur Jones <ajones@riverbed.com> for reporting the bug,
and testing patches out.
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Arthur Jones ...
| May 20, 3:34 pm 2008 |
| Chuck Ebbert | [patch] x86: don't read maxlvt before checking if APIC i ...
x86: don't read maxlvt before checking if APIC is mapped
A check for unmapped apic was added before reading maxlvt but the early
read of maxlvt wasn't removed.
Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
Index: linux-2.6.25.noarch/arch/x86/kernel/apic_64.c
===================================================================
--- linux-2.6.25.noarch.orig/arch/x86/kernel/apic_64.c
+++ linux-2.6.25.noarch/arch/x86/kernel/apic_64.c
@@ -524,7 +524,7 @@ int setup_profiling_timer(unsigned int ...
| May 20, 3:18 pm 2008 |
| Németh Márton | [PATCH] smc-ultra: get rid of "eth%d" message
Print out the dev->name only after register_netdev(). If the
dev->name is printk()ed out before calling register_netdev()
the result will be "eth%d" in the dmesg instead of "eth0".
Signed-off-by: Márton Németh <nm127@freemail.hu>
---
--- linux-2.6.26-rc3/drivers/net/smc-ultra.c.orig 2008-04-17 04:49:44.000000000 +0200
+++ linux-2.6.26-rc3/drivers/net/smc-ultra.c 2008-05-20 22:04:15.000000000 +0200
@@ -228,9 +228,6 @@ static int __init ultra_probe1(struct ne
for (i = 0; i < 6; i++)
...
| May 20, 3:05 pm 2008 |
| Michael Halcrow | [PATCH] eCryptfs: Privileged kthread for lower file opens
eCryptfs would really like to have read-write access to all files in
the lower filesystem. Right now, the persistent lower file may be
opened read-only if the attempt to open it read-write fails. One way
to keep from having to do that is to have a privileged kthread that
can open the lower persistent file on behalf of the user opening the
eCryptfs file; this patch implements this functionality.
This patch will properly allow a less-privileged user to open the
eCryptfs file, followed by a ...
| May 20, 2:46 pm 2008 |
| Andrea Righi | Re: [PATCH] eCryptfs: Privileged kthread for lower file opens
Michael Halcrow wrote:
[snip]
Hi,
Why not:
if (!(req->flags & ECRYPTFS_REQ_ZOMBIE))
dget(req->lower_dentry);
mntget(req->lower_mnt);
(*req->lower_file) = dentry_open(
req->lower_dentry, req->lower_mnt,
(O_RDWR | O_LARGEFILE));
req->flags |= ECRYPTFS_REQ_PROCESSED;
wake_up_process(req->requesting_task);
}
--
| May 20, 4:16 pm 2008 |
| Dan Williams | [git pull] drivers/dma: fixups for 2.6.26-rc
Linus, please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/djbw/async_tx.git fixes
to receive:
Christophe Jaillet (1):
iop-adma: fixup some kzalloc/memset confusions
Zhang Wei (1):
fsldma: update the fsldma driver MAINTAINERS info
MAINTAINERS | 6 ++++--
drivers/dma/iop-adma.c | 6 ++----
2 files changed, 6 insertions(+), 6 deletions(-)
Just a maintainer update and some simple cleanups of the iop-adma
driver.
Thanks,
Dan
Full ...
| May 20, 2:16 pm 2008 |
| Mudeem Siddiqui | VM: killing process - How to identify the problem
Hi all,
I have linux 2.4.25 on a mips processor. Other than my application, the
other processes that are running on the system are udhcpd, dhcpd,
mini_dns etc. The applicaiton is quite memory intensive, it has
allocated 5 MB of a buffer which acts as a queue and the applicaiton
queues and de-queues packets in the queue at frequents intervals. The
memory for this buffer is allocated just once when the application
starts at the time of boot. So I would assume that there would be quite
a lot of ...
| May 20, 2:10 pm 2008 |
| Remy Bohmer | Compile warning rtmutex code on 2.6.24.7-rt8 (CC:LKML added)
Hello Steven,
Do you recognise these warnings? I do not know (yet) if these are ARM
specific...
CC kernel/rtmutex.o
kernel/rtmutex.c: In function 'rt_write_fastlock':
kernel/rtmutex.c:1582: warning: initialization makes pointer from
integer without a cast
kernel/rtmutex.c: In function 'rt_write_fasttrylock':
kernel/rtmutex.c:1622: warning: initialization makes pointer from
integer without a cast
If so, do you have a fix for it?
Regards,
Remy
--
| May 20, 1:56 pm 2008 |
| Steven Rostedt | Re: Compile warning rtmutex code on 2.6.24.7-rt8 (CC:LKM ...
Ah, I guess ARM is a bit more critical of chpxchg than x86 is.
I'll add a patch for 2.6.24.7-rt9 (which I plan on releasing soon). It
will have some minor clean ups.
-- Steve
--
| May 20, 2:11 pm 2008 |
| Steven Rostedt | Re: Compile warning rtmutex code on 2.6.24.7-rt8 (CC:LKM ...
Remy,
Can you see if this helps,
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
---
kernel/rtmutex.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.24.7-rt9/kernel/rtmutex.c
===================================================================
--- linux-2.6.24.7-rt9.orig/kernel/rtmutex.c 2008-05-20 17:11:29.000000000 -0400
+++ linux-2.6.24.7-rt9/kernel/rtmutex.c 2008-05-20 17:13:18.000000000 -0400
@@ -1577,7 +1577,7 @@ rt_write_fastlock(struct ...
| May 20, 2:20 pm 2008 |
| Trent Piepho | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
This came up on the Freescale list. I should have put what I wrote there into
my patch descrition:
It's the _le versions that have a problem, since we can't get gcc to just use
the register indexed mode. It seems like an obvious thing to have a
constraint for, but I guess there weren't enough instructions that only come
in 'x' versions to bother with it. There is a 'Z' constraint, "Memory operand
that is an indexed or indirect from a register", but I tried it and it can use
both "rb,ri" ...
| May 20, 3:11 pm 2008 |
| Andreas Schwab | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
'Z' will never emit a non-zero constant displacement.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
| May 20, 3:47 pm 2008 |
| Scott Wood | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
What about memory obtained from dma_alloc_coherent()? We still need a
sync and a compiler barrier. The current I/O accessors have the former,
but not the latter.
-Scott
--
| May 20, 3:35 pm 2008 |
| Alan Cox | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
DMA descriptors in main memory are dependant on cache behaviour anyway
and the dma_* operators should be the ones enforcing the needed behaviour.
Alan
--
| May 20, 3:15 pm 2008 |
| David Miller | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
From: Scott Wood <scottwood@freescale.com>
Indeed, and even the GCC manual is clear about this.
--
| May 20, 3:53 pm 2008 |
| Benjamin Herrenschmidt | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
The current accessors should provide all the necessary ordering
guarantees...
Ben.
--
| May 20, 2:16 pm 2008 |
| Andreas Schwab | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
There is the "Z" constraint, which matches either an indirect or an
indexed memory address. That should fit here.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
| May 20, 3:00 pm 2008 |
| Trent Piepho | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
Depends on what you define as "necessary". It's seem clear that I/O accessors
_no not_ need to be strictly ordered with respect to normal memory accesses,
by what's defined in memory-barriers.txt. So if by "necessary" you mean what
the Linux standard for I/O accessors requires (and what other archs provide),
then yes, they have the necessary ordering guarantees.
But, if you want them to be strictly ordered w.r.t to normal memory, that's
not the case.
For example, in something like:
u32 ...
| May 20, 3:00 pm 2008 |
| Benjamin Herrenschmidt | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
We probably want a full "memory" clobber then...
Ben.
--
| May 20, 3:02 pm 2008 |
| Trent Piepho | [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated
for the in_beXX() and out_beXX() mmio functions has been sub-optimal.
The out_leXX() family of functions are created with the macro
DEF_MMIO_OUT_LE() while the out_beXX() family are created with
DEF_MMIO_OUT_BE(). In what was perhaps a bit too much macro use, both of
these macros are in turn created via the macro DEF_MMIO_OUT().
For the LE versions, eventually they boil down to an asm that will look
something like ...
| May 20, 1:40 pm 2008 |
| Trent Piepho | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
It's too bad gas doesn't appear to be smart enough to turn:
stwbrx 0, 0(3) -or- stwbr 0, 0(3)
into the desired:
stwbrx 0, 0, 3
--
| May 20, 4:14 pm 2008 |
| David Miller | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
From: Scott Wood <scottwood@freescale.com>
The __volatile__ in the asm construct disallows movement of the
inline asm relative to statements surrounding it.
The only reason barrier() in kernel.h needs a memory clobber is
because of a bug in ancient versions of gcc. In fact, I think
that memory clobber might even be removable.
--
| May 20, 3:39 pm 2008 |
| Scott Wood | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
It looks like we rely on -fno-strict-aliasing to prevent reordering
ordinary memory accesses (such as to DMA descriptors) past the I/O
access. It won't prevent reordering of memory reads around an I/O read,
though, which could be a problem if the I/O read result determines the
validity of the DMA buffer. IMHO, a memory clobber would be better.
-Scott
--
| May 20, 2:38 pm 2008 |
| Scott Wood | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
Current versions of GCC seem quite happy to move non-asm memory accesses
around a volatile asm without a memory clobber; see the test Trent posted.
-Scott
--
| May 20, 3:43 pm 2008 |
| Trent Piepho | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
As far as I could tell, no other arch has a full memory clobber. I can see
the argument for changing the Linux model to be stricter and less efficient,
but easier to program for. Not that I entirely agree with it.
But I don't see a good reason for why powerpc should be different than
everything else.
--
| May 20, 3:21 pm 2008 |
| Trent Piepho | Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
There doesn't appear to be any barriers to use for coherent dma other than
mb() and wmb().
Correct me if I'm wrong, but I think the sync isn't actually _required_ (by
memory-barriers.txt's definitions), and it would be enough to use eieio,
except there is code that doesn't use mmiowb() between I/O access and
unlocking.
So, as I understand it, the minimum needed is eieio. To provide strict
ordering w.r.t. spin locks without using mmiowb(), you need sync. To provide
strict ordering w.r.t. ...
| May 20, 3:55 pm 2008 |
| Remy Bohmer | Compile bug in 2.6.24.8-rt7 on ARM
Hello Steven,
Now I started looking at compiling 2.6.24.7-rt8 for ARM, and I found
another compile problem... ;-))
This one:
CC arch/arm/kernel/process.o
arch/arm/kernel/process.c: In function 'cpu_idle':
arch/arm/kernel/process.c:175: error: implicit declaration of function
'trace_preempt_exit_idle'
arch/arm/kernel/process.c:180: error: implicit declaration of function
'trace_preempt_enter_idle'
These function do not appear to exist _anywhere_ in the kernel.
So these calls can ...
| May 20, 1:37 pm 2008 |
| Steven Rostedt | Re: Compile bug in 2.6.24.8-rt7 on ARM
Thanks Remy,
Yes that was left over from the latency_trace conversion to ftrace. Note,
I have yet (nor anyone else) ported the new ftrace to arm. That is going
to be needed soon.
If you want to do it (hint hint) don't waste your time on the -rt ftrace.
That will soon be revamped to get back in line with upstream ftrace, which
can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
Look for the ftrace branch. Any work on ftrace should be done ...
| May 20, 1:55 pm 2008 |
| werner | 2.6.26-rcX: Problem with mem config > 4GB ; fore2000 atm ...
I observed the following problems with 2.6.26-rcX-gitY:
Steady-steady I got segmentation faults. On 2.6.25.4 no problems. I compiled plenty times the newer kernels to find out the reason. I thing the problem is the memory configuration as > 4 GB. In my config file, since earlier kernels, i configured >4 GB. When I use config files with that, then occure the problems, with <4 GB not. It seems that the menuconfig of the new kernels accept only until 4 GB.
Another problem with the fore2000 atm ...
| May 20, 12:49 pm 2008 |
| Steven Rostedt | 2.6.25.4-rt3
We are pleased to announce the 2.6.25.4-rt3 tree, which can be
downloaded from the location:
http://rt.et.redhat.com/download/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
Changes since 2.6.25.4-rt2
- Read Write locks with multiple readers (Steven Rostedt)
- Compile fix for my misapply of Thomas tsc patch (Mike Galbraith)
to build a 2.6.25.4-rt3 tree, the following patches should be applied:
...
| May 20, 12:44 pm 2008 |
| Ingo Molnar | [patch] video/dvb: fix MEDIA_TUNER && FW_LOADER build error
-tip testing found the following build failure:
LD .tmp_vmlinux1
drivers/built-in.o: In function `generic_set_freq':
tuner-xc2028.c:(.text+0xbd896): undefined reference to `request_firmware'
tuner-xc2028.c:(.text+0xbdd7a): undefined reference to `release_firmware'
drivers/built-in.o: In function `xc_load_fw_and_init_tuner':
xc5000.c:(.text+0xc68e6): undefined reference to `request_firmware'
xc5000.c:(.text+0xc6abe): undefined reference to `release_firmware'
with this ...
| May 20, 12:34 pm 2008 |
| Harvey Harrison | Re: [PATCH 2/2] byteorder: eliminate pointer bytorder api
Obviously I missed that part, my apologies. Would it be acceptable if,
taking the possibly arch-specific parts, moved the [endian]_to_cpup
name over to get_[endian]
ie:
le16_to_cpup -> get_le16
I'd leave cpu_to_le16p alone (it's not used that much anyway).
To make it similar to the get_unaligned_le16 helpers?
Thanks for having a look,
Harvey
--
| May 20, 3:15 pm 2008 |
| David Miller | Re: [PATCH 2/2] byteorder: eliminate pointer bytorder api
From: Harvey Harrison <harvey.harrison@gmail.com>
But what you're doing in the first patch is killing performance for some
cases.
The reason we use the cpu_to_*p() interfaces is to get the other-endian
load and store instructions some processors have.
What you're doing is undoing all of that work we've done to take
advantage of such things.
--
| May 20, 2:17 pm 2008 |
| Harvey Harrison | Re: [PATCH 2/2] byteorder: eliminate pointer bytorder api
Saw a lot of (or similar in a private helper):
*(__be32 *)ptr = cpu_to_be32(val);
So I came up with
void put_be32(val, ptr);
This looked a lot like the put_unaligned_be32 helpers and only left a
gap that was get_be32(ptr).
But this was exactly the same as the existing be32_to_cpup, so I wasn't
sure if I should add it or not. In the end I just went ahead and did
it and wanted to see what the patch would be like moving over existing
users to the new api looked like.
On top of that ...
| May 20, 3:30 pm 2008 |
| David Miller | Re: [PATCH 2/2] byteorder: eliminate pointer bytorder api
From: Harvey Harrison <harvey.harrison@gmail.com>
Why are we fiddling with interface names that have been fine for about
10 years?
--
| May 20, 3:19 pm 2008 |
| Harvey Harrison | [PATCH 2/2] byteorder: eliminate pointer bytorder api
Not a great api, should be using cpu_to_etc and deref the pointer yourself.
cpu_to_le16p
cpu_to_le32p
cpu_to_le64p
cpu_to_be16p
cpu_to_be32p
cpu_to_be64p
Replaced by the aligned get_/put_ helpers
le16_to_cpup
le32_to_cpup
le64_to_cpup
be16_to_cpup
be32_to_cpup
be64_to_cpup
Also add const to the get/put helpers and use them in the access_ok case for
unaligned access.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
include/linux/byteorder/big_endian.h | 50 ...
| May 20, 12:24 pm 2008 |
| David Miller | Re: [PATCH 1/2] Remove all users of cpu_to_{le|be}{16|32|64}p
From: Harvey Harrison <harvey.harrison@gmail.com>
Can you provide some contextual information in the changelog
message?
Why are the cpu_to_*p() uses going away? Do the normal cpu_to_*() now
transparently emit the special other-endian loads and stores some
cpus?
You should always describe such things in your changelog message so
people don't need to ask these kinds of questions.
--
| May 20, 2:16 pm 2008 |
| Harvey Harrison | [PATCH 1/2] Remove all users of cpu_to_{le|be}{16|32|64}p
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
akpm: applies on top of the 21-patch aligned get/put helpers series.
arch/sparc64/lib/PeeCeeI.c | 16 ++++++++--------
drivers/i2c/busses/i2c-pmcmsp.c | 2 +-
drivers/isdn/hisax/st5481_usb.c | 4 ++--
drivers/net/usb/kaweth.c | 6 +++---
drivers/net/usb/pegasus.c | 12 ++++++------
drivers/usb/class/cdc-acm.c | 5 +++--
drivers/usb/core/message.c | 6 +++---
...
| May 20, 12:24 pm 2008 |
| Matthew Garrett | Re: [PATCH] Firmware loader driver for USB Apple iSight camera
If it loses its firmwrare, it'll reattach with the old ID.
--
Matthew Garrett | mjg59@srcf.ucam.org
--
| May 20, 3:03 pm 2008 |
| Oliver Neukum | Re: [PATCH] Firmware loader driver for USB Apple iSight camera
Thereby breaking the binding to the uvc driver. It'll be considered
a new device. You might just as well load the firmware through usbfs
triggered by udev.
If you really want to fix this you'd have to extend the persist
infrastructure first.
Regards
Oliver
--
| May 20, 3:08 pm 2008 |
| Matthew Garrett | [PATCH] Firmware loader driver for USB Apple iSight camera
Uninitialised Apple iSight drivers present with a distinctive USB ID.
Once firmware has been uploaded, they disconnect and reconnect with a
new ID. At this point they can be driven by the uvcvideo driver. As this
is unique to the Apple cameras and not functionality shared by any other
UVC devices, it makes sense to provide the firmware loading
functionality in a separate driver. This driver will read an isight.fw
file extracted from the Apple driver using the tools at ...
| May 20, 12:06 pm 2008 |
| Oliver Neukum | Re: [PATCH] Firmware loader driver for USB Apple iSight camera
How does that simplify suspend/resume?
If the device looses its firmware due to suspend you must implement
this support in uvc, or a user space driver will be as good as this solution.
Regards
Oliver
--
| May 20, 2:59 pm 2008 |
| 葉婉菁 | 珍珠墬鏈禮盒每盒特價$600
您2008想5給21心愛的另ㄧ半ㄧ份21驚5喜2008嗎?
近5來5看5看,試5試5這5個5喔 ^.^
珍9珠9貝9殼9項9鍊9禮9盒 ~ 日9本9九9州9空9運9來9台
網址在這→203.70.179.39/ju←複製這行網址貼上即可
∴←▽←↓
| May 20, 12:05 pm 2008 |
| m.s.tsirkin | regression iwl3945/mac80211: association times out since ...
Hi!
In all of 2.6.26-rc1, rc2 and rc3, my iwl3945 wifi card can't associate with my access point.
It does associate in 2.6.25.
under 2.6.-26-rc[1,2,3] wpa_supplicant reports:
Trying to associate with 00:16:e3:ef:5d:f0 (SSID='' freq=0 MHz)
Authentication with 00:00:00:00:00:00 timed out.
where under 2.6.25 I was associating with
Trying to associate with 00:16:e3:ef:5d:f0 (SSID='SIEMENS-EF5DF0' freq=2437 MHz)
Associated with 00:16:e3:ef:5d:f0
WPA: Key negotiation completed with ...
| May 20, 11:49 am 2008 |
| David Miller | Re: include/linux/netfilter.h after make headers_install ...
From: "Greg Steuck" <greg@nest.cx>
No, it does not. netfilter-devel@vger.kernel.org is the correct place
to discuss this, added to CC:.
Perhaps you sent this to plain "netfilter@vger.kernel.org" or the
--
| May 20, 2:21 pm 2008 |
| Greg Steuck | Fwd: include/linux/netfilter.h after make headers_instal ...
Hello,
I asked this on netfilter list, but it doesn't seem to be generating any
interest there. Maybe the question belongs on this list?
I ran make headers_install in 2.6.25 tree and the installed netfilter.h is
not complete. Namely, it declares
union nf_inet_addr {
__u32 all[4];
__be32 ip;
__be32 ip6[4];
...
}
The __u32, __be32 types are declared in <linux/types.h> and the #include
directive is removed by the installation process. This in ...
| May 20, 11:44 am 2008 |
| mark | fork: Resource temporarily unavailable / cant start new ...
I upgraded to 2.6.25.3-18.fc9.x86_64 fedora core 9, now I get this
error when I try to login to the box, kill a pr start a python app, or
do anything on a regular basis.
fork: Resource temporarily unavailable
I have over 10GB RAM free, and zero swap spaced used. The box is a
dual quad core Intel Xeon 5405 with 16GB RAM.
There is no error message in /var/log/messages or dmesg ...
how do I identify the problem?
thanks!
uname -a
Linux XXX 2.6.25.3-18.fc9.x86_64 #1 SMP Tue May 13 04:54:47 ...
| May 20, 11:26 am 2008 |
| Stas Sergeev | [patch] provide rtc_cmos platform device
Hello.
Recently (around 2.6.25) I've noticed
that RTC no longer works for me.
It turned out this is because I use
pnpacpi=off kernel option to work
around the parport_pc bugs.
I always did so, but RTC used to work
fine in the past, and now it have
regressed.
The attached patch fixes the problem
by creating the platform device for
the RTC when PNP is disabled.
This may also help running the
PNP-enabled kernel on an older PCs.
Signed-off-by: Stas Sergeev <stsp@aknet.ru>
| May 20, 11:25 am 2008 |
| Christoph Lameter | Yet another mm notifier: Notify when pages are unmapped.
[Empty message]
| May 20, 11:21 am 2008 |
| Paul Rolland | SATA hotplug device renaming and dmraid...
Hello,
I'm using a machine that supports SATA hotplug and with and Intel ESB2
(Fake)Raid controller.
I've configured a raid1 (mirror) array using dmraid, that is made of
/dev/sda and /dev/sdb, and seen by the OS as /dev/mapper/isw_xxxxxxx_RAID1
My problem is that when I unplug and replug a disk, it is assigned a
new name (/dev/sdc first time as this is the first name available), and
so it is no more considered as being part of the RAID array.
Is this an expected behavior ? Is there a way ...
| May 20, 11:11 am 2008 |
| Alan D. Brunelle | /proc/lock_stat "stuck"
I'm attempting to use /proc/lock_stat to gather some information during
some benchmarking runs, but what I find happens is as follows:
1. I boot the system - 2.6.26-rc3 kernel + CONFIG_LOCK_STAT=y
2. I can then look at /proc/lock_stat, and it has valid-looking values
3. I wait a while, do some stuff, but when I look at /proc/lock_stat
again the values have not changed.
4. If I clear the counters - echo 0 > /proc/lock_stat - the counters
never increase, and no information besides the ...
| May 20, 11:09 am 2008 |
| Harvey Harrison | [PATCH 08/21] ata: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
drivers/ata/pdc_adma.c | 11 +++++------
drivers/ata/sata_qstor.c | 10 +++++-----
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/ata/pdc_adma.c b/drivers/ata/pdc_adma.c
index be53545..12675f3 100644
--- a/drivers/ata/pdc_adma.c
+++ b/drivers/ata/pdc_adma.c
@@ -284,11 +284,11 @@ static int adma_fill_sg(struct ata_queued_cmd *qc)
u32 len;
addr = (u32)sg_dma_address(sg);
- *(__le32 *)(buf ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 07/21] scsi: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
drivers/scsi/aacraid/commsup.c | 8 ++++----
drivers/scsi/aic94xx/aic94xx_scb.c | 4 ++--
drivers/scsi/aic94xx/aic94xx_task.c | 8 ++++----
drivers/scsi/stex.c | 2 +-
include/scsi/sas.h | 2 +-
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c
index 289304a..2dcdaf0 100644
--- ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 12/21] cifs: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
fs/cifs/inode.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index fcbdbb6..6271e9f 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -317,8 +317,8 @@ static int decode_sfu_inode(struct inode *inode, __u64 size,
/* we have enough to decode dev num */
__u64 mjr; /* major */
__u64 mnr; /* minor */
- mjr = le64_to_cpu(*(__le64 ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 11/21] affs: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
fs/affs/bitmap.c | 14 +++++++-------
fs/affs/super.c | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/affs/bitmap.c b/fs/affs/bitmap.c
index c4a5ad0..3df7327 100644
--- a/fs/affs/bitmap.c
+++ b/fs/affs/bitmap.c
@@ -92,14 +92,14 @@ affs_free_block(struct super_block *sb, u32 block)
data = (__be32 *)bh->b_data + bit / 32 + 1;
/* mark block free */
- tmp = be32_to_cpu(*data);
+ tmp = ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 04/21] drivers/infiniband: use aligned-endian get ...
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
drivers/infiniband/core/packer.c | 16 ++++++++--------
drivers/infiniband/core/sysfs.c | 4 ++--
drivers/infiniband/core/user_mad.c | 2 +-
drivers/infiniband/hw/ipath/ipath_driver.c | 3 +--
drivers/infiniband/hw/mlx4/main.c | 19 +++++++++----------
drivers/infiniband/hw/mthca/mthca_cmd.c | 8 ++++----
drivers/infiniband/hw/mthca/mthca_dev.h | 12 ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 10/21] ntfs: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
fs/ntfs/collate.c | 4 ++--
fs/ntfs/compress.c | 9 ++++-----
fs/ntfs/endian.h | 6 +++---
fs/ntfs/mst.c | 2 +-
fs/ntfs/super.c | 2 +-
5 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/fs/ntfs/collate.c b/fs/ntfs/collate.c
index 4a28ab3..d370931 100644
--- a/fs/ntfs/collate.c
+++ b/fs/ntfs/collate.c
@@ -52,8 +52,8 @@ static int ntfs_collate_ntofs_ulong(ntfs_volume *vol,
// FIXME: ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 18/21] media: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
drivers/media/dvb/frontends/or51132.c | 2 +-
drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c | 2 +-
drivers/media/video/bt8xx/bttv-cards.c | 4 ++--
drivers/video/aty/mach64_accel.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/frontends/or51132.c b/drivers/media/dvb/frontends/or51132.c
index c7b5785..b2af1de 100644
--- ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 21/21] arch: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
arch/parisc/lib/iomap.c | 4 ++--
arch/powerpc/sysdev/qe_lib/qe.c | 2 +-
arch/sparc64/kernel/unaligned.c | 8 ++++----
arch/sparc64/lib/PeeCeeI.c | 6 +++---
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/parisc/lib/iomap.c b/arch/parisc/lib/iomap.c
index 9abed07..ac2f0eb 100644
--- a/arch/parisc/lib/iomap.c
+++ b/arch/parisc/lib/iomap.c
@@ -278,7 +278,7 @@ unsigned int ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 16/21] gfs2: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
fs/gfs2/bmap.c | 2 +-
fs/gfs2/lops.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
index c19184f..42473ee 100644
--- a/fs/gfs2/bmap.c
+++ b/fs/gfs2/bmap.c
@@ -160,7 +160,7 @@ int gfs2_unstuff_dinode(struct gfs2_inode *ip, struct page *page)
gfs2_buffer_clear_tail(dibh, sizeof(struct gfs2_dinode));
if (ip->i_di.di_size) {
- *(__be64 *)(di + 1) = ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 14/21] ext3: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
fs/ext3/super.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index fe3119a..1dbae0f 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -2595,8 +2595,8 @@ static int ext3_statfs (struct dentry * dentry, struct kstatfs * buf)
buf->f_ffree = percpu_counter_sum_positive(&sbi->s_freeinodes_counter);
es->s_free_inodes_count = cpu_to_le32(buf->f_ffree);
...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 13/21] ext2: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
fs/ext2/super.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext2/super.c b/fs/ext2/super.c
index ef50cbc..ca619bf 100644
--- a/fs/ext2/super.c
+++ b/fs/ext2/super.c
@@ -1277,8 +1277,8 @@ static int ext2_statfs (struct dentry * dentry, struct kstatfs * buf)
buf->f_ffree = ext2_count_free_inodes(sb);
es->s_free_inodes_count = cpu_to_le32(buf->f_ffree);
buf->f_namelen = ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 09/21] xfs: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
fs/xfs/xfs_log.c | 4 ++--
fs/xfs/xfs_log_priv.h | 6 +++---
fs/xfs/xfs_log_recover.c | 9 ++++-----
fs/xfs/xfs_mount.c | 12 ++++++------
4 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
index afaee30..b90325d 100644
--- a/fs/xfs/xfs_log.c
+++ b/fs/xfs/xfs_log.c
@@ -1529,7 +1529,7 @@ xlog_sync(xlog_t *log,
*/
for (i = 0; i < split; i += ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 06/21] net: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
net/9p/conv.c | 14 +++++++-------
net/9p/trans_fd.c | 2 +-
net/9p/trans_virtio.c | 2 +-
net/decnet/af_decnet.c | 4 ++--
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/net/9p/conv.c b/net/9p/conv.c
index 4454720..e1dfb73 100644
--- a/net/9p/conv.c
+++ b/net/9p/conv.c
@@ -92,7 +92,7 @@ static void buf_put_int8(struct cbuf *buf, u8 val)
static void buf_put_int16(struct cbuf *buf, ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 17/21] fs: remaining users of aligned-endian get/ ...
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
fs/hfsplus/wrapper.c | 6 +++---
fs/isofs/compress.c | 4 ++--
fs/partitions/acorn.c | 2 +-
fs/qnx4/inode.c | 2 +-
fs/reiserfs/super.c | 2 +-
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/hfsplus/wrapper.c b/fs/hfsplus/wrapper.c
index 175d08e..0e2fd86 100644
--- a/fs/hfsplus/wrapper.c
+++ b/fs/hfsplus/wrapper.c
@@ -35,17 +35,17 @@ static int hfsplus_read_mdb(void *bufptr, struct ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | Re: [PATCH 05/21] drivers/usb: use aligned-endian get/pu ...
After all that I compiled with the wrong config to make sure
^
Sorry.
Harvey
--
| May 20, 11:45 am 2008 |
| Harvey Harrison | [PATCH 05/21] drivers/usb: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
drivers/usb/c67x00/c67x00-hcd.c | 4 ++--
drivers/usb/core/devio.c | 12 ++++++------
drivers/usb/gadget/net2280.c | 2 +-
drivers/usb/host/ehci.h | 6 ++----
drivers/usb/host/isp116x-hcd.c | 4 ++--
drivers/usb/host/ohci.h | 16 ++++++----------
drivers/usb/host/uhci-hub.c | 6 +++---
drivers/usb/misc/auerswald.c | 2 +-
drivers/usb/serial/garmin_gps.c | 9 ++++-----
...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 15/21] ext4: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
fs/ext4/super.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 09d9359..d0e537b 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3006,8 +3006,8 @@ static int ext4_statfs (struct dentry * dentry, struct kstatfs * buf)
buf->f_ffree = percpu_counter_sum_positive(&sbi->s_freeinodes_counter);
es->s_free_inodes_count = cpu_to_le32(buf->f_ffree);
...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 19/21] drivers/block: use aligned-endian get/put ...
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
drivers/block/cciss.c | 11 +++++------
drivers/block/paride/pd.c | 8 ++++----
drivers/block/ub.c | 4 ++--
3 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index e336b05..5e5d39a 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -1513,8 +1513,7 @@ static int rebuild_lun_table(ctlr_info_t *h, struct gendisk *del_disk)
0, ...
| May 20, 11:06 am 2008 |
| Harvey Harrison | [PATCH 20/21] drivers: remaining users of aligned-endian ...
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
drivers/atm/lanai.c | 7 +++----
drivers/cdrom/cdrom.c | 2 +-
drivers/char/pcmcia/cm4040_cs.c | 2 +-
drivers/char/tpm/tpm_tis.c | 4 ++--
drivers/firewire/fw-card.c | 2 +-
drivers/firewire/fw-device.c | 2 +-
drivers/firewire/fw-ohci.c | 3 +--
drivers/hwmon/ibmpex.c | 2 +-
...
| May 20, 11:06 am 2008 |
| David Dillow | Re: [PATCH 03/21] drivers/net: use aligned-endian get/pu ...
Acked-by: David Dillow <dave@thedillows.org>
--
| May 20, 12:03 pm 2008 |
| Harvey Harrison | [PATCH 03/21] drivers/net: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
drivers/net/8139cp.c | 4 ++--
drivers/net/8139too.c | 6 +++---
drivers/net/bfin_mac.c | 8 ++++----
drivers/net/forcedeth.c | 4 ++--
drivers/net/mlx4/eq.c | 2 +-
drivers/net/mlx4/fw.c | 16 ++++++++--------
drivers/net/netxen/netxen_nic_init.c | 2 +-
...
| May 20, 11:05 am 2008 |
| Harvey Harrison | [PATCH 02/21] crypto: use aligned-endian get/put helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
crypto/ccm.c | 6 +++---
crypto/crc32c.c | 4 ++--
crypto/lrw.c | 2 +-
crypto/michael_mic.c | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/crypto/ccm.c b/crypto/ccm.c
index 7cf7e5a..9fdc2db 100644
--- a/crypto/ccm.c
+++ b/crypto/ccm.c
@@ -150,11 +150,11 @@ static int format_adata(u8 *adata, unsigned int a)
* RFC 3610 and NIST Special Publication 800-38C
*/
if ...
| May 20, 11:05 am 2008 |
| Harvey Harrison | [PATCH 01/21] lib: add byteorder helpers for the aligned case
Some users know the pointer they are writeing to are aligned,
rather than doing *(__le16 *)ptr = cpu_to_le16(val) add helpers
wrapping this up that have the same convention as put_unaligned_le/be.
Although the get_be/le versions duplicate the le16_to_cpup functionality
add them anyway as it makes this a complete api and start work to
eliminate {le|be}{16|32|64}_to_cpup uses (not many).
This makes the api look like:
get_unaligned_le16
put_unaligned_le16
get_le16
put_le16
With ...
| May 20, 11:05 am 2008 |
| David Brownell | Re: [PATCH] gpiolib: Fix off by one errors
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
... should make it into 2.6.26-final, but this is evidently
--
| May 20, 11:23 am 2008 |
| Trent Piepho | [PATCH] gpiolib: Fix off by one errors
The last gpio belonging to a chip is chip->base + chip->ngpios - 1. Some
places in the code, but not all, forgot the critical minus one.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
---
drivers/gpio/gpiolib.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 7f138c6..beaf6b3 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -127,7 +127,7 @@ int __init gpiochip_reserve(int start, int ...
| May 20, 10:58 am 2008 |
| Jesse Barnes | [git pull] PCI fixes
Please pull the PCI fixes:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6.git for-linus
We're still tracking down a couple of PCI hotplug regressions (there's a new
delay at probe time and drivers fighting over ports), so this won't be the
last pull request, but I wanted to get this HP fix upstream. This pull also
includes an update for the PCI error list entry in MAINTAINERS; I forgot to
update it when linux-pci@ moved.
Thanks,
Jesse
Jesse Barnes (1):
PCI: ...
| May 20, 10:51 am 2008 |
| Cyrill Gorcunov | [Q] eCryptFS race window?
Hi Michael,
it seems there is a few potential race window in eCryptFS which I was trying
to fix but it requires more deeper eCrypFS knowledge that have (at least only
by understanding eCryptFS in big picture it is possible to fix this problem
by elegant path). So what is the problem - the procedures
ecryptfs_miscdev_poll
ecryptfs_miscdev_read
does take ecryptfs_daemon_hash_mux mutex and then daemon->mux _but_ releases
them not in exactly backward order as it should. My patches (not in ...
| May 20, 10:03 am 2008 |
| Cyrill Gorcunov | Re: [Q] eCryptFS race window?
[Michael Halcrow - Tue, May 20, 2008 at 01:27:57PM -0500]
| On Tue, May 20, 2008 at 09:03:21PM +0400, Cyrill Gorcunov wrote:
| > it seems there is a few potential race window in eCryptFS which I
| > was trying to fix but it requires more deeper eCrypFS knowledge that
| > have (at least only by understanding eCryptFS in big picture it is
| > possible to fix this problem by elegant path). So what is the
| > problem - the procedures
| >
| > ecryptfs_miscdev_poll
| > ecryptfs_miscdev_read
| > ...
| May 20, 11:54 am 2008 |
| Michael Halcrow | Re: [Q] eCryptFS race window?
I cannot find an execution path whereby one of the two must re-acquire
ecryptfs_daemon_hash_mux in order to release daemon->mux, so I do not
think we will ever have deadlock between those two functions.
Mike
--
| May 20, 11:27 am 2008 |
| Cyrill Gorcunov | Re: [Q] eCryptFS race window?
[Michael Halcrow - Tue, May 20, 2008 at 01:27:57PM -0500]
| On Tue, May 20, 2008 at 09:03:21PM +0400, Cyrill Gorcunov wrote:
| > it seems there is a few potential race window in eCryptFS which I
| > was trying to fix but it requires more deeper eCrypFS knowledge that
| > have (at least only by understanding eCryptFS in big picture it is
| > possible to fix this problem by elegant path). So what is the
| > problem - the procedures
| >
| > ecryptfs_miscdev_poll
| > ecryptfs_miscdev_read
| > ...
| May 20, 11:39 am 2008 |
| Andy Whitcroft | [PATCH 2/3] hugetlb-move-reservation-region-support-earlier
The following patch will require use of the reservation regions support.
Move this earlier in the file. No changes have been made to this code.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
mm/hugetlb.c | 242 +++++++++++++++++++++++++++++-----------------------------
1 files changed, 121 insertions(+), 121 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3cae97d..9f060f1 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -561,6 +561,127 @@ static void ...
| May 20, 9:55 am 2008 |
| Andy Whitcroft | [PATCH 1/3] record MAP_NORESERVE status on vmas and fix ...
When a small page mapping is created with mmap() reservations are created
by default for any memory pages required. When the region is read/write
the reservation is increased for every page, no reservation is needed for
read-only regions (as they implicitly share the zero page). Reservations
are tracked via the VM_ACCOUNT vma flag which is present when the region
has reservation backing it. When we convert a region from read-only to
read-write new reservations are aquired and VM_ACCOUNT is ...
| May 20, 9:55 am 2008 |
| Joel Becker | Re: [Ocfs2-devel] [RFC][PATCH 0/3] configfs: Make nested ...
Hmm, this is definitely a more readable solution than the
previous, but I'm also with Arjan that it's scary :-)
Joel
--
"Ninety feet between bases is perhaps as close as man has ever come
to perfection."
- Red Smith
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
--
| May 20, 2:41 pm 2008 |
| Joel Becker | Re: [RFC][PATCH 0/3] configfs: Make nested default group ...
Looking at this, it's taking the address of the struct
lock_class_key as the actual key. Thus, if we tie one of these guys to
the structure we're representing, we get lock safety...except that we're
talking about i_mutex here, and we want to interact with the VFS's use
thereof.
Joel
--
"There is no sincerer love than the love of food."
- George Bernard Shaw
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
--
| May 20, 4:51 pm 2008 |
| Joel Becker | Re: [RFC][PATCH 0/3] configfs: Make nested default group ...
I think that's what we're talking about here. The toplevel is
I_MUTEX_PARENT, then each child has a class of (I_MUTEX_CHILD + depth),
where depth is the value of s_level. His original try passed depth
everywhere. I'm asking him to attach it to the configfs_dirent so that
the code stays readable. We run into a depth limit at
(MAX_LOCKDEP_SUBCLASS - I_MUTEX_PARENT - 1 == 5), which I think is
probably sane.
Do you mean something else? Perhaps not starting from
I_MUTEX_PARENT/CHILD and ...
| May 20, 3:27 pm 2008 |
| Arjan van de Ven | Re: [RFC][PATCH 0/3] configfs: Make nested default group ...
On Tue, 20 May 2008 18:33:20 +0200
I'm... not entirely happy with such a solution ;(
there must be a better one.
--
| May 20, 9:58 am 2008 |
| Arjan van de Ven | Re: [RFC][PATCH 0/3] configfs: Make nested default group ...
On Tue, 20 May 2008 15:27:02 -0700
not quite what I meant; what I meant is more like how sched.c deals
with per cpu queues:
(from sched.c)
spin_lock_init(&rq->lock);
lockdep_set_class(&rq->lock, &rq->rq_lock_key);
eg you can override the class (not just add a subclass) for a lock
based on a "key"..
--
| May 20, 3:35 pm 2008 |
| Louis Rilling | [RFC][PATCH 0/3] configfs: Make nested default groups lo ...
Hi all,
The following patches fix lockdep warnings resulting from (correct) recursive
locking in configfs.
Current lockdep annotations for inode mutexes in configfs are lockdep-friendly
provided that:
1/ config_groups have at most one level of default groups (see
configfs_attach_group()),
2/ config_groups having default groups are never removed (see
configfs_detach_prep()).
Since lockdep does not handle such correct recursion, the idea is to insert
lockdep_off()/lockdep_on() for ...
| May 20, 9:33 am 2008 |
| Louis Rilling | Re: [RFC][PATCH 0/3] configfs: Make nested default group ...
Hmm, to me there are three solutions:
1/ keep lockdep and configfs like they are, and use this patchset
2/ enhance lockdep to handle wariable-depth but correct recursion:
seems uncertain...
3/ remove this recursive locking from configfs:
unfortunately, it seems that there are a good reasons for doing
recursive inode locking, at least when removing a config_group with
default groups. So, seems uncertain too...
Other ideas?
--
Dr Louis Rilling Kerlabs
Skype: ...
| May 20, 10:08 am 2008 |
| Joel Becker | Re: [RFC][PATCH 0/3] configfs: Make nested default group ...
We're trying to find it. I really appreciate Louis taking the
time to approach the issue. His first pass was to add 1 to MUTEX_CHILD
for each level of recursion. This has a very tight limit (4 or 5
levels), but probably covers all users that exist and perhaps all that
ever will exist. However, it means passing the lockdep annotation level
throughout the entire call chain across multiple files. It was
definitely less readable.
This approach takes a different tack - it's very readable, ...
| May 20, 2:56 pm 2008 |
| Arjan van de Ven | Re: [RFC][PATCH 0/3] configfs: Make nested default group ...
On Tue, 20 May 2008 14:56:39 -0700
you can also make a new lockdep key for each level... not pretty but it
works
--
| May 20, 3:13 pm 2008 |
| Louis Rilling | [RFC][PATCH 3/3] configfs: Silence lockdep when destroyi ...
When destroying a config_group having default groups, lockdep raises a warning
because multiple locks of class I_MUTEX_NORMAL are taken in
configfs_detach_prep() (the first one being in vfs_rmdir()). However this
recursive locking is another instance of I_MUTEX_PARENT -> I_MUTEX_CHILD
dependency, which was already checked correct when creating the config_group,
and which lockdep cannot handle cleanly because of the variable depth.
This patch silences lockdep when destroying default groups by ...
| May 20, 9:33 am 2008 |
| Louis Rilling | [RFC][PATCH 2/3] configfs: Silence lockdep when creating ...
When default groups are nested, lockdep raises a warning since it sees a
lock recursion of class I_MUTEX_CHILD in populate_groups().
However, this lock recursion is just a variant of the I_MUTEX_PARENT ->
I_MUTEX_CHILD dependency, which is ok in the VFS, and is already checked when
creating the first level of default groups.
This patch silences lockdep with nested default groups, by hiding the mutex
locks of populate_groups() from lockdep when the considered config_group is
itself a default ...
| May 20, 9:33 am 2008 |
| Louis Rilling | [RFC][PATCH 1/3] configfs: set CONFIGFS_USET_DEFAULT ear ...
When creating a config_group, the CONFIGFS_USET_DEFAULT flag of default
sub-groups is only known after create_default_group() finishes its work, that is
after having creating the whole sub-hierarchy. In order to track which lock to
hide from lockdep, we need to known whether a config_group is default earlier,
that is before creating the sub-hierarchy.
This patch adds a def_group flag to configfs_attach_group(), which allows
configfs_attach_group to set the CONFIGFS_USET_DEFAULT flag before ...
| May 20, 9:33 am 2008 |
| Stefan Richter | [GIT PULL] ieee1394 updates
Linus, please pull from the for-linus branch at
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-linus
to receive the following IEEE 1394/ FireWire subsystem updates.
Jay Fenlason (1):
firewire: prevent userspace from accessing shut down devices
Stefan Richter (1):
ieee1394: sbp2: use correct size of command descriptor block
drivers/firewire/fw-cdev.c | 14 ++++++++++++++
drivers/ieee1394/sbp2.c | 20 ++++++++------------
2 files ...
| May 20, 9:46 am 2008 |
| Cyrill Gorcunov | Re: [PATCH] eCryptFS: mutex lock-unlock ordering fix
[Cyrill Gorcunov - Tue, May 20, 2008 at 08:39:28PM +0400]
| We should lock/unlock mutexes by a proper way which means
| there should not be chains like ABAB but ABBA otherwise the
| race window is opened.
|
| Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
| CC: Michael A. Halcrow <mhalcrow@us.ibm.com>
| ---
|
| check_list:
[...]
| if (list_empty(&daemon->msg_ctx_out_queue)) {
NIT ---> | + if (mutex_is_locked(&ecryptfs_daemon_hash_mux))
| ...
| May 20, 9:42 am 2008 |
| Cyrill Gorcunov | [PATCH] eCryptFS: mutex lock-unlock ordering fix
We should lock/unlock mutexes by a proper way which means
there should not be chains like ABAB but ABBA otherwise the
race window is opened.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
CC: Michael A. Halcrow <mhalcrow@us.ibm.com>
---
Michael, could you test it please? To be honest I see that
my patch makes source looks ugly unfirtunelly... thoughts?
Any comments are welcome. Maybe I missed something - but I think
the chain LOCK: hash_mux -> mux, UNLOCK: hash_mux -> mux is a ...
| May 20, 9:39 am 2008 |
| 廖泓恭 | 來個激情的擁抱吧!!
您2008想5給21心愛的另ㄧ半ㄧ份21驚5喜2008嗎?
近31來31看31看,試31試31這31個31喔 ^.^
珍9珠9貝9殼9項9鍊9禮9盒 ~ 日9本9九9州9空9運9來9台
網址在這→203.70.179.39/ju←複製這行網址貼上即可
◇▼↖⊙↑
| May 20, 9:31 am 2008 |
| Mel Gorman | [PATCH 2/3] Reserve huge pages for reliable MAP_PRIVATE ...
This patch reserves huge pages at mmap() time for MAP_PRIVATE mappings in a
similar manner to the reservations taken for MAP_SHARED mappings. The reserve count is
accounted both globally and on a per-VMA basis for private mappings. This
guarantees that a process that successfully calls mmap() will successfully
fault all pages in the future unless fork() is called.
The characteristics of private mappings of hugetlbfs files behaviour after
this patch are;
1. The process calling mmap() is ...
| May 20, 9:29 am 2008 |
| Mel Gorman | [PATCH 3/3] Guarantee that COW faults for a process that ...
After patch 2 in this series, a process that successfully calls mmap()
for a MAP_PRIVATE mapping will be guaranteed to successfully fault until a
process calls fork(). At that point, the next write fault from the parent
could fail due to COW if the child still has a reference.
We only reserve pages for the parent but a copy must be made to avoid leaking
data from the parent to the child after fork(). Reserves could be taken for
both parent and child at fork time to guarantee faults but if the ...
| May 20, 9:29 am 2008 |
| Mel Gorman | [PATCH 1/3] Move hugetlb_acct_memory()
A later patch in this set needs to call hugetlb_acct_memory() before it
is defined. This patch moves the function without modification. This makes
later diffs easier to read.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---
mm/hugetlb.c | 82 +++++++++++++++++++++++++++---------------------------
1 file changed, 41 insertions(+), 41 deletions(-)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.26-rc2-mm1-clean/mm/hugetlb.c ...
| May 20, 9:29 am 2008 |
| Mel Gorman | [PATCH 0/3] Guarantee faults for processes that call mma ...
This release is mainly a rebase. Ideally, this would be reviewed from
the perspective of "is this desirable and useful behaviour for hugepage
applications" as well as general correctness. If reactions are positive
or there are no objections, I'll attempt a push towards -mm for wider
testing. As it is, they are passing basic tests as well as a slightly-modified
libhugetlbfs regression test.
Changelog since V2
o Rebase to 2.6.26-rc2-mm1
o Document when hugetlb_lock is held for reserve counter ...
| May 20, 9:28 am 2008 |
| Takashi Iwai | [GIT PULL] ALSA fixes #2 for 2.6.26-rc3
Hi Linus,
please pull ALSA updates for 2.6.26-rc3 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git for-linus
This contains another snd-pcsp fix slipped from the last pull request,
and two trivial fixes for specific HD-audio models.
Thanks!
Takashi
===
Stas Sergeev (1):
snd-pcsp: use HRTIMER_CB_SOFTIRQ
Takashi Iwai (1):
[ALSA] hda - Fix ALC262 fujitsu model
Travis Place (1):
[ALSA] hda - Fix ASUS P5GD1 model
...
| May 20, 8:33 am 2008 |
| Ingo Molnar | [patch] fix build error in drivers/media/video/cx23885/c ...
testing of the -tip tree found the following module build failure on
latest -git:
Building modules, stage 2.
MODPOST 421 modules
ERROR: "dib7000p_attach" [drivers/media/video/cx23885/cx23885.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
with the following config:
http://redhat.com/~mingo/misc/config-Tue_May_20_17_13_32_CEST_2008.bad
the problem is caused that ./drivers/media/video/cx23885/cx23885-dvb.c
depends on a DVB_DIB7000P ...
| May 20, 8:32 am 2008 |
| mkrufky | Re: [patch] fix build error in drivers/media/video/cx238 ...
Please see below, proper patch attached...
Ingo,
Your patch will work around a symptom of the problem, but this is not
the proper fix.
Please see the attached patch, which should be applied, instead.
Thanks for pointing this out.
Regards,
Mike Krufky
| May 20, 9:16 am 2008 |
| Andi Kleen | [PATCH] [2/11] Add unlocked_fasync
Add a new fops entry point to allow fasync without BKL. While it's arguably
unclear this entry point is called often enough for it really matters
it was still relatively easy to do. And there are far less async users
in the tree than ioctls so it's likely they can be all converted
eventually and then the non unlocked async entry point could be dropped.
There was still the problem of the actual flags change being
protected against other setters of flags. Instead of using BKL
for this use the ...
| May 20, 8:28 am 2008 |
| Andi Kleen | [PATCH] [5/11] Convert fuse to unlocked_fasync
Cc: miklos@szeredi.hu
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
fs/fuse/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/fs/fuse/dev.c
===================================================================
--- linux.orig/fs/fuse/dev.c
+++ linux/fs/fuse/dev.c
@@ -1082,7 +1082,7 @@ const struct file_operations fuse_dev_op
.aio_write = fuse_dev_write,
.poll = fuse_dev_poll,
.release = ...
| May 20, 8:28 am 2008 |
| Andi Kleen | Re: [PATCH] [2/11] Add unlocked_fasync
That's the goal actually to "get stuck with it" and ->fasync going
away.
-Andi
--
| May 20, 11:59 am 2008 |
| Arjan van de Ven | Re: [PATCH] [2/11] Add unlocked_fasync
On Tue, 20 May 2008 17:28:43 +0200 (CEST)
I (again) really don't like having another entry point for this...
it'll stay around forever rather than doing this as one step and
move on.
--
| May 20, 8:58 am 2008 |
| Jonathan Corbet | Re: [PATCH] [2/11] Add unlocked_fasync
I guess my one concern with this mirrors what other people have said:
might not it be better to just push the BKL down into the fasync()
implementations and avoid adding yet another file operation? A quick
grep shows 43 drivers defining fasync() functions - and many of those
use the same one. fs/ has a few more. Obnoxious but doable, unless
there's something I'm missing?
Thanks,
jon
--
| May 20, 8:58 am 2008 |
| Andi Kleen | [PATCH] [4/11] Convert socket fasync to unlocked_fasync
Pretty sure the socket layer has no BKL requirements.
Cc: davem@davemloft.net
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
net/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/net/socket.c
===================================================================
--- linux.orig/net/socket.c
+++ linux/net/socket.c
@@ -134,7 +134,7 @@ static const struct file_operations sock
.mmap = sock_mmap,
.open ...
| May 20, 8:28 am 2008 |
| Andi Kleen | [PATCH] [10/11] Use unlocked_fasync in RTC
Just uses fasync_helper
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
drivers/char/rtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/drivers/char/rtc.c
===================================================================
--- linux.orig/drivers/char/rtc.c
+++ linux/drivers/char/rtc.c
@@ -913,7 +913,7 @@ static const struct file_operations rtc_
.ioctl = rtc_ioctl,
.open = rtc_open,
.release = rtc_release,
- .fasync = ...
| May 20, 8:28 am 2008 |
| Alan Cox | Re: [PATCH] [2/11] Add unlocked_fasync
On Tue, 20 May 2008 08:58:30 -0700
Agreed entirely - all our unlocked_foo methods we got stuck with, all our
push down everyone cases we got most cases promptly fixed and the other
lock/unlocks show up clearly in grep and help embarass the
maintainer/author 8)
--
| May 20, 11:33 am 2008 |
| Andi Kleen | [PATCH] [0/11] REPOST: Early exception fixes
Mostly saves some code size and cleans up the code after Roland's
recent changes.
Please ack or nack.
-Andi
--
| May 20, 8:28 am 2008 |
| Andi Kleen | [PATCH] [9/11] Convert hpet to unlocked_fasync
Just calls fasync_helper and private structure is protected by
file reference count.
Cc: clemens@ladisch.de
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
drivers/char/hpet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/drivers/char/hpet.c
===================================================================
--- linux.orig/drivers/char/hpet.c
+++ linux/drivers/char/hpet.c
@@ -585,7 +585,7 @@ static const struct file_operations hpet
.ioctl = ...
| May 20, 8:28 am 2008 |
| Andi Kleen | Re: [PATCH] [2/11] Add unlocked_fasync
See my reply to Arjan. While for complicated stuff pushing down first
is better, fasync is not that complicated and I think my strategy
with the new entry point, with the old one going away is better in this
case.
-Andi
--
| May 20, 11:31 am 2008 |
| Andi Kleen | [PATCH] [11/11] Convert uio to fasync_unlocked
Just calls fasync_helper
Cc: hjk@linutronix.de
---
drivers/uio/uio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/drivers/uio/uio.c
===================================================================
--- linux.orig/drivers/uio/uio.c
+++ linux/drivers/uio/uio.c
@@ -541,7 +541,7 @@ static const struct file_operations uio_
.read = uio_read,
.mmap = uio_mmap,
.poll = uio_poll,
- .fasync = uio_fasync,
+ .unlocked_fasync = uio_fasync,
};
static ...
| May 20, 8:28 am 2008 |
| Andi Kleen | Re: [PATCH] [2/11] Add unlocked_fasync
What do you find ugly exactly? The prefix "unlocked_" ? Other than
that there is no difference.
Duplicated entry points are not great, but they will be going away.
-Andi
--
| May 20, 4:35 pm 2008 |
| Andi Kleen | Re: [PATCH] [2/11] Add unlocked_fasync
Yes the goal is for it staying around forever, correct. And ->fasync()
will go instead.
Advantage is that out of tree drivers will be compile broken which I
consider an advantage. Yes I know Linus said earlier that's not
important to him, but in this case my standards are higher than his.
Also BTW if you're that worried about the audit not getting
finished then the result would be just that lots of lock_kernel()s
would stay around. Hardly better.
But cannot do that many drivers in one ...
| May 20, 11:30 am 2008 |
| Andi Kleen | [PATCH] [1/11] Remove BKL from remote_llseek v2
- Replace remote_llseek with generic_file_llseek_unlocked (to force compilation
failures in all users)
- Change all users to either use generic_file_llseek_unlocked directly or
take the BKL around. I changed the file systems who don't use the BKL
for anything (CIFS, GFS) to call it directly. NCPFS and SMBFS and NFS
take the BKL, but explicitely in their own source now.
I moved them all over in a single patch to avoid unbisectable sections.
Open problem: 32bit kernels can corrupt fpos ...
| May 20, 8:28 am 2008 |
| Arjan van de Ven | Re: [PATCH] [2/11] Add unlocked_fasync
On Tue, 20 May 2008 20:30:06 +0200
I'd say it's just different standards.
My concern is that the new API as long lived is ugly and not the right
thing. I assume Linus and others have similar concerns, and weigh that
over the "some obscure out of tree driver might break".
--
| May 20, 1:06 pm 2008 |
| Andi Kleen | [PATCH] [7/11] Convert DRM to unlocked_fasync
Doesn't need BKL because it just uses fasync_helper and minor->dev is
protected by the file reference count.
Cc: airlied@linux.ie
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
drivers/char/drm/i810_dma.c | 2 +-
drivers/char/drm/i810_drv.c | 2 +-
drivers/char/drm/i830_dma.c | 2 +-
drivers/char/drm/i830_drv.c | 2 +-
drivers/char/drm/i915_drv.c | 2 +-
drivers/char/drm/mga_drv.c | 2 +-
drivers/char/drm/r128_drv.c | 2 +-
...
| May 20, 8:28 am 2008 |
| Randy Dunlap | Re: [PATCH] [2/11] Add unlocked_fasync
BKL held.
so is that BKL must be held by the caller or this function
---
~Randy
--
| May 20, 8:58 am 2008 |
| Andi Kleen | [PATCH] [8/11] Use unlocked_fasync in random.c
Just uses fasync_helper which does its own locking
Cc: mpm@selenic.com
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
drivers/char/random.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux/drivers/char/random.c
===================================================================
--- linux.orig/drivers/char/random.c
+++ linux/drivers/char/random.c
@@ -1121,7 +1121,7 @@ const struct file_operations random_fops
.write = random_write,
.poll = ...
| May 20, 8:28 am 2008 |
| Andi Kleen | [PATCH] [3/11] Convert pipe over to unlocked_fasync
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
fs/pipe.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Index: linux/fs/pipe.c
===================================================================
--- linux.orig/fs/pipe.c
+++ linux/fs/pipe.c
@@ -787,7 +787,7 @@ const struct file_operations read_fifo_f
.unlocked_ioctl = pipe_ioctl,
.open = pipe_read_open,
.release = pipe_read_release,
- .fasync = ...
| May 20, 8:28 am 2008 |
| Andi Kleen | [PATCH] [6/11] Convert bad_inode to unlocked_fasync
Not that it matters much, but it was easy.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
fs/bad_inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/fs/bad_inode.c
===================================================================
--- linux.orig/fs/bad_inode.c
+++ linux/fs/bad_inode.c
@@ -174,7 +174,7 @@ static const struct file_operations bad_
.release = bad_file_release,
.fsync = bad_file_fsync,
...
| May 20, 8:28 am 2008 |
| Gregory Haskins | [PATCH 3/5] rtmutex: use task->oncpu to save a call
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
---
kernel/rtmutex.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index 8ae9de3..b6ff1eb 100644
--- a/kernel/rtmutex.c
+++ b/kernel/rtmutex.c
@@ -738,7 +738,7 @@ static int adaptive_wait(struct rt_mutex_waiter *waiter,
}
/* Owner went to bed, so should we */
- if (!task_is_current(orig_owner)) {
+ if (!orig_owner->oncpu) {
sleep = 1;
...
| May 20, 7:49 am 2008 |
| Gregory Haskins | [PATCH 0/5] RT: adaptive-lock enhancements
Hi Ingo, Steven, Thomas,
The following series are the scraps from adaptive-locks-v3 that have not yet
been pulled into RT. This series applies to 25.4-rt2.
For the most part, this is the difference between adaptive-v3 and whats in
the upstream tree, with the following exceptions:
1) I have fixed an issue in the "optimize-wakeup" patch that went out in v3.
There was a hunk left-over from when we applied adaptive to both spinlocks
and mutexes. We have since dropped ...
| May 20, 7:49 am 2008 |
| Gregory Haskins | [PATCH 2/5] sched: make task->oncpu available in all con ...
We will use this later in the series to eliminate the need for a function
call.
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
---
include/linux/sched.h | 2 --
kernel/sched.c | 35 ++++++++++++++++++++++++-----------
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index ec94970..70175e0 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1080,10 +1080,8 @@ struct task_struct {
int ...
| May 20, 7:49 am 2008 |
| Gregory Haskins | [PATCH 5/5] remove the extra call to try_to_take_lock
From: Peter W. Morreale <pmorreale@novell.com>
Remove the redundant attempt to get the lock. While it is true that the
exit path with this patch adds an un-necessary xchg (in the event the
lock is granted without further traversal in the loop) experimentation
shows that we almost never encounter this situation.
Signed-off-by: Peter W. Morreale <pmorreale@novell.com>
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
---
kernel/rtmutex.c | 6 ------
1 files changed, 0 insertions(+), ...
| May 20, 7:49 am 2008 |
| Gregory Haskins | [PATCH 4/5] adjust pi_lock usage in wakeup
From: Peter W.Morreale <pmorreale@novell.com>
In wakeup_next_waiter(), we take the pi_lock, and then find out whether
we have another waiter to add to the pending owner. We can reduce
contention on the pi_lock for the pending owner if we first obtain the
pointer to the next waiter outside of the pi_lock.
Signed-off-by: Peter W. Morreale <pmorreale@novell.com>
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
---
kernel/rtmutex.c | 14 +++++++++-----
1 files changed, 9 ...
| May 20, 7:49 am 2008 |
| Gregory Haskins | [PATCH 1/5] optimize rt lock wakeup
It is redundant to wake the grantee task if it is already running, and
the call to wake_up_process is relatively expensive. If we can safely
skip it we can measurably improve the performance of the adaptive-locks.
Credit goes to Peter Morreale for the general idea.
Signed-off-by: Gregory Haskins <ghaskins@novell.com>
Signed-off-by: Peter Morreale <pmorreale@novell.com>
---
kernel/rtmutex.c | 45 ++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 40 insertions(+), 5 ...
| May 20, 7:49 am 2008 |
| Pavel Machek | Unify common parts of i8259.c
Merge common parts of i8259_{32,64} into i8259.c.
Signed-off-by: Pavel Machek <pavel@suse.cz>
---
commit 4544eda7dd9bc73061bc308130ed03e8b81f4f61
tree 6a4adc5a6661136352f6ff362d9574142ab0c246
parent 3576982b19d0fbd81f8d31d0475bf7b374010cb5
author Pavel <pavel@amd.ucw.cz> Tue, 20 May 2008 17:14:29 +0200
committer Pavel <pavel@amd.ucw.cz> Tue, 20 May 2008 17:14:29 +0200
arch/x86/kernel/Makefile | 2
arch/x86/kernel/i8259.c | 323 +++++++++++++++++++++++++++++++++++++++++++
...
| May 20, 8:15 am 2008 |
| Pavel Machek | Re: Unify common parts of i8259.c
Yes, it should have been mechanic, but I guess I was not careful
I don't think I can split it into 20 changes, but I should be able to
split it into 3 or so, and make them trivial enough to be bug
free. (In fact, there were only about 20 lines of "real" changes in
in this huge changelog). I'll produce better patches.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| May 20, 3:35 pm 2008 |
| Ingo Molnar | Re: Unify common parts of i8259.c
hm, did you intend this to be a 'mechanic' (i.e. no functionality
changes expected) unification?
i stuck it into -tip for testing and it caused a boot failure after a
couple of bootups, with this config:
http://redhat.com/~mingo/misc/config-Tue_May_20_22_15_40_CEST_2008.bad
the hang is during early bootup, after SLUB init:
SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ hard hang ]
full bootlog below. Reverting your patch fixes the bootup. The next ...
| May 20, 1:47 pm 2008 |
| Jeremy Fitzhardinge | Getting WARN_ON in hres_timers_resume after Xen resume
I'm implementing suspend/resume for Xen at the moment. It's all going
well, but I'm getting this WARN_ON:
------------[ cut here ]------------
WARNING: at /home/jeremy/hg/xen/paravirt/linux/kernel/hrtimer.c:635 hres_timers_resume+0x33/0x56()
Modules linked in:
Pid: 1397, comm: kstopmachine Tainted: G W 2.6.26-rc2-sched-devel.git #94
[<c102e87d>] warn_on_slowpath+0x41/0x5d
[<c10477a1>] ? clockevents_program_event+0x105/0x10d
[<c1047dd3>] ? tick_resume+0x5c/0x61
[<c100145d>] ? ...
| May 20, 7:54 am 2008 |
| Rune Torgersen | Broken highmem support with preempt-rt
Hi
When booting v2.6.25.4-rt1 (PREEMPT-RT) on my 8280 CPU with 1 GB RAM, I
get the following oopses.
They both are caused by a BUG_ON in kmap_atomic
(include/asm-powerpc/highmem.h).
If I boot with mem=512M or mem=768M they do not appear.
Any help is greatly appreciated.
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT Innovative Systems ApMax
Modules linked in:
NIP: c005e780 LR: c005e758 CTR: 00000000
REGS: ef2c1d20 TRAP: 0700 Not tainted (2.6.25.4-rt1)
MSR: 00029032 ...
| May 20, 7:48 am 2008 |
| Rune Torgersen | RE: Oops in fs_enet driver with preempt-rt
Working on it.
--
| May 20, 11:53 am 2008 |
| Rune Torgersen | RE: Oops in fs_enet driver with preempt-rt
Hmm.... ttyCPM1 output seems to be kinda garbled... Any ideas?
Incomplete locking between printk and userland use of ttyCPM1 as
console?
kjour[ OK ] nal
stdrtiag. nCom it mnteivalr5 s cones
dXT3EFS n soa7,dint rnae jolrnau
ElT3-Xs: founmed tilefystsm weth irdeoed ratadmod .
ek/* [ Removing /var/run/* and /var/locp... [ OK ]
Creating new /var/run/utmlogin /fastboot and /forcefsck... OK ]
Removing possible /etc/noBringing up the loopback interface... [ OK ]
OK ]
OK ] ...
| May 20, 9:14 am 2008 |
| Rune Torgersen | RE: Oops in fs_enet driver with preempt-rt
That worked. Console output is sane again.
--
| May 20, 9:31 am 2008 |
| Scott Wood | Re: Oops in fs_enet driver with preempt-rt
Do you have shared interrupt debugging turned on? That breaks this
driver, and a patch to remove the shared flag was nacked in favor of
actually fixing the driver, which I haven't gotten around to.
-Scott
--
| May 20, 8:41 am 2008 |
| Rune Torgersen | RE: Oops in fs_enet driver with preempt-rt
Thanks!!
That worked. Now I just have to get highmem support...
--
| May 20, 9:08 am 2008 |
| Scott Wood | Re: Oops in fs_enet driver with preempt-rt
s/incomplete/nonexistent/ :-P
Try acquiring port->lock in cpm_uart_console_write.
-Scott
--
| May 20, 9:21 am 2008 |
| Kumar Gala | Re: Oops in fs_enet driver with preempt-rt
I'm hoping to see some patches related to these fixes :)
- k
--
| May 20, 10:33 am 2008 |
| Rune Torgersen | Oops in fs_enet driver with preempt-rt
Hi
I am trying to get preempt-rt (v2.6.25.4-rt1) to work on a Freescale
8280 CPU (arch/powerpc)
I get the follwing oops when trying to enable ethernet:
(looks like a null pointer dereference in
drivers/net/fs_enet/fs_enet-main.c:106)
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0197efc
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT Innovative Systems ApMax
Modules linked in:
NIP: c0197efc LR: c0197c48 CTR: c01986c4
REGS: ...
| May 20, 7:40 am 2008 |
| Rune Torgersen | RE: Oops in fs_enet driver with preempt-rt
And if I disable NAPI I get this one instead:
Bringing up the eth1 interface...Unable to handle kernel paging request
for data at address 0x00000000
Faulting instruction address: 0xc019706c
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT Innovative Systems ApMax
Modules linked in:
NIP: c019706c LR: c0196d84 CTR: c0198790
REGS: ef2c3cb0 TRAP: 0300 Not tainted (2.6.25.4-rt1)
MSR: 00009032 <EE,ME,IR,DR> CR: 42004222 XER: 00000000
DAR: 00000000, DSISR: 20000000
TASK = ef2ac590[114] ...
| May 20, 7:53 am 2008 |
| Jiri Kosina | [GIT] HID fixes for 2.6.26-rc4
Linus,
could you please pull from 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
or
master.kernel.org:/pub/scm/linux/kernel/git/jikos/hid.git for-linus
to receive fixes for 2.6.26-rc4. It contains a few blacklist additions,
comment cleanup patch from Adrian and regression fix for numlock on
apple_pb. Thanks.
drivers/hid/hid-debug.c | 2 -
drivers/hid/hid-input.c | 7 ++---
...
| May 20, 7:30 am 2008 |
| Michael Kerrisk | Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem
Hello Nadia,
Regarding your:
[PATCH 1/8] Scaling msgmni to the amount of lowmem
http://article.gmane.org/gmane.linux.kernel/637849/
which I see has made its way in 2.6.26-rc
Your patch has the following change:
-#define MSGPOOL (MSGMNI*MSGMNB/1024) /* size in kilobytes of message pool */
+#define MSGPOOL (MSGMNI * MSGMNB) /* size in bytes of message pool */
Since this constitutes a kernel-userland interface change, so please
do CC me, so that I can change the man pages if ...
| May 20, 7:28 am 2008 |
| Nadia Derbey | Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem
No, that was the only reason.
Should I repost a patch to set it back as it used to be?
Regards
Nadia
--
| May 20, 7:45 am 2008 |
| Michael Kerrisk | Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem
[Fixing the bad list address in my initial mail: CC += linux-mm@kvack.org]
On the one hand, I'd be inclined to leave things as they were pre
2.6.26. On the other hand, I believe that on other systems that have
the limit, msgpool is a limit in bytes. (But documentation of these
details on other systems is very thin on the ground.) I wonder if
anyone else has some knowledge here?
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? ...
| May 20, 7:56 am 2008 |
| Pavel Machek | Re: aperture_64: use symbolic constants
Can you elaborate? Yes, it would be nicer if this went to .c
somewhere, but aperture_64.c seems unsuitable (we need it on 32-bit,
too, right?)... plus it was __init in one place, and __devinit in the
other, so I figured out "inline it so that it works automagically".
Plus, I don't think it should go into drivers/agp, as iommu code in
arch/x86/kernel seems to be able to work without that...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) ...
| May 20, 8:32 am 2008 |
| Dave Jones | Re: aperture_64: use symbolic constants
On Tue, May 20, 2008 at 04:27:17PM +0200, Pavel Machek wrote:
> +static inline int aperture_valid(u64 aper_base, u32 aper_size, u32 min_size)
> +{
> + if (!aper_base)
> + return 0;
> +
> + if (aper_base + aper_size > 0x100000000ULL) {
> + printk(KERN_ERR "Aperture beyond 4GB. Ignoring.\n");
> + return 0;
> + }
> + if (e820_any_mapped(aper_base, aper_base + aper_size, E820_RAM)) {
> + printk(KERN_ERR "Aperture pointing to e820 RAM. Ignoring.\n");
> + return 0;
> + }
> ...
| May 20, 8:06 am 2008 |
| Pavel Machek | Re: aperture_64: use symbolic constants
Thanks, I have a copy now. And this one is relative to it:
---
Factor-out common aperture_valid code.
Signed-off-by: Pavel Machek <pavel@suse.cz>
diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index 02f4dba..5373f78 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -109,27 +109,6 @@ static u32 __init allocate_aperture(void
return (u32)__pa(p);
}
-static int __init aperture_valid(u64 aper_base, u32 aper_size, u32 ...
| May 20, 7:27 am 2008 |
| Dave Jones | Re: aperture_64: use symbolic constants
On Tue, May 20, 2008 at 05:32:15PM +0200, Pavel Machek wrote:
> > Instead of making this an inline, we could add it to the agpgart code
> > and export it, and have the gart-iommu code call it.
> > You can't build the IOMMU code without agpgart anyway, and having this inlined
> > in both places seems a bit wasteful.
> > Additionally, it would mean not having a function in a header file,
> > which always strikes me as a wrong thing to do.
>
> Can you elaborate? Yes, it would be nicer if ...
| May 20, 8:42 am 2008 |
| Ingo Molnar | Re: aperture_64: use symbolic constants
applied, thanks Pavel.
Ingo
--
| May 20, 8:42 am 2008 |
| Robert Schwebel | Re: 2.6.25.4-rt2 compile errors on ARM due to cmpxchg() ...
Hi Steven,
If you need an ARM cross compiler, you can for example use ptxdist to
setup an OSELAS.Toolchain:
http://www.pengutronix.de/oselas/toolchain/index_en.html
The current well tested revisions are based on 4.1.2, but -trunk does
also contain (work-in-progress) top-of-tree versions.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. ...
| May 20, 12:11 pm 2008 |
| Remy Bohmer | 2.6.25.4-rt2 compile errors on ARM due to cmpxchg() problems.
Hello Steven,
I want to test 2.6.25.4-rt2 on ARM, but unfortunately I run into
several compile errors.
All errors seem to be related to cmpxchg routines -> duplicate
definitions or missing BUILD_BUG_ON() or typecheck() macros.
I already figured out the missing BUILD_BUG_ON() + typecheck() problem
which is caused by including a header
'include/asm-generic/cmpxchg-local.h' in linux/kernel.h before these
macros are defined in linux/kernel.h. See below for a piece/snippet of
the compiler ...
| May 20, 7:21 am 2008 |
| Steven Rostedt | Re: 2.6.25.4-rt2 compile errors on ARM due to cmpxchg() ...
No idea right off the bat. But I may be needing to set up a ARM
crosscompiler. Unless Thomas would like to take a look into this.
Thomas?
-- Steve
--
| May 20, 7:34 am 2008 |
| Remy Bohmer | Re: 2.6.25.4-rt2 compile errors on ARM due to cmpxchg() ...
Hello All,
In that case, here are my 2 cents ;-)))
If you do not want to bother building a compiler toolchain and just
want to have a compiler very quickly, you can also download the
precompiled Codesourcery compiler toolchain for ARM for free...
http://www.codesourcery.com/gnu_toolchains/arm/download.html
They provide toolchains for PowerPC and MIPS too...
(Always handy for cross compile checks)
Kind Regards,
Remy
--
| May 20, 12:25 pm 2008 |
| Philippe De Muyter | Re: powerpc + i2c/rtc : where is the 11 min update ?
CCing lkml
Thanks. I agree that is a good place.
But, here CONFIG_GENERIC_CMOS_UPDATE is defined and an i2c clock also,
and my rtc clock is not updated. I see kernel/time/ntp.c::sync_cmos_clock
calling arch/powerpc/kernel/time.c::update_persistent_clock, where
ppc_md.set_rtc_time is NULL.
Who is supposed to initialize ppc_md.set_rtc_time to use an i2c clock and
when in the boot process may that happen ?
Or alternatively, should update_persistent_clock not be part of the ...
| May 20, 7:07 am 2008 |
| Alan Cox | Re: [BISECTED] pata_jmicron: no drives found on post 2.6 ...
The PCIE ASM stuff is experimental and for good reason it appears.
Not an ATA layer bug - a PCIE one so once the PCIE folks fix their stuff
hopefully it'll magically start working.
--
| May 20, 7:13 am 2008 |
| Arjan van de Ven | PATCH] Replace a printk + WARN_ON() to a WARN()
From: Arjan van de Ven <arjan@linux.intel.com>
Subject: [PATCH] Replace a printk + WARN_ON() to a WARN()
Replace a printk+WARN_ON() by a WARN(); this increases the
chance of the string making it into the bugreport
(eg it goes inside the ---[ cute here ]--- section)
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
kernel/irq/manage.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 46d6611..e296f67 ...
| May 19, 8:41 pm 2008 |
| Arjan van de Ven | [PATCH] block: blk_queue_bounce_limits can actually sleep
From: Arjan van de Ven <arjan@linux.intel.com>
Subject: [PATCH] block: blk_queue_bounce_limits can actually sleep
blk_queue_bounce_limit can call init_emergency_isa_pool, which
does sleeping allocations... document it as such by adding might_sleep() to the driver
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
block/blk-settings.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/block/blk-settings.c b/block/blk-settings.c
index 8dd8641..c420a67 ...
| May 19, 8:24 pm 2008 |
| Jens Axboe | Re: [PATCH] block: blk_queue_bounce_limits can actually sleep
Isn't that superflous, as mempool_create() -> kmalloc(..., __GFP_WAIT)
ends up spewing that warning anyway?
--
Jens Axboe
--
| May 20, 12:29 pm 2008 |
| Arjan van de Ven | Re: [PATCH] block: blk_queue_bounce_limits can actually sleep
well either it sleeps or it doesn't.....
if this guy should sleep (and right now it does) we shouldn't call it
from such contexts.
If we do the right thing and allocate the isa pools in a sane context,
it wouldn't ever sleep and the patch isn't needed...
--
| May 20, 2:02 pm 2008 |
| Andrew Morton | Re: [PATCH] block: blk_queue_bounce_limits can actually sleep
On Tue, 20 May 2008 21:29:59 +0200
It's largely superfluous given the way in which Arjan implemented it.
One situation which we regularly hit is:
foo()
{
...
if (some_unlikely_condition())
do_something_which_sleeps();
...
}
and then we go and call that code under spinlock and ship it out, when
of course a handful of testers hit the unlikely condition.
The solution to that is to add a might_sleep() _outside_ the test of
some_unlikely_condition(). ie:
--- ...
| May 20, 12:45 pm 2008 |
| Jens Axboe | Re: [PATCH] block: blk_queue_bounce_limits can actually sleep
Yeah, THAT I agree with in general, but it's probably too much here
since most callers will not block and probably do call it under the
Probably the math still isn't quite correct, so it ends up setting up
the isa pool for no good reason :-(
--
Jens Axboe
--
| May 20, 12:58 pm 2008 |
| Arjan van de Ven | Re: [PATCH] block: blk_queue_bounce_limits can actually sleep
On Tue, 20 May 2008 12:45:56 -0700
the sata_nv driver calls this from an invalid context ... and spews a
ton of warnings as a result... made me think this is a common mistake
to make.
I'd love to make it do your version instead, but I was afraid it would
trigger too often....
--
| May 20, 1:03 pm 2008 |
| Arjan van de Ven | [PATCH] serial: fix enable_irq_wake/disable_irq_wake imb ...
From: Arjan van de Ven <arjan@linux.intel.com>
Subject: [PATCH] serial: fix enable_irq_wake/disable_irq_wake imbalance in serial_core.c
enable_irq_wake() and disable_irq_wake() need to be balanced.
However, serial_core.c calls these for different conditions during
the suspend and resume functions...
This is causing a regular WARN_ON() as found at
http://www.kerneloops.org/search.php?search=set_irq_wake
This patch makes the conditions for triggering the _wake
enable/disable sequence ...
| May 19, 8:11 pm 2008 |
| Maciej W. Rozycki | Re: PIIX4 DMA Timeout
It looks like some problem with interrupt routing. At least with some of
the PIIX chips I recall there was some limitation about how the IDE
interrupts had to be used for DMA to be operational. For PIO modes there
were no restrictions. Do you have chip-level documentation for your
board?
Maciej
--
| May 20, 9:53 am 2008 |
| Gavin Shan | PIIX4 DMA Timeout
Hi All,
There has one MV64460 on my board, which includes 2 PCI bridges. PIIX4 is on slot 3 of PCI1.
But now, IDE driver reported it's timeouted on DMA operation. Thanks in advance for your
suggestions.
Resources of PIIX4 function 1
=====================
0001:00:03.1: idx=0 flags=0x20000110 start=0x00000000 end=0x00000007
0001:00:03.1: idx=1 flags=0x20000110 start=0x00000000 end=0x00000000
0001:00:03.1: idx=2 flags=0x20000110 start=0x00000000 end=0x00000007
0001:00:03.1: idx=3 ...
| May 20, 6:04 am 2008 |
| Lukas Hejtmanek | (No subject)
<stern@rowland.harvard.edu>, Greg KH <greg@kroah.com>
Bcc:
Subject: Re: [Bug #10630] USB devices plugged into dock are not discoverred
until reload of ehci-hcd
Reply-To:
In-Reply-To: <200805201327.34678.oliver@neukum.org>
X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb
Hm, without USB_SUSPEND it works. So what next, considered fixed or any
further investigation is needed?
--
Lukáš Hejtmánek
--
| May 20, 5:34 am 2008 |
| Lukas Hejtmanek | Re: [Bug #10630] USB devices plugged into dock are not d ...
Should I use USB_SUSPEND or not?
--
Lukáš Hejtmánek
--
| May 20, 7:11 am 2008 |
| Lukas Hejtmanek | Re: [Bug #10630] USB devices plugged into dock are not d ...
seems to be working, device is detected. Thanks. Please, push the patch.
--
Lukáš Hejtmánek
--
| May 20, 9:11 am 2008 |
| Alan Stern | Re: your mail
No further investigation is needed. I tried doing essentially the same
thing on my system and the same problem occurred.
It is caused by the way ehci-hcd "auto-clears" the port
change-suspend feature. This patch should fix the problem. Please
try it out and let us know if it works.
Alan Stern
Index: usb-2.6/drivers/usb/host/ehci.h
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci.h
+++ usb-2.6/drivers/usb/host/ehci.h
@@ ...
| May 20, 8:20 am 2008 |
| Oliver Neukum | Re:
It is by no means fixed!
Now we find out what exactly doesn't work. Please apply this patch
and provide "dmesg -c" before you plug in the device and after that.
Regards
Oliver
---
--- linux-2.6.25/drivers/usb/host/ehci-hcd.c 2008-05-20 10:07:45.585199135 +0200
+++ alt/drivers/usb/host/ehci-hcd.c 2008-05-20 11:11:53.614580823 +0200
@@ -712,11 +712,15 @@ static irqreturn_t ehci_irq (struct usb_
unsigned i = HCS_N_PORTS (ehci->hcs_params);
pcd_status = status;
...
| May 20, 5:40 am 2008 |
| Oliver Neukum | Re: [Bug #10630] USB devices plugged into dock are not d ...
Yes, use USB_SUSPEND.
Regards
Oliver
--
| May 20, 7:18 am 2008 |
| Gavin Shan | PIIX4 DMA Timeout
Hi All,
There has one MV64460 on my board, which includes 2 PCI bridges. PIIX4 is on slot 3 of PCI1.
But now, IDE driver reported it's timeouted on DMA operation. Thanks in advance for your
suggestions.
Resources of PIIX4 function 1
=====================
0001:00:03.1: idx=0 flags=0x20000110 start=0x00000000 end=0x00000007
0001:00:03.1: idx=1 flags=0x20000110 start=0x00000000 end=0x00000000
0001:00:03.1: idx=2 flags=0x20000110 start=0x00000000 end=0x00000007
0001:00:03.1: idx=3 ...
| May 20, 5:23 am 2008 |
| Hirokazu Takahashi | [PATCH 4/4] BIO tracking take2
Hi,
With this patch, dm-ioband can work with the bio cgroup.
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
diff -dupr linux-2.6.26-rc2.cg2/drivers/md/dm-ioband-type.c linux-2.6.26-rc2/drivers/md/dm-ioband-type.c
--- linux-2.6.26-rc2.cg2/drivers/md/dm-ioband-type.c 2008-05-19 13:51:23.000000000 +0900
+++ linux-2.6.26-rc2/drivers/md/dm-ioband-type.c 2008-05-19 18:40:10.000000000 +0900
@@ -6,6 +6,7 @@
* This file is released under the GPL.
*/
#include ...
| May 20, 5:04 am 2008 |
| Hirokazu Takahashi | [PATCH 2/4] BIO tracking take2
Hi,
This patch is for cleaning up the code of the cgroup memory subsystem
to remove a lot of "#ifdef"s.
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
diff -dupr linux-2.6.26-rc2.cg1/mm/memcontrol.c linux-2.6.26-rc2/mm/memcontrol.c
--- linux-2.6.26-rc2.cg1/mm/memcontrol.c 2008-05-19 12:33:32.000000000 +0900
+++ linux-2.6.26-rc2/mm/memcontrol.c 2008-05-19 12:34:16.000000000 +0900
@@ -228,6 +228,47 @@ struct mem_cgroup *mem_cgroup_from_task(
struct mem_cgroup, css);
}
...
| May 20, 5:02 am 2008 |
| Hirokazu Takahashi | [PATCH 1/4] BIO tracking take2
Hi,
This patch splits the cgroup memory subsystem into two parts.
One is for tracking pages to find out the owners. The other is
for controlling how much amount of memory should be assigned to
each cgroup.
With this patch, you can use the page tracking mechanism even if
the memory subsystem is off.
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
diff -udpr linux-2.6.26-rc2.cg0/include/linux/memcontrol.h linux-2.6.26-rc2/include/linux/memcontrol.h
--- ...
| May 20, 5:02 am 2008 |
| Hirokazu Takahashi | [PATCH O/4] BIO tracking take2
Hi all,
With this series of patches, you can determine the owners of any
type of I/Os. I ported the previous version to linux-2.6.26-rc2-mm1.
This makes dm-ioband -- I/O bandwidth controller -- be able to control
the Block I/O bandwidths even when it accepts delayed write requests.
Dm-ioband can find the owner cgroup of each request.
It is also possible that OpenVz team and NEC Uchida-san team working on
the CFQ scheduler use this functionality to control asynchronous I/Os
with a little ...
| May 20, 4:59 am 2008 |
| Hirokazu Takahashi | [PATCH 3/4] BIO tracking take2
Hi,
This patch implements the bio cgroup on the memory cgroup.
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
diff -dupr linux-2.6.26-rc2.cg2/block/blk-ioc.c linux-2.6.26-rc2/block/blk-ioc.c
--- linux-2.6.26-rc2.cg2/block/blk-ioc.c 2008-05-19 13:51:22.000000000 +0900
+++ linux-2.6.26-rc2/block/blk-ioc.c 2008-05-19 18:40:10.000000000 +0900
@@ -84,24 +84,28 @@ void exit_io_context(void)
}
}
+void init_io_context(struct io_context *ioc)
+{
+ atomic_set(&ioc->refcount, ...
| May 20, 5:03 am 2008 |
| Alan Jenkins | Re: Loading DSDT from initrd, can it be done from grub i ...
Um, why? What stops you from reverting the offending commit?
Without further info, I'd assume the feature was removed on policy
grounds. I.e. it's not nice to be effectively patching the BIOS
yourself, and vendors have fixed most of their BIOS's / linux is
slightly more tolerant to broken ones. I don't know whats wrong with
reading files from the initrd.
Alan
--
| May 20, 4:58 am 2008 |
| Alan Jenkins | Re: Loading DSDT from initrd, can it be done from grub i ...
Mea cupla. Apologies if my tone was also inappropriate.
I saw a short question on an interesting subject, without a context to
suggest an ongoing
conversation. I would have saved myself some embarassment if I
remembered that linux really doesn't like in-kernel filesystem access; I
just didn't make the connection.
I guessed wrong, didn't see where you were coming from, and didn't take
the effort to resolve the SHA commit id. I literally don't have the
space for a checkout on my main ...
| May 20, 5:51 am 2008 |
| Gabriel C | May 20, 5:09 am 2008 | |
| David | Re: Loading DSDT from initrd, can it be done from grub i ...
Because doing it from grub (if possible) would allow custom DSDT's to be
loaded without patching the kernel (e.g. allows distro kernels to be used)
and without introducing code that opens files from kernel space and mucks
If you do not understand the issue at hand, why comment?
--
David Härdeman
--
| May 20, 5:20 am 2008 |
| Ingo Molnar | Re: [PATCH] Make LIST_POISON less deadly (v3)
looks good - thanks Avi - i've added your patch to the -tip tree. I have
opened a separate topic for it: tip/safe-poison-pointers. (because it
affects other architectures as well)
Ingo
--
| May 20, 4:55 am 2008 |
| Avi Kivity | Re: [PATCH] Make LIST_POISON less deadly (v3)
The poison code adds a large offset (>1MB) so we're safe here.
--
error compiling committee.c: too many arguments to function
--
| May 20, 8:17 am 2008 |
| Andi Kleen | Re: [PATCH] Make LIST_POISON less deadly (v3)
Don't make it exactly 0xffffc10000000000 but 0xffffc10000000000 + 0x1000000
or so, otherwise list_entry() users which subtract offsets would still
end up in user space and there might be actually something in there
by default.
-Andi
--
| May 20, 8:15 am 2008 |
| Avi Kivity | [PATCH] Make LIST_POISON less deadly (v3)
The list macros use LIST_POISON1 and LIST_POISON2 as undereferencable
pointers in order to trap erronous use of freed list_heads. Unfortunately
userspace can arrange for those pointers to actually be dereferencable,
potentially turning an oops to an expolit.
To avoid this allow architectures (currently x86_64 only) to override
the default values for these pointers with truly-undereferncable values.
This is easy on x86_64 as the virtual address space is large and contains
unmapped ...
| May 20, 4:39 am 2008 |
| Jeff Dike | Re: UML fails to locate address space
Looks right, and mmap_min_addr is in mainline, just with a value of
zero. So, it looks like the right thing to do is read the value of
/proc/sys/vm/mmap_min_addr and start bottom there.
Jeff
--
Work email - jdike at linux dot intel dot com
--
| May 20, 12:24 pm 2008 |
| linux-os (Dick Johnson) | Re: UML fails to locate address space
Yes, shouldn't be.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended ...
| May 20, 2:58 pm 2008 |
| Jeff Dike | Re: UML fails to locate address space
Yup.
Can you try three things:
check the maps file for any arbitrary process
(i.e. /proc/$$/maps) and see if there's anything mapped at 0
gdb UML, stop it at that mmap, check its maps file and see if
there's anything mapped at 0
send me a pointer to the patches that Ubuntu has applied on
top of the stock kernel - I'm suspicious that they special-cased page
zero in order to ensure that NULL pointer dereferences cause faults.
You can test this last theory by initializing bottom to 4096 ...
| May 20, 9:10 am 2008 |
| Tom Spink | Re: UML fails to locate address space
Attached. I guess the line of interest is:
mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = -1 EACCES (Permission
I gathered that much - I was just letting you know which test it was
Thanks!
--
Tom Spink
| May 20, 6:59 am 2008 |
| Tom Spink | UML fails to locate address space
Hi,
I've just recently pulled the latest GIT and compiled UML, however,
when I run it a message appears saying "Locating the top of the
address space... Address 0x0 no good?" and the program exits.
After some digging, it appears that page_ok is returning false when
checking 'bottom', in os_get_task_size
(arch/um/os-Linux/sys-i386/task_size.c:96). After running through
GDB, it seems that in line 31 of that file is where the segfault
occurs:
n = *address;
i.e. when trying to read from ...
| May 20, 4:08 am 2008 |
| Tom Spink | Re: UML fails to locate address space
I suspected this type of foul-play, and tried altering bottom to 1,
but this didn't work. So, I took out the page_ok test, and it
continued booting. So I went back, put the test back in and
incremented bottom until I got to 16. It worked at 16. :-)
Is this something that can be fixed, or would a config option be appropriate?
I am willing to blame Ubuntu, but unfortunately, I can't find an
--
Tom Spink
--
| May 20, 9:43 am 2008 |
| linux-os (Dick Johnson) | Re: UML fails to locate address space
Okay, then instead of putting a NULL in the "hint" to mmap() try
something else (0x1000?). That may help.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or ...
| May 20, 2:54 pm 2008 |
| Jeff Dike | Re: UML fails to locate address space
Looks OK, but I need a Signed-off-by.
Some style comments, which I can take care of if you don't feel like it:
there's only one use of PROC_MMAP_MIN_ADDR, so you might as
well inline the filename
the stat is unnecessary - open failing will tell you what you
need to know
the strtoul needs some error checking
I'd change the mmap_min_addr[8] to [sizeof("12345678")] to
make it clear what's expected to fit into it
On a less-stylistic note, this thing does have to work in the absence
of ...
| May 20, 2:27 pm 2008 |
| Jeff Dike | Re: UML fails to locate address space
The segfaults are on purpose - it will trap SIGSEGV and longjmp out of
the handler and mark the affected address as not-usable.
Jeff
--
Work email - jdike at linux dot intel dot com
--
| May 20, 6:52 am 2008 |
| Jeff Dike | Re: UML fails to locate address space
Heh, I guess they were also worried about up to 64K offsets off a NULL
This was done in order to remove config options. It might be
reasonable to effectively do what you did, and search for the lowest
https://wiki.ubuntu.com/KernelGitGuide lists a bunch of git repos.
Tell me which one applies to you and I'll take a look.
Jeff
--
Work email - jdike at linux dot intel dot com
--
| May 20, 10:56 am 2008 |
| Tom Spink | Re: UML fails to locate address space
Here's the new patch, with that size correction in. Does this look okay?
---
From: Tom Spink <tspink@gmail.com>
Date: Wed, 21 May 2008 00:53:54 +0100
Subject: [PATCH] Read the minimum mmap address from proc
This patch makes os_get_task_size read the minimum mmap address from the proc
entry on the host system, if available. If not, it resorts to manually
searching for the minimum mmap address by incrementally testing pages from
zero onwards.
Because the bottom of the address space ...
| May 20, 4:57 pm 2008 |
| Tom Spink | Re: UML fails to locate address space
I'm a hardy. I bet it's 893f802872c3.
--
Tom Spink
--
| May 20, 11:01 am 2008 |
| Jeff Dike | Re: UML fails to locate address space
We're operating from userspace here.
In any case, this hasn't happened with any kernel I've seen, but I'm
suspicious that Ubuntu has started treating page zero specially.
Jeff
--
Work email - jdike at linux dot intel dot com
--
| May 20, 10:35 am 2008 |
| Tom Spink | Re: UML fails to locate address space
I was re-writing the patch, but after reading over the function, is
the return value correct? I did a quick run through on paper about
what would happen if the (real) bottom = 5 and the (real) top = 15,
and the (initial) top = 20. So this is a size of 10 pages, which is
what the function should return... but:
top = 20, bottom = 5
test = 12
bottom = 12
(top - bottom) = 8
top = 20, bottom = 12
test = 16
top = 16
(top - bottom) = 4
top = 16, bottom = 12
test = 14
bottom = 14
(top - ...
| May 20, 3:03 pm 2008 |
| linux-os (Dick Johnson) | Re: UML fails to locate address space
Does this mean that I cannot mmap() address zero in the kernel
anymore? I should be able (in the kernel) read anything, and
then mmap() it to something usable in user-space. If address
zero is now artifically trapped there are problems being created
for no good reason at all.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The ...
| May 20, 8:22 am 2008 |
| Tom Spink | Re: UML fails to locate address space
Wuhoo.
tom@holly:~$ cat /proc/sys/vm/mmap_min_addr
65536
And this is what I did:
diff --git a/arch/um/os-Linux/sys-i386/task_size.c
b/arch/um/os-Linux/sys-i386/task_size.c
index ccb49b0..f5ece4b 100644
--- a/arch/um/os-Linux/sys-i386/task_size.c
+++ b/arch/um/os-Linux/sys-i386/task_size.c
@@ -1,10 +1,14 @@
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
+#include <fcntl.h>
+#include <unistd.h>
#include <sys/mman.h>
#include "longjmp.h"
#include ...
| May 20, 12:42 pm 2008 |
| Paul Mackerras | [git pull] Please pull powerpc.git merge branch
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a collection of small fixes and a defconfig update for
powerpc, plus an update to MAINTAINERS for the Cell port.
Thanks,
Paul.
MAINTAINERS | 23 ++-
arch/powerpc/boot/.gitignore | 8 -
arch/powerpc/boot/Makefile | 6 +
arch/powerpc/boot/dts/mpc8377_mds.dts | 18 ++
...
| May 20, 4:06 am 2008 |
| David | Loading DSDT from initrd, can it be done from grub instead?
In commit 9a9e0d685553af76cb6ae2af93cca4913e7fcd47 the
ACPI_CUSTOM_DSDT_INITRD option was removed.
I was wondering if it'd be feasible to hack grub to load a custom DSDT
instead (since grub can read filesystems) and then pass a pointer to a
memory location containing the DSDT to the kernel?
--
David Härdeman
--
| May 20, 3:10 am 2008 |
| Heiko Carstens | [PATCH] memory hotplug: fix early allocation handling
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Trying to add memory via add_memory() from within an initcall function
results in
bootmem alloc of 163840 bytes failed!
Kernel panic - not syncing: Out of memory
This is caused by zone_wait_table_init() which uses system_state to
decide if it should use the bootmem allocator or not.
When initcalls are handled the system_state is still SYSTEM_BOOTING
but the bootmem allocator doesn't work anymore. So the allocation
will fail.
To fix this ...
| May 20, 3:51 am 2008 |
| Andy Whitcroft | Re: [PATCH] memory hotplug: fix early allocation handling
It would be nice to be able to check that bootmem is enabled separatly
from whether slab is available, as I am sure there is a time where
neither is available during the change over. But the change looks
reasonable as we cannot use vmalloc until slab is working.
Reviewed-by: Andy Whitcroft <apw@shadowen.org>
-apw
--
| May 20, 7:48 am 2008 |
| Hans J. Koch | Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver
On Tue, May 20, 2008 at 07:51:32PM +0900, Magnus Damm wrote:
Uwe Kleine-Koenig already submitted such a framework:
http://lkml.org/lkml/2008/5/20/94
It's his third version, and it looks good. I presume you didn't know
about his work. The main difference is that he leaves interrupt handling
to platform code. That might look strange (it did to me first), but it
has the advantage that you can put hardware dependent stuff in your
board support (which depends on hardware anyway).
Could you ...
| May 20, 2:07 pm 2008 |
| Magnus Damm | [PATCH 03/03] sh: Export sh7343/sh7722/sh7723 VPU/VEU blocks
This patch exports the following SuperH hardware to user space:
sh7343: VPU
sh7722: VPU, VEU
sh7723: VPU, VEU, VEU
Signed-off-by: Magnus Damm <damm@igel.co.jp>
---
arch/sh/kernel/cpu/sh4a/setup-sh7343.c | 32 ++++++++++
arch/sh/kernel/cpu/sh4a/setup-sh7722.c | 63 +++++++++++++++++++++
arch/sh/kernel/cpu/sh4a/setup-sh7723.c | 94 ++++++++++++++++++++++++++++++++
3 files changed, 189 insertions(+)
--- 0001/arch/sh/kernel/cpu/sh4a/setup-sh7343.c
+++ ...
| May 20, 3:51 am 2008 |
| Magnus Damm | [PATCH 00/03][RFC] Reusable UIO Platform Driver
These patches implement a reusable UIO platform driver. This driver
can be used to export hardware to user space, as long as the device
is a) memory mapped and b) equipped with an unique IRQ.
The uio_platform driver gets all information through platform data,
including address window information and IRQ number. The driver also
supports assigning a contiguous piece of memory to each instance.
This may be useful when the exported hardware blocks can bus master
but requires physically contiguous ...
| May 20, 3:51 am 2008 |
| Magnus Damm | [PATCH 01/03] uio: Add enable_irq() callback
Add enable_irq() callback to struct uio_info. This callback is needed by
the uio_platform driver so interrupts can be enabled before blocking.
Signed-off-by: Magnus Damm <damm@igel.co.jp>
---
drivers/uio/uio.c | 6 ++++++
include/linux/uio_driver.h | 1 +
2 files changed, 7 insertions(+)
--- 0001/drivers/uio/uio.c
+++ work/drivers/uio/uio.c 2008-05-19 14:52:08.000000000 +0900
@@ -365,6 +365,9 @@ static unsigned int uio_poll(struct file
if (idev->info->irq == ...
| May 20, 3:51 am 2008 |
| Magnus Damm | [PATCH 02/03] uio: Add uio_platform driver
This patch implements a reusable UIO platform driver. Only memory mapped
hardware devices with unique IRQs are supported.
Signed-off-by: Magnus Damm <damm@igel.co.jp>
---
Tested using the VEU on a SuperH sh7722.
drivers/uio/Kconfig | 10 ++
drivers/uio/Makefile | 1
drivers/uio/uio_platform.c | 161 ++++++++++++++++++++++++++++++++++++++++++
include/linux/uio_platform.h | 10 ++
4 files changed, 182 insertions(+)
--- 0001/drivers/uio/Kconfig
+++ ...
| May 20, 3:51 am 2008 |
| Stephen Rothwell | linux-next: Tree for May 20
Hi all,
News:
Noone sceamed =3D> no more tarballs.
Changes since next-20080519:
New trees: trivial, cpufeq-current.
Changed trees: cpufeq changed remot branch name.
I reverted "PM: New suspend and hibernation callbacks for PCI bus type"
from the driver-core tree before it was merged at the authors request (it
needs conflict work).
The driver-core tree lost two conflicts but gained a build error.
The x86, pci and i2c trees lost their conflicts.
The cpufreq tree lost its ...
| May 20, 3:27 am 2008 |
| Kamalesh Babulal | [BUILD_FAILURE] linux-next: Tree for May 20 - build fail ...
Hi Stephen,
The next-20080520 kernel build fails on powerpc, when build the randconfig with
build error message
CC arch/powerpc/kernel/prom_init.o
CALL arch/powerpc/kernel/prom_init_check.sh
Error: External symbol 'kernstart_addr' referenced from prom_init.c
make[1]: *** [prom_init_check] Error 1
make: *** [arch/powerpc/kernel] Error 2
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
| May 20, 3:55 am 2008 |
| Michael Ellerman | Re: [BUILD_FAILURE] linux-next: Tree for May 20 - build ...
It's broken in upstream actually, for RELOCATABLE && FLATMEM.
Patch on the way.
cheers
--=20
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
| May 20, 5:44 am 2008 |
| Andy Whitcroft | [PATCH] zonelists: handle a node zonelist with no applic ...
When booting 2.6.26-rc3 on a multi-node x86_32 numa system we are seeing
panics when trying node local allocations:
BUG: unable to handle kernel NULL pointer dereference at 0000034c
IP: [<c1042507>] get_page_from_freelist+0x4a/0x18e
*pdpt = 00000000013a7001 *pde = 0000000000000000
Oops: 0000 [#1] SMP
Modules linked in:
Pid: 0, comm: swapper Not tainted (2.6.26-rc3-00003-g5abc28d #82)
EIP: 0060:[<c1042507>] EFLAGS: 00010282 CPU: 0
EIP is at get_page_from_freelist+0x4a/0x18e
EAX: ...
| May 20, 3:23 am 2008 |
| Marco Berizzi | Re: [IPSEC]: Use the correct ip_local_out function
Herbert,
many many thanks to you for fixing this bug.
I was going on with git bisect, but I was not
able anymore to reproduce the bug after four
git bisect step.
I'm going to apply immediately your patch to
2.6.25.4
Just for record, this is my last git bisect log:
root@Venus:/tmp/GIT/my2.6.25.y# git bisect log
git-bisect start
# good: [49914084e797530d9baaf51df9eda77babc98fa8] Linux 2.6.24
git-bisect good 49914084e797530d9baaf51df9eda77babc98fa8
# bad: ...
| May 20, 3:18 am 2008 |
| Jean Delvare | Re: Accelerometer, Gyros and ADC's etc within the kernel.
Hi Jonathan,
Bad idea. Grouping drivers by connectivity is almost always the wrong
thing to do, as it means that different persons will maintain them and
they have all chances to diverge. You really want to group drivers by
functionality. On top of that, I am busy enough maintaining the i2c
core and bus drivers without having more i2c device drivers added to my
Probably not the wisest choice, if nothing else, because the hwmon
maintainer is already overloaded. And I don't think that these ...
| May 20, 4:28 am 2008 |
| Jonathan Cameron | Accelerometer, Gyros and ADC's etc within the kernel.
This email is basically a request for opinions on how and where such sensors
should be integrated into the kernel.
To set the scene...
Increasing numbers of embedded devices are being supplied attached MEMS
devices (www.xbow.com imote2 etc). Along with more traditional sensors such
as ADC's not being used for hardware monitoring, these do not really
seem to
fit with in an particular subsystem of the kernel. A previous
discussion on
lkml in 2006 considered the accelerometers to be found ...
| May 20, 3:04 am 2008 |
| mark gross | Re: Accelerometer, Gyros and ADC's etc within the kernel.
FWIW: I have this device talking to a PIC-18 and pushing the results
over the serial port.
WRT linux support, I can't think of a generalized way to create a driver
that would be able to be used with this device in Linux. You need to
know witch IRQ line the DR line is connected too, and if you are
bit-banging the SPI data off the thing, then you need to know which
GPIO's of the host CPU you'll be using. If you have SPI hardware then
you need to know where to pull the data from. The problem ...
| May 20, 10:50 am 2008 |
| Hans J. Koch | Re: Accelerometer, Gyros and ADC's etc within the kernel.
100% ACK. And the functionality here is something like "industrial
control" or "automation I/O". If this sort of hardware appears as device
with mappable memory, we can handle it with UIO, but for SPI, I2C, USB,
serial, we should have a new subsystem. It should handle not only input,
but also similar output devices. It doesn't make sense to have ADCs in
Agreed, hwmon devices are not really tuned for maximum performance, for
example. Performance is often critical in automation control
This ...
| May 20, 2:40 pm 2008 |
| Andy Whitcroft | [PATCH 2/2] x86: cope with no remap space being allocate ...
When allocating the pgdat's for numa nodes on x86_32 we attempt to
place them in the numa remap space for that node. However should
the node not have any remap space allocated (such as due to having
non-ram pages in the remap location in the node) then we will
incorrectly place the pgdat at zero. Check we have remap available,
falling back to node 0 memory where we do not.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Acked-by: Mel Gorman <mel@csn.ul.ie>
---
arch/x86/mm/discontig_32.c ...
| May 20, 3:01 am 2008 |
| Andy Whitcroft | [PATCH 1/2] x86: reinstate numa remap for SPARSEMEM on x ...
Recent kernels have been panic'ing trying to allocate memory early in boot,
in __alloc_pages:
BUG: unable to handle kernel paging request at 00001568
IP: [<c10407b6>] __alloc_pages+0x33/0x2cc
*pdpt = 00000000013a5001 *pde = 0000000000000000
Oops: 0000 [#1] SMP
Modules linked in:
Pid: 1, comm: swapper Not tainted (2.6.25 #78)
EIP: 0060:[<c10407b6>] EFLAGS: 00010246 CPU: 0
EIP is at __alloc_pages+0x33/0x2cc
EAX: 00001564 EBX: 000412d0 ECX: 00001564 EDX: 000005c3
ESI: ...
| May 20, 3:01 am 2008 |
| Ingo Molnar | Re: [PATCH 0/2] panics booting NUMA SPARSEMEM on x86_32 NUMA
applied to -tip, thanks Andy.
Ingo
--
| May 20, 5:08 am 2008 |
| Andy Whitcroft | [PATCH 0/2] panics booting NUMA SPARSEMEM on x86_32 NUMA
We have been seeing panics booting NUMA SPARSEMEM kernels on x86_32
hardware, while trying to allocate node local memory in early boot.
These are caused by a miss-allocation of the node pgdat structures when
numa remap is disabled.
Following this email are two patches, the first reenables numa remap for
SPARSEMEM as the underlying bug has now been fixed. The second hardens
the pgdat allocation in the face of there being no numa remap for a
particular node (which may still occur).
-apw
--
| May 20, 3:00 am 2008 |
| Denis V. Lunev | [PATCH 3/4] modules: proper cleanup of kobject without C ...
kobject: '<NULL>' (ffffffffa0104050): is not initialized, yet kobject_put() is being called.
------------[ cut here ]------------
WARNING: at /home/den/src/linux-netns26/lib/kobject.c:583 kobject_put+0x53/0x55()
Modules linked in: ipv6 nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs ide_cd_mod cdrom button [last unloaded: pktgen]
comm: rmmod Tainted: G W 2.6.26-rc3 #585
Call Trace:
[<ffffffff802359ab>] warn_on_slowpath+0x58/0x7a
[<ffffffff80236aca>] ? printk+0x67/0x69
...
| May 20, 2:59 am 2008 |
| Robert Olsson | Re: [PATCH 2/4] pktgen: make sure that pktgen_thread_wor ...
Denis V. Lunev writes:
> static int kthread(void *_create)
> {
> ...
> if (!kthread_should_stop())
> pktgen_thread_worker();
> ...
> }
>
> and kthread_stop. If kthread_stop will be called _before_ the control
> goes inside pktgen_thread_worker you'll OOPS.
For some reason my tests survives here... but agree the completion syncing
gives better control.
Cheers
--ro
--
| May 20, 12:59 pm 2008 |
| Denis V. Lunev | [PATCH 4/4] flock: remove unused fields from file_lock_o ...
fl_insert and fl_remove are not used right now in the kernel. Remove them.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
---
fs/locks.c | 6 ------
include/linux/fs.h | 2 --
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 11dbf08..dce8c74 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -561,9 +561,6 @@ ...
| May 20, 2:59 am 2008 |
| Denis V. Lunev | [PATCH 1/4] proc: proc_get_inode should get module only once
Any file under /proc/net opened more than once leaked the refcounter
on the module it belongs to.
The problem is that module_get is called for each file opening while
module_put is called only when /proc inode is destroyed. So, lets put
module counter if we are dealing with already initialised inode.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Cc: David Miller <davem@davemloft.net>
Cc: Patrick McHardy <kaber@trash.net>
Acked-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: Robert Olsson ...
| May 20, 2:59 am 2008 |
| David Miller | Re: [PATCH 2/4] pktgen: make sure that pktgen_thread_wor ...
From: "Denis V. Lunev" <den@openvz.org>
Patch applied, thanks a lot Denis!
--
| May 20, 3:12 pm 2008 |
| Denis V. Lunev | Re: [PATCH 2/4] pktgen: make sure that pktgen_thread_wor ...
you can't. The idea is to have a checkpoint _before_ khread_stop.
Currently you have a race between
static int kthread(void *_create)
{
...
if (!kthread_should_stop())
pktgen_thread_worker();
...
}
and kthread_stop. If kthread_stop will be called _before_ the control
goes inside pktgen_thread_worker you'll OOPS.
Regards,
Den
--
| May 20, 11:43 am 2008 |
| Denis V. Lunev | [PATCH 2/4] pktgen: make sure that pktgen_thread_worker ...
The following courruption can happen during pktgen stop:
list_del corruption. prev->next should be ffff81007e8a5e70, but was 6b6b6b6b6b6b6b6b
kernel BUG at lib/list_debug.c:67!
:pktgen:pktgen_thread_worker+0x374/0x10b0
? autoremove_wake_function+0x0/0x40
? _spin_unlock_irqrestore+0x42/0x80
? :pktgen:pktgen_thread_worker+0x0/0x10b0
kthread+0x4d/0x80
child_rip+0xa/0x12
? restore_args+0x0/0x30
? kthread+0x0/0x80
? child_rip+0x0/0x12
RIP ...
| May 20, 2:59 am 2008 |
| Robert Olsson | [PATCH 2/4] pktgen: make sure that pktgen_thread_worker ...
Denis V. Lunev writes:
> The problem is that pktgen_thread_worker can not be executed if kthread_stop
> has been called too early. Insert a completion on the normal initialization
> path to make sure that pktgen_thread_worker will gain the control for sure.
Yes how about if we move the wait_for_completion() to pg_cleanup before
we remove the threads. And move the complete() last in pktgen_thread_worker.
This completion would sync with both start and stop.
...
| May 20, 11:30 am 2008 |
| swhiteho | [PATCH 1/3] [GFS2] filesystem consistency error from do_strip
From: Bob Peterson <rpeterso@redhat.com>
This patch fixes a GFS2 filesystem consistency error reported from
function do_strip. The problem was caused by a timing window
that allowed two vfs inodes to be created in memory that point
to the same file. The problem is fixed by making the vfs's
iget_test, iget_set mechanism check and set a new bit in the
in-core gfs2_inode structure while the vfs inode spin_lock is held.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven ...
| May 20, 2:12 am 2008 |
| Steven Whitehouse | [GFS2] Pull request
Hi,
Please consider pulling the following bug fixes,
Steve.
----------------------------------------------------------------------------
The following changes since commit 492c2e476eac010962850006c49df326919b284c:
Linus Torvalds (1):
Linux 2.6.26-rc2
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes.git
Andrew Price (1):
[GFS2] Fix cast from unsigned int to s64
Bob Peterson (1):
[GFS2] filesystem ...
| May 20, 3:05 am 2008 |
| swhiteho | [GFS2] Pre-pull patch posting (bug fixes)
Hi,
Here is a set of three patches which constitute the current set of
fixes for GFS2. They are all fairly minor changes, but useful
nonetheless,
Steve.
--
| May 20, 2:12 am 2008 |
| swhiteho | [PATCH 3/3] [GFS2] Prefer strlcpy() over snprintf()
From: Jean Delvare <khali@linux-fr.org>
strlcpy is faster than snprintf when you don't use the returned value.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index ef9c6c4..b2028c8 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -142,8 +142,8 @@ static int init_names(struct gfs2_sbd *sdp, int silent)
if (!table[0])
table = sdp->sd_vfs->s_id;
...
| May 20, 2:12 am 2008 |
| swhiteho | [PATCH 2/3] [GFS2] Fix cast from unsigned int to s64
From: Andrew Price <andy@andrewprice.me.uk>
This fixes bz 444829 where allocating a new block caused gfs2 file systems to
report 0 bytes used in df. It was caused by a broken cast from an unsigned int
in gfs2_block_alloc() to a negative s64 in gfs2_statfs_change(). This patch
casts the unsigned int to an s64 before the unary minus is applied.
Signed-off-by: Andrew Price <andy@andrewprice.me.uk>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
diff --git a/fs/gfs2/rgrp.c ...
| May 20, 2:12 am 2008 |
| Greg KH | Re: [PATCH 2/3][-mm] reclassify the sg_sysfs_class mutex
Are you suggesting we do this for every struct class in the kernel? If
so, why not just do it in the class core, instead of having to modify
every single caller?
I don't think the overall idea of this patch set is acceptable anyway :(
thanks,
greg k-h
--
| May 20, 10:22 am 2008 |
| Dave Young | [PATCH 2/3][-mm] reclassify the sg_sysfs_class mutex
[Please first apply the patch 1/3 before this]
To please lockdep here we use class_reclassify to change
the lock class of sg_sysfs_class
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
---
drivers/scsi/sg.c | 2 ++
1 file changed, 2 insertions(+)
--- linux/drivers/scsi/sg.c 2008-05-19 12:41:05.000000000 +0800
+++ linux.new/drivers/scsi/sg.c 2008-05-19 14:08:19.000000000 +0800
@@ -1579,6 +1579,8 @@ init_sg(void)
rc = PTR_ERR(sg_sysfs_class);
goto err_out;
...
| May 20, 2:58 am 2008 |
| Matthew Wilcox | Re: [PATCH 1/3][-mm] add class_reclassify macro
Andrew, we already discussed this on the thread you started that you
The problem is that you add one type of class which then adds devices
that are of another class. This is not a bug. My proposal is to give
each sysfs class its own lock class; Dave's is to only do it for the
two classes he knows about that do this.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ...
| May 20, 10:36 am 2008 |
| Dave Young | Re: [PATCH 1/3][-mm] add class_reclassify macro
On Tue, May 20, 2008 at 6:02 PM, Andrew Morton
I agree.
There's wellmeant lockdep warnings for some safe code logic every some time.
Yes, this macro violates the lockdep class-based rules, but it can act
My wrong, thanks.
Regards
dave
--
| May 20, 4:05 am 2008 |
| Greg KH | Re: [PATCH 1/3][-mm] add class_reclassify macro
Um, no, that's a "feature" that some types of hardware and interfaces
require.
This is one reason I really don't like this type of conversion, it's
causing lots of problems for no known gain.
So I would just recommend dropping this patch set, the current "convert
class semaphore to a mutex" patch in the -mm tree is already causing
lockdep warnings, and trying to do something like this isn't really
going to solve the root problem here.
thanks,
greg k-h
--
| May 20, 10:21 am 2008 |
| Matthew Wilcox | Re: [PATCH 1/3][-mm] add class_reclassify macro
That's what I suggested (in a thread you were cc'd on, but probably
aren't reading). I don't like this reclassify thing either.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
| May 20, 4:36 am 2008 |
| Andrew Morton | Re: [PATCH 1/3][-mm] add class_reclassify macro
I think it would need a lavish comment explaining what it is for, and
the reasons for its existence.
Perhaps this should be a kernel-wide thing in lockdep.h. But then that
would invite people to use it, and it looks like a bad thing.
device.h does not include lockdep.h, so putting this here assumes that
callees have already included lockdep.h. This is the sort of
assumption which leads to compilation errors.
--
| May 20, 3:02 am 2008 |
| Andrew Morton | Re: [PATCH 1/3][-mm] add class_reclassify macro
Well what are these lockdep warnings? Normally such a warning means that
we have a locking bug. I _assume_ that you've determined that the warnings
are false-positives?
The warning which Mariusz Kozlowski discovered ("Subject: Re:
2.6.26-rc2-mm1: possible circular locking dependency detected") was
triggered by the "class semaphore to mutex" conversion and it looks
like a real bug to me. Would your patch prevent warnings such as that
one from being available to us?
--
| May 20, 10:30 am 2008 |
| Dave Young | [PATCH 1/3][-mm] add class_reclassify macro
Converting class semaphore to mutex cause lockdep warnings due to
class_interface_register/unregister will possible call device_add/del
For the class_interface users here add a class_reclassify macro to
reclassify the lock class of their struct class.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
---
include/linux/device.h | 7 +++++++
1 file changed, 7 insertions(+)
--- linux/include/linux/device.h 2008-05-19 12:29:54.000000000 +0800
+++ ...
| May 20, 2:55 am 2008 |
| Andrew Morton | Re: [PATCH 1/3][-mm] add class_reclassify macro
On Tue, 20 May 2008 11:36:41 -0600
rofl.
All pertinent information should be in a patch's changelog. Then this
Well that sounds reasonable. I'm not sure that we should introduce
generic-looking helper infrastructure to do it, however.
Anyway I'll happily sit back and let you guys and Greg sort this one out ;)
--
| May 20, 12:23 pm 2008 |
| Rami Rosen | [PATCH net-2.6] [NET] The world is not perfect patch.
Hi,
There are three methods in the network stack which start with
#ifndef I_WISH_WORLD_WERE_PERFECT.
These methods are:
ipip_err() in net/ipv4/ipip.c
ipgre_err() in net/ipv4/ip_gre.c
ipip6_err() in net/ipv6/sit.c
When building the kernel with -DI_WISH_WORLD_WERE_PERFECT we have
various compilation
errors, mostly due to the fact that the corresponding code was not
updated recently.
(As we all know, indeed the world is not perfect, unluckily...)
This patch fixes these errors and ...
| May 20, 2:29 am 2008 |
| David Miller | Re: [PATCH net-2.6] [NET] The world is not perfect patch.
From: "Rami Rosen" <ramirose@gmail.com>
I think it is better to delete this code. It is impossible
for anyone to build test it without making source modifications,
therefore it will continute to break over and over again over
time.
--
| May 20, 2:33 pm 2008 |
| Vegard Nossum | [PATCH] x86: add save_stack_trace_bp() for tracing from ...
Hi Ingo,
I'll put this at the front of the kmemcheck queue. Looks ok?
Vegard
From 03c790cd13efc34c26b9866db46e501dc645faf8 Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@gmail.com>
Date: Tue, 20 May 2008 11:15:43 +0200
Subject: [PATCH] x86: add save_stack_trace_bp() for tracing from a specific stack frame
This will help kmemcheck (and possibly other debugging tools) since we
can now simply pass regs->bp to the stack tracer instead of specifying
the number of stack frames ...
| May 20, 2:28 am 2008 |
| 賴佳君 | 從新鮮蚌殼中取出珍珠的那ㄧ剎
您2008想5給20心愛的另ㄧ半ㄧ份20驚5喜2008嗎?
近27來27看27看,試27試27這27個27喔 ^.^
珍34珠34貝34殼34項34鍊34禮34盒 ~ 日34本34九34州34空34運34來34台
網址在這→203.70.179.39/ju←複製這行網址貼上即可
▽⊕⊕∵◆
| May 20, 2:27 am 2008 |
| Linus Torvalds | Re: [PATCH 0 of 8] x86: use PTE_MASK consistently
Well, since we actually had a regression, I had to do something before
actually doing 2.6.26.
So to fix the X crash problem with PAE, the choice was between either
applying this series that cleans things up or alternatively add yet
another hack to work around the problem.
And I'm much happier taking the proper fix, even if it was slightly
bigger. It's not like it was a huge and complicated and scary fix ;)
Linus
--
| May 20, 1:02 pm 2008 |
| Ingo Molnar | Re: [PATCH 0 of 8] x86: use PTE_MASK consistently
the only delta between the 8 patches you posted here and tip/x86/ptemask
topic is the comment below - so we are indeed on the safe side.
Ingo
----------------->
diff --git a/include/asm-x86/pgtable.h b/include/asm-x86/pgtable.h
index 21fed4f..97c271b 100644
--- a/include/asm-x86/pgtable.h
+++ b/include/asm-x86/pgtable.h
@@ -57,6 +57,7 @@
#define _KERNPG_TABLE (_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | \
_PAGE_DIRTY)
+/* Set of bits not changed in pte_modify */
#define ...
| May 20, 12:55 pm 2008 |
| Hugh Dickins | [PATCH] x86: strengthen 64-bit p?d_bad()
The x86_64 pgd_bad(), pud_bad(), pmd_bad() inlines have differed from
their x86_32 counterparts in a couple of ways: they've been unnecessarily
weak (e.g. letting 0 or 1 count as good), and were typed as unsigned long.
Strengthen them and return int.
The PAE pmd_bad was too weak before, allowing any junk in the upper half;
but got strengthened by the patch correcting its ~PAGE_MASK to ~PTE_MASK.
The PAE pud_bad already said ~PTE_MASK; and since it folds into pgd_bad,
and we don't set the ...
| May 20, 5:59 am 2008 |
| Linus Torvalds | Re: [PATCH 0 of 8] x86: use PTE_MASK consistently
The thing is, making _PAGE_FOO be a signed long in no way guarantees any
appropriately sized masks.
Why? Because 'long' mixes with 'unsigned long' and in the C type system,
unsigned is stronger than signed.
As a result, if you depend on sign-extension of things like a binary 'not'
operation, you're always going to have cases where it simply doesn't work,
just because you happen to mix it up with other things that may have type
'unsigned long' (or, on 32-bit, 'unsigned int' which ...
| May 20, 11:34 am 2008 |
| Jeremy Fitzhardinge | Re: [PATCH 0 of 8] x86: use PTE_MASK consistently
Yes, well, that was me too, with the intention of making ~_PAGE_FOO
generate an appropriately sized mask. I guess it would be better to use
pteval_t these days.
J
--
| May 20, 6:47 am 2008 |
| Jeremy Fitzhardinge | [PATCH 0 of 8] x86: use PTE_MASK consistently
[ Repost due to screwed up mail headers. ]
Hi all,
Here's a series to rationalize the use of PTE_MASK and remove some
amount of ad-hocery.
This gist of the series is:
1. Fix the definition of PTE_MASK so that its equally applicable in
all pagetable modes
2. Use it consistently
I haven't tried to address the *_bad() stuff, other than to convert
pmd_bad_* to use PTE_MASK.
This series has had some testing in the x86.git tree, and hasn't shown
any problems. Each patch is more or ...
| May 20, 12:26 am 2008 |
| Hugh Dickins | Re: [PATCH 0 of 8] x86: use PTE_MASK consistently
Yes, thanks Jeremy: I've checked that each stage builds and runs X on my
boxes here, x86_32 and x86_32+PAE and x86_64. (So even 1/8 is enough to
fix the PAT pte_modify issue, though 2/8 then fixes compiler warnings.)
I'll leave it to you and Linus whether your way of defining PTE_MASK is
satisfactory as is, or needs to be improved to his way. I've not tried
his suggestion of doing the _PAGE_BIT definitions: certainly it's
seemed odd to me that they were defined with L, but I've ...
| May 20, 5:57 am 2008 |
| Jeremy Fitzhardinge | [PATCH 8 of 8] xen: use PTE_MASK in pte_mfn()
Use PTE_MASK to extract mfn from pte.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
include/asm-x86/xen/page.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asm-x86/xen/page.h b/include/asm-x86/xen/page.h
--- a/include/asm-x86/xen/page.h
+++ b/include/asm-x86/xen/page.h
@@ -127,7 +127,7 @@
static inline unsigned long pte_mfn(pte_t pte)
{
- return (pte.pte & ~_PAGE_NX) >> PAGE_SHIFT;
+ return (pte.pte & PTE_MASK) >> ...
| May 20, 12:26 am 2008 |
| Jeremy Fitzhardinge | [PATCH 6 of 8] x86: clarify use of _PAGE_CHG_MASK
_PAGE_CHG_MASK is defined as the set of bits not updated by
pte_modify(); specifically, the pfn itself, and the Accessed and Dirty
bits (which are updated by hardware).
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
include/asm-x86/pgtable.h | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/include/asm-x86/pgtable.h b/include/asm-x86/pgtable.h
--- a/include/asm-x86/pgtable.h
+++ b/include/asm-x86/pgtable.h
@@ -57,6 +57,7 @@
#define ...
| May 20, 12:26 am 2008 |
| Jeremy Fitzhardinge | [PATCH 5 of 8] x86: use PTE_MASK in pgtable_32.h
---
include/asm-x86/pgtable_32.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-x86/pgtable_32.h b/include/asm-x86/pgtable_32.h
--- a/include/asm-x86/pgtable_32.h
+++ b/include/asm-x86/pgtable_32.h
@@ -88,7 +88,7 @@
/* To avoid harmful races, pmd_none(x) should check only the lower when PAE */
#define pmd_none(x) (!(unsigned long)pmd_val((x)))
#define pmd_present(x) (pmd_val((x)) & _PAGE_PRESENT)
-#define pmd_bad(x) ((pmd_val(x) & (~PAGE_MASK & ...
| May 20, 12:26 am 2008 |
| Jeremy Fitzhardinge | [PATCH 4 of 8] x86: use PTE_MASK in 32-bit PAE
Use PTE_MASK in 3-level pagetables (ie, 32-bit PAE).
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
include/asm-x86/pgtable-3level.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-x86/pgtable-3level.h b/include/asm-x86/pgtable-3level.h
--- a/include/asm-x86/pgtable-3level.h
+++ b/include/asm-x86/pgtable-3level.h
@@ -120,9 +120,9 @@
write_cr3(pgd);
}
-#define pud_page(pud) ((struct page *) __va(pud_val(pud) & ...
| May 20, 12:26 am 2008 |
| Jeremy Fitzhardinge | [PATCH 3 of 8] x86: rearrange __(VIRTUAL|PHYSICAL)_MASK
Put the definitions of __(VIRTUAL|PHYSICAL)_MASK before their uses.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
include/asm-x86/page.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-x86/page.h b/include/asm-x86/page.h
--- a/include/asm-x86/page.h
+++ b/include/asm-x86/page.h
@@ -9,6 +9,9 @@
#define PAGE_MASK (~(PAGE_SIZE-1))
#ifdef __KERNEL__
+
+#define __PHYSICAL_MASK ((phys_addr_t)(1ULL << ...
| May 20, 12:26 am 2008 |
| Jeremy Fitzhardinge | [PATCH 2 of 8] x86: fix warning on 32-bit non-PAE
Fix the warning:
include2/asm/pgtable.h: In function `pte_modify':
include2/asm/pgtable.h:290: warning: left shift count >= width of type
On 32-bit PAE the virtual and physical addresses are both 32-bits,
so it ends up evaluating 1<<32. Do the shift as a 64-bit shift then
cast to the appropriate size. This should all be done at compile time,
and so have no effect on generated code.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
include/asm-x86/page.h | 2 ...
| May 20, 12:26 am 2008 |
| Jeremy Fitzhardinge | [PATCH 1 of 8] x86: define PTE_MASK in a universally use ...
Define PTE_MASK so that it contains a meaningful value for all x86
pagetable configurations. Previously it was defined as a "long" which
means that it was too short to cover a 32-bit PAE pte entry.
It is now defined as a pteval_t, which is an integer type long enough
to contain a full pte (or pmd, pud, pgd).
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
include/asm-x86/page.h | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git ...
| May 20, 12:26 am 2008 |
| Jeremy Fitzhardinge | [PATCH 7 of 8] x86: use PTE_MASK rather than ad-hoc mask
Use ~PTE_MASK to extract the non-pfn parts of the pte (ie, the pte
flags), rather than constructing an ad-hoc mask.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
include/asm-x86/pgtable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asm-x86/pgtable.h b/include/asm-x86/pgtable.h
--- a/include/asm-x86/pgtable.h
+++ b/include/asm-x86/pgtable.h
@@ -305,7 +305,7 @@
return __pgprot(preservebits | addbits);
}
-#define ...
| May 20, 12:26 am 2008 |
| Ingo Molnar | Re: [PATCH 0 of 8] x86: use PTE_MASK consistently
yep, this has been problem-free in x86.git and then in -tip, we had a
separate x86/ptemask topic for it that we originally intended for
v2.6.27, and we dont mind to see it upstream now ;-)
Ingo
--
| May 20, 12:51 pm 2008 |
| Li Zefan | May 20, 2:33 am 2008 | |
| KAMEZAWA Hiroyuki | [RFC][PATCH 2/3] memcg:: seq_ops support for cgroup
Does anyone have a better idea ?
==
Currently, cgroup's seq_file interface just supports single_open.
This patch allows arbitrary seq_ops if passed.
For example, "status per cpu, status per node" can be very big
in general and they tend to use its own start/next/stop ops.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
include/linux/cgroup.h | 9 +++++++++
kernel/cgroup.c | 32 +++++++++++++++++++++++++++++---
2 files changed, 38 insertions(+), 3 ...
| May 20, 2:08 am 2008 |
| Pavel Emelyanov | Re: [RFC][PATCH 1/3] memcg: documentation for controll file
I have described some files, that should be created by a control group,
which uses a res_counter in Documentation/controllers/resource_counter.txt
section 4.
Maybe it's worth adding a reference to this file, or even rework this
--
| May 20, 2:04 am 2008 |
| KAMEZAWA Hiroyuki | [RFC][PATCH 1/3] memcg: documentation for controll file
Add a documentation for memory resource controller's files.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Index: mm-2.6.26-rc2-mm1/Documentation/controllers/memory_files.txt
===================================================================
--- /dev/null
+++ mm-2.6.26-rc2-mm1/Documentation/controllers/memory_files.txt
@@ -0,0 +1,76 @@
+Files under memory resource controller and its resource counter.
+(See controllers/memory.txt about memory resource ...
| May 20, 2:05 am 2008 |
| KAMEZAWA Hiroyuki | Re: [RFC][PATCH 3/3] memcg: per node information
On Tue, 20 May 2008 17:33:20 +0800
Thanks, will fix.
-Kame
--
| May 20, 3:56 am 2008 |
| Pavel Emelyanov | Re: [RFC][PATCH 2/3] memcg:: seq_ops support for cgroup
Acked-by: Pavel Emelyanov <xemul@openvz.org>
--
| May 20, 2:23 am 2008 |
| KAMEZAWA Hiroyuki | Re: [RFC][PATCH 1/3] memcg: documentation for controll file
On Tue, 20 May 2008 13:04:33 +0400
I'll drop parameters from res_coutner and just shows special files for
memory controller and some how-to-use text. (maybe add to memory.txt)
Thanks,
-Kame
--
| May 20, 2:23 am 2008 |
| Paul Menage | Re: [RFC][PATCH 2/3] memcg:: seq_ops support for cgroup
On Tue, May 20, 2008 at 2:08 AM, KAMEZAWA Hiroyuki
As a way of printing plain text files, it seems fine.
My concern is that it means that cgroups no longer has any idea about
the typing of the data being returned, which will make it harder to
integrate with a binary stats API. You'd end up having to have a
separate reporting method for the same data to use it. That's why the
"read_map" function specifically doesn't take a seq_file, but instead
takes a key/value callback abstraction, which ...
| May 20, 11:46 am 2008 |
| KAMEZAWA Hiroyuki | [RFC][PATCH 3/3] memcg: per node information
Show per-node statistics in following format.
node-id total acitve inactive
[root@iridium bench]# cat /opt/cgroup/memory.numa_stat
0 417611776 99586048 318025728
1 655360000 0 655360000
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
mm/memcontrol.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 66 insertions(+)
Index: mm-2.6.26-rc2-mm1/mm/memcontrol.c
===================================================================
--- ...
| May 20, 2:09 am 2008 |
| Bryan Wu | [PATCH 1/1] mtd m25p80: fix bug - ATmel spi flash fails ...
From: Michael Hennerich <michael.hennerich@analog.com>
remove duplicate code.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
---
drivers/mtd/devices/m25p80.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index b10649b..7f89b54 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -122,8 +122,6 @@ static int ...
| May 20, 1:40 am 2008 |
| Justin Piszcz | Kernel 2.6.25.4 crashed upon bootup [BUG: NMI Watchdog d ...
This is the first time my machine has ever crashed while booting up.
Kernel = 2.6.25.4
May 20 03:57:23 box1 [ 13.917884] BUG: NMI Watchdog detected LOCKUP
May 20 03:57:23 box1 on CPU1, ip c010146e, registers:
May 20 03:57:23 box1 [ 13.917884] Modules linked in:
May 20 03:57:23 box1 snd_hda_intel
May 20 03:57:23 box1 snd_hwdep
May 20 03:57:23 box1
May 20 03:57:23 box1 [ 13.917884]
May 20 03:57:23 box1 [ 13.917884] Pid: 0, comm: swapper Not tainted (2.6.25.4 #1)
May 20 03:57:23 ...
| May 20, 1:12 am 2008 |
| Zhang, Yanmin | hackbench regression with 2.6.26-rc2 on tulsa machine
Comparing with 2.6.26-rc1, hackbench has about 30% regression with 2.6.26-rc2 on my tulsa machine
which is a netburst architecure hyper-threading x86_64.
Command line to test: #hackbench 100 process 2000
With 2.6.26-rc1, it takes 30 seconds. But with 2.6.26-rc2/rc3, it takes 40 seconds.
Bisect located below patch:
46151122e0a2e80e5a6b2889f595e371fe2b600d is first bad commit
commit 46151122e0a2e80e5a6b2889f595e371fe2b600d
Author: Mike Galbraith <efault@gmx.de>
Date: Thu May 8 17:00:42 ...
| May 20, 1:09 am 2008 |
| Mike Galbraith | Re: hackbench regression with 2.6.26-rc2 on tulsa machine
Oh joy. I'll update my poor old P4 and see what I can duplicate this.
Do you still have group scheduling enabled? If so, can you turn it off
and try again? (when in doubt, grasp at any straw within reach;)
-Mike
--
| May 20, 2:22 am 2008 |
| Andrew Morton | Re: + pcmcia-add-support-the-cf-pcmcia-driver-for-blackf ...
Nope, I keep the patches separate and then fold them prior to sending
to Linus.
I marked this as for-2.6.26 as it's clearly non-injurious to existing stuff.
should probably be using CONFIG_foo but that might not work if it's to
be preprocessed by userspace. I didn't look. Plus that'd be
off-topic.
--
| May 20, 1:02 am 2008 |
| Bryan Wu | Re: + pcmcia-add-support-the-cf-pcmcia-driver-for-blackf ...
Thanks Andrew,
Need I resend out the a new patch which fold these 3 patches together.
it is easier for you to maintain.
Regards,
-Bryan
--
| May 20, 12:51 am 2008 |
| Javier Herrero | Re: b4aa54d951d38d7a989d6b6385494ef5ea7371d7 breaks some ...
Does the problem arise due to the change of inclusion order of
asm/serial.h (from after 8250.h to before 8250.h) ?
--
------------------------------------------------------------------------
Javier Herrero EMAIL: jherrero@hvsistemas.com
HV Sistemas S.L. PHONE: +34 949 336 806
Los Charcones, 17A FAX: +34 949 336 792
19170 El Casar - Guadalajara - Spain WEB: http://www.hvsistemas.com
--
| May 20, 1:07 am 2008 |
| Russell King | Re: b4aa54d951d38d7a989d6b6385494ef5ea7371d7 breaks some ...
Can blackfin systems accept PCMCIA cards? Or PCI cards? In which case
you probably don't want to implement this support like this.
A better solution may be to add some UPF_ flags to indicate the interrupt
polarity on a per-port basis. Not sure I'm particularly thrilled by that
idea though, but other solutions I can think of inspire me even less.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
| May 20, 4:13 pm 2008 |
| Russell King | b4aa54d951d38d7a989d6b6385494ef5ea7371d7 breaks some ser ...
The above commit contains the following patch:
| --- a/drivers/serial/8250.c
| +++ b/drivers/serial/8250.c
| @@ -43,6 +43,7 @@
|
| #include <asm/io.h>
| #include <asm/irq.h>
| +#include <asm/serial.h>
|
| #include "8250.h"
|
| @@ -92,8 +93,6 @@ static unsigned int nr_uarts = CONFIG_SERIAL_8250_RUNTIME_UARTS;
| */
| #define CONFIG_HUB6 1
|
| -#include <asm/serial.h>
| -
| /*
| * SERIAL_PORT_DFNS tells us about built-in ports that have no
| * standard enumeration ...
| May 20, 12:35 am 2008 |
| Javier Herrero | Re: b4aa54d951d38d7a989d6b6385494ef5ea7371d7 breaks some ...
I see... would be OK to move the asm/serial.h include to its original
position and to modify the asm-blackfin/serial.h in this way to avoid
duplicate definition warnings, or would it be too ugly?:
/*
* include/asm-blackfin/serial.h
*/
+#ifdef SERIAL_EXTRA_IRQ_FLAGS
+#undef SERIAL_EXTRA_IRQ_FLAGS
+#endif
#define SERIAL_EXTRA_IRQ_FLAGS IRQF_TRIGGER_HIGH
Regards,
Javier
--
------------------------------------------------------------------------
Javier Herrero ...
| May 20, 3:52 am 2008 |
| Russell King | Re: b4aa54d951d38d7a989d6b6385494ef5ea7371d7 breaks some ...
Yes. It was placed where it was because of the dependencies of
asm/serial.h on the code between the two places.
The alternative solution is to get rid of the CONFIG_* compatibility
and update those asm/serial.h which reference the old symbols.
However, that's a larger patch.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
| May 20, 1:32 am 2008 |
| Mike Frysinger | Re: b4aa54d951d38d7a989d6b6385494ef5ea7371d7 breaks some ...
yes, you can hook PCMCIA cards up to a Blackfin proc (and we have).
we probably wont be supporting PCI since it tends to require MMU
support, and at least with all the Blackfins we support now, none have
PCI support on-chip.
-mike
--
| May 20, 4:21 pm 2008 |
| Avi Kivity | [PATCH] Make LIST_POISON less deadly (v2)
The list macros use LIST_POISON1 and LIST_POISON2 as undereferencable
pointers in order to trap erronous use of freed list_heads. Unfortunately
userspace can arrange for those pointers to actually be dereferencable,
potentially turning an oops to an expolit.
To avoid this allow architectures (currently x86_64 only) to override
the default values for these pointers with truly-undereferncable values.
This is easy on x86_64 as the virtual address space is smaller than
the range spanned by pointer ...
| May 20, 12:10 am 2008 |
| Bart Van Assche | [PATCH 2.6.26-rc3] Suppress files generated during x86_6 ...
Suppress the following additional files generated during an x86_64 kernel
build in Documentation/dontdiff: bounds.h, cpustr.h, mkcpustr, vdso-syms.lds,
vdso.so.dbg, vdso32-syms.lds, vdso32-syscall-syms.lds, vdso32-syscall.so.dbg,
vdso32-sysenter-syms.lds, vdso32-sysenter.so.dbg, vdso32.lds, wakeup.elf
and wakeup.lds
Signed-off-by: Bart Van Assche <bart.vanassche@gmail.com>
diff -uprN -X Documentation/dontdiff ../orig/linux-2.6.26-rc3/Documentation/dontdiff ./Documentation/dontdiff
--- ...
| May 19, 11:52 pm 2008 |
| Romano Giannetti | Re: [Bug 10620] VT switching broken - X does not resume ...
On Mon, 2008-05-19 at 14:44 -0700, bugme-daemon@bugzilla.kernel.org
I know. The problem was that I didn't know if this was due to the drm,
video, acpi or x86... so it seems that is quite restricted now.
To resume (see http://bugzilla.kernel.org/show_bug.cgi?id=10620 )
- VT switching is broken after gnome has started (acceleration?)
- the symptom is that the X VT stays black, which just the cursor (and
sometime some residual bit of the panel) shown.
- it happens almost all the time with ...
| May 19, 11:38 pm 2008 |
| KAMEZAWA Hiroyuki | Re: + memcg-remove-refcnt-from-page_cgroup.patch added t ...
hi, I found a bug in this patch. (A fix is attached below.)
On Thu, 15 May 2008 19:53:17 -0700
Should be if (!newpage->mapping). Maybe a typo in restructuring...
Sorry.
-Kame
==
This rollback should be done at failure.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
mm/memcontrol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: mm-2.6.26-rc2-mm1/mm/memcontrol.c
===================================================================
--- ...
| May 19, 11:35 pm 2008 |
| Steven Rostedt | 2.6.24.7-rt8
We are pleased to announce the 2.6.24.7-rt8 tree, which can be
downloaded from the location:
http://rt.et.redhat.com/download/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
Changes since 2.6.24.7-rt7
- Read Write locks with multiple readers (Steven Rostedt)
The previous versions of the RT tree would serialize the RW locks
for all readers to allow for priority inheritance to take place.
This change allows for multiple readers but ...
| May 19, 9:46 pm 2008 |
| H. Peter Anvin | Re: [X86] Add a boot parameter to force-enable PAT
Either that or "pat={off,on,force}" to give space for other options...
would mean keeping "nopat" around as an alias for now, though...
-hpa
--
| May 20, 3:21 pm 2008 |
| Yinghai Lu | Re: [X86] Add a boot parameter to force-enable PAT
you don't need to set that bit again...
YH
--
| May 19, 10:53 pm 2008 |
| Dave Jones | Re: [X86] Add a boot parameter to force-enable PAT
On Mon, May 19, 2008 at 10:53:58PM -0700, Yinghai Lu wrote:
> you don't need to set that bit again...
>
> prevoious !test_cpu_cap(..) already get out.
* Add an enablepat boot parameter, useful for testing CPUs not yet
added to the whitelist.
* Don't try to enable PAT if it was never enabled in the first place.
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 72c07a0..e179c22 100644
--- ...
| May 20, 6:23 am 2008 |
| Rene Herman | Re: [X86] Add a boot parameter to force-enable PAT
Yes, that would be nicer. As to the alias; "nopat" hasn't been in a
released kernel yet so should be okay to do away with? It's not like
it's in Documentation/kernel-parameters.txt or anything... ;-/
Rene.
--
| May 20, 3:42 pm 2008 |
| H. Peter Anvin | Re: [X86] Add a boot parameter to force-enable PAT
OK, just double-checked... since it's not in Linus we can still change
it, and as so I'd suggest the pat= option.
-hpa
--
| May 20, 3:42 pm 2008 |
| Dave Jones | Re: [X86] Add a boot parameter to force-enable PAT
On Tue, May 20, 2008 at 03:42:49PM -0700, H. Peter Anvin wrote:
> > Yes, that would be nicer. As to the alias; "nopat" hasn't been in a
> > released kernel yet so should be okay to do away with? It's not like
> > it's in Documentation/kernel-parameters.txt or anything... ;-/
> >
>
> OK, just double-checked... since it's not in Linus we can still change
> it, and as so I'd suggest the pat= option.
Not boot-tested, but it compiles for me..
I also folded in the 'debugpat' ...
| May 20, 3:56 pm 2008 |
| Dave Jones | Re: [X86] Add a boot parameter to force-enable PAT
* Add an enablepat boot parameter, useful for testing CPUs not yet
added to the whitelist.
* Don't try to enable PAT if it was never enabled in the first place.
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 72c07a0..e179c22 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -236,6 +236,10 @@ and is between 256 and 4096 characters. It is defined in the ...
| May 20, 12:58 pm 2008 |
| Mikael Pettersson | Re: [X86] Add a boot parameter to force-enable PAT
Dave Jones writes:
> On Mon, May 19, 2008 at 10:53:58PM -0700, Yinghai Lu wrote:
>
> > you don't need to set that bit again...
> >
> > prevoious !test_cpu_cap(..) already get out.
>
>
> * Add an enablepat boot parameter, useful for testing CPUs not yet
> added to the whitelist.
> * Don't try to enable PAT if it was never enabled in the first place.
>
> Signed-off-by: Dave Jones <davej@redhat.com>
>
> diff --git a/Documentation/kernel-parameters.txt ...
| May 20, 7:41 am 2008 |
| Rene Herman | Re: [X86] Add a boot parameter to force-enable PAT
This should probably be called plain "pat" to mirror arch/x86/mm/pat.c
"nopat" force off parameter. That by the way is an early_param which I
It seems you needn't test this, the !cpu_has_pat test in pat_init() will
Rene.
--
| May 20, 2:49 pm 2008 |
| Dave Jones | [X86] Add a boot parameter to force-enable PAT
* Add an enablepat boot parameter, useful for testing CPUs not yet
added to the whitelist.
* Don't try to enable PAT if it was never enabled in the first place.
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 72c07a0..e179c22 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -236,6 +236,10 @@ and is between 256 and 4096 characters. It is defined in the ...
| May 19, 9:09 pm 2008 |
| Yinghai Lu | May 19, 10:49 pm 2008 | |
| Dave Jones | [X86] Add recent Centaur CPUs to PAT whitelist
From conversation with Centaur engineers, both the newer generations
of the VIA C7, and their future CPUs support PAT, with no known errata.
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/arch/x86/kernel/cpu/addon_cpuid_features.c b/arch/x86/kernel/cpu/addon_cpuid_features.c
index c2e1ce3..638a3a6 100644
--- a/arch/x86/kernel/cpu/addon_cpuid_features.c
+++ b/arch/x86/kernel/cpu/addon_cpuid_features.c
@@ -62,6 +81,10 @@ void __cpuinit validate_pat_support(struct cpuinfo_x86 *c)
...
| May 19, 9:09 pm 2008 |
| Dave Jones | Re: [X86] Add recent Centaur CPUs to PAT whitelist
On Mon, May 19, 2008 at 10:49:28PM -0700, Yinghai Lu wrote:
> > + case X86_VENDOR_CENTAUR:
> > + if ((c->x86 > 6) || (c->x86 == 6 && c->x86_model >= 10))
> > + set_cpu_cap(c, X86_FEATURE_PAT);
> > + break;
> > }
> >
> > pat_disable(cpu_has_pat ?
>
> you may need to return early...
Argh, old version of the patch. This one should be right.
Dave
---
From conversation with Centaur engineers, both the ...
| May 20, 6:19 am 2008 |
| H. Peter Anvin | Re: [X86] Remove unnecessary code in 64bit CPU identification.
I'd really like to avoid divergences between the 32-bit and 64-bit code
if they can be avoided at this point. These codes need to be unified,
not further split.
-hpa
--
| May 20, 7:46 am 2008 |
| Dave Jones | [X86] Remove unnecessary code in 64bit CPU identification.
There were no 64bit Transmeta CPUs made (and it'd be something of
a surprise if they started any time soon). To the best of my knowledge,
no CPU vendor cloned the 80860000 cpuid space claimed by Transmeta.
By removing this code, we can also eliminate calling cpuid 0x80000007 twice.
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index ff62838..0380726 100644
--- a/arch/x86/kernel/setup_64.c
+++ ...
| May 19, 9:09 pm 2008 |
| Dave Jones | Re: [X86] Remove unnecessary code in 64bit CPU identification.
On Tue, May 20, 2008 at 07:46:57AM -0700, H. Peter Anvin wrote:
> Dave Jones wrote:
> > There were no 64bit Transmeta CPUs made (and it'd be something of
> > a surprise if they started any time soon). To the best of my knowledge,
> > no CPU vendor cloned the 80860000 cpuid space claimed by Transmeta.
> > By removing this code, we can also eliminate calling cpuid 0x80000007 twice.
> >
> > Signed-off-by: Dave Jones <davej@redhat.com>
>
> I'd really like to avoid divergences between ...
| May 20, 8:16 am 2008 |
| Dave Jones | Re: [X86] Remove unnecessary code in 64bit CPU identification.
On Tue, May 20, 2008 at 10:58:07AM -0700, H. Peter Anvin wrote:
> Dave Jones wrote:
> > On Tue, May 20, 2008 at 07:46:57AM -0700, H. Peter Anvin wrote:
> > > Dave Jones wrote:
> > > > There were no 64bit Transmeta CPUs made (and it'd be something of
> > > > a surprise if they started any time soon). To the best of my knowledge,
> > > > no CPU vendor cloned the 80860000 cpuid space claimed by Transmeta.
> > > > By removing this code, we can also eliminate calling cpuid 0x80000007 ...
| May 20, 11:06 am 2008 |
| Dave Jones | Re: [X86] Remove unnecessary code in 64bit CPU identification.
On Tue, May 20, 2008 at 12:09:35AM -0400, Dave Jones wrote:
> There were no 64bit Transmeta CPUs made (and it'd be something of
> a surprise if they started any time soon). To the best of my knowledge,
> no CPU vendor cloned the 80860000 cpuid space claimed by Transmeta.
> By removing this code, we can also eliminate calling cpuid 0x80000007 twice.
argh, after reading this a dozen times, I send it, and then notice a typo.
That should be ' eliminate calling cpuid 0x80000000 ...
| May 19, 9:14 pm 2008 |
| Dave Jones | Re: [X86] Remove unnecessary code in 64bit CPU identification.
On Tue, May 20, 2008 at 10:58:07AM -0700, H. Peter Anvin wrote:
> Dave Jones wrote:
> > On Tue, May 20, 2008 at 07:46:57AM -0700, H. Peter Anvin wrote:
> > > Dave Jones wrote:
> > > > There were no 64bit Transmeta CPUs made (and it'd be something of
> > > > a surprise if they started any time soon). To the best of my knowledge,
> > > > no CPU vendor cloned the 80860000 cpuid space claimed by Transmeta.
> > > > By removing this code, we can also eliminate calling cpuid 0x80000007 ...
| May 20, 12:18 pm 2008 |
| H. Peter Anvin | Re: [X86] Remove unnecessary code in 64bit CPU identification.
*Shrug* ... it seems like pointless churn to code that really needs to
die to me.
-hpa
--
| May 20, 10:58 am 2008 |
| H. Peter Anvin | Re: [X86] Remove unnecessary code in 64bit CPU identification.
Looks good to me at first glance, and would definitely be a good step on
the way.
-hpa
--
| May 20, 12:42 pm 2008 |
| Jeff Dike | Re: UML and VMI ... how does UML work?
There's nothing magic. It turns out that the system call interface is
sufficient to virtualize an entire system, and UML is an existence
proof of that. The major mappings are:
system calls -> ptrace
memory -> mmap, munmap, mprotect
interrupts -> signals
This paragraph is very unclear to me...
Jeff
--
Work email - jdike at linux dot intel dot com
--
| May 20, 6:45 am 2008 |
| peerchen | Re: Re: [PATCH] ahci: change the Device IDs of nvidia MC ...
We make a mistake, the IDs need to be changed are not correct, those IDs belong to other devices.
------------------
peerchen
2008-05-20
-------------------------------------------------------------
发件人:Jeff Garzik
发送日期:2008-05-20 03:11:56
收件人:peerchen
抄送:linux-kernel; linux-ide; akpm
主题:Re: [PATCH] ahci: change the Device IDs of nvidia MCP7B AHCI controllerin ahci.c
A little bit more patch description, please?
Why is this change needed? A change with a description ...
| May 19, 7:50 pm 2008 |
| Reeve Yang | kernel 2.6.22 CPU shoot up with same amount of file I/O
Hi all,
We recently upgrade kernel from 2.6.17.4 to 2.6.22.15 on our products.
In our some test, the disk I/O shot as well as CPU utilization, which
starving our some other critical process. For the sake of curiosity, I
ran bonnie++ on both kernels, following are the result:
## ###############Linux 2.6.17 #1 SMP Tue May 6
##################################
Version 1.03c ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per ...
| May 19, 7:47 pm 2008 |
| Shaohua Li | Re: [BISECTED] pata_jmicron: no drives found on post 2.6 ...
[Empty message]
| May 19, 6:48 pm 2008 |
| Plamen Petrov | Re: [BISECTED] pata_jmicron: no drives found on post 2.6 ...
Checkout the attached files. Sorry for the delay - I was away from the
Thanks for your time,
Plamen=20
--=20
Plamen Petrov, network & system administrator
Filial - Silistra
RU "Angel Kantchev"
http://fs.ru.acad.bg/
--------------------------------
this message is UTF8 encoded=20
_
___
_____
------------------------------------------
This message was sent by the mail server
at fs.ru.acad.bg using the web interface:
https://fs.ru.acad.bg/s/m/webmail
E-mail ...
| May 20, 9:09 am 2008 |
| Peng Haitao | [PATCH] remove useless argument type in audit_filter_user()
The second argument "type" is not used in audit_filter_user(), so I think that type can be removed. If I'm wrong, please tell me.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
---
include/linux/audit.h | 2 +-
kernel/audit.c | 2 +-
kernel/auditfilter.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 2af9ec0..018f143 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -537,7 ...
| May 19, 6:13 pm 2008 |
| Dragan Noveski | problems compiling alsa-drivers-1.0.16 into 2.6.25.4 kernel
hallo list,
steven rostedt asked me to pass this problem to this list, so here it goes.
when running make in the alsa-driver source i get this error:
.....
make[1]: Entering directory `/usr/src/linux-2.6.25'
CC [M]
/home/nowhiskey/software/nove/alsa/alsa-driver-1.0.16/acore/hwdep.o
CC [M]
/home/nowhiskey/software/nove/alsa/alsa-driver-1.0.16/acore/memory_wrapper.o
CC [M]
/home/nowhiskey/software/nove/alsa/alsa-driver-1.0.16/acore/memalloc.o
CC [M] ...
| May 19, 6:03 pm 2008 |
| Benjamin Herrenschmidt | Re: [patch v2] LMB: Add basic spin locking to lmb
I think the core memory hotplug is... However, we used to not change the
LMB when doing so (afaik, I'm travelling and not looking at the code
right now). However, things like PS3 memory hotplug tries to keep LMB is
sync for the sake of /dev/mem or similar and that happens before the
memory is added to the core.
Ben.
--
| May 19, 7:32 pm 2008 |
| David Miller | Re: [patch v2] LMB: Add basic spin locking to lmb
From: Geoff Levand <geoffrey.levand@am.sony.com>
I'm not against this patch, but I'm pretty sure it's not
necessary. Isn't memory hotplug already synchronized at
a higher level?
If not, it should be.
--
| May 19, 7:22 pm 2008 |
| David Miller | Re: [patch v2] LMB: Add basic spin locking to lmb
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
But if the memory hotplug is synchronized, so are changes to the LMB
tables.
And if there are LMB read side access concernes outside of the hotplug
event, ideally we should use the synchronization mechanism that
hotplug uses instead of adding a new one.
--
| May 19, 7:34 pm 2008 |
| Geoff Levand | [patch v2] LMB: Add basic spin locking to lmb
Add a spinlock to struct lmb to enforce concurrency in
lmb_add(), lmb_remove(), lmb_analyze(), lmb_find(), and
lmb_dump_all().
This locking is needed for SMP systems that access the lmb structure
during hot memory add and remove operations after secondary cpus
have been started.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
v2: o Add locking to lmb_find().
include/linux/lmb.h | 1
lib/lmb.c | 62 ++++++++++++++++++++++++++++++++++++++++------------
2 ...
| May 19, 5:55 pm 2008 |
| Geoff Levand | [rfc] [patch] LMB: Add basic spin locking to lmb
Add a spinlock to struct lmb to enforce concurrency in
lmb_add(), lmb_remove(), lmb_analyze(), and lmb_dump_all().
This locking is needed for SMP systems that access the lmb structure
during hot memory add and remove operations after secondary cpus
have been started.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
This patch just adds locks for the few lmb routines that would
be used for hot memory adding and removing.
-Geoff
include/linux/lmb.h | 1
lib/lmb.c ...
| May 19, 5:40 pm 2008 |
| Miquel van Smoorenburg | dma_alloc_coherent() sets __GFP_NORETRY ? [was: Re: [PAT ...
I actually did that in the next patch, but I have been looking a bit
deeper into this and it might not be such a good idea. That, or there is
a bug in pci-dma_64.c.
In arch/x86/kernel/pci-dma_64.c , dma_alloc_coherent() adds
__GFP_NORETRY to the gfp flags before it calls __get_free_pages (through
dma_alloc_pages).
That means dma_alloc_coherent() -> __get_free_pages() can fail quite
easily on x86_64 with GFP_KERNEL.
If in __get_free_pages() try_to_free_pages() fails once, ...
| May 19, 5:24 pm 2008 |
| Carlos R. Mafra | Re: [PATCH] Intel Management Engine Interface
These definitions are not used in any file, why don't you remove
them?
--
| May 20, 1:35 pm 2008 |
| Maxim Levitsky | Re: [PATCH] Intel Management Engine Interface
I bought a system with intel DG965RY motherboard year ago, and still no support for its
O/B sensors in linux.
Can I ask again, when you expect it to be released.
At least intel should release documents how to access the QST sensors.
I know that HECI is first step for that, but it is not enought to read those sensors.
I Really hope there are good news,
Best regards,
Maxim Levitsky
--
| May 20, 8:42 am 2008 |
| Jiri Slaby | Re: [PATCH] Intel Management Engine Interface
return wait_event_interruptible_timeout();
'H' all linux/hiddev.h
struct heci_message_data is not 32/64-bit friendly
_IOC_NRBITS is 8, 0x800 is far higher than that
PCI_VDEVICE?
the format is:
This can be built tristate, right? What if THIS_MODULE is 0.
BUG()
...
--
| May 20, 3:27 pm 2008 |
| Anas Nashif | [PATCH] Intel Management Engine Interface
We have addressed more issues raised on lkml after initial submission,
especially the legacy device support issue which was removed in this
patch.
The Intel Management Engine Interface (aka HECI: Host Embedded
Controller Interface ) enables communication between the host OS and
the Management Engine firmware. MEI is bi-directional, and either the
host or Intel AMT firmware can initiate transactions.
The core hardware architecture of Intel Active Management Technology
(Intel AMT) is resident ...
| May 19, 5:11 pm 2008 |
| Gabriel C | Re: [PATCH] Intel Management Engine Interface
This patch is against what tree / kernel version ?
Won't compile on current kernels cause it still uses class_device_* so I guess it is based on 2.6.22/23 ?
Also in drivers/char/Makefile $(CONFIG_HECI) should be $(CONFIG_INTEL_MEI)
Gabriel
--
| May 20, 12:02 pm 2008 |
| Andrew Morton | Re: [PATCH] Intel Management Engine Interface
On Mon, 19 May 2008 20:11:54 -0400
What a lot of code.
It'd be nice if the changelog were to describe the proposed and
all-important kernel<->userspace interface, please. From a five-second
peek it looks like a miscdev with ioctls? Ah, and there's read and
write too.
What is the payload for those system calls, and the meanings of their
return values, etc, etc?
Does it make sense for this driver to be available on all
architectures?
--
| May 19, 5:28 pm 2008 |
| Harvey Harrison | Re: [2.6.27 patch] the scheduled smbfs removal
So it's generally people talking to older (or very old) servers that
would be affected by this? What options would they have if smbfs were
removed? Is there an alternative to smbfs that would work? FUSE client?
(Not affected personally, just curious what the alternatives are where
cifs won't do it)
Harvey
--
| May 19, 5:49 pm 2008 |
| Steve French | Re: [2.6.27 patch] the scheduled smbfs removal
A partial list follows - let me know if you are aware of more (or even
better open bugs in the project bugzilla on samba.org)
Note that some of the backlevel server support issues aren't handled
by smbfs either (and are hard due to protocol limitations). Guenter
Kukkukk had been tracking some of the issues with better backlevel
support (mostly for OS/2 and Win9x servers) so he might have more
information, but the obvious holes that come to mind are:
a) utimes to backlevel (lanman) ...
| May 19, 5:00 pm 2008 |
| Steve French | Re: [2.6.27 patch] the scheduled smbfs removal
On Mon, May 19, 2008 at 7:49 PM, Harvey Harrison
They could use smbclient (an ftp like tool in the samba suite), but
there are no obvious reasons for another file system.
There are some usability improvements that could be made in mount.cifs
that might be all that is needed for 99% of the users of these very
old servers. Currently mounting to old servers such as os/2 and win95
requires specifying a server "netbios name" (mount option
"servernetbiosname" is needed since netbiosnames are often ...
| May 19, 6:49 pm 2008 |
| Günter Kukkukk | Re: [2.6.27 patch] the scheduled smbfs removal
dropping smbfs in 2.6.27 will conflict with
- legacy servers like
- win9x/me
- OS/2
- even todays sold "samba NAS boxes (2.x.x)" (!!!)
- other old legacy servers like MSDOS/IBMDOS
Cifs vfs - the successor of smbfs - was _initially_
designed to only support the "NT LM 0.12" and "POSIX 2"
SMB/CIFS network dialects - NO legacy support at all.
I really can't talk about "FUSE client" - the burden
is on cifs vfs ... to also support legacy servers.
Steve French ...
| May 19, 7:40 pm 2008 |
| Alan Cox | Re: [PATCH 2/3, RFC] watchdog dev BKL pushdown
On Tue, 20 May 2008 02:20:56 -0400
In progress in two ways
- Wim was (is ?) working on a proper device layer
- I've cleaned up all the drivers and am now testing a watchdog
driver supporting library which is taking about 50% of the code out of
each driver I convert.
Alan
--
| May 20, 2:08 am 2008 |
| Arnd Bergmann | Re: [PATCH 2/3, RFC] watchdog dev BKL pushdown
I fully agree, I thought the same thing when I did the patches. I remember
that Wim had a git tree doing this, which is still active at
http://git.kernel.org/?p=linux/kernel/git/wim/linux-2.6-watchdog-experimental.git;a=co...
Unfortunately, it hasn't seen much activitity over the last two years, and
the number of watchdog drivers seems to have exploded: I count 67 of them,
including some outside of drivers/watchdog.
Wim, was there anything ...
| May 20, 1:30 am 2008 |
| Alan Cox | Re: [PATCH 2/3, RFC] watchdog dev BKL pushdown
On Tue, 20 May 2008 01:14:23 +0200
NAK. I've posted set of bigger patches which actually fix up all the
watchdog locking code - and simply adding lock/unlock kernel isn't enough
because of all the bugs in the code (it won't make it worse but it won't
fix it either).
Alan
--
| May 20, 1:42 am 2008 |
| Arnd Bergmann | Re: [PATCH 2/3, RFC] watchdog dev BKL pushdown
Are you planning this as a transitional method for
converting drivers, or are you aware of any driver that
All the ioctl numbers are compatible, so it would be good
to register the watchdog ioctl function as compat_ioctl
as well. Once all drivers are using the common abstraction,
we can also kill their COMPATIBLE_IOCTL() entries in
There are a few watchdog drivers living outside of drivers/watchdog/,
I could find:
* arch/um/drivers/harddog_kern.c
* drivers/char/ipmi/ipmi_watchdog.c
* ...
| May 20, 2:00 pm 2008 |
| Wim Van Sebroeck | Re: [PATCH 2/3, RFC] watchdog dev BKL pushdown
check the linux-2.6-watchdog-mm tree. You'll see the patches sitting there
as the uniform watchdog driver. They are thus also in the -mm tree.
I'll need to change it also to an unlocked_ioctl (and add documentation!)
but I'll attach the core code below (This does not seem to be the latest code,
because I know there was a request to change the alloc_watchdogdev code so that
it could also allocate a private data-area/space).
But it gives you an idea where I was going to. Second step would then be ...
| May 20, 8:47 am 2008 |
| Alan Cox | Re: [PATCH 2/3, RFC] watchdog dev BKL pushdown
Some watchdogs have no stop method so you need to allow for that (it
Should have been done by the driver anyway - so this is a WARN check
Races register - plus you don't need to check these cases
Also there is a problem with module locking as you don't lock down the
driver module as your fops are owned by the watchdog_dev.
I'd actually been thinking along the same lines but not paid attention
to your tree (was a bit busy without poking watchdog).
The patch below is actually quite ...
| May 20, 11:31 am 2008 |
| Christoph Hellwig | Re: [PATCH 2/3, RFC] watchdog dev BKL pushdown
Actually I'd prefer to fix this for real. This single open stuff aswell
as same set of ioctls are duplicated all over the watchdog drivers. We'd
be much better off introducing a simple watchdog layer that handles this
plus proper locking and convert drivers over to it gradually.
--
| May 19, 11:20 pm 2008 |
| Kasper Sandberg | Re: 2.6.25.4-rt2
<snip>
I have just tested this, and it breaks jackd horribly, no matter the
settings, jack ALWAYS underruns.
--
| May 19, 5:19 pm 2008 |
| Steven Rostedt | Re: 2.6.25.4-rt2
You need to set SCHED_DEBUG which is dependent on DEBUG_KERNEL.
-- Steve
--
| May 19, 6:21 pm 2008 |
| Steven Rostedt | Re: 2.6.25.4-rt2
Also, could you try 2.6.24.7-rt7.
Thanks,
-- Steve
--
| May 19, 5:49 pm 2008 |
| Steven Rostedt | Re: 2.6.25.4-rt2
Did it work with 2.6.25.4-rt1?
Also could you try this:
# sysctl kernel.sched_nr_migrate = 4
or try 2.
Thanks,
-- Steve
--
| May 19, 5:48 pm 2008 |
| MA QING A | RE: 2.6.25.4-rt2
Forgive me to ask a stupid question.
Why using the 24 mainline kernel, the time is less than using the rt-patched kernel?
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Steven Rostedt
Sent: 2008年5月20日 7:44
To: Kasper Sandberg
Cc: LKML; RT; Ingo Molnar; Thomas Gleixner
Subject: Re: 2.6.25.4-rt2
Well, the BKL is still a semaphore in 25.
For my hackbench runs, I have:
[root@bxrhel51 c]# cat ...
| May 19, 5:44 pm 2008 |
| Steven Rostedt | RE: 2.6.25.4-rt2
The test I used is a performance test, not a latency test. An RTOS
(Real-time Operating System) will sacrifice performance to achieve
determinism (low latencies). Several key features to an RT system usually
come with a performance cost.
A non RT system will perform 99% of the time faster than an RTOS. But all
it takes is that one time to miss a deadline to make an RT system crash.
An RTOS may be slightly slower, but it will not have those outliers that a
normal desktop system would ...
| May 19, 9:37 pm 2008 |
| Steven Rostedt | RE: 2.6.25.4-rt2
Hi,
[
It seems that you may be new to the lists, so I will let you know,
please do not top post. It is appropriate to either bottom post or
better yet, inline reply. See http://en.wikipedia.org/wiki/Posting_style
]
I'm not sure where you read that. With the introduction of high-resolution
timers, the HZ value isn't that important anymore. Things that might use
select or poll as timeouts will still be at the HZ frequency, but other
code that uses proper timer API will still react ...
| May 20, 6:54 am 2008 |
| Kasper Sandberg | Re: 2.6.25.4-rt2
I do not know - this is a very new box, and first time i run realtime
I am afraid i do not have this proc entry.
my .config is as follows:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25.4-rt2
# Tue May 20 01:59:59 2008
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_DEFCONFIG_LIST="arch/x86/configs/x86_64_defconfig"
# CONFIG_GENERIC_LOCKBREAK is not ...
| May 19, 5:49 pm 2008 |
| MA QING A | RE: 2.6.25.4-rt2
Thanks very much for your explanation
At the very beginning I thought the Hackbench was a latency tools, so I was very surprised to see such result.
But there's another question. When I choose the Complete Preemption -Real Time configuration, it's recommended to choose Timer Frequency ---> 1000Mhz to improve the cpu performance, does it mean cpu will cost much more during the thread context switch? Or I should choose 100Mhz in order to decrease the thread context switch and get a better ...
| May 19, 9:59 pm 2008 |
| Geert Uytterhoeven | Re: [2.6 patch] m68k: remove CVS keywords
Thanks, queued for 2.6.27.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
| May 20, 12:37 am 2008 |
| Jan Kara | Re: [2.6 patch] quota: remove CVS keywords
Acked-by: Jan Kara <jack@suse.cz>
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
| May 19, 5:43 pm 2008 |
| Mike Isely | Re: [2.6 patch] drivers/media/: remove CVS keywords
They weren't expanded in the pvrusb2 case because when the driver
sources move from my standalone / dev area into the v4l-dvb repository,
I process them with a script which does various manipulations to make
the sources suitable for the v4l-dvb repository. Among these
manipulations include unexpanding any expanded CVS (actually Subversion
in this case) keywords. So the keywords actually are used and are
accurate in the standalone context, but the processed result leaves them
unexpanded ...
| May 19, 10:19 pm 2008 |
| Chas Williams (CONTR ... | Re: [2.6 patch] drivers/atm/: remove CVS keywords
Acked-by: Chas Williams <chas@cmf.nrl.navy.mil>
--
| May 20, 6:48 am 2008 |
| David Miller | Re: [2.6 patch] drivers/atm/: remove CVS keywords
From: "Chas Williams (CONTRACTOR)" <chas@cmf.nrl.navy.mil>
Applied, thanks everyone.
--
| May 20, 2:52 pm 2008 |
| H. Peter Anvin | Re: [2.6 patch] asm-generic/int-ll64.h: always provide _ ...
*Groan* you're right. Blitering idiots... they only present __i386__
and whatever *exact* CPU you have -march= for, which of course is a
*CHANGING SET* (just __i486__, __i586__ and __i686__ isn't enough...
they seem to also have __core2__, __k8__ and $DEITY knows what else.)
The only sensible way to handle that would be to centralize that
knowledge in a header file.
-hpa
--
| May 20, 7:54 am 2008 |
| H. Peter Anvin | Re: [2.6 patch] asm-generic/int-ll64.h: always provide _ ...
Yes, it does. -march=pentium defines __i486__ as well as __i586__, and
so on.
-hpa
--
| May 19, 6:16 pm 2008 |
| Adrian Bunk | Re: [2.6 patch] asm-generic/int-ll64.h: always provide _ ...
The worst thing is how many CONFIG_'s they currently leak to userspace.
And e.g. the versions in the x86 header are therefore not the fastest
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
| May 19, 5:13 pm 2008 |
| Adrian Bunk | Re: [2.6 patch] asm-generic/int-ll64.h: always provide _ ...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
| May 19, 5:33 pm 2008 |
| H. Peter Anvin | Re: [2.6 patch] asm-generic/int-ll64.h: always provide _ ...
This is a valid point. This should be __i486__ for userspace, which is
gcc's way to tell you if you're compiling with -march=i486.
-hpa
--
| May 19, 5:17 pm 2008 |
| Adrian Bunk | Re: [2.6 patch] asm-generic/int-ll64.h: always provide _ ...
$ cat test.c
#include <stdio.h>
int main()
{
#ifdef __i486__
printf("foobarbaz\n");
#endif
return 0;
}
$ gcc -O2 -march=i486 -Wall test.c; ./a.out
foobarbaz
$ gcc -O2 -march=pentium -Wall test.c; ./a.out
$ gcc --version
gcc (Debian 4.3.0-4) 4.3.1 20080501 (prerelease)
...
$ /usr/local/DIR/gcc-3.2.3/bin/gcc -O2 -march=i486 -Wall test.c; ./a.out
foobarbaz
$ /usr/local/DIR/gcc-3.2.3/bin/gcc -O2 -march=pentium -Wall test.c; ./a.out
$ /usr/local/DIR/gcc-3.2.3/bin/gcc ...
| May 20, 2:09 am 2008 |
| Adrian Bunk | Re: [RFC: 2.6 patch] build kernel/profile.o only when re ...
In these two cases I only moved code.
And I actually moved the other code and git just decided to move the
code that stayed instead since it creates less changed lines...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
| May 20, 3:21 am 2008 |
| Andrew Morton | Re: [RFC: 2.6 patch] build kernel/profile.o only when re ...
This omits the argument's name, whereas elsewhere you have taken care
I think this could be a static inline, which is neater.
I wonder why create_prof_cpu_mask() is called only by s390. I suppose
I should I should get the historical-git tree onto this machine and
find out.
--
| May 20, 2:01 am 2008 |
| Andrew Morton | Re: [RFC: 2.6 patch] build kernel/profile.o only when re ...
umm, you also changed the declarations of profile_tick() and
profile_hits() but not of create_prof_cpu_mask().
Oh well, I'll do it.
--
| May 20, 3:34 am 2008 |
| Adrian Bunk | Re: [RFC: 2.6 patch] build kernel/profile.o only when re ...
For profile_{hits,tick}() I added dummies.
But I didn't touch create_prof_cpu_mask() at all.
I'm very unsure how many cleanups I should stuff into such patches, and
I'd actually rather expected someone telling I shouldn't have touched
the existing profile_{hits,tick}() prototypes...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
...
| May 20, 3:42 am 2008 |
| Brice Goglin | May 19, 10:52 pm 2008 | |
| Stephen Smalley | Re: LSM: MAINTAINERS points to no longer existing URL
What about the git tree listed above? Is it still being maintained?
James Morris set up a security-testing git tree that was used e.g. for
the audit conversion from direct selinux calls to using LSM hooks and
for the security= boot parameter (i.e. for changes that went beyond just
--
Stephen Smalley
National Security Agency
--
| May 20, 5:29 am 2008 |
| Chris Wright | Re: LSM: MAINTAINERS points to no longer existing URL
Yeah, I updated it last night to add this patch, a couple of other
trivial patches (Lindent-type) that were sent to me, and I would put
the proc ptrace one there as well, since it's touching core/smack/etc...
That needs coordination w/ any follow-on.
thanks,
-chris
--
| May 20, 8:55 am 2008 |
| Jean Delvare | Re: [patch 0/2] i2c-core.c: use list_for_each_entry_safe()
Applied, thanks.
--
Jean Delvare
--
| May 20, 1:07 pm 2008 |
| Harvey Harrison | Re: significance of using 2kb long byte_rev_table in lib ...
It's used in reversing the bits in a byte value as well, which your
patch breaks (see the bitrev8 users)
Harvey
--
| May 19, 5:53 pm 2008 |
| Soumyadip Das Mahapatra | Re: significance of using 2kb long byte_rev_table in lib ...
Well you can do that modifying the value of k. I commented these in the
program.
Soumya
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
| May 20, 4:05 am 2008 |
| Soumyadip Das Mahapatra | Re: [PATCH 1/2] bitreversal program
Thanks for reviewing Harvey :-)
It is a static function, so you cant use it from outside of this
Why store those things if stuffs can be done in smoother and cleaner
(using less memeory ofcourse) way!
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
| May 20, 4:01 am 2008 |
| Benoit Boissinot | Re: [PATCH 1/2] bitreversal program
A quick benchmarking (that you should have done at least one your
computer gives for 100000000 iterations):
old:
real 0m1.631s
user 0m1.628s
sys 0m0.004s
new:
real 0m5.553s
user 0m5.540s
sys 0m0.004s
So I guess there's no need to discuss this further.
regards,
Benoit
--
| May 20, 9:39 am 2008 |
| Soumyadip Das Mahapatra | Re: [PATCH 1/2] bitreversal program
Thanks Benoit for giving me such a precious advice. But sorry, I dont
have any benchmarking system in my hand(how can i have? i am just a
student, not a professional).
So if you do me a favour and kindly do it for me, please :-)
Anyway thanks again.
Soumya
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
| May 20, 8:57 am 2008 |
| Akinobu Mita | Re: [PATCH 1/2] bitreversal program
bitrev8() is static inline function in header file.
There are several users:
./drivers/isdn/gigaset/asyncdata.c
./drivers/isdn/gigaset/isocdata.c
./drivers/isdn/hisax/st5481_b.c
./drivers/rtc/rtc-s35390a.c
...
--
| May 20, 5:13 am 2008 |
| Soumyadip Das Mahapatra | Re: [PATCH 1/2] bitreversal program
Thanks for giving a reply Akinobu :-)
I forgot that bitrev8() is static in header file. Sorry for that.
Below is my new patch considering this. Cant it be applicable?
Please review it.
I know that my bitrev8() takes more instructions than that
of yours. But we have to think about faster access of cpu cache over that
of memory cache(which your bit_rev_table uses).
Thanks anyway ;-)
---Inline Attachment---
--- a/include/linux/bitrev.h 2008-04-17 08:19:44.000000000 +0530
+++ ...
| May 20, 8:25 am 2008 |
| John Hubbard | Re: [PATCH 1/2] bitreversal program
One reason it could be better, at least in some situations, is that the
above is more likely to execute directly from the CPU's instruction
cache. The table lookup appears more efficient at first, until you
consider the memory caching hierarchy.
--John Hubbard
--
| May 19, 11:53 pm 2008 |
| Benoit Boissinot | Re: [PATCH 1/2] bitreversal program
On Tue, May 20, 2008 at 5:25 PM, Soumyadip Das Mahapatra
I didn't review your patch, sorry.
But I'm pretty sure that your patch won't be considered unless you
provide benchmarks
with numbers for different CPU/architecture.
Ideally you should provide a script to test the correctness and the
performance of your
change that anyone could run on his computer.
regards,
Benoit
--
| May 20, 8:47 am 2008 |
| Holger Macht | Re: [PATCH] Fixups to ATA ACPI hotplug
Handle bay devices in dock stations
* Differentiate between bay devices in dock stations and others:
- When an ACPI_NOTIFY_EJECT_REQUEST appears, just signal uevent to
userspace (that is when the optional eject button on a bay device is
pressed/pulled) giving the possibility to unmount file systems and to
clean up. Also, only send uevent in case we get an EJECT_REQUEST
without doing anything else. In other cases, you'll get an add/remove
event because libata ...
| May 20, 6:18 am 2008 |
| Matthew Garrett | Re: [PATCH] Fixups to ATA ACPI hotplug
As long as this fixes the hang on dock removal, this looks good to me.
Acked-by: Matthew Garrett <mjg@redhat.com>
--
Matthew Garrett | mjg59@srcf.ucam.org
--
| May 20, 7:00 am 2008 |
| Holger Macht | Re: [PATCH] Fixups to ATA ACPI hotplug
I tried it, it doesn't.
Yes, see my patch.
Regards,
Holger
--
| May 20, 1:49 am 2008 |
| Matthew Garrett | Re: [PATCH] Fixups to ATA ACPI hotplug
I think we want to do the _EJ0 checking before this, otherwise we'll
generate two uevents for the same removal on some hardware. Otherwise,
looks good.
--
Matthew Garrett | mjg59@srcf.ucam.org
--
| May 20, 6:22 am 2008 |
| Matthew Garrett | Re: [PATCH] Fixups to ATA ACPI hotplug
The only issue I can see is that this one doesn't check _EJ0. Unless
that's done, you'll (on some hardware) evaluate _STA on the bay itself
rather than the device within the bay, which leads to confusion as to
whether the device has been inserted. Other than that, looks good.
Jeff's sent my patch to Linus, so can you redo this on top and I'll sign
it off?
Thanks,
--
Matthew Garrett | mjg59@srcf.ucam.org
--
| May 20, 3:20 am 2008 |
| Holger Macht | Re: [PATCH] Fixups to ATA ACPI hotplug
Ok, it seems we're currently doing the same work two times. I've also got
a patch for this. Already tested, so please have a look if this would also
match your requirements:
Handle bay devices in dock stations
* Differentiate between bay devices in dock stations and others:
- When an ACPI_NOTIFY_EJECT_REQUEST appears, just signal uevent to
userspace (that is when the optional eject button on a bay device is
pressed/pulled) giving the possibility to unmount file systems and to
...
| May 20, 12:44 am 2008 |
| Holger Macht | Re: [PATCH] Fixups to ATA ACPI hotplug
So once again:
Handle bay devices in dock stations
* Differentiate between bay devices in dock stations and others:
- When an ACPI_NOTIFY_EJECT_REQUEST appears, just signal uevent to
userspace (that is when the optional eject button on a bay device is
pressed/pulled) giving the possibility to unmount file systems and to
clean up. Also, only send uevent in case we get an EJECT_REQUEST
without doing anything else. In other cases, you'll get an add/remove
event because ...
| May 20, 6:58 am 2008 |
| Clemens Ladisch | Re: HDMI Audio Support in ALSA
(please don't top-post)
L-PCM is linear PCM, which is the sample format used by practically
_every_ sound card. IEC 60958 is AES/EBU, which is essentially S/PDIF,
which uses linear PCM samples. IEC 61937 specifies how to transport
compressed streams over S/PDIF, by pretending the data stream is a
sequence of linear PCM samples.
All of this is supported by ALSA.
Regards,
Clemens
--
| May 20, 1:10 am 2008 |
| Patrizio Bassi | Re: 2.6.25: usb-storage unknown partition table issue
Hi Abel/All,
it doesn't work at all. Actually even other pen i have were formatted in
windows and they work ok.
And, as said, parted reconize it. now i destroyed and created again with
parted, but on windows it works, on linux not.
What else to try?
Patrizio
--
| May 20, 8:50 am 2008 |
| Abel Bernabeu | Re: 2.6.25: usb-storage unknown partition table issue
Can you supply me your .config file? I am sure it is just a matter of
enabling the correct option there.
Yours, Abel.
--
| May 20, 3:44 pm 2008 |
| Patrizio Bassi | Re: 2.6.25: usb-storage unknown partition table issue
Attached.
Patrizio
| May 20, 3:47 pm 2008 |
| Pavel Machek | Re: recent 2.6.26 kernel hangs at suspend
Ok, so we have X in the mix.
Can you try if it happens if you disable Intel framebuffer driver?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| May 20, 12:48 am 2008 |
| Jeff Chua | Re: recent 2.6.26 kernel hangs at suspend
The whole problem went away after the latest git pull.
Looks like the commit below fixes the problem of failing on 2nd suspense.
I've tested whole day and it's suspending-resuming after many cycles.
Sorry, couldn't get to email whole day. Traveling. Slow train.
Thank you all for your help!!!
Jeff.
commit 860da5e578c25d1ab4528c0d1ad13f9969e3490f
Merge: 1bf9947... e948e99...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon May 19 13:30:40 2008 -0700
Merge ...
| May 20, 9:11 am 2008 |
| Alan Cox | Re: [PATCH 00/20] Implment a tty port structure and supp ...
I'm trying to work in sensible testable stages. Whats brewing at the
moment is thoughts tty_get() and tty_put() but I don't have a bootable
usable tree for that yet and there is work to be done.
--
| May 20, 11:53 am 2008 |
| Alan Cox | Re: [PATCH 00/20] Implment a tty port structure and supp ...
On Mon, 19 May 2008 18:39:43 -0400
Not currently. Its on my todo list to sort that out hence testign stuff
like stgit at the moment.
Alan
--
| May 20, 1:31 am 2008 |
| Andrew Morton | Re: [PATCH 00/20] Implment a tty port structure and supp ...
A lot depends on what else Alan is brewing up. I only have a single
tty-related patch at present (remove-is_tty.patch) and a handful of
possibly-related char driver patches
(proper-extern-for-mwave_s_mdd.patch, if-0-hpet_unregister.patch and
riscom8-remove-redundant-null-pointer-test.patch).
But if a great mountain of tty- and/or char-related patches is
forthcoming, that mountain will probably have a depencency upon your
tree. And that's OK too, as long as you don't go and bugger up ...
| May 20, 1:52 am 2008 |
| Greg KH | Re: [PATCH 00/20] Implment a tty port structure and supp ...
That's up to Alan, I don't know what he has brewing for 2.6.27.
Alan?
thanks,
greg k-h
--
| May 20, 10:23 am 2008 |
| Trent Piepho | Re: [i2c] [PATCH 1/1] i2c: align i2c_device_id
Is there any more information about this? Items in a structure should be
aligned to the alignment required by their type. Usually sizeof(x) ==
alignof(x), but not always.
I guess in this case the structures are used as a cross-platform binary on
disk representation, and so the alignment of the build host must match the
alignment of the target?
Maybe it would be better to include the alignment attribute in the
definition of kernel_ulong_t?
--
| May 19, 9:25 pm 2008 |
| Wim Van Sebroeck | Re: [PATCH 00/57] watchdog: Giant scrub
Sorry guys, I had to do electricity, ... for the new house. I have to finish
still one thing tonight and then things should be normal again for a few weeks.
I indeed have some backlog, but Alan's patches seems rather straight forward.
I'll merge them in the linux-watchdog-mm tree as soon as possible (but i'll first
sent some watchdog patches over to linus because I seemed to have missed allready
2 rc releases :-( ).
Greetings,
Wim.
--
| May 20, 1:01 am 2008 |
| Florian Fainelli | Re: [PATCH 28/57] mtx-1_wdt: clean up, coding style, unl ...
Hi Alan,
Thanks for doing this.
Acked-by: Florian Fainelli <florian.fainelli@telecomint.eu>
--
| May 20, 8:08 am 2008 |
| Andrew Morton | Re: [PATCH 00/57] watchdog: Giant scrub
Thanks, no probs. Linus may get grumpy, but he hopefully doesn't know
where you live ;)
Please do take a look at the itco_wdt-ich9do-support.patch and
watchdog-fix-booke_wdtc-on-mpc85xx-smp-system.patch which I just
resent. And we need to work out what to do about the Rusty problem,
which is also a linux-next problem.
--
| May 20, 1:37 am 2008 |
| Wim Van Sebroeck | Re: [PATCH 00/57] watchdog: Giant scrub
He definitely knows which country, but indeed not exactly where :-)
So I'll survive. My wive and children however, do know where I live and they
want to be able to move end of this summer, so it's obvious what to choose :-)
Greetings,
Wim.
--
| May 20, 8:34 am 2008 |
| Andrey Panin | Re: [PATCH 14/57] ibmasr: coding style, locking verify
Patch looks good, thank you. I'll test it as soon as I can. I need to find
unused IBM server first :)
--=20
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net
| May 19, 10:52 pm 2008 |
| Andrew Morton | Re: [PATCH 18/57] iTCO: unlocked_ioctl, coding style and ...
This runs afoul of git-watchdog and/or itco_wdt-ich9do-support.patch
Hunk #1 succeeded at 66 (offset 1 line).
Hunk #3 FAILED at 139.
Hunk #4 FAILED at 158.
Hunk #5 FAILED at 201.
Hunk #6 FAILED at 222.
Hunk #7 FAILED at 246.
Hunk #8 succeeded at 374 (offset 12 lines).
Hunk #9 FAILED at 429.
Hunk #10 FAILED at 458.
Hunk #11 FAILED at 472.
Hunk #12 FAILED at 480.
Hunk #13 FAILED at 489.
Hunk #14 FAILED at 518.
Hunk #15 FAILED at 534.
Hunk #16 FAILED at 588.
Hunk #17 succeeded at 454 ...
| May 20, 1:26 am 2008 |
| MinChan Kim | Re: [PATCH] Fix to return wrong pointer in slob
I agree
Thanks, Matt :)
--
Thanks,
MinChan Kim
--
| May 19, 7:32 pm 2008 |
| Andi Kleen | Re: aperture_64: use symbolic constants
Strictly "AMD64_" is not the correct prefix, because these registers
are generic standard AGP3 registers.
-Andi
--
| May 20, 4:20 am 2008 |
| James Morris | Re: [PATCH] security: split proc ptrace checking into r ...
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-akpm
- James
--
James Morris
<jmorris@namei.org>
--
| May 19, 5:37 pm 2008 |
| Tom Spink | Re: [RFC PATCH] Introduce filesystem type tracking
I spotted this while I was coding, and I was careful not to let it get
added to the list... If the ->init routine fails, the superblock
hasn't even been added to the list yet. The patch moves this line:
list_add_tail(&s->s_list, &super_blocks);
I had something similar earlier, but I thought it started to look
slightly messy when I discovered that dropping the spinlock would lead
to a racey ->init... but I hadn't thought of putting the mutex outside
the spinlock; the mutex ...
| May 20, 3:22 pm 2008 |
| Al Viro | Re: [RFC PATCH] Introduce filesystem type tracking
On Tue, May 20, 2008 at 02:06:42PM +0100, Tom Spink wrote:
No, you have not and no, doing that anywhere near that layer is hopeless.
a) Instances of filesystem can easily outlive all vfsmounts,
let alone their attachment to namespaces.
b) What should happen if init is done in the middle of exit?
c) Why do we need to bother, anyway?
--
| May 20, 6:43 am 2008 |
| Matthew Wilcox | Re: [RFC PATCH] Introduce filesystem type tracking
You can't take a mutex while holding a spinlock -- what if you had to
sleep to acquire the mutex?
I imagine you also don't want to hold a spinlock while calling the
->init or ->exit -- what if the fs wants to sleep in there (eg allocate
memory with GFP_KERNEL).
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde ...
| May 20, 8:34 am 2008 |
| Christoph Hellwig | Re: [RFC PATCH] Introduce filesystem type tracking
We had a discussion about filesystems starting threads without an
active instance. I suggested tracking instances and add ->init / ->exit
methods to struct file_system_type for these kinds of instances.
But we should track superblock instances, not vfsmount instances of
course. Tom, you probably don't even need a counter, emptyness
of file_system_type.fs_supers should be indication enough. And yes
we'd need locking to prevent init racing with exit.
--
| May 20, 6:57 am 2008 |
| Tom Spink | Re: [RFC PATCH] Introduce filesystem type tracking
Well, just for the reason I mentioned, I saw the posting about XFS
starting threads (when compiled into the kernel), but there's no use
of an XFS filesystem at all - there was a suggestion that something
like this be tried, so I thought I'd give it a go.
Thanks for replying!
--
Regards,
Tom Spink
--
| May 20, 6:50 am 2008 |
| Tom Spink | Re: [RFC PATCH] Introduce filesystem type tracking
Hi,
I'm just adding people to CC here, but also I had a couple of thoughts
after reviewing my own code.
I see that do_kern_mount is encapsulated with the BKL, but would it be
wise to introduce a lock (e.g. a mutex) now for reading and updating
nr_mounts (and hence calling ->init), rather than wait for the BKL
removal to come round here?
Also, have I got all the cases where a filesystem is unmounted,
because I now see umount_tree, and am wondering if decrementing the
nr_mounts field ...
| May 20, 6:06 am 2008 |
| Matthew Wilcox | Re: [RFC PATCH] Introduce filesystem type tracking
Hi Tom,
I spotted one definite bug; on failure, you leave the superblock on
the super_blocks list.
Your locking may well be correct, but it has the hallmarks of being "a bit
tricky" and a bit tricky means potentially buggy. How about doing the
nesting the other way round, ie take the mutex first, then the spinlock?
The code needs a bit of tweaking because you don't want to put the
superblock on any list where it can be found until it's fully
sget is a little more complex ... the ...
| May 20, 3:00 pm 2008 |
| Tom Spink | Re: [RFC PATCH] Introduce filesystem type tracking
Hi Guys,
I've taken some more time to go over the locking semantics. I wrote a
quick toy filesystem to simulate delays, blocking, memory allocation,
etc in the init and exit routines - and with an appropriately large
amount of printk's everywhere, I saw a quite a few interleavings.
I *think* I may have got it right, but please, let me know what you
think! The only thing that I think may be wrong with this patch is
the
spin_lock/unlock at the end of sget, where the superblock ...
| May 20, 2:08 pm 2008 |
| Tom Spink | Re: [RFC PATCH] Introduce filesystem type tracking
Hi Guys,
Thanks for looking! So I've had another go - this time taking the
superblock approach, and hopefully I've got the locking right too.
Let me know what you think (or if I'm still barking up the wrong
tree)!
---
From: Tom Spink <tspink@gmail.com>
Date: Tue, 20 May 2008 16:04:51 +0100
Subject: [PATCH] Introduce on-demand filesystem initialisation
This patch adds on-demand filesystem initialisation capabilities to the VFS,
whereby an init routine will be executed on first use of a ...
| May 20, 8:18 am 2008 |
| Tom Spink | Re: [RFC PATCH] Introduce filesystem type tracking
Oh no! This is bad. I really need to devise some script to stress
test my code - and also make myself pay attention to what I'm doing.
Sorry for the noise, guys.
--
Tom Spink
--
| May 20, 8:36 am 2008 |
| Peter Oberparleiter | Re: [PATCH] consolidate all within() implementations
Now that every line using a within() has to be changed anyway, it could
Well, between the unsigned long and the void * version, there's not that
much of a difference in the number of casts. So here goes #3:
--
From: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
This patch consolidates a number of different implementations of the
within() function which checks whether an address is within a specified
address range. Apart from parameter typing, existing implementations can
be ...
| May 20, 8:42 am 2008 |
| Peter Oberparleiter | Re: [PATCH] consolidate all within() implementations
I was hoping to get by without the spray of unsigned long casts that
entails the enforcement of this specific parameter type, seeing that
each implementation had it's own combination of longs and void *.
On the other hand, an inline function would of course be the cleaner
approach, so if the code owners agree, here goes take #2:
--
From: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
This patch consolidates a number of different implementations of the
within() function which ...
| May 20, 1:08 am 2008 |
| Andrew Morton | Re: [PATCH] consolidate all within() implementations
The kernel's use of unsigned long to represent pointers sometimes makes
sense, but often gets us into a mess. It's OK in bootup code which
fiddles with memory map layout because there is no reason why such
code will ever dereference any of the addresses.
But I don't think we can assume this usage pattern when creating a
kernel-wide facility in kernel.h.
So yes, I do think that an address-comparison tool like this should
And you've had to add a great pile of casts anwyay?
--
| May 20, 2:45 am 2008 |
| Peter Oberparleiter | Re: [PATCH 1/7] kernel: call constructors
In that case, no constructors would be called and as a result the gcov
debugfs directory would be empty. This should be easily fixable as the
case arises though. I've re-checked arch/*/vmlinux* and all of those
linker scripts seem to include asm-generic/vmlinux.lds.h at most via
Includes asm-generic/vmlinux.lds.h either via vmlinux-sun3.lds or
Includes asm-generic/vmlinux.lds.h either via vmlinux_32.lds.S or
Includes asm-generic/vmlinux.lds.h either via uml.lds.S or ...
| May 19, 11:45 pm 2008 |
| Stephen Rothwell | Re: linux-next: Tree for May 19
Hi Thomas,
It was not intentional, I missed it sneaking in. It seems to be gone
again today.
--=20
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
| May 19, 9:19 pm 2008 |
| Herbert Xu | Re: [BUILD_FAILURE] linux-next: Tree for May 19 - build ...
Sorry, I forgot to push :) It's there now so should show up tomorrow.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
| May 19, 11:40 pm 2008 |
| Dave Young | Re: [2.6.26-rc2-mm1] sync to speed up?
I'm using ext3. Jiri's patch fixes the my problem. Seems the problem
I didn't notice same thing on 2.6.26-rc2, is it necessary for me to test on it?
Regards
dave
--
| May 19, 7:14 pm 2008 |
| Dave Young | May 19, 7:16 pm 2008 | |
| Mike Snitzer | Re: [RFC][PATCH] md: avoid fullsync if a faulty member m ...
Hi Neil,
We're much closer. The events_cleared is symmetric on both the failed
and active member of the raid1. But there have been some instances
where the md thread hits a deadlock during my testing. What follows
is the backtrace and live crash info:
md0_raid1 D 000002c4b6483a7f 0 11249 2 (L-TLB)
ffff81005747dce0 0000000000000046 0000000000000000 ffff8100454c53c0
000000000000000a ffff810048fbd0c0 000000000000000a ffff810048fbd0c0
ffff81007f853840 000000000000148e ...
| May 20, 8:30 am 2008 |
| Mike Snitzer | Re: [RFC][PATCH] md: avoid fullsync if a faulty member m ...
Err, that block is in bitmap_startwrite()...
Mike
--
| May 20, 8:33 am 2008 |
| Alan Cox | Re: [PATCH, RFC] Char dev BKL pushdown v2
Right. Or two ioctls against each other unless one sleepers, or against
random other parts of the kernel which still use the BKL - eg fasync,
Exactly.
Alan
--
| May 20, 1:26 am 2008 |
| Jeff Dike | Re: [PATCH, RFC] Char dev BKL pushdown v2
There's the case where one thread is calling ioctl on the new
descriptor before open (in other thread) has returned (it's malicious
and trying to oops you, it's accidentally trying to operate on a
closed descriptor, etc). It might hit the window between the
descripor being installed and open returning.
Jeff
--
Work email - jdike at linux dot intel dot com
--
| May 19, 7:10 pm 2008 |
| Zhu Yi | Re: [ipw3945-devel] ieee80211: unable to handle kernel N ...
This is a known mac80211 bug. The fix (might not be the final one) is
here:
http://marc.info/?l=linux-wireless&m=121120929012836&w=2
Thanks,
-yi
--
| May 19, 8:54 pm 2008 |
| Ivo van Doorn | Re: [PATCH 11/15] rfkill: add notifier chains support
Besides the spelling comments from Thomas, patch is fine with me.
--
| May 20, 3:09 am 2008 |
| Ivo van Doorn | May 20, 3:08 am 2008 | |
| Ivo van Doorn | May 20, 3:09 am 2008 | |
| Henrique de Moraes H ... | Re: [PATCH 15/15] rfkill: document rw rfkill switches an ...
Yes, but IMHO we should do that in a future patch. That patch will touch
every rfkill driver, so I'd rather we do that later. IMHO it is best to get
the most important stuff merged, first...
Then, in that future patch, we change the API, fix all in-tree drivers using
that API, and update the documentation to match the new API. For now, we
update the documentation to match the current API.
What do you think?
--
"One disk to rule them all, One disk to find them. One disk to bring
...
| May 20, 8:54 am 2008 |
| Ivo van Doorn | Re: [PATCH 15/15] rfkill: document rw rfkill switches an ...
Sounds good to me. :)
Ivo
--
| May 20, 10:18 am 2008 |
| Ivo van Doorn | May 20, 3:09 am 2008 | |
| Ivo van Doorn | May 20, 3:08 am 2008 | |
| Ivo van Doorn | Re: [PATCH 15/15] rfkill: document rw rfkill switches an ...
Wasn't it the plan to send the current hardware state as rfkill registration argument,
so we can force drivers to send a valid state to rfkill?
Ivo
--
| May 20, 3:09 am 2008 |
| Ivo van Doorn | May 20, 3:08 am 2008 | |
| Ivo van Doorn | May 20, 3:08 am 2008 | |
| Ivo van Doorn | May 20, 3:08 am 2008 | |
| Ivo van Doorn | Re: [PATCH 14/15] rfkill: do not allow userspace to over ...
I don't quite agree here. The SW_RFKILL_ALL key is the one send by thinkpad-acpi,
what makes that key so special that is has to be handled differently then a key
that only controls a single radio type?
All keys should have the same rules when it is pressed, so either all keys should
--
| May 20, 3:09 am 2008 |
| Ivo van Doorn | Re: [PATCH 09/15] rfkill: add the WWAN radio type
If WiMAX is a subset of the WWAN technology, shouldn't we replace WiMAX completely
in rfkill? Otherwise people might get ideas and add the other technologies seperately as well. ;)
Other then that, the addition of WWAN is fine with me. :)
--
| May 20, 3:08 am 2008 |
| David Miller | Re: [PATCH] net/ipv4/arp.c: Use the exported hex_asc fro ...
From: Harvey Harrison <harvey.harrison@gmail.com>
Good idea, I'll revert, Denis can you generate a new patch?
Thanks.
--
| May 20, 3:45 pm 2008 |
| Harvey Harrison | Re: [PATCH] net/ipv4/arp.c: Use the exported hex_asc fro ...
From: Harvey Harrison <harvey.harrison@gmail.com>
Subject: [PATCH] net: use common hex_asc helpers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
Something like this.
net/ipv4/arp.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 418862f..9b539fa 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -1288,7 +1288,6 @@ static void arp_format_neigh_entry(struct seq_file *seq,
struct neighbour *n)
...
| May 20, 3:41 pm 2008 |
| David Miller | Re: [PATCH] net/ipv4/arp.c: Use the exported hex_asc fro ...
From: Denis Cheng <crquan@gmail.com>
Applied, thanks.
--
| May 20, 3:36 pm 2008 |
| Harvey Harrison | Re: [PATCH] net/ipv4/arp.c: Use the exported hex_asc fro ...
You may want to use the hex_asc_hi, hex_asc_lo helpers to do the
mask/shifts for you.
Harvey
--
| May 20, 3:40 pm 2008 |
| Sergei Shtylyov | Re: [PATCH 22/40] ide-floppy: start DMA engine in ideflo ...
Hello.
Good. I have long ago noticed that DMA is started too early in ide-floppy
which is known to cobfuse some chips (like PDC20246) and was going to do a
May be too early still... ide-cd does this after writing the command packet.
WBR, Sergei
--
| May 20, 4:00 am 2008 |
| Patrick McHardy | Re: asterisk hangs with RT priority
The problem is gone in the current -git tree.
--
| May 20, 2:59 am 2008 |
| Avi Kivity | Re: [PATCH] Make LIST_POISON less deadly
Makes sense. I'll send out v3.
Is there a similar range on i386?
--
error compiling committee.c: too many arguments to function
--
| May 20, 4:34 am 2008 |
| Ingo Molnar | Re: [PATCH] Make LIST_POISON less deadly
i dont think it's worth going for 32-bit here. On 32-bit the poison
value gets skewed into hard to recognize values which might make oops
analysis harder. Lets start small with 64-bit-only - there it's a quite
plausible change, besides the exponentially larger address space on
64-bit it might realistically happen that an attacker can control a
32-bit-is offset but not a full 64-bit offset.
Ingo
--
| May 20, 5:04 am 2008 |
| Avi Kivity | Re: [PATCH] Make LIST_POISON less deadly
I found some workaround (define the variable only on archs that want it,
While I agree with you, I defer to Ingo on this.
--
error compiling committee.c: too many arguments to function
--
| May 20, 12:06 am 2008 |
| Andi Kleen | Re: [PATCH] Make LIST_POISON less deadly
You could make a 3 page fixmap and point to the middle page. 3 because
negative offsets are also especially importants for list_heads due to
list_entry
-Andi
--
| May 20, 5:04 am 2008 |
| Andi Kleen | Re: [PATCH] Make LIST_POISON less deadly
Don't think so. Address space is too precious here.
What you could probably do is to unmap one fixed page in some range
that is always split to 4K pages anyways and use that. Perhaps somewhere
in the 640k-1MB range. But if you're unlucky this might require a
variable, not a constant.
-Andi
--
| May 20, 4:49 am 2008 |
| Avi Kivity | Re: [PATCH] Make LIST_POISON less deadly
It's a potential security hole. You need to find a list corruption
first. The patch prevents escalation of the oops into a code injection.
i386 is fixable, though it will take more work than x86_64.
--
error compiling committee.c: too many arguments to function
--
| May 20, 9:50 am 2008 |
| Pavel Machek | Re: [PATCH] Make LIST_POISON less deadly
"Security hole unless arch maintainer does _foo_" sounds
scary. Especially when i386 is hard to fix...
(And very nice catch, btw).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| May 20, 9:47 am 2008 |
| Andi Kleen | Re: [PATCH] Make LIST_POISON less deadly
Hmm, thought I had sent a reply earlier, but don't see it so again.
My apologies if you see it twice.
The problem with your address values is that they're non canonical
and will result in a #GP, not #PF and oops handler cannot display
the address which will make them much less obvious.
I would rather use a guaranteed to be unmapped but canonical
address like in the ffffc10000000000 - ffffc1ffffffffff range
so that you still get page faults.
-Andi
--
| May 20, 4:24 am 2008 |
| Avi Kivity | Re: [PATCH] Make LIST_POISON less deadly
I guess a fixmap would work for this. But then the offsets added to
that page would need to be limited to 4K.
--
error compiling committee.c: too many arguments to function
--
| May 20, 4:52 am 2008 |
| Andrew Morton | Re: [PATCH] eCryptFS: fix missed mutex_unlock
Better to do it this way, I think:
--- a/fs/ecryptfs/crypto.c~ecryptfs-fix-missed-mutex_unlock
+++ a/fs/ecryptfs/crypto.c
@@ -1906,9 +1906,9 @@ int ecryptfs_get_tfm_and_mutex_for_ciphe
goto out;
}
}
- mutex_unlock(&key_tfm_list_mutex);
(*tfm) = key_tfm->key_tfm;
(*tfm_mutex) = &key_tfm->key_tfm_mutex;
out:
+ mutex_unlock(&key_tfm_list_mutex);
return rc;
}
_
Holding the lock for an additional few instructions may not be strictly
needed, but we might avoid the ...
| May 20, 12:28 am 2008 |
| Cyrill Gorcunov | Re: [PATCH] eCryptFS: fix missed mutex_unlock
On Tue, May 20, 2008 at 11:28 AM, Andrew Morton
Good idea, thanks! Could you update the patch, please?
--
| May 20, 2:46 am 2008 |
| Rafael J. Wysocki | Re: [PATCH 0/4] Fix forcedeth hibernate/wake-on-lan problems
That may be worth some investigation. However, since that doesn't work on
You can try s2ram to bring the VGA to life, I think
Thanks,
Rafael
--
| May 20, 3:39 pm 2008 |
| Rafael J. Wysocki | Re: [Bug #10678] 2.6.26-rc1: warnings from sysfs, blueto ...
Thanks,
Rafael
--
| May 20, 3:18 pm 2008 |
| Rafael J. Wysocki | Re: 2.6.26-rc2-git5: Reported regressions from 2.6.25
Bugzilla entry updated with the patch link.
Thanks,
Rafael
--
| May 20, 2:56 pm 2008 |
| Lukas Hejtmanek | Re: [Bug #10630] USB devices plugged into dock are not d ...
done.
http://bugzilla.kernel.org/show_bug.cgi?id=10630
--
Lukáš Hejtmánek
--
| May 20, 4:17 am 2008 |
| Alan Stern | Re: [PATCH] Re: [Bug #10713] ehci splatter in 2.6.26-rc2
That must be it. This code base is getting too large to keep in a
single mind...
Looks like you should submit your patch.
Alan Stern
--
| May 20, 8:31 am 2008 |
| Oliver Neukum | Re: [Bug #10630] USB devices plugged into dock are not d ...
Aha. Thanks.
Please recompile without CONFIG_USB_SUSPEND
Regards
Oliver
--
| May 20, 4:27 am 2008 |
| Oliver Neukum | Re: [Bug #10630] USB devices plugged into dock are not d ...
Can you please also post your .config with which this problem happens?
Regards
Oliver
--
| May 20, 3:57 am 2008 |
| Lennert Buytenhek | [PATCH] Re: [Bug #10713] ehci splatter in 2.6.26-rc2
This patch appears to fix it:
The Orion EHCI root hub does have a built-in Transaction Translator.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Index: linux-2.6.26-rc3/drivers/usb/host/ehci-orion.c
===================================================================
--- linux-2.6.26-rc3.orig/drivers/usb/host/ehci-orion.c
+++ linux-2.6.26-rc3/drivers/usb/host/ehci-orion.c
@@ -115,6 +115,8 @@ static int ehci_orion_setup(struct usb_h
if (retval)
return retval;
...
| May 20, 3:50 am 2008 |
| Alan Stern | Re: [PATCH] Re: [Bug #10713] ehci splatter in 2.6.26-rc2
Pardon me for being puzzled, but I don't see how that change could
possibly have any effect on the problem you saw.
Nor do I see how the patch you identified could have caused any
problems. That has_tt flag isn't used anywhere in ehci-hcd (it is only
ever set, never read), and the only place it is used in usbcore is for
adjusting the root hub's device descriptor.
Alan Stern
--
| May 20, 7:04 am 2008 |
| Alan Stern | Re: [PATCH] Re: [Bug #10713] ehci splatter in 2.6.26-rc2
A similar change is needed in other bus-glue files. I have put
together a patch to take care of them all; it will be posted later
today.
Alan Stern
--
| May 20, 9:48 am 2008 |
| Lennert Buytenhek | Re: [PATCH] Re: [Bug #10713] ehci splatter in 2.6.26-rc2
Well. I just re-tested it a couple more times to be sure, and the
"hcd->has_tt = 1;" line does make all the difference in the world when
it comes to getting oopses on plugging in low speed USB devices on this
board. So if you don't understand what's going on then I guess I don't
Maybe this code in drivers/usb/core/hub.c has something to do with
it?
switch (hdev->descriptor.bDeviceProtocol) {
case 0:
break;
case 1:
...
| May 20, 7:59 am 2008 |
| David Brownell | Re: [Bug #10713] ehci splatter in 2.6.26-rc2
I'm guessing that this has a version of the ARC/TDI/whoever-now-owns-it
IP, on a PCI bus? But without the integrated TT option?
If this is on a PCI bus, then try removing the ehci-pci.c line added
by that patch, see if that helps.
- Dave
--
| May 19, 11:13 pm 2008 |
| Lennert Buytenhek | Re: [Bug #10713] ehci splatter in 2.6.26-rc2
A bisect turns up this:
7329e211b987a493cbcfca0e98c60eb108ab42df is first bad commit
commit 7329e211b987a493cbcfca0e98c60eb108ab42df
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Thu Apr 3 18:02:56 2008 -0400
USB: root hubs don't lie about their number of TTs
Currently EHCI root hubs enumerate with a bDeviceProtocol code
indicating that they possess a Transaction Translator. However the
vast majority of controllers do not; they rely on a ...
| May 19, 5:18 pm 2008 |
| Lennert Buytenhek | Re: [Bug #10713] ehci splatter in 2.6.26-rc2
No, this is not on a PCI bus -- this is the on-chip EHCI controller
of the Marvell Orion ARM SoC (ehci-orion.c.)
I have honestly no idea whether the IP is in-house or third-party.
--
| May 20, 1:25 am 2008 |
| James Morris | Re: [PATCH] selinux: reorder inode_security_struct to in ...
Done in
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-akpm
--
James Morris <jmorris@namei.org>
--
| May 19, 5:01 pm 2008 |
| Yinghai Lu | Re: kernel boot hangs after x86: insert_resorce for lapi ...
On Mon, May 19, 2008 at 6:24 PM, Ciaran McCreesh
seems acpi pnp resource cause some problem....
please try attached patch and send out /proc/mtrr
YH
| May 19, 7:48 pm 2008 |
| Yinghai Lu | Re: kernel boot hangs after x86: insert_resorce for lapi ...
On Mon, May 19, 2008 at 5:44 PM, Ciaran McCreesh
the iomem allocation seems good...
can you send out /proc/iomem?
Thanks
YH
--
| May 19, 6:22 pm 2008 |
| Ciaran McCreesh | Re: kernel boot hangs after x86: insert_resorce for lapi ...
On Mon, 19 May 2008 19:48:38 -0700
The patch doesn't help I'm afraid.
/proc/mtrr is:
reg00: base=3D0x100000000 (4096MB), size=3D 512MB: write-back, count=3D1
reg01: base=3D0x00000000 ( 0MB), size=3D2048MB: write-back, count=3D1
reg02: base=3D0x80000000 (2048MB), size=3D1024MB: write-back, count=3D1
reg03: base=3D0xc0000000 (3072MB), size=3D 256MB: write-back, count=3D1
reg04: base=3D0xd0000000 (3328MB), size=3D 128MB: write-back, count=3D1
Thanks,
--=20
Ciaran McCreesh
| May 19, 8:16 pm 2008 |
| Yinghai Lu | Re: kernel boot hangs after x86: insert_resorce for lapi ...
can you boot with pnpacpi=off ?
YH
--
| May 19, 8:25 pm 2008 |
| Yinghai Lu | Re: kernel boot hangs after x86: insert_resorce for lapi ...
On Mon, May 19, 2008 at 8:16 PM, Ciaran McCreesh
sorry, please send /proc/iomem
after check request_resource and insert resource...
it seems if you insert or request one small one, and request big one,
then only have big one, but if you insert the big one, the small one
will because big one's child...
so at that case, could be pnp res return from acpi (dsdt) is bigger
than e820 region...
so it seems the offending patch just reveal problem cause by pnp code.
YH
--
| May 19, 8:22 pm 2008 |
| Ciaran McCreesh | Re: kernel boot hangs after x86: insert_resorce for lapi ...
--MP_//82HB2HDuXSkJVkgYHqc5G7
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Sun, 18 May 2008 20:43:09 -0700
dmesg with debugging attached.
Thanks.
--=20
Ciaran McCreesh
--MP_//82HB2HDuXSkJVkgYHqc5G7
Content-Type: application/octet-stream; name=dmesg-pci-debug.txt.gz
Content-Transfer-Encoding: base64
Content-Disposition: attachment; ...
| May 19, 5:44 pm 2008 |
| Ciaran McCreesh | Re: kernel boot hangs after x86: insert_resorce for lapi ...
On Mon, 19 May 2008 18:22:00 -0700
00000000-0009ffff : pnp 00:09
000f0000-000fffff : pnp 00:09
00100000-d7feffff : pnp 00:09
d7ff0000-d7ffffff : pnp 00:09
d8000000-dfffffff : PCI Bus 0000:01
d8000000-dfffffff : 0000:01:05.0
e0000000-efffffff : PCI MMCONFIG 0
e0000000-efffffff : pnp 00:08
fdb00000-fdbfffff : PCI Bus 0000:03
fdc00000-fdcfffff : PCI Bus 0000:03
fdcff000-fdcff0ff : 0000:03:05.0
fdcff000-fdcff0ff : 8139too
fdd00000-fddfffff : PCI Bus 0000:02
fdd00000-fdd1ffff : ...
| May 19, 6:24 pm 2008 |
| Adrian Bunk | Re: references from Makefiles to non-existent CONFIG variables
This PMC MSP71xx platform in the kernel was AFAIR never in a usable
state (read: even compilation fails).
Marc, will you (or anyone else) bring it into shape or should I send a
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
| May 20, 7:07 am 2008 |
| Mauro Carvalho Chehab | Re: mplayer v4l hangs in 2.6.25.2/4 (likely regression)
Hi Arjan,
Sorry for a late answer. I'm currently travelling on a short vacations.
On Sat, 17 May 2008 13:20:50 -0700
I have a trivial patch to fix this already. I'll add it soon to my tree and
The fix looks sane. I prefer to just remove the lock call from bttv, instead of
calling __videobuf_mmap_setup() and make this symbol global. The better is to
avoid locking inside the drivers, except during the interrupts, and inside
videbuf code. This is what we're doing on the other ...
| May 20, 4:49 am 2008 |
| Arjan van de Ven | Re: mplayer v4l hangs in 2.6.25.2/4 (likely regression)
On Tue, 20 May 2008 08:49:11 -0300
but it's more complex than I want to deal with right now.. lets changing
Sure
Linus, please apply this bugfix:
From: Arjan van de Ven <arjan@linux.intel.com>
Subject: [PATCH] Fix a deadlock in the bttv driver
vidiocgmbuf() does this:
mutex_lock(&fh->cap.vb_lock);
retval = videobuf_mmap_setup(&fh->cap, gbuffers, gbufsize,
V4L2_MEMORY_MMAP);
and videobuf_mmap_setup() then just does
...
| May 20, 9:53 am 2008 |
| Oleg Nesterov | Re: [PATCH 1/3] signals: fix sigqueue_free() vs __exit_s ...
Yes, other patches are not bugfixes.
Probably this fix is not "urgent" too, the race is very old and nobody
complained.
Oleg.
--
| May 20, 2:17 am 2008 |
| Andrew Morton | Re: [PATCH 1/3] signals: fix sigqueue_free() vs __exit_s ...
afacit this is the only needed-in-2.6.26 patch from these two
three-patch series, yes?
--
| May 19, 11:33 pm 2008 |
| Dmitry Torokhov | Re: [PATCH] Add support for HTC Shift Touchscreen
No, this will not work.. next time you open the device you won't have
IRQ anymore. You need the opposite of outb_p(DEVICE_ENABLE,
HTCPEN_PORT_INIT); here.
--
Dmitry
--
| May 19, 6:49 pm 2008 |
| Pau Oliva Fora | Re: [PATCH] Add support for HTC Shift Touchscreen
It is actually working; it also works after suspend/resume without any
issues.
I currently do not know a safe way of disabling the device, as HTC did
not offer any specifications or datasheet when I requested, so everything
in the driver has been reverse engineered.
Let me know if you think it's ok to leave it as is, otherwise I'll try
to find the proper way to disable the device (it should not be much
different than the way of enabling it).
Best Regards,
Pau Oliva
--
| May 20, 4:02 am 2008 |
| Dmitry Torokhov | Re: [PATCH] Add support for HTC Shift Touchscreen
You need to close the device. Making evdev a module and unloading it
If you can't find the way to disable device then you need to revert to
the old way, with enabling it in _probe() and freein irq in _remove(),
you just need to make sure that you free_irq() first and then call
input_unregister_device().
Also, like Andrey said, we might consider using DMI table so we dont
poke IO ports on random boxes. Oh, and one more thing, you need to
reserve the IO ports your driver is using with ...
| May 20, 6:54 am 2008 |
| Andrey Panin | Re: [PATCH] Add support for HTC Shift Touchscreen
Poking on random ioports isn't very nice detection method.=20
--=20
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net
| May 20, 5:37 am 2008 |
| Pau Oliva Fora | Re: [PATCH] Add support for HTC Shift Touchscreen
Finding a way to disable it was easy :-)
Thanks Andrey for the suggestion of using DMI table, see the patch below.
Should I keep the old device detection using IO port stuff or just
dmi_check_system() should be fine?
> Oh, and one more thing, you need to
> reserve the IO ports your driver is using with request_region.
Thanks, I implemented this too in the patch below, but I have a problem:
I can successfully reserve 0x250-0x251, but 0x68 and 0x6c are already
reserved by the ...
| May 20, 12:09 pm 2008 |
| Andrew Morton | Re: Possible partial miss in pages needed for zone's mem ...
I looked in there for 30 seconds and collapsed in confusion over which
variables are in which units.
Hint: never ever name a variable or a /proc file or your cat
or anything else anything dimensionless like "size". It can always be
replaced with something which communicates its units. zones_nrbytes,
zholes_nrpages, etc.
--
| May 19, 11:19 pm 2008 |
| KAMEZAWA Hiroyuki | Re: Possible partial miss in pages needed for zone's mem ...
On Mon, 19 May 2008 23:19:37 -0700
Hmm, size * sizeof(struct page) is multiple of PAGE_SIZE in many case.
Becasue "size" is always alinged to (1 << MAX_ORDER -1) (I believe...).
ex.) In x86 case,
(1 << (MAX_ORDER(11) - 1)) * 4 (sizeof(long)) = (1 << 12) = PAGE_SIZE.
But not sure on other archs with various params.
I think above fix is correct.
Thanks,
-Kame
--
| May 20, 12:02 am 2008 |
| Marcel Holtmann | Re: [RFC] make wext wireless bits optional and deprecate them
patch looks good to me.
Regards
Marcel
--
| May 20, 10:28 am 2008 |
| Johannes Berg | Re: [RFC] make wext wireless bits optional and deprecate them
I have filed a patch to fix HAL to use the canonical SIOCGIWNAME at
https://bugs.freedesktop.org/show_bug.cgi?id=3D16037. Any further
objections to this patch?
johannes
| May 20, 10:15 am 2008 |
| Jeremy Fitzhardinge | Re: [Bug 10732] REGRESSION: 2.6.26-rc2-git4: X server fa ...
I got rid of a bunch of _AT() uses because the constants aren't used in
.S files anywhere. Also, I couldn't see how to represent a 64-bit
constant in assembler, so I wasn't sure of their correctness (the as
__PHYSICAL_LOW_BITS is a bit more elegant than what I did there (the
problem is getting a physaddr_t-width PAGE_MASK). But the formulation
in my patch certainly works.
J
--
| May 20, 12:32 am 2008 |
| Linus Torvalds | Re: [Bug 10732] REGRESSION: 2.6.26-rc2-git4: X server fa ...
.. and in addition to that, perhaps something like this too?
Making the actual _PAGE_XYZ bits be of the proper type makes using bitops
and negation on them automatically DTRT, so that we don't need those
insane casts in pte_mkclean() and friends.
Again, totally untested, but we really should just get the types right,
instead of getting them wrogn and then messing around with various silly
and incorrect work-arounds for the fact that we got them wrong.
And while it's untested - if ...
| May 19, 7:33 pm 2008 |
| Hugh Dickins | Re: [Bug 10732] REGRESSION: 2.6.26-rc2-git4: X server fa ...
That's very much what I'd prefer too. Jeremy has patches in Ingo's
tree to do that, which have been tested - though perhaps not in
combination with the PAT pte_modify changes. I did check that they're
Yes, Jeremy makes it a pteval_t. (My builds and Ingo's builds succeed,
but I've not worked out how that goes down in assembly: there was an
Yes, I'm highly resistant to taking untested patches here. The two-liner
I sent last night was about my fifth attempt to get it working, and I ...
| May 19, 9:14 pm 2008 |
| Jeremy Fitzhardinge | Re: [Bug 10732] REGRESSION: 2.6.26-rc2-git4: X server fa ...
That's pretty close to the core of my patches (just reposted), which
have been cooking in x86.git for a week or so.
One thing I'd take from your patch is something like your
__PHYSICAL_LOW_BITS definition, since its a bit clearer than what I
did. (I haven't updated my patch before posting just because I wanted
J
--
| May 20, 12:31 am 2008 |
| Andrew Morton | Re: [PATCH] RTC: M41T80: Century Bit support
On Tue, 20 May 2008 20:51:56 +0100 (BST)
It's be saner for me to drop it and have you resend when appropriate.
The chances of me being able to succesfully correlate this patch and
something called "the flags" at some time in the future are less than
100% ;)
--
| May 20, 1:03 pm 2008 |
| Maciej W. Rozycki | Re: [PATCH] RTC: M41T80: Century Bit support
Well, Andrew has applied this patch to the -mm tree now and after a bit
of thinking I have made up my mind and decided we should keep the patch.
This is an I2C device which means it will always only be explicitly
requested by platform code. This is an opportunity for the platform to
express the will and the way to use the century bit.
I'll cook-up a follow-on patch as soon as the SWARM bits propagate to
upstream, to add a set of flags that will let platforms specify the
desired way the ...
| May 20, 12:51 pm 2008 |
| Maciej W. Rozycki | Re: [PATCH] RTC: M41T80: Century Bit support
You mean like 99.9% less? ;-) Some people call it "epsilon".
Maciej
--
| May 20, 1:30 pm 2008 |
| Jesper Juhl | Re: [GIT pull] x86 fixes for 2.6.26
Not if I can help it, no. I just couldn't work out from the git docs
how to do it otherwise when working with kernel.org and bare trees.
<snip>
That worked beautifully. Thanks a lot.
Stephen: There is now a trivial-2.6.git tree at
git://git.kernel.org/pub/scm/linux/kernel/git/juhl/trivial-2.6.git
with a 'next' branch that you can pull into linux-next, please.
git://git.kernel.org/pub/scm/linux/kernel/git/juhl/trivial-2.6.git next
Once we hit a merge window I'll rename the 'next' ...
| May 19, 5:01 pm 2008 |
| Guennadi Liakhovetski | Re: [PATCH 3/4] spi: Add OF binding support for SPI busses
Hm, are there actually such SPI _controllers_ that use SPI data to toggle
chipselects? I.e., you would have to send your SPI client data (for the
RTC or whatever) plus some extra bytes or with some modifications, and
this extra information would then be intercepted by the SPI _controller_
itself and only client data would be sent out? Isn't what you're
describing really a case of an SPI bridge, as you also call it below? In
which case, I think, it might make sense to cleanly ...
| May 20, 8:26 am 2008 |
| Grant Likely | Re: [PATCH 3/4] spi: Add OF binding support for SPI busses
On Tue, May 20, 2008 at 9:26 AM, Guennadi Liakhovetski
Yes! There really are!!! One case I've been told of is an SPI bridge
Hmmm, yeah, I suppose it is possible; but if it is internal to the bus
controller then it can also be handled internally by the bus
controller driver and probably won't need to be reflected in the
It also needs to describe layouts which require SPI transfers in a
particular order. For example, if you're doing 2 SPI messages (M1 and
M2) to 2 different SPI devices ...
| May 20, 8:48 am 2008 |
| Grant Likely | Re: [PATCH 3/4] spi: Add OF binding support for SPI busses
On Mon, May 19, 2008 at 10:30 AM, Guennadi Liakhovetski
Hurrmmmm...
I'm not so fond of this approach. cs-parent doesn't seem to make much
sense to me. It might be better to have a cs-handler property on the
SPI bus node instead of on the SPI slave nodes, but even then it
leaves a number of questions about what it really means. In some
cases it would be overkill. For example, if the SPI node simply had
multiple GPIO lines then an extra cs-parent node wouldn't be needed at
all. Then there ...
| May 19, 10:13 pm 2008 |
| Jamie Lokier | Re: [PATCH 4/4] ext4: call blkdev_issue_flush on fsync
ISTR fsync() on ext3 did not always force a commit, if in-place data
writes did not change any metadata. Has this been fixed in ext4 but
not ext3 then?
Does WRITE_BARRIER always cause a flush? It does not have to
according to Documentation/block/barrier.txt. There are caveats about
tagged queuing "not yet implemented" in the text, but can we rely on
that? The documentation is older than the current implementation;
those caveats might no longer apply.
-- Jamie
--
| May 20, 8:43 am 2008 |
| Jens Axboe | Re: [PATCH 4/4] ext4: call blkdev_issue_flush on fsync
It does, if you use ordered tags then that assumes write through
caching (or ordered tag + drain + flush after completion).
--
Jens Axboe
--
| May 20, 12:54 pm 2008 |
| Eric Sandeen | Re: [PATCH 4/4] ext4: call blkdev_issue_flush on fsync
I think that might still be true, but I'm still looking through it (in
the background...)
I tried blktrace to see what was going on but I'm not sure what an "NB"
in the RWBS field means, anyone know?
-Eric
--
| May 20, 8:52 am 2008 |
| Theodore Tso | Re: [PATCH 4/4] ext4: call blkdev_issue_flush on fsync
This patch isn't necessary, and in fact will cause a double flush.
When you call fsync(), it calls ext4_force_commit(), and we do a the
equivalent of a blkdev_issue_flush() today (which is what happenes
when you do a submit_bh(WRITE_BARRIER, bh), which is what setting
set_ordered_mode(bh) ends up causing.
- Ted
--
| May 19, 7:34 pm 2008 |
| Jamie Lokier | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
Except when it crosses an MD disk boundary. Then it's really likely.
We could also ask if there's _any_ possibility, when they are a merged
single I/O, of them not getting written in the expected order?
What about when FUA is set, does that imply any order?
But it's all moot: Checksumming is the way forward here, no doubt.
Checksumming makes the multi-sector write "atomic or corrupt". That's
the same expectation as a commit sector provides by itself, but
generalised to the whole journal ...
| May 20, 4:44 pm 2008 |
| Jamie Lokier | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
Fwiw, you can test correctness by running a nested VM-in-VM guest
which simulates disk write cache and flush operations (which flush to
the host kernel). I believe recent QEMU/KVM has this as an option.
Data written by the innermost guest will reside in the middle kernel's
write cache.
Disk cache flush commands from the innermost kernel will cause the
middle kernel to write dirty sectors to the outer kernel. Killing the
outermost host process is roughly equivalent to pulling the plug on ...
| May 20, 7:42 am 2008 |
| Jens Axboe | Re: [PATCH 4/4] ext4: call blkdev_issue_flush on fsync
Eric already knows this now, but for the benefit of anyone else that may
be curious - it's an empty (data-less) barrier. 'N' is basically 'no
data' (eg not a read nor a write) and 'B' is barrier.
--
Jens Axboe
--
| May 20, 1:14 pm 2008 |
| Chris Mason | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
I hesitate to get too fancy here, if the disk is idle we probably won't notice
This is true, and would be a fairly good performance boost. It fits nicely
with the jbd trick of avoiding writes of a metadata block if a later
transaction has logged it.
But, it complicates the decision about when you're allowed to dirty a metadata
block for writeback. It used to be dirty-after-commit and it would change to
dirty-after-barrier. I suspect that is some significant surgery into jbd.
Also, ...
| May 20, 9:02 am 2008 |
| Jamie Lokier | Re: [PATCH, RFC] ext4: Fix use of write barrier in commi ...
Last time I looked, the database write + fsync case did not result in
a journal commit in some cases, and therefore no blkdev_issue_flush().
The problem was one of correctness. Has this been fixed?
A database had no way to issue a hard disk barrier in these cases
without doing weird stuff like forcing metadata changes prior to fsync
(e.g. toggling permissions bits), which causes an intolerable two disk
seeks per fsync. That is _way_ expensive.
There is also no way in ext3 to _just_ ...
| May 20, 8:23 am 2008 |
| Jamie Lokier | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
Will need benchmarking, but might just work.
Still need barriers for reasonable performance + integrity on systems
without NCQ, like the kit on my desk. Without barriers I have to turn
That's right. You can keep it quite simple: just distinguish barriers
from flushes. Or make it more detailed, distinguishing different
I think simply distinguishing barrier from flush is relatively
Yeah, if you're going to do it _properly_ that's the way :-)
But the I/O failure strategy is really a ...
| May 20, 3:26 pm 2008 |
| Jamie Lokier | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
That is a great optimisation to make the filesystem safe against power
fails without barriers. Upon replay, the filesystem is consistent.
But does it break fsync()? Consistency isn't enough for fsync().
Returning from fsync() means "this data is committed now".
-- Jamie
--
| May 20, 7:45 am 2008 |
| Jamie Lokier | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
+1 too.
-- Jamie
--
| May 20, 7:58 am 2008 |
| Chris Mason | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
That would be great, I'd like to confirm that my machine isn't the only one on
the planet so easily broken ;)
I was also able to trigger corruptions on XFS (one run out of two), so it is
unlikely I'm seeing bugs in the ext3 replay or logging code.
-chris
--
| May 19, 5:29 pm 2008 |
| Jamie Lokier | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
I wonder, does sending any kind of reset commands to drives cause them
to discard their write cache?
If the hot swap power switch is accessible from software, that would
be a nice trick :-)
-- Jamie
--
| May 20, 4:48 pm 2008 |
| Timothy Shimmin | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
Hi Chris,
Just to clarify,
was this test with barriers on or off for XFS?
I'm wondering if it was with barriers on, then we have a reproducible
bug in log replay.
Or whether you were just confirming the problems with barriers off on
another filesystem.
Thanks muchly,
Tim.
--
| May 19, 8:29 pm 2008 |
| Chris Mason | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
Great, thanks Jens.
So, one compromise may be to change the barriers on ext3 to look like the
patch Ted just sent out for ext4. It should be mostly safe to skip the
barrier between the log blocks and the commit block since the drive is likely
to do those sequentially anyway. A little extra logic could be added to
detect log wrapping and force an extra barrier in that case.
Reiserfs saw some significant performance gains when I changed the code from:
write log blocks
barrier
wait ...
| May 20, 5:17 am 2008 |
| Jamie Lokier | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
I think you're right, but it's hard to be sure. One of the problems
with barrier-implemented-as-flush-all is that it flushes data=ordered
data, even when that's not wanted, and there can be a lot of data in
the disk's write cache, spread over many seeks.
Then it's good to delay barrier-flushes to batch metadata commits, but
good to issue the barrier-flushes prior to large batches of
data=ordered data, so the latter can be survive in the disk write
cache for seek optimisations with later ...
| May 20, 9:27 am 2008 |
| Jens Axboe | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
I ran this twice, killing power after 'renames ready'. The first time it
was fine, the second time I got:
centera:~/e2fsprogs-1.40.9/e2fsck # ./e2fsck -f /dev/sdb1
e2fsck 1.40.9 (27-Apr-2008)
/dev/sdb1: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Problem in HTREE directory inode 2395569: node (281) has bad max hash
Problem in HTREE directory inode 2395569: node (849) has bad max hash
Problem in HTREE directory inode 2395569: node (1077) ...
| May 20, 1:25 am 2008 |
| Chris Mason | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
On Monday 19 May 2008, Timothy Shimmin wrote:
Barriers were off on xfs, the corruptions were not xfs' fault.
-chris
--
| May 20, 5:04 am 2008 |
| Jamie Lokier | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
Ooh.
Might it be possible for fsck to identify certain problems as likely
caused by power loss in misordered writes?
If metadata sectors had an update generation number, to be compared
with journal entries, perhaps that would be more feasible.
-- Jamie
--
| May 20, 4:35 pm 2008 |
| Jamie Lokier | Re: [PATCH 4/4] ext4: call blkdev_issue_flush on fsync
Oh. That's really unclear from the opening paragraph of barrier.txt,
which _defines_ what I/O barriers are for, and does not mention flushing:
I/O barrier requests are used to guarantee ordering around the barrier
requests. Unless you're crazy enough to use disk drives for
implementing synchronization constructs (wow, sounds interesting...),
the ordering is meaningful only for write requests for things like
journal checkpoints. All requests queued before a barrier request
...
| May 20, 3:02 pm 2008 |
| Jamie Lokier | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
A little optimisation note.
You don't need the barrier after in some cases, or it can be deferred
until a better time. E.g. when the disk write cache is probably empty
(some time after write-idle), barrier flushes may take the same time
as NOPs.
This sequence:
#1 write metadata to journal
#1 write commit block (checksummed)
BARRIER
#1 write metadata in place
... time passes ...
#2 write metadata to journal
#2 write commit block (checksummed)
BARRIER
...
| May 20, 8:36 am 2008 |
| Chris Mason | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
Jens and I talked about tossing the barriers completely and just doing FUA for
all metadata writes. For drives with NCQ, we'll get something close to
optimal because the higher layer elevators are already doing most of the hard
work.
Either way, you do want the flush to cover all the data=ordered writes, at
least all the ordered writes from the transaction you're about to commit.
Telling the difference between data=ordered from an old transaction or from
the running transaction gets ...
| May 20, 10:08 am 2008 |
| Theodore Tso | [PATCH, RFC] ext4: Fix use of write barrier in commit logic
And here it is....
Comments, please. And Eric, if you have a chance to benchmark this to
see how this patch works out, comparing "barrier=0, "barrier=1", and
"barrier=1,journal_async_commit", as we had discussed earlier on the
ext4, I'd be very much obliged.
As I mentioned earlier, adding blkdev_issue_flush() to ext[34]/fsync.c
is I believe not necessary. We should be doing the right thing in the
commit.c file. In the future, if we want some extra bonus points, in
the case where writes ...
| May 19, 7:51 pm 2008 |
| Jamie Lokier | Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes
I haven't read the code and don't use MacOS myself.
From its fcntl() man page:
Note that while fsync() will flush all data from the host to the
drive (i.e. the "permanent storage device"), the drive itself may
not physically write the data to the platters for quite some time
and it may be written in an out-of-order sequence.
Specifically, if the drive loses power or the OS crashes, the
application may find that only some or none of their data was
written. The ...
| May 20, 8:13 am 2008 |
| K.Prasad | Re: [RFC Patch 1/1] trace_printk and trace_dump interface - v2
Must be an act of my mail client. Will re-send with proper word-wrapping
Yes, I missed it. Will modify to look like this:
if (strlen(name) > TRACE_NAME_SIZE)
return ERR_PTR(-ENOMEM);
temp = kzalloc(sizeof(struct trace_dir), GFP_KERNEL);
if (temp == NULL)
Ok. Will name this instance,
The name 'trace' (previously GTSC), I gather that it was the chosen after
much deliberation (http://tinyurl.com/6odoh4), however I'm open to the
idea of changing the name (say ...
| May 20, 12:53 pm 2008 |
| Andrew Morton | Re: [RFC Patch 1/1] trace_printk and trace_dump interface - v2
On Wed, 21 May 2008 01:23:09 +0530
Well I was just putting it out there for consideration. Yes, I think
the whole idea of consuming the "trace_*" namespace in this patchset
was ill-advised.
Also, I don't know how to move forward with the whole feature - I
haven't seen a lot of interest from others and I haven't seen much
discussion of how this feature differs from all the other tracing
things which have been floating about.
And even if the proposed patches presently offer unique and ...
| May 20, 1:12 pm 2008 |
| Dave Jones | Re: Top kernel oopses/warnings for the week of May 16th 2008
On Fri, May 16, 2008 at 09:04:26PM +0300, Adrian Bunk wrote:
> On Fri, May 16, 2008 at 09:41:31AM -0700, Arjan van de Ven wrote:
> >...
> > Bug of the week
> > ---------------
> > Not in the top 10 (but barely not so), but upcoming fast is a bug that has a very
> > distinct pattern.
> > The backtraces are at http://www.kerneloops.org/searchweek.php?search=fput
> >
> > The pattern is that the kernel gets an invalid pointer passed to fput(),
> > coming down from a select() system call ...
| May 19, 8:53 pm 2008 |
| Nicolas Ferre | [PATCH] atmel_lcdfb: FIFO underflow management rework
Manage atmel_lcdfb FIFO underflow rework
Resetting the LCD and DMA allows to fix screen shifting after
a FIFO underflow. It follows reset sequence from errata
"LCD Screen Shifting After a Reset".
Reworked following Andrew Morton comments.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
This error may append in latency sensitive cases : slow clock,
Ok incremental patch follows. Tell me if you prefer that I send
a reworked one.
Ok, I try to adapt this comment in the ...
| May 20, 6:54 am 2008 |
| Hugh Dickins | Re: 2.6.25.1: Kernel BUG at mm/rmap.c:669, General Prote ...
If it is bisectable (rather than just taking much longer to go wrong
sometimes than others, so you never know when to say "good" or "bad"),
then that is well worth doing, from my point of view: thank you for
taking the trouble to do so. But keep an open mind: if it really is
down to a hardware issue of some kind, it may turn out to be a waste
They might be: the more information you can give us the better.
So if you do get something interesting in the logs, please do send
it over, with a ...
| May 20, 11:33 am 2008 |
| Randy Johnson | Re: 2.6.25.1: Kernel BUG at mm/rmap.c:669, General Prote ...
I did manage to steal another complete set of RAM and swapped it in,
with no change. This still doesn't rule out potential issues with the
MB (slots or controller); I've got a spare board coming in in the next
week.
In the mean time, I've been busy bisecting this one down.
Unfortunately, it takes a good hour or two of heavy load to trigger
sometimes, and I've got a good 15000 or so commits to get through, so
it could still be a while. I haven't been keeping any traces from
these, even if I ...
| May 20, 7:56 am 2008 |
| Ingo Molnar | [patch] dvb/usb: input layer dependency fixes
testing of the -tip tree found the following build failures on
2.6.26-rc3:
drivers/built-in.o: In function `ttusb_dec_disconnect':
ttusb_dec.c:(.text+0xa2c95): undefined reference to `input_unregister_device'
drivers/built-in.o: In function `dvb_usb_read_remote_control':
dvb-usb-remote.c:(.text+0xa6a94): undefined reference to `input_event'
with this config:
http://redhat.com/~mingo/misc/config-Tue_May_20_03_48_57_CEST_2008.bad
these are due to the media/dvb/usb layer ...
| May 20, 1:02 am 2008 |
| Maciej W. Rozycki | Re: [PATCH] x86: Get irq for hpet timer
Hmm, you probably want to skip all lines that are edge-triggered.
Otherwise you may have problems with sharing. Drivers for devices used
with these edge-triggered lines may have special provisions to permit
sharing in a crafted way in special arrangements (cf. the 8250 serial or
the IDE driver), but that may not work in a generic way with a different
driver in the scenario. And the polarity may be wrong too --
edge-triggered lines are often active-high, because it's fine with them.
This ...
| May 20, 8:46 am 2008 |
| Kevin Hao | Re: [PATCH] x86: Get irq for hpet timer
We can simply skip these special IRQ. :-)
Does anyone has a better solution?
----
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index 0fdc627..b04a15d 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -390,6 +390,11 @@ static int hpet_timer_get_irq(struct hpet_dev *devp)
struct hpets *hpetp;
unsigned long cap, irq_flags;
int irq;
+ /*
+ * skip IRQ0, IRQ2, IRQ8 because which is always used by some
+ * legacy device
+ */
+ unsigned long skip_irq = (1 << ...
| May 20, 2:03 am 2008 |
| Christian Kujau | Re: [Jfs-discussion] Hello and a question about high cpu ...
Would oprofile[0] help to see what jfsCommit is doing here?
C.
[0] http://oprofile.sf.net
--
make bzImage, not war
--
| May 20, 5:19 am 2008 |
| Dave Kleikamp | Re: Hello and a question about high cpu usage on jfsComm ...
Since it's only happening during periods of high activity, it doesn't
seem as serious a problem as I suspected it may be. Several threads
operating on a lot of files and/or directories at one time could put a
lot on the jfsCommit thread's queue, even though 99% cpu utilization
Since the thread isn't stuck in some kind of infinite loop, I don't
really think a reboot will make any difference. When I asked I wasn't
If you see it again, Christian's suggesting of running oprofile to see
where ...
| May 20, 7:10 am 2008 |
| David Fix | Re: Hello and a question about high cpu usage on jfsComm ...
Hey Dave,
Thanks for following up on this... The previous kernel that I was
running was 2.6.18.1... From CentOS 5.1.
It appears that the thread eating up that much CPU isn't a continuous
happening, only when there's a fair amount of activity going on. It's
hard to nail down exactly when it happens, but the next time it does,
I'll definitely let you all know!
I haven't been able to reboot this machine, as it's a production unit,
but if I do get the chance, I'll do so. It seems to ...
| May 20, 6:06 am 2008 |
| J. Bruce Fields | Re: [patch 1/9] lockd: dont return EAGAIN for a permanen ...
Just for the sake of future readers, I might go ahead and give
specifics: "and older versions of the linux server sometimes returned
Might be a bit clearer (or at least make the comment and code more
obviously agree) to do:
status = nlm_stat_to_errno(resp->status);
if (status == -EAGAIN && (fl_flags & FL_SLEEP))
status = -ENOLCK;
This might make more sense as separate client and server-side patches.
Seems reasonable to me otherwise.
--
| May 20, 11:47 am 2008 |
| Jesse Barnes | Re: [PATCH] PCI: Correct last two HP entries in the bfso ...
I just sent Linus the pull request for this fix; should be upstream soon.
Thanks,
Jesse
--
| May 20, 10:53 am 2008 |
| Jesse Barnes | Re: [PATCH] msi: skip calling pci_find_capability from m ...
Great, thanks a lot for testing (and getting us on track to fix this in the
first place!).
Jesse
--
| May 20, 1:06 pm 2008 |
| Arnaldo Carvalho de Melo | Re: [PATCH] msi: skip calling pci_find_capability from m ...
Tested, works as expected, thanks.
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
- Arnaldo
--
| May 20, 12:56 pm 2008 |
| Michael Ellerman | Re: [PATCH 2/2] ftrace: support for PowerPC
Hi Steven,
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
I don't grok what you're doing with CALL_BACK, you add it in places and
subtract in others - and it looks like you could do neither, but I haven't
And that.
0x03fffffe should be 0x03fffffc, if you set bit 1 you'll end with a "bla" ...
| May 20, 7:04 am 2008 |
| Steven Rostedt | Re: [PATCH 2/2] ftrace: support for PowerPC
I figured it was something like that, so I didn't look too deep into it,
and decided that it was best just not to trace it.
-- Steve
--
| May 20, 7:51 am 2008 |
| Benjamin Herrenschmidt | Re: [PATCH 2/2] ftrace: support for PowerPC
Not running at the linked address... might be causing trouble.
Ben.
--
| May 20, 7:17 am 2008 |
| Steven Rostedt | Re: [PATCH 2/2] ftrace: support for PowerPC
Hi Michael,
I really appreciate this. It's been a few years since I did any real PPC
The -pg flag makes calls to the mcount code. I didn't look too deeply, but
at least in my first prototypes the early boot up code would crash when
calling mcount. I found that simply keeping them from calling mcount made
things OK. Perhaps I'm just hiding the problem, but the tracing wont
I tried hard to make most of the complex logic stay in generic code.
What dynamic ftrace does is at start up the ...
| May 20, 7:32 am 2008 |
| Stephen Hemminger | Re: [PATCH] driver core: Suppress sysfs warnings for dev ...
On Tue, 20 May 2008 12:59:13 +0200
This is still getting to be overkill. I prefer that the warnings
always are removed.
--
| May 20, 2:45 pm 2008 |
| Greg KH | Re: [PATCH] driver core: Suppress sysfs warnings for dev ...
Looks good to me, feel free to add an:
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
to it.
David, are you going to take this through your tree?
thanks,
greg k-h
--
| May 20, 3:52 pm 2008 |
| Greg KH | Re: [PATCH] driver core: Suppress sysfs warnings for dev ...
No, I do not. They have found a lot of real bugs that have been going
unnoticed for quite some time, and some new ones (like the current mess
in the pci hotplug subsystem where two different drivers are controlling
the same pci hotplug slots and not realizing it at all.)
So having the warning gone for rename() is fine, but I still want it
there for new files that are being added to the system.
thanks,
greg k-h
--
| May 20, 3:52 pm 2008 |
| Cornelia Huck | [PATCH] driver core: Suppress sysfs warnings for device_ ...
OK, here is an actually-compiled patch with proper description and
s-o-b. Comments?
-----
driver core: Suppress sysfs warnings for device_rename().
Renaming network devices to an already existing name is not
something we want sysfs to print a scary warning for, since the
callers can deal with this correctly. So let's introduce
sysfs_create_link_nowarn() which gets rid of the common warning.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
---
drivers/base/core.c | 17 ...
| May 20, 3:59 am 2008 |
| Ray Lee | Re: troubleshooting/debugging hard locks
The only thing I can think of is to recompile the latest mainline
kernel with all debugging options enabled in the .config. and then try
to reproduce with that.
--
| May 20, 2:19 pm 2008 |
| Lee Howard | Re: troubleshooting/debugging hard locks
After further troubleshooting it turns out that the message above was a
bit of a red herring. I moved the PCIe modem card from one PCIe slot to
another so that it would be on a different IRQ (one that wasn't shared
with the network, ATA, and USB). The message above does not occur now,
however, the hard lock is back... and this time with no kernel messages
at all.
So, I'm back to square one again... I've got:
nmi_watchdog=1 idle=poll nohz=off
... and still I get the hard lockup ...
| May 20, 1:47 pm 2008 |
| Alok Kataria | RE: Kernel hangs in SMP + VMware environment.
________________________________________
From: jengelh@sovereign.computergmbh.de [jengelh@sovereign.computergmbh.de] On Behalf Of Jan Engelhardt [jengelh@medozas.de]
Sent: Sunday, May 18, 2008 12:45 PM
To: Alok Kataria
Cc: penguin-kernel@i-love.sakura.ne.jp; devzero@web.de; linux-kernel@vger.kernel.org; Daniel Hecht
Subject: Re: Kernel hangs in SMP + VMware environment.
I too noticed it; clocksource=pit is my current workaround.
ANK> What kernel do you see this with ? Did you get a a chance ...
| May 19, 6:08 pm 2008 |
| Arnd Bergmann | Re: [PATCH, RFC] char dev BKL pushdown
Right, unless Alan or Wim are confident enough that removing the
BKL won't break the drivers (more than they are today).
Almost all of the open functions go along the lines of
int open(struct file *f, struct inode *i)
{
if (wd_is_open)
return -EBUSY;
wd_is_open = 1;
start_wd();
return nonseekable_open(f, i);
}
nonseekable_open doesn't need the BKL by itself, and the wd_is_open
variable is protected by the misc_mtx mutex.
I can't see any scenario in which start_wd() would ...
| May 20, 10:21 am 2008 |
| Alan Cox | Re: [PATCH 1/3, RFC] misc char dev BKL pushdown
On Tue, 20 May 2008 01:26:28 +0200
Acked-by: Alan Cox <alan@redhat.com>
--
| May 20, 1:46 am 2008 |
| Mike Frysinger | Re: [PATCH 1/3, RFC] misc char dev BKL pushdown
please drop the coreb.c changes from your patch
-mike
--
| May 20, 4:01 pm 2008 |
| Alan Cox | Re: [PATCH, RFC] char dev BKL pushdown
You need to review the use of misc_register(). Which is what I did
already and sorted out for each watchdog - the job is done and completed
and the various problem cases fixed. Watchdog has already been made BKL
removal safe in the patch series I sent.
Alan
--
| May 20, 11:51 am 2008 |
| Jonathan Corbet | Re: [PATCH 1/3, RFC] misc char dev BKL pushdown
The existence of a spinlock is a good sign. But, until somebody has
looked at the code and verified that said lock is really protecting
everything, it's best to leave the BKL protection (which has always been
there, just at a higher level) in place.
jon
--
| May 19, 5:21 pm 2008 |
| Jonathan Corbet | Re: [PATCH, RFC] char dev BKL pushdown
OK, it looks like the "misc" misc drivers patch can go into the
bkl-removal tree, while the watchdog patches should not. What that
means, I guess, is that the final misc_open() patch cannot go in at this
point; Alan's watchdog stuff needs to find its way in first. Make
Alas, I have no such script. I just committed each change as I made it
- each one required individual attention anyway. The misc changes look
pretty straightforward, so I could probably hack up such a thing pretty
quickly ...
| May 20, 8:13 am 2008 |
| Mike Frysinger | Re: [PATCH 1/3, RFC] misc char dev BKL pushdown
this open func already has a spinlock protecting it. doesnt that mean
we dont need the bkl in it ?
-mike
--
| May 19, 5:07 pm 2008 |
| Jonathan Corbet | Re: [PATCH 1/3, RFC] misc char dev BKL pushdown
At a minimum, I would hope such a request would say something like "I've
looked at the driver's locking and am convinced that the BKL is not
needed." Have you done that? There is a certain leap of faith involved
in removing that protection from a driver.
I decided to take a quick look...
- You use spin_lock_irq(&coreb_lock) in a number of places, but you do
not take the lock in the interrupt handler. You also do not take the
lock in coreb_write() or coreb_read(), so those can race ...
| May 20, 4:25 pm 2008 |
| Mike Frysinger | Re: [PATCH 1/3, RFC] misc char dev BKL pushdown
if the spinlock doesnt do what it's advertising (preventing mutual
access), then the BKL is needed. if there's some UP behavior i'm not
aware of, then the BKL is needed. otherwise, the BKL is not needed in
this driver.
i should prob rewrite this driver anyways ... the open code could
easily be replaced with some atomic funcs.
-mike
--
| May 19, 5:46 pm 2008 |
| David Miller | Re: [IPSEC]: Use the correct ip_local_out function
From: Herbert Xu <herbert@gondor.apana.org.au>
Applied and queued to -stable, thanks!
--
| May 20, 2:32 pm 2008 |
| Herbert Xu | [IPSEC]: Use the correct ip_local_out function
OK found the problem, it was my fault after all :)
Dave, this patch needs to go into stable too.
[IPSEC]: Use the correct ip_local_out function
Because the IPsec output function xfrm_output_resume does its
own dst_output call it should always call __ip_local_output
instead of ip_local_output as the latter may invoke dst_output
directly. Otherwise the return values from nf_hook and dst_output
may clash as they both use the value 1 but for different purposes.
When that clash occurs this ...
| May 20, 2:25 am 2008 |
| Andreas Dilger | Re: [RFC PATCH 1/3] Implement generic freeze feature
Should this be EINVAL, or EOPNOTSUPP? Usually EINVAL means there is
something wrong with the passed ioctl parameters (e.g. bad value),
while EOPNOTSUPP is "operation not supported" and makes more sense.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
| May 19, 8:57 pm 2008 |
| Mariusz Kozlowski | Re: 2.6.26-rc2-mm1: possible circular locking dependency ...
Hello,
This lockdep warning is seen when I remove pcmcia wifi card
from the slot. Doesn't happen every time. It's x86_32.
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.26-rc2-mm1 #2
-------------------------------------------------------
pccardd/1037 is trying to acquire lock:
(rtnl_mutex){--..}, at: [<c02870f1>] rtnl_lock+0x14/0x16
but task is already holding lock:
(&socket->skt_mutex){--..}, at: [<c02608ba>] ...
| May 20, 3:01 am 2008 |
| Andrew Morton | Re: 2.6.26-rc2-mm1: possible circular locking dependency ...
cls->mutex
rtnl_lock
cls->mutex
This bug has always been there, and is now exposed by the conversion
of cls->mutex from a semaphore to a mutex. Because lockdep doesn't
check semaphores.
I don't know how to get this fixed, sorry. I'll just push
struct-class-sem-to-mutex-converting.patch at Greg until it sticks,
then it will go into mainline, then we'll get a shower of bug reports,
including this one, then someone someday will do soemthing about it.
Fun.
--
| May 20, 3:22 am 2008 |
| Romano Giannetti | Re: 2.6.26-rc2 hosed X?
Maybe related to: http://bugzilla.kernel.org/show_bug.cgi?id=10620 ?
Romano
--
Sorry for the disclaimer --- ¡I cannot stop it!
--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido ...
| May 20, 12:44 am 2008 |
| Norbert Preining | Re: 2.6.26-rc2 hosed X?
I had the very same problems like you and I had to apply two patches:
(see http://bugzilla.kernel.org/show_bug.cgi?id=10709)
The one is included in -rc3, that was solved by applying
http://lkml.org/lkml/2008/5/13/188
the former was solved by using the vblank reverse patch given in the
above bug, or directly here:
http://marc.info/?l=linux-kernel&m=121074889124387&w=4
Try -rc3 plus this patch, it is now working here. In bocca al lupo!
Best ...
| May 20, 1:16 am 2008 |
| Romano Giannetti | Re: 2.6.26-rc2 hosed X?
OK: fixed in v2.6.26-rc3-119-g8033c6e, which includes the above
patches.
Thanks to all.
Romano
--
Sorry for the disclaimer --- ¡I cannot stop it!
--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ...
| May 20, 2:54 am 2008 |
| Harald Dunkel | Re: 2.6.25.3: su gets stuck for root
No improvement: I killed syslogd, and yet stty gets stuck.
But surely it was a smart idea.
Regards
Harri
--
| May 20, 1:26 pm 2008 |
| Willy Tarreau | Re: 2.6.25.3: su gets stuck for root
have you checked in /proc/$(pidof stty)/fd/ to see if stty is bound to
any particular file descriptor ? Maybe you'll find the source of the
blocking operation here. You can find a unix socket attached to
another process, it may be a tty, a pipe, or even a device (eg:
/dev/random when there is no entropy left). Same for "su" BTW.
Regards,
willy
--
| May 20, 1:38 pm 2008 |
| david | Re: 2.6.25.3: su gets stuck for root
try killing syslog and then see if you continue to have the problem. It's
possible that what's happening is syslog is getting stuck and su is
sitting waiting for syslog to process the log entry.
David Lang
--
| May 20, 12:12 pm 2008 |
| Harald Dunkel | Re: 2.6.25.3: su gets stuck for root
I doubt that Debian is to blame here. I get the same with native
gdb-6.8 and native coreutils-6.10:
# /usr/local/stow/gdb-6.8/bin/gdb ./stty 11944
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as ...
| May 20, 12:01 pm 2008 |
| Roland McGrath | Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
ptrace/user_regset copies out and in the whole fxsave block from the ptrace
caller. (Only the mxcsr word is constrained after copy-in.)
Thanks,
Roland
--
| May 20, 1:10 pm 2008 |
| Mikael Pettersson | Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
Suresh Siddha writes:
> On Mon, May 19, 2008 at 04:52:01PM +0200, Mikael Pettersson wrote:
> > > But we can
> > >use some what similar magic, if the fxsave/fxrstor give away
> > >some of the fields at the end of fxsave image (today it is reserved
> > >and ignored during fxsave/fxrstor) for software use.
> > >We can then use these fields at the end of fpstate, to indicate the presence of
> > >xstate. But this requires some architecture changes like giving
> > >away this space for SW use. ...
| May 20, 1:58 am 2008 |
| H. Peter Anvin | Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
Or use the OSXSAVE hack. Let me think about this for some time.
There is also the option of simply using a field guarded by a 64- or
128-bit magic number. It's a bit ugly, but it works.
-hpa
--
| May 20, 10:57 am 2008 |
| Mikael Pettersson | Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
Andi Kleen writes:
> Suresh Siddha wrote:
> > On Mon, May 19, 2008 at 04:52:01PM +0200, Mikael Pettersson wrote:
> >>> But we can
> >>> use some what similar magic, if the fxsave/fxrstor give away
> >>> some of the fields at the end of fxsave image (today it is reserved
> >>> and ignored during fxsave/fxrstor) for software use.
> >>> We can then use these fields at the end of fpstate, to indicate the presence of
> >>> xstate. But this requires some architecture changes like giving
> ...
| May 20, 6:19 am 2008 |
| Andi Kleen | Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
I don't think there is one. We never copy fxsave completely out of the
kernel. x86-64 does FXSAVE directly in/out user space, but the
only leak is what there was before.
-Andi
--
| May 20, 8:03 am 2008 |
| Suresh Siddha | Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
This issue of not-zeroing, is present in only 64bit kernels and for 64bit apps,
right?
64bit app signal handling uses only rt_frame, so we can add an uc_flag for
them and for 32bit apps, kernel was always zero'ing the reserved bits
at the end of _fpstate.
In short, for non-rt frames, they can check the reserved bits at the end
of fpstate frame and for rt-frames (perhaps even for 32bit rt frame handling)
apps can check for uc_flag aswell, for extended state presence. Is this
good ...
| May 20, 10:53 am 2008 |
| H. Peter Anvin | Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
Are we sure about the "always" bit here (I suspect yes, but we may want
to double-check at least back to 2.2 or 2.4.)
Anyway, seems reasonable enough to me.
-hpa
--
| May 20, 10:59 am 2008 |
| H. Peter Anvin | Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
OK, so that's not a usable path unless we can find some area in the
existing data set to put a flag. Groan.
-hpa
--
| May 20, 7:58 am 2008 |
| H. Peter Anvin | Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
I'm pretty sure they weren't zeroed by the CPUs. If they weren't zeroed
*by the kernel*, there might have been an information leak.
-hpa
--
| May 20, 7:55 am 2008 |
| Mikael Pettersson | Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
H. Peter Anvin writes:
> Mikael Pettersson wrote:
> > >
> > > Are they always zeroed in earlier CPUs though? If not that wouldn't
> > > work 100% reliably because whatever cookie you put in could have been
> > > there before by chance.
> >
> > I wrote a test program (fill an area with zeroes, fxsave, inspect
> > reserved fields, then fill it with ones, fxsave, inspect again),
> > and all processors appear to just not write anything to the reserved
> > fields after the last xmm ...
| May 20, 8:20 am 2008 |
| Andi Kleen | Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
Are they always zeroed in earlier CPUs though? If not that wouldn't
work 100% reliably because whatever cookie you put in could have been
there before by chance.
I don't see anything in the SDM guaranteeing zeroing.
-Andi
--
| May 20, 3:01 am 2008 |
| Suresh Siddha | Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
Ok. CPU folks are planning to make some of the bytes at the end of fxsave
image, SW usable.
We can use some of these fields, to represent the extended state
presence with a cookie, save area size, mask of the state
stored. If needed, we can include the start address of the fpstate pointer
(also as part of the cookie), so that we can detect the situation,
where apps are just memcopying sizeof(struct _fpstate) from the fpstate
pointer (but not aware of the extended state).
we don't need any ...
| May 19, 6:57 pm 2008 |
| Jan-Bernd Themann | Re: [PATCH] drivers/net/ehea - remove unnecessary memset ...
The patch looks good.
Acked-by: Jan-Bernd Themann <themann@de.ibm.com>
Thanks,
Jan-Bernd
--
| May 20, 6:53 am 2008 |
| Jesse Barnes | Re: [PATCH] PCI: boot parameter to avoid expansion ROM m ...
Ok, just pushed the norom patch to linux-next. I'll test it out, but it would
be good if you could try the tree out out on one of the problem machines too.
Thanks,
Jesse
--
| May 20, 1:16 pm 2008 |
| Jesse Barnes | Re: [PATCH] PCI: boot parameter to avoid expansion ROM m ...
Unless there's a ton of demand, I'd rather go with the norom option, but
either way, I'd like to push the fix early in the 2.6.27 cycle rather than
trying to get it into 2.6.26 at the last minute...
So assuming you're ok with your last patch, I'll stuff it into linux-next.
Thanks,
Jesse
--
| May 20, 10:57 am 2008 |
| Gary Hade | Re: [PATCH] PCI: boot parameter to avoid expansion ROM m ...
This is fine. I would also like to see the pci=norom option
added as-is with the thought that we may improve later by either
modifying pci=norom to exclude devices that need memory mapped
to their expansion ROMs or by adding another option (pci=minrom ?)
Works for me. Thanks.
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
garyhade@us.ibm.com
http://www.ibm.com/linux/ltc
--
| May 20, 1:00 pm 2008 |
| David Chinner | Re: [patch 10/21] buffer heads: Support slab defrag
Oh, god no. Let's not put the inode_lock right at the top of
the VM page cleaning path. We don't need to modify inode state,
the superblock dirty lists, etc - all we need to do is write
dirty pages on a given mapping in a more efficient manner.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
--
| May 20, 2:46 pm 2008 |
| Evgeniy Polyakov | Re: [patch 10/21] buffer heads: Support slab defrag
I'm not advocating that, but having swap on reclaim does not hurt
anyone, this is essentially the same, but with different underlying
storage. System will do that anyway sooner or later during usual
writeback, which in turn can be a result of the same reclaim...
--
Evgeniy Polyakov
--
| May 20, 3:25 pm 2008 |
| Evgeniy Polyakov | Re: [patch 10/21] buffer heads: Support slab defrag
Or just sync_inode().
--
Evgeniy Polyakov
--
| May 19, 11:56 pm 2008 |
| Evgeniy Polyakov | Re: [patch 10/21] buffer heads: Support slab defrag
And actually having tiny operations under inode_lock is the last thing
to worry about when we are about to start writing pages to disk because
memory is so fragmented that we need to move things around.
That is the simplest from the typing viewpoint, one can also do
something like that:
struct address_space *mapping = page->mapping;
struct backing_dev_info *bdi = mapping->backing_dev_info;
struct writeback_control wbc = {
.bdi = bdi,
.sync_mode = WB_SYNC_ALL, /* likly we want to wait... ...
| May 20, 4:22 pm 2008 |
| David Chinner | Re: [patch 10/21] buffer heads: Support slab defrag
How hard is it? I don't have time right now to do this, but it's essentially:
mapping = page->mapping;
......
- mapping->aops->writepage();
+ filemap_fdatawrite_range(mapping, start, end);
Where [start,end] span page->index and are is large enough
to get a substantial sized I/O to disk (say at least SWAP_CLUSTER_MAX
pages, preferrably larger for 4k page size machines).
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
--
| May 19, 5:25 pm 2008 |
| Andrew Morton | Re: [patch 10/21] buffer heads: Support slab defrag
It's more than efficiency. There are lots and lots of things we cannot
do in direct-reclaim context.
a) Can't lock pages (well we kinda sorta could, but generally code
will just trylock)
b) Cannot rely on the inode or the address_space being present in
memory after we have unlocked the page.
c) Cannot run iput(). Or at least, we couldn't five or six years
ago. afaik nobody has investigated whether the situation is now
better or worse.
d) lots of deadlock scenarios - ...
| May 20, 4:28 pm 2008 |
| David Chinner | Re: [patch 10/21] buffer heads: Support slab defrag
Sure. But my point is simply that sync_inode() is far too
heavy-weight to be used in a reclaim context. The fact that it holds
the inode_lock will interfere with normal writeback via pdflush and
that could potentially slow down writeback even more.
e.g. think of kswapd threads running on 20 nodes of a NUMA machine
all at once writing back dirty memory (yes, it happens). If we use
sync_inode() to write back dirty mappings we would then have at
least 20 CPUs serialising on the inode_lock trying ...
| May 20, 4:19 pm 2008 |
| David Chinner | Re: [patch 10/21] buffer heads: Support slab defrag
Which is the exact implementation of
filemap_fdatawrite_range(mapping, start, end);
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
--
| May 20, 4:30 pm 2008 |
| Jamie Lokier | Re: [patch 10/21] buffer heads: Support slab defrag
I don't think that's true on no-MMU. Defragmentation can be needed
often on no-MMU when there's lots of free memory, just in the wrong
places.
-- Jamie
--
| May 20, 3:53 pm 2008 |
| Jason Wessel | Re: kgdb test suite failure
Is this a problem you can reproduce every time? Basically what line 5
of the test does is to write a value into the register struct to rewind
the PC after hitting a breakpoint such that the instruction will be
executed again. This is stored in memory which will be used for a
context switch back to the process. The test also replaces the
original instruction in memory. In this case the memory write failed.
This will certainly be fatal to the operation of the kernel and
stability would be ...
| May 20, 8:18 am 2008 |
| Alexander Beregalov | Re: kgdb test suite failure
It seems like this.
The kernel with the following config can boot.
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_KGDB_TESTS=y
CONFIG_KGDB_TESTS_ON_BOOT=y
CONFIG_KGDB_TESTS_BOOT_STRING="V1F100"
# CONFIG_DEBUG_RODATA is not set
And kgdbts runs successfully:
[ 7.579110] kgdb: Registered I/O driver kgdbts.
[ 7.633491] kgdbts:RUN plant and detach test
[ 7.686505] kgdbts:RUN sw breakpoint test
[ 7.734031] kgdbts:RUN bad memory access test
[ 7.786258] ...
| May 20, 11:30 am 2008 |
| Jean Delvare | Re: [PATCH 1/3] i2c : use class_for_each_device
Hi Dave,
... but calling another one? Can't be correct. Which raises a question:
you didn't test your patch, did you? I'm also surprised how you managed
to mess this up, given that all you had to do was to move already
The rest looks OK. I'll fix the patch myself and add it to my i2c tree
now.
--
Jean Delvare
--
| May 20, 10:31 am 2008 |
| Jean Delvare | Re: [i2c] [RFC][PATCH 4/4] RTC: SMBus support for the M41T80,
Hi David,
No #ifdefs required until we drop the deprecated helpers, which will
inevitably happen, even if only in several years. So in practice,
#ifdefs would be required for out-of-tree drivers (or semi-out-of-tree
I agree that the i2c-dev.h mess needs some love and this is on my to-do
list for this year. That's not necessarily related to the problem at
Whether it's in the kernel or outside the kernel is irrelevant. The
developers are likely to be the same, and the person who will have ...
| May 20, 2:20 am 2008 |
| Trond Myklebust | Re: Solved - How to change the FSINFO for nfsd?
XFS is 64-bit, but file sizes are of type off_t or loff_t, and are
therefore _signed_.
0x7fffffffffffffff is therefore indeed the maximum allowed file size for
a 64-bit filesystem.
Trond
--
| May 20, 6:12 am 2008 |
| P.V.Anthony | Re: Solved - How to change the FSINFO for nfsd?
Using xfs filesystem on a gentoo 64bit linux with 2.6.22 kernel,
when mounting the FSINFO return got was 7f ff ff ff ff ff ff ff.
Assuming that xfs is 64bit,
the FSINFO returned is still not ff ff ff ff ff ff ff ff.
Used wireshark to see the FSINFO return.
P.V.Anthony
--
| May 20, 1:15 am 2008 |
| Pavel Machek | Re: Deleting large files
If you fork a kernel thread, you lose error handling, too.
Think -EIO when writing back bitmaps...
(Hmm, you'd have to use O_SYNC to see that, so this is probably
minor).
I guess doing freeing asynchronously would be okay in the 'close'
case...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| May 20, 7:33 am 2008 |
| Robin Holt | Re: [PATCH 08 of 11] anon-vma-rwsem
That was covered in the early very long discussion about 28 seconds.
The read timeout for the BTE is 28 seconds and it automatically retried
for certain failures. In interrupt context, that is 56 seconds without
any subsequent interrupts of that or lower priority.
Thanks,
Robin
--
| May 20, 3:01 am 2008 |
| Nick Piggin | Re: [PATCH 08 of 11] anon-vma-rwsem
Oh, so the BTE transfer is purely for fault isolation. I was thinking
you guys might have sufficient control of the hardware to be able to
do it at the level of CPU memory operations, but if it is some
limitation of ia64, then I guess that's a problem.
How do you do fault isolation of userspace XPMEM accesses?
--
| May 20, 4:14 am 2008 |
| Nick Piggin | Re: [PATCH 08 of 11] anon-vma-rwsem
Really? You can get the information through via a sleeping messaging API,
but not a non-sleeping one? What is the difference from the hardware POV?
--
| May 19, 10:31 pm 2008 |
| Robin Holt | Re: [PATCH 08 of 11] anon-vma-rwsem
I was wrong about that. I thought it was safe to do an uncached write,
but it turns out any processor write is uncontained and the MCA that
surfaces would be fatal. Likewise for the uncached read.
--
| May 20, 4:05 am 2008 |
| Nick Piggin | Re: [PATCH 08 of 11] anon-vma-rwsem
I thought you said it would be possible to get the required invalidate
information without using the BTE. Couldn't you use XPMEM pages in
the kernel to read the data out of, if nothing else?
--
| May 20, 3:50 am 2008 |
| Robin Holt | Re: [PATCH 08 of 11] anon-vma-rwsem
The MCA handler can see the fault was either in userspace (processor
priviledge level I believe) or in the early kernel entry where it is
saving registers. When it sees that condition, it kills the users
process. While in kernel space, there is no equivalent of the saving
user state that forces the processor stall.
--
| May 20, 4:26 am 2008 |
| Tim Pepper | Re: [PATCH 7/9] Make idr_remove rcu-safe
Sure. I guess I was thinking out loud that it's maybe somewhat implicit
that things must be serial at that point and I wasn't sure if it was meant
to be required or enforced, if it should be clarified with comments or
I've had a bunch of machine issues, but I did manage to do some testing.
I'd started looking at the regression after Anton Blanchard mentioned
seeing it via this simple bit of code:
http://ozlabs.org/~anton/junkcode/lock_comparison.c
It essentially spawns a number of ...
| May 19, 10:29 pm 2008 |
| Tim Pepper | Re: [PATCH 7/9] Make idr_remove rcu-safe
I don't have results from a run handy with over 64 threads with the
patched kernel for the contended case. But from what I've seen, the
closer the number of test threads is to the number of actual cores,
not SMT threads, the more noisy the test gets. I think this is
reasonable/expected and that there's nothing magic about 63 or 64
threads.
We've been having network issues in the lab where this big box is.
If/when I can get access long enough, I'll do a series of runs including
past ...
| May 20, 9:26 am 2008 |
| Tim Pepper | Re: [PATCH 7/9] Make idr_remove rcu-safe
Errr...clumsy fingers. I attached a plot that had up to 128 threads, which
is really just noise over 60-ish.
At any rate, if anybody would like to see more runs/details let me know.
--
Tim Pepper <lnxninja@linux.vnet.ibm.com>
IBM Linux Technology Center
--
| May 19, 10:35 pm 2008 |
| Nadia Derbey | Re: [PATCH 7/9] Make idr_remove rcu-safe
Indeed, thanks a lot for taking some of your time to pass the tests!
Actually there are 2 numbers that bother me: those for the contended
loops on the patched kernel (63 and 64 threads) - the last 2 numbers in
the rightmost column.
Did you have the opportunity to run that same test for 128 threads: this
is just for me to check whether 64 is not the #of threads we are
starting to slow down from.
Thanks,
Nadia
--
| May 20, 12:03 am 2008 |
| Pavel Machek | Re: [Linux-fbdev-devel] [PATCH 1/9] viafb: VIA Frame Buf ...
Supports? . at end of line? Remove 2.6 reference as it will work in
Check indentation.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| May 20, 5:56 am 2008 |
| Artem Bityutskiy | Re: [PATCH take 2 01/28] VFS: introduce writeback_inodes_sb()
Andrew,
is it OK for you if ubifs-2.6.git will have some patches which ubi-2.6.git
also contains. Will your -mm system handle this?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
| May 20, 5:45 am 2008 |
| Andrew Morton | Re: [PATCH take 2 01/28] VFS: introduce writeback_inodes_sb()
It happens occasionally and I usually manage to work it out. Sometimes
with git hackery, sometimes manually. It'd be better if it was a
once-off thing, rather than having new conflicts arise each time I
repull the trees, if possible.
--
| May 20, 10:49 am 2008 |
| Yinghai Lu | May 20, 10:24 am 2008 | |
| Pavel Machek | Re: [PATCH] x86: process fam 10h like k8 with fixed mtrr ...
This also changes family 0x11. Is that ok?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| May 20, 5:54 am 2008 |
| Christoph Hellwig | Re: [2.6 patch] unexport uts_sem
Yesm they should never had done that anyway. The module support
does it's own version checking already.
--
| May 20, 10:27 am 2008 |
| Frank Ch. Eigler | Re: [2.6 patch] unexport uts_sem
Am I correct that this would makes it invalid for modules to call
utsname() (since the protective semaphore is now hidden)? Systemtap
has been using them in order to validate the modules it builds against
possible kernel vs. kernel-devel differences.
- FChE
--
| May 20, 10:16 am 2008 |
| Frank Ch. Eigler | Re: [2.6 patch] unexport uts_sem
Hi -
Sorry, I misspoke - this check is intended not to cross-check
kernel-devel and the kernel itself, but the debuginfo or similar data
that is given to describe target of a systemtap script. I guess for
new enough kernels we'll just do that using buildid hash codes.
By the way, there do appear to be a few suspect in-tree users of
utsname() without uts_sem locking (usb/storage/usb.c, cifs/connect.c,
char/random.cc, fs/lockd/clntproc.c, ...). If these need to be fixed,
then wouldn't ...
| May 20, 11:38 am 2008 |
| Lukas Hejtmanek | Re: 2.6.26-rc1 regression since 2.6.25
More precisly, it was already plugged but the external power of the USB drive
Moreover, I discovered that removing ehci module before I put the machine into
the dock causes the uhci module to discover the USB device. Dmesg traces are
attached.
Do you still need the usbmon traces?
--
Lukáš Hejtmánek
--
| May 20, 1:39 am 2008 |
| Arjan van de Ven | Re: System call instrumentation
On Mon, 19 May 2008 23:44:53 -0400
the audit subsystem already does all of this... why not use that??
copying twice does mean that if the user wants, he can cheat you. He
can, in another thread, change the string under you. So say you're
doing this for anti-virus purposes, he can make you scan one file and
open another.
The audit subsystem was carefully designed to avoid this trap... how
about using that?
--
| May 20, 7:18 am 2008 |
| Mathieu Desnoyers | Re: System call instrumentation
Hrm, a quick benchmark on my pentium 4 comparing a normal open() system
call executed in a loop to a modified open() syscall which executes the
lines added in the following patch adds 450 cycles to each open() system
call. I added a putname/getname on purpose to see the cost of a second
userspace copy and it's not exactly free.
The normal getname correctly nested, re-using the string previously
copied, should not suffer from that kind of performance hit. Also, given
that the string would be ...
| May 19, 8:44 pm 2008 |
| Arjan van de Ven | Re: [PATCH] Make
On Mon, 19 May 2008 23:24:48 -0400
now that -mm has a WARN(condition, printk arguments), could we make
this use it? The advantage (apart from smaller C code) is that it puts
the printk inside the ---[ cut here ]--- which makes it more likely that
reporters (and kerneloops.org) get the actual text....
--
| May 20, 7:14 am 2008 |
| Dave Jones | Re: [PATCH] Make
On Tue, May 20, 2008 at 07:54:10AM -0700, Linus Torvalds wrote:
> I think Arjan meant like
>
> WARN(next->prev != prev,
> "list_add corruption. next->prev should be "
> "prev (%p), but was %p. (next=%p).\n",
> prev, next->prev, next);
>
> without any "if()" statement at all.
Nice. I like that.
diff --git a/lib/list_debug.c b/lib/list_debug.c
index 4350ba9..311ffab 100644
--- a/lib/list_debug.c
+++ b/lib/list_debug.c
@@ -20,18 +20,14 @@ void __list_add(struct ...
| May 20, 8:20 am 2008 |
| Dave Jones | Re: [PATCH] Make
On Tue, May 20, 2008 at 08:12:41AM -0700, Linus Torvalds wrote:
> So no, lists aren't "special" in any inherent way, they are just special
> in these kinds of "incidentally, a lot of random data structure corruption
> has traditionally shown up in lists, because there are so many of them".
It's also been _really_ useful for showing up random bit flips in bad hardware.
"hey, if that bit had been a 1, this pointer would have looked valid and we
wouldn't have oopsed" has led to quite a ...
| May 20, 8:22 am 2008 |
| Alexey Dobriyan | Re: [PATCH] Make
Why list_head corruptions are special?
--
| May 20, 8:00 am 2008 |
| Dave Jones | Re: [PATCH] Make
On Tue, May 20, 2008 at 07:14:58AM -0700, Arjan van de Ven wrote:
> On Mon, 19 May 2008 23:24:48 -0400
> Dave Jones <davej@redhat.com> wrote:
>
> > printk(KERN_ERR "list_add corruption. next->prev
> > should be " "prev (%p), but was %p. (next=%p).\n",
> > prev, next->prev, next);
> > - BUG();
> > + WARN_ON(1);
> > }
>
>
> now that -mm has a WARN(condition, printk arguments), could we make
> this use it? The advantage (apart from smaller C code) is that it puts
> ...
| May 20, 7:27 am 2008 |
| Dave Jones | [PATCH] Make
Arjan noted that the list_head debugging is BUG'ing when it detects
corruption. By causing the box to panic immediately, we're possibly
losing some bug reports. Changing this to a WARN_ON should mean
we at the least start seeing reports collected at kerneloops.org
[ I chose to BUG() when I first added that code, because I was
chasing a bug which caused a lockup anyway, so it made little difference
to me. ]
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/lib/list_debug.c ...
| May 19, 8:24 pm 2008 |
| Linus Torvalds | Re: [PATCH] Make
It's not that list corruptions are special, but:
- *any* corruption is very interesting, and the earlier we find it the
better
- we have a lot of lists in the kernel, so testing pointers is actually
likely to find stuff.
- and lists are something we can *test* for corruption
That third one is important. Most random pointers we can't sanely test
because they don't have trivial and important patterns.
The second one is relevant too: some of the pointers that we *could* test ...
| May 20, 8:12 am 2008 |
| Alexey Dobriyan | Re: [PATCH] Make (LIST_DEBUG WARN not BUG)
Affirmative, LIST_DEBUG is very useful.
Let's look again at what patch actually does: writes to corrupted memory
will be done even if it's known for sure it's corrupted.
There is
BUG_ON(!list_empty(&father->children));
in forget_original_parent(). Should it be changed to WARN_ON? Why [not]?
--
| May 20, 2:52 pm 2008 |
| Arjan van de Ven | Re: [PATCH] Make
On Tue, 20 May 2008 07:54:10 -0700 (PDT)
Dave...what Linus said ;)
would be nice to get WARN() into mainline soon... ;)
--
| May 20, 9:15 am 2008 |
| Linus Torvalds | Re: [PATCH] Make
I think Arjan meant like
WARN(next->prev != prev,
"list_add corruption. next->prev should be "
"prev (%p), but was %p. (next=%p).\n",
prev, next->prev, next);
without any "if()" statement at all.
Linus
--
| May 20, 7:54 am 2008 |
| Bart Van Assche | Re: [PATCH 2.6.25.1] Suppress more generated files via D ...
On Fri, May 2, 2008 at 5:16 PM, Bart Van Assche
This patch is now obsolete and has been replaced by a new patch -- see
also http://lkml.org/lkml/2008/5/20/32.
Bart.
--
| May 20, 12:16 am 2008 |
| Rusty Russell | Re: [PATCH] virtio_net: free transmit skbs in a timer
Sure, linux/virtio_ring.h:
/* The Host uses this in used->flags to advise the Guest: don't kick me when
* you add a buffer. It's unreliable, so it's simply an optimization. Guest
* will still kick if it's out of buffers. */
#define VRING_USED_F_NO_NOTIFY 1
/* The Guest uses this in avail->flags to advise the Host: don't interrupt me
* when you consume a buffer. It's unreliable, so it's simply an
* optimization. */
No, you misunderstand; this is not a performance issue. On xmit, ...
| May 19, 6:37 pm 2008 |
| Pavel Machek | Re: [patch/rfc 2.6.25-git] gpio: sysfs interface
No, sorry.
I'm not sure if it should go to configfs, or if sysfs should be
improved. But "something" should be done, because we will be stuck
with this interface for a long while.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| May 20, 1:02 am 2008 |
| David Brownell | Re: [patch/rfc 2.6.25-git] gpio: sysfs interface
This isn't configfs, and I didn't happen to notice any polite
way for sysfs users to intercept "mkdir", parse the relevant
directory name, reject illegal names, and pre-populate the
just-created directory with relevant contents.
Were you implying it should go into configfs? If so, do you
maybe have an update to the patch I sent a day or so ago?
--
| May 19, 6:26 pm 2008 |
| Andrew Morton | Re: [patch 2.6.26-rc2-git] gpio: sysfs interface
ick. So we got caught partway through constification and we need to
patch it up with a cast.
--
| May 20, 12:17 am 2008 |
| hooanon05 | Re: [git pull] VFS patches
Hello Al,
I have a question about the commit you made last month.
When an application issues sys_oldumount(), ->umount_begin() will not be
called because the flag is 0. Is this behaviour intended?
And it it better to put the paranthesis around (flags & MNT_FORCE).
Junjiro Okajima
--
| May 20, 5:04 am 2008 |
| Jesper Juhl | Re: [PATCH] fix typo "kernal" -> "kernel"
<snip>
None the less I've added the patch to Trivial. It's the Linux *kernel*
after all, not the Linux kernal.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
--
| May 19, 5:04 pm 2008 |
| Johannes Weiner | Re: [PATCH] fix typo "kernal" -> "kernel"
Hey, there is even kernal.org!
--
| May 19, 8:14 pm 2008 |
| Jesper Juhl | Re: [PATCH] Tighten up the use of loose
I've added this one to the trivial tree. Thanks Nick.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
--
| May 19, 5:10 pm 2008 |
| Uwe Kleine-König | [PATCH] UIO: don't let UIO_CIF and UIO_SMX depend twice on UIO
ae210f188614bb3d1ee3f19c64e28e3cdd44877c introduced a big "if UIO"/"endif"
where all uio drivers are defined. So know there is no need for them to
depend explicitly on UIO.
Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
---
drivers/uio/Kconfig | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index a4aaab9..78e139c 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -15,7 +15,7 @@ if UIO
...
| May 20, 2:24 am 2008 |
| Uwe Kleine-König | [PATCH] UIO: generic platform driver
Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
---
drivers/uio/Kconfig | 7 +++
drivers/uio/Makefile | 1 +
drivers/uio/uio_pdrv.c | 118 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 126 insertions(+), 0 deletions(-)
create mode 100644 drivers/uio/uio_pdrv.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 78e139c..2e9079d 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -26,6 +26,13 @@ config UIO_CIF
To compile ...
| May 20, 2:24 am 2008 |
| Hans J. Koch | May 20, 2:12 pm 2008 | |
| Hans J. Koch | May 20, 2:08 pm 2008 | |
| Uwe | Re: [PATCH 3/3] UIO: generic platform driver
Hello Hans,
For now I suggest 2). Using the clk API might be implemented by a
generic open/release routine. Maybe I will look into that at a later
time. For now I'm happy without clk support, too.
For now you can find two patches in my uio branch at
git://www.modarm9.com/gitsrc/pub/people/ukleinek/linux-2.6.git uio
I rebased them to current Linus' master; otherwise they are unmodified
since the last posts. For completeness I'll resend them as a reply to
this mail.
For shortlog and ...
| May 20, 2:23 am 2008 |
| Mingming Cao | [PATCH-v2] JBD: Fix race between free buffer and commit ...
Updated patch to use existing GFP_KERNEL mask to indicating synchornous
wait in journal_try_to_free_buffers() to resolve the race with
journal_commit_transaction().
JBD: fix race between journal_try_to_free_buffers() and jbd commit transaction
From: Mingming Cao <cmm@us.ibm.com>
journal_try_to_free_buffers() could race with jbd commit transaction when
the later is holding the buffer reference while waiting for the data buffer
to flush to disk. If the caller of journal_try_to_free_buffers() ...
| May 20, 11:02 am 2008 |
| Mingming Cao | [PATCH -v2] JBD2: Fix race between journal free buffer a ...
JBD2: fix race between jbd2_journal_try_to_free_buffers() and jbd2 commit transaction
From: Mingming Cao <cmm@us.ibm.com>
journal_try_to_free_buffers() could race with jbd commit transaction when
the later is holding the buffer reference while waiting for the data buffer
to flush to disk. If the caller of journal_try_to_free_buffers() request
tries hard to release the buffers, it will treat the failure as error and return
back to the caller. We have seen the directo IO failed due to this race. ...
| May 20, 11:03 am 2008 |
| Jens Axboe | Re: [PATCH] JBD: Fix DIO EIO error caused by race betwee ...
So something like this, then?
diff --git a/fs/splice.c b/fs/splice.c
index 7815003..e08a2f5 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -58,8 +58,8 @@ static int page_cache_pipe_buf_steal(struct pipe_inode_info *pipe,
*/
wait_on_page_writeback(page);
- if (PagePrivate(page))
- try_to_release_page(page, GFP_KERNEL);
+ if (PagePrivate(page) && !try_to_release_page(page, GFP_KERNEL))
+ goto out_unlock;
/*
* If we succeeded in removing the mapping, set LRU ...
| May 20, 2:30 am 2008 |
| Mingming Cao | May 20, 10:47 am 2008 | |
| Jan Kara | Re: [PATCH-v2] JBD: Fix race between free buffer and com ...
What is actually the point of entering the function with j_state_lock
held and also keeping it after return? It should be enough to take it
This comment seems a bit misleading to me - I'd rather write there:
@gfp_mask: we use the mask to detect how hard should we try to release
buffers. If __GFP_WAIT and __GFP_FS is set, we wait for commit code to
I think this test is wrong - it should rather be something like
(ret == 0 && (gfp_mask & GFP_KERNEL == GFP_KERNEL)) - or even expand the
test ...
| May 20, 4:53 pm 2008 |
| previous day | today | next day |
|---|---|---|
| May 19, 2008 | May 20, 2008 | May 21, 2008 |
