[00:10] rtg: lrm is now uploaded, and I need some sleep :) [00:25] tjaalton: Danke. === smb_away is now known as smb_tp === _stijn_ is now known as C === C is now known as _stijn_ === asac_ is now known as asac [09:10] moin [11:29] Hi, I hope this is on-topic enough - I'm updating kboot for ps3 (LP bug 146230). It comes bundled with it's own kernel source (2.6.24) ... [11:29] Launchpad bug 146230 in ps3-kboot "update ps3-kboot to 1.4.1" [Medium,In progress] https://launchpad.net/bugs/146230 [11:30] Could someone offer any advice on what I should do about "syncing" it with the Hardy kernel? [11:30] E.g. should I take a snapshot of the hardy kernel and include that within the ps3-kboot package? Or is there a more elegant solution? [11:31] Also how important is it that the kboot kernel and ubuntu kernel are the same? [11:31] thx [11:52] Hi there, I reported a bug #199934, which is causing hardy to panic upon reboot in the raid device driver - and the bug is still 'undecided' and I just wanted to know what I can do, to get some attention to get it fixed for -release [11:52] Launchpad bug 199934 in linux-meta "Kernel Panic, in gdth (RAID) driver on reboot" [Undecided,New] https://launchpad.net/bugs/199934 [12:02] cjwatson: have you got a moment to chat about ps3-kboot? [12:07] munckfish: BenC will really be better for that, once he's around [12:07] (he's US Eastern time) [12:11] cjwatson: ok thx I'll look out for him later. thx [12:54] soren: Hi, I'd have a question about the virtual kernel package. When I use the vmxnet driver in the VM, I have to select "wired network" each time I log in. Is the driver lacking some features which NetworkManager needs? [13:30] Good morning everyone [13:33] Morning BenC [13:42] amitk_: I see the wimax firmware disappeared. [13:48] brb, testing my vzw evdo card [14:14] sweet, evdo card works [14:34] BenC: Hi have you got a moment to talk about ps3-kboot? [14:35] I'm working on LP bug 146230 [14:35] Launchpad bug 146230 in ps3-kboot "update ps3-kboot to 1.4.1" [Medium,In progress] https://launchpad.net/bugs/146230 [14:37] munckfish: Sure [14:37] Great [14:37] basically I'm half way to getting it to compile [14:37] as is, from upstream [14:37] Now, it bundles kernel 2.6.24 [14:38] What should I do about "syncing" it with the Hardy kernel? [14:38] Should I take a snapshot [14:38] of the hardy kernel source [14:38] and put that into the source tarball? [14:38] Or is there a more elegant solution? [14:38] No [14:38] just use what they have, stock [14:38] Aha, ok [14:39] it's only used for first stage loader, it's not what the system uses to boot [14:39] the end boot results will be out powerpc64-smp kernel [14:39] *our [14:39] Ok great that makes things simpler :) [14:39] Right then, well I'll cont. working on it. [14:40] I have all evening Friday put aside [14:40] hopefully I'll have something to show next week [14:40] thanks [14:47] BenC: so who do you have service with for your evdo card? [14:49] rtg: verizon [14:49] USB? [14:49] rtg: it had to be activated via windows, but easy to setup after [14:49] when are you guys getting WiMAX rollouts? [14:49] rtg: it's USB, but it's one of the dell provided cards that fits into the internal wwan slot [14:49] BenC: I think I have one of those. [14:50] pretty sure jose sent you one when he sent me one [15:10] BenC: Hi, do you perhaps know why NetworkManager doesn't activate "wired network" with the vmxnet driver? After each login, I have to enable it. [15:13] It doesn't provide carrier detect? [15:22] mjg59: aha, ok. I read something about it on http://blogs.gnome.org/dcbw/2008/02/18/hey-vmware-set_netdev_dev-wants-a-word-with-you/ [15:23] it seems that vmxnet supports carrier detection, but NetworkManager is not able to find it out. [18:36] mjg59: thanks for getting the ball rolling on bug 201591 - looks like all is well with 2.6.24-14 :) [18:36] Launchpad bug 201591 in linux "atyfb regression - screen blank except for blinking cursor after fbcon vtswitch " [Medium,Fix released] https://launchpad.net/bugs/201591 [18:37] thoreauputic: Excellent [18:38] finally! Now I can pursue my eccentric little no-X project with a hardy version [18:39] anyway, I thought I'd drop in and say thanks, because you took the trouble to start the process with your patch etc. [18:40] Yeah, it was my fault to begin with [18:40] really? [18:41] ah well - all's well that ends well and other conventional sentiments... [18:41] :) [18:44] Hm [18:44] acx111 just blew away my kernel === doko_ is now known as doko [20:36] any clue where I will find Tim Gardener? [20:37] dhaval: yes? [20:37] rtg, regarding BUG 188226 [20:37] Launchpad bug 188226 in linux "Kernel should use CONFIG_FAIR_CGROUP_SCHED" [High,Fix released] https://launchpad.net/bugs/188226 [20:38] CONFIG_FAIR_CGROUP_SCHED is arch independent [20:38] dhaval: as far as I could tell, it is not supported on non x86/x86_64 arches (which I found a bit surprising) [20:39] rtg, it is arch independent. i have resolved fair_cgroup_sched bugs on ia64 and ppc [20:39] I went through the menuconfig options manually, but no CGROUPS selection presented itself. [20:39] rtg, you need to have CONFIG_CGROUP on for that [20:40] is the a prerequisite ? [20:40] it depends on that [20:40] well, how else would you do cgroup scheduling :) [20:40] hmm, lemme recheck. [20:40] I was in a hurry at the time. [20:40] hmm. you had us a bit worried [20:40] rtg, i still suggest, keep cgroup_sched as default [20:40] shit. you know thats gonna cause another ABI bump. [20:40] itwill save you a lot of bugs like that boinc one [20:41] rtg, hmm? [20:41] its not a big deal, but does cause some process work for the archive admins. [20:42] ok. well i have been hollering for cgroup_sched for months now :) [20:43] I have to point out that you are a small (but vocal) minority. I have not been able to extract an informed opinion from the server group. [20:43] trust me, it would make life a lot easier. you would have old behavior and if you wanted group scheduling, you just have to mount it [20:43] rtg, heh, i wrote part of that code :) [20:44] as I pointed out in the LP report, its the addition of user space configuration that is causing me problems. Its more of a policy restriction given the development stage we are at. Hardy is about to release. [20:45] rtg, i have been hollering for months. i don't have any issues. [20:45] but you are going to get a number of "bugs" because people are not going to be aware of the changed behavior [20:45] I'll get CGROUPS in the server image, but I'm not willing to mess with the desktop until we start Intrepid next month. [20:45] Those who really care can run the server image on their desktop. [20:46] rtg, people are *NOT* going to be aware of the new scheduler behavior [20:46] they are going to find that they get 50% cpu and daemons get 50% [20:46] and nice can't help them there. [20:46] you will get bugs raised on that, and you will have to come up with workarounds. [20:47] the suggested solution is to shift to CGROUP_SCHED, which as I mention i have been suggesting for months now :) [20:47] in all honesty, 99% of desktop users don't care. I'll point out the alternatives when I have to. [20:48] rtg, ok, i will let you be the judge on that. its your decision in the end.. [20:48] CGROUPS is definitely in the cards for Intrepid. [20:49] rtg, btw, could you mention that fair_cgroup_sched is arch independent on that thread, esp since that might come up on google searches and we don't want ubuntu bz to give wrong results [20:49] yes - as part of updating the configs. [20:49] rtg, might I also suggest to try playing with the memory controller, which allows you to control memory.. :) [20:49] i'll get it into the LP report. [20:49] rtg, thanks! [20:53] dhaval: what about CONFIG_CGROUP_NS and CONFIG_CPUSETS ? [20:53] rtg, cpusets will allow you create groups of CPUs/memory banks [20:53] you can then put tasks and set them to run only on those cpusets [20:54] dhaval: so you recommend enabling those options as well? [20:54] ns is still a black hole for me. [20:54] rtg, ns, i suggest you get in touch with their developers. [20:54] i believe cpusets is quite stable. [20:54] dhaval: you would be just as happy with just cpusets? [20:55] rtg, did not get the question [20:55] dhaval: sorry, l meant would you be ok with only enabling CONFIG_CPUSETS ? [20:55] do you actually use either option in practice? [20:56] rtg, i am not sure if desktop users would be interested in cpusets. [20:56] or ns proxy. [20:56] as a user, i don't use cpusets or ns [20:57] dhaval: ok, since their use is optional I'll enable them as well. [20:57] i do use cgroup scheduling though when i want to control how my system is running as well as the memory controller to trap firefox/openioffice [20:59] rtg, this is for intrepid right? [20:59] Doesn't cpusets depend on cgroup? [20:59] blueyed, yep, all thesedepend on cgroup [20:59] dhaval: thanks for bringing this issue up again here. [20:59] rtg: I've been also pondering about this, since 2.6.24 hit Hardy.. [20:59] dhaval: I was going to enable cpusets and ns for Hardy server. [21:00] blueyed, i did not know about the existence of this channel, otherwise i would have been hollering here earlier [21:00] it's really a regression for users/desktops.. [21:00] blueyed, well, we can agree to disagree :) [21:00] blueyed, i call it expected behavior [21:00] rtg, i just talked to upstream folks, they like the idea, it will get it wider coverage [21:00] dhaval: I'm for cgroups.. because it's the old behaviour, I mean. [21:00] rtg, thanks a lot for listening! [21:01] blueyed, yeah, i aree [21:01] dhaval: the new kernel package should show up by morning (UTC-8) [21:01] rtg, thanks, i should set up hardy-rawhide or something like that on a virtual machine [21:02] rtg: with cgroups only for server, still? [21:02] blueyed, rtg i would still suggest desktop as well, but its your decision in the end, not mine [21:03] dhaval, blueyed: its actually not _all_ my decision. the kernel team discussed the ramifications, and being a generally conservative bunch, decided to only enable CGROUPS for servers. [21:04] rtg, i wish they would have involved us in the discussion as well [21:04] we could have provided you with more information [21:04] well, better late then never :) [21:04] being conservative, i would have suggested cgroup and not user [21:04] rtg: I've scammed the irclogs about this, and it seemed to just have been rushed over. [21:04] user is more dangerous, because of the "bugs" that will surely crop up as blueyed will confirm [21:04] blueyed: it may well have been, being somewhat ignorant of the issue myself. [21:05] rtg: not fair.. I've been here before, there have been several bug reports it, etc.. [21:05] rtg, fwiw, why don't you guys get upstream folks involved as well? [21:05] It has just been ignored and then "too late now...".. [21:05] blueyed, i agree.. [21:05] its a matter of volume. there are few of us, and literally thousands of bug reports. [21:06] the stuff that gets my attention are hard failures. [21:06] rtg: you could have saved some time, by listening to this issue earlier.. ;) "upstream" (dhaval) came to us even.. [21:06] rtg, hmm. that is where getting upstream more closely involved would help [21:07] rtg, fwiw, i don't use ubuntu and this experience made me feel like using ubuntu even lesser [21:07] come on you guys, quit beating me up. I can on;y do so much. [21:08] rtg, sorry! not meant to beat you up. [21:08] but lesson to be learnt. do involve upstream [21:08] we all want linux to get better [21:08] rtg: sorry, we're not beating.. but finally somebody seems to listen, so.. [21:09] I'm working on it. like I said, I'll have a CGROUPS server release in the morning. [21:09] rtg, if you do hit scheduler bugs, do report it up, most of the folks are very responsive [21:09] rtg, fwiw, it holds for all subsystems [21:09] will do [21:10] remember, we all want to make Linux better :) [21:12] rtg: thanks. Do you understand the issue for desktop users, too? Having processes in the background (cron, daemons, especially owned by root [because it gets 2000 by default in user_sched]) makes the foreground/user's tasks slow. IMHO it's even more important for the desktop then for the server. [21:12] rtg: can you please bring this up in the kernel-team again? [21:13] blueyed, thanks for putting it up so clearly, thta's what i have been trying to say [21:13] rtg, i have to agree with blueyed [21:13] blueyed: I'll raise the issue. I'll even post a PPA kernel for testing. [21:13] what is PPA? [21:13] rtg: great. I would have put one in my Personal Package Archive (PPA) anyway. [21:13] dhaval: Personal Package Archive. [21:13] blueyed, thanks! [21:13] rtg, thanks! [21:14] (or installed -server), but all that won't help normal users. [21:14] blueyed, i would suggest custom sched-devel kernel :) [21:14] Thank you, dhaval. Also with bugging me about properly working around in boinc.. :) [21:15] sched-devel? [21:15] blueyed, that is the tree for the next kernel release. (currently aimed for 2.6.26) [21:15] dhaval: don't ask for too much.. ;) [21:16] blueyed, ah, np. (that part of the code i had written (and believe me, sysfs is a big pain to work with!), so all the hard work had to be seen in action :P ) [21:17] rtg, blueyed are there any resources on how i can setup the ubuntu-devel branch? [21:17] let me just set it up in a virtual machine [21:17] dhaval: there is some wiki info. lemme find it. [21:18] https://wiki.ubuntu.com/KernelMaintenance [21:18] rtg, oh, i meant something similar to fedora's rawhide which is a daily build of how fedora looks? [21:20] dhaval: not knowing how the rawhide stuff works, I'm not sure what to tell you. I have not enabled the daily kernel build stuff yet. Its on my list for Intrepid. [21:20] there is agit repo. [21:20] s/agit/a git/ [21:21] rtg, oh ok, so what fedora does is that it builds the whole distro every night and you do a yum update to get updated fully. is there something similar for ubuntu? [21:21] if i can set that up, I can get you more feedback than I can do now [21:21] dhaval: no, the distro is only built on demand, e.g., when a package update is uploaded. [21:22] hmm. ok. [21:22] right, that's similar to rawhide. [21:23] what i meant by rebuild was that you have a daily build. the updates are pushed out once aday [21:23] the updates are pushed to the archive as soon as an archive admin pushes them, about once an hour. [21:24] that is, after the build completes. [21:24] ok, so is there some documentation about that? i can't really find my way through the ubuntu wiki. Contribute brought me to a completely unexpected page :( [21:26] dhaval: its all based on the debian way of doing things. Its such a deep topic I'm not sure where to tell you to start. I've only been doing it for just over a year. [21:27] rtg, oh. ok, proably another day then. [21:27] rtg, i won't be lurking about here, but feel free to let me know by email if I can help [21:27] yay, my framebuffer console (radeon) works again with -14 [21:27] dhaval: ok. thanks for the pointers. [21:29] rtg, np. hope to see the cfs group scheduler in action and making people more happy with its responsiveness. btw, i've given a pointer to a daemon in the LP mail if you want to simulate user scheduling with cgroup_sched [21:31] rtg, i did have one more question [21:32] dhaval: yes? [21:32] rtg, how does one get packages in ubuntu? i'm working on a userspace library for control groups known as libcg, (http://libcg.sf.net) [21:32] do you need sponsors and such stuff? [21:33] dhaval: right, they are called MOTU sponsors. [21:33] if this is totally off topic, just point me to the right channel [21:33] dhaval: is there an #ubuntu channel? Its likely a good place to start. [21:34] that seems like a user channel and /join #ubuntu-devel gave me * ubuntu-devel :That channel doesn't exist [21:34] hmm. i seemed to have made a stupid mistake [21:34] mised the # [21:35] dhaval: if that doesn't work out, send an email to Daniel Holbach [21:36] rtg, thanks! i found #ubuntu-motu [21:36] ok, I'm ducking out for a bit. [21:37] hmm. that channel seems awfully quiet [21:37] rtg, ok, thanks! [21:45] dhaval: just get the beta release (or daily live cd), install it and then you can upgrade from there, as the package get built/uploaded. [21:45] blueyed, link to the daily live cd? [21:45] dhaval: http://cdimage.ubuntu.com/daily-live/current/ [21:45] (from google :p) [21:45] blueyed, thanks! [21:46] blueyed, too lazy, its too late here. i am supposed to be asleep about 2 hours back === dhaval is now known as dhaval_away [21:57] is lbm meant to be a staging area for proposed updates to lum? [22:03] irssi quit [22:06] blueyed: you did the acpi-support update? I'm not sure if that's to blame, but the suspend hotkey doesn't work on my thinkpad anymore since some recent update [22:24] hello, i've done an hardy upgrade, which downloaded a new kernel 2.6.24-14, when i now boot my notebook it hangs on every new boot on a different driver. once at the iwl3945 driver loading, once at the ricoh-mmc driver. may there be something i miss or isn't done automaticaly? [22:38] num: I would try a memtest :-) [22:39] a memtest? [22:40] Nafallo: but a memtest that urly during boot? [22:40] num: esc during the grub menu and choose memtest [22:41] Nafallo: you suppose a damaged memory? [22:42] that's one of the first things I check. sounds like some kind of hardware issue at least. [22:43] i can't believe this, since i'm on this machine with the kernel version below, xx-12 [22:43] and no problems [22:43] * Nafallo shrugs [22:44] I just say what it sounds like to me. and never said that it was the actual issue. [22:44] Nafallo: i thank you [22:44] i appreciate any ideas, help [22:45] :-) [22:46] what i also saw was, that my wireless is a iwl3945, and kernel -12 shows the device as 3945ABG and the new kernel -14 shows it as 3945AB [22:59] tjaalton: I don't think it was acpi-support. There have been some generic hotkeys been reported lately.. do you have a bug report? What laptop do you have? [23:23] is there intended to be another kernel build before release? or is 14 likely to be it barring any disasters? [23:24] Ng: one more ABI bump tonight. [23:25] I did n't get CGROUPS set correctly on all arches. [23:25] erk [23:25] oh well, I was probably going to have to maintain my own lum, I can do the same with the kernel. damn new hardware ;) [23:26] the joys of open source? [23:26] it cuts both ways, I've had all of the major hardware glitches worked out within a fairly short time of contacting upstream projects, but it's been harder to get the fine details locked down enough to push for inclusion [23:28] and I can make easily enough make a PPA for people with the same hardware [23:28] Ng: what hw do you have that we are not supporting? [23:29] Ng: You solved your camera problem [23:29] ? [23:29] rtg: audio chipset and usb camera [23:29] smb_tp: I think so, yeah [23:29] well I didn't, upstream did :) [23:30] Ng: I guess somewhere in this wretched find_control. Maybe you can give me the pointer. Or did you just get the latest driver? [23:30] smb_tp: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/200990/comments/10 [23:30] Launchpad bug 200990 in linux "[hardy] oops when running cheese on Thinkpad X300" [High,Triaged] [23:32] Ng: Just missed that by seconds, hmpf. ;-) [23:33] hehe [23:33] I've not tried applying it to hardy source yet, working with upstream tarballs is a lot quicker for building one tiny driver ;) [23:35] Ng: yeah, but looks tiny enough to be ok and if that fixes your oops its one less on the bad list. rtg: would that be alright to push into lum? [23:36] smb_tp: looks fine. It demonstrably fixes the issue? [23:37] rtg: So says Ng but i can put that in and make a test module [23:37] smoh, I missed that port. I trust Ng. (must be getting late) [23:37] s/smoh/oh/ [23:38] rtg: It really is. :) [23:39] if you can make a test module with our version of uvc I'd be very happy to test it since I've only tested it with the latest upstream svn. I could try building it myself, but it might take some time ;) [23:39] smb_tp: make it so. I'll get it before I upload later this evening. [23:39] rtg: I'll try my very best... [23:40] thanks :) [23:44] Ng: What did you do to earn this bizarre level of trust? [23:44] Ng: Has rtg *seen* terminator? [23:45] infinity: I'll have you know that more than one respected member of the distro team uses it! ;) [23:46] Ng: Can you name them, or have they begged for anonymity? :) [23:46] infinity: I trust him because he could delete all of my accounts. wait - is that a bad thing? I could go on vacation again. [23:47] rtg: I can prevent you from ever building anything again; do my patches get similar treatment? :) [23:47] infinity: only if you attach them to the LP report :) its so easy that way... [23:48] rtg: That's so much more effort than just directly committing them. [23:48] infinity: I might choose to protect them from association with the unfair treatment terminator gets, and the irony is that the haters all use gnome-terminal, which is hardly a paragon of quality ;) [23:48] Ng: xterm's where it's at!