[00:10] <tjaalton> rtg: lrm is now uploaded, and I need some sleep :)
[00:25] <infinity> tjaalton: Danke.
[09:10] <kraut> moin
[11:29] <munckfish> 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] <ubotu> Launchpad bug 146230 in ps3-kboot "update ps3-kboot to 1.4.1" [Medium,In progress] https://launchpad.net/bugs/146230
[11:30] <munckfish> Could someone offer any advice on what I should do about "syncing" it with the Hardy kernel?
[11:30] <munckfish> 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] <munckfish> Also how important is it that the kboot kernel and ubuntu kernel are the same?
[11:31] <munckfish> thx
[11:52] <phoenix_> 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] <ubotu> Launchpad bug 199934 in linux-meta "Kernel Panic, in gdth (RAID) driver on reboot" [Undecided,New] https://launchpad.net/bugs/199934
[12:02] <munckfish> cjwatson: have you got a moment to chat about ps3-kboot?
[12:07] <cjwatson> munckfish: BenC will really be better for that, once he's around
[12:07] <cjwatson> (he's US Eastern time)
[12:11] <munckfish> cjwatson: ok thx I'll look out for him later. thx
[12:54] <Whoopie> 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] <BenC> Good morning everyone
[13:33] <amitk_> Morning BenC 
[13:42] <rtg> amitk_: I see the wimax firmware disappeared.
[13:48] <BenC> brb, testing my vzw evdo card
[14:14] <BenC> sweet, evdo card works
[14:34] <munckfish> BenC: Hi have you got a moment to talk about ps3-kboot?
[14:35] <munckfish> I'm working on LP bug 146230
[14:35] <ubotu> Launchpad bug 146230 in ps3-kboot "update ps3-kboot to 1.4.1" [Medium,In progress] https://launchpad.net/bugs/146230
[14:37] <BenC> munckfish: Sure
[14:37] <munckfish> Great
[14:37] <munckfish> basically I'm half way to getting it to compile
[14:37] <munckfish> as is, from upstream
[14:37] <munckfish> Now, it bundles kernel 2.6.24
[14:38] <munckfish> What should I do about "syncing" it with the Hardy kernel?
[14:38] <munckfish> Should I take a snapshot
[14:38] <munckfish> of the hardy kernel source
[14:38] <munckfish> and put that into the source tarball?
[14:38] <munckfish> Or is there a more elegant solution?
[14:38] <BenC> No
[14:38] <BenC> just use what they have, stock
[14:38] <munckfish> Aha, ok
[14:39] <BenC> it's only used for first stage loader, it's not what the system uses to boot
[14:39] <BenC> the end boot results will be out powerpc64-smp kernel
[14:39] <BenC> *our
[14:39] <munckfish> Ok great that makes things simpler :)
[14:39] <munckfish> Right then, well I'll cont. working on it.
[14:40] <munckfish> I have all evening Friday put aside
[14:40] <munckfish> hopefully I'll have something to show next week
[14:40] <munckfish> thanks
[14:47] <rtg> BenC: so who do you have service with for your evdo card?
[14:49] <BenC> rtg: verizon
[14:49] <rtg> USB?
[14:49] <BenC> rtg: it had to be activated via windows, but easy to setup after
[14:49] <amitk_> when are you guys getting WiMAX rollouts?
[14:49] <BenC> rtg: it's USB, but it's one of the dell provided cards that fits into the internal wwan slot
[14:49] <rtg> BenC: I think I have one of those.
[14:50] <BenC> pretty sure jose sent you one when he sent me one
[15:10] <Whoopie> 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] <mjg59> It doesn't provide carrier detect?
[15:22] <Whoopie> 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] <Whoopie> it seems that vmxnet supports carrier detection, but NetworkManager is not able to find it out.
[18:36] <thoreauputic> mjg59: thanks for getting the ball rolling on bug 201591 - looks like all is well with 2.6.24-14 :)
[18:36] <ubotu> 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] <mjg59> thoreauputic: Excellent
[18:38] <thoreauputic> finally! Now I can pursue my eccentric little no-X project with a hardy version
[18:39] <thoreauputic> 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] <mjg59> Yeah, it was my fault to begin with
[18:40] <thoreauputic> really?
[18:41] <thoreauputic> ah well - all's well that ends well and other conventional sentiments...
[18:41] <thoreauputic> :)
[18:44] <mjg59> Hm
[18:44] <mjg59> acx111 just blew away my kernel
[20:36] <dhaval> any clue where I will find Tim Gardener?
[20:37] <rtg> dhaval: yes?
[20:37] <dhaval> rtg, regarding BUG 188226
[20:37] <ubotu> Launchpad bug 188226 in linux "Kernel should use CONFIG_FAIR_CGROUP_SCHED" [High,Fix released] https://launchpad.net/bugs/188226
[20:38] <dhaval> CONFIG_FAIR_CGROUP_SCHED is arch independent
[20:38] <rtg> 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] <dhaval> rtg, it is arch independent. i have resolved fair_cgroup_sched bugs on ia64 and ppc
[20:39] <rtg> I went through the menuconfig options manually, but no CGROUPS selection presented itself.
[20:39] <dhaval> rtg, you need to have CONFIG_CGROUP on for that
[20:40] <rtg> is the a prerequisite ?
[20:40] <dhaval> it depends on that
[20:40] <dhaval> well, how else would you do cgroup scheduling :)
[20:40] <rtg> hmm, lemme recheck.
[20:40] <rtg> I was in  a hurry at the time.
[20:40] <dhaval> hmm. you had us a bit worried
[20:40] <dhaval> rtg, i still suggest, keep cgroup_sched as default
[20:40] <rtg> shit. you know thats gonna cause another ABI bump.
[20:40] <dhaval> itwill save you a lot of bugs like that boinc one
[20:41] <dhaval> rtg, hmm?
[20:41] <rtg> its not a big deal, but does cause some process work for the archive admins.
[20:42] <dhaval> ok. well i have been hollering for cgroup_sched for months now :)
[20:43] <rtg> 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] <dhaval> 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] <dhaval> rtg, heh, i wrote part of that code :)
[20:44] <rtg> 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] <dhaval> rtg, i have been hollering for months. i don't have any issues.
[20:45] <dhaval> but you are going to get a number of "bugs" because people are not going to be aware of the changed behavior
[20:45] <rtg> 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] <rtg> Those who really care can run the server image on their desktop.
[20:46] <dhaval> rtg, people are *NOT* going to be aware of the new scheduler behavior
[20:46] <dhaval> they are going to find that they get 50% cpu and daemons get 50%
[20:46] <dhaval> and nice can't help them there.
[20:46] <dhaval> you will get bugs raised on that, and you will have to come up with workarounds.
[20:47] <dhaval> the suggested solution is to shift to CGROUP_SCHED, which as I mention i have been suggesting for months now :)
[20:47] <rtg> in all honesty, 99% of desktop users don't care. I'll point out the alternatives when I have to.
[20:48] <dhaval> rtg, ok, i will let you be the judge on that. its your decision in the end..
[20:48] <rtg> CGROUPS is definitely in the cards for Intrepid.
[20:49] <dhaval> 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] <rtg> yes - as part of updating the configs.
[20:49] <dhaval> rtg, might I also suggest to try playing with the memory controller, which allows you to control memory.. :)
[20:49] <rtg> i'll get it into the LP report.
[20:49] <dhaval> rtg, thanks!
[20:53] <rtg> dhaval: what about  CONFIG_CGROUP_NS and CONFIG_CPUSETS ?
[20:53] <dhaval> rtg, cpusets will allow you create groups of CPUs/memory banks
[20:53] <dhaval> you can then put tasks and set them to run only on those cpusets
[20:54] <rtg> dhaval: so you recommend enabling those options as well?
[20:54] <dhaval> ns is still a black hole for me.
[20:54] <dhaval> rtg, ns, i suggest you get in touch with their developers.
[20:54] <dhaval> i believe cpusets is quite stable.
[20:54] <rtg> dhaval: you would be just as happy with just cpusets?
[20:55] <dhaval> rtg, did not get the question
[20:55] <rtg> dhaval: sorry, l meant would you be ok with only enabling CONFIG_CPUSETS ?
[20:55] <rtg> do you actually use either option in practice?
[20:56] <dhaval> rtg, i am not sure if desktop users would be interested in cpusets.
[20:56] <dhaval> or ns proxy.
[20:56] <dhaval> as a user, i don't use cpusets or ns
[20:57] <rtg> dhaval: ok, since their use is optional I'll enable them as well.
[20:57] <dhaval> 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] <dhaval> rtg, this is for intrepid right?
[20:59] <blueyed> Doesn't cpusets depend on cgroup?
[20:59] <dhaval> blueyed, yep, all thesedepend on cgroup
[20:59] <blueyed> dhaval: thanks for bringing this issue up again here.
[20:59] <blueyed> rtg: I've been also pondering about this, since 2.6.24 hit Hardy..
[20:59] <rtg> dhaval: I was going to enable cpusets and ns for Hardy server.
[21:00] <dhaval> blueyed, i did not know about the existence of this channel, otherwise i would have been hollering here earlier
[21:00] <blueyed> it's really a regression for users/desktops..
[21:00] <dhaval> blueyed, well, we can agree to disagree :)
[21:00] <dhaval> blueyed, i call it expected behavior
[21:00] <dhaval> rtg, i just talked to upstream folks, they like the idea, it will get it wider coverage
[21:00] <blueyed> dhaval: I'm for cgroups.. because it's the old behaviour, I mean.
[21:00] <dhaval> rtg, thanks a lot for listening!
[21:01] <dhaval> blueyed, yeah, i aree
[21:01] <rtg> dhaval: the new kernel package should show up by morning (UTC-8)
[21:01] <dhaval> rtg, thanks, i should set up hardy-rawhide or something like that on a virtual machine
[21:02] <blueyed> rtg: with cgroups only for server, still?
[21:02] <dhaval> blueyed, rtg i would still suggest desktop as well, but its your decision in the end, not mine
[21:03] <rtg> 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] <dhaval> rtg, i wish they would have involved us in the discussion as well
[21:04] <dhaval> we could have provided you with more information
[21:04] <rtg> well, better late then never :)
[21:04] <dhaval> being conservative, i would have suggested cgroup and not user
[21:04] <blueyed> rtg: I've scammed the irclogs about this, and it seemed to just have been rushed over.
[21:04] <dhaval> user is more dangerous, because of the "bugs" that will surely crop up as blueyed will confirm
[21:04] <rtg> blueyed: it may well have been, being somewhat ignorant of the issue myself.
[21:05] <blueyed> rtg: not fair.. I've been here before, there have been several bug reports it, etc..
[21:05] <dhaval> rtg, fwiw, why don't you guys get upstream folks involved as well?
[21:05] <blueyed> It has just been ignored and then "too late now..."..
[21:05] <dhaval> blueyed, i agree..
[21:05] <rtg> its a matter of volume. there are few of us, and literally thousands of bug reports.
[21:06] <rtg> the stuff that gets my attention are hard failures.
[21:06] <blueyed> rtg: you could have saved some time, by listening to this issue earlier.. ;) "upstream" (dhaval) came to us even..
[21:06] <dhaval> rtg, hmm. that is where getting upstream more closely involved would help
[21:07] <dhaval> rtg, fwiw, i don't use ubuntu and this experience made me feel like using ubuntu even lesser
[21:07] <rtg> come on you guys, quit beating me up. I can on;y do so much.
[21:08] <dhaval> rtg, sorry! not meant to beat you up.
[21:08] <dhaval> but lesson to be learnt. do involve upstream
[21:08] <dhaval> we all want linux to get better
[21:08] <blueyed> rtg: sorry, we're not beating.. but finally somebody seems to listen, so..
[21:09] <rtg> I'm working on it. like I said, I'll have a CGROUPS server release in the morning.
[21:09] <dhaval> rtg, if you do hit scheduler bugs, do report it up, most of the folks are very responsive
[21:09] <dhaval> rtg, fwiw, it holds for all subsystems
[21:09] <rtg> will do
[21:10] <dhaval> remember, we all want to make Linux better :)
[21:12] <blueyed> 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] <blueyed> rtg: can you please bring this up in the kernel-team again?
[21:13] <dhaval> blueyed, thanks for putting it up so clearly, thta's what i have been trying to say
[21:13] <dhaval> rtg, i have to agree with blueyed 
[21:13] <rtg> blueyed: I'll raise the issue. I'll even post a PPA kernel for testing.
[21:13] <dhaval> what is PPA?
[21:13] <blueyed> rtg: great. I would have put one in my Personal Package Archive (PPA) anyway.
[21:13] <rtg> dhaval: Personal Package Archive.
[21:13] <dhaval> blueyed, thanks!
[21:13] <dhaval> rtg, thanks!
[21:14] <blueyed> (or installed -server), but all that won't help normal users.
[21:14] <dhaval> blueyed, i would suggest custom sched-devel kernel :)
[21:14] <blueyed> Thank you, dhaval. Also with bugging me about properly working around in boinc.. :)
[21:15] <blueyed> sched-devel?
[21:15] <dhaval> blueyed, that is the tree for the next kernel release. (currently aimed for 2.6.26)
[21:15] <blueyed> dhaval: don't ask for too much.. ;)
[21:16] <dhaval> 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] <dhaval> rtg, blueyed are there any resources on how i can setup the ubuntu-devel branch?
[21:17] <dhaval> let me just set it up in a virtual machine
[21:17] <rtg> dhaval: there is some wiki info. lemme find it.
[21:18] <rtg> https://wiki.ubuntu.com/KernelMaintenance
[21:18] <dhaval> rtg, oh, i meant something similar to fedora's rawhide which is a daily build of how fedora looks?
[21:20] <rtg> 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] <rtg> there is agit repo.
[21:20] <rtg> s/agit/a git/
[21:21] <dhaval> 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] <dhaval> if i can set that up, I can get you more feedback than I can do now
[21:21] <rtg> dhaval: no, the distro is only built on demand, e.g., when a package update is uploaded.
[21:22] <dhaval> hmm. ok.
[21:22] <dhaval> right, that's similar to rawhide.
[21:23] <dhaval> what i meant by rebuild was that you have a daily build. the updates are pushed out once aday
[21:23] <rtg> the updates are pushed to the archive as soon as an archive admin pushes them, about once an hour.
[21:24] <rtg> that is, after the build completes.
[21:24] <dhaval> 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] <rtg> 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] <dhaval> rtg, oh. ok, proably another day then.
[21:27] <dhaval> rtg, i won't be lurking about here, but feel free to let me know by email if I can help
[21:27] <cradek> yay, my framebuffer console (radeon) works again with -14
[21:27] <rtg> dhaval: ok. thanks for the pointers.
[21:29] <dhaval> 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] <dhaval> rtg, i did have one more question
[21:32] <rtg> dhaval: yes?
[21:32] <dhaval> 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] <dhaval> do you need sponsors and such stuff?
[21:33] <rtg> dhaval: right, they are called MOTU sponsors.
[21:33] <dhaval> if this is totally off topic, just point me to the right channel
[21:33] <rtg> dhaval: is there an #ubuntu channel? Its likely a good place to start.
[21:34] <dhaval> that seems like a user channel and /join #ubuntu-devel gave me * ubuntu-devel :That channel doesn't exist
[21:34] <dhaval> hmm. i seemed to have made a stupid mistake
[21:34] <dhaval> mised the #
[21:35] <rtg> dhaval: if that doesn't work out, send an email to Daniel Holbach <dholbach@ubuntu.com>
[21:36] <dhaval> rtg, thanks! i found #ubuntu-motu
[21:36] <rtg> ok, I'm ducking out for a bit.
[21:37] <dhaval> hmm. that channel seems awfully quiet
[21:37] <dhaval> rtg, ok, thanks!
[21:45] <blueyed> 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] <dhaval> blueyed, link to the daily live cd?
[21:45] <blueyed> dhaval: http://cdimage.ubuntu.com/daily-live/current/
[21:45] <blueyed> (from google :p)
[21:45] <dhaval> blueyed, thanks!
[21:46] <dhaval> blueyed, too lazy, its too late here. i am supposed to be asleep about 2 hours back
[21:57] <tjaalton> is lbm meant to be a staging area for proposed updates to lum?
[22:03] <liquidhackz> irssi quit
[22:06] <tjaalton> 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] <num> 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] <Nafallo> num: I would try a memtest :-)
[22:39] <num> a memtest?
[22:40] <num> Nafallo: but a memtest that urly during boot?
[22:40] <Nafallo> num: esc during the grub menu and choose memtest
[22:41] <num> Nafallo: you suppose a damaged memory?
[22:42] <Nafallo> that's one of the first things I check. sounds like some kind of hardware issue at least.
[22:43] <num> i can't believe this, since i'm on this machine with the kernel version below, xx-12
[22:43] <num> and no problems
[22:43]  * Nafallo shrugs
[22:44] <Nafallo> I just say what it sounds like to me. and never said that it was the actual issue.
[22:44] <num> Nafallo: i thank you
[22:44] <num> i appreciate any ideas, help
[22:45] <Nafallo> :-)
[22:46] <num> 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] <blueyed> 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] <Ng> is there intended to be another kernel build before release? or is 14 likely to be it barring any disasters?
[23:24] <rtg> Ng: one more ABI bump tonight.
[23:25] <rtg> I did n't get CGROUPS set correctly on all arches.
[23:25] <Ng> erk
[23:25] <Ng> 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] <rtg> the joys of open source?
[23:26] <Ng> 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] <Ng> and I can make easily enough make a PPA for people with the same hardware
[23:28] <rtg> Ng: what hw do you have that we are not supporting?
[23:29] <smb_tp> Ng: You solved your camera problem
[23:29] <smb_tp> ?
[23:29] <Ng> rtg: audio chipset and usb camera
[23:29] <Ng> smb_tp: I think so, yeah
[23:29] <Ng> well I didn't, upstream did :)
[23:30] <smb_tp> 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] <Ng> smb_tp: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/200990/comments/10
[23:30] <ubotu> Launchpad bug 200990 in linux "[hardy] oops when running cheese on Thinkpad X300" [High,Triaged] 
[23:32] <smb_tp> Ng: Just missed that by seconds, hmpf. ;-)
[23:33] <Ng> hehe
[23:33] <Ng> 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] <smb_tp> 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] <rtg> smb_tp: looks fine. It demonstrably fixes the issue?
[23:37] <smb_tp> rtg: So says Ng but i can put that in and make a test module
[23:37] <rtg> smoh, I missed that port. I trust Ng. (must be getting late)
[23:37] <rtg> s/smoh/oh/
[23:38] <smb_tp> rtg: It really is. :)
[23:39] <Ng> 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] <rtg> smb_tp: make it so. I'll get it before I upload later this evening.
[23:39] <smb_tp> rtg: I'll try my very best...
[23:40] <Ng> thanks :)
[23:44] <infinity> Ng: What did you do to earn this bizarre level of trust?
[23:44] <infinity> Ng: Has rtg *seen* terminator?
[23:45] <Ng> infinity: I'll have you know that more than one respected member of the distro team uses it! ;)
[23:46] <infinity> Ng: Can you name them, or have they begged for anonymity? :)
[23:46] <rtg> 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] <infinity> rtg: I can prevent you from ever building anything again; do my patches get similar treatment? :)
[23:47] <rtg> infinity: only if you attach them to the LP report :) its so easy that way...
[23:48] <infinity> rtg: That's so much more effort than just directly committing them.
[23:48] <Ng> 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] <infinity> Ng: xterm's where it's at!