Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2
On Mon, 2007-03-12 at 21:34 +1100, Con Kolivas wrote: On Monday 12 March 2007 20:38, Xavier Bestel wrote: On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote: On Monday 12 March 2007 19:55, Mike Galbraith wrote: Hmm. So... anything that's client/server is going to suffer horribly unless niced tasks are niced all the way down to 19? Fortunately most client server models dont usually have mutually exclusive cpu use like this X case. There are many things about X that are still a little (/me tries to think of a relatively neutral term)... wanting. :( I'd say the problem is less with X than with Xlib, which is heavily round-trip-based. Fortunately XCB (its successor) seeks to be more asynchronous. Yes I recall a talk by Keith Packard on Xorg development and how a heck of a lot of time spent spinning by X (?Xlib) for no damn good reason was the number one thing that made X suck and basically it was silly to try and fix that at the cpu scheduler level since it needed to be corrected in X, and was being actively addressed. So we should stop trying to write cpu schedulers for X. Excuse me for barging in. But. with latest xorg, xlib will be using xcb internally, which afaik should help matters a little, but furthermore, with the arrival of xcb, stuff are bound to change somewhat fast, and with abit more incentive(as in, real benefit on latest kernels), they are bound to change even faster. and if people upgrading to newest X(using xlib w/xcb) and applications being updated can help stuff out in the kernel, i'd say its best to push for that. Xav - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 00/18] Make common x86 arch area for i386 and x86_64 - Take 2
On Wed, 2007-03-14 at 01:08 -0400, Steven Rostedt wrote: [Hopefully fixed email client to make it to the list this time] [This series has changed by using git-diff -M] snip Seems appropriate, but I really don't care what it's called. One thing about this name, is that typing arch/x86Tab doesn't tab complete x86_64 anymore. But if you can think of something better, I'd be happy to apply it. sorry for being so late, but about what it could be called, well, what about common_x86 or common/x86 or something? snip -- Steve PS. Sorry for the spam. I need to figure out how to tame quilt mail! -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is RSDL an unfair scheduler too?
On Sat, 2007-03-17 at 21:13 -0500, Bill Davidsen wrote: Con Kolivas wrote: snip Now for something constructive... by any chance is Mike running KDE instead of GNOME? I only had a short time to play because I had to look at another problem in 2.6.21-rc3 (nbd not working), so the test machine is in use. But it looked as if behavior was not as smooth with KDE. May that thought be useful. Now i must say here, i use KDE, and have been testing 0.31, and i have been observing all the effects, in contrast with vanilla and staircase. this is on 2.6.20 I do not notice kde being slower, in fact i notice various interactivity speedups compared to mainline. first one i noticed(because i deliberately tested) was kicker. Kickers hide function was very very smooth during boot, and still is under load. It is not entirely as smooth under vanilla during boot(i suspect IO issue), under staircase it is, however under huge loads, it even is not smooth under staircase. then i started my konsole, and the one thing i immediately noticed was that zsh started instantly, usually i can see/(feel) zsh starting, as in it takes like 0.2 before my prompt comes. This is simply gone now with rsdl, behavior used to be the same in vanilla/rsdl. But the most interresting, and dare i say, completely unexpected things are much more important. I have for a long time had issues with tvtime, if i did stuff like move windows, tvtime would drop frames, or simply hovering javascript stuff on sites in konqueror, (this seemed to be introduced in 2.6.~5+), cause in EARLY 2.6 i did not have this problem, but it was the same in staircase and vanilla. But this is gone completely, tvtime no longer drops any frames when doing this. Another thing i noticed, which almost blew my mind as badly as with tvtime, was with wine, and world of warcraft(and nvidia blob driver, but this IS what many desktop users runs). While loading a level, the sound no longer skipped. This problem afaik, EVERYBODY which runs wine +wow has(unless they change the buffer size to ridicoulesly high which annoys gameplay). And more playing wow has shown me that rsdl seems to be doing an extremely good job of not letting other tasks interfere. For example i have spamasassin going quite very often (every minute, for lots of accounts), and this usually kills all sorts of high performance opengl stuff, causing severe stuttering, but with RSDL i only noticed my framerate dropping, but no strange stuttering as i usually experience, only lowered fps, which to me is quite natural, as spamasassin now has to use cpu. the last of my immediate observations are ktorrent. my ktorrent has LOTS of open fd's (in fact like ~5-6k), and the application tends to be very sluggish, but that is not so anymore. And now for the side effects i have observed. The only down right regression (which i wouldnt even call it, cause its a NATURAL thing when other stuff uses cpu) is that when i play a movie in kaffeine, and move the kaffeine window insanely fast all over the desktop, the audio skipped once, the strange thing is, even if i keep moving it, it does not skip any more, only the one time when you start to move it. But 720p h264 does take SOME cpu to decode, so i dont feel that this is unfair. i have however with X observed that under high load(720p h264 video playback, while doing video encoding, ktorrent running, and make running) that windows take longer time to redraw in X, if i move windows over each other, but not really a problem. another effect i have observed is that stuff does not stutter as much when under load, it simply gets slower.(but i suppose thats what i said when describing the good effects i have noticed) it should be noted that i have not reniced a single thing, and this is a singlecore amd64 2ghz with 1.5gb ram. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RSDL v0.31
On Sun, 2007-03-18 at 07:17 +0100, Mike Galbraith wrote: On Sat, 2007-03-17 at 23:55 +0300, Al Boldi wrote: Mike, I'm not saying RSDL is perfect, but v0.31 is by far better than mainline. Try this easy test: startx with the vesa driver run reflect from the mesa5.0-demos load 5 cpu-hogs start moving the mouse On my desktop, mainline completely breaks down, and no nicing may rescue. (hmm.. i would think that _renicing_ X would help that) On RSDL, even without nicing, the desktop is at least useable. So neither does a good job with this load. that sorely depends on what you mean by good job. It seems like what you call a good job is preserving the speed of the gui(X + apps which uses it) at _ALL_ costs to other stuff. -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote: On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: I'd recon KDE regresses because of kioslaves waiting on a pipe (communication with the app they're doing IO for) and then expiring. That's why splitting IO from an app isn't exactly smart. It should at least be ran in an another thread. Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. not really, only X sucks. KDE works atleast as good with rsdl as vanilla. i dont know how originally said kde works worse, wasnt it just someone that thought? -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RSDL v0.31
On Tue, 2007-03-20 at 08:16 -0700, Ray Lee wrote: On 3/20/07, Mark Lord [EMAIL PROTECTED] wrote: I've droppped it from my machine -- interactive response is much more important for my primary machine right now. Help out with a data point? Are you running KDE as well? If you are, then it looks like the common denominator that RSDL is handling poorly is client-server communication. (KDE's KIO slaves in this case, but X in general.) im not experiencing any problems with KDE. if anything ktorrent seems to be going a teeny tiny bit smoother, though its nothing i can back up with data. now i havent tested ALL kioslaves yet, but stuff like sftp, fish, tar and such works just as good. If so, one would hope that a variation on Linus's 2.5.63 pipe wakeup pass-the-interactivity idea could work here. The problem with that original patch, IIRC, was that a couple of tasks could bounce their interactivity bonus back and forth and thereby starve others. Which might be expected given there was no 'decaying' of the interactivity bonus, which means you can make a feedback loop. Anyway, looks like processes that do A - B - A communication chains are getting penalized under RSDL. In which case, perhaps I can make a test case that exhibits the problem without having to have the same graphics card or desktop as you. An easy-to-reproduce testcase would be good. Ray - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Mon, 2007-03-19 at 16:47 -0400, Bill Davidsen wrote: Kasper Sandberg wrote: On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote: On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: I'd recon KDE regresses because of kioslaves waiting on a pipe (communication with the app they're doing IO for) and then expiring. That's why splitting IO from an app isn't exactly smart. It should at least be ran in an another thread. Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. not really, only X sucks. KDE works atleast as good with rsdl as vanilla. i dont know how originally said kde works worse, wasnt it just someone that thought? It was probably me, and I had the opinion that KDE is not as smooth as GNOME with RSDL. I haven't had time to measure, but using for daily stuff for about an hour each way hasn't changed my opinion. Every once in a while KDE will KLUNK to a halt for 200-300ms doing mundane stuff like redrawing a page, scrolling, etc. I don't see it with GNOME. umm, could you try to find something that always does it, so i can try to reproduce? cause i dont really hit any such thing, and i only have a 2ghz amd64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: race condition in dm-crypt?
On Fri, 2007-03-23 at 21:41 +0100, Christoph Maier wrote: Jan C. Nordholz wrote: I think I'm experiencing a race condition: Irregularly my kernel runs into an Oops when it tries to initialize my crypt containers. FYI, there are similiar reports on the net, going as far back as May 2006: http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/1636 is the oldest one I could find. Bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=7388 I, too, ran into the bug and failed to reproduce it. However, it might be worth knowing that the system went to 100% iowait afterwards. Very interresting actually. I myself run dm-crypt and somewhat regularly my io stops for 5-10 seconds, with seemingly no errors or high load, io just stalls, and then returns after a while. Regards, Christoph Maier - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZFS with Linux: An Open Plea
On Fri, 2007-04-13 at 19:18 -0400, David R. Litwin 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 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). 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. This seems to me to be a rather uninformed, arrogant, and quite stupid comment. What are the thoughts of the Linux community? I appologise right now for my intrusion. I am a Linux-nobody; I freely admit it. I haven't even subscribed to this list (so do CC me) because I don't want to be over-whelmed with the list's glorious posts. But, part of Linux is it's being a community. If a member of this community (that is, a user of Linux) can't ask the others their thoughts and opinions, then the community has failed in a large respect. Take this letter as you will. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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, 2007-04-15 at 04:57 -0400, David R. Litwin wrote: On 15/04/07, Kasper Sandberg [EMAIL PROTECTED] wrote: On Fri, 2007-04-13 at 19:18 -0400, David R. Litwin wrote: 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. This seems to me to be a rather uninformed, arrogant, and quite stupid comment. Thank you, sir, for calling my comment stupid. Perhaps you are one of those FUSE folk. In that case, I would love for you to enlighten me as to why any one would bother attempting to port a file system when it is known that not only is it much slower than the slowest currently available to Linux, but also does not provide much of the functionality of the original product. Well first off, i dont believe anyone has ever prooved that an fuse filesystem on linux is inheritly much slower than the slowest filesystem on linux, in fact i believe this to be very far from the truth, and even if you are not able to squeeze the last bits of efficiency out, i doubt that its gonna be the cpu overhead that will kill your IO performance. ZFS-on-FUSE may not have all the features now, it may not ever get them, but its far from pointless, but whats even more pointless and silly, is you blindly acknowledging that you are uninformed and seeking information (which is okay enough), but at the same time calls stuff silly and unreal. As to uninformed, well, yes, I am uninformed; hence my request for you to inform me. And arrogant? I sure am. Cheers. -- —A watched bread-crumb never boils. —My hover-craft is full of eels. —[...]and that's the he and the she of it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [possible regression] 2.6.22 reiserfs/libata sporadically hangs on resume from hibernation
Sorry for top posting, but this is MAYBE a related matter, i am not sure. the thing is, i am running with libata and reiserfs on a raid5 with 6 disks, and after i changed to libata it has worked excellently (before it used to give DMA errors and then go boom). however now i sometimes, if theres some load on the array, see that the hdd leds go fully on, and for ~10sec to 1 min, all IO just stops complete, and after the time, it resumes and works perfectly. any ideas? and i also bring this up as it may give a clue as to what causes this. - I also use CFQ On Sun, 2007-09-02 at 15:29 +0400, Andrey Borzenkov wrote: On Sunday 01 July 2007, Rafael J. Wysocki wrote: On Saturday, 30 June 2007 23:34, Andrey Borzenkov wrote: On Sunday 01 July 2007, Rafael J. Wysocki wrote: On Saturday, 30 June 2007 06:59, Andrey Borzenkov wrote: Since 2.6.18 I do not have suspend to RAM; now I am starting to lose suspend to disk :) Environment - vanilla kernel (2.6.22-rc6 currently + squashfs + single pata_ali patch to switch off DMA on CD-ROM), single root on reiserfs, libata with pata_ali driver. Until 2.6.22-rc I never had problems with hibernation. With 2.6.22-rc system hung at least once in every rcX. Up to rc6 those lockups were absolutely silent (black screen without reaction to any key). In rc6 I just got something different. After resume I got on screem: swsusp: Marking nosave pages: 0009f000-0010 swsusp: Basic memory bitmaps created swsusp: Basic memory bitmaps freed After that it just sits there doing nothing. Ther was brief sound of HDD but I suspect it was related more to power-on. System was responding to power-on button press: ACPI Error (event-0305): No installed handler for fixed event [0002 20070125] And SysRq was functioning. That probably means that there's a deadlock somewhere in there. Unfortunately I do not have serial console so I copy manually stacks from several last screens of output; I have tried to make a photo but right now my kbluetooth is refusing to work at all so I cannot transfer them :( (but I suspect quality would be too bad anyway) laptop_mode D io_schedule+0xe/0x20 Looks suspicious to me. Can you identify what line of code this points to? If you could explain how to ... Michal has already done that. :-) [--snip--] I see you're using CFQ as the default IO scheduler. Can you please switch to AS and see if that changes anything? Sure, but given that I have no idea how to reproduce the lockup, we may never know whether it actually helped. Well, if the lockup never happens with AS, that will indicate something ... I thought it is gone but it just happened again with 2.6.23-rc5. I thought I have been running AS but no, I did use CFQ. Now I definitely switched to AS default; let's see ... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SD still better than CFS for 3d (was Re: 2.6.23-rc1)
On Sun, 2007-07-22 at 14:04 -0700, Linus Torvalds wrote: Ok, right on time, two weeks afetr 2.6.22, there's a 2.6.23-rc1 out there. And it has a *ton* of changes as usual for the merge window, way too much for me to be able to post even just the shortlog or diffstat on the mailing list (but I had many people who wanted to full logs to stay around, so you'll continue to see those being uploaded to kernel.org). Lots of architecture updates (for just about all of them - x86[-64], arm, alpha, mips, ia64, powerpc, s390, sh, sparc, um..), lots of driver updates (again, all over - usb, net, dvb, ide, sata, scsi, isdn, infiniband, firewire, i2c, you name it). Filesystems, VM, networking, ACPI, it's all there. And virtualization all over the place (kvm, lguest, Xen). Notable new things might be the merge of the cfs scheduler, and the UIO driver infrastructure might interest some people. Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. And this is despite many patches he sent me to try and tweak it. As far as im concerned, i may be forced to unofficially maintain SD for my own systems(allthough lots in the gaming community is bound to be interrested, as it does make games lots better) snip - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
(sorry for repost, but there seemed to have been some troubles..) On Sun, 2007-07-22 at 14:04 -0700, Linus Torvalds wrote: Ok, right on time, two weeks afetr 2.6.22, there's a 2.6.23-rc1 out there. And it has a *ton* of changes as usual for the merge window, way too much for me to be able to post even just the shortlog or diffstat on the mailing list (but I had many people who wanted to full logs to stay around, so you'll continue to see those being uploaded to kernel.org). Lots of architecture updates (for just about all of them - x86[-64], arm, alpha, mips, ia64, powerpc, s390, sh, sparc, um..), lots of driver updates (again, all over - usb, net, dvb, ide, sata, scsi, isdn, infiniband, firewire, i2c, you name it). Filesystems, VM, networking, ACPI, it's all there. And virtualization all over the place (kvm, lguest, Xen). Notable new things might be the merge of the cfs scheduler, and the UIO driver infrastructure might interest some people. Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. And this is despite many patches he sent me to try and tweak it. As far as im concerned, i may be forced to unofficially maintain SD for my own systems(allthough lots in the gaming community is bound to be interrested, as it does make games lots better) snip - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Fri, 2007-07-27 at 19:35 -0700, Linus Torvalds wrote: On Sat, 28 Jul 2007, Kasper Sandberg wrote: Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. And this is despite many patches he sent me to try and tweak it. You realize that different people get different behaviour, don't you? Maybe not. Sure. People who think SD was perfect were simply ignoring reality. Sadly, that seemed to include Con too, which was one of the main reasons that I never ended entertaining the notion of merging SD for very long at all: Con ended up arguing against people who reported problems, rather than trying to work with them. Im not saying its perfect, not at all, neither am i saying CFS is bad, surely CFS is much better than the old one, and i agree with what that university test you mentioned on kerneltrap says, that CFS and SD is basically impossible to feel difference in, EXCEPT for 3d under load, where CFS simply can not compete with SD, theres no but, this is how it has acted on every system ive tested, and YES, others reported it too, whether you choose to see it or not. and others people who run games on linux tells me the exact same thing, and i have had quite a few people try this. Andrew also reported an oops in the scheduler when SD was merged into -mm, so there were other issues. And whats the point here? If you are trying to pull the old Con just runs away, forget it, its a certainty that he would have put the required time into fixing whatever issues arise. As far as im concerned, i may be forced to unofficially maintain SD for my own systems(allthough lots in the gaming community is bound to be interrested, as it does make games lots better) You know what? You can do whatever you want to. That's kind of the point of open source. Keep people honest by having alternatives. True that But the the thing is, if you want to do a good job of doing that, here's a big hint: instead of keeping to your isolated world, instead of just talking about your own machine and ignoring other peoples machines and First off, i've personally run tests on many more machines than my own, i've had lots of people try on their machines, and i've seen totally unrelated posts to lkml, plus i've seen the experiences people are writing about on IRC. Frankly, im not just thinking of myself. issues and instead of just denying that problems may exist, and instead of attacking people who report problems, how about working with them? As i recall, there was only 1 persons reports that were attacked, and that was because the person repeatedly reported the EXPECTED behavior as broken, simply because it was FAIRLY allocating the cpu time, and this did not meet with the dudes expectations. And it was after multiple mails he was attacked That was where the SD patches fell down. They didn't have a maintainer that I could trust to actually care about any other issues than his own. You may not have been able to trust Con, but thats because you havent taken the time to actually really see whats been going on, if you just read the threads for SD you'd realize that he was more than willing to maintain it, after all, why do you think he wrote and submitted it? you think he just wrote it to piss you off by having it merged and leave? So here's a hint: if you think that your particular graphics card setup is the only one that matters, it's not going to be very interesting for anybody else. as explained earlier, its not just my particular setup, but actually that of alot of people, with lots of different hardware. [ I realize that this comes as a shock to some of the SD people, but I'm told that there was a university group that did some double-blind testing of the different schedulers - old, SD and CFS - and that everybody agreed that both SD and CFS were better than the old, but that there was no significant difference between SD and CFS. You can try asking Thomas Gleixner for more details. ] I'm happy that SD was perfect for you. It wasn't for others, and it had nobody who was even interested in trying to solve those issues. As a long-term maintainer, trust me, I know what matters. And a person who can actually be bothered to follow up on problem reports is a *hell* of a lot more important than one who just argues with reporters. Okay, i wasnt going to ask, but ill do it anyway, did you even read the threads about SD? Con was extremely polite to everyone, and he did work with a multitude of people, you seem to be totally deadlocked into the ONE incident with a person that was unhappy with SD, simply for being a fair scheduler. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo
Re: Linus 2.6.23-rc1
On Sat, 2007-07-28 at 10:50 -0700, Linus Torvalds wrote: On Sat, 28 Jul 2007, Kasper Sandberg wrote: First off, i've personally run tests on many more machines than my own, i've had lots of people try on their machines, and i've seen totally unrelated posts to lkml, plus i've seen the experiences people are writing about on IRC. Frankly, im not just thinking of myself. Ok, good. Has anybody tried to figure out why 3D games seem to be such a special case? I know Ingo looked at it, and seemed to think that he found and fixed something. But it sounds like it's worth a lot more discussion. Yes, but the various patches i've recieved seems to not solve it, it simply changed the load at which CFS seemed to perform well. On irc there has been wild speculation as to whether its the sched_yield() stuff in most 3d drivers, but my tests with stubbing it out, and altering behavior has not changed anything. Okay, i wasnt going to ask, but ill do it anyway, did you even read the threads about SD? I don't _ever_ go on specialty mailing lists. I don't read -mm, and I don't read the -fs mailing lists. I don't think they are interesting. And I tried to explain why: people who concentrate on one thing tend to become this self-selecting group that never looks at anything else, and then rejects outside input from people who hadn't become part of the mind meld. That's what I think I saw - I saw the reactions from where external people were talking and cc'ing me. And yes, it's quite possible that I also got a very one-sided picture of it. I'm not disputing that. Con was also ill for a rather critical period, which was certainly not helping it all. Con was extremely polite to everyone, and he did work with a multitude of people, you seem to be totally deadlocked into the ONE incident with a person that was unhappy with SD, simply for being a fair scheduler. Hey, maybe that one incident just ended up being a rather big portion of what I saw. Too bad. That said, the end result (Con's public gripes about other kernel developers) mostly reinforced my opinion that I did the right choice. But maybe you can show a better side of it all. I don't think _any_ scheduler is perfect, and almost all of the time, the RightAnswer(tm) ends up being not one or the other, but somewhere in between. It's not like we've come to the end of the road: the baseline has just improved. If you guys can show that SD actually is better at some loads, without penalizing others, we can (and will) revisit this issue. well, as far as my tests show, the only real difference between SD and CFS in terms of performance, is 3d, where both will deliver basically the same FPS in a given application, SD does it smooth, which is the best way to explain it, what happens with CFS, as i experience it, is that it seems to burstly allocate ressources. So what you should take away from this is that: from what I saw over the last couple of months, it really wasn't much of a decision. The difference in how Ingo and Con reacted to peoples reports was pretty stark. And no, I haven't followed the ck mailing list, and so yes, I obviously did get just a part of the picture, but the part I got was pretty damn unambiguous. I really think you should try read the SD and RSDL threads on lkml again, the only place where con havent been extremely fourthcoming was deep in the thread where Mike was unhappy with SD not giving X more prioity than fairness dictates.. But at the same time, no technical decision is ever written in stone. It's all a balancing act. I've replaced the scheduler before, I'm 100% sure we'll replace it again. Schedulers are actually not at all that important in the end: they are a very very small detail in the kernel. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Sun, 2007-07-29 at 01:41 +0200, Volker Armin Hemmann wrote: Hi, I never tried Con's patchset, for two reasons: I tried his 2.4 patches ones, and I never saw any improvements. So when people were reporting huge improvements with his SD scheduler, I compared that with the reports of huge improvements with his 2.4 kernel patches. Well thats a reason if there ever were one... ... The second: too many patches. I only would have tried one or two, but the ck-patchset is a lot bigger.. and I am a little bit uneasy about that. so use only the scheduler? nobody forces you to do many things.. But I tried a lot of Ingo's cfs patches - and it was a very pleasant experience. Ingo reacted very fast on my feedback and when I hit a problem he really tried to find the cause and solve it - and it always was one patch, so I felt a lot less scared ;) My usual workload is very 'usual'. KDE desktop, kmail, konqueror, sometimes xine or amarok providing some background noise while typing away in kate, triplea, wesnoth or some other game when I need to 'rest' for a while. A lot of compiling in the background, because I am one of these gentoo users. With cfs the experience was much more pleasant than with the 'old' scheduler. Compiling did not hurt as much as usual anymore - the only thing that hurts is swap But there is another thing I do regularly: I play ut2004. Not every single day, but sometimes several times a day. 20minutes of mayhem and then back to the desktop. And I do not see any problems with cfs and ut2004. The maximum FPS are indeed a little bit lower (and you can argue that this really is not important if the pre-game FPS in a level looking down on the floor go down from 390 to 380FPS), but the minimum FPS went up! well, surely CFS is better than the old vanilla scheduler, also with 3d, and if you have that high fps, i doubt you will notice the effects me and others are having. it is not that it is bad, its just not as good as SD has shown to be possible.. In scenes when my system is fighting hard to provide the FPS, when the action is high (like when fighting with half a douzend bots at a power node, while some other bots are shooting into the mess) CFS is much better than the old scheduler. It is a big difference if you get 6-10FPS or 15-25. (I am playing with maximum 'beautifullness' - I would be able to get a lot more FPS, if I wanted, but I want a nice scenery and maximum visual effects ...) From my point of view 3D is a lot better with cfs. Better than old vanilla yes, but than SD? well, you should give it a try. Now the question for all the people who are bashing cfs for its bad 3d performance: what am I doing wrong? As said, we never said CFS was worse than old vanilla, and we never said it was BAD, we did however say its not as good as SD :) Glück Auf, Volker - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Sun, 2007-07-29 at 17:04 +0200, Ingo Molnar wrote: hi Kasper, * Kasper Sandberg [EMAIL PROTECTED] wrote: Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. And this is despite many patches he sent me to try and tweak it. [...] hey, i thought you vanished from the face of the earth :-) The last email i got from you was more than 2 months ago, where you said that you'll try the latest CFS version as soon as possible but that you were busy with work. I sent 2 more emails to you about new CFS versions but then stopped pestering you directly - work _does_ take precedence over games =B-) I did respond to that one, but perhaps some mail have been getting lost, cause i cant find any more from you in my inbox. CFS v14, v15, v16, v17, v18 and v19 was released meanwhile, CFS v20 went upstream, there were no 3D related CFS regressions open for quite some time and because i never heard back from you i assumed everything's peachy. I must admit i havent tested the very very latest, will do In any case i'm glad you found the time to try CFS again, so please let me know in what way it regresses. In your most recent emails you did not indicate what specific problem you are having (and you did not reply to my last emails from May) - are your old regression reports against CFS v13 from May still true as of v2.6.23-rc1? If they are, could you please indicate which specific report of yours describes it best and send me (or upload to some webspace) the specific .config you are using on your box, and the cfs-debug-info.sh snapshot taken when you are running your game. (make sure you have CONFIG_SCHED_DEBUG=y enabled, for highest quality debug output) You can pick the script up from: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh Giving us that info would help us immensely with tracking down any CFS problem you might still be having. Sure. Or, if you feel adventurous enough to look into the internals of the kernel (which, considering your offer to take up SD maintenance, you must be ;-), here's my kernel latency tracer: Well, im not sure how good i would be at maintaining SD, my idea was more or less just do the bare minimum to get the thing running on newer kernels :) http://people.redhat.com/mingo/latency-tracing-patches/ ( see: latency-tracer-v2.6.23-rc1-combo.patch ) the simplest way to use it is to enable CONFIG_WAKEUP_TIMING, to set /proc/sys/kernel/preempt_max_latency back to 0 (after bootup) and to thus measure raw worst-case scheduler latencies - if you regularly see the kernel report above say 1000 usecs latencies to the syslog, on a PREEMPT kernel then there's definitely something foul going on. For example, that's how i found an audio playback latency problem in an early version of CFS: (sshd-14614|#1): new 5 us maximum-latency wakeup. ( ogg123-6603 |#1): new 6 us maximum-latency wakeup. ( ogg123-6608 |#1): new 6 us maximum-latency wakeup. (sshd-14614|#1): new 10 us maximum-latency wakeup. ( ogg123-6607 |#0): new 15 us maximum-latency wakeup. (events/0-9|#0): new 789 us maximum-latency wakeup. ( ogg123-6603 |#0): new 2566 us maximum-latency wakeup. Actually, now that you mention ogg123, i've had some bugs on CFS with this, i thought it was an ogg123 bug, but now that i remember it its only on CFS i have it.. when i run multiple ogg123 instances, suddenly they will just stop playing and lock up. This happens when someone writes alot fast to me on kopete, where i use ogg123 to play a bling sound.. that 2.5 msecs latency in the ogg123 task was definitely the sign of a kernel bug. If plain WAKEUP_TIMING does not show anything suspicious, you can use the latency tracer in more advanced ways as well to trace the whole system and figure out the precise cause of your game latencies - i'll be glad to help with that if no simpler measure helps. [see trace-it.c for some of those details.] [...] As far as im concerned, i may be forced to unofficially maintain SD for my own systems(allthough lots in the gaming community is bound to be interrested, as it does make games lots better) i'd encourage you to do it - in fact i already tried to prod Peter Williams into doing exactly that ;) The more reality checks a scheduler has, the better. [ Btw., after the obvious initial merging trouble it should be much easier to keep SD maintained against future upstream kernels due to the policy modularity that CFS introduces. (and which policy-modularity should also help reduce the size and complexity of the SD patch.) ] Thanks, Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL
Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Sun, 2007-07-29 at 19:06 +0200, Ingo Molnar wrote: * Kasper Sandberg [EMAIL PROTECTED] wrote: Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. [...] here's an update: checking whether Wine could be a factor in your problem i just tested latest CFS against latest SD with a 3D game running under Wine: v2.6.22-ck1 versus v2.6.22-cfsv19 (to get the most comparable kernel), using Quake 3 Arena Demo under Wine (0.9.41). Here are the results in a pretty graph: http://people.redhat.com/mingo/misc/cfs-vs-sd-wine-quake.jpg or, in text: 2.6.22-ck1 2.6.22-cfs-v19 quake + 0 loops | 41 fpsquake + 0 loops | 41 fps quake + 1 loop | 3 fpsquake + 1 loop | 41 fps quake + 2 loops | 2 fpsquake + 2 loops | 32 fps quake + 3 loops | 1 fpsquake + 3 loops | 24 fps quake + 4 loops | 0 fpsquake + 4 loops | 20 fps quake + 5 loops | 0 fpsquake + 5 loops | 16 fps Quake3-under-Wine behavior under SD/-ck: framerate breaks down massively during any kind of load. The game is completely unusable with 1 CPU loop running already! I run quake3 natively, ut2k4 natively, and world of warcraft under wine. Quake3-under-Wine behavior under CFS: framerate goes down gently with load, gameplay remains smooth. Framerate is still pretty acceptable and the game is playable even with a 500% CPU overload. The graph looks good and the framerate reduction goes roughly along the expected 1/n 'fairness curve' - so it all looks pretty healthy. [Note: quake3 keeps its fully 41 fps even with 1 competing loop running on the CPU due to sleeper fairness.] [ i've re-tested this using other SD and ck versions and other CFS versions such as v2.6.23-rc1 and the results are the same. To get the fps result i started a simple game scene: Single Player / Q3DM1 / I Can Win, turned on the fps display of Quake3, and did not move the player at all, just looked at the framerate that is displayed. (i also tried other scenes and other gameplay sections and they all behave consistently with the above results.) The system was otherwise completely idle. While i trust these numbers take them with a grain of salt, i'm obviously not neutral in this thing :-) ] so Kasper, i'll definitely need your help in tracking down your 3D smoothness problem under CFS. I have the feeling that it could be some odd factor that only hits your system, and once we've tracked that down there will be a simple solution that does not affect the totality of the scheduler. So far only you have reported any 3D game smoothness problem against recent CFS versions. (all 3D feedback has been positive, and that includes a number of gamers as well. Most of the 3D smoothness problems were fixed in CFS v13..v15 and it has not been reported to have regressed since then.) I believe the responsibility for my situation is both IO and cpu load. i dont know why SD does this. my test is to make spamasassin process mails while i have these applications running(and wine is most sensitive, the difference is almost negligable in the native applications, but very much noticable with wine+wow) could perhaps be filesystem related, i have my maildir(extremely large) on reiserfs, and /home on xfs. what my mail client will do is download mail, spamasassin it(loading database from home), then it will put to imap server placing it on reiserfs, and then a local copy in my home. while i only see the spamasassin thread as hogging cpu, i suspect IO is also to blame. 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Tue, 2007-07-31 at 10:57 +0200, Ingo Molnar wrote: * Peter Zijlstra [EMAIL PROTECTED] wrote: On Tue, 2007-07-31 at 01:46 +0200, Kasper Sandberg wrote: could perhaps be filesystem related, i have my maildir(extremely large) on reiserfs, and /home on xfs. what my mail client will do is download mail, spamasassin it(loading database from home), then it will put to imap server placing it on reiserfs, and then a local copy in my home. Ooh, do you perchance have PREEMPT_BKL=y? sorry late response. nope, i run totally without preemption, i did however test with, it seemed to not matter in terms of smoothness, but reduced the throughput slightly. If so, try on another filesystem than reiserfs (or disable PREEMPT_BKL, but that is obviously the lesser of the two choices). Ingo traced a 1+ second latency at my end to BKL priority inversion between tty and reiserfs. ah, indeed, that makes quite a bit of sense. Almost all of the Reiser3 code runs under the BKL, and the only other major kernel infrastructure that has BKL dependencies is the TTY code. Kasper, as a debugging matter, could you try to move that spamassassin workload off into a non-Reiser3 filesystem and/or disable PREEMPT_BKL? If that makes a noticeable difference (for the better ;) then we can continue figuring out what's happening exactly. the pricess is as this: mail client fetches mail mail client invokes spamasassin if spam - spam else filtering if it matches certain filters, it gets put into my imap server, which is reiserfs. 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] CFS scheduler, -v6
On Thu, 2007-04-26 at 10:41 -0400, Gene Heskett wrote: snip Compared to mainline? I still think this is a 100% keeper for desktop users like me. Here its alot worse, just playing an ogg with ogg123 even without anything reniced (X is 0), just pressing a link in konqueror can make audio skip (ogg123 fails to fill the alsa buffer, and thus it skips). this is something that simply does not happen for me on vanilla, staircase or SD. it just doesent seem to work properly.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: REPORT: sd-0.46 vs cfs-v6 vs mainline 2.6.21-rc7 Beryl + Video + Audio
On Thu, 2007-04-26 at 21:01 -0700, hechacker1 wrote: snip Overall: SD-0.46 is my new choice for scheduler. When not under load everything run's better or similarly to cfs or mainline. Under load however it shows the most responsiveness. Occasionally I had complete mouse freezes with cfs when the system was busy. But rarely. Under SD i haven't seen anything get starved. mainline surprisingly works better than i expected, but beryl suffers and responsiveness suffers under load. Your findings seems somewhat similar to mine, what i have observed is that SD is much more smooth, with vanilla/cfs, under just abit load opengl stuff will stutter, whereas with sd it will simply get slightly(or more, depending on the load) lower fps. --hechacker1 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v6
On Fri, 2007-04-27 at 13:55 +0200, Ingo Molnar wrote: * Ingo Molnar [EMAIL PROTECTED] wrote: update for lkml readers: this is some really 'catastrophic' condition triggering on your box. Here ogg123 just never skips on an older 750 MHz box, which is 4-5 times slower than your 2GHz box - while i have _fourty nice-0 infinite loops_ running. I.e. at this clearly ridiculous load, at just 2.5% of CPU time ogg123 is just chugging along nicely and never leaves out a beat. Kasper, just to exclude the possibility that this is somehow related to IO scheduling, could you copy the OGG file over to /dev/shm and play it from there? Do you still get the bad skips? Just copied to a tmpfs, and it still skips badly. in response to your question, Ingo, yes, i see those atleast 0 ms messages. I am not running esd, i use alsa directly from ogg123. but its not just ogg123, mplayer does it too. just moving a window can trigger it. even scrolling in my maillist causes it. and this ONLY happens on cfs, not vanilla, not staircase, not sd. while i look at top, the load average is 0.11 its definetly not an IO issue, cause i just tried creating some IO load, like reading files, it doesent skip, but moving windows triggers it better than anything(mplayer seems more sensitive than ogg123), it seems anything X-related makes it explode.. tried looking for buffer stuff in /proc/asound, couldnt find anything, im using the via82xx driver. 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] CFS scheduler, -v6
Okay so i've tried with cfs 7 now, and the completely broken audio behavior is fixed. The only things i really notice now is that gtk apps seems to redraw somewhat slower, and renicing X doesent seem to be able to bring it on par with SD or vanilla. And smoothness just doesent match SD, it may be abit better than vanilla/staircase, i cant really definitively say, but SD just has the smoothness factor which is extremely attractive. This is with 3d stuff, like through wine or natively on linux, under load(and even just minor things like using a browser or other things, like spamasassin), vanilla/staircase(not rsdl or sd)/cfs will go down in FPS, but at the same time stutter, it goes down to around the same fps under same load, as SD, but SD is completely smooth. Im not sure im describing properly, but say it takes 35fps for the 3d stuff to seem perfect, the fps monitor updates once every 1 or two seconds, showing average fps(havent looked at the code, but i assume it spans those 1-2 seconds), usually i have like 60 fps, but under load it can go down to 35, but under anything but SD its not smooth, it will do the 35 fps, but i suspect it does it in chunks, for example it will skip for 200 ms and then hurry to display the 35 frames. This means it does get the workload done, but not in a very plesant matter, and its here i see SD as being in such a high league that its really impossible to describe the results with any other word than Perfect. mvh. Kasper Sandberg - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v6
On Sun, 2007-04-29 at 08:59 +0200, Ingo Molnar wrote: * Willy Tarreau [EMAIL PROTECTED] wrote: I don't know if Mike still has problems with SD, but there are now several interesting reports of SD giving better feedback than CFS on real work. In my experience, CFS seems smoother on *technical* tests, which I agree that they do not really simulate real work. well, there are several reports of CFS being significantly better than SD on a number of workloads - and i know of only two reports where SD was reported to be better than CFS: in Kasper's test (where i'd like to know what the 3D stuff he uses is and take a good look at that workload), and another 3D report which was done against -v6. (And even in these two reports the 'smoothness advantage' was not dramatic. If you know of any other reports then please let me know!) I can tell you one thing, its not just me that has observed the smoothness in 3d stuff, after i tried rsdl first i've had lots of people try rsdl and subsequently sd because of the significant improvement in smoothness, and they have all found the same results. The stuff i have tested with in particular is unreal tournament 2004 and world of warcraft through wine, both running opengl, and consuming all the cpu time it can get. and the thing that happens is simply that even when theres only that process, sd is still smoother, but the significance is much larger once just something starts, like if the mail client starts fetching mail, and running some somewhat demanding stuff like spamasassin, the only way you notice it is by the drop in fps, smoothness is 100% intact with SD (ofcourse if you started HUGE load it probably would get so little cpu it would stutter), but with every other scheduler you will notice immediate and quite severe stuttering, in fact to many it will seem intolerable. I can tell you how I first noticed this, i was experimenting in ut2k4 with sd, and usually i always have to close my mail client, because when spamasassin starts (nice 0), the game would stutter quite much, but when i was playing i noticed some IO activity and work noises from my disk, but that was all, no noticable stutter or problems with the 3d, but i couldnt figure out why, i then discovered i had forgotten to close my mail client which i previously ALWAYS have had to do. If you have some ideas on how these problems might be fixed i'd surely try fixes and stuff, or if you have some data you need me to collect to better understand whats going on. But i suspect any somewhat demanding 3d application will do, and the difference is so staggering that when you see it in effect, you cant miss it. 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] CFS scheduler, -v6
On Sun, 2007-04-29 at 12:30 +0200, Thomas Gleixner wrote: Willy, snip As a sidenote: I really wonder if anybody noticed yet, that the whole CFS / SD comparison is so ridiculous, that it is not even funny anymore. CFS modifies the scheduler and nothing else, SD fiddles all over the kernel in interesting ways. have you looked at diffstat lately? :) sd: Documentation/sched-design.txt | 241 +++ Documentation/sysctl/kernel.txt | 14 Makefile|2 fs/pipe.c |7 fs/proc/array.c |2 include/linux/init_task.h |4 include/linux/sched.h | 32 - kernel/sched.c | 1279 +++- kernel/softirq.c|2 kernel/sysctl.c | 26 kernel/workqueue.c |2 11 files changed, 919 insertions(+), 692 deletions(-) cfs: Documentation/kernel-parameters.txt | 43 Documentation/sched-design-CFS.txt | 107 + Makefile|2 arch/i386/kernel/smpboot.c | 13 arch/i386/kernel/tsc.c |8 arch/ia64/kernel/setup.c|6 arch/mips/kernel/smp.c | 11 arch/sparc/kernel/smp.c | 10 arch/sparc64/kernel/smp.c | 36 fs/proc/array.c | 11 fs/proc/base.c |2 fs/proc/internal.h |1 include/asm-i386/unistd.h |3 include/asm-x86_64/unistd.h |4 include/linux/hardirq.h | 13 include/linux/sched.h | 94 + init/main.c |2 kernel/exit.c |3 kernel/fork.c |4 kernel/posix-cpu-timers.c | 34 kernel/sched.c | 2288 +--- kernel/sched_debug.c| 152 ++ kernel/sched_fair.c | 601 + kernel/sched_rt.c | 184 ++ kernel/sched_stats.h| 235 +++ kernel/sysctl.c | 32 26 files changed, 2062 insertions(+), 1837 deletions(-) This is worse than apples and oranges, it's more like apples and screwdrivers. snip tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v6
On Sun, 2007-04-29 at 13:11 +0200, Willy Tarreau wrote: On Sun, Apr 29, 2007 at 12:30:54PM +0200, Thomas Gleixner wrote: snip Contrarily to most people, I don't see them as competitors. I see SD as a first step with a low risk of regression, and CFS as an ultimate solution relying on a more solid framework. See this is the part i dont understand, what makes CFS the ultimate solution compared to SD? snip Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v6
On Sun, 2007-04-29 at 14:13 +0200, Thomas Gleixner wrote: On Sun, 2007-04-29 at 14:00 +0200, Kasper Sandberg wrote: On Sun, 2007-04-29 at 13:11 +0200, Willy Tarreau wrote: On Sun, Apr 29, 2007 at 12:30:54PM +0200, Thomas Gleixner wrote: snip Contrarily to most people, I don't see them as competitors. I see SD as a first step with a low risk of regression, and CFS as an ultimate solution relying on a more solid framework. See this is the part i dont understand, what makes CFS the ultimate solution compared to SD? SD is a one to one replacement of the existing scheduler guts - with a different behaviour. CFS is a huge step into a modular and hierarchical scheduler design, which allows more than just implementing a clever scheduler for a single purpose. In a hierarchical scheduler you can implement resource management and other fancy things, in the monolitic design of the current scheduler (and it's proposed replacement SD) you can't. But SD can be made one of the modular variants. But all these things, arent they just in the modular scheduler policy code? and not the actual sched_cfs one? tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v6
On Sun, 2007-04-29 at 08:42 -0700, Ray Lee wrote: On 4/29/07, Kasper Sandberg [EMAIL PROTECTED] wrote: On Sun, 2007-04-29 at 08:59 +0200, Ingo Molnar wrote: well, there are several reports of CFS being significantly better than SD on a number of workloads - and i know of only two reports where SD was reported to be better than CFS: in Kasper's test (where i'd like to know what the 3D stuff he uses is and take a good look at that workload), and another 3D report which was done against -v6. (And even in these two reports the 'smoothness advantage' was not dramatic. If you know of any other reports then please let me know!) I can tell you one thing, its not just me that has observed the smoothness in 3d stuff, after i tried rsdl first i've had lots of people try rsdl and subsequently sd because of the significant improvement in smoothness, and they have all found the same results. The stuff i have tested with in particular is unreal tournament 2004 and world of warcraft through wine, both running opengl, and consuming all the cpu time it can get. [snip more of sd smoother than cfs report] WINE is an interesting workload as it does most of its work out of process to the 'wineserver', which then does more work out of process to the X server. So, it's three mutually interacting processes total, once one includes the original client (Unreal Tournament or World of Warcraft, in this case). the wineserver process is using next to no cpu-time compared to the main process.. Perhaps running one of the windows system performance apps (that can be freely downloaded) under WINE would give some hard numbers people could use to try to reproduce the report. Ray - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] hotplug-ng 001 release
hey greg i remember for some months back, you posted something similar.. is this a version thats ready for use? if it is! im gonna use it! :D On Thu, 2005-02-10 at 16:52 -0800, Greg KH wrote: On Thu, Feb 10, 2005 at 04:40:33PM -0800, Greg KH wrote: I'd like to announce, yet-another-hotplug based userspace project: linux-ng. Bah. The name is hotplug-ng. Sorry about that... greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
On Thu, 2005-02-10 at 22:41 -0800, Greg KH wrote: On Fri, 2005-02-11 at 02:30 +0100, Kasper Sandberg wrote: hey greg i remember for some months back, you posted something similar.. is this a version thats ready for use? if it is! im gonna use it! :D Yes, this is that version, cleaned up and given a proper build system, and even tested on my machines here :) ah cool. and in that case, you probably also have ebuilds for it, if you do, please post them somewhere :) thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
On Fri, 2005-02-11 at 09:06 -0800, Greg KH wrote: On Fri, Feb 11, 2005 at 12:47:07PM +0100, Kasper Sandberg wrote: On Thu, 2005-02-10 at 22:41 -0800, Greg KH wrote: On Fri, 2005-02-11 at 02:30 +0100, Kasper Sandberg wrote: hey greg i remember for some months back, you posted something similar.. is this a version thats ready for use? if it is! im gonna use it! :D Yes, this is that version, cleaned up and given a proper build system, and even tested on my machines here :) ah cool. and in that case, you probably also have ebuilds for it, if you do, please post them somewhere :) I don't have an ebuild for it yet, but it's on my list to get done. And when I do so, it will just show up in the normal gentoo tree. The main issue with this is I need to create a virtual for the hotplug service so it doesn't conflict with the existing hotplug package. Not a big deal, just not as simple as adding a single ebuild to the tree. just make it provide virtual/hotplug, then do a fgrep -r hotplug /usr/portage/ and then replace with virtual/hotplug ;) thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs+acl makes processes hang?
confirmed, i run 2.6.12 with reiserfs, created with reiserfsprogs 3.6.19 On Fri, 2005-07-15 at 23:19 +, Tarmo Tänav wrote: Hi, I think I've found a bug in reiserfs acls. If triggered it means that any program trying to access the partition, where the bug occured, will just hang in D state, with no way to kill the program. Here's how to reproduce: 1. mount a reiserfs volume (loopmount will do) with -o acl. 2. create a directory dir 3. set some default acl: setfacl -d -m u:username:rwX dir 4. cd dir 5. dd if=/dev/zero of=somefile1 bs=4k count=10 (the idea is to run out of space) 6. now df should show 0 free space, if not then repeat 5. 7. echo 1 somefile2 # this should hang infinitely Now no program will be able to access the partition. I haven't tried to reproduce it, but the same problem also happened when a user hit his hard quota limit on my server. Then no program could access his homedir. PS. I'm not subscribed to lkml so please CC -- Tarmo Tänav [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
inotify - i dont get a inotify device
hello.. i have a small problem with inotify in kernel 2.6.13-rc3-git4 - i do not get the inotify device, i know i build it in, gzcat /proc/config.gz | grep -i inotify confirms it, and i have a very new udev, where inotify is in the rules file, i tried udevstart but it did not create me the inotify device.. anyone that can help? perhaps a fix is known? -- Kasper Sandberg [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DVD burning still have problems
On Mon, 2005-01-24 at 16:07 +0100, Jens Axboe wrote: On Sun, Jan 23 2005, Alessandro Suardi wrote: On Sun, 23 Jan 2005 21:26:55 +0100, Volker Armin Hemmann [EMAIL PROTECTED] wrote: Hi, have you checked, that cdrecord is not suid root, and growisofs/dvd+rw-tools is? I had some probs, solved with a simple chmod +s growisofs :) Lucky you. Burning as root here, cdrecord not suid. Tried also burning with a +s growisofs, but... 794034176/4572807168 (17.4%) @2.4x, remaining 18:47 805339136/4572807168 (17.6%) @2.4x, remaining 18:42 :-[ [EMAIL PROTECTED] failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error builtin_dd: 396976*2KB out @ average 2.4x1385KBps :-( write failed: Input/output error As with the original report, the drive is sending back a write error to the issuer. Looks like bad media. when i do the following: 1: get a brand new 25pack box. 2: burn with my 2.6.11-rc1-bk9, and it fails 3: boot 2.6.9-rc1 and -rc4, and it works perfectly i find it extremely unlikely that the dvd's (of the same pack) i try on a newer kernel than 2.6.9-rcX just happens to be the faulty ones.. especially since other persons report aswell.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DVD burning still have problems
On Mon, 2005-01-24 at 11:46 +1000, Tim Fairchild wrote:
On Monday 24 Jan 2005 06:59, Alessandro Suardi wrote:
On Sun, 23 Jan 2005 21:26:55 +0100, Volker Armin Hemmann
[EMAIL PROTECTED] wrote:
Hi,
have you checked, that cdrecord is not suid root, and
growisofs/dvd+rw-tools is?
I had some probs, solved with a simple chmod +s growisofs :)
Lucky you. Burning as root here, cdrecord not suid. Tried also
burning with a +s growisofs, but...
You can test if it's the kernel/growisofs clashing by hacking the
drivers/block/scsi_ioctl.c code
It's around line 193 in 2.6.9, and line 196 in 2.6.10
not sure about 2.6.11
at line 196
find the code:
/* Write-safe commands just require a writable open.. */
if (type CMD_WRITE_SAFE) {
if (file-f_mode FMODE_WRITE)
return 0;
}
edit it to something like:
/* Write-safe commands just require a writable open.. */
if (type CMD_WRITE_SAFE) {
printk (Write safe command in );
if (file-f_mode FMODE_WRITE)
printk (write mode.\n);
else
printk (read mode.\n);
return 0;
}
Compile the kernel with that and that may make it work and burn dvd and let
you know if it's growisofs sending incorrect commands. You'll get messages in
dmesg like
Write safe command in read mode.
which means growisofs is still not right. Maybe later version fixed this?
i got the latest version, and i just did this, nothing of this appeared
in dmesg, but also, i dont see what scsi_ioctl has to do with anything?
i dont use scsi emulation
tim
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: DVD burning still have problems
On Mon, 2005-01-24 at 21:44 +, Alan Cox wrote: On Llu, 2005-01-24 at 20:45, Jens Axboe wrote: I've got several reports like this that only happen with ACPI, and one user whose burns report fine but are corrupted if ACPI is allowed to do power manglement. Really weird, I cannot begin to explain that. Perhaps the two reporters in this thread can try it as well? I can sort of guess - the CPU frequency changes (either from ACPI or perhaps also from cpuspeed if in use ?) involve the CPU disconnecting from the bus and reconnecting. There is much magic involved in this and there are certainly chipset and CPU errata in this area. would this mean that i should not use cpu frequency scaling? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DVD burning still have problems
On Mon, 2005-01-24 at 23:48 +, Alan Cox wrote: On Llu, 2005-01-24 at 23:01, Kasper Sandberg wrote: there are certainly chipset and CPU errata in this area. would this mean that i should not use cpu frequency scaling? Worth an experiment but I'd be suprised if it was your fix. The more data the better however I disabled cpufreq in the kernel, acpi i still have in kernel.. when i booted i did acpi=off, and changed IO scheduler to anticipatory i just burned a DVD, and it works ;D pretty neat, im not sure what caused it. but im glad.. i still have the small change in scsi_ioctl.h, however nothing appears in dmesg.. gonna burn one more dvd in a little bit, if it doesent work, i will let you know, if you dont hear more about it, assume it works :DD btw: the reason i changed to anticipatory from cfq is that i noticed that sometimes the speed dropped abit, and thought it might have something to do with it, and, with as it did not - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DVD burning still have problems
On Fri, 2005-01-28 at 14:47 +0100, Jens Axboe wrote: On Fri, Jan 28 2005, Kasper Sandberg wrote: On Mon, 2005-01-24 at 23:48 +, Alan Cox wrote: On Llu, 2005-01-24 at 23:01, Kasper Sandberg wrote: there are certainly chipset and CPU errata in this area. would this mean that i should not use cpu frequency scaling? Worth an experiment but I'd be suprised if it was your fix. The more data the better however I disabled cpufreq in the kernel, acpi i still have in kernel.. when i booted i did acpi=off, and changed IO scheduler to anticipatory i just burned a DVD, and it works ;D pretty neat, im not sure what caused it. but im glad.. i still have the small change in scsi_ioctl.h, however nothing appears in dmesg.. gonna burn one more dvd in a little bit, if it doesent work, i will let you know, if you dont hear more about it, assume it works :DD btw: the reason i changed to anticipatory from cfq is that i noticed that sometimes the speed dropped abit, and thought it might have something to do with it, and, with as it did not That's interesting, a short io starvation could for sure cause it. I would really appreciate if you could try one change at the time though, right now it's not really clear if it's acpi or the io scheduler. well.. all good things must come to an end.. the second dvd i burned failed.. :( this is really frustrating.. but im pretty pretty sure its not media error.. perhaps i must reboot after each burn again.. anyway, it is nice knowing everything isnt completely lost :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DVD burning still have problems
first, sorry for posting so much :| On Fri, 2005-01-28 at 15:05 +0100, Kasper Sandberg wrote: On Fri, 2005-01-28 at 14:47 +0100, Jens Axboe wrote: On Fri, Jan 28 2005, Kasper Sandberg wrote: On Mon, 2005-01-24 at 23:48 +, Alan Cox wrote: On Llu, 2005-01-24 at 23:01, Kasper Sandberg wrote: there are certainly chipset and CPU errata in this area. would this mean that i should not use cpu frequency scaling? Worth an experiment but I'd be suprised if it was your fix. The more data the better however I disabled cpufreq in the kernel, acpi i still have in kernel.. when i booted i did acpi=off, and changed IO scheduler to anticipatory i just burned a DVD, and it works ;D pretty neat, im not sure what caused it. but im glad.. i still have the small change in scsi_ioctl.h, however nothing appears in dmesg.. gonna burn one more dvd in a little bit, if it doesent work, i will let you know, if you dont hear more about it, assume it works :DD btw: the reason i changed to anticipatory from cfq is that i noticed that sometimes the speed dropped abit, and thought it might have something to do with it, and, with as it did not That's interesting, a short io starvation could for sure cause it. I would really appreciate if you could try one change at the time though, right now it's not really clear if it's acpi or the io scheduler. well.. all good things must come to an end.. the second dvd i burned failed.. :( this is really frustrating.. but im pretty pretty sure its not media error.. perhaps i must reboot after each burn again.. anyway, it is nice knowing everything isnt completely lost :) i just rebooted, (and booted with acpi off, anticipatory like before) and burned a DVD, and it works.. this means that when acpi is disabled, cpufreq off, i have the same problems i initially had with earlier kernels (2.6.9-rc*) that is: i could burn 1 dvd, which works fine, then the next i burn fails, with io error, then the third i burns works.. in short, every second works.. unless i reboot after each, then no one fails.. its a insanely strange problem. :) but atleast im able to get abit free hd space 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/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE][RFC] plugsched-2.0 patches ...
its nice to see that this project is not dead after all :DD On Thu, 2005-01-20 at 12:23 +1100, Peter Williams wrote: ... are now available from: http://prdownloads.sourceforge.net/cpuse/plugsched-2.0-for-2.6.10.patch?download as a single patch to linux-2.6.10 and at: http://prdownloads.sourceforge.net/cpuse/plugsched-2.0-for-2.6.10.patchset.tar.gz?download snip Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
DVD burning still have problems
hello, i followed the last thread, unable to burn DVD, and there was a patch, which was said to work, but it does not.. (i am running 2.6.11-rc1-bk9).. the problem started around 2.6.9 (or something like it), when i was only able to burn 1 dvd, then i had to restart before i could burn another (or every second dvd i burn would fail), the error i get is input/output error.. my burner is working perfect, since it works on windows, and on 2.6.9-rcSomething. it is not a specific place in the burning process it fails, sometimes at 10%, and sometimes at 97% burning normal cd's works perfectly now on 2.6.10 and 2.6.11-later i cant burn dvd's at all, every time i try to burn one, it fails, i have tried different speeds and media, same thing, i got a Liteon sohw1213S dvd duallayer burner, allthough im not using duallayer media. here is a log from a burning i just tried: /dev/hda: engaging DVD-R DAO upon user request... /dev/hda: reserving 2149200 blocks /dev/hda: Current Write Speed is 4.1x1385KBps. 0.02% done, estimate finish Tue Jan 25 13:20:53 2005 0.05% done, estimate finish Mon Jan 24 15:13:15 2005 snip 83.66% done, estimate finish Sun Jan 23 16:50:47 2005 83.68% done, estimate finish Sun Jan 23 16:50:47 2005 83.71% done, estimate finish Sun Jan 23 16:50:46 2005 :-[ [EMAIL PROTECTED] failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error :-( write failed: Input/output error /dev/hda: flushing cache this is simply what happens :( i have tried with and without pktcdvd loaded, same result, i hope someone can help me thanks - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
On Fri, 2005-09-02 at 15:34 -0700, Andrew Morton wrote: Miklos Szeredi [EMAIL PROTECTED] wrote: Hi Andrew! Do you plan to send FUSE to Linus for 2.6.14? snip i use fuse too, and i like it, it works good, and its quite fast and easy. it has given me no problems at all, i suggest merging, it harms nothing, and seems to be well maintained To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/
BUG, 2.6.20-rc3 raid autodetection
Hello. i just attempted to test .20-rc3-git4 on a box, which has 6 drives in raid5. it uses raid autodetection, and 2 ide controllers (via and promise 20269). there are two problems. first, and most importantly, it doesent autodetect, i attempted with both the old ide drivers, and the new pata on libata drivers, the drives appears to be found, but the raid autoassembling just doesent happen. this is .17, which works: http://sh.nu/p/8001 this is .20-rc3-git4 which doesent work, in pata-on-libata mode: http://sh.nu/p/8000 this is .20-rc3-git4 which doesent work, in old ide mode: http://sh.nu/p/8002 second bug: notice on these pastes the lines at bottom, the keyboard stuff, these are repeated constantly, and caps/scrolllock button on keyboard is blinking. mvh. Kasper Sandberg - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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, 2.6.20-rc3 raid autodetection
On Thu, 2007-01-04 at 20:07 +0100, Bartlomiej Zolnierkiewicz wrote: On 1/4/07, Kasper Sandberg [EMAIL PROTECTED] wrote: Hello. i just attempted to test .20-rc3-git4 on a box, which has 6 drives in raid5. it uses raid autodetection, and 2 ide controllers (via and promise 20269). there are two problems. first, and most importantly, it doesent autodetect, i attempted with both the old ide drivers, and the new pata on libata drivers, the drives appears to be found, but the raid autoassembling just doesent happen. this is .17, which works: http://sh.nu/p/8001 this is .20-rc3-git4 which doesent work, in pata-on-libata mode: http://sh.nu/p/8000 this is .20-rc3-git4 which doesent work, in old ide mode: http://sh.nu/p/8002 For some reason IDE disk driver is not claiming IDE devices. Could you please double check that IDE disk driver is built-in (CONFIG_BLK_DEV_IDEDISK=y in the kernel configuration) and not compiled as module? i need not check even once, i do not have module support enabled, so everything 100% surely is built in. this is the case for .17 too (and earlier, this box was started with .15 i think.) Bart - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG, 2.6.20-rc3 raid autodetection
On Thu, 2007-01-04 at 23:05 +0100, Bartlomiej Zolnierkiewicz wrote: On 1/4/07, Kasper Sandberg [EMAIL PROTECTED] wrote: On Thu, 2007-01-04 at 22:06 +0100, Bartlomiej Zolnierkiewicz wrote: On 1/4/07, Kasper Sandberg [EMAIL PROTECTED] wrote: On Thu, 2007-01-04 at 21:07 +0100, Bartlomiej Zolnierkiewicz wrote: On 1/4/07, Kasper Sandberg [EMAIL PROTECTED] wrote: On Thu, 2007-01-04 at 20:07 +0100, Bartlomiej Zolnierkiewicz wrote: On 1/4/07, Kasper Sandberg [EMAIL PROTECTED] wrote: Hello. i just attempted to test .20-rc3-git4 on a box, which has 6 drives in raid5. it uses raid autodetection, and 2 ide controllers (via and promise 20269). there are two problems. first, and most importantly, it doesent autodetect, i attempted with both the old ide drivers, and the new pata on libata drivers, the drives appears to be found, but the raid autoassembling just doesent happen. this is .17, which works: http://sh.nu/p/8001 this is .20-rc3-git4 which doesent work, in pata-on-libata mode: http://sh.nu/p/8000 this is .20-rc3-git4 which doesent work, in old ide mode: http://sh.nu/p/8002 For some reason IDE disk driver is not claiming IDE devices. Could you please double check that IDE disk driver is built-in (CONFIG_BLK_DEV_IDEDISK=y in the kernel configuration) and not compiled as module? i need not check even once, i do not have module support enabled, so OK everything 100% surely is built in. this is the case for .17 too (and earlier, this box was started with .15 i think.) Could you send me your config? I'll try to reproduce this locally. sure thing. http://sh.nu/p/8004 -- .17 working CONFIG_BLK_DEV_IDEDISK=y http://sh.nu/p/8005 -- .20-rc3-git4 nonworking, idemode, the one with libata i dont have anymore, but the only difference is that i use the libata drivers, but as its same result, shouldnt matter # CONFIG_BLK_DEV_IDEDISK is not set so not everything is 100% surely built-in ;) i see your point, im afraid i may have misinterpreted you, since you said and not compiled as module, so i thought you meant i had to make sure it wasnt moduled only. You were right - I forgot about CONFIG_BLK_DEV_IDEDISK=n case. i will try with this now, what about pataonlibata, do i need this for Please report if this fixes the issue. yeah it did. that too? for libata you need SCSI disk driver: CONFIG_BLK_DEV_SD=y [ libata is not independent subsystem like IDE but depends on SCSI, and I really don't know why this is not mentioned in config help ] i knew that, i just thought it may select what it required, though i can see that it isnt strictly required, just what one wishes often. :) thanks for your help, will try with libata 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/
libata error handling
Hello.
i have a question in regards to libata's error handling, specifically
with pata drivers.
ill start by explaining something that happens to me using the normal
ide drivers (via ide and pdc202 new)
this is what i get when it has been used for a while:
hde: dma_intr: bad DMA status (dma_stat=75)
hde: dma_intr: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hde: dma_timer_expiry: dma status == 0x60
hde: DMA timeout retry
PDC202XX: Primary channel reset.
hde: timeout waiting for DMA
its ALWAYS hde, and its on the promise controller, i attempted to
replace the promise controller by other controllers, but i got the same
error. i have tried replacing cables too, and swapping around
harddrives, its ALWAYS the last harddrive that gets me this. after this,
my raid (6x300gb drives in raid5) would go nuts, as if the data was
there, but skewed, so i got it all from an offset.
this has been going on since always on this box, from .15 to .17, but
now i updated to .20-rc3-git4, and went over to the pata-on-libata
drivers, where i think this has stopped, or atleast, its not causing
WEIRD errors anymore, i have observed some stalls, but im not sure this
is due to it doing this, or simply syncing. i get no messages like this
from the kernel anymore.
i have heard that libata has much better error handling (this is what
made me try it), and from initial observations, that appears to be very
true, however, im wondering, is there something i can do to get
extremely verbose information from libata? for example if it corrects
errors? cause i'd really like to know if it still happens, and if i
perhaps get corruption as before, even though not severe.
Regards,
Kasper Sandberg
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: libata error handling
On Sat, 2007-01-06 at 12:21 -0600, Robert Hancock wrote: Kasper Sandberg wrote: i have heard that libata has much better error handling (this is what made me try it), and from initial observations, that appears to be very true, however, im wondering, is there something i can do to get extremely verbose information from libata? for example if it corrects errors? cause i'd really like to know if it still happens, and if i perhaps get corruption as before, even though not severe. Any errors, timeouts or retries would be showing up in dmesg.. how sure can i be of this? is it 100% sure that i have not encountered this error then? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata error handling
On Sat, 2007-01-06 at 13:01 -0600, Robert Hancock wrote: Kasper Sandberg wrote: On Sat, 2007-01-06 at 12:21 -0600, Robert Hancock wrote: Kasper Sandberg wrote: i have heard that libata has much better error handling (this is what made me try it), and from initial observations, that appears to be very true, however, im wondering, is there something i can do to get extremely verbose information from libata? for example if it corrects errors? cause i'd really like to know if it still happens, and if i perhaps get corruption as before, even though not severe. Any errors, timeouts or retries would be showing up in dmesg.. how sure can i be of this? is it 100% sure that i have not encountered this error then? Pretty sure, I'm quite certain libata never does any silent error recovery.. okay, i suppose i face two possibilities then: 1: libata drivers are simply better, and the error does not occur because of driver bugs in the old ide drivers 2: it hasnt happened to me on libata yet (though this is also abit weird, as it has now ran far longer than were previously required to hit the errors) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata error handling
On Sat, 2007-01-06 at 20:28 +0100, Bartlomiej Zolnierkiewicz wrote: On 1/6/07, Kasper Sandberg [EMAIL PROTECTED] wrote: On Sat, 2007-01-06 at 13:01 -0600, Robert Hancock wrote: Kasper Sandberg wrote: On Sat, 2007-01-06 at 12:21 -0600, Robert Hancock wrote: Kasper Sandberg wrote: i have heard that libata has much better error handling (this is what made me try it), and from initial observations, that appears to be very true, however, im wondering, is there something i can do to get extremely verbose information from libata? for example if it corrects errors? cause i'd really like to know if it still happens, and if i perhaps get corruption as before, even though not severe. Any errors, timeouts or retries would be showing up in dmesg.. how sure can i be of this? is it 100% sure that i have not encountered this error then? Pretty sure, I'm quite certain libata never does any silent error recovery.. AFAIR this is true (at least it was last time that I've looked at libata eh code) okay, i suppose i face two possibilities then: 1: libata drivers are simply better, and the error does not occur because of driver bugs in the old ide drivers very likely however pdc202xx_new bugs should be fixed in 2.6.20-rc3 (as it contains a lot of bugfixes for this driver from Sergei Shtylyov) these fixes are also in the libata driver? 2: it hasnt happened to me on libata yet (though this is also abit weird, as it has now ran far longer than were previously required to hit the errors) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gaming Interface
On Mon, 2007-01-08 at 16:36 +0100, Dirk wrote: Helge Hafting wrote: Dirk wrote: Jay Vaughan wrote: At 13:13 +0100 8/1/07, Dirk wrote: Trent Waddington wrote: Call me crazy, but game manufacturers want directx right? You aint running that in the kernel. They want something like DirectX that changes it's API less frequent than DirectX and that compiles as a module because you don't want to run it in the kernel. Whats wrong with just using SDL/OpenGL? Thousands of games are made with SDL/OpenGL, and there are realms of Linux usage where this works just fine, especially for games (GP2X, etc). In case you didn't notice, plenty of pro Game Developers use SDL/OpenGL just fine for their needs, and get the job done without grumbling and groaning about needing to have their hands held through the process. But I don't see top titles ported to SDL/OpenGL. Tough luck then - openGL is the standard gaming interface on linux, well for the 3D graphichs part at least. You already have this, so having a standard clearly isn't enough then. More titles will be ported to linux when linux becomes more popular as a home platform. It is that simple. And then it will happen no matter what the interface will be. Although I believe it will still be opengl - opengl is nice and don't need to change. Also, the fact that it isn't in the _kernel_ doesn't matter at all. It is in the standard distributions - that is what matters. You must take into account with what kind of people you're dealing with. It's not the pro Game Develpers who make decisions. It's the people who completely rely on words who ake decisions. So, if you tell them that there will be a _official_ API on Kernel level which will be available on all 300+ Linux distributions they will understand that they're dealing with something they can rely on. Wrong. This kind of people worry about market share and so they decide on windows games for that reason alone. They don't know SDL. And most of these characters think OpenGL is dead. It is wrong - it might be dead _on windows_ because windows have directx as well as a less useful opengl. That's arrogant, I know. They choice about what stuff they care is made by big words and statements, not by their competence. Then you won't get support here - nobody cares about big words here. I fail to see the reason this requirement has to be a 'kernel' interface, other than pure sheer laziness and inability to grok on the part of the so-called professional Game Developers. That's exactly what I'm talking about. They're lazy and dumb. So they need something where they can say: Hey, that is one interface that doesn't change every couple of month. I can try to wrap my lazy brain around it with a good feeling. 1. Linux don't support the lazy and dumb. Won't happen. 2. Even the lazy and dumb can use nice standardized unchanging interfaces - provided by a library rather than the kernel. It is not harder to do in any way. Gaming is only *one* kind of application for the Linux kernel - shall we burden the kernel with everything everyone wants just because people fail to understand the proper way to assemble a Linux-based kit for their specific application needs? (Hint: work with the distro builders.) Yes. Exactly. There is already code for very specific tasks in the kernel. A module that acts as a i-will-never-change-my-api-and-will-be-available-on-EVERY-linux-because i'm-part-of-the-kernel wrapper for video, sound and events dedicated to the gaming folks wouldn't hurt. Such a thing is nice - but it don't need to be in the kernel. Try to understand that! An interface set in stone can be provided by a standard library that all distros pick up. (No distro will skip an important library, that way they get behind the other distros.) The advantage of this is that such a library can keep the game programmers interface constant even when the kernel interfaces are mercilessly changed. And yes - they _will_ change. Everytime that happens, people here laugh at commercial actors getting in trouble. (Example - the tradition of ruthlessly breaking the binary-only modules from ati, nvidia, vmware...) Just my .2c, but anyone suggesting that API's be crowbar'ed into the kernel just to make it easier to get what you want from a single source is probably not as familiar with the underlying technology, nor the reasons for its structured organization, as they ought to be before making such suggestions .. I'm just guessing that the real problem of Linux gaming is that developers must get it that there is an official way to port games to linux w/o toolongdidntread, ever changing API's or as many different problems as there are distributions. Sure, and that official way is to use support
Re: Gaming Interface
On Tue, 2007-01-09 at 08:22 +0100, Dirk wrote: Kasper Sandberg wrote: On Mon, 2007-01-08 at 16:36 +0100, Dirk wrote: Helge Hafting wrote: Dirk wrote: Jay Vaughan wrote: At 13:13 +0100 8/1/07, Dirk wrote: Trent Waddington wrote: Call me crazy, but game manufacturers want directx right? You aint running that in the kernel. They want something like DirectX that changes it's API less frequent than DirectX and that compiles as a module because you don't want to run it in the kernel. Whats wrong with just using SDL/OpenGL? Thousands of games are made with SDL/OpenGL, and there are realms of Linux usage where this works just fine, especially for games (GP2X, etc). In case you didn't notice, plenty of pro Game Developers use SDL/OpenGL just fine for their needs, and get the job done without grumbling and groaning about needing to have their hands held through the process. But I don't see top titles ported to SDL/OpenGL. Tough luck then - openGL is the standard gaming interface on linux, well for the 3D graphichs part at least. You already have this, so having a standard clearly isn't enough then. More titles will be ported to linux when linux becomes more popular as a home platform. It is that simple. And then it will happen no matter what the interface will be. Although I believe it will still be opengl - opengl is nice and don't need to change. Also, the fact that it isn't in the _kernel_ doesn't matter at all. It is in the standard distributions - that is what matters. You must take into account with what kind of people you're dealing with. It's not the pro Game Develpers who make decisions. It's the people who completely rely on words who ake decisions. So, if you tell them that there will be a _official_ API on Kernel level which will be available on all 300+ Linux distributions they will understand that they're dealing with something they can rely on. Wrong. This kind of people worry about market share and so they decide on windows games for that reason alone. They don't know SDL. And most of these characters think OpenGL is dead. It is wrong - it might be dead _on windows_ because windows have directx as well as a less useful opengl. That's arrogant, I know. They choice about what stuff they care is made by big words and statements, not by their competence. Then you won't get support here - nobody cares about big words here. I fail to see the reason this requirement has to be a 'kernel' interface, other than pure sheer laziness and inability to grok on the part of the so-called professional Game Developers. That's exactly what I'm talking about. They're lazy and dumb. So they need something where they can say: Hey, that is one interface that doesn't change every couple of month. I can try to wrap my lazy brain around it with a good feeling. 1. Linux don't support the lazy and dumb. Won't happen. 2. Even the lazy and dumb can use nice standardized unchanging interfaces - provided by a library rather than the kernel. It is not harder to do in any way. Gaming is only *one* kind of application for the Linux kernel - shall we burden the kernel with everything everyone wants just because people fail to understand the proper way to assemble a Linux-based kit for their specific application needs? (Hint: work with the distro builders.) Yes. Exactly. There is already code for very specific tasks in the kernel. A module that acts as a i-will-never-change-my-api-and-will-be-available-on-EVERY-linux-because i'm-part-of-the-kernel wrapper for video, sound and events dedicated to the gaming folks wouldn't hurt. Such a thing is nice - but it don't need to be in the kernel. Try to understand that! An interface set in stone can be provided by a standard library that all distros pick up. (No distro will skip an important library, that way they get behind the other distros.) The advantage of this is that such a library can keep the game programmers interface constant even when the kernel interfaces are mercilessly changed. And yes - they _will_ change. Everytime that happens, people here laugh at commercial actors getting in trouble. (Example - the tradition of ruthlessly breaking the binary-only modules from ati, nvidia, vmware...) Just my .2c, but anyone suggesting that API's be crowbar'ed into the kernel just to make it easier to get what you want from a single source is probably not as familiar with the underlying technology, nor the reasons for its structured organization, as they ought to be before making such suggestions .. I'm just guessing that the real problem of Linux gaming is that developers must get it that there is an official way to port games to linux w/o toolongdidntread, ever changing API's or as many different problems
Re: Gaming Interface
On Tue, 2007-01-09 at 08:14 +0100, Dirk wrote: Jan Dittmer wrote: Dirk wrote: Alright. I came to discuss an idea I had because I realized that installing Windows and running Linux in VMware is the only _fun_ way to play real Games and have Linux at the same time. And everyone who says I'm a troll doesn't like Games or simple things. That's not true, see wine/cedega for a linux direct-x implementation. Works wonders with most of the current games and copy protections. I tried to get WoW installed with Cedega 5.2.9 for two days now. and thats because you made the wrong choice. world of warcraft installs and runs perfectly in wine. and if you dont mind using proprietary nvidia blob, and have an nvidia card, even faster than on winblows. Cedega is not a replacement for ports. And it does not encourage ports. Dirk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gaming Interface
On Tue, 2007-01-09 at 17:08 +1000, Trent Waddington wrote: On 1/9/07, Adrian Bunk [EMAIL PROTECTED] wrote: And remember Picasa as a success story for Wine - exactly because a port would have required too much effort for developers that were busy with other things. I understand what you're saying here, but Picasa *is* a port. They ship an elf binary that links to winelib and they integrate in native file pickers for your favourite platform. If by port you mean GUI rewrite to use GNOME or KDE then no, it isn't that, but that doesn't mean it's not a port. they ship a precompiled wine, which runs their default win32 binaries. but yes, they have made efforts to integrate. Trent - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/
that sk98lin suspend/resume patch
hello, i run 2.6.13-rc4-git2, and i am experiencing problems with sk98lin, suddenly it just stops working, and i need to reboot to get network up again, does this fix it? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: writting files 100 MB in FAT32
On Thu, 2007-01-18 at 11:22 +0200, Condor wrote: Hello, [1.] Files if 100 MB saving in USB memory stick 4 GB with FAT32. While saving all files is broken. im sorry, i do not understand this. you are saying that if you copy files larger than 100mb into drive, all files die? [2.] I have USB memory stick A-DATA 4 GB with FAT32. When i trying to save files in my USB and files is of 100 MB, all files that i save is broken. I put my USB in my laptop and mount it as: mount /dev/sda1 /mnt/usb-win While i mount it, i got in my local disk and copy one file that is 520 MB. The file is copying very slow (10 min). and after i see again my console i wait light to my usb is off and i unmount it as: umount /mnt/usb-win I get my USB stick and when i return to home i trying to copy file from my USB to my windows and linux. Both OS unable to read file. After some tryings i format my USB in FAT16 and now every thing is work fine. I copy files to my USB and back to my hard drive and all files work fine. okay, i think thats what you are saying, could you please try to run dosfsck on it so we can see 100% whats wrong? also, try to do this: mount, copy, run command 'sync', unmount, pull out, and see if it works. finally, one more question. you said it does not work when you take it home, can you try this: mount, copy, unmount, mount, check to see if file works. [3.] lsmod # lsmod snip nvidia 4709172 22 ohh, tainted ;P naughty. Though i dont think this affects vfat. snip Regards, Condor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 14:19 +, David Howells wrote:
Chuck Ebbert [EMAIL PROTECTED] wrote:
Here is a patch to reverse that. Kasper, can you test it?
(Your filesystem is on a FAT/VFAT volume, I assume.)
I do have a fat32 filesystem mounted using the vfat driver (the msdos
one arent compiled in), however the chroot in no way has access to this,
and i dont see how ANY 32bit apps can have attempted to access it, ill
go so far as say im certain they havent.
Please don't revert that patch. If you do, you'll break CONFIG_BLOCK=n.
okay, i will not.
Can you compile and run the attached program as both 32-bit and 64-bit?
Yes, i will conduct tests, however it will have to wait till atleast
tomorow (cant garantuee anything though, i have lots of work to do).
On my x86_64 test box, I did:
[EMAIL PROTECTED] ~]# mkfs.vfat /dev/sda5
[EMAIL PROTECTED] ~]# mount /dev/sda5 /mnt
[EMAIL PROTECTED] ~]# mkdir /mnt/a
[EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 32-bit
268 : 82187201, 82187202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
Calling VFAT_IOCTL_READDIR_BOTH
[EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 64-bit
280 : 82307201, 82307202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl: Inappropriate ioctl for device
Calling VFAT_IOCTL_READDIR_BOTH
Which is what I'd expect (the 64-bit ioctl does not support the 32-bit
function). Tracing the 64-bit version shows that the right numbers are being
given to the syscall, though strace decodes them as the same symbol if not in
raw mode:
[EMAIL PROTECTED] ~]# strace -eioctl -eraw=ioctl /tmp/ioctl /mnt/a
280 : 82307201, 82307202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl(0x3, 0x82187201, 0x7fff9cec36c0) = -1 (errno 25)
ioctl: Inappropriate ioctl for device
Calling VFAT_IOCTL_READDIR_BOTH
ioctl(0x3, 0x82307201, 0x7fff9cec3490) = 0x1
Process 3410 detached
Applying the attached patch to the kernel produces the following elements in
the log for the 32-bit compilation:
== fat_compat_dir_ioctl(82187201,ffa803b8)
== fat_dir_ioctl(82307201,810036a97ca8)
== fat_dir_ioctl() = 1
== fat_compat_dir_ioctl() = 1
== fat_compat_dir_ioctl(82187201,ffa801a0)
== fat_dir_ioctl(82307201,810036a97ca8)
== fat_dir_ioctl() = 1
== fat_compat_dir_ioctl() = 1
and this for the 64-bit compilation:
== fat_dir_ioctl(82187201,7fff031f69f0)
call fat_generic_ioctl()
== fat_dir_ioctl() = -25
== fat_dir_ioctl(82307201,7fff031f67c0)
== fat_dir_ioctl() = 1
Which is entirely what I'd expect.
However, it's possible that the 64-bit kernel interface used to allow the
32-bit calls. If that's the case could you be running a 64-bit program
somewhere in your 32-bit chroot?
I am basically positive that i am not running 64bit stuff within my
32bit chroot, however i will check to make absolutely sure.
| i have only tested with =rc5, thw folling, as an example, appears in
| dmesg:
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
How do you get that? I don't see anything like that. I've tried:
all i did was run wine's regedit inside my 32bit chroot.
echo 1 /proc/sys/kernel/compat-log
But that doesn't seem to do anything.
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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? atleast =2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 21:31 -0500, Chuck Ebbert wrote: In-Reply-To: [EMAIL PROTECTED] On Tue, 05 Dec 2006 22:11:11 +, David Howells wrote: I only have 32-bit userspace. When I run your program against a directory on a JFS filesystem (msdos ioctls not supported) I get this on vanilla 2.6.19: Can I just check? You're using an x86_64 CPU in 64-bit mode with a 64-bit kernel, but with a completely 32-bit userspace? It's FC5 i386 so there's no way any 64-bit userspace code is in there. (I have a cross-compiler only for building kernels.) Having a pure 32-bit userspace lets me switch between i386 and x86_64 kernels without having to maintain two separate Linux installs. A question for you: Why is userspace assuming that it'll get ENOTTY rather than EINVAL? I'm not sure it is, but that's what it used to get. Kasper, what problems (other that the annoying message) are you having? if it had only been the messages i wouldnt have complained. the thing is, when i get these messages, the app provoking them acts very strange, and in some cases, my system simply hardlocks. and i am very very sure its because of this, i can run with the kernel (atleast with rc5 i had that long) for 10 days, and then chroot in, run the 32bit apps, and within hours of using, hardlock. wine seems to be worst at provoking hardlock, however i encountered one i am sure was caused by java(the 32bit one inside chroot). as i said in my post yesterday, my chroot doesent have access to my vfat partitions, so i dont believe thats it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-12-06 at 13:08 +, David Howells wrote: Kasper Sandberg [EMAIL PROTECTED] wrote: and i am very very sure its because of this, i can run with the kernel (atleast with rc5 i had that long) for 10 days, and then chroot in, run the 32bit apps, and within hours of using, hardlock. What do you mean by hardlock? Do you mean the application has to be killed, or do you mean the kernel is stuck and the machine has to be rebooted? i mean the kernel itself, two of the times it has happened to me, magic sysrq havent even been able to reboot for me, i had to hit the button on my tower. when i the very first time encountered this, it was with regedit, the app went nuts, and then it frooze, i had to kill -9 it, and then an hour later i noticed the kernel messages. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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? atleast =2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-12-06 at 16:48 +, David Howells wrote: Kasper Sandberg [EMAIL PROTECTED] wrote: What do you mean by hardlock? Do you mean the application has to be killed, or do you mean the kernel is stuck and the machine has to be rebooted? i mean the kernel itself, two of the times it has happened to me, magic sysrq havent even been able to reboot for me, i had to hit the button on my tower. That's got to be some other problem. There's no way this ioctl error message change should cause the kernel to die - applications, yes; but not the kernel. Okay, do you have an idea what it can be then? it have to be something in relation to 32bit emulation, cause it happens only when using 32bit apps. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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? atleast =2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-12-06 at 22:29 +0100, Andi Kleen wrote: and i am very very sure its because of this, i can run with the kernel (atleast with rc5 i had that long) for 10 days, and then chroot in, run the 32bit apps, and within hours of using, hardlock. Early AMD K8 platforms had a hardware bug that could have caused such hardlocks when running 32bit code under 64bit (independent of anything the kernel does). If you have such a board/CPU try a BIOS update. well, 2.6.18 were 100% stable, none of these issues. however you have caught my attention, cause i have one of the first amd64's, a 3200+ 1mb cache, socket 754. and an asus board. ill try find a floppy and upgrade the bios if there are updates available. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Mon, 2006-12-11 at 03:27 -0500, Chuck Ebbert wrote: In-Reply-To: [EMAIL PROTECTED] On Wed, 06 Dec 2006 13:58:00 +0100, Kasper Sandberg wrote: Kasper, what problems (other that the annoying message) are you having? if it had only been the messages i wouldnt have complained. the thing is, when i get these messages, the app provoking them acts very strange, and in some cases, my system simply hardlocks. You can try the patch I sent you to see if it fixes the Wine app. (David thought I was proposing it for the mainline kernel but I just wanted to see whether it made a difference.) do you think it may be a bug in the kernel? the stuff with wine that gets thrown in the kernel messages? cause if it is, i ofcourse wish to help by testing. one more thing, im 100% positive wine does NOT have access to any fat32, cause i entirely removed the only disk having such a filesystem, and it still likes to give this, however the last few times i havent observed the app going nuts :) As for the lockups, there are possibly other bugs lurking in 2.6.19. yes, when the using-much-ram-perhaps-even-swap thing was mentioned i came to think, cause i do happen to use alarmingly much swap. i noticed a ~5 second lockup (where it actually returned to normal again) when i reached ~50mb free ram, and this was outside the chroot. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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? atleast =2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-12-13 at 02:50 -0500, Chuck Ebbert wrote: In-Reply-To: [EMAIL PROTECTED] On Wed, 13 Dec 2006 05:39:43 +0100, Kasper Sandberg wrote: do you think it may be a bug in the kernel? the stuff with wine that gets thrown in the kernel messages? Let's just say the behavior has changed. It now returns -EINVAL instead of -ENOTTY when the msdos IOCTLs fail. im 100% positive wine does NOT have access to any fat32, cause i entirely removed the only disk having such a filesystem, and it still likes to give this That's when this happens: running certain programs that try msdos-type IOCTLs on native Linux filesystems. ohhh :) well wine may do that :) however the last few times i havent observed the app going nuts If there aren't any other problems you can just turn off the logging. Did you change something else? i did upgrade from rc5 to final Anyway, here is a much simpler patch that restores the previous behavior (but leaves the message.) However if you aren't having any problems now other than the messages maybe there's no real problem after all? well the hardlock problem still occurs, however that, (as i believe has veen the semi-conclusion in this thread) arent related? --- 2.6.19.1-64smp.orig/fs/compat.c +++ 2.6.19.1-64smp/fs/compat.c @@ -444,7 +444,11 @@ asmlinkage long compat_sys_ioctl(unsigne if (++count = 50) compat_ioctl_error(filp, fd, cmd, arg); - error = -EINVAL; + + if (cmd == 0x82187201) + error = -ENOTTY; + else + error = -EINVAL; } goto out_fput; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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? atleast =2.6.19-rc5, x86 chroot on x86_64
i know i said i suspected this was another bug, but i have revised my
suspecisions, and i do believe its in relation to x86 chroot on x86_64
install, as it has happened with more stuff now, inside the chroot, and
only inside the chroot, while the same apps dont do it outside chroot.
2.6.19 release is affected too
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
On Wed, 22 Nov 2006 15:29:02 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
it appears some sort of bug has gotten into .19, in regards to x86
emulation on x86_64.
i have only tested with =rc5, thw folling, as an example, appears in
dmesg:
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
Try
echo 0 /proc/sys/kernel/compat-log
I don't _think_ we did anything to change the logging in there. Which kernel
version were you using previously (the one which didn't do this)?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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? atleast =2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 03:36 +0100, Kasper Sandberg wrote:
i know i said i suspected this was another bug, but i have revised my
suspecisions, and i do believe its in relation to x86 chroot on x86_64
install, as it has happened with more stuff now, inside the chroot, and
only inside the chroot, while the same apps dont do it outside chroot.
and by that (so that theres no confusion), i mean that with the x86_64
binaries of the same application dont crash it, but the x86 binaries in
the chroot does :)
2.6.19 release is affected too
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
On Wed, 22 Nov 2006 15:29:02 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
it appears some sort of bug has gotten into .19, in regards to x86
emulation on x86_64.
i have only tested with =rc5, thw folling, as an example, appears in
dmesg:
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
Try
echo 0 /proc/sys/kernel/compat-log
I don't _think_ we did anything to change the logging in there. Which
kernel
version were you using previously (the one which didn't do this)?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
On Wed, 22 Nov 2006 15:29:02 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
it appears some sort of bug has gotten into .19, in regards to x86
emulation on x86_64.
i have only tested with =rc5, thw folling, as an example, appears in
dmesg:
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
Try
echo 0 /proc/sys/kernel/compat-log
this appears to make the logging stop, however, it still acts somewhat
weird, and i am somewhat certain its because of this. this appears to be
able to cause hardlocks.
I don't _think_ we did anything to change the logging in there. Which kernel
version were you using previously (the one which didn't do this)?
.18
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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? atleast =2.6.19-rc5, x86 chroot on x86_64| perhaps duplicate bug report?
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
On Wed, 22 Nov 2006 15:29:02 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
it appears some sort of bug has gotten into .19, in regards to x86
emulation on x86_64.
i have only tested with =rc5, thw folling, as an example, appears in
dmesg:
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
Try
echo 0 /proc/sys/kernel/compat-log
I don't _think_ we did anything to change the logging in there. Which kernel
version were you using previously (the one which didn't do this)?
it just struck me, that this may be the same bug Jesper Juhl has
discovered (atleast the hardlock part), as i read that thread, it strike
me that whenever i have hardlocks from this, its when i in wine runs
stuff that uses basically all my ram, and MAY even touch my swap.
just an idea.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast =2.6.19-rc5, x86 chroot on x86_64| perhaps duplicate bug report?
On Sun, 2006-11-26 at 19:52 +, Alistair John Strachan wrote:
On Sunday 26 November 2006 18:07, Kasper Sandberg wrote:
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
On Wed, 22 Nov 2006 15:29:02 +0100
Kasper Sandberg [EMAIL PROTECTED] wrote:
it appears some sort of bug has gotten into .19, in regards to x86
emulation on x86_64.
i have only tested with =rc5, thw folling, as an example, appears in
dmesg:
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
Try
echo 0 /proc/sys/kernel/compat-log
I don't _think_ we did anything to change the logging in there. Which
kernel version were you using previously (the one which didn't do this)?
it just struck me, that this may be the same bug Jesper Juhl has
discovered (atleast the hardlock part), as i read that thread, it strike
me that whenever i have hardlocks from this, its when i in wine runs
stuff that uses basically all my ram, and MAY even touch my swap.
I see this same ioctl32 warning on a few apps running inside Wine, but I've
not had any hard locks. On the contrary, everything works fine.
thats why i have come to suspect it may not be the ioctl thing that
causes the hardlocks, as i read that other thread
I guess it would be nice to know which ioctl it is that doesn't have a compat
wrapper on x86-64, 82187201 is a bit cryptic.
yes, it did not say these things on .18 :)
how do i get more verbose information on what exactly it is?
HTH.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 ata layer in 2.6.24
On Mon, 2008-01-28 at 11:35 -0500, Gene Heskett wrote:
On Monday 28 January 2008, Mikael Pettersson wrote:
Gene Heskett writes:
On Monday 28 January 2008, Peter Zijlstra wrote:
On Mon, 2008-01-28 at 09:17 +0100, Mikael Pettersson wrote:
1. Wrong mailing list; use linux-ide (@vger) instead.
What, and keep all us other interested people in the dark?
As a test, I tried rebooting to the latest fedora kernel and found it
kills X, so I'm back to the second to last fedora version ATM, and the
third 'smartctl -t lng /dev/sda' in 24 hours is running now. The first
two completed with no errors.
I've added the linux-ide list to refresh those people of the problem,
the logs are being spammed by this message stanza:
Jan 28 04:46:25 coyote kernel: [26550.290016] ata1.00: exception Emask
0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Jan 28 04:46:25 coyote kernel:
[26550.290028] ata1.00: cmd 35/00:58:c9:9c:0a/00:01:00:00:00/e0 tag 0 dma
176128 out Jan 28 04:46:25 coyote kernel: [26550.290029] res
40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Jan 28 04:46:25
coyote kernel: [26550.290032] ata1.00: status: { DRDY } Jan 28 04:46:25
coyote kernel: [26550.290060] ata1: soft resetting link Jan 28 04:46:25
coyote kernel: [26550.452301] ata1.00: configured for UDMA/100 Jan 28
04:46:25 coyote kernel: [26550.452318] ata1: EH complete
Jan 28 04:46:25 coyote kernel: [26550.455898] sd 0:0:0:0: [sda] 390721968
512-byte hardware sectors (200050 MB) Jan 28 04:46:25 coyote kernel:
[26550.456151] sd 0:0:0:0: [sda] Write Protect is off Jan 28 04:46:25
coyote kernel: [26550.456403] sd 0:0:0:0: [sda] Write cache: enabled,
read cache: enabled, doesn't support DPO or FUA
It's not obvious from this incomplete dmesg log what HW or driver
is behind ata1, but if the 2.6.24-rc7 kernel matches the 2.6.24 one,
it should be pata_amd driving a WDC disk:
[ 30.702887] pata_amd :00:09.0: version 0.3.10
[ 30.703052] PCI: Setting latency timer of device :00:09.0 to 64
[ 30.703188] scsi0 : pata_amd
[ 30.709313] scsi1 : pata_amd
[ 30.710076] ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000
irq 14 [ 30.710079] ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma
0xf008 irq 15 [ 30.864753] ata1.00: ATA-6: WDC WD2000JB-00EVA0,
15.05R15, max UDMA/100 [ 30.864756] ata1.00: 390721968 sectors, multi
16: LBA48
[ 30.871629] ata1.00: configured for UDMA/100
Unfortunately we also see:
[ 48.285456] nvidia: module license 'NVIDIA' taints kernel.
[ 48.549725] ACPI: PCI Interrupt :02:00.0[A] - Link [APC4] - GSI
19 (level, high) - IRQ 20 [ 48.550149] NVRM: loading NVIDIA UNIX x86
Kernel Module 169.07 Thu Dec 13 18:42:56 PST 2007
We have no way of debugging that module, so please try 2.6.24 without it.
Sorry, I can't do this and have a working machine. The nv driver has
suffered
bit rot or something since the FC2 days when it COULD run a 19 crt at
1600x1200, and will not drive this 20 wide screen lcd 1680x1050 monitor at
more than 800x600, which is absolutely butt ugly fuzzy, looking like a jpg
compressed to 10%. The system is not usable on a day to basis without the
nvidia driver.
Fix the nv driver so it will run this screen at its native resolution and
I'll
be glad to run it even if it won't run google earth, which I do use from time
to time. Now, if in all the hits you can get from google on this, currently
14,800 just for 'exception Emask', apparently caused by a timeout, if 100% of
the complainers are running nvidia drivers also, then I see a legit
I can invalidate this theory...
i helped a guy on irc debug this problem, and he had ati. I tried having
him stop using fglrx, and go to r300.. same problem, and same problem
even with vesa.. :)
also, i have this on my fileserver with .20, which doesent even run X,
or module support in kernel :)
complaint. Again, fix the nv driver so it will run my screen I'll be glad
to switch. I can see the reason, sure, but the machine must be capable of
doing its common day to day stuff, while using that driver, like running kde
for kmail, and browsers that work.
If the problems persist, please try to capture a complete log from the
failing kernel -- the interesting bits are everything from initial boot
up to and including the first few errors. You may need to increase the
kernel's log buffer size if the log gets truncated (CONFIG_LOG_BUF_SHIFT).
If by log you mean /var/log/messages, I have several megabytes of those.
If you mean a live dmesg capture taken right now, its attached. It contains
several of these at the bottom. I long ago made the kernel log buffer
bigger, cuz it couldn't even show the start immediately after the boot, and
even the dump to syslog was truncated.
There are no pata_amd changes from 2.6.24-rc7 to 2.6.24 final.
That is what I was afraid of. I've done
Re: Problem with ata layer in 2.6.24
On Mon, 2008-01-28 at 23:49 -0500, Gene Heskett wrote:
On Monday 28 January 2008, Kasper Sandberg wrote:
[...]
snip
I can invalidate this theory...
i helped a guy on irc debug this problem, and he had ati. I tried having
him stop using fglrx, and go to r300.. same problem, and same problem
even with vesa.. :)
No Kasper, you are validating it, that it is not nvidia related, which is
what
I was also saying.
yeah thats what i mean - i can invalidate the theory that all the
affected boxes run nvidia.
also, i have this on my fileserver with .20, which doesent even run X,
or module support in kernel :)
That far back? Although ISTR I saw it happen once only when I was running
2.6.18-somethingorother.
Yes im afraid so.. i will now provide some complete details, as i feel
they are relevant.
the thing is, i run 6x300gb disks, IDE, in raid5.
i have both an onboard via ide controller, and then i bought a promise
pdc 202 new thingie. i had problem however..
after a bit of time, i would get DMA reset error thing, and it all
kindof went NUTS. it was as if all data access were skewed, and as you
might imagine, this made everything fail badly.
i purchased an ITE based controller for the drives on the promise, but
exactly the same thing happened.
the errors i got was:
hdf: dma_intr: bad DMA status (dma_stat=75)
hdf: dma_intr: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
---
i then found new hope, when i heard that libata provided much better
error handling, so i upgraded to .20.
this made my box usable.
the error happens once or twice a day, the disk led will turn on
constantly, and all IO freezes for about half a minute, where it returns
PROPERLY(thank you libata!). as far as i can tell, the only side effect
is that i get those messages like described here, and flooded with on
google.
to put some timeline perspective into this.
i believe it was in 2005 i assembled the system, and when i realized it
was faulty, on old ide driver, i stopped using it - that miht have been
in beginning of 2006. then for almost a year i werent using it, hoping
to somehow fix it, but in january 2007 i think it was, atleast in the
very beginning of 2007, i hit upon the idea of trying libata, and ever
since the system has been running 24/7 - doing these errors around 2
times a day.
i have multiple times reported my problems to lkml, but nothing has
happened, i also tried to aproeach jgarzik direcly, but he was not
interested.
i really hope this can be solved now, its a huge problem
my fileserver has an asus k8v motherboard, with via chipset (k8t880 i
think it is, or something like it). currently using the promise
controller again(strangely enough all the timeouts seems to happen here,
and when the ITE was on, there, not the onboard one), in conjunction
with the onboard via.
complaint. Again, fix the nv driver so it will run my screen I'll be
snip
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 ata layer in 2.6.24
On Sun, 2008-01-27 at 21:22 -0500, Gene Heskett wrote: Greeting; snip None were logged during the time I was running an -rc7 or -rc8. The previous hits on this resulted in the udma speed being downgraded till it was actually running in pio just before the freeze that required the hardware reset button. I'll reboot to -rc8 right now and resume. If its the drive, I should see it. If not, then 2.6.24 is where I'll point the finger. Idea's anyone? I believe there is some sort of bug in libata, not just for this kernel version. i run a fileserver with .20, and i get these resets a few times a day.. no freezes though... except when its in progress, then all IO freezes and locks up applications using it.. but it passes after ~30sec. i know that since ubuntu started shipping with libata by default for IDE, a large number of people are seeing these intermittant freezes aswell(which passes after half a minute or less). i reported this before, however as far as i know, no reason, and much less a fix, has been found. it would be great to get this solved though. -- 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) Yow! Am I in Milwaukee? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v11
Hello Ingo. Sorry it has taken this long, but i've been quite busy with work. Here are my results with v11 for smoothness. under slight load (spamasassin nice 19'ed), its now doing okay in smoothness, almost as good as SD. but under harder load such as pressing a link in a browser while 3d(at nice 0), or spamasassin at nice 0 still makes it go stutterish instead of smooth. But overall it does seem better. On Tue, 2007-05-08 at 17:04 +0200, Ingo Molnar wrote: * Mike Galbraith [EMAIL PROTECTED] wrote: [...] Values 0x3 and 0xb are merely context switch happy. thanks Mike - value 0x8 looks pretty good here and doesnt have the artifacts you found. I've done a quick -v11 release with that fixed, available at the usual place: http://people.redhat.com/mingo/cfs-scheduler/ with no other changes. 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/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v11
On Thu, 2007-05-10 at 18:59 +0200, Christian wrote: Hello lkml, hello Ingo! I've been using CFS-v10 for a few days and I must say that I'm verry impressed ;-) Desktop performance without any manual renicing is excellent, even with make -j20. Gaming performance is at least on par with SD now! I've tried to Which games are you trying? and have you tried other workloads then make -j20? try have a window with some 3d game open, and a browser besides it, and press a link. i cant seem to get smooth results with CFS. Perhaps i could also conduct tests with the games you are trying on my hardware. change the sched_load_smoothing config to 8 but there is no visible difference when it's set to 7. Both schedulers are verrry good! I can't really tell which one is better. I noticed that while compiling a kernel (with -j4) my CPU temperature is two to three degrees hotter than with mainline. I have not done any timing tests, but I suspect that it's a little faster while preserving excellent desktop usability. Great work!! :-) -Christian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/
3d smoothness (was: Re: [patch] CFS scheduler, -v6)
On Sunday 29 April 2007 19:39, Ingo Molnar wrote: hi Kasper, i found an aspect of CFS that could cause the kind of 'stuttering' you described in such detail. I'm wondering whether you could try the attached -v8-rc1 patch ontop of the -v7 CFS patch - does it improve the 'games FPS' situation in any way? Thanks in advance, Ingo This patch makes things much worse, i'd categorize it as severe regression compared to cfs 7. It makes the cursor in X stutter enormously, it even caused my entire X to lock up for a second, and events like keyboard input is totally wrecked, it lagged as i wrote in xchat. as for under load, it seems only worse.. Also if i just press a link in konqueror on some website, while it loads, the mouse is stuttering untill the page has loaded finished. this seems weird because its such a relatively simple patch. In the patchs defense, gtk seems to redraw faster (when, and only when 3d is NOT running) i also discovered another thing about cfs 7 (without this patch), which is same behavior as old staircase/vanilla, but which SD actually fixes. this is a wine case, where when it loads a level in world of warcraft, the audio skips. I believe this to be a problem in wine, however, in sd it actually does not skip. On the desktop however, the audio issues were totally fixed in v7.. mvh. Kasper Sandberg - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3d smoothness (was: Re: [patch] CFS scheduler, -v6)
On Mon, 2007-04-30 at 22:17 +0200, Ingo Molnar wrote: * Kasper Sandberg [EMAIL PROTECTED] wrote: This patch makes things much worse, [...] yeah, the small patch i sent to you in private mail was indeed buggy, please disregard it. It also hardlocked my box :) but it was worth a shot. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
hey greg i remember for some months back, you posted something similar.. is this a version thats ready for use? if it is! im gonna use it! :D On Thu, 2005-02-10 at 16:52 -0800, Greg KH wrote: > On Thu, Feb 10, 2005 at 04:40:33PM -0800, Greg KH wrote: > > I'd like to announce, yet-another-hotplug based userspace project: > > linux-ng. > > Bah. The name is hotplug-ng. Sorry about that... > > greg k-h > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
On Thu, 2005-02-10 at 22:41 -0800, Greg KH wrote: > On Fri, 2005-02-11 at 02:30 +0100, Kasper Sandberg wrote: > > hey greg > > > > i remember for some months back, you posted something similar.. is this > > a version thats ready for use? if it is! im gonna use it! :D > > Yes, this is that version, cleaned up and given a proper build system, > and even tested on my machines here :) ah cool. and in that case, you probably also have ebuilds for it, if you do, please post them somewhere :) > > thanks, > > greg k-h > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
On Fri, 2005-02-11 at 09:06 -0800, Greg KH wrote: > On Fri, Feb 11, 2005 at 12:47:07PM +0100, Kasper Sandberg wrote: > > On Thu, 2005-02-10 at 22:41 -0800, Greg KH wrote: > > > On Fri, 2005-02-11 at 02:30 +0100, Kasper Sandberg wrote: > > > > hey greg > > > > > > > > i remember for some months back, you posted something similar.. is this > > > > a version thats ready for use? if it is! im gonna use it! :D > > > > > > Yes, this is that version, cleaned up and given a proper build system, > > > and even tested on my machines here :) > > ah cool. and in that case, you probably also have ebuilds for it, if you > > do, please post them somewhere :) > > I don't have an ebuild for it yet, but it's on my list to get done. And > when I do so, it will just show up in the normal gentoo tree. The main > "issue" with this is I need to create a virtual for the hotplug service > so it doesn't conflict with the existing hotplug package. Not a big > deal, just not as simple as adding a single ebuild to the tree. just make it provide virtual/hotplug, then do a fgrep -r "hotplug" /usr/portage/ and then replace with virtual/hotplug ;) > > thanks, > > greg k-h > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DVD burning still have problems
On Mon, 2005-01-24 at 23:48 +, Alan Cox wrote: > On Llu, 2005-01-24 at 23:01, Kasper Sandberg wrote: > > > there are certainly chipset and CPU errata in this area. > > would this mean that i should not use cpu frequency scaling? > > Worth an experiment but I'd be suprised if it was your fix. The more > data the better however I disabled cpufreq in the kernel, acpi i still have in kernel.. when i booted i did acpi=off, and changed IO scheduler to anticipatory i just burned a DVD, and it works ;D pretty neat, im not sure what caused it. but im glad.. i still have the small change in scsi_ioctl.h, however nothing appears in dmesg.. gonna burn one more dvd in a little bit, if it doesent work, i will let you know, if you dont hear more about it, assume it works :DD btw: the reason i changed to anticipatory from cfq is that i noticed that sometimes the speed dropped abit, and thought it might have something to do with it, and, with as it did not > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DVD burning still have problems
On Fri, 2005-01-28 at 14:47 +0100, Jens Axboe wrote: > On Fri, Jan 28 2005, Kasper Sandberg wrote: > > On Mon, 2005-01-24 at 23:48 +, Alan Cox wrote: > > > On Llu, 2005-01-24 at 23:01, Kasper Sandberg wrote: > > > > > there are certainly chipset and CPU errata in this area. > > > > would this mean that i should not use cpu frequency scaling? > > > > > > Worth an experiment but I'd be suprised if it was your fix. The more > > > data the better however > > I disabled cpufreq in the kernel, acpi i still have in kernel.. when i > > booted i did acpi=off, and changed IO scheduler to anticipatory > > i just burned a DVD, and it works ;D pretty neat, im not sure what > > caused it. but im glad.. i still have the small change in scsi_ioctl.h, > > however nothing appears in dmesg.. gonna burn one more dvd in a little > > bit, if it doesent work, i will let you know, if you dont hear more > > about it, assume it works :DD > > > > btw: the reason i changed to anticipatory from cfq is that i noticed > > that sometimes the speed dropped abit, and thought it might have > > something to do with it, and, with as it did not > > That's interesting, a short io starvation could for sure cause it. I > would really appreciate if you could try one change at the time though, > right now it's not really clear if it's acpi or the io scheduler. well.. all good things must come to an end.. the second dvd i burned failed.. :( this is really frustrating.. but im pretty pretty sure its not media error.. perhaps i must reboot after each burn again.. anyway, it is nice knowing everything isnt completely lost :) > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DVD burning still have problems
first, sorry for posting so much :| On Fri, 2005-01-28 at 15:05 +0100, Kasper Sandberg wrote: > On Fri, 2005-01-28 at 14:47 +0100, Jens Axboe wrote: > > On Fri, Jan 28 2005, Kasper Sandberg wrote: > > > On Mon, 2005-01-24 at 23:48 +, Alan Cox wrote: > > > > On Llu, 2005-01-24 at 23:01, Kasper Sandberg wrote: > > > > > > there are certainly chipset and CPU errata in this area. > > > > > would this mean that i should not use cpu frequency scaling? > > > > > > > > Worth an experiment but I'd be suprised if it was your fix. The more > > > > data the better however > > > I disabled cpufreq in the kernel, acpi i still have in kernel.. when i > > > booted i did acpi=off, and changed IO scheduler to anticipatory > > > i just burned a DVD, and it works ;D pretty neat, im not sure what > > > caused it. but im glad.. i still have the small change in scsi_ioctl.h, > > > however nothing appears in dmesg.. gonna burn one more dvd in a little > > > bit, if it doesent work, i will let you know, if you dont hear more > > > about it, assume it works :DD > > > > > > btw: the reason i changed to anticipatory from cfq is that i noticed > > > that sometimes the speed dropped abit, and thought it might have > > > something to do with it, and, with as it did not > > > > That's interesting, a short io starvation could for sure cause it. I > > would really appreciate if you could try one change at the time though, > > right now it's not really clear if it's acpi or the io scheduler. > well.. all good things must come to an end.. the second dvd i burned > failed.. :( > this is really frustrating.. but im pretty pretty sure its not media > error.. > perhaps i must reboot after each burn again.. anyway, it is nice knowing > everything isnt completely lost :) i just rebooted, (and booted with acpi off, anticipatory like before) and burned a DVD, and it works.. this means that when acpi is disabled, cpufreq off, i have the same problems i initially had with earlier kernels (2.6.9-rc*) that is: i could burn 1 dvd, which works fine, then the next i burn fails, with io error, then the third i burns works.. in short, every second works.. unless i reboot after each, then no one fails.. its a insanely strange problem. :) but atleast im able to get abit free hd space 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/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
that sk98lin suspend/resume patch
hello, i run 2.6.13-rc4-git2, and i am experiencing problems with sk98lin, suddenly it just stops working, and i need to reboot to get network up again, does this fix it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs+acl makes processes hang?
confirmed, i run 2.6.12 with reiserfs, created with reiserfsprogs 3.6.19 On Fri, 2005-07-15 at 23:19 +, Tarmo Tänav wrote: > Hi, > > I think I've found a bug in reiserfs acls. If triggered > it means that any program trying to access the partition, > where the bug occured, will just hang in D state, with > no way to kill the program. > > Here's how to reproduce: > 1. mount a reiserfs volume (loopmount will do) with "-o acl". > 2. create a directory "dir" > 3. set some default acl: setfacl -d -m u:username:rwX dir > 4. cd dir > 5. dd if=/dev/zero of=somefile1 bs=4k count=10 > (the idea is to run out of space) > 6. now df should show 0 free space, if not then repeat 5. > 7. echo "1" > somefile2 # this should hang infinitely > > Now no program will be able to access the partition. > > I haven't tried to reproduce it, but the same problem also happened > when a user hit his hard quota limit on my server. Then no program > could access his homedir. > > > PS. I'm not subscribed to lkml so please CC > > -- > Tarmo Tänav > [EMAIL PROTECTED] > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
inotify - i dont get a inotify device
hello.. i have a small problem with inotify in kernel 2.6.13-rc3-git4 - i do not get the inotify device, i know i build it in, gzcat /proc/config.gz | grep -i inotify confirms it, and i have a very new udev, where inotify is in the rules file, i tried udevstart but it did not create me the inotify device.. anyone that can help? perhaps a fix is known? -- Kasper Sandberg <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FUSE merging?
On Fri, 2005-09-02 at 15:34 -0700, Andrew Morton wrote: > Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > > Hi Andrew! > > > > Do you plan to send FUSE to Linus for 2.6.14? > i use fuse too, and i like it, it works good, and its quite fast and easy. it has given me no problems at all, i suggest merging, it harms nothing, and seems to be well maintained > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message 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/
BUG, 2.6.20-rc3 raid autodetection
Hello. i just attempted to test .20-rc3-git4 on a box, which has 6 drives in raid5. it uses raid autodetection, and 2 ide controllers (via and promise 20269). there are two problems. first, and most importantly, it doesent autodetect, i attempted with both the old ide drivers, and the new pata on libata drivers, the drives appears to be found, but the raid autoassembling just doesent happen. this is .17, which works: http://sh.nu/p/8001 this is .20-rc3-git4 which doesent work, in pata-on-libata mode: http://sh.nu/p/8000 this is .20-rc3-git4 which doesent work, in old ide mode: http://sh.nu/p/8002 second bug: notice on these pastes the lines at bottom, the keyboard stuff, these are repeated constantly, and caps/scrolllock button on keyboard is blinking. mvh. Kasper Sandberg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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, 2.6.20-rc3 raid autodetection
On Thu, 2007-01-04 at 20:07 +0100, Bartlomiej Zolnierkiewicz wrote: > On 1/4/07, Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > Hello. > > > > i just attempted to test .20-rc3-git4 on a box, which has 6 drives in > > raid5. it uses raid autodetection, and 2 ide controllers (via and > > promise 20269). > > > > there are two problems. > > > > first, and most importantly, it doesent autodetect, i attempted with > > both the old ide drivers, and the new pata on libata drivers, the drives > > appears to be found, but the raid autoassembling just doesent happen. > > > > this is .17, which works: > > http://sh.nu/p/8001 > > > > this is .20-rc3-git4 which doesent work, in pata-on-libata mode: > > http://sh.nu/p/8000 > > > > this is .20-rc3-git4 which doesent work, in old ide mode: > > http://sh.nu/p/8002 > > For some reason IDE disk driver is not claiming IDE devices. > > Could you please double check that IDE disk driver is built-in > (CONFIG_BLK_DEV_IDEDISK=y in the kernel configuration) > and not compiled as module? i need not check even once, i do not have module support enabled, so everything 100% surely is built in. this is the case for .17 too (and earlier, this box was started with .15 i think.) > > Bart > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG, 2.6.20-rc3 raid autodetection
On Thu, 2007-01-04 at 23:05 +0100, Bartlomiej Zolnierkiewicz wrote: > On 1/4/07, Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-01-04 at 22:06 +0100, Bartlomiej Zolnierkiewicz wrote: > > > On 1/4/07, Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > > > On Thu, 2007-01-04 at 21:07 +0100, Bartlomiej Zolnierkiewicz wrote: > > > > > On 1/4/07, Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > > > > > On Thu, 2007-01-04 at 20:07 +0100, Bartlomiej Zolnierkiewicz wrote: > > > > > > > On 1/4/07, Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > > > > > > > Hello. > > > > > > > > > > > > > > > > i just attempted to test .20-rc3-git4 on a box, which has 6 > > > > > > > > drives in > > > > > > > > raid5. it uses raid autodetection, and 2 ide controllers (via > > > > > > > > and > > > > > > > > promise 20269). > > > > > > > > > > > > > > > > there are two problems. > > > > > > > > > > > > > > > > first, and most importantly, it doesent autodetect, i attempted > > > > > > > > with > > > > > > > > both the old ide drivers, and the new pata on libata drivers, > > > > > > > > the drives > > > > > > > > appears to be found, but the raid autoassembling just doesent > > > > > > > > happen. > > > > > > > > > > > > > > > > this is .17, which works: > > > > > > > > http://sh.nu/p/8001 > > > > > > > > > > > > > > > > this is .20-rc3-git4 which doesent work, in pata-on-libata mode: > > > > > > > > http://sh.nu/p/8000 > > > > > > > > > > > > > > > > this is .20-rc3-git4 which doesent work, in old ide mode: > > > > > > > > http://sh.nu/p/8002 > > > > > > > > > > > > > > For some reason IDE disk driver is not claiming IDE devices. > > > > > > > > > > > > > > Could you please double check that IDE disk driver is built-in > > > > > > > (CONFIG_BLK_DEV_IDEDISK=y in the kernel configuration) > > > > > > > and not compiled as module? > > > > > > i need not check even once, i do not have module support enabled, so > > > > > > > > > > OK > > > > > > > > > > > everything 100% surely is built in. this is the case for .17 too > > > > > > (and earlier, this box was started with .15 i think.) > > > > > > > > > > Could you send me your config? > > > > > I'll try to reproduce this locally. > > > > sure thing. > > > > > > > > http://sh.nu/p/8004 <-- .17 working > > > > > > CONFIG_BLK_DEV_IDEDISK=y > > > > > > > http://sh.nu/p/8005 <-- .20-rc3-git4 nonworking, idemode, the one with > > > > libata i dont have anymore, but the only difference is that i use the > > > > libata drivers, but as its same result, shouldnt matter > > > > > > # CONFIG_BLK_DEV_IDEDISK is not set > > > > > > so not everything is "100% surely" built-in ;) > > i see your point, im afraid i may have misinterpreted you, since you > > said "and not compiled as module", so i thought you meant i had to make > > sure it wasnt moduled only. > > You were right - I forgot about "CONFIG_BLK_DEV_IDEDISK=n" case. > > > i will try with this now, what about pataonlibata, do i need this for > > Please report if this fixes the issue. yeah it did. > > > that too? > > for libata you need SCSI disk driver: CONFIG_BLK_DEV_SD=y > > [ libata is not independent subsystem like IDE but depends on SCSI, > and I really don't know why this is not mentioned in config help ] i knew that, i just thought it may select what it required, though i can see that it isnt strictly required, just what one wishes often. :) thanks for your help, will try with libata 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/
libata error handling
Hello.
i have a question in regards to libata's error handling, specifically
with pata drivers.
ill start by explaining something that happens to me using the normal
ide drivers (via ide and pdc202 new)
this is what i get when it has been used for a while:
hde: dma_intr: bad DMA status (dma_stat=75)
hde: dma_intr: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hde: dma_timer_expiry: dma status == 0x60
hde: DMA timeout retry
PDC202XX: Primary channel reset.
hde: timeout waiting for DMA
its ALWAYS hde, and its on the promise controller, i attempted to
replace the promise controller by other controllers, but i got the same
error. i have tried replacing cables too, and swapping around
harddrives, its ALWAYS the last harddrive that gets me this. after this,
my raid (6x300gb drives in raid5) would go nuts, as if the data was
there, but skewed, so i got it all from an offset.
this has been going on since always on this box, from .15 to .17, but
now i updated to .20-rc3-git4, and went over to the pata-on-libata
drivers, where i think this has stopped, or atleast, its not causing
WEIRD errors anymore, i have observed some stalls, but im not sure this
is due to it doing this, or simply syncing. i get no messages like this
from the kernel anymore.
i have heard that libata has much better error handling (this is what
made me try it), and from initial observations, that appears to be very
true, however, im wondering, is there something i can do to get
extremely verbose information from libata? for example if it corrects
errors? cause i'd really like to know if it still happens, and if i
perhaps get corruption as before, even though not severe.
Regards,
Kasper Sandberg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: libata error handling
On Sat, 2007-01-06 at 12:21 -0600, Robert Hancock wrote: > Kasper Sandberg wrote: > > i have heard that libata has much better error handling (this is what > > made me try it), and from initial observations, that appears to be very > > true, however, im wondering, is there something i can do to get > > extremely verbose information from libata? for example if it corrects > > errors? cause i'd really like to know if it still happens, and if i > > perhaps get corruption as before, even though not severe. > > Any errors, timeouts or retries would be showing up in dmesg.. how sure can i be of this? is it 100% sure that i have not encountered this error then? > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata error handling
On Sat, 2007-01-06 at 13:01 -0600, Robert Hancock wrote: > Kasper Sandberg wrote: > > On Sat, 2007-01-06 at 12:21 -0600, Robert Hancock wrote: > >> Kasper Sandberg wrote: > >>> i have heard that libata has much better error handling (this is what > >>> made me try it), and from initial observations, that appears to be very > >>> true, however, im wondering, is there something i can do to get > >>> extremely verbose information from libata? for example if it corrects > >>> errors? cause i'd really like to know if it still happens, and if i > >>> perhaps get corruption as before, even though not severe. > >> Any errors, timeouts or retries would be showing up in dmesg.. > > how sure can i be of this? is it 100% sure that i have not encountered > > this error then? > > Pretty sure, I'm quite certain libata never does any silent error recovery.. okay, i suppose i face two possibilities then: 1: libata drivers are simply better, and the error does not occur because of driver bugs in the old ide drivers 2: it hasnt happened to me on libata yet (though this is also abit weird, as it has now ran far longer than were previously required to hit the errors) > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata error handling
On Sat, 2007-01-06 at 20:28 +0100, Bartlomiej Zolnierkiewicz wrote: > On 1/6/07, Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > On Sat, 2007-01-06 at 13:01 -0600, Robert Hancock wrote: > > > Kasper Sandberg wrote: > > > > On Sat, 2007-01-06 at 12:21 -0600, Robert Hancock wrote: > > > >> Kasper Sandberg wrote: > > > >>> i have heard that libata has much better error handling (this is what > > > >>> made me try it), and from initial observations, that appears to be > > > >>> very > > > >>> true, however, im wondering, is there something i can do to get > > > >>> extremely verbose information from libata? for example if it corrects > > > >>> errors? cause i'd really like to know if it still happens, and if i > > > >>> perhaps get corruption as before, even though not severe. > > > >> Any errors, timeouts or retries would be showing up in dmesg.. > > > > how sure can i be of this? is it 100% sure that i have not encountered > > > > this error then? > > > > > > Pretty sure, I'm quite certain libata never does any silent error > > > recovery.. > > AFAIR this is true > (at least it was last time that I've looked at libata eh code) > > > okay, i suppose i face two possibilities then: > > 1: libata drivers are simply better, and the error does not occur > > because of driver bugs in the old ide drivers > > very likely however pdc202xx_new bugs should be fixed in 2.6.20-rc3 > (as it contains a lot of bugfixes for this driver from Sergei Shtylyov) these fixes are also in the libata driver? > > > 2: it hasnt happened to me on libata yet (though this is also abit > > weird, as it has now ran far longer than were previously required to hit > > the errors) > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gaming Interface
On Mon, 2007-01-08 at 16:36 +0100, Dirk wrote: > Helge Hafting wrote: > > Dirk wrote: > >> Jay Vaughan wrote: > >> > >>> At 13:13 +0100 8/1/07, Dirk wrote: > >>> > Trent Waddington wrote: > > Call me crazy, but game manufacturers want directx right? You aint > > running that in the kernel. > They want something like DirectX that changes it's API less frequent > than DirectX and that compiles as a module because you don't want to > run > it in the kernel. > > > >>> Whats wrong with just using SDL/OpenGL? Thousands of games are made > >>> with SDL/OpenGL, and there are realms of Linux usage where this works > >>> just fine, especially for games (GP2X, etc). In case you didn't notice, > >>> plenty of pro Game Developers use SDL/OpenGL just fine for their needs, > >>> and get the job done without grumbling and groaning about needing to > >>> have their hands held through the process. > >>> > >> > >> But I don't see top titles ported to SDL/OpenGL. > > Tough luck then - openGL is the standard gaming interface on linux, > > well for the 3D graphichs part at least. You already have this, > > so having a "standard" clearly isn't enough then. > > > > More titles will be ported to linux when linux becomes more > > popular as a home platform. It is that simple. And then it will > > happen no matter what the interface will be. Although I > > believe it will still be opengl - opengl is nice and don't need > > to change. Also, the fact that it isn't in the _kernel_ doesn't > > matter at all. It is in the standard distributions - that is what matters. > > > > > >> You must take into > >> account with what kind of people you're dealing with. It's not the pro > >> Game Develpers who make decisions. It's the people who completely rely > >> on words who ake decisions. So, if you tell them that there will be a > >> _official_ API on Kernel level which will be available on all 300+ Linux > >> distributions they will understand that they're dealing with something > >> they can rely on. > > Wrong. This kind of people worry about market share and so > > they decide on windows games for that reason alone. > >> They don't know SDL. And most of these characters > >> think OpenGL is dead. > > It is wrong - it might be dead _on windows_ because > > windows have directx as well as a "less useful" opengl. > >> That's arrogant, I know. They choice about what > >> stuff they care is made by big words and statements, not by their > >> competence. > >> > > Then you won't get support here - nobody cares about > > "big words" here. > >>> I fail to see the reason this requirement has to be a 'kernel' > >>> interface, other than pure sheer laziness and inability to grok on the > >>> part of the so-called professional Game Developers. > >>> > >> > >> That's exactly what I'm talking about. They're lazy and dumb. So they > >> need something where they can say: "Hey, that is one interface that > >> doesn't change every couple of month. I can try to wrap my lazy brain > >> around it with a good feeling." > >> > > 1. Linux don't support the lazy and dumb. Won't happen. > > 2. Even the lazy and dumb can use nice standardized unchanging > >interfaces - provided by a library rather than the kernel. It is not > >harder to do in any way. > > > >>> Gaming is only > >>> *one* kind of application for the Linux kernel - shall we burden the > >>> kernel with everything everyone wants just because people fail to > >>> understand the proper way to assemble a Linux-based kit for their > >>> specific application needs? (Hint: work with the distro builders.) > >>> > >> > >> Yes. Exactly. There is already code for very specific tasks in the > >> kernel. A module that acts as a > >> i-will-never-change-my-api-and-will-be-available-on-EVERY-linux-because > >> i'm-part-of-the-kernel wrapper for video, sound and events dedicated to > >> the gaming folks wouldn't hurt. > >> > > Such a thing is nice - but it don't need to be in the kernel. Try > > to understand that! An interface set in stone can be provided > > by a standard library that all distros pick up. (No distro will > > skip an important library, that way they get behind the other distros.) > > The advantage of this is that such a library can keep the > > game programmers interface constant even when the kernel interfaces > > are mercilessly changed. And yes - they _will_ change. Everytime > > that happens, people here laugh at commercial actors getting > > in trouble. (Example - the tradition of ruthlessly breaking the binary-only > > modules from ati, nvidia, vmware...) > > > >>> Just my .2c, but anyone suggesting that API's be crowbar'ed into the > >>> kernel "just to make it easier to get what you want from a single > >>> source" is probably not as familiar with the underlying technology, nor > >>> the reasons for its structured organization, as they ought to be before > >>> making such
Re: Gaming Interface
On Tue, 2007-01-09 at 08:22 +0100, Dirk wrote: > Kasper Sandberg wrote: > > On Mon, 2007-01-08 at 16:36 +0100, Dirk wrote: > >> Helge Hafting wrote: > >>> Dirk wrote: > >>>> Jay Vaughan wrote: > >>>> > >>>>> At 13:13 +0100 8/1/07, Dirk wrote: > >>>>> > >>>>>> Trent Waddington wrote: > >>>>>> > Call me crazy, but game manufacturers want directx right? You aint > >>>>>> > running that in the kernel. > >>>>>> They want something like DirectX that changes it's API less frequent > >>>>>> than DirectX and that compiles as a module because you don't want to > >>>>>> run > >>>>>> it in the kernel. > >>>>>> > >>>>>> > >>>>> Whats wrong with just using SDL/OpenGL? Thousands of games are made > >>>>> with SDL/OpenGL, and there are realms of Linux usage where this works > >>>>> just fine, especially for games (GP2X, etc). In case you didn't notice, > >>>>> plenty of pro Game Developers use SDL/OpenGL just fine for their needs, > >>>>> and get the job done without grumbling and groaning about needing to > >>>>> have their hands held through the process. > >>>>> > >>>> But I don't see top titles ported to SDL/OpenGL. > >>> Tough luck then - openGL is the standard gaming interface on linux, > >>> well for the 3D graphichs part at least. You already have this, > >>> so having a "standard" clearly isn't enough then. > >>> > >>> More titles will be ported to linux when linux becomes more > >>> popular as a home platform. It is that simple. And then it will > >>> happen no matter what the interface will be. Although I > >>> believe it will still be opengl - opengl is nice and don't need > >>> to change. Also, the fact that it isn't in the _kernel_ doesn't > >>> matter at all. It is in the standard distributions - that is what matters. > >>> > >>> > >>>> You must take into > >>>> account with what kind of people you're dealing with. It's not the pro > >>>> Game Develpers who make decisions. It's the people who completely rely > >>>> on words who ake decisions. So, if you tell them that there will be a > >>>> _official_ API on Kernel level which will be available on all 300+ Linux > >>>> distributions they will understand that they're dealing with something > >>>> they can rely on. > >>> Wrong. This kind of people worry about market share and so > >>> they decide on windows games for that reason alone. > >>>> They don't know SDL. And most of these characters > >>>> think OpenGL is dead. > >>> It is wrong - it might be dead _on windows_ because > >>> windows have directx as well as a "less useful" opengl. > >>>> That's arrogant, I know. They choice about what > >>>> stuff they care is made by big words and statements, not by their > >>>> competence. > >>>> > >>> Then you won't get support here - nobody cares about > >>> "big words" here. > >>>>> I fail to see the reason this requirement has to be a 'kernel' > >>>>> interface, other than pure sheer laziness and inability to grok on the > >>>>> part of the so-called professional Game Developers. > >>>>> > >>>> That's exactly what I'm talking about. They're lazy and dumb. So they > >>>> need something where they can say: "Hey, that is one interface that > >>>> doesn't change every couple of month. I can try to wrap my lazy brain > >>>> around it with a good feeling." > >>>> > >>> 1. Linux don't support the lazy and dumb. Won't happen. > >>> 2. Even the lazy and dumb can use nice standardized unchanging > >>>interfaces - provided by a library rather than the kernel. It is not > >>>harder to do in any way. > >>> > >>>>> Gaming is only > >>>>> *one* kind of application for the Linux kernel - shall we burden the > >>>>> kernel with everything everyone wants just because people fail to > >>>>> understand the proper way to assemble a Linux-based kit for their > >>>
Re: Gaming Interface
On Tue, 2007-01-09 at 08:14 +0100, Dirk wrote: > Jan Dittmer wrote: > > Dirk wrote: > >> Alright. I came to discuss an idea I had because I realized that > >> installing Windows and running Linux in VMware is the only _fun_ way to > >> play "real" Games and have Linux at the same time. > >> > >> And everyone who says I'm a troll doesn't like Games or simple things. > > > > That's not true, see wine/cedega for a linux direct-x implementation. > > Works wonders with most of the current games and copy protections. > > > > I tried to get WoW installed with Cedega 5.2.9 for two days now. and thats because you made the wrong choice. world of warcraft installs and runs perfectly in wine. and if you dont mind using proprietary nvidia blob, and have an nvidia card, even faster than on winblows. > > Cedega is not a replacement for ports. And it does not encourage ports. > > > Dirk > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gaming Interface
On Tue, 2007-01-09 at 17:08 +1000, Trent Waddington wrote: > On 1/9/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > And remember Picasa as a success story for Wine - exactly because a port > > would have required too much effort for developers that were busy with > > other things. > > I understand what you're saying here, but Picasa *is* a port. They > ship an elf binary that links to winelib and they integrate in native > file pickers for your favourite platform. If by "port" you mean "GUI > rewrite to use GNOME or KDE" then no, it isn't that, but that doesn't > mean it's not a port. they ship a precompiled wine, which runs their default win32 binaries. but yes, they have made efforts to integrate. > > Trent > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
i know i said i suspected this was another bug, but i have revised my
suspecisions, and i do believe its in relation to x86 chroot on x86_64
install, as it has happened with more stuff now, inside the chroot, and
only inside the chroot, while the same apps dont do it outside chroot.
2.6.19 release is affected too
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> On Wed, 22 Nov 2006 15:29:02 +0100
> Kasper Sandberg <[EMAIL PROTECTED]> wrote:
>
> > it appears some sort of bug has gotten into .19, in regards to x86
> > emulation on x86_64.
> >
> > i have only tested with >=rc5, thw folling, as an example, appears in
> > dmesg:
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
>
> Try
>
> echo 0 > /proc/sys/kernel/compat-log
>
> I don't _think_ we did anything to change the logging in there. Which kernel
> version were you using previously (the one which didn't do this)?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 03:36 +0100, Kasper Sandberg wrote:
> i know i said i suspected this was another bug, but i have revised my
> suspecisions, and i do believe its in relation to x86 chroot on x86_64
> install, as it has happened with more stuff now, inside the chroot, and
> only inside the chroot, while the same apps dont do it outside chroot.
and by that (so that theres no confusion), i mean that with the x86_64
binaries of the same application dont crash it, but the x86 binaries in
the chroot does :)
>
> 2.6.19 release is affected too
>
> On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> > On Wed, 22 Nov 2006 15:29:02 +0100
> > Kasper Sandberg <[EMAIL PROTECTED]> wrote:
> >
> > > it appears some sort of bug has gotten into .19, in regards to x86
> > > emulation on x86_64.
> > >
> > > i have only tested with >=rc5, thw folling, as an example, appears in
> > > dmesg:
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> >
> > Try
> >
> > echo 0 > /proc/sys/kernel/compat-log
> >
> > I don't _think_ we did anything to change the logging in there. Which
> > kernel
> > version were you using previously (the one which didn't do this)?
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 14:19 +, David Howells wrote:
> Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
> > Here is a patch to reverse that. Kasper, can you test it?
> > (Your filesystem is on a FAT/VFAT volume, I assume.)
I do have a fat32 filesystem mounted using the vfat driver (the msdos
one arent compiled in), however the chroot in no way has access to this,
and i dont see how ANY 32bit apps can have attempted to access it, ill
go so far as say im certain they havent.
>
> Please don't revert that patch. If you do, you'll break CONFIG_BLOCK=n.
okay, i will not.
>
> Can you compile and run the attached program as both 32-bit and 64-bit?
Yes, i will conduct tests, however it will have to wait till atleast
tomorow (cant garantuee anything though, i have lots of work to do).
>
> On my x86_64 test box, I did:
>
> [EMAIL PROTECTED] ~]# mkfs.vfat /dev/sda5
> [EMAIL PROTECTED] ~]# mount /dev/sda5 /mnt
> [EMAIL PROTECTED] ~]# mkdir /mnt/a
> [EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 32-bit
> 268 : 82187201, 82187202
> 268 : 82187201, 82187202
> Calling VFAT_IOCTL_READDIR_BOTH32
> Calling VFAT_IOCTL_READDIR_BOTH
> [EMAIL PROTECTED] ~]# /tmp/ioctl /mnt/a # 64-bit
> 280 : 82307201, 82307202
> 268 : 82187201, 82187202
> Calling VFAT_IOCTL_READDIR_BOTH32
> ioctl: Inappropriate ioctl for device
> Calling VFAT_IOCTL_READDIR_BOTH
>
> Which is what I'd expect (the 64-bit ioctl does not support the 32-bit
> function). Tracing the 64-bit version shows that the right numbers are being
> given to the syscall, though strace decodes them as the same symbol if not in
> raw mode:
>
> [EMAIL PROTECTED] ~]# strace -eioctl -eraw=ioctl /tmp/ioctl /mnt/a
> 280 : 82307201, 82307202
> 268 : 82187201, 82187202
> Calling VFAT_IOCTL_READDIR_BOTH32
> ioctl(0x3, 0x82187201, 0x7fff9cec36c0) = -1 (errno 25)
> ioctl: Inappropriate ioctl for device
> Calling VFAT_IOCTL_READDIR_BOTH
> ioctl(0x3, 0x82307201, 0x7fff9cec3490) = 0x1
> Process 3410 detached
>
> Applying the attached patch to the kernel produces the following elements in
> the log for the 32-bit compilation:
>
> ==> fat_compat_dir_ioctl(82187201,ffa803b8)
> ==> fat_dir_ioctl(82307201,810036a97ca8)
> <== fat_dir_ioctl() = 1
> <== fat_compat_dir_ioctl() = 1
> ==> fat_compat_dir_ioctl(82187201,ffa801a0)
> ==> fat_dir_ioctl(82307201,810036a97ca8)
> <== fat_dir_ioctl() = 1
> <== fat_compat_dir_ioctl() = 1
>
> and this for the 64-bit compilation:
>
> ==> fat_dir_ioctl(82187201,7fff031f69f0)
> call fat_generic_ioctl()
> <== fat_dir_ioctl() = -25
> ==> fat_dir_ioctl(82307201,7fff031f67c0)
> <== fat_dir_ioctl() = 1
>
> Which is entirely what I'd expect.
>
> However, it's possible that the 64-bit kernel interface used to allow the
> 32-bit calls. If that's the case could you be running a 64-bit program
> somewhere in your 32-bit chroot?
I am basically positive that i am not running 64bit stuff within my
32bit chroot, however i will check to make absolutely sure.
>
> | i have only tested with >=rc5, thw folling, as an example, appears in
> | dmesg:
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
>
> How do you get that? I don't see anything like that. I've tried:
all i did was run wine's regedit inside my 32bit chroot.
>
> echo 1 >/proc/sys/kernel/compat-log
>
> But that doesn't seem to do anything.
>
> David
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Tue, 2006-12-05 at 21:31 -0500, Chuck Ebbert wrote: > In-Reply-To: <[EMAIL PROTECTED]> > > On Tue, 05 Dec 2006 22:11:11 +, David Howells wrote: > > > > I only have 32-bit userspace. When I run your program against > > > a directory on a JFS filesystem (msdos ioctls not supported) > > > I get this on vanilla 2.6.19: > > > > Can I just check? You're using an x86_64 CPU in 64-bit mode with a 64-bit > > kernel, but with a completely 32-bit userspace? > > It's FC5 i386 so there's no way any 64-bit userspace code is in there. > (I have a cross-compiler only for building kernels.) Having a pure > 32-bit userspace lets me switch between i386 and x86_64 kernels > without having to maintain two separate Linux installs. > > > A question for you: Why is userspace assuming that it'll get ENOTTY rather > > than EINVAL? > > I'm not sure it is, but that's what it used to get. > > Kasper, what problems (other that the annoying message) are you having? if it had only been the messages i wouldnt have complained. the thing is, when i get these messages, the app provoking them acts very strange, and in some cases, my system simply hardlocks. and i am very very sure its because of this, i can run with the kernel (atleast with rc5 i had that long) for 10 days, and then chroot in, run the 32bit apps, and within hours of using, hardlock. wine seems to be worst at provoking hardlock, however i encountered one i am sure was caused by java(the 32bit one inside chroot). as i said in my post yesterday, my chroot doesent have access to my vfat partitions, so i dont believe thats it. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64
On Wed, 2006-12-06 at 13:08 +, David Howells wrote: > Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > > and i am very very sure its because of this, i can run with the kernel > > (atleast with rc5 i had that long) for 10 days, and then chroot in, run > > the 32bit apps, and within hours of using, hardlock. > > What do you mean by "hardlock"? Do you mean the application has to be killed, > or do you mean the kernel is stuck and the machine has to be rebooted? i mean the kernel itself, two of the times it has happened to me, magic sysrq havent even been able to reboot for me, i had to hit the button on my tower. when i the very first time encountered this, it was with regedit, the app went nuts, and then it frooze, i had to kill -9 it, and then an hour later i noticed the kernel messages. > > David > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
