| vrsa | i just installed the new kernel and now my video is pooched | 03:13 |
|---|---|---|
| vrsa | any ideas? | 03:13 |
| === emgent_ is now known as emgent | ||
| === mdz_ is now known as mdz | ||
| amitk | smb_: when do you plan to uploaded the -updates kernel? | 09:26 |
| smb_ | amitk, for Jaunty? We wanted to wait somwhen into this week to see whether something serious pops up | 09:27 |
| amitk | smb_: yes jaunty | 09:28 |
| smb_ | amitk, So mid to end of this week | 09:29 |
| amitk | cool | 09:29 |
| apw | cking, ok figured out this VT-1 issue ... its not the kernel | 09:54 |
| apw | its actually the kexec reboot. when you use that it no longer has any output on it | 09:54 |
| cking | I though kexec reboot had been turned off? | 09:56 |
| cking | s/though/thought/ | 09:56 |
| apw | nope. not according to Keybuk noone has done that. it may be this is the trigger for that to change however. filing a bug on kexec now | 09:57 |
| apw | (though it is _likely_ a kernel bug) | 09:57 |
| apw | cking, in fact it was fixed in intrepid and not yet so in jaunty (bug #251242) | 10:00 |
| ubot3 | Malone bug 251242 in kexec-tools "Always kexecs on shutdown/reboot" [Undecided,Fix released] https://launchpad.net/bugs/251242 | 10:00 |
| cking | apw, interesting. So this is not specific to any hardware, just only when one reboots with kexec | 10:02 |
| apw | cking, i cannot confirm or deny that. i can say the issue only appears for me if i have kexec reboot enabled on my hardware. from the release sprint i would say that the only people seeing it were those who had had a reason to install kexec tools as part of some testing we had been doing | 10:05 |
| apw | the only other person i saw with the issue was mdz who i believe did a lot of the kcrashdump testing and thus would have it installed | 10:05 |
| cking | makes sense | 10:06 |
| apw | if you are bored you could install kexec-tools and try a reboot for me. its a simple change to turn it off even if it remains installed | 10:06 |
| mdz | apw: yes, last I checked, installing kexec-tools was actively harmful and could not be recommended (much less installed by default) | 10:07 |
| mdz | apw: in my opinion, installing the package should not imply any change in behavior in itself | 10:08 |
| mdz | sounds like you agree, from the bug | 10:09 |
| apw | mdz indeed not. there is a separate bug bug #251242 for changing the default behaviour to not use kexec, making it opt-in. this got fixed in intrepid but not jaunty | 10:09 |
| ubot3 | Malone bug 251242 in kexec-tools "Always kexecs on shutdown/reboot" [Undecided,Fix released] https://launchpad.net/bugs/251242 | 10:09 |
| mdz | apw: yes, I reported it ;-) | 10:09 |
| mdz | apw: I don't think it ever got fixed in Intrepid either, to be quite honest | 10:10 |
| apw | doh :) so i think that needs nominating for jaunty. | 10:10 |
| mdz | despite the upload and changelog entry | 10:10 |
| apw | i am guessing even if they fixed it for new users, they wouldn't have been able to for us older users | 10:10 |
| mdz | apw: it should have just been changing the default setting in a config file, I don't see why it wouldn't apply to new users | 10:11 |
| apw | yeah it should be done for new users, but i suspect changing the file once made is likely not allowed as i may have chosen to be happy with it. but we do need to check the package as is and make sure its defaulting off | 10:12 |
| * apw downloads it ... and pokes | 10:12 | |
| mdz | the patch looked reasonable (http://launchpadlibrarian.net/16568735/kexec-tools_20070330-4ubuntu5_20070330-4ubuntu6.diff.gz) but I think the script may have been buggy | 10:12 |
| apw | mdz yeah it does. the new stuff is different using a true/false variable and the default is very much a true right now | 10:13 |
| apw | i guess its time for a patch | 10:14 |
| Whoopie | smb_: Hi, would you accept a patch for jaunty to update tp_smapi to 0.40 and re-add the hdaps_ec module? | 10:47 |
| smb_ | Whoopie, it came up just this morning again. There have been different opinions about that on the kernel team list. I am not completely against it. But as it is always a maintenance burden the question about getting things upstream is valid as well. | 10:49 |
| Whoopie | smb_: oh, what a strange co-incidence. ;) | 10:53 |
| amitk | smb_: do you know if upstream (staging/) has rejected the hdaps module? | 11:07 |
| amitk | if not, perhaps Whoopie could ping the maintainer of the module to get his code into staging | 11:07 |
| Whoopie | amitk: we won't see it upstream. because there're some doubts about the info to write the improved hdaps driver. | 11:13 |
| Whoopie | the info used | 11:14 |
| mnemo | is this a kernel bug? is the dmesg errors/stacktraces actionable for someone in the kernel team? --> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/367410 | 11:14 |
| Whoopie | and the maintainer uses a pseudonym which was also a KO | 11:14 |
| ubot3 | Malone bug 367410 in xorg "Xorg has a corrupted page table" [Undecided,New] | 11:14 |
| amitk | Whoopie: pseudonym is ok if he/she agrees to reveal it to a single person who then commits the code upstream.... | 11:16 |
| Whoopie | amitk: it wasn't OK for Greg and some others. | 11:16 |
| amitk | hmm... | 11:17 |
| * apw idly wonders what the pseudonym is | 11:22 | |
| Whoopie | apw: Shem Multinymous | 11:23 |
| smb_ | Whoopie, amitk That roughly is my memory as well. One plan might be to drop that part of tpctl that does the additional battery features (which in turn requires the additional ec layer). Unfortunately it will not be before we drop it until we learn how many use it. | 12:46 |
| smb_ | Then the change to make the kernel driver do the same as the tputils one is not that big, iirc | 12:47 |
| Whoopie | smb_: but the battery features are the interesting part of tp_smapi. you can add start/stop threashold for charging. | 12:48 |
| smb_ | I know, I know. So that would be the first "complain" ;-) | 12:48 |
| smb_ | The best thing would be to have everything in either kernel or staging. And somehow I thought the last time asking around, there was some hope to have it happen. I don't know whether it was just the lack of someone pushing or another concern of where the source came from | 12:50 |
| Whoopie | I absolutely understand that managing two hdaps modules is too troublesome. but for jaunty, could we have both? | 12:51 |
| smb_ | mjg59, Was it you, I had spoken with about that ^^^ | 12:51 |
| smb_ | Whoopie, we will have to convince rtg on that. And I can understand that "now you accept it for Jaunty" -> next "why not in Karmic..." | 12:53 |
| amitk | Whoopie: I will probably NACK it | 12:53 |
| amitk | s/probably// | 12:54 |
| Whoopie | smb_, amitk: both true, but please also see it from the users' perspective. ;) | 12:54 |
| Whoopie | you accepted it once in hardy, so you "must"/should continue until a better solution is found. | 12:55 |
| smb_ | I good reason to stop it. Give the little finger and your whole arm is gone.. ;-) | 12:55 |
| smb_ | Beside of that, maybe (and that is no promise) it would be possible to extract the functional change (xy axis inversion) and get it upstream accepted. | 12:56 |
| smb_ | But that would still not allow you to use the battery stuff concurrently | 12:57 |
| amitk | Whoopie: I can't comment on why it was accepted for Hardy. But our standing policy is that out-of-tree drivers must make an effort to get their code upstream. In this case, that is not true. | 12:57 |
| smb_ | amitk, Well at the time in Hardy it sounded as such an effort was made. That is the reason it got in. But even now, nothing has happened. | 12:58 |
| amitk | Whoopie: We will be glad to help to get it upstream. And with the advent of drivers/staging/, the crappiest drivers are making it upstream. So there is NO excuse for out-of-tree drivers to remain out. | 12:59 |
| amitk | The users should pressure the driver maintainer to work on this problem now. | 13:01 |
| eportel6607 | Hi guys. First time here for me. | 13:07 |
| eportel6607 | Guys is any way for me to get the kernel source to the last 4 kernels (including patches) used for ubuntu/kubuntu? | 13:08 |
| eportel6607 | Is this stuff archived at all? | 13:09 |
| smb_ | eportel6607, I believe the source package are removed at some point, but if you can use git, you can go back to any kernel | 13:10 |
| eportel6607 | smb_: hey thanks! But will that get me the source or just allow me to use a particular kernel for the OS? | 13:11 |
| Whoopie | amitk: nothing more to say then. ;) | 13:11 |
| smb_ | eportel6607, That will give you the kernel source. You would have to compile on your side | 13:11 |
| eportel6607 | smb_: oh that's fine! I haven't used or even herd of the git command...is there any special syntax | 13:12 |
| smb_ | Not special, "git clone git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git jaunty" will clone everything to you into the jaunty dir. | 13:14 |
| smb_ | Then you can checkout at various points in time: "git checkout Ubuntu-2.6.28-11.42" for example | 13:15 |
| eportel6607 | smb_: thanks man...wow that's pretty cool. So this is ran in a terminal just like anything else? | 13:15 |
| smb_ | eportel6607, yes, but bring a bigger cup of coffee with you. It is big | 13:16 |
| amitk | Whoopie: sorry, but a line has to be drawn some where. FWIW, I have a thinkpad too. :) | 13:16 |
| smb_ | amitk, Whoopie Me as well | 13:16 |
| Whoopie | and you don't complain that the hdapsd daemon doesn't work with kernel 2.6.28? ;) | 13:17 |
| smb_ | Not enough time to play neverball ;-) | 13:17 |
| apw | eportel6607, you can get all of the old binary packages from launchpad as well should you just want old kernels to test | 13:18 |
| smb_ | apw, Yeah, I was not sure how far back the source packages remain in the archive | 13:19 |
| eportel6607 | apw: oh...but is that a way to get the source too...like the patches.. Ubuntu kernels are really impressive and I would like to see what patches are involved | 13:19 |
| smb_ | eportel6607, The source package contain the tree including all the patches | 13:19 |
| apw | eportel6607, for the source you want the git tree always, as it has the real patche etc | 13:19 |
| apw | smb_, i think only the ones which are the latest in each pocke | 13:19 |
| apw | 13:19 | |
| smb_ | The git method would have the advantage to see the log history of the patches as well | 13:20 |
| smb_ | apw, That is what I remembered, so I was not sure it is possible to get the last 4 kernels from there | 13:20 |
| apw | pretty sure not in the general case | 13:21 |
| apw | launchpad may well have the whole history on the +versions page. but thats not as good as the git tree for source of course | 13:21 |
| eportel6607 | apw: ok....now git is a command....or part of a URL? | 13:22 |
| apw | git is a command, the command used to navigate the source in the git repository smd pointed you to | 13:23 |
| smb_ | git is also part of the url as it has its own transport mechanism. there would also be http:// but I made the experience that git's own transport is faster | 13:24 |
| eportel6607 | apw: oh yeah...geesss I'm sorry guys I have 4 conversations going on at onces over here...that's right sorry. Thanks guys I rally appreicate the infor. ubuntu's kernel really rocks! | 13:24 |
| eportel6607 | ahhh Ok cool I'll look into that now | 13:25 |
| smb_ | eportel6607, No worries, multiplexing happens here as well :) | 13:25 |
| eportel6607 | smb_: ah..yeah sometimes I forget who I said what to! :) | 13:26 |
| === asac_ is now known as asac | ||
| amitk | apw: given a list of sha ids, how can I get git to show _just_ the author and oneline descriptions of the commits? | 15:52 |
| amitk | I find now way of make git-show show me only selected header info | 15:52 |
| amitk | *no way | 15:53 |
| eportel6607 | smb_: hey man...ya still there? | 15:56 |
| smb_ | no, I am just pretending :) | 15:56 |
| amitk | apw: hmm.. git rev-list could be misused with the -n1 option | 15:57 |
| eportel6607 | smb_: :) | 15:58 |
| smb_ | amitk, tried git show --pretty='format:%an:%s'? | 15:58 |
| eportel6607 | Hey I try what you guys told me and it worked! thanks...the only question is where is the "patches" directory?...If this is the source to the kernel shouldn't there be a directory that hold all the patches that is added to the kernel? | 15:59 |
| smb_ | eportel6607, There are no patches. All the patches go directly to the tree. | 16:00 |
| eportel6607 | smb_: hmmm so the patches are intergrated into the file tree itself? | 16:00 |
| amitk | smb_: 'git show' shows the entire patch too. I don't want that. | 16:00 |
| smb_ | Yes | 16:00 |
| smb_ | amitk, with that format string it only shows me the two things | 16:01 |
| eportel6607 | smb_: please forgive my cluelessness to this stuff :) So is there a way to see just the patches or just extract those patches from this tree? | 16:02 |
| smb_ | amitk, Oh, sorry. replace show with log | 16:02 |
| rtg | eportel6607: git log --pretty=oneline | grep UBUNTU | 16:02 |
| amitk | smb_: but 'log' shows everything since the commit. I only info of that one commit. | 16:03 |
| smb_ | eportel6607, Hardly, though you can diff between v2.6.28 but that would show the stable updates as well | 16:03 |
| smb_ | amitk, git log ... sha -1 | 16:03 |
| eportel6607 | Ah | 16:03 |
| amitk | smb_: aah, that might work. Thanks | 16:04 |
| eportel6607 | rtg..please clue me in on this command? :) | 16:04 |
| smb_ | rtg, That would still miss some of the cherry picks | 16:05 |
| rtg | eportel6607: have you read https://wiki.ubuntu.com/KernelTeam/KernelMaintenance yet? | 16:05 |
| eportel6607 | rtg: I get a "not a git repository" | 16:05 |
| eportel6607 | rtg: no I haven't read that | 16:06 |
| smb_ | eportel6607, All of the git commands must be issued in a git tree | 16:06 |
| eportel6607 | smb_: oh so 'cd' over to the directory that just got downloaded? | 16:07 |
| smb_ | eportel6607, correct | 16:07 |
| eportel6607 | smb_: Got it! | 16:07 |
| eportel6607 | smb_: with the git command what would be the proper syntax for 7.04? I tried 'ubuntu-fiesty"...no go and "ubuntu-fiesty-fawn"...Is there a certain syntax to getting to that version | 16:21 |
| apw | amitk, you should be able to use log with the --pretty=format:<soemthing something> | 16:23 |
| smb_ | eportel6607, The tags are not carried over for each series. For feisty you would have to download the feisty tree. But feisty is now out of maintenance and moved out of the usual git trees | 16:23 |
| eportel6607 | smb_: I see | 16:24 |
| eportel6607 | Ok thanks | 16:24 |
| smb_ | Feisty is git://kernel.ubuntu.com/ubuntu-archive/ubuntu-feisty.git | 16:25 |
| smb_ | The tags are based on Ubuntu-<kernel-version>-<abi>-<rel> | 16:25 |
| smb_ | err Ubuntu-<kernel-version>-<abi>.<rel> | 16:26 |
| rtg | bradf: lets defer working on bug #359049 until we decide what instruction set we'll use for Karmic. If we decide to compile for v7, then most of the armel flavours will disappear (as will the armel arch name). | 16:26 |
| ubot3 | Malone bug 359049 in linux "imx51 udeb hardcodes linux version in vmlinuz binary name" [High,Won't fix] https://launchpad.net/bugs/359049 | 16:26 |
| apw | amitk, something like this perhaps: | 16:27 |
| apw | apw@dm$ git log -2 --pretty=format:'%an:%s' | 16:27 |
| apw | Jesse Barnes:i915: enable MCHBAR if needed | 16:27 |
| apw | Bjorn Helgaas:pnp: add PNP resource range checking function | 16:27 |
| smb_ | apw, You threw yourself behind the train :-P | 16:27 |
| apw | heh, he sorted himself out already has he | 16:28 |
| smb_ | I told the same before. But alright I had mistaken log and show first | 16:28 |
| smb_ | You can also use <sha> -1 to get only the one entry you want | 16:29 |
| amitk | apw: yeah, sorted it out. Now I need to run it through a list of sha ids using xargs I guess | 16:30 |
| apw | i would think it would take a list | 16:30 |
| * amitk -> step out for a bit | 16:30 | |
| bradf | rtg: sounds ok to me | 16:34 |
| eportel6607 | smb_: could any of theses patches be used on another kernel? | 16:34 |
| rtg | bradf: plant that little nugget in the bug report, please | 16:35 |
| bradf | rtg: will do | 16:35 |
| smb_ | eportel6607, Not sure what you mean by that. Many of the patches are single picks from upstream. Except for those marked with SAUCE in the subject | 16:36 |
| eportel6607 | well to be honest I would love to use some of the great patches from ubuntu and patch another kernel with them. The functionality of the ubuntu works very well that I would love to have our kernel work as well | 16:37 |
| smb_ | Well as said. Many come from upstream. So, in general they might apply to any other kernel at the same level. But still you have to decide which you want and might have to modify them to apply cleanly. But there is no simple way to extract the changes to a base kernel. That is just not needed for us. | 16:41 |
| eportel6607 | smb_: I see...well that's ok....I didn't think it would be easy :) Thanks very much for your help :) | 16:43 |
| eportel6607 | Guys is it normal for a kernel source NOT to have a "patches" directory? Our's has one...but none of the other seem to | 17:42 |
| === pace_t_zulu_ is now known as pace_t_zulu | ||
| ThJ | The driver for Intel cards fails to initialize GEM (some Intel specific mode?) for OpenGL programs with the bigmem kernel in Jaunty and reverts back to Xv mode instead (according to a bug report I found). | 19:05 |
| ThJ | 3D performance is being affected negatively. I run this on an EeePC with only 1 GB of RAM, so I don't need a bigmem kernel. | 19:05 |
| ThJ | I've been looking for an official non-bigmem kernel to use, but can't find it. | 19:06 |
| ThJ | I looked at linux-image-virtual because it probably has bigmem disabled, but I suspect it may come with other penalties, and a smaller set of drivers? | 19:07 |
| mjg59 | ThJ: Only -server has PAE | 19:08 |
| mjg59 | The generic kernel should be ok | 19:08 |
| ThJ | mjg59: How can I check if PAE is enabled or not? | 19:09 |
| smb_ | The Jaunty i386 kernel does not have PAE enabled | 19:09 |
| ThJ | Okay, so I'm looking at a different problem? | 19:10 |
| maxb | Is -virtual the same kernel as -server, just with less modules? | 19:10 |
| smb_ | Might be. I have not followed the problem closely, but there have been issues with the i915 drm driver and tiling | 19:11 |
| ThJ | I keep getting this error: Failed to initialize GEM. Falling back to classic. | 19:12 |
| ThJ | Which I didn't have before the Jaunty upgrade. | 19:12 |
| ThJ | And the framerate of the OpenGL app I am developing is noticably lower. | 19:12 |
| smb_ | maxb, Yes virtual in Jaunty is derived from the server kernel | 19:13 |
| smb_ | ThJ, It might be bug 349314. | 19:15 |
| ubot3 | Malone bug 349314 in linux "Slow performance and tiling issues on i915" [Unknown,Confirmed] https://launchpad.net/bugs/349314 | 19:15 |
| * ThJ reads | 19:15 | |
| ThJ | Not using Netbook Remix, but reading on | 19:16 |
| maxb | Right, so -virtual will have PAE enabled, contrary to ThJ's wishes | 19:17 |
| smb_ | As I said, I have not followed closely but there seemed to be some issues there. Probably most noticeable on netbooks as they are not that powerful CPU wise | 19:18 |
| ThJ | Might not be relevant in any case, if my current kernel isn't PAE anyway. | 19:18 |
| mjg59 | The tiling issue on the Eee is actually down to their memory setup, IIRC | 19:18 |
| smb_ | Not the generic i386 as there are some CPUs around that will not support it and it is a compile time decision | 19:18 |
| ThJ | But bigmem kernels can cause the same error message. | 19:19 |
| ThJ | The tiling issue is new for Jaunty? I ran Intrepid on this machine before the upgrade. No issues there. | 19:20 |
| ThJ | Then again, I was using a custom array.org kernel. But only custom insofar as it had redundant drivers stripped out, and extra modules for wireless. | 19:21 |
| smb_ | To my knowledge yes. | 19:21 |
| ThJ | This bug mentions GEM: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/303011 | 19:23 |
| ubot3 | Malone bug 303011 in xserver-xorg-video-intel "[i945] 2.5.1 driver poor performance" [Unknown,Fix released] | 19:23 |
| ThJ | lol | 19:23 |
| ThJ | Oh, it's a bot. | 19:23 |
| smb_ | Yep, it is quite useful :) | 19:24 |
| ThJ | Can't seem to find the .deb they're talking about | 19:24 |
| ThJ | I'd rather not touch a compiler for this. Having home-compiled stuff installed in place of system packagres tends to break things. | 19:25 |
| ThJ | *packages | 19:25 |
| smb_ | Maybe on a PPA, but I just saw something mentioned about enabling UXA as a work-around... | 19:26 |
| smb_ | Option "AccelMethod" "UXA" (likely added to Xorg.conf) | 19:26 |
| ThJ | Hmm, I could try that, I guess... | 19:27 |
| ThJ | BRB | 19:29 |
| ThJ | Do NOT recommend AccelMethod "UXA" | 19:37 |
| ThJ | Caused weird malfunction of the LCD, big liquid multicolor cloud. | 19:37 |
| ThJ | Had to enter recovery mode to fix it. | 19:37 |
| ThJ | Only other time I have ever seen that effect was when I gutted my iMac and replaced the hard drive and managed to break the display cable in the process. | 19:39 |
| ThJ | So my immediate reaction to this was "Ho sh..." | 19:39 |
| ThJ | smb_: Are you getting this, lol | 19:40 |
| smb_ | ThJ, Wow, sorry to hear. It seemed to have worked for some... Hope no permanent damage was done | 19:42 |
| ThJ | smb_: No damage that I can see, just startled me | 19:42 |
| smb_ | ThJ, Can imagine. Though I have seen a few "interesing" effects like this on some netbooks with suspend/resume | 19:44 |
| ThJ | smb_: It's a cool effect if you don't know what it is tho, lol | 19:45 |
| ThJ | smb_: Display starts out black or gray, and then a big white cloud with some pixel errors starts to form in the middle | 19:45 |
| ThJ | smb_: Then the screen goes completely white, then blacks out | 19:46 |
| ThJ | smb_: Such an eerily organic shape for a digital device malfunctioning | 19:46 |
| ThJ | Okay, so back to searching for a solution I guess | 19:47 |
| smb_ | Yeah, that sounds a bit like the "whiteout". There also had been effects of wobbling all colours --- hard to describe. | 19:47 |
| smb_ | But in general I would suspect your problem somewhere in the i915 drm or the intel xord driver or combinations of it | 19:48 |
| ThJ | Yeah, the last post of that bug report I posted mentions a new version of that Intel driver. Also I think I saw something that looked like a HOWTO page on Google | 19:49 |
| ThJ | http://ubuntuforums.org/showthread.php?t=1130582 | 19:54 |
| bryce | apw: | 20:04 |
| bryce | <jbarnes> cool thanks for the update | 20:04 |
| bryce | and if you see apw can you ping him about the MCHBAR stuff? he tested those patches and I'm still waiting on his tested-by messages to intel-gfx | 20:04 |
| bryce | (along with the pnp resource code he actually used; he fixed up one of the patches) | 20:04 |
| smb_ | bryce, He might get back in later. He was somewhere travelling | 20:05 |
| bryce | smb_: ok cool thanks | 20:05 |
| === bradf is now known as bradf_afk | ||
| apw | bryce, yes got distracted. i used a backport version so i need to send those out with the underlying core allocator range change with my tested stuff on it. will do that in the am | 20:26 |
| brinstar | hi, just posted this in the main ubuntu channel, got no decent responses, so thought i would try here | 20:33 |
| brinstar | one thing i dont understand is that no i386 cpu can even run ubuntu acceptably, and i would even go as far as saying, nothing less than a pentium 2 (i686) can run ubuntu acceptably, so why cater for something which is never going to be used??? :S | 20:33 |
| bryce | apw: thanks | 20:40 |
| === bradf_afk is now known as bradf | ||
| hyperair | hi. does anyone notice jaunty's kernel taking lots and lots of disk cache, and not releasing it, eventually forcing many apps into swap and trashing? | 21:20 |
| bryce | nope | 21:37 |
| === mkrufky is now known as Guest83366 | ||
| === mkrufky1 is now known as mkrufky | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!