| From | Subject | Date |
|---|---|---|
| Harvey Harrison | [PATCH] sh: module.c use kernel unaligned helpers
Replace the COPY_UNALIGNED_WORD helper.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
arch/sh/kernel/module.c | 39 +++++----------------------------------
1 files changed, 5 insertions(+), 34 deletions(-)
diff --git a/arch/sh/kernel/module.c b/arch/sh/kernel/module.c
index b3d0a03..5482e65 100644
--- a/arch/sh/kernel/module.c
+++ b/arch/sh/kernel/module.c
@@ -30,6 +30,7 @@
#include <linux/fs.h>
#include <linux/string.h>
#include <linux/kernel.h>
+#include ...
| May 28, 4:38 pm 2008 |
| Harvey Harrison | [PATCH] m32r: module.c use kernel-provided unaligned helpers
Replace the hand-rolled COPY_UNALIGNED_WORD/HWORD
This also possibly fixes a bug in the R_M32R_16_RELA case as it was reading
2 bytes from hlocation, applying the relocation, but writing back 4 bytes
(perhaps it meant to use COPY_UNALIGNED_HWORD rather than _WORD) two bytes of
which were not calculated. This patch writes back only two bytes as hvalue
is a short.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
arch/m32r/kernel/module.c | 150 ...
| May 28, 4:30 pm 2008 |
| Andrew Morton | Re: [PATCH] tmpfs: support aio
On Thu, 29 May 2008 00:13:35 +0100 (BST)
hm. This version:
static ssize_t shmem_file_aio_read(struct kiocb *iocb,
const struct iovec *iov, unsigned long nr_segs, loff_t pos)
{
struct file *filp = iocb->ki_filp;
ssize_t retval;
unsigned long seg;
size_t count;
loff_t *ppos = &iocb->ki_pos;
count = 0;
retval = generic_segment_checks(iov, &nr_segs, &count, VERIFY_WRITE);
if (retval)
return retval;
if (count == 0)
return 0;
retval = 0;
for (seg = 0; seg < nr_segs; ...
| May 28, 4:58 pm 2008 |
| Hugh Dickins | [PATCH] tmpfs: support aio
We have a request for tmpfs to support the AIO interface: easily done,
no more than replacing the old shmem_file_read by shmem_file_aio_read,
cribbed from generic_file_aio_read. (In 2.6.25 its write side was
already changed to use generic_file_aio_write.)
Tests out fine with LTP's ltp-aiodio.sh, given hacks (not included)
to support O_DIRECT. tmpfs cannot honestly support O_DIRECT: its
cache-avoiding-IO nature is at odds with direct IO-avoiding-cache.
Signed-off-by: Hugh Dickins ...
| May 28, 4:13 pm 2008 |
| Eugene_Bordenkircher | BUG/OOPS: Double Lock in fsl_usb2_udc.c
Hello All,
I have recently found an instance in the drivers/usb/gadget/fsl_usb2_udc.c
file that causes the udc->lock spinlock to be taken twice. The problem
arises when you disconnect from the DR port and then reconnect. The
interrupt routine for the driver receives a 'reset' event which takes the
lock and calls reset_queues() which in turn calls
udc->driver->disconnect(). Eventually, that disconnect() call comes back
up to the fsl_usb2_udc driver and calls fsl_ep_disable() which ...
| May 28, 3:25 pm 2008 |
| Lee Revell | Re: mmap over HPET - 32 bit wrap arround
HPET counter can be either 32 or 64 bit. Check COUNT_SIZE_CAP.
http://www.intel.com/hardwaredesign/hpetspec_1.pdf
Lee
--
| May 28, 4:57 pm 2008 |
| Raz | mmap over HPET - 32 bit wrap arround
I am wondering wether someone can explain how hpet behaves. The bellow
is a short program that reads from a mmaped /dev/hpet the time. I am
running it and it looks that afer ~296 seconds the counter resets . I
AM RUNNING 64bi KERNEL(2.6.18-8.el5) and reading a 64BIT VARIABLE.
my hpet is 14MHZ, so I am guessing a 32bit wraparound ( ~296 * 14Mhz
) = MAX_INT . but why ?
thank you
raz
#include <stdint.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>ing 6
#include ...
| May 28, 3:19 pm 2008 |
| Sam Ravnborg | Re: KBUILD_DEFCONFIG change
Use the shorter version:
ARCH=ia64 make bigsur_defconfig
There is no need to fiddle with KBUILD_DEFCONFIG.
KBUILD_DEFCONFIG is a pure internal thing that
may change without notice.
Sam
--
| May 28, 4:44 pm 2008 |
| Doug Reiland | KBUILD_DEFCONFIG change
The following used to work:
ARCH=ia64 KBUILD_DEFCONFIG=bigsur_defconfig make defconfig
Now 2.6.25 makes you do:
ARCH=ia64 make KBUILD_DEFCONFIG=bigsur_defconfig defconfig
Is this my intent?
It seems like the arch/<xxxx>/Makefile files should be:
KBUILD_DEFCONFIG ?= generic_defconfig
Instead of
KBUILD_DEFCONFIG := generic_defconfig
--
| May 28, 3:05 pm 2008 |
| Johannes Berg | Re: pull request: wireless-2.6 2008-05-28
What about
[PATCH] b43legacy: fix build errors when DMA or PIO are not selected
johannes
| May 28, 3:11 pm 2008 |
| John W. Linville | pull request: wireless-2.6 2008-05-28
David,
Another round of fixes for 2.6.26 follows...
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit 289c79a4bd350e8a25065102563ad1a183d1b402:
Patrick McHardy (1):
vlan: Use bitmask of feature flags instead of seperate feature bits
are available in the git repository at:
...
| May 28, 2:38 pm 2008 |
| Jan Kara | [PATCH] Silence warnings about non-uptodate buffers
Hello,
the series of patches below gets rid of warning messages in mark_buffer_dirty()
when underlying block device becomes unavailable. Andrew, would you merge them
please?
Honza
--
| May 28, 2:56 pm 2008 |
| Jan Kara | [PATCH] jbd: Silence warnings about non-uptodate buffers
When underlying block device becomes unavailable (e.g. someone pulling an
USB stick from under us), kernel produces warning about non-uptodate buffer
(superblock) being marked dirty. Silence these warnings by making buffer
uptodate before marking it dirty.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/jbd/journal.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c
index b99c3b3..9303608 100644
--- a/fs/jbd/journal.c
+++ ...
| May 28, 2:56 pm 2008 |
| Jan Kara | [PATCH] ext3: Silence warnings about non-uptodate buffers
When underlying block device becomes unavailable (e.g. someone pulling an
USB stick from under us), kernel produces warning about non-uptodate buffer
(superblock) being marked dirty. Silence these warnings by making buffer
uptodate before marking it dirty.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/ext3/super.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index fe3119a..19d2fb4 100644
--- a/fs/ext3/super.c
+++ ...
| May 28, 2:56 pm 2008 |
| Jan Kara | [PATCH] jbd2: Silence warnings about non-uptodate buffers
When underlying block device becomes unavailable (e.g. someone pulling an
USB stick from under us), kernel produces warning about non-uptodate buffer
(superblock) being marked dirty. Silence these warnings by making buffer
uptodate before marking it dirty.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/jbd2/journal.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 2e24567..55de8f7 100644
--- a/fs/jbd2/journal.c
+++ ...
| May 28, 2:56 pm 2008 |
| Jan Kara | [PATCH] ext2: Silence warnings about non-uptodate buffers
When underlying block device becomes unavailable (e.g. someone pulling an
USB stick from under us), kernel produces warning about non-uptodate buffer
(superblock) being marked dirty. Silence these warnings by making buffer
uptodate before marking it dirty.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/ext2/super.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/ext2/super.c b/fs/ext2/super.c
index ef50cbc..2941bc3 100644
--- a/fs/ext2/super.c
+++ ...
| May 28, 2:56 pm 2008 |
| Jan Kara | Re: [PATCH] Silence warnings about non-uptodate buffers
And just for reference a similar patch for UDF which I'll merge through
my git tree.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
---
From 756bc361a065b65df9977c2632472f587659a6f7 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Wed, 28 May 2008 23:39:19 +0200
Subject: [PATCH] udf: Silence warnings about non-uptodate buffers
When underlying block device becomes unavailable (e.g. someone pulling an
USB stick from under us), kernel produces warning about ...
| May 28, 3:06 pm 2008 |
| Jan Kara | [PATCH] ext4: Silence warnings about non-uptodate buffers
When underlying block device becomes unavailable (e.g. someone pulling an
USB stick from under us), kernel produces warning about non-uptodate buffer
(superblock) being marked dirty. Silence these warnings by making buffer
uptodate before marking it dirty.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/ext4/super.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 09d9359..298c94f 100644
--- a/fs/ext4/super.c
+++ ...
| May 28, 2:56 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 20/21] ide: remove no longer used ide_pio_timings[]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/ide-lib.c | 17 -----------------
include/linux/ide.h | 8 --------
2 files changed, 25 deletions(-)
Index: b/drivers/ide/ide-lib.c
===================================================================
--- a/drivers/ide/ide-lib.c
+++ b/drivers/ide/ide-lib.c
@@ -76,23 +76,6 @@ static u8 ide_rate_filter(ide_drive_t *d
}
/*
- * Standard (generic) timings for PIO modes, from ATA2 specification.
- * These ...
| May 28, 2:43 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 04/21] ide: move some bits from ide-timing.h to < ...
Move struct ide_timing and IDE_TIMING_* defines to <linux/ide.h>
from drivers/ide/ide-timing.h.
While at it:
- use u8/u16 instead of short for struct ide_timing fields
- use enum for IDE_TIMING_*
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/ide-timing.h | 23 -----------------------
include/linux/ide.h | 28 ++++++++++++++++++++++++++++
2 files changed, 28 insertions(+), 23 ...
| May 28, 2:40 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 08/21] ali14xx: convert to use ide_timing_find_mode()
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/Kconfig | 1 +
drivers/ide/legacy/ali14xx.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
Index: b/drivers/ide/Kconfig
===================================================================
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -988,6 +988,7 @@ config BLK_DEV_4DRIVES
config BLK_DEV_ALI14XX
tristate "ALI ...
| May 28, 2:40 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 12/21] cmd640: convert to use ide_timing_find_mode()
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/Kconfig | 1 +
drivers/ide/pci/cmd640.c | 8 ++++++--
2 files changed, 7 insertions(+), 2 deletions(-)
Index: b/drivers/ide/Kconfig
===================================================================
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -329,6 +329,7 @@ config BLK_DEV_PLATFORM
config BLK_DEV_CMD640
tristate "CMD640 ...
| May 28, 2:42 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 10/21] qd65xx: convert to use ide_timing_find_mode()
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/Kconfig | 1 +
drivers/ide/legacy/qd65xx.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
Index: b/drivers/ide/Kconfig
===================================================================
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -1018,6 +1018,7 @@ config BLK_DEV_HT6560B
config BLK_DEV_QD65XX
tristate "QDI ...
| May 28, 2:42 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 02/21] ide: remove unused XFER_UDMA_SLOW
Remove unused XFER_UDMA_SLOW from ide_timing[].
While at it:
- fix re-defining XFER_PIO_5 (no need to define it in ide-timing.h as
it is defined in <linux/ata.h> which is included by <linux/hdreg.h>)
- fix whitespace damage
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/ide-timing.h | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
Index: ...
| May 28, 2:40 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 01/21] ide: remove needless includes from ide-lib.c
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/ide-lib.c | 15 ---------------
1 file changed, 15 deletions(-)
Index: b/drivers/ide/ide-lib.c
===================================================================
--- a/drivers/ide/ide-lib.c
+++ b/drivers/ide/ide-lib.c
@@ -1,26 +1,11 @@
-#include <linux/module.h>
#include <linux/types.h>
#include <linux/string.h>
#include <linux/kernel.h>
-#include <linux/timer.h>
-#include <linux/mm.h>
#include ...
| May 28, 2:39 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 00/21] ide: convert ide-timing.h to ide-timings.c ...
This (fairly obvious/trivial) patchset converts drivers/ide/ide-timing.h
into ide-timings.c library (enabled by host drivers that want to use it by
selecting CONFIG_IDE_TIMINGS config option) and updates host drivers still
using ide_pio_timings[] to use ide_timing_find_mode() instead.
Also as a bonus it moves PIO blacklist from ide-lib.c to ide-pio-blacklist.c.
diffstat:
drivers/ide/Kconfig | 16 +
drivers/ide/Makefile | 4
drivers/ide/arm/palm_bk3710.c | ...
| May 28, 2:39 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 21/21] ide: move PIO blacklist to ide-pio-blacklist.c
Move PIO blacklist to ide-pio-blacklist.c.
While at it:
- fix comment
- fix whitespace damage
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/Makefile | 3 -
drivers/ide/ide-lib.c | 96 ----------------------------------------
drivers/ide/ide-pio-blacklist.c | 94 +++++++++++++++++++++++++++++++++++++++
include/linux/ide.h | 2
4 files changed, 98 ...
| May 28, 2:43 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 16/21] sl82c105: convert to use ide_timing_find_mode()
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/Kconfig | 1 +
drivers/ide/pci/sl82c105.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
Index: b/drivers/ide/Kconfig
===================================================================
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -704,6 +704,7 @@ config BLK_DEV_SIS5513
config BLK_DEV_SL82C105
tristate "Winbond ...
| May 28, 2:42 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 06/21] ide: checkpatch.pl fixes for ide-timing.h
Also fix placement of comments in ide_timing_compute() while at it.
There should be no functional changes caused by this patch
(md5sum was verified to be the same before/after the patch).
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/ide-timing.h | 93 ++++++++++++++++++++++++-----------------------
1 file changed, 48 insertions(+), 45 deletions(-)
Index: b/drivers/ide/ide-timing.h
===================================================================
--- ...
| May 28, 2:40 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 18/21] ide-pmac: convert to use ide_timing_find_mode()
Also update my Copyrights while at it.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/ppc/pmac.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
Index: b/drivers/ide/ppc/pmac.c
===================================================================
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -5,7 +5,7 @@
* for doing DMA.
*
* Copyright (C) 1998-2003 Paul ...
| May 28, 2:43 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 15/21] opti621: convert to use ide_timing_find_mode()
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/Kconfig | 1 +
drivers/ide/pci/opti621.c | 10 +++++-----
2 files changed, 6 insertions(+), 5 deletions(-)
Index: b/drivers/ide/Kconfig
===================================================================
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -426,6 +426,7 @@ config BLK_DEV_GENERIC
config BLK_DEV_OPTI621
tristate "OPTi ...
| May 28, 2:42 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 09/21] ht6560b: convert to use ide_timing_find_mode()
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/Kconfig | 1 +
drivers/ide/legacy/ht6560b.c | 7 +++----
2 files changed, 4 insertions(+), 4 deletions(-)
Index: b/drivers/ide/Kconfig
===================================================================
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -1008,6 +1008,7 @@ config BLK_DEV_DTC2278
config BLK_DEV_HT6560B
tristate ...
| May 28, 2:41 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 03/21] ide: use u8 for xfer modes in ide-timing.h
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/ide-timing.h | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
Index: b/drivers/ide/ide-timing.h
===================================================================
--- a/drivers/ide/ide-timing.h
+++ b/drivers/ide/ide-timing.h
@@ -29,7 +29,7 @@
#include <linux/hdreg.h>
struct ide_timing {
- short mode;
+ u8 mode;
short ...
| May 28, 2:40 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 07/21] ide: convert ide-timing.h to ide-timings.c ...
* Don't include ide-timing.h in cs5535 and sis5513 host drivers
(they don't need it currently).
* Convert ide-timing.h to ide-timings.c library and add CONFIG_IDE_TIMINGS
config option to be selected by host drivers using the library.
While at it:
- fix ide_timing_find_mode() placement
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/Kconfig | 7 +
drivers/ide/Makefile ...
| May 28, 2:40 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 17/21] ide-mpc8xx: convert to use ide_timing_find ...
Also fix (disabled) debugging code while at it.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/ppc/mpc8xx.c | 33 +++++++++++++--------------------
1 file changed, 13 insertions(+), 20 deletions(-)
Index: b/drivers/ide/ppc/mpc8xx.c
===================================================================
--- a/drivers/ide/ppc/mpc8xx.c
+++ b/drivers/ide/ppc/mpc8xx.c
@@ -89,7 +89,7 @@ ide_ioport_desc_t ...
| May 28, 2:43 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 19/21] ide: move ide_pio_cycle_time() to ide-timings.c
All ide_pio_cycle_time() users already select CONFIG_IDE_TIMINGS
so move the function from ide-lib.c to ide-timings.c.
While at it:
- convert ide_pio_cycle_time() to use ide_timing_find_mode()
- cleanup ide_pio_cycle_time() a bit
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/ide-lib.c | 23 -----------------------
drivers/ide/ide-timings.c | 22 ++++++++++++++++++++++
...
| May 28, 2:43 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 13/21] cmd64x: convert to use ide_timing_find_mode()
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/Kconfig | 1 +
drivers/ide/pci/cmd64x.c | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
Index: b/drivers/ide/Kconfig
===================================================================
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -495,6 +495,7 @@ config BLK_DEV_ATIIXP
config BLK_DEV_CMD64X
tristate ...
| May 28, 2:42 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 11/21] alim15x3: convert to use ide_timing_find_mode()
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/Kconfig | 1 +
drivers/ide/pci/alim15x3.c | 6 ++----
2 files changed, 3 insertions(+), 4 deletions(-)
Index: b/drivers/ide/Kconfig
===================================================================
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -458,6 +458,7 @@ config BLK_DEV_AEC62XX
config BLK_DEV_ALI15X3
tristate "ALI ...
| May 28, 2:42 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 14/21] cy82c693: convert to use ide_timing_find_mode()
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/Kconfig | 1 +
drivers/ide/pci/cy82c693.c | 9 ++++-----
2 files changed, 5 insertions(+), 5 deletions(-)
Index: b/drivers/ide/Kconfig
===================================================================
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -510,6 +510,7 @@ config BLK_DEV_TRIFLEX
config BLK_DEV_CY82C693
tristate ...
| May 28, 2:42 pm 2008 |
| Bartlomiej Zolnierki ... | [PATCH 05/21] ide: remove XFER_* masks from ide-timing.h
* Check requested xfer mode against xfer modes instead of XFER_* masks
in ide_timing_compute() and cs5535.c::cs5535_set_speed().
* Remove XFER_[MODE,MWDMA,EPIO,PIO] masks.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
drivers/ide/ide-timing.h | 24 +++++++-----------------
drivers/ide/pci/cs5535.c | 4 +---
2 files changed, 8 insertions(+), 20 deletions(-)
Index: ...
| May 28, 2:40 pm 2008 |
| Dave Jones | Re: Call for nominations
On Wed, May 28, 2008 at 05:34:58PM -0400, Theodore Ts'o wrote:
>
> [ This is the last message concerning the kernel summit that will be sent
> to LKML; discussion should take place from henceforth on 2008 Kernel
> Summit discuss list, and folks can subcribe by going to the URL:
> https://lists.linux-foundation.org/mailman/listinfo/ksummit-2008-pc ]
That should be https://lists.linux-foundation.org/mailman/listinfo/ksummit-2008-discuss
of course. the -pc list is the list used for ...
| May 28, 2:50 pm 2008 |
| Theodore Ts'o | Call for nominations
[ This is the last message concerning the kernel summit that will be sent
to LKML; discussion should take place from henceforth on 2008 Kernel
Summit discuss list, and folks can subcribe by going to the URL:
https://lists.linux-foundation.org/mailman/listinfo/ksummit-2008-pc ]
Hi all,
As in previous years, the program committee will consider people from a
list of potential nominees. To quote from a message from Jonathan
Corbet documenting the process from previous years (with a few ...
| May 28, 2:34 pm 2008 |
| Randy Dunlap | linux-next 20080528: XEN build error when no Power Mgt enabled
linux-next-20080528/drivers/xen/manage.c: In function 'xen_suspend':
linux-next-20080528/drivers/xen/manage.c:43: error: implicit declaration of function 'device_power_down'
linux-next-20080528/drivers/xen/manage.c:65: error: implicit declaration of function 'device_power_up'
linux-next-20080528/drivers/xen/manage.c: In function 'do_suspend':
linux-next-20080528/drivers/xen/manage.c:114: error: implicit declaration of function 'device_resume'
make[3]: *** [drivers/xen/manage.o] Error ...
| May 28, 2:38 pm 2008 |
| Jeremy Fitzhardinge | Re: linux-next 20080528: XEN build error when no Power M ...
Thanks for the reminder. That was on my TODO list.
J
--
| May 28, 2:33 pm 2008 |
| Andrew Morton | Re: Oops during hibernation - two times the same one
On Thu, 29 May 2008 00:09:36 +0200
Looks like this is
BUG_ON(inode->i_state == I_CLEAR);
Please do enable CONFIG_DEBUG_BUGVERBOSE. Turning off this stuff
Beats me. Somehow the swap device's blockdev inode got I_CLEAR set
while swsusp_write() was playing with it. Or during.
I guess we could add I_CLEAR checks on resume_bdev into
kernel/power/swap.c in various places.
Had there been any swapoffs before or during this suspend?
Does the above BUG only occur when swsusp encountered ...
| May 28, 3:29 pm 2008 |
| Rafael J. Wysocki | Re: Oops during hibernation - two times the same one
Thanks for the report, but I have no idea of what could go wrong.
--
"Premature optimization is the root of all evil." - Donald Knuth
--
| May 28, 3:09 pm 2008 |
| Ondrej Zary | Oops during hibernation - two times the same one
Hello,
I'm using hibernation on my desktop machine every day instead of power off. It
mostly works but sometimes aborts with "no space left on device" error.
Closing some programs and trying again usually fixes it - but recently, I got
two oopses instead. I'm sending them because they're the same, only some
details are different. Does anyone know what might be wrong?
------------[ cut here ]------------
Kernel BUG at c015610b [verbose debug info unavailable]
invalid opcode: 0000 ...
| May 28, 2:23 pm 2008 |
| Jan Engelhardt | Re: Pipe buffers' limit of 16 * 4K
You could have a look at the tee(2) system call and see whether it helps
you a bit. Something along the lines of:
int pfd[2];
pipe(pfd); /* tee() wants an fd... */
tee(STDIN_FILENO, pfd[1], len, SPLICE_F_NONBLOCK);
read(pfd[0], ..., also in nonblock-mode)
Of course this also has a certain drawback, namely that the pipe will
only give you as much bytes as it carries, and no more than that,
because the write side of the pipe at STDIN_FILENO is currently
blocking exactly because the ...
| May 28, 3:05 pm 2008 |
| Fausto Richetti Blanco | Re: Pipe buffers' limit of 16 * 4K
I think you did not receive it so I'm sending again....
On Mon, May 26, 2008 at 2:43 PM, Fausto Richetti Blanco
--
| May 28, 2:22 pm 2008 |
| James Kosin | Re: optimizing out inline functions
Another way would be to have:
static inline void some_debug_function(var1)
{
#ifdef KCONFIG_DEBUG_SOMETHING
something = var1;
printk(some debug text);
#endif
}
BUT, this probably violates some styling rules.
James
}
--
| May 28, 1:37 pm 2008 |
| Johannes Berg | Re: Linux 2.6.26-rc4
rtnl, in fact, I suspect.
Actually, please apply the patch "=EF=BB=BFrt2x00: Use atomic interface
iteration in irq context" before trying anything more, that'll fix it.
I'm not sure where Linville is hiding ;)
(http://article.gmane.org/gmane.linux.kernel.wireless.general/15268)
johannes
| May 28, 1:17 pm 2008 |
| John W. Linville | Re: Linux 2.6.26-rc4
Zzzzzzz....huh, what?? :-)
I just sent a pull request to Dave M. with that patch in it.
Last weekend was a long one in the USA, so I apologize for the delay...
John
--
John W. Linville
linville@tuxdriver.com
--
| May 28, 2:48 pm 2008 |
| Linus Torvalds | Re: Linux 2.6.26-rc4
.. again, please give the full oops, without that we just know that "an
I assume it's related to the oops above - the oops probably happened while
holding some mutex or other lock, which is why network-related stuff then
blocks on that lock (which will never be released, since the oops killed
the process that held it).
I suspect the oops is also why the bootup breaks, so it's likely all the
same issue. Please save the dmesg into a file, reboot into a working
setup, and send ...
| May 28, 1:10 pm 2008 |
| Christoph Lameter | Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB
Could the nommu people either tell us what this is all about? Or junk the
code. This looks very wrong.
--
| May 28, 1:29 pm 2008 |
| Pekka Enberg | Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB
(cc'ing linux-kernel)
We use kobjsize() for pointers returned from do_mmap() which is why I
kept the page->index case. Are we using PageCompound for those as well?
Hmm...
--
| May 28, 1:03 pm 2008 |
| Pekka Enberg | Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB
I don't know how the nommu code is supposed to work. I simply assumed it
has a reason for being there and that compound_order() is not enough to
handle that.
--
| May 28, 1:25 pm 2008 |
| Christoph Lameter | Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB
What does do_mmap have to do with page->index?
--
| May 28, 1:25 pm 2008 |
| Steve French | optimizing out inline functions
In trying to remove some macros, I ran across another kernel style
question. I see two ways that people try to let the compiler optimize
out unused code and would like to know which is preferred. The first
example uses an empty inline function and trusts the compiler will
optimize it out.
#ifdef CONFIG_DEBUG_SOMETHING
static inline void some_debug_function(var1)
{
something = var1;
printk(some debug text);
}
#else
static inline void some_debug_function(var1)
{
/* empty ...
| May 28, 12:51 pm 2008 |
| Sam Ravnborg | Re: optimizing out inline functions
With reference to a recent thread about kconfig
I would prefer:
static inline void some_debug_function(var1)
{
if (KCONFIG_DEBUG_SOMETHING) {
something = var1;
printk(some debug text);
}
}
But we do not have KCONFIG_DEBUG_SOMETHING available
so the second best is to use an empty function
to keep the typechecking in place.
IIRC gcc optimize both away.
Sam
--
| May 28, 1:00 pm 2008 |
| Pekka Enberg | Re: optimizing out inline functions
Both are optimized out but empty function is preferred for type checking.
--
| May 28, 12:54 pm 2008 |
| Stephen Hemminger | [PATCH] sysctl: permission check based on capability not euid
This patch modifies the permission checks for sysctl's from being based on uid=0 (root)
to use the capability system. This matches the behavior of other OS's using sysctl's
and capabilities. Linux has tried to get away from using uid=0 for security overrides
and use capabilities instead.
I was working on Quagga enhancement that involved enabling a sysctl, and it didn't
work because is a safe daemon and drops privileges and resets its real/effective uid
after initialization; it then re-enables ...
| May 28, 12:12 pm 2008 |
| Chris Wright | Re: [PATCH] sysctl: permission check based on capability ...
I don't think CAP_SYS_ADMIN makes sense for net.*, for example.
--
| May 28, 1:14 pm 2008 |
| Cyrill Gorcunov | [PATCH] x86: nmi - fix incorrect NMI watchdog used by default
The commit
commit 4b82b277707a39b97271439c475f186f63ec4692
Author: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Sat May 24 19:36:35 2008 +0400
set nmi_watchdog to NMI_IO_APIC as by default. This causes hangs on some
machines with buggy watchdogs. Fix it - i.e. restore old behaviour.
Thanks to Sitsofe Wheeler and Adrian Bunk for catching the problem
and Maciej W. Rozycki for explanation what is going on there.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
CC: Maciej W. Rozycki ...
| May 28, 12:00 pm 2008 |
| Ingo Molnar | Re: [PATCH] x86: nmi - fix incorrect NMI watchdog used b ...
applied, thanks Cyrill.
Ingo
--
| May 28, 12:08 pm 2008 |
| Rik van Riel | Re: [PATCH] NTP: Let update_persistent_clock() sleep
On Wed, 28 May 2008 19:15:41 +0100 (BST)
Acked-by: Rik van Riel <riel@redhat.com>
--
All rights reversed.
--
| May 28, 12:17 pm 2008 |
| Maciej W. Rozycki | [PATCH] NTP: Let update_persistent_clock() sleep
This is a change that makes the 11-minute RTC update be run in the
process context. This is so that update_persistent_clock() can sleep,
which may be required for certain types of RTC hardware -- most notably
I2C devices.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
Hello,
After the initial enthusiasm, I am not sure how my series of patches to
let read_persistent_clock() and update_persistent_clock() use the class
RTC subsystem is going to be handled. As keeping the order ...
| May 28, 11:15 am 2008 |
| Qinghuang Feng | [PATCH]scsi/arm: check the return value of device_create ...
powertec.c : add code to print an error message while device_create_file() called from powertecscsi_probe() fail
Signed-off-by: Qinghuang Feng <s3c24xx@gmail.com>
---
diff --git a/drivers/scsi/arm/powertec.c b/drivers/scsi/arm/powertec.c
index d9a546d..14e25a6 100644
--- a/drivers/scsi/arm/powertec.c
+++ b/drivers/scsi/arm/powertec.c
@@ -315,6 +315,7 @@ powertecscsi_probe(struct expansion_card
struct powertec_info *info;
void __iomem *base;
int ret;
+ int ferr;
ret = ...
| May 28, 11:11 am 2008 |
| Jason Wessel | [GIT PULL] kgdb fixes for 2.6.26-rc4
Linus, please pull from the for_linus branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git
for_linus
The first patch makes use of the helper functions that were introduced
in the mainline kernel.
The second patch fixes the boot regression failures when using the
kgdb tests and CONFIG_DEBUG_RODATA.
Thanks,
Jason.
---
Harvey Harrison (1):
kgdb: use common ascii helpers and put_unaligned_be32 helper
Jason Wessel (1):
kgdbts: Use HW ...
| May 28, 11:05 am 2008 |
| Pekka Enberg | Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project
Hi James,
On Thu, May 29, 2008 at 12:01 AM, James Bottomley
I'm not sure what you expect to happen if we "shut down" the Janitors
project. The important janitorial work doesn't just magically
disappear. For example, we still need people for:
- Fixing API misuse
- Converting code from old APIs to new ones
- Consolidating duplicate code
- Fixing error handling code
- Removing unused code
- De-obfuscating code (e.g. removing bad macro magic, etc.)
And, quite frankly, I don't ...
| May 28, 2:31 pm 2008 |
| Luck, Tony | RE: [Ksummit-2008-discuss] Fixing the Kernel Janitors project
That depends on whether we are gradually adding to the pool
of developers, or seeing an increasing stream of newcomers
who supply a patch or two before disappearing again.
If you look at the list of contributors some old release for
which we have good data (say 2.6.16). How many of those people
contributed to each of the following releases? Does the
decay curve look steeper or more gentle if you start from
a more recent release?
-Tony
--
| May 28, 4:23 pm 2008 |
| James Bottomley | Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project
Yes, the median age of the MAINTAINERS is rising. Not quite at the rate
of a year per year which would show we have practically no turn over,
but it is rising.
However, even if there were no recruitment problem at all, getting more
people involved is always better because it means more contributions.
And contributions (useful ones) are the lifeblood that moves the kernel
I don't think so. But that's not really what I'm saying. I'm saying we
need to make the process of encouraging useful ...
| May 28, 3:35 pm 2008 |
| James Bottomley | [Ksummit-2008-discuss] Fixing the Kernel Janitors project
In the spirit of having a more process than technical based kernel
summit, I'd like to put the topic of the kernel Janitors project up for
discussion.
In the early days, the project was conceived as a way of getting fresh
blood into kernel development by giving them fairly simple but generally
useful tasks and hoping they'd move more into the mainstream. If we
wind forwards to 2008, there's considerable and rising friction being
generated by janitorial patches. This is only an ...
| May 28, 10:20 am 2008 |
| David Woodhouse | Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project
Do we really have a problem recruiting people to work in the kernel? On
what do you base that observation?
On a similar note, do we have any real data on the question of whether
those who are volunteering the patches which raise so much ire would
_ever_ become productive members of the team, even if we were to nurture
them properly?
--
dwmw2
--
| May 28, 3:18 pm 2008 |
| James Bottomley | Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project
Isn't the kernel mentors project supposed to help us at least get
feedback on that problem (if not prevent it altogether)?
James
--
| May 28, 1:38 pm 2008 |
| David Woodhouse | Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project
The example that sums it up for me is this one:
http://lkml.org/lkml/2008/5/18/20
We have people making minor cosmetic changes, and not paying even the
_slightest_ attention to what they're doing. This one's a particularly
scary example because it's something even the most non-technical person
should have spotted; there's _no_ excuse. It's the cosmetic equivalent
of a naïve warning fix that leaves the actual bug in place.
I think you're right that the status quo is damaging, and I don't ...
| May 28, 1:49 pm 2008 |
| James Bottomley | Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project
Right, but that's why I think we have to change the process. If we keep
the Janitors project, then the bar has to be raised so that it becomes
more participatory and thought oriented (i.e. eliminate from the outset
anyone who is not going to graduate from mechanical changes to more
useful ones). That's why I think bug finding and reporting is a better
thing to do. There are mechanical aspects to finding bugs but it is a
useful service. Bug fixing is participatory because we usually do ...
| May 28, 2:01 pm 2008 |
| James Bottomley | Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project
I'm just outlining the possible solutions; shutting it down wasn't the
one I advocated. One can argue that janitorial changes with enough
intrinsic value tend to get done anyway regardless of whether we have
The problem is that there's something in the way all of this is working
that's causing politeness to get short shrift. In turn that's giving
lkml a larger than normal reputation for being a free for all dog fight
and discouraging potential contributors from coming forwards.
Appeals to ...
| May 28, 2:42 pm 2008 |
| H. Peter Anvin | Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project
As far as whitespace fixes, it seems we should just declare a flag day,
specifically, right before Linus releases 2.6.26 or .27 he'd run
"cleanfile" on the WHOLE TREE and check it in (either as one patch or
several.)
After that, one would either have to use "patch -l" to refresh patches
across the flag day, or I would write a reverse version of "cleanpatch"
(one which cleans the minus lines and the context instead of the output)
to fix them up.
Then the whole tree would be ...
| May 28, 10:43 am 2008 |
| Rik van Riel | Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project
On Wed, 28 May 2008 12:20:12 -0500
I've had some limited success with:
http://kernelnewbies.org/KernelProjects
One problem is that people end up beginning with a project but
for some reason stop working on it later - with no indication
as to whether the project ended up being too difficult, or they
ran out of time, or something else happened...
--
All rights reversed.
--
| May 28, 12:08 pm 2008 |
| Greg KH | Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project
My raw numbers show that the number of individual kernel contributors
continues to increase with every release, so this might not be as much
I agree.
thanks,
greg k-h
--
| May 28, 3:51 pm 2008 |
| Chris Mason | Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project
I think our mistake is the assumption that everyone who wants to contribute to
the kernel wants to code, or that everyone wants to end up at the top of the
major feature contributors list. For lots of people, we're going to be that
experiment from college they never quite want to admit to later on in life.
Looking at the KernelProjects link, bugzilla is at the buttom and janitors is
at the top. I've always thought the janitors project was important, but
maybe we want to change the ...
| May 28, 1:15 pm 2008 |
| Chris Friesen | iTCO watchdog timer broken for Intel 3100 chipset
Hi all,
We've got a board with the Intel 3100 chipset. It shows a PCI id of
2670, which matches PCI_DEVICE_ID_INTEL_ESB2_0 and so the iTCO_wdt.c
driver happily initializes. However, the documentation for the TCO wdt
for this chipset doesn't match the implementation in the driver, so
things get messed up.
I'm not sure why the PCI IDs match, but maybe there is something else
that the iTCO_wdt driver should key off of to make sure it doesn't try
to run invalid code?
On another ...
| May 28, 10:17 am 2008 |
| H. Peter Anvin | Re: [X86] Fix up silly i1586 boot message.
LOL. Merged.
-hpa
--
| May 28, 10:31 am 2008 |
| Dave Jones | [X86] Fix up silly i1586 boot message.
Trying to boot a 64-bit kernel on a 32bit Pentium 4 gets
you an amusing message along the lines of.
"you need an x86-64, but you only have an i1586"
due to the P4 being family F. Munge it to be 686.
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/arch/x86/boot/cpu.c b/arch/x86/boot/cpu.c
index 00e19ed..882c839 100644
--- a/arch/x86/boot/cpu.c
+++ b/arch/x86/boot/cpu.c
@@ -28,6 +28,8 @@ static char *cpu_name(int level)
if (level == 64) {
return "x86-64";
} else {
+ if ...
| May 28, 9:57 am 2008 |
| Maciej W. Rozycki | Re: [X86] Fix up silly i1586 boot message.
Pardon my ignorance -- is there anything special about the number 801586?
It might be fun to display the family in hexadecimal though -- if86 or
80F86. ;)
Maciej
--
| May 28, 10:53 am 2008 |
| H. Peter Anvin | Re: [X86] Fix up silly i1586 boot message.
uname reports i686 on these chips. The rest is ridiculous.
-hpa
--
| May 28, 12:30 pm 2008 |
| H. Peter Anvin | Re: [X86] Fix up silly i1586 boot message.
Actually, I have seen some Intel literature talking about the 786. This
was back when the 486 was new, and they wanted to impress how advanced
their roadmap was. Needless to say, it was completely bogus.
-hpa
--
| May 28, 11:11 am 2008 |
| H. Peter Anvin | Re: [X86] Fix up silly i1586 boot message.
Merged; however, if you could in the future use x86: instead of [X86] as
the prefix, it would save us having to edit it manually.
-hpa
--
| May 28, 10:34 am 2008 |
| Dave Jones | Re: [X86] Fix up silly i1586 boot message.
On Wed, May 28, 2008 at 07:48:03PM +0200, Jan Engelhardt wrote:
>
> On Wednesday 2008-05-28 18:57, Dave Jones wrote:
>
> >Trying to boot a 64-bit kernel on a 32bit Pentium 4 gets
> >you an amusing message along the lines of.
> >"you need an x86-64, but you only have an i1586"
> >due to the P4 being family F. Munge it to be 686.
>
> What is wrong with it? If i386, 486, 586 and 686 are valid names,
> why should not 786 (or rather 1586... since someone thought it
> would be cool ...
| May 28, 10:59 am 2008 |
| Jan Engelhardt | May 28, 11:02 am 2008 | |
| Jan Engelhardt | Re: [X86] Fix up silly i1586 boot message.
What is wrong with it? If i386, 486, 586 and 686 are valid names,
why should not 786 (or rather 1586... since someone thought it
would be cool to jump the number^1) be?
[^1 Which also is interesting because the original number had an 80
prepended, i.e. 80286, 80586,... and you'd guess what number 1586
would map to.]
--
| May 28, 10:48 am 2008 |
| Maciej W. Rozycki | Re: [X86] Fix up silly i1586 boot message.
Hmm, 801586 should be fine as with Intel 80 used to stand for
microprocessors and 81586 would be confusing as I think 81 was used for
RAM devices (82 stood for peripherals, BTW). My vote is for 80F86 though,
with "F" standing for "fast" as in the 74 TTL series. ;)
Maciej
--
| May 28, 11:25 am 2008 |
| Doug Reiland | Re: Kbuild changes since 2.6.21??
By bad, drivers/power/Makefile is ok.
I thought I reproduced the issue there.
--
| May 28, 11:27 am 2008 |
| Doug Reiland | Kbuild changes since 2.6.21??
There are some makefiles that look at CONFIG_XXXX variables to make
decisions. For example, drivers/power/Makefile has the following
lines:
ifeq ($(CONFIG_SYSFS),y)
power_supply-objs += power_supply_sysfs.o
endif
If I run make clean or make mrproper, it doesn't see CONFIG_SYSFS set
anymore so it doesn't cleanup power_supply_sysfs.o.
This is for 2.6.25, but I think this use to work for 2.6.21. I am
using drivers/power/Makefile as an example, but I am seeing the same
thing for my ...
| May 28, 9:23 am 2008 |
| Sam Ravnborg | Re: Kbuild changes since 2.6.21??
We use find to delete all .o files. So the content of your Kbuild file
should not matter here.
Can you describe the setup where you see the issue?
Sam
--
| May 28, 11:42 am 2008 |
| Jeremy Fitzhardinge | [PATCH 3/3] arch/sh: use __page_aligned_bss
The patch "make page-aligned data and bss less fragile" introduces
__page_aligned_data and __page_aligned_bss to make sure that page
aligned things remain so, even if there are non-page-sized
page-aligned things.
This paragraph converts the two C instances of page-aligned bss
variables to use them. It's a purely decorative patch.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Paul Mundt <lethal@linux-sh.org>
---
arch/sh/kernel/irq.c | 8 +++-----
1 file ...
| May 28, 9:05 am 2008 |
| Jeremy Fitzhardinge | [PATCH 2/3] arch/powerpc: use __page_aligned_bss
The patch "make page-aligned data and bss less fragile" introduces
__page_aligned_data and __page_aligned_bss to make sure that page
aligned things remain so, even if there are non-page-sized
page-aligned things.
This paragraph converts an instance of an explicit section attribute
to __page_aligned_data. It's purely decorative.
(It should be noted that powerpc already defines __page_aligned to
have the same meaning as __page_aligned_data in non-MODULE code. Also
this particular case looks ...
| May 28, 9:04 am 2008 |
| Jeremy Fitzhardinge | [PATCH 1/3] make page-aligned data and bss less fragile
Making a variable page-aligned by using
__attribute__((section(".data.page_aligned"))) is fragile because if
sizeof(variable) is not also a multiple of page size, it leaves
variables in the remainder of the section unaligned.
This patch introduces two new qualifiers, __page_aligned_data and
__page_aligned_bss to set the section *and* the alignment of
variables. This makes page-aligned variables more robust because the
linker will make sure they're aligned properly. Unfortunately it
requires ...
| May 28, 9:04 am 2008 |
| David Howells | [PATCH] FRV: Specify the minimum slab/kmalloc alignment ...
From: David Howells <dhowells@redhat.com>
Specify the minimum slab/kmalloc alignment to be 8 bytes. This fixes a crash
when SLOB is selected as the memory allocator. The FRV arch needs this so
that it can use the load- and store-double instructions without faulting. By
default SLOB sets the minimum to be 4 bytes.
Signed-off-by: David Howells <dhowells@redhat.com>
---
include/asm-frv/mem-layout.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git ...
| May 28, 8:48 am 2008 |
| Alan Jenkins | Re: libata - DMA problems ICH7 rev 02
This is the exact situation cdrecord's -immed option was designed
for. "wodim"/cdrkit should have inherited it. It sets a flag in the
commands to avoid blocking, though the documentation I read said it
was slightly experimental.
--
| May 28, 8:04 am 2008 |
| Alan Jenkins | Re: libata - DMA problems ICH7 rev 02
This is the exact situation cdrecord's -immed option was designed
for. "wodim"/cdrkit should have inherited it. It sets a flag in the
commands to avoid blocking, though the documentation I read said it
was slightly experimental.
--
| May 28, 8:03 am 2008 |
| Jack Steiner | [PATCH] - Update macros used by UV platform
Update the UV address macros to better describe the
fields of UV physical addresses. Improve comments
in the header files. Add additional MMR definitions.
Signed-off-by: Jack Steiner <steiner@sgi.com>
---
arch/x86/kernel/genx2apic_uv_x.c | 141 +++++++---
include/asm-x86/uv/uv_hub.h | 188 +++++++++-----
include/asm-x86/uv/uv_mmrs.h | 509 ++++++++++++++++++++++++++++++++++++++-
3 files changed, 731 insertions(+), 107 deletions(-)
Index: ...
| May 28, 7:51 am 2008 |
| David Howells | [PATCH] FRV: Specify the minimum slab/kmalloc alignment
From: David Howells <dhowells@redhat.com>
Specify the minimum slab/kmalloc alignment to be 8 bytes. This fixes a crash
when SLOB is selected as the memory allocator. The FRV arch needs this so
that it can use the load- and store-double instructions without faulting. By
default SLOB sets the minimum to be 4 bytes.
Signed-off-by: David Howells <dhowells@redhat.com>
---
include/asm-frv/mem-layout.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git ...
| May 28, 7:36 am 2008 |
| David Howells | Re: [PATCH] FRV: Specify the minimum slab/kmalloc alignment
This doesn't work if SLAB is selected and slab debugging is enabled as these
are passed to the preprocessor.
David
--
| May 28, 8:49 am 2008 |
| Andrew Morton | Re: [PATCH] FRV: Specify the minimum slab/kmalloc alignment
On Wed, 28 May 2008 16:49:01 +0100
So.. like this?
From: David Howells <dhowells@redhat.com>
Specify the minimum slab/kmalloc alignment to be 8 bytes. This fixes a
crash when SLOB is selected as the memory allocator. The FRV arch needs
this so that it can use the load- and store-double instructions without
faulting. By default SLOB sets the minimum to be 4 bytes.
We need to use literal constants here as slab evaluates these within cpp.
Signed-off-by: David Howells ...
| May 28, 12:15 pm 2008 |
| Tejun Heo | Re: [PATCH] libata: Handle bay devices in dock stations
Acked-by: Tejun Heo <htejun@gmail.com>
--
tejun
--
| May 28, 7:39 am 2008 |
| Holger Macht | [PATCH] libata: 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 attaches/detaches the device.
- In case of a dock ...
| May 28, 7:38 am 2008 |
| Ronald Wahl | Q: Is the "x86: clear DF before calling signal handler" ...
Hi,
I just have a short question to the recent issue with gcc 4.3.x which
was fixed here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e40cd10ccf...
Does User Mode Linux on x86 need a similar fix?
Thanks,
ron
--
Ronald Wahl - ronald.wahl@raritan.com
Raritan Deutschland GmbH, Kornmarkt 7, 08056 Zwickau
Phone +49 375271349-0 Fax -99, USt-IdNr. DE813094160, HRB 23605 Chemnitz
Geschäftsführer / Managing Director: Gerard W. J. ...
| May 28, 6:39 am 2008 |
| Jan Niklas Hasse | Re: libata - DMA problems ICH7 rev 02
As I have a notebook, I think I can't do that, can I?
--
| May 28, 6:36 am 2008 |
| Markku Savela | in_group_p test for another process?
If I have a PID and some GID at hand, how do I find whether the OHTER
process identified by PID has the GID in its supplementary set of
groups?
I can find the "in_group_p" test, but that does it only for current process.
Do I have to write my own function that uses the "tasklist_lock",
finds task by "find_task_by_pid", and then calls
"groups_search(task->group_info, gid)"?
Can I do this in a module, or do I have to patch the "kernel/sys.c"
myself for a privately modified version of the ...
| May 28, 6:02 am 2008 |
| John Miller | 6/20/08 invitation
I would like to personally invite you to attend this historic event for our industry. The contacts you will make will be priceless.
Where? The Rio Hotel, Las Vegas - Nevada
When? June 20th 2008
for addional information go to
http://friendlyseminar.com/
or call today: 858.736.7788
to be taken of our list please:
http://friendlyseminar.com/del/ or, send us a letter to:
PBMSII, 5451 Weuery Ave., La JoIIa, CA 92037
--------------------------------------------
.
--
| May 28, 2:59 am 2008 |
| Johannes Berg | Re: two different oopses with 2.6.26-rc4
=EF=BB=BF
Yeah. Please don't. Report one bug per email, to the appropriate forum.
wireless really doesn't want to see any debugging of weird other
problems.
Anyhow, the wireless problem here is known and a fix is on its way, so
everybody *please* drop wireless from CC if you want to reply.
johannes
| May 28, 3:05 am 2008 |
| Alejandro Riveira | two different oopses with 2.6.26-rc4
I sent this to the list with other mail address and it didn't reach it
afaics. apologies if someone sees this twice
i cced wireless becouse of the first oops
First boot into 2.6.26-rc4
Compiled and booting into 2.6.26-rc4
1) With splash quiet on grub line it doesn't boot (or i didin't wait long
enough)
2) without quiet and splash I get into VT X filas becouse i use the evil
nvidia driver that's expected. But ubuntu failsafe mode (xserver with vesa
in low res) doesn't ...
| May 28, 2:50 am 2008 |
| Balbir Singh | MPTSAS problems in 2.6.26-rc2-mm1
I have 2.6.26-rc2-mm1 with Rik's splitvm patches. While booting the kernel, I
ran into the following. I searched my email quickly to see that no one else has
reported this problem. Lockdep seems to be complaining about the same lock being
held at the same location (the message is a bit confusing to me).
=============================================
[ INFO: possible recursive locking detected ]
2.6.26-rc2-mm1 #2
---------------------------------------------
insmod/1072 is trying to acquire ...
| May 28, 2:41 am 2008 |
| James Bottomley | Re: MPTSAS problems in 2.6.26-rc2-mm1
This is another instance of a problem being caused by semaphore to mutex
conversion in struct class;
There's another thread on this here:
http://marc.info/?t=121074904600001
James
--
| May 28, 7:47 am 2008 |
| Balbir Singh | Re: MPTSAS problems in 2.6.26-rc2-mm1
Thanks for pointer, it does indeed look like a variant of the same problem
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
| May 28, 7:56 am 2008 |
| Peter Zijlstra | Re: MPTSAS problems in 2.6.26-rc2-mm1
looks like device_add() recursing - most likely with a different device
--
| May 28, 2:45 am 2008 |
| Justin Piszcz | Performance Characteristics of All Linux RAIDs (mdadm/bo ...
Hardware:
1. Utilized (6) 400 gigabyte sata hard drives.
2. Everything is on PCI-e (965 chipset & a 2port sata card)
Used the following 'optimizations' for all tests.
# Set read-ahead.
echo "Setting read-ahead to 64 MiB for /dev/md3"
blockdev --setra 65536 /dev/md3
# Set stripe-cache_size for RAID5.
echo "Setting stripe_cache_size to 16 MiB for /dev/md3"
echo 16384 > /sys/block/md3/md/stripe_cache_size
# Disable NCQ on all disks.
echo "Disabling NCQ on all disks..."
for i in ...
| May 28, 1:53 am 2008 |
| Justin Piszcz | Re: Performance Characteristics of All Linux RAIDs (mdad ...
The RAID1 is correct. As has been discussed on this list before, you will=
=20
only see raid speed > 1 disk if you run 2(?, or 3 minimal) threads=20
from the same device (raid1).
Justin.
| May 28, 10:33 am 2008 |
| Keld | Re: Performance Characteristics of All Linux RAIDs (mdad ...
I added this in the wiki performance section.
I think it would have been informative if also a test with one drive in
a non-raid setup was described.
Are there any particular findings you want to highlight?
Is there some way to estimate random read and writes from this test?
Are the XFS file systems completely new when running the tests?
Best regards
keld
--
| May 28, 12:02 pm 2008 |
| Bryan Mesich | Re: Performance Characteristics of All Linux RAIDs (mdad ...
The RAID 1 read speed metrics do not depict multithreaded
processes reading from the array simutaneouly. I would suspect
that the read performance metrics would look better if 2 bonnie
simulations were ran together (for RAID 1 that is).
Bryan
--
| May 28, 9:46 am 2008 |
| Jens Bäckman | Re: Performance Characteristics of All Linux RAIDs (mdad ...
Either the RAID 1 read speed must be wrong, or something is odd in the
Linux implementation. There's six drives that can be used for reading
at the same time, as they contain the very same data. 63MB/s
sequential looks like what you would get from a single drive.
--
| May 28, 9:34 am 2008 |
| Justin Piszcz | Re: Performance Characteristics of All Linux RAIDs (mdad ...
Since the performance of bonnie++ deals with single threads/a raid1 would p=
Not in particular, just I could never find this information provided anywhe=
re
that showed all of the raid variation/types in one location that was easy t=
o
Yes, after the creation of each array, mkfs.xfs -f /dev/md3 was run to ensu=
re
> keld
| May 28, 12:05 pm 2008 |
| Chris Snook | Re: Performance Characteristics of All Linux RAIDs (mdad ...
The test is a single thread reading one block at a time, so this is not
surprising. If you get this doing multi-megabyte readahead, or with
several threads, something is very wrong.
-- Chris
--
| May 28, 9:40 am 2008 |
| Peter Rabbitson | Re: Performance Characteristics of All Linux RAIDs (mdad ...
Results are meaningless without a crucial detail - what was the chunk size
used during array creation time? Otherwise interesting test :)
Cheers
Peter
--
| May 28, 3:54 am 2008 |
| Bill Davidsen | Re: Performance Characteristics of All Linux RAIDs (mdad ...
I really don't think that's any part of the issue, the same memory and
bridge went 4-5x faster in other read cases. The truth is that the
raid-1 performance is really bad, and it's the code causing it AFAIK. If
you track the actual io it seems to read one drive at a time, in order,
without overlap.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
| May 28, 4:00 pm 2008 |
| Justin Piszcz | Re: Performance Characteristics of All Linux RAIDs (mdad ...
Only/usually on multi-threaded jobs/tasks, yes?
Also, I turn off NCQ on all of my hosts that has it enabled by default because
there are many bugs that occur when NCQ is on, they are working on it in the
libata layer but IMO it is not safe at all for running SATA disks w/NCQ as
with it on I have seen drives drop out of the array (with it off, no problems).
--
| May 28, 10:32 am 2008 |
| Chris Snook | Re: Performance Characteristics of All Linux RAIDs (mdad ...
Given that one of the greatest benefits of NCQ/TCQ is with parity RAID,
I'd be fascinated to see how enabling NCQ changes your results. Of
course, you'd want to use a single SATA controller with a known good NCQ
implementation, and hard drives known to not do stupid things like
disable readahead when NCQ is enabled.
-- Chris
--
| May 28, 8:40 am 2008 |
| Justin Piszcz | Re: Performance Characteristics of All Linux RAIDs (mdad ...
Indeed, the chunk size used was 256 KiB for all tests.
Justin.
--
| May 28, 4:05 am 2008 |
| Chris Snook | Re: Performance Characteristics of All Linux RAIDs (mdad ...
Generally, yes, but there's caching and readahead at various layers in
software that can expose the benefit on certain single-threaded
Are you using SATA drives with RAID-optimized firmware? Most SATA
manufacturers have variants of their drives for a few dollars more that
have firmware that provides bounded latency for error recovery
operations, for precisely this reason.
-- Chris
--
| May 28, 12:22 pm 2008 |
| Justin Piszcz | Re: Performance Characteristics of All Linux RAIDs (mdad ...
I have done NCQ measurements in the past, for single threaded apps NCQ off
is the way to go, check this out from earlier (10 raptors raid5):
http://home.comcast.net/~jpiszcz/ncq_vs_noncq/
--
| May 28, 10:53 am 2008 |
| Alan Cox | Re: Performance Characteristics of All Linux RAIDs (mdad ...
On Wed, 28 May 2008 18:34:00 +0200
Which is fairly typical of a cheap desktop PC where the limitation is the
memory and PCI bridge as much as the drive.
Alan
--
| May 28, 11:57 am 2008 |
| Justin Piszcz | Re: Performance Characteristics of All Linux RAIDs (mdad ...
I see--however, as I understood it there were bugs utilizing NCQ in libata?
But FYI--
In this test, they were regular SATA drives, not special raid-ones (RE2,etc).
Thanks for the info!
Justin.
--
| May 28, 12:27 pm 2008 |
| Bill Davidsen | Re: Performance Characteristics of All Linux RAIDs (mdad ...
I have two tiny nits to pick with this information. One is the
readahead, which as someone else mentioned is in sectors. The other is
the unaligned display of the numbers, leading the eye to believe that
values with a similar number of digits can be compared. In truth there's
a decimal, but only sometimes. I imported the csv file, formatted all
the numbers to an equal number of places after the decimal, and it is
far easier to read.
Okay, and a half-nit, there were some patches to ...
| May 28, 4:09 pm 2008 |
| Néstor Amigo Cairo | Fwd: QUESTION: How can I make a driver for a special ser ...
(Now, for all people, sorry)
---------- Forwarded message ----------
From: Néstor Amigo Cairo <nestorac@gmail.com>
Date: 2008/5/27
Subject: Re: QUESTION: How can I make a driver for a special serial
keyboard which also supports output (maybe via serio_raw)?
To: Benoit Boissinot <bboissin@gmail.com>
Thanks!! You are awesome, guys, I wouldn't been able to find this if
it was "Googling". I have to take a look now, but it looks cool. If I
can just use this X11 hack now, then I have plenty ...
| May 28, 1:00 am 2008 |
| Stephen Rothwell | Re: linux-next: Tree for May 28
On Wed, 28 May 2008 17:51:40 +1000 Stephen Rothwell <sfr@canb.auug.org.au> =
Actually 83 trees.
--=20
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
| May 28, 1:00 am 2008 |
| Stephen Rothwell | linux-next: Tree for May 28
Hi all,
Changes since next-20080527:
New tree: ubifs
The pci tree had a conflict with the pci-current tree.
The hid tree was fixed.
The semaphore-removal tree still needed three patches reverted because simi=
lar
patches were merged into upstream and the scsi-rc-fixes trees.
I have applied the following temporary patch for known build problems:
"Fix various 8390 builds" - the net tree broke builds on various
architectures - hopefully this patch will go into the net tree ...
| May 28, 12:51 am 2008 |
| Vegard Nossum | [#2][PATCH] x86: break mutual header inclusion
From: Vegard Nossum <vegard.nossum@gmail.com>
Date: Tue, 27 May 2008 21:38:35 +0200
Subject: [PATCH] x86: break mutual header inclusion
This breaks up the mutual inclusion between headers ptrace.h and vm86.h
by moving some small part of vm86.h which is needed by ptrace.h into
processor-flags.h.
We also try to move #include lines to the top.
This has been compile tested on x86_32 and x86_64 defconfig, and run
through 'make headers_check'.
Cc: Adrian Bunk <bunk@kernel.org>
Signed-off-by: ...
| May 28, 12:46 am 2008 |
| Christopher Martin | personal invitation
I would like to personally invite you to attend this historic event for our industry. The contacts you will make will be priceless.
Where? The Rio Hotel, Las Vegas - Nevada
When? June 20th 2008
for addional information go to
http://industryseminar.com/
or call today: 858.736.7788
to be taken of our list please:
http://industryseminar.com/del/ or, send us a letter to:
PBMSII, 5451 Weuery Ave., La JoIIa, CA 92037
--------------------------------------------
.
--
| May 27, 11:30 pm 2008 |
| Randy Dunlap | [patch -mmotm] docbook: duplicate kernel-locking doc merge
From: Randy Dunlap <randy.dunlap@oracle.com>
Removed duplicated patch lines.
I was checking mmotm (2008-0527) kernel docs and got this error:
xmlto: input does not validate (status 3)
/local/linsrc/mmotm-2008-0527-0032/Documentation/DocBook/kernel-locking.xml:722: element chapter: validity error : ID trylock-functions already defined
<chapter id="trylock-functions">
^
/local/linsrc/mmotm-2008-0527-0032/Documentation/DocBook/kernel-locking.xml:722: element ...
| May 27, 10:13 pm 2008 |
| Andrew Morton | Re: [patch -mmotm] docbook: duplicate kernel-locking doc merge
ah, thanks, that's me trying to pick up patches which aren't in linux-next
yet. I normally don't bother doing that unless there's a lot of material
involved.
I'll zap the erroneously-included
rusty-misc-doc_add_a_chapter_about_trylock_functions_bug_9011.patch
--
| May 27, 10:14 pm 2008 |
| Steven Rostedt | 2.6.24.7-rt11
We are pleased to announce the 2.6.24.7-rt11 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-rt10
- preempt __delay fix (Steven Rostedt)
- load_balance breaks (Peter Zijlstra)
- ftrace minor fixes (Steven Rostedt, Clark Williams,
and Abhishek Sagar)
- disable ftrace daemon (Steven Rostedt)
- ...
| May 27, 7:45 pm 2008 |
| David Brownell | Re: Latest gpio gumph
All the relevant stuff is now upstream (2.6.26-rc4) except:
- the userspace sysfs interface (which is in MM, and ISTR
you were cc'd on that)
- an avr32 patch, appended (no response on the avr32 list)
Nothing else touches core code; if you're using AVR32, then
you won't care about at91 gpiolib and inlining support, or the
patch sent this AM on LKML (which I've not yet reviewed).
- Dave
====== CUT HERE
From: David Brownell <dbrownell@users.sourceforge.net>
Subject: AVR32: ...
| May 27, 9:44 pm 2008 |
| Ben Nizette | Latest gpio gumph
Hey David,
Have you got a git/quilt repo somewhere with all the latest gpiolib (and
gpio framework) stuff glued in? I've seen most of it hit -mm but
developing against -mm on (especially on obscure archs like AVR32 as I
do) is always fraught.
Of course I do build and test -mm on avr32 as regularly as I can (and
submit patches for the inevitable munging it's taken) but I don't really
want to develop against it.
Thx,
--Ben.
--
| May 27, 7:41 pm 2008 |
| Haavard Skinnemoen | Re: Latest gpio gumph
Sorry about the lack of response.
But then we need to keep track of whether pullups used to be enabled so
that we can re-enable it in gpio_direction_input(), don't we?
I can't see the harm of keeping the pullup enabled while the port is
configured as output. For consistency, I'd rather honor the pullup flag
Hmm. I guess that makes sense, though I would be lying if I said I care
all that much. I think gpiolib is going pretty far to accommodate buggy
drivers that don't call gpio_request() ...
| May 28, 1:14 am 2008 |
| David Brownell | Re: Latest gpio gumph
"Need"? I'd figure that changing direction like that would be
uncommon without something determining signal level (like an
external driver or pullup) ... and if nothing did so, then it'd
I guess I don't like the idea of facilitating the constant current
waste that implies if output is being driven low. Even if it's not
a huge current waste! (These pullups being a lot weaker than I'd
have expected, at typically 190 kOhm.) No big deal here I guess.
For an open drain output it's probably ...
| May 28, 2:01 am 2008 |
| Ben Nizette | Re: Latest gpio gumph
Righteo, thanks.
--
| May 27, 10:13 pm 2008 |
| Haavard Skinnemoen | Re: Latest gpio gumph
If you enable the internal pullup during port configuration, it should
stay that way, I think. But I think at32_select_gpio() should be fixed
so that when the user specifies AT32_GPIOF_OUTPUT | AT32_GPIOF_PULLUP,
I don't think we're talking about a lot of pins that need to switch
direction on the fly, and the pullup is very weak as you say. And a
The board designer should know this and set the AT32_GPIOF_PULLUP flag
Yes, but it will only catch that particular case, not ...
| May 28, 2:21 am 2008 |
| Arjan van de Ven | Re: bad pmd ffff810000207238(9090909090909090).
On Tue, 27 May 2008 23:01:01 -0300
909090 is asm for "nop nop nop", a pattern often used in rootkits to
deal with slightly unknown memory locations
I would REALLY REALLY strongly suggest that you check for rootkits and
the like on your system...
--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
| May 27, 9:09 pm 2008 |
| Fede | bad pmd ffff810000207238(9090909090909090).
Hi,
Today I tried to start a firewalling script and failed due to an
unrelated issue, but when I checked the log I saw this:
May 27 20:38:15 kaoz ip_tables: (C) 2000-2006 Netfilter Core Team
May 27 20:38:28 kaoz Netfilter messages via NETLINK v0.30.
May 27 20:38:28 kaoz nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
May 27 20:38:28 kaoz ctnetlink v0.93: registering with nfnetlink.
May 27 20:38:28 kaoz ClusterIP Version 0.8 loaded successfully
May 27 20:38:28 kaoz mm/memory.c:127: bad ...
| May 27, 7:01 pm 2008 |
| Hugh Dickins | Re: [PATCH] Re: bad pmd ffff810000207238(9090909090909090).
I'm hardly the right person to answer on this, but I believe that
because the 0x90 NOP is particularly appropriate in .text (and
prevents stalls even where it cannot be reached?), it gets used
as the default alignment filler all over. (It's even specified
for the arch-independent default _ALIGN in linux/linkage.h.)
Hugh
--
| May 28, 3:20 pm 2008 |
| Ingo Molnar | Re: [PATCH] Re: bad pmd ffff810000207238(9090909090909090).
applied, nice catch!
Ingo
--
| May 28, 11:40 am 2008 |
| Hugh Dickins | [PATCH] Re: bad pmd ffff810000207238(9090909090909090).
Thanks a lot for re-reporting this: it was fun to work it out.
It's not a rootkit, it's harmless, but we ought to fix the noise.
Simple patch below, but let me explain more verbosely first.
What was really interesting in your report was that the address
is so close to that in OGAWA-San's report. I had a look at that
page on my x86_64 boxes, and they have lots of 0x90s there too.
It's just some page alignment filler that x86_64 kernel startup
has missed cleaning up - patch below fixes that. ...
| May 28, 11:36 am 2008 |
| Willy Tarreau | Re: [PATCH] Re: bad pmd ffff810000207238(9090909090909090).
Is there a particular reason we use 0x90 as an alignment filler ?
If we can put anything else, at least next time it will not get
confused with NOPs. We could use 0xAF (Alignment Filler) for
instance.
Well done BTW ;-)
Reagrds,
Willy
--
| May 28, 12:56 pm 2008 |
| Willy Tarreau | Re: [PATCH] Re: bad pmd ffff810000207238(9090909090909090).
OK, I did not understand from Hugh's explanation that it was
all about alignment within functions. Of course, 0x90 is fine
there (though there are multi-byte NOPs available).
Cheers,
Willy
--
| May 28, 1:43 pm 2008 |
| Jan Engelhardt | Re: [PATCH] Re: bad pmd ffff810000207238(9090909090909090).
Alignment within functions. You could use a JMP to jump over
the alignment, but that would be costly. So in order to
"run through the wall", you need an opcode that does not
do anything, something like 0x90.
0xAF would map to scasd on x86, and I'd hardly call that a
no-op.
--
| May 28, 1:14 pm 2008 |
| Jan Engelhardt | Re: [PATCH] Re: bad pmd ffff810000207238(9090909090909090).
"All about alignment within functions" -- I am not sure about that,
you just happened to ask about 0x90 :)
And if you have a 1-byte NOP (which fits perfectly everywhere),
which is also a real NOP (and not just a filler byte that could
possibly be an opcode doing something very different), you've
got an ideal candidate for padding, no?
There is probably nothing wrong with padding .data sections
with 0xAF or even 0xDB and ud2 to catch execute-readonly-data
cases. To that end, I think something ...
| May 28, 2:24 pm 2008 |
| Hiroshi Shimamoto | [PATCH] x86: coding style fixes for nmi.c
From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
before
total: 1 errors, 6 warnings, 534 lines checked
after
total: 0 errors, 1 warnings, 532 lines checked
Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
---
cleanup for unified nmi.c
arch/x86/kernel/nmi.c | 16 +++++++---------
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index 9b02b0d..9ecf56f 100644
--- a/arch/x86/kernel/nmi.c
+++ ...
| May 27, 6:49 pm 2008 |
| Gregory Haskins | [PATCH 0/3] sched: misc sched-devel fixes for PREEMPT_RT
Hi Steven,
The following series are patches that have been accepted by Ingo in
sched-devel post 2.6.25. They probably should be considered for the
next RT release as well. The series applies to 25.4-rt3.
Regards,
-Greg
--
| May 27, 5:59 pm 2008 |
| Gregory Haskins | [PATCH 1/3] sched: fix RT task-wakeup logic
Dmitry Adamushko pointed out a logic error in task_wake_up_rt() where we
will always evaluate to "true". You can find the thread here:
http://lkml.org/lkml/2008/4/22/296
In reality, we only want to try to push tasks away when a wake up request is
not going to preempt the current task. So lets fix it.
Note: We introduce test_tsk_need_resched() instead of open-coding the flag
check so that the merge-conflict with -rt should help remind us that we
may need to support NEEDS_RESCHED_DELAYED in ...
| May 27, 5:59 pm 2008 |
| Gregory Haskins | [PATCH 2/3] sched: fix SCHED_FAIR wake-idle logic error
We currently use an optimization to skip the overhead of wake-idle
processing if more than one task is assigned to a run-queue. The
assumption is that the system must already be load-balanced or we
wouldnt be overloaded to begin with.
The problem is that we are looking at rq->nr_running, which may include
RT tasks in addition to CFS tasks. Since the presence of RT tasks
really has no bearing on the balance status of CFS tasks, this throws
the calculation off.
This patch changes the logic ...
| May 27, 5:59 pm 2008 |
| Gregory Haskins | [PATCH 3/3] sched: prioritize non-migratable tasks over ...
Dmitry Adamushko pointed out a known flaw in the rt-balancing algorithm
that could allow suboptimal balancing if a non-migratable task gets
queued behind a running migratable one. It is discussed in this thread:
http://lkml.org/lkml/2008/4/22/296
This issue has been further exacerbated by a recent checkin to
thing. Using Dmitry's nomenclature, if T0 is on cpu1 first, and T1
wakes up at equal or lower priority (affined only to cpu1) later, it
*should* wait for T0 to finish. However, in ...
| May 27, 5:59 pm 2008 |
| Steven Rostedt | [PATCH] ftrace: user update and disable dynamic ftrace daemon
In dynamic ftrace, the mcount function starts off pointing to a stub
function that just returns.
On start up, the call to the stub is modified to point to a "record_ip"
function. The job of the record_ip function is to add the function to
a pre-allocated hash list. If the function is already there, it simply is
ignored, otherwise it is added to the list.
Later, a ftraced daemon wakes up and calls kstop_machine if any functions
have been recorded, and changes the calls to the recorded ...
| May 27, 5:48 pm 2008 |
| Yuhong Bao | Update to "On the matter of EFI..."
I forgot to mention that I am not subscribed to the mailing list.
Yuhong Bao
--
| May 27, 5:32 pm 2008 |
| Yuhong Bao | On the matter of EFI...
On the matter of EFI, Linus do have a point. EFI is complex enough that it is more like DOS than a BIOS. And it is funny to compare hardware complexity to human evolution.
Yuhong Bao
_________________________________________________________________
If you like crossword puzzles, then you'll love Flexicon, a game which combines four overlapping crossword puzzles into one!
http://g.msn.ca/ca55/208--
| May 27, 5:22 pm 2008 |
| Benjamin Herrenschmidt | [PATCH] [POWERPC] Add "memory" clobber to MMIO accessors
gcc might re-order MMIO accessors vs. surrounding consistent
memory accesses, which is a "bad thing".
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
include/asm-powerpc/io.h | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- linux-work.orig/include/asm-powerpc/io.h 2008-05-28 09:39:11.000000000 +1000
+++ linux-work/include/asm-powerpc/io.h 2008-05-28 09:40:28.000000000 +1000
@@ -100,7 +100,7 @@ static inline type name(const volatile t
...
| May 27, 5:18 pm 2008 |
| David Brownell | Re: HAVE_CLK (for <linux/clk.h> support)
If this approach goes forward, I'd expect those platforms
Best done by #ifdef HAVE_CLK in <linux/clk.h> support, and
putting the stubs there. However, since those platforms
don't actually have clocks, I'd make them all report errors
of whichever kind.
That's kind of a second-order question to "should we create
a HAVE_CLK in Kconfig". Since Certain People have objected
to patches touching <linux/clk.h> I avoided doing that the
first time around ... it'd be a better solution, yes.
- ...
| May 27, 6:41 pm 2008 |
| Felipe Balbi | Re: HAVE_CLK (for <linux/clk.h> support)
Hi,
I actually like it. I didn't see this error cuz I was only building
musb for arm architecture.
But why only davinci and omap?
What about: mach-aaec2000, mach-at91, mach-ep93xx, mach-integrator,
mach-lh7a40x, mach-ns9xxx, mach-pnx4008, mach-pxa, mach-realview,
mach-sa1100, mach-versatile, mach-s3c24x.
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
--
| May 27, 5:01 pm 2008 |
| Felipe Balbi | Re: HAVE_CLK (for <linux/clk.h> support)
On Wed, May 28, 2008 at 2:14 AM, David Brownell <david-b@pacbell.net> wrote:
Sorry, another comment.
Instead of making the driver dependant on HAVE_CLK (which would be
true for virtually any driver comming from linux-omap), you could make
clk_enable a nop in case arch doesn't HAVE_CLK. How does that sound?
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
--
| May 27, 5:05 pm 2008 |
| Adam Litke | Re: [PATCH 2/3] hugetlb-move-reservation-region-support- ...
Acked-by: Adam Litke <agl@us.ibm.com>
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
--
| May 28, 1:38 pm 2008 |
| Scott Lovenberg | Re: Love and Hate on LKML
I'm just a software development major in college who follows kernel
development (it's kind of like following a sport that's played 24/7, and I can
participate in!) fairly closely. But, for what it's worth, Chris, I really
appreciated your comment. It's really refreshing to actually see a positive
outlook with a call to action these days (especially where thousands of
introverts are concerned). Thank you for a humble, well thought out reply to a
slightly hostile post.
I've always ...
| May 28, 5:02 am 2008 |
| Willy Tarreau | Re: Love and Hate on LKML
Chris,
your comments make a lot of sense. Unfortunately, I think that
you wasted your time trying to educate this one. Judging by
his/her pathetic blog made up from carefully selected excerpts
from the list, and the fact that he/she has no name to post
with, I think he/she's just a kid waiting for his/her parents
to discover he/she used dad's computer without authorization.
Otherwise, I 100% agree with what you said.
Cheers,
Willy
--
| May 27, 10:12 pm 2008 |
| Steven Whitehouse | Re: 2.6.26rc4 GFS2 oops.
Hi,
I've tried it on -nmw and it seems to run ok, and I'm currently running
it on the current upstream kernel and its done 1/2 hour so far with no
sign of a problem.
Can you give a few more details, such as the block size of the fs, the
exact command line for fsx (I was just running with defaults) and
perhaps check all the info into a Red Hat bugzilla? I know this is
upstream, but I tend to use "Fedora/rawhide" to keep tabs on such things
just so as all the bugs are in the same ...
| May 28, 4:36 am 2008 |
| Dave Jones | Re: 2.6.26rc4 GFS2 oops.
On Wed, May 28, 2008 at 12:36:04PM +0100, Steven Whitehouse wrote:
> Hi,
>
> On Tue, 2008-05-27 at 15:44 -0400, Dave Jones wrote:
> > Single node GFS2 filesystem. Run fsx. Boom.
> >
> I've tried it on -nmw and it seems to run ok, and I'm currently running
> it on the current upstream kernel and its done 1/2 hour so far with no
> sign of a problem.
>
> Can you give a few more details, such as the block size of the fs
whatever the defaults that mkfs used. (unless anaconda did ...
| May 28, 6:49 am 2008 |
| Adam Litke | Re: [PATCH 3/3] Guarantee that COW faults for a process ...
Acked-by: Adam Litke <agl@us.ibm.com>
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
--
| May 28, 11:16 am 2008 |
| Adam Litke | Re: [PATCH 1/3] Move hugetlb_acct_memory()
Acked-by: Adam Litke <agl@us.ibm.com>
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
--
| May 28, 6:37 am 2008 |
| Mel Gorman | Re: [PATCH 3/3] Guarantee that COW faults for a process ...
[PATCH 4/3] Fix prio tree lookup
I spoke too soon. This is a fix to patch 3/3.
If a child unmaps the start of the VMA, the start address is different and
that is perfectly legimite making the BUG_ON check bogus and should be removed.
While page cache lookups are in HPAGE_SIZE, the vma->vm_pgoff is in PAGE_SIZE
units, not HPAGE_SIZE. The offset calculation needs to be in PAGE_SIZE units
to find other VMAs that are mapping the same range of pages. This patch
fixes the offset calculation and ...
| May 28, 9:00 am 2008 |
| Adam Litke | Re: [PATCH 3/3] Guarantee that COW faults for a process ...
Acked-by: Adam Litke <agl@us.ibm.com>
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
--
| May 28, 11:15 am 2008 |
| Adam Litke | Re: [PATCH 2/3] Reserve huge pages for reliable MAP_PRIV ...
Acked-by: Adam Litke <agl@us.ibm.com>
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
--
| May 28, 6:52 am 2008 |
| Meelis Roos | Re: PPC PReP link failure - copy_page, empty_zero_page
Yes, this fixes it, thanks! Hopefully it is merged before 2.6.26.
--
Meelis Roos (mroos@linux.ee)
--
| May 28, 10:57 am 2008 |
| Tony Breeds | Re: PPC PReP link failure - copy_page, empty_zero_page
Try that patch at: http://patchwork.ozlabs.org/linuxppc/patch?id=18710
Fixes it for me.
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
--
| May 27, 5:53 pm 2008 |
| Jason Wessel | Re: [PATCH] softlockup: fix NMI hangs due to lock race - ...
If the try locks are used it will certainly solve the NMI problem, but
it seems that the probability that lock could not be obtained would
increase for the "normal" operation case. In the "normal" operation
case the lock would generally be available in a few more cpu ticks and
the update would proceed correctly. It is not clear to me if there is
some ramification of returning the ->clock without the update in this
case, which is why I opted for deferring the update in the NMI ...
| May 28, 6:31 am 2008 |
| David Howells | Re: [PATCH, RFD] Unbreaking nommu mmap, v2
I'd like to counter with this patch. This goes for proper VMAs and doesn't
make use of compound pages. This makes things more similar to MMU-mode.
Note that this patch unconditionally trims allocations, whereas on yours this
is optional. That can be easily remedied, if, in fact, the ability to request
untrimmed allocations is worth doing.
David
---
[PATCH] NOMMU: Make VMAs per MM as for MMU-mode linux
From: David Howells <dhowells@redhat.com>
Make VMAs per mm_struct as for MMU-mode ...
| May 28, 9:47 am 2008 |
| Bernd Schmidt | Re: [PATCH, RFD] Unbreaking nommu mmap, v2
Have you investigated the effect on fragmentation? I backed off on
trimming allocations, as it gave unacceptable results.
Is this patch different from the ones I tested last year? They were not
stable in my tests back then (fragmentation may have been an issue).
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer ...
| May 28, 9:51 am 2008 |
| Michael Renzmann | Re: madwifi && v2.6.26-rc4
I'm not "the maintainer" of MadWifi, just one of the guys working on the
project.
I agree with Arjan that this report is off-topic on lkml, since MadWifi is
not part of the Linux kernel. Please report this either via our bugtracker
or via one of the MadWifi-related mailing lists (see
http://madwifi.org/wiki/Resources).
Bye, Mike
--
| May 27, 9:42 pm 2008 |
| john stultz | Re: Shifts for clocksources and clockevents
On Tue, May 27, 2008 at 7:54 AM, Linus Walleij
The goal is to have the highest shift-value possible (providing
improved slewing accuracy for ntp), while not overflowing on the
multiply if the cycles are not accumulated over an extended period of
time (usually 2-5 seconds).
See the comments in kernel/time/jiffies.c for an example.
thanks
-john
--
| May 27, 6:25 pm 2008 |
| Jens Axboe | Re: [PATCH] Changed blk trace msgs to directly use relay ...
The complexity is the same imho, both versions are fairly trivial.
I wasn't out to optimize this in a memory copy sense. To me the most
precious resource is the data stream to the app, and 128 bytes
is probably 6 times larger than the normal message would be. With
the actual trace structure, we are down to about 3 times the byte
size.
So it was just an idea, I don't care much either way. With 128 bytes,
we could just put the buffer on the stack (and still do the copy to
the relay buffer). ...
| May 28, 6:00 am 2008 |
| Jens Axboe | Re: [PATCH] Changed blk trace msgs to directly use relay ...
Or, alternatively, something like the below. Then we don't
unconditionally reserve and copy 128 bytes for each message, at the
cost 128 bytes per-cpu per trace.
diff --git a/block/blktrace.c b/block/blktrace.c
index 20e11f3..7ae87cc 100644
--- a/block/blktrace.c
+++ b/block/blktrace.c
@@ -79,13 +79,16 @@ void __trace_note_message(struct blk_trace *bt, const char *fmt, ...)
{
int n;
va_list args;
- static char bt_msg_buf[BLK_TN_MAX_MSG];
+ char *buf;
+ preempt_disable();
+ buf = ...
| May 28, 5:13 am 2008 |
| Alan D. Brunelle | Re: [PATCH] Changed blk trace msgs to directly use relay ...
Given your prioritizing of relay-copying over kernel-copying, I think
you're solution is better (and more flexible going forward).
Alan
--
| May 28, 6:22 am 2008 |
| Jens Axboe | Re: [PATCH] Changed blk trace msgs to directly use relay ...
OK good, it's committed and going upstream soon(ish).
--
Jens Axboe
--
| May 28, 6:28 am 2008 |
| Alan D. Brunelle | Re: [PATCH] Changed blk trace msgs to directly use relay ...
I looked into something like this, but thought the added complexity
wasn't worth it. Besides the extra per-cpu stuff, you also have an extra
memcopy involved - in my patch you print directly into the relay buffer.
I figure that /if/ copying (128-msg_size) extra bytes is too much, one
could always shrink the 128 down further. [I would think 64 bytes is
probably ok.]
I'd bet that the reduced complexity, and skipping the extra memcopy more
than offsets having to copy a few extra ...
| May 28, 5:26 am 2008 |
| Haavard Skinnemoen | Re: [PATCH] atmel_serial: Filter out FP during baud rate ...
Yes...I guess that's one more reason to filter them out.
FWIW, the u-boot patch explicitly excludes those two processors,
falling back to the existing CD calculation code.
Haavard
--
| May 28, 12:04 am 2008 |
| Uwe | Re: configure gpio for interrupt function
Hello David,
I think s3c2443 is similar. For them just using the input mode for a
gpio isn't enough to get an irq, too. (At least if I believe my
IMHO pinmux and GPIO are not orthogonal. The GPIO API just choosed not
OK. (But then a general driver cannot make use of this function. IMHO
There isn't "the pin". E.g. IRQ_NS9XXX_EXT0 can trigger on gpios 1, 9,
16 and 105 on ns9215. These are four different pins. What should I do
when two of them are in input mode? (I can remember for which ...
| May 28, 12:17 am 2008 |
| Andi Kleen | Re: [PATCH] call_usermodehelper() increase reliability
Patch looks good to me. Thanks for fixing this properly.
-Andi
--
| May 27, 7:40 pm 2008 |
| Jeremy Fitzhardinge | Re: [PATCH] call_usermodehelper() increase reliability
Yes, looks good.
--
| May 28, 1:05 am 2008 |
| Li Zefan | Re: [PATCH] call_usermodehelper() increase reliability
I have no problem with this patch.
Reviewed-by: Li Zefan <lizf@cn.fujitsu.com>
--
| May 27, 9:51 pm 2008 |
| Andrew Morton | Re: [patch][resend] provide rtc_cmos platform device, take 2
On Tue, 27 May 2008 15:23:06 +0400
So is everyone happy with this now?
It got lost from the changelog but IIRC this fixes a small sort-of regression
which was added in 2.6.25(?) because Stas switched drivers. I assume
that the incompatibility was unintentional.
So it might be 2.6.26 material, and possibly even 2.6.25.x?
--
| May 28, 4:36 pm 2008 |
| Matthew Wilcox | Re: [PATCH][-mm] reclassify sg_sysfs_class for lockdep
Look, you've been told how to do this properly. Send me the patch that
does the mutex conversion and I'll do a patch on top of that. I have no
inclination to go wading in the cesspool of patches that is mm trying to
find yours.
--
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 28, 7:49 am 2008 |
| Andrew Morton | Re: [PATCH][-mm] reclassify sg_sysfs_class for lockdep
On Wed, 28 May 2008 08:49:43 -0600
Feel free to identify the cessful patches so they can be fixed or dropped.
From: Dave Young <hidave.darkstar@gmail.com>
The class_device is already removed, so do the class->sem to mutex conversion.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Cc: Greg KH <greg@kroah.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/base/class.c | 22 +++++++++++-----------
...
| May 28, 12:18 pm 2008 |
| James Bottomley | Re: [PATCH][-mm] reclassify sg_sysfs_class for lockdep
This isn't really a generic solution, is it? It only works because we
currently only have two users of the interface functions, so if we
reclassify one they look separate to lockdep. It will fall over again
if we ever get another one.
Surely the correct fix is to initialise lockdep for the mutex the same
way we did for the semaphore in class_register() (which does exactly the
same locking without triggering lockdep)? That way we'll also fix the
problem for other conversions of ...
| May 28, 7:40 am 2008 |
| Li Zefan | May 27, 5:58 pm 2008 | |
| Dave Kleikamp | Re: [Jfs-discussion] [PATCH] JFS: diAlloc() should retur ...
I'm not sure how this one escaped detection this long. I've added this
patch to the jfs git tree.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
--
| May 28, 7:02 am 2008 |
| Stephen Rothwell | Re: can UBIFS be taken to linux-next?
Hi Artem,
On Tue, 27 May 2008 09:18:07 +0300 Artem Bityutskiy <Artem.Bityutskiy@nokia=
OK, my requirements are that you intend for it to be integrated in the
next merge window, that it be reviewed and that it be unit tested (i.e.
tested as well as you can in isolation). You seem to have done all that,
so I will add it.
I will put it at the end of the merge today.
Andrew, does that make sense to you?
--=20
Cheers,
Stephen Rothwell ...
| May 27, 6:41 pm 2008 |
| Artem Bityutskiy | Re: can UBIFS be taken to linux-next?
Indeed Christoph made a good go through and we appreciate this. We have
addressed most of his requests. I'll just cite the latest UBIFS submit
mail (http://marc.info/?l=linux-kernel&m=121180458401234&w=2):
* Requests from Christoph Hellwig's review (may be found here:
http://marc.info/?l=linux-kernel&m=121093446502796&w=2). Few things
related to the background thread were not done though. Here are
explanations why: http://marc.info/?l=linux-kernel&m=121155640026661&w=2
and ...
| May 27, 10:03 pm 2008 |
| Artem Bityutskiy | Re: can UBIFS be taken to linux-next?
We have not got too much review, just because there are not so many people
involved into the area. But we have got some review. The best one was
Yes, we do this on regular basis. We have our own tests [1] ans we use
older JFFS2 tests [2]. We also use it in Nokia and we have several users
Thanks.
[1] git://git.infradead.org/~dedekind/ubifs-userspace.git
or http://git.infradead.org/users/dedekind/ubifs-userspace.git
[2] git://git.infradead.org/mtd-utils.git
or ...
| May 27, 10:14 pm 2008 |
| Andrew Morton | Re: can UBIFS be taken to linux-next?
I'm not aware of any issues which would block a 2.6.27 merge.
I haven't reviewed the filesystem myself. Christoph Hellwig seems to
have had a good go through it and had numerous review comments, but it
is unclear what stage things are at with addressing them?
--
| May 27, 7:29 pm 2008 |
| Andi Kleen | Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM ...
When the 16MB zone overflows (which can be common in some workloads)
calling the OOM killer is pretty useless because it has barely any
real user data [only exception would be the "only 16MB" case Alan
mentioned]. Killing random processes in this case is bad.
I think for 16MB __GFP_NORETRY is ok because there should be
nothing freeable in there so looping is useless. Only exception would be the
"only 16MB total" case again but I'm not sure 2.6 supports that at all
on x86.
On the other ...
| May 27, 7:47 pm 2008 |
| Andrew Morton | Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM ...
I guess that's more specifally solving that-which-we-wish-to-solve.
Formally we should be testing __GFP_DMA here, not GFP_DMA - just the
zone selector field. They're presently equal, but someone could
legitimately come along and do
#define GFP_DMA (__GFP_DMA|__GFP_HIGH)
or similar.
--
| May 28, 1:40 am 2008 |
| Andi Kleen | Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM ...
Then the allocator could still be stuck in ZONE_DMA32 on 64bit.
Also d_a_c() does one "speculative" allocation, as in an allocation
where it knows the zone is too large for the mask but it tries anyways
because it often works. In that case too much trying is also not good.
-Andi
--
| May 28, 5:54 am 2008 |
| Miquel van Smoorenburg | Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM ...
Okay, so how about this then ?
--- linux-2.6.26-rc4.orig/arch/x86/kernel/pci-dma.c 2008-05-26 20:08:11.000000000 +0200
+++ linux-2.6.26-rc4/arch/x86/kernel/pci-dma.c 2008-05-28 10:27:41.000000000 +0200
@@ -397,9 +397,6 @@
if (dev->dma_mask == NULL)
return NULL;
- /* Don't invoke OOM killer */
- gfp |= __GFP_NORETRY;
-
#ifdef CONFIG_X86_64
/* Why <=? Even when the mask is smaller than 4GB it is often
larger than 16MB and in this case we have a chance of
@@ -410,7 +407,9 ...
| May 28, 1:31 am 2008 |
| Jeremy Fitzhardinge | Re: Question about interrupt routing and irq allocation
The case I'm discussing now is in hvm domains - ie, fully virtualized PC
platform. I'm adding a driver to poke a hole through all the emulated
hardware to get directly to the underlying Xen layer so that we can run
paravirtual drivers to get better performance. Only the irqs associated
In this case the sharing is between fully paravirtualized paravirt_ops
Xen and pv-on-hvm drivers. In general I want those drivers to look as
Something along the lines of passing -1 as the irq, and it ...
| May 28, 3:40 am 2008 |
| Eric W. Biederman | Re: Question about interrupt routing and irq allocation
I see. The fully virtualized machine case. So we do have apics
Right. We should be able to assume that the native irqs for
those devices are not shared, and we should be able to extend
that property (among others) to the virtualzed irqs for the
devices.
Under other hypervisors sparc, ppc we can run unmodified pci
drivers just the OS platform code changes. How close to that
can we come in the Xen case?
I think running unmodified drivers with the OS platform code doing
the adaption ...
| May 28, 9:04 am 2008 |
| Eric W. Biederman | Re: Question about interrupt routing and irq allocation
- I think using create_irq is a good step.
- I think all vectors are wasted in the case of Xen.
- I think we want a individual irq for each xen irq source.
Sparc already does a demux in similar circumstances with
a queue of received MSI messages an a single cpu irq
that these get demuxed from.
If we don't have individual irqs per drivers it will be hard
to share a source base with native drivers.
- I think it would be very nice if we could get irqs allocated
in request_irq instead ...
| May 28, 2:35 am 2008 |
| Cyrill Gorcunov | Re: [REGRESSION][BISECTED][X86] next-20080526 hangs on boot
Hi,
thanks a lot for checking this!
I'll take a look today evening.
--
| May 27, 8:21 pm 2008 |
| Bill Davidsen | Re: Linux 2.6.26-rc4
Unless I misread the thread, akpm had a raft of issues with the first
one, all of which were spelling except one initialization which he
thought was not needed. All of those could be fixed in less effort that
it takes to mention them, perhaps, but even so I think the patch could
be ready in a short time.
The problem looks worth fixing to me, but probably not a must have at
the rc4 level. Maybe in 2.6.27 we could get rid of the potential race?
--
Bill Davidsen <davidsen@tmr.com>
...
| May 28, 4:59 pm 2008 |
| Paul E. McKenney | Re: 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0
And it passes light testing on a 4-CPU x86 box.
--
| May 28, 12:26 am 2008 |
| Paul E. McKenney | Re: 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0
And here is a just-now hacked up patch. Untested, probably fails to compile.
Just kicked off a light test run, will let you know how it goes.
Thanx, Paul
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
include/linux/rcupreempt.h | 15 ++++++++-
kernel/Kconfig.preempt | 15 +++++++++
kernel/rcupreempt.c | 71 ++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 99 insertions(+), 2 deletions(-)
diff -urpNa -X dontdiff ...
| May 27, 10:01 pm 2008 |
| Pavel Machek | Re: amd64-agp: resume but too late?
I'm not aware of such patch. I don't think I sent it.
I did add suspend/resume support to pci-gart_64.c , which is
confusingly similar code. That patch needs a bit more testing, and
some de-uglyfication.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
| May 28, 3:42 am 2008 |
| Maciej W. Rozycki | Re: [PATCH] [SERIAL] fix driver_name conflicts
Not that it makes much sense to have both included in the same kernel,
but for the purpose of purity:
Acked-by: Maciej W. Rozycki <macro@linux-mips.org>
Maciej
--
| May 28, 7:15 am 2008 |
| Pete Wyckoff | Re: bsg locking patches update
Looks good. I can't see any problems with this approach. And it
tests okay in my problem scenario, on top of 2.6.26-rc4. You can
add my tested-by and submit as a bug fix to .26 safely, I think.
Thanks again!
--
| May 28, 7:18 am 2008 |
| FUJITA Tomonori | Re: bsg locking patches update
On Mon, 26 May 2008 12:53:18 -0400
We could but we use bsg_mutex to protect bsg_device_list and idr. So I
think that we don't need hold bsg_mutex during
bsg_complete_all_commands. How about this?
diff --git a/block/bsg.c b/block/bsg.c
index f0b7cd3..d81104e 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -721,8 +721,6 @@ static int bsg_put_device(struct bsg_device *bd)
int ret = 0, do_free;
struct request_queue *q = bd->queue;
- mutex_lock(&bsg_mutex);
-
do_free = ...
| May 28, 5:00 am 2008 |
| FUJITA Tomonori | Re: bsg locking patches update
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: Re: bsg locking patches update
On second thoughts, I realized that the previous patch leads to a race
between bsg_put_device and __bsg_get_device (__bsg_get_device possibly
finds a device that is being removed). Here's new one.
diff --git a/block/bsg.c b/block/bsg.c
index f0b7cd3..7cdec32 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -724,8 +724,13 @@ static int bsg_put_device(struct bsg_device *bd)
...
| May 28, 6:51 am 2008 |
| Chris Wright | Re: Redzone overwritten with CONFIG_SECURITY
I had wondered that, since data structures will grow w/ CONFIG_SECURITY
set (like inode, for example). I haven't encountered a Kbuild dependency
bug in quite a while though.
thanks,
-chris
--
| May 28, 2:51 pm 2008 |
| Eric Sesterhenn | Re: Redzone overwritten with CONFIG_SECURITY
I did a fresh git-clone and tried again without being able
to reproduce this.
I diffed all .h and .c files and except for
the autogenerated ones they are exactly the same...
Is it possible that this was caused because a file didnt
get rebuild correctly? I can still reproduce it with the
old checkout. Sorry if this causes unessecary noise :(
Greetings, Eric
--
| May 28, 3:03 am 2008 |
| Jan Kara | Re: UBIFS seekdir()/telldir() issue
The sequence you write above is actually incorrect I think. Noone
guarantees that the cookie returned by telldir() is valid after
closedir(). What is a bigger (and quite common) problem is, if somebody
uses readdir/telldir/seekdir while someone else creates/deletes files in
the directory. The standard implies in this case that subsequent
readdir should return all the files which were not touched (or all files
after position set by seekdir if used...).
Honza
--
Jan Kara ...
| May 28, 8:45 am 2008 |
| Renato S. Yamane | Re: [Bug 10797] Something is consuming power after shutdown
I test two times as commented in [1] and I can see that this problem
don't hapen if, before shutdown, I close LCD Display (activing LID to
hibernate).
[1] <http://bugzilla.kernel.org/show_bug.cgi?id=10797#c1>
So, to shutdown laptop with no battery change, is necessary:
1) Active LID (closing LCD Display). With this, my laptop will
hibernate, so is necessary wake-up again.
2) Shutdown
Best regards,
Renato S. Yamane
--
| May 28, 4:52 am 2008 |
| Artem Bityutskiy | Re: [PATCH take 3 29/29] UBIFS: include FS to compilation
Ok, thanks for suggestion. Will be done.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
| May 27, 9:57 pm 2008 |
| Peter Zijlstra | Re: [bug] stuck localhost TCP connections, v2.6.26-rc3+
Just a quick note to say, me too!!
same scenario: distcc on localhost.
--
| May 28, 2:27 am 2008 |
| Andrew Morton | Re: [PATCH 1/1] Char: vt, make sysfs operations atomic
On Tue, 27 May 2008 16:48:58 -0400
The patch does fix a race, by extending console_sem coverage to provide
exclusion between the sysfs creation and teardown operations.
I assume - no race was identified in the changelog. Can we actually
simultaneously run con_open() and con_close() against the same device?
I guess it might be possible if userspace tried hard enough.
I renamed the patch to the much more accurate "vt: hold console_sem
across sysfs operations" - "atomic" in the kernel ...
| May 28, 3:57 pm 2008 |
| Andrew Morton | Re: [PATCH] Restore MSGPOOL original value
On Mon, 26 May 2008 11:17:17 +0200
Please prefer to include the subsystem identifier in the patch title. ie:
[patch] ipc: restore MSGPOOL original value
But it is needed in 2.6.26, yes?
--
| May 28, 3:48 pm 2008 |
| Dave Jones | Re: Problem activating multiple cores ONLY if I press an ...
On Mon, May 26, 2008 at 10:06:44AM +0200, Jiri Slaby wrote:
> On 05/26/2008 05:39 AM, S K wrote:
> > and Fedora 9 with kernel 2.6.25.3-18.fc9.i686.
> [...]
> > I see this in dmesg:
> > CPU 1 irqstacks, hard=c07ba000 soft=c079a000
> > Not responding.
> > Inquiring remote APIC #1...
> > ... APIC #1 ID: failed
> > ... APIC #1 VERSION: failed
> > ... APIC #1 SPIV: failed
> > CPU #1 not responding - cannot use it.
> > Booting processor 1/2 ip 4000
> > Not responding.
> > Inquiring ...
| May 28, 11:35 am 2008 |
| Junio C Hamano | [ANNOUNCE] GIT 1.5.5.3
The latest maintenance release GIT 1.5.5.3 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.5.3.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.5.3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.5.3.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.5.3-1.$arch.rpm (RPM)
This one is much smaller than 1.5.5.2, primarily to push out a few fixes
to send-email and bisect that have already been in 'master' for a ...
| May 28, 1:18 am 2008 |
| Russell King - ARM Linux | Re: [PATCH]scsi: check the return value of device_create ...
I'd prefer not to kill the driver if device_create_file fails. Just
arrange to print a warning instead (and remember not to unregister
the file if it wasn't created.)
--
| May 28, 7:42 am 2008 |
| David Woodhouse | Re: [PATCHv4 27/28] firmware: Add CONFIG_BUILTIN_FIRMWAR ...
More feedback... Andrew wanted the help text to be a little more...
well, helpful. And Johannes wanted to add a CONFIG_BUILTIN_FIRMWARE_DIR
option, which lets you just point it at /lib/firmware or somewhere else
outside the kernel tree. And we fixed up a bunch of other details, like
the dependencies on directories, and the fact that the .S file doesn't
actually need to change when the binary blob does.
I even made the Makefile fit in 80 characters. It's going to make your
brain hurt either way ...
| May 28, 4:46 am 2008 |
| Steven Rostedt | Re: [PATCH] x86: enable preemption in delay
It's not even protected with the old code.
inline void __const_udelay(unsigned long xloops)
{
__delay(((xloops * HZ *
cpu_data(raw_smp_processor_id()).loops_per_jiffy) >> 32) + 1);
}
Here it calculates the loops_per_jiffy for the CPU and calls into __delay.
But it can easily be preempted here and the delay could run on another
CPU.
-- Steve
--
| May 28, 6:01 am 2008 |
| Maciej W. Rozycki | Re: [patch 06/11] x86: nmi_32/64.c - use apic_write_arou ...
Do you have a link with the patch included?
Maciej
--
| May 28, 9:13 am 2008 |
| Cyrill Gorcunov | Re: [patch 06/11] x86: nmi_32/64.c - use apic_write_arou ...
[Maciej W. Rozycki - Wed, May 28, 2008 at 04:35:14PM +0100]
| On Sat, 24 May 2008, Cyrill Gorcunov wrote:
|
| > apic_write_around will be expanded to apic_write in 64bit mode
| > anyway. Only a few CPUs (well, old CPUs to be precise) requires
| > such an action. In general it should not hurt and could be cleaned
| > up for apic_write (just in case)
| >
| > Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
| > ---
|
| Acked-by: Maciej W. Rozycki <macro@linux-mips.org>
|
| Almost all ...
| May 28, 9:04 am 2008 |
| Maciej W. Rozycki | Re: [patch 06/11] x86: nmi_32/64.c - use apic_write_arou ...
Acked-by: Maciej W. Rozycki <macro@linux-mips.org>
Almost all local APIC write accesses must use apic_write_around(). The
notable exceptions are appropriately guarded accesses to the ESR (there is
no need ever to write to this register on Pentium processors and a read of
the register has side-effects) and pieces of code known never to run on
original Pentium processors.
Maciej
--
| May 28, 8:35 am 2008 |
| Maciej W. Rozycki | Re: [patch 06/11] x86: nmi_32/64.c - use apic_write_arou ...
Well, nmi_watchdog=1 is the I/O APIC watchdog and if no watchdog has been
specified at the command line, the piece of code you have moved selects
between the local and the I/O APIC watchdog based on availability of the
former. So in this case the local watchdog must have been unavailable as
it works if requested explicitly.
No piece of code in nmi_watchdog_default() touches peripheral hardware
and native_smp_prepare_cpus() is called early enough the system is still
running UP and no APIC ...
| May 28, 10:47 am 2008 |
| Cyrill Gorcunov | Re: [patch 06/11] x86: nmi_32/64.c - use apic_write_arou ...
[Maciej W. Rozycki - Wed, May 28, 2008 at 05:13:08PM +0100]
| On Wed, 28 May 2008, Cyrill Gorcunov wrote:
|
| > Could you take a look please on
| >
| > http://lkml.org/lkml/2008/5/26/146
| >
| > i'm investigateting what is happening (Adrian pointed on
| > main reason I think) but can't understand why is that.
|
| Do you have a link with the patch included?
|
| Maciej
|
Here is the patch itself:
---
x86: nmi_32.c - add nmi_watchdog_default helper
Signed-off-by: Cyrill ...
| May 28, 9:25 am 2008 |
| Cyrill Gorcunov | Re: [patch 06/11] x86: nmi_32/64.c - use apic_write_arou ...
[Maciej W. Rozycki - Wed, May 28, 2008 at 06:47:56PM +0100]
| On Wed, 28 May 2008, Cyrill Gorcunov wrote:
|
| > Thanks a lot, Maciej!!! Could you please explain me how did you find
| > that? 'cause reporter said that with nmi_watchdog=2 it works and with
| > nmi_watchdog=1 it stalls? Maybe I should better make this function
| > the same as 64bit version has? I.e. set nmi_watchdog = NMI_NONE by default?
|
| Well, nmi_watchdog=1 is the I/O APIC watchdog and if no watchdog has been
| specified ...
| May 28, 11:32 am 2008 |
| Maciej W. Rozycki | Re: [patch 06/11] x86: nmi_32/64.c - use apic_write_arou ...
The problem is the I/O APIC NMI watchdog which does not work correctly on
the reporter's machine. Your patch makes the NMI watchdog be enabled by
default on 32-bit platforms (OTOH, proc_nmi_enabled() is only called by an
explicit request via sysctl). Unfortunately many hardware vendors have
not fully recognised the existence of Linux yet and the NMI watchdog
frequently triggers breakage in SMM firmware even on modern equipment;
actually it was less likely to break in the old days.
...
| May 28, 10:09 am 2008 |
| Cyrill Gorcunov | Re: [patch 06/11] x86: nmi_32/64.c - use apic_write_arou ...
[Maciej W. Rozycki - Wed, May 28, 2008 at 06:09:38PM +0100]
| On Wed, 28 May 2008, Cyrill Gorcunov wrote:
|
| > So I've moved a part of code (32bit) from proc_nmi_enabled() to
| > nmi_watchdog_default() BUT this nmi_watchdog_default() also called
| > from smpboot.c:native_smp_prepare_cpus() and before this patch
| > this call was just an empty call (and eliminated by gcc I think)
| > now it's not empy. But how it leads to hang I can't understand.
| > The only thing is done - nmi_watchdog is set ...
| May 28, 10:16 am 2008 |
| Gene Heskett | Re: floppy question of the hour
ilv=3 reads the fastest by a wide margin on the target machine.
Thanks Guys.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
God made everything out of nothing, but the nothingness shows through.
-- Paul Valery
--
| May 28, 2:50 pm 2008 |
| Gene Heskett | Re: floppy question of the hour
That would be a huge improvement, but I'm afraid it would need someone far more
familiar with floppy.c than I.
I am beginning to figure out how to make it work though. The sequence goes
something like this:
1. insert disk in drive, wait 5 minutes just in case, didn't help.
2. setfdprm /dev/fd0 COCO7203.5
3. getfdprm /dev/fd0 (fails, no such device)
4. dd if=/dev/fd0 bs=256 count=1
5. wait 20 to 40 secs for it to fail with an i/o error
6. setfdprm /dev/fd0 COCO7203.5
7. getfdprm ...
| May 28, 2:46 pm 2008 |
| Phillip Susi | Re: floppy question of the hour
IIRC, there is no way to detect the interleave factor that the media has
been formatted with, unless you maybe try several and see which one
reads fastest.
--
| May 28, 12:38 pm 2008 |
| Lennart Sorensen | Re: floppy question of the hour
Yeah, the Amiga trick wouldn't work. The Amiga had no interleave. It
didn't even have sector gaps. Just 11 consequtive sectors worth of data
per track and one gap at the end of the track. I really doubt any other
system could emulate that floppy access method without extra hardware.
--
Len Sorensen
--
| May 28, 12:59 pm 2008 |
| Gene Heskett | Re: floppy question of the hour
The drives, at least for the 880k format, were std chinon 3.5" drives. However,
I was under the impression there was about a 20 byte gap with the sector number
and a short A5 A5 synch string between the sectors. I still have a big box
A-2k, with one DD drive, and one of the special 1760k 150 rpm HD drives too.
But its been nearly a decade since an HD failure prompted me to store it in the
basement and learn to really use the first linux box I ever built in 1998,
RH-5.1 on it. So my ...
| May 28, 2:58 pm 2008 |
| Lennart Sorensen | Re: floppy question of the hour
Just do what the Amiga did: Read the entire track into a buffer in
memory, then deal with the sectors, and write the entire track back. :)
--
Len Sorensen
--
| May 28, 6:42 am 2008 |
| Daisuke Nishimura | Re: [PATCH -mm 04/16] free swap space on swap-in/activation
I'm sorry if I misunderstand your patches, but is this part needed
after
[PATCH -mm 07/16] second chance replacement for anonymous pages
is applied?
After the patch, if shrink_active_list() is called about
anon pages(that is, with file=0), those pages should go to inactive list,
so they should not be removed from swap cache, should they?
Thanks,
Daisuke Nishimura.
--
| May 28, 2:08 am 2008 |
| Rik van Riel | Re: [PATCH -mm 07/16] second chance replacement for anon ...
On Wed, 28 May 2008 14:36:56 +0900
It is zeroed 2 statements down.
if (!file)
zone->recent_rotated_anon += pgmoved;
/*
* Now put the pages back on the appropriate [file or anon] inactive
* and active lists.
*/
pagevec_init(&pvec, 1);
pgmoved = 0;
--
All rights reversed.
--
| May 28, 6:39 am 2008 |
| Daisuke Nishimura | Re: [PATCH -mm 07/16] second chance replacement for anon ...
Shouldn't 'pgmoved' be cleared to 0 before scanning l_hold?
It's used to store the result of sc->isolate_pages() before
scanning l_hold.
Thanks,
Daisuke Nishimura.
--
| May 27, 10:36 pm 2008 |
| Rik van Riel | Re: [PATCH -mm 07/16] second chance replacement for anon ...
On Wed, 28 May 2008 20:03:11 +0900
Good catch, I have applied your patch to my tree.
--
All rights reversed.
--
| May 28, 6:43 am 2008 |
| Daisuke Nishimura | Re: [PATCH -mm 07/16] second chance replacement for anon ...
When all the patches applied, shrink_active_list() looks like:
1135 pgmoved = sc->isolate_pages(nr_pages, &l_hold, &pgscanned, sc->order,
1136 ISOLATE_ACTIVE, zone,
1137 sc->mem_cgroup, 1, file);
:
1150 if (file)
1151 __mod_zone_page_state(zone, NR_ACTIVE_FILE, -pgmoved);
1152 else
1153 __mod_zone_page_state(zone, NR_ACTIVE_ANON, ...
| May 28, 8:42 am 2008 |
| Rik van Riel | Re: [PATCH -mm 07/16] second chance replacement for anon ...
On Thu, 29 May 2008 00:42:52 +0900
You are right, of course.
Looks like that code got mangled a little during one of the forward merges :)
--
All rights reversed.
--
| May 28, 9:08 am 2008 |
| KOSAKI Motohiro | Re: [PATCH -mm 07/16] second chance replacement for anon ...
I made memcgroup noreclaim infrastructure today.
and, I found slightly odd behaviour.
this condition increase OOM, because prevent active -> inactive moving
even though non global reclaim.
| May 28, 4:03 am 2008 |
| Guillaume Chazarain | Re: [PATCH] fs-writeback: handle errors in sync_sb_inodes()
On Wed, May 28, 2008 at 7:38 AM, Andrew Morton
http://lkml.org/lkml/2007/1/2/238
Hope that helps :-)
--
Guillaume
--
| May 28, 1:18 am 2008 |
| Dave Chinner | Re: [PATCH] fs-writeback: handle errors in sync_sb_inodes()
IIRC, it'll produce lots of spurious EIO errors under writeback on
XFS as XFS will return EAGAIN if we've been asked for a non-blocking
flush and we would have blocked....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
| May 28, 1:25 am 2008 |
| Andrew Morton | Re: [PATCH] fs-writeback: handle errors in sync_sb_inodes()
ho hum, I've forgotten why I didn't like this. Let's give it a run.
--
| May 27, 10:38 pm 2008 |
| Andrew Morton | Re: [PATCH] fs-writeback: handle errors in sync_sb_inodes()
argh. Who said it was allowed to do that :(
Give up. We (ie: I) need to fix this one properly.
--
| May 28, 1:46 am 2008 |
| Andrew Morton | Re: [PATCH] fs-writeback: handle errors in sync_sb_inodes()
OIC. This, I guess...
--- a/fs/fs-writeback.c~fs-writeback-handle-errors-in-sync_sb_inodes-fix
+++ a/fs/fs-writeback.c
@@ -500,7 +500,8 @@ void generic_sync_sb_inodes(struct super
__iget(inode);
pages_skipped = wbc->pages_skipped;
err = __writeback_single_inode(inode, wbc);
- mapping_set_error(mapping, err);
+ if (err == -EIO || err == -ENOSPC) /* xfs can return -EAGAIN */
+ mapping_set_error(mapping, err);
if (wbc->sync_mode == WB_SYNC_HOLD) {
inode->dirtied_when = ...
| May 28, 1:35 am 2008 |
| Dave Chinner | Re: [PATCH] fs-writeback: handle errors in sync_sb_inodes()
Rapidly gets messy. XFS can also return at least EDQUOT and EUCLEAN
(i.e. EFSCORRUPTED) from here as well, and it's likely that there's
other real errors I can't think of right now as well.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
| May 28, 1:43 am 2008 |
| Balbir Singh | Re: [PATCH -mm 00/16] VM pageout scalability improvements (V8)
Yes, I just saw it after I sent out my email. Let me try those patches. I'll
revert back
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
| May 28, 6:36 am 2008 |
| KOSAKI Motohiro | Re: [PATCH -mm 00/16] VM pageout scalability improvements (V8)
I sent the patch of fix this problem.
please see it.
--
| May 28, 6:33 am 2008 |
| Balbir Singh | Re: [PATCH -mm 00/16] VM pageout scalability improvements (V8)
Rik,
I've run into a case where with the splitvm patches the memory controller
immediately OOMs a task in the cgroup on exceeding it's limit. I am going to try
and find the root cause for it.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
| May 28, 4:49 am 2008 |
| KOSAKI Motohiro | [RFC PATCH] No Reclaim LRU Infrastructure enhancement fo ...
I tried to implement it today.
don't worry :)
it isn't big problem.
global lru is reclaimbale and memcg lru is noreclaimable
-> we can repair at move lru of shrink_[in]active_page().
global lru is noreclaimbale and memcg lru is reclaimable
-> we can repair mem_cgroup_isolate_pages()
| May 28, 4:04 am 2008 |
| KAMEZAWA Hiroyuki | Re: [PATCH -mm 00/16] VM pageout scalability improvements (V8)
On Tue, 27 May 2008 11:54:02 -0400
In my understanding, 2 checks we have to do.
1. When memcg finds PG_noreclaim page in its LRU, move it to noreclaim list of
memcg.
2. When PG_noreclaim page is moved back to generic LRU, memcg should move
it on its list. (we have to add a hook somewhere.)
But this may break current 'loose' synchronization between global LRU and
memcg's LRU. When PG_noreclaim page is put back into active/inactive LRU ?
concerns are
A. how to implement '2'
B. race ...
| May 27, 6:12 pm 2008 |
| Jonathan Woithe | Re: [PATCH] fujitsu-laptop: autload module on Lifebook P1510D
Ack.
jonathan
--
| May 27, 9:09 pm 2008 |
| Stephen Rothwell | Re: [PATCH -next] block: genhd errors when CONFIG_PROC_FS=n
Yeah, Greg has added it to his series for tomorrow and I have added it
to the end of linux-next for today.
--=20
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
| May 27, 11:01 pm 2008 |
| Greg KH | Re: [PATCH -next] block: genhd errors when CONFIG_PROC_FS=n
Yeah, sorry, missed that first time around, just added it to my tree
about an hour ago and sent out a response to Randy about it :)
thanks,
greg k-h
--
| May 27, 10:26 pm 2008 |
| Andrew Morton | Re: [PATCH -next] block: genhd errors when CONFIG_PROC_FS=n
This is a fix against
commit ce8568d9535b4756ea304a97ea803314ce895d3c
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date: Thu May 22 17:21:08 2008 -0400
block: make proc files seq_start use the class_find_device()
Use the proper class iterator function instead of mucking around in the
internals of the class structures.
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
--
| May 27, 10:20 pm 2008 |
| Matthew Garrett | [PATCH 1/3] Input: Add switch for dock events
Add a SW_DOCK switch to input.h. ACPI docks currently send their docking
status as a uevent, but not all docks are ACPI or correspond to a
device. In that case, it makes more sense to simply generate an input
event on docking or undocking.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
diff --git a/include/linux/input.h b/include/linux/input.h
index 28a094f..0bc55ee 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -638,6 +638,7 @@ struct input_absinfo {
#define ...
| May 28, 6:06 am 2008 |
| Matthew Garrett | [PATCH 3/3] Misc: Add HP WMI laptop extras driver
This driver adds support for reading and configuring certain information
on modern HP laptops with WMI BIOS interfaces. It supports enabling and
disabling the ambient light sensor, querying attached displays and hard
drive temperature, sending events on docking and querying the state of
the dock and toggling the state of the wifi, bluetooth and wwan hardware
via rfkill. It also makes the little "(i)" button work on machines that
send that via WMI rather than via the keyboard ...
| May 28, 6:29 am 2008 |
| Matthew Garrett | [PATCH 2/3] ACPI: Send switch event on dock events
Send a switch event on docking for consistency with docks that don't
present as a separate device.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
diff --git a/drivers/acpi/dock.c b/drivers/acpi/dock.c
index fa44fb9..a67e74c 100644
--- a/drivers/acpi/dock.c
+++ b/drivers/acpi/dock.c
@@ -25,6 +25,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
+#include <linux/input.h>
#include <linux/types.h>
#include <linux/notifier.h>
#include ...
| May 28, 6:21 am 2008 |
| Andrew Morton | Re: [RFC][Patch 5/5]integrity: IMA as an integrity servi ...
- I see lots of user file I/O being done from within the kernel.
This makes eyebrows raise. Also some other eyebrow-raising
file-related things in there.
- A complicated-looking in-kernel string parser which is implementing
an new and apparently-undocumented user->kernel ABI.
- Some GFP_ATOMICs which can hopefully become GFP_KERNEL.
- timespec_set() is unneeeded - just use struct assignment (ie: "=")
- timespec_recent() looks a bit hacky. The problems which are being
solved ...
| May 28, 1:22 am 2008 |
| Andrew Morton | Re: [RFC][PATCH 4/5]integrity: Linux Integrity Module(LIM)
Strange locking. We take the rcu_read_lock then locate a pointer to an
object then drop the lock, returning that pointer while doing nothing
hrm.
Probably the message should identify where it came from? "integrity:
I'm trying to find a non-trivial ->d_instantiate() implementation to
see how much overhead is being added to these performance-critical
Can we put the integrity_inode_init_integrity() call into
security_inode_init_security() thus avoiding having to change lots ...
| May 28, 12:46 am 2008 |
| Andrew Morton | Re: [RFC][Patch 2/5]integrity: TPM internel kernel interface
For robustness purposes it would be good to have a check that
sizeof(pcrread) does not exceed READ_PCR_RESULT_SIZE. One way of doing
that would be to add
if (sizeof(pcrread) > READ_PCR_RESULT_SIZE)
function_which_does_not_exist();
under the assumption that gcc will not emit the call. Or a plain old
BUG_ON() in the init code somewhere.
Or, better, implement all of this in a typesafe manner, using the C
An unaligned access. What architectures is this hardware available ...
| May 28, 12:17 am 2008 |
| Harvey Harrison | Re: [RFC][Patch 2/5]integrity: TPM internel kernel interface
rc = get_unaligned_be32((__be32 *)(data + 6));
If it was aligned:
rc = be32_to_cpup((__be32 *)(data + 6));
Cheers,
Harvey
--
| May 28, 9:12 am 2008 |
| Artem Bityutskiy | Re: bad example in Documentation/atomic_ops.txt ?
David,
do you have any comments on this? I paste the example below for
convenience.
static void obj_list_add(struct obj *obj)
{
obj->active = 1;
list_add(&obj->list);
}
static void obj_list_del(struct obj *obj)
{
list_del(&obj->list);
obj->active = 0;
}
static void obj_destroy(struct obj *obj)
{
BUG_ON(obj->active);
kfree(obj);
}
struct obj *obj_list_peek(struct list_head *head)
{
if (!list_empty(head)) {
...
| May 27, 10:28 pm 2008 |
| Sam Ravnborg | Re: [bisected] Re: [PATCH 05 of 12] xen: add p2m mfn_list_list
I cooked up this:
diff --git a/arch/x86/kernel/vmlinux_32.lds.S b/arch/x86/kernel/vmlinux_32.lds.S
index ce5ed08..963b2ae 100644
--- a/arch/x86/kernel/vmlinux_32.lds.S
+++ b/arch/x86/kernel/vmlinux_32.lds.S
@@ -40,6 +40,7 @@ SECTIONS
.text : AT(ADDR(.text) - LOAD_OFFSET) {
. = ALIGN(PAGE_SIZE); /* not really needed, already page aligned */
*(.text.page_aligned)
+ end_text_page_aligned = .;
TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
@@ -49,6 +50,9 @@ ...
| May 28, 7:10 am 2008 |
| Ingo Molnar | [bisected] Re: [PATCH 05 of 12] xen: add p2m mfn_list_list
-tip tree auto-testing found the following early bootup hang:
-------------->
get_memcfg_from_srat: assigning address to rsdp
RSD PTR v0 [Nvidia]
BUG: Int 14: CR2 ffd00040
EDI 8092fbfe ESI ffd00040 EBP 80b0aee8 ESP 80b0aed0
EBX 000f76f0 EDX 0000000e ECX 00000003 EAX ffd00040
err 00000000 EIP 802c055a CS 00000060 flg 00010006
Stack: ffd00040 80bc78d0 80b0af6c 80b1dbfe 8093d8ba 00000008 80b42810 80b4ddb4
80b42842 00000000 80b0af1c 801079c8 808e724e 00000000 ...
| May 28, 5:28 am 2008 |
| Jeremy Fitzhardinge | Re: [bisected] Re: [PATCH 05 of 12] xen: add p2m mfn_list_list
The use of __section(.data.page_aligned) (or worse
__attribute__((section(".data.page_aligned"))) is fairly verbose and
brittle. I've got a (totally untested) proposed patch below, to
introduce __page_aligned_data|bss which sets the section and the
alignment. This will work, but it requires that all page-aligned
variables also have an alignment associated with them, so that mis-sized
ones don't push the others around.
There aren't very many users of .data|bss.page_aligned, so it ...
| May 28, 7:02 am 2008 |
| Arjan van de Ven | Re: [PATCH] x86: Add PCI extended config space access fo ...
On Mon, 3 Sep 2007 10:17:39 +0200
Robert Richter <robert.richter@amd.com> wrote:
Hi,
As said before, I like the general approach. I have two comments below
Comment 1:
Can we make the 256/4096 thing conditional on actually having the
feature somehow? (while not making the code TOO ugly)
Comment 2:
The cpu_has_XXX is a bit dubious; while it's dependent on your cpu
model right now, I'm a bit hesitant to consider a PCI feature something
that belongs in the cpu_has_XXX namespace. (Yes I ...
| May 28, 12:02 pm 2008 |
| Sharyathi Nagesh | Re: correction to compat_sys_kexec_load
Bernhard/Eric
Thanks for helping with this. kexec patch has been submitted up stream
Thanks
Yeehaw
--
| May 27, 9:39 pm 2008 |
| Luck, Tony | RE: [PATCH 2/2] ACPI: add DMI info to enable OSI(Linux) ...
That sounds reasonable. We should also put #if defined(CONFIG_X86)
around all the existing entries in the acpi_osi_dmi_table[].
-Tony
--
| May 27, 9:04 pm 2008 |
| KAMEZAWA Hiroyuki | Re: [PATCH 2/2] ACPI: add DMI info to enable OSI(Linux) ...
On Tue, 27 May 2008 16:20:29 -0700
Ah, sorry. I think this is not 2.6.26 candidates.
Before patch.
- PrimeQuest doesn't work well without acpi_osi="Linux" boot option.
After patch
- PrimeQuest works well without boot option.
But Pavel Machek and Arjan van de Ven informed us that "Supporting OSI("Linux")
on PrimeQuest will be harmful even if it works well now. Because we cannot
guarantee compatibility of this interface in future". So, we're now discussing
the problem with our ...
| May 27, 5:09 pm 2008 |
| Alan Cox | Re: [PATCH] video4linux: Push down the BKL
The posix spec doesn't limit the errors returnable this way - it says if
the error is one of the ones listed it must return the error code stated so
Agreed - especially if it is opened with O_NDELAY
--
| May 28, 1:34 am 2008 |
| Devin Heitmueller | Re: [PATCH] video4linux: Push down the BKL
Pardon me for not being clear. I wasn't suggesting having a mutex for
on the open call itself. The mutex we have in the em28xx driver is
only in place when we are *switching* between modes. The thinking was
to have open return EBUSY if the device is already in use in the other
mode, but we weren't sure if that would cause problems with MythTV
(since the open call would fail) If MythTV can gracefully handle that
scenario, then that would be the ideal solution from a driver
Yeah, this was ...
| May 27, 7:47 pm 2008 |
| Hans Verkuil | Re: [PATCH] video4linux: Push down the BKL
Actually, it depends on how the card was defined. There are cards that
only utilize the analog part of the cx23418, cards that can do both
digital and analog at the same time and cards that can do either
digital or analog. The cx18 driver supports the first two cases but not
yet the last.
Regards,
Hans
--
| May 27, 11:13 pm 2008 |
| Devin Heitmueller | Re: [PATCH] video4linux: Push down the BKL
Hello Andy,
In this case, what you see as a 'feature' in MythTV is actually a
problem in our case. While the HVR-1600 can support this scenario,
the HVR-950 can only use one or the other (the em28xx chip uses GPIOs
to enable the demodulator and presumably you should never have both
demodulators enabled at the same time). Because of this we need a
lock. If MythTV only opened one device or the other at a time, we
could put the lock on the open() call, but since MythTV opens ...
| May 27, 5:46 pm 2008 |
| Andy Walls | Re: [PATCH] video4linux: Push down the BKL
I don't think a lock would be good for MythTV or any other app that
open()s multiple nodes at once. How can an app know that it's
dead-locking or barring itself via the kernel driver?
Maybe return an EBUSY or E-something else for these cases when Myth
tries to open() the second device node, when there's an underlying
factor that requires things to be mutually exclusive. Allowing things
like read() to allow hardware mode switching between analog and digital
seems like it could result in ...
| May 27, 7:37 pm 2008 |
| Haavard Skinnemoen | Re: [RFC][PATCH 1/2] Clocklib: add generic framework for ...
Sorry. I am...or at least I used to be until struct clk went all porky
and got hidden away in a .c file...
Like I've said before, I think the size of this thing is a real problem
and will prevent most arch maintainers from even considering it. The
previous version looked very good in that respect, but now the
porkiness of struct clk is back with a vengeance.
While I actually liked the previous version, there's no way I'm going
to use this version on avr32 with its 50+ clocks, and I expect ...
| May 28, 12:44 am 2008 |
| Haavard Skinnemoen | Re: [RFC][PATCH 1/2] Clocklib: add generic framework for ...
On Wed, 28 May 2008 19:34:34 +0400
Most of the 36 bytes that the kobject take up are useless. The fields
that _are_ useful are often useful to the hardware driver too, e.g.
Right...I forgot about that restriction. Maybe static platform_devices
Why not? Because a clock provider may decide to remove a clock
I don't think BUG()ing is appropriate since the module providing the
clock has no way of knowing whether it's ok to unregister the clock.
Maybe we can do the ...
| May 28, 12:52 pm 2008 |
| Dmitry Baryshkov | Re: [RFC][PATCH 1/2] Clocklib: add generic framework for ...
Hi,
Sorry, I don't understand you. Here is the definition from the C file:
struct clk {
struct kobject kobj;
int usage;
const struct clk_ops *ops;
void *data;
};
Which fields are useless from your POV? The mid-layer manages clocks
registration, so kobj. It manages usage (enablement) counters.
Citing Documentation/kobject.txt:
Because kobjects are dynamic, they must not be declared statically or on
the stack, but instead, always allocated dynamically. Future versions ...
| May 28, 8:34 am 2008 |
| Haavard Skinnemoen | Re: [RFC][PATCH 1/2] Clocklib: add generic framework for ...
clk_get_rate() returns unsigned long, so we're screwed. I think we need
You forgot to audit all drivers to make sure they handle bogus return
I have to say I'm glad the "clk function" stuff is gone as I never
Yes, I think it's less acceptable than the previous patchset. But if
other people like this patchset better, I can always stay with my own
"private" fields for a mid-layer that doesn't actually do anything
No, I really wish I could, but I can't think of any way to remove ...
| May 28, 6:56 am 2008 |
| Dmitry | Re: [RFC][PATCH 1/2] Clocklib: add generic framework for ...
Hi,
Haavard, few words before detailed comments. In this version of the patchset
I tried to solve the problem of dynamic unregistration of clocks.
Consider this example:
1) Module A register CLKA
2) Module B clk_gets CLKA
3) Module A is unloaded
3.1) As it's unloaded module A unregisters CLKA
4) Module B tries to clk_get_rate on CLKA
I can think of several solutions for this problem, but IMO the most clear one is
to force struct clk to be fully dynamic and to use kobjects for it's ...
| May 28, 5:44 am 2008 |
| David Howells | Re: [RFC/PATCH] nommu: fix ksize() abuse
Acked-by: David Howells <dhowells@redhat.com>
--
| May 28, 6:12 am 2008 |
| Pekka J Enberg | Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB
Thanks for testing! Where do I send these patches though? There's no entry
for no-MMU in MAINTAINERS. I guess I could just send them to Andrew...
Pekka
--
| May 28, 6:17 am 2008 |
| David Howells | Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB
Okay, I've fixed things so that it gets things aligned properly with SLOB.
This patch doesn't work for SLOB because SLOB doesn't set PG_slab on its
pages. This causes:
kernel BUG at mm/nommu.c:129!
Or, as gdb sees it:
Break 00000002
Program received signal SIGABRT, Aborted.
0xc0055498 in kobjsize (objp=<value optimized out>) at mm/nommu.c:129
(gdb) list
124
125 if (PageCompound(page))
126 return PAGE_SIZE << compound_order(page);
127
128 BUG_ON(page->index < ...
| May 28, 7:27 am 2008 |
| Christoph Lameter | Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB
Right. SLAB/SLUB align to long long. SLOB needs to do the same.
--
| May 28, 10:26 am 2008 |
| David Howells | Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB
Works for SLAB and SLUB. SLOB breaks well before getting to anything these
patches affect.
Acked-by: David Howells <dhowells@redhat.com>
--
| May 28, 6:12 am 2008 |
| David Howells | Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB
Andrew and/or Linus.
David
--
| May 28, 6:40 am 2008 |
| Mike Frysinger | Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB
what was the change exactly ? we were seeing alignment problems on
Blackfin and we fixed it with:
http://blackfin.uclinux.org/git/?p=readonly-mirrors/linux-kernel.git;a=commitdiff;h=50...
-mike
--
| May 28, 1:35 pm 2008 |
| David Howells | Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB
I fixed it by setting ARCH_KMALLOC_MINALIGN and ARCH_SLAB_MINALIGN.
David
--
| May 28, 10:38 am 2008 |
| David Howells | Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB
Okay... The problem with SLOB is that it can return large objects (8Kb in this
case) that aren't 8-byte aligned. This screws up FRV as it expects to be able
to use load and store-double instructions, which fault if they don't get
8-byte (double register) alignment.
David
--
| May 28, 7:09 am 2008 |
| Peter Zijlstra | Re: trace_mark ugliness
Doesn't leave much room...
void _trace_mark(const struct marker *mdata, ...)
{
va_list l;
preempt_disable();
for (iter = mdata->funcs; iter; iter = iter->next) {
va_start(l, mdata);
iter->func(mdata, &l);
va_end(l);
}
preempt_enable();
}
#define TRACE_FUNC4(name, type1, type2, type3, type4) \
struct marker_##name { \
struct marker mdata; \
void (*func_##name)(type1, type2, type3, type4); \
} \
static inline void trace_##name##_func(const ...
| May 28, 8:19 am 2008 |
| Andrew Morton | Re: [PATCH] security: was "Re: capget() overflows buffers."
"deprecated", please. "depreciated" is where you don't want your
investments to be.
--- a/include/linux/capability.h~capabilities-remain-source-compatible-with-32-bit-raw-legacy-capability-support-fix
+++ a/include/linux/capability.h
@@ -31,7 +31,7 @@ struct task_struct;
#define _LINUX_CAPABILITY_VERSION_1 0x19980330
#define _LINUX_CAPABILITY_U32S_1 1
-#define _LINUX_CAPABILITY_VERSION_2 0x20071026 /* depreciated - use v3 */
+#define _LINUX_CAPABILITY_VERSION_2 0x20071026 /* ...
| May 27, 8:33 pm 2008 |
| Vivek Goyal | Re: [PATCH 2/2] kexec jump -v10: save/restore device state
On Thu, May 22, 2008 at 05:38:19PM +0800, Huang, Ying wrote:
These two patches look good to me. I think once you have worked out
issues with IOAPIC and generated patches for compatibility with
new suspend/resume callbacks, these patches are good enough to get
some testing going on in -mm tree.
I will also test out -v10 very soon.
Thanks
Vivek
--
| May 28, 5:57 am 2008 |
| Luming Yu | Re: [RFC PATCH] set TASK_TRACED before arch_ptrace code ...
Some correction about the test case hang, the ps output should looks
like the following:
13925 S+ strace -f ./test1
13926 S+ ./test1
13927 T+ /bin/bash ./test2
I'm trying upstream kdump to get more detailed data for help analysis
the scenario..
But unfortunately upstream kernel just hang when I echo c to
sysrq-trigger. Downgrade the kernel to 2.6.22, 'echo c' doesn't
hang, but I just got "zero" dump file...
Will try F9 later... But from the symptom shouldn't we ask this
question: why ...
| May 28, 2:14 am 2008 |
| Dhaval Giani | Re: fair group scheduler not so fair?
So it is converging to a fair state. How does it look
This is over a longer duration or a 10 second duration?
--
regards,
Dhaval
--
| May 28, 11:47 am 2008 |
| Srivatsa Vaddagiri | Re: fair group scheduler not so fair?
Thanks for trying this combination. I discovered a task-leak in this loop
(__load_balance_iterator):
/* Skip over entities that are not tasks */
do {
se = list_entry(next, struct sched_entity, group_node);
next = next->next;
} while (next != &cfs_rq->tasks && !entity_is_task(se));
if (next == &cfs_rq->tasks)
return NULL;
We seem to be skipping the last element in the task list always. In your
case, the lone ...
| May 28, 9:33 am 2008 |
| Chris Friesen | Re: fair group scheduler not so fair?
Looking much better, but still some fairness issues with more complex
setups.
pid 2477 in A, others in B
2477 99.5%
2478 49.9%
2479 49.9%
move 2478 to A
2479 99.9%
2477 49.9%
2478 49.9%
So far so good. I then created C, and moved 2478 to it. A 3-second
"top" gave almost a 15% error from the desired behaviour for one group:
2479 76.2%
2477 72.2%
2478 51.0%
A 10-sec average was better, but we still see errors of 6%:
2478 72.8%
2477 64.0%
2479 63.2%
I then set up a ...
| May 28, 11:35 am 2008 |
| David Howells | Re: [2.6 patch] don't offer BINFMT_FLAT on frv
Consider it tested too.
David
--
| May 28, 6:00 am 2008 |
| Pierre Ossman | Re: 2.6.24 not recognizing 2G MMC card?
On Wed, 21 May 2008 13:21:04 -0400
Do you have any other MMC cards that work? Ricoh doesn't something
If you have a newer controller, then the ricoh_mmc module won't be able
to do its magic. Try the following patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=882c49...
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer ...
| May 28, 6:42 am 2008 |
| Pascal Hambourg | Re: Wired behaviour with IPv6 over PPP
Hello all,
AFAIK IPV6CP/PPP only allows to negotiate link local addresses. So I
guess the global address and default route is assigned by another
mechanism, maybe stateless autoconfiguration using router advertisement,
although I was not aware it could be used on a PPP link because of the
absence of MAC address. Enabling global forwarding
(net.ipv6.conf.all.forwarding=1) disables stateless autoconfiguration
(see ip-sysctl.txt in kernel documentation) on all interfaces. I believe
I ...
| May 28, 2:59 am 2008 |
| Willy Tarreau | Re: Wired behaviour with IPv6 over PPP
Hi,
Sorry, I understood that IPv6 addresses got lost when IP forwarding was
set to 1, which sounded strange to me. I've re-read the original mail
more carefully and noticed that it was _autoconfiguration_ which does not
Yes, any security fix must be backported when appropriate. I just don't
remember about this one, maybe I missed it. Care to send a pointer to
the commit in 2.6 ?
Thanks,
Willy
--
| May 28, 5:45 am 2008 |
| Andrew Morton | Re: [PATCH] VFS: Pagecache usage optimization onpagesize ...
On Tue, 27 May 2008 18:34:02 +0900
OK, thanks, let's give it a try.
It would be excellent if we had some benchmark numbers which justify
this change.
It also would be good if we can think up some workload which might be
slowed down by the change, and then demonstrate that this is not a
significant problem.
After all, it _is_ a performance patch...
--
| May 28, 4:23 pm 2008 |
| Haavard Skinnemoen | Re: MMIO and gcc re-ordering issue
I do -- in all the drivers for on-chip peripherals that are shared
between AT91 ARM (LE) and AVR32 (BE). Since everything goes on inside
the chip, we must use LE accesses on ARM and BE accesses on AVR32.
Currently, this is the only interface I know that can do native-endian
accesses, so if you take it away, I'm gonna need an alternative
interface that doesn't do byteswapping.
Haavard
--
| May 28, 1:36 am 2008 |
| Pavel Machek | Re: i8259: fix final uglyness
Done.
---
Introduce IRQx_VECTOR on 32-bit, so that #ifdef noise is kept
down. There should be no object code change.
Signed-off-by: Pavel Machek <pavel@suse.cz>
diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c
index 7a0fda8..dc92b49 100644
--- a/arch/x86/kernel/i8259.c
+++ b/arch/x86/kernel/i8259.c
@@ -297,34 +297,28 @@ void init_8259A(int auto_eoi)
* outb_pic - this has to work on a wide range of PC hardware.
*/
outb_pic(0x11, PIC_MASTER_CMD); /* ICW1: ...
| May 28, 3:42 am 2008 |
| Greg KH | Re: [PATCH 1/3][-mm] add class_reclassify macro
Oh forget it, I'm messing around in this area anyway, so all of these
changes are not going to apply to tomorrow's -next tree at all.
I'll take this and get it working, give me a bit...
thanks,
greg k-h
--
| May 28, 9:28 am 2008 |
| Greg KH | Re: [PATCH 1/3][-mm] add class_reclassify macro
Sorry, this will not work properly, as class_create() is now more
commonly called, and it calls class_register() from within the driver
core. So there would be a lot of classes with the same "key" because of
this.
So try changing class_create also.
thanks,
greg k-h
--
| May 28, 9:06 am 2008 |
| Matthew Wilcox | Re: [PATCH 1/3][-mm] add class_reclassify macro
We don't even have to go that far. Here's all that's needed:
diff -u a/drivers/base/class.c b/drivers/base/class.c
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -134,7 +134,7 @@
}
}
-int class_register(struct class *cls)
+int __class_register(struct class *cls, struct lock_class_key *key)
{
int error;
@@ -143,7 +143,7 @@
INIT_LIST_HEAD(&cls->devices);
INIT_LIST_HEAD(&cls->interfaces);
...
| May 28, 8:48 am 2008 |
| Greg KH | Re: [2.6 patch] remove Documentation/usb/uhci.txt
Sorry, it's old and out dated. If you wish to refresh it and add it
back, I'll gladly accept that patch.
thanks,
greg k-h
--
| May 28, 2:10 pm 2008 |
| Felipe Balbi | Re: [2.6 patch] remove Documentation/usb/uhci.txt
On Wed, 28 May 2008 14:38:42 +0800, "jidong xiao" <jidong.xiao@gmail.com>
True. I vote for keeping the doc :-)
--
Best Regards,
Felipe Balbi
http://felipebalbi.com
me@felipebalbi.com
--
| May 28, 6:34 am 2008 |
| jidong xiao | Re: [2.6 patch] remove Documentation/usb/uhci.txt
But I think this document is still very useful and informative
especially to those who are not quite familiar with UHCI HCDs. It is
not necessary to remove this one at the moment.
Regards
Jason
--
| May 27, 11:38 pm 2008 |
| Pierre Ossman | Re: [2.6 patch] include/linux/mmc/mmc.h: remove CVS tags
On Tue, 20 May 2008 00:57:27 +0300
Applied, thanks.
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
--
| May 28, 6:39 am 2008 |
| FUJITA Tomonori | Re: [PATCH v2 -mm 0/2] x86: per-device dma_mapping_ops
On Tue, 27 May 2008 11:24:08 +0530
I'm not sure what you mean exactly, but there might be other people
who want to use the dma_ops stacking though I'm not sure yet how they
use it:
Andrew already put this patchset in -mm. Unless someone comes with a
new reason against this patchset, it will be merged, I think.
BTW, Andrew, really sorry about several compile bugs due to the first
patch (changing dma_mapping_error) in this patchset. And thanks a lot
for fixing them.
--
| May 28, 3:19 am 2008 |
| K.Prasad | [RFC Patch 2/2] Renaming lib/trace.[ch] files to kernel/ ...
This patch renames the lib/trace.[ch] files to
kernel/relay_debugfs.[ch]. Also present are the changes to rename the
"trace_*" functions to "relay_*".
Two new functions which provide an easy-to-use interface for relay
called relay_printk() and relay_dump() are also introduced (earlier
called as trace_printk() and trace_dump()).
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
Documentation/filesystems/relay.txt | 22 +
include/linux/relay_debugfs.h | 155 +++++++
...
| May 28, 11:48 am 2008 |
| K.Prasad | Re: [RFC Patch 1/1] trace_printk and trace_dump interface - v2
Hi Andrew,
Given that "trace_*" consists of wrapper functions around "relay"
(relay + debugfs filesystem), I'm sending out the following patches
which rename lib/trace.[ch] to kernel/relay_debugfs.[ch]. The "trace_*"
functions are renamed to "relay_*" functions without any name-space
clashes with existing "relay" functions.
Now the new functions relay_printk() and relay_dump() will provide an
easy-to-use interface for "relay" and will also reduce the amount of
Along with the above ...
| May 28, 11:16 am 2008 |
| K.Prasad | [RFC Patch 0/1] Merging Documentation/trace.txt with Doc ...
This patch merges the "trace" documentation with that of "relay" as a
part of renaming/merging "trace" with "relay. It also renames the
functions wherever required.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
Documentation/filesystems/relay.txt | 215 ++++++++++++++++++++++++++++++++++++
Documentation/trace.txt | 210 -----------------------------------
2 files changed, 215 insertions(+), 210 deletions(-)
Index: ...
| May 28, 11:37 am 2008 |
| Kevin Hao | Re: [PATCH] x86: Get irq for hpet timer
Sorry for the delays.
I have revised this patch according to Maciej & Clemens suggestions.
The modifications include:
1. Assign a irq to the timer when we open the timer device. I think it's
better than do it in platform code. So we will have little impact on
other device.
2. Set IRQ routing entry for the irq we select.
3. If we in PIC mode, we skip all the well known legacy IRQ. And in io
apic we skip all the legacy IRQ.
4. Use level triggered mode by default.
BTW, Maciej. I am ...
| May 28, 3:42 am 2008 |
| Jun Ma | Re: MIPS kernel hangs: Warning: unable to open an initia ...
On Thu, May 15, 2008 at 9:38 PM, Manuel Lauss
And you must have a tty node in your /dev directory, e.g. /dev/ttyS0
--
FIXME if it is wrong.
--
| May 27, 8:15 pm 2008 |
| Paul Jackson | Re: [PATCH 10/10] x86 boot: add code to add BIOS provide ...
Good grief - you're right. I had only looked back nine months in my
archives, as you can tell, from my last message, in which I recite
some of that history. This saga has dragged on for two years now.
Summary of what's transpired in the last two years:
A] In the summer of 2006, Edgar Hucek submitted a patch that
after some back and forth ended up doing pretty much what my
latest patch does -- enabling the kernel to extract any EFI
memory map entries and add them to the ...
| May 28, 2:59 am 2008 |
| Jeremy Fitzhardinge | Re: [PATCH] x86: extend e820 ealy_res support 32bit - fix #2
Thanks, that nearly works. I needed the patch below to get it to
successfully boot.
For reference, this is what the early reserve map looks like now:
(early) 256MB LOWMEM available.
(early) low ram: 02634000 - 10000000
(early) bootmap 02634000 - 02636000
(early) early res: 0 [0-fff] BIOS data page
(early) early res: 1 [1000-1fff] EX TRAMPOLINE
(early) early res: 2 [6000-6fff] TRAMPOLINE
(early) early res: 3 [25db000-261dfff] XEN
(early) early res: 4 [1000000-18a8303] TEXT ...
| May 28, 3:01 am 2008 |
| Jeremy Fitzhardinge | Re: [PATCH] x86: extend e820 ealy_res support 32bit - fix #2
We can do that later. For now it's better to give them distinct names.
J
--
| May 28, 2:24 pm 2008 |
| Yinghai Lu | Re: [PATCH] x86: extend e820 ealy_res support 32bit - fix #2
can we use e820 entries for that? So the domain builder could have
will need x86_64_start_kernel there, maybe we should change all name
to x86_start_kernel
YH
--
| May 28, 1:48 pm 2008 |
| Jan Engelhardt | Re: vt/fbcon: fix background color on line feed
commit 7f676fb7cf34dd2982d0cf79aeea7e5b06ad91eb
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Wed May 28 10:00:41 2008 +0200
vt: fix background color on line feed, DEC invert
Original report: """I used to force my console to black-on-white by
the command `setterm -inversescreen on`. In 2.6.26-rc4, I get lots of
black background characters."""
Another addendum to commit c9e587ab.
This was previously missed out since I was not aware of what
...
| May 28, 10:08 am 2008 |
| thunder7 | Re: vt/fbcon: fix background color on line feed
From: Jan Engelhardt <jengelh@medozas.de>
Thanks, that fixes my issue with setterm -inversescreen on in
2.6.26-rc4.
Kind regards,
Jurriaan
--
"Light makes shadows. We all cast them. We'd be foolish to believe other-
wise. But that one--" She tilted her chin over her shoulder. "She darkens
those near her. She was a shadow before the sun ever touched her."
Melanie Rawn - Skybowl
--
| May 28, 11:56 am 2008 |
| Jason Wessel | Re: kgdb test suite failure
I believe the kgdb tests should pass for this configuration, and the
tests have been adjusted to support boards that do and don't have
working hardware breakpoints.
I queued the patch below into the for_linus branch for the 2.6.26
tree.
Jason.
---
From: Jason Wessel <jason.wessel@windriver.com>
Subject: kgdbts: Use HW breakpoints with CONFIG_DEBUG_RODATA
Whenever CONFIG_DEBUG_RODATA is set in the kernel config many kernel
text sections become read-only, and the use of software ...
| May 27, 6:37 pm 2008 |
| Jason Wessel | Re: kgdb test suite failure
It does seem like there should be a general way to force a controlled
write to a read-only page. That would certainly allow for the use of
software breakpoints with KGDB. At the point in time that such calls
come into existence I would certainly consider adding a toggle which
you can use from the debugger to provide such access.
At least for the current time for kgdb, we will use hardware
breakpoints.
Jason.
--
| May 27, 6:43 pm 2008 |
| Matheos Worku | Re: NIU - Sun Neptune 10g - Transmit timed out reset (2.6.24)
Dave,
Considering that fixing the HW would take considerable time, I was
wondering if the scheme we use in the nxge driver could be considered as
a workaround. Since the niu driver is already doing skb_orphan as a work
around, what if already transmitted TX buffers are reclaimed
periodically, within dev->hard_start_xmit() ? Then TX_DESC_MARK would
be set if/when available TX descriptor count falls below some watermark.
Disable device TX queue about the time TX_DESC_MARK is set and ...
| May 27, 6:18 pm 2008 |
| Nathan Lynch | Re: [PATCH 2/3] [2.6.26] ehea: Add dependency to Kconfig
Hello,
I disagree with this change.
It makes it impossible to build the ehea driver without memory hotplug
enabled. Presumably, this commit was intended to work around a build
break of this sort (with EHEA=m and MEMORY_HOTPLUG=n):
drivers/net/ehea/ehea_qmr.c: In function 'ehea_create_busmap':
drivers/net/ehea/ehea_qmr.c:635: error: implicit declaration of function 'walk_memory_resource'
(some indication of this should have been in the commit message, btw)
I think this was the wrong ...
| May 28, 9:44 am 2008 |
| Jan Engelhardt | Re: sound: azx_get_response timeout
Ah nah.. for some reason I forgot to delete that line from the mail.
But then it seems to be running for half an hour with 2.6.23.17 so far,
so that may be a bisection helping point. Will report bisect findings as
The voulme control for 'Headphones' is 0, but I do hear things,
so I do use the "Master Front" mixer. (There is just one green
(have not booted into 2.6.25 again yet, but will do)
--
| May 28, 10:09 am 2008 |
| Jens Axboe | Re: 2.6.26-rc4: RIP __call_for_each_cic+0x20/0x50
Good point, I was thinking we decremented the mod count on call_rcu(),
but we don't actually do it before the rcu callback has completed. So
that part is actually OK already.
--
Jens Axboe
--
| May 28, 4:58 am 2008 |
| Paul E. McKenney | Re: 2.6.26-rc4: RIP __call_for_each_cic+0x20/0x50
So the call from cfq_get_io_context() needs an rcu_read_lock()?
Not seeing this in the patch below, but maybe you have it up a
Looks much improved! Very interested to hear how it does with the testing.
--
| May 28, 3:30 am 2008 |
| Fabio Checconi | Re: 2.6.26-rc4: RIP __call_for_each_cic+0x20/0x50
But isn't the ioc_gone completion (notified only when there are no more
cic allocated) assuring that cfq_slab_kill() is called only after all
the rcu callbacks are completed? This should avoid the need for the
rcu_barrier().
--
| May 28, 4:52 am 2008 |
| Jens Axboe | Re: 2.6.26-rc4: RIP __call_for_each_cic+0x20/0x50
So that one was also OK, as Fabio pointed out. If you follow the
ioc_gone and user tracking, the:
if (elv_ioc_count_read(ioc_count))
wait_for_completion(ioc_gone);
also has the side effect of waiting for RCU callbacks calling
It's in there, it now does:
rcu_read_lock();
cic = rcu_dereference(ioc->ioc_data);
if (cic && cic->key == cfqd) {
rcu_read_unlock();
return cic;
}
...
OK? ...
| May 28, 5:44 am 2008 |
| Jens Axboe | Re: 2.6.26-rc4: RIP __call_for_each_cic+0x20/0x50
__call_for_each_cic() is always called under rcu_read_lock(), it merely
exists to avoid a double rcu_read_lock(). Even if it is cheap. The
convention follows the usual __lock_is_already_held() double under
score, but I guess it could do with a comment! There are only two
callers of the function, call_for_each_cic() which does the
rcu_read_lock(), and cfq_free_io_context() which is called from ->dtor
(and holds the rcu_read_lock() and ->trim which actually does not. That
looks like it could be ...
| May 28, 3:07 am 2008 |
| Paul E. McKenney | Re: 2.6.26-rc4: RIP __call_for_each_cic+0x20/0x50
OK, looks good.
--
| May 28, 6:20 am 2008 |
| Greg KH | Re: [PATCH] usb-serial: option: Don't match Huawei drive ...
Oops, sorry, I lost this message in the queue.
Can you regenerate your patch against 2.6.26-rc4 and resend it?
thanks,
greg k-h
--
| May 28, 10:17 am 2008 |
| Michael Karcher | Re: [PATCH] usb-serial: option: Don't match Huawei drive ...
--=-RJYjmwQH4n3IEhz6MAzZ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Regenerated agains git HEAD, attached.
Regards,
Michael Karcher
--=-RJYjmwQH4n3IEhz6MAzZ
Content-Disposition: attachment; filename=huawei-id.diff
Content-Type: text/x-patch; name=huawei-id.diff; charset=utf-8
Content-Transfer-Encoding: ...
| May 28, 2:58 pm 2008 |
| Eric W. Biederman | Re: [PATCH] kill_something_info: don't take tasklist_loc ...
We can only pretend that if the parent lives. If the parent is killed
then we can not so pretend.
Which in a lot of ways is the problem. kill(-1,SIGKIL) should
kill everything except for init and the process that sent the
signal. If anything else survives we have a broken the shutdown
scripts.
Since the race would rarely hit it will take ages for someone
to trace back to a kernel change.
If I could convince myself that Oleg is correct and that what
Oleg is proposing will always work ...
| May 28, 8:03 am 2008 |
| Nick Piggin | Re: Why is the rewritten ramdisk driver called brd insta ...
Yeah it was a rwrite from scratch and it lived with the rd.c code for
a while (although maybe never in mainline). I guess it might be good
idea to rename it back to rd?
--
| May 27, 11:11 pm 2008 |
| Mingming Cao | Re: [PATCH-v2] JBD: Fix race between free buffer and com ...
You are right that the page was locked during the process we are trying
Thanks for pointing this out. I think when we put back the reversed
locking order and new ordered mode the jbd2 patch could go away...
Updated patch for JBD (take 4) below.
Mingming
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 ...
| May 28, 11:18 am 2008 |
| Jan Kara | Re: [PATCH-v2] JBD: Fix race between free buffer and com ...
I think Andrew prefered this test to be expanded but otherwise the patch
is fine now. You can add:
Acked-by: Jan Kara <jack@suse.cz>
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
| May 28, 11:55 am 2008 |
| Huang, Ying | Re: [PATCH -mm] kexec jump -v9
On Tue, 2008-05-27 at 18:15 -0400, Vivek Goyal wrote:
Yes. Rafel has a new patch to separate suspend and hibernation device
call backs.
Yes. This issue is kexec/kjump specific. We can call it in kexec_jump().
Maybe we also need call something other in native_machine_shutdown()?
BTW: I have a new version -v10: http://lkml.org/lkml/2008/5/22/106, do
you have time to review it?
Best Regards,
Huang Ying
--
| May 27, 6:35 pm 2008 |
| Eric Sandeen | Re: 4KSTACKS + DEBUG_STACKOVERFLOW harmful
Nope... but Andi Kleen sent a patch to put the warning on the irq stack
rather than the main process stack, so it avoids the original problem
It depends, I guess; if you have 8k stacks it'd probably fit ok in
I don't actually know if systemtap can do what you want (not saying it
can't; just saying I don't know...)
-Eric
--
| May 28, 8:13 am 2008 |
| Mike Snitzer | Re: 4KSTACKS + DEBUG_STACKOVERFLOW harmful
Hi Eric,
Did you happen to get a patch together that reduces the stack usage of
dump_stack?
Also, what did you use to print your (above) indented callchain stack
usage of dump_stack?
I'd like to be able to audit the worst case stack usage of _all_ call
chains that originate from a given thread. This would effectively be
like DEBUG_STACK_USAGE except with finer grained (per call-chain)
statistics. One crude way of doing this is to dump_stack() whenever a
task's call-chain is the new ...
| May 28, 7:36 am 2008 |
| previous day | today | next day |
|---|---|---|
| May 27, 2008 | May 28, 2008 | May 29, 2008 |
