| Kenny_Duehit | anyone have time to help me with a Kernel Panic I am having? it's grub related and occurs on boot up. | 00:03 |
|---|---|---|
| stenten | If I'm git-bisecting, is this how I'm supposed to compile the kernel after getting a commit to test? https://wiki.ubuntu.com/Kernel/Dev/QuickBuildLocal | 02:38 |
| stenten | I tried using the directions here: http://ubuntuforums.org/showthread.php?t=311158 but it failed after compiling for 3+ hours: http://paste.ubuntu.com/473800/ | 02:40 |
| lamont | where's my ppc kernel guy | 04:29 |
| jk- | lamont: i don't think that's me, but I can try to help :) | 04:33 |
| lamont | root 31624 0.0 0.1 5624 2196 ? D Aug02 0:00 \_ /usr/lib/apt/methods/http | 04:36 |
| lamont | jk-: it's more one of "want me to look at anything before I stab the poor Xserve?" | 04:37 |
| lamont | last thing in dmesg is the RAID check starting almost 2 days before the timestamp on the build log | 04:38 |
| lamont | I'm of a mind to just reboot it and see when it gets mad next | 04:39 |
| lamont | or maybe even just trigger a check of the array to see if it crashes again faster | 04:40 |
| lamont | yeah - that'll let it get started again before I sleep | 04:40 |
| lamont | and off to bed with me | 04:41 |
| jjohansen | rebooting | 04:45 |
| MTecknology | apparmor is in the mainline kernel... isn't it? | 05:18 |
| MTecknology | I'm not able to find that little guy | 05:19 |
| MTecknology | /SECURITY_APPARMOR = :( | 05:19 |
| MTecknology | Is that not until 2.6.36? | 05:21 |
| starkraving | The last few kernel releases have disabled my wireless card, Dell Inspiron 6400. With the new kernel release today the last one that worked has now rolled off of grub. Any idea how to get it back? | 06:34 |
| starkraving | The wireless card shows up in LSPCI but it doesn't show up in my list of interfaces | 06:42 |
| === lag is now known as tjmjigtx | ||
| === tjmjigtx is now known as lag | ||
| === yofel_ is now known as yofel | ||
| cybrocop | Hi, I wonder if I can ask a Linux kernel/system question. I don't have a bug necessarily, but I have a question about performance of certain activities. | 10:41 |
| cybrocop | Does the "cp" command make any special performance optimizations to make it run faster than a custom written C code (read a block from source and copy a block to destination). I realize the source of cp is available but I was hoping someone could give me a quick answer. I have a software that I'm writing that will need to (among other things do file copies), and I wanted to implement the copying myself in order to keep track of bandwidth. (Don't | 10:44 |
| cybrocop | want to copy too fast and use up IO for other procs.) | 10:44 |
| === amitk is now known as amitk-afk | ||
| === lifeless_ is now known as lifeless | ||
| lapion | anyone from ubuntu-kernel-lucid-ppa in here ? | 11:19 |
| lapion | Has support been removed for /dev/dsp ? | 11:20 |
| apw | lapion, not sure what PPA that is, got a url ? | 11:20 |
| lapion | ppa,launchpad.net/kernel-ppa/ppa/ubuntu | 11:23 |
| apw | lapion, so do you mean the maverick kernel in there? | 11:23 |
| lapion | apw yes.. | 11:25 |
| lapion | the latest versions the i915 xserver/kms doesn't crash | 11:26 |
| apw | yes the maverick kernel has OSS support turned off, as maverick supplies OSS compatibility via pulseaudio | 11:26 |
| lapion | as often | 11:26 |
| lapion | yes but there is a version n there for lucid as well... | 11:27 |
| apw | lapion, yep, understood, but the version compiled for lucid is the same config as for maverick | 11:27 |
| apw | so i can believe that OSS support is missing on lucid if you are using that kernel | 11:28 |
| apw | or better put, using that kernel on lucid | 11:28 |
| lapion | slight problem, mythtv doesn't work well with alsa or pulse, and the tvcard has it's own dsp running at 32k the only way to get it to work is by using dsp in mythtv | 11:30 |
| apw | lapion, a problem indeed, not sure what to say, currently there is no suoport for that kernel on non-server, and worse currently no mechanism for it to have a different configuration from that in maverick -- even if we wanted to fix it | 11:32 |
| apw | tis not even possible to file a bug against the package as the package is not yet in the official archive | 11:33 |
| apw | lapion, i suspect your best bet is to report this on the kernel-team@ email list ... and we can think about it | 11:34 |
| lapion | any info on how to add dsp-emulation on pulse ? | 11:35 |
| lapion | *to | 11:35 |
| apw | lapion, that i have no idea about sorry ... drop an email to the list and we can start the discussion | 11:36 |
| cking-afk | http://launchpadlibrarian.net/53159327/buildlog_ubuntu-maverick-i386.fwts_0.17.5_CHROOTWAIT.txt.gz | 11:39 |
| === cking-afk is now known as cking1 | ||
| lapion | apw, list of the ppa ? | 11:52 |
| apw | i mean email to kernel-team@lists.ubuntu.com ... thats the team list | 11:52 |
| cking1 | apw, is your mumble working?! | 12:00 |
| lapion | apw will send the mail laters, thanks | 12:07 |
| cking1 | apw, http://smackerelofopinion.blogspot.com/2009/06/looking-at-intel-x-hangs.html | 12:12 |
| gnomefreak | has the nvidia+2.6.35.13 been fixed. (getting black screen and cant do anything) | 12:12 |
| tseliot | apw, cking1: are we going to get this patch in maverick (as a backport)? http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ | 12:14 |
| tseliot | gnomefreak: what bug report would that be? | 12:14 |
| gnomefreak | tseliot: not sure if there was one. but as i understand it nvidia hasnt yet supported the new kernel i remember someone saying that. i will file a bug now igf you need one :) | 12:15 |
| gnomefreak | oh wait | 12:15 |
| gnomefreak | tseliot: i did file one. bug 613458 | 12:17 |
| ubot2 | Launchpad bug 613458 in nvidia-graphics-drivers (Ubuntu) "After upgrading to lates kernel i get a black screena nd cant do anything except ctrl+alt+delete to reboot (affects: 2) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/613458 | 12:17 |
| tseliot | gnomefreak: ok, Nvidia should reply in that report | 12:19 |
| tseliot | I've just subscribed them | 12:19 |
| gnomefreak | tseliot: thanks | 12:19 |
| tseliot | np | 12:19 |
| === amitk-afk is now known as amitk | ||
| cking1 | apw, http://kerneltrap.org/Linux/Removing_The_Big_Kernel_Lock2 | 13:05 |
| amitk | cking1: if you want to talk to arnd about details, pop into #linaro. He is working in Linaro Kernel consolidation WG | 13:11 |
| === amitk is now known as amitk-afk | ||
| apw | amitk-afk, thanks | 13:33 |
| lamont | [856361.776368] Warning: dev (tty7) tty->count(4) != #fd's(3) in tty_release_dev | 14:03 |
| lamont | ew | 14:03 |
| apw | lamont, heh thats the bug i am chasing | 14:03 |
| lamont | well then, I'll go back to other things | 14:03 |
| apw | (well one symptom thereof anyhow | 14:03 |
| lamont | 'twas logcheck spam | 14:03 |
| lamont | well, maybe not _spam_, per se | 14:03 |
| lamont | though that does remind me that I need to reboot for the shiny new kernel | 14:04 |
| apw | nice new shiney crashes | 14:04 |
| tgardner | apw, https://pastebin.canonical.com/35537/ | 14:09 |
| === jjohansen is now known as jj-afk | ||
| === bjf[afk] is now known as bjf | ||
| bjf | moin | 14:35 |
| JFo | moin bjf | 14:37 |
| tgardner | apw, how about https://pastebin.canonical.com/35546/ ? | 14:50 |
| apw | tgardner, other than putting filling in the close time at the the point that we put CLOSING in i think that could work | 14:52 |
| tgardner | apw, isn't the tty structure released after closing? | 14:52 |
| * apw reboots to test the EAGAIN thing | 14:52 | |
| apw | tgardner, yeah i mean the time needs to be set correctly at the same instant we put in TTY_CLOSING | 14:53 |
| apw | into the flags ... as its that we use to detect closing and when we start checking the times | 14:53 |
| tgardner | apw, well, its done under tty_mutex | 14:54 |
| apw | tgardner, yeah its more stylistic, in case someone split them later, as they are needed to be together the intent is better served by putting them together | 14:54 |
| tgardner | apw, then we need a separate function to consolidate the set_bit(TTY_CLOSING, &tty->flags) statements | 14:55 |
| apw | and i suspect that that is the right thing for an upstream patch, for somethig we want to not collide to much not so much | 14:55 |
| === amitk-afk is now known as amitk | ||
| tgardner | apw, like upstream is gonna take this anyways | 14:56 |
| apw | well indeed | 14:57 |
| tseliot | apw: shall I take it as a no on this? http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ | 15:05 |
| tgardner | smb, do you think this LVM snapshot regression fix will have an impact no how bad system response sucks when doing qemu/armel builds? I assume its related since bind mounts are being torn down. | 15:07 |
| apw | tseliot, the patch isn't very big and quite self contained | 15:07 |
| apw | so its not a flat NO on first viewing | 15:07 |
| apw | are the patches 'finished' yet though? | 15:07 |
| smb | tgardner, Only if fs freeze/unfreeze calls would be involved. The other thing is our still pending writeback suckiness | 15:08 |
| tgardner | smb, my desktop would freeze for 20-30 seconds at a time during the build. | 15:08 |
| smb | tgardner, The snapshot freezes were actual hangs. Not to be recovered without force reboot | 15:09 |
| smb | tgardner, I would think you see the "we do sync syncronous" issue | 15:09 |
| apw | smb, where are we with the write back stuff ? | 15:09 |
| smb | apw, The patches seem to be ok from testing, but feedback from Jens is 0 of 4 | 15:10 |
| apw | 0 of 4 ? | 15:11 |
| smb | I wonder if I should just send them to Greg with him on cc | 15:11 |
| smb | apw, Tried 4 times got 0 response | 15:11 |
| smb | apw, The unfortunate thing is that the set is 14 patches or so | 15:12 |
| smb | apw, And not the shortest too | 15:12 |
| apw | smb, nasty ... | 15:13 |
| smb | And then there seem to be even more issues (like the other thing that an active writer can starve other things) or potentially fs specific slowness in other cases... | 15:14 |
| smb | tgardner, is that on boxes that run Maverick, too? | 15:14 |
| apw | tgardner, the changes tseliot is pointing to are interesting as they help with intereactive performance under heavy IO load | 15:14 |
| apw | smb ^^ | 15:14 |
| * tseliot nods | 15:14 | |
| tgardner | smb, no, I'm running the lucid -proposed kernel | 15:15 |
| tgardner | 2.6.32-24-generic | 15:15 |
| tgardner | dunno about maverick | 15:15 |
| smb | tseliot, apw, Is that about lumpy reclaim again? | 15:15 |
| apw | smb, indeed lumpy | 15:16 |
| smb | Which is the one we discussed yesterday which seems unfinished in discussion | 15:16 |
| smb | apw, You can try in Maverick. If it does not explode I might think again. :) | 15:17 |
| apw | may well be, hense my question on its completedness, but its very small | 15:17 |
| smb | tgardner, Ok, potentially you could try the writeback test kernel | 15:18 |
| smb | If I find the place... | 15:18 |
| tseliot | smb: I'm not sure about what patch you're referring to but it might be the same | 15:18 |
| smb | tseliot, I saw some lines with lumpy reclaim and I have been seeing a discussion upstream about that. Which seemed to go on still. So my impression was this is still in progress | 15:19 |
| smb | tgardner, bug 585092 has a reference to the test kernels | 15:19 |
| ubot2 | Launchpad bug 585092 in linux (Ubuntu Maverick) (and 2 other projects) "giant IO delays on unmount (affects: 1) (heat: 24)" [Medium,Fix released] https://launchpad.net/bugs/585092 | 15:20 |
| tseliot | smb: this discussion? http://lkml.org/lkml/2010/8/1/40 | 15:20 |
| smb | I think yes | 15:20 |
| tseliot | ok | 15:21 |
| tseliot | let's see how it goes then | 15:21 |
| tseliot | the discussion, that is | 15:21 |
| smb | Assumed so. :) | 15:21 |
| tseliot | good | 15:21 |
| smb | It just seemed to hot at least to jump on it from Lucid | 15:22 |
| tgardner | smb, http://people.canonical.com/~smb/lp585092/linux-image-2.6.32-23-generic_2.6.32-23.38~lp585092v4_amd64.deb ? | 15:22 |
| smb | tgardner, there should be a -24 as well... | 15:23 |
| tgardner | ah, no should be 24 | 15:23 |
| tgardner | right | 15:23 |
| smb | tgardner, The comments from someone in the bug seem to indicate even more slackness. So the issue you see might still be there. But if it survives a build box too it at least should not regress. | 15:25 |
| === sconklin-gone is now known as sconklin | ||
| tgardner | smb, rebooting for your test kernel | 15:26 |
| === amitk is now known as amitk-afk | ||
| smagoun | smb: Hi, I noticed that the lpia flavor of linux-ubuntu-modules-2.6.24 (2.6.24-28.46) in hardy-security FTBFS. Is that a known issue? (I pinged you since your name is on the upload) | 16:01 |
| smagoun | smb: https://edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24 | 16:02 |
| smb | smagoun, Let me check the versions. The latest security should have fixed the FTBS but the real lpia flavour is build through OEM anyway. | 16:03 |
| smb | Oh wait its. modules | 16:03 |
| tgardner | lum | 16:04 |
| smb | yeah. Though there was no lum upload this time. So this would be old | 16:05 |
| smagoun | smb: yeah, it's old (April). I'm auditing a tool we use to track security updates, I noticed that distro's lpia l-u-m wasn't what I expected | 16:06 |
| smb | smagoun, I cannot find the reason for the FTBS on LP but likely it was because the kernel itself FTBSed. Then probably doing a retry should fix it | 16:06 |
| * smb wonders whether he can click on retry... | 16:08 | |
| smb | Seems to work. Now lets see | 16:09 |
| smb | smagoun, Seems to have failed again, but as long as it does not tell me why, I have a hard time to say whether or how to fix it. | 16:17 |
| smagoun | smb: alright, I'll talk to a LOSA | 16:18 |
| smb | smagoun, ok, let me know what you find out. | 16:19 |
| apw | http://people.csail.mit.edu/albert/bluez-intro/x232.html | 16:21 |
| === BenC_ is now known as BenC | ||
| vanhoof | pgraner: ping | 16:49 |
| apw | cking1, i can still _see_ you | 17:24 |
| === cking1 is now known as not-really-here- | ||
| apw | not-really-here-, don't make me kick you | 17:30 |
| * not-really-here- leaves | 17:34 | |
| === not-really-here- is now known as cking-gone | ||
| bjf | JFo, apw, i've just created https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat , I don't know where it's _supposed_ to go but there it is | 18:17 |
| JFo | cool | 18:18 |
| * JFo looks | 18:19 | |
| apw | bjf, i like it, not sure thats 'Stable' related at all ... | 18:20 |
| apw | bjf, perhaps PatchCommentryFormat | 18:20 |
| apw | (but spelt correctly) | 18:20 |
| smb | Though some of the musts or more applying to SRU than the general patch submission | 18:21 |
| bjf | apw, the stable team requires the subject line format and the buglink which is just "nice to have" in dev kernel patches | 18:21 |
| apw | bjf, i don't think it should be nice to have in dev patches ... i think we should be consistant | 18:22 |
| bjf | apw, also the double ack | 18:22 |
| apw | the only difference should be the number of acks | 18:22 |
| apw | so two ack* | 18:22 |
| apw | * stable only | 18:22 |
| apw | should be the only difference to my mind | 18:22 |
| bjf | and having two ack's for dev wouldn't be a really bad thing | 18:23 |
| ogasawara | we do enforce the two ack's after kernel freeze for the dev kernel | 18:23 |
| apw | and the rest of the page is mostly about formatting, and that should be consistant both sides of the line | 18:23 |
| apw | how to say where it came from, how to form the front of the title etc etc applied to dev too | 18:24 |
| smb | apw, Well I guess if you and ogasawara look at it and agree then it is fine. I looked over that more from the SRU point of view | 18:24 |
| ogasawara | I agree with apw we should be consistent with both the dev and stable releases in terms of patch submission | 18:25 |
| === bjf is now known as bjf[afk] | ||
| pgraner | vanhoof, pong | 19:08 |
| === sconklin is now known as sconklin-gone | ||
| * apw s done | 19:42 | |
| === emma is now known as em | ||
| * ogasawara lunch | 21:07 | |
| alex_joni | is there a better place than this to ask a LiveCD question? | 23:09 |
| virtuald | alex_joni: yes #ubuntu | 23:14 |
| alex_joni | not the type of question I had in mind, but thanks anyways | 23:20 |
| === em is now known as emma | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!