| billybigrigger | is it possible to git pull a fix from kernel.org before it's put into linus' tree? | 01:10 |
|---|---|---|
| billybigrigger | there are some fixes here > http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=summary | 01:10 |
| billybigrigger | that should fix my webcam, but i don't when they will be put into linus' source | 01:11 |
| === speck is now known as nuspeck | ||
| jjohansen | billybigrigger: yes. you can cherry pick commits from another tree and merge them into your own | 01:32 |
| billybigrigger | so if i have linus' source in ~/linux-2.6 | 01:41 |
| billybigrigger | cd ~/linux-2.6 | 01:41 |
| billybigrigger | git pull git://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git | 01:41 |
| billybigrigger | ? | 01:41 |
| nuspeck | whats a good book for device driver programming? | 03:24 |
| mjg59 | http://lwn.net/Kernel/LDD3/ is decent and free | 03:24 |
| nuspeck | thank you I'll take a loot at it. | 03:25 |
| === MobileMyles6o7 is now known as TwoToneSpirit | ||
| nev | hi all... Does Ubuntu actually use group scheduling? It enables Group CPU Scheduler and Control Group support, but I don't see it mounts cgroup fs and use it... | 04:46 |
| amitk | apw: so what is genconfig used for? | 09:32 |
| apw | for debugging the config | 09:33 |
| apw | you run that and it gives you a CONFIG/* with the compile level configs | 09:33 |
| apw | lets you check things are as you expect | 09:33 |
| amitk | so it give you the merged config? | 09:34 |
| apw | it gives you a clean config for each arch/flavour which you can use to build | 09:34 |
| apw | and to confirm options end up set as desired | 09:35 |
| apw | every time i changed anything in the config i wanted to be able to confirm i'd done it right | 09:35 |
| amitk | aah, so you can copy it to you .config, analyse it in menuconfig, etc... | 09:35 |
| apw | and so i had a patch to do 'genpatch' and figured it was generally useful | 09:35 |
| apw | right exactly that | 09:35 |
| apw | do 'grep ADFS_FS' and check its on in all of them as expected | 09:36 |
| amitk | ok, just wonder how it was different from calling the 'prepare' target | 09:37 |
| amitk | *wondered | 09:37 |
| apw | it makes _all_ of them instead of just one | 09:37 |
| amitk | yeah, now I understand | 09:37 |
| apw | its most handy when one is changing the config system again :) | 09:38 |
| amitk | apw: I'm ready to do one last test and _then_ create the configs for imx51 on karmic. Are the configs going to be relatively stable today. That last config patch almost always fails to apply when the git tree changes. | 09:43 |
| apw | the configs just changed, as i just rebased the tree to -rc4 | 09:44 |
| amitk | *groan* | 09:45 |
| apw | its not yet pushed ... just testing it | 09:45 |
| apw | we rebase weekly your life is never going to be easy | 09:45 |
| apw | is this going into the master branch or onto its own | 09:45 |
| amitk | into its own branch for now | 09:46 |
| apw | with that new config fix the configs are easier to inject | 09:46 |
| apw | then the config is always going to conflict ... | 09:46 |
| apw | as you are going to be a rebase tree ongoing till you arn't a branch | 09:46 |
| amitk | true | 09:46 |
| apw | you could just keep the entire configs as a file | 09:46 |
| apw | and put it as the flavour config | 09:47 |
| apw | and not run updateconfigs | 09:47 |
| apw | or ... keep it separate somewhere else in the tree | 09:47 |
| amitk | that's an idea! | 09:47 |
| apw | and cp it to the flavour and run updateconfigs after each rebase | 09:47 |
| apw | which will collapse it in | 09:47 |
| apw | (now i've fixed the config update :)) | 09:48 |
| amitk | OTOH, since imx51 kernels are needed by -mobile to create images, are we prepared to have a different package namespace for this for karmic? | 09:48 |
| amitk | separate branch would mean separate source package | 09:49 |
| apw | we need to have a conversation about this, if it can wait, then at sprint would be appropriate | 09:49 |
| apw | we need a strategy on how we handle these branches | 09:49 |
| amitk | it needs to get in before A4 | 09:49 |
| amitk | and sooner the better so that -mobile team works out all the kinks in image building | 09:49 |
| apw | so this new branch makes a new amx51 flavour yes? | 09:50 |
| amitk | it adds the patches for the new mx51 flavour yes. We already have a mx51 flavour in karmic, but it is borked and defaults to some mx3 config | 09:51 |
| apw | imx even | 09:51 |
| amitk | basically karmic has the infrastructure for imx51 flavour but no code :) | 09:51 |
| apw | yeah so if this is a branch, then we have no machinary to get that built in the main build | 09:52 |
| apw | so either we need some of that, or we need to make it a different source package | 09:52 |
| apw | and strip imx51 from the main tree | 09:52 |
| apw | its custom-binary basically | 09:53 |
| amitk | IMHO, we should just merge this into the karmic tree after reviewing that all the fencing is in place to separate Freescale code from upstream code. | 09:53 |
| apw | thats a simpler approach i am sure | 09:54 |
| Kano | hi apw , you saw rc4? | 10:40 |
| apw | yes | 10:40 |
| Kano | tell me when you are done | 10:40 |
| apw | archive is frozen for alpha-3 | 10:40 |
| apw | so there won't be an upload for a bit | 10:40 |
| Kano | i dont need uploads, i need only git | 10:41 |
| Kano | kdb.c has a conflict | 10:41 |
| Kano | and there are some modules more | 10:41 |
| apw | a conflict with what? | 10:41 |
| Kano | i guess with one of your sauce patches | 10:43 |
| apw | there is no kdb.c | 10:43 |
| Kano | well maybe not that name, but similar, was on the other pc ;) | 10:43 |
| apw | ah atkbd.c perhaps | 10:44 |
| Kano | something like that yes | 10:45 |
| apw | its in progress ... will go up once its tested ok | 10:46 |
| Kano | rc3-git5 had still several bad issues for me | 10:46 |
| Kano | like kdesu not working | 10:46 |
| Kano | virtualbox module working in 50% of all cases | 10:47 |
| apw | can't say i generally test on kubuntu | 10:47 |
| Kano | i can test kubuntu, maybe kdesu can be tested when a root account is enabled... | 10:47 |
| Kano | just need to reset the sudo override | 10:48 |
| cking | in what way is it not working? | 10:54 |
| Kano | well here i get connection to su refused | 10:54 |
| Kano | only with that kernel, when i boot 2.6.30, no problem | 10:55 |
| cking | Hrm. Has the virtual box KMS module not been built successfully with 2.6.31 then? | 10:57 |
| hyperair | hmm for some reason, grub refuses to load the 2.6.28-14 kernel | 11:06 |
| hyperair | -generic. | 11:06 |
| Kano | cking: for vbox it is no problem building the module | 11:10 |
| Kano | cking: you have to restart the service till you dont get a dmesg error, when i do that 100 times about 50 fails | 11:10 |
| cking | Lemme look into that later today and see what's up | 11:11 |
| cking | Kano, what dmesg error do you get? | 11:12 |
| Kano | it has something to do with the watchdog | 11:12 |
| cking | I suggest filing a bug, putting all the dmesg details in and then we can see exactly what's up | 11:13 |
| Kano | hmm when i try to write a custom .kde/share/config/kdesurc in the home it does not seem to work | 11:18 |
| Kano | with super-user-command=su | 11:18 |
| Kano | ok, it works,but you have to disable the admin line with visudo | 11:20 |
| hyperair | try booting with nmi_watchdog=0 | 11:23 |
| Kano | yes thats the error, but that option does not help | 11:23 |
| Kano | you just try a few times then it works | 11:24 |
| Kano | i just dont get why kdesu is not in the path on kubuntu... | 11:24 |
| Kano | apw: but the error you can verify | 11:25 |
| Kano | apw: the passwd is not accepted | 11:25 |
| hyperair | wait, what does kdesu have to do with vboxdrv? | 11:25 |
| Kano | there is no connection error as with kde 3.5,but the correct pass fails | 11:26 |
| hyperair | ? | 11:26 |
| hyperair | you haven't answered my question. | 11:26 |
| Kano | hyperair: both errors are because of .31 | 11:26 |
| hyperair | ...ha? | 11:27 |
| hyperair | i don't see how .31 can affect kdesu | 11:27 |
| hyperair | but then again i don't use kde, i use gnome. | 11:27 |
| hyperair | and i don't use gksu very often either. i usually use sudo because i'm in the temrinal most of the time | 11:27 |
| Kano | well ubuntu does not use su by default at all | 11:27 |
| Kano | so no vaild comparison | 11:28 |
| Kano | you play with sudo all the time | 11:28 |
| hyperair | right. | 11:28 |
| hyperair | and what's the problem with kdesu now? | 11:28 |
| Kano | the connection fails | 11:29 |
| hyperair | what connection? | 11:29 |
| Kano | on kde 3.5, not fully sure if kdesu is reading the super-user-command override | 11:29 |
| Kano | hyperair: thats the error message | 11:29 |
| hyperair | ._. | 11:29 |
| hyperair | what a pile of fail. | 11:29 |
| Kano | it is harder to verify that error with u | 11:30 |
| hyperair | imo you should go and poke the kde people about this. | 11:30 |
| rtg_ | apw, did you pick up Ike;s bnx2x firmware patch for Karmic? | 13:15 |
| apw | has that been resubmitted? | 13:15 |
| * apw checks | 13:16 | |
| rtg_ | apw, I don't think he needed to. It was correct in its original form. | 13:16 |
| apw | ahh i saw cjwat sons responce and hand't seen ikes responce. will double check his stuff and pull it in | 13:18 |
| apw | yeah ike appears to be correct, subtle having xxx and libxxx in the kernel | 13:19 |
| * apw sucks | 13:19 | |
| apw | rtg_, this is mind mangling.. had a discussion this am how the installer does not use udebs and yet we are updating udebs for the installer ... | 13:23 |
| apw | i guess this could be the alternate cd images ? hrm | 13:24 |
| rtg_ | apw, Ubiquity doesn't use udebs, but the alternate installer does. | 13:24 |
| * apw watches the light bulb go on ... makes sense | 13:24 | |
| apw | so if we could ubuquity on the alternate cds all of kernel wedge could go away | 13:24 |
| rtg_ | apw, ain't gonna happen. | 13:25 |
| rtg_ | apw, udebs are also used on the server install IIRC | 13:25 |
| apw | i assume that is actually just an alternate installer | 13:25 |
| rtg_ | apw, yep | 13:26 |
| rtg_ | same framework with some behavioral differences | 13:26 |
| smb_tp | rtg_, Would you agree with a modified version of your e1000e-next patch that adds the new module to the nic udeb | 13:39 |
| rtg_ | smb_tp, sounds right, especially if you want net booting to work | 13:39 |
| rtg_ | or net install, rather | 13:40 |
| smb_tp | rtg_, Yeah, thought so. Ok, then I guess it is ready to push now | 13:40 |
| rtg_ | apw, how about pushing your -rc4 stuff. I'm working on an rfkill bug, and I want to be able to complain on the wireless list about it using current kernel bits. | 13:44 |
| rtg_ | note that rfkill is not in wireless-testing | 13:45 |
| apw | rtg_, will do ... will poke you when its done | 13:46 |
| apw | rtg, karmic updated | 13:56 |
| amitk | apw: can I rebase on top of this? | 13:58 |
| rtg_ | amitk, you ought to be able to. we won't rebase again until the next rc | 14:00 |
| amitk | rtg_: do you plan on make a separate source package for imx51 karmic? | 14:03 |
| amitk | *making | 14:03 |
| rtg_ | amitk, if its on a topic branch, then yes. | 14:04 |
| rtg_ | amitk, do you have something functional yet for karmic? | 14:04 |
| amitk | rtg_: yes, cleaning up the patchset (merging, annotating, etc.) currently. | 14:05 |
| amitk | rtg_: but I won't be able to fix up a new source package for the next upload. | 14:06 |
| apw | amitk, yeah its basically there, just pushed one more patch | 14:06 |
| rtg_ | amitk, then why not put it in the master branch? Its not like the current imx51 flavour is doing us much good, is it? | 14:07 |
| amitk | rtg_: It would certainly make it easier for me to put things in master. And yes, the current imx51 flavour is a dud. | 14:09 |
| amitk | rtg_: there might be rebase conflicts though, until .31 is released | 14:09 |
| rtg_ | amitk, I'd just as soon avoid the hassle of a topic branch if you have something that works. 2.6.31 is getting pretty close do being done, so I wouldn't expect many rebase conflicts. | 14:11 |
| Kano | apw: do you know why dm is still borken and needs a patch? | 14:14 |
| apw | i don't know that dm is broken | 14:14 |
| Kano | http://kanotix.com/files/excalibur/linux-2.6.31-generic/source/ | 14:15 |
| Kano | i also would suggest to apply at leaste the copy ieee header patch | 14:15 |
| Kano | that will be needed for dvb external | 14:15 |
| Kano | not yet compiling with .31 however, but thats a requirement i found for .30 | 14:16 |
| Kano | 2.6.31-rc2-v2-dm-table-pass-device-s-length-to-device_area_is_valid.patch | 14:16 |
| Kano | that was needed to make dm work | 14:16 |
| amitk | apw: why don't we set CONFIG_IP_PNP? | 14:21 |
| apw | what the heck does that do? | 14:21 |
| amitk | kernel autoconfiguration (bootp, dhcp, rarp) for diskless systems | 14:21 |
| amitk | https://wiki.ubuntu.com/KernelTeam/2.6.28-2-generic-config doesn't have any remarks | 14:22 |
| amitk | apw: CONFIG_ATM=y? | 14:38 |
| rtg_ | amitk, every desktop should have an ATM stack | 14:38 |
| apw | i would say take the default from i386 if in doubt | 14:39 |
| apw | and list the defaults you think are wrong separatly... we can then review those now or at sprint | 14:40 |
| rtg_ | amitk, if size is not a consideration, then I'd like to see as many common selections as possible across ARM and x86. | 14:40 |
| amitk | rtg_: size isn't a consideration on ARM anymore. But I assume that for drivers/protocols that can be modules, we default to modules, except when boot critical. And ATM didn't fit that category :) | 14:41 |
| rtg_ | amitk, ATM is a protocol stack, so I'm not sure why its built in. apw ? | 14:42 |
| * apw will check hang on | 14:43 | |
| amitk | apw: that was meant as a question. Why it is built-in? Not "should I build it in". But I'll stop bothering you and just keep a list of options needing review | 14:43 |
| apw | i thought at the jaunty uds we decided to move a lot of those =y | 14:44 |
| apw | bringing in the stacks themselves, not the drivers | 14:44 |
| rtg_ | well, the stacks that are in common use. When was the last time you connected to an ATM device? | 14:45 |
| apw | indeed, have to agree it seems anomolous | 14:45 |
| apw | trying to see when it occured to see if there is some reasoning supplied | 14:46 |
| rtg_ | it could be we were all so zoned out by that time in the review that it just slipped by | 14:46 |
| apw | heh yeah quite likely | 14:46 |
| apw | 'its a stack =y' | 14:46 |
| rtg_ | apw, I'm fine with CONFIG_ATM=m across the board | 14:47 |
| apw | rtg_, yeah me too... will wait for amitks list and we can do them all together | 14:48 |
| apw | it think he and brad will explode if the config changes radically again before they can even finish rebasing onto the current one | 14:49 |
| rtg_ | apw, besides, we have a bit more experience now with what is _actually_ boot essential. | 14:49 |
| rtg_ | apw, ack on the stable config for now :) | 14:49 |
| apw | yes very true ... | 14:49 |
| rtg_ | apw, A3 is released, so I guess we can crack a kernel just about anytime. | 15:12 |
| apw | rtg_, anything pending? | 15:12 |
| apw | from your end? if not i'll do the do on it | 15:13 |
| rtg_ | apw, you might check with jjohansen. how about the printk format fix? | 15:13 |
| apw | yeah good point | 15:13 |
| rtg_ | apw, I'd say just apply it and he'll pick it up when he rebases. | 15:13 |
| apw | yeah will do that | 15:14 |
| rtg_ | apw, I've about got it built, so I can do some boot testing while working on rfkill | 15:14 |
| apw | cool | 15:15 |
| apw | i'll shove that one fix in and tie the bows on it | 15:15 |
| * smb_tp waves to chris-qBT, thanks for testing all that kernels :) | 15:19 | |
| chris-qBT | smb_tp, no problems :) | 15:20 |
| chris-qBT | I was surprised no one else reported that problem. | 15:20 |
| chris-qBT | I guess jfs is not used as much as I thought | 15:20 |
| smb_tp | chris-qBT, Yeah, that seem to be true. Even not upstream | 15:21 |
| chris-qBT | smb_tp, Thanks a lot for fixing this. This bug was annoying me since rc1. | 15:21 |
| smb_tp | Or we found it first. apw will make sure it is in our next upload | 15:21 |
| chris-qBT | great. | 15:21 |
| apw | smb_tp, is that that nasty rcu freeing things which are not free looking bug? | 15:22 |
| smb_tp | apw, yes | 15:22 |
| apw | yeeks, that one is very nasty ... use after free ... be worth getting in me thinks, get it on the mailing list so rtg can review it | 15:23 |
| * smb_tp is lready typing | 15:24 | |
| apw | ack | 15:25 |
| rtg_ | apw, you gonna get that jfs patch in before you tie the ribbon ? | 15:46 |
| apw | rtg yep, | 15:46 |
| bjf | rtg, when building the kernel, where is the knob to not spawn multiple compiles? | 18:00 |
| rtg_ | bjf: CONCURRENCY_LEVEL=1 | 18:05 |
| rtg_ | apw, its all built, I'll upload in a bit | 18:35 |
| apw | rtg_, thanks ... | 18:35 |
| rtg_ | apw, you gonna send out the ABI bump announcement? Its uploading ... | 18:41 |
| apw | rtg_ ack | 18:42 |
| rtg_ | apw, how is it that dmraid4-5 ever compiled? | 18:43 |
| apw | thats a goodie | 18:43 |
| apw | cause on all of our architectures test_bit is a #define | 18:44 |
| apw | so its defined as (soemthing) | 18:44 |
| apw | so it _happens_ to be valid code | 18:44 |
| rtg_ | ah, makes sense | 18:44 |
| apw | its wild amazing luck | 18:44 |
| rtg_ | I pushed that fix | 18:44 |
| apw | ack | 18:44 |
| rawler | hi people.. I've got a _really_ weird problem with a Karmic kernel ATM, I figured maybe someone wants debug-info before I reboot? | 20:03 |
| rawler | basically, "du -sh" at a certain folder chews disk like a maniac, and consumes 100:s of MB of rsize.. | 20:04 |
| rawler | oh.. cd:in into a certain subfolder makes my shell go nuts as well.. :S | 20:06 |
| rawler | strac:ing the process (either DH), or the shell process, I get TONS of getdents64() calls.. | 20:08 |
| amitk | rawler: best thing would be to note all these observations with logs to a bug in launchpad | 20:08 |
| rawler | is there anything in particular to make note of? I've got a really bad experience submitting bugs to LP.. even when I submit bugs with a solution (I.E. working patch), I've seen it take years to get attention.. | 20:10 |
| rawler | so, for a problem like this (which may perhaps even go away after a reboot), I'm naturally a bit reluctant.. | 20:10 |
| rawler | this is interesting though.. ls says the _directory_ itself is 170M.. :S | 20:11 |
| jjohansen | rawler: the best way to capture this is ubuntu-bug -p linux | 20:14 |
| jjohansen | if it goes away after boot then there is a least a record of it in launchpad | 20:14 |
| rawler | seriously? is that going to figure exactly what happened here? | 20:15 |
| jjohansen | also if it goes away after boot, it is going to be really hard to replicate | 20:15 |
| jjohansen | rawler: no, but it does grad a lot of info and feed a bug into lp | 20:15 |
| rawler | yeah, my thought exactly.. which is why I wondered if someone wanted to do some short investigation BEFORE I reboot.. :) | 20:15 |
| jjohansen | rawler: what kind of short investigation? ssh into the box? | 20:16 |
| rawler | (although, considering the directory-entry itself is of ridiculous size, I kindof doubt that the problem will go away.. my prime suspect right now is that ext4 have done something bad.. :S) | 20:17 |
| rawler | jjohansen: well, I thought maybe one could start by feeding specific info to a pastebin or something like that.. :) | 20:17 |
| jjohansen | rawler: ugh, I hope not | 20:17 |
| jjohansen | rawler: feel free to paste away | 20:17 |
| rawler | neither do I.. :) | 20:17 |
| rawler | well, I don't know how to troubleshoot this further.. ls on the directory kills the shell, du on the directory kills du.. (or at least, takes a ridiculous amount of time), and the directory itself is silly large.. | 20:18 |
| rawler | http://pastebin.com/d7cae0828 <- info is the culprit.. look at the size.. can a dir-entry even grow that big? | 20:19 |
| rawler | also, it must have happened fairly recently.. I clean .Trash fairly often so anything taking THIS much time would have been noted before.. | 20:20 |
| rawler | is it better to take this directly to ##kernel, or so? | 20:21 |
| jjohansen | rawler: what does strace ls on the dir show | 20:23 |
| jjohansen | and what is in dmesg, when ls gets killed | 20:23 |
| rawler | it goes http://pastebin.com/d396295e9 | 20:24 |
| rawler | dmesg shows nothing in particular.. | 20:24 |
| rawler | ls doesn't die.. it just spins the disk like crazy, and consumes ridiculous amounts of ram.. (100s of meg after a while) | 20:25 |
| jjohansen | rawler: well that isn't surprising considering the size of directory | 20:26 |
| rawler | actually, my bad.. ls doesn't seem to go nuts with ram.. THAT is just du who does.. ls keeps to a few megs of rsize.. | 20:26 |
| rawler | but, what could have happened making the directory that big all of a sudden? | 20:27 |
| rawler | and, 170meg directory-entry.. that's absolutely HUGE? | 20:27 |
| jjohansen | what do fsck -nf show | 20:28 |
| rawler | that's millions of files? | 20:28 |
| jjohansen | maybe, I am wondering if it can spot format corruption | 20:28 |
| rawler | fsck while the fs is mounted? | 20:28 |
| jjohansen | well -n == nochanges | 20:29 |
| rawler | yeah.. I just thought about false positives while checking a mounted FS.. :) | 20:30 |
| jjohansen | it still not ideal but when trying to avoid a reboot ... | 20:30 |
| rawler | (it's just done pass 1 so far, but i does complain about some maybe 75 orphaned inodes.. | 20:31 |
| rawler | damn.. I've gotta re-run.. I forgot to set LANG before fsck, and I assume you don't read swedish.. ;) | 20:32 |
| rawler | it also complains something about a bunch of faulty blocks.. I'll pastebin it all.. | 20:32 |
| rawler | http://pastebin.com/da2bb66a | 20:33 |
| rawler | oh, yeah.. I forgot to mention one piece of information that may be relevant.. I run on mdadm-raid1, and yesterday I did "replace" one of the disks.. (actually, just re-partitioned it, but still) | 20:36 |
| rawler | it maybe also have made something funky, perhaps.. | 20:36 |
| rawler | dmesg (and uptime just in case).. problems were discovered today, and I'm pretty sure I emptied trash this monday without problems | 20:39 |
| jjohansen | rawler: sigh mdadm-raid1 and repartion, I have a feeling this is going to be one of those bugs that isn't easily reproduced | 20:43 |
| rawler | http://pastebin.com/d3f52b941 | 20:43 |
| rawler | jjohansen: me too.. which was the largest reason why I felt a LP-bug would just add noise and help nobody.. :) | 20:43 |
| rawler | is it interesting to keep troubleshooting, or should I just reboot and fsck and be done with it? | 20:43 |
| rawler | as | 20:44 |
| rawler | as I said, this IS a weird problem.. :) | 20:45 |
| jjohansen | rawler: I don't see anything to follow, the interesting bit has already happened and left its mess | 20:45 |
| jjohansen | yep | 20:45 |
| jjohansen | I would fsck it and see if that fixes it | 20:45 |
| rawler | oki.. I'll just make it work again and be done with it then.. :) | 20:45 |
| rawler | thanks for now, and have fun! | 20:45 |
| praveen | hiiii | 21:34 |
| praveen | looking for source code of fopen function | 21:35 |
| praveen | want to know if fopen calls open to get its task done in the end | 21:35 |
| rawler | jjohansen (or anyone else reading): well, fsck showed no problems after a clean unmount.. :S | 21:49 |
| rawler | now trying to rm the problematic dir, but it's been going on for over an hour, with no luck.. :S | 21:51 |
| rawler | one peculiar thing is that it seems to make a lot of others apps freeze up for a while.. :S | 21:53 |
| rawler | although, it now seems like there's actually really nothing wrong on the fs (thank god).. when stracing the rm-process it actually prints the files it removes while working... for some reason, it seems nautilus actually has created millions of files.. :S | 22:00 |
| rawler | of the form file.<incrementing_number>.extension.trashinfo.. | 22:00 |
| rawler | in any case, not an ext4-problem, or a softraid-related problem (again, thank god).. just nautilus having done something stupid.. | 22:01 |
| jjohansen | rawler: well it is nice to hear that it is unlikely the kernel but it is still disturbing | 22:02 |
| rawler | yeah, kindof.. there's thousands of .trashinfo for each file I've removed during the last week.. that's what made the dir so big, and I guess the utils didn't really cope all that well with that huge amounts of files.. | 22:04 |
| rawler | interesting kernel-related question though; since it makes my system half-freeze for up to 15-secs at a time, could this be used to DOS a multi-user-system? | 22:06 |
| rawler | it certainly doesn't seem like the I/O is CFQ-scheduled while doing this... :) | 22:07 |
| jjohansen | rawler: possibly, though with the proper limits set a user could be prevent from ever creating those millions of files | 22:08 |
| rawler | oh? in ulimit, or where? | 22:09 |
| jjohansen | well ulimit would be run time limits I was thinking more of quotas | 22:11 |
| rawler | btw, while I'm here, I've actually already devised a small prgram that really sinks my desktop machine I/O-wise.. | 22:13 |
| rawler | what it does is allocate just a little too much ram, so the swap gets used... | 22:13 |
| jjohansen | rawler: yep that will do it | 22:14 |
| rawler | then iterate over it's memory, doing some read/write in a cyclic fashion.. it absolutely kills my desktop-machine.. power-cycle or sysrq is the only way to kill it.. logging in through ssh will just time out, so it's almost impossible to terminate this remotely | 22:16 |
| rawler | on my laptop, it's not just as bad.. it definately gets tired, but it doesn't keel over and die.. | 22:16 |
| rawler | the interesting part of this, is that on my desktop, I've actually set a ulimit rss-size on half my ram.. | 22:17 |
| rawler | so, in theory, other apps should be able to use the remaining 512 GB, which SHOULD be enough to login and kill the memhog.. :S | 22:17 |
| rawler | I've been waiting to get it tested on more systems before concluding anything, but isn't this also a potential DOS on multiuser-systems? | 22:18 |
| rawler | esp. if ulimit is not effective? | 22:18 |
| jjohansen | rawler: in theory, but swap storms can make apps very unresponsive if they involve any disk io | 22:18 |
| rawler | how come? if ulimit is limiting rss, I mean? | 22:19 |
| rawler | it still shouldn't be much worse than, for instance copying a file, I'd presume? | 22:20 |
| jjohansen | rawler: well, you can get into situations where you are triggering swap, even with the rss limit set to half. | 22:21 |
| jjohansen | rawler: it would depend on what kind of mem the other apps are using | 22:21 |
| jjohansen | rawler: not saying it isn't broken, just it is possible | 22:22 |
| rawler | yeah, but things like ssh? it could certainly do with 512MB ram before, when that was all that was in the system? | 22:22 |
| rawler | oki.. seems a bit worrying to me.. :) (that's administrating a multi-user-system at work.. sure, everyones benevolent NOW ;) ) | 22:23 |
| jjohansen | well ssh still works with a lot less. But again its the sum of the parts, and if you manage to push a machine into a swap storm all bets are off | 22:23 |
| rawler | ouch.. :S | 22:24 |
| rawler | sounds like a minefield.. just hoping someone doesn't go nuts with memory.. | 22:24 |
| jjohansen | rawler: it does sound broken, but I would want to see a lot more detailed accounting of where all the memory is being used | 22:24 |
| rawler | if you're interested, compile up http://pastebin.com/df09cd1c and test on your machine.. :) | 22:25 |
| jjohansen | rawler: yeah, I am not a fan of swap, from a usability stand point it can be better to fail things than going to swap | 22:26 |
| rawler | well.. swap is good in theory, provided it does not burden the rest of the system more than other I/O access does.. (like, copying a file) | 22:26 |
| rawler | swap in THEORY, shouldn't be any worse than an app mmap():ing a large file.. | 22:27 |
| rawler | although, practice seem to differ.. :) | 22:27 |
| rawler | in any case, I think maybe ubuntu, especially -server, should think a little about this.. it may still be an issue with some part of my specific system that makes it completely freeze and die.. but in that case, I wonder exactly what that circumstance is, and if it's likely to affect others.. | 22:29 |
| rawler | jjohansen: oh, btw.. if you (or someone else) DO decide to test my little program, do remember that oom-kill is triggered by sysrq+f.. (you won't be able to look it up after ;) ) | 22:31 |
| rawler | and, if you're on a 32-bit-system with more than 2GB ram, you'll want to run the program several times at once, each instance set to consuming a couple of gigs.. | 22:32 |
| jjohansen | hehe, yeah that is why you don't run something like that on your main system :) | 22:32 |
| rawler | yep.. :) | 22:32 |
| rawler | also, I'm a bit curious exactly how evil that is in virtualization.. I.E. what happens on a KVM-system.. does other vhosts also get bogged all down to unusable, or does that somehow work differently.. | 22:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!