Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Monday 16 April 2007, Con Kolivas wrote: And I snipped, Sorry fellas. Con's original submission was to me, quite an improvement. But I have to say it, and no denegration of your efforts is intended Con, but you did 'pull the trigger' and get this thing rolling by scratching the itch & drawing attention to an ugly lack of user interactivity that had crept into the 2.6 family. So from me to Con, a tip of the hat, and a deep bow in your direction, thank you. Now, you have done what you aimed to do, so please get well. I've now been through most of an amanda session using Ingo's "CFS" and I have to say that it is another improvement over your 0.40 that's is just as obvious as your first patch was against the stock scheduler. No other scheduler yet has allowed the full utilization of the cpu, and maintained user interactivity as well as this one has, my cpu is running about 5 degrees F hotter just from this effect alone. gzip, if the rest of the system is in between tasks, is consistently showing around 95%, but let anything else stick up its hand, like procmail etc, and gzip now dutifully steps aside, dropping into the 40% range until procmail and spamd are done, at which point there is no rest for the wicked and the cpu never gets a chance to cool. There was, just now, a pause of about 2 seconds, while amanda moved a tarball from the holding disk area on /dev/hda to the vtapes disk on /dev/hdd, so that would have been an I/O bound situation. This one Ingo, even without any other patches and I think I did see one go by in this thread which I didn't apply, is a definite keeper. Sweet even. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) A word to the wise is enough. -- Miguel de Cervantes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.6.21-rc7 hpt366 driver broken
Hello, I am testing the 2.6.21-rc7 kernel release. The IDE hpt366 driver is crashing hanging the boot. I have basically the same config as 2.6.20.7 which works fine (except for netconsole mentioned in a previous mail). here is the hand-copied info: * "unable to handle paging request" , null deref * EIP @ init_chipset_hpt366 init_setup_hpt302 htp366_init_one ide_scan_pcidev ide_scan_pcibus ide_init init some hardware info: /usr/sbin/lspci -v | grep -i HPT -A 9 [EMAIL PROTECTED] 00:09.0 RAID bus controller: Triones Technologies, Inc. HPT302/302N (rev 02) Subsystem: Triones Technologies, Inc. Unknown device 0001 Flags: bus master, 66MHz, medium devsel, latency 120, IRQ 18 I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=8] I/O ports at e000 [size=4] I/O ports at dc00 [size=256] Expansion ROM at dffe [disabled by cmd] [size=128K] Capabilities: I cannot get more information since netconsole is broken. I am running a git-bisect to see if I can resolve it to a commit. Cheers, Mike Mattie signature.asc Description: PGP signature
Re: If not readdir() then what?
On Sunday April 15, [EMAIL PROTECTED] wrote: > On Thu, Apr 12, 2007 at 10:35:49AM -0700, H. Peter Anvin wrote: > > > > Any fixed size is too small. It should be a dynamic size. > > Idally it should be dynamic, but my guess is that if the cookie were a > fixed 256 bits, it would be sufficient for pretty much all filesystems. > "my guess", "pretty much" really bother me. It sounds like "The largest anyone has asked for is 128bits, or let's double it and hope that is enough until the next protocol revision". Which was probably reasonable when NFSv2 was being developed and maybe even when v3 was developed, but I kind of hoped we were beyond that. If a filesystem wanted to order filenames lexically, it really needs 256 *bytes*. And it is fairly silly having a cookie that big. I still thinking that filename + 64bits is required and plenty (aka necessary and sufficient). You would need a truly enormous directory before that would be insufficient for an off-set based scheme or a hash-plus-collision scheme, and it is clearly enough for a lexically-ordered scheme. I wouldn't argue against 128bits (64 for a search key and 64 to guarantee uniqueness) but I really think 256 excessive with no value. We we still need the last-filename in the READDIR key. (Mind you, I'm still wondering why NFSv4 felt the need for 128 *byte* file handles so maybe I'm just small minded :-) NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Mon, 16 Apr 2007, Pavel Pisa wrote: > I cannot help myself to not report results with GAVL > tree algorithm there as an another race competitor. > I believe, that it is better solution for large priority > queues than RB-tree and even heap trees. It could be > disputable if the scheduler needs such scalability on > the other hand. The AVL heritage guarantees lower height > which results in shorter search times which could > be profitable for other uses in kernel. > > GAVL algorithm is AVL tree based, so it does not suffer from > "infinite" priorities granularity there as TR does. It allows > use for generalized case where tree is not fully balanced. > This allows to cut the first item withour rebalancing. > This leads to the degradation of the tree by one more level > (than non degraded AVL gives) in maximum, which is still > considerably better than RB-trees maximum. > > http://cmp.felk.cvut.cz/~pisa/linux/smart-queue-v-gavl.c Here are the results on my Opteron 252: Testing N=1 gavl_cfs = 187.20 cycles/loop CFS = 194.16 cycles/loop TR = 314.87 cycles/loop CFS = 194.15 cycles/loop gavl_cfs = 187.15 cycles/loop Testing N=2 gavl_cfs = 268.94 cycles/loop CFS = 305.53 cycles/loop TR = 313.78 cycles/loop CFS = 289.58 cycles/loop gavl_cfs = 266.02 cycles/loop Testing N=4 gavl_cfs = 452.13 cycles/loop CFS = 518.81 cycles/loop TR = 311.54 cycles/loop CFS = 516.23 cycles/loop gavl_cfs = 450.73 cycles/loop Testing N=8 gavl_cfs = 609.29 cycles/loop CFS = 644.65 cycles/loop TR = 308.11 cycles/loop CFS = 667.01 cycles/loop gavl_cfs = 592.89 cycles/loop Testing N=16 gavl_cfs = 686.30 cycles/loop CFS = 807.41 cycles/loop TR = 317.20 cycles/loop CFS = 810.24 cycles/loop gavl_cfs = 688.42 cycles/loop Testing N=32 gavl_cfs = 756.57 cycles/loop CFS = 852.14 cycles/loop TR = 301.22 cycles/loop CFS = 876.12 cycles/loop gavl_cfs = 758.46 cycles/loop Testing N=64 gavl_cfs = 831.97 cycles/loop CFS = 997.16 cycles/loop TR = 304.74 cycles/loop CFS = 1003.26 cycles/loop gavl_cfs = 832.83 cycles/loop Testing N=128 gavl_cfs = 897.33 cycles/loop CFS = 1030.36 cycles/loop TR = 295.65 cycles/loop CFS = 1035.29 cycles/loop gavl_cfs = 892.51 cycles/loop Testing N=256 gavl_cfs = 963.17 cycles/loop CFS = 1146.04 cycles/loop TR = 295.35 cycles/loop CFS = 1162.04 cycles/loop gavl_cfs = 966.31 cycles/loop Testing N=512 gavl_cfs = 1029.82 cycles/loop CFS = 1218.34 cycles/loop TR = 288.78 cycles/loop CFS = 1257.97 cycles/loop gavl_cfs = 1029.83 cycles/loop Testing N=1024 gavl_cfs = 1091.76 cycles/loop CFS = 1318.47 cycles/loop TR = 287.74 cycles/loop CFS = 1311.72 cycles/loop gavl_cfs = 1093.29 cycles/loop Testing N=2048 gavl_cfs = 1153.03 cycles/loop CFS = 1398.84 cycles/loop TR = 286.75 cycles/loop CFS = 1438.68 cycles/loop gavl_cfs = 1149.97 cycles/loop There seem to be some difference from your numbers. This is with: gcc version 4.1.2 and -O2. But then and Opteron can behave quite differentyl than a Duron on a bench like this ;) - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] netconsole hangs machine 2.6.20
Hello, netconsole is hanging my box during IDE init. I am running 2.6.20.7, config is attached from /proc Without using netconsole the kernel boots fine. I am writing this message from it. When I do enable net-console I get from the linux banner to a couple of lines after "sanitize end" on the logging client ( Mac OS X 10.4 , simple nc listener ) The boot continues until hde (handled by the HPT366 driver, hdg is the last drive ) and then the kernel just hangs. Also two previous mails to lkml have disappeared. Debugging is getting really hard when it is unbounded recursion :) Cheers, Mike Mattie config.gz Description: GNU Zip compressed data signature.asc Description: PGP signature
Re: BUG: Bad page state errors during kernel make
On Sun, Apr 15, 2007 at 10:31:38PM -0700, Zach Carter wrote: > > Dave Jones wrote: > > On Sun, Apr 15, 2007 at 08:30:27PM -0700, Zach Carter wrote: > > > list_del corruption. prev->next should be c21a4628, but was e21a4628 > > > > 'c' became 'e' in that last address. A single bit flipped. > > Given you've had this for some time, this smells like a hardware problem. > > memtest86+ will probably show up something. > > Hum. I forgot to mention in my report that I had already run thru 10 clean > passes with memtest86+ > > Do you think there might be other bad hw, or another explanation? Maybe. I've seen underpowered PSUs, bad motherboard capacitors, and even poor ventilation caused by clogged fans causing similar bugs. It could also actually be a software fault, but it's surprising that you hit it so easily, for so long, and no-one else seems to be equally as affected. 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: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Sun, Apr 15, 2007 at 09:25:07AM -0700, Arjan van de Ven wrote: > Now this doesn't mean that people shouldn't be nice to each other, not > cooperate or steal credits, but I don't get the impression that that is > happening here. Ingo is taking part in the discussion with a counter > proposal for discussion *on the mailing list*. What more do you want?? Con should have been CCed from the first moment this was put into motion to limit the perception of exclusion. That was mistake number one and big time failures to understand this dynamic. After it was Con's idea. Why the hell he was excluded from Ingo's development process is baffling to me and him (most likely). He put int a lot of effort into SDL and his experiences with scheduling should still be seriously considered in this development process even if he doesn't write a single line of code from this moment on. What should have happened is that our very busy associate at RH by the name of Ingo Molnar should have leverage more of Con's and Bill's work and use them as a proxy for his own ideas. They would have loved to have contributed more and our very busy Ingo Molnar would have gotten a lot of his work and ideas implemented without him even opening a single source file for editting. They would have happily done this work for Ingo. Ingo could have been used for something else more important like making KVM less of a freaking ugly hack and we all would have benefitted from this. He could have been working on SystemTap so that you stop losing accounts to Sun and Solaris 10's Dtrace. He could have been working with Riel to fix your butt ugly page scanning problem causing horrible contention via the Clock/Pro algorithm, etc... He could have been fixing the ugly futex rwsem mapping problem that's killing -rt and anything that uses Posix threads. He could have created a userspace thread control block (TCB) with Mr. Drepper so that we can turn off preemption in userspace (userspace per CPU local storage) and implement a very quick non-kernel crossing implementation of priority ceilings (userspace check for priority and flags at preempt_schedule() in the TCB) so that our -rt Posix API doesn't suck donkey shit... Need I say more ? As programmers like Ingo get spread more thinly, he needs super smart folks like Bill Irwin and Con to help him out and learn to resist NIH folk's stuff out of some weird fear. When this happens, folks like Ingo must learn to "facilitate" development in addition to implementing it with those kind of folks. This takes time and practice to entrust folks to do things for him. Ingo is the best method of getting new Linux kernel ideas and communicate them to Linus. His value goes beyond just just code and is often the biggest hammer we have in the Linux community to get stuff into the kernel. "Facilitation" of others is something that solo programmers must need when groups like the Linux kernel get larger and large every year. Understand ? Are we in embarrassing agreement here ? bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Bad page state errors during kernel make
Dave Jones wrote: On Sun, Apr 15, 2007 at 08:30:27PM -0700, Zach Carter wrote: > list_del corruption. prev->next should be c21a4628, but was e21a4628 'c' became 'e' in that last address. A single bit flipped. Given you've had this for some time, this smells like a hardware problem. memtest86+ will probably show up something. Hum. I forgot to mention in my report that I had already run thru 10 clean passes with memtest86+ Do you think there might be other bad hw, or another explanation? -Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: kernel 2.6.20.6 build failed for ppc board chestnut(ibm ppc 750GX/FX)
I'm using eldk4, there are no problems.
Wang, Baojun wrote:
PROBLEM: linux kernel 2.6.20.6 build failed for ppc board chestnut(ibm ppc
750GX/FX)
STEPS I followed:
1) make ARCH=ppc CROSS_COMPILE=ppc_4xx- chestnut_defconfig # toolchain from
eldk 4.1
2) make ARCH=ppc CROSS_COMPILE=ppc_4xx- V=1
...
make -f scripts/Makefile.build obj=arch/ppc/platforms
ppc_4xx-gcc -m32 -Wp,-MD,arch/ppc/platforms/.chestnut.o.d -nostdinc -isystem /opt/eldk/usr/bin/../lib/gcc/powerpc-linux/4.0.0/include -D__KERNEL__ -Iinclude -include
include/linux/autoconf.h -Iarch/ppc -Iarch/ppc/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -O2 -Iarch/ppc -msoft-float -pipe -ffixed-r2 -mmultiple -mno-altivec -mstring -Wa,-maltivec -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(chestnut)" -D"KBUILD_MODNAME=KBUILD_STR(chestnut)" -c -o
arch/ppc/platforms/chestnut.o arch/ppc/platforms/chestnut.c
arch/ppc/platforms/chestnut.c: In function 'chestnut_setup_mtd':
arch/ppc/platforms/chestnut.c:435: error: 'physmap_map' undeclared (first use
in this function)
arch/ppc/platforms/chestnut.c:435: error: (Each undeclared identifier is
reported only once
arch/ppc/platforms/chestnut.c:435: error: for each function it appears in.)
make[1]: *** [arch/ppc/platforms/chestnut.o] Error 1
make: *** [arch/ppc/platforms] Error 2
This PROBLEM should also affect these boards:
find -name '*.[chS]' -exec grep physmap_map {} \; -print
physmap_map.size = CHESTNUT_32BIT_SIZE;
./arch/ppc/platforms/chestnut.c
physmap_map.size = size;
./arch/ppc/platforms/ev64360.c
physmap_map.size = size;
./arch/ppc/platforms/katana.c
I've veryfied 2.6.15, 2.6.19.2 2.6.20.1 2.6.20.6
ONLY 2.6.15 can build successfully. sounds like the problem is caused by the
interface change of mtd.
this brute force patch sould solve the problem:
diff -Nru /tmp/linux-2.6.20.6/arch/ppc/platforms/chestnut.c \
linux-2.6.20.6/arch/ppc/platforms/chestnut.c
--- /tmp/linux-2.6.20.6/arch/ppc/platforms/chestnut.c 2007-04-07
04:02:48.0 +0800
+++ linux-2.6.20.6/arch/ppc/platforms/chestnut.c2007-04-13
17:09:03.0 +0800
@@ -432,7 +432,9 @@
ptbl.name = "User FS";
ptbl.size = CHESTNUT_32BIT_SIZE;
- physmap_map.size = CHESTNUT_32BIT_SIZE;
+ // physmap_map.size = CHESTNUT_32BIT_SIZE;
+ physmap_configure(CHESTNUT_32BIT_BASE, CHESTNUT_32BIT_SIZE,
CONFIG_MTD_PHYSMAP_BANKWIDTH, NULL);
+
physmap_set_partitions(, 1);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: kernel 2.6.20.6 build failed for ppc board chestnut(ibm ppc 750GX/FX)
PROBLEM: linux kernel 2.6.20.6 build failed for ppc board chestnut(ibm ppc
750GX/FX)
STEPS I followed:
1) make ARCH=ppc CROSS_COMPILE=ppc_4xx- chestnut_defconfig # toolchain from
eldk 4.1
2) make ARCH=ppc CROSS_COMPILE=ppc_4xx- V=1
...
make -f scripts/Makefile.build obj=arch/ppc/platforms
ppc_4xx-gcc -m32 -Wp,-MD,arch/ppc/platforms/.chestnut.o.d -nostdinc -isystem
/opt/eldk/usr/bin/../lib/gcc/powerpc-linux/4.0.0/include -D__KERNEL__ -Iinclude
-include
include/linux/autoconf.h -Iarch/ppc -Iarch/ppc/include -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -O2
-Iarch/ppc -msoft-float -pipe -ffixed-r2 -mmultiple -mno-altivec -mstring
-Wa,-maltivec -fomit-frame-pointer -Wdeclaration-after-statement
-Wno-pointer-sign-D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(chestnut)"
-D"KBUILD_MODNAME=KBUILD_STR(chestnut)" -c -o
arch/ppc/platforms/chestnut.o arch/ppc/platforms/chestnut.c
arch/ppc/platforms/chestnut.c: In function 'chestnut_setup_mtd':
arch/ppc/platforms/chestnut.c:435: error: 'physmap_map' undeclared (first use
in this function)
arch/ppc/platforms/chestnut.c:435: error: (Each undeclared identifier is
reported only once
arch/ppc/platforms/chestnut.c:435: error: for each function it appears in.)
make[1]: *** [arch/ppc/platforms/chestnut.o] Error 1
make: *** [arch/ppc/platforms] Error 2
This PROBLEM should also affect these boards:
find -name '*.[chS]' -exec grep physmap_map {} \; -print
physmap_map.size = CHESTNUT_32BIT_SIZE;
./arch/ppc/platforms/chestnut.c
physmap_map.size = size;
./arch/ppc/platforms/ev64360.c
physmap_map.size = size;
./arch/ppc/platforms/katana.c
I've veryfied 2.6.15, 2.6.19.2 2.6.20.1 2.6.20.6
ONLY 2.6.15 can build successfully. sounds like the problem is caused by the
interface change of mtd.
this brute force patch sould solve the problem:
diff -Nru /tmp/linux-2.6.20.6/arch/ppc/platforms/chestnut.c \
linux-2.6.20.6/arch/ppc/platforms/chestnut.c
--- /tmp/linux-2.6.20.6/arch/ppc/platforms/chestnut.c 2007-04-07
04:02:48.0 +0800
+++ linux-2.6.20.6/arch/ppc/platforms/chestnut.c2007-04-13
17:09:03.0 +0800
@@ -432,7 +432,9 @@
ptbl.name = "User FS";
ptbl.size = CHESTNUT_32BIT_SIZE;
- physmap_map.size = CHESTNUT_32BIT_SIZE;
+ // physmap_map.size = CHESTNUT_32BIT_SIZE;
+ physmap_configure(CHESTNUT_32BIT_BASE, CHESTNUT_32BIT_SIZE,
CONFIG_MTD_PHYSMAP_BANKWIDTH, NULL);
+
physmap_set_partitions(, 1);
return 0;
}
--
Wang, BaojunLanzhou University
Distributed & Embedded System Lab http://dslab.lzu.edu.cn
School of Information Science and Engeneering[EMAIL PROTECTED]
Tianshui South Road 222. Lanzhou 73 .P.R.China
Tel:+86-931-8912025Fax:+86-931-8912022
pgp8XeK8j0iAy.pgp
Description: PGP signature
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB updates
Michael Krufky wrote: > Mauro, > > I've been out of town for the past few days... I just got home and saw this: > > > Mauro Carvalho Chehab wrote: >>- Fix 1/3 for bug 7819: fixed frontend hotplug issue >>- Fix 2/3 for bug 7819: demux and dvr >>- Fix 3/3 for bug 7819: fixed hotplugging for dvbnet > I don't think that this is 2.6.21 material. These patches have not yet > received > enough testing to be sent to mainline. > > I have tested them, and they seem to work for my cxusb device, but we have > yet to hear test results from users of usb dvb devices that do not use the > dvb-usb framework. (ttusb, flexcop-usb, cinergyT2, for example) > > The bug that these patches fix has been around throughout the entire kernel > history of the dvb subsystem. The bug is not a regression -- it has > always been > there. In my opinion, it is too late in 2.6.21 development to apply > this change. > Because these fixes are not obvious, I think we should let them get some > more testing, and have them queued for 2.6.22 . I am not arguing about the veracity of the patches, but how things are handled. Agreed to all the mentioned above. There is one more aspect. The mentioned patches, do not have any ACK/SOB from any DVB developer/maintainer for the same. Huge regressions are created this way. One more time the regression creator is caught. Manu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Monday 16 April 2007 01:05, Ingo Molnar wrote: > * Con Kolivas <[EMAIL PROTECTED]> wrote: > > 2. Since then I've been thinking/working on a cpu scheduler design > > that takes away all the guesswork out of scheduling and gives very > > predictable, as fair as possible, cpu distribution and latency while > > preserving as solid interactivity as possible within those confines. > > yeah. I think you were right on target with this call. Yay thank goodness :) It's time to fix the damn cpu scheduler once and for all. Everyone uses this; it's no minor driver or $bigsmp or $bigram or $small_embedded_RT_hardware feature. > I've applied the > sched.c change attached at the bottom of this mail to the CFS patch, if > you dont mind. (or feel free to suggest some other text instead.) > * 2003-09-03 Interactivity tuning by Con Kolivas. > * 2004-04-02 Scheduler domains code by Nick Piggin > + * 2007-04-15 Con Kolivas was dead right: fairness matters! :) LOL that's awful. I'd prefer something meaningful like "Work begun on replacing all interactivity tuning with a fair virtual-deadline design by Con Kolivas". While you're at it, it's worth getting rid of a few slightly pointless name changes too. Don't rename SCHED_NORMAL yet again, and don't call all your things sched_fair blah_fair __blah_fair and so on. It means that anything else is by proxy going to be considered unfair. Leave SCHED_NORMAL as is, replace the use of the word _fair with _cfs. I don't really care how many copyright notices you put into our already noisy bootup but it's redundant since there is no choice; we all get the same cpu scheduler. > > 1. I tried in vain some time ago to push a working extensable > > pluggable cpu scheduler framework (based on wli's work) for the linux > > kernel. It was perma-vetoed by Linus and Ingo (and Nick also said he > > didn't like it) as being absolutely the wrong approach and that we > > should never do that. [...] > > i partially replied to that point to Will already, and i'd like to make > it clear again: yes, i rejected plugsched 2-3 years ago (which already > drifted away from wli's original codebase) and i would still reject it > today. No that was just me being flabbergasted by what appeared to be you posting your own plugsched. Note nowhere in the 40 iterations of rsdl->sd did I ask/suggest for plugsched. I said in my first announcement my aim was to create a scheduling policy robust enough for all situations rather than fantastic a lot of the time and awful sometimes. There are plenty of people ready to throw out arguments for plugsched now and I don't have the energy to continue that fight (I never did really). But my question still stands about this comment: > case, all of SD's logic could be added via a kernel/sched_sd.c module > as well, if Con is interested in such an approach. ] What exactly would be the purpose of such a module that governs nothing in particular? Since there'll be no pluggable scheduler by your admission it has no control over SCHED_NORMAL, and would require another scheduling policy for it to govern which there is no express way to use at the moment and people tend to just use the default without great effort. > First and foremost, please dont take such rejections too personally - i > had my own share of rejections (and in fact, as i mentioned it in a > previous mail, i had a fair number of complete project throwaways: > 4g:4g, in-kernel Tux, irqrate and many others). I know that they can > hurt and can demoralize, but if i dont like something it's my job to > tell that. Hmm? No that's not what this is about. Remember dynticks which was not originally my code but I tried to bring it up to mainline standard which I fought with for months? You came along with yet another rewrite from scratch and the flaws in the design I was working with were obvious so I instantly bowed down to that and never touched my code again. I didn't ask for credit back then, but obviously brought the requirement for a no idle tick implementation to the table. > My view about plugsched: first please take a look at the latest > plugsched code: > > http://downloads.sourceforge.net/cpuse/plugsched-6.5-for-2.6.20.patch > > 26 files changed, 8951 insertions(+), 1495 deletions(-) > > As an experiment i've removed all the add-on schedulers (both the core > and the include files, only kept the vanilla one) from the plugsched > patch (and the makefile and kconfig complications, etc), to see the > 'infrastructure cost', and it still gave: > > 12 files changed, 1933 insertions(+), 1479 deletions(-) I do not see extra code per-se as being a bad thing. I've heard said a few times before "ever notice how when the correct solution is done it is a lot more code than the quick hack that ultimately fails?". Insert long winded discussion of perfect is the enemy of good here, _but_ I'm not arguing perfect versus good, I'm talking about solid code
Re: [PATCH] sparc64: modalias support for of_device
From: Kyle McMartin <[EMAIL PROTECTED]> Date: Mon, 16 Apr 2007 00:19:33 -0400 > Quick patch to add modalias support for of_device to arch/sparc64 so > sbus drivers can be automatically loaded (I hope :) > > Untested, as I'm sparc-less at the moment. Thanks Kyle. How does this work? Does some program walk through sysfs scanning the attributes of devices, and this triggers module matching? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] pci-quirks: disable MSI on RS400-200 and RS480
MSI doesn't work on RS400-200 and RS480 requiring pci=nomsi kernel boot parameter for ahci to work. This patch disables MSI on those chips. http://thread.gmane.org/gmane.linux.ide/17820 http://thread.gmane.org/gmane.linux.ide/17516 https://bugzilla.novell.com/show_bug.cgi?id=263893 Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 65d6f23..3300ff1 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1761,6 +1761,8 @@ static void __devinit quirk_disable_msi(struct pci_dev *dev) } } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_BRIDGE, quirk_disable_msi); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_msi); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_msi); /* Go through the list of Hypertransport capabilities and * return 1 if a HT MSI capability is found and enabled */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Unable to mount root fs on unknown-block(1,0)
Sorry, the version of linux should be 2.6.15 for MPC8xx, which is included in ELDK. gshan wrote: Hi Folks, I got problem to boot linux 2.6.25 using u-boot-1.1.4, any ideas? - U-Boot 1.1.4 (Apr 14 2007 - 00:57:01) CPU: XPC850xxZTB at 50 MHz: 2 kB I-Cache 1 kB D-Cache Board: ### No HW ID - assuming TQM8xxL DRAM: 8 MB FLASH: 4 MB In:serial Out: serial Err: serial Net: SCC ETHERNET Hit any key to stop autoboot: 0 Using SCC ETHERNET device TFTP from server 90.0.0.1; our IP address is 90.0.0.2 Filename 'uImage'. Load address: 0x10 Loading: # # done Bytes transferred = 825541 (c98c5 hex) => printenv bootdelay=5 baudrate=9600 loads_echo=1 ethact=SCC ETHERNET netmask=0xff00 vlan=0x nvlan=0x clocks_in_mhz=1 bootcmd=tftp 0x10 uImage autostart=no filesize=c98c5 fileaddr=10 ipaddr=90.0.0.2 serverip=90.0.0.1 bootargs=root=/dev/ram rw stdin=serial stdout=serial stderr=serial Environment size: 293/16380 bytes => bdinfo memstart= 0x memsize = 0x0080 flashstart = 0x1000 flashsize = 0x0040 flashoffset = 0x00021000 sramstart = 0x sramsize= 0x0080 immr_base = 0xFFF0 bootflags = 0x0001 intfreq = 50 MHz busfreq = 50 MHz ethaddr = 00:00:00:00:00:00 IP addr = 90.0.0.2 baudrate= 9600 bps => tftp 0x20 aaa Using SCC ETHERNET device TFTP from server 90.0.0.1; our IP address is 90.0.0.2 Filename 'aaa'. Load address: 0x20 Loading: # done Bytes transferred = 776 (308 hex) => bootm 0x10 0x20 ## Booting image at 0010 ... Image Name: Linux-2.6.15 Created: 2007-04-15 16:56:44 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:825477 Bytes = 806.1 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 0020 ... Image Name: ramdisk Created: 2007-04-15 17:31:31 UTC Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:712 Bytes = 0.7 kB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 007b8000, end 007b82c8 ... OK Linux version 2.6.15 ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #182 Mon Apr 16 00:56:43 CST 2007 Built 1 zonelists Kernel command line: root=/dev/ram rw PID hash table entries: 64 (order: 6, 1024 bytes) 50 Decrementer Frequency = 18750/60 Console: colour dummy device 80x25 Dentry cache hash table entries: 2048 (order: 1, 8192 bytes) Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) Memory: 6236k available (1408k kernel code, 364k data, 84k init, 0k highmem) Mount-cache hash table entries: 512 checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 0k freed NET: Registered protocol family 16 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered Generic RTC Driver v1.07 Serial: CPM driver $Revision: 0.01 $ ttyCPM0 at MMIO 0xfff00a80 (irq = 20) is a CPM UART RAMDISK driver initialized: 2 RAM disks of 1024K size 1024 blocksize loop: loaded (max 8 devices) eth0: CPM ENET Version 0.2 on SCC1, 00:00:00:00:00:00 NET: Registered protocol family 2 IP route cache hash table entries: 128 (order: -3, 512 bytes) TCP established hash table entries: 512 (order: -1, 2048 bytes) TCP bind hash table entries: 512 (order: -1, 2048 bytes) TCP: Hash tables configured (established 512 bind 512) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 RAMDISK: Compressed image found at block 0 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) <0>Rebooting in 180 seconds.. Thanks, Gavin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm] scheduler: fix the return of the first time_slice
At Mon, 16 Apr 2007 11:16:24 +0900, Satoru Takeuchi wrote: > > At Sat, 14 Apr 2007 01:31:12 +1000, > Con Kolivas wrote: > > > > On Monday 09 April 2007 16:09, Andrew Morton wrote: > > > On Sat, 07 Apr 2007 16:31:39 +0900 Satoru Takeuchi > > <[EMAIL PROTECTED]> wrote: > > > > When I was examining the following program ... > > > > > > > > 1. There are a large amount of small jobs takes several msecs, > > > > and the number of job increases constantly. > > > > 2. The process creates a thread or a process per job (I examined both > > > > the thread model and the process model). > > > > 3. Each child process/thread does the assigned job and exit > > > > immediately. > > > > > > > > ... I found that the thread model's latency is longer than proess > > > > model's one against my expectation. It's because of the current > > > > sched_fork()/sched_exit() implementation as follows: > > > > > > > > a) On sched_fork, the creator share its timeslice with new process. > > > > b) On sched_exit, if the exiting process didn't exhaust its first > > > > timeslice yet, it gives its timeslice to the parent. > > > > > > > > It has no problem on the process model since the creator is the parent. > > > > However, on the thread model, the creator is not the parent, it is same > > > > as the creator's parent. Hence, on this kind of program, the creator > > > > can't retrieve shared timeslice and exausts its timeslice at a rate of > > > > knots. In addition, somehow, the parent (typically shell?) gets extra > > > > timeslice. > > > > > > > > I believe it's a bug and the exiting process should give its timeslice > > > > to the creator. Now I have some patch plan to fix this problem as > > > > follow: > > > > > > > > a) Add the field for the creator to task_struct. It needs extra memory. > > > > b) Doesn't add extra field and have thread's parent the creater, which > > > > is same as process creation. However it has many side effects, for > > > > example, we also need to change sys_getppid() implementation. > > > > > > > > What do you think? Any comments are welcome. > > > > > > This comes at an awkward time, because we might well merge the > > > staircase/deadline work into 2.6.22, and I think it rewrites the part of > > > the scheduler which is causing the problems you're observing. > > > > > > Has anyone verified that SD fixes this problem and the one at > > > http://lkml.org/lkml/2007/4/7/21 ? > > > > No, SD does nothing different in this regard. There is no notion of who > > made > > the thread and who the remaining timeslice should go to. As you say, some > > decision on sched_exit should probably be used to decide where to send it. > > In > > the absence of yet more fields in task_struct, the easiest thing to do > > would > > be to check if the the thread id is equal to the pid and if not, send it to > > the pid (or any parent of that if it no longer exists). Whether it's worth > > adding yet another field to task_struct to track this or not I do not have > > enough information to make an informed choice in this regard. Either way > > I'm > > low on patch-creation cycles so please feel free to provide your solution. > > I wrote the patch fixing this problem. It's for 2.6.21-rc6 and works well. > I also examined the following load tests: > > - Compile kernel with -j4 option continuously for 8 hours on i386 UP box. > - Compile kernel with -j48 option continuously for 2 hours on ia64 12 CPU >box. > > Now I'm testing its 2.6.21-rc6-mm1(with SD) version and would submit it soon. Here is the -mm version. I examined the same test as -rc6. Thanks, Satoru --- Fix the return of the first time_slice Currently exiting process takes back its first_time_slice to its parent. If the task is created with CLONE_PARENT or CLONE_THREAD flag, the parent is not the creator. Hence the creator can't collect the time_slice and time_slice leak occurs. To fix this problem, remove first_time_slice field of task_struct and introduce time_slice_reaper field instead. The new field means the task which exiting task should return its first_time_slice to, and is NULL after exhausting its first time_slice. Signed-off-by: Satoru Takeuchi <[EMAIL PROTECTED]> Index: linux-2.6.21-rc6-mm1.tsfix/include/linux/sched.h === --- linux-2.6.21-rc6-mm1.tsfix.orig/include/linux/sched.h 2007-04-15 16:56:12.0 +0900 +++ linux-2.6.21-rc6-mm1.tsfix/include/linux/sched.h2007-04-15 16:56:17.0 +0900 @@ -864,8 +864,8 @@ * before being requeued at a lower priority. */ int time_slice; - /* Is this the very first time_slice this task has ever run. */ - unsigned int first_time_slice; + /* The task which this task should bring back its first time_slice. */ + struct task_struct *time_slice_reaper; /* How much this task receives at each priority level */ int quota; Index:
Unable to mount root fs on unknown-block(1,0)
Hi Folks, I got problem to boot linux 2.6.25 using u-boot-1.1.4, any ideas? - U-Boot 1.1.4 (Apr 14 2007 - 00:57:01) CPU: XPC850xxZTB at 50 MHz: 2 kB I-Cache 1 kB D-Cache Board: ### No HW ID - assuming TQM8xxL DRAM: 8 MB FLASH: 4 MB In:serial Out: serial Err: serial Net: SCC ETHERNET Hit any key to stop autoboot: 0 Using SCC ETHERNET device TFTP from server 90.0.0.1; our IP address is 90.0.0.2 Filename 'uImage'. Load address: 0x10 Loading: # # done Bytes transferred = 825541 (c98c5 hex) => printenv bootdelay=5 baudrate=9600 loads_echo=1 ethact=SCC ETHERNET netmask=0xff00 vlan=0x nvlan=0x clocks_in_mhz=1 bootcmd=tftp 0x10 uImage autostart=no filesize=c98c5 fileaddr=10 ipaddr=90.0.0.2 serverip=90.0.0.1 bootargs=root=/dev/ram rw stdin=serial stdout=serial stderr=serial Environment size: 293/16380 bytes => bdinfo memstart= 0x memsize = 0x0080 flashstart = 0x1000 flashsize = 0x0040 flashoffset = 0x00021000 sramstart = 0x sramsize= 0x0080 immr_base = 0xFFF0 bootflags = 0x0001 intfreq = 50 MHz busfreq = 50 MHz ethaddr = 00:00:00:00:00:00 IP addr = 90.0.0.2 baudrate= 9600 bps => tftp 0x20 aaa Using SCC ETHERNET device TFTP from server 90.0.0.1; our IP address is 90.0.0.2 Filename 'aaa'. Load address: 0x20 Loading: # done Bytes transferred = 776 (308 hex) => bootm 0x10 0x20 ## Booting image at 0010 ... Image Name: Linux-2.6.15 Created: 2007-04-15 16:56:44 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:825477 Bytes = 806.1 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 0020 ... Image Name: ramdisk Created: 2007-04-15 17:31:31 UTC Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:712 Bytes = 0.7 kB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 007b8000, end 007b82c8 ... OK Linux version 2.6.15 ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #182 Mon Apr 16 00:56:43 CST 2007 Built 1 zonelists Kernel command line: root=/dev/ram rw PID hash table entries: 64 (order: 6, 1024 bytes) 50 Decrementer Frequency = 18750/60 Console: colour dummy device 80x25 Dentry cache hash table entries: 2048 (order: 1, 8192 bytes) Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) Memory: 6236k available (1408k kernel code, 364k data, 84k init, 0k highmem) Mount-cache hash table entries: 512 checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 0k freed NET: Registered protocol family 16 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered Generic RTC Driver v1.07 Serial: CPM driver $Revision: 0.01 $ ttyCPM0 at MMIO 0xfff00a80 (irq = 20) is a CPM UART RAMDISK driver initialized: 2 RAM disks of 1024K size 1024 blocksize loop: loaded (max 8 devices) eth0: CPM ENET Version 0.2 on SCC1, 00:00:00:00:00:00 NET: Registered protocol family 2 IP route cache hash table entries: 128 (order: -3, 512 bytes) TCP established hash table entries: 512 (order: -1, 2048 bytes) TCP bind hash table entries: 512 (order: -1, 2048 bytes) TCP: Hash tables configured (established 512 bind 512) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 RAMDISK: Compressed image found at block 0 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) <0>Rebooting in 180 seconds.. Thanks, Gavin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] sparc64: modalias support for of_device
Hi Dave,
Quick patch to add modalias support for of_device to arch/sparc64 so
sbus drivers can be automatically loaded (I hope :)
Untested, as I'm sparc-less at the moment.
Cheers,
Kyle
diff --git a/arch/sparc64/kernel/of_device.c b/arch/sparc64/kernel/of_device.c
index fb9bf1e..d00ed90 100644
--- a/arch/sparc64/kernel/of_device.c
+++ b/arch/sparc64/kernel/of_device.c
@@ -173,6 +173,19 @@ struct of_device *of_find_device_by_node(struct
device_node *dp)
}
EXPORT_SYMBOL(of_find_device_by_node);
+static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ ssize_t len;
+ struct of_device *d = to_of_device(dev);
+ struct device_node *node = d->node;
+
+ len = sprintf(buf, "of:N%sT%sC%s\n",
+ node->name, node->type, "*");
+
+ return len;
+}
+
#ifdef CONFIG_PCI
struct bus_type isa_bus_type = {
.name = "isa",
@@ -207,9 +220,15 @@ struct bus_type sbus_bus_type = {
EXPORT_SYMBOL(sbus_bus_type);
#endif
+static struct device_attribute of_dev_attrs[] = {
+ __ATTR_RO(modalias),
+ __ATTR_NULL
+};
+
struct bus_type of_bus_type = {
.name = "of",
.match = of_platform_bus_match,
+ .dev_attrs = of_dev_attrs,
.probe = of_device_probe,
.remove = of_device_remove,
.suspend= of_device_suspend,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Bartek wrote: > 2007/4/14, David Miller <[EMAIL PROTECTED]>: > >> From: Patrick McHardy <[EMAIL PROTECTED]> >> Date: Thu, 12 Apr 2007 07:43:39 +0200 >> >> > It seems we fail to reserve enough headroom for the case >> > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. >> > >> > Can you try this patch please? >> >> Any confirmation of this fix yet? > > > I'm testing that patch, till now everything seems ok. Please test Paul's patch instead and keep everyone CCed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Bad page state errors during kernel make
On Sun, Apr 15, 2007 at 08:30:27PM -0700, Zach Carter wrote: > Console Messages: > Bad page state in process 'cc1' > page:c1ca88e8 flags:0x5200 mapping:c100 mapcount:0 count:0 > Trying to fix it up, but a reboot is needed > Backtrace: > [] bad_page+0x5e/0x89 > [] get_page_from_freelist+0x1de/0x298 > [] __alloc_pages+0x68/0x2aa > [] anon_vma_prepare+0x20/0xb8 > [] tasklet_action+0x4b/0xa4 > [] __handle_mm_fault+0x3b2/0x88f > [] smp_apic_timer_interrupt+0x6e/0x7a > [] hrtimer_run_queues+0x138/0x152 > [] do_page_fault+0x23f/0x53c > [] do_page_fault+0x0/0x53c > [] error_code+0x7c/0x84 > === > list_del corruption. prev->next should be c21a4628, but was e21a4628 'c' became 'e' in that last address. A single bit flipped. Given you've had this for some time, this smells like a hardware problem. memtest86+ will probably show up something. 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/2] 2.6.21-rc7: known regressions
Adrian Bunk wrote: > I'm not sure why I thought you two ran into the same regression. > > So "hpet=disable" worked for Jeremy but not for you, IOW: you two were > running into different regressions? > > @Jeremy: > If this is true, is your HPET related related regression still present > in -rc7? I need to recheck, but when I tried -rc6, I was still having resume problems but hpet=disabled didn't help. So I definitely think there are multiple bugs with the same symtoms. I haven't tried -rc7 yet. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG: Bad page state errors during kernel make
Hiya folks,
If there is anything I can do to help track down and fix this bug, please let
me know.
thanks!
-Zach
PROBLEM: Bad page state errors during kernel make
DESCRIPTION: Frequently, when trying to build the kernel from source,
my PC will lock up with console messages such as these. I do not
recall a version of the kernel when this has not been a problem,
however, it did become less frequent when I upgraded from 2.6.20.4 to
2.6.21-rc5.
Steps To Reproduce:
# note, I have never gotten past try #3
for i in 1 2 3 4 5
do
echo $i > /tmp/num_tries
cd /src/linux-2.6 && make clean && make -j4
done
Console Messages:
Bad page state in process 'cc1'
page:c1ca88e8 flags:0x5200 mapping:c100 mapcount:0 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
[] bad_page+0x5e/0x89
[] get_page_from_freelist+0x1de/0x298
[] __alloc_pages+0x68/0x2aa
[] anon_vma_prepare+0x20/0xb8
[] tasklet_action+0x4b/0xa4
[] __handle_mm_fault+0x3b2/0x88f
[] smp_apic_timer_interrupt+0x6e/0x7a
[] hrtimer_run_queues+0x138/0x152
[] do_page_fault+0x23f/0x53c
[] do_page_fault+0x0/0x53c
[] error_code+0x7c/0x84
===
list_del corruption. prev->next should be c21a4628, but was e21a4628
[ cut here ]
kernel BUG at lib/list_debug.c:67!
invalid opcode: [#1]
SMP
Modules linked in: xt_tcpudp iptable_filter ip_tables x_tables w83627ehf i2c_isa eeprom hidp l2cap
bluetooth sunrpc ipv6 cpufreq_ondemand dm_mirror dm_multipath dm_mod raid10 raid0 video sbs i2c_ec
dock button battery asus_acpi ac lp parport_serial snd_hda_intel snd_hda_codec snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss parport_pc ohci1394
snd_pcm usblp parport ieee1394 snd_timer sg ide_cd cdrom snd soundcore snd_page_alloc shpchp
forcedeth k8temp hwmon serio_raw i2c_nforce2 floppy i2c_core pcspkr sata_sil sata_via sata_nv libata
sd_mod scsi_mod raid456 xor raid1 ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU:0
EIP:0060:[]Tainted: GB VLI
EFLAGS: 00010092 (2.6.21-rc6 #17)
EIP is at list_del+0x21/0x5d
eax: 0048 ebx: c21a4608 ecx: c03f2fd0 edx: 0082
esi: c03f8c10 edi: 0011 ebp: 0011 esp: f7f03e6c
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process kswapd0 (pid: 245, ti=f7f02000 task=c258c7f0 task.ti=f7f02000)
Stack: c03b0c1a c21a4628 e21a4628 c21a4608 c0159617 f7f03f04 0020 c03f8c00
0c1d c03f7b00 f7f03f74 c0159762 f7f03f0c 0020 0007
0001 c21aebf8 c21adcd0 c21830c0 c21903d8
Call Trace:
[] isolate_lru_pages+0x31/0x7d
[] shrink_active_list+0xff/0x38a
[] mb_cache_shrink_fn+0x47/0xbb
[] shrink_slab+0x132/0x13e
[] shrink_zone+0xb3/0xef
[] kswapd+0x2c7/0x3fe
[] autoremove_wake_function+0x0/0x35
[] kswapd+0x0/0x3fe
[] kthread+0xb2/0xda
[] kthread+0x0/0xda
[] kernel_thread_helper+0x7/0x10
===
Code: 00 00 00 89 c3 eb e8 90 90 90 53 83 ec 0c 8b 48 04 8b 11 39 c2 74 18 89 54 24 08 89 44 24 04
c7 04 24 1a 0c 3b c0 e8 c9 fa f3 ff <0f> 0b eb fe 8b 10 8b 5a 04 39 c3 74 18 89 5c 24 08 89 44 24 04
EIP: [] list_del+0x21/0x5d SS:ESP 0068:f7f03e6c
BUG: spinlock lockup on CPU#1, ld/9860, c03f8c00
[] _raw_spin_lock+0xbb/0xdc
[] __pagevec_lru_add+0x42/0x8f
[] mpage_readpages+0xeb/0x110
[] ext3_get_block+0x0/0xd0 [ext3]
[] __alloc_pages+0x68/0x2aa
[] __ext3_journal_stop+0x19/0x34 [ext3]
[] ext3_readpages+0x0/0x15 [ext3]
[] __do_page_cache_readahead+0x125/0x1cc
[] ext3_get_block+0x0/0xd0 [ext3]
[] blockable_page_cache_readahead+0x4c/0x9f
[] page_cache_readahead+0xbf/0x196
[] do_generic_mapping_read+0x137/0x463
[] generic_file_aio_read+0x173/0x1a3
[] file_read_actor+0x0/0xe0
[] mmx_clear_page+0x24/0x60
[] do_sync_read+0xc7/0x10a
[] autoremove_wake_function+0x0/0x35
[] mutex_lock+0x1a/0x29
[] do_sync_read+0x0/0x10a
[] vfs_read+0xa6/0x152
[] sys_read+0x41/0x67
[] sysenter_past_esp+0x5d/0x81
===
BUG: spinlock lockup on CPU#0, irqbalance/2974, c03f8c00
[] _raw_spin_lock+0xbb/0xdc
[] __pagevec_lru_add_active+0x42/0x94
[] unmap_region+0x2b/0xfb
[] do_munmap+0x164/0x1b6
[] sys_munmap+0x30/0x3e
[] sysenter_past_esp+0x5d/0x81
===
-
Linux hoth 2.6.21-rc6 #17 SMP Fri Apr 13 09:51:51 PDT 2007 i686 athlon i386
GNU/Linux
Gnu C 4.1.1
Gnu make 3.81
binutils 2.17.50.0.6-2.fc6
util-linux 2.13-pre7
mount 2.13-pre7
module-init-tools 3.3-pre1
e2fsprogs 1.39
pcmciautils014
quota-tools3.13.
PPP2.4.4
isdn4k-utils 3.9
Linux C Library> libc.2.5
Dynamic linker (ldd) 2.5
Procps 3.2.7
Net-tools 1.60
Kbd1.12
oprofile 0.9.2
Sh-utils 5.97
udev 095
wireless-tools
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Mon, Apr 16, 2007 at 01:15:27PM +1000, Con Kolivas wrote: > On Monday 16 April 2007 12:28, Nick Piggin wrote: > > So, on to something productive, we have 3 candidates for a new scheduler so > > far. How do we decide which way to go? (and yes, I still think switchable > > schedulers is wrong and a copout) This is one area where it is virtually > > impossible to discount any decent design on correctness/performance/etc. > > and even testing in -mm isn't really enough. > > We're in agreement! YAY! > > Actually this is simpler than that. I'm taking SD out of the picture. It has > served it's purpose of proving that we need to seriously address all the > scheduling issues and did more than a half decent job at it. Unfortunately I > also cannot sit around supporting it forever by myself. My own life is more > important, so consider SD not even running the race any more. > > I'm off to continue maintaining permanent-out-of-tree leisurely code at my > own > pace. What's more is, I think I'll just stick to staircase Gen I version blah > and shelve SD and try to have fond memories of SD as an intellectual > prompting exercise only. Well I would hope that _if_ we decide to switch schedulers, then you get a chance to field something (and I hope you will decide to and have time to), and I hope we don't rush into the decision. We've had the current scheduler for so many years now that it is much more important to make sure we take the time to do the right thing rather than absolutely have to merge a new scheduler right now ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert
Adrian Bunk wrote: [ Cc's added, additional information is in http://lkml.org/lkml/2007/4/15/32 ] On Sun, Apr 15, 2007 at 02:49:29PM +0400, Brad Campbell wrote: Brad Campbell wrote: G'day all, All I have is a digital photo of this oops. (It's 3.5mb). I have serial console configured, but Murphy is watching me carefully and I just can't seem to reproduce it while logging the console output. And as usual, after trying to capture one for 4 days, I get one 10 mins after I've sent the E-mail :) I think I've just found a way to make this easier to reproduce as /dev/sdd was not even mounted this time. I just cold booted and started an md5sum -c run on a directory of about 180GB. Is this also present with kernel 2.6.20 or is it a regression? Yes, I reproduced it with 2.6.20 but appear to be unable to do so with 2.6.19. -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Mon, Apr 16, 2007 at 03:32:54AM +0100, ian wrote: > On Sun, 2007-04-15 at 21:57 -0300, Henrique de Moraes Holschuh wrote: > > > > No, that won't help much. IMO, we want the sanest set of standard > > attributes we can get, and weird as it might be, average reporting are > > common properties of battery control firmware on laptops (maybe > > because of SBS, but still...). > > We need to think very carefully here. > > charge, current, capacity, etc. are properties all batteries have, and > the current values can all be sampled instantaneously. > > funky values processed by 'black box' firmware are not universal > properties of all batteries. > > IOW, battery class should be for 'simple' battery types only. > > perhaps rename it to simple battery class to make it distinct? > > Userspace is the place to put the complications, in any case, and I see > nothing wrong with having both a simple battery class AND other > proprietary battery class an SBS battery class. (or a > toshiba_proprietary_bios battery class or whatever). > > Perhaps we need a 'libbattery.so' so that userspace can have a nice > consistent interface? Why? With current battery class we can do whatever everyone needs. No need for wrappers. Adding new properties is cheap and easy. Simple batteries using only "simple" properties/attributes, and complicated batteries using complicated attributes. Because of your original design, simple batteries are stay simple, and no noticing that there is some "complicated" attributes exists at all. That's indeed great characteristic of that *universal* battery class. For example, ds2760 is not really "simple" monitoring chip. ADC battery is (it's in -hh tree so far). So, ds2760 is somewhere in between SBS design, and dumb ADC batteries. So, my another purposal, which I very like now: Let's do self-documented properties. current_now, current_avg, e.t.c. No more just "current", lets remove any ambiguousness! -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Monday 16 April 2007 12:28, Nick Piggin wrote: > So, on to something productive, we have 3 candidates for a new scheduler so > far. How do we decide which way to go? (and yes, I still think switchable > schedulers is wrong and a copout) This is one area where it is virtually > impossible to discount any decent design on correctness/performance/etc. > and even testing in -mm isn't really enough. We're in agreement! YAY! Actually this is simpler than that. I'm taking SD out of the picture. It has served it's purpose of proving that we need to seriously address all the scheduling issues and did more than a half decent job at it. Unfortunately I also cannot sit around supporting it forever by myself. My own life is more important, so consider SD not even running the race any more. I'm off to continue maintaining permanent-out-of-tree leisurely code at my own pace. What's more is, I think I'll just stick to staircase Gen I version blah and shelve SD and try to have fond memories of SD as an intellectual prompting exercise only. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: If not readdir() then what?
On Thu, Apr 12, 2007 at 10:35:49AM -0700, H. Peter Anvin wrote: > J. Bruce Fields wrote: > >On Thu, Apr 12, 2007 at 08:21:16AM -0400, Theodore Tso wrote: > >>Again, compared to a directory fd cache, what you're proposing a huge > >>hit to the filesystem, and at the moment, given that telldir/seekdir > >>is rarely used by everyone else, it's mainly NFS which is the main bad > >>actor here by insisting on the use of a small 31/63-bit cookie as a > >>condition of protocol correctness. > > > >If we want to get bigger cookies into the protocol, then the sooner we > >start working on that the better How big is big enough? And is a > >larger cookie sufficient on its own? > > > > Any fixed size is too small. It should be a dynamic size. Idally it should be dynamic, but my guess is that if the cookie were a fixed 256 bits, it would be sufficient for pretty much all filesystems. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZFS with Linux: An Open Plea
On Sun, Apr 15, 2007 at 08:50:25PM -0400, Rik van Riel wrote: > David R. Litwin wrote: > > >>4: ZFS has a HUGE capacity. I don't have 30 exobytes, but I might some > >>day > > > >ext4 will probably cope with that. XFS definitely has very high > >limits though I admit I don't know what they are. > > > >XFS is also a few exobytes. > > The fsck for none of these filesystems will be able to deal with > a filesystem that big. Unless, of course, you have a few weeks > to wait for fsck to complete. Which is why I want to be able to partially offline a chunk of a filesystem and repair it while the rest is still online. > Backup and restore are similar problems. When part of the filesystem > is lost, you don't want to have to wait for a full restore. > > Sounds simple? Well, the hard part is figuring out exactly which > part of the filesystem you need to restore... > > I don't see ZFS, ext4 or XFS addressing these issues. XFS has these sorts of issues directly in our cross-hairs. The major scaling problem XFS has right now is to do with how long repair/backup/restore take when you have hundreds of terabytes of storage. > IMHO chunkfs could provide a much more promising approach. Agreed, that's one method of compartmentalising the problem. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
William Lee Irwin III wrote: >> One of the reasons I never posted my own code is that it never met its >> own design goals, which absolutely included switching on the fly. I >> think Peter Williams may have done something about that. >> It was my hope >> to be able to do insmod sched_foo.ko until it became clear that the >> effort it was intended to assist wasn't going to get even the limited >> hardware access required, at which point I largely stopped working on >> it. On Mon, Apr 16, 2007 at 11:06:56AM +1000, Peter Williams wrote: > I didn't but some students did. > In a previous life, I did implement a runtime configurable CPU > scheduling mechanism (implemented on True64, Solaris and Linux) that > allowed schedulers to be loaded as modules at run time. This was > released commercially on True64 and Solaris. So I know that it can be done. > I have thought about doing something similar for the SPA schedulers > which differ in only small ways from each other but lack motivation. Driver models for scheduling are not so far out. AFAICS it's largely a tug-of-war over design goals, e.g. maintaining per-cpu runqueues and switching out intra-queue policies vs. switching out whole-system policies, SMP handling and all. Whether this involves load balancing depends strongly on e.g. whether you have per-cpu runqueues. A 2.4.x scheduler module, for instance, would not have a load balancer at all, as it has only one global runqueue. There are other sorts of policies wanting significant changes to SMP handling vs. the stock load balancing. William Lee Irwin III wrote: >> I'm not sure what happened there. It wasn't a big enough patch to take >> hits in this area due to getting overwhelmed by the programming burden >> like some other efforts of mine. Maybe things started getting ugly once >> on-the-fly switching entered the picture. My guess is that Peter Williams >> will have to chime in here, since things have diverged enough from my >> one-time contribution 4 years ago. On Mon, Apr 16, 2007 at 11:06:56AM +1000, Peter Williams wrote: > From my POV, the current version of plugsched is considerably simpler > than it was when I took the code over from Con as I put considerable > effort into minimizing code overlap in the various schedulers. > I also put considerable effort into minimizing any changes to the load > balancing code (something Ingo seems to think is a deficiency) and the > result is that plugsched allows "intra run queue" scheduling to be > easily modified WITHOUT effecting load balancing. To my mind scheduling > and load balancing are orthogonal and keeping them that way simplifies > things. ISTR rearranging things for con in such a fashion that it no longer worked out of the box (though that wasn't the intention; restructuring it to be more suited to his purposes was) and that's what he worked off of afterward. I don't remember very well what changed there as I clearly invested less effort there than the prior versions. Now that I think of it, that may have been where the sample policy demonstrating scheduling classes was lost. On Mon, Apr 16, 2007 at 11:06:56AM +1000, Peter Williams wrote: > As Ingo correctly points out, plugsched does not allow different > schedulers to be used per CPU but it would not be difficult to modify it > so that they could. Although I've considered doing this over the years > I decided not to as it would just increase the complexity and the amount > of work required to keep the patch set going. About six months ago I > decided to reduce the amount of work I was doing on plugsched (as it was > obviously never going to be accepted) and now only publish patches > against the vanilla kernel's major releases (and the only reason that I > kept doing that is that the download figures indicated that about 80 > users were interested in the experiment). That's a rather different goal from what I was going on about with it, so it's all diverged quite a bit. Where I had a significant need for mucking with the entire concept of how SMP was handled, this is rather different. At this point I'm questioning the relevance of my own work, though it was already relatively marginal as it started life as an attempt at a sort of debug patch to help gang scheduling (which is in itself a rather marginally relevant feature to most users) code along. On Mon, Apr 16, 2007 at 11:06:56AM +1000, Peter Williams wrote: > PS I no longer read LKML (due to time constraints) and would appreciate > it if I could be CC'd on any e-mails suggesting scheduler changes. > PPS I'm just happy to see that Ingo has finally accepted that the > vanilla scheduler was badly in need of fixing and don't really care who > fixes it. > PPS Different schedulers for different aims (i.e. server or work > station) do make a difference. E.g. the spa_svr scheduler in plugsched > does about 1% better on kernbench than the next best scheduler in the bunch. > PPPS Con, fairness isn't always best as
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Sun, Apr 15, 2007 at 04:31:54PM -0500, Matt Mackall wrote: > On Sun, Apr 15, 2007 at 10:48:24PM +0200, Ingo Molnar wrote: > > > 4) the good thing that happened to I/O, after years of stagnation isnt > >I/O schedulers. The good thing that happened to I/O is called Jens > >Axboe. If you care about the I/O subystem then print that name out > >and hang it on the wall. That and only that is what mattered. > > Disagree. Things didn't actually get interesting until Nick showed up > with AS and got it in-tree to demonstrate the huge amount of room we > had for improvement. It took several iterations of AS and CFQ (with a > couple complete rewrites) before CFQ began to look like the winner. > The resulting time-sliced CFQ was fairly heavily influenced by the > ideas in AS. Well to be fair, Jens had just implemented deadline, which got me interested ;) Actually, I would still like to be able to deprecate deadline for AS, because AS has a tunable that you can switch to turn off read anticipation and revert to deadline behaviour (or very close to). It would have been nice if CFQ were then a layer on top of AS that implemented priorities (or vice versa). And then AS could be deprecated and we'd be back to 1 primary scheduler. Well CFQ seems to be going in the right direction with that, however some large users still find AS faster for some reason... Anyway, moral of the story is that I think it would have been nice if we hadn't proliferated IO schedulers, however in practice it isn't easy to just layer features on top of each other, and also keeping deadline helped a lot to be able to debug and examine performance regressions and actually get code upstream. And this was true even when it was globally boottine switchable only. I'd prefer if we kept a single CPU scheduler in mainline, because I think that simplifies analysis and focuses testing. I think we can have one that is good enough for everyone. But if the only other option for progress is that Linus or Andrew just pull one out of a hat, then I would rather merge all of them. Yes I think Con's scheduler should get a fair go, ditto for Ingo's, mine, and anyone else's. > > nor was the non-modularity of some piece of code ever an impediment to > > competition. May i remind you of the pretty competitive SLAB allocator > > landscape, resulting in things like the SLOB allocator, written by > > yourself? ;-) > > Thankfully no one came out and said "we don't want to balkanize the > allocator landscape" when I submitted it or I probably would have just > dropped it, rather than painfully dragging it along out of tree for > years. I'm not nearly the glutton for punishment that Con is. :-P I don't think this is a fault of the people or the code involved. We just didn't have much collective drive to replace the scheduler, and even less an idea of how to decide between any two of them. I've kept nicksched around since 2003 or so and no hard feelings ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZFS with Linux: An Open Plea
On Sat, Apr 14, 2007 at 08:56:40PM +0200, Krzysztof Halasa wrote: > Neil Brown <[EMAIL PROTECTED]> writes: > > > What, specifically, is there in ZFS that you want to use in Linux? > > There is lots of interesting stuff in there, but which bit has caught > > your attention? It is possible that that functionality can be > > incorporated into Linux without trying to clone or copy ZFS. > > Filesystem block hashes (checksums) and in-fs redundancy (using the > hashes to determine which copy of data is correct in case of > corruption). It would mean multi-device filesystem. Yup - multidevice support in XFS is something I'm working on at the moment. There's many nice features that multi-device filesystems can take advantage of (different geomteries, multiple journals, internal RAID, redundancy, partially online/offline filesystems, partial filesystem repair, etc). Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Sun, 2007-04-15 at 21:57 -0300, Henrique de Moraes Holschuh wrote: > > No, that won't help much. IMO, we want the sanest set of standard > attributes we can get, and weird as it might be, average reporting are > common properties of battery control firmware on laptops (maybe > because of SBS, but still...). We need to think very carefully here. charge, current, capacity, etc. are properties all batteries have, and the current values can all be sampled instantaneously. funky values processed by 'black box' firmware are not universal properties of all batteries. IOW, battery class should be for 'simple' battery types only. perhaps rename it to simple battery class to make it distinct? Userspace is the place to put the complications, in any case, and I see nothing wrong with having both a simple battery class AND other proprietary battery class an SBS battery class. (or a toshiba_proprietary_bios battery class or whatever). Perhaps we need a 'libbattery.so' so that userspace can have a nice consistent interface? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CPU_IDLE prevents resuming from STR [was: Re: 2.6.21-rc6-mm1]
On Sat, 2007-04-14 at 01:45 +0200, Mattia Dongili wrote: > On Sun, Apr 08, 2007 at 02:35:59PM -0700, Andrew Morton wrote: > ... > > git-acpi.patch > > after bisecting I can finally say what breaks resume from STR here: > > tada: CPU_IDLE. > I first spotted the git-acpi.patch then reapplied it and disabled > CPU_IDLE, now my laptop resumes. > > Any useful information I should add? > > $ cat /sys/devices/system/cpu/cpuidle/* > acpi_idle > no governors > acpi_idle > no governor please check if the patch at http://marc.info/?l=linux-acpi=117523651630038=2 fixed the issue Thanks, Shaohua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Mon, Apr 16, 2007 at 08:52:33AM +1000, Con Kolivas wrote: > On Monday 16 April 2007 05:00, Jonathan Lundell wrote: > > On Apr 15, 2007, at 10:59 AM, Linus Torvalds wrote: > > > It's a really good thing, and it means that if somebody shows that > > > your > > > code is flawed in some way (by, for example, making a patch that > > > people > > > claim gets better behaviour or numbers), any *good* programmer that > > > actually cares about his code will obviously suddenly be very > > > motivated to > > > out-do the out-doer! > > > > "No one who cannot rejoice in the discovery of his own mistakes > > deserves to be called a scholar." > > Lovely comment. I realise this is not truly directed at me but clearly in the > context it has been said people will assume it is directed my way, so while > we're all spinning lkml quality rhetoric, let me have a right of reply. > > One thing I have never tried to do was to ignore bug reports. I'm forever > joking that I keep pulling code out of my arse to improve what I've done. > RSDL/SD was no exception; heck it had 40 iterations. The reason I could not > reply to bug report A with "Oh that is problem B so I'll fix it with code C" > was, as I've said many many times over, health related. I did indeed try to > fix many of them without spending hours replying to sometimes unpleasant > emails. If health wasn't an issue there might have been 1000 iterations of > SD. Well what matters is the code and development. I don't think Ingo's scheduler is the final word, although I worry that Linus might jump the gun and merge something "just to give it a test", which we then get stuck with :P I don't know how anybody can think Ingo's new scheduler is anything but a good thing (so long as it has to compete before being merged). And that's coming from someone who wants *their* scheduler to get merged... I think mine can compete ;) and if it can't, then I'd rather be using the scheduler that beats it. > There was only ever _one_ thing that I was absolutely steadfast on as a > concept that I refused to fix that people might claim was "a mistake I did > not rejoice in to be a scholar". That was that the _correct_ behaviour for a > scheduler is to be fair such that proportional slowdown with load is (using > that awful pun) a feature, not a bug. If something is using more than a fair share of CPU time, over some macro period, in order to be interactive, then definitely it should get throttled. I've always maintained (since starting scheduler work) that the 2.6 scheduler is horrible because it allows these cases where some things can get more CPU time just by how they behave. Glad people are starting to come around on that point. So, on to something productive, we have 3 candidates for a new scheduler so far. How do we decide which way to go? (and yes, I still think switchable schedulers is wrong and a copout) This is one area where it is virtually impossible to discount any decent design on correctness/performance/etc. and even testing in -mm isn't really enough. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] scheduler: fix the return of the first time_slice
At Sat, 14 Apr 2007 01:31:12 +1000,
Con Kolivas wrote:
>
> On Monday 09 April 2007 16:09, Andrew Morton wrote:
> > On Sat, 07 Apr 2007 16:31:39 +0900 Satoru Takeuchi
> <[EMAIL PROTECTED]> wrote:
> > > When I was examining the following program ...
> > >
> > > 1. There are a large amount of small jobs takes several msecs,
> > > and the number of job increases constantly.
> > > 2. The process creates a thread or a process per job (I examined both
> > > the thread model and the process model).
> > > 3. Each child process/thread does the assigned job and exit
> > > immediately.
> > >
> > > ... I found that the thread model's latency is longer than proess
> > > model's one against my expectation. It's because of the current
> > > sched_fork()/sched_exit() implementation as follows:
> > >
> > > a) On sched_fork, the creator share its timeslice with new process.
> > > b) On sched_exit, if the exiting process didn't exhaust its first
> > > timeslice yet, it gives its timeslice to the parent.
> > >
> > > It has no problem on the process model since the creator is the parent.
> > > However, on the thread model, the creator is not the parent, it is same
> > > as the creator's parent. Hence, on this kind of program, the creator
> > > can't retrieve shared timeslice and exausts its timeslice at a rate of
> > > knots. In addition, somehow, the parent (typically shell?) gets extra
> > > timeslice.
> > >
> > > I believe it's a bug and the exiting process should give its timeslice
> > > to the creator. Now I have some patch plan to fix this problem as follow:
> > >
> > > a) Add the field for the creator to task_struct. It needs extra memory.
> > > b) Doesn't add extra field and have thread's parent the creater, which
> > > is same as process creation. However it has many side effects, for
> > > example, we also need to change sys_getppid() implementation.
> > >
> > > What do you think? Any comments are welcome.
> >
> > This comes at an awkward time, because we might well merge the
> > staircase/deadline work into 2.6.22, and I think it rewrites the part of
> > the scheduler which is causing the problems you're observing.
> >
> > Has anyone verified that SD fixes this problem and the one at
> > http://lkml.org/lkml/2007/4/7/21 ?
>
> No, SD does nothing different in this regard. There is no notion of who made
> the thread and who the remaining timeslice should go to. As you say, some
> decision on sched_exit should probably be used to decide where to send it. In
> the absence of yet more fields in task_struct, the easiest thing to do would
> be to check if the the thread id is equal to the pid and if not, send it to
> the pid (or any parent of that if it no longer exists). Whether it's worth
> adding yet another field to task_struct to track this or not I do not have
> enough information to make an informed choice in this regard. Either way I'm
> low on patch-creation cycles so please feel free to provide your solution.
I wrote the patch fixing this problem. It's for 2.6.21-rc6 and works well.
I also examined the following load tests:
- Compile kernel with -j4 option continuously for 8 hours on i386 UP box.
- Compile kernel with -j48 option continuously for 2 hours on ia64 12 CPU
box.
Now I'm testing its 2.6.21-rc6-mm1(with SD) version and would submit it soon.
Thanks,
Satoru
---
Fix the return of the first time_slice
Currently exiting process takes back its first_time_slice to its
parent. If the task is created with CLONE_PARENT or CLONE_THREAD
flag, the parent is not the creator. Hence the creator can't
collect the time_slice and time_slice leak occurs.
To fix this problem, remove first_time_slice field of task_struct
and introduce time_slice_reaper field instead. The new field means
the task which exiting task should return its first_time_slice to,
and is NULL after exhausting its first time_slice.
Signed-off-by: Satoru Takeuchi <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc6.tsfix/kernel/exit.c
===
--- linux-2.6.21-rc6.tsfix.orig/kernel/exit.c 2007-04-13 20:53:11.0
+0900
+++ linux-2.6.21-rc6.tsfix/kernel/exit.c2007-04-14 13:58:29.0
+0900
@@ -679,6 +679,8 @@
reaper = child_reaper(father);
break;
}
+ if (reaper->time_slice_reaper == father)
+ p->time_slice_reaper = NULL;
} while (reaper->exit_state);
/*
@@ -700,6 +702,8 @@
if (father == p->real_parent) {
/* reparent with a reaper, real father it's us */
+ if (p->time_slice_reaper == father)
+ p->time_slice_reaper = NULL;
choose_new_parent(p, reaper);
reparent_thread(p, father, 0);
} else {
@@ -721,6 +725,8 @@
}
list_for_each_safe(_p, _n,
Re: [PATCH 3/7] [RFC] Battery monitoring class
On Sun, Apr 15, 2007 at 09:57:22PM -0300, Henrique de Moraes Holschuh wrote: > On Mon, 16 Apr 2007, Anton Vorontsov wrote: > > Current battery class assumes values are not averaged. I.e. momentary > > values. In general, it's userspace' job to collect statistics. Though, > > if hardware can report only average values, it's just okay to use > > usual attributes. > > What about SBS-style battery firmware, which can report *both* ? This > includes just about all ThinkPads in the last five years, so we are talking > about a damn big lot of machines... Sure, no problem. I'm taking away my words "if hardware can report only average values, it's just okay to use usual attributes", and replacing them by "if hardware can report only average values, it should use _AVG attributes". So, this scheme should work now: 1. If userspace (nice GUI app) seeing _avg values, it will use these. 2. If userspace seeing no _avg values, it is using its own statistics mechanism, i.e. collecting information from momentary attributes. 3. If userspace seeing both, it can decide, most probably it will decide to use hardware averaged values, i.e. _avg. > I'd really appreciate if there is a standard way to communicate both. And > it is probably a good idea to define what should be averaged, and what > should be instantaneous when that matters, that way userspace actually has a > chance at not doing something braindamaged. > > Actually, IMHO, every attribute and alarm from SBS should be somehow > losslessly translatable to standard class attributes from day one, unless it > is something that makes no sense at all (and there is precious little of > that in the latest version of SBS, thankfully...). > > > Also, if you your battery can collect and report its approximated values > > in additional to momentary values, you're free to add _AVG attributes > > to standard ones and use them. > > No, that won't help much. IMO, we want the sanest set of standard > attributes we can get, and weird as it might be, average reporting are > common properties of battery control firmware on laptops (maybe because of > SBS, but still...). Why that won't help? Is there something else besides momentary and hardware-averaged values? > We don't have to get it perfect at the first try, but I really think we are > getting a bit too far from "as good as we can make it" at the first attempt > if we don't take the SBS into account properly, given the ammount of > circuits and firmware out there that are shaped along the SBS guidelines. I guess the only question for you is whether we would use, "attr" as momentary and "attr_avg" as averaged by hardware value, or will use "attr" as averaged values, and something alike "attr_now" for momentary? And you voting for "attr" being averaged and "attr_now" momentary. Actually, I don't see much difference, except default assumption of "attr" being averaged/momentary. Though, if it's real issue for you or SBS conformity, I can surely rename attrs. > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh > And again, much thanks for your comments! They're really helpful. -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [xfs-masters] Re: mm snapshot broken-out-2007-04-11-02-24.tar.gz uploaded
On Wed, Apr 11, 2007 at 03:42:04PM -0700, Andrew Morton wrote:
> On Thu, 12 Apr 2007 00:14:59 +0200
> Michal Piotrowski <[EMAIL PROTECTED]> wrote:
>
> > Andrew Morton napisa__(a):
> > [ 1053.757285] EIP is at xlog_iodone+0x99/0xbb [xfs]
> > [ 1053.762069] eax: ebx: d6871ae8 ecx: c04a396c edx:
> > [ 1053.769002] esi: d6871ae8 edi: d0f7def8 ebp: d0fa5f30 esp: d0fa5f18
> > [ 1053.775912] ds: 007b es: 007b fs: 00d8 gs: ss: 0068
> > [ 1053.781842] Process xfslogd/1 (pid: 3642, ti=d0fa4000 task=cac7f5a0
> > task.ti=d0fa4000)
> > [ 1053.789660] Stack: c01339fc d0f36130 db641df8 d6871ae8 d0f3611c d6871b84
> > d0fa5f40 fddab492
> > [ 1053.798450]dd2439ad d6871b88 d0fa5f70 c0133a26 c9c39db0 d0f36144
> > d0fa5f70 c01372d8
> > [ 1053.807213] fddab477 d0f3611c d0f85d70
> > d0fa5fb0 c0134469
> > [ 1053.815902] Call Trace:
> > [ 1053.818721] [] xfs_buf_iodone_work+0x1b/0x3e [xfs]
> > [ 1053.824830] [] run_workqueue+0x8e/0x15a
> > [ 1053.829766] [] worker_thread+0x108/0x116
> > [ 1053.834793] [] kthread+0xb5/0xe1
> > [ 1053.839129] [] kernel_thread_helper+0x7/0x10
> > [ 1053.844539] ===
> > [ 1053.848172] INFO: lockdep is turned off.
> > [ 1053.852201] Code: 46 4c db fd ba 02 00 00 00 e8 61 fc 01 00 ba 02 00 00
> > 00 eb 0f 8a 47 78 83 e0 80 3c 01 19 d2 f7 d2 83 e2 02 89 f8 e8 99 f7 ff ff
> > 46 68 10 75 14 f0 ff 86 bc 00 00 00 7f 0b 8d 86 bc 00 00 00
> > [ 1053.872927] EIP: [] xlog_iodone+0x99/0xbb [xfs] SS:ESP
> > 0068:d0fa5f18
> >
>
> Bingo. So it seems the xfslogd_workqueue is being run after unmount has
> freed the memory which it uses. Or something along those lines.
It looks like the workqueue is being run while the log is
being torn down.
On unmount, we write a log record to indicate a clean unmount just
before we tear the log down. We sleep on the iclog force semaphore
waiting for the log I/O to complete, which is processed by xfslogd
and xlog_iodone().
xlog_iodone() calls xlog_state_done_syncing() which processes the I/O
completion and wakes the unmount process sleeping on the semaphore.
xlog_state_done_syncing() then does a bit more work before returning
to xlog_iodone() where we check the buffer to determine if it was an
async I/o or not.
However, before we get to this, the unmount process has woken and
continued onwards which then frees the iclogs and the buffer. Hence
we have a race between xlog_iodone() looking at the buffer and the
unmount process tearing the buffer down.
There's a couple of different ways I can see to fix the problem -
the first is to not reference the buffer in xlog_iodone() after
running the callbacks that may trigger it being freed. I'd prfer to
see if this fixes the problem before having to do more invasive
surgery. Can you try the patch below to see if it fixes the
problem?
> > >> [11050.550630] -
> > >> [11050.556142] umount/3359 is trying to acquire lock:
> > >> [11050.561060] (&(>i_lock)->mr_lock){}, at: []
> > >> xfs_ilock+0x4d/0x6e [xfs]
> > >> [11050.569565]
> > >> [11050.569567] but task is already holding lock:
> > >> [11050.575487] (&(>i_lock)->mr_lock){}, at: []
> > >> xfs_ilock+0x4d/0x6e [xfs]
> > >
> > > An xfs thing.
> >
> > Yes, I know. This is a known bug since at least 05-Jul-2006.
>
> It's probably not very important - often these things turn out to not
> really be deadlockable at all.
Right - it's not a bug as such. XFS needs lockdep annotations
(being worked on) to prevent this.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
---
fs/xfs/xfs_log.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
Index: 2.6.x-xfs-new/fs/xfs/xfs_log.c
===
--- 2.6.x-xfs-new.orig/fs/xfs/xfs_log.c 2007-04-03 09:09:36.0 +1000
+++ 2.6.x-xfs-new/fs/xfs/xfs_log.c 2007-04-16 11:40:21.655306665 +1000
@@ -988,14 +988,11 @@ xlog_iodone(xfs_buf_t *bp)
} else if (iclog->ic_state & XLOG_STATE_IOERROR) {
aborted = XFS_LI_ABORTED;
}
+ /* log I/O is always issued ASYNC, so we should see that here */
+ WARN_ON(!(XFS_BUF_ISASYNC(bp)));
xlog_state_done_syncing(iclog, aborted);
- if (!(XFS_BUF_ISASYNC(bp))) {
- /*
-* Corresponding psema() will be done in bwrite(). If we don't
-* vsema() here, panic.
-*/
- XFS_BUF_V_IODONESEMA(bp);
- }
+ /* do not reference bp here - it may have been freed during unmount */
+
} /* xlog_iodone */
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
William Lee Irwin III wrote: On Sun, Apr 15, 2007 at 10:48:24PM +0200, Ingo Molnar wrote: 2) plugsched did not allow on the fly selection of schedulers, nor did it allow a per CPU selection of schedulers. IO schedulers you can change per disk, on the fly, making them much more useful in practice. Also, IO schedulers (while definitely not being slow!) are alot less performance sensitive than CPU schedulers. One of the reasons I never posted my own code is that it never met its own design goals, which absolutely included switching on the fly. I think Peter Williams may have done something about that. I didn't but some students did. In a previous life, I did implement a runtime configurable CPU scheduling mechanism (implemented on True64, Solaris and Linux) that allowed schedulers to be loaded as modules at run time. This was released commercially on True64 and Solaris. So I know that it can be done. I have thought about doing something similar for the SPA schedulers which differ in only small ways from each other but lack motivation. It was my hope to be able to do insmod sched_foo.ko until it became clear that the effort it was intended to assist wasn't going to get even the limited hardware access required, at which point I largely stopped working on it. On Sun, Apr 15, 2007 at 10:48:24PM +0200, Ingo Molnar wrote: 3) I/O schedulers are pretty damn clean code, and plugsched, at least the last version i saw of it, didnt come even close. I'm not sure what happened there. It wasn't a big enough patch to take hits in this area due to getting overwhelmed by the programming burden like some other efforts of mine. Maybe things started getting ugly once on-the-fly switching entered the picture. My guess is that Peter Williams will have to chime in here, since things have diverged enough from my one-time contribution 4 years ago. From my POV, the current version of plugsched is considerably simpler than it was when I took the code over from Con as I put considerable effort into minimizing code overlap in the various schedulers. I also put considerable effort into minimizing any changes to the load balancing code (something Ingo seems to think is a deficiency) and the result is that plugsched allows "intra run queue" scheduling to be easily modified WITHOUT effecting load balancing. To my mind scheduling and load balancing are orthogonal and keeping them that way simplifies things. As Ingo correctly points out, plugsched does not allow different schedulers to be used per CPU but it would not be difficult to modify it so that they could. Although I've considered doing this over the years I decided not to as it would just increase the complexity and the amount of work required to keep the patch set going. About six months ago I decided to reduce the amount of work I was doing on plugsched (as it was obviously never going to be accepted) and now only publish patches against the vanilla kernel's major releases (and the only reason that I kept doing that is that the download figures indicated that about 80 users were interested in the experiment). Peter PS I no longer read LKML (due to time constraints) and would appreciate it if I could be CC'd on any e-mails suggesting scheduler changes. PPS I'm just happy to see that Ingo has finally accepted that the vanilla scheduler was badly in need of fixing and don't really care who fixes it. PPS Different schedulers for different aims (i.e. server or work station) do make a difference. E.g. the spa_svr scheduler in plugsched does about 1% better on kernbench than the next best scheduler in the bunch. PPPS Con, fairness isn't always best as humans aren't very altruistic and we need to give unfair preference to interactive tasks in order to stop the users flinging their PCs out the window. But the current scheduler doesn't do this very well and is also not very good at fairness so needs to change. But the changes need to address interactive response and fairness not just fairness. -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB updates
Mauro, I've been out of town for the past few days... I just got home and saw this: Mauro Carvalho Chehab wrote: >- Fix 1/3 for bug 7819: fixed frontend hotplug issue >- Fix 2/3 for bug 7819: demux and dvr >- Fix 3/3 for bug 7819: fixed hotplugging for dvbnet I don't think that this is 2.6.21 material. These patches have not yet received enough testing to be sent to mainline. I have tested them, and they seem to work for my cxusb device, but we have yet to hear test results from users of usb dvb devices that do not use the dvb-usb framework. (ttusb, flexcop-usb, cinergyT2, for example) The bug that these patches fix has been around throughout the entire kernel history of the dvb subsystem. The bug is not a regression -- it has always been there. In my opinion, it is too late in 2.6.21 development to apply this change. Because these fixes are not obvious, I think we should let them get some more testing, and have them queued for 2.6.22 . Regards, 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: 2.6.21-rc6, ASUS M2V 1.01G, ALSA detection/non-support
On Sun, 15 Apr 2007, Jiri Slaby wrote: Date: Sun, 15 Apr 2007 23:45:29 +0200 From: Jiri Slaby <[EMAIL PROTECTED]> To: Richard A Nelson <[EMAIL PROTECTED]> Cc: linux-kernel Subject: Re: 2.6.21-rc6, ASUS M2V 1.01G, ALSA detection/non-support Cc: [EMAIL PROTECTED] Richard A Nelson napsal(a): My son has an earlier version of the M2V & BIOS (0901) and his gets full 6ch sound. The 1.01G, and related BIOS (1304 or 1701) do not properly handle the onboard sound: hda_codec: Unknown model for ALC660VD/ALC861VD, trying auto-probe from BIOS... What does your /proc/asound/version say? Both machines say: Advanced Linux Sound Architecture Driver Version 1.0.14rc3 (Wed Mar 14 07:25:50 2007 UTC). The machines are running Debian Sid -- Rick Nelson Life'll kill ya -- Warren Zevon Then you'll be dead -- Life'll kill ya - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/2] 2.6.21-rc7: known regressions
On Sun, Apr 15, 2007 at 08:54:46PM -0400, Dave Jones wrote: > On Mon, Apr 16, 2007 at 02:37:23AM +0200, Adrian Bunk wrote: > > > Subject: ThinkPad X60: resume no longer works (PCI related?) > > workaround: booting with "hpet=disable" > > References : http://lkml.org/lkml/2007/3/13/3 > > Submitter : Dave Jones <[EMAIL PROTECTED]> > > Jeremy Fitzhardinge <[EMAIL PROTECTED]> > > Caused-By : PCI merge > > commit 78149df6d565c36675463352d0bfeb02b7a7 > > Handled-By : Eric W. Biederman <[EMAIL PROTECTED]> > > Rafael J. Wysocki <[EMAIL PROTECTED]> > > Status : unknown > > note that this workaround doesn't seem to work in all cases. > Mine may a slightly different model (I have the tablet version) > but disabling hpet shows the same regression. > I've been fighting Eric's USB debug cable code in the hope > of getting _something_ useful out of it other than a black screen, > but I've been getting nowhere with it. I'm not sure why I thought you two ran into the same regression. So "hpet=disable" worked for Jeremy but not for you, IOW: you two were running into different regressions? @Jeremy: If this is true, is your HPET related related regression still present in -rc7? > Dave 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 0/8] unprivileged mount syscall
Quoting Miklos Szeredi ([EMAIL PROTECTED]): > > > > Agreed on desired behavior, but not on chroot sufficing. It actually > > > > sounds like you want exactly what was outlined in the OLS paper. > > > > > > > > Users still need to be in a different mounts namespace from the admin > > > > user so long as we consider the deluser and backup problems > > > > > > I don't think it matters, because /share/$USER duplicates a part or > > > the whole of the user's namespace. > > > > > > So backup would have to be taught about /share anyway, and deluser > > > operates on /home/$USER and not on /share/*, so there shouldn't be any > > > problem. > > > > In what I was thinking of, /share/$USER is bind mounted to > > ~$USER/share, so it would have to be done in a private namespace in > > order for deluser to not be tricked. > > But /share/$USER is surely not bind mounted to ~$USER/share in the > _global_ namespace, is it? I can't see any sense in that. No it's not, only in the private namespace. > > > There's actually very little difference between rbind+chroot, and > > > CLONE_NEWNS. In a private namespace: > > > > > > 1) when no more processes reference the namespace, the tree will be > > > disbanded > > > > > > 2) the mount tree won't be accessible from outside the namespace > > > > But it *can* be, if properly set up. That's part of the point of the > > example in the OLS paper. When a user logs in, sshd clones a new > > namespace, then bind-mounts /share/$USER into ~$USER/share. So assuming > > that /share/$USER was --make-shared'd, it and ~$USER are now in the > > same peer group, and any changes made by the user under ~$USER will > > be reflected back into /share/$USER. > > I acknowledge, that it can be done. My point was that it can be done > more simply _without_ using CLONE_NS. Seems like a matter of preference, but I see what you're saying. > > > Wanting a persistent namespace contradicts 1). > > > > Not necessarily, see above. > > > > > Wanting a per-user (as opposed to per-session) namespace contradicts > > > 2). The namespace _has_ to be accessible from outside, so that a new > > > session can access/copy it. > > > > Again, I *think* you are wrong that private namespace contradicts this > > requirement. > > I'm not saying there's any contradiction, I'm saying rbind+chroot is a > better fit. Ok, I see. > I haven't yet heard a single reason why a per-session namespace with > parts shared per-user is better than just a per-user namespace. In fact I suspect we could show that they are functionally equivalent (for your purposes) by drawing the fs tree and peer groups from current->fs->root on up for both methods. And not using private namespaces leaves the admin (at least for now) better able to diagnose the state of the system. -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance Stats: Kernel patch
On Sun 2007-04-15 03:21:57, William Lee Irwin III wrote: >> nvcsw and nivcsw are conventional variable names for these quantities. On Sun, Apr 15, 2007 at 08:10:24PM +, Pavel Machek wrote: > I can't decipher them and would not want users see them in /proc. > Would nonvoluntary_ctxt_switch be that much worse? I'm not too attached to a particular name. I just think that the traditional counter names should pass readability/etc. criteria on account of the very strong historical precedent. I'd consider more verbose affairs for the sake of putative legibility as equivalent in quality. Maybe that means others voting for the more verbose names should result in an aggregate decision in favor of verbosity. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/2] 2.6.21-rc7: known regressions
On Mon, Apr 16, 2007 at 02:37:23AM +0200, Adrian Bunk wrote: > Subject: ThinkPad X60: resume no longer works (PCI related?) > workaround: booting with "hpet=disable" > References : http://lkml.org/lkml/2007/3/13/3 > Submitter : Dave Jones <[EMAIL PROTECTED]> > Jeremy Fitzhardinge <[EMAIL PROTECTED]> > Caused-By : PCI merge > commit 78149df6d565c36675463352d0bfeb02b7a7 > Handled-By : Eric W. Biederman <[EMAIL PROTECTED]> > Rafael J. Wysocki <[EMAIL PROTECTED]> > Status : unknown note that this workaround doesn't seem to work in all cases. Mine may a slightly different model (I have the tablet version) but disabling hpet shows the same regression. I've been fighting Eric's USB debug cable code in the hope of getting _something_ useful out of it other than a black screen, but I've been getting nowhere with it. 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: [PATCH 3/7] [RFC] Battery monitoring class
On Mon, 16 Apr 2007, Anton Vorontsov wrote: > Current battery class assumes values are not averaged. I.e. momentary > values. In general, it's userspace' job to collect statistics. Though, > if hardware can report only average values, it's just okay to use > usual attributes. What about SBS-style battery firmware, which can report *both* ? This includes just about all ThinkPads in the last five years, so we are talking about a damn big lot of machines... I'd really appreciate if there is a standard way to communicate both. And it is probably a good idea to define what should be averaged, and what should be instantaneous when that matters, that way userspace actually has a chance at not doing something braindamaged. Actually, IMHO, every attribute and alarm from SBS should be somehow losslessly translatable to standard class attributes from day one, unless it is something that makes no sense at all (and there is precious little of that in the latest version of SBS, thankfully...). > Also, if you your battery can collect and report its approximated values > in additional to momentary values, you're free to add _AVG attributes > to standard ones and use them. No, that won't help much. IMO, we want the sanest set of standard attributes we can get, and weird as it might be, average reporting are common properties of battery control firmware on laptops (maybe because of SBS, but still...). We don't have to get it perfect at the first try, but I really think we are getting a bit too far from "as good as we can make it" at the first attempt if we don't take the SBS into account properly, given the ammount of circuits and firmware out there that are shaped along the SBS guidelines. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?
On Sunday 15 April 2007 14:59, Luca Tettamanti wrote: > On 4/15/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote: > > But I missed the details, such as the specific devices in question, > > which ports they use, how they are described in ACPI, which AML > > methods use those ports, and which non-ACPI drivers also use them. > > The original report was about the temperature sensors of K8 cpus. It > happens that ACPI reads the sensors while the linux driver is using it > and gets garbage (and shut down the system). The problem is more > generic though, and applies to all hardware monitoring chips for which > a driver exists. Yes, I saw that much, but that's not enough detail to craft a good solution. In the case of k8temp, the driver claims PCI devices with a certain vendor and device ID. PCI devices are mostly outside the scope of ACPI. There's a standard enumeration protocol, and a driver should be able to claim any device it recognizes without fear of conflict. I claim that an AML method that accesses a PCI device is defective because the AML can't know whether a native driver has claimed the device. Sometimes the firmware can hide PCI devices so the OS enumeration doesn't find them. In that case, AML might be able to safely use the PCI device, but the native driver wouldn't be able to claim the device, so there would be no conflict. (Linux sometimes uses quirks to "unhide" things like this, which could lead to a conflict of our own making.) I suspect that other sensor drivers may just probe for devices at "known" addresses hard-coded in the driver. This is a problem because the ACPI model is that the OS learns about all built-in devices via the ACPI namespace. If it isn't in the namespace, it shouldn't exist as far as the OS is concerned. So we could easily have the situation where ACPI uses a sensor and does not expose it to the OS in the namespace. In that case, the firmware expectation is that the OS won't touch the device. If the OS pokes around at the magic addresses and happens to trip over the device, we just made ourselves a problem. > > It also sounds like the non-ACPI drivers provide much more > > functionality than ACPI exposes. I'd like to understand this, > > too, because an obvious way to solve the problem would be to > > drop the non-ACPI drivers. > > Problem is that ACPI may access the sensors anyway (e.g. via SMM). If ACPI accesses sensors but there is no native driver, there should be no conflict. > > Is this extra functionality available > > on Windows? If so, do we know whether Windows uses non-ACPI drivers > > or whether they have some smarter way to use ACPI? > > Usually ACPI exposes 1 or 2 temperature readings (CPU and > motherboard), while the hw driver can also provide fans and voltages > measurements. > > Vendors usually provides a monitoring utility for Win that also > exposes these information. It's not known whether there's a way to > avoid conflicting accesses between ACPI and the raw driver; it's > possible that it's vendor-specific and not documented. I'd be surprised if Windows provided interfaces to coordinate between two drivers. My impression is that they really want to have a single owner for a piece of hardware. It would be interesting to figure out how these monitoring utilities work. Maybe the monitor and the AML both go through an embedded controller driver and coordinate that way? Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZFS with Linux: An Open Plea
David R. Litwin wrote: 4: ZFS has a HUGE capacity. I don't have 30 exobytes, but I might some day ext4 will probably cope with that. XFS definitely has very high limits though I admit I don't know what they are. XFS is also a few exobytes. The fsck for none of these filesystems will be able to deal with a filesystem that big. Unless, of course, you have a few weeks to wait for fsck to complete. Backup and restore are similar problems. When part of the filesystem is lost, you don't want to have to wait for a full restore. Sounds simple? Well, the hard part is figuring out exactly which part of the filesystem you need to restore... I don't see ZFS, ext4 or XFS addressing these issues. IMHO chunkfs could provide a much more promising approach. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[1/2] 2.6.21-rc7: known regressions
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: snd_hda_intel doesn't work with ASUS M2V mainboard References : http://bugzilla.kernel.org/show_bug.cgi?id=8273 Submitter : Hans-Georg Rist <[EMAIL PROTECTED]> Status : unknown Subject: snd_intel8x0: divide error: References : http://lkml.org/lkml/2007/3/5/252 Submitter : Michal Piotrowski <[EMAIL PROTECTED]> Status : unknown Subject: ali_pata: boot from CD fails References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark <[EMAIL PROTECTED]> Status : unknown Subject: kernels fail to boot with drives on ATIIXP controller (ACPI/IRQ related) References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 http://lkml.org/lkml/2007/3/4/257 Submitter : Michal Jaegermann <[EMAIL PROTECTED]> Status : unknown Subject: boot failure: rtl8139: exception in interrupt routine References : http://lkml.org/lkml/2007/3/31/160 Submitter : Stephen Clark <[EMAIL PROTECTED]> Status : unknown Subject: laptops with e1000: lockups References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 Submitter : Dave Jones <[EMAIL PROTECTED]> Handled-By : Jesse Brandeburg <[EMAIL PROTECTED]> Status : problem is being debugged Subject: forcedeth: interface hangs under load References : http://lkml.org/lkml/2007/4/3/39 http://www.spinics.net/lists/netdev/msg28981.html Submitter : Ingo Molnar <[EMAIL PROTECTED]> Handled-By : Ingo Molnar <[EMAIL PROTECTED]> Ayaz Abdulla <[EMAIL PROTECTED]> David Miller <[EMAIL PROTECTED]> Status : problem is being debugged Subject: hal daemon crashes after pulling a USB serial device References : http://www.opensubscriber.com/message/[EMAIL PROTECTED]/6369800.html Submitter : Andi Kleen <[EMAIL PROTECTED]> Handled-By : Oliver Neukum <[EMAIL PROTECTED]> Status : problem is being debugged Subject: Oops when changing USB DVB-T adapter References : http://lkml.org/lkml/2007/3/9/212 http://lkml.org/lkml/2007/4/5/154 Submitter : CIJOML <[EMAIL PROTECTED]> Handled-By : Markus Rechberger <[EMAIL PROTECTED]> Status : patches available - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2/2] 2.6.21-rc7: known regressions
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: suspend to disk hangs (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/3/25/217 Submitter : Jeff Chua <[EMAIL PROTECTED]> Status : unknown Subject: ThinkPad X60: resume no longer works (PCI related?) workaround: booting with "hpet=disable" References : http://lkml.org/lkml/2007/3/13/3 Submitter : Dave Jones <[EMAIL PROTECTED]> Jeremy Fitzhardinge <[EMAIL PROTECTED]> Caused-By : PCI merge commit 78149df6d565c36675463352d0bfeb02b7a7 Handled-By : Eric W. Biederman <[EMAIL PROTECTED]> Rafael J. Wysocki <[EMAIL PROTECTED]> Status : unknown Subject: suspend to disk works only once References : http://lkml.org/lkml/2007/4/13/240 Submitter : Tobias Diedrich <[EMAIL PROTECTED]> Caused-By : Rafael J. Wysocki <[EMAIL PROTECTED]> commit ed746e3b18f4df18afa3763155972c5835f284c5 Handled-By : Rafael J. Wysocki <[EMAIL PROTECTED]> Dmitry Torokhov <[EMAIL PROTECTED]> David Brownell <[EMAIL PROTECTED]> Status : problem is being debugged Subject: resume from RAM corrupts vesafb console References : http://lkml.org/lkml/2007/3/26/76 http://lkml.org/lkml/2007/4/13/313 Submitter : Marcus Better <[EMAIL PROTECTED]> Handled-By : Pavel Machek <[EMAIL PROTECTED]> Antonino A. Daplas <[EMAIL PROTECTED]> Status : problem is being debugged - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] MTD driver for MMC cards
On Mon, 16 April 2007 01:33:17 +0200, Arnd Bergmann wrote: > > There is also still some need for performance testing. Jörn > brought up the point that if a specific card can't have multiple > open erase block simulateously, it's rather pointless for > logfs. It might still be useful to use jffs2 on those cards, > because IFAIK that only writes to one erase block at any > time. This appears to be a problem for practically all consumer-available flash media. They spend a lot of effort trying to hide any flash properties from their users. And while this is a decent strategy for FAT, ext3, ntfs and similar, it is actually very inefficient for a flash filesystem. After talking to several manufacturers, most seemed to be fairly open-minded towards supporting an alternate interface with raw flash access. So much for the good news. Bad news is that such an elternate interface still needs to be defined. Jörn -- Courage is not the absence of fear, but rather the judgement that something else is more important than fear. -- Ambrose Redmoon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Sunday 15 April 2007, Mike Galbraith wrote: >On Sun, 2007-04-15 at 12:58 -0400, Gene Heskett wrote: >> Chuckle, possibly but then I'm not anything even remotely close to an >> expert here Con, just reporting what I get. And I just rebooted to >> 2.6.21-rc6 + sched-mike-5.patch for grins and giggles, or frowns and >> profanity as the case may call for. > >Erm, that patch is embarrassingly buggy, so profanity should dominate. > > -Mike Chuckle, ROTFLMAO even. I didn't run it that long as I immediately rebuilt and rebooted when I found I'd used the wrong patch, and in fact had tested that one and found it sub-optimal before I'd built and ran Con's -0.40 version. As for bugs of the type that make it to the screen or logs, I didn't see any. OTOH, my eyesight is slowly going downhill, now 20/25. It was 20/10 30 years ago. Now thats reason for profanity... -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Unix weanies are as bad at this as anyone. -- Larry Wall 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/
Linux 2.6.21-rc7
Since we're still waiting for resolution for some regressions that people weren't able to work on last week, there's a new -rc kernel out there. Hopefully we'll get them all and I can do 2.6.21-final next weekend or so.. The changes from 2.6.21-rc6 are pretty small, and I'm including both the shortlog and the diffstat here since they both fit comfortably under the kernel mailing list size limits even when combined. I really don't know what to say that would be more readable and informative than the shortlog. The HPET failsafe thing will hopefully resolve a few more bootup/resume issues. Mostly driver fixes, some networking and NFS. Go wild! Linus --- Adam Kropelin (1): HID: Do not discard truncated input reports Alan Stern (1): EHCI: fix remote wakeup regression in 2.6.21-rc Andrew Morton (3): x86_64 early quirks: fix early_qrk[] section tag i386: irqbalance_disable() section fix [PKTGEN]: Add try_to_freeze() Bjorn Helgaas (1): cciss: unregister from SCSI before tearing down device resources Brice Goglin (3): myri10ge: fix management of the firmware 4KB boundary crossing restriction myri10ge: more Intel chipsets providing aligned PCIe completions myri10ge: update driver version to 1.3.0-1.233 Cliff Brake (1): Input: ucb1400 - set up driver's name to show in sysfs Daniel Drake (2): zd1211rw: Reject AL2230S devices zd1211rw: Fix E2P_PHY_REG patching Danny Kukawka (1): ide: add "optical" to sysfs "media" attribute David Brownell (2): omap_cf: oops-on-suspend fix doc: gpio.txt describes open-drain emulation David Howells (1): FRV: Update the FRV arch MAINTAINER record to get a hit on "grep -i frv" David S. Miller (7): [IPV6]: Revert recent change to rt6_check_dev(). [TCP]: slow_start_after_idle should influence cwnd validation too [SPARC64]: Fix SBUS IOMMU allocation code. [SUNRPC]: Make sure on-stack cmsg buffer is properly aligned. [SPARC64]: Fix arg passing to compat_sys_ipc(). [NETFILTER] arp_tables: Fix unaligned accesses. [SCSI] QLOGICPTI: Do not unmap DMA unless we actually mapped something. Divy Le Ray (3): cxgb3 - avoid deadlock with mac watchdog cxgb3 - MAC watchdog update cxgb3 - missing CPL hanler and register setting. Dmitry Torokhov (1): PM: use kobject_name() to access kobject names Domen Puncer (1): [POWERPC] mpc52xx_pic: fix main interrupt masking Emil Larsson (1): USB: Nikon D80 unusual device patch Erez Zilber (1): IB/iser: Don't defer connection failure notification to workqueue Herbert Xu (1): [SC92031]: Fix priv->lock context Ingo Molnar (2): high-res timers: resume fix sched: get rid of p->children use in show_task() Ishimatsu Yasuaki (1): [IA64] Fix wrong assumption about irq and vector in msi_ia64.c James Bottomley (1): [SCSI] 3w-: fix oops caused by incorrect REQUEST_SENSE handling Jaroslav Kysela (1): [NETFILTER]: ipt_CLUSTERIP: fix oops in checkentry function Jeff Mahoney (1): autofs4: fix race in unhashed dentry code Jerome Borsboom (1): [VLAN]: Allow VLAN interface on top of bridge interface Joy Latten (1): [IPSEC] XFRM_USER: kernel panic when large security contexts in ACQUIRE Larry Finger (2): bcm43xx: Fix 802.11b/g scan limits to match regulatory reqs bcm43xx: Fix PPC machine checks and match loopback gain specs Linus Torvalds (2): sched.c: Remove unused variable 'relative' Linux 2.6.21-rc7 Michael Chan (1): [TG3]: Fix crash during tg3_init_one(). Michael S. Tsirkin (1): IPoIB/cm: Fix DMA direction typo Mike Habeck (1): [IA64] SGI Altix : fix pcibr_dmamap_ate32() bug Neil Brown (1): md: fix calculation for size of filemap_attr array in md/bitmap Olaf Kirch (1): DVB: dvb-usb-remote - fix oops when changing keymap Patrick McHardy (6): [XFRM]: beet: fix IP option encapsulation [XFRM]: beet: use IPOPT_NOP for option padding [XFRM]: beet: fix beet mode decapsulation [XFRM]: beet: fix IP option decapsulation [NET_SCHED]: cls_tcindex: fix compatibility breakage [NETFILTER]: ipt_ULOG: use put_unaligned Randy Dunlap (1): fix kernel oops with badly formatted module option Ravikiran G Thirumalai (1): failsafe mechanism to HPET clock calibration Robert Reif (1): [SPARC]: Fix section mismatch warnings in pci.c and pcic.c Roland McGrath (1): [SPARC]: avoid CHILD_MAX and OPEN_MAX constants Russ Anderson (1): [IA64] BTE error timer fix Stefan Richter (1): ieee1394: change deprecation status of dv1394 Stephen Hemminger (5): skge: turn carrier off when down sky2: turn carrier off when down sky2: turn on clocks when doing resume sky2: phy workarounds for Yukon EC-U A1 skge: fix wake on lan Steve Wise (1): RDMA/cxgb3: Add
Re: [OOPS] 2.6.21-rc6-git5 in cfq_dispatch_insert
[ Cc's added, additional information is in http://lkml.org/lkml/2007/4/15/32 ] On Sun, Apr 15, 2007 at 02:49:29PM +0400, Brad Campbell wrote: > Brad Campbell wrote: > >G'day all, > > > >All I have is a digital photo of this oops. (It's 3.5mb). I have serial > >console configured, but Murphy is watching me carefully and I just can't > >seem to reproduce it while logging the console output. > > > > And as usual, after trying to capture one for 4 days, I get one 10 mins > after I've sent the E-mail :) > > I think I've just found a way to make this easier to reproduce as /dev/sdd > was not even mounted this > time. I just cold booted and started an md5sum -c run on a directory of > about 180GB. Is this also present with kernel 2.6.20 or is it a regression? > [ 2566.192665] BUG: unable to handle kernel NULL pointer dereference at > virtual address 005c > [ 2566.218242] printing eip: > [ 2566.226362] c0203169 > [ 2566.232906] *pde = > [ 2566.241274] Oops: [#1] > [ 2566.249637] Modules linked in: > [ 2566.258832] CPU:0 > [ 2566.258833] EIP:0060:[]Not tainted VLI > [ 2566.258834] EFLAGS: 00010082 (2.6.21-rc6-git5 #1) > [ 2566.296146] EIP is at cfq_dispatch_insert+0x19/0x70 > [ 2566.310761] eax: f7a0eae0 ebx: f7a0cb28 ecx: e2f869e8 edx: > [ 2566.331076] esi: f79fea7c edi: f7d04ac0 ebp: esp: f6945de0 > [ 2566.351388] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > [ 2566.368843] Process md5sum (pid: 2875, ti=f6944000 task=f68f4ad0 > task.ti=f6944000) > [ 2566.390975] Stack: f79fea7c f7d04ac0 c02032d9 f6ae5ef0 > c0133411 1000 > [ 2566.416414]0008 0004 0b582fd4 f79fea7c f7d04ac0 > f79fea7c > [ 2566.441870]c0203519 f7a0cb28 f7a0cb28 f79e 0282 c01fb7a9 > c016ea4d > [ 2566.467326] Call Trace: > [ 2566.475236] [] __cfq_dispatch_requests+0x79/0x170 > [ 2566.492224] [] do_generic_mapping_read+0x281/0x470 > [ 2566.509473] [] cfq_dispatch_requests+0x69/0x90 > [ 2566.525681] [] elv_next_request+0x39/0x130 > [ 2566.540850] [] bio_endio+0x5d/0x90 > [ 2566.553942] [] scsi_request_fn+0x45/0x280 > [ 2566.568851] [] blk_run_queue+0x32/0x70 > [ 2566.582982] [] scsi_next_command+0x30/0x50 > [ 2566.598154] [] scsi_end_request+0x9b/0xc0 > [ 2566.613063] [] scsi_io_completion+0x81/0x330 > [ 2566.628751] [] scsi_delete_timer+0xb/0x20 > [ 2566.643661] [] ata_scsi_qc_complete+0x65/0xd0 > [ 2566.659613] [] sd_rw_intr+0x8b/0x220 > [ 2566.673222] [] ata_altstatus+0x1c/0x20 > [ 2566.687352] [] ata_hsm_move+0x14d/0x3f0 > [ 2566.701744] [] scsi_finish_command+0x40/0x60 > [ 2566.717434] [] scsi_softirq_done+0x6f/0xe0 > [ 2566.732604] [] sil_interrupt+0x81/0x90 > [ 2566.746733] [] blk_done_softirq+0x58/0x70 > [ 2566.761644] [] __do_softirq+0x6f/0x80 > [ 2566.775516] [] do_softirq+0x27/0x30 > [ 2566.788866] [] do_IRQ+0x3e/0x80 > [ 2566.801177] [] common_interrupt+0x23/0x28 > [ 2566.816090] === > [ 2566.826793] Code: 3e 05 f0 ff e9 47 ff ff ff 89 f6 8d bc 27 00 00 00 00 > 83 ec 10 89 1c 24 89 6c > 24 0c 89 74 24 04 89 7c 24 08 89 c3 89 d5 8b 40 0c <8b> 72 5c 8b 78 04 89 > d0 e8 4a fa ff ff 8b 45 14 > 89 ea 25 01 80 > [ 2566.886586] EIP: [] cfq_dispatch_insert+0x19/0x70 SS:ESP > 0068:f6945de0 > [ 2566.909179] Kernel panic - not syncing: Fatal exception in interrupt 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: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
* William Lee Irwin III <[EMAIL PROTECTED]> wrote: >> I've been suggesting testing CPU bandwidth allocation as influenced by >> nice numbers for a while now for a reason. On Sun, Apr 15, 2007 at 09:57:48PM +0200, Ingo Molnar wrote: > Oh I was very much testing "CPU bandwidth allocation as influenced by > nice numbers" - it's one of the basic things i do when modifying the > scheduler. An automated tool, while nice (all automation is nice) > wouldnt necessarily show such bugs though, because here too it needed > thousands of running tasks to trigger in practice. Any volunteers? ;) Worse comes to worse I might actually get around to doing it myself. Any more detailed descriptions of the test for a rainy day? -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Sunday 15 April 2007 00:38, Davide Libenzi wrote: > Haven't looked at the scheduler code yet, but for a similar problem I use > a time ring. The ring has Ns (2 power is better) slots (where tasks are > queued - in my case they were som sort of timers), and it has a current > base index (Ib), a current base time (Tb) and a time granularity (Tg). It > also has a bitmap with bits telling you which slots contains queued tasks. > An item (task) that has to be scheduled at time T, will be queued in the > slot: > > S = Ib + min((T - Tb) / Tg, Ns - 1); > > Items with T longer than Ns*Tg will be scheduled in the relative last slot > (chosing a proper Ns and Tg can minimize this). > Queueing is O(1) and de-queueing is O(Ns). You can play with Ns and Tg to > suite to your needs. > This is a simple bench between time-ring (TR) and CFS queueing: > > http://www.xmailserver.org/smart-queue.c > > In my box (Dual Opteron 252): > > [EMAIL PROTECTED]:~$ ./smart-queue -n 8 > CFS = 142.21 cycles/loop > TR = 72.33 cycles/loop > [EMAIL PROTECTED]:~$ ./smart-queue -n 16 > CFS = 188.74 cycles/loop > TR = 83.79 cycles/loop > [EMAIL PROTECTED]:~$ ./smart-queue -n 32 > CFS = 221.36 cycles/loop > TR = 75.93 cycles/loop > [EMAIL PROTECTED]:~$ ./smart-queue -n 64 > CFS = 242.89 cycles/loop > TR = 81.29 cycles/loop Hello all, I cannot help myself to not report results with GAVL tree algorithm there as an another race competitor. I believe, that it is better solution for large priority queues than RB-tree and even heap trees. It could be disputable if the scheduler needs such scalability on the other hand. The AVL heritage guarantees lower height which results in shorter search times which could be profitable for other uses in kernel. GAVL algorithm is AVL tree based, so it does not suffer from "infinite" priorities granularity there as TR does. It allows use for generalized case where tree is not fully balanced. This allows to cut the first item withour rebalancing. This leads to the degradation of the tree by one more level (than non degraded AVL gives) in maximum, which is still considerably better than RB-trees maximum. http://cmp.felk.cvut.cz/~pisa/linux/smart-queue-v-gavl.c The description behind the code is there http://cmp.felk.cvut.cz/~pisa/ulan/gavl.pdf The code is part of much more covering uLUt library http://cmp.felk.cvut.cz/~pisa/ulan/ulut.pdf http://sourceforge.net/project/showfiles.php?group_id=118937_id=130840 I have included all required GAVL code directly into smart-queue-v-gavl.c to provide it for easy testing. There are tests run on my little dated computer - Duron 600 MHz. Test are run twice to suppress run order influence. ./smart-queue-v-gavl -n 1 -l 200 gavl_cfs = 55.66 cycles/loop CFS = 88.33 cycles/loop TR = 141.78 cycles/loop CFS = 90.45 cycles/loop gavl_cfs = 55.38 cycles/loop ./smart-queue-v-gavl -n 2 -l 200 gavl_cfs = 82.85 cycles/loop CFS = 104.18 cycles/loop TR = 145.21 cycles/loop CFS = 102.74 cycles/loop gavl_cfs = 82.05 cycles/loop ./smart-queue-v-gavl -n 4 -l 200 gavl_cfs = 137.45 cycles/loop CFS = 156.47 cycles/loop TR = 142.00 cycles/loop CFS = 152.65 cycles/loop gavl_cfs = 139.38 cycles/loop ./smart-queue-v-gavl -n 10 -l 200 gavl_cfs = 229.22 cycles/loop (WORSE) CFS = 206.26 cycles/loop TR = 140.81 cycles/loop CFS = 208.29 cycles/loop gavl_cfs = 223.62 cycles/loop (WORSE) ./smart-queue-v-gavl -n 100 -l 200 gavl_cfs = 257.66 cycles/loop CFS = 329.68 cycles/loop TR = 142.20 cycles/loop CFS = 319.34 cycles/loop gavl_cfs = 260.02 cycles/loop ./smart-queue-v-gavl -n 1000 -l 200 gavl_cfs = 258.41 cycles/loop CFS = 393.04 cycles/loop TR = 134.76 cycles/loop CFS = 392.20 cycles/loop gavl_cfs = 260.93 cycles/loop ./smart-queue-v-gavl -n 1 -l 200 gavl_cfs = 259.45 cycles/loop CFS = 605.89 cycles/loop TR = 196.69 cycles/loop CFS = 622.60 cycles/loop gavl_cfs = 262.72 cycles/loop ./smart-queue-v-gavl -n 10 -l 200 gavl_cfs = 258.21 cycles/loop CFS = 845.62 cycles/loop TR = 315.37 cycles/loop CFS = 860.21 cycles/loop gavl_cfs = 258.94 cycles/loop The GAVL code has not been tuned by any "likely"/"unlikely" constructs. It brings even some other overhead from it generic design which is not necessary for this use - it keeps permanently even pointer to the last element, ensures, that the insertion order is preserved for same key values etc. But it still proves much better scalability then kernel used RB-tree code. On the other hand, it does not encode color/height in one of the pointers and requires additional field for height. May it be, that difference is due some bug in my testing, then I would be interrested in correction. The test case is oversimplified probably. I have already run more different tests against GAVL code in the past to compare it with different tree and queues implementations and I have not found case with real performance degradation. On the other hand, there are cases for small items counts where GAVL
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Sun, Apr 15, 2007 at 10:48:24PM +0200, Ingo Molnar wrote: > 2) plugsched did not allow on the fly selection of schedulers, nor did >it allow a per CPU selection of schedulers. IO schedulers you can >change per disk, on the fly, making them much more useful in >practice. Also, IO schedulers (while definitely not being slow!) are >alot less performance sensitive than CPU schedulers. One of the reasons I never posted my own code is that it never met its own design goals, which absolutely included switching on the fly. I think Peter Williams may have done something about that. It was my hope to be able to do insmod sched_foo.ko until it became clear that the effort it was intended to assist wasn't going to get even the limited hardware access required, at which point I largely stopped working on it. On Sun, Apr 15, 2007 at 10:48:24PM +0200, Ingo Molnar wrote: > 3) I/O schedulers are pretty damn clean code, and plugsched, at least >the last version i saw of it, didnt come even close. I'm not sure what happened there. It wasn't a big enough patch to take hits in this area due to getting overwhelmed by the programming burden like some other efforts of mine. Maybe things started getting ugly once on-the-fly switching entered the picture. My guess is that Peter Williams will have to chime in here, since things have diverged enough from my one-time contribution 4 years ago. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] MTD driver for MMC cards
This is a new version of the driver I posted back in January. I now
have hardware to test it and fixed a number of bugs, most of which
are the ones that Pierre told me about in the first place.
It now seems to work fine with the mtdblock driver, which of course
it entirely pointless.
I've tried using it with jffs2 once, but get an immediate oops,
which still needs some investigation.
I'm also not sure what to do about SDHC media, but probably the
easiest solutions is to disallow them with this driver -- the
mtd layer doesn't deal with media larger than 4GB anyway at
this point.
There is also still some need for performance testing. Jörn
brought up the point that if a specific card can't have multiple
open erase block simulateously, it's rather pointless for
logfs. It might still be useful to use jffs2 on those cards,
because IFAIK that only writes to one erase block at any
time.
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
Index: olpc-2.6/drivers/mmc/mmc.c
===
--- olpc-2.6.orig/drivers/mmc/mmc.c
+++ olpc-2.6/drivers/mmc/mmc.c
@@ -621,6 +621,7 @@ static void mmc_decode_csd(struct mmc_ca
csd->r2w_factor = UNSTUFF_BITS(resp, 26, 3);
csd->write_blkbits = UNSTUFF_BITS(resp, 22, 4);
csd->write_partial = UNSTUFF_BITS(resp, 21, 1);
+ csd->erase_blksize = UNSTUFF_BITS(resp, 39, 7);
break;
case 1:
/*
@@ -649,6 +650,8 @@ static void mmc_decode_csd(struct mmc_ca
csd->r2w_factor = 4; /* Unused */
csd->write_blkbits = 9;
csd->write_partial = 0;
+#warning need to read au_size for sdhc
+ csd->erase_blksize = 0; // 8192 << au_size;
break;
default:
printk("%s: unrecognised CSD structure version %d\n",
@@ -691,6 +694,8 @@ static void mmc_decode_csd(struct mmc_ca
csd->r2w_factor = UNSTUFF_BITS(resp, 26, 3);
csd->write_blkbits = UNSTUFF_BITS(resp, 22, 4);
csd->write_partial = UNSTUFF_BITS(resp, 21, 1);
+ csd->erase_blksize = (UNSTUFF_BITS(resp, 37, 5) + 1) *
+ (UNSTUFF_BITS(resp, 42, 5) + 1);
}
}
Index: olpc-2.6/include/linux/mmc/card.h
===
--- olpc-2.6.orig/include/linux/mmc/card.h
+++ olpc-2.6/include/linux/mmc/card.h
@@ -32,6 +32,7 @@ struct mmc_csd {
unsigned intmax_dtr;
unsigned intread_blkbits;
unsigned intwrite_blkbits;
+ unsigned interase_blksize;
unsigned intcapacity;
unsigned intread_partial:1,
read_misalign:1,
Index: olpc-2.6/drivers/mmc/mmc_mtd.c
===
--- /dev/null
+++ olpc-2.6/drivers/mmc/mmc_mtd.c
@@ -0,0 +1,366 @@
+/*
+ * MTD driver for MMC cards
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * check if a write command was completed correctly, must be called
+ * with host claimed.
+ */
+static int mmc_mtd_get_status(struct mmc_card *card)
+{
+ int err;
+ struct mmc_command cmd;
+
+ do {
+ cmd = (struct mmc_command) {
+ .opcode = MMC_SEND_STATUS,
+ .arg = card->rca << 16,
+ .flags = MMC_RSP_R1 | MMC_CMD_AC,
+ };
+
+ err = mmc_wait_for_cmd(card->host, , 5);
+ if (err) {
+ dev_err(>dev, "error %d requesting status\n",
err);
+ break;
+ }
+ } while (!(cmd.resp[0] & R1_READY_FOR_DATA));
+
+ return err;
+}
+
+/*
+ * erase a range of erase groups aligned to mtd->erase_size
+ */
+static int mmc_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
+{
+ struct mmc_card *card = mtd->priv;
+ struct mmc_command cmd[3] = { {
+ .opcode = MMC_ERASE_GROUP_START,
+ .arg = instr->addr,
+ .flags = MMC_RSP_R1 | MMC_CMD_AC,
+ }, {
+ .opcode = MMC_ERASE_GROUP_END,
+ .arg = instr->addr + instr->len,
+ .flags = MMC_RSP_R1 | MMC_CMD_AC,
+ }, {
+ .opcode = MMC_ERASE,
+ .flags = MMC_RSP_R1B | MMC_CMD_AC,
+ },
+ };
+ int err, i;
+
+ dev_dbg(>dev, "%s: from %d len %d\n", __FUNCTION__,
+ instr->addr, instr->len);
+
+ instr->state = MTD_ERASING;
+ err = 0;
+ err = mmc_card_claim_host(card);
+ if (err)
+ goto error;
+
+
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Monday 16 April 2007 02:23:08 Arjan van de Ven wrote: > On Mon, 2007-04-16 at 01:49 +0300, Ismail Dönmez wrote: > > Hi, > > > > On Friday 13 April 2007 23:21:00 Ingo Molnar wrote: > > > [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler > > > [CFS] > > > > > > i'm pleased to announce the first release of the "Modular Scheduler > > > Core and Completely Fair Scheduler [CFS]" patchset: > > > > > >http://redhat.com/~mingo/cfs-scheduler/sched-modular+cfs.patch > > > > Tested this on top of Linus' GIT tree but the system gets very > > unresponsive during high disk i/o using ext3 as filesystem but even > > writing a 300mb file to a usb disk (iPod actually) has the same affect. > > just to make sure; this exact same workload but with the stock scheduler > does not have this effect? > > if so, then it could well be that the scheduler is too fair for it's own > good (being really fair inevitably ends up not batching as much as one > should, and batching is needed to get any kind of decent performance out > of disks nowadays) Tried with make install in kdepim (which made system sluggish with CFS) and the system is just fine (using CFQ). Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Mon, 2007-04-16 at 01:49 +0300, Ismail Dönmez wrote: > Hi, > On Friday 13 April 2007 23:21:00 Ingo Molnar wrote: > > [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler > > [CFS] > > > > i'm pleased to announce the first release of the "Modular Scheduler Core > > and Completely Fair Scheduler [CFS]" patchset: > > > >http://redhat.com/~mingo/cfs-scheduler/sched-modular+cfs.patch > > Tested this on top of Linus' GIT tree but the system gets very unresponsive > during high disk i/o using ext3 as filesystem but even writing a 300mb file > to a usb disk (iPod actually) has the same affect. just to make sure; this exact same workload but with the stock scheduler does not have this effect? if so, then it could well be that the scheduler is too fair for it's own good (being really fair inevitably ends up not batching as much as one should, and batching is needed to get any kind of decent performance out of disks nowadays) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
The error also happens in 2.6.19, same as in 2.6.18. I extracted this from syslog: Apr 17 00:14:08 kdev kernel: loop: loaded (max 8 devices) Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): ufs_check_page: bad entry in directory #2: directory entry across blocks - offset=356, rec_len=668, name_len=19 Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): ufs_readdir: bad page in #2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3/3] 2.6.21-rc6: known regressions
On Sun, 2007-04-15 at 18:26 +0200, Marcus Better wrote: > Antonino A. Daplas wrote: > > A screen with blinking green blocks implies that your display is in text > > mode, not in graphics mode. > > Yes, it happens when I suspend from text mode. Just for clarification, do you suspend from VESA framebuffer console or from VGA text console? If from the latter, that's actually worse from the user's point of view, but I can modify vgacon so that it saves its state on suspend and restore it on resume. > > If the above does not work, also try > > > > acpi_sleep=s3_bios,s3_mode > > Will try, but I'm using "s2ram -f -a3" which should mean precisely the above > IIUC. Okay. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] [RFC] Battery monitoring class
Hi, On Mon, Apr 16, 2007 at 12:08:54AM +0200, Ondrej Zajicek wrote: > On Thu, Apr 12, 2007 at 03:25:03AM +0400, Anton Vorontsov wrote: > > Here is battery monitor class. According to first copyright string, we're > > maintaining it since 2003. I've took few days and cleaned it up to be > > more suitable for mainline inclusion. > > Just some ideas: > > - what about using exponents in values? > For example file "voltage" could contain "123 -3" to represent 123 mV. > Exponents could be hardcoded in drivers according to device's range > (so there is no complication in it), but interface is usable in great > range of values. And it is pretty easy to use from userspace. No, sorry. Common units is main goal of that class. If you're saying "energy" you always know that it's uWh. It's better for both userspace (don't bother to parse anything from kernel) and kernel itself. No need to invent new kernel<->userspace protocols, no need to do useless string manipulations in kernel itself. > - interface should allow to present values which are some monotonic > functions of common physical properties. For example when we know > where are some raw data from sensor, but we don't know where are > calibration tables to be able to compute value in some standard unit > (as V for voltage) - in this case it is better to show raw data > (or raw data after some transformation which makes them monotonic) > and specify that this is raw data than show nothing. > > - it would be nice to know whether presented value is from some > measurement or it is (inaccurate) estimation. Current battery class assumes values are not averaged. I.e. momentary values. In general, it's userspace' job to collect statistics. Though, if hardware can report only average values, it's just okay to use usual attributes. Also, if you your battery can collect and report its approximated values in additional to momentary values, you're free to add _AVG attributes to standard ones and use them. > -- > Elen sila lumenn' omentielvo > > Ondrej 'SanTiago' Zajicek (email: [EMAIL PROTECTED], jabber: [EMAIL > PROTECTED]) > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) > "To err is human -- to blame it on a computer is even more so." Thanks for comments! -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Monday 16 April 2007 05:00, Jonathan Lundell wrote: > On Apr 15, 2007, at 10:59 AM, Linus Torvalds wrote: > > It's a really good thing, and it means that if somebody shows that > > your > > code is flawed in some way (by, for example, making a patch that > > people > > claim gets better behaviour or numbers), any *good* programmer that > > actually cares about his code will obviously suddenly be very > > motivated to > > out-do the out-doer! > > "No one who cannot rejoice in the discovery of his own mistakes > deserves to be called a scholar." Lovely comment. I realise this is not truly directed at me but clearly in the context it has been said people will assume it is directed my way, so while we're all spinning lkml quality rhetoric, let me have a right of reply. One thing I have never tried to do was to ignore bug reports. I'm forever joking that I keep pulling code out of my arse to improve what I've done. RSDL/SD was no exception; heck it had 40 iterations. The reason I could not reply to bug report A with "Oh that is problem B so I'll fix it with code C" was, as I've said many many times over, health related. I did indeed try to fix many of them without spending hours replying to sometimes unpleasant emails. If health wasn't an issue there might have been 1000 iterations of SD. There was only ever _one_ thing that I was absolutely steadfast on as a concept that I refused to fix that people might claim was "a mistake I did not rejoice in to be a scholar". That was that the _correct_ behaviour for a scheduler is to be fair such that proportional slowdown with load is (using that awful pun) a feature, not a bug. Now there are people who will still disagree violently with me on that. SD attempted to be a fairness first virtual-deadline design. If I failed on that front, then so be it (and at least one person certainly has said in lovely warm fuzzy friendly communication that I'm a global failure on all fronts with SD). But let me point out now that Ingo's shiny new scheduler is a fairness-first virtual-deadline design which will have proportional slowdown with load. So it will have a very similar feature. I dare anyone to claim that proportional slowdown with load is a bug, because I will no longer feel like I'm standing alone with a BFG9000 trying to defend my standpoint. Others can take up the post at last. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
Hi, On Friday 13 April 2007 23:21:00 Ingo Molnar wrote: > [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler > [CFS] > > i'm pleased to announce the first release of the "Modular Scheduler Core > and Completely Fair Scheduler [CFS]" patchset: > >http://redhat.com/~mingo/cfs-scheduler/sched-modular+cfs.patch Tested this on top of Linus' GIT tree but the system gets very unresponsive during high disk i/o using ext3 as filesystem but even writing a 300mb file to a usb disk (iPod actually) has the same affect. Regards, ismail signature.asc Description: This is a digitally signed message part.
Re: [PATCH 3/7] [RFC] Battery monitoring class
On Thu, Apr 12, 2007 at 03:25:03AM +0400, Anton Vorontsov wrote: > Here is battery monitor class. According to first copyright string, we're > maintaining it since 2003. I've took few days and cleaned it up to be > more suitable for mainline inclusion. Just some ideas: - what about using exponents in values? For example file "voltage" could contain "123 -3" to represent 123 mV. Exponents could be hardcoded in drivers according to device's range (so there is no complication in it), but interface is usable in great range of values. And it is pretty easy to use from userspace. - interface should allow to present values which are some monotonic functions of common physical properties. For example when we know where are some raw data from sensor, but we don't know where are calibration tables to be able to compute value in some standard unit (as V for voltage) - in this case it is better to show raw data (or raw data after some transformation which makes them monotonic) and specify that this is raw data than show nothing. - it would be nice to know whether presented value is from some measurement or it is (inaccurate) estimation. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: [EMAIL PROTECTED], jabber: [EMAIL PROTECTED]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH][EXPERIMENTAL] CPU hotplug with frozen tasks
Hi, As I said before, we have a problem with using the CPU hotplug for suspending because of the notifiers that are called from within cpu_up()/cpu_down() and (sometimes) assume that the system is fully functional. One obvious solution of this problem would be to make the notifiers behave differently if tasks are frozen, but for this purpose we'd need to tell them that this is the case. In principle, we could do it in many different ways (eg. by using a global variable, with the help of suspend notifiers etc.), but IMO one of the cleanest methods woud be to use some special values for the notifications occuring while tasks are frozen (eg. CPU_DEAD_FROZEN instead of CPU_DEAD etc.). In that case the notifiers could react in some special ways to the "FROZEN" notfifications and that would allow us to simplify some code paths (eg. in the microcode driver). The appended patch introduces such "FROZEN" notfifications, modifies the CPU hotplug core to use them and updates all of the users of CPU hotplug notifiers to recognize them. For now, they are treated in the same way as the corresponding "normal" notifications, but I'm going to modify the microcode driver to really use them and I believe that some other subsystems can benefit from using them as well. The patch is totally experimental and untested, although it's been successfully compiled on x86_64 and it's main purpose is to show what exactly I mean. :-) Comments welcome. Greetings, Rafael --- Documentation/cpu-hotplug.txt |8 ++-- arch/i386/kernel/cpu/intel_cacheinfo.c|2 ++ arch/i386/kernel/cpu/mcheck/therm_throt.c |2 ++ arch/i386/kernel/cpuid.c |2 ++ arch/i386/kernel/microcode.c |3 +++ arch/i386/kernel/msr.c|2 ++ arch/ia64/kernel/palinfo.c|2 ++ arch/ia64/kernel/salinfo.c|2 ++ arch/ia64/kernel/topology.c |2 ++ arch/powerpc/kernel/sysfs.c |2 ++ arch/powerpc/mm/numa.c|3 +++ arch/s390/appldata/appldata_base.c|2 ++ arch/x86_64/kernel/mce.c |2 ++ arch/x86_64/kernel/mce_amd.c |2 ++ arch/x86_64/kernel/vsyscall.c |2 +- block/ll_rw_blk.c |2 +- drivers/base/topology.c |3 +++ drivers/cpufreq/cpufreq.c |3 +++ drivers/cpufreq/cpufreq_stats.c |2 ++ drivers/infiniband/hw/ehca/ehca_irq.c |6 ++ drivers/kvm/kvm_main.c|3 +++ fs/buffer.c |2 +- fs/xfs/xfs_mount.c|3 +++ include/linux/notifier.h |9 + kernel/cpu.c | 26 ++ kernel/hrtimer.c |2 ++ kernel/profile.c |4 kernel/rcupdate.c |2 ++ kernel/relay.c|2 ++ kernel/sched.c| 10 ++ kernel/softirq.c |4 kernel/softlockup.c |4 kernel/timer.c|2 ++ kernel/workqueue.c|6 ++ lib/radix-tree.c |2 +- mm/page_alloc.c |5 - mm/slab.c |6 ++ mm/swap.c |2 +- mm/vmscan.c |2 +- mm/vmstat.c |3 +++ net/core/dev.c|2 +- net/core/flow.c |2 +- net/iucv/iucv.c |6 ++ 43 files changed, 140 insertions(+), 23 deletions(-) Index: linux-2.6.21-rc6/include/linux/notifier.h === --- linux-2.6.21-rc6.orig/include/linux/notifier.h 2007-04-16 00:24:57.0 +0200 +++ linux-2.6.21-rc6/include/linux/notifier.h 2007-04-16 00:25:14.0 +0200 @@ -186,6 +186,15 @@ extern int srcu_notifier_call_chain(stru #define CPU_DOWN_PREPARE 0x0005 /* CPU (unsigned)v going down */ #define CPU_DOWN_FAILED0x0006 /* CPU (unsigned)v NOT going down */ #define CPU_DEAD 0x0007 /* CPU (unsigned)v dead */ +/* The following values are used for CPU hotplug events occuring while tasks are + * frozen (eg. during a suspend) + */ +#define CPU_ONLINE_FROZEN 0x000A /* CPU (unsigned)v is up */ +#define CPU_UP_PREPARE_FROZEN 0x000B /* CPU (unsigned)v coming up */ +#define CPU_UP_CANCELED_FROZEN 0x000C /* CPU (unsigned)v NOT coming up */ +#define CPU_DOWN_PREPARE_FROZEN0x000D /* CPU (unsigned)v going down */ +#define CPU_DOWN_FAILED_FROZEN 0x000E /* CPU (unsigned)v NOT going down */ +#define CPU_DEAD_FROZEN
Re: Kaffeine problem with CFS
15 Nis 2007 Paz tarihinde, Christoph Pfister şunları yazmıştı: > Could you try xine-ui or gxine? Because I suspect rather xine-lib for > freezing issues. In any way I think a gdb backtrace would be much > nicer - but if you can't reproduce the freeze issue with other xine > based players and want to run kaffeine in gdb, you need to execute > "gdb --args kaffeine --nofork". I just tested xine-ui and i can easily reproduce exact same problem with xine-ui also so you are right, it seems a xine-lib problem trigger by CFS changes. > > > thanks. This does has the appearance of a userspace race condition of > > > some sorts. Can you trigger this hang with the patch below applied to > > > the vanilla tree as well? (with no CFS patch applied) > > > > oops, please use the patch below instead. Tomorrow i'll test that patch and also try to get a backtrace. Cheers -- S.Çağlar Onur <[EMAIL PROTECTED]> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! signature.asc Description: This is a digitally signed message part.
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
Hello Pavel, On Sun, Apr 15, 2007 at 07:56:56PM +, Pavel Machek wrote: > Hi! > > > * It insists on reusing its predefined attributes *and* their units. > > So, userspace getting expected values for any battery. > > > > Also common units is required for APM/ACPI emulation. > > > > Though our battery class insisting on re-usage, but not forces it. If some > > battery driver can't convert its own raw values (can't imagine why), then > > driver is free to implement its own attributes *and* additional _units > > attribute. Though, this scheme is discouraged. > > > > * LEDs support. Each battery register its trigger, and gadgets with LEDs > > can quickly bind to battery-charging / battery-full triggers. > > > > Here how it looks like from user space: > > > > # ls /sys/class/battery/main-battery/ > > capacity max_capacity max_voltage min_current power subsystem uevent > > current max_current min_capacity min_voltage status temp > > voltage > > # cat /sys/class/battery/main-battery/status > > Full > > # cat /sys/class/leds/h5400\:green-right/trigger > > none h5400-radio timer hwtimer main-battery-charging [main-battery-full] > > # cat /sys/class/leds/h5400\:green-right/brightness > > 255 > > Can we get few lines in Documentation? Yes, sure. > I guess min_capacity is > shutdown capacity at current temperature, but its surely non-obvious. > > Will min_capacity increase as batery gets old? Or will max_capacity > decrease? min_capacity and max_capacity depend on temperature. But some drivers can/want to interpolate, others can't/don't want. It's driver's matter. ds2760_battery just remembers last capacity when current was < 10 mA (i.e. battery charged full at given temperature) as max_capacity, and takes this as reference for calculations. > (Should we introduce design_capacity for ACPI systems that > know the difference?) Yup, I've introduced it in [take2] (it's in this thread, thus it's hard to find). Will resend it as separate thread soon, along with few other changes. > What is min_current? Granularity of amper meter? > > And min_voltage is shutdown voltage? Yes, should be. But, for example, ds2760 battery can't remember this value in its eeprom (iirc), thus this value passed by platform code, i.e. in our case (iPaqs) it's machine dependent value. Probably we should not even export this attribute in ds2760_battery driver, as it does not take any part in calculations. Plus this attribute highly depend on battery chemistry and temperature. Thus it's hardly anyhow useful, except if hardware itself reports it (not ds2760 case). > Otherwise it looks good to me. Something like this is really needed. Thanks! > > + * All voltages, currents, capacities and temperatures in mV, mA, mAh and > > + * tenths of a degree unless otherwise stated. It's driver's job to convert > > tenths of degree Celsius? Yup, fixed in [take2]. > > +#define BATTERY_STATUS_UNKNOWN 0 > > +#define BATTERY_STATUS_CHARGING 1 > > +#define BATTERY_STATUS_DISCHARGING 2 > > +#define BATTERY_STATUS_NOT_CHARGING 3 > > +#define BATTERY_STATUS_FULL 4 > > Perhaps we need STATUS_ERROR? At least on some machines it is > different from STATUS_NOT_CHARGING. I'm unsure about this. BATTERY_STATUS_* is mostly about charging process status (should I rename it to more verbose BATTERY_CHARGING_STATUS_, or just mention it in Documentation?). For errors things it might be better to create "health" attribute. > > + /* private */ > > + struct power_supplicant pst; > > + > > + #ifdef CONFIG_LEDS_TRIGGERS > > + struct led_trigger *charging_trig; > > + char *charging_trig_name; > > + struct led_trigger *full_trig; > > + char *full_trig_name; > > + #endif > > +}; > > #ifdefs need to be at column 0? Yup, fixed in [take2]. > > +/* > > + * This is recommended structure to specify static battery parameters. > > + * Generic one, parametrizable for different batteries. Battery device > > + * itself does bot use it, but that's what implementing most drivers, > > 'does not'? Thanks, will fix! > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.16.48
Location: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ git tree: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git RSS feed of the git tree: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss Changes since 2.6.16.47: Adrian Bunk (2): Linux 2.6.16.48-rc1 Linux 2.6.16.48 Andreas Oberritter (1): V4L/DVB: Pluto2: fix incorrect TSCR register setting David Brownell (1): USB: usbnet driver bugfix Francois Romieu (3): r8169: fix a race between PCI probe and dev_open r8169: fix suspend/resume for down interface r8169: issue request_irq after the private data are completely initialized Herbert Xu (1): [IPSEC]: Reject packets within replay window but outside the bit mask John Heffner (1): [TCP]: Do receiver-side SWS avoidance for rcvbuf < MSS. Michael Krufky (1): V4L: tveeprom: autodetect LG TAPC G701D as tuner type 37 Oliver Endriss (1): V4L: saa7146: Fix allocation of clipping memory Patrick McHardy (2): [NET_SCHED]: cls_basic: fix memory leak in basic_destroy [NET_SCHED]: cls_tcindex: fix compatibility breakage Stephen Hemminger (3): skge: turn carrier off when down sky2: turn carrier off when down sky2: turn on clocks when doing resume Thomas Gleixner (1): i386: fix file_read_actor() and pipe_read() for original i386 systems Trent Piepho (1): V4L: radio: Fix error in Kbuild file YOSHIFUJI Hideaki (1): [IPv6]: Fix incorrect length check in rawv6_sendmsg() Makefile |2 - arch/i386/lib/usercopy.c |9 drivers/media/dvb/pluto2/pluto2.c | 22 +++ drivers/media/radio/Kconfig |2 - drivers/media/video/tveeprom.c|2 - drivers/net/r8169.c | 56 -- drivers/net/skge.c|1 drivers/net/sky2.c|8 drivers/usb/net/usbnet.c |7 ++- include/media/saa7146_vv.h|3 + net/ipv4/tcp_output.c |3 + net/ipv6/raw.c|4 +- net/ipv6/udp.c|2 - net/sched/cls_basic.c |1 net/sched/cls_tcindex.c |4 +- net/xfrm/xfrm_state.c |3 + 16 files changed, 83 insertions(+), 46 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6, ASUS M2V 1.01G, ALSA detection/non-support
Really Cc: [EMAIL PROTECTED] Richard A Nelson napsal(a): > My son has an earlier version of the M2V & BIOS (0901) and his gets full > 6ch > sound. > > The 1.01G, and related BIOS (1304 or 1701) do not properly handle the > onboard sound: > hda_codec: Unknown model for ALC660VD/ALC861VD, trying auto-probe from > BIOS... What does your /proc/asound/version say? > it seems to truely be a BIOS issue, as I don't see a difference in lspci > -vvxxx between our systems: > > 80:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio > Controller (rev 10) > Subsystem: ASUSTeK Computer Inc. Unknown device 81e7 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Step ping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 17 > Region 0: Memory at fbffc000 (64-bit, non-prefetchable) [size=16K] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA > PME(D0+,D1-,D2-,D3ho t+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/0 Enable- > Address: Data: > Capabilities: [70] Express Unknown type IRQ 0 > Device: Supported: MaxPayload 128 bytes, PhantFunc 0, > ExtTag- > Device: Latency L0s <64ns, L1 <1us > Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- > Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- > Device: MaxPayload 128 bytes, MaxReadReq 128 bytes > Link: Supported Speed unknown, Width x0, ASPM unknown, > Port 0 > Link: Latency L0s <64ns, L1 <1us > Link: ASPM Disabled CommClk- ExtSynch- > Link: Speed unknown, Width x0 > 00: 06 11 88 32 06 00 10 00 10 00 03 04 10 00 00 00 > 10: 04 c0 ff fb 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 e7 81 > 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00 > 40: 00 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 01 60 42 c8 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 05 70 80 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 10 00 91 00 00 00 00 00 00 00 30 00 00 00 00 00 > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > ALSA, instead of seeing ALC660, on my box sees ALC660-VD, with very > little in the way of devices (only front output) - which does not work > either :( > > Stumped on where to go from here... regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZFS with Linux: An Open Plea
On 14/04/07, David R. Litwin <[EMAIL PROTECTED]> wrote: Before I go on, let me appologise. I don't really know what I hope to accomplish, beyond trying to garner thoughts (and support?) for the topic. Essentially: I want to use Linux and ZFS. I don't particularly care about licences or any of the rest of that nonsense. The license that protects the code we write is far from nonsense. The code is there; it merely needs to be made to work with Linux. Done and done -- provided I can find some one to do this for me (I'd do it myself, but I haven't the foggiest notion how to go about such a feat). I suggest the first thing you do is contact the ZFS developers and convince them to release their code under a license that's GPL compatible, then we can start looking at a Linux port. By the way, forget about this FUSE business. I don't know why they're bothering: It's not real, it's slow and, in general, silly. FUSE is nice for trying out new and interresting ideas in userspace - it has its uses. What are the thoughts of the Linux community? Can't tell you that, all I can tell you is my own oppinion. I believe ZFS for Linux would be interresting, if not for any other reason then for compatibility. I'd personally like to see it - but, settle the license issue first. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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: so what *is* obsolete and removable?
On 15/04/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: in a recent posting, ian anderson suggested that, before kernel features are removed, they should spend a reasonable amount of time in the feature removal file to give everyone fair warning. if that's the case, then there are a *bunch* of things that should perhaps be added to that file real soon now just to start the clock ticking. [snip] ./sound/oss/Kconfig:bool "Obsolete OSS drivers" ./sound/oss/Kconfig: This option enables support for obsolete OSS drivers that clearly, that was a fairly brainless search, but it still reveals a pile of stuff that's "obsolete" (whatever that means in the context in which it's used). so what's really obsolete? IIRC Adrian Bunk is handling the removal of obsolete OSS drivers and doing a nice job at it. Dunno about the rest of the stuff. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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] hpet: Enable hidden HPET on NVidia motherboards
On Sunday 15 April 2007 21:14, Mikko Tiihonen wrote: > Enables HPET for NVidia motherboards with broken BIOS. The patch reads the > HPET address from the pci config space. The patch should also work if ACPI > is disabled. > > The HPET search is done in early-quirks because even > DECLARE_PCI_FIXUP_EARLY was too late. If the new quirk causes problems it > can be disabled with the nohpet boot option. > > The patch assumes that the BIOS has done the basic setup of HPET, but has > not published the result in ACPI tables. This is at least true for some > Asus and Gigabyte motherboards. This works fine on my DFI Lanparty UT nForce4 CK804 mainboard: [EMAIL PROTECTED]:~$ dmesg | grep hpet [ 25.677099] hpet0: at MMIO 0xfefff000, IRQs 2, 8, 31 [ 25.677102] hpet0: 3 32-bit timers, 2500 Hz [ 25.678799] Time: hpet clocksource has been installed. I've been wanting hpets for a while, this patch is extremely useful to me. Unfortunately your patch does not seem to apply with standard tools, perhaps your mailer corrupted it (I just hand applied it). Thanks Mikko. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6, ASUS M2V 1.01G, ALSA detection/non-support
Cc: [EMAIL PROTECTED] Richard A Nelson napsal(a): > My son has an earlier version of the M2V & BIOS (0901) and his gets full > 6ch > sound. > > The 1.01G, and related BIOS (1304 or 1701) do not properly handle the > onboard sound: > hda_codec: Unknown model for ALC660VD/ALC861VD, trying auto-probe from > BIOS... What does your /proc/asound/version say? > it seems to truely be a BIOS issue, as I don't see a difference in lspci > -vvxxx between our systems: > > 80:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio > Controller (rev 10) > Subsystem: ASUSTeK Computer Inc. Unknown device 81e7 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Step ping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 17 > Region 0: Memory at fbffc000 (64-bit, non-prefetchable) [size=16K] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA > PME(D0+,D1-,D2-,D3ho t+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/0 Enable- > Address: Data: > Capabilities: [70] Express Unknown type IRQ 0 > Device: Supported: MaxPayload 128 bytes, PhantFunc 0, > ExtTag- > Device: Latency L0s <64ns, L1 <1us > Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- > Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- > Device: MaxPayload 128 bytes, MaxReadReq 128 bytes > Link: Supported Speed unknown, Width x0, ASPM unknown, > Port 0 > Link: Latency L0s <64ns, L1 <1us > Link: ASPM Disabled CommClk- ExtSynch- > Link: Speed unknown, Width x0 > 00: 06 11 88 32 06 00 10 00 10 00 03 04 10 00 00 00 > 10: 04 c0 ff fb 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 e7 81 > 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00 > 40: 00 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 01 60 42 c8 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 05 70 80 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 10 00 91 00 00 00 00 00 00 00 30 00 00 00 00 00 > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > ALSA, instead of seeing ALC660, on my box sees ALC660-VD, with very > little in the way of devices (only front output) - which does not work > either :( > > Stumped on where to go from here... regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: so what *is* obsolete and removable?
Robert P. J. Day napsal(a): > ./drivers/char/Kconfig: tristate "Moxa SmartIO support (OBSOLETE)" Yes, I'm going to add it to the schedule shortly -- will post patch with correcting bad Kconfig info after some bugfixes of mxser_new. regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Sun, Apr 15, 2007 at 10:48:24PM +0200, Ingo Molnar wrote: > > * Matt Mackall <[EMAIL PROTECTED]> wrote: > > > Look at what happened with I/O scheduling. Opening things up to some > > new ideas by making it possible to select your I/O scheduler took us > > from 10 years of stagnation to healthy, competitive development, which > > gave us a substantially better I/O scheduler. > > actually, 2-3 years ago we already had IO schedulers, and my opinion > against plugsched back then (also shared by Nick and Linus) was very > much considering them. There are at least 4 reasons why I/O schedulers > are different from CPU schedulers: ... > 3) I/O schedulers are pretty damn clean code, and plugsched, at least >the last version i saw of it, didnt come even close. That's irrelevant. Plugsched was an attempt to get alternative schedulers exposure in mainline. I know, because I remember encouraging Bill to pursue it. Not only did you veto plugsched (which may have been a perfectly reasonable thing to do), but you also vetoed the whole concept of multiple schedulers in the tree too. "We don't want to balkanize the scheduling landscape". And that latter part is what I'm claiming has set us back for years. It's not a technical argument but a strategic one. And it's just not a good strategy. > 4) the good thing that happened to I/O, after years of stagnation isnt >I/O schedulers. The good thing that happened to I/O is called Jens >Axboe. If you care about the I/O subystem then print that name out >and hang it on the wall. That and only that is what mattered. Disagree. Things didn't actually get interesting until Nick showed up with AS and got it in-tree to demonstrate the huge amount of room we had for improvement. It took several iterations of AS and CFQ (with a couple complete rewrites) before CFQ began to look like the winner. The resulting time-sliced CFQ was fairly heavily influenced by the ideas in AS. Similarly, things in scheduler land had been pretty damn boring until Con finally got Andrew to take one of his schedulers for a spin. > nor was the non-modularity of some piece of code ever an impediment to > competition. May i remind you of the pretty competitive SLAB allocator > landscape, resulting in things like the SLOB allocator, written by > yourself? ;-) Thankfully no one came out and said "we don't want to balkanize the allocator landscape" when I submitted it or I probably would have just dropped it, rather than painfully dragging it along out of tree for years. I'm not nearly the glutton for punishment that Con is. :-P -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ALPHA: support graphics on non-zero PCI domains (take 2)
Sam Ravnborg wrote:
+#ifndef CONFIG_ALPHA_GENERIC
+EXPORT_SYMBOL(tsunami_ioportmap);
+EXPORT_SYMBOL(tsunami_ioremap);
+#endif
>>> It looks strange that the function is always defined but conditionally
>>> exported.
>>> Also usual style is to place EXPORT right after closing brace of function -
>>> (with no empty lines in-between).
>> In a generic kernel the IO functions are never addressed directly,
>> only via machine vector, so there is no point in exporting them.
>> What about something like EXPORT_SYMBOL_NONGENERIC() macro?
> As I wrote it looked strange. Unconditionally exporting them should not harm
> and then we are one pair of ifdef/endif shorter?
>
> Nitty gritty detail so do what you think match best.
>
> Sam
Thanks for all the feedback, Sam.
Find attached a reworked set of patches that I think cleans up all the
areas with which you had issues.
Sorry about putting it into an attachment, I've yet to figure out out
to do the verbatim inclusion of patch text into Thunderbird without
adverse side effects... :-(
Thanks again.
--Jay++
--
Jay A EstabrookHPTC - XC I & B
Hewlett-Packard Company - ZKO1-3/D-B.8 (603) 884-0301
110 Spit Brook Road, Nashua NH 03062 [EMAIL PROTECTED]
diff -Naurp a/arch/alpha/Kconfig c/arch/alpha/Kconfig
--- a/arch/alpha/Kconfig2007-04-02 13:03:21.0 -0400
+++ c/arch/alpha/Kconfig2007-04-15 14:03:24.0 -0400
@@ -481,6 +481,15 @@ config ALPHA_BROKEN_IRQ_MASK
depends on ALPHA_GENERIC || ALPHA_PC164
default y
+config VGA_HOSE
+ bool
+ depends on ALPHA_GENERIC || ALPHA_TITAN || ALPHA_MARVEL || ALPHA_TSUNAMI
+ default y
+ help
+ Support VGA on an arbitrary hose; needed for several platforms
+ which always have multiple hoses, and whose consoles support it.
+
+
config ALPHA_SRM
bool "Use SRM as bootloader" if ALPHA_CABRIOLET || ALPHA_AVANTI_CH ||
ALPHA_EB64P || ALPHA_PC164 || ALPHA_TAKARA || ALPHA_EB164 || ALPHA_ALCOR ||
ALPHA_MIATA || ALPHA_LX164 || ALPHA_SX164 || ALPHA_NAUTILUS || ALPHA_NONAME
default y if ALPHA_JENSEN || ALPHA_MIKASA || ALPHA_SABLE || ALPHA_LYNX
|| ALPHA_NORITAKE || ALPHA_DP264 || ALPHA_RAWHIDE || ALPHA_EIGER ||
ALPHA_WILDFIRE || ALPHA_TITAN || ALPHA_SHARK || ALPHA_MARVEL
@@ -644,6 +653,13 @@ source "arch/alpha/oprofile/Kconfig"
source "arch/alpha/Kconfig.debug"
+# DUMMY_CONSOLE may be defined in drivers/video/console/Kconfig
+# but we also need it if VGA_HOSE is set
+config DUMMY_CONSOLE
+ bool
+ depends on VGA_HOSE
+ default y
+
source "security/Kconfig"
source "crypto/Kconfig"
diff -Naurp a/arch/alpha/kernel/console.c c/arch/alpha/kernel/console.c
--- a/arch/alpha/kernel/console.c 2007-02-04 13:44:54.0 -0500
+++ c/arch/alpha/kernel/console.c 2007-04-15 12:27:37.0 -0400
@@ -9,16 +9,20 @@
#include
#include
#include
+#include
#include
#include
+#include "pci_impl.h"
+
#ifdef CONFIG_VGA_HOSE
-/*
- * Externally-visible vga hose bases
- */
-unsigned long __vga_hose_io_base = 0; /* base for default hose */
-unsigned long __vga_hose_mem_base = 0; /* base for default hose */
+struct pci_controller *pci_vga_hose = NULL;
+static struct resource alpha_vga = {
+ .name = "alpha-vga+",
+ .start = 0x3C0,
+ .end= 0x3DF
+};
static struct pci_controller * __init
default_vga_hose_select(struct pci_controller *h1, struct pci_controller *h2)
@@ -30,36 +34,58 @@ default_vga_hose_select(struct pci_contr
}
void __init
-set_vga_hose(struct pci_controller *hose)
-{
- if (hose) {
- __vga_hose_io_base = hose->io_space->start;
- __vga_hose_mem_base = hose->mem_space->start;
- }
-}
-
-void __init
locate_and_init_vga(void *(*sel_func)(void *, void *))
{
struct pci_controller *hose = NULL;
struct pci_dev *dev = NULL;
+ /* Default the select function */
if (!sel_func) sel_func = (void *)default_vga_hose_select;
+ /* Find the console VGA device */
for(dev=NULL; (dev=pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, dev));) {
- if (!hose) hose = dev->sysdata;
- else hose = sel_func(hose, dev->sysdata);
+ if (!hose)
+ hose = dev->sysdata;
+ else
+ hose = sel_func(hose, dev->sysdata);
}
- /* Did we already inititialize the correct one? */
- if (conswitchp == _con &&
- __vga_hose_io_base == hose->io_space->start &&
- __vga_hose_mem_base == hose->mem_space->start)
+ /* Did we already initialize the correct one? Is there one? */
+ if (!hose || (conswitchp == _con && pci_vga_hose == hose))
return;
- /* Set the VGA hose and init the new console */
- set_vga_hose(hose);
+ /* Create a new VGA ioport resource WRT the hose it is on. */
+
2.6.21-rc6, ASUS M2V 1.01G, ALSA detection/non-support
My son has an earlier version of the M2V & BIOS (0901) and his gets full 6ch sound. The 1.01G, and related BIOS (1304 or 1701) do not properly handle the onboard sound: hda_codec: Unknown model for ALC660VD/ALC861VD, trying auto-probe from BIOS... it seems to truely be a BIOS issue, as I don't see a difference in lspci -vvxxx between our systems: 80:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio Controller (rev 10) Subsystem: ASUSTeK Computer Inc. Unknown device 81e7 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?
On 4/15/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote: On Sunday 15 April 2007 03:41, Jean Delvare wrote: > On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote: > > Of course, there are always BIOS defects. But if we could make a > > case that a BIOS that doesn't declare the resources used by the AML > > is defective, we could add quirks to reserve the undeclared resources. > > Only realistic if the list of systems needing a quirk is small. Do you > think that would be the case? I don't know. I confess that I don't clearly understand the problem yet. It sounds like the sensor drivers want to talk to hardware that ACPI methods might also use. Exactly. But I missed the details, such as the specific devices in question, which ports they use, how they are described in ACPI, which AML methods use those ports, and which non-ACPI drivers also use them. The original report was about the temperature sensors of K8 cpus. It happens that ACPI reads the sensors while the linux driver is using it and gets garbage (and shut down the system). The problem is more generic though, and applies to all hardware monitoring chips for which a driver exists. It also sounds like the non-ACPI drivers provide much more functionality than ACPI exposes. I'd like to understand this, too, because an obvious way to solve the problem would be to drop the non-ACPI drivers. Problem is that ACPI may access the sensors anyway (e.g. via SMM). Is this extra functionality available on Windows? If so, do we know whether Windows uses non-ACPI drivers or whether they have some smarter way to use ACPI? Usually ACPI exposes 1 or 2 temperature readings (CPU and motherboard), while the hw driver can also provide fans and voltages measurements. Vendors usually provides a monitoring utility for Win that also exposes these information. It's not known whether there's a way to avoid conflicting accesses between ACPI and the raw driver; it's possible that it's vendor-specific and not documented. Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is there any generic GPIO chip framework like IRQ chips?
To merge, this would be split apart ... what's interesting here is
the way the new leds-gpio driver can be made to talk to leds that
sit across an I2C link.
== CUT HERE
This presumes various patches updating:
- LED framework to support generic GPIOs (in MM and LED queue)
- LED framework's generic GPIO support to understand that some GPIOs
can't be directly accessed in timer callbacks (patch submitted)
- I2C to support "new style" drivers (driver model conformance, in MM
and i2c queues);
- Kernel.org to match current OMAP trees (in the works, huge)
- OMAP to use the "struct gpio_chip" infrastructure for its GPIOs (a
previous patch in this series)
- TPS65010 to be such a "new style" I2C driver (blocked waiting for OMAP
and I2C patches to merge);
Given those prerequisites, this patch:
* Exposes tps65010 GPIOs and LEDs through the GPIO framework (gaining an
activity light for CF access)
* Converts the OSK board to use that framework (not quite everywhere; at
least the ads7846 driver and serial line wakeup still need updating)
* Removes "old style" OSK led support, except with the Mistral board
whose red-or-green LED isn't really supported by the new framework
Note that this is the first example of the "I2C GPIO expander" case,
where the GPIOs can't be accessed in non-sleeping contexts.
---
arch/arm/mach-omap1/board-osk.c | 66 +---
arch/arm/mach-omap1/leds-osk.c| 92 --
arch/arm/mach-omap1/leds.c| 15 ++---
drivers/i2c/chips/tps65010.c | 59 +
include/asm-arm/arch-omap/board-osk.h | 11
include/asm-arm/arch-omap/tps65010.h | 17 ++
6 files changed, 141 insertions(+), 119 deletions(-)
--- osk2.orig/include/asm-arm/arch-omap/tps65010.h 2007-04-15
11:09:12.0 -0700
+++ osk2/include/asm-arm/arch-omap/tps65010.h 2007-04-15 11:09:15.0
-0700
@@ -152,5 +152,22 @@ extern int tps65010_config_vregs1(unsign
*/
extern int tps65013_set_low_pwr(unsigned mode);
+
+/**
+ * struct tps65010_board - packages GPIO and LED lines
+ * @base: the GPIO number to assign to GPIO-1
+ * @outmask: bit (N-1) is set to allow GPIO-N to be used
+ * as an (open drain) output
+ *
+ * Board data may be used to package the GPIO (and LED) lines
+ * for use in by the generic GPIO and LED frameworks. The first
+ * four GPIOs starting at gpio_base are GPIO1..GPIO4; the next
+ * two are LED1..LED2.
+ */
+struct tps65010_board {
+ int base;
+ unsignedoutmask;
+};
+
#endif /* __ASM_ARCH_TPS65010_H */
--- osk2.orig/drivers/i2c/chips/tps65010.c 2007-04-15 11:09:12.0
-0700
+++ osk2/drivers/i2c/chips/tps65010.c 2007-04-15 11:09:15.0 -0700
@@ -34,9 +34,9 @@
#include
#include
+#include
#include
-#include
#include
#include
@@ -91,7 +91,8 @@ struct tps65010 {
u8 chgstatus, regstatus, chgconf;
u8 nmask1, nmask2;
- /* not currently tracking GPIO state */
+ u8 outmask;
+ struct gpio_chipchip;
};
#definePOWER_POLL_DELAYmsecs_to_jiffies(5000)
@@ -454,6 +455,38 @@ static irqreturn_t tps65010_irq(int irq,
/*-*/
+/* offsets 0..3 == GPIO1..GPIO4
+ * offsets 4..5 == LED1..LED2 (we set one of the non-BLINK modes)
+ */
+static void
+tps65010_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+ if (offset < 4)
+ tps65010_set_gpio_out_value(offset + 1, value);
+ else
+ tps65010_set_led(offset - 3, value ? ON : OFF);
+}
+
+static int
+tps65010_output(struct gpio_chip *chip, unsigned offset, int value)
+{
+ /* GPIOs may be input-only */
+ if (offset < 4) {
+ struct tps65010 *tps;
+
+ tps = container_of(chip, struct tps65010, chip);
+ if (!(tps->outmask & (1 << offset)))
+ return -EINVAL;
+ tps65010_set_gpio_out_value(offset + 1, value);
+ } else
+ tps65010_set_led(offset - 3, value ? ON : OFF);
+
+ return 0;
+}
+
+
+/*-*/
+
static struct tps65010 *the_tps;
static int __exit tps65010_remove(struct i2c_client *client)
@@ -475,6 +508,7 @@ static int tps65010_probe(struct i2c_cli
struct tps65010 *tps;
int status;
unsigned long irqflags;
+ struct tps65010_board *board = client->dev.platform_data;
if (the_tps) {
dev_dbg(>dev, "only one %s for now\n", DRIVER_NAME);
@@ -585,6 +619,27 @@ static int tps65010_probe(struct i2c_cli
tps->file = debugfs_create_file(DRIVER_NAME, S_IRUGO, NULL,
tps,
Re: is there any generic GPIO chip framework like IRQ chips?
Makes OMAP use the infrastructure in the preceding patch; slightly
slows down the code, because it adds an indirect function call and
uses a non-table lookup, but GPIOs aren't accessed on critical paths.
=== CUT HERE
Update OMAP to use the new GPIO implementation framework. This is just a
quick'n'dirty update; more code could now be removed. Plus, it'd really
be better to shift the entire OMAP GPIO infrastructure over to cleaner
code, this all sort of "just growed" over time.
Note: against current Linux-OMAP tree. The code at the end of gpio.c
isn't yet upstream; remove that segment and it may apply against kernel.org
trees too.
---
arch/arm/plat-omap/Kconfig |2
arch/arm/plat-omap/gpio.c| 201 ++-
include/asm-arm/arch-omap/gpio.h | 52 ++
3 files changed, 88 insertions(+), 167 deletions(-)
--- osk2.orig/arch/arm/plat-omap/Kconfig2007-04-15 10:59:51.0
-0700
+++ osk2/arch/arm/plat-omap/Kconfig 2007-04-15 11:00:40.0 -0700
@@ -11,9 +11,11 @@ choice
config ARCH_OMAP1
bool "TI OMAP1"
+ select GPIO_LIB
config ARCH_OMAP2
bool "TI OMAP2"
+ select GPIO_LIB
endchoice
--- osk2.orig/arch/arm/plat-omap/gpio.c 2007-04-15 10:59:51.0 -0700
+++ osk2/arch/arm/plat-omap/gpio.c 2007-04-15 11:02:54.0 -0700
@@ -137,6 +137,7 @@ struct gpio_bank {
u32 saved_risingdetect;
#endif
spinlock_t lock;
+ struct gpio_chip chip;
};
#define METHOD_MPUIO 0
@@ -838,17 +839,23 @@ static int gpio_wake_enable(unsigned int
int omap_request_gpio(int gpio)
{
struct gpio_bank *bank;
+ int status;
if (check_gpio(gpio) < 0)
return -EINVAL;
+ status = gpio_request(gpio, NULL);
+ if (status < 0)
+ return status;
+
bank = get_gpio_bank(gpio);
spin_lock(>lock);
if (unlikely(bank->reserved_map & (1 << get_gpio_index(gpio {
printk(KERN_ERR "omap-gpio: GPIO %d is already reserved!\n",
gpio);
dump_stack();
spin_unlock(>lock);
- return -1;
+ gpio_free(gpio);
+ return -EBUSY;
}
bank->reserved_map |= (1 << get_gpio_index(gpio));
@@ -902,6 +909,7 @@ void omap_free_gpio(int gpio)
bank->reserved_map &= ~(1 << get_gpio_index(gpio));
_reset_gpio(bank, gpio);
spin_unlock(>lock);
+ gpio_free(gpio);
}
/*
@@ -1199,6 +1207,50 @@ static inline void mpuio_init(void) {}
/*-*/
+/* REVISIT these are stupid implementations! replace by ones that
+ * don't switch on METHOD_* and which mostly avoid spinlocks
+ */
+
+static int gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+ return omap_get_gpio_datain(chip->base + offset);
+}
+
+static void gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+ struct gpio_bank *bank;
+
+ bank = container_of(chip, struct gpio_bank, chip);
+ spin_lock(>lock);
+ _set_gpio_dataout(bank, offset, value);
+ spin_unlock(>lock);
+}
+
+static int gpio_input(struct gpio_chip *chip, unsigned offset)
+{
+ struct gpio_bank *bank;
+
+ bank = container_of(chip, struct gpio_bank, chip);
+ spin_lock(>lock);
+ _set_gpio_direction(bank, offset, 1);
+ spin_unlock(>lock);
+ return 0;
+}
+
+static int gpio_output(struct gpio_chip *chip, unsigned offset, int value)
+{
+ struct gpio_bank *bank;
+
+ bank = container_of(chip, struct gpio_bank, chip);
+ spin_lock(>lock);
+ _set_gpio_dataout(bank, offset, value);
+ _set_gpio_direction(bank, offset, 0);
+ spin_unlock(>lock);
+ return 0;
+}
+
+/*-*/
+
static int initialized;
static struct clk * gpio_ick;
static struct clk * gpio_fck;
@@ -1212,6 +1264,7 @@ static int __init _omap_gpio_init(void)
{
int i;
struct gpio_bank *bank;
+ int gpio = 0;
initialized = 1;
@@ -1346,6 +1399,27 @@ static int __init _omap_gpio_init(void)
gpio_count = 32;
}
#endif
+ /* REVISIT just switch from OMAP-specific gpio
+* interfaces over to the generic ones
+*/
+ bank->chip.get = gpio_get;
+ bank->chip.set = gpio_set;
+ bank->chip.direction_input = gpio_input;
+ bank->chip.direction_output = gpio_output;
+ if (bank_is_mpuio(bank)) {
+ bank->chip.base = OMAP_MPUIO(0);
+ bank->chip.name = "MPUIO";
+ } else {
+ bank->chip.base = gpio;
+ bank->chip.name = "GPIO";
+ gpio += gpio_count;
+ }
+
Re: is there any generic GPIO chip framework like IRQ chips?
This patch shows some almost-mergeable code matching $SUBJECT.
CUT HERE
Provide some implementation infrastructure that platforms may choose
to use when implementing the GPIO programming interface.
As previously discussed on LKML, this can be very desirable on some
platforms -- with GPIOs provided by non-SOC controllers -- but such
implementation choices are transparent to the driver interface.
When debugfs is available this provides an /sys/debug/gpio file showing
what GPIOs are available, and how the ones in use are configured.
Note that both OMAP and AVR32 implementations of the gpio_request() and
gpio_free() calls have additional features, which may be worth stealing.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Documentation/gpio.txt |4
include/asm-generic/gpio.h | 96 +++
lib/Kconfig|6
lib/Makefile |2
lib/gpiolib.c | 364 +
5 files changed, 472 insertions(+), 2 deletions(-)
--- g26.orig/Documentation/gpio.txt 2007-04-14 19:51:00.0 -0700
+++ g26/Documentation/gpio.txt 2007-04-14 19:51:12.0 -0700
@@ -63,7 +63,9 @@ and that can be critical for glue logic.
Plus, this doesn't define an implementation framework, just an interface.
One platform might implement it as simple inline functions accessing chip
registers; another might implement it by delegating through abstractions
-used for several very different kinds of GPIO controller.
+used for several very different kinds of GPIO controller. (There is some
+library code supporting such an implementation strategy, but drivers using
+the interface should not care if that's how the interface is implemented.)
That said, if the convention is supported on their platform, drivers should
use it when possible:
--- g26.orig/lib/Kconfig2007-04-14 19:51:00.0 -0700
+++ g26/lib/Kconfig 2007-04-14 19:51:12.0 -0700
@@ -111,4 +111,10 @@ config HAS_IOPORT
depends on HAS_IOMEM && !NO_IOPORT
default y
+#
+# gpiolib is selected if needed
+#
+config GPIO_LIB
+ boolean
+
endmenu
--- g26.orig/include/asm-generic/gpio.h 2007-04-14 19:51:00.0 -0700
+++ g26/include/asm-generic/gpio.h 2007-04-15 10:58:19.0 -0700
@@ -1,6 +1,101 @@
#ifndef _ASM_GENERIC_GPIO_H
#define _ASM_GENERIC_GPIO_H
+#ifdef CONFIG_GPIO_LIB
+
+/* Platforms may implement their GPIO interface with library code,
+ * at the cost of performance for non-inlined operations.
+ */
+
+#ifndef ARCH_GPIOS_PER_CHIP
+#define ARCH_GPIOS_PER_CHIPBITS_PER_LONG
+#endif
+
+/**
+ * struct gpio_chip - abstract a GPIO controller
+ * @get: retrieves value for a given gpio signal
+ * @set: assigns value for a given gpio signal
+ * @direction_input: assigns signal as input, or returns error code
+ * @direction_output: assigns assigns signal as output, or returns error code
+ * @base: identifies the first GPIO number handled by this chip
+ * @name: for use in diagnostics
+ * @irqs: to report optional coupling to the IRQ framework
+ * @irq_base: identifies the first IRQ handled by this chip
+ * @ngpio: the number of GPIOs handled by this controller; the value must
+ * be at most ARCH_GPIOS_PER_CHIP, so the last GPIO handled is
+ * (base + ngpio - 1).
+ * @can_sleep: flag must be set iff get()/set() methods sleep, as they
+ * must while accessing GPIO expander chips over I2C or SPI
+ *
+ * A gpio_chip can help platforms abstract various sources of GPIOs so
+ * they can all be accessed through a common programing interface.
+ * Example sources would be SOC controllers, FPGAs, multifunction
+ * chips, dedicated GPIO expanders, and so on.
+ */
+struct gpio_chip {
+ int (*get)(struct gpio_chip *chip,
+ unsigned offset);
+ void(*set)(struct gpio_chip *chip,
+ unsigned offset, int value);
+ int (*direction_input)(struct gpio_chip *chip,
+ unsigned offset);
+ int (*direction_output)(struct gpio_chip *chip,
+ unsigned offset, int value);
+ unsignedbase;
+ const char *name;
+ struct irq_desc *irqs;
+ unsignedirq_base;
+ u16 ngpio;
+ unsignedcan_sleep:1;
+
+ /* other fields are for the gpio library only */
+ struct list_headchips;
+ unsigned long is_out[DIV_ROUND_UP(ARCH_GPIOS_PER_CHIP,
+ BITS_PER_LONG)];
+#ifdef CONFIG_DEBUG_FS
+ /* fat bits */
+ const char *requested[ARCH_GPIOS_PER_CHIP];
+#else
+ /* thin bits */
+ unsigned long
so what *is* obsolete and removable?
in a recent posting, ian anderson suggested that, before kernel features are removed, they should spend a reasonable amount of time in the feature removal file to give everyone fair warning. if that's the case, then there are a *bunch* of things that should perhaps be added to that file real soon now just to start the clock ticking. as a trivial first observation, there are a load of options described as "obsolete" in one way or another in the various Kconfig files: $ grep -iw obsolete $(find . -name Kconfig\*) ./net/sched/Kconfig:bool "Traffic Policing (obsolete)" ./net/netfilter/Kconfig:bool "Layer 3 Dependent Connection tracking (OBSOLETE)" ./net/netfilter/Kconfig: This target replaced the old obsolete QUEUE target. ./net/ipv6/netfilter/Kconfig: tristate "IP6 Userspace queueing via NETLINK (OBSOLETE)" ./net/ipv4/netfilter/Kconfig: tristate "IP Userspace queueing via NETLINK (OBSOLETE)" ./net/ipv4/Kconfig: This code is experimental and also obsolete. If you want to use it, ./net/bridge/netfilter/Kconfig: tristate "ebt: ulog support (OBSOLETE)" ./drivers/pcmcia/Kconfig: bool "PCMCIA control ioctl (obsolete)" ./drivers/net/wireless/Kconfig:# Note : the cards are obsolete (can't buy them anymore), but the drivers ./drivers/net/wireless/Kconfig:comment "Obsolete Wireless cards support (pre-802.11)" ./drivers/net/Kconfig:new card, since the 3c501 is slow, broken, and obsolete: you will ./drivers/net/Kconfig: tristate "Traffic Shaper (OBSOLETE)" ./drivers/block/paride/Kconfig: This option enables support for the (obsolete) EPIA parallel port ./drivers/block/paride/Kconfig: This option enables support for the (obsolete) 90c20 parallel port ./drivers/block/Kconfig: obsolete. For details, read . ./drivers/sbus/char/Kconfig:tristate "Bidirectional parallel port support (OBSOLETE)" ./drivers/sbus/char/Kconfig: Say Y here to support Sun's obsolete variant of IEEE1284 ./drivers/message/i2o/Kconfig: bool "Enable ioctls (OBSOLETE)" ./drivers/char/Kconfig: tristate "Moxa SmartIO support (OBSOLETE)" ./drivers/char/Kconfig: tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)" ./drivers/mtd/chips/Kconfig: select some other chip drivers which are now considered obsolete, ./drivers/isdn/Kconfig: tristate "Old ISDN4Linux (obsolete)" ./drivers/isdn/Kconfig: Therefore the old ISDN4Linux layer is becoming obsolete. It is ./lib/Kconfig.debug:bool "Enable unused/obsolete exported symbols" ./arch/i386/Kconfig: 1995 when it was made obsolete by the PCI bus. ./arch/arm/Kconfig: 1995 when it was made obsolete by the PCI bus. ./arch/sparc64/Kconfig: 1995 when it was made obsolete by the PCI bus. ./arch/m68k/Kconfig: 1995 when it was made obsolete by the PCI bus. ./arch/um/Kconfig.char:tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)" ./arch/um/Kconfig: into UML. This option is largely obsolete, given that skas0 provides ./arch/mips/Kconfig: 1995 when it was made obsolete by the PCI bus. ./arch/powerpc/platforms/iseries/Kconfig: tristate "iSeries Virtual Console Support (Obsolete)" ./arch/sh/Kconfig:1995 when it was made obsolete by the PCI bus. ./sound/core/Kconfig: Say Y here to support the obsolete ALSA PCM API (ver.0.9.0 rc3 ./sound/oss/Kconfig:bool "Obsolete OSS drivers" ./sound/oss/Kconfig: This option enables support for obsolete OSS drivers that clearly, that was a fairly brainless search, but it still reveals a pile of stuff that's "obsolete" (whatever that means in the context in which it's used). so what's really obsolete? as i recall, the isdn4linux was *un*obsoleted, wasn't it? and raw drivers are going to be kept around for a while longer. so what's legitimately dead? or what should be added to the feature removal schedule? or, if it's not really "obsolete," perhaps it shouldn't be described that way. just my $0.02 (Cdn). rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is there any generic GPIO chip framework like IRQ chips?
On Thursday 12 April 2007 6:57 am, Paul Sokolovsky wrote: > Wednesday, April 11, 2007, 7:52:20 AM, you wrote: > > So, talking about what an (optional) implementation framework might > > look like (and which could handle the SOC, FPGA, I2C, and MFD cases > > I've looked at): See patches in following messages ... a preliminary "gpio_chip" core for such a framework, plus example support for one SOC family's GPIOs, and then updating one board's handling of GPIOs, including over I2C. > Thanks for describing this once again. But I really looked into your > January's code and this code already. And I fully agree that this will > work! And your code could have been long ago in git, but is not, ... Actually, no ... there was a pressing need to adopt some simple basic interfaces, but no such need for implementation infrastructure to support fancier features (until the basic interface was in use). Plus, that code was barely proof-of-concept. The fact that there are now three simple generic drivers (i2c-gpio, leds-gpio, gpio_keys) and various additional drivers using those same interfaces -- working already on multiple platforms! -- illustrates that anything more than a programming interface, with support on a handful of "seed" platforms, wasn't required initially. > Yes, and let that's something which can be entailed from your > approach: you argue that it's extensible interface, but kernel is > exactly not C++ classlib, there must be implementation. I said "implementation choice" not "extensible interface"; those are two very different approaches. You keep bringing C++ into this. You may not know that doesn't win points in Linux. If the point is solid, it doesn't need to rely on parallels to languages that won't be used in the kernel. (Plus, why would you imply C++ class libraries don't need to have implementations?) > And that > implementation: a) will contain inline access for CPU SOC GPIO > controllers, just because "they are always there"; Not what I said. You said "will", I said "can"; there's a big difference. Consider that for example the OMAP infrastructure for GPIOs already has a fair amount of indirection, while most other platforms started more simply ... some of them only included inlines, others just had simple accessor functions. My "can" allows all those; your "will" disallows most of them. And none of them unified that model with non-SOC GPIOs. > b) will not contain > anything else, just because "it's not always there". That's exactly > what implementation will go into 2.6.21. Again, not what I said. The implementations there today just wrap pre-existing GPIO code which mostly addressed SOC support since that's the first thing that's needed. But extensibility has always been on the agenda. It's just *details* of how to extend that have been deferred ... not just by this iteration of the interface, but by all the preceding platform-specific ones too. > Yes, you argue that anyone who needs to extend Generic GPIO API to > their case can do that, and in such way that he won't lose single tick > comparing to using direct low-level methods. Again, not what I said ... I've discouraged changing/extending the programming interface. But I've certainly pointed out ways that existing performance expectations can be preserved without changing that programming interface. > But let's face it - most people will not hack mainline-provided > inlinable headers to add efficient handling for their boards' > additional GPIO, Many folk working with embedded hardware will be more than willing to do exactly that, should performance be a factor. Especially if the platform code is written so it's straightforward ... > 2) Thankfully, we don't have gpio_chip yet. The temptation to clone > irq_chip, irq_desc, and stuff is high. So, what we talk here about is > not only how to implement extensible GPIO, but whether we finally can > break away from need to use in-kernel bureaucracies for handling each > and every (low-level) object. By "bureaucracy" I presume you mean the existence of opaque cookies? Or do you mean the implied resource tracking? (Remember that one of the most basic tasks of an operating system is resource management...) > > Let me rephrase that in a way I think clarifies things ... and adds > > some of the context you've omitted: > > > - What I sketched was (a) a "gpio controller" abstraction, plus > >mapping of GPIO numbers to (b) controller, e.g. "yyy[gpio >> 5]" > >and (c) controller-specific gpio index, e.g. "gpio & 0x1f"; > > >That's how people have managed GPIOs on Linux for many years now. > >It plays well with the very common use of GPIOs as IRQ sources. > > >Usually the "gpio controller" is a register bank on a SOC, but as > >I've pointed out, that could be generalized through the classic > >"another level of indirection" technology (not patentable) at > >the cost of a new mandatory indirect function call. > > > -
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
* Matt Mackall <[EMAIL PROTECTED]> wrote: > Look at what happened with I/O scheduling. Opening things up to some > new ideas by making it possible to select your I/O scheduler took us > from 10 years of stagnation to healthy, competitive development, which > gave us a substantially better I/O scheduler. actually, 2-3 years ago we already had IO schedulers, and my opinion against plugsched back then (also shared by Nick and Linus) was very much considering them. There are at least 4 reasons why I/O schedulers are different from CPU schedulers: 1) CPUs are a non-persistent resource shared by _all_ tasks and workloads in the system. Disks are _persistent_ resources very much attached to specific workloads. (If tasks had to be 'persistent' to the CPU they were started on we'd have much different scheduling technology, and there would be much less complexity.) More analogous to CPU schedulers would perhaps be VM/MM schedulers, and those tend to be hard to modularize in a technologically sane way too. (and unlike disks there's no good generic way to attach VM/MM schedulers to particular workloads.) So it's apples to oranges. in practice it comes down to having one good scheduler that runs all workloads on a system reasonably well. And given that a very large portion of system runs mixed workloads, the demand for one good scheduler is pretty high. While i can run with mixed IO schedulers just fine. 2) plugsched did not allow on the fly selection of schedulers, nor did it allow a per CPU selection of schedulers. IO schedulers you can change per disk, on the fly, making them much more useful in practice. Also, IO schedulers (while definitely not being slow!) are alot less performance sensitive than CPU schedulers. 3) I/O schedulers are pretty damn clean code, and plugsched, at least the last version i saw of it, didnt come even close. 4) the good thing that happened to I/O, after years of stagnation isnt I/O schedulers. The good thing that happened to I/O is called Jens Axboe. If you care about the I/O subystem then print that name out and hang it on the wall. That and only that is what mattered. all in one, while there are definitely uses (embedded would like to have a smaller/different scheduler, etc.), the technical case for modularization for the sake of selectability is alot lower for CPU schedulers than it is for I/O schedulers. nor was the non-modularity of some piece of code ever an impediment to competition. May i remind you of the pretty competitive SLAB allocator landscape, resulting in things like the SLOB allocator, written by yourself? ;-) 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 0/8] unprivileged mount syscall
> > > Agreed on desired behavior, but not on chroot sufficing. It actually > > > sounds like you want exactly what was outlined in the OLS paper. > > > > > > Users still need to be in a different mounts namespace from the admin > > > user so long as we consider the deluser and backup problems > > > > I don't think it matters, because /share/$USER duplicates a part or > > the whole of the user's namespace. > > > > So backup would have to be taught about /share anyway, and deluser > > operates on /home/$USER and not on /share/*, so there shouldn't be any > > problem. > > In what I was thinking of, /share/$USER is bind mounted to > ~$USER/share, so it would have to be done in a private namespace in > order for deluser to not be tricked. But /share/$USER is surely not bind mounted to ~$USER/share in the _global_ namespace, is it? I can't see any sense in that. > > There's actually very little difference between rbind+chroot, and > > CLONE_NEWNS. In a private namespace: > > > > 1) when no more processes reference the namespace, the tree will be > > disbanded > > > > 2) the mount tree won't be accessible from outside the namespace > > But it *can* be, if properly set up. That's part of the point of the > example in the OLS paper. When a user logs in, sshd clones a new > namespace, then bind-mounts /share/$USER into ~$USER/share. So assuming > that /share/$USER was --make-shared'd, it and ~$USER are now in the > same peer group, and any changes made by the user under ~$USER will > be reflected back into /share/$USER. I acknowledge, that it can be done. My point was that it can be done more simply _without_ using CLONE_NS. > > Wanting a persistent namespace contradicts 1). > > Not necessarily, see above. > > > Wanting a per-user (as opposed to per-session) namespace contradicts > > 2). The namespace _has_ to be accessible from outside, so that a new > > session can access/copy it. > > Again, I *think* you are wrong that private namespace contradicts this > requirement. I'm not saying there's any contradiction, I'm saying rbind+chroot is a better fit. I haven't yet heard a single reason why a per-session namespace with parts shared per-user is better than just a per-user namespace. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?
On Sunday 15 April 2007 03:41, Jean Delvare wrote: > On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote: > > Of course, there are always BIOS defects. But if we could make a > > case that a BIOS that doesn't declare the resources used by the AML > > is defective, we could add quirks to reserve the undeclared resources. > > Only realistic if the list of systems needing a quirk is small. Do you > think that would be the case? I don't know. I confess that I don't clearly understand the problem yet. It sounds like the sensor drivers want to talk to hardware that ACPI methods might also use. But I missed the details, such as the specific devices in question, which ports they use, how they are described in ACPI, which AML methods use those ports, and which non-ACPI drivers also use them. It also sounds like the non-ACPI drivers provide much more functionality than ACPI exposes. I'd like to understand this, too, because an obvious way to solve the problem would be to drop the non-ACPI drivers. Is this extra functionality available on Windows? If so, do we know whether Windows uses non-ACPI drivers or whether they have some smarter way to use ACPI? In the long run, I think the easiest, most reliable route would be to use the system in a similar way. Then we'd be doing things the way the manufacturer intended and we'd take advantage of all the Windows- focused firmware testing. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/8] unprivileged mount syscall
> > Thinking a bit more about this, I'm quite sure most users wouldn't
> > even want private namespaces. It would be enough to
> >
> > chroot /share/$USER
> >
> > and be done with it.
>
> I don't think so. How to you want to implement non-shared /tmp
> directories?
mount --bind /.tmp/$USER /share/$USER/tmp
or whatever else this polyunsaturated thingy does within the cloned
namespace.
> The chroot is overkill in this case.
What do you mean it's an overkill? clone(CLONE_NS) duplicates all the
mounts, just as mount --rbind does.
> > Private namespaces are only good for keeping a bunch of mounts
> > referenced by a group of processes. But my guess is, that the natural
> > behavior for users is to see a persistent set of mounts.
> >
> > If for example they mount something on a remote machine, then log out
> > from the ssh session and later log back in, they would want to see
> > their previous mount still there.
>
> They can mount to /mnt where the directory is shared ("mount
> --make-shared /mnt") and visible and all namespaces.
>
> I think /share/$USER is an extreme example. You can found more
> situations when private namespaces are nice solution.
Private to a single login session? I'd like to hear examples.
Thanks,
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Sun, Apr 15, 2007 at 05:05:36PM +0200, Ingo Molnar wrote: > so the rejection was on these grounds, and i still very much stand by > that position here and today: i didnt want to see the Linux scheduler > landscape balkanized and i saw no technological reasons for the > complication that external modularization brings. But "balkanization" is a good thing. "Monoculture" is a bad thing. Look at what happened with I/O scheduling. Opening things up to some new ideas by making it possible to select your I/O scheduler took us from 10 years of stagnation to healthy, competitive development, which gave us a substantially better I/O scheduler. Look at what's happening right now with TCP congestion algorithms. We've had decades of tweaking Reno slightly now turned into a vibrant research area with lots of radical alternatives. A winner will eventually emerge and it will probably look quite a bit different than Reno. Similar things have gone on since the beginning with filesystems on Linux. Being able to easily compare filesystems head to head has been immensely valuable in improving our 'core' Linux filesystems. And what we've had up to now is a scheduler monoculture. Until Andrew put RSDL in -mm, if people wanted to experiment with other schedulers, they had to go well off the beaten path to do it. So all the people who've been hopelessy frustrated with the mainline scheduler go off to the -ck ghetto, or worse, stick with 2.4. Whether your motivations have been protectionist or merely shortsighted, you've stomped pretty heavily on alternative scheduler development by completely rejecting the whole plugsched concept. If we'd opened up mainline to a variety of schedulers _3 years ago_, we'd probably have gotten to where we are today much sooner. Hopefully, the next time Rik suggests pluggable page replacement algorithms, folks will actually seriously consider it. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hpet: Enable hidden HPET on NVidia motherboards
Enables HPET for NVidia motherboards with broken BIOS. The patch reads the
HPET address from the pci config space. The patch should also work if ACPI is
disabled.
The HPET search is done in early-quirks because even DECLARE_PCI_FIXUP_EARLY
was too late. If the new quirk causes problems it can be disabled with the
nohpet boot option.
The patch assumes that the BIOS has done the basic setup of HPET, but has not
published the result in ACPI tables. This is at least true for some Asus and
Gigabyte motherboards.
Patch is against 2.6.21-rc6-git7 but should apply cleanly to most kernels.
Signed-off-by: Mikko Tiihonen <[EMAIL PROTECTED]>
---
It looks probable that most NVidia chipsets have the HPET address at 0x44. It
might be possible to enable the HPET even if BIOS did not initialize it
properly by writing the wanted address there. Some other pci config space bits
might need to be fiddled around too, most likely candidates are 0x74 bit 2 and
0xA3 bit ?. One or both of them have been identified to change in some
motherboards when HPET is enabled/disabled in BIOS.
--- arch/x86_64/kernel/early-quirks.c.orig 2007-04-16 01:30:33.0
+0300
+++ arch/x86_64/kernel/early-quirks.c 2007-04-16 01:27:23.0 +0300
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
static void __init via_bugs(void)
{
@@ -36,6 +37,104 @@ static int __init nvidia_hpet_check(stru
}
#endif
+#ifdef CONFIG_HPET
+
+static u32 nvidia_hpet_chips[] __initdata = {
+ /* ISA Bridge */
+ PCI_VENDOR_ID_NVIDIA | (0x0050 << 16),
+ PCI_VENDOR_ID_NVIDIA | (0x0051 << 16),
+ /* LPC Bridge */
+ PCI_VENDOR_ID_NVIDIA | (0x0360 << 16),
+ PCI_VENDOR_ID_NVIDIA | (0x0361 << 16),
+ PCI_VENDOR_ID_NVIDIA | (0x0362 << 16),
+ PCI_VENDOR_ID_NVIDIA | (0x0363 << 16),
+ PCI_VENDOR_ID_NVIDIA | (0x0364 << 16),
+ PCI_VENDOR_ID_NVIDIA | (0x0365 << 16),
+ PCI_VENDOR_ID_NVIDIA | (0x0366 << 16),
+ PCI_VENDOR_ID_NVIDIA | (0x0367 << 16),
+ 0,
+};
+
+static int __init force_enable_nvidia_hpet(void)
+{
+ int num, slot, func;
+ u32 addr;
+ struct resource *hpet_res;
+
+ if (hpet_address || nohpet)
+ return 0;
+
+ /* Poor man's PCI discovery */
+ for (num = 0; num < 32; num++) {
+ for (slot = 0; slot < 32; slot++) {
+ for (func = 0; func < 8; func++) {
+ u32 class;
+ u32 vendor;
+ u8 type;
+ int i;
+ class = read_pci_config(num,slot,func,
+ PCI_CLASS_REVISION);
+ if (class == 0x)
+ break;
+ vendor = read_pci_config(num, slot, func,
+PCI_VENDOR_ID);
+
+ for (i = 0; nvidia_hpet_chips[i]; i++)
+ if (nvidia_hpet_chips[i] == vendor) {
+ goto found;
+ }
+
+ type = read_pci_config_byte(num, slot, func,
+ PCI_HEADER_TYPE);
+ if (!(type & 0x80))
+ break;
+ }
+ }
+ }
+ return 0;
+
+ found:
+ addr = read_pci_config(num, slot, func, 0x44);
+ if (!addr) {
+ return 0;
+ }
+
+#define HPET_RESOURCE_NAME_SIZE 12
+ hpet_res = alloc_bootmem(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE);
+ if (!hpet_res) {
+ /* We could try writing to the 0x44 and see if that is enough
+* to enable HPET even if BIOS did not initialize it.
+*/
+ printk(KERN_INFO "HPET not set up by BIOS.\n");
+ return 0;
+ }
+
+ memset(hpet_res, 0, sizeof(*hpet_res));
+ hpet_res->name = (void *)_res[1];
+ hpet_res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+ strncpy((char *)hpet_res->name, "NVidia HPET",
+ HPET_RESOURCE_NAME_SIZE);
+ hpet_res->start = addr;
+ hpet_res->end = hpet_res->start + HPET_MMAP_SIZE - 1;
+
+ if (request_resource(_resource, hpet_res)) {
+ printk(KERN_INFO "NVidia quirk failed. Could not "
+ "reserve resources for HPET at base: %#x\n", addr);
+ return 0;
+ }
+
+ hpet_address = addr;
+ printk(KERN_INFO "NVidia quirk. Enabled hidden HPET that BIOS had "
+ "configured at base: %#x\n", addr);
+ return 1;
+}
+#else
+static int __init force_enable_nvidia_hpet(void)
+{
+ return 0;
+}
+#endif
+
static void __init nvidia_bugs(void)
{
#ifdef CONFIG_ACPI
Re: Performance Stats: Kernel patch
Hi! On Sun 2007-04-15 03:21:57, William Lee Irwin III wrote: > At some point in the past, someone's attribution was stripped from: Maxim's. > >> + return buffer + sprintf(buffer, "Nvcsw:\t%lu\n" > >> + "Nivcsw:\t%lu\n", > >> + p->nvcsw, > >> + p->nivcsw); > > On Sun, Apr 15, 2007 at 09:47:07AM +, Pavel Machek wrote: > > We don't encrypt variable names like this. > > nvcsw and nivcsw are conventional variable names for these quantities. I can't decipher them and would not want users see them in /proc. Would nonvoluntary_ctxt_switch be that much worse? -- (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 1/7] [RFC] External power framework
Hi! > External power framework - power supplies and power supplicants. > > Supplicants (batteries so far) may ask to notify they when power supply > arrive/gone. This framework used by battery class (next patches). > > It's permitted for supply to be bound to several supplicants (think main > and backup batteries). > > It's also permitted for supplicants to consume power from several > external supplies (say AC and USB). > > Here is how it look like from userspace: > > # pwd > /sys/class/power_supply > # ls > ac usb > # cat ac/online usb/online > 1 > 0 Looks nice to me. 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 3/7] [RFC] Battery monitoring class
Hi! > * It insists on reusing its predefined attributes *and* their units. > So, userspace getting expected values for any battery. > > Also common units is required for APM/ACPI emulation. > > Though our battery class insisting on re-usage, but not forces it. If some > battery driver can't convert its own raw values (can't imagine why), then > driver is free to implement its own attributes *and* additional _units > attribute. Though, this scheme is discouraged. > > * LEDs support. Each battery register its trigger, and gadgets with LEDs > can quickly bind to battery-charging / battery-full triggers. > > Here how it looks like from user space: > > # ls /sys/class/battery/main-battery/ > capacity max_capacity max_voltage min_current power subsystem uevent > current max_current min_capacity min_voltage status temp voltage > # cat /sys/class/battery/main-battery/status > Full > # cat /sys/class/leds/h5400\:green-right/trigger > none h5400-radio timer hwtimer main-battery-charging [main-battery-full] > # cat /sys/class/leds/h5400\:green-right/brightness > 255 Can we get few lines in Documentation? I guess min_capacity is shutdown capacity at current temperature, but its surely non-obvious. Will min_capacity increase as batery gets old? Or will max_capacity decrease? (Should we introduce design_capacity for ACPI systems that know the difference?) What is min_current? Granularity of amper meter? And min_voltage is shutdown voltage? Otherwise it looks good to me. Something like this is really needed. > + * All voltages, currents, capacities and temperatures in mV, mA, mAh and > + * tenths of a degree unless otherwise stated. It's driver's job to convert tenths of degree Celsius? Pavel > +#define BATTERY_STATUS_UNKNOWN 0 > +#define BATTERY_STATUS_CHARGING 1 > +#define BATTERY_STATUS_DISCHARGING 2 > +#define BATTERY_STATUS_NOT_CHARGING 3 > +#define BATTERY_STATUS_FULL 4 Perhaps we need STATUS_ERROR? At least on some machines it is different from STATUS_NOT_CHARGING. > + /* private */ > + struct power_supplicant pst; > + > + #ifdef CONFIG_LEDS_TRIGGERS > + struct led_trigger *charging_trig; > + char *charging_trig_name; > + struct led_trigger *full_trig; > + char *full_trig_name; > + #endif > +}; #ifdefs need to be at column 0? > +/* > + * This is recommended structure to specify static battery parameters. > + * Generic one, parametrizable for different batteries. Battery device > + * itself does bot use it, but that's what implementing most drivers, 'does not'? 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: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
* William Lee Irwin III <[EMAIL PROTECTED]> wrote: > On Sun, Apr 15, 2007 at 09:20:46PM +0200, Ingo Molnar wrote: > > so Linus was right: this was caused by scheduler starvation. I can > > see one immediate problem already: the 'nice offset' is not divided > > by nr_running as it should. The patch below should fix this but i > > have yet to test it accurately, this change might as well render > > nice levels unacceptably ineffective under high loads. > > I've been suggesting testing CPU bandwidth allocation as influenced by > nice numbers for a while now for a reason. Oh I was very much testing "CPU bandwidth allocation as influenced by nice numbers" - it's one of the basic things i do when modifying the scheduler. An automated tool, while nice (all automation is nice) wouldnt necessarily show such bugs though, because here too it needed thousands of running tasks to trigger in practice. Any volunteers? ;) 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: Add a norecovery option to ext3/4?
Hi! > >You might not damage the underlying filesystem, but you > >could sure go > >off in the weeds trying to read it, if you stumbled > >upon some > >half-updated metadata... so while it may be safe for > >the filesystem, I'm > >not convinced that it's safe for the host reading the > >filesystem. > > > Exactly. If the data are protected you can use other > software to access it. For ext3 an explicit ext2 mount > might do it... It does not :-(. dirty ext3 is marked incompatible with ext2. -- (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 6/7] [RFC] ds2760 battery driver
Hi!
> This is driver for batteries with ds2760 chip inside. Such batteries
> used in almost every HP iPaq and HTC PDAs/phones.
Looks nice to me. It even knows about dependency between temperature
and remaining power :-).
> + di->update_time = jiffies;
> +
> + /* DS2760 reports voltage in units of 4.88mV, but the battery class
> + * reports in units of mV, so convert by multiplying by 4.875.
> + * We approximate because integer math is cheap, and close enough. */
> + di->voltage_raw = (di->raw[DS2760_VOLTAGE_MSB] << 3) |
> + (di->raw[DS2760_VOLTAGE_LSB] >> 5);
> + di->voltage_mV = (di->voltage_raw * 5) - (di->voltage_raw / 8);
Hmm, not sure if such tricks re really worth it... should not compiler
be doing this?
> + /* Calculate the empty level at the present temperature. */
> + scale[4] = di->raw[DS2760_ACTIVE_EMPTY + 4];
> + for (i = 3; i >= 0; i--)
> + scale[i] = scale[i + 1] + di->raw[DS2760_ACTIVE_EMPTY + i];
> +
> + di->empty_mAh = battery_interpolate(scale, di->temp_C / 10);
Wow.
> +static struct platform_driver ds2760_battery_driver = {
> + .driver = {
> + .name = "ds2760-battery",
> + },
> + .probe= ds2760_battery_probe,
> + .remove = ds2760_battery_remove,
> + #ifdef CONFIG_PM
> + .suspend = ds2760_battery_suspend,
> + .resume = ds2760_battery_resume,
> + #endif
I thought ifdefs need to be at column 0?
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] ACPI: more verbose thermal zone shutdown message
Hi!
> while debug some strange termal shutdowns I wrote this patch to get more
> information in /var/log/messages about the reason for the shutdown. I
> think this would be useful in general.
>
> Danny
>
> From: Danny Kukawka <[EMAIL PROTECTED]>
> Subject: ACPI: more verbose thermal zone shutdown message
>
> add more information to acpi thermal zone shutdown message for easier
> debugging
>
> Signed-off-by: Danny Kukawka <[EMAIL PROTECTED]>
Yes, please.
(I actually had similar patch in my tree forever).
> if (tz->temperature >= tz->trips.critical.temperature) {
> - printk(KERN_WARNING PREFIX "Critical trip point\n");
> + printk(KERN_WARNING PREFIX
> +"Critical trip point (%ld C) reached on thermal zone
> [%s]\n",
> +KELVIN_TO_CELSIUS(tz->trips.critical.temperature),
> +acpi_device_bid(tz->device));
> tz->trips.critical.flags.enabled = 1;
> } else if (tz->trips.critical.flags.enabled)
> tz->trips.critical.flags.enabled = 0;
>
> printk(KERN_EMERG
> -"Critical temperature reached (%ld C), shutting down.\n",
> -KELVIN_TO_CELSIUS(tz->temperature));
> +"Critical temperature reached (%ld C on [%s] with trip point set
> to: %ld C), shutting down.\n",
> +KELVIN_TO_CELSIUS(tz->temperature),
> +acpi_device_bid(tz->device),
> +KELVIN_TO_CELSIUS(tz->trips.critical.temperature));
> +
Why two printks with same info, and why is one of them WARNING and
second EMERG?
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: [linux-pm] Linux 2.6.21-rc6
On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote: > Rafael J. Wysocki wrote: > > On Sunday, 15 April 2007 17:14, David Brownell wrote: > > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: > > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > > > > > > > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ > > > > > > > > single core CPU. > > > > > > And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment > > > would be to disable the EHCI (high speed USB) support in BIOS, to make > > > for a simpler hardware configuration, and see if that makes BIOS happier. > > > (Or better, just take EHCI out of your Linux config.) Likewise, taking > > > the 8042 drivers out of Linux. > > > > > > I wouldn't be surprised if those factors didn't matter, but it'd be good > > > to rule them out. > > > > I think the disabling of i8042 support might help. > > Still hangs with "# CONFIG_SERIO_I8042 is not set". > > > > > Dmitry, could you please have a look? > > > > > > > > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long > > > > > as USB legacy support is disabled (however without legacy support I > > > > > can't use the USB keyboard to control grub). > > > > > > > > I think using the 'shutdown' mode of suspend would be better. There's > > > > a little > > > > point in using 'platform' on desktop systems anyway. > > > > > > > > Frankly, I don't know what to do about it. If we move > > > > platform_finish() after > > > > device_resume(), some systems may be broken ... > > > > > > What I'm curious about is exactly why the patch matters. What ACPI > > > magic is being invoked to confuse, or unconfuse, those controllers? > > > > I think the patch helps, because it makes the ACPI magic be done while the > > i8042's .resume() is being executed. > > > > Which makes me think the following patch might help: > > Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042. Well, this means i8042 can be ruled out, so the problem probably is related to the ACPI resume which makes it _much_ more difficult to debug. Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as modules, boot the kernel with init=/bin/bash and see if the problem is still present (please keep CONFIG_SERIO_I8042 unset just in case)? 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: [2.6.22 patch] the scheduled removal of the i8xx_tco watchdog driver
Hello Adrian, > This patch contains the scheduled removal of the i8xx_tco watchdog > driver. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Signed-off-by me also. We probably also need to remove some stuff in the Documentation/watchdog files. Greetings, Wim. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Linux 2.6.21-rc6
Rafael J. Wysocki wrote:
> On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> >
> > > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
> > > > > > > single core CPU.
> >
> > And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment
> > would be to disable the EHCI (high speed USB) support in BIOS, to make
> > for a simpler hardware configuration, and see if that makes BIOS happier.
> > (Or better, just take EHCI out of your Linux config.) Likewise, taking
> > the 8042 drivers out of Linux.
> >
> > I wouldn't be surprised if those factors didn't matter, but it'd be good
> > to rule them out.
>
> I think the disabling of i8042 support might help.
Still hangs with "# CONFIG_SERIO_I8042 is not set".
> > > Dmitry, could you please have a look?
> > >
> > > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long
> > > > as USB legacy support is disabled (however without legacy support I
> > > > can't use the USB keyboard to control grub).
> > >
> > > I think using the 'shutdown' mode of suspend would be better. There's a
> > > little
> > > point in using 'platform' on desktop systems anyway.
> > >
> > > Frankly, I don't know what to do about it. If we move platform_finish()
> > > after
> > > device_resume(), some systems may be broken ...
> >
> > What I'm curious about is exactly why the patch matters. What ACPI
> > magic is being invoked to confuse, or unconfuse, those controllers?
>
> I think the patch helps, because it makes the ACPI magic be done while the
> i8042's .resume() is being executed.
>
> Which makes me think the following patch might help:
Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042.
> drivers/input/serio/i8042.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
> ===
> --- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07
> 12:15:19.0 +0200
> +++ linux-2.6.21-rc6/drivers/input/serio/i8042.c 2007-04-15
> 18:30:01.0 +0200
> @@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
> static int i8042_suspend(struct platform_device *dev, pm_message_t state)
> {
> if (dev->dev.power.power_state.event != state.event) {
> - if (state.event == PM_EVENT_SUSPEND)
> + if (state.event == PM_EVENT_SUSPEND
> + || state.event == PM_EVENT_PRETHAW)
> i8042_controller_reset();
>
> dev->dev.power.power_state = state;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
