Re: linux-next: Tree for Feb 20
On Tue, Feb 19, 2008 at 09:50:55PM -0800, Greg KH wrote: > What's the best way to constantly follow this tree? I had cloned it > a while ago, but now if I 'git pull' it wants to merge things, which > isn't right. I would guess: $ git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git $ git fetch linux-next then use the remote branch names when poking about: $ git log -p linux-next/master etc? Or is there a better way? -- 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] kill hotplug init/exit section annotations
On Thu, Jan 31, 2008 at 07:55:43PM +0200, Adrian Bunk wrote: > Who was talking about laptops? If laptops are mostly MP these days, then 'desktops' and 'servers' certainly are --- so pretty much everyone needs CPU hotplug. -- 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] kill hotplug init/exit section annotations
On Thu, Jan 31, 2008 at 07:14:36PM +0200, Adrian Bunk wrote: > > cpuhotplug is required for suspend/resume. > > Not on UP computers. those are less and less common now, most modern laptops are dual core -- 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] xfs: revert to double-buffering readdir
On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote: > Looks like the readdir is in the bowels of the btree code when > filldir gets called here, there are probably locks on several > buffers in the btree at this point. This will only show up for large > directories I bet. I see it for fairly small directories. Larger than what you can stuff into an inode but less than a block (I'm not checking but fairly sure that's the case). > Just rambling, not a single line of code was consulted in writing > this message. Can you explain why the offset is capped and treated in an 'odd way' at all? + curr_offset = filp->f_pos; + if (curr_offset == 0x7fff) + offset = 0x; + else + offset = filp->f_pos; and later the offset to filldir is masked. Is that some restriction in filldir? - 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] xfs: revert to double-buffering readdir
On Sun, Nov 25, 2007 at 04:30:14PM +, Christoph Hellwig wrote: > The current readdir implementation deadlocks on a btree buffers > locks because nfsd calls back into ->lookup from the filldir > callback. The only short-term fix for this is to revert to the old > inefficient double-buffering scheme. This seems to work really well here. > This patch does exactly that and reverts xfs_file_readdir to what's > basically the 2.6.23 version minus the uio and vnops junk. This should probably be submitted for inclusion stable-2.6.24. Perhaps a version with the #if 0 [...] stuff dropped? (I'm happy to send a patch for that if you prefer). - 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: 2.6.24-rc2 XFS nfsd hang
On Fri, Nov 16, 2007 at 09:19:32AM -0500, Trond Myklebust wrote: > Very funny, but disabling XFS on the client won't help. Oops, I meant it for NFSD... and I'm somewhat serious. I'm not saying it's a good long term solution, but a potentially safer short-term workaround. - 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: 2.6.24-rc2 XFS nfsd hang
On Fri, Nov 16, 2007 at 10:17:17AM +0100, Christian Kujau wrote: > OK, I'll try this. I hope this can be fixed somehow before 2.6.24... Well, one simple nasty idea would be something like: diff --git a/fs/Kconfig b/fs/Kconfig index 429a002..da231fd 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -1604,7 +1604,7 @@ config NFS_FS config NFS_V3 bool "Provide NFSv3 client support" - depends on NFS_FS + depends on NFS_FS && !XFS help Say Y here if you want your NFS client to be able to speak version 3 of the NFS protocol. So people who are likely to be affect just side-step the issue until it's resolved. - 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: 2.6.24-rc2 XFS nfsd hang / smbd too
On Thu, Nov 15, 2007 at 08:51:36AM +0100, Christian Kujau wrote: > [] mutex_lock_nested+0xcc/0x2c0 > [] do_lookup+0xa4/0x190 > [] __link_path_walk+0x749/0xd10 > [] link_path_walk+0x44/0xc0 > [] path_walk+0x18/0x20 > [] do_path_lookup+0x78/0x1c0 > [] __user_walk_fd+0x38/0x60 > [] vfs_stat_fd+0x21/0x50 > [] vfs_stat+0x11/0x20 > [] sys_stat64+0x14/0x30 > [] sysenter_past_esp+0x5f/0xa5 nfsd already wedged up and holds a lock, this is expected. I'm not sure what you're doing here, but a viable work-around for now might be to use nfsv2 mounts, something like mount -o vers=2 ... or to keep v3 and disable readdirplus doing something like: mount -o vers=3,nordirplus ... The later I didn't test but was suggested on #linuxfs. - 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.24-rc2 XFS nfsd hang --- filldir change responsible?
On Tue, Nov 13, 2007 at 11:04:00PM -0800, Chris Wedgwood wrote: > With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always) > see a hang when accessing some NFS exported XFS filesystems. Local > access to these filesystems ahead of time works without problems. > > This does not occur with 2.6.23.1. The filesystem does not appear > to be corrupt. After some bisection pain (sg broken in the middle and XFS not compiling in other places) the regression seems to be: commit 051e7cd44ab8f0f7c2958371485b4a1ff64a8d1b Author: Christoph Hellwig <[EMAIL PROTECTED]> Date: Tue Aug 28 13:58:24 2007 +1000 [XFS] use filldir internally There have been a lot of changes since this so reverting it and retesting as-is won't work. I'll have to see what I can come up with after some sleep. I'm not building/testing with dmapi --- perhaps that makes a difference here? I would think it would have broken with xfsqa but the number of bug reports seems small so far. - 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.24-rc2 XFS nfsd hang
With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always) see a hang when accessing some NFS exported XFS filesystems. Local access to these filesystems ahead of time works without problems. This does not occur with 2.6.23.1. The filesystem does not appear to be corrupt. The call chain for the wedged process is: [ 1462.911256] nfsd D 80547840 4760 2966 2 [ 1462.911283] 81010414d4d0 0046 81010414d610 [ 1462.911322] 810104cbc6e0 81010414d480 80746dc0 80746dc0 [ 1462.911360] 80744020 80746dc0 81010129c140 8101000ad100 [ 1462.911391] Call Trace: [ 1462.911417] [] __down+0xe9/0x101 [ 1462.911437] [] default_wake_function+0x0/0xe [ 1462.911458] [] __down_failed+0x35/0x3a [ 1462.911480] [] _xfs_buf_find+0x84/0x24d [ 1462.911501] [] _xfs_buf_find+0x193/0x24d [ 1462.911522] [] xfs_buf_lock+0x43/0x45 [ 1462.911543] [] _xfs_buf_find+0x1ba/0x24d [ 1462.911564] [] xfs_buf_get_flags+0x5a/0x14b [ 1462.911586] [] xfs_buf_read_flags+0x12/0x86 [ 1462.911607] [] xfs_trans_read_buf+0x4c/0x2cf [ 1462.911629] [] xfs_da_do_buf+0x41b/0x65b [ 1462.911652] [] xfs_da_read_buf+0x24/0x29 [ 1462.911673] [] xfs_dir2_block_lookup_int+0x4d/0x1ab [ 1462.911694] [] xfs_dir2_block_lookup_int+0x4d/0x1ab [ 1462.911717] [] xfs_dir2_block_lookup+0x15/0x8e [ 1462.911738] [] xfs_dir_lookup+0xd2/0x12c [ 1462.911761] [] submit_bio+0x10d/0x114 [ 1462.911781] [] xfs_dir_lookup_int+0x2c/0xc5 [ 1462.911802] [] lockdep_init_map+0x90/0x495 [ 1462.911823] [] xfs_lookup+0x44/0x6f [ 1462.911843] [] xfs_vn_lookup+0x29/0x60 [ 1462.915246] [] __lookup_hash+0xe5/0x109 [ 1462.915267] [] lookup_one_len+0x41/0x4e [ 1462.915289] [] compose_entry_fh+0xc1/0x117 [ 1462.915311] [] encode_entry+0x17c/0x38b [ 1462.915333] [] find_or_create_page+0x3f/0xc9 [ 1462.915355] [] _xfs_buf_lookup_pages+0x2c1/0x2f6 [ 1462.915377] [] _spin_unlock+0x1f/0x49 [ 1462.915399] [] cache_alloc_refill+0x1ba/0x4b9 [ 1462.915424] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915448] [] nfs3svc_encode_entry_plus+0x10/0x13 [ 1462.915469] [] xfs_dir2_block_getdents+0x15b/0x1e2 [ 1462.915491] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915514] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915534] [] xfs_readdir+0x91/0xb6 [ 1462.915557] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915579] [] xfs_file_readdir+0x31/0x40 [ 1462.915599] [] vfs_readdir+0x61/0x93 [ 1462.915619] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.915642] [] nfsd_readdir+0x6d/0xc5 [ 1462.915663] [] nfsd3_proc_readdirplus+0x114/0x204 [ 1462.915686] [] nfsd_dispatch+0xde/0x1b6 [ 1462.915706] [] svc_process+0x3f8/0x717 [ 1462.915729] [] nfsd+0x1a9/0x2c1 [ 1462.915749] [] child_rip+0xa/0x12 [ 1462.915769] [] __svc_create_thread+0xea/0x1eb [ 1462.915792] [] nfsd+0x0/0x2c1 [ 1462.915812] [] child_rip+0x0/0x12 Over time other processes pile up beind this. [ 1462.910728] nfsd D 5440 2965 2 [ 1462.910769] 8101040cdd40 0046 0001 810103471900 [ 1462.910812] 8101029a72c0 8101040cdcf0 80746dc0 80746dc0 [ 1462.910852] 80744020 80746dc0 81010008e0c0 8101012a1040 [ 1462.910882] Call Trace: [ 1462.910909] [] nfsd_permission+0x95/0xeb [ 1462.910931] [] vfs_readdir+0x46/0x93 [ 1462.910950] [] mutex_lock_nested+0x165/0x27c [ 1462.910971] [] _spin_unlock+0x1f/0x49 [ 1462.910994] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.911015] [] vfs_readdir+0x46/0x93 [ 1462.911037] [] nfs3svc_encode_entry_plus+0x0/0x13 [ 1462.911057] [] nfsd_readdir+0x6d/0xc5 [ 1462.911079] [] nfsd3_proc_readdirplus+0x114/0x204 [ 1462.911102] [] nfsd_dispatch+0xde/0x1b6 [ 1462.911122] [] svc_process+0x3f8/0x717 [ 1462.911143] [] nfsd+0x1a9/0x2c1 [ 1462.911165] [] child_rip+0xa/0x12 [ 1462.911184] [] __svc_create_thread+0xea/0x1eb [ 1462.911206] [] nfsd+0x0/0x2c1 [ 1462.911225] [] child_rip+0x0/0x12 Any suggestions other than to bisect this? (Bisection might be painful as it crosses the x86-merge.) - 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: [00/50] 2.6.22-stable review
> (to make it easier for people to click) actually, it's not a tarball either... am I seeing something stale or perhaps the result of slow 'kernel.org replication? - 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: [00/50] 2.6.22-stable review
On Mon, Sep 24, 2007 at 09:31:48AM -0700, Greg KH wrote: > A tarball of the patches can be found at: > kernel.org/pub/linux/kernel/v2.6/stable-testing/patch-2.6.22.8-rc1.gz ^^^ s/testing/review/ http://kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.22.8-rc1.gz (to make it easier for people to click) - 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] Add a 'minimal tree install' target
On Thu, Sep 13, 2007 at 10:17:27PM +0200, Oleg Verych wrote: > That particular one-line `ALTARCH := i386' of course can be matched > simpler, because there's only *one* (as written above) whitespace and no > make's assignment variations, The goal is to extract the RHS from ALTARCH := ... > Also, please take a look on man isspace(). It matches much more > characters, than necessary for ordinary syntax whitespace. Good point. > Using [:blank:] (i.e. tab and space, with no options) is OK. Last > thing: i'm not sure, what that `+' is. I stick to BRE in sed, as it > should be, so just don't know what it does. The \+ was misplaced :-) I typed that very quickly and didn't think to hard. - 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] Add a 'minimal tree install' target
On Thu, Sep 13, 2007 at 08:34:00PM +0200, Sam Ravnborg wrote:
> A few. Please address them and resubmit with full changelog and
> proper attribution (if possible) and a signed-of-by.
sure
> I would strongly prefer the name "build-pkg".
right
> The prefix -pkg is just to use the magic in top-level Makefile to
> dicert it to the right Makefile.
yeah, i had something a bit like originally but didn't like the name
so changed it and poked the top-level Makefile
> I would like to attribute whoever made this somehow.
so would i, i assume it was davej + others so i cc'd him on this
hoping for feedback
> This becomes obsolete when target is named -pkg
yes
> Here we could do a $(MAKE) KBUILD_SRC= clean
> This will leave all files needed for building external modules
> but delete the rest (almost).
ok, i'll try that
> set -e to bail out on error could do it for now.
will do
> kbuild will not like it either so you can drop this FIXME
ok
> > +# This relies on the following environment variables being sane and
> > +# passed in from the Makefiles:
> > +#
> > +#INSTALL_MINTREE_PATH
> > +#KERNELVERSION
> Could we pass this as parameters. This makes it explicit.
> You do not need to check them since this script is not
> supposed to be used stand-alone.
can do
> > +if [ "$srctree" != "$objtree" ] ; then
> > +cp --parents $(find -type f -name "Makefile*" -o -name "Kconfig*" -not
> > -ipath "$objtree/*Makefile" ) ${tgtdir}
>
> ^
> Why this wildcard??? (objtree/>* Seems to be a typing error.
no, it's so we catch things like
linux/build/Makefile
*and*
linux/build/foo/bar/Makefile
> > +#rm -rf ${tgtdir}/Documentation
> Remove this line since it is commented out
right, actually, it can be uncommented but the 'make help' fails; i'm
not sure if we need make help to work since most of the other targets
won't anyhow
so should i remove it (leaving 'make help' as usable) or remove it?
> > +rm -f ${tgtdir}/scripts/*.o
> > +rm -f ${tgtdir}/scripts/*/*.o
> If we do the make clean this is not needed.
ok
> Something less hardcoded are preferred. Maybe like:
> cp -a `ls | grep -v ^asm` asm-generic $(tgtdir}/include
ok (though i'm not a big fan of ls | grep as a rule, it tends to be
fragile when people do dumb things)
> Here we use readlink but in next line we use $ARCH.
> We should be consitent and use ARCH all over.
i tried to preserve as much logic as possible from the original
script, at least initially
i'll change that
> > +if [ "$ARCH" = "x86_64" ]; then
> > +cp -a asm-i386 ${tgtdir}/include
> > +fi
> Too hardcoded.
> Here we could use some sed magic to extract a potential ALTARCH from
> asm-${ARCH}/Kbuild
> My sed skills are too limited to do this in a minute... :-(
what about something like?
sed -n "s/^ALTARCH[[:space:]]:=[[:space:]]\(.*$\)\+/\1/p"
(i'm sure there is a better way though)
> This part I did not check up on - I assume it is correct.
it all seems to 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/
[RFC PATCH] Add a 'minimal tree install' target
This is a somewhat rough first-pass at making a 'minimal tree'
installation target. This installs a partial source-tree which you
can use to build external modules against. It feels pretty unclean
but I'm not aware of a much better way to do some of this.
This patch works for me, even when using O=. It probably
needs further cleanups.
Comments?
-
Add a 'mintree-install' makefile target.
Red Hat and other distributions typically have some logic in their
kernel package build system to create/install 'minimalist source tree'
which contains enough state to build external modules against but is
much smaller than the entire build-tree.
This introduces similar logic, the guts of this was taken from a
Fedora Core spec file and mutilated to make it work for O=<...>
builds.
-
diff --git a/Makefile b/Makefile
index 3067f6a..1246939 100644
--- a/Makefile
+++ b/Makefile
@@ -1085,6 +1085,11 @@ package-dir := $(srctree)/scripts/package
$(Q)$(MAKE) $(build)=$(package-dir) $@
rpm: include/config/kernel.release FORCE
$(Q)$(MAKE) $(build)=$(package-dir) $@
+# /usr/src/linux to match what most distro's do
+#export INSTALL_MINTREE_PATH ?= /usr/src/linux
+export INSTALL_MINTREE_PATH ?= /tmp/mt-test/
+mintree-install: include/config/kernel.release FORCE
+ $(Q)$(MAKE) $(build)=$(package-dir) $@
# Brief documentation of the typical targets used
diff --git a/scripts/package/Makefile b/scripts/package/Makefile
index 7c434e0..0c5f07d 100644
--- a/scripts/package/Makefile
+++ b/scripts/package/Makefile
@@ -86,6 +86,12 @@ tar%pkg: FORCE
clean-dirs += $(objtree)/tar-install/
+# minimal tree installation target
+# ---
+mintree-install: FORCE
+ $(MAKE) KBUILD_SRC=
+ $(CONFIG_SHELL) $(srctree)/scripts/package/mintree-install
+
# Help text displayed when executing 'make help'
# ---
help: FORCE
@@ -96,4 +102,6 @@ help: FORCE
@echo ' tar-pkg - Build the kernel as an uncompressed tarball'
@echo ' targz-pkg - Build the kernel as a gzip compressed
tarball'
@echo ' tarbz2-pkg - Build the kernel as a bzip2 compressed
tarball'
+ @echo ' mintree-install - Build the kernel and install a
minimal-build-tree'
+ @echo 'that can be used to build external modules
against'
diff --git a/scripts/package/mintree-install b/scripts/package/mintree-install
new file mode 100644
index 000..1362cc2
--- /dev/null
+++ b/scripts/package/mintree-install
@@ -0,0 +1,87 @@
+#!/bin/bash
+
+# miniman-tree-install
+#
+# This should install necessary the headers, makefiles and
+# configuration files in a location so that you can use kbuild to
+# build external (out of tree) modules without needing the entire
+# kernel build tree.
+#
+
+# This has been shamelessly taken from a Red Hat's spec file,
+#
http://cvs.fedora.redhat.com/viewcvs/devel/kernel/kernel.spec?rev=1.145&view=markup
+
+# FIXME:cw Some parts of this are still icky, it's not clear how best
+# to clean some of this up. Error handling is more or less
+# non-existent. You could argue that this entire process should be
+# done differently (ie. using kbuild knowledge instead of a whole lot
+# of hard-coded magic here).
+
+# FIXME:cw If any of srctree, objtree or INSTALL_MINTREE_PATH have
+# spaces in them some parts of this will fail as-is, it shouldn't be
+# that hard to fix (it's not clear if the rest of t kbuild is clean in
+# that respect though)
+
+# This relies on the following environment variables being sane and
+# passed in from the Makefiles:
+#
+#INSTALL_MINTREE_PATH
+#KERNELVERSION
+
+
+# target directory
+tgtdir="${INSTALL_MINTREE_PATH}"/${KERNELVERSION}/
+
+
+# And save the headers/makefiles etc for building modules against
+#
+# This all looks scary, but the end result is supposed to be:
+# * all arch relevant include/ files
+# * all Makefile/Kconfig files
+# * all script/ files
+
+cd "$srctree" || exit $?
+
+mkdir -p ${tgtdir}
+
+# first copy everything. If objtree differs from srctree (ie. O=<...>
+# is used) then make sure we don't copy the Makefile(s) from inside
+# $objtree
+if [ "$srctree" != "$objtree" ] ; then
+cp --parents $(find -type f -name "Makefile*" -o -name "Kconfig*" -not
-ipath "$objtree/*Makefile" ) ${tgtdir}
+else
+cp --parents $(find -type f -name "Makefile*" -o -name "Kconfig*")
${tgtdir}
+fi
+
+cp "${objtree}/Module.symvers" ${tgtdir}
+# then drop all but the needed Makefiles/Kconfig files
+#rm -rf ${tgtdir}/Documentation
+rm -rf "${tgtdir}/scripts"
+rm -rf "${tgtdir}/include"
+cp "${objtree}/.config" ${tgtdir}
+cp -a scripts ${tgtdir}
+if [ -d ${srctree}/arch/${ARCH}/scripts ]; then
+cp -a ${srctree}/arch/${ARCH}/scripts ${tgtdir}/arch/${ARCH} || :
+fi
+if [ -f ${objtree}/arch/${ARCH}/*lds ]; then
+cp -a ${objtree}/arch/${ARCH}/*lds ${tgtdir}/arch/${AR
Re: RFC: drop support for gcc < 4.0
On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote: > Are there any architectures still requiring a gcc < 4.0 ? Yes, sadly in some places (embedded) there are people with older compiler who want newer kernels. - 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/3] Fix XFS_IOC_FSGEOMETRY_V1 in compat mode
On Wed, May 30, 2007 at 02:59:55PM +0200, Michal Marek wrote:
> +typedef struct xfs_fsop_geom_v132 {
wouldn't xfs_fsop_geom_v1_32
^
> + __u32 blocksize; /* filesystem (data) block size */
[...]
> + __u32 dirblocksize; /* directory block size, bytes */
> +} __attribute__((packed)) xfs_fsop_geom_v132_t;
and xfs_fsop_geom_v1_32_t
^
read better 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/
(hacky) [PATCH] silence MODPOST section mismatch warnings
MODPOST seems to be spewing bogus warnings. It's not clear how best to fix it so perhaps we should silence it for now? diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 113dc77..bd6fe7b 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -872,6 +872,10 @@ static void warn_sec_mismatch(const char *modname, const char *fromsec, sechdrs[hdr->e_shstrndx].sh_offset; const char *secname = secstrings + sechdrs[sym->st_shndx].sh_name; + /* FIXME: this function doesn't work correctly anymore, it's +* not clear if it should be fixed or removed. */ + return; + find_symbols_between(elf, r.r_offset, fromsec, &before, &after); refsym = find_elf_symbol(elf, r.r_addend, sym); - 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] nfs: memclear_highpage_flush -> zero_user_page conversion
Does this look correct?
diff --git a/fs/nfs/read.c b/fs/nfs/read.c
index 9a55807..7bd7cb9 100644
--- a/fs/nfs/read.c
+++ b/fs/nfs/read.c
@@ -79,7 +79,7 @@ void nfs_readdata_release(void *data)
static
int nfs_return_empty_page(struct page *page)
{
- memclear_highpage_flush(page, 0, PAGE_CACHE_SIZE);
+ zero_user_page(page, 0, PAGE_CACHE_SIZE, KM_USER0);
SetPageUptodate(page);
unlock_page(page);
return 0;
@@ -103,10 +103,10 @@ static void
nfs_readpage_truncate_uninitialised_page(struct nfs_read_data *data)
pglen = PAGE_CACHE_SIZE - base;
for (;;) {
if (remainder <= pglen) {
- memclear_highpage_flush(*pages, base, remainder);
+ zero_user_page(*pages, base, remainder, KM_USER0);
break;
}
- memclear_highpage_flush(*pages, base, pglen);
+ zero_user_page(*pages, base, pglen, KM_USER0);
pages++;
remainder -= pglen;
pglen = PAGE_CACHE_SIZE;
@@ -130,7 +130,7 @@ static int nfs_readpage_async(struct nfs_open_context *ctx,
struct inode *inode,
return PTR_ERR(new);
}
if (len < PAGE_CACHE_SIZE)
- memclear_highpage_flush(page, len, PAGE_CACHE_SIZE - len);
+ zero_user_page(page, len, PAGE_CACHE_SIZE - len, KM_USER0);
nfs_list_add_request(new, &one_request);
if (NFS_SERVER(inode)->rsize < PAGE_CACHE_SIZE)
@@ -532,7 +532,7 @@ readpage_async_filler(void *data, struct page *page)
return PTR_ERR(new);
}
if (len < PAGE_CACHE_SIZE)
- memclear_highpage_flush(page, len, PAGE_CACHE_SIZE - len);
+ zero_user_page(page, len, PAGE_CACHE_SIZE - len, KM_USER0);
nfs_pageio_add_request(desc->pgio, new);
return 0;
}
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index de92b95..211d0b1 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -168,7 +168,7 @@ static void nfs_mark_uptodate(struct page *page, unsigned
int base, unsigned int
if (count != nfs_page_length(page))
return;
if (count != PAGE_CACHE_SIZE)
- memclear_highpage_flush(page, count, PAGE_CACHE_SIZE - count);
+ zero_user_page(page, count, PAGE_CACHE_SIZE - count, KM_USER0);
SetPageUptodate(page);
}
-
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] Add getcpu and epoll_pwait system calls.
On Wed, May 09, 2007 at 12:24:32AM +0200, Andi Kleen wrote: > Somehow yes. But i'm not going to add a useless syscall just to > shut it up. It turns out this has come up in other places. Sam has a suggestion on how to silence this per-arch so I'll post a patch once that change is in. - 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] Add getcpu and epoll_pwait system calls.
On Wed, May 09, 2007 at 12:13:48AM +0200, Andi Kleen wrote: > Nope. There already is a getcpu vsyscall. This is not needed. The kbuild magic that checks for missing syscalls needs to be taught about this then I take 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/
Re: [PATCH] [x86-64] Add getcpu and epoll_pwait system calls.
On Tue, May 08, 2007 at 11:37:26AM -0700, Chris Wedgwood wrote: > +#define __NR_getcpu 280 I see something was merged just now that uses 280. Should I resubmit this using 281 & 282? - 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] Type cast some size_t arguments to 'unsigned int' to avoid (harmless) gcc printk warnings.
On Wed, May 09, 2007 at 12:03:19AM +0400, Alexey Dobriyan wrote: > For one, size_t should be printed with %zu. thanks, i wasn't aware of this > For two, this is already fixed in mainline. this was against mainline that wasn't more than an hour old when i sent the patch - 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] Type cast some size_t arguments to 'unsigned int' to avoid (harmless) gcc printk warnings.
Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]>
---
net/sunrpc/sched.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
index 4a53e94..60df3c1 100644
--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -764,7 +764,7 @@ void *rpc_malloc(struct rpc_task *task, size_t size)
buf = kmalloc(size, gfp);
*buf = size;
dprintk("RPC: %5u allocated buffer of size %u at %p\n",
- task->tk_pid, size, buf);
+ task->tk_pid, (unsigned int)size, buf);
return (void *) ++buf;
}
@@ -783,7 +783,7 @@ void rpc_free(void *buffer)
buf--;
dprintk("RPC: freeing buffer of size %u at %p\n",
- size, buf);
+ (unsigned int)size, buf);
if (size <= RPC_BUFFER_MAXSIZE)
mempool_free(buf, rpc_buffer_mempool);
else
--
1.5.1.3
-
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] [x86-64] Add getcpu and epoll_pwait system calls.
Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]> --- include/asm-x86_64/unistd.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/asm-x86_64/unistd.h b/include/asm-x86_64/unistd.h index 26e23e0..aa7d4bf 100644 --- a/include/asm-x86_64/unistd.h +++ b/include/asm-x86_64/unistd.h @@ -619,6 +619,10 @@ __SYSCALL(__NR_sync_file_range, sys_sync_file_range) __SYSCALL(__NR_vmsplice, sys_vmsplice) #define __NR_move_pages279 __SYSCALL(__NR_move_pages, sys_move_pages) +#define __NR_getcpu280 +__SYSCALL(__NR_getcpu, sys_getcpu) +#define __NR_epoll_pwait 281 +__SYSCALL(__NR_epoll_pwait, sys_epoll_pwait) #ifndef __NO_STUBS #define __ARCH_WANT_OLD_READDIR -- 1.5.1.3 - 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] Remove unused device_probe_drivers function.
Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]>
---
drivers/base/dd.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 92428e5..b0088b0 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -207,19 +207,6 @@ static int __device_attach(struct device_driver * drv,
void * data)
return driver_probe_device(drv, dev);
}
-static int device_probe_drivers(void *data)
-{
- struct device *dev = data;
- int ret = 0;
-
- if (dev->bus) {
- down(&dev->sem);
- ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
- up(&dev->sem);
- }
- return ret;
-}
-
/**
* device_attach - try to attach device to a driver.
* @dev: device.
--
1.5.1.3
-
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] fallocate system call
On Mon, Apr 30, 2007 at 03:56:32PM +1000, David Chinner wrote: > On Sun, Apr 29, 2007 at 10:25:59PM -0700, Chris Wedgwood wrote: > IIRC, the argument for FA_ALLOCATE changing file size is that > posix_fallocate() is supposed to change the file size. But it's not posix_fallocate; it's something more generic. glibc can do posix_fallocate using truncate + fallocate. > Note that the way XFS implements growing the file size after the > allocation is via a truncate What's wrong with that? That seems very reasonable. > That's would what I did because otherwise you'd use ftruncate64(). > Without documented behaviour or an ext4 implementation, I have to > ask what it's supposed to do, though ;) How many *real* users are there for ext4? Why does 'what ext4 does' define 'the semantics'? Surely semantics should be decided either by precedent (if there is an existing relevant userbase) or sensible thought and some debate? - 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] fallocate system call
On Mon, Apr 30, 2007 at 10:47:02AM +1000, David Chinner wrote: > For FA_ALLOCATE, it's supposed to change the file size if we > allocate past EOF, right? I would argue no. Use truncate for that. > For FA_DEALLOCATE, does it change the filesize at all? Same as above. > Or does > it just punch a hole in the file? Yes. > FWIW, we definitely need a FA_PREALLOCATE mode (FA_ALLOCATE but does > not change file size) so we can preallocate beyond EOF for apps > which use O_APPEND (i.e. changing file size would cause problems for > them). FA_ALLOCATE should be able to allocate past-EOF I would argue. - 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] fallocate system call
On Fri, Apr 27, 2007 at 07:46:13PM +0200, Heiko Carstens wrote: > If one insists to have fd at first argument, what is wrong with > having u32 arguments only? Well, I was one of those who objected as it seems *UGLY* to me. > It's not that this syscall comes even close to what can be > considered performance critical... Right. > It adds userspace overhead for one architecture. Every *trace and > *libc needs special handling on s390 for this syscall. I would > prefer to avoid this. I'm not that bothered about it. I would prefer it did use clean 64-bit arguments, but given it's a non-critical syscall I'm don't think the aesthetics are worth impossing crud on s390 for. - 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.21-rc6
On Sun, Apr 08, 2007 at 08:59:03PM -0400, Jeff Garzik wrote: > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch > > It sounded this was specific to Ingo. I'm not sure, it sounds a bit like something I saw a while ago. I would have to check for sure, I made a quick debugging patch (sent to netdev) and it went away so I think my last though was a miscompilation. - 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: Warning: unable to open an initial console.
On Mon, Apr 02, 2007 at 12:04:56PM -0700, Tom Strader wrote: > I have seen quite a few posts regarding unable to open an initial > console, but my system seems to have the necessary things in place > so I come looking for help. your rootfs/initramfs/initrd is missing a valid working /dev/console > VFS: Mounted root (jffs2 filesystem). check /dev/ on this filesystem - 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: Interface for the new fallocate() system call
On Thu, Mar 29, 2007 at 05:21:26PM +0530, Amit K. Arora wrote: >int fallocate(int fd, loff_t offset, loff_t len, int mode) Right now there are only two possible values for mode --- it's not clear what additional values there will be in the future. How about two syscalls? If we decide later on we need something more complicated we can revisit this and *THEN* add another system call which may end up being a superset of the other two. I know that sounds somewhat icky but: * it's fairly simple * we get nice argument handling on all arches by dropping u32 mode (don't we?) * syscalls don't really cost a lot to keep about, they do cost in terms on maintenance though, but in this case i don't see it being all that much of a problem * IMO badly/over designed syscalls are going to be a bigger problem long term Given that *NO* single fs in mainline right now can *reliably* use this functionality for a while maybe whatever solution people come up with next should sit in -mm for a while? At least that gives people exposure to it and a chance to make some changes as once it's merged to mainline it's pretty hard to change. - 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] sys_fallocate() system call
I hate to comment at this late stage, especially on something that I think is really a great idea (I did similar more complex, sys_blkalloc with even more arguments time ago --- I'm glad given how complex this thread has become I didn't post them now). In the past there wasn't that much incentive to get this functionality exposed because of various other issues (mmap + page dirty didn't flush reliably) which are close to being resolve, so I think the timing of this is really great On Wed, Mar 21, 2007 at 05:34:25PM +0530, Amit K. Arora wrote: > As suggested by you and Russel, I have made this change to the > patch. Here is how it looks like now. Please let me know if anyone > has concerns about passing arguments this way (breaking each > "loff_t" into two "u32"s). I really dislike breaking 64-bit args up unless it's necessary. I guess it doesn't really hurt, but it feels needlessly ugly. > + .long sys_fallocate /* 320 */ > +/* > + * fallocate() modes > + */ > +#define FA_ALLOCATE 0x1 > +#define FA_DEALLOCATE0x2 > + given there are the only TWO modes right now, why not leave the arguments as 64-bit sane and simply have two syscalls, one for each? - 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] ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set
On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote: > This patch allows for ibm-acpi to coexist (with diminished > functionality) with other drivers like ACPI_BAY. Given the ACP_IBM_BAY implementation is more complete (or seems to be, please comment if that isn't the case) we should probably actually make sure that is the *preferred* code used (on suitable hardware) at run time surely? That way distributions can build both options and on IBM/Lenovo hardware it will use the IBM ACPI code and otherwise will use the generic ACPI BAY code? Perhaps the IBM_ACPI_BAY code should go away and any missing functionality provided there should be merged into ACPI_BAY? - 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] ACPI_IBM_BAY can not coexist with ACPI_BAY
ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI code to fail to initialize so all the IBM ACPI functionality is missing. The simplest fix is to just make sure the Kconfig magic disallows ACPI_IBM_BAY when ACPI_BAY is enabled. Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index e2ce4a9..1a83fc6 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -246,7 +246,7 @@ config ACPI_IBM_DOCK config ACPI_IBM_BAY bool "Legacy Removable Bay Support" - depends on ACPI_IBM + depends on ACPI_IBM && !ACPI_BAY default y ---help--- Allows the ibm_acpi driver to handle removable bays. It will allow - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Thu, Jan 18, 2007 at 10:29:14AM +0100, joachim wrote: > Not only has it only been on Nvidia chipsets but we have only seen > reports on the Nvidia CK804 SATA controller. People have reported problems with other controllers. I have one here I can test given a day or so. I don't think it's SATA related, it just happens that it shows up well there, for networking you would end up with the odd corrupted packet probably and end up just dropping those so it might not be noticeable. - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Thu, Jan 18, 2007 at 04:00:28AM -0700, Erik Andersen wrote: > I just tried again and while using iommu=soft does avoid the > corruption problem, as with previous kernels with 2.6.20-rc5 using > iommu=soft still makes my pcHDTV HD5500 DVB cards not work. i would file a separate bug about that, presumably it won't work in intel based machines too if the driver has dma api bugs - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Tue, Jan 16, 2007 at 09:31:31PM +0100, Krzysztof Halasa wrote: > Do you (someone) have (maintain) a list of affected systems, > including motherboard type and possibly version, BIOS version and > CPU type? A similar list of unaffected systems with 4GB+ RAM could > be useful, too. All I know is that some system hit this and some don't seem to. Why it's not clear. > I'm afraid with default iommu=soft it will be a mystery forever. Right, but given windows doesn't use the iommu at all and that a lot of newer hardware/drivers doesn't need it it might be the safest option since it clearly has been causing corruption for a number of people for well over a year 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote: > I agree,... it seems drastic, but this is the only really secure > solution. I'd like to here from Andi how he feels about this? It seems like a somewhat drastic solution in some ways given a lot of hardware doesn't seem to be affected (or maybe in those cases it's just really hard to hit, I don't know). > Well we can hope that Nvidia will find out more (though I'm not too > optimistic). Ideally someone from AMD needs to look into this, if some mainboards really never see this problem, then why is that? Is there errata that some BIOS/mainboard vendors are dealing with that others are not? > But we should not forget about the issue, just because SATA is not > longer affected. Right. - 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: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Tue, Jan 16, 2007 at 08:26:05AM -0600, Robert Hancock wrote: > >If one use iommu=soft the sata_nv will continue to use the new code > >for the ADMA, right? > > Right, that shouldn't affect it. right now i'm thinking if we can't figure out which cpu/bios combinations are safe we might almost be better off doing iommu=soft for *all* k8 stuff except for those that are whitelisted; though this seems extremely drastic it's not clear if this only affect nvidia based chipsets, the nature of the corruption makes me think it's not an iommu software bug (we see a few bytes not entire pages corrupted, it's not even clear if it's entire cachelines trashed) --- perhaps other vendors have more recent bios errata or maybe it's just that nvidia has sold a lot of these so they are more visible? (i'm assuming at this point it might be some kind of cpu errata that some bioses deal with because some mainboards don't ever seem to see this whilst others do) in some ways the problem is worse with recent kernels --- because the ethernet and sata can address over 4GB and don't use the iommu anymore the problem is going to be *much* harder to hit, but still here lurking to cause problems for people. with ethernet you'll probably end up getting the odd trashed tcp frame and dropping it, so those will go mostly unnoticed, so this is why sata seems to be the easier way to show 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/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote: > Please don't use that name, it strikes me as much more confusing > than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite > convey what it means, either. Calling internal symbols _INTERNAL is confusing? > EXPORT_SYMBOL_RESTRICTED? EXPORT_SYMBOL_DERIVED? At least > something which is not internally inconsistent would be good (how is > something which is exported "internal?") But those symbols aren't, they're about internal interfaces that might change. > And, as long as EXPORT_SYMBOL_GPL continues to check that the module > using it has a GPL license, then it really -is- exactly descriptive > of what it's doing and probably shouldn't be changed. IIMHO. Well, if EXPORT_SYMBOL_GPL / EXPORT_SYMBOL_INTERNAL is about documenting things, why restrict who can use them based on the license? Surely the licence is more about tainting the kernel and debugging not politics? Do we even need to check the license at all in that case? Maybe a better idea would be to embed where the source code is located and use the non-existence of that for a tainting? - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Thu, Dec 14, 2006 at 05:38:27PM +, Christoph Hellwig wrote: > Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. A quick grep shows that changing this now would require updating nearly 1900 instances, so patches to do this would be pretty large and disruptive (though we could support both during a transition and migrate them over time). - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote: > I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if > done properly (and I think we use it fairly well). > > I think we _can_ do things where we give clear hints to people that > "we think this is such an internal Linux thing that you simply > cannot use this without being considered a derived work". Then why not change the name to something more along those lines? - 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: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Wed, Dec 13, 2006 at 09:11:29PM +0100, Christoph Anton Mitterer wrote: > - error in the Opteron (memory controller) > - error in the Nvidia chipsets > - error in the kernel My guess without further information would be that some, but not all BIOSes are doing some work to avoid this. Does anyone have an amd64 with an nforce4 chipset and >4GB that does NOT have this problem? If so it might be worth chasing the BIOS vendors to see what errata they are dealing with. - 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: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Wed, Dec 13, 2006 at 08:18:21PM +0100, Christoph Anton Mitterer wrote: > booting with iommu=soft => works fine > booting with iommu=noagp => DOESN'T solve the error > booting with iommu=off => the system doesn't even boot and panics > When I set IOMMU to disabled in the BIOS the error is not solved- > I tried to set bigger space for the IOMMU in the BIOS (256MB instead of > 64MB),.. but it does not solve the problem. > Any ideas why iommu=disabled in the bios does not solve the issue? The kernel will still use the IOMMU if the BIOS doesn't set it up if it can, check your dmesg for IOMMU strings, there might be something printed to this effect. > 1) And does this now mean that there's an error in the hardware > (chipset or CPU/memcontroller)? My guess is it's a kernel bug, I don't know for certain. Perhaps we shaould start making a more comprehensive list of affected kernels & CPUs? - 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: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Wed, Dec 13, 2006 at 08:20:59PM +0100, Christoph Anton Mitterer wrote: > Did anyone made any test under Windows? I cannot set there > iommu=soft, can I? Windows never uses the hardware iommu, so it's always doing the equivalent on iommu=soft - 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/
amd64 iommu causing corruption? (was Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!)
On Mon, Dec 11, 2006 at 10:24:02AM +0100, Karsten Weiss wrote: > We could not reproduce the data corruption anymore if we boot the > machines with the kernel parameter "iommu=soft" i.e. if we use > software bounce buffering instead of the hw-iommu. (As mentioned > before, booting with mem=2g works fine, too, because this disables > the iommu altogether.) I can confirm this also seems to be the case for me, I'm still doing more testing to confirm this. But it would seem: nforce4, transfer of a large mount of data with 4GB+ of RAM I get some corruption. This is present on both the nv SATA and also Sil 3112 connected drives. Using iommu=soft so far seems to be working without any corruption. I still need to do more testing on other machines which have less memory (so the IOMMU won't be in use there either) and see if there are problems 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: data corruption with nvidia chipsets and IDE/SATA drives
On Wed, Dec 06, 2006 at 12:11:38PM +0100, Christian wrote: > I copied a massive amount of data (more than 500GB) several times > between the HDDs and ran md5sum each time, but it found no errors. It might be a known problem that your BIOS addresses already, or maybe it's restricted to some revisions of the chip(s)? - 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: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
On Sat, Dec 02, 2006 at 01:56:06AM +0100, Christoph Anton Mitterer wrote: > I found a severe bug mainly by fortune because it occurs very > rarely. My test looks like the following: I have about 30GB of > testing data on my harddisk,... I repeat verifying sha512 sums on > these files and check if errors occur. Heh, I see this also with an Tyan S2866 (nforce4 chipset). I've been aware something is a miss for a while because if I transfer about 40GB of data from one machine to another there are checksum mismatches and some files have to be transfered again. I've kept quite about it so far because it's not been clear what the cause is and because i can mostly ignore it now that I checksum all my data and check after xfer that it's sane (so I have 2+ copies of all this stuff everywhere). > One test pass verifies the 30GB 50 times,... about one to four > differences are found in each pass. Sounds about the same occurance rate I see, 30-40GB xfer, one or two pages (4K) are wrong. > The corrupted data is not one single completely wrong block of data > or so,.. but if you look at the area of the file where differences > are found,.. than some bytes are ok,.. some are wrong,.. and so on > (seems to be randomly). For me it seems that a single block in the file would be bad and the rest OK --- we I'm talking about 2 random blocks in 30BG or so. - 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: i386: kill !4KSTACKS
On Fri, Sep 02, 2005 at 02:39:15AM +0200, Adrian Bunk wrote: > 4Kb kernel stacks are the future on i386, and it seems the problems > it initially caused are now sorted out. Not entirely. XFS when mixed with raid/lvm/nfs still blows up. It's probably not alone in this respect but worse than ext2/3. - 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: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On Thu, Sep 01, 2005 at 12:12:00AM +0200, Jesper Juhl wrote: > b) add a new boot option telling the kernel the name of some file in > initrd or similar from which to load additional options. a file in initrd isn't a good choice; as the initrd is generally a fix image the point is some bootloaders might want to pass quite a bit of state to the kernel at times (i actually have this for a mip32 target where i construct a table and pass a pointer to that in, a tad icky but for lack of options) - 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: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On Wed, Aug 31, 2005 at 03:12:58PM -0700, H. Peter Anvin wrote: > Well, we have initramfs for the really big stuff. The kernel > shouldn't really need that much data, though. except the initrd image is in many cases fairly fixed; right now i have options i pass into initramfs by passing arguments on the command line which initrd them reads, parses and uses that to grab a file from the network it's a tad disconnected to have to do this though - 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: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On Wed, Aug 31, 2005 at 03:01:57PM -0700, H. Peter Anvin wrote: > Maybe not. Another option would simply be to bump it up > significantly (2x isn't really that much.) 4096, maybe. I wonder if we're not at the point where we need something different to what we have now. The concept of a command-line works for passing simple state but for more complex things it's too cumbersome. - 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: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On Wed, Aug 31, 2005 at 02:29:44PM -0700, H. Peter Anvin wrote: > I think someone on the SYSLINUX mailing list already sent a patch to > akpm to make 512 the default; making it configurable would be a > better idea. Feel free to send your patch through me. So we really need this to be a configuration option? We have too many of those already. - 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: Initramfs and TMPFS!
On Sat, Aug 27, 2005 at 10:45:55PM +, Kent Robotti wrote: > Why don't you do some research on manners? It was (an obvious) troll. Don't take it so seriously. Besides, deep deep down I really am a terrible person. - 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: Initramfs and TMPFS!
On Sat, Aug 27, 2005 at 08:19:18AM +, Kent Robotti wrote: > I know that experience dosen't come from packing the kernel source, > or the zillion other tar archives on the internet. Are you deliberately trying to be annoying? Let me guess: - your under 25 years of age, probably in high school or not far out of it - you have a stupid oversized wanky computer case with neon lighting and useless analog dials and what not. you might have even overclocked it - you've run windows most of your live - you probably run gentoo now. you like the feeling of having everything optimized for your exact system; the addition 0.25% speed increase more than offsets the fact everything is crappy and crashes all the time - you run reiserfs, you probably can't wait till reiser4 is merged so you can run that - you're very interesting in real-time patches. linux should clearly have all real-time stuff merged. second to your interest in realtime is probably something like selinux - if you drive a car, it has extra spoilers added and you've replaced the steering wheel with something from MOMO - you 'friends' are worried you'll die a virgin Please. How about you do a little research on some things for a bit? The initramfs code is done the way it is for a good reason. cpio is used over tar for another good reason. You are most welcome to disagree and even voice you disagreement, but there comes a point where you really need to produce some better arguments. Patches wouldn't hurt either. - 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: Initramfs and TMPFS!
On Sat, Aug 27, 2005 at 03:21:27AM +, Kent Robotti wrote: > The purpose of the patch is to overmount ramfs/rootfs with tmpfs before > the compressed cpio archive is unpacked and /init is run. yes and no there are people who want the overmount even without cpio decompression > But, it's only needed because the current initramfs implementation > doesn't offer tmpfs as an option. tmpfs isn't initialized early enough; i've hacked around this but a cleaner solution is needed > /init could just be a symbolic link to /sbin/init, or it could be > some other executable (shell script etc.), but there would be no > need to pivot or move root. pivot is evil, it probably should be depricated - 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: Initramfs and TMPFS!
On Fri, Aug 26, 2005 at 08:08:51PM +, Kent Robotti wrote: > Overmount_rootfs shouldn't take place until you know for sure the > kernel detects an initramfs. Actually, it was a deliberate decision to *always* overmount after some discussion with people. It's not a clean solution and the overall goals aren't clear here so it was never submitted for inclusion --- an the fact is 99.9% of users simply don't need or care for this. - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 08:05:32PM +0100, Alan Jenkins wrote: > I'm curious as to why the kernel has to include the decoder - why > you can't just run a self-extracting executable in an empty > initramfs (with a preset capacity if needs be). You could do tht right now if you wished. We just support decompression in the kernel because it's not overly painful to do so (the code exists and works fairly well for the most part). The code to do so isn't ver large and it's marked __init too (well, it should be). - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 11:38:49AM -0400, [EMAIL PROTECTED] wrote: > What if you have a root.cpio.gz that requires 200MB to hold, but you > only have 300MB of memory? then it won't work with nay of the schemes you've suggested > 50% of total memory wouldn't hold it, but 90% etc. would (tmpfs_size=90%). no, actually it won't - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 09:39:15PM -0400, [EMAIL PROTECTED] wrote: > Wouldn't it be better to put overmount_rootfs in initramfs.c > and call it only if there's a initramfs? I don't see what or how that helps. Yes we can shuffle some code about but the real problem still exists. That is is that (by design) the early userspace is unpacked as soon as possible before all kernel subsystems are up. - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote: > I don't know, because tar is probably more widely used and > consequently people are more familiar with how to use it. As I said before, the cpio format is cleaner/easier to parse in the kernel. Everyone has cpio probably so using tar isn't necessary. > But, that is not as important as having the option of using tmpfs > as the initramfs. Well, it's not clean that we really want this either. I have some niche needs for it but I suspect most people will never use such an option. - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote: > Right, but it would be nice to have that option if initramfs > using tmpfs becomes part of the kernel. But it's not needed so why add bloat? - 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: Initramfs and TMPFS!
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote: > Also, tar should be an option instead of cpio for the archiver, > because tar is more widely used. pretty much everyone will have cpio and it's format is much simpler/cleaner to deal with if we want vastly more complex early-userspace semantics i think we need to carefully decide what is needed and how to put as much of that logic into userspace rather than hacking this much more in the kernel for fear of breaking things in subtle ways - 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: Initramfs and TMPFS!
On Wed, Aug 24, 2005 at 06:41:26PM -0400, [EMAIL PROTECTED] wrote: > I tried it with kernel 2.6.13-rc5 and it seems to work. it should yes > It uses 50% of total memory for tmpfs, but it would be nice to have > an option (tmpfs_size=90% etc.) that you could pass to the kernel. that's just because of the tmpfs default; you can remount to change that if it's not suitable once your up and running in your init-scripts or whatever > You need to add this to init/main.c for it to compile. > #include hmm... really? i'll rediff it at some point and test it maybe. i really don't like the explicity shm init though, i'd like to think of a cleaner way to do that - 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.6.13-rc6] dcdbas: add Dell Systems Management Base Driver with sysfs support
On Wed, Aug 24, 2005 at 09:00:21PM -0500, Doug Warzecha wrote: [...] > +Dell OpenManage requires this driver on the following Dell PowerEdge systems: > +300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC, > +700, and 750. Other Dell software such as the open source Libsmbios library > +is expected to make use of this driver, and it may include the use of this > +driver on other Dell systems. I'd like to see a URL/pointer somewhere about here in the docs for the location of libsmbios if nobody objects. - 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: Initramfs and TMPFS!
On Wed, Aug 24, 2005 at 04:52:37PM -0400, Wakko Warner wrote:
> Care to send me the patch?
Heh. Not really as I don't really know if people should be using it
in it's current state --- the shmem init is very very hacky and I have
other changes I've not had a chance to do.
Anyhow, here is an older version of it. It's from some old internal
embedded tree but should be trivial to shoehorn into anything recent.
If people really do like or want this I would like to know and maybe
something more elegant can be worked out.
Index: linux/init/main.c
===
--- linux/init/main.c (revision 51)
+++ linux/init/main.c (working copy)
@@ -689,6 +689,49 @@
#endif
}
+/* If we want the rootfs on initramfs so we mount initramfs over the
+ * rootfs before we unpack it. The little dance we do by creating a
+ * pivot point and moving the root to that is in fact necessary
+ * because lookups of "." don't resolve mountpoints.
+ */
+static inline void __init overmount_rootfs(void)
+{
+#ifdef CONFIG_EARLYUSERSPACE_ON_TMPFS
+ int init_tmpfs(void);
+ int (*initfunc)(void) = init_tmpfs;
+ mm_segment_t oldfs;
+ char pivot[] = "/pivot";
+
+ /* Explicitly go and init the overmount fs early (long-term
+* the need for this will probably go away. */
+
+ if (initfunc())
+ goto err;
+
+ oldfs = get_fs();
+ set_fs(KERNEL_DS);
+
+ if (sys_mkdir(pivot, 0700) < 0)
+ goto err;
+ if (sys_mount("tmpfs", pivot, "tmpfs", 0, NULL))
+ goto err;
+
+ /* Below here errors are unlikely and icky to deal with. */
+ sys_chdir(pivot);
+ sys_mount(".", "/", NULL, MS_MOVE, NULL);
+ sys_chdir(".");
+ sys_chroot(".");
+ printk(KERN_INFO "Overmounted tmpfs\n");
+ goto out;
+
+ err:
+ printk(KERN_ERR "Overmount error\n");
+
+ out:
+ set_fs(oldfs);
+#endif /* CONFIG_EARLYUSERSPACE_ON_TMPFS */
+}
+
static int init(void * unused)
{
lock_kernel();
@@ -715,6 +758,7 @@
* Do this before initcalls, because some drivers want to access
* firmware files.
*/
+ overmount_rootfs();
populate_rootfs();
do_basic_setup();
Index: linux/fs/Kconfig
===
--- linux/fs/Kconfig(revision 51)
+++ linux/fs/Kconfig(working copy)
@@ -951,6 +951,18 @@
If you are not using a security module that requires using
extended attributes for file security labels, say N.
+config EARLYUSERSPACE_ON_TMPFS
+ bool "Unpack the early userspace onto tmpfs"
+ depends TMPFS
+ default y
+ help
+ Use this to have your early userspace placed (decompressed)
+ onto tmpfs as opposed ramfs. This will allow you to
+ restrict the size of your root-filesystem and it will also
+ be swappable.
+
+ If unsure, say Y.
+
config HUGETLBFS
bool "HugeTLB file system support"
depends X86 || IA64 || PPC64 || SPARC64 || SUPERH || X86_64 || BROKEN
Index: linux/mm/shmem.c
===
--- linux/mm/shmem.c(revision 51)
+++ linux/mm/shmem.c(working copy)
@@ -2206,7 +2206,7 @@
};
static struct vfsmount *shm_mnt;
-static int __init init_tmpfs(void)
+int __init init_tmpfs(void)
{
int error;
@@ -2239,7 +2239,12 @@
shm_mnt = ERR_PTR(error);
return error;
}
+/* Don't do this if we are calling it early explicity */
+#ifndef CONFIG_EARLYUSERSPACE_ON_TMPFS
+/* Iff CONFIG_EARLYUSERSPACE_ON_TMPFS is set then we will interpose
+ * ramfs so this will get called explicitly and early */
module_init(init_tmpfs)
+#endif /* !CONFIG_EARLYUSERSPACE_ON_TMPFS */
/*
* shmem_file_setup - get an unlinked file living in tmpfs
-
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: Initramfs and TMPFS!
On Tue, Aug 23, 2005 at 06:05:47PM -0400, [EMAIL PROTECTED] wrote: > I was just making a suggestion to whoever it may concern, because I > think it would extend the usefullness of initramfs. I have a path for initramfs to use tmpfs. It's sorta hacky so I never submitted it and solves a niche problem for embedded people. Ultimately we might one day still want to change how we initialize the early userspace (Al suggesting a reasomably nice way to move the decompressor(s) to userspace for example) so I don't feel there is a compelling reason to do more than cleanups in this area right 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: PATCH for changing of DVD speed via ioctl() call
On Sun, Aug 21, 2005 at 09:56:45PM +0200, Bodo Eggert wrote:
> The parameter value should IMHO be a pointer to a struct {
> unsigned long long maxspeed; // (with 0 being the magic max. value?)
> int facility; /* 0=general speed, 2=general read, 4=read data,
> 6=read audio, 8=read raw ... whatever is supported
> n+1 = s/read/write/ */
> }
Passing pointers inside ioctl's is horrible IMO and if we can avoid it
we should. It's just asking for problems.
-
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: largefile-support-for-accounting.patch added to -mm tree
On Sat, Aug 20, 2005 at 05:33:27PM -0700, [EMAIL PROTECTED] wrote: > Another annoying problem is that once the system reaches this 2GB > limit, then every process which exits will receive a signal, > SIGXFSZ. This signal is generated because an attempt was made to > write beyond the limit for the file descriptor. This signal makes > it look like every process has exited due to a signal, when in fact, > they have not. Eeek. > The solution is to add the O_LARGEFILE flag to the list of flags > used to open the accounting file. The rest of the accounting > support is already largefile safe. That fixes the larger accounting file problem but it doesn't address the fact that signals resulting writes to the accounting file are delivered incorrectly. We could still have issues if the accounting file as over quota for example. Surely all accounting file writes should be insulated from the processes involved? - 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: sched_yield() makes OpenLDAP slow
On Thu, Aug 18, 2005 at 11:03:45PM -0700, Howard Chu wrote: > If the 2.6 kernel makes this programming model unreasonably slow, > then quite simply this kernel is not viable as a database platform. Pretty much everyone else manages to make it 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: overflows in /proc/net/dev
On Thu, Aug 18, 2005 at 09:28:10AM +0200, Sebastian Cla?en wrote:
> in struct net_device_stats all members are defined as unsgined
> long. In time of gigabit ethernet this takes not long to overflow.
It should still take an appreciable amount of time surely? We can
detect those wraps in userspace and deal with it as needed.
> Are there any plans to change these coutners to unsigned long long?
It comes up from time to time (see below).
> I saw in ifconfig source code the byte and packet counters are
> already defined as unsigned long long.
ifconfig is userspace.
[...]
> struct net_device_stats
> {
> - unsigned long rx_packets; /* total packets received
> */
> - unsigned long tx_packets; /* total packets transmitted
> */
> - unsigned long rx_bytes; /* total bytes received */
> - unsigned long tx_bytes; /* total bytes transmitted */
> + unsigned long long rx_packets; /* total packets received
> */
> + unsigned long long tx_packets; /* total packets transmitted
> */
> + unsigned long long rx_bytes;/* total bytes received
> */
> + unsigned long long tx_bytes;/* total bytes transmitted
> */
I thought the concensurs here was that because doing reliable atomic
updates of 64-bit values isn't possible on some (most?) 32-bit
architectures so we need additional locking to make this work which is
undesirable? (It might even be a FAQ by now as this comes up fairly
often).
-
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] Watchdog device node name unification
On Sun, Aug 14, 2005 at 09:47:15AM +0100, Christoph Hellwig wrote: > Looks like people never learn. We had horrible problems with devfs > because it decided to overload existing name fields, but the udev > brigade does the same idiocy again.. It's not too late to fix this. We can add a new field and rename the old one with minimal effort. - 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: NCQ support NVidia NForce4 (CK804) SATAII
On Mon, Aug 15, 2005 at 09:42:37AM -0400, Stephen Frost wrote: > I also agree and am rather disappointed by this news. > Unfortunately, I've already bought an A8N-SLI. If you can send it back citing the driver issues as the reason. Linux sales are probably a tiny blip on the radar for them so I don't expect this to make a big difference immediately but keeping constant pressure of vendors like nvidia about openness is probably the best we can do right now (obviously this means avoiding buying their products as much as possible). - 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] pull XFS support out of Kconfig submenu
On Wed, Aug 17, 2005 at 10:45:48PM +0200, Jesper Juhl wrote: > It seems slightly odd to me that XFS support should be in a separate > submenu, when all the other filesystems are not using submenus but > are directly selectable from the Filesystems menu. XFS also has an out-of-tree version. Making it a submenu is probably to make maintenance easier (ie. replace files, not merge). - 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 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
On Tue, Aug 16, 2005 at 12:19:49AM -0500, Michael E Brown wrote: > Hmm... did I mention libsmbios? :-) > http://linux.dell.com/libsmbios/main. I'm aware of it --- it seems pretty limited right now and I'm still irked Dell isn't more forthcoming with documentation. > SMI support is not yet implemented inside libsmbios, but I am > working feverishly on it (in-between emails to linux-kernel, of > course.) :-) We have a development mailing list, and I will make the > announcement there when it has been complete. [...] > I cannot (at this point, I'm working on it, though), provide our > internal documentation of our SMI implementation directly. But, I am > authorized to add all of this to libsmbios, and I intend to very > clearly document all of the SMI calls in libsmbios. Given that why not resubmit the kernel driver when the userspace becomes usable for people without them having to use MonsterApp from Dell? > Aside from that, for the most part, the only thing SMI ever does is > pass buffers back and forth. I meant to ask; does this have horrible latency or nasties like lots of laptop SMM stuff? - 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 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
On Tue, Aug 16, 2005 at 12:55:35AM -0400, Kyle Moffett wrote: > I'm worried that it might be more of a mess in userspace than it > could be if done properly in the kernel. I would rather if it's gonna be a mess it's, then we put that mess in userspace rather than in the kernel. > Hardware drivers, especially for something as critical as the BIOS, > should probably be done in-kernel. For the most part it's not for the BIOS though AFAICT. It's for some hacky little microcontroller that controls fans and similar things that Dell won't give up details for. > Look at the mess that X has become, it mmaps /dev/mem and pokes at > the PCI busses directly. I just don't want an MSI-driver to become > another /dev/mem. It's for old hardware, I'm not sure it will evolve much other than just for maintenance. It's really hard to say, maybe if Dell gave more details about the userspace we would have a better idea? - 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 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote: > Why can't you just implement the system management actions in the > kernel driver? Why put things in the kernel unless it's really needed? I'm not thrillied about the lack of userspace support for this driver but that still doesn't mean we need to shovel wads of crap into the 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: [PATCH] Watchdog device node name unification
On Sun, Aug 14, 2005 at 01:43:22AM +0200, Olaf Hering wrote: > It is used for /class/misc/$name/dev Ick. I would almost suggest we change that were it not too late. I think keeping the decription is useful and desirable. - 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: Syncing single filesystem (slow USB writing)
On Fri, Jul 29, 2005 at 07:31:20AM +0400, Andrey Borzenkov wrote: > Mandrake always mounted USB sticks with sync option; it was > effectively noop except for a patch that implemented limited dsync > semantic. fwiw; various people have reported using flash block devices with 'sync' ruins them as there can be many more (and very frequent) updates to the device - 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] ramfs: pretend dirent sizes
On Thu, Jul 21, 2005 at 09:20:03AM +0200, J?rn Engel wrote: > In both cases, what used to be a proper offset in one fd can be > complete bogus for another one. Exactly. Knowing the position within a directory is of questionable value and trying to implement any reliable semantics for lseek is futile. - 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] ramfs: pretend dirent sizes
On Wed, Jul 20, 2005 at 01:21:27PM +0200, J?rn Engel wrote: > To my understanding, you can lseek to any "proper" offset inside a > directory. Proper means that the offset marks the beginning of a > new dirent (or end of file) in the interpretation of the filesystem. But you can never tell where these are in general. > Userspace doesn't have any means to figure out, which addresses are > proper and which aren't. Except that getdents(2) moves the fd > offset to a proper address, which likely will remain proper until > the fd is closed. I don't see why or how this can be true in general (it might be, but I don't see how myself). If we are half way through scanning a directory and people start messing with it we could end up somewhere bogus (in which case f_op->readdir I guess is expected to try and do something sane here?) > Reopening the same directory may result in a formerly proper offset > isn't anymore. For that to be the case where is the state kept to ensure your current offset is valid? - 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] ramfs: pretend dirent sizes
On Tue, Jul 19, 2005 at 09:14:04PM +0200, Jan Blunck wrote: > >So you can seek to m*+ to access an offset into > >something at depth m? > > > > Yes. Hos does that work if offset >= m? > I disagree. Where is the information value of i_size if we always > could return 0? Directories clearly can't have zero size, so 0 means 'special'. Anything other than zero *might* be a real value. > IMO it should be at least an upper bound for the "number" of > informations that could actually be read (in terms of a seek offset) > like it is in the case of regular files. Why? And what should that upper bound be? > Better, if it is a strict upper bound so that you can seek to every > value smaller than i_size. For this purpose the i_size of > directories doesn't need to reflect any unit. lseek talks about bytes --- yes, it means for files specifically but I still don't see why we need to define more counter-intuitive semantics for directories when we don't need them. Also, how is lseek + readdir supposed to work in general? - 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] ramfs: pretend dirent sizes
On Tue, Jul 19, 2005 at 08:22:26PM +0200, Jan Blunck wrote: > Since these "arranged" values are also used as the offsets in the > return dirent IMO it is quite clean. So the size you want to reflect is n* i take it? Where in this case n is 20? So you can seek to m*+ to access an offset into something at depth m? > Nope. This value is kind of traditional: tmpfs is using it > (http://marc.theaimsgroup.com/?l=linux-kernel&m=103208296515378&w=2). I > think a better value would be 1 (one) since this is also used as the > dirent offset by dcache_readdir(). I really don't know why tmpfs is doing this. > The i_size of a directory isn't covered by the POSIX standard. IMO, > it should be possible to seek in the range of i_size and a following > readdir() on the directory should succeed. With what defined semantics? What if an entry is added in between seek and readdir? > But this isn't possible even not with real file systems like ext2. I'm not sure how expecting a meaningful offset into a directory can have consistent bahvior. > But keeping the i_size bound to zero even if the directory contains > entries does not make sense at all. Why? It seems perfectly reasonable that we can return 0 in such cases. Zero seems to make more sense as 'magical/unknown' than say any other arbitrary value. It's also possible a regular filesystem could return an arbitrary value such as 20 (not that this directly matters except it becomes confusing potentially): [EMAIL PROTECTED]:~$ mkdir foobar [EMAIL PROTECTED]:~$ ls -ld foobar drwxr-xr-x 2 cw cw 6 Jul 19 11:29 foobar [EMAIL PROTECTED]:~$ mkdir foobar/1234567 [EMAIL PROTECTED]:~$ ls -ld foobar drwxr-xr-x 3 cw cw 20 Jul 19 11:30 foobar - 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] ramfs: pretend dirent sizes
On Tue, Jul 19, 2005 at 11:28:10AM +0200, Jan Blunck wrote: > I'm using the i_size of directories in my patches. When reading > from a union directory, I'm using the i_size to seek to the right > offset in the union stack. Ick. That'a a bit of a hack. > Therefore I need values of dirent->d_off which are smaller than the > i_size of the directory. Hence the value of 20 I guess --- assuming nothing will stack this high? > Altogether, it doesn't make sense to me to seek to an offset which > is greater than the i_size and let the dirent read succeed. I personally would prefer that to be honest or some other way that doesn't change i_size. - 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] char: Add Dell Systems Management Base driver
On Tue, Jul 12, 2005 at 06:17:29PM -0500, Doug Warzecha wrote: > Because the hardware interfaces on those systems and the Dell > systems management software that access the interfaces are > proprietary, I can't provide specifications for the interfaces or > source code for the software. So you want a driver merged which nobody except Dell can write code for? > The systems that are supported by the dcdbas driver contain the > following Dell proprietary hardware systems management interfaces: > Temperature Voltage Monitor (TVM) and Calling Interface. These > interfaces are supported by older Dell PowerEdge systems. What's so special here that you can't give more details? I personally find it a little unfair to ask to have a driver merged into mainline to facilitate some proprietary userland where you refuse to give protocol level details to create a viable alternative. - 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] ramfs: pretend dirent sizes
On Fri, Jul 15, 2005 at 11:52:42AM -0700, Linus Torvalds wrote: > I really think you should update the "simple_xxx()" functions > instead, and thus make this happen for _any_ filesystem that uses > the simple fs helper functions. Why bother at all? I don't see why zero sizes are a problem. We've had them for year without complaints. - 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] i386: Selectable Frequency of the Timer Interrupt
On Fri, Jul 15, 2005 at 12:33:15PM -0400, Brown, Len wrote: > So, the 13-year-old design advice will continue to apply to > 13-year-old systems, but newer systems with C3 and HPET > should be using them. Last I looked HPET isn't everywhere yet (absent from nforce4 mainboards for example, but that might be a linux issue as I was told window can see one). - 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] i386: Selectable Frequency of the Timer Interrupt
On Thu, Jul 14, 2005 at 01:41:44PM -0700, Christoph Lameter wrote: > AFAIK John simply wants to change jiffies to count in nanoseconds > since bootup and then call it "clock_monotonic". Clocks and counter drift so calling it seconds would be misleading. It would really only be good for approximate timing. I think call it something arbitrary and work towards have a separate mechanism for time of day (which could end up being much more expensive to use but less frrequently needed). > One 64 bit value no splitting into seconds and nanoseconds anymore. Using a 64-bit value is a pain on some (many?) 32-bit CPUs. - 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] i386: Selectable Frequency of the Timer Interrupt
On Wed, Jul 13, 2005 at 04:41:41PM -0700, dean gaudet wrote: > windows xp base rate is 100Hz... but multimedia apps can ask for > almost any rate they want (depends on the hw capabilities). i > recall seeing rates >1200Hz when you launch some of the media player > apps -- sorry i forget the exact number. Windows starts an additional high-speed timer as needed for this? - 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] i386: Selectable Frequency of the Timer Interrupt
On Wed, Jul 13, 2005 at 05:24:41PM -0400, Lee Revell wrote: > Does anyone object to setting HZ at boot? I suspect nothing else > will make everyone happy. Does it bloat the code or slow things measurably? - 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] i386: Selectable Frequency of the Timer Interrupt
On Wed, Jul 13, 2005 at 01:48:57PM -0700, Andrew Morton wrote: > Len Brown, a year ago: "The bottom line number to laptop users is > battery lifetime. Just today somebody complained to me that Windows > gets twice the battery life that Linux does." It seems the motivation for lower HZ is really: (1) ACPI/SMM suckage in laptops (2) NUMA systems with *horrible* remote memory latencies Both can be detected from you .config and we could see HZ as needed there and everyone else could avoid this surely? The above one year old comment where it says "someone complained" makes me wonder if we ever had an original report with hard facts or just some internal/private comment/bug about how things seem. Surely we can test this accurately? > "My expectation is if we want to beat the competition, we'll want > the ability to go *under* 100Hz." What does Windows do here? > Len, any updates on the relationship between HZ and power > consumption? I can measure this[1] for some *old* hardware but as it has unusable behavior for ACPI I'm not sure how useful that is. [1] I was just going to remove batteries and run it from a bench supply in the lab and measure how much current was being drawn. Can anyone suggest something more sensible than that? - 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] i386: Selectable Frequency of the Timer Interrupt
On Mon, Jul 11, 2005 at 10:05:10AM -0400, Theodore Ts'o wrote: > The real answer here is for the tickless patches to cleaned up to > the point where they can be merged, and then we won't waste battery > power entering the timer interrupt in the first place. :-) Whilst conceptually this is a nice idea I've yet to see any viable code that overall has a lower cost. Tickless is a really nice idea for embedded devices and also paravirtualized hardware but I don't think anyone has it working well enough yet do they? - 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] compress the stack layout of do_page_fault(), x86
On Sat, Jul 09, 2005 at 04:41:16PM +0200, Ingo Molnar wrote: > this patch pushes the creation of a rare signal frame (SIGBUS or > SIGSEGV) into a separate function, thus saving stackspace in the > main do_page_fault() stackframe. The effect is 132 bytes less of > stack used by the typical do_page_fault() invocation - resulting in > a denser cache-layout. does the benefit actually show up anywhere? - 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] i386: Selectable Frequency of the Timer Interrupt
On Sat, Jul 09, 2005 at 02:49:43PM -0400, Lee Revell wrote: > BTW, Christoph Lameter, if you're seeing this, your mail is bouncing... my bad, i typoed it when i first send the original 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] i386: Selectable Frequency of the Timer Interrupt
On Sat, Jul 09, 2005 at 08:31:55PM +0200, Arjan van de Ven wrote: > it's a config option. Some distros ship 100 already, others 1000, > again others will do 250. Who does anything other than 1000 for a 2.6.x 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: [PATCH] i386: Selectable Frequency of the Timer Interrupt
On Fri, Jul 08, 2005 at 03:59:35PM -0700, Martin J. Bligh wrote: > I think we're talking between 2.6.12-git5 and 2.6.12-git6 right? I > can confirm more explicitly if really need be. 48s -> 45.5s elapsed. That's a huge difference (5%) --- what hardware is that on? - 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] i386: Selectable Frequency of the Timer Interrupt
On Fri, Jul 08, 2005 at 02:59:53PM -0700, Andrew Morton wrote: > > On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote: > ^^ > It's been over two weeks and nobody has complained about anything. Two weeks isn't that long IMO (I only just noticed myself). > Because 1000 is too high. How so? There have been comparatively few complaints about this since we switched quite some time ago. Strictly speaking I agree 1000 might be too high --- but we've had it for so long now, almost all over 2.5.x (I think?) and all of 2.6.x. - 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] i386: Selectable Frequency of the Timer Interrupt
On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote: > [PATCH] i386: Selectable Frequency of the Timer Interrupt [...] > +choice > + prompt "Timer frequency" > + default HZ_250 WHAT? The previous value here i386 is 1000 --- so why is the default 250. Changing the *default* time interrupt frequency in a stable series is *really* bad idea if you ask me. Now that this has hit mainline please consider applying: --- kernel/Kconfig.hz~ 2005-06-24 22:16:35.023986593 -0700 +++ kernel/Kconfig.hz 2005-07-08 14:46:35.428917597 -0700 @@ -4,7 +4,7 @@ choice prompt "Timer frequency" - default HZ_250 + default HZ_1000 help Allows the configuration of the timer frequency. It is customary to have the timer interrupt run at 1000 HZ but 100 HZ may be more - 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] char: Add Dell Systems Management Base driver
On Tue, Jul 05, 2005 at 07:13:34PM -0500, Doug Warzecha wrote: > This patch adds the Dell Systems Management Base driver. You keep posting this driver without explaining/showing how it's used. Could you perhaps give some more details here 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/
