[PATCH try #2] Blackfin on-chip NAND Flash Controller driver
This is the driver for latest Blackfin on-chip nand flash controller
- use nand_chip and mtd_info common nand driver interface
- provide both PIO and dma operation
- compiled with ezkit bf548 configuration
- use hardware 1-bit ECC
- tested with YAFFS2 and can mount YAFFS2 filesystem as rootfs
ChangeLog from try#1
- use hweight32() instead of count_bits()
- replace bf54x with bf5xx and BF54X with BF5XX
- compare against plat->page_size in 2 cases when enable hardware ECC
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/mtd/nand/Kconfig | 19 +
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/bf5xx_nand.c | 791 +
include/asm-blackfin/mach-bf548/dma.h |1 +
include/asm-blackfin/nand.h | 47 ++
5 files changed, 859 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/nand/bf5xx_nand.c
create mode 100644 include/asm-blackfin/nand.h
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 7992c43..3c88bb8 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -131,6 +131,25 @@ config MTD_NAND_AU1550
This enables the driver for the NAND flash controller on the
AMD/Alchemy 1550 SOC.
+config MTD_NAND_BF5XX
+ tristate "Blackfin on-chip NAND Flash Controller driver"
+ depends on BF54x && MTD_NAND
+ help
+ This enables the Blackfin on-chip NAND flash controller
+
+ No board specific support is done by this driver, each board
+ must advertise a platform_device for the driver to attach.
+
+ This driver can also be built as a module. If so, the module
+ will be called bf5xx-nand.
+
+config MTD_NAND_BF5XX_HWECC
+ bool "BF5XX NAND Hardware ECC"
+ depends on MTD_NAND_BF5XX
+ help
+ Enable the use of the BF5XX's internal ECC generator when
+ using NAND.
+
config MTD_NAND_RTC_FROM4
tristate "Renesas Flash ROM 4-slot interface board (FROM_BOARD4)"
depends on SH_SOLUTION_ENGINE
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index b16d234..e43d8d3 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_MTD_NAND_TOTO) += toto.o
obj-$(CONFIG_MTD_NAND_AUTCPU12)+= autcpu12.o
obj-$(CONFIG_MTD_NAND_EDB7312) += edb7312.o
obj-$(CONFIG_MTD_NAND_AU1550) += au1550nd.o
+obj-$(CONFIG_MTD_NAND_BF5XX) += bf5xx_nand.o
obj-$(CONFIG_MTD_NAND_PPCHAMELEONEVB) += ppchameleonevb.o
obj-$(CONFIG_MTD_NAND_S3C2410) += s3c2410.o
obj-$(CONFIG_MTD_NAND_DISKONCHIP) += diskonchip.o
diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
new file mode 100644
index 000..c5ce8a3
--- /dev/null
+++ b/drivers/mtd/nand/bf5xx_nand.c
@@ -0,0 +1,791 @@
+/* linux/drivers/mtd/nand/bf5xx_nand.c
+ *
+ * Copyright 2006-2007 Analog Devices Inc.
+ * http://blackfin.uclinux.org/
+ * Bryan Wu <[EMAIL PROTECTED]>
+ *
+ * Blackfin BF5xx on-chip NAND flash controler driver
+ *
+ * Derived from drivers/mtd/nand/s3c2410.c
+ * Copyright (c) 2007 Ben Dooks <[EMAIL PROTECTED]>
+ *
+ * Derived from drivers/mtd/nand/cafe.c
+ * Copyright © 2006 Red Hat, Inc.
+ * Copyright © 2006 David Woodhouse <[EMAIL PROTECTED]>
+ *
+ * Changelog:
+ * 12-Jun-2007 Bryan Wu: Initial version
+ * 18-Jul-2007 Bryan Wu:
+ * - ECC_HW and ECC_SW supported
+ * - DMA supported in ECC_HW
+ * - YAFFS tested as rootfs in both ECC_HW and ECC_SW
+ *
+ * TODO:
+ * Enable JFFS2 over NAND as rootfs
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "bf5xx-nand"
+#define DRV_VERSION"1.2"
+#define DRV_AUTHOR "Bryan Wu <[EMAIL PROTECTED]>"
+#define DRV_DESC "BF5xx on-chip NAND FLash Controller Driver"
+
+#ifdef CONFIG_MTD_NAND_BF5XX_HWECC
+static int hardware_ecc = 1;
+#else
+static int hardware_ecc;
+#endif
+
+static unsigned short bfin_nfc_pin_req[] = {P_NAND_CE, P_NAND_RB,
Re: [PATCH] Make rcutorture RNG use temporal entropy
Hi Paul, On Wed, 15 Aug 2007, Paul E. McKenney wrote: > > The locking used by get_random_bytes() can conflict with the > preempt_disable() and synchronize_sched() form of RCU. This patch changes > rcutorture's RNG to gather entropy from the new cpu_clock() interface > (relying on interrupts, preemption, daemons, and rcutorture's reader > thread's rock-bottom scheduling priority to provide useful entropy), > and also adds and EXPORT_SYMBOL_GPL() to make that interface available > to GPLed kernel modules such as rcutorture. Honestly, rcutorture goes to some amazing lengths just to have this randomizing-the-delays-that-read/write-test-threads-spend-inside-or- outside-the-critical-sections thing :-) Especially, seeing that synchro-test, the other "comparable" module, just doesn't bother with all this at all. (especially check out its load == interval == do_sched == 0 case! :-) So IMHO, considering that rcutorture isn't a "serious" user of randomness in the first place (of even a "fast-and-loose version" for that matter), you could consider a solution where you gather all the randomness you need at module_init time itself and save it somewhere, and then use it wherever you're calling into rcu_random()->cpu_clock() [ or get_random_bytes() ] in the current code. You could even make some trivial updates to those random numbers after every RCU_RANDOM_REFRESH uses, like present. Agreed, anybody running rcutorture isn't really looking for performance, but why call get_random_bytes() or cpu_clock() (and the smp_processor_id() + irq_save/restore + export_symbol() that goes with it) when it isn't _really_ "required" as such ... Just a suggestion, Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc4-mm1: mips compile error
* Adrian Bunk ([EMAIL PROTECTED]) wrote: > On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote: > >... > > Changes since 2.6.23-rc3-mm1: > >... > > git-mips.patch > >... > > git trees > >... > > <-- snip --> > > ... > CC arch/mips/kernel/asm-offsets.s > In file included from include2/asm/processor.h:22, > from include2/asm/thread_info.h:15, > from > /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/include/linux/thread_info.h:21, > from > /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/include/linux/preempt.h:9, > from > /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/include/linux/spinlock.h:49, > from > /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/include/linux/seqlock.h:29, > from > /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/include/linux/time.h:8, > from > /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/include/linux/timex.h:57, > from > /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/include/linux/sched.h:52, > from > /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/arch/mips/kernel/asm-offsets.c:13: > include2/asm/system.h:415:39: error: asm-generic/cmpxchg-local.h: No such > file or directory > make[2]: *** [arch/mips/kernel/asm-offsets.s] Error 1 > > <-- snip --> > Hello, It is because "Add cmpxchg64 and cmpxchg64_local to mips" has been added to the git-mips.patch, but it depends on "add-cmpxchg-local-to-generic-for-up.patch" which is not merged yet. It was an error in my series file. add-cmpxchg-local-to-generic-for-up.patch should come before these patches: i386-cmpxchg64-80386-80486-fallback.patch add-cmpxchg64-to-alpha.patch add-cmpxchg64-to-mips.patch add-cmpxchg64-to-powerpc.patch add-cmpxchg64-to-x86_64.patch Mathieu > > cu > Adrian > > -- > >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed > -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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: kconfig/kbuild rewite (Re: What's up with CONFIG_BLK_DEV?)
On Sunday 02 September 2007 6:51:50 am Sam Ravnborg wrote: > As for Kconfig the low hanging fruits are not in the tools but in the > structure of the Kconfig files. There are a lot that can be improved > with a decent effort but nobody has stepped up doing so. > The tools could be better too but if the root problem is the structure > of the Kconfig files this is where we should focus and not on the tools. On a semi-related note, I recently wrote a dumb little minimal python parser that converted all the menuconfig help to html: http://kernel.org/doc/menuconfig http://kernel.org/doc/make/menuconfig2html.py I did this by ignoring half of the structure of the files (I was only interested in the help text), but it occurs to me that my current script to create miniconfig files by repeatedly calling "allnoconfig": http://landley.net/hg/firmware/file/fe0e5b641cb4/sources/toys/miniconfig.sh Could probably be replaced by a python script to read the .config, parse the kconfig, understand the dependencies, and spit out the miniconfig, without _too_ much effort. I'll throw it on the todo heap after the other 12 projects I hope to get to this month... > For Kbuild I fail to see anything that demand a rewrite from a structure > view of the Kbuild files. > The Kbuild internal stuff is antoehr story - here a rewrite to a saner > language then GNU make syntax could improve hackability a lot. I agree about getting away from make, but I arrived at the conclusion from a different perspective. I believe make is starting to outlive its usefulness. Rampant opinion follows: Incremental builds are a developer convenience. Users who download the source code to open source projects but who aren't modifying the project tend to do "make all", and nothing else. Source build systems like gentoo generally don't have any "rebuild several variants of the same package incrementally" option, and for many packages changing configuration requires a "make clean" anyway. (Since make doesn't handle configuration dependencies, anybody who _does_ make that work without an intervening make clean implemented extensive infrastructure of their own, on top of make.) As far as release versions are concerned, all make provides is an expected user interface (./configure; make; make install). The infrastructure to calculate dependencies (make's reason to exist) is essentially useless during deployment of release versions. For 90% of the software packages out there, "make all" takes less than 10 seconds on modern hardware. Sometimes the ./configure step takes longer to run than the actual build. (The kernel is not one of these packages, but the kernel is probably the largest open source software development effort in history, at least in terms of the number of developers involved if not absolute code size.) So for all but the largest and most complicated software packages, make doesn't even significantly improve the lives of developers. And those large software packages tend to either reimplement make (XFree86 had ibuild, KDE did cmake, Apache has ant...) because for _large_ packages, make sucks. Kbuild can be seen as yet another such reimplementation, in this case built on top of gnu make rather than by replacing it. The most efficient way to build software these days is to feed all the .c files to gcc in one go, so the optimizer can work on the entire program in one big tree. This can give up about 10% smaller and faster code, assuming you have a few hundred megs of ram which essentially all new development systems do. It's also faster to do this than to do a normal "make all" because you don't re-exec gcc lots of times, and can stay cache-hot more. So for deployment builds, eliminating the granularity of make and batching the compile into larger chunks is functionally superior. This reduces make's job to "call gcc once for each output binary, then do any fancy linker stuff". Intermediate levels of granularity are available, for example the linux kernel source code already produces one .o file per directory (built-in.o). It could compile a directory at a time rather than a file at a time, and check that this one .o file is newer than every other file in the directory or else rebuild it, improving efficiency and reducing build complexity without requiring full 4-minute rebuilds. This is the same kind of "more intelligent batching" optimization people were doing back in the days of reel-to-reel tape. Ask Maddog about it sometime, he's got great stories. :) Using a faster non-optimizing compiler (like tcc) can build even large projects like the entire Linux kernel in the 10 second range. (For example, http://fabrice.bellard.free.fr/tcc/tccboot.html took 15 seconds to compile the linux kernel on a Pentium 4. A modern 64-bit core 2 duo is noticeably faster than this.) The resulting code has some downsides (inefficient, and tcc isn't finished yet: I'm still working on getting tcc
Re: [PATCH] linux-2.6.16.51 gzipped core dump patch
On Tue, Sep 04, 2007 at 12:04:37AM -0400, Pallewatta Mano-FPCD67 wrote: > This support was there in the 2.6.16.51 kernel. In fact there was no > call_usermodehelper_pipe(). So backport it, instead of creating an incompatible interface and headache when you eventually rebase to later 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] linux-2.6.16.51 gzipped core dump patch
This support was there in the 2.6.16.51 kernel. In fact there was no
call_usermodehelper_pipe().
Mano
-Original Message-
From: Al Viro [mailto:[EMAIL PROTECTED]
Sent: Monday, September 03, 2007 8:27 PM
To: Pallewatta Mano-FPCD67
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] linux-2.6.16.51 gzipped core dump patch
On Mon, Sep 03, 2007 at 10:32:00PM -0400, Pallewatta Mano-FPCD67 wrote:
> This patch was developed for embedded systems which had limited space
> for file storage. If an external process is to compress core files you
> will need to store those files somewhere first as core dump output
> cannot be directly fed to the stdin of compression program.
Why? Create a pipe, start a new process, put the reader struct file
into its descriptor table as stdin, do execve in new process and
pass the writer struct file to ->core_dump().
As the matter of fact, it's already done - see
lock_kernel();
ispipe = format_corename(corename, core_pattern, signr);
unlock_kernel();
if (ispipe) {
/* SIGPIPE can happen, but it's just never processed */
if(call_usermodehelper_pipe(corename+1, NULL, NULL,
)) {
printk(KERN_INFO "Core dump to %s pipe
failed\n",
corename);
goto fail_unlock;
}
} else
file = filp_open(corename,
O_CREAT | 2 | O_NOFOLLOW | O_LARGEFILE
| flag,
0600);
in do_coredump(). So take a look at fs/exec.c:format_corename() and see
what to feed for it in order to get the equivalent of your patch.
core_patttern is set by sysctl (just say
echo [whatever] >/proc/sys/kernel/core_pattern
and don't forget quoting, since | should be the first character to
indicate
that you want to pipe coredump through a helper).
I really don't see a reason to do that kind of work in the kernel,
embedded
system or not.
-
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] [ALSA] Added new pin config for first gen macbook.
On 9/3/07, Ivan N. Zlatev <[EMAIL PROTECTED]> wrote: > On 9/3/07, Ivan N. Zlatev <[EMAIL PROTECTED]> wrote: > > On 9/3/07, Takashi Iwai <[EMAIL PROTECTED]> wrote: > > > At Mon, 3 Sep 2007 15:55:18 +0530, > > > Abhijit Bhopatkar wrote: > > > > > > > > commit 5d5d3bc3eddf2ad97b2cb090b92580e7fed6cee1 changed all > > > > pin configs for intel macs, but it breaks sound on > > > > Macbook first > > > > > > Please elaborate how does it break. "it breaks sound" is too > > > ambigious like the most popular bug reports "sound doesn't work" :) Apologies for the terse report, On my macbook with latest kernels 1. Alsamixer is showing only three controlls in total, Master PCM and Digital. 2. There is absolutely no output sound what so ever. 3. There is no capture sound being captured either. Reverting back the pin config to the one in previous kernels is working (although not perfect e.g. to enable input sound we need to toggle the capture device to mic and linein atlease once, no idea whats the deal with that) I am willing to do whatever test you people want, though I do not know where to look for more info at this point. So please feel free direct me to arrive at a better soultion or better info. Thanks Abhijit PS: lspci -v shows 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) Subsystem: Unknown device 8384:7680 Flags: us master, fast devsel, latency 0, IRQ 21 Memory at 9044 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Let me know if you need output dump of other 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: [PATCH] linux-2.6.16.51 gzipped core dump patch
On Mon, Sep 03, 2007 at 10:32:00PM -0400, Pallewatta Mano-FPCD67 wrote:
> This patch was developed for embedded systems which had limited space
> for file storage. If an external process is to compress core files you
> will need to store those files somewhere first as core dump output
> cannot be directly fed to the stdin of compression program.
Why? Create a pipe, start a new process, put the reader struct file
into its descriptor table as stdin, do execve in new process and
pass the writer struct file to ->core_dump().
As the matter of fact, it's already done - see
lock_kernel();
ispipe = format_corename(corename, core_pattern, signr);
unlock_kernel();
if (ispipe) {
/* SIGPIPE can happen, but it's just never processed */
if(call_usermodehelper_pipe(corename+1, NULL, NULL, )) {
printk(KERN_INFO "Core dump to %s pipe failed\n",
corename);
goto fail_unlock;
}
} else
file = filp_open(corename,
O_CREAT | 2 | O_NOFOLLOW | O_LARGEFILE | flag,
0600);
in do_coredump(). So take a look at fs/exec.c:format_corename() and see
what to feed for it in order to get the equivalent of your patch.
core_patttern is set by sysctl (just say
echo [whatever] >/proc/sys/kernel/core_pattern
and don't forget quoting, since | should be the first character to indicate
that you want to pipe coredump through a helper).
I really don't see a reason to do that kind of work in the kernel, embedded
system or not.
-
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] Blackfin BF54x NAND Flash Controller driver
On Mon, 2007-09-03 at 13:57 -0400, Mike Frysinger wrote: > On 9/3/07, Bryan Wu <[EMAIL PROTECTED]> wrote: > > --- a/drivers/mtd/nand/Kconfig > > +++ b/drivers/mtd/nand/Kconfig > > @@ -131,6 +131,24 @@ config MTD_NAND_AU1550 > > +config MTD_NAND_BF54X > > + tristate "NAND Flash support for Blackfin BF54X SoC DSP" > > i'd just describe it as "Blackfin on-chip NAND" rather than sticking > in exact part numbers as i imagine we can extend it down the line > > > + This enables the NAND flash controller on the BF54X SoC DPSs > > "BF54X SoC DPSs" -> "BF54x SoC DSPs" > > > + No board specific support is done by this driver, each board > > + must advertise a platform_device for the driver to attach. > > should mention the module name when built as a module > I will get rid of this BF54X and use BF5XX for (BF54x and BF52x and future processor) > > +config MTD_NAND_BF54X_HWECC > > + bool "BF54X NAND Hardware ECC" > > + depends on MTD_NAND_BF54X > > + help > > + Enable the use of the BF54X's internal ECC generator when > > + using NAND. Early versions of the chip have had problems with > > + incorrect ECC generation, and if using these, the default of > > + software ECC is preferable. > > rather than advertising this, i'd just keep it in the driver ... > presumably there are anomaly #'s for when the ECC is wrong, so we can > make the code depend on those > -mike This option is quite common in the NAND driver. If there are anomaly #'s, code can still depend on those by using hardware_ecc varible. This option is very useful when someone need software_ecc. Thanks - Bryan Wu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE/RFC] Really Simple Really Fair Scheduler
Hi, On Mon, 3 Sep 2007, Ingo Molnar wrote: > > It's a variation of the sleeper bonus. [...] > > hm, where are its effects described in your explanation? Seems like a > key item. It has no direct effect on the correctness of the mathematical model, the time is initialized before the time is added to the model. What you're after is the effect on the behaviour, which wasn't my focus, so sorry, I didn't mention it. > > [...] Let's assume two running tasks which have been running for 95ms > > and 105ms and a time slice of 10ms, the average is thus 100ms. If the > > new task has been sleeping for a while it starts at 90ms, if the task > > had been running lately it doesn't get this bonus again. > > what happens if there are lots of such tasks? What limits the total > bonus? Every task gets a little more bonus, but it grows quite slowly, every task gets time_slice/task_cnt more than the previous one (assuming all tasks are started at the same time), so the 10th gets 2.82*time_slice, the 100th gets 5.18*time_slice, the 1000th gets 7.48*time_slice... I thought about it already and I didn't consider it a serious problem, however it's solvable if needed by keeping the bonus separate: avg = avg_exec_runtime(cfs_rq); se->time_norm = kclock_max(avg - time_slice, se->time_norm); se->bonus = avg - se->time_norm; cfs_rq->time_sum += avg; But the bonus also had to be undone when unqueueing the task: cfs_rq->time_sum -= se->time_norm + bonus; > > That would be equivalent to simply clearing wait_runtime in CFS. > > so my prototype patch is not an exact map of the nice-0 special-case of > your code? Would this be the correct thing then perhaps: > > + se->exec_runtime = > + max(avg_exec_runtime(cfs_rq), se->exec_runtime); You should substract the desired bonus here from the average as above and evtl. also store the given bonus separately. bye, Roman - 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] linux-2.6.16.51 gzipped core dump patch
This patch was developed for embedded systems which had limited space for file storage. If an external process is to compress core files you will need to store those files somewhere first as core dump output cannot be directly fed to the stdin of compression program. Imagine storing a 40 Meg core file in an embedded system. A few core files will fill up the file system and some core files can get corrupted too. Mano -Original Message- From: Al Viro [mailto:[EMAIL PROTECTED] Sent: Monday, September 03, 2007 6:38 PM To: Pallewatta Mano-FPCD67 Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] linux-2.6.16.51 gzipped core dump patch On Mon, Sep 03, 2007 at 08:49:00PM -0400, Pallewatta Mano-FPCD67 wrote: > Hi, > The attached patch is based on Jan Frey's previous patch posted in 2004 > for the Linux 2.4 kernel. It has been tested on X86 and MIPS platforms. > If the core pattern doesn't end in ".gz" it will be added to the name of > the core file. It's offered under GPL v2 without any warranties. If you > have any questions, please contact me directly at Mano.Pallewatta "at" > motorola.com. This is silly, IMO - why do in kernel what can be done in userland? External process can damn well gzip/bzip2/uuencode and post to alt.sex.cthulhu.binaries/ whatever. Just feed the usual data to its stdin... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH? fix SIGNAL_STOP_DEQUEUED vs SIGCONT race
> Yes, I also thought about something like this, but tried to avoid because > it adds some complications. OTOH, this is not the fast path. I agree it's not real pleasing, and would be glad to find better ideas. > I'll try to think a bit more about this, and update the patch according > to your comments. Looks like we don't need to check SIGNAL_GROUP_EXIT > here, we are doing this later anyway. I look forward to your next version. Thanks, Roland - 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: IP1000A network driver in Linux tree?
Dear All: Was IC Plus IP1000A Linux Driver in kernel tree or not? Our customer is pushing us to put it into kernel. Is there anything that we should do? Thanks. Best Regards, Jesse Huang -Original Message- From: Francois Romieu [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 12, 2007 6:50 AM To: Caio Marcelo Cc: [EMAIL PROTECTED] Subject: Re: IP1000A network driver in Linux tree? Caio Marcelo <[EMAIL PROTECTED]> : [...] > The "ipg" driver (for IP1000A) isn't part of Linux kernel tree today, > but looking at mailing lists I've found messages indicating that it > would be. Something happened? Is something missing to make it get into > Linux tree? Do you need help, I'm not an expert on the area (network > drivers) but I would be glad to help, or at least try to help :) You can clone a standard git tree of the kernel, then fetch the 'ipg' branch at: git://electric-eye.fr.zoreil.com/home/romieu/linux/linux-2.6-out It should be safe up to commit f66b763f55de7fa863beb954ccef9fe3b044955d After this commit... Well, I should really try my own dog food before advertising it :o) -- Ueimor - 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] linux-2.6.16.51 gzipped core dump patch
On Mon, Sep 03, 2007 at 08:49:00PM -0400, Pallewatta Mano-FPCD67 wrote: > Hi, > The attached patch is based on Jan Frey's previous patch posted in 2004 > for the Linux 2.4 kernel. It has been tested on X86 and MIPS platforms. > If the core pattern doesn't end in ".gz" it will be added to the name of > the core file. It's offered under GPL v2 without any warranties. If you > have any questions, please contact me directly at Mano.Pallewatta "at" > motorola.com. This is silly, IMO - why do in kernel what can be done in userland? External process can damn well gzip/bzip2/uuencode and post to alt.sex.cthulhu.binaries/ whatever. Just feed the usual data to its stdin... - 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.23-rc4-mm1: boot failure on HPC nx6325
On Mon, 2007-09-03 at 22:51 +0200, Rafael J. Wysocki wrote: > > Also it would be interesting whether the -hrt patchset on top of rc5 has > > the same problem: > > > > http://www.tglx.de/projects/hrtimers/2.6.23-rc5/patch-2.6.23-rc5-hrt1.patches.tar.bz2 > > This one boots normally. Thanks. that narrows down the wreckage window substantially. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL weasels and the atheros stink
On Monday 03 September 2007 20:23:37 David Schwartz wrote: > > Wrong - I said "You can't complain about Person A doing X when > > you let Person > > B do X without complaint". > > Yes, I can. There is no inconsistency between acting in one case and > failing to act in another. We need not act in every possible case where we > could act to preserve our right to act in a particular case. Sorry, I should have said that you cannot prosecute one person for doing something without prosecuting everyone that is doing it. Otherwise you have lost the case before it has started - no judge would allow such a one sided application of the law. > > To whit: you can't complain that Jiri has made > > changes to a dual-licensed "work" and only released his changes > > under one of > > the licenses on the work when somebody else - in this case Msr. > > Floeter - has > > done the same thing. > > First of all, I haven't complained about Jiri's changes. Second, I most > certainly can. I can complain about one murder without complaining about > every murder. There is no inconsistency whatsoever with acting in one case > without having to act in every other conceivable case. Sorry, this ties back to the original statement and the implied threats of legal action by Theo and backed up by almost every OpenBSD developer that has participated in this discussion. It's a mis-statement of mine - see above. If you are going to prosecute one person for doing something, you have to prosecute everyone who does it. > We can complain about or work to fight whatever injustices we like. There > is no obligation to address every equal, or greater, injustice before > working on the injustice of one's choice. Yes, of course. > > No, no confusion. You could care less about the code being dual-licensed. > > Your > > > choice of subjects 'GPL weasels' speaks volumes. > > *My* choice of subjects?! You seem to have me confused with someone else > entirely. Potentially - I am terrible with names and had assumed that you were the person who had forked the "Stealing Our Code" thread with the "GPL weasels" subject. If my assumption is faulty, then I apologize and ask your forgiveness for my false accusation. > My sole points in this thread were to: > > 1) Correct some misunderstandings about how dual licenses actually work. This was, IIRC, already well understood by most of the people on the Linux Kernel side of things. (Alan Cox has given several quite lucid statements showing that he, at least, does understand this) > 2) Explain *why* a file cannot really remain dual-licensed if it's part of > the Linux kernel distribution. A file/files can have as many licenses on it as the developer wants, provided that at least one of them is the GPL(v2). That is because, for it to be legally distributed as part of the Linux Kernel it has to be done so under the auspices of the license on the Linux Kernel - the GPLv2. > While I generally prefer the BSD license to the GPL license and tend to be > a pretty vocal GPL critic, I have said many times that almost any > *consistent* license is better for a large project than different licenses, > even if they're compatible, on different files. I am critical of the GPL myself, as is Linus and a lot of people. (Linus himself has said, numerous times, that he is "no fan of the GPL, but it is the best that exists" (his words and opinion) - and I have heard similar sentiments from a lot of people.) I am not a fan of the BSD license because I'd like to be able to incorporate any changes someone might make back into the original code. There is no requirement in the BSD license for someone to make their changes to my code available to me - so I am not a fan of it. > > Doesn't matter if the BSD license or the GPL *PERMITS* it or not. The > > fact remains that the person making a work available under *ANY* form of > > copyright > > > license has the right to revoke said grant of license to anyone. The GPL > > codifies certain situations in which the person would not, personally, > > have > > > to revoke the license, but does not limit the original copyright holders > > rights (in that regard) in any way. > > I'm not sure where you're getting this from, but it's not true. Linus > cannot decide tomorrow that nobody can distribute the Linux kernel anymore. In the US you have to explicitly waive rights for you to not have them (in regards to licenses). Although, considering what I have been informed of in regards to the law in Poland (and, seeing as how this has surprised a lot of people, likely a large number of other countries), to make sure those rights are "reserved" they should be explicitly spelled out in the text of the license. And the truth is that Linus could do that - if he required contributors to do a copyright assignment (which would make him the holder of the sole copyright on the Linux Kernel). Since Linus is *NOT* the sole copyright holder on Linux, he cannot do this. He
[PATCH] linux-2.6.16.51 gzipped core dump patch
Hi, The attached patch is based on Jan Frey's previous patch posted in 2004 for the Linux 2.4 kernel. It has been tested on X86 and MIPS platforms. If the core pattern doesn't end in ".gz" it will be added to the name of the core file. It's offered under GPL v2 without any warranties. If you have any questions, please contact me directly at Mano.Pallewatta "at" motorola.com. Regards, Methlal (Mano) Pallewatta gzipped_core_dump.patch Description: gzipped_core_dump.patch
RE: GPL weasels and the atheros stink
> Wrong - I said "You can't complain about Person A doing X when > you let Person > B do X without complaint". Yes, I can. There is no inconsistency between acting in one case and failing to act in another. We need not act in every possible case where we could act to preserve our right to act in a particular case. > To whit: you can't complain that Jiri has made > changes to a dual-licensed "work" and only released his changes > under one of > the licenses on the work when somebody else - in this case Msr. > Floeter - has > done the same thing. First of all, I haven't complained about Jiri's changes. Second, I most certainly can. I can complain about one murder without complaining about every murder. There is no inconsistency whatsoever with acting in one case without having to act in every other conceivable case. We can complain about or work to fight whatever injustices we like. There is no obligation to address every equal, or greater, injustice before working on the injustice of one's choice. > No, no confusion. You could care less about the code being dual-licensed. Your > choice of subjects 'GPL weasels' speaks volumes. *My* choice of subjects?! You seem to have me confused with someone else entirely. My sole points in this thread were to: 1) Correct some misunderstandings about how dual licenses actually work. 2) Explain *why* a file cannot really remain dual-licensed if it's part of the Linux kernel distribution. While I generally prefer the BSD license to the GPL license and tend to be a pretty vocal GPL critic, I have said many times that almost any *consistent* license is better for a large project than different licenses, even if they're compatible, on different files. > Doesn't matter if the BSD license or the GPL *PERMITS* it or not. The fact > remains that the person making a work available under *ANY* form of copyright > license has the right to revoke said grant of license to anyone. The GPL > codifies certain situations in which the person would not, personally, have > to revoke the license, but does not limit the original copyright holders > rights (in that regard) in any way. I'm not sure where you're getting this from, but it's not true. Linus cannot decide tomorrow that nobody can distribute the Linux kernel anymore. DS - 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: Fwd: That whole "Linux stealing our code" thing
On Monday 03 September 2007 15:33:01 Krzysztof Halasa wrote: > Daniel Hazelton <[EMAIL PROTECTED]> writes: > > I hate to belabor the point, but you seem to be making the mistake of > > "The license applies to the copyright holder" > > Of course not. I'll take this at face value - I might have mis-parsed your earlier statements wrong. > > The person holding the copyright has all the legal standing to revoke a > > license grant at any time. > > Based on? US Copyright law. A copyright holder, regardless of what license he/she may have released the work under, can still revoke the license for a specific person or group of people. (There are some exceptions, but they do not apply to the situation that is being discussed) > > Licenses such as the GPL are not signed contracts, > > and that means there are limits to what effect they can have on the > > copyright > > holder. > > Perhaps that is your local laws, but I'd be surprised anyway. I wouldn't. The US Legal system is rather twisted. > Do you sign contracts when shopping, or are you (and the shop) > allowed to "revoke" the transaction after it's made (I'm not > talking about shop's return policy)? A purchase is separate from a grant of copyright under license. If I purchase a book I have the right to read the book and I have the right to sell the book to someone else, but I have no other rights to it. But if I purchase something, there are rights that go along with said purchase. Under a license such as the GPL (I can't say the same for the BSD/ISC license - I haven't spent enough time studying it to know for sure) no money need change hands for access to the program *and* source. All the rights that anyone *BESIDES* the copyright holder have to the program and/or source comes from license. But since money has not changed hands, there is no further set of rights or guarantees - the copyright holder has not, in general, sold a copy of the work or granted any guarantee that the license will not be revoked. > Is what you wrote only valid WRT licences? Yes. For contracts there is slightly different set of laws in play. > Which country has such laws BTW? The USA. > > In Poland, I can't just go and "revoke" a "statement of will" > if I haven't explicite reserved a right to do so. > Obviously I can act contrary to the statement, and be held liable. Ah, see - in the US the license(s) in question (and licenses in general) are grants of rights, not a "statements of will". If there are to be any limits on the rights of the copyright holder, under US law, they have to be explicitly stated in the license itself. (Truthfully, in the US a license should be read with an implicit "All rights reserved") DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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 1/1] Unionfs: cache-coherency - dentries
From: Erez Zadok <[EMAIL PROTECTED]>
Utility functions to check if lower dentries/inodes are newer than upper
ones, and purging cached data if lower objects are newer. Also passed flag
to our d_revalidate_chain, to tell it if the caller may be writing data or
just reading it.
[jsipek: changed purge_inode_data to take a struct inode]
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/commonfops.c |2 +-
fs/unionfs/dentry.c | 143 ++-
fs/unionfs/inode.c | 24 +---
fs/unionfs/rename.c |4 +-
fs/unionfs/super.c |2 +-
fs/unionfs/union.h |5 +-
fs/unionfs/unlink.c | 12 +++-
fs/unionfs/xattr.c |8 +-
8 files changed, 164 insertions(+), 36 deletions(-)
diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 28cb4e9..0dc7492 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -287,7 +287,7 @@ int unionfs_file_revalidate(struct file *file, int
willwrite)
* but not unhashed dentries.
*/
if (!d_deleted(dentry) &&
- !__unionfs_d_revalidate_chain(dentry, NULL)) {
+ !__unionfs_d_revalidate_chain(dentry, NULL, willwrite)) {
err = -ESTALE;
goto out_nofree;
}
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index 4a3c479..d937329 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -23,19 +23,18 @@
* Assume that dentry's info node is locked.
* Assume that parent(s) are all valid already, but
* the child may not yet be valid.
- * Returns 1 if valid, 0 otherwise.
+ * Returns true if valid, false otherwise.
*/
-static int __unionfs_d_revalidate_one(struct dentry *dentry,
+static bool __unionfs_d_revalidate_one(struct dentry *dentry,
struct nameidata *nd)
{
- int valid = 1; /* default is valid (1); invalid is 0. */
+ bool valid = true; /* default is valid */
struct dentry *lower_dentry;
int bindex, bstart, bend;
int sbgen, dgen;
int positive = 0;
int locked = 0;
int interpose_flag;
-
struct nameidata lowernd; /* TODO: be gentler to the stack */
if (nd)
@@ -128,7 +127,7 @@ static int __unionfs_d_revalidate_one(struct dentry *dentry,
interpose_flag);
if (result) {
if (IS_ERR(result)) {
- valid = 0;
+ valid = false;
goto out;
}
/*
@@ -142,7 +141,7 @@ static int __unionfs_d_revalidate_one(struct dentry *dentry,
if (positive && UNIONFS_I(dentry->d_inode)->stale) {
make_bad_inode(dentry->d_inode);
d_drop(dentry);
- valid = 0;
+ valid = false;
goto out;
}
goto out;
@@ -158,12 +157,12 @@ static int __unionfs_d_revalidate_one(struct dentry
*dentry,
|| !lower_dentry->d_op->d_revalidate)
continue;
if (!lower_dentry->d_op->d_revalidate(lower_dentry,
- ))
- valid = 0;
+ ))
+ valid = false;
}
if (!dentry->d_inode)
- valid = 0;
+ valid = false;
if (valid) {
/*
@@ -184,12 +183,94 @@ out:
}
/*
+ * Determine if the lower inode objects have changed from below the unionfs
+ * inode. Return 1 if changed, 0 otherwise.
+ */
+bool is_newer_lower(const struct dentry *dentry)
+{
+ int bindex;
+ struct inode *inode;
+ struct inode *lower_inode;
+
+ /* ignore if we're called on semi-initialized dentries/inodes */
+ if (!dentry || !UNIONFS_D(dentry))
+ return false;
+ inode = dentry->d_inode;
+ if (!inode || !UNIONFS_I(inode) ||
+ ibstart(inode) < 0 || ibend(inode) < 0)
+ return false;
+
+ for (bindex = ibstart(inode); bindex <= ibend(inode); bindex++) {
+ lower_inode = unionfs_lower_inode_idx(inode, bindex);
+ if (!lower_inode)
+ continue;
+ /*
+* We may want to apply other tests to determine if the
+* lower inode's data has changed, but checking for changed
+* ctime and mtime on the lower inode should be enough.
+*/
+ if (timespec_compare(>i_mtime,
+_inode->i_mtime) < 0) {
+ printk("unionfs: new lower inode mtime "
+ "(bindex=%d,
Re: [PATCH 03/32] VFS/fsstack: cpp endif comments
On Mon, Sep 03, 2007 at 08:39:27AM +0200, Jan Engelhardt wrote: > > On Sep 2 2007 22:20, Josef 'Jeff' Sipek wrote: > >diff --git a/include/linux/fs_stack.h b/include/linux/fs_stack.h > >index 6b52faf..28543ad 100644 > >--- a/include/linux/fs_stack.h > >+++ b/include/linux/fs_stack.h > >@@ -39,4 +39,4 @@ static inline void fsstack_copy_attr_times(struct inode > >*dest, > > dest->i_ctime = src->i_ctime; > > } > > > >-#endif /* _LINUX_FS_STACK_H */ > >+#endif /* not _LINUX_FS_STACK_H */ > > I hardly think this changes a thing, and it even goes against > the de-facto standard of a lot of other files. Fair enough. I'm going to drop it. Jeff. -- My public GPG key can be found at http://www.josefsipek.net/gpg/public-0xC7958FFE.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer dereference - nfs v3
Hi David, On Fri, 27 Jul 2007, David CHANIAL wrote: > > Le vendredi 20 juillet 2007 15:36, Satyam Sharma a ecrit: > > Yes, you can apply the patch Neil just sent to your kernel, > > re-build, and test that. > > Hi, I have no patched the kernel as asked by Neil, but i would notice > that > with 2.6.22.1 kernel it continue to happend : > > http://internetworkpro.org/pastebin/765 > > I would patch the kernel now and wait to see... Did you test with that patch applied? Did you manage to hit the BUG again (with or without it)? Neil, I don't see this one applied upstream as yet -- if this patch indeed solves the oops David saw again (as per the link he has posted) then I'd suggest it be pushed upstream (and -stable too). Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HIMEM calculation
James C. Georgas wrote: I'm not sure I understand how the kernel calculates the amount of physical RAM it can map during the boot process. I've quoted two blocks of kernel messages below, one for a kernel with NOHIGHMEM and another for a kernel with HIGHMEM4G. If I do the math on the BIOS provided physical RAM map, there is less than 5MiB of the address space reserved. Since I only have 1GiB of physical RAM in the board, I figured that it would still be possible to physically map 1019MiB, even with the 3GiB/1GiB split between user space and kernel space that occurs with NOHIGHMEM. However, What actually happens is that I'm 127MiB short of a full GiB. What am I missing here? Why does that last 127MiB have to go in HIGHMEM? That's the vmalloc address space. You only get 896 MB in the NORMAL zone on i386, to leave room for vmalloc. If you don't like it, go 64-bit. -- Chris - 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: [lm-sensors] [PATCH] hwmon: Add power meters to Documentation/hwmon/sysfs-interface
On Mon, 03 Sep 2007, Jean Delvare wrote: > On Sun, 2 Sep 2007 23:02:01 -0300, Henrique de Moraes Holschuh wrote: > > On Sun, 02 Sep 2007, Jean Delvare wrote: > > > I guess power[1-*]_average would be OK? > > > > AFAIK, yes. It is probably not 100% in sync with the power supply class, > > though. > > Is the power supply class creating sysfs files? I see a number of > attributes listed in Documentation/power_supply_class.txt, but they are > all uppercase, which doesn't seem suitable for sysfs file names. That > document also doesn't list the numbering convention when multiple > channels are present. Looks like power supply needs some tweaks, then. > My main worry is that we will have to add support for power measurement > in libsensors, and I would like it to be as easy as possible. Thus > sticking to the same naming convention hwmon have been using for years > appears to be the best solution. Agreed. > I see that the power supply class units are 10^-6 A and 10^-6 W, so if > we are supposed to be compatible, I guess we'll have to use this too. There was a good reason for that, and people who deal with small portables said that they needed 10^-4 A or somesuch, at which point it makes more sense to just go to 10^-6 already. I don't recall why 10^-6 W, though. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - 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: ramdisk
Xu Yang wrote: thanks for the reply. no , it is not decompressed. isn' t the kernel supposed to do that? As we have tried to load this filesystem on the pc, it turns out the the kernel can recognize it. concerning the root=/dev/ram0, as the default value is root=/dev/nfs, so I just modify the nfs to ram0. is this might be a problem? Hopefully someone who works with this regularly can provide some answers, the only time I used booting into a RAM-only system the tools which I had "just worked" and I followed the steps outlined without fully understanding the details. However, I just tried loop mounting a compressed filesystem and that didn't work, while decompressing into a ramdisk and mounting worked fine. That's why I asked if your tool was just copying to RAM without decompression, since I have no ides what tool you use. As for the name, your original post used "dev" without a leading "/" and while I assumed it was a typo, I thought it was worth mentioning since you were looking for suggestions. I would expect /dev/ram0 to be correct. I would try the decompressed image next, and I have no other ideas at the moment. regards, 2007/9/3, Bill Davidsen <[EMAIL PROTECTED]>: Xu Yang wrote: Hi everyone, I want to use ramdisk to boot my filesystem, as I can't use NFS and harddisk. I have load the ramdisk into the ram memory (start address :0x400) and in the boot options I specified : root =dev/ram0 initrd=0x400 but the kernel said it can not find any file system on it. Looking at the information below, did the program which loaded the filesystem into RAM decompress it? It noted that it was compressed so I would assume so, but I am unfamiliar with ARM tools, so I ask the question. Also, should the boot device be "/dev/ram0" rather than "dev/ram0" or is that correct for your system? Here is the information I can supply : U-Boot 1.2.0 (Aug 31 2007 - 20:54:55) *** Auto-detects ethernet chip *** DRAM: 0 kB ## Unknown FLASH on Bank 1 - Size = 0x = 0 MB Flash: 0 kB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 ## Booting image at 7fc0 ... Image Name: Linux-2.6.19-arm2 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:740372 Bytes = 723 kB Load Address: 8000 Entry Point: 8000 OK ## Loading Ramdisk Image at 0400 ... Image Name: ramdisc Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size:12582962 Bytes = 12 MB Load Address: 0400 Entry Point: 0400 Starting kernel ... . RAMDISK driver initialized: 16 RAM disks of 10240K size 1024 blocksize <6>loop: loaded (max 8 devices) <6>mice: PS/2 mouse device common for all mice <6>VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 3 No filesystem could mount root, tried: ext2 cramfs vfat <0>Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Who can give me some hints ? or point me some direction to handle this. I appreciate this very much. regards, Yang -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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/
HIMEM calculation
I'm not sure I understand how the kernel calculates the amount of physical RAM it can map during the boot process. I've quoted two blocks of kernel messages below, one for a kernel with NOHIGHMEM and another for a kernel with HIGHMEM4G. If I do the math on the BIOS provided physical RAM map, there is less than 5MiB of the address space reserved. Since I only have 1GiB of physical RAM in the board, I figured that it would still be possible to physically map 1019MiB, even with the 3GiB/1GiB split between user space and kernel space that occurs with NOHIGHMEM. However, What actually happens is that I'm 127MiB short of a full GiB. What am I missing here? Why does that last 127MiB have to go in HIGHMEM? Message log for a NOHIGHMEM kernel: Sep 3 16:56:50 Tachyon kernel: Linux version 2.6.22-gentoo-r5 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1)) #2 PREEMPT Mon Sep 3 16:01:08 EDT 2007 Sep 3 16:56:50 Tachyon kernel: BIOS-provided physical RAM map: Sep 3 16:56:50 Tachyon kernel: BIOS-e820: - 0009fc00 (usable) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: 0009fc00 - 000a (reserved) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: 0010 - 3ffd3000 (usable) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: 3ffd3000 - 4000 (reserved) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: feda - fee0 (reserved) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: ffb8 - 0001 (reserved) Sep 3 16:56:50 Tachyon kernel: Warning only 896MB will be used. Sep 3 16:56:50 Tachyon kernel: Use a HIGHMEM enabled kernel. Sep 3 16:56:50 Tachyon kernel: 896MB LOWMEM available. Sep 3 16:56:50 Tachyon kernel: Zone PFN ranges: Sep 3 16:56:50 Tachyon kernel: DMA 0 -> 4096 Sep 3 16:56:50 Tachyon kernel: Normal 4096 -> 229376 Sep 3 16:56:50 Tachyon kernel: early_node_map[1] active PFN ranges Sep 3 16:56:50 Tachyon kernel: 0:0 -> 229376 Sep 3 16:56:50 Tachyon kernel: DMI 2.3 present. Message log for a HIGHMEM4G kernel: Sep 3 17:40:53 Tachyon kernel: BIOS-provided physical RAM map: Sep 3 17:40:53 Tachyon kernel: BIOS-e820: - 0009fc00 (usable) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: 0009fc00 - 000a (reserved) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: 0010 - 3ffd3000 (usable) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: 3ffd3000 - 4000 (reserved) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: feda - fee0 (reserved) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: ffb8 - 0001 (reserved) Sep 3 17:40:53 Tachyon kernel: 127MB HIGHMEM available. Sep 3 17:40:53 Tachyon kernel: 896MB LOWMEM available. Sep 3 17:40:53 Tachyon kernel: Zone PFN ranges: Sep 3 17:40:53 Tachyon kernel: DMA 0 -> 4096 Sep 3 17:40:53 Tachyon kernel: Normal 4096 -> 229376 Sep 3 17:40:53 Tachyon kernel: HighMem229376 -> 262099 Sep 3 17:40:53 Tachyon kernel: early_node_map[1] active PFN ranges Sep 3 17:40:53 Tachyon kernel: 0:0 -> 262099 Sep 3 17:40:53 Tachyon kernel: DMI 2.3 present. - 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: [pre-2.6.23 REGRESSION] 2.6.23-rc3-git1 crash/stuck on VIA CN700 system
Stefan Becker <[EMAIL PROTECTED]> writes: > while trying to debug a hibernation/rtc_cmos alarm wakeup problem in > 2.6.22 (or later) I noticed that the latest kernel crashes (or gets > stuck sometimes) during boot after the message: > > SMP alternatives: switching to UP code > > Every kernel up to 2.6.22.1 works fine on the system. Does the problem start with 2.6.22.2 or with 2.6.23-rc? The first sentence conflicts with the last one. > I've attached > the log file taken from the serial console (4 boot attempts with > different acpi= options) and the .config of the kernel. The kernel is > from the Fedora 8 development line. Please report for mainline kernels. -Andi - 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.23-rc4-mm1
Hi,
On Mon, 3 Sep 2007, Wim Van Sebroeck wrote:
>
> >
> > on x86_64:
> > drivers/watchdog/core/watchdog_dev.c:84:
> > warning: format '%i' expects type 'int', but argument 5 has type 'size_t'
Hmm, a warning I missed during my Sunday evening pastime.
> I'll have a look at it.
How about ... (unrelated cleanup thrown in, but SCNR)
* Fix this warning:
drivers/watchdog/core/watchdog_dev.c:84:
warning: format '%i' expects type 'int', but argument 5 has type 'size_t'
* CONFIG_xxx options are directly usable by preprocessor directives.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/watchdog/core/Makefile |5 -
drivers/watchdog/core/watchdog_dev.c |6 +++---
2 files changed, 3 insertions(+), 8 deletions(-)
--- linux-2.6.23-rc4-mm1/drivers/watchdog/core/Makefile~fix 2007-09-04
03:12:27.0 +0530
+++ linux-2.6.23-rc4-mm1/drivers/watchdog/core/Makefile 2007-09-04
03:12:45.0 +0530
@@ -4,8 +4,3 @@
# The Generic Watchdog Driver
obj-$(CONFIG_WATCHDOG_CORE)+= watchdog_core.o watchdog_dev.o
-
-ifeq ($(CONFIG_WATCHDOG_DEBUG_CORE), y)
-EXTRA_CFLAGS += -DDEBUG
-endif
-
--- linux-2.6.23-rc4-mm1/drivers/watchdog/core/watchdog_dev.c~fix
2007-09-04 02:37:12.0 +0530
+++ linux-2.6.23-rc4-mm1/drivers/watchdog/core/watchdog_dev.c 2007-09-04
03:10:58.0 +0530
@@ -36,7 +36,7 @@
#include /* For __init/__exit/... */
#include /* For copy_to_user/put_user/... */
-#ifdef DEBUG
+#ifdef CONFIG_WATCHDOG_DEBUG_CORE
#define trace(format, args...) \
printk(KERN_INFO "%s(" format ")\n", __FUNCTION__ , ## args)
#define dbg(format, arg...) \
@@ -81,7 +81,7 @@ static DEFINE_MUTEX(watchdog_register_mt
static ssize_t watchdog_write(struct file *file, const char __user *data,
size_t len, loff_t *ppos)
{
- trace("%p, %p, %i, %p", file, data, len, ppos);
+ trace("%p, %p, %zu, %p", file, data, len, ppos);
if (!watchdogdev ||
!watchdogdev->watchdog_ops ||
@@ -144,7 +144,7 @@ static int watchdog_ioctl(struct inode *
.identity = "Watchdog Device",
};
- trace("%p, %p, %i, %li", inode, file, cmd, arg);
+ trace("%p, %p, %u, %li", inode, file, cmd, arg);
if (!watchdogdev || !watchdogdev->watchdog_ops)
return -ENODEV;
-
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 -mm 2/2] 3c59x MAINTAINERS
Remove duplicate entry for the same driver. Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> --- MAINTAINERS |6 -- 1 file changed, 6 deletions(-) --- linux-2.6.23-rc4-mm1/MAINTAINERS~fix2007-09-04 03:49:16.0 +0530 +++ linux-2.6.23-rc4-mm1/MAINTAINERS2007-09-04 03:49:28.0 +0530 @@ -104,12 +104,6 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] S: Maintained -3C59X NETWORK DRIVER -P: Steffen Klassert -M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -S: Maintained - 3CR990 NETWORK DRIVER P: David Dillow M: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input: i8042 - add HP Pavilion DV4270ca to the MUX blacklist
This fixes "atkbd.c: Suprious NAK on isa0060/serio0" errors for
HP Pavilion DV4270ca. Same reasons as for
9d9d50bb2efb50594abfc3941a5504b62c514ebd
and 6e782584e0713ea89da151333e7fe754c8f40324.
Signed-off-by: Elvis Pranskevichus <[EMAIL PROTECTED]>
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index 702a526..f8fe421 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -211,6 +211,16 @@ static struct dmi_system_id __initdata
i8042_dmi_nomux_table[] = {
},
},
{
+ /*
+* Like DV4017EA does not raise AUXERR for errors on MUX ports.
+*/
+ .ident = "HP Pavilion DV4270ca",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Pavilion dv4000
(EH476UA#ABL)"),
+ },
+ },
+ {
.ident = "Toshiba P10",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
--
1.5.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 -mm 1/2] 3c59x: Fix uninitialized variable bug
drivers/net/3c59x.c: In function 'vortex_up':
drivers/net/3c59x.c:1495: warning: 'err' may be used uninitialized in this
function
is a genuine bug. The function returns an uninitialized value of 'err'
back to the caller, which expects it to be 0 for success cases. Let's
fix this by explicitly initializing 'err' to zero.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/net/3c59x.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.23-rc4-mm1/drivers/net/3c59x.c~fix2007-09-04
03:29:40.0 +0530
+++ linux-2.6.23-rc4-mm1/drivers/net/3c59x.c2007-09-04 03:30:08.0
+0530
@@ -1492,7 +1492,8 @@ vortex_up(struct net_device *dev)
struct vortex_private *vp = netdev_priv(dev);
void __iomem *ioaddr = vp->ioaddr;
unsigned int config;
- int i, mii_reg1, mii_reg5, err;
+ int i, mii_reg1, mii_reg5;
+ int err = 0;
if (VORTEX_PCI(vp)) {
pci_set_power_state(VORTEX_PCI(vp), PCI_D0);/* Go active */
-
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.23-rc5
Alessandro Suardi wrote: > > [snip] > > This one has bitten many of us :) > > http://lkml.org/lkml/2007/9/2/219 Thx , I didn't saw that patch. Gabriel - 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: Hang in 2.6.23-rc5
Here is a relevant oops for this hang. [ 7329.832382] BUG: unable to handle kernel NULL pointer dereference at virtual address 0025 [ 7329.934755] printing eip: [ 7329.967145] 802cb921 [ 7329.993347] *pde = [ 7330.026799] Oops: [#1] [ 7330.060246] Modules linked in: usblp ipt_MASQUERADE iptable_nat nf_nat ipt_LOG xt_limit xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables pppoe pppox ppp_generic slhc dvb_pll cx22702 usbhid tuner hid cx88_dvb video_buf_dvb dvb_core cx8800 cx8802 cx88_alsa cx88xx ir_common i2c_algo_bit tveeprom i2c_core videodev compat_ioctl32 v4l2_common v4l1_compat video_buf ehci_hcd uhci_hcd btcx_risc usbcore [ 7330.518076] CPU:0 [ 7330.518077] EIP:0060:[<802cb921>]Not tainted VLI [ 7330.518079] EFLAGS: 00210246 (2.6.23-rc5-dirty #72) [ 7330.669129] EIP is at tcp_rto_min+0xb/0x16 [ 7330.718088] eax: 0032 ebx: d76b5ab0 ecx: 209d edx: [ 7330.799277] esi: d76b5ab0 edi: ebp: 803ecdd8 esp: 803ecdd8 [ 7330.880468] ds: 007b es: 007b fs: gs: 0033 ss: 0068 [ 7330.950225] Process firefox-bin (pid: 2625, ti=803ec000 task=d1bfcaa0 task.ti=d1bfd000) [ 7331.043890] Stack: 803ecde8 802cb9e8 d76b5ab0 d76b5ab0 803ecdf4 802cc1e2 803bc3e0 803ece6c [ 7331.144727]802cd85f 03ccf75e 208b3367 291abfc5 6eaa5ef6 d6c52818 [ 7331.245564]0001 03ccf6f4 eddd6e3e 03ccf75e 0001 0001 803eceac 03ccf75e [ 7331.346403] Call Trace: [ 7331.377800] [<80102abd>] show_trace_log_lvl+0x1a/0x2f [ 7331.439343] [<80102b6d>] show_stack_log_lvl+0x9b/0xa3 [ 7331.500885] [<80102d1f>] show_registers+0x1aa/0x278 [ 7331.560349] [<80102ed5>] die+0xe8/0x205 [ 7331.607336] [<802f0bea>] do_page_fault+0x469/0x53a [ 7331.665761] [<802ef73a>] error_code+0x6a/0x70 [ 7331.718987] [<802cb9e8>] tcp_rtt_estimator+0xbc/0x102 [ 7331.780529] [<802cc1e2>] tcp_ack_saw_tstamp+0x17/0x47 [ 7331.842071] [<802cd85f>] tcp_ack+0x6a5/0x1731 [ 7331.895298] [<802d11be>] tcp_rcv_established+0x353/0x5f5 [ 7331.959959] [<802d6358>] tcp_v4_do_rcv+0x2f/0x2fa [ 7332.017344] [<802d8413>] tcp_v4_rcv+0x6d1/0x71a [ 7332.072650] [<802c0919>] ip_local_deliver+0x12d/0x17c [ 7332.134193] [<802c07c0>] ip_rcv+0x40b/0x437 [ 7332.185339] [<802ac6b0>] netif_receive_skb+0x161/0x1ac [ 7332.247921] [<802ae63a>] process_backlog+0x71/0xda [ 7332.306345] [<802ae6f9>] net_rx_action+0x56/0xd5 [ 7332.362690] [<80114514>] __do_softirq+0x38/0x7a [ 7332.417995] [<801039cd>] do_softirq+0x41/0x91 [ 7332.471223] === [ 7332.513947] Code: e4 8b 82 54 03 00 00 89 82 f8 04 00 00 a1 30 e7 39 80 89 82 fc 04 00 00 83 c4 10 5b 5e 5f c9 c3 55 8b 50 64 b8 32 00 00 00 89 e5 42 25 20 74 03 8b 42 54 c9 c3 55 85 d2 b9 01 00 00 00 0f 45 [ 7332.746397] EIP: [<802cb921>] tcp_rto_min+0xb/0x16 SS:ESP 0068:803ecdd8 [ 7332.825845] Kernel panic - not syncing: Fatal exception in interrupt > Try this from net-2.6 tree: > > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -560,7 +560,7 @@ static u32 tcp_rto_min(struct sock *sk) > struct dst_entry *dst = __sk_dst_get(sk); > u32 rto_min = TCP_RTO_MIN; > > - if (dst_metric_locked(dst, RTAX_RTO_MIN)) > + if (dst && dst_metric_locked(dst, RTAX_RTO_MIN)) > rto_min = dst->metrics[RTAX_RTO_MIN-1]; > return rto_min; > } Looks like this is the fix. I'm recompiling with it now. Robert - 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: kconfig/kbuild rewite (Re: What's up with CONFIG_BLK_DEV?)
On Sun, Sep 02, 2007 at 01:51:50PM +0200, Sam Ravnborg wrote: [] > Then as now you have not yet expalined what you are trying to do. > Nevertheless I look forward for a minmal set of patches that improve > whatever you are working with. Yes, because it's LKML, that wants not-hand-waving stuff in first place. But recent kevent, scheduler stuff shows inflexibility/agendas, though. That examples were bad WRT kernel production infrastructure. Even then i doubt, i must waste everyone's time with details, only goals. > As for Kconfig the low hanging fruits are not in the tools but in the > structure of the Kconfig files. There are a lot that can be improved > with a decent effort but nobody has stepped up doing so. > The tools could be better too but if the root problem is the structure > of the Kconfig files this is where we should focus and not on the tools. In my view this all interconnected. Designing flexible and easy configuration system yields dramatic changes to the build one as well. * profiles non/debug, non/production * per file, per algorithm tuning * efficiency * choosing structure sizes * selecting fast/slow paths * per case choosing need/dead code * various parameters * optimization * per compiler/version * option profiles * feature/warning sets * linker * is there anything alternative? * distributed development * open possibility to work in any part of the tree * making changes and quickly having * config (dependency, etc.) set/UI ready * per profile/option test builds (e.g. making return->goto or loop change and quickly getting -O0, -O2, -Os images; check size; have userspace testing skeleton -> have runtime test) * integration with quilt-like source/patch managers ``here'' * allow per architecture development * small source tree * developer's profiles, that will have exact feature/tuning/build config options results for everybody within given source tree version (for easy testing, but not "send me your .config; what binutils?..") * base set of tools to have easy to configure alternatives * shell to use basic POSIX (plus accepted, not NIH like in bash) features (i have some examples; unfortunately even basic set behaves differently and buggy) * make stat() wrapper executing shell everywhere; of course there are some features, but anyway, interface for it and the like is needed * perl/python/ruby establish text processing rules * coreutils/busybox/etc non is perfect, having replacement mechanism allows faster debug and enhancement of their own development and testing * UI (maybe next time) Only one thing. I don't have time and will to study all that ncurses/slang/qt/gtk/AJAX/whatever stuff. I wanted to do basic terminal or text/stream editor friendly user interface. As for the former, i just upset about software capabilities of the todays terminal emulators. I'm fine with exchanging escape sequences, but all that inherited TEKTRONIX 4010, APL, HP2645, Microterm ACT-IV, Ann Arbor 4080, LSI ADM-3a (man terminfo) legacy without even a hint of progress last 20 years is just dead. I likely to end up with shell script generation, that will be available for everybody who knows shell and have ordinary text editor. autoconf/configure inside out? Maybe, but at least from the new sheet of paper, with good background in history and basic text processing tools. Just in case anybody cares about how ugly modern software development is (INA software industry dude, and may be just crazy, of course). Well, recent Rusty's gig may give a clue, how things may look different. > For Kbuild I fail to see anything that demand a rewrite from a structure > view of the Kbuild files. > The Kbuild internal stuff is antoehr story - here a rewrite to a saner > language then GNU make syntax could improve hackability a lot. - 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.23-rc5
On 9/3/07, Gabriel C <[EMAIL PROTECTED]> wrote: > Rafael J. Wysocki wrote: > > On Sunday, 2 September 2007 09:54, Prakash Punnoor wrote: > >> Hi, > >> > >> 2.6.23-rc5 locks up hard (Magic Syskeys won't even work) after a few > >> minutes > >> of work on x86_64. 2.6.23-rc4 was fine. I'll try git-bisect to find out > >> what > >> is causing trouble. Yes, I am using nvidia binary but it didn't make > >> troubles > >> since ages... When I found the bugger, I'll try whether it works w/o nvidia > >> binary. > > > > Just for the record, I'm running -rc5 on two x86_64 boxes without any > > visible > > issue. > > > > I don't use any binary graphics drivers, though. > > 2.6.23-rc5 dies here random[1] too .. on 2 Dell boxes ( i686 not x86_64 here > ) which I upgraded to rc5 yesterday. > > When dies 'Caps Lock and Scroll Lock' blinks and the box lockups hard .. rc4 > got an 7 days uptime on both with the same config , > kernel compiled with same gcc/glibc/binutils etc. [snip] This one has bitten many of us :) http://lkml.org/lkml/2007/9/2/219 --alessandro "I can't believe you if I can't hear you" (Editors, 'Smokers Outside The Hospital Doors') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE/RFC] Really Fair Scheduler
On Mon, 2007-09-03 at 20:20 +0200, Roman Zippel wrote: > Basically that's it and I hope that explains the basic math a bit easier. :-) > It helps a tiny bit .. However, I appreciate that you took the time to write this .. Thanks you. Daniel - 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/5] Use macros instead of TASK_ flags
On Sat, Sep 01, 2007 at 10:46:51PM -0400, Matthew Wilcox wrote:
> Abstracting away direct uses of TASK_ flags allows us to change the
> definitions of the task flags more easily.
>
> Also restructure do_wait() a little
>
> Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
> ---
> arch/ia64/kernel/perfmon.c |4 +-
> fs/proc/array.c|9 +---
> fs/proc/base.c |2 +-
> include/linux/sched.h | 15 +++
> include/linux/wait.h | 11 +++--
> kernel/exit.c | 90 +++
> kernel/power/process.c |7 +--
> kernel/ptrace.c|8 ++--
> kernel/sched.c | 15 +++
> kernel/signal.c|6 +-
> kernel/wait.c |2 +-
> 11 files changed, 83 insertions(+), 86 deletions(-)
Here's a replacement patch 2/5, including fixes for the problems spotted
by Daniel and myself. A machine running a kernel including these patches
has been up for more than 24 hours.
commit 10287ac5d615a2ccca6611426572259ebc69dc92
Author: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Sat Sep 1 09:31:22 2007 -0400
Use macros instead of TASK_ flags
Abstracting away direct uses of TASK_ flags allows us to change the
definitions of the task flags more easily.
Also restructure do_wait() a little
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c
index 14b8e5a..3690c46 100644
--- a/arch/ia64/kernel/perfmon.c
+++ b/arch/ia64/kernel/perfmon.c
@@ -2637,7 +2637,7 @@ pfm_task_incompatible(pfm_context_t *ctx, struct
task_struct *task)
*/
if (task == current) return 0;
- if ((task->state != TASK_STOPPED) && (task->state != TASK_TRACED)) {
+ if (!is_task_stopped_or_traced(task)) {
DPRINT(("cannot attach to non-stopped task [%d] state=%ld\n",
task->pid, task->state));
return -EBUSY;
}
@@ -4797,7 +4797,7 @@ recheck:
* the task must be stopped.
*/
if (PFM_CMD_STOPPED(cmd)) {
- if ((task->state != TASK_STOPPED) && (task->state !=
TASK_TRACED)) {
+ if (!is_task_stopped_or_traced(task)) {
DPRINT(("[%d] task not in stopped state\n", task->pid));
return -EBUSY;
}
diff --git a/fs/proc/array.c b/fs/proc/array.c
index ee4814d..6a3c876 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -140,13 +140,8 @@ static const char *task_state_array[] = {
static inline const char *get_task_state(struct task_struct *tsk)
{
- unsigned int state = (tsk->state & (TASK_RUNNING |
- TASK_INTERRUPTIBLE |
- TASK_UNINTERRUPTIBLE |
- TASK_STOPPED |
- TASK_TRACED)) |
- (tsk->exit_state & (EXIT_ZOMBIE |
- EXIT_DEAD));
+ unsigned int state = (tsk->state & TASK_REPORT) |
+ (tsk->exit_state & (EXIT_ZOMBIE | EXIT_DEAD));
const char **p = _state_array[0];
while (state) {
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 19489b0..3155ef1 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -196,7 +196,7 @@ static int proc_root_link(struct inode *inode, struct
dentry **dentry, struct vf
(task == current || \
(task->parent == current && \
(task->ptrace & PT_PTRACED) && \
-(task->state == TASK_STOPPED || task->state == TASK_TRACED) && \
+(is_task_stopped_or_traced(task)) && \
security_ptrace(current,task) == 0))
static int proc_pid_environ(struct task_struct *task, char * buffer)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index f4e324e..ea509e9 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -176,6 +176,21 @@ print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq
*cfs_rq)
#define TASK_NONINTERACTIVE64
#define TASK_DEAD 128
+/* Convenience macros for the sake of wake_up */
+#define TASK_NORMAL(TASK_INTERRUPTIBLE | TASK_UNINTERRUPTIBLE)
+#define TASK_ALL (TASK_NORMAL | TASK_STOPPED | TASK_TRACED)
+
+/* get_task_state() */
+#define TASK_REPORT(TASK_RUNNING | TASK_INTERRUPTIBLE | \
+TASK_UNINTERRUPTIBLE | TASK_STOPPED | \
+TASK_TRACED)
+
+#define is_task_traced(task) ((task->state & TASK_TRACED) != 0)
+#define is_task_stopped(task) ((task->state & TASK_STOPPED) != 0)
+#define is_task_stopped_or_traced(task)\
+ ((task->state & (TASK_STOPPED | TASK_TRACED)) != 0)
+#define is_task_loadavg(task) ((task->state & TASK_UNINTERRUPTIBLE) != 0)
+
#define __set_task_state(tsk, state_value) \
do { (tsk)->state =
[PATCH] 9p: attach-per-user
The 9P2000 protocol requires the authentication and permission checks to be
done in the file server. For that reason every user that accesses the file
server tree has to authenticate and attach to the server separately.
Multiple users can share the same connection to the server.
Currently v9fs does a single attach and executes all I/O operations as a
single user. This makes using v9fs in multiuser environment unsafe as it
depends on the client doing the permission checking.
This patch improves the 9P2000 support by allowing every user to attach
separately. The patch defines three modes of access (new mount option
'access'):
- attach-per-user (access=user)
If a user tries to access a file served by v9fs for the first time, v9fs
sends an attach command to the server (Tattach) specifying the user. If
the attach succeeds, the user can access the v9fs tree.
As there is no uname->uid (string->integer) mapping yet, this mode works
only with the 9P2000.u dialect.
- allow only one user to access the tree (access=)
Only the user with uid can access the v9fs tree. Other users that attempt
to access it will get EPERM error.
- do all operations as a single user (access=any)
V9fs does a single attach and all operations are done as a single user.
If this mode is selected, the v9fs behavior is identical with the current
one.
The patch also renames uid and gid options to dfltuid and dfltgid. The new
names describe better the values they set.
Signed-off-by: Latchesar Ionkov <[EMAIL PROTECTED]>
---
commit 836f166ce5578b084c1cd75807e29474586bab61
tree c7e1eb631c3e6b0f1cd773ae7884379776c2857d
parent 3ec910913c8c743cbe4cd9cdde17df26a75d02ec
author Latchesar Ionkov <[EMAIL PROTECTED](none)> Mon, 03 Sep 2007 14:09:29
-0600
committer Latchesar Ionkov <[EMAIL PROTECTED](none)> Mon, 03 Sep 2007 14:09:29
-0600
fs/9p/fid.c | 157 +--
fs/9p/v9fs.c| 87 +++---
fs/9p/v9fs.h| 27 +++-
fs/9p/vfs_inode.c | 52
include/net/9p/9p.h |7 +-
include/net/9p/client.h |5 +
net/9p/client.c | 10 ++-
net/9p/conv.c | 32 --
8 files changed, 278 insertions(+), 99 deletions(-)
diff --git a/fs/9p/fid.c b/fs/9p/fid.c
index 15e05a1..b16b14b 100644
--- a/fs/9p/fid.c
+++ b/fs/9p/fid.c
@@ -1,6 +1,7 @@
/*
* V9FS FID Management
*
+ * Copyright (C) 2007 by Latchesar Ionkov <[EMAIL PROTECTED]>
* Copyright (C) 2005, 2006 by Eric Van Hensbergen <[EMAIL PROTECTED]>
*
* This program is free software; you can redistribute it and/or modify
@@ -34,9 +35,9 @@
#include "fid.h"
/**
- * v9fs_fid_insert - add a fid to a dentry
+ * v9fs_fid_add - add a fid to a dentry
+ * @dentry: dentry that the fid is being added to
* @fid: fid to add
- * @dentry: dentry that it is being added to
*
*/
@@ -66,52 +67,144 @@ int v9fs_fid_add(struct dentry *dentry, struct p9_fid *fid)
}
/**
- * v9fs_fid_lookup - return a locked fid from a dentry
+ * v9fs_fid_find - retrieve a fid that belongs to the specified uid
* @dentry: dentry to look for fid in
- *
- * find a fid in the dentry, obtain its semaphore and return a reference to it.
- * code calling lookup is responsible for releasing lock
- *
- * TODO: only match fids that have the same uid as current user
+ * @uid: return fid that belongs to the specified user
+ * @any: if non-zero, return any fid associated with the dentry
*
*/
-struct p9_fid *v9fs_fid_lookup(struct dentry *dentry)
+static struct p9_fid *v9fs_fid_find(struct dentry *dentry, u32 uid, int any)
{
struct v9fs_dentry *dent;
- struct p9_fid *fid;
-
- P9_DPRINTK(P9_DEBUG_VFS, " dentry: %s (%p)\n", dentry->d_iname, dentry);
- dent = dentry->d_fsdata;
- if (dent)
- fid = list_entry(dent->fidlist.next, struct p9_fid, dlist);
- else
- fid = ERR_PTR(-EBADF);
+ struct p9_fid *fid, *ret;
+
+ P9_DPRINTK(P9_DEBUG_VFS, " dentry: %s (%p) uid %d any %d\n",
+ dentry->d_iname, dentry, uid, any);
+ dent = (struct v9fs_dentry *) dentry->d_fsdata;
+ ret = NULL;
+ if (dent) {
+ spin_lock(>lock);
+ list_for_each_entry(fid, >fidlist, dlist) {
+ if (any || fid->uid == uid) {
+ ret = fid;
+ break;
+ }
+ }
+ spin_unlock(>lock);
+ }
- P9_DPRINTK(P9_DEBUG_VFS, " fid: %p\n", fid);
- return fid;
+ return ret;
}
/**
- * v9fs_fid_clone - lookup the fid for a dentry, clone a private copy and
- * release it
+ * v9fs_fid_lookup - lookup for a fid, try to walk if not found
* @dentry: dentry to look for fid in
*
- * find a fid in the dentry and then clone to a new private fid
- *
- * TODO: only match fids that have the same uid as current user
- *
+ * Look for a fid in the
Re: [PATCH] i386 and x86_64: randomize brk()
On Mon, 3 Sep 2007, Franck Bui-Huu wrote:
> > > +/* overriden by architectures supporting brk randomization */
> > > +void __weak arch_randomize_brk(struct mm_struct *mm) { }
> I was actually suggesting in my last email:
> unsigned long randomize_brk(unsigned long brk)
> therefore arch specific code don't have to know about implementation
> details ie how to retrieve brk values from a mm. And it also matches
> the prototype of arch_align_stack().
OK, I personally don't care that much. Andrew, the version as per Franck's
suggestion is below. It should be functionally equivalent to the patch
sent in my previous message in this thread, please consider merging one of
them. Thanks a lot.
From: Jiri Kosina <[EMAIL PROTECTED]>
i386 and x86_64: randomize brk()
This patch randomizes the location of the heap (brk) for i386 and x86_64.
The range is randomized in the range starting at current brk location up
to 0x0200 offset for both architectures. This, together with
pie-executable-randomization.patch and
pie-executable-randomization-fix.patch, should make the address space
randomization on i386 and x86_64 complete.
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
index 8466471..8e0624d 100644
--- a/arch/i386/kernel/process.c
+++ b/arch/i386/kernel/process.c
@@ -949,3 +949,17 @@ unsigned long arch_align_stack(unsigned long sp)
sp -= get_random_int() % 8192;
return sp & ~0xf;
}
+
+unsigned long arch_randomize_brk(unsigned long brk)
+{
+ unsigned long new_brk;
+ unsigned long range_end;
+
+ range_end = brk + 0x0200;
+ new_brk = randomize_range(brk, range_end, 0);
+ if (new_brk)
+ return new_brk;
+ else
+ return brk;
+}
+
diff --git a/arch/x86_64/kernel/process.c b/arch/x86_64/kernel/process.c
index 2842f50..b20f0eb 100644
--- a/arch/x86_64/kernel/process.c
+++ b/arch/x86_64/kernel/process.c
@@ -902,3 +902,17 @@ unsigned long arch_align_stack(unsigned long sp)
sp -= get_random_int() % 8192;
return sp & ~0xf;
}
+
+unsigned long arch_randomize_brk(unsigned long brk)
+{
+ unsigned long new_brk;
+ unsigned long range_end;
+
+ range_end = brk + 0x0200;
+ new_brk = randomize_range(brk, range_end, 0);
+ if (new_brk)
+ return new_brk;
+ else
+ return brk;
+}
+
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d65f1d9..7afec71 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -47,6 +47,9 @@ static int load_elf_binary(struct linux_binprm *bprm, struct
pt_regs *regs);
static int load_elf_library(struct file *);
static unsigned long elf_map (struct file *, unsigned long, struct elf_phdr *,
int, int, unsigned long);
+/* overriden by architectures supporting brk randomization */
+unsigned long __weak arch_randomize_brk(unsigned long brk) { return brk; }
+
/*
* If we don't support core dumping, then supply a NULL so we
* don't even try.
@@ -1073,6 +1076,10 @@ static int load_elf_binary(struct linux_binprm *bprm,
struct pt_regs *regs)
current->mm->end_data = end_data;
current->mm->start_stack = bprm->p;
+ if (current->flags & PF_RANDOMIZE)
+ current->mm->brk = current->mm->start_brk =
+ arch_randomize_brk(current->mm->brk);
+
if (current->personality & MMAP_PAGE_ZERO) {
/* Why this, you ask??? Well SVr4 maps page 0 as read-only,
and some applications "depend" upon this behavior.
-
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.23-rc4-mm1: boot failure on HPC nx6325
On Monday, 3 September 2007 10:36, Thomas Gleixner wrote: > On Sun, 2007-09-02 at 22:39 +0200, Rafael J. Wysocki wrote: > > On Saturday, 1 September 2007 06:58, Andrew Morton wrote: > > > - dynticks-for-x86_64 has returned > > > > It fails to boot on my HPC nx6325 (hangs very early, before any messages > > reach > > the console), because of this patch: > > > > x86_64-convert-to-clockevents.patch > > Sigh. Can you try > > noapictimer > nohpet > > on the kernel commandline please ? > > Also it would be interesting whether the -hrt patchset on top of rc5 has > the same problem: > > http://www.tglx.de/projects/hrtimers/2.6.23-rc5/patch-2.6.23-rc5-hrt1.patches.tar.bz2 This one boots normally. Greetings, Rafael - 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 -mm] ipc namespace: remove config ipc ns fix
Finish the work : kill all #ifdef CONFIG_IPC_NS.
Thanks Robert !
C.
Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Cc: Eric Biederman <[EMAIL PROTECTED]>
Cc: Robert P. J. Day <[EMAIL PROTECTED]>
---
ipc/ipc_sysctl.c |4
1 file changed, 4 deletions(-)
Index: 2.6.23-rc4-mm1/ipc/ipc_sysctl.c
===
--- 2.6.23-rc4-mm1.orig/ipc/ipc_sysctl.c
+++ 2.6.23-rc4-mm1/ipc/ipc_sysctl.c
@@ -15,7 +15,6 @@
#include
#include
-#ifdef CONFIG_IPC_NS
static void *get_ipc(ctl_table *table)
{
char *which = table->data;
@@ -23,9 +22,6 @@ static void *get_ipc(ctl_table *table)
which = (which - (char *)_ipc_ns) + (char *)ipc_ns;
return which;
}
-#else
-#define get_ipc(T) ((T)->data)
-#endif
#ifdef CONFIG_PROC_FS
static int proc_ipc_dointvec(ctl_table *table, int write, struct file *filp,
-
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/4] 2.6.23-rc4: known regressions
Takashi Iwai schrieb: > At Wed, 29 Aug 2007 18:42:56 +0300, > Ivan N. Zlatev wrote: > > ... but without the hardware :-< > > IMO, this is actually no real regression. In the earlier verison, you > didn't have controls for multiple outputs, thus the mixer control was > named as Master. Now you do have multiple individual controls, and > thus there is no master any more, instead. That's the trade-off. > Konnichiwa. Ok. Seen from this viewpoint this is no real regression. But do you have an idea how can i fix my setup? Currently i have these .Xmodmap key bindings: keycode 174 = XF86AudioLowerVolume keycode 176 = XF86AudioRaiseVolume keycode 160 = XF86AudioMute Some kde component while take care of the "XF86AudioLowerVolume" and "XF86AudioRaiseVolume" events and change the value of the "master" volume control. This is still happening with 2.6.23-rc5, but the master volume, stopped to be connected with the build-in speakers. When i connect headphones to my notebook the "MacBook-Volume-Up" and "MacBook-Volume-Down" keys still work, but they stopped to work with the build-in speaker, but will work with the headphones plugged in. The problem is, that i use the build-in speakers more often than the headphones. When a headphone is connected the build-in speakers go silent. And i agree with Mr. Juhl that a master volume control should control both outputs, i.e. built-in speakers and headphones. Any ideas? mfg thomas - 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: [Lguest] [RFC] 9p Virtualization Transports
On 9/1/07, Rusty Russell <[EMAIL PROTECTED]> wrote: > On Tue, 2007-08-28 at 13:52 -0500, Eric Van Hensbergen wrote: > > The lguest and kvm transports are functional, but we are still working out > > remaining bugs and need to spend some time focusing on performance issues. > > I wanted to send out this "preview" patch set to the community to solicit > > ideas on things we can do differently/better. > > Patches look reasonable, but just a heads-up: lguest will be moving to > virtio, as will kvm. That means a single implementation for both > (yay!), but it does complicate your life in the short term 8( > > Dor has published a kvm virtio implementation, and we've already > discussed a couple of modifications. I expect that to be nailed in the > next 2 weeks tho, and lguest will follow. > yeah, I've been emailing Dor -- it sounds like he'll have stuff ready for the 2.6.24 merge window -- that being the case, I'll write a virtio transport and mothball the PCI and lguest transports. They were straightforward to write (a couple hours for the lguest transport) and the lguest transport was a good learning experience -- so I'm not shedding tears over wasted effort. -eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix preemptible lazy mode bug
On Sat, 2007-09-01 at 14:09 -0700, Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
> > Do you agree it is better to be safe than sorry in this case? The
> > kind of bugs introduced by getting this wrong are really hard to find,
> > and I would rather err on the side of an extra increment and decrement
> > of preempt_count that causing a regression.
>
> I think this patch is the direction we should go. I this this would
> work equally well for the other pv implementations; it would probably go
> into the common lazy mode logic when we get around to doing it.
Well, here's the (untested) hoisting patch...
===
Hoist per-cpu lazy_mode variable up into common code.
VMI, Xen and lguest all track paravirt_lazy_mode individually, meaning
we hand a "magic" value for set_lazy_mode() to say "flush if currently
active".
We can simplify the logic by hoisting this variable into common code.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 072a0b3924fb arch/i386/kernel/vmi.c
--- a/arch/i386/kernel/vmi.cThu Aug 30 04:47:43 2007 +1000
+++ b/arch/i386/kernel/vmi.cTue Sep 04 05:36:11 2007 +1000
@@ -554,22 +554,14 @@ vmi_startup_ipi_hook(int phys_apicid, un
static void vmi_set_lazy_mode(enum paravirt_lazy_mode mode)
{
- static DEFINE_PER_CPU(enum paravirt_lazy_mode, lazy_mode);
-
if (!vmi_ops.set_lazy_mode)
return;
/* Modes should never nest or overlap */
- BUG_ON(__get_cpu_var(lazy_mode) && !(mode == PARAVIRT_LAZY_NONE ||
-mode == PARAVIRT_LAZY_FLUSH));
-
- if (mode == PARAVIRT_LAZY_FLUSH) {
- vmi_ops.set_lazy_mode(0);
- vmi_ops.set_lazy_mode(__get_cpu_var(lazy_mode));
- } else {
- vmi_ops.set_lazy_mode(mode);
- __get_cpu_var(lazy_mode) = mode;
- }
+ BUG_ON(get_lazy_mode() && !(mode == PARAVIRT_LAZY_NONE |
+ | mode == PARAVIRT_LAZY_FLUSH));
+
+ vmi_ops.set_lazy_mode(mode);
}
static inline int __init check_vmi_rom(struct vrom_header *rom)
diff -r 072a0b3924fb arch/i386/xen/enlighten.c
--- a/arch/i386/xen/enlighten.c Thu Aug 30 04:47:43 2007 +1000
+++ b/arch/i386/xen/enlighten.c Tue Sep 04 05:37:14 2007 +1000
@@ -52,8 +52,6 @@
EXPORT_SYMBOL_GPL(hypercall_page);
-DEFINE_PER_CPU(enum paravirt_lazy_mode, xen_lazy_mode);
-
DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info);
DEFINE_PER_CPU(unsigned long, xen_cr3);
@@ -255,23 +253,16 @@ static void xen_set_lazy_mode(enum parav
switch (mode) {
case PARAVIRT_LAZY_NONE:
- BUG_ON(x86_read_percpu(xen_lazy_mode) == PARAVIRT_LAZY_NONE);
+ BUG_ON(get_lazy_mode() == PARAVIRT_LAZY_NONE);
break;
case PARAVIRT_LAZY_MMU:
case PARAVIRT_LAZY_CPU:
- BUG_ON(x86_read_percpu(xen_lazy_mode) != PARAVIRT_LAZY_NONE);
+ BUG_ON(get_lazy_mode() != PARAVIRT_LAZY_NONE);
break;
-
- case PARAVIRT_LAZY_FLUSH:
- /* flush if necessary, but don't change state */
- if (x86_read_percpu(xen_lazy_mode) != PARAVIRT_LAZY_NONE)
- xen_mc_flush();
- return;
}
xen_mc_flush();
- x86_write_percpu(xen_lazy_mode, mode);
}
static unsigned long xen_store_tr(void)
@@ -358,7 +349,7 @@ static void xen_load_tls(struct thread_s
* loaded properly. This will go away as soon as Xen has been
* modified to not save/restore %gs for normal hypercalls.
*/
- if (xen_get_lazy_mode() == PARAVIRT_LAZY_CPU)
+ if (x86_read_percpu(paravirt_lazy_mode) == PARAVIRT_LAZY_CPU)
loadsegment(gs, 0);
}
diff -r 072a0b3924fb arch/i386/xen/multicalls.h
--- a/arch/i386/xen/multicalls.hThu Aug 30 04:47:43 2007 +1000
+++ b/arch/i386/xen/multicalls.hTue Sep 04 05:37:52 2007 +1000
@@ -35,7 +35,7 @@ void xen_mc_flush(void);
/* Issue a multicall if we're not in a lazy mode */
static inline void xen_mc_issue(unsigned mode)
{
- if ((xen_get_lazy_mode() & mode) == 0)
+ if ((get_lazy_mode() & mode) == 0)
xen_mc_flush();
/* restore flags saved in xen_mc_batch */
diff -r 072a0b3924fb arch/i386/xen/xen-ops.h
--- a/arch/i386/xen/xen-ops.h Thu Aug 30 04:47:43 2007 +1000
+++ b/arch/i386/xen/xen-ops.h Tue Sep 04 05:29:20 2007 +1000
@@ -29,13 +29,6 @@ unsigned long long xen_sched_clock(void)
void xen_mark_init_mm_pinned(void);
-DECLARE_PER_CPU(enum paravirt_lazy_mode, xen_lazy_mode);
-
-static inline unsigned xen_get_lazy_mode(void)
-{
- return x86_read_percpu(xen_lazy_mode);
-}
-
void __init xen_fill_possible_map(void);
void __init xen_setup_vcpu_info_placement(void);
diff -r 072a0b3924fb drivers/lguest/lguest.c
--- a/drivers/lguest/lguest.c Thu Aug 30 04:47:43 2007 +1000
+++ b/drivers/lguest/lguest.c Tue Sep 04 05:32:24 2007 +1000
@@
Re: [PATCH] Make rcutorture RNG use temporal entropy
On Mon, Sep 03, 2007 at 08:29:04AM -0500, Matt Mackall wrote: > On Mon, Aug 27, 2007 at 06:15:54PM -0700, Paul E. McKenney wrote: > > On Thu, Aug 23, 2007 at 02:40:37PM -0500, Matt Mackall wrote: > > > Yes. Using a hash function rather than a trivial LFSR is preferable. > > > But pulling the guts out and giving it an n-bytes interface like > > > get_random_bytes(). > > > > OK. But this cannot be the first discussion of getting a fast and loose > > version of get_random_bytes() into the kernel. Anyplace I should look > > for cautionary tales? A quick search located a spirited discussion of > > proposed kernel infrastructure for user-mode random number generation > > back in 2003, but... > > > > Also a 2006 proposal from Stephan Eranian: http://lkml.org/lkml/2006/8/23/41 > > This appears to have gotten zero replies. :-/ (Though not hash-based.) > > You probably did the same searches I would do, so no, don't have any > pointers, just vague recollections. I was afraid of that. ;-) > > Other semi-related threads: > > > > http://lkml.org/lkml/2005/3/15/102 > > http://lkml.org/lkml/2004/9/23/337 > > > > Some years back, my reflexive design would have been per-CPU state, > > accessed with interrupts disabled. Not so good for realtime usage, > > though. One could go with per-task state in order to avoid the > > interrupt disabling, which might be OK if the state is quite small. > > We only need be concerned here with locking insofar as we'd produce > duplicate output without it. So it's fairly easy to imagine a lockless > design using percpu data and perhaps folding in the preemption state. And if we have a hash on the output, conflicting updates to the state should be tolerable as well. Still want per-CPU state in order to avoid cache thrashing, of course, but should be able to avoid preemption disabling. So the trick will be getting a performance/size/entropy tradeoff that 75% of the current roll-your-own random-number-generator uses can live with. Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE/RFC] Really Simple Really Fair Scheduler
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Mon, 3 Sep 2007, Ingo Molnar wrote:
>
> > My next question then is about this code of yours in the wakeup path:
> >
> > +static void
> > +enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
> > +{
> > + kclock_t min_time;
> > +
> > + verify_queue(cfs_rq, cfs_rq->curr != se, se);
> > + min_time = get_time_avg(cfs_rq) - se->req_weight_inv;
> > + if ((kclock_t)(se->time_norm - min_time) < 0)
> > + se->time_norm = min_time;
> >
> > why do you only use the "min_time" if the pre-sleep time_norm is smaller
> > than the min_time? Here 'min_time' is close to the current average.
>
> It's a variation of the sleeper bonus. [...]
hm, where are its effects described in your explanation? Seems like a
key item.
> [...] Let's assume two running tasks which have been running for 95ms
> and 105ms and a time slice of 10ms, the average is thus 100ms. If the
> new task has been sleeping for a while it starts at 90ms, if the task
> had been running lately it doesn't get this bonus again.
what happens if there are lots of such tasks? What limits the total
bonus?
> > Shouldnt here the woken up task be set to the average time, like i
> > did it in the crude prototype:
> >
> > + se->exec_runtime = avg_exec_runtime(cfs_rq);
>
> That would be equivalent to simply clearing wait_runtime in CFS.
so my prototype patch is not an exact map of the nice-0 special-case of
your code? Would this be the correct thing then perhaps:
+ se->exec_runtime =
+ max(avg_exec_runtime(cfs_rq), se->exec_runtime);
Or if not, could you suggest a code-line at that place? Thanks,
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE/RFC] Really Simple Really Fair Scheduler
Hi,
On Mon, 3 Sep 2007, Ingo Molnar wrote:
> My next question then is about this code of yours in the wakeup path:
>
> +static void
> +enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
> +{
> + kclock_t min_time;
> +
> + verify_queue(cfs_rq, cfs_rq->curr != se, se);
> + min_time = get_time_avg(cfs_rq) - se->req_weight_inv;
> + if ((kclock_t)(se->time_norm - min_time) < 0)
> + se->time_norm = min_time;
>
> why do you only use the "min_time" if the pre-sleep time_norm is smaller
> than the min_time? Here 'min_time' is close to the current average.
It's a variation of the sleeper bonus. Let's assume two running tasks
which have been running for 95ms and 105ms and a time slice of 10ms, the
average is thus 100ms. If the new task has been sleeping for a while it
starts at 90ms, if the task had been running lately it doesn't get this
bonus again.
> Shouldnt here the woken up task be set to the average time, like i did
> it in the crude prototype:
>
> + se->exec_runtime = avg_exec_runtime(cfs_rq);
That would be equivalent to simply clearing wait_runtime in CFS.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: libata not working for sis5533
Jan Engelhardt ha scritto: > On Sep 2 2007 11:40, Alan Cox wrote: > >>> i've been out for a week, but found no notice, did i lost any email or >>> no activity on this issue? >>> >> I tagged it onto the obscure IDE report pile. It doesn't contain any >> really useful information and its probably not an IDE layer bug as of >> itself. But its on the todo list for further investigation and to see if >> patterns emerge >> > > I shall give this a spin too, since I happen to have sis5513. > > oops i just noticed i made a typo in the subject...5513 for me too Patrizio - 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: [-mm PATCH] Memory controller improve user interface (v3)
Paul Menage wrote: > On 9/2/07, Balbir Singh <[EMAIL PROTECTED]> wrote: >> - s += sprintf(s, "%lu\n", *val); >> + if (read_strategy) >> + s += read_strategy(*val, s); >> + else >> + s += sprintf(s, "%lu\n", *val); > > This would be better as %llu > Hi, Paul, This does not need fixing, since the other counters like failcnt are still unsigned long >> + tmp = simple_strtoul(buf, , 10); > > and this as simple_strtoull() > Will do, thanks! -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - 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: [-mm PATCH] Memory controller improve user interface (v3)
Paul Menage wrote: > On 9/2/07, Balbir Singh <[EMAIL PROTECTED]> wrote: >> - s += sprintf(s, "%lu\n", *val); >> + if (read_strategy) >> + s += read_strategy(*val, s); >> + else >> + s += sprintf(s, "%lu\n", *val); > > This would be better as %llu > >> + tmp = simple_strtoul(buf, , 10); > > and this as simple_strtoull() > > Paul > Thanks for catching it, I'll fix that. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in 2.6.22.6, net/sunrpc/svcsock.c
Hi Wolfgang, On Mon, 3 Sep 2007, Wolfgang Walter wrote: > > in 2.6.22.6, net/sunrpc/svcsock.c > > random characters are printed by svc_tcp_accept: > > lockd: last TCP connect from > [...] > > --- linux-2.6.22.6/net/sunrpc/svcsock.c 2007-08-27 18:10:14.0 > +0200 > +++ linux-2.6.22.6w/net/sunrpc/svcsock.c 2007-09-03 18:27:30.0 > +0200 > @@ -1090,7 +1090,7 @@ > serv->sv_name); > printk(KERN_NOTICE > "%s: last TCP connect from %s\n", > -serv->sv_name, buf); > +serv->sv_name, __svc_print_addr(sin, > buf, sizeof(buf))); > } > /* >* Always select the oldest socket. It's not fair, Your patch is correct, but please read patch submission instructions at: http://lxr.linux.no/source/Documentation/SubmittingPatches http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt http://lkml.org/lkml/2005/4/7/183 At a minimum, you need to: (1) provide Signed-off-by: line on top of the patch, (2) cc: netdev[at]vger.kernel.org (or other maintainer(s)) in your mail, and, (3) give a useful "[patch] sunrpc: fix printk argument" kind of Subject: line. Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/2] JBD: slab management support for large block(>8k)
On Mon, Sep 03, 2007 at 12:31:49PM -0700, Christoph Lameter wrote: > So you'd be fine with replacing the allocs with > > get_free_pages(GFP_xxx, get_order(size)) ? Yes. And rip out all that code related to setting up the slabs. I plan to add WARN_ONs to bio_add_page and friends to detect further usage of slab pages if there is any. - 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 1/2] JBD: slab management support for large block(>8k)
On Mon, 3 Sep 2007, Christoph Hellwig wrote: > > How about getting rid of the slabs there and use kmalloc? Kmalloc in mm > > (and therfore hopefully 2.6.24) will convert kmallocs > PAGE_SIZE to page > > allocator calls. Not sure what to do about the 1k and 2k requests though. > > The problem is that we must never use kmalloc pages, so we always need > to request a page or more for these. Better to use get_free_page directly, > that's how I fixed it in XFS a while ago. So you'd be fine with replacing the allocs with get_free_pages(GFP_xxx, get_order(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: Fwd: That whole "Linux stealing our code" thing
Daniel Hazelton <[EMAIL PROTECTED]> writes: > I hate to belabor the point, but you seem to be making the mistake of "The > license applies to the copyright holder" Of course not. > The person holding the copyright has all the legal standing to revoke a > license grant at any time. Based on? > Licenses such as the GPL are not signed contracts, > and that means there are limits to what effect they can have on the > copyright > holder. Perhaps that is your local laws, but I'd be surprised anyway. Do you sign contracts when shopping, or are you (and the shop) allowed to "revoke" the transaction after it's made (I'm not talking about shop's return policy)? Is what you wrote only valid WRT licences? Which country has such laws BTW? In Poland, I can't just go and "revoke" a "statement of will" if I haven't explicite reserved a right to do so. Obviously I can act contrary to the statement, and be held liable. -- Krzysztof Halasa - 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 5/5] x86: Set PCI config space size to extended for AMD Barcelona
Hi! > it's so very unfortunate the PCI standard has no feature bit to indicate > the presence of ECS. > > FWIW in my testing on a range of machines spanning 7 or 8 years i could > read config space reg 256... and get 0x when the device didn't > support ECS, and get valid data when the device did support ECS... granted > there may be some system out there which behaves really badly when you do > this. > > perhaps someone could write a userspace program and test that concept on a > far wider range of machines. If you want to experiment with this in user space, it's easy to write a couple of access functions for the libpci in pciutils. (Patches welcome, as usually :) ) Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth God is real, unless declared integer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE/RFC] Really Simple Really Fair Scheduler
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> On Mon, 3 Sep 2007, Ingo Molnar wrote:
>
> > If this basic model is correct, we can look further.
>
> The basic model is correct insofar I use an absolute time instead of a
> relative time, but it's not the essence of my math, so I don't quite
> understand the point of this exercise.
thanks. (and i did not claim nor do i want to claim this to be the
essence of your efforts - it is very clear from your mails where your
focus is.)
My next question then is about this code of yours in the wakeup path:
+static void
+enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
+{
+ kclock_t min_time;
+
+ verify_queue(cfs_rq, cfs_rq->curr != se, se);
+ min_time = get_time_avg(cfs_rq) - se->req_weight_inv;
+ if ((kclock_t)(se->time_norm - min_time) < 0)
+ se->time_norm = min_time;
why do you only use the "min_time" if the pre-sleep time_norm is smaller
than the min_time? Here 'min_time' is close to the current average.
Shouldnt here the woken up task be set to the average time, like i did
it in the crude prototype:
+ se->exec_runtime = avg_exec_runtime(cfs_rq);
(and lets again only consider the special case of only having nice-0
tasks.)
Or is it set in a similar way as my prototype does, and i missed some
detail why that branch is there?
Ingo
-
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.23-rc4-mm1
Hi Randy, > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ > > > > Changes since 2.6.23-rc3-mm1: > > > > git-watchdog.patch > > > on x86_64: > drivers/watchdog/core/watchdog_dev.c:84: warning: format '%i' expects type > 'int', but argument 5 has type 'size_t' I'll have a look at it. Greetings, Wim. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE/RFC] Really Simple Really Fair Scheduler
Hi, On Mon, 3 Sep 2007, Ingo Molnar wrote: > If this basic model is correct, we can look further. The basic model is correct insofar I use an absolute time instead of a relative time, but it's not the essence of my math, so I don't quite understand the point of this exercise. bye, Roman - 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: [Lguest] [RFC] 9p Virtualization Transports
On Tue, 2007-08-28 at 13:52 -0500, Eric Van Hensbergen wrote: > The lguest and kvm transports are functional, but we are still working out > remaining bugs and need to spend some time focusing on performance issues. > I wanted to send out this "preview" patch set to the community to solicit > ideas on things we can do differently/better. Hi Eric, Patches look reasonable, but just a heads-up: lguest will be moving to virtio, as will kvm. That means a single implementation for both (yay!), but it does complicate your life in the short term 8( Dor has published a kvm virtio implementation, and we've already discussed a couple of modifications. I expect that to be nailed in the next 2 weeks tho, and lguest will follow. Thanks! Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: That whole "Linux stealing our code" thing
On Monday 03 September 2007 14:26:29 Krzysztof Halasa wrote: > Daniel Hazelton <[EMAIL PROTECTED]> writes: > > The fact > > remains that the person making a work available under *ANY* form of > > copyright > > license has the right to revoke said grant of license to anyone. > > Not after the licence has been given and accepted (and there might be > restrictions), unless of course the licence contained such reservation. I hate to belabor the point, but you seem to be making the mistake of "The license applies to the copyright holder" that I've seen a lot of people make (and kept quiet about). The person holding the copyright has all the legal standing to revoke a license grant at any time. Licenses such as the GPL are not signed contracts, and that means there are limits to what effect they can have on the copyright holder. If the license was of the "signed contract" type, or contained text stating that the copyright holder was giving up all rights of revocation (etc...) I could agree with you. As it stands, no "Open Source" license that I have seen used on a major project contains any part that does that. In fact, the GPL is the only license I can name (offhand) that even touches on the rights of the copyright holder - and then it is in the form of "If you do X, Y or Z all rights granted under this license are automatically revoked". That is an "automatic clause" - not a limitation stating that the copyright holder can only revoke under those conditions. The person holding the copyright has quite a few rights - more than people believe - and not even the most generous of Open Source licenses (except those that contain text like "granted in perpetuity" or similar) even come close to being exempt from the holder of the copyright not being able to summarily revoke a given persons license. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE/RFC] Really Simple Really Fair Scheduler
* Roman Zippel <[EMAIL PROTECTED]> wrote: > Hi, > > On Sun, 2 Sep 2007, Ingo Molnar wrote: > > > Roman, as an addendum to my review, please find below a prototype patch > > i've just written that implements RSRFS (Really Simple Really Fair > > Scheduler) ontop of CFS. It is intended to demonstrate the essence of > > the math you have presented via your patch. (it has no nice levels > > support yet, to make the math really apparent to everyone interested) > > It simplifies the math too much, the nice level weighting is an > essential part of the math and without it one can't really understand > the problem I'm trying to solve. At http://lkml.org/lkml/2007/9/3/168 > I provide an example of the math, which more acurately demonstrates > the essential math. as i mentioned it above, in the first level review i'm mainly interested in your patch's behavior wrt. simple nice-0 tasks, how they run and how they sleep and wake up. Nothing else. Why? That's what 99% of the Linux tasks do after all. So could you please confirm whether that aspect of what i wrote (both in words and in code) is correct? If this basic model is correct, we can look further. If this basic model is flawed, no amount of weighting, nice level logic, rounding behavior can fix it. I'm sure you agree with that too. That's why i wrote this prototype, please confirm or deny whether i correctly understood how you intend to handle nice-0 tasks. (From your mails i read a part-acknowledgement of that but i'd like to see a more clear acknowledgement - or please mention any issues if you know about them.) Thanks! Ingo - 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 3/4] ide: make ide_rate_filter() also respect PIO and SW/MW DMA mode masks (take 2)
Hi,
On Sunday 02 September 2007, Sergei Shtylyov wrote:
> Make ide_rate_filter() also respect PIO/SWDMA/MWDMA mode masks. While at it,
Hm, this seems to be already dealt with by:
http://kernel.org/pub/linux/kernel/people/bart/pata-2.6/patches/ide-mode-limiting-fixes-for-user-requested-speed-changes.patch
after applying the above patch ide_rate_filter() looks like this:
/**
* ide_rate_filter - filter transfer mode
* @drive: IDE device
* @speed: desired speed
*
* Given the available transfer modes this function returns
* the best available speed at or below the speed requested.
*
* TODO: check device PIO capabilities
*/
u8 ide_rate_filter(ide_drive_t *drive, u8 speed)
{
ide_hwif_t *hwif = drive->hwif;
u8 mode = ide_find_dma_mode(drive, speed);
if (mode == 0) {
if (hwif->pio_mask)
mode = fls(hwif->pio_mask) - 1 + XFER_PIO_0;
else
mode = XFER_PIO_4;
}
// printk("%s: mode 0x%02x, speed 0x%02x\n", __FUNCTION__, mode, speed);
return min(speed, mode);
}
What is still missing from IDE tree is "respecting device PIO limits" (sorry
I was quoting from memory it is TODO not FIXME [1]) which probably comes down
to adding ide_get_best_pio_mode() call to ide_rate_filter() (IMO this should
be done before ide-mode-limiting-fixes-for-user-requested-speed-changes.patch
changes).
[1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg09750.html
Ah, I see the source of the confusion now, I misunderstood your remark about
->mwdma_mask being ignored (for some reason I though that you were referring
to MWDMA mode not being tried if device refuses SET_XFER command w/ UDMA).
ide_find_dma_mode() is a bit tricky because it used also by ide_max_dma_mode()
but it should take care of ->mwdma_mask if ->udma_mask is zero just fine.
> make the udma_filter() method calls take precedence over using the mode masks.
This change is OK - could you make a new patch?
> Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
>
> ---
> Alas, the previous version of the patch wasn't even worth signing it off --
> the code had to be much trickier. The patch against the current Linus' tree
> and
take #1 was correct - i.e. if UDMA0 is not available we want to go down
to MWDMA2 and not MWDMA0 (this is what the old code was doing BTW)
> unfortunately I was able to only compile test it since that tree gives MODPOST
> warning and dies early on bootup. I'm hoping to give it more tesring when/if
> I have time... :-)
>
> drivers/ide/ide-dma.c |7 +++---
> drivers/ide/ide-lib.c | 57
> ++
> 2 files changed, 39 insertions(+), 25 deletions(-)
>
> Index: linux-2.6/drivers/ide/ide-dma.c
> ===
> --- linux-2.6.orig/drivers/ide/ide-dma.c
> +++ linux-2.6/drivers/ide/ide-dma.c
> @@ -664,10 +664,11 @@ static unsigned int ide_get_mode_mask(id
> if ((id->field_valid & 4) == 0)
> break;
>
> - mask = id->dma_ultra & hwif->ultra_mask;
> -
> if (hwif->udma_filter)
> - mask &= hwif->udma_filter(drive);
> + mask = hwif->udma_filter(drive);
> + else
> + mask = hwif->ultra_mask;
> + mask &= id->dma_ultra;
>
> if ((mask & 0x78) && (eighty_ninty_three(drive) == 0))
> mask &= 0x07;
> Index: linux-2.6/drivers/ide/ide-lib.c
> ===
> --- linux-2.6.orig/drivers/ide/ide-lib.c
> +++ linux-2.6/drivers/ide/ide-lib.c
> @@ -75,38 +75,51 @@ EXPORT_SYMBOL(ide_xfer_verbose);
> *
> * Given the available transfer modes this function returns
> * the best available speed at or below the speed requested.
> - *
> - * FIXME: filter also PIO/SWDMA/MWDMA modes
> */
>
> u8 ide_rate_filter(ide_drive_t *drive, u8 speed)
> {
> -#ifdef CONFIG_BLK_DEV_IDEDMA
> ide_hwif_t *hwif = drive->hwif;
> - u8 mask = hwif->ultra_mask, mode = XFER_MW_DMA_2;
> + u8 mask, base = speed & 0xf8, bit = 1 << (speed & 0x07);
>
> - if (hwif->udma_filter)
> - mask = hwif->udma_filter(drive);
> + switch (base) {
> +#ifdef CONFIG_BLK_DEV_IDEDMA
> + case XFER_UDMA_0:
> + mask = hwif->udma_filter ? hwif->udma_filter(drive) :
> +hwif->ultra_mask;
>
> - /*
> - * TODO: speed > XFER_UDMA_2 extra check is needed to avoid false
> - * cable warning from eighty_ninty_three(), moving ide_rate_filter()
> - * calls from ->speedproc to core code will make this hack go away
> - */
> - if (speed > XFER_UDMA_2) {
> - if ((mask & 0x78) && (eighty_ninty_three(drive) == 0))
> + /*
> + * TODO: if speed > XFER_UDMA_2, an extra
Re: [PATCH 2/4] hpt366: MWDMA filter for SATA cards
On Sunday 02 September 2007, Sergei Shtylyov wrote:
> Hello, I wrote:
>
> The patch was 4/4 of course. :-<
> Probably I was too esctatic about the code. ;-)
>
> > The Marvell bridge chips used on HighPoint SATA cards do not seem to support
> > the MWDMA modes (at least that caould be seen in their so-called drivers
> > :-),
> > so the driver needs to account for this -- to achieve this:
>
> > - add mdma_filter() method from the original patch by Bartlomiej
> > Zolnierkewicz
> > with his consent, also adding the method callout to ide_rate_filter();
>
> > - installed the method for all chips to only return empty mask if a SATA
> > drive
> > is detected onHPT372{AN]/374 chips...
>
> > Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
>
> > ---
> > This patch against the current Linus' tree and unfortunately I was able to
> > only
> > compile test it since that tree gives MODPOST warning and dies early on
> > bootup.
> > Will hopefully try to test if/when I have time... :-)
>
> > Index: linux-2.6/drivers/ide/pci/hpt366.c
> > ===
> > --- linux-2.6.orig/drivers/ide/pci/hpt366.c
> > +++ linux-2.6/drivers/ide/pci/hpt366.c
> > @@ -1,5 +1,5 @@
> > /*
> > - * linux/drivers/ide/pci/hpt366.c Version 1.12Aug 25, 2007
> > + * linux/drivers/ide/pci/hpt366.c Version 1.13Aug 22, 2007
>
> Errr... and version shuold Aug 02 -- thought I've fixed that. :-/
and we have ATA_MWDMA2 define in _vanilla_ kernel now :)
Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL -mm] Unionfs/fsstack/eCryptfs updates/cleanups/fixes
In message <[EMAIL PROTECTED]>, Al Boldi writes:
> Erez Zadok wrote:
> > Al, we have back-ports of the latest Unionfs to 2.6.{22,21,20,19,18,9},
> > all in http://unionfs.filesystems.org/. Before we release any change, we
> > test it on all back-ports as well as the latest -rc/-mm code base (takes
> > over 24 hours straight to get through all of our regressions :-)
>
> I am impressed, thanks!
You're welcome.
> It's probably a good idea to always point these backports out, whenever
> submitting patches against -mm. Otherwise, people might forget.
Good idea.
> > So we'd be happy to submit those patches to the latest stable kernel.
> > But, are you talking about VFS/ecryptfs patches (which are in the stable
> > kernel), or are you talking about Unionfs (which is not)?
>
> I'm talking about Unionfs, which seems like a rather critical feature to
> miss-out on.
Hmmm, we'll have to discuss this among the unionfs developers first.
> BTW, did you ever get that oops-on-umount worked out?
Which bug? Is that something anyone submitted to our
https://bugzilla.filesystems.org? I don't recall such a bug in a while, so
if it got fixed, it must've been a while back. If it's still there and
reproducible, please let me know asap so I can work on it.
It is possible that the bug is in the -mm code. That's why we just posted
the long series of Unionfs patches: those patches represent more than four
months of intense hardening and testing. Some of the bugs we've fixed had
to do with improper refcounting (esp. mnt refcounting, which, if not
perfect, either causes an EBUSY on unmount or an oops on unmount :-)
> Thanks!
>
> --
> Al
Erez.
-
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] Send quota messages via netlink
> On Mon, 3 Sep 2007 19:48:46 +0200 Jan Kara <[EMAIL PROTECTED]> wrote: > On Mon 03-09-07 10:12:34, Randy Dunlap wrote: > > On Mon, 3 Sep 2007 16:43:36 +0200 Jan Kara wrote: > > > > > User-Agent: Mutt/1.5.13 (2006-08-11) > > > > Mutt knows how to send patches inline vs. attachments... :( > Hmm, I thought Andrew either does not mind or prefers attachments. If > it isn't the case, I can inline patches. Andrew? BTW: I personally prefer > attachments - mutt inlines text attachments for me anyway and sometimes > it's useful to have the file structured by MIME. inlined is a bit better, mainly because one can reply to it and the email client will quote the whole thing. > > +This command is used to send a notification about any of the above > > mentioned > > +events. Each message has six attributes. These are (type of the argument is > > +in braces): > > > > s/braces/parentheses/ > > > > +QUOTA_NL_A_QTYPE (u32) > > + - type of quota beging exceeded (one of USRQUOTA, GRPQUOTA) > > > > s/beging/being/ > Thanks for reading it. Andrew, should I resend the patch or will you > substitute it in the patch? I'll sort it out, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE/RFC] Really Simple Really Fair Scheduler
Hi, On Sun, 2 Sep 2007, Ingo Molnar wrote: > Roman, as an addendum to my review, please find below a prototype patch > i've just written that implements RSRFS (Really Simple Really Fair > Scheduler) ontop of CFS. It is intended to demonstrate the essence of > the math you have presented via your patch. (it has no nice levels > support yet, to make the math really apparent to everyone interested) It simplifies the math too much, the nice level weighting is an essential part of the math and without it one can't really understand the problem I'm trying to solve. At http://lkml.org/lkml/2007/9/3/168 I provide an example of the math, which more acurately demonstrates the essential math. bye, Roman - 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/
Ath5k panic fix
Ath5k panics on ath_open() because sc->pdev is never set, fixed. Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]> --- a/drivers/net/wireless/ath5k_base.c +++ b/drivers/net/wireless/ath5k_base.c @@ -2295,6 +2295,7 @@ static int __devinit ath_pci_probe(struct pci_dev *pdev, hw->max_rssi = 127; /* FIXME: get a real value for this. */ sc = hw->priv; sc->hw = hw; + sc->pdev = pdev; /* * Mark the device as detached to avoid processing - 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.23-rc5
Rafael J. Wysocki wrote: > On Sunday, 2 September 2007 09:54, Prakash Punnoor wrote: >> Hi, >> >> 2.6.23-rc5 locks up hard (Magic Syskeys won't even work) after a few minutes >> of work on x86_64. 2.6.23-rc4 was fine. I'll try git-bisect to find out what >> is causing trouble. Yes, I am using nvidia binary but it didn't make >> troubles >> since ages... When I found the bugger, I'll try whether it works w/o nvidia >> binary. > > Just for the record, I'm running -rc5 on two x86_64 boxes without any visible > issue. > > I don't use any binary graphics drivers, though. 2.6.23-rc5 dies here random[1] too .. on 2 Dell boxes ( i686 not x86_64 here ) which I upgraded to rc5 yesterday. When dies 'Caps Lock and Scroll Lock' blinks and the box lockups hard .. rc4 got an 7 days uptime on both with the same config , kernel compiled with same gcc/glibc/binutils etc. I don't have any Oops/BUG or whatever messages in any of my logs nor I'm able to capture everything with netconsole :/ Any idea how else I could capture the Oops/BUG messages ? Ohh well all I have is this : ( captured with a script which I started some seconds before a box died , no idea it has something to do with this bug but I post anyway ) .. [ 5414.309269] SysRq : Show Pending Timers [ 5414.309359] Timer List Version: v0.3 [ 5414.309363] HRTIMER_MAX_CLOCK_BASES: 2 [ 5414.309366] now at 5391544457987 nsecs [ 5414.309371] [ 5414.309372] cpu: 0 [ 5414.309377] clock 0: [ 5414.309390] .index: 0 [ 5414.309394] .resolution: 1 nsecs [ 5414.309399] .get_time: ktime_get_real [ 5414.309429] .offset: 1188833557343399512 nsecs [ 5414.309435] active timers: [ 5414.309443] clock 1: [ 5414.309448] .index: 1 [ 5414.309454] .resolution: 1 nsecs [ 5414.309458] .get_time: ktime_get [ 5414.309473] .offset: 0 nsecs [ 5414.309477] active timers: [ 5414.309482] #0: <3>BUG: scheduling while atomic: swapper/0x1001/0 [ 5414.309500] [] __sched_text_start+0x5b0/0x6c0 [ 5414.309530] [] __cond_resched+0x18/0x29 [ 5414.309548] [] cond_resched+0x2a/0x31 [ 5414.309562] [] mutex_lock+0xb/0x1c [ 5414.309573] [] lookup_module_symbol_name+0x14/0xbb [ 5414.309613] [] print_name_offset+0x1a/0x8e [ 5414.309630] [] release_console_sem+0x1b1/0x1d1 [ 5414.309656] [] timekeeping_resume+0x7d/0xa1 [ 5414.309668] [] ktime_get_ts+0x1b/0x4e [ 5414.309681] [] timer_list_show+0x661/0xa55 [ 5414.309700] [] tick_sched_timer+0x0/0xbd [ 5414.309715] [] __handle_sysrq+0x7a/0x115 [ 5414.309730] [] kbd_event+0x330/0x5d4 [ 5414.309741] [] kbd_event+0x0/0x5d4 [ 5414.309755] [] input_event+0x410/0x44f [ 5414.309790] [] atkbd_interrupt+0x42c/0x56e [ 5414.309817] [] serio_interrupt+0x2f/0x69 [ 5414.309832] [] i8042_interrupt+0x108/0x23e [ 5414.309849] [] do_timer+0x1c/0xed [ 5414.309867] [] handle_IRQ_event+0x25/0x4a [ 5414.309885] [] handle_edge_irq+0xb2/0x102 [ 5414.309911] [] do_IRQ+0x3b/0x78 [ 5414.309923] [] smp_apic_timer_interrupt+0x59/0x84 [ 5414.309937] [] common_interrupt+0x23/0x28 [ 5414.309947] [] default_idle+0x0/0x3e [ 5414.309959] [] default_idle+0x2f/0x3e [ 5414.309973] [] cpu_idle+0x5e/0x78 [ 5414.309982] [] start_kernel+0x2c2/0x348 [ 5414.309996] [] unknown_bootoption+0x0/0x1de [ 5414.310010] === ... I don't use any *binary* drivers. [1] It dies after minutes or after hour(s) , dies while doing something ( like compiling , copying stuff ) or while doing nothing ( box idles no activity at all ). Right now I got an 3h uptime ( heh ) while died before in about 2 hours 5 times.. > > Greetings, > Rafael Gabriel - 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: New x86-Setup code breaks HVM-XEN boot
Hi, On Thu, Aug 30, 2007 at 07:49:26AM -0700, H. Peter Anvin wrote: > Christian Ehrhardt wrote: > > > >Note the the xm console command terminates on its own, i.e. the guest > >machine seems to halt and not hang somewhere. > > > >I could verify that the real mode code up to the assembly code in > >pmjump.S is in fact executed. The problem appears to occur while > >enabling protected mode. I tried to put endless loops into the 32-bit > >setup code but these were apparently not reached. As far as I understand > >this, the protected mode jump in pmjump.S seems to jump into nowhere. > > > >I am willing to do tests with the XEN guest and send any additional > >information that might be helpful. However, I cannot change the XEN host > >at this time. > > > >Any suggestions? > > > > All of this point to a bug in the Xen emulation host. You're not saying > if you're on an Intel or AMD host, but on Intel, hardware > virtualization doesn't actually kick in until you're in protected mode > with all segments configured properly. This means all of pmjump.S runs > in an interpreter. A bug in that interpreter would cause what you observe. I took the trouble to bisect (manually) exactly which change in the new boot code triggers this problem. The problem is with the lgdt instruction. Apparently XEN does not keep the contents of the 48-bit gdt_48 data structure that is passed to lgdt in the XEN machine state. Instead it appears to save the _address_ of the 48-bit descriptor somewhere. Unfortunately this data happens to reside on the stack and is probably no longer availiable at the time of the actual protected mode jump. This is most likely a XEN-bug but given that there is a on line patch to work around this problem, the linux kernel should probably do this. My fix is to make the gdt_48 description in setup_gdt static (in setup_idt this is already the case). This allows the kernel to boot under XEN-hvm again. Sometimes it is a bit disappointing if quite some debuggin work results in a on line patch :-) Pleae consider applying. regards Christian Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> diff --git a/arch/i386/boot/pm.c b/arch/i386/boot/pm.c index 6be9ca8..f7958f1 100644 --- a/arch/i386/boot/pm.c +++ b/arch/i386/boot/pm.c @@ -122,7 +122,7 @@ static void setup_gdt(void) /* DS: data, read/write, 4 GB, base 0 */ [GDT_ENTRY_BOOT_DS] = GDT_ENTRY(0xc093, 0, 0xf), }; - struct gdt_ptr gdt; + static struct gdt_ptr gdt; gdt.len = sizeof(boot_gdt)-1; gdt.ptr = (u32)_gdt + (ds() << 4); - 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: [GIT PULL -mm] Unionfs/fsstack/eCryptfs updates/cleanups/fixes
Erez Zadok wrote:
> Al, we have back-ports of the latest Unionfs to 2.6.{22,21,20,19,18,9},
> all in http://unionfs.filesystems.org/. Before we release any change, we
> test it on all back-ports as well as the latest -rc/-mm code base (takes
> over 24 hours straight to get through all of our regressions :-)
I am impressed, thanks!
It's probably a good idea to always point these backports out, whenever
submitting patches against -mm. Otherwise, people might forget.
> So we'd be happy to submit those patches to the latest stable kernel.
> But, are you talking about VFS/ecryptfs patches (which are in the stable
> kernel), or are you talking about Unionfs (which is not)?
I'm talking about Unionfs, which seems like a rather critical feature to
miss-out on. BTW, did you ever get that oops-on-umount worked out?
Thanks!
--
Al
-
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: Fwd: That whole "Linux stealing our code" thing
Daniel Hazelton <[EMAIL PROTECTED]> writes: > The fact > remains that the person making a work available under *ANY* form of > copyright > license has the right to revoke said grant of license to anyone. Not after the licence has been given and accepted (and there might be restrictions), unless of course the licence contained such reservation. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE/RFC] Really Fair Scheduler
Hi,
On Sun, 2 Sep 2007, Daniel Walker wrote:
> For instance if there are three tasks in the system. Call them A,B, and
> C.
>
> then
>
> time equals "time of A" + "time of B" + "time of C"
Ok, let's take a simple example. :)
If we have three task A, B, C, each with a weight of 1, 2, 3, so the
weight sum is 6. If we let these three tasks run over a period of 12s,
each task gets time/weight_sum*weight_{t} seconds, that is each task gets
2, 4, 6 seconds of runtime.
The basic idea of CFS is now that using this formula, the time is
distributed to the active tasks and accounted against the runtime they
get. Let's assume a time slice of 1s, where each task gets
1s/weight_sum*weight_{t} of eligible runtime every second, so in the
following table the task column contains the values (eligible runtime
- obtained runtime):
timecurrent A B C fair_clock
1 C 1/6-0 2/6-0 3/6-1 1/6
2 C 2/6-0 4/6-0 6/6-2 2/6
3 C 3/6-0 6/6-0 9/6-3 3/6
4 B 4/6-0 8/6-1 12/6-3 4/6
5 B 5/6-0 10/6-2 15/6-3 5/6
6 A 6/6-1 12/6-2 18/6-3 6/6
7 C 7/6-1 14/6-2 21/6-4 7/6
8 C 8/6-1 16/6-2 24/6-5 8/6
9 C 9/6-1 18/6-2 27/6-6 9/6
10 B 10/6-1 20/6-3 30/6-6 10/6
11 B 11/6-1 22/6-4 33/6-6 11/6
12 A 12/6-2 24/6-4 36/6-6 12/6
Practically the eligible runtime part isn't updated constantly, but a
delta against the last update is used. If everything is working
correctly in the end the difference between the eligible and obtained
runtime is zero.
Peter's patches now make an interesting step, basically they change the
position of the weight_{t} variable, so every task get's now
1s/weight_sum per second and weight_{t} is now used to scale the
obtained runtime instead:
timecurrent A B C fair_clock
1 C 1/6-0/1 1/6-0/2 1/6-1/3 1/6
2 C 2/6-0/1 2/6-0/2 2/6-2/3 2/6
3 C 3/6-0/1 3/6-0/2 3/6-3/3 3/6
4 B 4/6-0/1 4/6-1/2 4/6-3/3 4/6
5 B 5/6-0/1 5/6-2/2 5/6-3/3 5/6
6 A 6/6-1/1 6/6-2/2 6/6-3/3 6/6
7 C 7/6-1/1 7/6-2/2 7/6-4/3 7/6
8 C 8/6-1/1 8/6-2/2 8/6-5/3 8/6
9 C 9/6-1/1 9/6-2/2 9/6-6/3 9/6
10 B 10/6-1/110/6-3/210/6-6/310/6
11 B 11/6-1/111/6-4/211/6-6/311/6
12 A 12/6-2/112/6-4/212/6-6/312/6
As you can see here the fair_clock part is the same for every task in
every row, so that it can be removed, this is basically the step I do in
my patch:
timecurrent A B C fair_clock
1 C 0/1 0/2 1/3 1/6
2 C 0/1 0/2 2/3 2/6
3 C 0/1 0/2 3/3 3/6
4 B 0/1 1/2 3/3 4/6
5 B 0/1 2/2 3/3 5/6
6 A 1/1 2/2 3/3 6/6
7 C 1/1 2/2 4/3 7/6
8 C 1/1 2/2 5/3 8/6
9 C 1/1 2/2 6/3 9/6
10 B 1/1 3/2 6/3 10/6
11 B 1/1 4/2 6/3 11/6
12 A 2/1 4/2 6/3 12/6
This means fair_clock isn't used in the runtime calculation anymore and
time isn't relative to fair_clock, but it's an absolute value. It looks
relatively simple, but it means all calculations involving fair_clock
deltas and wait_runtime values have to be redone in this context and
that's the part where I need some help with - some of the tuning
features aren't converted yet.
The importance of this step is that it removes a major error source for
the accuracy of the scheduler. All these fractions have to be rounded to
integer values at some point and the main problem here is that the
denominator in the fair_clock calculation is variable - it changes with
the number of active tasks and it requires quite some resolution, so the
error doesn't become noticable.
fair_clock isn't used here anymore, but it's still used to initialize the
time value of new tasks. For
Re: [patch 5/5] x86: Set PCI config space size to extended for AMD Barcelona
On 03.09.07 09:48:15, dean gaudet wrote: > it's so very unfortunate the PCI standard has no feature bit to indicate > the presence of ECS. Right. Not nice. > FWIW in my testing on a range of machines spanning 7 or 8 years i could > read config space reg 256... and get 0x when the device didn't > support ECS, and get valid data when the device did support ECS... granted > there may be some system out there which behaves really badly when you do > this. > > perhaps someone could write a userspace program and test that concept on a > far wider range of machines. A user space programm could map the config space (if MMCONFIG is usable) and scan the PCI devices directly using memory access. This patch sets pcidev->cfg_size to 4096 for certain devices so that the ECS is also available using proc/sys fs or lspci -. In this case the Kernel access functions are used. This works with both methods, CF8 and MMCONFIG. For CF8, all patches of these series must be used. Note also, that ECS access is not only for CPU devices available, but also of other PCI Express devices on the bus. -Robert -- AMD Saxony, Dresden, Germany Operating System Research Center email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL weasels and the atheros stink
On Monday 03 September 2007 13:18:35 Krzysztof Halasa wrote: > Daniel Hazelton <[EMAIL PROTECTED]> writes: > > Then go yell at Mr. Floeter. The code is dual-licensed and he put > > BSD-License > > only code in it. Because that's the *EXACT* *SAME* thing you're talking > > about. > > Actually it is not. > > Dual BSD/GPL licence essentially means BSD, because rights given by > BSD are a superset of these by GPL. Actually, I was pointing out a logical fallacy. I'll spell it out long here so everyone can see the point I was trying to make. Person A writes a device driver and releases it under a dual license. Person B modifies said device driver and licenses his changes under only one of the licenses on the device driver. Nobody complains. Person C modifies the same device driver and licenses his changes under the other license on the device driver. People start complaining. In this case either the actions of both persons B and C are legal - in which case neither person B or person C is likely to lose a lawsuit (or even face one) - or they are illegal, in which case the second a lawsuit is brought against person C, the same lawsuit must be brought against person B. The exact nature of the licenses and whether one is a superset or subset of the other doesn't matter. Either the action of making modifications licensed solely under one or the other of the two licenses on the original code-base is illegal or it isn't. > The other thing is copyright notices. I think one can't legally > alter someone else's licence conditions (in his/her name), unless > something like that is explicitly permitted. Fully agreed. I've even said such myself. > However, we're talking about derivative works. A derivative > work may be, for example, GPL-licenced: > > "Copyright (C) 1234 Joe the GPL lover > licenced under the GPL as published" > > but could lawfully use code originally licenced under BSD: > > "Portions copyright (C) 1234 Bill the BSD lover > originally licenced under no-ad BSD" > > Thus his (Joe's) work is GPL only, but Bill's licence notice is > intact as required by it (BSD). I've suggested that such be done in the future - if just because it *IS* how it should be done. > > IANAL, maybe you (all of us) should consult one if required. Would cost me money to consult a lawyer over this, but I do have a few friends that have completed law school and are waiting on the results of the BAR. They have told me that they are not legally allowed to dispense legal advice - but I got around that by asking them to recount what the law actually says. Apparently the above suggestion would meet the letter of the law. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: Fwd: That whole "Linux stealing our code" thing
On Monday 03 September 2007 05:48:00 David Schwartz wrote: > > Mr. Floeter *CAN* request that his code be removed from said fork > > - his code > > is solely licensed (AFAICT and IIRC) under the BSD/ISC license > > and was only > > covered by the dual-license because it was integrated into a work that > > carried said dual-license. (I'm not sure how well such a revocation would > > work in reality, but it is Mr. Floeters right.)... > > No. Neither the BSD license nor the GPL license permit you to revoke > rights. Mr. Floeter's code is still available under the BSD/ISC license. > The BSD license does not require you to make derived works available under > a BSD license. *His* code is still available under a BSD/ISC license, of > course, but the changed code is not. Doesn't matter if the BSD license or the GPL *PERMITS* it or not. The fact remains that the person making a work available under *ANY* form of copyright license has the right to revoke said grant of license to anyone. The GPL codifies certain situations in which the person would not, personally, have to revoke the license, but does not limit the original copyright holders rights (in that regard) in any way. The BSD/ISC license has none of the automatic conditions of the GPL, but it also cannot remove the copyright holder(s) from exercising their rights. (And no, I haven't spoken to a lawyer about this - I did, however, ask a recently graduated law-school student where I could look for case-law and the text of the actual laws. What I got was some background on US copyright law itself and an agreement that a copyright license does not - and can not - affect the person holding the copyright) > Read the BSD license. It does not require changes to be made available > under a compatible license. This is the main difference between the BSD and > GPL licenses. Have done so. And that is the only part of the license that I actually don't like. > Note that it would be an error to remove the BSD license text, as the BSD > license requires you to keep it and you still need the BSD license to grant > you distribution rights to the original work. However, the license does not > apply to protectable aspects of the code not placed under the BSD license > by their original author, and it is important to add a note to that effect. Agreed, and I've never claimed otherwise. (Nor has anyone else. I believe the closest that anyone has come was Alan Cox saying (and I'm going to paraphrase it because I don't think he ever stated it well) "If you've made changes to a file that carries a dual BSD/GPL license and your changes are GPL only, the file can no longer be distributed under the BSD license at all. So it is safe to remove the headers from that individual file." There is no way that a license on a constituent file can alter or affect the license on the whole project (if it is different). It can "muddy the waters", but that is about as far as I can see it going. (I realize I may have said different, originally, but you'll have to forgive me. I was not in the best of moods (or the best state of mind) to be making a completely rational argument when I did such.) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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] Blackfin BF54x NAND Flash Controller driver
On 9/3/07, Clemens Koller <[EMAIL PROTECTED]> wrote: > Bryan Wu schrieb: > > This is the driver for latest Blackfin BF54x nand flash controller > > > > - use nand_chip and mtd_info common nand driver interface > > - provide both PIO and dma operation > > - compiled with ezkit bf548 configuration > > - use hardware 1-bit ECC > > - tested with YAFFS2 and can mount YAFFS2 filesystem as rootfs > > Looks great! > > Will this driver also work for the new BF52x series of the Blackfin Series? > (Or is it planned to make it work for... anytime soon.) the order for porting of new chips is: u-boot -> core kernel -> peripherals we generally dont bother looking at peripherals until the earlier stuff is done -mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata not working for sis5533
On Sep 2 2007 11:40, Alan Cox wrote: > >> i've been out for a week, but found no notice, did i lost any email or >> no activity on this issue? > >I tagged it onto the obscure IDE report pile. It doesn't contain any >really useful information and its probably not an IDE layer bug as of >itself. But its on the todo list for further investigation and to see if >patterns emerge I shall give this a spin too, since I happen to have sis5513. Jan -- - 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] Blackfin BF54x NAND Flash Controller driver
On 9/3/07, Bryan Wu <[EMAIL PROTECTED]> wrote: > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -131,6 +131,24 @@ config MTD_NAND_AU1550 > +config MTD_NAND_BF54X > + tristate "NAND Flash support for Blackfin BF54X SoC DSP" i'd just describe it as "Blackfin on-chip NAND" rather than sticking in exact part numbers as i imagine we can extend it down the line > + This enables the NAND flash controller on the BF54X SoC DPSs "BF54X SoC DPSs" -> "BF54x SoC DSPs" > + No board specific support is done by this driver, each board > + must advertise a platform_device for the driver to attach. should mention the module name when built as a module > +config MTD_NAND_BF54X_HWECC > + bool "BF54X NAND Hardware ECC" > + depends on MTD_NAND_BF54X > + help > + Enable the use of the BF54X's internal ECC generator when > + using NAND. Early versions of the chip have had problems with > + incorrect ECC generation, and if using these, the default of > + software ECC is preferable. rather than advertising this, i'd just keep it in the driver ... presumably there are anomaly #'s for when the ECC is wrong, so we can make the code depend on those -mike - 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/
mutex vs cache coherency protocol(for multiprocessor )
Hello everyone, Just got a rough question in my head. don't know whether anyone interested . mutex vs cache coherency protocol(for multiprocessor) both of these two can be used to protect shared resource in the memory. are both of them necessary? for example: in a multiprocessor system, if there is only mutex no cache coherency. obviously this would cause problem. what about there is no mutex mechanism, only cache coherency protocol in multiprocessor system? after consideration, I found this also could casue problem, when the processors are multithreading processors, which means more than one threads can be running on one processor. in this case if we only have cache coherency and no mutex, this would cause problem. because all the threads running on one processor share one cache, the cache coherency protocol can not be functioning anymore. the shrared resource could be crashed by different threads. then if all the processors in the multiprocessor system are sigle thread processor, only one thread can be running one one processor. is it ok, if we only have cache coherency protocol ,no mutex mechanism? anyone has any idea? all the comments are welcome and appreciated, including criticism. regards, - 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 weasels and the atheros stink
(As noted before - I am surround all-caps text with *'s to indicate vocal stress, not volume) On Monday 03 September 2007 05:47:59 David Schwartz wrote: > Daniel Hazelton wrote: > > > Your entire argument is based on the false assumption that > > > these licenses > > > are compatible. They are not. You cannot put code that was offered > > > under the GPLv2 into code that is licensed under the dual license and > > > distribute > > > the result. > > > > Then go yell at Mr. Floeter. The code is dual-licensed and he put > > BSD-License > > only code in it. Because that's the *EXACT* *SAME* thing you're talking > > about. > > This is a completely irrelevent reply. For one thing, I'm not yelling at > anyone, so I don't see why you think I'm being inconsistent or something > because I'm not yelling at Mr. Floeter. > > Actually, it's perfectly fine to put BSD-only code in a dual-licensed file. > You just need to remove the dual license and make the file GPL-only. Huh? You're not making any sense. I think what you meant was "It's perfectly fine to put BSD-only code in a dual-licensed file. You just need to make the file *BSD* only." And you are correct - but you (and I may be wrongly interpreting your words) and a lot of other people have complained that Jiri made modifications to the Atheros code and only licensed his code under the GPL. What none of you have done is complained that Mr. Floeter did the same thing - made changes to the Atheros code and made his changes only available under *ONE* of the licenses. Apparently the reason why people that are complaining about Jiri doing such haven't complained about Floeter doing the same thing is that he used a license that you and the other people like. > > IANAL, but your argument is specious - if the code is > > dual-licensed and you > > are going to let one person add code to it that is only licensed > > under one of > > those licenses, you *CANNOT* complain when somebody else does it > > and chooses > > the other license. (Well, you can, but the complaint has no legal > > standing) > > What argument am I making that's specious? Perhaps you have me confused > with someone else? > > In any event, I utterly reject the argument that you make. Any argument > "you cannot complain about X unless you also complain about Y" is just > totally bogus. You can say "you cannot complain about X and *defend* Y > because X and Y are similar". But the fact that I don't complain about > something creates no inconsistency. I am under no obligation to complain > about everything that contradicts my principles, even things I don't know > about or don't have enough information to give an informed opinion. Wrong - I said "You can't complain about Person A doing X when you let Person B do X without complaint". To whit: you can't complain that Jiri has made changes to a dual-licensed "work" and only released his changes under one of the licenses on the work when somebody else - in this case Msr. Floeter - has done the same thing. > > > That's not the problem. The problem is that if the file stays > > > dual-licensed, everyone working on that file in the Linux > > > kernel will have > > > to be careful not to put any GPLv2-only code into it. That's just > > > untenable. Any consistent license is better than different files being > > > under different licenses such that you can't cut and paste code between > > > files. > > > > Then why aren't you complaining about Mr. Floeters code ? > > Because I am too busy answering nonsensical arguments like yours. Nonsense? Maybe in your little fantasy world. In the real world what I have proved by stating the facts is that you are complaining about something - and apparently claiming that its illegal - when somebody else has done the *EXACT* *SAME* *THING* and you have no problem with it. (And since you apparently keep forgetting, that "exact same thing" is 'making changes to a dual-licensed project and only releasing the changes under one of the licenses on the project) > I am > under no obligation to complain about everything I might disagree with if I > were informed about it. Huh? You are complaining about one person doing something and are not or do not see a need to complain about somebody else who has does the same thing. You either have a problem with the action or you don't - in this case it appears that you are complaining because the person in question made a choice you don't like. > Why aren't you complaining about starving kids in > Africa? Nice straw-man, but I'll answer anyway... I do, all the time. But I also do that in a forum where it does some good, and I even use my own money to try and do something about it. > > His code doesn't maintain the dual-license. I think the reason is > > that you > > could care less about the "Dual License" and you just want the > > code - period. > > You are probably confusing me with someone else. I honestly can't see how > your reply in any way fits with what
Re: [PATCH 01/32] VFS: export release_open_intent symbol
On Mon, Sep 03, 2007 at 09:59:15PM +0530, Satyam Sharma wrote: > > > On Sun, 2 Sep 2007, Josef 'Jeff' Sipek wrote: > > > > diff --git a/fs/namei.c b/fs/namei.c > > index a83160a..b2b7c8e 100644 > > --- a/fs/namei.c > > +++ b/fs/namei.c > > @@ -374,6 +374,7 @@ void release_open_intent(struct nameidata *nd) > > else > > fput(nd->intent.open.file); > > } > > +EXPORT_SYMBOL(release_open_intent); > > Hmm, why is this being pushed into mainline? This also looks like an > -mm only patch to me, there are no modular users of release_open_intent() > in mainline, and the next patch doesn't add one either. Err...a thinko. Good catch. Josef 'Jeff' Sipek. -- I abhor a system designed for the "user", if that word is a coded pejorative meaning "stupid and unsophisticated." - Ken Thompson - 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 and x86_64: randomize brk()
Hi,
Jiri Kosina wrote:
> >
[snip]
> > +/* overriden by architectures supporting brk randomization */
> > +void __weak arch_randomize_brk(struct mm_struct *mm) { }
I was actually suggesting in my last email:
unsigned long randomize_brk(unsigned long brk)
therefore arch specific code don't have to know about implementation
details ie how to retrieve brk values from a mm. And it also matches
the prototype of arch_align_stack().
Franck
-
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] Blackfin BF54x NAND Flash Controller driver
On Mon, 2007-09-03 at 17:46 +0100, David Woodhouse wrote:
> On Mon, 2007-09-03 at 15:25 +0800, Bryan Wu wrote:
> > + if (hardware_ecc) {
> > + if (plat->page_size == NFC_PG_SIZE_256) {
> > + chip->ecc.bytes = 3;
> > + chip->ecc.size = 256;
> > + } else if (mtd->writesize == NFC_PG_SIZE_512) {
>
> Comparing against plat->page_size in one case, but mtd->writesize in the
> other?
This is a typo in development. I will fix it ASAP. -:)
> And elsewhere it seems plat->page_size is treated as a boolean,
> indicating only 256-byte vs. 512-byte pages (you don't support 2KiB or
> other page sizes at all?)
>
When enabled hardware ECC, NFC of BF54x supports 256 and 512 bytes page
size ECC.
it's maybe little confusing with the NAND chip's pagesize. When NAND
chip is 2KiB or other page size, this driver can use multiple 256/512
pages to do hardware ECC. And it's handled by the driver software here.
-Bryan Wu
-
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] Send quota messages via netlink
On Mon 03-09-07 10:12:34, Randy Dunlap wrote: > On Mon, 3 Sep 2007 16:43:36 +0200 Jan Kara wrote: > > > User-Agent: Mutt/1.5.13 (2006-08-11) > > Mutt knows how to send patches inline vs. attachments... :( Hmm, I thought Andrew either does not mind or prefers attachments. If it isn't the case, I can inline patches. Andrew? BTW: I personally prefer attachments - mutt inlines text attachments for me anyway and sometimes it's useful to have the file structured by MIME. > +This command is used to send a notification about any of the above mentioned > +events. Each message has six attributes. These are (type of the argument is > +in braces): > > s/braces/parentheses/ > > +QUOTA_NL_A_QTYPE (u32) > + - type of quota beging exceeded (one of USRQUOTA, GRPQUOTA) > > s/beging/being/ Thanks for reading it. Andrew, should I resend the patch or will you substitute it in the patch? Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - 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 weasels and the atheros stink
Daniel Hazelton <[EMAIL PROTECTED]> writes: > Then go yell at Mr. Floeter. The code is dual-licensed and he put > BSD-License > only code in it. Because that's the *EXACT* *SAME* thing you're talking > about. Actually it is not. Dual BSD/GPL licence essentially means BSD, because rights given by BSD are a superset of these by GPL. You can legally take BSD code (or BSD/GPL, which is the same thing) and include it in GPL project (or even in closed source one). You can't legally take GPL code and include it in BSD project (or in GPL/BSD), because GPL forbids derivative works distributed under less (or more) restrictive licence than itself. Being distributed under GPL/BSD legally equals "pure" BSD (BSD allows restricting downstream, while GPL doesn't). If some file in Linux reads "GPL/BSD" then it's, in fact, under BSD licence. Crazy, isn't it? :-) The other thing is copyright notices. I think one can't legally alter someone else's licence conditions (in his/her name), unless something like that is explicitly permitted. However, we're talking about derivative works. A derivative work may be, for example, GPL-licenced: "Copyright (C) 1234 Joe the GPL lover licenced under the GPL as published" but could lawfully use code originally licenced under BSD: "Portions copyright (C) 1234 Bill the BSD lover originally licenced under no-ad BSD" Thus his (Joe's) work is GPL only, but Bill's licence notice is intact as required by it (BSD). IANAL, maybe you (all of us) should consult one if required. -- Krzysztof Halasa - 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] Send quota messages via netlink
On Mon, 3 Sep 2007 16:43:36 +0200 Jan Kara wrote: > User-Agent: Mutt/1.5.13 (2006-08-11) Mutt knows how to send patches inline vs. attachments... :( Anyway, on to the patch. Thanks for adding the new doc file. +This command is used to send a notification about any of the above mentioned +events. Each message has six attributes. These are (type of the argument is +in braces): s/braces/parentheses/ +QUOTA_NL_A_QTYPE (u32) + - type of quota beging exceeded (one of USRQUOTA, GRPQUOTA) s/beging/being/ --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bug in 2.6.22.6, net/sunrpc/svcsock.c
Hello, in 2.6.22.6, net/sunrpc/svcsock.c random characters are printed by svc_tcp_accept: lockd: last TCP connect from because buf is used unitialized: printk(KERN_NOTICE "%s: last TCP connect from %s\n", serv->sv_name, buf); Probably it should be printk(KERN_NOTICE "%s: last TCP connect from %s\n", serv->sv_name, __svc_print_addr(sin, buf, sizeof(buf))); = --- linux-2.6.22.6/net/sunrpc/svcsock.c 2007-08-27 18:10:14.0 +0200 +++ linux-2.6.22.6w/net/sunrpc/svcsock.c2007-09-03 18:27:30.0 +0200 @@ -1090,7 +1090,7 @@ serv->sv_name); printk(KERN_NOTICE "%s: last TCP connect from %s\n", - serv->sv_name, buf); + serv->sv_name, __svc_print_addr(sin, buf, sizeof(buf))); } /* * Always select the oldest socket. It's not fair, === Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts - 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: ramdisk
thanks for the reply. no , it is not decompressed. isn' t the kernel supposed to do that? As we have tried to load this filesystem on the pc, it turns out the the kernel can recognize it. concerning the root=/dev/ram0, as the default value is root=/dev/nfs, so I just modify the nfs to ram0. is this might be a problem? regards, 2007/9/3, Bill Davidsen <[EMAIL PROTECTED]>: > Xu Yang wrote: > > Hi everyone, > > > > I want to use ramdisk to boot my filesystem, as I can't use NFS and > > harddisk. > > > > I have load the ramdisk into the ram memory (start address :0x400) > > > > and in the boot options I specified : root =dev/ram0 initrd=0x400 > > > > but the kernel said it can not find any file system on it. > > > Looking at the information below, did the program which loaded the > filesystem into RAM decompress it? It noted that it was compressed so I > would assume so, but I am unfamiliar with ARM tools, so I ask the > question. Also, should the boot device be "/dev/ram0" rather than > "dev/ram0" or is that correct for your system? > > > Here is the information I can supply : > > U-Boot 1.2.0 (Aug 31 2007 - 20:54:55) > > > > *** Auto-detects ethernet chip *** > > > > > > > > DRAM: 0 kB > > ## Unknown FLASH on Bank 1 - Size = 0x = 0 MB > > Flash: 0 kB > > *** Warning - bad CRC, using default environment > > > > In:serial > > Out: serial > > Err: serial > > > > Hit any key to stop autoboot: 0 > > ## Booting image at 7fc0 ... > >Image Name: Linux-2.6.19-arm2 > >Image Type: ARM Linux Kernel Image (uncompressed) > >Data Size:740372 Bytes = 723 kB > >Load Address: 8000 > >Entry Point: 8000 > > OK > > > > > > ## Loading Ramdisk Image at 0400 ... > >Image Name: ramdisc > >Image Type: ARM Linux RAMDisk Image (gzip compressed) > >Data Size:12582962 Bytes = 12 MB > >Load Address: 0400 > >Entry Point: 0400 > > > > Starting kernel ... > > > > > > . > > > > RAMDISK driver initialized: 16 RAM disks of 10240K size 1024 blocksize > > <6>loop: loaded (max 8 devices) > > <6>mice: PS/2 mouse device common for all mice > > <6>VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 3 > > No filesystem could mount root, tried: ext2 cramfs vfat > > <0>Kernel panic - not syncing: VFS: Unable to mount root fs on > > unknown-block(1,0) > > > > > > Who can give me some hints ? or point me some direction to handle this. > > > > I appreciate this very much. > > > > regards, > > > > Yang > > > -- > Bill Davidsen <[EMAIL PROTECTED]> > "We have more to fear from the bungling of the incompetent than from > the machinations of the wicked." - from Slashdot > - 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: [pre-2.6.23 REGRESSION] 2.6.23-rc3-git1 crash/stuck on VIA CN700 system
On Mon, 03 Sep 2007 08:59:58 +0300 Stefan Becker wrote: > Hi, > > > Stefan Becker wrote: > >> > >> while trying to debug a hibernation/rtc_cmos alarm wakeup problem in > >> 2.6.22 (or later) I noticed that the latest kernel crashes (or gets > >> stuck sometimes) during boot after the message: > >> > >> SMP alternatives: switching to UP code > > Retested with 2.6.23-rc4. Same result. > > I also added "debug" to the boot command line. Unfortunately it didn't > show anything new. Comparing to 2.6.22.2 boot the next message should be > > Freeing SMP alternatives: > > Any hints what I should change on the command line or config to reveal > more information? You could try booting with 'initcall_debug' to see if that helps narrow down the error. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/5] x86: Set PCI config space size to extended for AMD Barcelona
it's so very unfortunate the PCI standard has no feature bit to indicate
the presence of ECS.
FWIW in my testing on a range of machines spanning 7 or 8 years i could
read config space reg 256... and get 0x when the device didn't
support ECS, and get valid data when the device did support ECS... granted
there may be some system out there which behaves really badly when you do
this.
perhaps someone could write a userspace program and test that concept on a
far wider range of machines.
-dean
On Mon, 3 Sep 2007, Robert Richter wrote:
> This patch sets the config space size for AMD Barcelona PCI devices to
> 4096.
>
> Signed-off-by: Robert Richter <[EMAIL PROTECTED]>
>
> ---
> arch/i386/pci/fixup.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> Index: linux-2.6/arch/i386/pci/fixup.c
> ===
> --- linux-2.6.orig/arch/i386/pci/fixup.c
> +++ linux-2.6/arch/i386/pci/fixup.c
> @@ -8,6 +8,7 @@
> #include
> #include "pci.h"
>
> +#define PCI_CFG_SPACE_EXP_SIZE 4096
>
> static void __devinit pci_fixup_i450nx(struct pci_dev *d)
> {
> @@ -444,3 +445,16 @@ static void __devinit pci_siemens_interr
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SIEMENS, 0x0015,
> pci_siemens_interrupt_controller);
> +
> +/*
> + * Extend size of PCI configuration space for AMD CPUs
> + */
> +static void __devinit pci_ext_cfg_space_access(struct pci_dev *dev)
> +{
> + dev->cfg_size = PCI_CFG_SPACE_EXP_SIZE;
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_FAM10H_HT,
> pci_ext_cfg_space_access);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_FAM10H_MAP,
> pci_ext_cfg_space_access);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_FAM10H_DRAM,
> pci_ext_cfg_space_access);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_FAM10H_MISC,
> pci_ext_cfg_space_access);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_FAM10H_LINK,
> pci_ext_cfg_space_access);
>
> --
> AMD Saxony, Dresden, Germany
> Operating System Research Center
> email: [EMAIL PROTECTED]
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
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] Blackfin BF54x NAND Flash Controller driver
On Mon, 2007-09-03 at 15:25 +0800, Bryan Wu wrote:
> + if (hardware_ecc) {
> + if (plat->page_size == NFC_PG_SIZE_256) {
> + chip->ecc.bytes = 3;
> + chip->ecc.size = 256;
> + } else if (mtd->writesize == NFC_PG_SIZE_512) {
Comparing against plat->page_size in one case, but mtd->writesize in the
other? And elsewhere it seems plat->page_size is treated as a boolean,
indicating only 256-byte vs. 512-byte pages (you don't support 2KiB or
other page sizes at all?)
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm][resend] softlockup-improve-debug-output.patch fix
On Sun, 02 Sep 2007 18:07:06 +0530, Satyam Sharma said: > > > On Sun, 2 Sep 2007, Satyam Sharma wrote: > > > > --- kernel/softlockup.c~fix 2007-09-02 04:23:49.0 +0530 > > +++ kernel/softlockup.c 2007-09-02 04:34:45.0 +0530 > ^^ > > Ick, I botched a trivial patch, it doesn't even apply. Updated one below > (with indentation fix as added bonus :-) > > > [PATCH -mm] softlockup-improve-debug-output.patch fix (v2) > > kernel/softlockup.c: In function 'softlockup_tick': > kernel/softlockup.c:125: warning: 'regs' is used uninitialized in this > function > > is a genuine bug (will cause an oops in all probability, Thanks for catching this, it was actually managing to inspire a full-scale panic - flashing LEDs and the like. Now to go track down the probably self-inflicted cause of the soft-lockup message.. ;) pgpPxCC1PYrSo.pgp Description: PGP signature
Re: Mounts and namespaces
On Mon, Sep 03, 2007 at 06:23:18PM +0200, Jan Engelhardt wrote: > Hi, > > > what happens to mounts when the namespace they exist in, exits? > In my concrete case: > > ./newns /bin/bash > # clone(CLONE_NEWNS | CLONE_THREAD | CLONE_SIGHAND | CLONE_VM) > # and exec to given program > mount /dev/loop0 /mnt > exit > > Still mounted and unreachable forever? Forced unmount and fs corruption? lazy umount. - 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/
Mounts and namespaces
Hi, what happens to mounts when the namespace they exist in, exits? In my concrete case: ./newns /bin/bash # clone(CLONE_NEWNS | CLONE_THREAD | CLONE_SIGHAND | CLONE_VM) # and exec to given program mount /dev/loop0 /mnt exit Still mounted and unreachable forever? Forced unmount and fs corruption? Jan -- - 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: [GIT PULL -mm] Unionfs/fsstack/eCryptfs updates/cleanups/fixes
In message <[EMAIL PROTECTED]>, Al Boldi writes:
> Josef 'Jeff' Sipek wrote:
> > The following is a series of patches related to Unionfs, which include
> > three small VFS/fsstack patches and one eCryptfs patch; the rest are
> > Unionfs patches. The patches here represent several months of work and
> > testing under various conditions, especially low-memory, SMP, and
> > preemption situations with an assortment of lower systems: ext2/3/4, xfs,
> > reiserfs, nfs, jffs2, ramfs, tmpfs, cramfs, and squashfs.
>
> To increase test-usage, it may be critical to always backport at least to
> the latest stable release, like 2.6.22.
>
> Thanks!
>
> --
> Al
Al, we have back-ports of the latest Unionfs to 2.6.{22,21,20,19,18,9}, all
in http://unionfs.filesystems.org/. Before we release any change, we test
it on all back-ports as well as the latest -rc/-mm code base (takes over 24
hours straight to get through all of our regressions :-)
So we'd be happy to submit those patches to the latest stable kernel. But,
are you talking about VFS/ecryptfs patches (which are in the stable kernel),
or are you talking about Unionfs (which is not)?
Thanks,
Erez.
-
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 01/32] VFS: export release_open_intent symbol
On Sun, 2 Sep 2007, Josef 'Jeff' Sipek wrote: > > diff --git a/fs/namei.c b/fs/namei.c > index a83160a..b2b7c8e 100644 > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -374,6 +374,7 @@ void release_open_intent(struct nameidata *nd) > else > fput(nd->intent.open.file); > } > +EXPORT_SYMBOL(release_open_intent); Hmm, why is this being pushed into mainline? This also looks like an -mm only patch to me, there are no modular users of release_open_intent() in mainline, and the next patch doesn't add one 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: GPL weasels and the atheros stink
On Sun, 02 Sep 2007 16:03:07 +0200, Marc Espie said: > Look at the situation: Reyk Floeter writes some code, puts it > under a dual licence, and goes on vacation. > > While he's away, some other people (Jiri, for starters) tweak the > copyright and licence on the file he's mostly written. Without asking > Reyk. Without even having the basic decency to wait for him to be > around. And we collectively told Jiri where to stick that. So let's recap: 1) Jiri submitted a borked patch that changed the licenses. 2) We didn't accept said patch. 3) There's then a whole big fuss about a *NON EXISTENT PROBLEM*. I could see where the *BSD people could complain if we had *accepted and distributed* said patch. But it was wrong, we recognized it was wrong, and the system is working as designed. So let's quit the flamefest already. Geez. pgpYuDbamhD8U.pgp Description: PGP signature
Re: [lm-sensors] [PATCH] hwmon: Add power meters to Documentation/hwmon/sysfs-interface
On Sun, 2 Sep 2007 23:02:01 -0300, Henrique de Moraes Holschuh wrote: > On Sun, 02 Sep 2007, Jean Delvare wrote: > > I guess power[1-*]_average would be OK? > > AFAIK, yes. It is probably not 100% in sync with the power supply class, > though. Is the power supply class creating sysfs files? I see a number of attributes listed in Documentation/power_supply_class.txt, but they are all uppercase, which doesn't seem suitable for sysfs file names. That document also doesn't list the numbering convention when multiple channels are present. My main worry is that we will have to add support for power measurement in libsensors, and I would like it to be as easy as possible. Thus sticking to the same naming convention hwmon have been using for years appears to be the best solution. I see that the power supply class units are 10^-6 A and 10^-6 W, so if we are supposed to be compatible, I guess we'll have to use this too. -- Jean Delvare - 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: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On Mon, Sep 03, 2007 at 04:33:19AM -0700, Arjan van de Ven wrote: > On Mon, 3 Sep 2007 11:17:18 +0200 > "Andreas Herrmann" <[EMAIL PROTECTED]> wrote: > \> > > Do you see any other issues besides the naming of the bit? > > I wonder if we should key this off a PCI ID of the chipset rather than > the cpu id... I mean, how sure are you that all via chipsets connected > to the barcelona cpu will deal well? In general they should be able to deal with those accesses. They result in extended type 0/1 configuration cycles which are defined already in HT I/O Link Spec 1.10. So if unexpectedly problems arise then it is time to add a pci-quirk. But at the moment there is no need for further discussion on this subject because Andi refuses to add support for Barcelona CF8/CFC ECS access. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - 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: bogomips discrepancy on Intel Core2 Quad CPU
On Mon, 3 Sep 2007, Bill Davidsen wrote: Bauke Jan Douma wrote: $> uname -a Linux skyscraper 2.6.22.5 #7 SMP PREEMPT Sun Sep 2 12:12:25 CEST 2007 i686 GNU/Linux $> cat /proc/cpuinfo | grep bogomips bogomips: 4813.46 bogomips: 4810.91 bogomips: 4810.91 bogomips: 10583.94 The latter seems way off base. Prod me for more info. I see this occasionally on a dual, speedstep (or similar) finds a way to throttle down the cores under light load. I suspect that if you load the system: for n in 1 2 3 4; do nice -19 bash -c 'while true; do a=$RANDOM; done' & done Then you should see your bogomips rise on all cores. bjd [... copy of output snipped, see the O.P. ...] -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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/ $ uname -a Linux p34.internal.lan 2.6.22 #2 SMP Mon Jul 16 18:40:31 EDT 2007 x86_64 GNU/Linux $ cat /proc/cpuinfo | grep bogomips bogomips: 4797.72 bogomips: 4795.16 bogomips: 4795.21 bogomips: 4795.19 Mine is fine, not using any speedstep here. Justin. - 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/
