Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v4
On Wed, 2007-05-16 at 00:23 +0100, Alistair John Strachan wrote: > > - TSC calibration against PM-Timer > > Working fine now, thanks a lot. Great latencies on usleep() now too, just > what > I was looking for. > > (BTW, with HRT (but not NO_HZ), does the HZ value have any effect on usleep() > (and friends) latencies?) Not directly. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user
Andrew Morton wrote: On Wed, 16 May 2007 14:52:05 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: On the other hand non highmem platforms are burdened with always repeating the same KM_USER0 in every function call. Isnt it enough to know that standard functions use KM_USER0 for their operations? Couldn't that be filtered out inline? It is - there is no runtime overhead for non-highmem machines. The problem nowadays is all the developers who don't need, have, compile for or test on highmem machines. Well sure, if that's all Christoph is worried about, then it isn't really valid because in generic code we have to follow the architecture abstraction API -- there is no "non highmem platform" in generic code :) -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21 numa policy and huge pages not working
prior to 2.6.21 i could "numactl --interleave=all" and use SHM_HUGETLB and
the interleave policy would be respected. as of 2.6.21 it doesn't seem to
respect the policy on SHM_HUGETLB request.
see test program below.
output from pre-2.6.21:
2ab19620 interleave=0-3 file=/2\040(deleted) huge dirty=32 N0=8 N1=8 N2=8
N3=8
2ab19a20 default file=/SYSV\040(deleted) dirty=16384 active=0
N0=4096 N1=4096 N2=4096 N3=4096
output from 2.6.21:
2b49b1c0 default file=/10\040(deleted) huge dirty=32 N3=32
2b49b5c0 default file=/SYSV\040(deleted) dirty=16384 active=0
N0=4096 N1=4096 N2=4096 N3=4096
was this an intentional behaviour change? it seems to be only affecting
SHM_HUGETLB allocations. (i haven't tested hugetlbfs yet.)
run with "numactl --interleave=all ./shmtest"
-dean
/* shmtest.c */
#include
#include
#include
#include
#include
#include
#include
static void *alloc_arena_shm(size_t arena_size, unsigned flags)
{
FILE *fh;
char buf[512];
size_t huge_page_size;
char *p;
int shmid;
void *arena;
// find Hugepagesize in /proc/meminfo
if ((fh = fopen("/proc/meminfo", "r")) == NULL) {
perror("open(/proc/meminfo)");
exit(1);
}
for (;;) {
if (fgets(buf, sizeof(buf)-1, fh) == NULL) {
fprintf(stderr, "didn't find Hugepagesize in
/proc/meminfo");
exit(1);
}
buf[sizeof(buf)-1] = '\0';
if (strncmp(buf, "Hugepagesize:", 13) == 0) break;
}
p = strchr(buf, ':') + 1;
huge_page_size = strtoul(p, 0, 0) * 1024;
fclose(fh);
// round the size up to multiple of huge_page_size
arena_size = (arena_size + huge_page_size - 1) & ~(huge_page_size - 1);
shmid = shmget(IPC_PRIVATE, arena_size, IPC_CREAT|IPC_EXCL|flags|0600);
if (shmid == -1) {
perror("shmget");
exit(1);
}
arena = shmat(shmid, NULL, 0);
if (arena == (void *)-1) {
perror("shmat");
exit(1);
}
if (shmctl(shmid, IPC_RMID, 0) == -1) {
perror("shmctl warning");
}
return arena;
}
int main(int argc, char **argv)
{
char buf[1024];
const size_t sz = 64*1024*1024;
void *arena = alloc_arena_shm(sz, SHM_HUGETLB);
memset(arena, 0, sz);
snprintf(buf, sizeof(buf), "grep ^%llx /proc/%d/numa_maps", (unsigned
long long)arena, (int)getpid());
system(buf);
arena = alloc_arena_shm(sz, 0);
memset(arena, 0, sz);
snprintf(buf, sizeof(buf), "grep ^%llx /proc/%d/numa_maps", (unsigned
long long)arena, (int)getpid());
system(buf);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git patches] libata fixes
All bug fixes. The two things that do not seem like bugfixes ("separate
out..." and "add ATA_FLAG_ACPI_SATA") are not as they seem. The former
is a prep patch for a fix, and the latter fixes what ACPI considers a
legacy IDE interface.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ahci.c|3 +-
drivers/ata/libata-acpi.c | 10 +++---
drivers/ata/libata-core.c | 80 +++-
drivers/ata/libata-scsi.c | 44
drivers/ata/libata.h |3 +-
drivers/ata/pata_scc.c|4 +-
drivers/ata/sata_sil24.c |3 +-
include/linux/libata.h|3 +-
8 files changed, 100 insertions(+), 50 deletions(-)
Al Viro (1):
pata_scc had been missed by ata_std_prereset() switch
Tejun Heo (5):
libata: separate out ata_dev_reread_id()
libata: during revalidation, check n_sectors after device is configured
libata-acpi: add ATA_FLAG_ACPI_SATA port flag
libata: fix shutdown warning message printing
libata: track spindown status and skip spindown_compat if possible
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 1ae443d..e00e1b9 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -173,7 +173,8 @@ enum {
AHCI_FLAG_COMMON= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
- ATA_FLAG_SKIP_D2H_BSY,
+ ATA_FLAG_SKIP_D2H_BSY |
+ ATA_FLAG_ACPI_SATA,
};
struct ahci_cmd_hdr {
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index ed4138e..0223673 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -321,7 +321,7 @@ static int do_drive_get_GTF(struct ata_device *dev,
unsigned int *gtf_length,
/* Don't continue if device has no _ADR method.
* _GTF is intended for known motherboard devices. */
- if (!(ap->cbl == ATA_CBL_SATA)) {
+ if (!(ap->flags & ATA_FLAG_ACPI_SATA)) {
err = pata_get_dev_handle(gdev, _handle, );
if (err < 0) {
if (ata_msg_probe(ap))
@@ -343,7 +343,7 @@ static int do_drive_get_GTF(struct ata_device *dev,
unsigned int *gtf_length,
/* Get this drive's _ADR info. if not already known. */
if (!dev->obj_handle) {
- if (!(ap->cbl == ATA_CBL_SATA)) {
+ if (!(ap->flags & ATA_FLAG_ACPI_SATA)) {
/* get child objects of dev_handle == channel objects,
* + _their_ children == drive objects */
/* channel is ap->port_no */
@@ -528,7 +528,7 @@ static int do_drive_set_taskfiles(struct ata_device *dev,
ata_dev_printk(dev, KERN_DEBUG, "%s: ENTER: port#: %d\n",
__FUNCTION__, ap->port_no);
- if (libata_noacpi || !(ap->cbl == ATA_CBL_SATA))
+ if (libata_noacpi || !(ap->flags & ATA_FLAG_ACPI_SATA))
return 0;
if (!ata_dev_enabled(dev) || (ap->flags & ATA_FLAG_DISABLED))
@@ -578,7 +578,7 @@ int ata_acpi_exec_tfs(struct ata_port *ap)
* we should not run GTF on PATA devices since some
* PATA require execution of GTM/STM before GTF.
*/
- if (!(ap->cbl == ATA_CBL_SATA))
+ if (!(ap->flags & ATA_FLAG_ACPI_SATA))
return 0;
for (ix = 0; ix < ATA_MAX_DEVICES; ix++) {
@@ -641,7 +641,7 @@ int ata_acpi_push_id(struct ata_device *dev)
__FUNCTION__, dev->devno, ap->port_no);
/* Don't continue if not a SATA device. */
- if (!(ap->cbl == ATA_CBL_SATA)) {
+ if (!(ap->flags & ATA_FLAG_ACPI_SATA)) {
if (ata_msg_probe(ap))
ata_dev_printk(dev, KERN_DEBUG,
"%s: Not a SATA device\n", __FUNCTION__);
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4166407..d5939e6 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1919,7 +1919,6 @@ int ata_dev_configure(struct ata_device *dev)
snprintf(revbuf, 7, "ATA-%d",
ata_id_major_version(id));
dev->n_sectors = ata_id_n_sectors(id);
- dev->n_sectors_boot = dev->n_sectors;
/* SCSI only uses 4-char revisions, dump full 8 chars from ATA
*/
ata_id_c_string(dev->id, fwrevbuf, ATA_ID_FW_REV,
@@ -3632,7 +3631,6 @@ static int ata_dev_same_device(struct ata_device *dev,
unsigned int new_class,
const u16 *old_id = dev->id;
unsigned char model[2][ATA_ID_PROD_LEN + 1];
unsigned char serial[2][ATA_ID_SERNO_LEN + 1];
- u64 new_n_sectors;
if (dev->class != new_class) {
Re: Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user
On Wed, 16 May 2007 14:52:05 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: > Christoph Lameter wrote: > > On Tue, 15 May 2007, Andrew Morton wrote: > > > > > >>> The functions above default to KM_USER0 which is also always used when > >>> zero_user_page was called except in one single case. We open code that > >>> single case to draw attention to the spot. > >>> > >> > >>Dunno. fwiw, we decided to _not_ embed KM_USER0 in the callee: we have had > >>some pretty ghastly bugs in the past due to misuse of kmap slots so the > >>idea was to shove the decision into the caller's face, make them think > >>about what they're doing > > > > > > On the other hand non highmem platforms are burdened with always repeating > > the same KM_USER0 in every function call. Isnt it enough to know that > > standard functions use KM_USER0 for their operations? > > Couldn't that be filtered out inline? It is - there is no runtime overhead for non-highmem machines. The problem nowadays is all the developers who don't need, have, compile for or test on highmem machines. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] drivers/ata: correct a wrong free function for sata_nv driver
Sorry for posting a fault patch,following is the right one. Signed-off-by: Peer Chen <[EMAIL PROTECTED]> === --- linux-2.6.22-rc1/drivers/ata/sata_nv.c.orig +++ linux-2.6.22-rc1/drivers/ata/sata_nv.c @@ -1619,7 +1619,7 @@ static void nv_remove_one (struct pci_de struct nv_host_priv *hpriv = host->private_data; ata_pci_remove_one(pdev); - kfree(hpriv); + devm_kfree(>dev, hpriv); } #ifdef CONFIG_PM = BRs Peer Chen -Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 16, 2007 1:21 PM To: Peer Chen Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; IDE/ATA development list Subject: Re: [PATCH] drivers/ata: correct a wrong free function for sata_nv driver Peer Chen wrote: > For sata_nv driver in kernel 2.6.21 onward, Inside nv_init_one(),use > 'hpriv = devm_kzalloc(>dev, sizeof(*hpriv), GFP_KERNEL);' but > using the kfree(hpriv) to free that data struction in nv_remove_one(), > which will cause system hang when removing the sata_nv module. > > Change the 'kfree()' function to 'devm_kfree' will fix this bug. > > The patch base on kernel 2.6.22-rc1. > > Signed-off-by: Peer Chen <[EMAIL PROTECTED]> > = > --- linux-2.6.22-rc1/drivers/ata/sata_nv.c.orig > +++ linux-2.6.22-rc1/drivers/ata/sata_nv.c > @@ -1619,7 +1619,7 @@ static void nv_remove_one (struct pci_de > struct nv_host_priv *hpriv = host->private_data; > > ata_pci_remove_one(pdev); > - kfree(hpriv); > + devm_kfree(_dev->dev, hpriv); This patch is complete crap. It doesn't even compile. There is no variable "pci_dev" in this function at all. It is highly discouraging that you cannot even bother to compile your own submissions to the second (or third) most popular operating system in the world. Jeff --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird hard disk noise on shutdown (bug #7674)
On Tuesday 15 May 2007 5:08 pm, Dave Jones wrote: > On Mon, May 14, 2007 at 07:32:43PM +0200, Tejun Heo wrote: > > Francesco Pretto wrote: > > > 2007/5/4, Tejun Heo <[EMAIL PROTECTED]>: > > >> Yeap, the third iteration of the patch just got submitted. > > >> > > >> http://thread.gmane.org/gmane.linux.ide/18485 > > >> > > >> Unfortunately, there doesn't seem to be an easy way out. We'll need > > >> userland shutdown(8) update. > > >> > > >> -- > > >> tejun > > >> > > > > > > Ok, i can't understand if the patch will be included in 2.6.22 (i > > > didn't see it in the Andrew Morton merge plan). However, if you can > > > confirm the inclusion, i can send bug reports for ubuntu and gentoo. I > > > can even send an email to Miquel van Smoorenburg, who should be the > > > mainstream sysvinit developer (and probably the last maintainer). > > > > Okay, the patch made upstream and webpage posted. > > > > http://linux-ata.org/shutdown.html > > There's a typo.. > > "Check whether /sys/modules/libata/parameters/spindown_compat exists. If it does, write 0 to it." > > should be /sys/module/libata/parameters/spindown_compat > > (no 's' after module) Um, hang on. So libata can't reliably turn the system off without data loss and potential damage to hardware unless userspace goes through a special song and dance? And this is _not_ considered a defect in the kernel? Why? (Is there any other piece of hardware that needs userspace to quiesce it just so the _off_switch_ can take effect? Yes, I read both the gmane thread and the linux-ata.org link. I used to maintain the busybox halt/reboot/poweroff commands, although I don't anymore. That just called reboot(), and this worked.) Why on _earth_ does complicating software suspend add extra requirements to actual shutdown? Since when does the shutdown command have to enumerate attached block devices? If anything this would belong in umount -a, but that doesn't care about the hardware of the underlying block devices and SHOULDN'T... I'm confused. Could someone please explain? Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LogFS take three
On Wed, May 16, 2007 at 02:06:31AM +0200, Jörn Engel wrote: > On Tue, 15 May 2007 13:37:59 -0700, Andrew Morton wrote: > > It's strange and a bit regrettable that an fs would have dependency on MTD, > > really. > > It is and changing this wouldn't be too hard. All device access goes > through five functions (read, write, erase, is_bad and mark_bad). As > soon as someone seriously cares I will add a struct logfs_device_ops and > have a second set of these functions for block devices. > > On hard disks it shouldn't make too much sense. The filesystem will > fragment like a splinter bomb and be just as popular. On hard disks, yes, but as you suggested, there are lots of other flash devices interfaced as block devices. CompactFlash comes to mind, USB keys too. And on these ones, the most important is to reduce the number of writes and to support large sizes. I already see LogFS as an interesting alternative to JFFS2 on such devices, eventhough it does not (yet?) support compression. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
stack alignment on i386
[PATCH] x86: Drop cc-options call for all options supported in gcc
3.2+
The kernel only supports gcc 3.2+ now so it doesn't make sense
anymore to explicitely check for options this compiler version
already has.
This actually fixes a bug. The -mprefered-stack-boundary check
never worked because gcc rightly complains
CC arch/i386/kernel/asm-offsets.s
cc1: -mpreferred-stack-boundary=2 is not between 4 and 12
Hi
Your patch for stack alignment on i386 is wrong. -mprefered-stack-boundary
is log2 of the stack alignment (read gcc man page). On AMD64 16-byte
alignment is enforced because of SSE, on i386 minimal alignment is 4
bytes.
See the code in gcc that triggered your error:
i = atoi (ix86_preferred_stack_boundary_string);
if (i < (TARGET_64BIT ? 4 : 2) || i > 12)
error ("-mpreferred-stack-boundary=%d is not between %d and 12",
i,
TARGET_64BIT ? 4 : 2);
else
ix86_preferred_stack_boundary = (1 << i) * BITS_PER_UNIT;
You are actually dealing with gcc bug, not Linux bug --- when gcc is
compiled with AMD64 support it enforces 16-byte alignment even in 32-bit
mode.
Rather let it be as it was, adding -mpreferred-stack-boundary=4 doesn't
make sense, because it is default.
Mikulas
Signed-off-by: Mikulas Patocka <[EMAIL PROTECTED]>
--- linux-2.6.22-rc1/arch/i386/Makefile_Thu May 17 23:47:31 2007
+++ linux-2.6.22-rc1/arch/i386/Makefile Thu May 17 23:47:45 2007
@@ -34,7 +34,9 @@
CFLAGS += -pipe -msoft-float -mregparm=3 -freg-struct-return
# prevent gcc from keeping the stack 16 byte aligned
-CFLAGS += -mpreferred-stack-boundary=4
+# gcc has a bug that it doesn't allow 4-byte alignment when compiled with
+# 64-bit support and producing 32-bit code, so this option must be tested
+CFLAGS += $(call cc-option,-mpreferred-stack-boundary=2)
# CPU-specific tuning. Anything which can be shared with UML should go here.
include $(srctree)/arch/i386/Makefile.cpu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata: fix shutdown warning message printing
Tejun Heo wrote: Unlocking ap->lock and ssleeping don't work because SCSI commands can be issued from completion path without context. Reimplement delayed completion by allowing translation functions to override qc->scsidone(), storing the original completion function to scmd->scsi_done() and overriding qc->scsidone() with a function which schedules delayed invocation of scmd->scsi_done(). This isn't pretty at all but all the ugly parts are thankfully contained in the stop translation path where the compat feature is implemented. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> applied to #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/ata: correct a wrong free function for sata_nv driver
Peer Chen wrote: For sata_nv driver in kernel 2.6.21 onward, Inside nv_init_one(),use 'hpriv = devm_kzalloc(>dev, sizeof(*hpriv), GFP_KERNEL);' but using the kfree(hpriv) to free that data struction in nv_remove_one(), which will cause system hang when removing the sata_nv module. Change the 'kfree()' function to 'devm_kfree' will fix this bug. The patch base on kernel 2.6.22-rc1. Signed-off-by: Peer Chen <[EMAIL PROTECTED]> = --- linux-2.6.22-rc1/drivers/ata/sata_nv.c.orig +++ linux-2.6.22-rc1/drivers/ata/sata_nv.c @@ -1619,7 +1619,7 @@ static void nv_remove_one (struct pci_de struct nv_host_priv *hpriv = host->private_data; ata_pci_remove_one(pdev); - kfree(hpriv); + devm_kfree(_dev->dev, hpriv); This patch is complete crap. It doesn't even compile. There is no variable "pci_dev" in this function at all. It is highly discouraging that you cannot even bother to compile your own submissions to the second (or third) most popular operating system in the world. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make cancel_rearming_delayed_work() reliable
On Wed, May 16, 2007 at 02:08:12AM +0400, Oleg Nesterov wrote: > On 05/15, Jarek Poplawski wrote: > > > > I've overheared somebody is talking about my favorite 2-nd bit! ... > We already discussed this... Surely, we can do this. I believe > this will complicate (and _imho_ uglify) the code too much. Yes, but now I see you are about to change your mind about this bit... > May be I am wrong. Please provide a detailed description? I'll try too look more at your solution - maybe it's "not so bad". I've probably exaggerated yesterday about this overhead of setting the VALID bit. Cheers, Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Sorenson wrote: > Thomas Gleixner wrote: >> Frank, > >> On Tue, 2007-05-15 at 09:06 -0500, Frank Sorenson wrote: >>> Hangs at boot here: >>> Kernel alive >>> Kernel direct mapping tables up to 1 @ 8000-d000 >>> (and that's it) >>> >>> This is a Dell Inspiron E1705 with a Core 2 Duo 2.16GHz >>> >>> highres-v3 also hung at the same point, but 2.6.21-git2-v2 worked >>> 2.6.22-rc1 boots without problem >> Can you please try the following three command line option addons ? > >> 1: highres=off nohz=off >> 2: highres=off >> 3: nohz=off > >> Thanks, > >> tglx > > All 3 hang at the same point. I have tracked down the offending patch in the series to x86-64-convert-to-clockevents.patch Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGSpB2aI0dwg4A47wRAglRAJ4mJgbJClPd0hkXKp+YHq7G5VxQvgCgkVkv TtOjrSrjrwiHQPkNCqlq314= =lu8g -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] em28xx and ivtv should depend on PCI
On Wed, May 16, 2007 at 05:57:39AM +0200, Markus Rechberger wrote: > On 5/16/07, Al Viro <[EMAIL PROTECTED]> wrote: > >On Wed, May 16, 2007 at 03:25:23AM +0400, Manu Abraham wrote: > >> Al Viro wrote: > >> > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > >> > --- > >> > drivers/media/video/em28xx/Kconfig |2 +- > >> > drivers/media/video/ivtv/Kconfig |2 +- > >> > 2 files changed, 2 insertions(+), 2 deletions(-) > >> > > >> > diff --git a/drivers/media/video/em28xx/Kconfig > >b/drivers/media/video/em28xx/Kconfig > >> > index 3823b62..2c450bd 100644 > >> > --- a/drivers/media/video/em28xx/Kconfig > >> > +++ b/drivers/media/video/em28xx/Kconfig > >> > @@ -1,6 +1,6 @@ > >> > config VIDEO_EM28XX > >> > tristate "Empia EM2800/2820/2840 USB video capture support" > >> > -depends on VIDEO_V4L1 && I2C > >> > +depends on VIDEO_V4L1 && I2C && PCI > >> > >> Err .. why would a USB device need to be depend on PCI ? > > > >Because video-buf.c does. And VIDEO_EM28XX selects it. > > the em28xx does not rely on video-buf, this seems to be a dependency > derived from another dependency. select VIDEO_BUF select VIDEO_TUNER select VIDEO_TVEEPROM select VIDEO_IR select VIDEO_SAA711X if VIDEO_HELPER_CHIPS_AUTO select VIDEO_TVP5150 if VIDEO_HELPER_CHIPS_AUTO ---help--- This is a video4linux driver for Empia 28xx based TV cards. To compile this driver as a module, choose M here: the module will be called em28xx The first line does it. It's not a dependency, it's a direct select. And drivers/media/video/Makefile has obj-$(CONFIG_VIDEO_BUF) += video-buf.o - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 8/14] Union-mount lookup
On Tue, May 15, 2007 at 09:57:24AM +0200, Jan Engelhardt wrote:
>
> On May 14 2007 15:12, Bharata B Rao wrote:
> >
> >+struct dentry * d_lookup_single(struct dentry *parent, struct qstr *name)
> >+{
> >+struct dentry *dentry;
> >+unsigned long seq;
> >+
> >+do {
> >+seq = read_seqbegin(_lock);
> >+dentry = __d_lookup_single(parent, name);
> >+if (dentry)
> >+break;
> >+} while (read_seqretry(_lock, seq));
> >+return dentry;
> >+}
>
> Replace with tabs.
This is copied from fs/dcache.c:d_lookup() and the whitespaces came from there.
But that is not an excuse, will fix.
>
> >+lookup_union:
> >+do {
> >+struct vfsmount *mnt = find_mnt(topmost);
> >+UM_DEBUG_DCACHE("name=\"%s\", inode=%p, device=%s\n",
> >+topmost->d_name.name, topmost->d_inode,
> >+mnt->mnt_devname);
> >+mntput(mnt);
> >+} while (0);
>
> Why the extra do{}while? [elsewhere too]
Not sure, may be to get a scope to define 'mnt' here. Jan ?
>
> >+if (topmost->d_union) {
> >+union_lock_spinlock(topmost, >d_lock);
> >+}
>
> Extra {} could go [elsewhere too].
>
> >+if (last->d_overlaid
> >+&& (last->d_overlaid != dentry)) {
>
> As can these extra () [elsewhere too].
>
Sure, will fix all these.
> >+static inline struct dentry * __lookup_hash_single(struct qstr *name,
> >struct dentry *base, struct nameidata *nd)
> >+{
> >+struct dentry *dentry;
> >+struct inode *inode;
> >+int err;
> >+
> >+inode = base->d_inode;
> >+
> >+err = permission(inode, MAY_EXEC, nd);
> >+dentry = ERR_PTR(err);
> >+if (err)
> >+goto out;
> >+
> >+dentry = __lookup_hash_kern_single(name, base, nd);
> >+out:
> >+return dentry;
> >+}
>
> This looks a little big for being inline.
ok.
Regards,
Bharata.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch i2o 5/6] i2o_proc files permission
Alan Cox wrote: > On Tue, 15 May 2007 16:47:05 +0400 > Vasily Averin <[EMAIL PROTECTED]> wrote: > >> Reading from some i2o related proc files can lead to the i2o controller hang >> due >> unknown reasons. As a workaround this patch changes the permission of these >> files to root-only accessible. > > I guess you have a crap controller in this case. > > This isn't the right fix: Detect your specific buggy control and do not > register the problem /proc nodes for it at all. Alan, We have i2o on one of our testnodes: Adaptec Zero channel RAID 2010S integrated on MSI MS-9136 motherboard and I don't have access to another i2o hardware. Also I don't have any ideas how to detect buggy i2o node. As far as I understand Markus is right, and i2o hardware couldn't handle received message that on the first glance looks correctly. >From my POV it is bug in firmware and only vendor is able to fix it correctly. My patch is not a fix but workaround only -- it just do not allow to crash the node by any user in case when node admin due some reasons has loaded i2o_proc module. Thank you, Vasily Averin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 7/14] Union-mount mounting
On Tue, May 15, 2007 at 09:29:39AM +0200, Jan Engelhardt wrote:
>
> On May 14 2007 15:11, Bharata B Rao wrote:
> >
> >TODO: bind and move mounts aren't yet supported with union mounts.
>
> Are the semantics already set?
Not yet.
>
> >@@ -294,6 +294,10 @@ static struct vfsmount *clone_mnt(struct
> > if (!mnt)
> > goto alloc_failed;
> >
> >+/*
> >+ * As of now, cloning of union mounted mnt isn't permitted.
> >+ */
> >+BUG_ON(mnt->mnt_flags & MNT_UNION);
>
> One, please avoid BUG_ONs. Now I am not sure if clone_mnt is called
> as part of kthread creation when CLONE_FS is it. If so, get rid of
> this one real fast. Also see chunk "@@ -1031,.. @@ do_loopback"
> below.
Looks like not CLONE_FS but CLONE_NEWNS ends up calling clone_mnt.
>
> if(mnt->mnt_flags & MNT_UNION)
> goto return_einval;
>
> or something.
Will do this for now, but eventually we need to get this working sanely anyway.
>
> >+#ifdef CONFIG_UNION_MOUNT
> >+struct union_info *uinfo = NULL;
> >+#endif
> >
> > retval = security_sb_umount(mnt, flags);
> > if (retval)
> >@@ -685,6 +696,14 @@ static int do_umount(struct vfsmount *mn
> > }
> >
> > down_write(_sem);
> >+#ifdef CONFIG_UNION_MOUNT
> >+/*
> >+ * Grab a reference to the union_info which gets detached
> >+ * from the dentries in release_mounts().
> >+ */
> >+if (mnt->mnt_flags & MNT_UNION)
> >+uinfo = union_lock_and_get(mnt->mnt_root);
> >+#endif
> > spin_lock(_lock);
> > event++;
> >
> >@@ -699,6 +718,15 @@ static int do_umount(struct vfsmount *mn
> > security_sb_umount_busy(mnt);
> > up_write(_sem);
> > release_mounts(_list);
> >+#ifdef CONFIG_UNION_MOUNT
> >+if (uinfo) {
> >+if (atomic_read(>u_count) == 1)
> >+/* We are the last user of this union_info */
> >+union_release(uinfo);
> >+else
> >+union_put_and_unlock(uinfo);
> >+}
> >+#endif
> > return retval;
> > }
> >
>
> Is it feasible to do with with some less #if/#endif magic?:
>
Will try. We need union_info here which is available only with
CONFIG_UNION_MOUNT.
> >@@ -1031,6 +1070,15 @@ static int do_loopback(struct nameidata
> > if (err)
> > return err;
> >
> >+/*
> >+ * bind mounting to or from union mounts is not supported
> >+ */
> >+err = -EINVAL;
> >+if (nd->mnt->mnt_flags & MNT_UNION)
> >+goto out_unlocked;
> >+if (old_nd.mnt->mnt_flags & MNT_UNION)
> >+goto out_unlocked;
> >+
>
> Do the same in clone_mnt.
>
> > down_write(_sem);
> > err = -EINVAL;
> > if (IS_MNT_UNBINDABLE(old_nd.mnt))
> >@@ -1064,6 +1112,7 @@ static int do_loopback(struct nameidata
> >
> > out:
> > up_write(_sem);
> >+out_unlocked:
> > path_release(_nd);
> > return err;
> > }
>
> >+++ b/include/linux/fs.h
> >@@ -1984,6 +1984,9 @@ static inline ino_t parent_ino(struct de
> > /* kernel/fork.c */
> > extern int unshare_files(void);
> >
> >+/* fs/union.c */
> >+#include
> >+
> > /* Transaction based IO helpers */
> >
> > /*
>
> This raises a big eyebrow. If linux/fs.h can compile without the
> inclusion of linux/union.h, do not put linux/union.h in fs.h.
>
Ok, better to include union.h in the appropriate .c file which needs it.
> >+#ifdef CONFIG_UNION_MOUNT
> >+
> >+#include
> >+
> >+/* namespace stuff used at mount time */
> >+extern void attach_mnt_union(struct vfsmount *, struct nameidata *);
> >+extern void detach_mnt_union(struct vfsmount *, struct path *);
>
> You do not need that #include I suppose. Just predeclare the structs.
>
> struct path;
> struct vfsmount;
> extern void ...
>
> Saves us the "compiler slurps in so many .h files" problem.
Sure. And thanks for the review.
Regards,
Bharata.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LogFS take three
On Tue, 2007-05-15 at 21:19 +0200, Jörn Engel wrote: > On Tue, 15 May 2007 15:07:05 -0400, John Stoffel wrote: > > > > I've been semi watching this, and the only comment I really can give > > is that I hate the name. To me, logfs implies a filesystem for > > logging purposes, not for Flash hardware with wear leveling issues to > > be taken into account. > > Yeah, well, ... > > Two years ago when I started all this, I was looking for a good name. > All I could come up with sounded stupid, so I picked "LogFS" as a code > name. As soon as I find a better name, the code name should get > replaced. > > By now I still don't have anything better. All alternatives that were > proposed are just as bad - with the added disadvantage of being new and > not established yet. My hope of ever finding a better name is nearly > zero. Personally I'd just go for 'JFFS3'. After all, it has a better claim to the name than either of its predecessors :) -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce loop-AES-v3.2a file/swap crypto package
markus reichelt wrote: > * Jari Ruusu <[EMAIL PROTECTED]> wrote: > > loop-AES changes since previous release: > > - loop_twofish.c loop_serpent.c loop_blowfish.c modules included. > > They are not built by default. Add EXTRA_CIPHERS=y make parameter > > to build them. > > Just curious, will the ciphers package also be continued/available > separately as before or is it merged from now on into the loop-aes > package? Since loop-AES package now provides equivalent funtionality, it doesn't make sense to maintain second package providing redundant functionality. The merge was done because of difficulties getting versioned symbols to match between two separately compiled packages. Even if separate package were to be maintained (it won't be), it would not work well with versioned symbols. If you want to blame someone for that, then blame mainline linux kbuild guys. I forgot to clearly say following in loop-AES-v3.2a README: This command builds loop module with AES cipher integrated, as usual: make KEYSCRUB=y LINUX_SOURCE=/some/path/here This command builds loop module with AES cipher integrated, and separate twofish, serpent, and blowfish loop cipher modules: make KEYSCRUB=y EXTRA_CIPHERS=y LINUX_SOURCE=/some/path/here This command builds only twofish, serpent, and blowfish loop cipher modules. This assumes that kernel patch version of loop-AES is being used and is enabled in kernel configuration: make EXTRA_CIPHERS=y BUILD_LOOP=n LINUX_SOURCE=/some/path/here Key scrubbing, as enabled by KEYSCRUB=y make command line parameter, currently only works for AES cipher. It has no effect on twofish, serpent, and blowfish ciphers. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user
Christoph Lameter wrote: On Tue, 15 May 2007, Andrew Morton wrote: The functions above default to KM_USER0 which is also always used when zero_user_page was called except in one single case. We open code that single case to draw attention to the spot. Dunno. fwiw, we decided to _not_ embed KM_USER0 in the callee: we have had some pretty ghastly bugs in the past due to misuse of kmap slots so the idea was to shove the decision into the caller's face, make them think about what they're doing On the other hand non highmem platforms are burdened with always repeating the same KM_USER0 in every function call. Isnt it enough to know that standard functions use KM_USER0 for their operations? Couldn't that be filtered out inline? -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] (regression) AMD k6-III/450 won't boot w/2.6.22-rc1
On Tue, 15 May 2007 22:13:14 -0500 (CDT) Bob Tracy wrote: > The 2.6.22-rc1 boot panics early in amd_mcheck_init() with my k6-III/450. > It panics early enough that some of what I'm sure would be useful has > already scrolled off the screen, and there's no scrollback buffer at > that point. If more detail is needed, I'll have to transcribe what I > *can* see by hand. or use digital camera photo of screen if you have such a camera. It's a good idea to increase the screen virtual size by decreasing the font size if your video driver supports that. > Here's /proc/cpuinfo on the chance it will help someone track this down: > > processor : 0 > vendor_id : AuthenticAMD > cpu family: 5 > model : 9 > model name: AMD-K6(tm) 3D+ Processor > stepping : 1 > cpu MHz : 451.032 > cache size: 256 KB > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 1 > wp: yes > flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr > bogomips : 902.76 > clflush size : 32 --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] early printk and boot console fixups.
On 2/16/07, Gerd Hoffmann <[EMAIL PROTECTED]> wrote: The console subsystem already has an idea of a boot console, using the CON_BOOT flag. The implementation has some flaws though. The major problem is that presence of a boot console makes register_console() ignore any other console devices (unless explicitly specified on the kernel command line). This patch fixes the console selection code to *not* consider a boot console a full-featured one, so the first "normal" console registering will become the default boot console instead. This way the unregister call for the boot console in register_console() actually triggers and the handover from the boot console to the real console device works smoothly. The patch also changes the x86 early_printk code to use this. The early console is simply tagged as boot console, the disable_early_printk() call is gone as it isn't needed any more. just notice console handover patch got into mainline 5/8. for early_uart_console, I have some ideas: 1. merged that into early_serial_console in arch/x86_64/kernel/early_printk.c, and move early_printk.c to kernel/, --- make it understand earlyprintk=uart,io,0x3f8,9600n8 earlyprintk=uart,mmio,0xff5e,115200n8 in addition to vga, ttyS, serial 2. or make early_uart_console to be another CON_BOOT, and get rid of late_initcall(early_uart_console_switch). actually with late_initcall early_uart_console_switch instead of console handover, we will lose char output from serial drv init to late_initcall stage. in this case, we need to EARLY_SERIAL_CONSOLE to select early_serial_console or early_uart_console for x86_64 platform. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user
On Tue, 15 May 2007, Andrew Morton wrote:
> >The functions above default to KM_USER0 which is also always used when
> >zero_user_page was called except in one single case. We open code that
> >single case to draw attention to the spot.
> >
>
> Dunno. fwiw, we decided to _not_ embed KM_USER0 in the callee: we have had
> some pretty ghastly bugs in the past due to misuse of kmap slots so the
> idea was to shove the decision into the caller's face, make them think
> about what they're doing
On the other hand non highmem platforms are burdened with always repeating
the same KM_USER0 in every function call. Isnt it enough to know that
standard functions use KM_USER0 for their operations?
> > + flush_dcache_page(page);
> > + kunmap_atomic(kaddr, KM_USER0);
> > +}
>
> For some reason we've always done the flush_dcache_page() while holding the
> kmap. There's no reason for doing it this way and it just serves to worsen
> scheduling latency a tiny bit.
Thats easy to chanbe. Just a sec
Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user
Simplify page cache zeroing of segments of pages through 3 functions
zero_user_segments(page, start1, end1, start2, end2)
Zeros two segments of the page. It takes the position where to
start and end the zeroing which avoids length calculations.
zero_user_segment(page, start, end)
Same for a single segment.
zero_user(page, start, length)
Length variant for the case where we know the length.
We remove the zero_user_page macro. Issues:
1. Its a macro. Inline functions are preferable.
2. It has a useless parameter specifying the kmap slot.
The functions above default to KM_USER0 which is also always used when
zero_user_page was called except in one single case. We open code that
single case to draw attention to the spot.
Also move the flushing of the cache after kunmap.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
drivers/block/loop.c|2 -
fs/affs/file.c |2 -
fs/buffer.c | 48 ++-
fs/direct-io.c |4 +--
fs/ext3/inode.c |4 +--
fs/libfs.c | 11 +++---
fs/mpage.c |7 +-
fs/ntfs/aops.c | 18 +
fs/ntfs/file.c | 32 ++-
fs/reiserfs/file.c | 17
fs/reiserfs/inode.c |4 +--
include/linux/highmem.h | 49 ++--
mm/filemap_xip.c|2 -
mm/truncate.c |2 -
14 files changed, 92 insertions(+), 110 deletions(-)
Index: vps/include/linux/highmem.h
===
--- vps.orig/include/linux/highmem.h2007-05-15 18:17:51.0 -0700
+++ vps/include/linux/highmem.h 2007-05-15 21:02:13.0 -0700
@@ -92,28 +92,41 @@ static inline void clear_highpage(struct
kunmap_atomic(kaddr, KM_USER0);
}
-/*
- * Same but also flushes aliased cache contents to RAM.
- *
- * This must be a macro because KM_USER0 and friends aren't defined if
- * !CONFIG_HIGHMEM
- */
-#define zero_user_page(page, offset, size, km_type)\
- do {\
- void *kaddr;\
- \
- BUG_ON((offset) + (size) > PAGE_SIZE); \
- \
- kaddr = kmap_atomic(page, km_type); \
- memset((char *)kaddr + (offset), 0, (size));\
- flush_dcache_page(page);\
- kunmap_atomic(kaddr, (km_type));\
- } while (0)
+static inline void zero_user_segments(struct page *page,
+ unsigned start1, unsigned end1,
+ unsigned start2, unsigned end2)
+{
+ void *kaddr = kmap_atomic(page, KM_USER0);
+
+ BUG_ON(end1 > PAGE_SIZE ||
+ end2 > PAGE_SIZE);
+
+ if (end1 > start1)
+ memset(kaddr + start1, 0, end1 - start1);
+
+ if (end2 > start2)
+ memset(kaddr + start2, 0, end2 - start2);
+
+ kunmap_atomic(kaddr, KM_USER0);
+ flush_dcache_page(page);
+}
+
+static inline void zero_user_segment(struct page *page,
+ unsigned start, unsigned end)
+{
+ zero_user_segments(page, start, end, 0, 0);
+}
+
+static inline void zero_user(struct page *page,
+ unsigned start, unsigned size)
+{
+ zero_user_segments(page, start, start + size, 0, 0);
+}
static inline void __deprecated memclear_highpage_flush(struct page *page,
unsigned int offset, unsigned int size)
{
- zero_user_page(page, offset, size, KM_USER0);
+ zero_user(page, offset, size);
}
#ifndef __HAVE_ARCH_COPY_USER_HIGHPAGE
Re: [PATCH] PowerPC64 symbols start with '.'
Hi Sam, On Tue, 15 May 2007 22:39:35 +0200 Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > On Fri, May 11, 2007 at 03:45:01PM +1000, Stephen Rothwell wrote: > > which we want to skip during modpost processing. We need this to make > > some of the whitelisting work. > > I have a popwerpc64 crosscompiler and would like to reproduce > this bug. > What config shall I use to try it out. I use allmodconfig, but that doesn't really build at the moment, so I have attached a config that should build (with a recent Linus tree). > Can you please supply the exact warning message too. WARNING: mm/built-in.o - Section mismatch: reference to .init.text:.__alloc_bootmem_node from .text between '.sparse_index_alloc' (at offset 0x27df0) and '.__section_nr' The '.sparse_index_alloc' doesn't match "sparse_index_alloc" in pat4sym due to the '.' at the beginning. I have seen another one as well, but cannot reproduce it at the moment. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22-rc1 # Wed May 16 13:52:50 2007 # CONFIG_PPC64=y CONFIG_64BIT=y CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set # # Processor support # # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y CONFIG_PPC_FPU=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set # CONFIG_PPC_OF_PLATFORM_PCI is not set CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=128 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_CPUSETS=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Platform support # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_EMBEDDED6xx is not set # CONFIG_APUS is not set CONFIG_PPC_PSERIES=y CONFIG_PPC_SPLPAR=y CONFIG_EEH=y CONFIG_SCANLOG=m CONFIG_LPARCFG=y # CONFIG_PPC_ISERIES is not set # CONFIG_PPC_MPC52xx is not set # CONFIG_PPC_MPC5200 is not set # CONFIG_PPC_PMAC is not set # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_PASEMI is not set # CONFIG_PPC_CELLEB is not set # CONFIG_PPC_PS3 is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_IBM_CELL_BLADE is not set # CONFIG_PQ2ADS is not set CONFIG_PPC_NATIVE=y # CONFIG_UDBG_RTAS_CONSOLE is not set CONFIG_XICS=y CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set CONFIG_PPC_I8259=y # CONFIG_U3_DART is not set CONFIG_PPC_RTAS=y CONFIG_RTAS_ERROR_LOGGING=y CONFIG_RTAS_PROC=y CONFIG_RTAS_FLASH=m # CONFIG_MMIO_NVRAM is not set CONFIG_IBMVIO=y CONFIG_IBMEBUS=y # CONFIG_PPC_MPC106 is not set # CONFIG_PPC_970_NAP is not set # CONFIG_PPC_INDIRECT_IO is not set # CONFIG_GENERIC_IOMAP is not set # CONFIG_CPU_FREQ is not set # CONFIG_CPM2 is not set # # Kernel options # # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set
Re: [PATCH] em28xx and ivtv should depend on PCI
On 5/16/07, Al Viro <[EMAIL PROTECTED]> wrote: On Wed, May 16, 2007 at 03:25:23AM +0400, Manu Abraham wrote: > Al Viro wrote: > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > > --- > > drivers/media/video/em28xx/Kconfig |2 +- > > drivers/media/video/ivtv/Kconfig |2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/media/video/em28xx/Kconfig b/drivers/media/video/em28xx/Kconfig > > index 3823b62..2c450bd 100644 > > --- a/drivers/media/video/em28xx/Kconfig > > +++ b/drivers/media/video/em28xx/Kconfig > > @@ -1,6 +1,6 @@ > > config VIDEO_EM28XX > > tristate "Empia EM2800/2820/2840 USB video capture support" > > - depends on VIDEO_V4L1 && I2C > > + depends on VIDEO_V4L1 && I2C && PCI > > Err .. why would a USB device need to be depend on PCI ? Because video-buf.c does. And VIDEO_EM28XX selects it. the em28xx does not rely on video-buf, this seems to be a dependency derived from another dependency. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -stable] JFS: Fix race waking up jfsIO kernel thread
This patch fixes a deadlock that has been reported by three different
users on recent kernels. The problem exists on mainline kernels since
2.6.18. It is included in linux-2.6.22-rc1.
JFS: Fix race waking up jfsIO kernel thread
It's possible for a journal I/O request to be added to the log_redrive
queue and the jfsIO thread to be awakened after the thread releases
log_redrive_lock but before it sets its state to TASK_INTERRUPTIBLE.
The jfsIO thread should set the state before giving up the spinlock, so
the waking thread will really wake it.
Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]>
diff -Nurp linux-2.6.21.1/fs/jfs/jfs_logmgr.c linux/fs/jfs/jfs_logmgr.c
--- linux-2.6.21.1/fs/jfs/jfs_logmgr.c 2007-04-27 16:49:26.0 -0500
+++ linux/fs/jfs/jfs_logmgr.c 2007-05-15 22:39:31.0 -0500
@@ -2354,12 +2354,13 @@ int jfsIOWait(void *arg)
lbmStartIO(bp);
spin_lock_irq(_redrive_lock);
}
- spin_unlock_irq(_redrive_lock);
if (freezing(current)) {
+ spin_unlock_irq(_redrive_lock);
refrigerator();
} else {
set_current_state(TASK_INTERRUPTIBLE);
+ spin_unlock_irq(_redrive_lock);
schedule();
current->state = TASK_RUNNING;
}
--
David Kleikamp
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] select and dependencies in Kconfig
On Wed, 16 May 2007, Al Viro wrote: > > BTW, this kind of situation happens often enough, so how about doing > the following: teach kconfig that if FOO selects BAR and BAR depends > on , we should act as if FOO had explicit depends on . Sounds sane. I wonder if there are any non-obvious gotchas, and I worry that the indirect dependency ends up getting really confusing at times, but I don't think the notion is broken - just worrying about how to *show* this to explain what is going on when people say "why can't I select X". Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH 1/2] powerpc: unmap_vm_area becomes unmap_kernel_range
On Wed, 2007-05-16 at 13:45 +1000, Benjamin Herrenschmidt wrote: > This patch renames unmap_vm_area to unmap_kernel_range and make > it take an explicit range instead of a vm_area struct. This makes > it more versatile for code that wants to play with kernel page > tables outside of the standard vmalloc area. > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> BTW, sorry for the incorrect title, it's not powerpc specific really (though I want to use the new function from powerpc code) Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH 1/2] powerpc: unmap_vm_area becomes unmap_kernel_range
This patch renames unmap_vm_area to unmap_kernel_range and make
it take an explicit range instead of a vm_area struct. This makes
it more versatile for code that wants to play with kernel page
tables outside of the standard vmalloc area.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
Documentation/cachetlb.txt |2 +-
arch/powerpc/mm/imalloc.c|2 +-
arch/powerpc/mm/pgtable_64.c |1 -
include/linux/vmalloc.h |3 ++-
mm/vmalloc.c | 10 +-
5 files changed, 9 insertions(+), 9 deletions(-)
Index: linux-cell/Documentation/cachetlb.txt
===
--- linux-cell.orig/Documentation/cachetlb.txt 2007-05-16 12:56:18.0
+1000
+++ linux-cell/Documentation/cachetlb.txt 2007-05-16 13:10:00.0
+1000
@@ -253,7 +253,7 @@ Here are the routines, one by one:
The first of these two routines is invoked after map_vm_area()
has installed the page table entries. The second is invoked
- before unmap_vm_area() deletes the page table entries.
+ before unmap_kernel_range() deletes the page table entries.
There exists another whole class of cpu cache issues which currently
require a whole different set of interfaces to handle properly.
Index: linux-cell/arch/powerpc/mm/imalloc.c
===
--- linux-cell.orig/arch/powerpc/mm/imalloc.c 2007-05-16 13:09:52.0
+1000
+++ linux-cell/arch/powerpc/mm/imalloc.c2007-05-16 13:10:00.0
+1000
@@ -301,7 +301,7 @@ void im_free(void * addr)
for (p = ; (tmp = *p) ; p = >next) {
if (tmp->addr == addr) {
*p = tmp->next;
- unmap_vm_area(tmp);
+ unmap_kernel_range(tmp->addr, tmp->size);
kfree(tmp);
mutex_unlock(_mutex);
return;
Index: linux-cell/arch/powerpc/mm/pgtable_64.c
===
--- linux-cell.orig/arch/powerpc/mm/pgtable_64.c2007-05-16
13:09:52.0 +1000
+++ linux-cell/arch/powerpc/mm/pgtable_64.c 2007-05-16 13:10:00.0
+1000
@@ -240,7 +240,6 @@ int __ioremap_explicit(phys_addr_t pa, u
/*
* Unmap an IO region and remove it from imalloc'd list.
* Access to IO memory should be serialized by driver.
- * This code is modeled after vmalloc code - unmap_vm_area()
*
* XXX what about calls before mem_init_done (ie python_countermeasures())
*/
Index: linux-cell/include/linux/vmalloc.h
===
--- linux-cell.orig/include/linux/vmalloc.h 2007-05-16 12:56:18.0
+1000
+++ linux-cell/include/linux/vmalloc.h 2007-05-16 13:10:00.0 +1000
@@ -65,9 +65,10 @@ extern struct vm_struct *get_vm_area_nod
unsigned long flags, int node,
gfp_t gfp_mask);
extern struct vm_struct *remove_vm_area(void *addr);
+
extern int map_vm_area(struct vm_struct *area, pgprot_t prot,
struct page ***pages);
-extern void unmap_vm_area(struct vm_struct *area);
+extern void unmap_kernel_range(unsigned long addr, unsigned long size);
/*
* Internals. Dont't use..
Index: linux-cell/mm/vmalloc.c
===
--- linux-cell.orig/mm/vmalloc.c2007-05-16 12:56:18.0 +1000
+++ linux-cell/mm/vmalloc.c 2007-05-16 13:14:04.0 +1000
@@ -68,12 +68,12 @@ static inline void vunmap_pud_range(pgd_
} while (pud++, addr = next, addr != end);
}
-void unmap_vm_area(struct vm_struct *area)
+void unmap_kernel_range(unsigned long addr, unsigned long size)
{
pgd_t *pgd;
unsigned long next;
- unsigned long addr = (unsigned long) area->addr;
- unsigned long end = addr + area->size;
+ unsigned long start = addr;
+ unsigned long end = addr + size;
BUG_ON(addr >= end);
pgd = pgd_offset_k(addr);
@@ -84,7 +84,7 @@ void unmap_vm_area(struct vm_struct *are
continue;
vunmap_pud_range(pgd, addr, next);
} while (pgd++, addr = next, addr != end);
- flush_tlb_kernel_range((unsigned long) area->addr, end);
+ flush_tlb_kernel_range(start, end);
}
static int vmap_pte_range(pmd_t *pmd, unsigned long addr,
@@ -284,7 +284,7 @@ static struct vm_struct *__remove_vm_are
return NULL;
found:
- unmap_vm_area(tmp);
+ unmap_kernel_range(tmp->addr, tmp->size);
*p = tmp->next;
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH 2/2] Make map_vm_area() static
map_vm_area() is only ever used inside of mm/vmalloc.c. This makes
it static and removes the prototype.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
include/linux/vmalloc.h |2 --
mm/vmalloc.c|3 ++-
2 files changed, 2 insertions(+), 3 deletions(-)
Index: linux-cell/include/linux/vmalloc.h
===
--- linux-cell.orig/include/linux/vmalloc.h 2007-05-16 13:18:31.0
+1000
+++ linux-cell/include/linux/vmalloc.h 2007-05-16 13:18:33.0 +1000
@@ -66,8 +66,6 @@ extern struct vm_struct *get_vm_area_nod
gfp_t gfp_mask);
extern struct vm_struct *remove_vm_area(void *addr);
-extern int map_vm_area(struct vm_struct *area, pgprot_t prot,
- struct page ***pages);
extern void unmap_kernel_range(unsigned long addr, unsigned long size);
/*
Index: linux-cell/mm/vmalloc.c
===
--- linux-cell.orig/mm/vmalloc.c2007-05-16 13:18:18.0 +1000
+++ linux-cell/mm/vmalloc.c 2007-05-16 13:18:22.0 +1000
@@ -140,7 +140,8 @@ static inline int vmap_pud_range(pgd_t *
return 0;
}
-int map_vm_area(struct vm_struct *area, pgprot_t prot, struct page ***pages)
+static int map_vm_area(struct vm_struct *area, pgprot_t prot,
+ struct page ***pages)
{
pgd_t *pgd;
unsigned long next;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] select and dependencies in Kconfig
On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote: > > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll > end up with unbuildable configs. BTW, this kind of situation happens often enough, so how about doing the following: teach kconfig that if FOO selects BAR and BAR depends on , we should act as if FOO had explicit depends on . Rationale: if FOO selects BAR, BAR depends on and is false, turning FOO on will land us into unbuildable configuration (BAR turned on, dependencies of BAR are not satisfied). It really happens often enough to be very annoying. And we have fsckloads of dependencies that are there only because of such scenarios. Gets especially nasty when BAR is selected by several dozens of options and dependencies of BAR change... Implementing that is pretty simply; the only thing I'm not sure how to deal with is how to show such inherited dependencies in menuconfig et.al. Comments? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user
On Tue, 15 May 2007 20:00:18 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> Simplify page cache zeroing of segments of pages through 3 functions
>
>
> zero_user_segments(page, start1, end1, start2, end2)
>
> Zeros two segments of the page. It takes the position where to
> start and end the zeroing which avoids length calculations.
>
> zero_user_segment(page, start, end)
>
> Same for a single segment.
>
> zero_user(page, start, length)
>
> Length variant for the case where we know the length.
>
>
>
> We remove the zero_user_page macro. Issues:
>
> 1. Its a macro. Inline functions are preferable.
>
> 2. It has a useless parameter specifying the kmap slot.
>The functions above default to KM_USER0 which is also always used when
>zero_user_page was called except in one single case. We open code that
>single case to draw attention to the spot.
>
Dunno. fwiw, we decided to _not_ embed KM_USER0 in the callee: we have had
some pretty ghastly bugs in the past due to misuse of kmap slots so the
idea was to shove the decision into the caller's face, make them think
about what they're doing
> +static inline void zero_user_segments(struct page *page,
> + unsigned start1, unsigned end1,
> + unsigned start2, unsigned end2)
> +{
> + void *kaddr = kmap_atomic(page, KM_USER0);
> +
> + BUG_ON(end1 > PAGE_SIZE ||
> + end2 > PAGE_SIZE);
> +
> + if (end1 > start1)
> + memset(kaddr + start1, 0, end1 - start1);
> +
> + if (end2 > start2)
> + memset(kaddr + start2, 0, end2 - start2);
> +
> + flush_dcache_page(page);
> + kunmap_atomic(kaddr, KM_USER0);
> +}
For some reason we've always done the flush_dcache_page() while holding the
kmap. There's no reason for doing it this way and it just serves to worsen
scheduling latency a tiny bit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Oops and Panics in 2.6.21.1, 2.6.20.6 and 2.6.19.2
On Wed, 16 May 2007 11:46:00 +0900 Clemens Schwaighofer <[EMAIL PROTECTED]> wrote: > On 05/16/2007 10:53 AM, Andrew Morton wrote: > > > How frequently do you see these failures? If it's repeatable with any > > reliability > > then it'd be great if you could test a patchset for us. It's at: > > > > http://userweb.kernel.org/~akpm/cs.gz > > > > that's a single patch against 2.6.21-rc1, containing the following patches, > > which > > are from the forthcoming 2.6.21-rc1-mm1 lineup: > > (and those above are 2.6.22-rc1 of course) > > well, I tried to apply those patches and when I compile I get this error: > > CC net/ipv6/exthdrs.o > net/ipv6/exthdrs.c: In function ‘ipv6_rthdr_rcv’: > net/ipv6/exthdrs.c:390: error: ‘struct sk_buff’ has no member named ‘h’ > net/ipv6/exthdrs.c:391: error: ‘struct sk_buff’ has no member named ‘h’ > net/ipv6/exthdrs.c:391: error: ‘struct sk_buff’ has no member named ‘h’ > net/ipv6/exthdrs.c:398: error: ‘struct sk_buff’ has no member named ‘h’ > make[2]: *** [net/ipv6/exthdrs.o] Error 1 > make[1]: *** [net/ipv6] Error 2 > make: *** [net] Error 2 > > It's probably totally unrelated but sadly a showstopper for testing the > new sysfs patches, oh crap, sorry. Oh well. Please test 2.6.22-rc1-mm1 which has all the fixes and is a damn fine kernel. It's at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/ The core patch is at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/2.6.22-rc1-mm1.gz, and it's against 2.6.22-rc1. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc1-mm1
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/
- I found some time to look into some writeback problems in
fs/fs-writeback.c. The results were ugly. There are a pile of fixes here
but more work (mainly testing) needs to be done.
There's some new debug code in there which could be very expensive if
there are a lot of dirty inodes in the machine (quadratic behaviour). If
the machine seems to be affected by this, the debugging may be disabled with
echo 0 > /proc/sys/fs/inode_debug
- Added an i386 early-startup development tree, as git-newsetup.patch ("H.
Peter Anvin" <[EMAIL PROTECTED]>)
- Brought back git-sas.patch (Darrick J. Wong <[EMAIL PROTECTED]>). It got
lost quite some time ago.
Boilerplate:
- See the `hot-fixes' directory for any important updates to this patchset.
- To fetch an -mm tree using git, use (for example)
git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git
tag v2.6.16-rc2-mm1
git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1
- -mm kernel commit activity can be reviewed by subscribing to the
mm-commits mailing list.
echo "subscribe mm-commits" | mail [EMAIL PROTECTED]
- If you hit a bug in -mm and it is not obvious which patch caused it, it is
most valuable if you can perform a bisection search to identify which patch
introduced the bug. Instructions for this process are at
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
But beware that this process takes some time (around ten rebuilds and
reboots), so consider reporting the bug first and if we cannot immediately
identify the faulty patch, then perform the bisection search.
- When reporting bugs, please try to Cc: the relevant maintainer and mailing
list on any email.
- When reporting bugs in this kernel via email, please also rewrite the
email Subject: in some manner to reflect the nature of the bug. Some
developers filter by Subject: when looking for messages to read.
- Occasional snapshots of the -mm lineup are uploaded to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
the mm-commits list.
Changes since 2.6.21-mm2:
origin.patch
git-acpi.patch
git-alsa.patch
git-agpgart.patch
git-arm-master.patch
git-avr32.patch
git-cpufreq.patch
git-dvb.patch
git-gfs2-nmw.patch
git-hid.patch
git-ia64.patch
git-ieee1394.patch
git-input.patch
git-kvm.patch
git-leds.patch
git-libata-all.patch
git-md-accel.patch
git-mips.patch
git-mmc.patch
git-ubi.patch
git-battery.patch
git-ioat.patch
git-nfs.patch
git-ocfs2.patch
git-parisc.patch
git-r8169.patch
git-selinux.patch
git-pciseg.patch
git-s390.patch
git-sh.patch
git-sh64.patch
git-scsi-target.patch
git-block.patch
git-sas.patch
git-unionfs.patch
git-wireless.patch
git-ipwireless_cs.patch
git-newsetup.patch
git-newsetup-fixup.patch
git-xfs.patch
git-xtensa.patch
git-gccbug.patch
git trees
-fix-unnecesary-meminit.patch
-smaps-only-define-clear_refs-for-config_mmu.patch
-frv-miscellaneous-fixes.patch
-m68k-asm-scatterlisth-needs-linux-typesh.patch
-usb_gigaset-dont-kmalloc0.patch
-revert-sched-redundant-reschedule-when-set_user_nice-boosts-a-prio-of-a-task-from-the-expired-array.patch
-declare-compat_sys_utimensat.patch
-krealloc-fix-kerneldoc-comments.patch
-fix-spellings-of-slab-allocator-section-in-init-kconfig.patch
-frv-replace-pgd-management-via-slabs-through-quicklists.patch
-disable-slub-on-powerpc.patch
-dm-raid1-one-kmirrord-per-mirror.patch
-dm-crypt-disable-barriers.patch
-dm-crypt-fix-call-to-clone_init.patch
-dm-crypt-fix-avoid-cloned-bio-ref-after-free.patch
-dm-crypt-fix-remove-first_clone.patch
-dm-crypt-use-smaller-bvecs-in-clones.patch
-dm-crypt-add-null-iv.patch
-dm-mpath-log-device-name.patch
-dm-allow-offline-devices.patch
-dm-log-fault-detection.patch
-dm-log-report-fault-status.patch
-dm-raid1-add-handle_errors-feature-flag.patch
-dm-io-delay-dec_count.patch
-dm-io-prepare-for-new-interface.patch
-dm-io-new-interface.patch
-dm-kcopyd-update-dm-io-interface.patch
-dm-exception-store-update-dm-io-interface.patch
-dm-log-update-dm-io-interface.patch
-dm-raid1-update-dm-io-interface.patch
-dm-io-remove-old-interface.patch
-dm-bio-list-helpers.patch
-dm-delay-target.patch
-dm-raid1-fix-to-commit-pending-clear-region-requests.patch
-dm-raid1-switch-rh_in_sync-to-blocking-in-do_reads.patch
-dm-log-fix-resume-failed-log-device.patch
-iop13xx-msi-support-rev6.patch
-s390-fix-subsystem-removal-fallout.patch
-power-management-remove-some-useless-code-from-arm.patch
-scx200-use-mutex-instead-of-semaphore.patch
-drivers-hwmon-switch-to-using-input_dev-devparent.patch
-git-ia64-sa_interrupt-is-deprecated.patch
-sn-validate-smp_affinity-mask-on-intr-redirect.patch
-sn-validate-smp_affinity-mask-on-intr-redirect-fix.patch
-sn-validate-smp_affinity-mask-on-intr-redirect-fix-2.patch
-sbp2-include-fixes.patch
-ieee1394-iso-needs-schedh.patch
Re: [PATCH 1/5][TAKE3] fallocate() implementation on i86, x86_64 and powerpc
On Wed, May 16, 2007 at 01:33:59AM +0530, Amit K. Arora wrote: > This patch implements sys_fallocate() and adds support on i386, x86_64 > and powerpc platforms. Can you please pick up the ia64 support patch I posted as well? > Changelog: > - > Note: The changes below are from the initial post (dated 26th April, > 2007) and _not_ from TAKE2. The only difference from TAKE2 is the kernel > version on which this patch is based. TAKE2 was based on 2.6.21 and this > is based on 2.6.22-rc1. > > Following changes were made to the previous version: > 1) Added description before sys_fallocate() definition. > 2) Return EINVAL for len<=0 (With new draft that Ulrich pointed to, > posix_fallocate should return EINVAL for len <= 0. > 3) Return EOPNOTSUPP if mode is not one of FA_ALLOCATE or FA_DEALLOCATE > 4) Do not return ENODEV for dirs (let individual file systems decide if > they want to support preallocation to directories or not. > 5) Check for wrap through zero. > 6) Update c/mtime if fallocate() succeeds. Please don't make this always happen. c/mtime updates should be dependent on the mode being used and whether there is visible change to the file. If no userspace visible changes to the file occurred, then timestamps should not be changed. e.g. FA_ALLOCATE that changes file size requires same semantics of ftruncate() extending the file, otherwise no change in timestamps should occur. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] (regression) AMD k6-III/450 won't boot w/2.6.22-rc1
The 2.6.22-rc1 boot panics early in amd_mcheck_init() with my k6-III/450. It panics early enough that some of what I'm sure would be useful has already scrolled off the screen, and there's no scrollback buffer at that point. If more detail is needed, I'll have to transcribe what I *can* see by hand. Here's /proc/cpuinfo on the chance it will help someone track this down: processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 9 model name : AMD-K6(tm) 3D+ Processor stepping: 1 cpu MHz : 451.032 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr bogomips: 902.76 clflush size: 32 -- --- Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org [EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kdb: add rdmsr and wrmsr commands for i386
Jordan Crouse wrote:
> Can you break this up with a : between the high dword and the low dword?
> That makes it easier to parse when debugging.
Good idea, but I used "_" instead because it's what AMD uses in their
documentation and it looks better with a "0x" prefix.
> Also, would it make sense to coordinate the order of the high and low
> dwords with the order they are specified with 'wrmsr'?
Yeah, I did it as suggested by Mitch. Here's a thrid
revision of the patch with everything included:
>From 1850ca76585306e2484cf5e709434049f1df3c1f Mon Sep 17 00:00:00 2001
From: Bernardo Innocenti <[EMAIL PROTECTED]>
Date: Tue, 15 May 2007 15:29:48 -0400
Subject: [PATCH] kdb: add rdmsr and wrmsr commands for i386 (take 3)
The syntax is:
rdmsr
wrmsr
Signed-off-by: Bernardo Innocenti <[EMAIL PROTECTED]>
---
arch/i386/kdb/kdbasupport.c | 47 +++---
kdb/kdbmain.c |3 +-
2 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/arch/i386/kdb/kdbasupport.c b/arch/i386/kdb/kdbasupport.c
index 482b319..7038dfb 100644
--- a/arch/i386/kdb/kdbasupport.c
+++ b/arch/i386/kdb/kdbasupport.c
@@ -223,6 +223,46 @@ kdba_removedbreg(kdb_bp_t *bp)
kdba_putdr7(dr7);
}
+static int
+kdba_rdmsr(int argc, const char **argv)
+{
+ unsigned long addr;
+ uint32_t l, h;
+ int diag;
+
+ if (argc != 1)
+ return KDB_ARGCOUNT;
+
+ if ((diag = kdbgetularg(argv[1], )))
+ return diag;
+
+ kdb_printf("msr(0x%lx) = ", addr);
+ rdmsr(addr, l, h);
+ kdb_printf("0x%08lx_%08lx\n", h, l);
+
+ return 0;
+}
+
+static int
+kdba_wrmsr(int argc, const char **argv)
+{
+ unsigned long addr;
+ unsigned long l, h;
+ int diag;
+
+ if (argc != 3)
+ return KDB_ARGCOUNT;
+
+ if ((diag = kdbgetularg(argv[1], ))
+ || (diag = kdbgetularg(argv[2], ))
+ || (diag = kdbgetularg(argv[3], )))
+ return diag;
+
+ wrmsr(addr, l, h);
+
+ return 0;
+}
+
/*
* kdba_getregcontents
@@ -474,12 +514,11 @@ kdba_setregcontents(const char *regname,
* argument is NULL (struct pt_regs). The alternate register
* set types supported by this function:
*
- * d Debug registers
+ * d Debug registers
* c Control registers
* u User registers at most recent entry to kernel
* for the process currently selected with "pid" command.
* Following not yet implemented:
- * m Model Specific Registers (extra defines register #)
* r Memory Type Range Registers (extra defines register)
*/
@@ -546,8 +585,6 @@ kdba_dumpregs(struct pt_regs *regs,
cr[0], cr[1], cr[2], cr[3], cr[4]);
return 0;
}
- case 'm':
- break;
case 'r':
break;
default:
@@ -899,6 +936,8 @@ kdba_init(void)
{
kdb_register("pt_regs", kdba_pt_regs, "address", "Format struct
pt_regs", 0);
kdb_register("stackdepth", kdba_stackdepth, "[percentage]", "Print
processes using >= stack percentage", 0);
+ kdb_register("rdmsr", kdba_rdmsr, "", "Display Model Specific
Register", 0);
+ kdb_register("wrmsr", kdba_wrmsr, " ", "Modify Model
Specific Register", 0);
return;
}
diff --git a/kdb/kdbmain.c b/kdb/kdbmain.c
index 0b2cb91..88bf14f 100644
--- a/kdb/kdbmain.c
+++ b/kdb/kdbmain.c
@@ -2596,8 +2596,7 @@ kdb_rd(int argc, const char **argv)
* none.
* Remarks:
* Currently doesn't allow modification of control or
- * debug registers, nor does it allow modification
- * of model-specific registers (MSR).
+ * debug registers.
*/
static int
--
1.5.0.2
--
// Bernardo Innocenti
\X/ http://www.codewiz.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user
Simplify page cache zeroing of segments of pages through 3 functions
zero_user_segments(page, start1, end1, start2, end2)
Zeros two segments of the page. It takes the position where to
start and end the zeroing which avoids length calculations.
zero_user_segment(page, start, end)
Same for a single segment.
zero_user(page, start, length)
Length variant for the case where we know the length.
We remove the zero_user_page macro. Issues:
1. Its a macro. Inline functions are preferable.
2. It has a useless parameter specifying the kmap slot.
The functions above default to KM_USER0 which is also always used when
zero_user_page was called except in one single case. We open code that
single case to draw attention to the spot.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
drivers/block/loop.c|2 -
fs/affs/file.c |2 -
fs/buffer.c | 48 ++-
fs/direct-io.c |4 +--
fs/ext3/inode.c |4 +--
fs/libfs.c | 11 +++---
fs/mpage.c |7 +-
fs/ntfs/aops.c | 18 +
fs/ntfs/file.c | 32 ++-
fs/reiserfs/file.c | 17
fs/reiserfs/inode.c |4 +--
include/linux/highmem.h | 49 ++--
mm/filemap_xip.c|2 -
mm/truncate.c |2 -
14 files changed, 92 insertions(+), 110 deletions(-)
Index: vps/include/linux/highmem.h
===
--- vps.orig/include/linux/highmem.h2007-05-15 18:17:51.0 -0700
+++ vps/include/linux/highmem.h 2007-05-15 19:47:32.0 -0700
@@ -92,28 +92,41 @@ static inline void clear_highpage(struct
kunmap_atomic(kaddr, KM_USER0);
}
-/*
- * Same but also flushes aliased cache contents to RAM.
- *
- * This must be a macro because KM_USER0 and friends aren't defined if
- * !CONFIG_HIGHMEM
- */
-#define zero_user_page(page, offset, size, km_type)\
- do {\
- void *kaddr;\
- \
- BUG_ON((offset) + (size) > PAGE_SIZE); \
- \
- kaddr = kmap_atomic(page, km_type); \
- memset((char *)kaddr + (offset), 0, (size));\
- flush_dcache_page(page);\
- kunmap_atomic(kaddr, (km_type));\
- } while (0)
+static inline void zero_user_segments(struct page *page,
+ unsigned start1, unsigned end1,
+ unsigned start2, unsigned end2)
+{
+ void *kaddr = kmap_atomic(page, KM_USER0);
+
+ BUG_ON(end1 > PAGE_SIZE ||
+ end2 > PAGE_SIZE);
+
+ if (end1 > start1)
+ memset(kaddr + start1, 0, end1 - start1);
+
+ if (end2 > start2)
+ memset(kaddr + start2, 0, end2 - start2);
+
+ flush_dcache_page(page);
+ kunmap_atomic(kaddr, KM_USER0);
+}
+
+static inline void zero_user_segment(struct page *page,
+ unsigned start, unsigned end)
+{
+ zero_user_segments(page, start, end, 0, 0);
+}
+
+static inline void zero_user(struct page *page,
+ unsigned start, unsigned size)
+{
+ zero_user_segments(page, start, start + size, 0, 0);
+}
static inline void __deprecated memclear_highpage_flush(struct page *page,
unsigned int offset, unsigned int size)
{
- zero_user_page(page, offset, size, KM_USER0);
+ zero_user(page, offset, size);
}
#ifndef __HAVE_ARCH_COPY_USER_HIGHPAGE
Index: vps/fs/buffer.c
===
--- vps.orig/fs/buffer.c2007-05-15 19:04:01.0 -0700
+++ vps/fs/buffer.c 2007-05-15 19:22:37.0 -0700
@@ -1787,19 +1787,10 @@ static int __block_prepare_write(struct
set_buffer_uptodate(bh);
continue;
}
- if (block_end > to || block_start < from) {
- void *kaddr;
-
- kaddr = kmap_atomic(page, KM_USER0);
- if (block_end > to)
- memset(kaddr+to, 0,
- block_end-to);
- if (block_start < from)
- memset(kaddr+block_start,
- 0, from-block_start);
- flush_dcache_page(page);
-
Re: Asynchronous scsi scanning
> No, it does matter. Your suggestion doesn't work, because > /sys/module/scsi_mod/parameters/ belongs to the module code. To create > a new attribute there, you use the module_param() code -- and there's > no way to have code called when your parameter is changed. If I'm not misunderstanding what you're talking about, there is actually a way to have code called when a module parameter is changed: module_param_call(). - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Asynchronous scsi scanning
On Wed, May 16, 2007 at 04:57:52AM +0530, Satyam Sharma wrote: > [ I appreciate you forked the thread and gave it a better subject name, > it would be better still if you could maintain the original CC list, > thanks. ] I removed the people I didn't think needed to be on the Cc list any more, since I was changing the direction of the thread. > On 5/15/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote: > >> >It's easy to suggest a sysfs attribute. What you've failed to do is > >> >suggest the pathname of the sysfs attribute, > > /sys/module/scsi_mod/parameters/wait_for_async_scans (?) > Doesn't really matter, but perhaps who created the sysfs namespace > for scsi in /sys/module/scsi_mod/... could be the best person to suggest. No, it does matter. Your suggestion doesn't work, because /sys/module/scsi_mod/parameters/ belongs to the module code. To create a new attribute there, you use the module_param() code -- and there's no way to have code called when your parameter is changed. > >Why? You're not forced to load the module. In what way does it > >inconvenience you? Nobody's making you run 'make modules_install'. > >I often forget to myself. > > OK, I'll get really silly here myself. I don't want even that half a second > of > overhead when that module is being _built_ (during make modules), not > the overhead of copying / installing at modules_install time. You're claiming that 0.7 second (I just timed it on a 3 year old laptop) *inconveniences* you? > I apologize if I sounded impolite, and I certainly don't want to act > demanding / difficult or anything, but it's just that doing this via a sysfs > attribute (or hey, anything else!) sounds a better way to tackle this than > this module thing. IMHO, at least. This whole thing is such a tempest in a teapot. I really don't understand why you care so much. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops and Panics in 2.6.21.1, 2.6.20.6 and 2.6.19.2
On 05/16/2007 10:53 AM, Andrew Morton wrote: > How frequently do you see these failures? If it's repeatable with any > reliability > then it'd be great if you could test a patchset for us. It's at: > > http://userweb.kernel.org/~akpm/cs.gz > > that's a single patch against 2.6.21-rc1, containing the following patches, > which > are from the forthcoming 2.6.21-rc1-mm1 lineup: (and those above are 2.6.22-rc1 of course) well, I tried to apply those patches and when I compile I get this error: CC net/ipv6/exthdrs.o net/ipv6/exthdrs.c: In function ‘ipv6_rthdr_rcv’: net/ipv6/exthdrs.c:390: error: ‘struct sk_buff’ has no member named ‘h’ net/ipv6/exthdrs.c:391: error: ‘struct sk_buff’ has no member named ‘h’ net/ipv6/exthdrs.c:391: error: ‘struct sk_buff’ has no member named ‘h’ net/ipv6/exthdrs.c:398: error: ‘struct sk_buff’ has no member named ‘h’ make[2]: *** [net/ipv6/exthdrs.o] Error 1 make[1]: *** [net/ipv6] Error 2 make: *** [net] Error 2 It's probably totally unrelated but sadly a showstopper for testing the new sysfs patches, -- [ Clemens Schwaighofer -=:~ ] [ TEQUILA\ Japan IT Group] [6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jp ] signature.asc Description: OpenPGP digital signature
Re: Fwd: Re: Linux 2.6.22-rc1
On Tue, May 15, 2007 at 10:46:21AM -0700, Randy Dunlap wrote: > On Wed, 16 May 2007 00:42:08 +0900 Mattia Dongili wrote: ... > > Given the drivers/acpi/Kconfig portion > > > > if ACPI > > ... > > config ACPI_EC > > bool > > default y > > help > > ... > > > > config ACPI_POWER > > bool > > default y > > > > config ACPI_SYSTEM > > bool > > default y > > help > > ... > > ... > > endif > > > > I'd expect the 3 symbols to be all set when CONFIG_ACPI=y. > > What am I overseeing? > > I think that this is just 'make randconfig' throwing a curve ball. > ACPI depends on PM, but PM=n. In my experience, randconfig is a > good tool for testing oddball configs, but the results are not > always something that is fixable or needs to be fixed. It looks like Kconfig does the right thing on i386 though. Not the same on x84_64. -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make appletouch shut up when it has nothing to say
On Tue, May 15, 2007 at 08:34:55PM +, Soeren Sonnenburg wrote: > I was using this patch for some days now and I realized that - from time > to time - the touchpad runs amok, i.e. I more or less unable to control > the mouse when that happens. Hmm. Just seen this. I'll see if I can work around that. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LogFS take three
There are rather a lot of of FIXME comments, including scary stuff like
> +/*
> + * FIXME: this cannot be right but it does "fix" a bug of i_count
> + * dropping too low. Needs more thought.
> + */
> +atomic_inc(_dentry->d_inode->i_count);
and
> +int __logfs_write_inode(struct inode *inode)
> +{
> +/*
> + * FIXME: Those two inodes are 512 bytes in total. Not good to
> + * have on the stack. Possibly the best solution would be to bite
> + * the bullet and do another format change before release and
> + * shrink the inodes.
> + */
> +struct logfs_disk_inode old, new;
are you going to change the format? or fix this some other way?
I think a sweep through the code searching for FIXME and at least
rewriting all such comments to look like stuff that can be deferred
would be warranted ;)
- R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LogFS take three
On Wed, 16 May 2007 02:06:31 +0200, Jörn Engel wrote:
>
> > > +
> > > + if (dest) {
> > > + /* symlink */
> > > + ret = logfs_inode_write(inode, dest, destlen, 0);
> > > + } else {
> > > + /* creat/mkdir/mknod */
> > > + ret = __logfs_write_inode(inode);
> > > + }
> > > + super->s_victim_ino = 0;
> > > + if (ret) {
> > > + if (!dest)
> > > + li->li_flags |= LOGFS_IF_STILLBORN;
> > > + /* FIXME: truncate symlink */
> > > + inode->i_nlink--;
> > > + iput(inode);
> > > + goto out;
> > > + }
> > > +
> > > + if (inode->i_mode & S_IFDIR)
> > > + dir->i_nlink++;
> >
> > You have helper functions for i_nlink++, which remember to do
> > mark_inode_dirty()?
>
> I do. Looks like I should use them here and in at least one other
> place. Will recheck them all.
Actually, this code was correct. New inodes get written immediatly to
ensure catching -ENOSPC at a place where errors can get returned. After
leaving this function, the inode is not dirty. Either it has been
written or it is marked LOGFS_IF_STILLBORN never will be.
Your intuition was still good. Link() did need the change you
indicated.
Jörn
--
Joern's library part 14:
http://www.sandpile.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] powerpc: Fix Section mismatch warnings
> -Original Message- > From: Kumar Gala [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 15, 2007 10:07 PM > To: Li Yang-r58472 > Cc: Paul; [EMAIL PROTECTED]; Linux Kernel > Subject: Re: [PATCH 2/2] powerpc: Fix Section mismatch warnings > > > On May 14, 2007, at 5:59 AM, Li Yang wrote: > > > This patch fix the following Section mismatch warnings > > in powerpc code. > > > > WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: > > reference to .init.data:mv643xx_eth_pd_devs from .text between > > 'mv643xx_eth_add_pds' (at offset 0x9ed2) and 'gg2_read_config' > > WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: > > reference to .init.data:mv643xx_eth_pd_devs from .text between > > 'mv643xx_eth_add_pds' (at offset 0x9ed6) and 'gg2_read_config' > > WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: > > reference to .init.text:note_scsi_host from __ksymtab between > > '__ksymtab_note_scsi_host' (at offset 0x8) and '__ksymtab_sys_ctrler' > > > > Signed-off-by: Li Yang <[EMAIL PROTECTED]> > > --- > > arch/powerpc/platforms/chrp/pegasos_eth.c |2 +- > > arch/powerpc/platforms/powermac/setup.c |2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > Did you change anything? Nothing yet. I think it's a delay of mail system. - Leo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v12
Ingo Molnar wrote: i'm pleased to announce release -v12 of the CFS scheduler patchset. The CFS patch against v2.6.22-rc1, v2.6.21.1 or v2.6.20.10 can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ -v12 fixes the '3D bug' that caused trivial latencies in 3D games: it turns out that the problem was not resulting out of any core quality of CFS, it was caused by 3D userspace growing dependent on the current inefficiency of the vanilla scheduler's sys_sched_yield() implementation, and CFS's "make yield work well" changes broke it. Even a simple 3D app like glxgears does a sys_sched_yield() for every frame it generates (!) on certain 3D cards, which in essence punishes any scheduler that implements sys_sched_yield() in a sane manner. This interaction of CFS's yield implementation with this user-space bug could be the main reason why some testers reported SD to be handling 3D games better than CFS. (SD uses a yield implementation similar to the vanilla scheduler.) So i've added a yield workaround to -v12, which makes it work similar to how the vanilla scheduler and SD does it. (Xorg has been notified and this bug should be fixed there too. This took some time to debug because the 3D driver i'm using for testing does not use sys_sched_yield().) The workaround is activated by default so -v12 should work 'out of the box'. Mike Galbraith has fixed a bug related to nice levels - the fix should make negative nice levels more potent again. Changes since -v10: - nice level calculation fixes (Mike Galbraith) - load-balancing improvements (this should fix the SMP performance problem reported by Michael Gerdau) - remove the sched_sleep_history_max tunable. - more debugging fields. - various cleanups, fixlets and code reorganization As usual, any sort of feedback, bugreport, fix and suggestion is more than welcome, Load balancing appears to be badly broken in this version. When I started 4 hard spinners on my 2 CPU machine one ended up on one CPU and the other 3 on the other CPU and they stayed there. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops and Panics in 2.6.21.1, 2.6.20.6 and 2.6.19.2
On 05/16/2007 10:53 AM, Andrew Morton wrote: > >> I think it started with 2.6.19.2, I cannot remember I had any of those >> problems before. The box can work fine for about a week or more, or it >> looks up several times a day. I run a memtest for 10 h, but I had no errors. > > shrink_dcache_memory->...sysfs_d_iput->BUG > > BUG_ON(sd->s_dentry != dentry); > > a number of people have hit that, on and off. > > We were close to having a fix, I think, but then we decided that great > chunks of sysfs needed rewriting and I believe that we believe that this > great rewrite will fix this bug. > > But alas, it's all too late for 2.6.22. Well, there is always hope for 2.6.23 :) > How frequently do you see these failures? If it's repeatable with any > reliability > then it'd be great if you could test a patchset for us. It's at: > > http://userweb.kernel.org/~akpm/cs.gz > > that's a single patch against 2.6.21-rc1, containing the following patches, > which > are from the forthcoming 2.6.21-rc1-mm1 lineup: I get this very frequently recently. I just got hit by another PANIC which was probably the same issue. I will get this patch and try it out and see if it helps for me. -- [ Clemens Schwaighofer -=:~ ] [ TEQUILA\ Japan IT Group] [6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jp ] signature.asc Description: OpenPGP digital signature
Re: Oops and Panics in 2.6.21.1, 2.6.20.6 and 2.6.19.2
On Wed, 16 May 2007 09:24:54 +0900 Clemens Schwaighofer <[EMAIL PROTECTED]> wrote: > I have re-occurring oopses and panics in those above kernels. The error > is always the same. I have the last Kernel Panic as a picture here: > > http://dev.tequila.jp/clemens/R0010172.JPG > > The oops have the same error style like this Panic. I tried to capture > one, but right after copying it into vim, I got a Panic. So next time I > try to. > > I think it started with 2.6.19.2, I cannot remember I had any of those > problems before. The box can work fine for about a week or more, or it > looks up several times a day. I run a memtest for 10 h, but I had no errors. shrink_dcache_memory->...sysfs_d_iput->BUG BUG_ON(sd->s_dentry != dentry); a number of people have hit that, on and off. We were close to having a fix, I think, but then we decided that great chunks of sysfs needed rewriting and I believe that we believe that this great rewrite will fix this bug. But alas, it's all too late for 2.6.22. How frequently do you see these failures? If it's repeatable with any reliability then it'd be great if you could test a patchset for us. It's at: http://userweb.kernel.org/~akpm/cs.gz that's a single patch against 2.6.21-rc1, containing the following patches, which are from the forthcoming 2.6.21-rc1-mm1 lineup: origin gregkh-driver-uio gregkh-driver-uio-documentation gregkh-driver-uio-hilscher-cif-card-driver gregkh-driver-idr-fix-obscure-bug-in-allocation-path gregkh-driver-idr-separate-out-idr_mark_full gregkh-driver-ida-implement-idr-based-id-allocator gregkh-driver-sysfs-move-release_sysfs_dirent-to-dirc gregkh-driver-sysfs-allocate-inode-number-using-ida gregkh-driver-sysfs-make-sysfs_put-ignore-null-sd gregkh-driver-sysfs-fix-error-handling-in-binattr-write gregkh-driver-sysfs-flatten-cleanup-paths-in-sysfs_add_link-and-create_dir gregkh-driver-sysfs-flatten-and-fix-sysfs_rename_dir-error-handling gregkh-driver-sysfs-consolidate-sysfs_dirent-creation-functions gregkh-driver-sysfs-add-sysfs_dirent-s_parent gregkh-driver-sysfs-add-sysfs_dirent-s_name gregkh-driver-sysfs-make-sysfs_dirent-s_element-a-union gregkh-driver-sysfs-implement-kobj_sysfs_assoc_lock gregkh-driver-sysfs-reimplement-symlink-using-sysfs_dirent-tree gregkh-driver-sysfs-implement-bin_buffer gregkh-driver-sysfs-implement-sysfs_dirent-active-reference-and-immediate-disconnect gregkh-driver-sysfs-kill-attribute-file-orphaning gregkh-driver-sysfs-separate-out-sysfs_attach_dentry gregkh-driver-sysfs-reimplement-syfs_drop_dentry gregkh-driver-sysfs-kill-unnecessary-attribute-owner gregkh-driver-driver-core-make-devt_attr-and-uevent_attr-static gregkh-driver-put_device-might_sleep gregkh-driver-kobject-warn gregkh-driver-warn-when-statically-allocated-kobjects-are-used gregkh-driver-nozomi fix-gregkh-driver-sysfs-fix-error-handling-in-binattr-write Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Software raid0 will crash the file-system, when each disk is 5TB
Here is the information of the created raid0. Hope it is enough. Jeff The crashing one: md: bind md: bind md: raid0 personality registered for level 0 md0: setting max_sectors to 4096, segment boundary to 1048575 raid0: looking at sde raid0: comparing sde(5859284992) with sde(5859284992) raid0: END raid0: ==> UNIQUE raid0: 1 zones raid0: looking at sdd raid0: comparing sdd(5859284992) with sde(5859284992) raid0: EQUAL raid0: FINAL 1 zones raid0: done. raid0 : md_size is 11718569984 blocks. raid0 : conf->hash_spacing is 11718569984 blocks. raid0 : nb_zone is 2. raid0 : Allocating 8 bytes for hash. JFS: nTxBlock = 8192, nTxLock = 65536 The working one: md: bind md: bind md: bind md: bind md0: setting max_sectors to 4096, segment boundary to 1048575 raid0: looking at sdd raid0: comparing sdd(2929641472) with sdd(2929641472) raid0: END raid0: ==> UNIQUE raid0: 1 zones raid0: looking at sdg raid0: comparing sdg(2929641472) with sdd(2929641472) raid0: EQUAL raid0: looking at sdf raid0: comparing sdf(2929641472) with sdd(2929641472) raid0: EQUAL raid0: looking at sde raid0: comparing sde(2929641472) with sdd(2929641472) raid0: EQUAL raid0: FINAL 1 zones raid0: done. raid0 : md_size is 11718565888 blocks. raid0 : conf->hash_spacing is 11718565888 blocks. raid0 : nb_zone is 2. raid0 : Allocating 8 bytes for hash. JFS: nTxBlock = 8192, nTxLock = 65536 -Original Message- From: Neil Brown [mailto:[EMAIL PROTECTED] Sent: Wednesday, 16 May 2007 12:04 p.m. To: Michal Piotrowski Cc: Jeff Zheng; Ingo Molnar; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: Software raid0 will crash the file-system, when each disk is 5TB On Wednesday May 16, [EMAIL PROTECTED] wrote: > > > > Anybody have a clue? > > No... When a raid0 array is assemble, quite a lot of message get printed about number of zones and hash_spacing etc. Can you collect and post those. Both for the failing case (2*5.5T) and the working case (4*2.55T) is possible. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc1
On 5/15/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: [...] If you transform a menu with hidden options (which do NOT "depend on" the menu - they can't even) into a menuconfig (continuing not to depend on the menuconfig), the presentation fucks up (especially in ncurses-menuconfig). That is a good hint something should be taken more seriously. Sorry, I didn't follow this "hidden options" thing at all ... So, for menus with hidden options I had a number of options how to go about them: - move the hidden options before the menuconfig or after, so the presentation does not bork; - leave the menu as-is because there's just so many hidden options and a menuconfig entry is detrimental ... but the second method seems sane and safe, still :-) So what do we need? * 'configmenu' option (with 'endconfigmenu') that works the same as 'menu' and 'endmenu' (so we can have hidden options), but at the same time make the ---> and options inside it disappear when it is not selected. Currently, no other type seems to satisfy this. (Yes, and with that implicit if-endif block to make "depends on" the configmenu for those config options that are inside it automatic) * Also, some "[MENU]" kind of prefix/tag in the text of configmenu options would also be nice. Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops and Panics in 2.6.21.1, 2.6.20.6 and 2.6.19.2
On 05/16/2007 09:24 AM, Clemens Schwaighofer wrote: > The oops have the same error style like this Panic. I tried to capture > one, but right after copying it into vim, I got a Panic. So next time I > try to. I just got a oops and I could record it, the followed Kernel Panic didn't send out any Panic to my remote serial box. So I cannot give more information about that. -- [ Clemens Schwaighofer -=:~ ] [ TEQUILA\ Japan IT Group] [6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jp ] [ 5955.558356] BUG: unable to handle kernel paging request at virtual address 182b10f7 [ 5955.558362] printing eip: [ 5955.558363] 182b10f7 [ 5955.558365] *pde = [ 5955.558367] Oops: [#1] [ 5955.558369] PREEMPT [ 5955.558370] Modules linked in: eeprom i2c_viapro i2c_core pcspkr k8temp hwmon eth1394 [ 5955.558377] CPU:0 [ 5955.558378] EIP:0060:[<182b10f7>]Not tainted VLI [ 5955.558379] EFLAGS: 00010202 (2.6.21.1 #1) [ 5955.558382] EIP is at 0x182b10f7 [ 5955.558385] eax: 80c7dcc1 ebx: f786bc00 ecx: 182b10f7 edx: 0002 [ 5955.558388] esi: f7836200 edi: c2669f6c ebp: f780c88f esp: c2669f34 [ 5955.558390] ds: 007b es: 007b fs: 00d8 gs: ss: 0068 [ 5955.558393] Process pdflush (pid: 192, ti=c2669000 task=c268da90 task.ti=c2669000) [ 5955.558395] Stack: c108a454 f7836284 00158443 024a f7836200 f783623c c2669f6c c147774c [ 5955.558401]c108aa8b c2669fb8 00158925 bc01 c1053030 c1052c44 [ 5955.558406]c2669f94 01b6 024a 0025 [ 5955.558411] Call Trace: [ 5955.558413] [] sync_sb_inodes+0x74/0x280 [ 5955.558419] [] writeback_inodes+0xab/0x110 [ 5955.558423] [] pdflush+0x0/0x220 [ 5955.558426] [] wb_kupdate+0x74/0xe0 [ 5955.558430] [] pdflush+0x114/0x220 [ 5955.558433] [] wb_kupdate+0x0/0xe0 [ 5955.558436] [] kthread+0xa8/0xe0 [ 5955.558439] [] kthread+0x0/0xe0 [ 5955.558442] [] kernel_thread_helper+0x7/0x18 [ 5955.558446] === [ 5955.558447] Code: Bad EIP value. [ 5955.558449] EIP: [<182b10f7>] 0x182b10f7 SS:ESP 0068:c2669f34 [ 5955.558455] note: pdflush[192] exited with preempt_count 1 signature.asc Description: OpenPGP digital signature
Re: [git patches] IDE updates/fixes
On Wed, 16 May 2007, Bartlomiej Zolnierkiewicz wrote:
>
> * host driver fixes:
> - pdc202xx_old: mode programming rewrite (a lot of bugs fixed)
> - serverworks/sis5513: PIO mode setup fixes
> - sl82c105: MWDMA0/1 support by Sergei
> - cs5530/sc1200/sl82c105: ->speedproc support ("hdparm -X")
> * 2nd part of cleanups basing on DMA tuning rework (which was merged
> in the previous IDE update) - quite straightforward code re-factoring
> (no functionality changes) and removal of no longer needed functions.
>
> This results in simpler, more generic code and in ~300 LOCs gone.
>
> * some misc fixes/updates
Bartlomiej, this really was too late for the 2.6.22 merge window. I'm
going to pull it, since it seems borderline mostly fixes and the
refactoring should hopefully not change any functionality, but I really
don't enjoy it. Please don't do this again.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc1
On 5/15/07, Tilman Schmidt <[EMAIL PROTECTED]> wrote: [...] > I do agree that anything non-essential (even if it's just a presentation > menu that doesn't affect builds) must be default n. It's tricky for "make oldconfig" when introducing a new "menuconfig" around some previously existing "config"s, because just accepting the default for the new option then causes previously selected ones to be silently dropped. But I don't know a perfect solution for that. Perhaps we'll just have to live with it. Or perhaps a warning message along the line of "deselecting option xxx" would be in order. [...] It's actually the other way around, all those options now tucked underneath the menuconfig were previously directly visible, so selecting "y" (either explicitly or by default) makes everything work as before while "n" very conveniently skips them all. Jan did mention this in the previous thread, but as Jens said, these problems would occur only the _first_ time someone transitions from the old .config's to the new scheme. But those "default y"s for all the various "configmenu"s (let's please call them that) that got introduced in the Kconfig files would cause unnecessary annoyance to users of make oldconfig _for ever_. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [m32r] __xchg() should be always_inline
Thank you.
Acked-by: Hirokazu Takata <[EMAIL PROTECTED]>
From: Al Viro <[EMAIL PROTECTED]>
Subject: [PATCH] [m32r] __xchg() should be always_inline
Date: Tue, 15 May 2007 20:37:00 +0100
>
> it depends on elimination of unreachable branches in switch (by object
> size), so we must declare it always_inline
>
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
> ---
> include/asm-m32r/system.h |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/include/asm-m32r/system.h b/include/asm-m32r/system.h
> index b291b2f..8ee73d3 100644
> --- a/include/asm-m32r/system.h
> +++ b/include/asm-m32r/system.h
> @@ -10,6 +10,7 @@
> * Copyright (C) 2004, 2006 Hirokazu Takata
> */
>
> +#include
> #include
>
> #ifdef __KERNEL__
> @@ -154,7 +155,7 @@ extern void __xchg_called_with_bad_pointer(void);
> #define DCACHE_CLEAR(reg0, reg1, addr)
> #endif /* CONFIG_CHIP_M32700_TS1 */
>
> -static inline unsigned long
> +static __always_inline unsigned long
> __xchg(unsigned long x, volatile void * ptr, int size)
> {
> unsigned long flags;
> --
> 1.5.0-rc2.GIT
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] em28xx and ivtv should depend on PCI
On Wed, May 16, 2007 at 03:25:23AM +0400, Manu Abraham wrote: > Al Viro wrote: > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > > --- > > drivers/media/video/em28xx/Kconfig |2 +- > > drivers/media/video/ivtv/Kconfig |2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/media/video/em28xx/Kconfig > > b/drivers/media/video/em28xx/Kconfig > > index 3823b62..2c450bd 100644 > > --- a/drivers/media/video/em28xx/Kconfig > > +++ b/drivers/media/video/em28xx/Kconfig > > @@ -1,6 +1,6 @@ > > config VIDEO_EM28XX > > tristate "Empia EM2800/2820/2840 USB video capture support" > > - depends on VIDEO_V4L1 && I2C > > + depends on VIDEO_V4L1 && I2C && PCI > > Err .. why would a USB device need to be depend on PCI ? Because video-buf.c does. And VIDEO_EM28XX selects it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Kconfig powernow-k8 driver should depend on ACPI P-States driver
Hello, Below is a one line patch to possibly fix this bug: http://bugs.gentoo.org/show_bug.cgi?id=178585 http://bugzilla.kernel.org/show_bug.cgi?id=8075 If the kernel is configured with: CONFIG_X86_POWERNOW_K8=y CONFIG_X86_ACPI_CPUFREQ=m Which is currently an allowed configuration, the powernow-k8 driver on an SMP system will fail with a warning like: powernow-k8: Found 4 Dual Core AMD Opteron(tm) Processor 285 processors (version 2.00.00) powernow-k8: MP systems not supported by PSB BIOS structure powernow-k8: MP systems not supported by PSB BIOS structure powernow-k8: MP systems not supported by PSB BIOS structure powernow-k8: MP systems not supported by PSB BIOS structure Which mimics that failure you get when powernow/cool'n'quiet is disabled in the BIOS. I don't know if this config combination is valid on a uniprocessor system so this dependency may need to be enforced only if SMP in enabled. The other powernow-* drivers likely have the same requirements as -k8 but I am unable to test them. Signed-off-by: Joshua Hoblitt <[EMAIL PROTECTED]> -- Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-2.6.21.1.orig/arch/i386/kernel/cpu/cpufreq/Kconfig2007-04-27 11:49:26.0 -1000 +++ linux-2.6.21.1/arch/i386/kernel/cpu/cpufreq/Kconfig 2007-05-15 14:48:50.0 -1000 @@ -82,6 +82,7 @@ config X86_POWERNOW_K8 tristate "AMD Opteron/Athlon64 PowerNow!" select CPU_FREQ_TABLE depends on EXPERIMENTAL + depends on X86_ACPI_CPUFREQ help This adds the CPUFreq driver for mobile AMD Opteron/Athlon64 processors. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab hang on boot
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Tue, 15 May 2007 18:00:23 -0700 (PDT) > Slab allocators: Define common size limitations Thanks for doing this work Christoph, I'll test this patch out on all my sparc64 boxes, with both SLAB and SLUB, later this evening. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab hang on boot
Here is the patch. It probably does not apply cleanly against Andrew's
tree. I am waiting for the new tree in order to submit it.
Slab allocators: Define common size limitations
Currently we have a maze of configuration variables that determine
the maximum slab size. Worst of all it seems to vary between SLAB and SLUB.
So define a common maximum size for kmalloc. For conveniences sake
we use the maximum size ever supported which is 32 MB. We limit the maximum
size to a lower limit if MAX_ORDER does not allow such large allocations.
For many architectures this patch will have the effect of adding large
possible kmalloc sizes. x86_64 adds 5 new kmalloc sizes. So a small amount
of memory will be needed for these caches (contemporary SLAB has dynamically
sizeable node and cpu structure so the waste is less than in th past)
Most architectures will then be able to allocate object sizes up to MAX_ORDER.
We have had repeated breakage on IA64 because a NUMA structure grew beyond
what the slab allocators supported. This will avoid future issues.
CONFIG_LARGE_ALLOCS is no longer necessary so drop it.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
arch/blackfin/Kconfig |8
arch/frv/Kconfig |8
arch/m68knommu/Kconfig|8
arch/sparc64/Kconfig |3 ---
arch/v850/Kconfig |8
include/linux/kmalloc_sizes.h | 20 +++-
include/linux/slab.h | 15 +++
include/linux/slub_def.h | 19 ++-
mm/slab.c | 19 ++-
9 files changed, 34 insertions(+), 74 deletions(-)
Index: slub/include/linux/slab.h
===
--- slub.orig/include/linux/slab.h 2007-05-14 17:26:56.0 -0700
+++ slub/include/linux/slab.h 2007-05-15 17:57:42.0 -0700
@@ -77,6 +77,21 @@ static inline void *kmem_cache_alloc_nod
#endif
/*
+ * The largest kmalloc size supported by the slab allocators is
+ * 32 megabyte (2^25) or the maximum allocatable page order if that is
+ * less than 32 MB.
+ *
+ * WARNING: Its not easy to increase this value since the allocators have
+ * to do various tricks to work around compiler limitations in order to
+ * ensure proper constant folding.
+ */
+#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT) <= 25 ? \
+ (MAX_ORDER + PAGE_SHIFT) : 25)
+
+#define KMALLOC_MAX_SIZE (1UL << KMALLOC_SHIFT_HIGH)
+#define KMALLOC_MAX_ORDER (KMALLOC_SHIFT_HIGH - PAGE_SHIFT)
+
+/*
* Common kmalloc functions provided by all allocators
*/
void *__kmalloc(size_t, gfp_t);
Index: slub/include/linux/slub_def.h
===
--- slub.orig/include/linux/slub_def.h 2007-05-14 17:26:56.0 -0700
+++ slub/include/linux/slub_def.h 2007-05-15 17:58:10.0 -0700
@@ -58,17 +58,6 @@ struct kmem_cache {
*/
#define KMALLOC_SHIFT_LOW 3
-#ifdef CONFIG_LARGE_ALLOCS
-#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT) < 25 ? \
- MAX_ORDER + PAGE_SHIFT - 1 : 25)
-#else
-#if !defined(CONFIG_MMU) || NR_CPUS > 512 || MAX_NUMNODES > 256
-#define KMALLOC_SHIFT_HIGH 20
-#else
-#define KMALLOC_SHIFT_HIGH 18
-#endif
-#endif
-
/*
* We keep the general caches in an array of slab caches that are used for
* 2^x bytes of allocations.
@@ -79,7 +68,7 @@ extern struct kmem_cache kmalloc_caches[
* Sorry that the following has to be that ugly but some versions of GCC
* have trouble with constant propagation and loops.
*/
-static inline int kmalloc_index(int size)
+static inline int kmalloc_index(size_t size)
{
/*
* We should return 0 if size == 0 but we use the smallest object
@@ -87,7 +76,7 @@ static inline int kmalloc_index(int size
*/
WARN_ON_ONCE(size == 0);
- if (size >= (1UL << KMALLOC_SHIFT_HIGH))
+ if (size > KMALLOC_MAX_SIZE)
return -1;
if (size > 64 && size <= 96)
@@ -110,17 +99,13 @@ static inline int kmalloc_index(int size
if (size <= 64 * 1024) return 16;
if (size <= 128 * 1024) return 17;
if (size <= 256 * 1024) return 18;
-#if KMALLOC_SHIFT_HIGH > 18
if (size <= 512 * 1024) return 19;
if (size <= 1024 * 1024) return 20;
-#endif
-#if KMALLOC_SHIFT_HIGH > 20
if (size <= 2 * 1024 * 1024) return 21;
if (size <= 4 * 1024 * 1024) return 22;
if (size <= 8 * 1024 * 1024) return 23;
if (size <= 16 * 1024 * 1024) return 24;
if (size <= 32 * 1024 * 1024) return 25;
-#endif
return -1;
/*
Index: slub/include/linux/kmalloc_sizes.h
===
--- slub.orig/include/linux/kmalloc_sizes.h 2007-05-14 17:26:56.0
-0700
+++ slub/include/linux/kmalloc_sizes.h 2007-05-14 18:42:45.0 -0700
@@
[GIT PULL] sh64 updates
Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh64-2.6.git Which contains: Milind Arun Choudhary (1): sh64: ROUND_UP macro cleanup in arch/sh64/kernel/pci_sh5.c Paul Mundt (8): sh64: Wire up many new syscalls. sh64: Fixups for the irq_regs changes. sh64: dma-mapping updates. sh64: ppoll/pselect6() and restartable syscalls. sh64: Fixup sh-sci build. sh64: Update cayman defconfig. sh64: generic quicklist support. sh64: Add .gitignore entry for syscalltab. Simon Arlott (1): spelling fixes: arch/sh64/ arch/sh64/Kconfig |3 + arch/sh64/configs/cayman_defconfig | 199 ++-- arch/sh64/kernel/entry.S |4 +- arch/sh64/kernel/irq.c |4 +- arch/sh64/kernel/pci_sh5.c | 17 ++-- arch/sh64/kernel/pci_sh5.h |2 +- arch/sh64/kernel/process.c |2 +- arch/sh64/kernel/signal.c | 33 +- arch/sh64/kernel/syscalls.S| 36 ++- arch/sh64/kernel/time.c| 18 ++-- arch/sh64/lib/.gitignore |1 + arch/sh64/mach-cayman/irq.c|4 +- arch/sh64/mach-cayman/setup.c |2 +- arch/sh64/mm/fault.c |2 +- arch/sh64/mm/init.c|2 +- arch/sh64/mm/tlbmiss.c |4 +- include/asm-sh64/dma-mapping.h | 14 ++- include/asm-sh64/irq_regs.h|1 + include/asm-sh64/pgalloc.h | 100 -- include/asm-sh64/sci.h |1 + include/asm-sh64/thread_info.h |6 + include/asm-sh64/unistd.h | 43 +++- mm/Kconfig |2 +- 23 files changed, 296 insertions(+), 204 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab hang on boot
On Tue, 15 May 2007, Andrew Morton wrote: > > Try to define a compile-time array size with it smarty > > pants :-) > > confusedy pants, more like. > > > That's what we did initially and it doesn't work. > > This: > > struct kmem_cache kmalloc_caches[KMALLOC_SHIFT_HIGH + 1] __cacheline_aligned; > > is still there. This works fine. Please have a look at the RFC that gets rid of the mess. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab hang on boot
On Tue, 15 May 2007, Andrew Morton wrote: > Either that newly-added test isn't needed, or those ifdefs aren't needed? The #ifdefs dont do the proper job thus the hack for Dave. The following RFC will clean things up. http://marc.info/?l=linux-kernel=117919444827939=2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IT821x: no DMA since 2.6.21
Hi,
On Tuesday 15 May 2007, Alan Cox wrote:
> On Tue, 15 May 2007 12:53:08 +0200
> Thomas Kuther <[EMAIL PROTECTED]> wrote:
>
> > Hi!
> >
> > Since 2.6.21 I have a problem with the it821x driver on my ITE 8212
> > controller.
> > Now I saw some updates to it821x in 2.6.22-rc1 and gave that a try, but
> > the problem persists.
>
> I've had multiple reports of this. I would recommend you use the libata
> driver. IT821x hasn't changed over the past few releases so its someting
commit 0e9b4e535fec7e2a189952670937adfbe2826b63
Author: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Date: Sat May 5 22:03:50 2007 +0200
it821x: PIO mode setup fixes
...
*cough, cough* ;)
> in the core IDE code that broke it [note it might not of course be that
> the problem is in the core code..].
The real problem seems to be that IT821x "virtual" ID misses info
about supported DMA modes (while it seems to contain enabled DMA
mode info).
This would be the logical explanation why the driver broke after:
commit 71ef51cc1756d1c56b57c70e7cc27a3559c81ee6
Author: Jens Axboe <[EMAIL PROTECTED]>
Date: Fri Jul 28 09:02:17 2006 +0200
[PATCH] it821x: fix ide dma setup bug
Only enable dma for a valid speed setting.
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
commit 0a8348d08677ad77ee353f96eb8745c693a05a13
Author: Jens Axboe <[EMAIL PROTECTED]>
Date: Fri Jul 28 08:58:26 2006 +0200
[PATCH] ide: if the id fields looks screwy, disable DMA
It's the safer choice. Originally due to a bug in itx821x, but a
generally sound thing to do.
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
Bogus ide_dma_enable() usage in it821x.c + loosy check in ide_dma_verbose()
allowed the hardware to operate in DMA mode, when these bugs were fixed
DMA support broke...
> I have no plans at this point to debug the old IT821x driver due to time
> constraints, and if anyone wants to have a crack at debugging this and
> fixing it go for it.
It seems that somebody has already debugged this issue to
the aforementioned changes:
http://lkml.org/lkml/2007/1/14/110
Thomas, does the following patch against 2.6.22-rc1 fix the issue?
[ Patch is based on the above theory and Alan's work on pata_it821x.
Sorry for no real description (TODO) but it's almost 3:00 am ... ]
---
drivers/ide/ide-probe.c | 12 ++--
drivers/ide/pci/it821x.c | 36 +---
2 files changed, 27 insertions(+), 21 deletions(-)
Index: b/drivers/ide/ide-probe.c
===
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -717,7 +717,7 @@ EXPORT_SYMBOL_GPL(ide_undecoded_slave);
* This routine only knows how to look for drive units 0 and 1
* on an interface, so any setting of MAX_DRIVES > 2 won't work here.
*/
-static void probe_hwif(ide_hwif_t *hwif)
+static void probe_hwif(ide_hwif_t *hwif, void (*fixup)(ide_hwif_t *hwif))
{
unsigned int unit;
unsigned long flags;
@@ -820,6 +820,9 @@ static void probe_hwif(ide_hwif_t *hwif)
return;
}
+ if (fixup)
+ fixup(hwif);
+
for (unit = 0; unit < MAX_DRIVES; ++unit) {
ide_drive_t *drive = >drives[unit];
@@ -874,10 +877,7 @@ static int hwif_init(ide_hwif_t *hwif);
int probe_hwif_init_with_fixup(ide_hwif_t *hwif, void (*fixup)(ide_hwif_t
*hwif))
{
- probe_hwif(hwif);
-
- if (fixup)
- fixup(hwif);
+ probe_hwif(hwif, fixup);
if (!hwif_init(hwif)) {
printk(KERN_INFO "%s: failed to initialize IDE interface\n",
@@ -1404,7 +1404,7 @@ int ideprobe_init (void)
for (index = 0; index < MAX_HWIFS; ++index)
if (probe[index])
- probe_hwif(_hwifs[index]);
+ probe_hwif(_hwifs[index], NULL);
for (index = 0; index < MAX_HWIFS; ++index)
if (probe[index])
hwif_init(_hwifs[index]);
Index: b/drivers/ide/pci/it821x.c
===
--- a/drivers/ide/pci/it821x.c
+++ b/drivers/ide/pci/it821x.c
@@ -262,7 +262,7 @@ static int it821x_tunepio(ide_drive_t *d
}
if (itdev->smart)
- goto set_drive_speed;
+ return 0;
/* We prefer 66Mhz clock for PIO 0-3, don't care for PIO4 */
itdev->want[unit][1] = pio_want[set_pio];
@@ -271,7 +271,6 @@ static int it821x_tunepio(ide_drive_t *d
it821x_clock_strategy(drive);
it821x_program(drive, itdev->pio[unit]);
-set_drive_speed:
return ide_config_drive_speed(drive, XFER_PIO_0 + set_pio);
}
@@ -455,12 +454,12 @@ static int it821x_tune_chipset (ide_driv
default:
return 1;
}
+
+ return ide_config_drive_speed(drive, speed);
}
- /*
-* In smart mode the clocking is done by the host
[git patches] IDE updates/fixes
This time:
* host driver fixes:
- pdc202xx_old: mode programming rewrite (a lot of bugs fixed)
- serverworks/sis5513: PIO mode setup fixes
- sl82c105: MWDMA0/1 support by Sergei
- cs5530/sc1200/sl82c105: ->speedproc support ("hdparm -X")
* 2nd part of cleanups basing on DMA tuning rework (which was merged
in the previous IDE update) - quite straightforward code re-factoring
(no functionality changes) and removal of no longer needed functions.
This results in simpler, more generic code and in ~300 LOCs gone.
* some misc fixes/updates
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6.git/
to receive the following updates:
drivers/ide/Kconfig| 15 +---
drivers/ide/cris/ide-cris.c| 14 +---
drivers/ide/ide-dma.c | 53 +++-
drivers/ide/ide-io.c |1 +
drivers/ide/ide-lib.c | 12 ---
drivers/ide/ide.c |1 +
drivers/ide/pci/alim15x3.c | 69 ++--
drivers/ide/pci/cmd64x.c | 15 +---
drivers/ide/pci/cs5530.c | 160 +--
drivers/ide/pci/it821x.c | 21 +-
drivers/ide/pci/pdc202xx_new.c | 29 +--
drivers/ide/pci/pdc202xx_old.c | 184 +---
drivers/ide/pci/sc1200.c | 161 +--
drivers/ide/pci/scc_pata.c | 22 +-
drivers/ide/pci/serverworks.c | 77 +++--
drivers/ide/pci/siimage.c | 24 +-
drivers/ide/pci/sis5513.c | 85 ---
drivers/ide/pci/sl82c105.c | 76 ++---
include/linux/ide.h|3 -
19 files changed, 340 insertions(+), 682 deletions(-)
Alan Cox (1):
sl82c105: Switch to ref counting API
Bartlomiej Zolnierkiewicz (13):
pdc202xx_old: rewrite mode programming code (v2)
serverworks: PIO mode setup fixes
sis5513: PIO mode setup fixes
alim15x3: use ide_tune_dma()
pdc202xx_new: use ide_tune_dma()
ide: always disable DMA before tuning it
cs5530/sc1200: add ->udma_filter methods
ide: use ide_tune_dma() part #2
cs5530/sc1200: DMA support cleanup
cs5530/sc1200: add ->speedproc support
ide: remove ide_dma_enable()
ide: add missing validity checks for identify words 62 and 63
ide: remove ide_use_dma()
Jan Engelhardt (1):
Use menuconfig objects: IDE
Sergei Shtylyov (1):
sl82c105: add speedproc() method and MWDMA0/1 support
diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig
index 9040809..b1a9b81 100644
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -4,13 +4,10 @@
# Andre Hedrick <[EMAIL PROTECTED]>
#
-if BLOCK
-
-menu "ATA/ATAPI/MFM/RLL support"
- depends on HAS_IOMEM
-
-config IDE
+menuconfig IDE
tristate "ATA/ATAPI/MFM/RLL support"
+ depends on BLOCK
+ depends on HAS_IOMEM
---help---
If you say Y here, your kernel will be able to manage low cost mass
storage units such as ATA/(E)IDE and ATAPI units. The most common
@@ -1099,8 +1096,4 @@ config BLK_DEV_HD_ONLY
config BLK_DEV_HD
def_bool BLK_DEV_HD_IDE || BLK_DEV_HD_ONLY
-endif
-
-endmenu
-
-endif
+endif # IDE
diff --git a/drivers/ide/cris/ide-cris.c b/drivers/ide/cris/ide-cris.c
index c04cb25..ca0341c 100644
--- a/drivers/ide/cris/ide-cris.c
+++ b/drivers/ide/cris/ide-cris.c
@@ -1002,18 +1002,6 @@ static int cris_ide_build_dmatable (ide_drive_t *drive)
return 1; /* let the PIO routines handle this weirdness */
}
-static int cris_config_drive_for_dma (ide_drive_t *drive)
-{
- u8 speed = ide_max_dma_mode(drive);
-
- if (!speed)
- return 0;
-
- speed_cris_ide(drive, speed);
-
- return ide_dma_enable(drive);
-}
-
/*
* cris_dma_intr() is the handler for disk read/write DMA interrupts
*/
@@ -1043,7 +1031,7 @@ static ide_startstop_t cris_dma_intr (ide_drive_t *drive)
static int cris_dma_check(ide_drive_t *drive)
{
- if (ide_use_dma(drive) && cris_config_drive_for_dma(drive))
+ if (ide_tune_dma(drive))
return 0;
return -1;
diff --git a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c
index 5fe8519..b77b7d1 100644
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -670,41 +670,6 @@ int __ide_dma_good_drive (ide_drive_t *drive)
EXPORT_SYMBOL(__ide_dma_good_drive);
-int ide_use_dma(ide_drive_t *drive)
-{
- struct hd_driveid *id = drive->id;
- ide_hwif_t *hwif = drive->hwif;
-
- if ((id->capability & 1) == 0 || drive->autodma == 0)
- return 0;
-
- /* consult the list of known "bad" drives */
- if (__ide_dma_bad_drive(drive))
- return 0;
-
- /* capable of UltraDMA modes */
- if (id->field_valid & 4) {
- if (hwif->ultra_mask & id->dma_ultra)
- return 1;
- }
-
- /* capable of regular DMA modes */
- if
Re: [PATCH 2/5] Use mutex instead of semaphore in IDE driver
On Monday 14 May 2007, Matthias Kaehlcke wrote: > The IDE driver uses a semaphore as mutex. Use the mutex API instead of > the (binary) semaphore. > > Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]> applied Since I already had a patch from you with identical patch summary/description (but for ide_cfg_sem semaphore) in my tree, I almost overlooked this one. :) Please choose more descriptive patch summary/description next time. Thanks, Bart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5][TAKE3] fallocate() implementation on i86, x86_64 and powerpc
On Wed, 2007-05-16 at 01:33 +0530, Amit K. Arora wrote:
> This patch implements sys_fallocate() and adds support on i386, x86_64
> and powerpc platforms.
> @@ -1137,6 +1148,8 @@ struct inode_operations {
> ssize_t (*listxattr) (struct dentry *, char *, size_t);
> int (*removexattr) (struct dentry *, const char *);
> void (*truncate_range)(struct inode *, loff_t, loff_t);
> + long (*fallocate)(struct inode *inode, int mode, loff_t offset,
> + loff_t len);
> };
Does the return value from fallocate inode operation has to be *long*?
It's not consistent with the ext4_fallocate() define in patch 4/5,
+int ext4_fallocate(struct inode *inode, int mode, loff_t offset, loff_t
len)
thus cause compile warnings.
Mingming
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] AFS: Implement shared-writable mmap
Andrew Morton wrote: On Tue, 15 May 2007 16:52:31 +0100 David Howells <[EMAIL PROTECTED]> wrote: Implement shared-writable mmap for AFS. This blows up in -mm: fs/afs/file.c:59: error: 'filemap_nopage' undeclared here (not in a function) fs/afs/file.c:60: error: unknown field 'populate' specified in initializer fs/afs/file.c:60: error: 'filemap_populate' undeclared here (not in a function) because Nick went and renamed half the VM and deleted the other half. And page_mkwrite is next ;) I need to work out what to do with mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch mm-merge-populate-and-nopage-into-fault-fixes-nonlinear-doc-fix.patch mm-merge-populate-and-nopage-into-fault-fixes-nonlinear-fix.patch mm-merge-nopfn-into-fault.patch convert-hugetlbfs-to-use-vm_ops-fault.patch mm-remove-legacy-cruft.patch mm-debug-check-for-the-fault-vs-invalidate-race.patch mm-fix-clear_page_dirty_for_io-vs-fault-race.patch Probably merge them, I guess. Hugh had concerns, I think over small additional overhead from the lock_page()? Yes he did. It seems to only be noticable in microbenchmarks. In my opinion not enough to withhold pagecache corruption bug fixes. Still, I have some lock_page speedup work that eliminates that regression anyway. However, Hugh hasn't exactly said yes or no yet... -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab hang on boot
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 15 May 2007 17:29:57 -0700 > This: > > struct kmem_cache kmalloc_caches[KMALLOC_SHIFT_HIGH + 1] __cacheline_aligned; > > is still there. My bad, we tried using min_t() and that's what caused the problems, that's why we open-coded the macro like it is now :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab hang on boot
On Tue, 15 May 2007 17:14:47 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Tue, 15 May 2007 16:56:36 -0700 > > > On Tue, 15 May 2007 16:45:22 -0700 (PDT) > > Christoph Lameter <[EMAIL PROTECTED]> wrote: > > > > > KMALLOC_SHIFT_HIGH is not a constant but may be less than 25. > > > > It darn well better be a compile-time constant. > > Try to define a compile-time array size with it smarty > pants :-) confusedy pants, more like. > That's what we did initially and it doesn't work. This: struct kmem_cache kmalloc_caches[KMALLOC_SHIFT_HIGH + 1] __cacheline_aligned; is still there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] AFS: Implement shared-writable mmap
David Howells wrote:
Implement shared-writable mmap for AFS.
The key with which to access the file is obtained from the VMA at the point
where the PTE is made writable by the page_mkwrite() VMA op and cached in the
affected page.
If there's an outstanding write on the page made with a different key, then
page_mkwrite() will flush it before attaching a record of the new key.
Good, will be nice to get a page_mkwrite() user in the tree.
+/*
+ * notification that a previously read-only page is about to become writable
+ * - if it returns an error, the caller will deliver a bus error signal
+ *
+ * we use this to make a record of the key with which the writeback should be
+ * performed and to flush any outstanding writes made with a different key
+ *
+ * the key to be used is attached to the file pinned by the VMA
+ */
+int afs_page_mkwrite(struct vm_area_struct *vma, struct page *page)
+{
+ struct afs_vnode *vnode = AFS_FS_I(vma->vm_file->f_mapping->host);
+ struct key *key = vma->vm_file->private_data;
+ int ret;
+
+ _enter("{{%x:%u},%x},{%lx}",
+ vnode->fid.vid, vnode->fid.vnode, key_serial(key), page->index);
+
+ lock_page(page);
+ ret = afs_prepare_write(vma->vm_file, page, 0, 0);
+ unlock_page(page);
+
+ _leave(" = %d", ret);
+ return ret;
+}
By the looks of afs_prepare_write, it is going to go bang when the page
gets truncated before lock_page.
Checking page->mapping after lock_page should do the trick.
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: libata reset-seq merge broke sata_sil on sh
On Sat, May 12, 2007 at 12:49:28PM +0900, Paul Mundt wrote: > On Fri, May 11, 2007 at 11:39:20AM +0200, Tejun Heo wrote: > > Paul Mundt wrote: > > > Bumping the hardreset delay up does indeed fix it, I've had to bump it up > > > to 1200 before it started working (at 600 it still fails): > > > > > > [0.967379] scsi0 : sata_sil > > > [0.970425] scsi1 : sata_sil > > > [0.973298] ata1: SATA max UDMA/100 cmd 0xfd000280 ctl 0xfd00028a > > > bmdma 0xfd000200 irq 0 > > > [0.981331] ata2: SATA max UDMA/100 cmd 0xfd0002c0 ctl 0xfd0002ca > > > bmdma 0xfd000208 irq 0 > > > [1.299353] ata1: device not ready (errno=-19), forcing hardreset > > > [2.817893] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) > > > [2.826284] ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors > > > = 39070080 > > > [2.831052] ata1.00: ATA-5: HHD424020F7SV00, 00MLA0A5, max UDMA/100 > > > [2.837548] ata1.00: 39070080 sectors, multi 0: LBA > > > [2.842702] ata1.00: applying bridge limits > > > [2.854162] ata1.00: ata_hpa_resize 1: sectors = 39070080, hpa_sectors > > > = 39070080 > > > [2.858938] ata1.00: configured for UDMA/100 > > > [3.172602] ata2: SATA link down (SStatus 0 SControl 310) > > > [3.175736] scsi 0:0:0:0: Direct-Access ATA HHD424020F7SV00 > > > 00ML PQ: 0 ANSI: 5 > > > > > > I'm not sure if it matters or not, but this is an iVDR drive, so that > > > might also have additional implications. > > > > Don't have the flimsiest idea what an iVDR drive is but I take it that > > it's some sort of special purpose thing. :-) > > > http://www.ivdr.org > > The GoVault appears to be a similar device, in that they're both > removeable cartridges. > > > Gary, IIRC, the requirement for GoVault was 3secs, right? Paul, can you > > try to estimate the minimum required delay? Please go down by 100ms and > > report where it breaks. > > > 800ms was the lowest it would work at, 700ms still breaks. Ping? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] resolve duplicate flag no for PG_lazyfree
Andrew Morton wrote: On Mon, 14 May 2007 14:06:19 -0400 Theodore Tso <[EMAIL PROTECTED]> wrote: On Sun, May 13, 2007 at 10:46:30PM -0700, Andrew Morton wrote: otoh, the intersection between pages which are PageBooked() and pages which are PageLazyFree() should be zreo, so it'd be good to actually formalise this reuse within the ext4 patches. otoh2, PageLazyFree() could have reused PG_owner_priv_1. Rik, Ted: any thoughts? We do need to scrimp on page flags: when we finally run out, we're screwed. It makes sense to me. PG_lazyfree is currently only in -mm, right? Ah, yes, I got confused, sorry. I don't see it in my git tree. It would probably would be a good idea to make sure that we check to add some sanity checking code if it isn't there already that PG_lazyfree isn't already set when try to set PG_lazyfree (just in case there is a bug in the future which causes the should-never-happen case of trying lazy free a PageBooked page). Actually, I think the current status of lazy-freeing-of-memory-through-madv_free.patch is "might not be needed". I _think_ we've determined that 0a27a14a62921b438bb6f33772690d345a089be6 sufficiently fixed the perfomance problems we had in there? I think so far we've found that it fixes the MySQL scalability problem, yes. I couldn't see any statistically significant difference with MySQL in my tests with MADV_FREE (versus MADV_DONTNEED). ebizzy is improved a bit at low concurrency but drops off slightly at higher concurrency. But basically, I don't think we've found a good reason to use a page flag and introduce the potential performance regressions that the MADV_FREE patch has. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] prohibit rcutorture from being compiled into the kernel
Hello! There have been a number of instances where people have accidentally compiled rcutorture into the kernel (CONFIG_RCU_TORTURE_TEST=y), which has never been useful, and has often resulted in great frustration. The attached patch prohibits rcutorture from being compiled into the kernel. It may be excluded altogether or compiled as a module. People wishing to have rcutorture hammer their machine immediately upon boot are free to hand-edit lib/Kconfig.debug to remove the "depends on m" line. Thanks to Randy Dunlap for the trick that makes this work. Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]> --- Kconfig.debug |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff -urpNa -X dontdiff linux-2.6.21/lib/Kconfig.debug linux-2.6.21-rcutorturemodonly/lib/Kconfig.debug --- linux-2.6.21/lib/Kconfig.debug 2007-04-25 20:08:32.0 -0700 +++ linux-2.6.21-rcutorturemodonly/lib/Kconfig.debug2007-05-15 17:17:14.0 -0700 @@ -382,14 +382,13 @@ config FORCED_INLINING config RCU_TORTURE_TEST tristate "torture tests for RCU" depends on DEBUG_KERNEL + depends on m default n help This option provides a kernel module that runs torture tests on the RCU infrastructure. The kernel module may be built after the fact on the running kernel to be tested, if desired. - Say Y here if you want RCU torture tests to start automatically - at boot time (you probably don't). Say M if you want the RCU torture tests to build as a module. Say N if you are unsure. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
help
Hi, Anybody can give me some information about CFS Thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] AFS: Fix afs_prepare_write()
David Howells wrote:
afs_prepare_write() should not mark a page up to date if it only partially
fills it in, in expectation of the caller filling in the rest prior to calling
commit_write(). commit_write(), however, should mark the page up to date.
Acked-by: Nick Piggin <[EMAIL PROTECTED]>
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
fs/afs/write.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/afs/write.c b/fs/afs/write.c
index 28f3751..a03b92a 100644
--- a/fs/afs/write.c
+++ b/fs/afs/write.c
@@ -206,7 +206,6 @@ int afs_prepare_write(struct file *file, struct page *page,
_leave(" = %d [prep]", ret);
return ret;
}
- SetPageUptodate(page);
}
try_again:
@@ -311,8 +310,8 @@ int afs_commit_write(struct file *file, struct page *page,
spin_unlock(>writeback_lock);
}
+ SetPageUptodate(page);
set_page_dirty(page);
-
if (PageDirty(page))
_debug("dirtied");
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix/add raw1394 CONFIG_COMPAT code
Stefan Richter wrote: On 7 May, Petr Vandrovec wrote: This patch makes raw1394 in current Linux git tree (2.6.21-1570) usable to 32bit applications running on 64bit kernel (tested on i386 app using x86_64 kernel). [...] With this in place I was able to run my test app and grab some mpegs, so I believe that I got everything necessary done. If you believe I have missed some ioctl, yell at me. Petr, thanks once again for the fixes. I took the liberty to split your patch into the read(), write(), and ioctl() parts but kept your From: and Signed-off-by: and Dan's ACK. Is this OK with you? I will reply to this message with Yes, of course. Thanks a lot. [PATCH 1/3] ieee1394: raw1394: Fix read() for 32bit userland on 64bit kernel [PATCH 2/3] ieee1394: raw1394: Fix write() for 32bit userland on 64bit kernel [PATCH 3/3] ieee1394: raw1394: Add ioctl() for 32bit userland on 64bit kernel I plan to do some own testing on a x86-64 box on Thursday and will then pass it upstream ASAP. Thanks. Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to force Kconfig tristate into range n..m?
On Tue, May 15, 2007 at 04:41:30PM -0700, Randy Dunlap wrote: > On Tue, 15 May 2007 16:30:02 -0700 Paul E. McKenney wrote: > > > Hello! > > > > It would be nice to constrain RCU_TORTURE_TEST to "n" or "m", excluding > > "y", since "y" gives anti-social results that I have never seen a use > > for. So I tried adding a "range n m" to the Kconfig.debug entry for > > RCU_TORTURE_TEST. This gives me the following warning at "make xconfig" > > time: > > > >lib/Kconfig.debug:386:warning: range is only allowed for int or hex > > symbols > > > > and xconfig ignores the restriction. > > > > A few clumsy hacks get rid of the error message, but fail to cause > > xconfig to enforce the limit. > > > > Is there some other way to prohibit modules from being compiled into > > the main kernel? > > I think that > depends on m > will do what you want. That's what some ancient PCMCIA drivers > do, as well as the crypto test module. This indeed works! Thank you!!! Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab hang on boot
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 15 May 2007 16:56:36 -0700 > On Tue, 15 May 2007 16:45:22 -0700 (PDT) > Christoph Lameter <[EMAIL PROTECTED]> wrote: > > > KMALLOC_SHIFT_HIGH is not a constant but may be less than 25. > > It darn well better be a compile-time constant. Try to define a compile-time array size with it smarty pants :-) That's what we did initially and it doesn't work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LogFS take three
On Tue, 15 May 2007 19:26:17 -0400, Albert Cahalan wrote:
>
> Please don't forget the immutable bit. ("man lsattr")
> Having both, BSD-style, would be even better.
> The immutable bit is important for working around
> software bugs and "features" that damage files.
>
> I also can't find xattr support.
Not forgotten, just on a different list. Bugs beat features. :)
Jörn
--
Data expands to fill the space available for storage.
-- Parkinson's Law
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LogFS take three
On Tue, 15 May 2007 13:37:59 -0700, Andrew Morton wrote:
> > +
> > +config LOGFS_FSCK
> > + bool "Run LogFS fsck at mount time"
> > + depends on LOGFS
> > + help
> > + Run a full filesystem check on every mount. If any errors are
> > + found, mounting the filesystem will fail. This is a debug option
> > + for developers.
> > +
> > + If unsure, say N.
> > +
>
> No dependency on MTD,
Ack.
> Can this code be tested by people who don't have MTD hardware? We used to
> ahve a fake-mtd-on-a-blockdev thing, whcih was in a state of some
> disrepair. Maybe it got repaired. Or removed. I can't immediately locate
> it...
Got removed. Block2mtd is the new one and works with logfs. At least
my version of it does and I pushed my patches to David - not sure if
they made it to mainline already. Mtdram should work as well.
> It's strange and a bit regrettable that an fs would have dependency on MTD,
> really.
It is and changing this wouldn't be too hard. All device access goes
through five functions (read, write, erase, is_bad and mark_bad). As
soon as someone seriously cares I will add a struct logfs_device_ops and
have a second set of these functions for block devices.
On hard disks it shouldn't make too much sense. The filesystem will
fragment like a splinter bomb and be just as popular.
> ooh, documentation. Quick, merge it!
:)
> > +/* memtree.c */
> > +void btree_init(struct btree_head *head);
> > +void *btree_lookup(struct btree_head *head, long val);
> > +int btree_insert(struct btree_head *head, long val, void *ptr);
> > +int btree_remove(struct btree_head *head, long val);
>
> These names are too generic. If we later add a btree library: blam.
My plan was to move this code to lib/ sooner or later. If you consider
it useful in its current state, I can do it immediatly. And if someone
else merged a superior btree library I'd happily remove mine and use the
new one instead.
Opinions?
> > +/* super.c */
> > +int mtdread(struct super_block *sb, loff_t ofs, size_t len, void *buf);
> > +int mtdwrite(struct super_block *sb, loff_t ofs, size_t len, void *buf);
> > +int mtderase(struct super_block *sb, loff_t ofs, size_t len);
> > +void logfs_crash_dump(struct super_block *sb);
> > +int all_ff(void *buf, size_t len);
> > +int logfs_statfs(struct dentry *dentry, struct kstatfs *stats);
>
> Have you checked that all of this needs global scope?
Not within the last month. Will recheck.
> > +
> > +/* progs/fsck.c */
> > +#ifdef CONFIG_LOGFS_FSCK
> > +int logfs_fsck(struct super_block *sb);
> > +#else
> > +#define logfs_fsck(sb) ({ 0; })
>
> static inline int logfs_fsck(struct super_block *sb)
> {
> return 0;
> }
>
> is better: nicer to look at, has typechecking.
That's what I tried first. But the brick I carry on my neck decided to
compile and link the read logfs_fsck() unconditionally and so this
collided.
Will change the Makefile and this.
> > +static inline struct logfs_super *LOGFS_SUPER(struct super_block *sb)
> > +{
> > + return sb->s_fs_info;
> > +}
> > +
> > +static inline struct logfs_inode *LOGFS_INODE(struct inode *inode)
> > +{
> > + return container_of(inode, struct logfs_inode, vfs_inode);
> > +}
>
> Do these need to be uppercase?
No more than EXT2_SB() or EXT2_I().
Since you are the second person to ask, I sense a majority vote to
change the case.
> > +static inline pgoff_t logfs_index(u64 pos)
> > +{
> > + return pos / LOGFS_BLOCKSIZE;
> > +}
>
> If the compiler goofs up here we'll end up trying to do a 64/32 divide and
> it won't link on 32-bit machines. It would be safer to do
>
> return pos >> LOGFS_BLOCKSHIFT;
Will change.
> > +int logfs_uncompress(void *in, void *out, size_t inlen, size_t outlen)
> > +{
> > + int err, ret;
> > +
> > + ret = -EIO;
> > + mutex_lock(_mutex);
>
> A per-superblock lock and stream would be nicer.
Yes and no. The zlib workspaces weigh about 300k. On any decent SMP
machine, that hardly matters and getting the scalability is nice. For
low-end embedded, that amount of memory per filesystem can matter.
I have no clue how many people would suffer one way or another.
> > +
> > +
> > +static inline loff_t file_end(struct inode *inode)
> > +{
> > + return (i_size_read(inode) + inode->i_sb->s_blocksize - 1)
> > + >> inode->i_sb->s_blocksize_bits;
> > +}
> > +static void logfs_set_name(struct logfs_disk_dentry *dd, struct qstr *name)
> > +{
>
> The code has a strange mix of two-blank-lines-between-functions and
> no-blank-lines-between-functions. One blank line is usual.
Will change.
> > +
> > + if (dest) {
> > + /* symlink */
> > + ret = logfs_inode_write(inode, dest, destlen, 0);
> > + } else {
> > + /* creat/mkdir/mknod */
> > + ret = __logfs_write_inode(inode);
> > + }
> > + super->s_victim_ino = 0;
> > + if (ret) {
> > + if (!dest)
> > + li->li_flags |= LOGFS_IF_STILLBORN;
> > + /*
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Gleixner wrote: > Frank, > > On Tue, 2007-05-15 at 09:06 -0500, Frank Sorenson wrote: >> Hangs at boot here: >> Kernel alive >> Kernel direct mapping tables up to 1 @ 8000-d000 >> (and that's it) >> >> This is a Dell Inspiron E1705 with a Core 2 Duo 2.16GHz >> >> highres-v3 also hung at the same point, but 2.6.21-git2-v2 worked >> 2.6.22-rc1 boots without problem > > Can you please try the following three command line option addons ? > > 1: highres=off nohz=off > 2: highres=off > 3: nohz=off > > Thanks, > > tglx All 3 hang at the same point. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGSkA6aI0dwg4A47wRAuQzAKDcmAMR2e2Ce/3ytR+39XxgG76XjwCfVtbj vWlY59M1gHz2Z8dIJWRYqTk= =algX -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Software raid0 will crash the file-system, when each disk is 5TB
On Wednesday May 16, [EMAIL PROTECTED] wrote: > > > > Anybody have a clue? > > No... When a raid0 array is assemble, quite a lot of message get printed about number of zones and hash_spacing etc. Can you collect and post those. Both for the failing case (2*5.5T) and the working case (4*2.55T) is possible. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab hang on boot
On Tue, 15 May 2007 16:45:22 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Tue, 15 May 2007, Andrew Morton wrote:
>
> > On Mon, 14 May 2007 16:46:17 -0700 (PDT)
> > Christoph Lameter <[EMAIL PROTECTED]> wrote:
> >
> > > @@ -86,6 +87,9 @@ static inline int kmalloc_index(int size
> > >*/
> > > WARN_ON_ONCE(size == 0);
> > >
> > > + if (size >= (1UL << KMALLOC_SHIFT_HIGH))
> > > + return -1;
> > > +
> >
> > I don't quite understand why we did this. The subsequent logic in
> > kmalloc_index() should return -1 for this `size' anyway. If it doesn't,
> > it's bust, isn't it?
>
> KMALLOC_SHIFT_HIGH is not a constant but may be less than 25.
It darn well better be a compile-time constant.
And look:
static inline int kmalloc_index(int size)
{
/*
* We should return 0 if size == 0 but we use the smallest object
* here for SLAB legacy reasons.
*/
WARN_ON_ONCE(size == 0);
if (size > (1 << KMALLOC_SHIFT_HIGH))
return -1;
if (size > 64 && size <= 96)
return 1;
if (size > 128 && size <= 192)
return 2;
if (size <= 8) return 3;
if (size <= 16) return 4;
if (size <= 32) return 5;
if (size <= 64) return 6;
if (size <=128) return 7;
if (size <=256) return 8;
if (size <=512) return 9;
if (size <= 1024) return 10;
if (size <= 2 * 1024) return 11;
if (size <= 4 * 1024) return 12;
if (size <= 8 * 1024) return 13;
if (size <= 16 * 1024) return 14;
if (size <= 32 * 1024) return 15;
if (size <= 64 * 1024) return 16;
if (size <= 128 * 1024) return 17;
if (size <= 256 * 1024) return 18;
#if KMALLOC_SHIFT_HIGH > 18
if (size <= 512 * 1024) return 19;
if (size <= 1024 * 1024) return 20;
#endif
#if KMALLOC_SHIFT_HIGH > 20
if (size <= 2 * 1024 * 1024) return 21;
if (size <= 4 * 1024 * 1024) return 22;
if (size <= 8 * 1024 * 1024) return 23;
if (size <= 16 * 1024 * 1024) return 24;
if (size <= 32 * 1024 * 1024) return 25;
#endif
return -1;
/*
* What we really wanted to do and cannot do because of compiler issues is:
* int i;
* for (i = KMALLOC_SHIFT_LOW; i <= KMALLOC_SHIFT_HIGH; i++)
* if (size <= (1 << i))
* return i;
*/
}
Either that newly-added test isn't needed, or those ifdefs aren't needed?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5][TAKE3] fallocate system call
On Wed, 2007-05-16 at 01:07 +0530, Amit K. Arora wrote: > ToDos: > - > 1> Implementation on other architectures (other than i386, x86_64, > ppc64 and s390(x)). David Chinner has already posted a patch for ia64. Here is the 2.6.22-rc1 version of David's patch: add fallocate() on ia64 From: David Chinner <[EMAIL PROTECTED]> Subject: [PATCH] ia64 fallocate syscall Cc: "Amit K. Arora" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ia64 fallocate syscall support. Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]> --- arch/ia64/kernel/entry.S |1 + include/asm-ia64/unistd.h |3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) Index: linux-2.6.22-rc1/arch/ia64/kernel/entry.S === --- linux-2.6.22-rc1.orig/arch/ia64/kernel/entry.S 2007-05-12 18:45:56.0 -0700 +++ linux-2.6.22-rc1/arch/ia64/kernel/entry.S 2007-05-15 15:36:48.0 -0700 @@ -1585,5 +1585,6 @@ data8 sys_getcpu data8 sys_epoll_pwait // 1305 data8 sys_utimensat + data8 sys_fallocate .org sys_call_table + 8*NR_syscalls // guard against failures to increase NR_syscalls Index: linux-2.6.22-rc1/include/asm-ia64/unistd.h === --- linux-2.6.22-rc1.orig/include/asm-ia64/unistd.h 2007-05-12 18:45:56.0 -0700 +++ linux-2.6.22-rc1/include/asm-ia64/unistd.h 2007-05-15 15:37:51.0 -0700 @@ -296,6 +296,7 @@ #define __NR_getcpu1304 #define __NR_epoll_pwait 1305 #define __NR_utimensat 1306 +#define __NR_fallocate 1307 #ifdef __KERNEL__ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Asynchronous scsi scanning
On 5/16/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: >> > >semantics of it (read-only? read-write? write-only? > > Well, it _has_ to be write, don't really care if it's read-write or > write-only. I would still prefer read-write, but we can go ahead with > write-only too. It doesn't really matter, does it? just to be devils advocate... it should be a read that returns when done, Heh, yeah. We just need to trigger that scsi_complete_async_scans() after all ... might as well abuse all intuition on the user's behalf :-) and that can be polled Gaah! :-) But seriously, though, this sysfs attribute can be implemented _any which way_. Better for us if we do it the simplest way (and which taxes the user's intuition the least). Just that Matthew asked so many questions so I thought I might as well answer them :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab hang on boot
On Tue, 15 May 2007, Andrew Morton wrote: > On Mon, 14 May 2007 16:46:17 -0700 (PDT) > Christoph Lameter <[EMAIL PROTECTED]> wrote: > > > @@ -86,6 +87,9 @@ static inline int kmalloc_index(int size > > */ > > WARN_ON_ONCE(size == 0); > > > > + if (size >= (1UL << KMALLOC_SHIFT_HIGH)) > > + return -1; > > + > > I don't quite understand why we did this. The subsequent logic in > kmalloc_index() should return -1 for this `size' anyway. If it doesn't, > it's bust, isn't it? KMALLOC_SHIFT_HIGH is not a constant but may be less than 25. > Also, afaict kmalloc_slab() will totally mishandle the -1 return value and > will return a garbage kmem_cache*, via > > return _caches[index]; It does an if (index < 0) before getting to that statement. > Could you double-check it all please? It was already checked. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Define percpu smp cacheline align interface
On Mon, 7 May 2007 15:58:41 -0700
Fenghua Yu <[EMAIL PROTECTED]> wrote:
> On Fri, May 04, 2007 at 05:12:18PM -0700, Fenghua Yu wrote:
> >
> > Define percpu smp cacheline align interface
>
> This is updated patch. Per cpu cacheline aligned data section name and macro
> name are changed to have better code understanding.
>
> The patches place all of smp cacheline aligned percpu data into
> .data.percpu.shared_cacheline_aligned. Other percpu data is still in
> data.percpu section. The patches can reduce cache line access in SMP and
> reduce alignment gap waste. The patches also define PERCPU macro for
> vmlinux.lds.S for concise code.
>
> PATCH 1/2: Define percpu smp cacheline align interface
> PATCH 2/2: Call percpu smp cacheline algin interface
For some reason arm exploded.
/opt/crosstool/gcc-3.4.5-glibc-2.3.6/arm-unknown-linux-gnu/bin/arm-unknown-linux-gnu-ld:arch/arm/kernel/vmlinux.lds:327:
parse error
__con_initcall_start = .;
*(.con_initcall.init)
__con_initcall_end = .;
__security_initcall_start = .;
*(.security_initcall.init)
__security_initcall_end = .;
. = ALIGN(32);
__initramfs_start = .;
usr/built-in.o(.init.ramfs)
__initramfs_end = .;
. = ALIGN(4096); __per_cpu_start = .; .data.percpu : AT(ADDR(.data.percpu) -
0) { *(.data.percpu) *(.data.percpu.shared_cacheline_aligned) } __per_cpu_end =
.;
}
Seems I don't have the latest version any more so I'll drop it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/pasemi_mac.c | 45 +++
drivers/net/pasemi_mac.h |4 +-
drivers/net/smc911x.c |6 +---
drivers/net/ucc_geth.c | 40 +++---
drivers/net/ucc_geth_mii.c |9 ---
drivers/net/ucc_geth_mii.h | 10
6 files changed, 58 insertions(+), 56 deletions(-)
Kim Phillips (1):
ucc_geth: eliminate max-speed, change interface-type to
phy-connection-type
Olof Johansson (1):
pasemi_mac: Interrupt ack fixes
Vitaly Wool (1):
smc911x: fix compilation breakage
[EMAIL PROTECTED] (3):
pasemi_mac: Fix register defines
pasemi_mac: Terminate PCI ID list
pasemi_mac: Fix local-mac-address parsing
diff --git a/drivers/net/pasemi_mac.c b/drivers/net/pasemi_mac.c
index bc7f3de..8d38425 100644
--- a/drivers/net/pasemi_mac.c
+++ b/drivers/net/pasemi_mac.c
@@ -85,6 +85,7 @@ static int pasemi_get_mac_addr(struct pasemi_mac *mac)
{
struct pci_dev *pdev = mac->pdev;
struct device_node *dn = pci_device_to_OF_node(pdev);
+ int len;
const u8 *maddr;
u8 addr[6];
@@ -94,9 +95,17 @@ static int pasemi_get_mac_addr(struct pasemi_mac *mac)
return -ENOENT;
}
- maddr = of_get_property(dn, "local-mac-address", NULL);
+ maddr = of_get_property(dn, "local-mac-address", );
+
+ if (maddr && len == 6) {
+ memcpy(mac->mac_addr, maddr, 6);
+ return 0;
+ }
+
+ /* Some old versions of firmware mistakenly uses mac-address
+* (and as a string) instead of a byte array in local-mac-address.
+*/
- /* Fall back to mac-address for older firmware */
if (maddr == NULL)
maddr = of_get_property(dn, "mac-address", NULL);
@@ -106,6 +115,7 @@ static int pasemi_get_mac_addr(struct pasemi_mac *mac)
return -ENOENT;
}
+
if (sscanf(maddr, "%hhx:%hhx:%hhx:%hhx:%hhx:%hhx", [0],
[1], [2], [3], [4], [5]) != 6) {
dev_warn(>dev,
@@ -113,7 +123,8 @@ static int pasemi_get_mac_addr(struct pasemi_mac *mac)
return -EINVAL;
}
- memcpy(mac->mac_addr, addr, sizeof(addr));
+ memcpy(mac->mac_addr, addr, 6);
+
return 0;
}
@@ -384,17 +395,14 @@ static void pasemi_mac_replenish_rx_ring(struct
net_device *dev)
static void pasemi_mac_restart_rx_intr(struct pasemi_mac *mac)
{
- unsigned int reg, stat;
+ unsigned int reg, pcnt;
/* Re-enable packet count interrupts: finally
* ack the packet count interrupt we got in rx_intr.
*/
- pci_read_config_dword(mac->iob_pdev,
- PAS_IOB_DMA_RXCH_STAT(mac->dma_rxch),
- );
+ pcnt = *mac->rx_status & PAS_STATUS_PCNT_M;
- reg = PAS_IOB_DMA_RXCH_RESET_PCNT(stat & PAS_IOB_DMA_RXCH_STAT_CNTDEL_M)
- | PAS_IOB_DMA_RXCH_RESET_PINTC;
+ reg = PAS_IOB_DMA_RXCH_RESET_PCNT(pcnt) | PAS_IOB_DMA_RXCH_RESET_PINTC;
pci_write_config_dword(mac->iob_pdev,
PAS_IOB_DMA_RXCH_RESET(mac->dma_rxch),
@@ -403,14 +411,12 @@ static void pasemi_mac_restart_rx_intr(struct pasemi_mac
*mac)
static void pasemi_mac_restart_tx_intr(struct pasemi_mac *mac)
{
- unsigned int reg, stat;
+ unsigned int reg, pcnt;
/* Re-enable packet count interrupts */
- pci_read_config_dword(mac->iob_pdev,
- PAS_IOB_DMA_TXCH_STAT(mac->dma_txch), );
+ pcnt = *mac->tx_status & PAS_STATUS_PCNT_M;
- reg = PAS_IOB_DMA_TXCH_RESET_PCNT(stat & PAS_IOB_DMA_TXCH_STAT_CNTDEL_M)
- | PAS_IOB_DMA_TXCH_RESET_PINTC;
+ reg = PAS_IOB_DMA_TXCH_RESET_PCNT(pcnt) | PAS_IOB_DMA_TXCH_RESET_PINTC;
pci_write_config_dword(mac->iob_pdev,
PAS_IOB_DMA_TXCH_RESET(mac->dma_txch), reg);
@@ -591,21 +597,24 @@ static irqreturn_t pasemi_mac_tx_intr(int irq, void *data)
{
struct net_device *dev = data;
struct pasemi_mac *mac = netdev_priv(dev);
- unsigned int reg;
+ unsigned int reg, pcnt;
if (!(*mac->tx_status & PAS_STATUS_CAUSE_M))
return IRQ_NONE;
pasemi_mac_clean_tx(mac);
- reg = PAS_IOB_DMA_TXCH_RESET_PINTC;
+ pcnt = *mac->tx_status & PAS_STATUS_PCNT_M;
+
+ reg = PAS_IOB_DMA_TXCH_RESET_PCNT(pcnt) | PAS_IOB_DMA_TXCH_RESET_PINTC;
if (*mac->tx_status & PAS_STATUS_SOFT)
reg |= PAS_IOB_DMA_TXCH_RESET_SINTC;
if (*mac->tx_status & PAS_STATUS_ERROR)
reg |= PAS_IOB_DMA_TXCH_RESET_DINTC;
- pci_write_config_dword(mac->iob_pdev,
PAS_IOB_DMA_TXCH_RESET(mac->dma_txch),
+
Re: How to force Kconfig tristate into range n..m?
On Tue, 15 May 2007 16:30:02 -0700 Paul E. McKenney wrote: > Hello! > > It would be nice to constrain RCU_TORTURE_TEST to "n" or "m", excluding > "y", since "y" gives anti-social results that I have never seen a use > for. So I tried adding a "range n m" to the Kconfig.debug entry for > RCU_TORTURE_TEST. This gives me the following warning at "make xconfig" > time: > >lib/Kconfig.debug:386:warning: range is only allowed for int or hex symbols > > and xconfig ignores the restriction. > > A few clumsy hacks get rid of the error message, but fail to cause > xconfig to enforce the limit. > > Is there some other way to prohibit modules from being compiled into > the main kernel? I think that depends on m will do what you want. That's what some ancient PCMCIA drivers do, as well as the crypto test module. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slab hang on boot
On Mon, 14 May 2007 16:46:17 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote: > @@ -86,6 +87,9 @@ static inline int kmalloc_index(int size >*/ > WARN_ON_ONCE(size == 0); > > + if (size >= (1UL << KMALLOC_SHIFT_HIGH)) > + return -1; > + I don't quite understand why we did this. The subsequent logic in kmalloc_index() should return -1 for this `size' anyway. If it doesn't, it's bust, isn't it? Also, afaict kmalloc_slab() will totally mishandle the -1 return value and will return a garbage kmem_cache*, via return _caches[index]; Could you double-check it all please? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc][patch] slob: improvements
On Tue, May 15, 2007 at 10:17:31AM -0500, Matt Mackall wrote: > On Tue, May 15, 2007 at 10:43:05AM +0200, Nick Piggin wrote: > > This patch goes on top of my previous RCU patch, and has various > > improvements for slob I noticed while implementing said patch ;) > > > > Comments? > > I'm warming to this. Please check that the comment block at the top is > still accurate. It wasn't, fixed. > > +/* > > + * slob_block has a field 'units', which indicates size of block if +ve, > > + * or offset of next block if -ve (in SLOB_UNITs). > > + * > > + * Free blocks of size 1 unit simply contain the offset of the next block. > > + * Those with larger size contain their size in the first SLOB_UNIT of > > + * memory, and the offset of the next free block in the second SLOB_UNIT. > > + */ > > +#if PAGE_SIZE <= (32*1024) > > +typedef s16 slobidx_t; > > +#else > > +typedef s32 slobidx_t; > > +#endif > > This math is wrong because you're doing pointer math on slobidx_ts: It is misleading. But the max is 32K, because INT16_MAX is only 32767. Well actually, if you factor in the minimum alignment requirement, then it does indeed go up to 64K pages. Here is an updated version. --- Improve slob by turning the freelist into a list of pages using struct page fields, then each page has a singly linked freelist of slob blocks via a pointer in the struct page. - The first benefit is that the slob freelists can be indexed by a smaller type (2 bytes, if the PAGE_SIZE is reasonable). - Next is that freeing is much quicker because it does not have to traverse the entire freelist. Allocation can be slightly faster too, because we can skip almost-full freelist pages completely. - Slob pages are then freed immediately when they become empty, rather than having a periodic timer try to free them. This gives efficiency and memory consumption improvement. Then, we don't encode seperate size and next fields into each slob block, rather we use the sign bit to distinguish between "size" or "next". Then size 1 blocks contain a "next" offset, and others contain the "size" in the first unit and "next" in the second unit. - This allows minimum slob allocation alignment to go from 8 bytes to 2 bytes on 32-bit and 12 bytes to 2 bytes on 64-bit. In practice, it is best to align them to word size, however some architectures (eg. cris) could gain space savings from turning off this extra alignment. Then, make kmalloc use its own slob_block at the front of the allocation in order to encode allocation size, rather than rely on not overwriting slob's existing header block. - This reduces kmalloc allocation overhead similarly to alignment reductions. - Decouples kmalloc layer from the slob allocator. Then, add a page flag specific to slob pages. - This means kfree of a page aligned slob block doesn't have to traverse the bigblock list. I would get benchmarks, but my test box's network doesn't come up with slob before this patch. I think something is timing out. Anyway, things are faster after the patch. Code size goes up about 1K, however dynamic memory usage _should_ be lower even on relatively small memory systems. Signed-off-by: Nick Piggin <[EMAIL PROTECTED]> --- mm/slob.c | 271 +- 1 file changed, 200 insertions(+), 71 deletions(-) Index: linux-2.6/mm/slob.c === --- linux-2.6.orig/mm/slob.c +++ linux-2.6/mm/slob.c @@ -7,53 +7,145 @@ * * The core of SLOB is a traditional K style heap allocator, with * support for returning aligned objects. The granularity of this - * allocator is 8 bytes on x86, though it's perhaps possible to reduce - * this to 4 if it's deemed worth the effort. The slob heap is a - * singly-linked list of pages from __get_free_page, grown on demand - * and allocation from the heap is currently first-fit. + * allocator is 4 bytes on 32-bit and 8 bytes on 64-bit, though it + * could be as low as 2 if the compiler alignment requirements allow. + * + * The slob heap is a linked list of pages from __get_free_page, and + * within each page, there is a singly-linked list of free blocks (slob_t). + * The heap is grown on demand and allocation from the heap is currently + * first-fit. * * Above this is an implementation of kmalloc/kfree. Blocks returned - * from kmalloc are 8-byte aligned and prepended with a 8-byte header. + * from kmalloc are 4-byte aligned and prepended with a 4-byte header. * If kmalloc is asked for objects of PAGE_SIZE or larger, it calls * __get_free_pages directly so that it can return page-aligned blocks * and keeps a linked list of such pages and their orders. These * objects are detected in kfree() by their page alignment. * * SLAB is emulated on top of SLOB by simply calling constructors and - * destructors for every SLAB allocation. Objects are returned with - * the 8-byte alignment unless the SLAB_HWCACHE_ALIGN flag is - *
How to force Kconfig tristate into range n..m?
Hello! It would be nice to constrain RCU_TORTURE_TEST to "n" or "m", excluding "y", since "y" gives anti-social results that I have never seen a use for. So I tried adding a "range n m" to the Kconfig.debug entry for RCU_TORTURE_TEST. This gives me the following warning at "make xconfig" time: lib/Kconfig.debug:386:warning: range is only allowed for int or hex symbols and xconfig ignores the restriction. A few clumsy hacks get rid of the error message, but fail to cause xconfig to enforce the limit. Is there some other way to prohibit modules from being compiled into the main kernel? Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] lguest: host code tidyups
On Tue, 2007-05-15 at 21:47 +1000, Stephen Rothwell wrote: > On Tue, 15 May 2007 21:42:35 +1000 Stephen Rothwell <[EMAIL PROTECTED]> wrote: > > > > On Tue, 15 May 2007 11:17:07 +1000 Rusty Russell <[EMAIL PROTECTED]> wrote: > > > - on_each_cpu(adjust_pge, 0, 0, 1); > > > + on_each_cpu(adjust_pge, (void *)0, 0, 1); > > > > Sorry? What ever happened to a simple NULL? > > Oh, I guess that is an explicit (numeric) 0 (of some type) caste to > "void *" because of the prototype - rather than not passing anything? Indeed. We really want to pass a bool, but on_each_cpu uses a void *. Hence the clearest solution seemed "(void *)0" and "(void *)1" in the callers. Thanks, Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Software raid0 will crash the file-system, when each disk is 5TB
[Ingo, Neil, linux-raid added to CC] On 16/05/07, Jeff Zheng <[EMAIL PROTECTED]> wrote: Hi everyone: We are experiencing problems with software raid0, with very large disk arrays. We are using two 3ware disk array controllers, each of them is connected 8 750GB harddrives. And we build a software raid0 on top of that. The total capacity is 5.5TB+5.5TB=11TB We use jfs as the file-system, we have a test application that write data continuously to the disks. After writing 52 10GB files, jfs crashed. And we are not able to recover it, fsck doesn't recognise it anymore. We then tried xfs, same application, lasted a little longer, but gives kernel crash later. We then reconfigured the hardware array, this time we configured two disk array from each controller, than we have 4 disk arrays, each of them have 4 750GB harddrives. Than build a new software raid0 on top of that. Total capacity is still the same, but 2.75T+2.75T+2.75T+2.75T=11T. This time we managed to fill the whole 11T data without problem, we are still doing validation on all 11TB of data written to the disks. It happened on 2.6.20 and 2.6.13. So I think the problem is in the way on software raid handling very large disk, maybe a integer overflow or something. I've searched on the web, only find another guy complaining the same thing on the xfs mailing list. Anybody have a clue? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Regards, Michal -- Michal K. K. Piotrowski Kernel Monkeys (http://kernel.wikidot.com/start) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Asynchronous scsi scanning
Satyam Sharma wrote: > >semantics of it (read-only? read-write? write-only? Well, it _has_ to be write, don't really care if it's read-write or write-only. I would still prefer read-write, but we can go ahead with write-only too. It doesn't really matter, does it? just to be devils advocate... it should be a read that returns when done, and that can be polled - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Asynchronous scsi scanning
Hi,
[ I appreciate you forked the thread and gave it a better subject name,
it would be better still if you could maintain the original CC list, thanks. ]
On Tue, May 15, 2007 at 12:26:29PM +0100, Simon Arlott wrote:
I've already suggested a sysfs attribute - or something equivalent - would
be much better. It's just one function that a user might want to run multiple
times (e.g. after adding scsi devices?) - why should loading a module be used
for this?
I have to agree with Simon that ...
static int __init wait_scan_init(void)
{
scsi_complete_async_scans();
return 0;
/* BTW this could've been return scsi_complete_async_scans();
* I see scsi_complete_async_scans() never fails, but still. */
}
late_initcall(wait_scan_init);
... does _not_ deserve to be a module, and writing/building a module
for something like this (just to run a function in some kernel subsytem)
does not seem to be the proper way to solve the problem either. And
IMHO sysfs attribute for this is a good (well, better than this module
thing, at least) suggestion -- I hope you'd take it more seriously.
On 5/15/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> >It's easy to suggest a sysfs attribute. What you've failed to do is
> >suggest the pathname of the sysfs attribute,
/sys/module/scsi_mod/parameters/wait_for_async_scans (?)
Doesn't really matter, but perhaps who created the sysfs namespace
for scsi in /sys/module/scsi_mod/... could be the best person to suggest.
> >the contents of it, or the
Merely needs to be a "echo 1 > " kind of attribute. Whenever a
store_ happens on that attribute (and it's "1"), we just call
scsi_complete_async_scans(). Then we reset the attribute itself back
to 0. Also we could introduce a lock on wait_for_async_scans so that
we don't call scsi_complete_async_scans() twice if someone
accidentally "echo 1 > "'s to it more than once (if that would really be
a bad thing, otherwise it's fine). Also, something like ... if you read the
attribute _during_ the scsi_complete_async_scans(), then you get to
see "1".
All this is doesn't really matter, anyway, all that we really care about
is that: scsi_complete_async_scans() should run whenever something
gets written to this attribute, isn't it?
> >semantics of it (read-only? read-write? write-only?
Well, it _has_ to be write, don't really care if it's read-write or
write-only. I would still prefer read-write, but we can go ahead with
write-only too. It doesn't really matter, does it?
> >blocking?)
Why, blocking, of course. scsi_complete_async_scans() by definition
is supposed to _wait_ for async scans to complete, after all? And I
see a wait_for_completion() in their which means the current method
will also block during insmod time anyway, so we'll only be
maintaining present behaviour.
> >I'd *really* like to hear from distro people. What is the most
> >convenient way for you to implement "load all the scsi modules, then
> >wait until all devices are found"?
What do the distro people really care?
It's either going to be a:
modprobe scsi_wait_scan
versus a:
echo 1 > /sys/module/scsi_mod/.../wait_for_async_scans
somewhere in some script. In fact, the latter method seems simpler,
saner, better (in every which way)!
> >James and I had thought that loading
> >a new module would be the easiest way for you, but it seems inconvenient
> >for you.
It's not _inconvenient_. Just that writing/building a module for accomplishing
something like that ... is just not _right_.
> It's inconvenient for people who *don't* use it to be unable to stop the
> module being built and installed.
Yes.
Why? You're not forced to load the module. In what way does it
inconvenience you? Nobody's making you run 'make modules_install'.
I often forget to myself.
OK, I'll get really silly here myself. I don't want even that half a second of
overhead when that module is being _built_ (during make modules), not
the overhead of copying / installing at modules_install time.
I apologize if I sounded impolite, and I certainly don't want to act
demanding / difficult or anything, but it's just that doing this via a sysfs
attribute (or hey, anything else!) sounds a better way to tackle this than
this module thing. IMHO, at least.
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LogFS take three
Please don't forget the immutable bit. ("man lsattr")
Having both, BSD-style, would be even better.
The immutable bit is important for working around
software bugs and "features" that damage files.
I also can't find xattr support.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: MAINTAINERS update.
On Sun, 13 May 2007 17:26:13 -0700, H. Peter Anvin <[EMAIL PROTECTED]> wrote: >Dave Jones wrote: >> >> That previous entry of MAINTAINERS raised an eyebrow too. >> You, Eric, Andi, and Zach seem to have done more work on 'i386 BOOT CODE' >> in the last few months than I recall Riley doing, well.. since ages. >> Not to belittle whatever work he did, but perhaps his entry belongs >> more in CREDITS than MAINTAINERS. It felt a little cheeky to be >> messing with someone elses entry though. Riley? >> > >Riley passed away about a month ago (traffic accident.) The news article I mentioned in my email is dated 15 December 2004. (I don't often read the MAINTAINERS file, but happened to spot him still listed there when I had a look recently. I was in Riley's class at university.) I hope this post makes it through, I'm posting via Gmane's NNTP server. -- -- Michael "Soruk" McConnell Eridani Star System MailStripper - http://www.MailStripper.eu/ - SMTP spam filter Mail Me Anywhere - http://www.MailMeAnywhere.com/ - Mobile email - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] em28xx and ivtv should depend on PCI
Al Viro wrote: > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > --- > drivers/media/video/em28xx/Kconfig |2 +- > drivers/media/video/ivtv/Kconfig |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/video/em28xx/Kconfig > b/drivers/media/video/em28xx/Kconfig > index 3823b62..2c450bd 100644 > --- a/drivers/media/video/em28xx/Kconfig > +++ b/drivers/media/video/em28xx/Kconfig > @@ -1,6 +1,6 @@ > config VIDEO_EM28XX > tristate "Empia EM2800/2820/2840 USB video capture support" > - depends on VIDEO_V4L1 && I2C > + depends on VIDEO_V4L1 && I2C && PCI Err .. why would a USB device need to be depend on PCI ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v4
On Tuesday 15 May 2007 09:18:02 Thomas Gleixner wrote: > I've uploaded a new version of the x86_64 highres/dyntick patches: > > http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc1-x86_64-hig >hres-v4.patch > > Broken out version: > > http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc1-x86_64-hig >hres-v4.patches.tar.bz2 > > Changes since last version: > > - TSC calibration against PM-Timer Working fine now, thanks a lot. Great latencies on usleep() now too, just what I was looking for. (BTW, with HRT (but not NO_HZ), does the HZ value have any effect on usleep() (and friends) latencies?) -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
