Re: [PATCH 1/3] Remove unused dependency
On Sun, Dec 30, 2007 at 04:16:10PM -0800, Joe Perches wrote:
> On Sun, 2007-12-30 at 23:00 +0100, Sam Ravnborg wrote:
> > Can you please remind me what problem you are actually trying to solve here.
> > Your current approach it not good - we do not want .c code in include/*
> > And what is wrong with the current include path?
>
> It's not a bit deal.
>
> inflate.c is #include'd with different depth "../" prefixes.
> Currently, depths 1, 3, 4 and 5 are used.
>
The relative path is the depending on the file that includes
inflate.c. The include uses '../../../...' to get to the
root of the kernel src tree and then fetching the file in
lib/.
> It seemed neater to take this inflate.c file, which can not
> be stand-alone compiled, and move it to somewhere on the
> include path so that it may be included via #include
>
> I was originally trying to make each file in a directory via
>
> for file in $(ls lib/*.c) ; do file=${file%.c}.o ; make $file ; done
Use:
make lib/
Then you will build the right stuff - your approach is just broken.
What we should fix is the wrong dependencies in the various Makefiles.
But that require the relevant toolchains to test it and I lost them
when I recently upgraded my devel box (crosstool is my friend...).
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] byteorder: introduce le32_add_cpu & friends to core
On Sun, Dec 30, 2007 at 10:49:34PM +0100, Marcin Slusarz wrote: > I found it in XFS only. Did I miss something? These helpers come from ocfs2 which has both be and le variants. > be32_add is shorter than be32_add_cpu but I think it's not clear > whether second parameter is in native byte order or not. Then again adding foreing endian values doesn't make much sense. If you insist on your naming please make sure to convert ocfs and xfs to your naming. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH 0/3] sched: hrtick and rt group scheduling
* Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> I spend xmas implementing group scheduling for the realtime scheduling
> classes. Its a tad raw, but seems to work for the trivial test cases I
> threw at it.
>
> The hrtick stuff is unrelated but was still stuck in my sched queue.
thanks Peter, this is really cool stuff! I have picked up all 3 patches
into sched-devel.git - let's see how they work out.
(btw., i had to do the fixes below. Are you sure you sent the right
version of the patches?)
Ingo
Index: linux/kernel/sched_rt.c
===
--- linux.orig/kernel/sched_rt.c
+++ linux/kernel/sched_rt.c
@@ -337,7 +337,6 @@ static void dequeue_rt_entity(struct sch
{
struct rt_rq *rt_rq = rt_rq_of_se(rt_se);
struct rt_prio_array *array = &rt_rq->active;
- struct rt_rq *group_rq = group_rt_rq(rt_se);
list_del_init(&rt_se->run_list);
if (list_empty(array->queue + rt_se_prio(rt_se)))
@@ -527,10 +526,8 @@ static struct task_struct *pick_next_tas
do {
rt_se = pick_next_rt_entity(rq, rt_rq);
- if (unlikely(!rt_se)) {
- foo = 1;
+ if (unlikely(!rt_se))
goto retry;
- }
rt_rq = group_rt_rq(rt_se);
} while (rt_rq);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Hibernation: Document __save_processor_state() on x86-64
On Dec 30, 2007 10:57 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > > what's exactly in the hibernation image? Dirty data i suppose > > > > No, everything, including the kernel code, page tables etc. :-) > > > > > - but what about kernel-internal pages. What if we go from SLAB to > > > SLUB? What if the size of a structure changes? Etc. > > > > We can go from SLAB to SLUB just fine, it doesn't matter. The only > > thing that matters is we have to jump to the right address at the end > > of core_restore_code() (defined in arch/x86/kernel/suspend_asm_64.S). > > ok, just to make sure we are talking about the same thing. Do you mean > we can restore an image saved by v2.6.12 into v2.6.24? I.e. a 2.6.24 > kernel will be able to run a 2.6.12 kernel's hibernation image, with all > the kernel internal data from v2.6.12, etc? No way can that work. I suspect here is a slight misunderstanding: It will never be possible to switch a kernel with a hibernation/resume cycle. The new thing is, that you can use a 2.6.24-SLUB-kernel to load a 2.6.12-SLAB-kernel(*) and then have the *2.6.12* kernel continue to run. The jump that Rafael talks about is a complete switchover from the kernel doing the resume to the old kernel (and all of its data structures) from the hibernation image. The now again running old kernel will discard any internal data from the resuming kernel and so it is not important if there was a SLAB vs SLUB difference. In some way you could see the kernel loading the image as a gigantic bootloader and just as is does not matter if you use lilo or grub it should no longer matter what bootloader/kernel was used for resuming, now that a ABI for the resume has been defined. Torsten (*): 2.6.12 might not work, as Rafael said the feature supporting different kernel versions was only merge recently. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: RAID timeout parameter accessibility request
Thanks guys for your answers (please remember to keep CCing me). Robert Hancock wrote: > This always seemed a strange use case to me. If the drive is getting > read errors, either it's dying and needs to be replaced, or it has a > sporadic bad sector as a result of a power failure during write, etc. in > which case the drive should be resynchronized. In either case the drive > should be dropped from the array and require manual intervention. It > doesn't seem logical to me to just read the data from another drive and > carry on in our merry way without any warning. --> A warning message is OK, but dropping the drive from the array is excessive IMHO. And anyway, this should be user-configurable, so that it becomes each user's responsibility to choose if the drive shall be dropped or not. Currently we don't have any choice. Jan Engelhardt wrote: > Not sure about Debian, but perhaps /sys/block/md0/md/safe_mode_delay > does something? --> I'll check that out. Does someone know about how this "safe mode delay" works ? Thanasis wrote: > WD 2500YS > price same as an IDE or SATA --> All RAID edition drives are more expensive that their equivalent "desktop edition" drives (same model on "desktop edition"). Just take a look at newegg for instance. Besides, trying to find an affordable "RAID edition" model is not a solution to this technical timeout issue, just a workaraound (a bad one IMHO). Thanks anyway. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
wanting to use mmap
hi all, i read the O_DIRECT january thread: http://kerneltrap.org/mailarchive/linux-kernel/2007/1/11/44365 i am interested in using mmap as a quick way of getting data to and from disk. i also want to handle errors (like bad blocks) as well as is possible using usual read/write calls. would i be right in saying that a) mmap+madvise+msync provides almost the same function as b) read/write(2)+posix_fadvise+fsync i have read that fault-tolerance or error-handling is 'better' using (b). what does this mean exactly? i note that write(2) may return EIO - what happens if the same underlying error occurs when accessing a mmap'ed file? i notice that in the implementation of msync, fsync is called so errno might be set to EIO... ta, jack (please cc: me) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Markers Implementation for Preempt RCU Boost Tracing
* K. Prasad <[EMAIL PROTECTED]> wrote:
> @@ -486,12 +309,12 @@ void rcu_unboost_readers(void)
>
> spin_lock_irqsave(&rcu_boost_wake_lock, flags);
>
> - rcu_trace_boost_try_unboost_readers(RCU_BOOST_ME);
> + trace_mark(try_unboost_readers, "%u", smp_processor_id());
this isnt directed at you or your patch, it's more directed at Mathieu,
but looking at this actual markers patch submitted to me, i'm still
fundamentally worried about the whole marker approach.
Firstly, why on earth does a full format string have to be passed in for
something as simple as a CPU id? This way we basically codify it forever
that tracing _has_ to be expensive when enabled. The latency-tracer
(which i'd love to convert to markers, if only markers were capable
enough) has shown it that tracing _can_ be used to capture performance
data without disturbing the measured system, even at hundreds of
thousands context switches a second per CPU.
Secondly, the inlined overhead of trace_mark() is still WAY too large:
if (unlikely(__mark_##name.state)) {\
preempt_disable(); \
(*__mark_##name.call) \
(&__mark_##name, call_data, \
format, ## args); \
preempt_enable(); \
} \
Whatever became of the obvious suggestion that i outlined years ago, to
have a _single_ trace call instruction and to _patch out_ the damn
marker calls by default? No .state flag checking inlined. No
preempt_disable()/enable() pair. Patching static tracepoints OUT of the
kernel, only leaving a ~5-byte NOP sequence behind them (and some
minimal disturbance to the variables the tracepoint accesses). We've got
all the alternatives.h code patching infrastructure available for such
purposes. Why are we 2 years down the line and _STILL_ arguing about
this?
Thirdly, the patch selects CONFIG_MARKERS:
> config RCU_TRACE
> - bool "Enable tracing for RCU - currently stats in debugfs"
> + tristate "Enable tracing for RCU - currently stats in debugfs"
> select DEBUG_FS
> - default y
> + select MARKERS
Which adds overhead (inlined checks for markers) all around the kernel,
even if all markers are deactivated! Imagine a thousand of them and the
kernel blows up measurably.
Sadly, this whole trace_mark() API seems to have gotten much worse since
i last saw it. It's sub-par when it's turned on and it's sub-par when
it's turned off. It gets us the worst of both worlds.
If it continues like this then i'd much rather see people add printks as
tracing, because there you _know_ that it's high-overhead and people
wont start arguing about trace compatibility either, etc.
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] Hibernation: Document __save_processor_state() on x86-64
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > ok, just to make sure we are talking about the same thing. Do you > > mean we can restore an image saved by v2.6.12 into v2.6.24? I.e. a > > 2.6.24 kernel will be able to run a 2.6.12 kernel's hibernation > > image, with all the kernel internal data from v2.6.12, etc? No way > > can that work. > > Well, not exactly. The support for different boot and image kernels > has only been merged recently, but we can use the current git to > restore 2.6.24-rc6-mm1, for example. > > The trick is to pass a little additional information in the image > header that can be used by the boot kernel to locate the entry point > to the image kernel and the image kernel's page tables. ok - i thought you meant that there's a general capability to resume across kernel versions. (which would be close to impossible without some major surgery.) btw., in what way is this different from kexec? 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: RAID timeout parameter accessibility request
on 12/31/2007 11:54 AM Jose de la Mancha wrote the following: > > --> All RAID edition drives are more expensive that their equivalent > "desktop edition" drives (same model on "desktop edition"). Just take a look > at newegg for instance. > http://www.newegg.com/Product/Product.aspx?Item=N82E16822136055&Tpk=WD%2b2500YS -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] qgit-2.1 and qgit-1.5.8
Marco Costalba wrote: > Hi all, > > new versions of Qt4 based qgit-2.1 and stable Qt3 based qgit-1.5.8 > have been released. > > Download tarballs from > http://sourceforge.net/project/showfiles.php?group_id=139897 > > Or directly from git repositories > > git://git.kernel.org/pub/scm/qgit/qgit.git (qgit-1.5.8) > git://git.kernel.org/pub/scm/qgit/qgit4.git (qgit-2.1) > > > Stable qgit-1.5.8 has only maintenance fixes, not a lot indeed, it > happens to be already very stable. > > New stuff is in qgit-2.1, you can find a detailed changelog at > > http://git.kernel.org/?p=qgit/qgit.git;a=shortlog > > > After popular request, this time I have packaged qgit-2.1 in a nice > Windows installer (Inno Setup based) downloadable from the above > sourceforge link, so that our Window's friends can try qgit without > worrying about compilers, Qt libraries and other geeky things ;-) > > Window installer will ask you to locate the msysgit directory. Indeed > msysgit is the only supported git distribution under Windows, because > Cygwin has some issues and is also muuuch slower. > > So the only prerequisite is to have already installed msysgit > (http://code.google.com/p/msysgit/) > > > Happy new year 2008 ! > Marco Hi, I git-cloned qgit-2.1 from your repository, then ran `qmake qgit.pro`, but `make` gave me errors. Afterwards I deleted src/Makefile, ran `qmake-qt4 qgit.pro` and `make` starts compiling some files but the process ends with other errors. This is the command line: [EMAIL PROTECTED]:/usr/src/git/qgit$ make cd src && make -f Makefile make[1]: Entering directory `/usr/src/git/qgit/src' make -f Makefile.Release make[2]: Entering directory `/usr/src/git/qgit/src' g++ -c -pipe -O2 -g3 -O2 -Wno-non-virtual-dtor -Wno-long-long -pedantic -Wconversion -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I../../../../share/qt4/mkspecs/linux-g++ -I. -I../../../../include/qt4/QtCore -I../../../../include/qt4/QtCore -I../../../../include/qt4/QtGui -I../../../../include/qt4/QtGui -I../../../../include/qt4 -I../src -I../build -I../build -o ../build/customactionimpl.o customactionimpl.cpp make[2]: Leaving directory `/usr/src/git/qgit/src' make[1]: Leaving directory `/usr/src/git/qgit/src' ../build/ui_customaction.h: In member function 'void Ui_CustomActionBase::setupUi(QWidget*)': ../build/ui_customaction.h:68: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ../build/ui_customaction.h:69: error: 'class QHBoxLayout' has no member named 'setTopMargin' ../build/ui_customaction.h:70: error: 'class QHBoxLayout' has no member named 'setRightMargin' ../build/ui_customaction.h:71: error: 'class QHBoxLayout' has no member named 'setBottomMargin' ../build/ui_customaction.h:76: error: 'class QVBoxLayout' has no member named 'setLeftMargin' ../build/ui_customaction.h:77: error: 'class QVBoxLayout' has no member named 'setTopMargin' ../build/ui_customaction.h:78: error: 'class QVBoxLayout' has no member named 'setRightMargin' ../build/ui_customaction.h:79: error: 'class QVBoxLayout' has no member named 'setBottomMargin' ../build/ui_customaction.h:93: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ../build/ui_customaction.h:94: error: 'class QHBoxLayout' has no member named 'setTopMargin' ../build/ui_customaction.h:95: error: 'class QHBoxLayout' has no member named 'setRightMargin' ../build/ui_customaction.h:96: error: 'class QHBoxLayout' has no member named 'setBottomMargin' ../build/ui_customaction.h:101: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ../build/ui_customaction.h:102: error: 'class QHBoxLayout' has no member named 'setTopMargin' ../build/ui_customaction.h:103: error: 'class QHBoxLayout' has no member named 'setRightMargin' ../build/ui_customaction.h:104: error: 'class QHBoxLayout' has no member named 'setBottomMargin' ../build/ui_customaction.h:158: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ../build/ui_customaction.h:159: error: 'class QHBoxLayout' has no member named 'setTopMargin' ../build/ui_customaction.h:160: error: 'class QHBoxLayout' has no member named 'setRightMargin' ../build/ui_customaction.h:161: error: 'class QHBoxLayout' has no member named 'setBottomMargin' ../build/ui_customaction.h:166: error: 'class QVBoxLayout' has no member named 'setLeftMargin' ../build/ui_customaction.h:167: error: 'class QVBoxLayout' has no member named 'setTopMargin' ../build/ui_customaction.h:168: error: 'class QVBoxLayout' has no member named 'setRightMargin' ../build/ui_customaction.h:169: error: 'class QVBoxLayout' has no member named 'setBottomMargin' ../build/ui_customaction.h:192: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ../build/ui_customaction.h:193: error: 'class QHBoxLayout' has no member named 'setTopMargin' ../build/ui_customaction.h:194: error: 'class QHBoxLayout' has no member named 'setRightMargin' ../build/ui_customaction.h:195: error: 'class QHBoxLayout' has
Re: Get physical MAC address
Theewara Vorakosit <[EMAIL PROTECTED]> wrote: > I get MAC address from ioctl. However, ifconfig can change this MAC > address. Can I get a real physical MAC address of the NIC? First, get a network card having a physical MAC. Most cards have only a (currently configured) default MAC address, maybe you'll be lucky with some old ISA cards ... Then, don't worry about sb changing it, since these cards don't support that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Updated Kernel Hacker's guide to git
Jan Engelhardt wrote: >> http://linux.yyz.us/git-howto.html > > It says > > """Don't forget to download tags from time to time. > > git pull only downloads sha1-indexed object data, and the requested > remote head. This misses updates to the .git/refs/tags/ and > .git/refs/heads/ directories. For tags, run git fetch --tags $URL.""" > > But when I do git pull on a simple tracking tree (e.g. git-clone > torvalds/linux-2.6.git; git pull;) it automatically grabs new tags. A while ago the default behavior of git pull was changed to fetch all tags which point to objects that can be reached from any of the tracked heads. Old behaviour: Option --tags was needed to fetch tags at all. Current behavior: Option --tags forces to download all tags and the objects they point to. Option --no-tags works like the old default behavior. Readers of Kernel Hackers' Guide to git will most certainly have a recent enough version of git so that the "download_tags" subsection can be removed without replacement. -- Stefan Richter -=-=-=== ==-- = http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] qgit-2.1 and qgit-1.5.8
On Dec 31, 2007 11:59 AM, Filippo Zangheri <[EMAIL PROTECTED]> wrote: > > Hi, > > I git-cloned qgit-2.1 from your repository, then ran `qmake qgit.pro`, but > `make` gave me errors. Yes, you need qmake of Qt4 not the Qt3 one. > Afterwards I deleted src/Makefile, ran `qmake-qt4 qgit.pro` and `make` starts > compiling some files but the process ends with other errors. > This is the command line: > > [EMAIL PROTECTED]:/usr/src/git/qgit$ make > cd src && make -f Makefile > make[1]: Entering directory `/usr/src/git/qgit/src' > make -f Makefile.Release > make[2]: Entering directory `/usr/src/git/qgit/src' > g++ -c -pipe -O2 -g3 -O2 -Wno-non-virtual-dtor -Wno-long-long -pedantic > -Wconversion -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB > -I../../../../share/qt4/mkspecs/linux-g++ -I. > -I../../../../include/qt4/QtCore -I../../../../include/qt4/QtCore > -I../../../../include/qt4/QtGui -I../../../../include/qt4/QtGui > -I../../../../include/qt4 -I../src -I../build -I../build -o > ../build/customactionimpl.o customactionimpl.cpp > make[2]: Leaving directory `/usr/src/git/qgit/src' > make[1]: Leaving directory `/usr/src/git/qgit/src' > ../build/ui_customaction.h: In member function 'void > Ui_CustomActionBase::setupUi(QWidget*)': > ../build/ui_customaction.h:68: error: 'class QHBoxLayout' has no member named > 'setLeftMargin' > ../build/ui_customaction.h:69: error: 'class QHBoxLayout' has no member named > 'setTopMargin' This is because you need at least Qt 4.3 as written in the README. > > > > I'm running Debian Etch 4.0 with vanilla kernel version 2.6.23.1 and I have > the following packages installed: > > [EMAIL PROTECTED]:/usr/src/git/qgit$ dpkg -l | grep qt4 > ii libqt4-core 4.2.1-2+etch1 Qt 4 core non-GUI > functionality runtime library > ii libqt4-dev 4.2.1-2+etch1 Qt 4 development files > ii libqt4-gui 4.2.1-2+etch1 Qt 4 core GUI functionality > runtime library > ii libqt4-qt3support4.2.1-2+etch1 Qt 3 compatibility library for Qt 4 > ii libqt4-sql 4.2.1-2+etch1 Qt 4 SQL database module > ii qt4-dev-tools4.2.1-2+etch1 Qt 4 development tools > > > what am I doing wrong? > Please upgrade to Qt 4.3 and everything will be OK ;-) Happy new year Marco -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On Sun, 30 Dec 2007 16:23:20 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > > continuing to investigate for a cause. It would be nice if it were a > > BIOS-fixable problem. It would be even nicer if the BIOS were GPL... > > If it was an SMM trap, I would expect it to be trapped in the SuperIO chip. Many SuperIO chips do port 0x80, but they do it over the LPC and they do it in hardware to the parallel port data lines. The timings posted for 0x80 on his box are really a bit fast for LPC. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
As suggested by Adrian Bunk, UNIX domain sockets should always be built in on normal systems. This is especially true since udev needs these sockets and fails to run if UNIX=m. Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> --- Last minute change: I decided against making it a bool because embedded folks might depend on a small kernel image. Edited in the patch below. diff -X dontdiff -pruN linux-2.6.23.base/net/unix/Kconfig linux-2.6.23.socket-y/net/unix/Kconfig --- linux-2.6.23.base/net/unix/Kconfig 2006-11-29 22:57:37.0 +0100 +++ linux-2.6.23.socket-y/net/unix/Kconfig 2007-12-31 12:57:44.0 +0100 @@ -3,7 +3,8 @@ # config UNIX - tristate "Unix domain sockets" + tristate "Unix domain sockets" if EMBEDDED + default y ---help--- If you say Y here, you will include support for Unix domain sockets; sockets are the standard Unix mechanism for establishing and -- A. Top posters Q. What's the most annoying thing on Usenet? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: RAID timeout parameter accessibility request
Jose de la Mancha wrote: [] > Jan Engelhardt wrote: >> Not sure about Debian, but perhaps /sys/block/md0/md/safe_mode_delay >> does something? > > --> I'll check that out. Does someone know about how this "safe mode delay" > works ? It's about something entirely different. This parameter tells md after how much inactivity time to update the superblocks to indicate the array is "clean" - so that in case of power loss w/o shutting down the array, it will not require reconstruction. It has nothing to do with timeouts. By the way, linux raid is usually discussed at [EMAIL PROTECTED], not here. /mjt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On Sun 2007-12-30 21:46:50, Ingo Molnar wrote: > > * Alan Cox <[EMAIL PROTECTED]> wrote: > > > > So the current plan is to go with an io_delay=udelay default in v2.6.25, > > > to give this a migration window, and io_delay=none in v2.6.26 [and a > > > complete removal of arch/x86/kernel/io_delay.c], once the _p() uses are > > > fixed up. This is gradual enough to notice any regressions we care about > > > and also makes it nicely bisectable and gradual. > > > > You will break systems if you blindly go around disabling _p delays > > for ISA and LPC bus devices. The DEC Hinote laptops for example are > > well known for requiring the correct ISA and other keyboard controller > > delays. I don't expect anyone to test with a hinote or see it until it > > hits Debian or similar 'low resource' friendly devices. > > well, using io_delay=udelay is not 'blindly disabling'. io_delay=none > would be the end goal, once all _p() API uses are eliminated by > transformation. In drivers/ alone that's more than 1000 callsites, so > it's quite frequently used, and wont go away overnight. IOW elimination of broken inb_p()/outb_p() interfaces is the ultimate goal. Agreed. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
From: Bodo Eggert <[EMAIL PROTECTED]> Date: Mon, 31 Dec 2007 13:09:43 +0100 (CET) > As suggested by Adrian Bunk, UNIX domain sockets should always be built in > on normal systems. This is especially true since udev needs these sockets > and fails to run if UNIX=m. > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> People who use udev can make sure they have it built into their kernel if they have such a dependency. Not everyone uses udev, and therefore needs AF_UNIX non-modular. I keep seeing this crap patch get submitted and I'm going to keep dropping it because it's bogus. It seems to stem from some filesystem interface or whatever that the VFS folks don't want to export or one they want to now stop exporting. But that is a really cruddy reason to want to force AF_UNIX to not be allowed to be modular, and the udev thing just makes it more of a joke rather than a good technical reason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
Hi! > > [EMAIL PROTECTED]:~/src/port80$ su -c ./port80 > > cycles: out 2400, in 2401 > > [EMAIL PROTECTED]:~/src/port80$ su -c ./port3cc > > cycles: out 459, in 394 > > > > As stated a few dozen times by now already, port 0x80 is _decidedly_ _non_ > > _random_ > > Oh, I agree 100% that port 80 is not random. It's very much selected on > purpose. > > The reason we use port 80 is because it's commonly used as the BIOS POST > debug port, which means that it's been a reasonable "safe" port to use, > since nobody would be so crazy as to actually hook up a real device behind > that port (and since it is below 0x100, it's also part of the "motherboard > range", so you won't have any crazy plug-in devices either). Eh? I have two mainboards here that have debug displays hooked to port 0x80. I have PCI DEBUG card that has display on port 0x80. "You plug in PCI DEBUG card and it overclocks your machine" is bad scenario.. (I don't know if it does... can PCI card emulate ISA timings?) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote: > As suggested by Adrian Bunk, UNIX domain sockets should always be built in > on normal systems. This is especially true since udev needs these sockets > and fails to run if UNIX=m. > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > --- > Last minute change: I decided against making it a bool because embedded > folks might depend on a small kernel image. Edited in the patch below. >... Is this just a purely theoretical thought or is this a reasonable use case people actually use in practice? After all, changing it to a bool will allow us to make the kernel image for nearly everyone smaller by a few hundred bytes... 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bad escriptions in Kconfig
In some of the Kconfig files, the options are not adequately decribed. I collected a few of the bad descriptions I found: --- Lowlevel video output switch controls (VIDEO_OUTPUT_CONTROL) [M/n/y/?] (NEW) ? This framework adds support for low-level control of the video output switch. --- - What is THE video output switch and why would I need low level control? - Frameworks should be auto-selected like libraries, shouldn't they? - WTF is this a module? - --- Auxiliary Display support (AUXDISPLAY) [N/y/?] (NEW) ? Say Y here to get to see options for auxiliary display drivers. This option alone does not add any kernel code. --- - If I knw what an axilary display was, I would not read this help text! - After digging some time, I discovered that all Auxdisplays are parallel port devices. Rename to "Parallel port display device support"? - --- Transformation user configuration interface (XFRM_USER) [N/m/y/?] (NEW) Support for Transformation(XFRM) user configuration interface like IPsec used by native Linux tools. If unsure, say Y. --- - I'm not sure if these words combine to a sentence. - I can't tell if IPSEC is the only user or if I'd break other parts by not saying 'Y'. OTOH, I don't want to bloat my kernel ... - What's a native linux tool? - --- SCSI target support (SCSI_TGT) [N/m/y/?] (NEW) ? If you want to use SCSI target mode drivers enable this option. If you choose M, the module will be called scsi_tgt. --- What TF is a SCSI target mode, what is a target mode driver? -- I'm a member of DNA (National Assocciation of Dyslexics). -- Storm in <[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: asm-x86/msr.h for sanitized headers: clean it or punt it
Mike Frysinger <[EMAIL PROTECTED]> writes: > The current asm-x86/msr.h does not actually define anything for (!__KERNEL__ > && __i386__). For x86_64, it fails to build due to u32/u64 types being used. > Simply not installing the header seems easiest to me. Otherwise, x86_64 will > need sanitizing and i386 should have things added back, otherwise it's just a > pointless empty header. Please don't -- asm/msr.h is very useful in user space for rdtscll et.al. I use it all the time in test programs. -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: SCSI errors on powerpc with 2.6.24-rc6-mm1
FUJITA Tomonori wrote: > > Oops, it's for -mm. > Hi, I just tested this patch and it works fine for me so far. Tested-by: Balbir Singh <[EMAIL PROTECTED]> -- 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: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On Sun, 30 Dec 2007 19:14:40 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > On 30-12-07 17:48, Alan Cox wrote: > > > For processors with TSC I think we should aim for 2.6.25 to do this and > > to have the major other _p fixups done. I pity whoever does stuff like > > the scc drivers but most of the rest isn't too bad. > > I'm by the way looking at drivers/net/wd.c which my 386 uses for its dual > mode NE2000/WD8013 clone ISA NIC and while it specifically needs no delay at > all it seems, the mixed use of out and outb_p seems to suggest that someone > once thought about that. Would you advice sticking in a udelay(2) manually > there? I dug out the reference drivers. The reference drivers use the delay and the 8390 datasheet confirms it is neccessary. The Crynwr driver has some interesting things to say | The National 8390 Chip (NIC) requires 4 bus clocks between successive | chip selects (National DP8390 Data Sheet Addendum, June 1990) Also " To establish a minimum delay, an I/O instruction must be used. A good rule of ; thumb is that ISA I/O instructions take ~1.0 microseconds and MCA I/O ; instructions take ~0.5 microseconds. Reading the NMI Status Register (0x61) ; is a good way to pause on all machines." But all the official drivers use pauses and the manual says they are needed for correct, reliable behaviour - at least with a genuine 8390. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
> "You plug in PCI DEBUG card and it overclocks your machine" is bad > scenario.. (I don't know if it does... can PCI card emulate ISA timings?) Easily. Its a bit more restricted by later spec revisions but it can halt your box of a week or two if it wants. Video cards used to pull this stunt for marketing benchmark numbers. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: kprobes change kprobe_handler flow
Harvey Harrison wrote:
> Make the control flow of kprobe_handler more obvious.
>
> Collapse the separate if blocks/gotos with if/else blocks
> this unifies the duplication of the check for a breakpoint
> instruction race with another cpu.
This is a patch derived from kprobe_handler of the ARM kprobes port. This
further simplifies the current x86 kprobe_handler. The resulting definition is
smaller, more readable, has no goto's and contains only a single call to
get_kprobe.
Signed-off-by: Abhishek Sagar <[EMAIL PROTECTED]>
Signed-off-by: Quentin Barnes <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/kernel/kprobes_32.c b/arch/x86/kernel/kprobes_32.c
index 3a020f7..5a626fd 100644
--- a/arch/x86/kernel/kprobes_32.c
+++ b/arch/x86/kernel/kprobes_32.c
@@ -240,108 +240,110 @@ void __kprobes arch_prepare_kretprobe(struct
kretprobe_instance *ri,
*sara = (unsigned long) &kretprobe_trampoline;
}
+static __always_inline void setup_singlestep(struct kprobe *p,
+struct pt_regs *regs,
+struct kprobe_ctlblk *kcb)
+{
+#if !defined(CONFIG_PREEMPT) || defined(CONFIG_PM)
+ if (p->ainsn.boostable == 1 && !p->post_handler) {
+ /* Boost up -- we can execute copied instructions directly */
+ reset_current_kprobe();
+ regs->eip = (unsigned long)p->ainsn.insn;
+ preempt_enable_no_resched();
+ } else {
+ prepare_singlestep(p, regs);
+ kcb->kprobe_status = KPROBE_HIT_SS;
+ }
+#else
+ prepare_singlestep(p, regs);
+ kcb->kprobe_status = KPROBE_HIT_SS;
+#endif
+}
+
/*
* Interrupts are disabled on entry as trap3 is an interrupt gate and they
* remain disabled thorough out this function.
*/
static int __kprobes kprobe_handler(struct pt_regs *regs)
{
- struct kprobe *p;
int ret = 0;
kprobe_opcode_t *addr;
+ struct kprobe *p, *cur;
struct kprobe_ctlblk *kcb;
addr = (kprobe_opcode_t *)(regs->eip - sizeof(kprobe_opcode_t));
+ if (*addr != BREAKPOINT_INSTRUCTION) {
+ /*
+* The breakpoint instruction was removed right
+* after we hit it. Another cpu has removed
+* either a probepoint or a debugger breakpoint
+* at this address. In either case, no further
+* handling of this interrupt is appropriate.
+* Back up over the (now missing) int3 and run
+* the original instruction.
+*/
+ regs->eip -= sizeof(kprobe_opcode_t);
+ return 1;
+ }
- /*
-* We don't want to be preempted for the entire
-* duration of kprobe processing
-*/
preempt_disable();
kcb = get_kprobe_ctlblk();
+ cur = kprobe_running();
+ p = get_kprobe(addr);
- /* Check we're not actually recursing */
- if (kprobe_running()) {
- p = get_kprobe(addr);
- if (p) {
- if (kcb->kprobe_status == KPROBE_HIT_SS &&
- *p->ainsn.insn == BREAKPOINT_INSTRUCTION) {
- regs->eflags &= ~TF_MASK;
- regs->eflags |= kcb->kprobe_saved_eflags;
- goto no_kprobe;
- }
- /* We have reentered the kprobe_handler(), since
-* another probe was hit while within the handler.
-* We here save the original kprobes variables and
-* just single step on the instruction of the new probe
-* without calling any user handlers.
-*/
- save_previous_kprobe(kcb);
- set_current_kprobe(p, regs, kcb);
- kprobes_inc_nmissed_count(p);
- prepare_singlestep(p, regs);
- kcb->kprobe_status = KPROBE_REENTER;
- return 1;
- } else {
- if (*addr != BREAKPOINT_INSTRUCTION) {
- /* The breakpoint instruction was removed by
-* another cpu right after we hit, no further
-* handling of this interrupt is appropriate
-*/
- regs->eip -= sizeof(kprobe_opcode_t);
+ if (p) {
+ if (cur) {
+ switch (kcb->kprobe_status) {
+ case KPROBE_HIT_ACTIVE:
+ case KPROBE_HIT_SSDONE:
+ /* a probe has been hit inside a
+* user handler */
+ save_previous_kprobe(kcb);
+ set_current_kprobe(p, regs, kcb);
+ k
Re: Recursive variable `KBUILD_CFLAGS' references itself (eventually).
On Mon, Nov 19, 2007 at 07:14:45PM -0500, Dave Jones wrote: > Trying to do a 32bit build on a 64bit machine. > I did.. > make ARCH=i386 oldconfig > make ARCH=i386 arch/x86/ > > and got.. > > scripts/kconfig/conf -s arch/x86/Kconfig > CHK include/linux/version.h > UPD include/linux/version.h > CHK include/linux/utsrelease.h > UPD include/linux/utsrelease.h > SYMLINK include/asm -> include/asm-x86 > HOSTCC scripts/kallsyms > HOSTCC scripts/conmakehash > CC scripts/mod/empty.o > HOSTCC scripts/mod/mk_elfconfig > HOSTCC scripts/bin2c > MKELF scripts/mod/elfconfig.h > HOSTCC scripts/mod/file2alias.o > HOSTCC scripts/mod/modpost.o > HOSTCC scripts/mod/sumversion.o > HOSTLD scripts/mod/modpost > CC arch/x86/kernel/asm-offsets.s > GEN include/asm-x86/asm-offsets.h > CALLscripts/checksyscalls.sh > /mnt/raid0/src/linux-2.6/arch/x86/Makefile_32:43: *** Recursive variable > `KBUILD_CFLAGS' references itself (eventually). Stop. > make: *** [arch/x86/] Error 2 Hi Dave. Walking through my mailbox I found this one. I did not get similar reports and I cannot reproduce it. Do you continue to see this or had it been fixed somehow? The only way I can see it heppen is that you have lost the initial assignmnet in top-level Makefile so make see this as an '=' assinment and not a ':=' assignment. The first may not reference itself. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1
On Dec 30, 2007 10:35 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On Dec 30, 2007 10:24 PM, J. Bruce Fields <[EMAIL PROTECTED]> wrote:
> > From: Tom Tucker <[EMAIL PROTECTED]>
> > Date: Sun, 30 Dec 2007 10:07:17 -0600
> >
> > Bruce/Aime:
> >
> > Here is what I believe to be the fix for the crashes/svc_xprt BUG_ON
> > that people are seeing. It would be great if those who have seen this
> > problem could apply this patch and see if it resolves their problem.
> >
> > The common code calls svc_xprt_received on behalf of the transport.
> > Since the provider was calling it as well, this resulted in clearing the
> > busy bit/resetting xpt_pool when the BUSY bit wasn't held.
> >
> > diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> > index 4628881..4d39db1 100644
> > --- a/net/sunrpc/svcsock.c
> > +++ b/net/sunrpc/svcsock.c
> > @@ -1272,7 +1272,6 @@ static struct svc_xprt *svc_create_socket(struct
> > svc_serv *serv,
> >
> > if ((svsk = svc_setup_socket(serv, sock, &error, flags)) != NULL) {
> > svc_xprt_set_local(&svsk->sk_xprt, newsin, newlen);
> > - svc_xprt_received(&svsk->sk_xprt);
> > return (struct svc_xprt *)svsk;
> > }
>
> I will send a mail, when I'm done with testing this...
Removing this line from 2.6.24-rc3-mm2 does not solve my crash
FYI the codepart from net/sunrpc/svcsock.c / svc_create_socket() where
I removed this:
if (protocol == IPPROTO_TCP) {
if ((error = kernel_listen(sock, 64)) < 0)
goto bummer;
}
if ((svsk = svc_setup_socket(serv, sock, &error, flags)) != NULL) {
memcpy(&svsk->sk_xprt.xpt_local, newsin, newlen);
//svc_xprt_received(&svsk->sk_xprt);
return (struct svc_xprt *)svsk;
}
bummer:
dprintk("svc: svc_create_socket error = %d\n", -error);
The crash itself:
[11166.565362] [ cut here ]
[11166.568595] kernel BUG at lib/list_debug.c:33!
[11166.571696] invalid opcode: [1] SMP
[11166.574527] last sysfs file:
/sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
[11166.580017] CPU 3
[11166.581442] Modules linked in: radeon drm nfsd exportfs w83792d
ipv6 tuner tea5767 tda8290 tuner_xc2
028 tda9887 tuner_simple mt20xx tea5761 tvaudio msp3400 bttv ir_common
compat_ioctl32 videobuf_dma_sg v
ideobuf_core btcx_risc tveeprom videodev usbhid v4l2_common hid
v4l1_compat sg pata_amd i2c_nforce2
[11166.600470] Pid: 5548, comm: nfsv4-svc Not tainted 2.6.24-rc3-mm2 #3
[11166.604912] RIP: 0010:[] []
__list_add+0x54/0x60
[11166.610408] RSP: :81007d83fdc0 EFLAGS: 00010282
[11166.614144] RAX: 0088 RBX: 81007f2e0400 RCX: 0002
[11166.619113] RDX: 81007dc6eed0 RSI: 0001 RDI: 807590c0
[11166.624130] RBP: 81007d83fdc0 R08: 0001 R09:
[11166.629124] R10: 810080058d48 R11: 0001 R12: 81007e444680
[11166.634129] R13: 81007e4446b8 R14: 81007e4446b8 R15: 81011ff50100
[11166.639128] FS: 7fb815abc6f0() GS:81011ff13280()
knlGS:
[11166.644786] CS: 0010 DS: ES: CR0: 8005003b
[11166.648809] CR2: 00441770 CR3: 00201000 CR4: 06e0
[11166.653796] DR0: DR1: DR2:
[11166.658784] DR3: DR6: 0ff0 DR7: 0400
[11166.663783] Process nfsv4-svc (pid: 5548, threadinfo
81007D83E000, task 81007DC6EED0)
[11166.669776] Stack: 81007d83fe00 805be25e
81007e444688 81011ff50100
[11166.675428] 81007f2e0400 81007dd62000 81010a138000
81011ff50110
[11166.680660] 81007d83fe10 805be357 81007d83fee0
805bf09c
[11166.685744] Call Trace:
[11166.687592] [] svc_xprt_enqueue+0x1ae/0x250
[11166.691672] [] svc_xprt_received+0x17/0x20
[11166.695700] [] svc_recv+0x39c/0x840
[11166.699299] [] svc_send+0xaf/0xd0
[11166.702755] [] default_wake_function+0x0/0x10
[11166.706983] [] nfs_callback_svc+0x7a/0x130
[11166.710992] [] trace_hardirqs_on_thunk+0x35/0x3a
[11166.715377] [] trace_hardirqs_on+0xbf/0x160
[11166.719454] [] child_rip+0xa/0x12
[11166.722919] [] restore_args+0x0/0x30
[11166.726578] [] nfs_callback_svc+0x0/0x130
[11166.730540] [] child_rip+0x0/0x12
[11166.734024]
[11166.735072] INFO: lockdep is turned off.
[11166.737843]
[11166.737844] Code: 0f 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 8b 16 48 89 e5 e8
[11166.744160] RIP [] __list_add+0x54/0x60
[11166.748015] RSP
[11166.750464] Kernel panic - not syncing: Aiee, killing interrupt handler!
-> then the system hung, no "---[ end trace xyz ]---"-output
Will it make a difference if I try it in -rc6-mm1?
Torsten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Force UNIX domain sockets to be built in
when i had that module modular and added to the initrd, udev didn`t work, though. same error message: udevd[1226]: init_udev_socket: error getting socket: Address family not supported by protocol not sure if i did a mistake here anyway, this message is not obvious to the end user. i like the kernel being modular, but i also like it if things "just work" - and with "allmodconfig", modular UNIX domain sockets seem to create hassle. (see http://forums.gentoo.org/viewtopic-t-476363-highlight-.html or http://forums.gentoo.org/viewtopic-t-463793-highlight-.html ) so, if this patch is being rejected, maybe it would be useful if udev would give a proper hint, if it`s missing this kernel feature. btw, udev documentation telling this: - The kernel must have sysfs, unix domain sockets and networking enabled. (unix domain sockets (CONFIG_UNIX) as a loadable kernel module may work, but it is completely silly - don't complain if anything goes wrong.) furthermore, if this needs to be modular, then i`d please have tcp/ip networking modular, too. :) regards roland ps: not being a skilled programmer, so this is mostly an admins/users perspective. > > From: Bodo Eggert <[EMAIL PROTECTED]> > Date: Mon, 31 Dec 2007 13:09:43 +0100 (CET) > > > As suggested by Adrian Bunk, UNIX domain sockets should always be built in > > on normal systems. This is especially true since udev needs these sockets > > and fails to run if UNIX=m. > > > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > People who use udev can make sure they have it built into their kernel > if they have such a dependency. > > Not everyone uses udev, and therefore needs AF_UNIX non-modular. > > I keep seeing this crap patch get submitted and I'm going to keep > dropping it because it's bogus. > > It seems to stem from some filesystem interface or whatever that the > VFS folks don't want to export or one they want to now stop exporting. > > But that is a really cruddy reason to want to force AF_UNIX to not > be allowed to be modular, and the udev thing just makes it more of a > joke rather than a good technical reason. > ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007, Adrian Bunk wrote: > On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote: > > As suggested by Adrian Bunk, UNIX domain sockets should always be built in > > on normal systems. This is especially true since udev needs these sockets > > and fails to run if UNIX=m. > > > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > > > --- > > Last minute change: I decided against making it a bool because embedded > > folks might depend on a small kernel image. Edited in the patch below. > >... > > Is this just a purely theoretical thought or is this a reasonable use > case people actually use in practice? For now, it's a theoretical thought, but having an embedded device, I can see the reason for $EVERYTHING=m there. > After all, changing it to a bool will allow us to make the kernel image > for nearly everyone smaller by a few hundred bytes... I can't see why optionally building it as a module would force us to make the kernel bigger. It may be a little more ugly to support =m, but thats it, isn't it? -- Logic: The art of being wrong with confidence... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] fixup genksyms usage/getopt
On Sat, Nov 10, 2007 at 09:32:20AM -0500, Mike Frysinger wrote: > The usage does not mention the "-a,--arch" or "-T,--dump-types" options, so > add them. The calls to getopt() seem to mention options that no longer exist > (some "k" and "p" thingy) but omits the "h" option which means using '-h' > actually triggers the error code path, so update those as well. Thanks, applied. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] sleepy linux
On Sun 2007-12-30 17:39:42, Oliver Neukum wrote: > Am Sonntag, 30. Dezember 2007 00:51:34 schrieb Pavel Machek: > > Hi! > > > > > > ... I also don't need to call any suspend() routines, because all the > > > > drivers are already suspended, right? > > > > > > Well, you have a number of devices which cannot do runtime pm. > > > They can do suspend/resume with the whole system. For them these > > > operations mean saving/restoring state. > > > So for these devices implementing autosuspend makes no sense. > > > They would sensibly do only idle/busy detection. > > > > Yep... Let's call busy/idle detection and save/restore state > > "autosuspend" for those devices. It does not save any power, but it > > can be viewed as "kind-of-suspend". (No, I do not have this kind of > > details ready). > > Well, you probably would have to walk through all devices and check > all devices are either suspended or can be suspended. That would mean > struct device has to be extended to show common attributes. > > But what's wrong with calling suspend() the conventional way once you've > decided to go into sleepy mode? I'm not sure if it can be done in non-racy way. It is different from "conventional" suspend(): you can still have userland requests after this suspend(), and you should abort auto-sleep if you get one. (As opposed to blocking in system suspend case). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH 0/3] sched: hrtick and rt group scheduling
Peter Zijlstra wrote: > I spend xmas implementing group scheduling for the realtime scheduling > classes. > Its a tad raw, but seems to work for the trivial test cases I threw at it. > Excellent, will test & review and get back. > The hrtick stuff is unrelated but was still stuck in my sched queue. > > Patches against .26-rc6-mm1 > > -- > -- 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: [2.6 patch] remove references to "make dep"
On Sun, Nov 11, 2007 at 07:48:25AM +0100, Adrian Bunk wrote: > "make dep" is no longer required in kernel 2.6, but was still mentioned > in some places. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > --- > > arch/arm/mach-imx/Makefile |3 --- > arch/arm/mach-netx/Makefile|3 --- > arch/frv/kernel/gdb-stub.c |2 +- > arch/mips/tx4927/common/Makefile |4 > arch/mips/tx4938/common/Makefile |4 > arch/mips/tx4938/toshiba_rbtx4938/Makefile |4 > arch/sh64/kernel/Makefile |4 > arch/sh64/lib/Makefile |4 > arch/sh64/mach-cayman/Makefile |4 > arch/sh64/mm/Makefile |4 > arch/xtensa/mm/Makefile|4 > arch/xtensa/platform-iss/Makefile |5 - > 12 files changed, 1 insertion(+), 44 deletions(-) Thanks - applied. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007, David Miller wrote: > From: Bodo Eggert <[EMAIL PROTECTED]> > > As suggested by Adrian Bunk, UNIX domain sockets should always be built in > > on normal systems. This is especially true since udev needs these sockets > > and fails to run if UNIX=m. > > > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > People who use udev can make sure they have it built into their kernel > if they have such a dependency. > > Not everyone uses udev, and therefore needs AF_UNIX non-modular. That's why I kept this option for embedded folks. Is there any benefit for non-embedded systems from having UNIX=m? -- Top 100 things you don't want the sysadmin to say: 89. I got a better job at Lockheed... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On 31-12-07 13:23, Alan Cox wrote:
I dug out the reference drivers. The reference drivers use the delay and
the 8390 datasheet confirms it is neccessary.
Great, thanks for that.
The Crynwr driver has some interesting things to say
| The National 8390 Chip (NIC) requires 4 bus clocks between successive
| chip selects (National DP8390 Data Sheet Addendum, June 1990)
Okay, that's pretty specific. Given that these things exist on actual ISA
cards and "I/O recovery time" BIOS settings that are availabe also on these
old 386s already it's probably still at least somewhat debatable how much
linux drivers really need to care even in this case -- but let's ignore that.
Also " To establish a minimum delay, an I/O instruction must be used. A
good rule of ; thumb is that ISA I/O instructions take ~1.0 microseconds
and MCA I/O ; instructions take ~0.5 microseconds. Reading the NMI Status
Register (0x61) ; is a good way to pause on all machines."
But all the official drivers use pauses and the manual says they are
needed for correct, reliable behaviour - at least with a genuine 8390.
Okay. Am about to go stuff my face with new years celebrations but will
definitely try to make that old WD8003 hickup.
By the way, expected, but before anyone else mentions it -- no, reading from
port 0x61 is not a reliable delay today. Duron 1300 / AMD756:
[EMAIL PROTECTED]:~/src/port80$ su -c ./portime
out 0x80: 2400 cycles
in 0x80: 2400 cycles
in 0x61: 2400 cycles
But PII 400 / Intel 440BX:
[EMAIL PROTECTED]:~/port80$ su -c ./portime
out 0x80: 545 cycles
in 0x80: 254 cycles
in 0x61: 254 cycles
Rene.
/* gcc -W -Wall -O2 -o portime portime.c */
#include
#include
#include
#include
#define LOOPS 1
inline uint64_t rdtsc(void)
{
uint32_t hi, lo;
asm ("rdtsc": "=d" (hi), "=a" (lo));
return (uint64_t)hi << 32 | lo;
}
inline void serialize(void)
{
asm ("cpuid": : : "eax", "ebx", "ecx", "edx");
}
int main(void)
{
uint64_t tsc0, tsc1, tsc2, tsc3, tsc4;
uint64_t out, in8, in6;
int i;
if (iopl(3) < 0) {
perror("iopl");
return EXIT_FAILURE;
}
asm ("cli");
tsc0 = rdtsc();
for (i = 0; i < LOOPS; i++) {
serialize();
serialize();
}
tsc1 = rdtsc();
for (i = 0; i < LOOPS; i++) {
serialize();
asm ("outb %al, $0x80");
serialize();
}
tsc2 = rdtsc();
for (i = 0; i < LOOPS; i++) {
serialize();
asm ("inb $0x80, %%al": : : "al");
serialize();
}
tsc3 = rdtsc();
for (i = 0; i < LOOPS; i++) {
serialize();
asm ("inb $0x61, %%al": : : "al");
serialize();
}
tsc4 = rdtsc();
asm ("sti");
out = ((tsc2 - tsc1) - (tsc1 - tsc0)) / LOOPS;
in8 = ((tsc3 - tsc2) - (tsc1 - tsc0)) / LOOPS;
in6 = ((tsc4 - tsc3) - (tsc1 - tsc0)) / LOOPS;
printf("out 0x80: %llu cycles\n", out);
printf("in 0x80: %llu cycles\n", in8);
printf("in 0x61: %llu cycles\n", in6);
return EXIT_SUCCESS;
}
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On Sun, 30 Dec 2007, Alan Cox wrote: > On Sun, 30 Dec 2007 12:53:02 -0800 > "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > > Bodo Eggert wrote: > > > I've never seen code which would do that, and it was not suggested by any > > > tutorial I ever saw. I'd expect any machine to break on all kinds of > > > software > > > if it required this. The only thing I remember being warned about is > > > writing > > > the index and the data register at the same time using outw, because that > > > would write both registers at the same time on 16-bit-cards. > > > > > > > And we use that, and have been for 15 years. I haven't seen any screams > > of pain about it. > > Actually there were, and I sent numerous people patches for that back in > ISA days. Are you talking about VGA cards requiring a delay between outb index/outb data, VGA cards barfing on outw or systems barfing on outb(0x80,42)? -- Programming is an art form that fights back. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
On Mon, Dec 31, 2007 at 02:26:42PM +0100, Bodo Eggert wrote: > On Mon, 31 Dec 2007, Adrian Bunk wrote: > > On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote: > > > > As suggested by Adrian Bunk, UNIX domain sockets should always be built > > > in > > > on normal systems. This is especially true since udev needs these sockets > > > and fails to run if UNIX=m. > > > > > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > > > > > --- > > > Last minute change: I decided against making it a bool because embedded > > > folks might depend on a small kernel image. Edited in the patch below. > > >... > > > > Is this just a purely theoretical thought or is this a reasonable use > > case people actually use in practice? > > For now, it's a theoretical thought, but having an embedded device, I can > see the reason for $EVERYTHING=m there. The only advantage I see is that the kernel image you have to flash can be made smaller - with the disadvantage that the running kernel is bigger by more than 10%. If you don't believe me, try it yourself: Build all drivers statically into your kernel, and then compare the vmlinux sizes with CONFIG_MODULES=n and CONFIG_MODULES=y. > > After all, changing it to a bool will allow us to make the kernel image > > for nearly everyone smaller by a few hundred bytes... > > I can't see why optionally building it as a module would force us to make > the kernel bigger. It may be a little more ugly to support =m, but thats it, > isn't it? On architectures like x86 where __exit code is freed at runtime af_unix_exit() makes your kernel image (but not the running kernel) bigger. With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the theoretical possibility of CONIG_UNIX=m waste a few hundred bytes of memory. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH 0/3] sched: hrtick and rt group scheduling
On Mon, 2007-12-31 at 19:21 +0530, Balbir Singh wrote:
> Peter Zijlstra wrote:
> > I spend xmas implementing group scheduling for the realtime scheduling
> > classes.
> > Its a tad raw, but seems to work for the trivial test cases I threw at it.
> >
>
> Excellent, will test & review and get back.
replacement patch for 3/3
fixes one crash bug in smp load balancing
simplifies the throttling
ensures \Sum tg.rt_ratio <= syctl_sched_rt_ratio
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -963,6 +963,15 @@ struct sched_rt_entity {
struct list_head run_list;
unsigned int time_slice;
unsigned long timeout;
+ int nr_cpus_allowed;
+
+#ifdef CONFIG_FAIR_GROUP_SCHED
+ struct sched_rt_entity *parent;
+ /* rq on which this entity is (to be) queued: */
+ struct rt_rq*rt_rq;
+ /* rq "owned" by this entity/group: */
+ struct rt_rq*my_q;
+#endif
};
struct task_struct {
@@ -1007,7 +1016,6 @@ struct task_struct {
unsigned int policy;
cpumask_t cpus_allowed;
- int nr_cpus_allowed;
#ifdef CONFIG_PREEMPT_RCU
int rcu_read_lock_nesting;
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -161,6 +161,8 @@ struct rt_prio_array {
struct cfs_rq;
+static LIST_HEAD(task_groups);
+
/* task group related information */
struct task_group {
#ifdef CONFIG_FAIR_CGROUP_SCHED
@@ -171,6 +173,11 @@ struct task_group {
/* runqueue "owned" by this group on each cpu */
struct cfs_rq **cfs_rq;
+ struct sched_rt_entity **rt_se;
+ struct rt_rq **rt_rq;
+
+ unsigned int rt_ratio;
+
/*
* shares assigned to a task group governs how much of cpu bandwidth
* is allocated to the group. The more shares a group has, the more is
@@ -208,6 +215,7 @@ struct task_group {
unsigned long shares;
struct rcu_head rcu;
+ struct list_head list;
};
/* Default task group's sched entity on each cpu */
@@ -215,9 +223,15 @@ static DEFINE_PER_CPU(struct sched_entit
/* Default task group's cfs_rq on each cpu */
static DEFINE_PER_CPU(struct cfs_rq, init_cfs_rq) cacheline_aligned_in_smp;
+static DEFINE_PER_CPU(struct sched_rt_entity, init_sched_rt_entity);
+static DEFINE_PER_CPU(struct rt_rq, init_rt_rq) cacheline_aligned_in_smp;
+
static struct sched_entity *init_sched_entity_p[NR_CPUS];
static struct cfs_rq *init_cfs_rq_p[NR_CPUS];
+static struct sched_rt_entity *init_sched_rt_entity_p[NR_CPUS];
+static struct rt_rq *init_rt_rq_p[NR_CPUS];
+
/* task_group_mutex serializes add/remove of task groups and also changes to
* a task group's cpu shares.
*/
@@ -240,6 +254,9 @@ static void set_se_shares(struct sched_e
struct task_group init_task_group = {
.se = init_sched_entity_p,
.cfs_rq = init_cfs_rq_p,
+
+ .rt_se = init_sched_rt_entity_p,
+ .rt_rq = init_rt_rq_p,
};
#ifdef CONFIG_FAIR_USER_SCHED
@@ -269,10 +286,13 @@ static inline struct task_group *task_gr
}
/* Change a task's cfs_rq and parent entity if it moves across CPUs/groups */
-static inline void set_task_cfs_rq(struct task_struct *p, unsigned int cpu)
+static inline void set_task_rq(struct task_struct *p, unsigned int cpu)
{
p->se.cfs_rq = task_group(p)->cfs_rq[cpu];
p->se.parent = task_group(p)->se[cpu];
+
+ p->rt.rt_rq = task_group(p)->rt_rq[cpu];
+ p->rt.parent = task_group(p)->rt_se[cpu];
}
static inline void lock_task_group_list(void)
@@ -297,7 +317,7 @@ static inline void unlock_doms_cur(void)
#else
-static inline void set_task_cfs_rq(struct task_struct *p, unsigned int cpu) { }
+static inline void set_task_rq(struct task_struct *p, unsigned int cpu) { }
static inline void lock_task_group_list(void) { }
static inline void unlock_task_group_list(void) { }
static inline void lock_doms_cur(void) { }
@@ -343,13 +363,22 @@ struct cfs_rq {
struct rt_rq {
struct rt_prio_array active;
unsigned long rt_nr_running;
+#if defined CONFIG_SMP || defined CONFIG_FAIR_GROUP_SCHED
+ int highest_prio; /* highest queued rt task prio */
+#endif
#ifdef CONFIG_SMP
unsigned long rt_nr_migratory;
- int highest_prio; /* highest queued rt task prio */
int overloaded;
#endif
+ int rt_throttled;
u64 rt_time;
- u64 rt_throttled;
+
+#ifdef CONFIG_FAIR_GROUP_SCHED
+ struct rq *rq;
+ struct list_head leaf_rt_rq_list;
+ struct task_group *tg;
+ struct sched_rt_entity *rt_se;
+#endif
};
#ifdef CONFIG_SMP
@@ -411,12 +440,14 @@ struct rq {
u64 nr_switches;
struct cfs_rq cfs;
+ struct rt_rq rt;
+ u64 rt_period_expire;
+
#ifdef CONFIG_FAIR_GROUP_SCHED
Re: kexec refuses to boot latest -mm
On Sat, Dec 29, 2007 at 11:11:13AM +0530, Dhaval Giani wrote: > On Fri, Dec 28, 2007 at 09:27:39AM -0500, Vivek Goyal wrote: > > On Fri, Dec 28, 2007 at 06:15:32PM +0530, Dhaval Giani wrote: > > > Hi Vivek, > > > > > > I can't seem to get the latest -mm (2.6.24-rc6-mm1) to boot with > > > kexec. It just gets stuck at "Starting new kernel". > > > > > > It does boot normally when booted as the first kernel. > > > > > > Any hints debugging? (x86 architecture) > > > > I generally try few things. > > > > - Specify earlyprintk= parameter for second kernel and see if control > > is reaching to second kernel. > > > > - Otherwise specify --console-serial parameter on "kexec -l" commandline > > and it should display a message "I am in purgatory" on serial console. > > This will just mean that control has reached at least till purgatory. > > > > Ok, so it reaches till here. I get "I'm in purgatory" on the console. > Ok. So it atleast reaches till purgatory. My hunch is that it also reaches the second kernel but dies early in that kernel before any message can be printed on screen. Can you put some "outb()" messages on serial console in start_kernel() in second kernel and see up to what point do you reach. My 2.6.24-rc6-mm1 kernel panics during boot on 32bit box. Let me try it on 64 bit box. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: kexec refuses to boot latest -mm
On Sat, Dec 29, 2007 at 11:11:13AM +0530, Dhaval Giani wrote: > On Fri, Dec 28, 2007 at 09:27:39AM -0500, Vivek Goyal wrote: > > On Fri, Dec 28, 2007 at 06:15:32PM +0530, Dhaval Giani wrote: > > > Hi Vivek, > > > > > > I can't seem to get the latest -mm (2.6.24-rc6-mm1) to boot with > > > kexec. It just gets stuck at "Starting new kernel". > > > > > > It does boot normally when booted as the first kernel. > > > > > > Any hints debugging? (x86 architecture) > > > > I generally try few things. > > > > - Specify earlyprintk= parameter for second kernel and see if control > > is reaching to second kernel. > > > > - Otherwise specify --console-serial parameter on "kexec -l" commandline > > and it should display a message "I am in purgatory" on serial console. > > This will just mean that control has reached at least till purgatory. > > > > Ok, so it reaches till here. I get "I'm in purgatory" on the console. One more thing. Is 2.6.24-rc6 working properly? Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Bad escriptions in Kconfig
Bodo Eggert wrote: > In some of the Kconfig files, the options are not adequately decribed. I > collected a few of the bad descriptions I found: > > > --- > Lowlevel video output switch controls (VIDEO_OUTPUT_CONTROL) [M/n/y/?] (NEW) ? > > This framework adds support for low-level control of the video > output switch. > --- > > - What is THE video output switch and why would I need low level control? > > - Frameworks should be auto-selected like libraries, shouldn't they? > > - WTF is this a module? > > > - > --- > Auxiliary Display support (AUXDISPLAY) [N/y/?] (NEW) ? > > Say Y here to get to see options for auxiliary display drivers. > This option alone does not add any kernel code. > --- > > - If I knw what an axilary display was, I would not read this help text! > > - After digging some time, I discovered that all Auxdisplays are parallel > port devices. > Rename to "Parallel port display device support"? > > > - > --- > Transformation user configuration interface (XFRM_USER) [N/m/y/?] (NEW) > > Support for Transformation(XFRM) user configuration interface > like IPsec used by native Linux tools. > > If unsure, say Y. > --- > > - I'm not sure if these words combine to a sentence. > - I can't tell if IPSEC is the only user or if I'd break other parts by not > saying 'Y'. OTOH, I don't want to bloat my kernel ... > - What's a native linux tool? > > > - > --- > SCSI target support (SCSI_TGT) [N/m/y/?] (NEW) ? > > If you want to use SCSI target mode drivers enable this option. > If you choose M, the module will be called scsi_tgt. > --- > > What TF is a SCSI target mode, what is a target mode driver? Heard of google :-) For explanations of SCSI (and other storage) terminology reference could be made to SAM-3 or SAM-4 drafts (because the real standards cost money) at www.t10.org . Perhaps many other subsections in the kernel could have similar references. Doug Gilbert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: TOMOYO Linux Security Goal
Quoting Tetsuo Handa ([EMAIL PROTECTED]): > Hello. > > Serge E. Hallyn wrote: > > > > > * namespace manipulation. (i.e. mount()/umount()/pivot_root()) > > > > > > > > do you track mounts namespace cloning? > > > > > > > Yes. TOMOYO can recognize mount operation with the following flags. > > > > > > --bind --move --remount > > > --make-unbindable --make-private --make-slave --make-shared > > > > No, I mean clone(CLONE_NEWNS) and unshare(CLONE_NEWNS). Without > > tracking those, it seems like a convoluted sequence of mounting, > > unmonting, and mount sharing and unsharing could potentially confuse > > your policy or your admins... > Oh, I see. TOMOYO doesn't track clone() and unshare(). > > > I haven't fully thought it through. But at least if an admin makes a > > policy update with an expectation that all processes have the same mount > > trees the result could be unsafe. > TOMOYO doesn't expect that all processes have the same mount trees. > But TOMOYO expects that the mount trees won't change unless one of mount()/ > umount()/pivot_root() are called. > Does a process get different mount trees by just calling clone() or unshare()? > My understanding is that clone() or unshare() disables propergation of > mount tree changes when somebody calls mount() or umount() or pivot_root(). Yes, with further propagation rules possible. > > > Speak of bind mounts, there comes vfsmount problem. > > > AppArmor has been proposing patches to pass "struct vfsmount" parameter to > > > VFS helper functions and LSM hooks so that AppArmor/TOMOYO can determine > > > which pathname was requested in the bind-mounted environment. > > > Without the vfsmount patches, we can't calculate pathname without the > > > risk of > > > AB-BA deadlock (if namespace_sem held) or crash (if namespace_sem not > > > held). > > > I think we should start discussing how the vfsmount patches can be merged. > > > I'm sad to see no response for AppArmor's posting > > > at http://lkml.org/lkml/2007/12/20/182 . > > > > If the patches solve your problem, and you respond saying "TOMOYO needs > > these patches too", it just might get the thread going. > > > I'll say it when I submit patches. > > 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: [PATCH] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007, Adrian Bunk wrote: > On Mon, Dec 31, 2007 at 02:26:42PM +0100, Bodo Eggert wrote: > > On Mon, 31 Dec 2007, Adrian Bunk wrote: > > > On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote: > > > > As suggested by Adrian Bunk, UNIX domain sockets should always be built > > > > in > > > > on normal systems. This is especially true since udev needs these > > > > sockets > > > > and fails to run if UNIX=m. > > > > > > > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > > > > > > > --- > > > > Last minute change: I decided against making it a bool because embedded > > > > folks might depend on a small kernel image. Edited in the patch below. > > > >... > > > > > > Is this just a purely theoretical thought or is this a reasonable use > > > case people actually use in practice? > > > > For now, it's a theoretical thought, but having an embedded device, I can > > see the reason for $EVERYTHING=m there. > > The only advantage I see is that the kernel image you have to flash > can be made smaller - with the disadvantage that the running kernel > is bigger by more than 10%. > > If you don't believe me, try it yourself: > Build all drivers statically into your kernel, and then compare the > vmlinux sizes with CONFIG_MODULES=n and CONFIG_MODULES=y. If you'd aim for a small kernel image, you would build anything as a module that is not requred for booting. > > > After all, changing it to a bool will allow us to make the kernel image > > > for nearly everyone smaller by a few hundred bytes... > > > > I can't see why optionally building it as a module would force us to make > > the kernel bigger. It may be a little more ugly to support =m, but thats it, > > isn't it? > > On architectures like x86 where __exit code is freed at runtime > af_unix_exit() makes your kernel image (but not the running kernel) > bigger. > > With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the > theoretical possibility of CONIG_UNIX=m waste a few hundred bytes > of memory. #define m='m' #if CONIG_UNIX=='m' #define EXPORT_SYMBOL_AF_UNIX EXPORT_SYMBOL #else #define EXPORT_SYMBOL_AF_UNIX() #endif #undef m You could also use "#if defined(C_U) && (C_U == m)". -- Funny quotes: 36. You never really learn to swear until you learn to drive. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: TOMOYO Linux Security Goal
Hello. Serge E. Hallyn wrote: > > Does a process get different mount trees by just calling clone() or > > unshare()? > > My understanding is that clone() or unshare() disables propergation of > > mount tree changes when somebody calls mount() or umount() or pivot_root(). > > Yes, with further propagation rules possible. > Excuse me. To which statement did you say "yes"? Does clone() or unshare() change visible directories without calling following mount()/umount()/pivot_root()? 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: TOMOYO Linux Security Goal
--- [EMAIL PROTECTED] wrote: > I'm pretty sure that most of the security community agrees on what "correct" > means - the disagreement is in the most cost-effective way to *create* one. Struth. (I'm practicing my Australian, it's gotten rusty) I say that the the only rational way to create a policy is to decide what you want the system to do and create your policy based on that. I think that calling something that does nothing more than enforce existing behavior without thought on what the behavior ought to be a "policy" does disservice to the entire security community. I realize that I'm in the minority on this one. Oh well. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On Sun, 30 Dec 2007 21:13:29 + Alan Cox <[EMAIL PROTECTED]> wrote: > > But that does't mean that other ports won't have the same timings. > > Also, it doesn't mean that we really need to have exactly *those* > > timings. > > For ISA bus you want "at least" those timings. That is an easy case > anyway - ISA bus boxes, old processors and generally no TSC so we can > fall back to 0x80 - we know from 15 years experience the problem only > occurs with recent non ISA systems that have borked firmware. > > Lots of ISA hardware does really need the delays and most of it will > be on old processors as well naturally enough. If I recall correctly, the MediaGX/Geode processor does need _p for the PIT accesses, and that CPU family does have a TSC (even though the TSC stops at times so is hard to use). I also seem to remember that the breakage did not happen very often, but running a system without _p overnight usually showed one hiccup where a read from the counter got corrupted. So unless I'm wrong (which I very well could be, it's been a couple of years since I was debugging the PIT code on a misbehaving Geode SC1200 based system) there is at least one fairly modern CPU, which is used in lots of embedded systems, and in active use, which does need the _p. Just a data point... It's not only ancient systems that need _p. /Christer -- "Just how much can I get away with and still go to heaven?" Christer Weinigel <[EMAIL PROTECTED]> http://www.weinigel.se -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
On Dec 31 2007 16:19, Bodo Eggert wrote: >Adrian Bunk wrote: >> >> The only advantage I see is that the kernel image you have to flash >> can be made smaller - with the disadvantage that the running kernel >> is bigger by more than 10%. >> >> If you don't believe me, try it yourself: >> Build all drivers statically into your kernel, and then compare the >> vmlinux sizes with CONFIG_MODULES=n and CONFIG_MODULES=y. > >If you'd aim for a small kernel image, you would build anything as a module >that is not requred for booting. > Yes, there is a tradeoff for both. Example: 16:30 ichi:../net/802 > l fc.o fc.ko -rw-r--r-- 1 jengelh users 7961 Dec 27 15:19 fc.ko -rw-r--r-- 1 jengelh users 2453 Dec 28 23:58 fc.o (from a recent not-so-complete patch turning CONFIG_FC etc. into =m) If fc was modular, it might save the 2453 bytes off the core kernel image, but adds ~5508 bytes to disk. So one has to pick =y or =m depending on whatever suits his/her situation. But the choice should be _available_. After all, changing it to a bool will allow us to make the kernel image for nearly everyone smaller by a few hundred bytes... >>> >>> I can't see why optionally building it as a module would force us >>> to make the kernel bigger. It may be a little more ugly to >>> support =m, but thats it, isn't it? >> >> On architectures like x86 where __exit code is freed at runtime >> af_unix_exit() makes your kernel image (but not the running kernel) >> bigger. >> >> With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for >> the theoretical possibility of CONIG_UNIX=m waste a few hundred >> bytes of memory. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Bad escriptions in Kconfig
On Mon, Dec 31, 2007 at 10:16:43AM -0500, Douglas Gilbert wrote: > Bodo Eggert wrote: > > --- > > SCSI target support (SCSI_TGT) [N/m/y/?] (NEW) ? > > > > If you want to use SCSI target mode drivers enable this option. > > If you choose M, the module will be called scsi_tgt. > > --- > > > > What TF is a SCSI target mode, what is a target mode driver? > > Heard of google :-) > > For explanations of SCSI (and other storage) terminology > reference could be made to SAM-3 or SAM-4 drafts (because > the real standards cost money) at www.t10.org . > > Perhaps many other subsections in the kernel could have > similar references. I think that's an appalling idea. Someone's trying to configure their kernel, not research hundreds of new ideas on the internet. Here's a better description: help The SCSI target code allows your computer to appear as a SCSI device. This is useful in a SAN or NAS environment where you want other computers to be able to treat this computer as a disc. To compile this driver as a module, choose M here: the module will be called scsi_tgt. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
On Dec 31, 2007 3:42 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the > theoretical possibility of CONIG_UNIX=m waste a few hundred bytes > of memory. One thing I always wondered about in this discussion about wasted EXPORT_SYMBOL's: Shouldn't it be possible to garbage collect these? depmod already contains code to analyze all modules to create a dependency tree. It should not be too difficult to extend it to create a list of all symbols that really are used by the current modules. Everything else could be stripped to save space. The problem with that: * out-of-tree modules would break if they don't get lucky to only use the remaining symbol. I would not see this as a problem, if the help text of the garbage-collect-option would contain a note like "don't enable this if you want out-of-tree modules". * if you later change your .config to include additional modules you might need to rebuild vmlinux and reboot into the new kernel. Currently you can probably build and load new modules without a reboot. (for example: usb drivers) Torsten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
On Monday 31 December 2007 16:55:57 Torsten Kaiser wrote: > On Dec 31, 2007 3:42 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the > > theoretical possibility of CONIG_UNIX=m waste a few hundred bytes > > of memory. > > One thing I always wondered about in this discussion about wasted > EXPORT_SYMBOL's: > Shouldn't it be possible to garbage collect these? > > depmod already contains code to analyze all modules to create a > dependency tree. It should not be too difficult to extend it to create > a list of all symbols that really are used by the current modules. > Everything else could be stripped to save space. > > The problem with that: > * out-of-tree modules would break if they don't get lucky to only use > the remaining symbol. I would not see this as a problem, if the help > text of the garbage-collect-option would contain a note like "don't > enable this if you want out-of-tree modules". > * if you later change your .config to include additional modules you > might need to rebuild vmlinux and reboot into the new kernel. > Currently you can probably build and load new modules without a > reboot. (for example: usb drivers) I'd say the practical advantage to the user would be almost zero. Which distribution is going to enable this option and defacto banning external modules? -- Greetings Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: asm-x86/msr.h for sanitized headers: clean it or punt it
On Monday 31 December 2007, Andi Kleen wrote: > Mike Frysinger <[EMAIL PROTECTED]> writes: > > The current asm-x86/msr.h does not actually define anything for > > (!__KERNEL__ && __i386__). For x86_64, it fails to build due to u32/u64 > > types being used. Simply not installing the header seems easiest to me. > > Otherwise, x86_64 will need sanitizing and i386 should have things added > > back, otherwise it's just a pointless empty header. > > Please don't -- asm/msr.h is very useful in user space for rdtscll et.al. > I use it all the time in test programs. can you enumerate which functions need to actually go to userspace then ? the __KERNEL__ markings are a crapshoot at the moment. you must also be jumping through hoops in order to use the header in the first place since the vanilla one wont compile out of the box. -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
> Okay. Am about to go stuff my face with new years celebrations but will > definitely try to make that old WD8003 hickup. Have fun. Is it an 8390 or an 83905 ? > By the way, expected, but before anyone else mentions it -- no, reading from > port 0x61 is not a reliable delay today. Duron 1300 / AMD756: No big suprise - the comment is from about 1992. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On Mon, 31 Dec 2007 15:39:02 +0100 (CET) > > Actually there were, and I sent numerous people patches for that back in > > ISA days. > > Are you talking about VGA cards requiring a delay between outb index/outb > data, VGA cards barfing on outw or systems barfing on outb(0x80,42)? VGA cards barfing on outw - on some trident at least it would cause weird display messups when scrolling the text console that went right the next scroll. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
> I'd say the practical advantage to the user would be almost zero. > Which distribution is going to enable this option and defacto > banning external modules? It would be a real nuisance for developing code let alone for using it. The entries are currently far bigger than is needed and fixing that would be much more productive. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Recursive variable `KBUILD_CFLAGS' references itself (eventually).
On Mon, Dec 31, 2007 at 02:16:19PM +0100, Sam Ravnborg wrote: > > Trying to do a 32bit build on a 64bit machine. > > I did.. > > make ARCH=i386 oldconfig > > make ARCH=i386 arch/x86/ > > Walking through my mailbox I found this one. > I did not get similar reports and I cannot reproduce it. > Do you continue to see this or had it been fixed somehow? Still happens for me with the latest tree from git. $ make ARCH=i386 arch/x86/ HOSTCC scripts/kconfig/conf.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf -s arch/x86/Kconfig CHK include/linux/version.h CHK include/linux/utsrelease.h UPD include/linux/utsrelease.h CALLscripts/checksyscalls.sh /mnt/raid0/src/linux-2.6/arch/x86/Makefile_32:43: *** Recursive variable `KBUILD_CFLAGS' references itself (eventually). Stop. make: *** [arch/x86/] Error 2 > The only way I can see it heppen is that you have lost > the initial assignmnet in top-level Makefile so > make see this as an '=' assinment and not a ':=' > assignment. $ git diff Makefile $ (This tree is completely pristine, no changes at all) Dave -- http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.24 patch] Fix Cell OProfile support
On Saturday 29 December 2007, Mathieu Desnoyers wrote: > This patch restores the Cell OProfile support that was killed by > commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9. > > It puts it in arch/powerpc/Kconfig. Since I don't see any good reason to leave > this as a supplementary user-selectable option, it is now automatically > enabled > whenever SPU_FS and OPROFILE are enabled. This one has already been superceded by the fix in aed3a8c9bb1a8623a618232087c5ff62718e3b9a, which made CONFIG_OPROFILE_CELL an automatically selected option, from arch/powerpc/platforms/cell/Kconfig. Arnd <>< -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
On Dec 31, 2007 4:59 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > On Monday 31 December 2007 16:55:57 Torsten Kaiser wrote: > > One thing I always wondered about in this discussion about wasted > > EXPORT_SYMBOL's: > > Shouldn't it be possible to garbage collect these? > > > > depmod already contains code to analyze all modules to create a > > dependency tree. It should not be too difficult to extend it to create > > a list of all symbols that really are used by the current modules. > > Everything else could be stripped to save space. > > > > The problem with that: > > * out-of-tree modules would break if they don't get lucky to only use > > the remaining symbol. I would not see this as a problem, if the help > > text of the garbage-collect-option would contain a note like "don't > > enable this if you want out-of-tree modules". > > * if you later change your .config to include additional modules you > > might need to rebuild vmlinux and reboot into the new kernel. > > Currently you can probably build and load new modules without a > > reboot. (for example: usb drivers) > > I'd say the practical advantage to the user would be almost zero. > Which distribution is going to enable this option and defacto > banning external modules? I would default this option to not remove used symbols, because it could break something. For distributions it could be used in both ways: * enabled -> only "distro approved" modules can be loaded * disabled -> works as of now For every other user who compiles own kernels without external modules (Not including out-of-tree drivers that get patched into the kernel code! Only modules that get compiled later independent from the kernel build!) it will save space. If this space would not matter there would be no need to be so hard on currently unused EXPORT_SYMBOLs. Torsten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
On Dec 31, 2007 5:01 PM, Alan Cox <[EMAIL PROTECTED]> wrote: > > I'd say the practical advantage to the user would be almost zero. > > Which distribution is going to enable this option and defacto > > banning external modules? > > It would be a real nuisance for developing code let alone for using it. Hmm... Why? a) this could be disabled during development if you want this b) this would even only affect development if you add new code that now needs a EXPORT_SYMBOL that was removed on an earlier build. And right now this would also need to trigger a rerun of depmod. And the same trigger could redo this garbage collect. Or am I missing something obvious? > The entries are currently far bigger than is needed and fixing that would > be much more productive. Can't say anything about that. ;) Torsten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: TOMOYO Linux Security Goal
Quoting Tetsuo Handa ([EMAIL PROTECTED]): > Hello. > > Serge E. Hallyn wrote: > > > Does a process get different mount trees by just calling clone() or > > > unshare()? > > > My understanding is that clone() or unshare() disables propergation of > > > mount tree changes when somebody calls mount() or umount() or > > > pivot_root(). > > > > Yes, with further propagation rules possible. > > > Excuse me. To which statement did you say "yes"? Sorry, "yes your understanding was correct." > Does clone() or unshare() change visible directories without > calling following mount()/umount()/pivot_root()? > > Regards. > - > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 05/10] x86_64: Use generic percpu
Andi Kleen wrote: > On Friday 28 December 2007 23:05:05 Mike Travis wrote: >> Andi Kleen wrote: >>> On Friday 28 December 2007 01:10:51 [EMAIL PROTECTED] wrote: x86_64 provides an optimized way to determine the local per cpu area offset through the pda and determines the base by accessing a remote pda. >>> And? The rationale for this patch seems to be incomplete. >>> >>> As far as I can figure out you're replacing an optimized percpu >>> implementation which a dumber generic one. Which needs >>> at least some description why. >> The specific intent for the next wave of changes coming are to reduce > [...] That should be in the changelog of the patch. > > Anyways the difference between the x86 percpu.h and the generic one is > that x86-64 uses a short cut through the PDA to get the current cpu > offset for the current CPU case. The generic one goes through > smp_processor_id()->array reference instead. > > I would request that this optimization is not being removed > without suitable replacement in the same patchkit. > > -Andi I'll take a closer look at this, but it may have to wait until Christoph is back this Wednesday. Thanks, 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: [PATCH 05/10] x86_64: Use generic percpu
Ingo Molnar wrote: > * Mike Travis <[EMAIL PROTECTED]> wrote: > >>> Also for such changes .text size comparisons before/after are a good >>> idea. >> x86_64-defconfig: >> >> pre-percpu post-percpu >> 159373 .init.text +3 .init.text >> 1411137 .rodata +8 .rodata >> 3629056 .text +48 .text >> 7057383 Total +59 Total > > ok, that looks like really minimal impact, so i'm in favor of merging > this into arch/x86 - and the unification it does later on is nice too. > > to get more test feedback: what would be the best way to get this tested > in x86.git in a standalone way? Can i just pick up these 10 patches and > remove all the non-x86 arch changes, and expect it to work - or are the > other percpu preparatory/cleanup patches in -mm needed too? > > Ingo I've tested some x86_64 configs but the UP model is currently broken so I haven't been able to test that. (the "fs/nfs/super.c" build problem with TASK_NORMAL and TASK_UNINTERRUPTIBLE undefined.) Thanks, 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/
[PATCH] sh: sh7712 clock support
From: Andrew Murray <[EMAIL PROTECTED]>
This patch provides specific clock support for the SH7712. (This is my first
ever patch, so apologies if I've not followed the procedure correctly!)
Signed-off-by: Andrew Murray <[EMAIL PROTECTED]>
---
diff -uprN -x sh-2.6/Documentation/dontdiff
sh-2.6/arch/sh/kernel/cpu/sh3/clock-sh7712.c
sh-2.6-devel/arch/sh/kernel/cpu/sh3/clock-sh7712.c
--- sh-2.6/arch/sh/kernel/cpu/sh3/clock-sh7712.c1970-01-01
01:00:00.0 +0100
+++ sh-2.6-devel/arch/sh/kernel/cpu/sh3/clock-sh7712.c 2007-12-31
15:04:51.0 +
@@ -0,0 +1,81 @@
+/*
+ * arch/sh/kernel/cpu/sh3/clock-sh7712.c
+ *
+ * SH7712 support for the clock framework
+ *
+ * Copyright (C) 2007 Andrew Murray <[EMAIL PROTECTED]>
+ *
+ * Based on arch/sh/kernel/cpu/sh3/clock-sh3.c
+ * Copyright (C) 2005 Paul Mundt
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+
+static int multipliers[] = { 1, 2, 3 };
+static int divisors[]= { 1, 2, 3, 4, 6 };
+
+static void master_clk_init(struct clk *clk)
+{
+ int frqcr = ctrl_inw(FRQCR);
+ int idx = (frqcr & 0x0300) >> 8;
+
+ clk->rate *= multipliers[idx];
+}
+
+static struct clk_ops sh7712_master_clk_ops = {
+ .init = master_clk_init,
+};
+
+static void module_clk_recalc(struct clk *clk)
+{
+ int frqcr = ctrl_inw(FRQCR);
+ int idx = frqcr & 0x0007;
+
+ clk->rate = clk->parent->rate / divisors[idx];
+}
+
+static struct clk_ops sh7712_module_clk_ops = {
+ .recalc = module_clk_recalc,
+};
+
+static void bus_clk_init(struct clk *clk)
+{
+ clk->rate = CONFIG_SH_PCLK_FREQ;
+}
+
+static struct clk_ops sh7712_bus_clk_ops = {
+ .init = bus_clk_init,
+};
+
+static void cpu_clk_recalc(struct clk *clk)
+{
+ int frqcr = ctrl_inw(FRQCR);
+ int idx = (frqcr & 0x0030) >> 4;
+
+ clk->rate = clk->parent->rate / divisors[idx];
+}
+
+static struct clk_ops sh7712_cpu_clk_ops = {
+ .recalc = cpu_clk_recalc,
+};
+
+static struct clk_ops *sh7712_clk_ops[] = {
+ &sh7712_master_clk_ops,
+ &sh7712_module_clk_ops,
+ &sh7712_bus_clk_ops,
+ &sh7712_cpu_clk_ops,
+};
+
+void __init arch_init_clk_ops(struct clk_ops **ops, int idx)
+{
+ if (idx < ARRAY_SIZE(sh7712_clk_ops))
+ *ops = sh7712_clk_ops[idx];
+}
+
diff -uprN -x sh-2.6/Documentation/dontdiff
sh-2.6/arch/sh/kernel/cpu/sh3/Makefile
sh-2.6-devel/arch/sh/kernel/cpu/sh3/Makefile
--- sh-2.6/arch/sh/kernel/cpu/sh3/Makefile 2007-12-31 14:47:32.0
+
+++ sh-2.6-devel/arch/sh/kernel/cpu/sh3/Makefile2007-12-31
15:01:15.0 +
@@ -22,5 +22,6 @@ clock-$(CONFIG_CPU_SUBTYPE_SH7706):= cl
clock-$(CONFIG_CPU_SUBTYPE_SH7709) := clock-sh7709.o
clock-$(CONFIG_CPU_SUBTYPE_SH7710) := clock-sh7710.o
clock-$(CONFIG_CPU_SUBTYPE_SH7720) := clock-sh7710.o
+clock-$(CONFIG_CPU_SUBTYPE_SH7712) := clock-sh7712.o
obj-y += $(clock-y)
diff -uprN -x sh-2.6/Documentation/dontdiff
sh-2.6/include/asm-sh/cpu-sh3/freq.h sh-2.6-devel/include/asm-sh/cpu-sh3/freq.h
--- sh-2.6/include/asm-sh/cpu-sh3/freq.h2007-12-31 14:47:47.0
+
+++ sh-2.6-devel/include/asm-sh/cpu-sh3/freq.h 2007-12-31 15:02:30.0
+
@@ -10,7 +10,12 @@
#ifndef __ASM_CPU_SH3_FREQ_H
#define __ASM_CPU_SH3_FREQ_H
+#ifdef CONFIG_CPU_SUBTYPE_SH7712
+#define FRQCR 0xA415FF80
+#else
#define FRQCR 0xff80
+#endif
+
#define MIN_DIVISOR_NR 0
#define MAX_DIVISOR_NR 4
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.8 - Release Date: 24/12/2007 00:00
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: asm-x86/msr.h for sanitized headers: clean it or punt it
> can you enumerate which functions need to actually go to userspace then ? > the rdtscl/rdtscll/rdpmc primarily > __KERNEL__ markings are a crapshoot at the moment. you must also be jumping > through hoops in order to use the header in the first place since the vanilla > one wont compile out of the box. At least the 64bit one or older 32bit one works without hoops. Agreed that the paravirt changes destroyed it on newer 32bit though. That's an unfortunate regression. -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: kexec refuses to boot latest -mm
On Sat, Dec 29, 2007 at 11:11:13AM +0530, Dhaval Giani wrote: > On Fri, Dec 28, 2007 at 09:27:39AM -0500, Vivek Goyal wrote: > > On Fri, Dec 28, 2007 at 06:15:32PM +0530, Dhaval Giani wrote: > > > Hi Vivek, > > > > > > I can't seem to get the latest -mm (2.6.24-rc6-mm1) to boot with > > > kexec. It just gets stuck at "Starting new kernel". > > > > > > It does boot normally when booted as the first kernel. > > > > > > Any hints debugging? (x86 architecture) > > > > I generally try few things. > > > > - Specify earlyprintk= parameter for second kernel and see if control > > is reaching to second kernel. > > > > - Otherwise specify --console-serial parameter on "kexec -l" commandline > > and it should display a message "I am in purgatory" on serial console. > > This will just mean that control has reached at least till purgatory. > > > > Ok, so it reaches till here. I get "I'm in purgatory" on the console. Hmm..., I just tried kexeing a 2.6.24-rc6-mm1 kernel from 2.6.24-rc6 on a 32bit box and it is working for me. That's a different thing 2.6.24-rc6-mm1 crashes later because of other problems. Which kexec-tools are you using? I am using kexec-tools-testing-20071030. Thanks Vivek 2.6.24-rc6-mm1 boot BUG() Creating block device nodes. Creating root device. end_request: I/O error, dev fd0, sector 0 input: ImPS/2 Generic Wheel Mouse as /class/input/input3 Mounting root filesystem. end_request: I/O error, dev fd0, sector 0 [ cut here ] kernel BUG at fs/buffer.c:1282! invalid opcode: [#1] SMP last sysfs file: /sys/block/hdc/dev Modules linked in: Pid: 1, comm: init Not tainted (2.6.24-rc6-mm1 #2) EIP: 0060:[] EFLAGS: 00010046 CPU: 0 EIP is at __find_get_block+0x1b/0x143 EAX: 0086 EBX: ECX: 0400 EDX: 0001 ESI: 0001 EDI: f78bc000 EBP: f746e380 ESP: f7823c60 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process init (pid: 1, ti=f7822000 task=f782 task.ti=f7822000) Stack: 0001 c014b17e 0003 000a c0d0 c16e2e00 c16e2ee0 f7177000 c16e2e00 c014bec4 0001 f78bc000 f746e380 c017ecbd 0400 0001 c0d0 c0d0 c0560798 Call Trace: [] __rmqueue+0x13/0x174 [] get_page_from_freelist+0x2d1/0x344 [] __getblk+0x21/0x295 [] __alloc_pages+0x67/0x2c5 [] __bread+0xa/0x78 [] ext3_fill_super+0x138/0x1335 [] vsnprintf+0x407/0x445 [] snprintf+0x1c/0x1f [] disk_name+0x51/0x5b [] get_sb_bdev+0xce/0x10c [] __alloc_pages+0x67/0x2c5 [] __kmalloc+0x2f/0x9b [] ext3_get_sb+0x12/0x16 [] ext3_fill_super+0x0/0x1335 [] vfs_kern_mount+0x39/0x72 [] do_kern_mount+0x2f/0xb4 [] do_mount+0x5bf/0x621 [] mntput_no_expire+0x11/0x85 [] link_path_walk+0x86/0x8f [] ide_disk_put+0x1c/0x27 [] sys_stat64+0xf/0x23 [] put_filp+0x3c/0x9a [] get_page_from_freelist+0x69/0x344 [] mutex_lock+0xb/0x1a [] __alloc_pages+0x67/0x2c5 [] copy_mount_options+0x26/0x109 [] sys_mount+0x6d/0xaa
Re: Bad escriptions in Kconfig
Matthew Wilcox wrote: > On Mon, Dec 31, 2007 at 10:16:43AM -0500, Douglas Gilbert wrote: >> Bodo Eggert wrote: >>> --- >>> SCSI target support (SCSI_TGT) [N/m/y/?] (NEW) ? >>> >>> If you want to use SCSI target mode drivers enable this option. >>> If you choose M, the module will be called scsi_tgt. >>> --- >>> >>> What TF is a SCSI target mode, what is a target mode driver? >> Heard of google :-) >> >> For explanations of SCSI (and other storage) terminology >> reference could be made to SAM-3 or SAM-4 drafts (because >> the real standards cost money) at www.t10.org . >> >> Perhaps many other subsections in the kernel could have >> similar references. > > I think that's an appalling idea. Someone's trying to configure their > kernel, not research hundreds of new ideas on the internet. Here's a > better description: > > help > The SCSI target code allows your computer to appear as a SCSI > device. This is useful in a SAN or NAS environment where you > want other computers to be able to treat this computer as a disc. > > To compile this driver as a module, choose M here: the module > will be called scsi_tgt. Appalling or not, it is more accurate to define a SCSI target properly than equate it to a direct access logical unit (i.e. a disk). IMO the designers of that driver and associated applications made exactly the same mistake which they are now fixing. That driver is also transport specific with support for iSCSI and iSER. Try writing a SPI, FC or SAS target driver for scsi_tgt (I failed with SAS). It could also be noted that if the reader doesn't understand the description they can most likely say 'N'. Doug Gilbert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ip[6]_tables.c: remove some inlines
On Friday 28 December 2007 15:30, Patrick McHardy wrote:
> >> This clashes with my pending patches, which I'll push upstream
> >> today. I also spent some time resyncing ip_tables and ip6_tables
> >> so a diff of both (with some sed'ing) shows only the actual
> >> differences, so please update ip6_tables as well.
> >
> > I would be happy to rediff the patch.
> >
> > Which tree should I sync against in order to not collide
> > with your changes?
>
> The net-2.6.25.git tree contains all my changes.
ip[6]_tables.c seem to abuse inline.
This patch removes inlines except those which are used
by packet matching code and thus are performance-critical.
Please take this patch into netfilter queue.
Signed-off-by: Denys Vlasenko <[EMAIL PROTECTED]>
--
vda
diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
index f5b66ec..982b7f9 100644
--- a/net/ipv4/netfilter/ip_tables.c
+++ b/net/ipv4/netfilter/ip_tables.c
@@ -75,6 +75,7 @@ do {\
Hence the start of any table is given by get_table() below. */
/* Returns whether matches rule or not. */
+/* Performance critical - called for every packet */
static inline bool
ip_packet_match(const struct iphdr *ip,
const char *indev,
@@ -153,7 +154,7 @@ ip_packet_match(const struct iphdr *ip,
return true;
}
-static inline bool
+static bool
ip_checkentry(const struct ipt_ip *ip)
{
if (ip->flags & ~IPT_F_MASK) {
@@ -183,8 +184,9 @@ ipt_error(struct sk_buff *skb,
return NF_DROP;
}
-static inline
-bool do_match(struct ipt_entry_match *m,
+/* Performance critical - called for every packet */
+static inline bool
+do_match(struct ipt_entry_match *m,
const struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
@@ -199,6 +201,7 @@ bool do_match(struct ipt_entry_match *m,
return false;
}
+/* Performance critical */
static inline struct ipt_entry *
get_entry(void *base, unsigned int offset)
{
@@ -206,6 +209,7 @@ get_entry(void *base, unsigned int offset)
}
/* All zeroes == unconditional rule. */
+/* Mildly perf critical (only if packet tracing is on) */
static inline int
unconditional(const struct ipt_ip *ip)
{
@@ -221,7 +225,7 @@ unconditional(const struct ipt_ip *ip)
#if defined(CONFIG_NETFILTER_XT_TARGET_TRACE) || \
defined(CONFIG_NETFILTER_XT_TARGET_TRACE_MODULE)
-static const char *hooknames[] = {
+static const char *const hooknames[] = {
[NF_INET_PRE_ROUTING] = "PREROUTING",
[NF_INET_LOCAL_IN] = "INPUT",
[NF_INET_FORWARD] = "FORWARD",
@@ -235,7 +239,7 @@ enum nf_ip_trace_comments {
NF_IP_TRACE_COMMENT_POLICY,
};
-static const char *comments[] = {
+static const char *const comments[] = {
[NF_IP_TRACE_COMMENT_RULE] = "rule",
[NF_IP_TRACE_COMMENT_RETURN] = "return",
[NF_IP_TRACE_COMMENT_POLICY] = "policy",
@@ -251,6 +255,7 @@ static struct nf_loginfo trace_loginfo = {
},
};
+/* Mildly perf critical (only if packet tracing is on) */
static inline int
get_chainname_rulenum(struct ipt_entry *s, struct ipt_entry *e,
char *hookname, char **chainname,
@@ -567,7 +572,7 @@ mark_source_chains(struct xt_table_info *newinfo,
return 1;
}
-static inline int
+static int
cleanup_match(struct ipt_entry_match *m, unsigned int *i)
{
if (i && (*i)-- == 0)
@@ -579,7 +584,7 @@ cleanup_match(struct ipt_entry_match *m, unsigned int *i)
return 0;
}
-static inline int
+static int
check_entry(struct ipt_entry *e, const char *name)
{
struct ipt_entry_target *t;
@@ -600,7 +605,8 @@ check_entry(struct ipt_entry *e, const char *name)
return 0;
}
-static inline int check_match(struct ipt_entry_match *m, const char *name,
+static int
+check_match(struct ipt_entry_match *m, const char *name,
const struct ipt_ip *ip,
unsigned int hookmask, unsigned int *i)
{
@@ -623,7 +629,7 @@ static inline int check_match(struct ipt_entry_match *m, const char *name,
return ret;
}
-static inline int
+static int
find_check_match(struct ipt_entry_match *m,
const char *name,
const struct ipt_ip *ip,
@@ -652,7 +658,7 @@ err:
return ret;
}
-static inline int check_target(struct ipt_entry *e, const char *name)
+static int check_target(struct ipt_entry *e, const char *name)
{
struct ipt_entry_target *t;
struct xt_target *target;
@@ -673,7 +679,7 @@ static inline int check_target(struct ipt_entry *e, const char *name)
return ret;
}
-static inline int
+static int
find_check_entry(struct ipt_entry *e, const char *name, unsigned int size,
unsigned int *i)
{
@@ -717,7 +723,7 @@ find_check_entry(struct ipt_entry *e, const char *name, unsigned int size,
return ret;
}
-static inline int
+static int
check_entry_size_and_hooks(struct ipt_entry *e,
struct xt_table_info *newinfo,
unsigned char *base,
@@ -760,7 +766,7 @@ check_entry_size_and_hooks(struct ipt_entry *e,
return 0;
}
-static inline int
+static int
cleanup_entry(struct ipt_entry *e, unsigned int *i)
{
struct ipt_entry_targe
Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
On Mon, 31 Dec 2007 17:57:35 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > FUJITA Tomonori wrote: > > > > Oops, it's for -mm. > > > > Hi, > > I just tested this patch and it works fine for me so far. > > Tested-by: Balbir Singh <[EMAIL PROTECTED]> Thanks! I sent an updated patch including this fix several hours ago: http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048997.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007 17:17:19 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote: > a) this could be disabled during development if you want this > b) this would even only affect development if you add new code that > now needs a EXPORT_SYMBOL that was removed on an earlier build. And > right now this would also need to trigger a rerun of depmod. And the > same trigger could redo this garbage collect. > > Or am I missing something obvious? Development is not a phase seperate from use or distribution. A lot of module testers for distributions will not be compiling their own modules but loading in ones to test provided by their vendor - which may of course then need different ksyms Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] remove __init modifier from header declaration
On Wed, Dec 19, 2007 at 11:12:36AM +0100, Ingo Molnar wrote: > * Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote: > > > This patch removes the __init modifier from an extern function > > declaration in acpi.h. > > > > Besides not being strictly needed, it requires the inclusion of > > linux/init.h, which is usually not even included directly, increasing > > header mess by a lot. > > thanks, applied. > > btw., people have been talking about reducing the include file mess for > nearly a decade now, Some of us are actually doing it. ;-) > but it didnt get that much better - at least not in > include/asm-x86/*.h. That's because hunting in include/linux/ is much more fruitful -- it decreases amount of code after preprocessing for everyone. Below are allyesconfig on x86_64 results for some kernels: $ wc ../*.i 79018171 229433654 2049266884 ../2.6.18.i 86568111 250674099 2245115663 ../2.6.19.i 85187296 247470579 2221334183 ../2.6.20.i <=== 88645422 242396928 2234855428 ../2.6.21.i 93897302 257990496 2377174442 ../2.6.22.i 98381373 268683402 2486321956 ../2.6.23.i E.g. we can have ~1.07% decrease in cpp output despite ~126000 lines added between .19 and .20. > So include file dependency flattening patches would > be more than welcome as well. Yup! Provided they're compile-tested sufficiently well. > (and unlike unification patches they have > no expectation of being 100% perfect, so a natural ping-pong of fixes, > until the changes are fully correct, would be natural.) That way you'll never clean anything especially during merge window. ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] sh: sh7712 clock support
On Mon, Dec 31, 2007 at 04:32:25PM -, Andrew Murray wrote:
> +static void bus_clk_init(struct clk *clk)
> +{
> + clk->rate = CONFIG_SH_PCLK_FREQ;
> +}
> +
> +static struct clk_ops sh7712_bus_clk_ops = {
> + .init = bus_clk_init,
> +};
> +
This shouldn't be necessary, the bus clk already references the master
clk as its parent, and inherits the rate from there. If you have no
recalc work to do, then you should be able to just leave this out
altogether. If you actually need this dummy init, then something is
broken with the upper layer, which we should fix ;-)
Patch looks fine otherwise. Tidy this up and I'll apply it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ip[6]_tables.c: remove some inlines
Denys Vlasenko wrote: ip[6]_tables.c seem to abuse inline. This patch removes inlines except those which are used by packet matching code and thus are performance-critical. Some people also consider the ruleset replacement path performance critical, but overall I agree with your patch. I'm travelling currently though so it will take a few days until I'll apply it. Do you have some numbers that show the actual difference these changes make? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 05/10] x86_64: Use generic percpu
Mike Travis wrote: > Ingo Molnar wrote: >> * Mike Travis <[EMAIL PROTECTED]> wrote: >> Also for such changes .text size comparisons before/after are a good idea. >>> x86_64-defconfig: >>> >>> pre-percpu post-percpu >>> 159373 .init.text +3 .init.text >>> 1411137 .rodata +8 .rodata >>> 3629056 .text +48 .text >>> 7057383 Total +59 Total >> ok, that looks like really minimal impact, so i'm in favor of merging >> this into arch/x86 - and the unification it does later on is nice too. >> >> to get more test feedback: what would be the best way to get this tested >> in x86.git in a standalone way? Can i just pick up these 10 patches and >> remove all the non-x86 arch changes, and expect it to work - or are the >> other percpu preparatory/cleanup patches in -mm needed too? >> >> Ingo > > I've tested some x86_64 configs but the UP model is currently broken so I > haven't been able to test that. (the "fs/nfs/super.c" build problem with > TASK_NORMAL and TASK_UNINTERRUPTIBLE undefined.) > > Thanks, > Mike Sorry, I guess I didn't exactly answer the question. Yes, these changes are standalone. Thanks, 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: 2.6.24-rc6-mm1 - git-lblnet.patch and networking horkage
On Wednesday 26 December 2007 4:52:03 pm James Morris wrote: > On Thu, 26 Dec 2007, Paul Moore wrote: > > As James said I'm away right now and computer access is limited. > > However, I'm stuck in the airport right now and spent some time looking > > at the code ... Based on what has been found so far I wonder if the > > problem isn't a race but a problem of skb->iif never being initialized > > correctly? To my untrained eye it looks like __netdev_alloc_skb() > > should be setting skb->iif (like it does for skb->dev) but it currently > > doesn't. > > ->iif will be zeroed during skb allocation, then set during > netif_receive_skb(). I was able to reproduce this bug this morning by running avahi as James did and did a little more digging. I don't have a fix yet, but thought I would pass along what I've found in case this triggers a moment of clarity to someone out there ... The skb->iif value appears to be messed up as early as netif_receive_skb(), in my case it is set to 196611 (trust me, I don't have that many interfaces in my test machine) which causes the ->iif initialization code in netif_receive_skb() to be skipped because ->iif is greater than zero. This particular packet is locally generated and locally consumed. Hopefully I'll have a fix later this afternoon but if someone has a bright idea I'd love to hear it. Backtrace is below: WARNING: at security/selinux/hooks.c:3805 selinux_socket_sock_rcv_skb() Pid: 1454, comm: avahi-daemon Not tainted 2.6.24-rc5 #4 [] selinux_socket_sock_rcv_skb+0x96/0x3ac [] printk+0x1b/0x1f [] __print_symbol+0x21/0x2a [] security_sock_rcv_skb+0xc/0xd [] sock_queue_rcv_skb+0x29/0xce [] ipt_do_table+0x423/0x466 [ip_tables] [] udp_queue_rcv_skb+0x199/0x201 [] vsnprintf+0x283/0x450 [] nf_conntrack_in+0x307/0x3d7 [nf_conntrack] [] __udp4_lib_rcv+0x3ee/0x7a7 [] nf_ct_deliver_cached_events+0x8/0x90 [nf_conntrack] [] ipv4_confirm+0x34/0x39 [nf_conntrack_ipv4] [] nf_iterate+0x3a/0x6e [] ip_local_deliver_finish+0x0/0x191 [] ip_local_deliver_finish+0x0/0x191 [] ip_local_deliver_finish+0x112/0x191 [] ip_rcv_finish+0x254/0x273 [] ip_rcv_finish+0x0/0x273 [] ip_rcv+0x1cc/0x1fb [] ip_rcv_finish+0x0/0x273 [] ip_rcv+0x0/0x1fb [] netif_receive_skb+0x37d/0x397 [] process_backlog+0x60/0x92 [] net_rx_action+0x67/0x118 [] __do_softirq+0x35/0x75 [] do_softirq+0x3e/0x8d [] local_bh_enable+0x6b/0x79 [] nf_ct_deliver_cached_events+0x8/0x90 [nf_conntrack] [] ipv4_confirm+0x34/0x39 [nf_conntrack_ipv4] [] ipv4_confirm+0x0/0x39 [nf_conntrack_ipv4] [] nf_iterate+0x3a/0x6e [] ip_finish_output+0x0/0x208 [] nf_hook_slow+0x4d/0xb5 [] ip_finish_output+0x0/0x208 [] ip_mc_output+0x172/0x18b [] ip_finish_output+0x0/0x208 [] ip_push_pending_frames+0x2be/0x311 [] dst_output+0x0/0x7 [] udp_push_pending_frames+0x298/0x2d7 [] udp_sendmsg+0x459/0x55c [] inet_sendmsg+0x3b/0x45 [] sock_sendmsg+0xc8/0xe3 [] autoremove_wake_function+0x0/0x33 [] sock_sendmsg+0xc8/0xe3 [] autoremove_wake_function+0x0/0x33 [] copy_from_user+0x32/0x5e [] copy_from_user+0x32/0x5e [] sys_sendmsg+0x192/0x1f7 [] current_fs_time+0x13/0x15 [] file_update_time+0x21/0x61 [] pipe_write+0x3cc/0x3d8 [] do_sync_write+0x0/0x109 [] do_sync_write+0xc6/0x109 [] autoremove_wake_function+0x0/0x33 [] sys_socketcall+0x240/0x261 [] syscall_call+0x7/0xb === -- paul moore linux security @ hp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
On Monday 31 December 2007 17:38:03 Alan Cox wrote: > On Mon, 31 Dec 2007 17:17:19 +0100 > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote: > > > a) this could be disabled during development if you want this > > b) this would even only affect development if you add new code that > > now needs a EXPORT_SYMBOL that was removed on an earlier build. And > > right now this would also need to trigger a rerun of depmod. And the > > same trigger could redo this garbage collect. > > > > Or am I missing something obvious? > > Development is not a phase seperate from use or distribution. A lot of > module testers for distributions will not be compiling their own modules > but loading in ones to test provided by their vendor - which may of > course then need different ksyms As an example, the whole purpose wireless-compat package is to load latest bleeding edge wireless stuff into a distribution kernel. So people are not required to recompile their kernels for using drivers that support their hardware. And guess what, it is used a _lot_. And lots of bugs are found with it. It increases our testing community a lot. So, all this wouldn't work, if kernel symbols could randomly get nuked by some "garbage collector". In practice, no distribution would use symbol garbage collection, as the only benefit from it would be an increased level of bugreports. -- Greetings Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [CFT] Code clarification patch to Kprobes arch code
Since people are discussing some x86 Kprobes code cleanup, I thought
I would contribute a small change as well. When developing the
Kprobes arch code for ARM, I ran across some code found in x86 and
s390 Kprobes arch code which I didn't consider as good as it could
be.
Once I figured out what the code was doing, I changed the code
for ARM Kprobes to work the way I felt was more appropriate.
I've tested the code this way in ARM for about a year and would
like to push the same change to the other affected architectures.
The code in question is in kprobe_exceptions_notify() which
does:
/* kprobe_running() needs smp_processor_id() */
preempt_disable();
if (kprobe_running() &&
kprobe_fault_handler(args->regs, args->trapnr))
ret = NOTIFY_STOP;
preempt_enable();
For the moment, ignore the code having the preempt_disable()/
preempt_enable() pair in it.
The problem is that kprobe_running() needs to call smp_processor_id()
which will assert if preemption is enabled. That sanity check by
smp_processor_id() makes perfect sense since calling it with preemption
enabled would return an unreliable result.
But the function kprobe_exceptions_notify() can be called from a
context where preemption could be enabled. If that happens, the
assertion in smp_processor_id() happens and we're dead. So what
the original author did (speculation on my part!) is put in the
preempt_disable()/preempt_enable() pair to simply defeat the check.
Once I figured out what was going on, I considered this an
inappropriate approach. If kprobe_exceptions_notify() is called
from a preemptible context, we can't be in a kprobe processing
context at that time anyways since kprobes requires preemption to
already be disabled, so just check for preemption enabled, and if
so, blow out before ever calling kprobe_running(). I wrote the ARM
kprobe code like this:
/* To be potentially processing a kprobe fault and to
* trust the result from kprobe_running(), we have
* be non-preemptible. */
if (!preemptible() && kprobe_running() &&
kprobe_fault_handler(args->regs, args->trapnr))
ret = NOTIFY_STOP;
The above code has been working fine for ARM Kprobes for a year.
So I changed the x86 code (2.6.24-rc6) to be the same way and ran
the Systemtap tests on that kernel. As on ARM, Systemtap on x86
comes up with the same test results either way, so it's a neutral
external functional change (as expected).
This issue has been discussed previously on linux-arm-kernel and the
Systemtap mailing lists. Pointers to the by base for the two
discussions:
http://lists.arm.linux.org.uk/lurker/message/20071219.223225.1f5c2a5e.en.html
http://sourceware.org/ml/systemtap/2007-q1/msg00251.html
I felt it was time to push it out and also get testing feedback from
the affected architectures (s390/x86_{32|64}).
Thoughts? Comments?
Quentin
Patch for the suggested change to 2.6.24-rc6.
Signed-off-by: Quentin Barnes <[EMAIL PROTECTED]>
diff --git a/arch/s390/kernel/kprobes.c b/arch/s390/kernel/kprobes.c
index c5549a2..53b167f 100644
--- a/arch/s390/kernel/kprobes.c
+++ b/arch/s390/kernel/kprobes.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
#include
@@ -595,12 +596,12 @@ int __kprobes kprobe_exceptions_notify(struct
notifier_block *self,
ret = NOTIFY_STOP;
break;
case DIE_TRAP:
- /* kprobe_running() needs smp_processor_id() */
- preempt_disable();
- if (kprobe_running() &&
+ /* To be potentially processing a kprobe fault and to
+* trust the result from kprobe_running(), we have
+* be non-preemptible. */
+ if (!preemptible() && kprobe_running() &&
kprobe_fault_handler(args->regs, args->trapnr))
ret = NOTIFY_STOP;
- preempt_enable();
break;
default:
break;
diff --git a/arch/x86/kernel/kprobes_32.c b/arch/x86/kernel/kprobes_32.c
index 3a020f7..007fbdf 100644
--- a/arch/x86/kernel/kprobes_32.c
+++ b/arch/x86/kernel/kprobes_32.c
@@ -29,6 +29,7 @@
#include
#include
+#include
#include
#include
#include
@@ -668,12 +669,12 @@ int __kprobes kprobe_exceptions_notify(struct
notifier_block *self,
ret = NOTIFY_STOP;
break;
case DIE_GPF:
- /* kprobe_running() needs smp_processor_id() */
- preempt_disable();
- if (kprobe_running() &&
+ /* To be potentially processing a kprobe fault and to
+* trust the result from kprobe_running(), we have
+* be non-preemptible. */
+ if (!preemptible() && kprobe_running() &&
kprobe_fault_handler(args->regs, args->trapnr))
Re: Updated Kernel Hacker's guide to git
Stefan Richter <[EMAIL PROTECTED]> writes: > Jan Engelhardt wrote: >>> http://linux.yyz.us/git-howto.html >> >> It says >> >> """Don't forget to download tags from time to time. >> >> git pull only downloads sha1-indexed object data, and the requested >> remote head. This misses updates to the .git/refs/tags/ and >> .git/refs/heads/ directories. For tags, run git fetch --tags $URL.""" >> >> But when I do git pull on a simple tracking tree (e.g. git-clone >> torvalds/linux-2.6.git; git pull;) it automatically grabs new tags. > > A while ago the default behavior of git pull was changed to fetch all > tags which point to objects that can be reached from any of the tracked > heads. > > Old behaviour: Option --tags was needed to fetch tags at all. Current > behavior: Option --tags forces to download all tags and the objects > they point to. Option --no-tags works like the old default behavior. > > Readers of Kernel Hackers' Guide to git will most certainly have a > recent enough version of git so that the "download_tags" subsection can > be removed without replacement. All correct. That "A while ago" is quite a while ago, though. IIRC it was added very early in 2006, which is eons ago in git timescale. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Hibernation: Document __save_processor_state() on x86-64
On Monday, 31 of December 2007, Ingo Molnar wrote: > > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > > ok, just to make sure we are talking about the same thing. Do you > > > mean we can restore an image saved by v2.6.12 into v2.6.24? I.e. a > > > 2.6.24 kernel will be able to run a 2.6.12 kernel's hibernation > > > image, with all the kernel internal data from v2.6.12, etc? No way > > > can that work. > > > > Well, not exactly. The support for different boot and image kernels > > has only been merged recently, but we can use the current git to > > restore 2.6.24-rc6-mm1, for example. > > > > The trick is to pass a little additional information in the image > > header that can be used by the boot kernel to locate the entry point > > to the image kernel and the image kernel's page tables. > > ok - i thought you meant that there's a general capability to resume > across kernel versions. (which would be close to impossible without some > major surgery.) Well, there will be one. :-) For example, one should be able to use a 2.6.25+ boot kernel to load the image containing 2.6.24-rc6 and restore the memory state from it. > btw., in what way is this different from kexec? Not that much different indeed. The hibernation code is more focused on restoring the pre-hibernation state of the system rather than anything else, plus on ACPI systems we try to handle the platform in accordance with the specification (to some extent - you'd have to use a non-ACPI boot kernel to follow the specification literally, which is possible but not straightforward). 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/
Re: [ANNOUNCE] qgit-2.1 and qgit-1.5.8
On Mon, Dec 31 2007 at 13:58 +0200, "Marco Costalba" <[EMAIL PROTECTED]> wrote: > On Dec 31, 2007 11:59 AM, Filippo Zangheri <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I git-cloned qgit-2.1 from your repository, then ran `qmake qgit.pro`, but >> `make` gave me errors. > > Yes, you need qmake of Qt4 not the Qt3 one. > A Theoretical question. Is it possible to compile Qt4 app all statically linked and run it on a Qt3 based KDE machine. Some thing like the windows installation, where every thing is self-contained? Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [usb regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
On Sun, 30 Dec 2007, Greg KH wrote:
> > It looks like Greg misused the debugfs API -- which is ironic, because
> > he wrote debugfs in the first place! :-)
>
> Oh crap, sorry, I did mess that up :(
>
> > Let me know if this patch fixes the problem. If it does, I'll submit
> > it to Greg with all the proper accoutrements.
>
> This isn't going to work if CONFIG_DEBUGFS is not enabled either :(
Why not? The debugging files won't be created, true, but the driver
should work just fine regardless. This is exactly the way uhci-hcd
behaves, and it hasn't caused any problems.
> > Index: 2.6.24-rc6-mm1/drivers/usb/host/ohci-hcd.c
> > ===
> > --- 2.6.24-rc6-mm1.orig/drivers/usb/host/ohci-hcd.c
> > +++ 2.6.24-rc6-mm1/drivers/usb/host/ohci-hcd.c
> > @@ -1067,14 +1067,8 @@ static int __init ohci_hcd_mod_init(void
> >
> > #ifdef DEBUG
> > ohci_debug_root = debugfs_create_dir("ohci", NULL);
> > - if (!ohci_debug_root || IS_ERR(ohci_debug_root)) {
> > - if (!ohci_debug_root)
> > - retval = -ENOENT;
> > - else
> > - retval = PTR_ERR(ohci_debug_root);
> > -
> > - goto error_debug;
> > - }
> > + if (!ohci_debug_root)
> > + return -ENOENT;
>
> It needs to check for ERR_PTR(-ENODEV) which is the return value if
> debugfs is not enabled, and if so, just ignore things.
No. That is the mistake you made before. If debugfs isn't enabled
then the driver should just ignore things, yes -- and in particular it
should ignore the fact that the return code is ERR_PTR(-ENODEV). No
extra checking is required.
> If NULL is returned, or anything else, it's a real error.
If NULL is returned, it's a real error, agreed. But if anything else
is returned then the call was successful as far as the driver is
concerned.
> So, try something like:
> if (!ohci_debug_root) {
> retval = -ENOENT;
> goto error_debug;
> }
> if (IS_ERR(ohci_debug_root) && PTR_ERR(ohci_debug_root) != -ENODEV) {
> retval = PTR_ERR(ohci_debug_root);
> goto error_debug;
> }
>
> and let me know of that works for you.
Greg, it sounds like you have forgotten the rationale you originally
used for specifying the return codes in debugfs! The idea was to
return non-NULL if CONFIG_DEBUGFS was disabled, so that drivers could
pretend the calls had succeeded and not need to worry about matters
beyond their control.
Only a NULL return indicates a genuine error. The kerneldoc for
debugfs_create_dir says this very plainly.
> Although the combination of CONFIG_USB_DEBUG and not CONFIG_DEBUGFS is
> strange, we could just enable CONFIG_DEBUGFS is USB_DEBUG is enabled and
> then simplify this logic a bunch at the same time.
Most distributions enable CONFIG_DEBUGFS by default, don't they? So
this problem only comes up when people make up their own configs.
Having USB_DEBUG enabled and DEBUGFS disabled seems like a perfectly
reasonable combination to me. I wouldn't change any aspect of the
configuration logic.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Force UNIX domain sockets to be built in
On Mon, Dec 31, 2007 at 04:19:23PM +0100, Bodo Eggert wrote: > On Mon, 31 Dec 2007, Adrian Bunk wrote: > > On Mon, Dec 31, 2007 at 02:26:42PM +0100, Bodo Eggert wrote: > > > On Mon, 31 Dec 2007, Adrian Bunk wrote: > > > > On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote: > > > > > > As suggested by Adrian Bunk, UNIX domain sockets should always be > > > > > built in > > > > > on normal systems. This is especially true since udev needs these > > > > > sockets > > > > > and fails to run if UNIX=m. > > > > > > > > > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > > > > > > > > > --- > > > > > Last minute change: I decided against making it a bool because > > > > > embedded > > > > > folks might depend on a small kernel image. Edited in the patch below. > > > > >... > > > > > > > > Is this just a purely theoretical thought or is this a reasonable use > > > > case people actually use in practice? > > > > > > For now, it's a theoretical thought, but having an embedded device, I can > > > see the reason for $EVERYTHING=m there. > > > > The only advantage I see is that the kernel image you have to flash > > can be made smaller - with the disadvantage that the running kernel > > is bigger by more than 10%. > > > > If you don't believe me, try it yourself: > > Build all drivers statically into your kernel, and then compare the > > vmlinux sizes with CONFIG_MODULES=n and CONFIG_MODULES=y. > > If you'd aim for a small kernel image, you would build anything as a module > that is not requred for booting. > > > > > After all, changing it to a bool will allow us to make the kernel image > > > > for nearly everyone smaller by a few hundred bytes... > > > > > > I can't see why optionally building it as a module would force us to make > > > the kernel bigger. It may be a little more ugly to support =m, but thats > > > it, > > > isn't it? > > > > On architectures like x86 where __exit code is freed at runtime > > af_unix_exit() makes your kernel image (but not the running kernel) > > bigger. > > > > With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the > > theoretical possibility of CONIG_UNIX=m waste a few hundred bytes > > of memory. > > #define m='m' > #if CONIG_UNIX=='m' > #define EXPORT_SYMBOL_AF_UNIX EXPORT_SYMBOL > #else > #define EXPORT_SYMBOL_AF_UNIX() > #endif > #undef m > > You could also use "#if defined(C_U) && (C_U == m)". Look at the number of exports in the kernel and the number of lines changed per months, and it becomes obvious that somwthing like that would not be maintainable. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ip[6]_tables.c: remove some inlines
On Monday 31 December 2007 17:00, Patrick McHardy wrote: > Denys Vlasenko wrote: > > ip[6]_tables.c seem to abuse inline. > > > > This patch removes inlines except those which are used > > by packet matching code and thus are performance-critical. > > > > Some people also consider the ruleset replacement path performance > critical, but overall I agree with your patch. I'm travelling currently > though so it will take a few days until I'll apply it. > > Do you have some numbers that show the actual difference these > changes make? Before: $ size */*/*/ip*tables*.o textdata bss dec hex filename 6402 500 1669181b06 net/ipv4/netfilter/ip_tables.o 7130 500 1676461dde net/ipv6/netfilter/ip6_tables.o After: $ size */*/*/ip*tables*.o textdata bss dec hex filename 6307 500 1668231aa7 net/ipv4/netfilter/ip_tables.o 7010 500 1675261d66 net/ipv6/netfilter/ip6_tables.o -- vda -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
On Mon, Dec 31, 2007 at 04:34:55PM +0100, Jan Engelhardt wrote: > > > >If you'd aim for a small kernel image, you would build anything as a module > >that is not requred for booting. > > > Yes, there is a tradeoff for both. > > Example: > 16:30 ichi:../net/802 > l fc.o fc.ko > -rw-r--r-- 1 jengelh users 7961 Dec 27 15:19 fc.ko > -rw-r--r-- 1 jengelh users 2453 Dec 28 23:58 fc.o > (from a recent not-so-complete patch turning CONFIG_FC etc. into =m) > > If fc was modular, it might save the 2453 bytes off the core kernel image, > but adds ~5508 bytes to disk. > So one has to pick =y or =m depending on whatever suits his/her situation. May I ask something that might be obvious for most of the development community: Modules have to be loaded in seperate pages, right ? Does that mean that each module wastes partially used pages of memory at runtime ? I've always tried to build as much into the kernel image as possible, because all of my systems have only 512M memory. Thanks, Patrick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Force UNIX domain sockets to be built in
On Mon, Dec 31, 2007 at 04:19:23PM +0100, Bodo Eggert wrote: > On Mon, 31 Dec 2007, Adrian Bunk wrote: > > On Mon, Dec 31, 2007 at 02:26:42PM +0100, Bodo Eggert wrote: > > > On Mon, 31 Dec 2007, Adrian Bunk wrote: > > > > On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote: > > > > > > As suggested by Adrian Bunk, UNIX domain sockets should always be > > > > > built in > > > > > on normal systems. This is especially true since udev needs these > > > > > sockets > > > > > and fails to run if UNIX=m. > > > > > > > > > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > > > > > > > > > --- > > > > > Last minute change: I decided against making it a bool because > > > > > embedded > > > > > folks might depend on a small kernel image. Edited in the patch below. > > > > >... > > > > > > > > Is this just a purely theoretical thought or is this a reasonable use > > > > case people actually use in practice? > > > > > > For now, it's a theoretical thought, but having an embedded device, I can > > > see the reason for $EVERYTHING=m there. > > > > The only advantage I see is that the kernel image you have to flash > > can be made smaller - with the disadvantage that the running kernel > > is bigger by more than 10%. > > > > If you don't believe me, try it yourself: > > Build all drivers statically into your kernel, and then compare the > > vmlinux sizes with CONFIG_MODULES=n and CONFIG_MODULES=y. > > If you'd aim for a small kernel image, you would build anything as a module > that is not requred for booting. >... Small kernel image to flash (e.g. due to a size limit there), if you would aim for a small running kernel you wouldn't use modules. And I'm not so sure about the image size without seeing actual numbers, e.g. for your device. Especially comparing your all-modular approach with a CONFIG_MODULES=n kernel using Denys' section garbage collection patches in both cases would be interesting. I'm not claiming you are wrong, all I say is that I'm not convinced without actual numbers that you are right. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] driver core: build with SYSFS=n
From: Randy Dunlap <[EMAIL PROTECTED]> When SYSFS=n and MODULES=y, build ends with: linux-2.6.24-rc6-mm1/drivers/base/module.c: In function 'module_add_driver': linux-2.6.24-rc6-mm1/drivers/base/module.c:49: error: 'module_kset' undeclared (first use in this function) make[3]: *** [drivers/base/module.o] Error 1 Below is one possible fix. Build-tested with all 4 config combinations of SYSFS & MODULES. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- drivers/base/Makefile |2 ++ drivers/base/base.h |2 +- 2 files changed, 3 insertions(+), 1 deletion(-) --- linux-2.6.24-rc6-mm1.orig/drivers/base/Makefile +++ linux-2.6.24-rc6-mm1/drivers/base/Makefile @@ -11,7 +11,9 @@ obj-$(CONFIG_FW_LOADER) += firmware_clas obj-$(CONFIG_NUMA) += node.o obj-$(CONFIG_MEMORY_HOTPLUG_SPARSE) += memory.o obj-$(CONFIG_SMP) += topology.o +ifeq ($(CONFIG_SYSFS),y) obj-$(CONFIG_MODULES) += module.o +endif obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o ifeq ($(CONFIG_DEBUG_DRIVER),y) --- linux-2.6.24-rc6-mm1.orig/drivers/base/base.h +++ linux-2.6.24-rc6-mm1/drivers/base/base.h @@ -79,7 +79,7 @@ extern char *make_class_name(const char extern int devres_release_all(struct device *dev); -#ifdef CONFIG_MODULES +#if defined(CONFIG_MODULES) && defined(CONFIG_SYSFS) extern void module_add_driver(struct module *mod, struct device_driver *drv); extern void module_remove_driver(struct device_driver *drv); #else -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] sysfs: make SYSFS_DEPRECATED depend on SYSFS
From: Randy Dunlap <[EMAIL PROTECTED]> Make SYSFS_DEPRECATED depend on SYSFS since files that check CONFIG_SYSFS_DEPRECATED don't check for CONFIG_SYSFS first. Also don't prompt user about SYSFS_DEPRECATED if SYSFS=n. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- init/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-2.6.24-rc6-mm1.orig/init/Kconfig +++ linux-2.6.24-rc6-mm1/init/Kconfig @@ -349,6 +349,7 @@ config RESOURCE_COUNTERS config SYSFS_DEPRECATED bool "Create deprecated sysfs files" + depends on SYSFS default y help This option creates deprecated symlinks such as the -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] crypto: scatterwalk.h needs sched.h
From: Randy Dunlap <[EMAIL PROTECTED]>
When CONFIG_PREEMPT_NONE=y, scatterwalk.h still uses cond_resched()
so it needs to include sched.h:
linux-2.6.24-rc6-mm1/include/crypto/scatterwalk.h:52: error: implicit
declaration of function 'cond_resched'
make[2]: *** [crypto/digest.o] Error 1
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
include/crypto/scatterwalk.h |1 +
1 file changed, 1 insertion(+)
--- linux-2.6.24-rc6-mm1.orig/include/crypto/scatterwalk.h
+++ linux-2.6.24-rc6-mm1/include/crypto/scatterwalk.h
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
static inline enum km_type crypto_kmap_type(int out)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] qgit-2.1 and qgit-1.5.8
On Dec 31, 2007 6:47 PM, Boaz Harrosh <[EMAIL PROTECTED]> wrote: > On Mon, Dec 31 2007 at 13:58 +0200, "Marco Costalba" <[EMAIL PROTECTED]> > wrote: > > On Dec 31, 2007 11:59 AM, Filippo Zangheri <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> I git-cloned qgit-2.1 from your repository, then ran `qmake qgit.pro`, but > >> `make` gave me errors. > > > > Yes, you need qmake of Qt4 not the Qt3 one. > > > > > A Theoretical question. > Is it possible to compile Qt4 app all statically linked and run it on a Qt3 > based KDE > machine. Some thing like the windows installation, where every thing is > self-contained? > It's also very practical...I have _only_ KDE 3 installed, not KDE 4 ;-) I have both Qt4 and Qt3 development (shared) libraries installed and there is absolutely no compatibility problem, the only thing you have to remember is when running qmake qgit.pro the first time, you need to be sure is the Qt4 qmake, not the Qt3. Because I have Qt3 qmake in path, not the Qt4 one, I need to explicitly give the whole path the first time I configure the sources, something like /usr/lib/qt4/bin/qmake qgit.pro Then no other settings are needed, when you call make, the Makefiles are already built by qmake to search for the correct libraries. Hope this helps... Marco -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: asm-x86/msr.h for sanitized headers: clean it or punt it
On Monday 31 December 2007, Andi Kleen wrote:
> > can you enumerate which functions need to actually go to userspace then ?
> > the
>
> rdtscl/rdtscll/rdpmc primarily
i'll just mark out the useless C funcs then
> > __KERNEL__ markings are a crapshoot at the moment. you must also be
> > jumping through hoops in order to use the header in the first place since
> > the vanilla one wont compile out of the box.
>
> At least the 64bit one or older 32bit one works without hoops. Agreed that
> the paravirt changes destroyed it on newer 32bit though. That's an
> unfortunate regression.
i dont see how when the exported code has prototypes with "u32" types in them.
but at any rate ...
---
Use __asm__ and __volatile__ in code that is exported to userspace. Wrap
kernel functions with __KERNEL__ so they get scrubbed.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-x86/msr.h b/include/asm-x86/msr.h
index ba4b314..ffb9319 100644
--- a/include/asm-x86/msr.h
+++ b/include/asm-x86/msr.h
@@ -193,7 +193,7 @@ static inline int wrmsr_safe_on_cpu(unsigned int cpu, u32
msr_no, u32 l, u32 h)
/* wrmsr with exception handling */
#define wrmsr_safe(msr,a,b) ({ int ret__; \
- asm volatile("2: wrmsr ; xorl %0,%0\n" \
+ __asm__ __volatile__("2: wrmsr ; xorl %0,%0\n" \
"1:\n\t" \
".section .fixup,\"ax\"\n\t" \
"3: movl %4,%0 ; jmp 1b\n\t" \
@@ -210,7 +210,7 @@ static inline int wrmsr_safe_on_cpu(unsigned int cpu, u32
msr_no, u32 l, u32 h)
#define rdmsr_safe(msr,a,b) \
({ int ret__; \
- asm volatile ("1: rdmsr\n" \
+ __asm__ __volatile__ ("1: rdmsr\n" \
"2:\n" \
".section .fixup,\"ax\"\n" \
"3: movl %4,%0\n" \
@@ -230,17 +230,17 @@ static inline int wrmsr_safe_on_cpu(unsigned int cpu, u32
msr_no, u32 l, u32 h)
__asm__ __volatile__ ("rdtsc" : "=a" (low) : : "edx")
#define rdtscp(low,high,aux) \
- asm volatile (".byte 0x0f,0x01,0xf9" : "=a" (low), "=d" (high), "=c"
(aux))
+ __asm__ __volatile__ (".byte 0x0f,0x01,0xf9" : "=a" (low), "=d" (high),
"=c" (aux))
#define rdtscll(val) do { \
unsigned int __a,__d; \
- asm volatile("rdtsc" : "=a" (__a), "=d" (__d)); \
+ __asm__ __volatile__("rdtsc" : "=a" (__a), "=d" (__d)); \
(val) = ((unsigned long)__a) | (((unsigned long)__d)<<32); \
} while(0)
#define rdtscpll(val, aux) do { \
unsigned long __a, __d; \
- asm volatile (".byte 0x0f,0x01,0xf9" : "=a" (__a), "=d" (__d), "=c"
(aux)); \
+ __asm__ __volatile__ (".byte 0x0f,0x01,0xf9" : "=a" (__a), "=d" (__d),
"=c" (aux)); \
(val) = (__d << 32) | __a; \
} while (0)
@@ -320,6 +320,7 @@ static inline unsigned int cpuid_edx(unsigned int op)
return edx;
}
+#ifdef __KERNEL__
#ifdef CONFIG_SMP
void rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h);
void wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h);
@@ -343,6 +344,7 @@ static inline int wrmsr_safe_on_cpu(unsigned int cpu, u32
msr_no, u32 l, u32 h)
return wrmsr_safe(msr_no, l, h);
}
#endif /* CONFIG_SMP */
+#endif /* __KERNEL__ */
#endif /* __ASSEMBLY__ */
#endif /* !__i386__ */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
asm-x86/byteorder.h: clean up for userspace
Since asm-x86/byteorder.h is exported to userspace, use __asm__ rather than
asm in its code.
Signed-Off-By: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-x86/byteorder.h b/include/asm-x86/byteorder.h
index 1f2d6d5..fe2f2e5 100644
--- a/include/asm-x86/byteorder.h
+++ b/include/asm-x86/byteorder.h
@@ -30,13 +30,13 @@ static __inline__ __attribute_const__ __u64
___arch__swab64(__u64 val)
} v;
v.u = val;
#ifdef CONFIG_X86_BSWAP
- asm("bswapl %0 ; bswapl %1 ; xchgl %0,%1"
+ __asm__("bswapl %0 ; bswapl %1 ; xchgl %0,%1"
: "=r" (v.s.a), "=r" (v.s.b)
: "0" (v.s.a), "1" (v.s.b));
#else
v.s.a = ___arch__swab32(v.s.a);
v.s.b = ___arch__swab32(v.s.b);
- asm("xchgl %0,%1" : "=r" (v.s.a), "=r" (v.s.b) : "0" (v.s.a), "1"
(v.s.b));
+ __asm__("xchgl %0,%1" : "=r" (v.s.a), "=r" (v.s.b) : "0" (v.s.a), "1"
(v.s.b));
#endif
return v.u;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1 (build problem: gpio_keys)
CC drivers/input/keyboard/gpio_keys.o In file included from /local/linsrc/linux-2.6.24-rc6-mm1/drivers/input/keyboard/gpio_keys.c:27: include2/asm/gpio.h:4:18: error: gpio.h: No such file or directory /local/linsrc/linux-2.6.24-rc6-mm1/drivers/input/keyboard/gpio_keys.c: In function 'gpio_keys_isr': /local/linsrc/linux-2.6.24-rc6-mm1/drivers/input/keyboard/gpio_keys.c:40: error: implicit declaration of function 'gpio_to_irq' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/input/keyboard/gpio_keys.c:42: error: implicit declaration of function 'gpio_get_value' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/input/keyboard/gpio_keys.c: In function 'gpio_keys_probe': /local/linsrc/linux-2.6.24-rc6-mm1/drivers/input/keyboard/gpio_keys.c:81: error: implicit declaration of function 'gpio_request' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/input/keyboard/gpio_keys.c:88: error: implicit declaration of function 'gpio_direction_input' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/input/keyboard/gpio_keys.c:93: error: implicit declaration of function 'gpio_free' make[4]: *** [drivers/input/keyboard/gpio_keys.o] Error 1 CC drivers/leds/leds-gpio.o In file included from /local/linsrc/linux-2.6.24-rc6-mm1/drivers/leds/leds-gpio.c:18: include2/asm/gpio.h:4:18: error: gpio.h: No such file or directory /local/linsrc/linux-2.6.24-rc6-mm1/drivers/leds/leds-gpio.c: In function 'gpio_led_work': /local/linsrc/linux-2.6.24-rc6-mm1/drivers/leds/leds-gpio.c:34: error: implicit declaration of function 'gpio_set_value_cansleep' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/leds/leds-gpio.c: In function 'gpio_led_set': /local/linsrc/linux-2.6.24-rc6-mm1/drivers/leds/leds-gpio.c:60: error: implicit declaration of function 'gpio_set_value' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/leds/leds-gpio.c: In function 'gpio_led_probe': /local/linsrc/linux-2.6.24-rc6-mm1/drivers/leds/leds-gpio.c:85: error: implicit declaration of function 'gpio_cansleep' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/leds/leds-gpio.c:90: error: implicit declaration of function 'gpio_request' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/leds/leds-gpio.c:94: error: implicit declaration of function 'gpio_direction_output' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/leds/leds-gpio.c:100: error: implicit declaration of function 'gpio_free' make[3]: *** [drivers/leds/leds-gpio.o] Error 1 --- ~Randy desserts: http://www.xenotime.net/linux/recipes/ config-gpio-keys Description: Binary data
Re: 2.6.24-rc6-mm1 (build problem: gpio/W1)
CC drivers/w1/masters/w1-gpio.o In file included from /local/linsrc/linux-2.6.24-rc6-mm1/drivers/w1/masters/w1-gpio.c:19: include2/asm/gpio.h:4:18: error: gpio.h: No such file or directory /local/linsrc/linux-2.6.24-rc6-mm1/drivers/w1/masters/w1-gpio.c: In function 'w1_gpio_write_bit_dir': /local/linsrc/linux-2.6.24-rc6-mm1/drivers/w1/masters/w1-gpio.c:26: error: implicit declaration of function 'gpio_direction_input' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/w1/masters/w1-gpio.c:28: error: implicit declaration of function 'gpio_direction_output' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/w1/masters/w1-gpio.c: In function 'w1_gpio_write_bit_val': /local/linsrc/linux-2.6.24-rc6-mm1/drivers/w1/masters/w1-gpio.c:35: error: implicit declaration of function 'gpio_set_value' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/w1/masters/w1-gpio.c: In function 'w1_gpio_read_bit': /local/linsrc/linux-2.6.24-rc6-mm1/drivers/w1/masters/w1-gpio.c:42: error: implicit declaration of function 'gpio_get_value' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/w1/masters/w1-gpio.c: In function 'w1_gpio_probe': /local/linsrc/linux-2.6.24-rc6-mm1/drivers/w1/masters/w1-gpio.c:58: error: implicit declaration of function 'gpio_request' /local/linsrc/linux-2.6.24-rc6-mm1/drivers/w1/masters/w1-gpio.c:82: error: implicit declaration of function 'gpio_free' make[4]: *** [drivers/w1/masters/w1-gpio.o] Error 1 --- ~Randy desserts: http://www.xenotime.net/linux/recipes/ config-w1-gpio Description: Binary data
Re: 2.6.24-rc6-mm1 (build problem: v4l / i2c)
MODPOST 120 modules ERROR: "i2c_attach_client" [drivers/media/video/v4l2-common.ko] undefined! make[2]: *** [__modpost] Error 1 --- ~Randy desserts: http://www.xenotime.net/linux/recipes/ config-v4l-i2c Description: Binary data
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
Alan Cox wrote: On Sun, 30 Dec 2007 16:23:20 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: continuing to investigate for a cause. It would be nice if it were a BIOS-fixable problem. It would be even nicer if the BIOS were GPL... If it was an SMM trap, I would expect it to be trapped in the SuperIO chip. Many SuperIO chips do port 0x80, but they do it over the LPC and they do it in hardware to the parallel port data lines. The timings posted for 0x80 on his box are really a bit fast for LPC. Ah, that would eliminate the SuperIO chip. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] sh: sh7712 clock support
Hello,
Yes you are correct. Here is an updated patch. Happy New Year.
---
From: Andrew Murray <[EMAIL PROTECTED]>
This patch provides specific clock support for the SH7712. (This is my first
ever patch, so apologies if I've not followed the procedure correctly!)
Signed-off-by: Andrew Murray <[EMAIL PROTECTED]>
---
diff -uprN -x sh-2.6/Documentation/dontdiff
sh-2.6/arch/sh/kernel/cpu/sh3/clock-sh7712.c
sh-2.6-devel/arch/sh/kernel/cpu/sh3/clock-sh7712.c
--- sh-2.6/arch/sh/kernel/cpu/sh3/clock-sh7712.c1970-01-01
01:00:00.0 +0100
+++ sh-2.6-devel/arch/sh/kernel/cpu/sh3/clock-sh7712.c 2007-12-31
15:04:51.0 +
@@ -0,0 +1,71 @@
+/*
+ * arch/sh/kernel/cpu/sh3/clock-sh7712.c
+ *
+ * SH7712 support for the clock framework
+ *
+ * Copyright (C) 2007 Andrew Murray <[EMAIL PROTECTED]>
+ *
+ * Based on arch/sh/kernel/cpu/sh3/clock-sh3.c
+ * Copyright (C) 2005 Paul Mundt
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+
+static int multipliers[] = { 1, 2, 3 };
+static int divisors[]= { 1, 2, 3, 4, 6 };
+
+static void master_clk_init(struct clk *clk)
+{
+ int frqcr = ctrl_inw(FRQCR);
+ int idx = (frqcr & 0x0300) >> 8;
+
+ clk->rate *= multipliers[idx];
+}
+
+static struct clk_ops sh7712_master_clk_ops = {
+ .init = master_clk_init,
+};
+
+static void module_clk_recalc(struct clk *clk)
+{
+ int frqcr = ctrl_inw(FRQCR);
+ int idx = frqcr & 0x0007;
+
+ clk->rate = clk->parent->rate / divisors[idx];
+}
+
+static struct clk_ops sh7712_module_clk_ops = {
+ .recalc = module_clk_recalc,
+};
+
+static void cpu_clk_recalc(struct clk *clk)
+{
+ int frqcr = ctrl_inw(FRQCR);
+ int idx = (frqcr & 0x0030) >> 4;
+
+ clk->rate = clk->parent->rate / divisors[idx];
+}
+
+static struct clk_ops sh7712_cpu_clk_ops = {
+ .recalc = cpu_clk_recalc,
+};
+
+static struct clk_ops *sh7712_clk_ops[] = {
+ &sh7712_master_clk_ops,
+ &sh7712_module_clk_ops,
+ &sh7712_cpu_clk_ops,
+};
+
+void __init arch_init_clk_ops(struct clk_ops **ops, int idx)
+{
+ if (idx < ARRAY_SIZE(sh7712_clk_ops))
+ *ops = sh7712_clk_ops[idx];
+}
+
diff -uprN -x sh-2.6/Documentation/dontdiff
sh-2.6/arch/sh/kernel/cpu/sh3/Makefile
sh-2.6-devel/arch/sh/kernel/cpu/sh3/Makefile
--- sh-2.6/arch/sh/kernel/cpu/sh3/Makefile 2007-12-31 14:47:32.0
+
+++ sh-2.6-devel/arch/sh/kernel/cpu/sh3/Makefile2007-12-31
15:01:15.0 +
@@ -22,5 +22,6 @@ clock-$(CONFIG_CPU_SUBTYPE_SH7706):= cl
clock-$(CONFIG_CPU_SUBTYPE_SH7709) := clock-sh7709.o
clock-$(CONFIG_CPU_SUBTYPE_SH7710) := clock-sh7710.o
clock-$(CONFIG_CPU_SUBTYPE_SH7720) := clock-sh7710.o
+clock-$(CONFIG_CPU_SUBTYPE_SH7712) := clock-sh7712.o
obj-y += $(clock-y)
diff -uprN -x sh-2.6/Documentation/dontdiff
sh-2.6/include/asm-sh/cpu-sh3/freq.h sh-2.6-devel/include/asm-sh/cpu-sh3/freq.h
--- sh-2.6/include/asm-sh/cpu-sh3/freq.h2007-12-31 14:47:47.0
+
+++ sh-2.6-devel/include/asm-sh/cpu-sh3/freq.h 2007-12-31 15:02:30.0
+
@@ -10,7 +10,12 @@
#ifndef __ASM_CPU_SH3_FREQ_H
#define __ASM_CPU_SH3_FREQ_H
+#ifdef CONFIG_CPU_SUBTYPE_SH7712
+#define FRQCR 0xA415FF80
+#else
#define FRQCR 0xff80
+#endif
+
#define MIN_DIVISOR_NR 0
#define MAX_DIVISOR_NR 4
-Original Message-
From: Paul Mundt [mailto:[EMAIL PROTECTED]
Sent: 31 December 2007 16:50
To: Andrew Murray
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sh: sh7712 clock support
On Mon, Dec 31, 2007 at 04:32:25PM -, Andrew Murray wrote:
> +static void bus_clk_init(struct clk *clk)
> +{
> + clk->rate = CONFIG_SH_PCLK_FREQ;
> +}
> +
> +static struct clk_ops sh7712_bus_clk_ops = {
> + .init = bus_clk_init,
> +};
> +
This shouldn't be necessary, the bus clk already references the master
clk as its parent, and inherits the rate from there. If you have no
recalc work to do, then you should be able to just leave this out
altogether. If you actually need this dummy init, then something is
broken with the upper layer, which we should fix ;-)
Patch looks fine otherwise. Tidy this up and I'll apply it.
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.8 - Release Date: 24/12/2007 00:00
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.8 - Release Date: 24/12/2007 00:00
sh7712clocksupportpatch2
Description: sh7712clocksupportpatch2
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
Alan Cox wrote: "You plug in PCI DEBUG card and it overclocks your machine" is bad scenario.. (I don't know if it does... can PCI card emulate ISA timings?) Easily. Its a bit more restricted by later spec revisions but it can halt your box of a week or two if it wants. Video cards used to pull this stunt for marketing benchmark numbers. The drivers, specifically (the old "don't check if the command FIFO is full before writing, just write anyway and if it's full let the whole PCI bus stall while the FIFO empties out" trick). I rather doubt any of those PCI POST debug cards would bother to accurately emulate the ISA timings of normal port 0x80 accesses, however. Most likely if you plug those in, port 0x80 accesses suddenly become lots faster now that the writes are completing on the PCI bus before ever hitting ISA/LPC.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Bad escriptions in Kconfig
On Mon, 31 Dec 2007, Douglas Gilbert wrote: > Matthew Wilcox wrote: > > On Mon, Dec 31, 2007 at 10:16:43AM -0500, Douglas Gilbert wrote: > >> Bodo Eggert wrote: (Kicking netdev from CC) > >>> --- > >>> SCSI target support (SCSI_TGT) [N/m/y/?] (NEW) ? > >>> > >>> If you want to use SCSI target mode drivers enable this option. > >>> If you choose M, the module will be called scsi_tgt. > >>> --- > >>> > >>> What TF is a SCSI target mode, what is a target mode driver? > >> Heard of google :-) > >> > >> For explanations of SCSI (and other storage) terminology > >> reference could be made to SAM-3 or SAM-4 drafts (because > >> the real standards cost money) at www.t10.org . > >> > >> Perhaps many other subsections in the kernel could have > >> similar references. > > > > I think that's an appalling idea. Someone's trying to configure their > > kernel, not research hundreds of new ideas on the internet. Here's a > > better description: > > > > help > > The SCSI target code allows your computer to appear as a SCSI > > device. This is useful in a SAN or NAS environment where you > > want other computers to be able to treat this computer as a disc. > > > > To compile this driver as a module, choose M here: the module > > will be called scsi_tgt. > > Appalling or not, it is more accurate to define a SCSI target > properly than equate it to a direct access logical unit (i.e. > a disk). Yes, but calling the current text a "help text" would be even less accurate. Can you create a helpfull text without being incorrect? -- Field experience is something you don't get until just after you need it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Force UNIX domain sockets to be built in
On Dec 31, 2007 6:18 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > On Monday 31 December 2007 17:38:03 Alan Cox wrote: > > On Mon, 31 Dec 2007 17:17:19 +0100 > > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote: > > > > > a) this could be disabled during development if you want this > > > b) this would even only affect development if you add new code that > > > now needs a EXPORT_SYMBOL that was removed on an earlier build. And > > > right now this would also need to trigger a rerun of depmod. And the > > > same trigger could redo this garbage collect. > > > > > > Or am I missing something obvious? > > > > Development is not a phase seperate from use or distribution. A lot of > > module testers for distributions will not be compiling their own modules > > but loading in ones to test provided by their vendor - which may of > > course then need different ksyms I understand that point. I just always assumed that kernel tests meant 'please test this patch' and doing the compile yourself. But I'm not convinced be the following: > As an example, the whole purpose wireless-compat package is > to load latest bleeding edge wireless stuff into a distribution kernel. > So people are not required to recompile their kernels for using > drivers that support their hardware. > And guess what, it is used a _lot_. And lots of bugs are found with it. > It increases our testing community a lot. This looks more like a "regular" out-of-tree module for the purpose of the suggested symbol garbage collector. And for that case I already a 'don't use it then'-note. The base problem is that there already are many options to break external modules. (CONFIG_MODULES=n ;) ) Or in the case of this wireless module: CONFIG_CRYPTO_ARC4=n (Without 'arc4' ieee80211_wep_init() will fail, that will fail ieee80211_register_hw() and so no mac80211 driver could be loaded) > So, all this wouldn't work, if kernel symbols could randomly get > nuked by some "garbage collector". > > In practice, no distribution would use symbol garbage collection, as the > only benefit from it would be an increased level of bugreports. The question I can't answer in this context is: Do distributions want to support external modules? Only if yes, your argument is valid. But then they could just disable this feature and prevent this kind of bugreports. Torsten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Warn about attempts to register/unregister devices during system suspend
This patch (as1030) prints warning messages in the system log when
drivers try to register or unregister devices during a system sleep
transition. These actions are now illegal and will either fail or
block (likely leading to deadlock).
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
This patch applies on top of
gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch. The
new locking arrangement can cause deadlocks or other errors if drivers
try to do the wrong thing. With this patch we should easily be able to
tell where the problems are.
Alan Stern
Index: usb-2.6/drivers/base/core.c
===
--- usb-2.6.orig/drivers/base/core.c
+++ usb-2.6/drivers/base/core.c
@@ -789,8 +789,11 @@ int device_add(struct device *dev)
int error;
error = pm_sleep_lock();
- if (error)
+ if (error) {
+ dev_warn(dev, "Illegal %s during suspend\n", __FUNCTION__);
+ dump_stack();
return error;
+ }
dev = get_device(dev);
if (!dev || !strlen(dev->bus_id)) {
@@ -953,6 +956,13 @@ void device_del(struct device * dev)
struct device * parent = dev->parent;
struct class_interface *class_intf;
+ if (pm_sleep_lock()) {
+ dev_warn(dev, "Illegal %s during suspend\n", __FUNCTION__);
+ dump_stack();
+ } else {
+ pm_sleep_unlock();
+ }
+
if (parent)
klist_del(&dev->knode_parent);
if (MAJOR(dev->devt))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1 (build problem: gpio_keys)
On Monday 31 December 2007, Randy Dunlap wrote: > CC drivers/input/keyboard/gpio_keys.o > In file included from > /local/linsrc/linux-2.6.24-rc6-mm1/drivers/input/keyboard/gpio_keys.c:27: > include2/asm/gpio.h:4:18: error: gpio.h: No such file or directory Find whatever broken patch selected (on x86_64) CONFIG_GENERIC_GPIO=y without actually providing that support (by providing and an implementation backing it up). That's the patch which broke those various GPIO-dependant drivers. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
