[01:10] <laga> iostat 1 > log
[01:10] <laga> gah
[01:11] <laga> sorry about that. i was gonna get some logs while my box was terribly lagging and got the wrong window on accident
[01:23] <zul> #133636
[01:24] <bdmurray> bug 133636
[01:24] <ubotu> Launchpad bug 133636 in linux-source-2.6.22 "[gutsy]  hdaps module does not load on Thinkpad T61P" [Low,Fix released]  https://launchpad.net/bugs/133636
[01:25] <bdmurray> It is the one you already fixed but I think some other models were mentioned in later comments
[01:26] <zul> *sigh* they should have opened other bug reports
[01:26] <bdmurray> heh
[01:26] <bdmurray> If only
[01:31] <zul> bug #133636
[01:31] <ubotu> Launchpad bug 133636 in linux-source-2.6.22 "[gutsy]  hdaps module does not load on Thinkpad T61P" [Low,Fix released]  https://launchpad.net/bugs/133636
[01:44] <TheMuso> c
[01:44] <TheMuso> ugh
[01:58] <osmosis> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/147014
[01:58] <ubotu> Launchpad bug 147014 in linux-meta "linux-image-xen on amd64 not detected by update-grub." [Undecided,New]  
[03:11] <bdmurray> zul: I don't see the R41 listed in the Gutsy git tree for hdaps
[03:19] <zul> damnt i could have sworn I seen it
[03:19] <bdmurray> I did look before I mentioned it. ;)
[03:21] <zul> which bug report is that?
[03:23] <bdmurray> bug 145877
[03:23] <ubotu> Launchpad bug 145877 in linux-source-2.6.22 "hdaps doesn't work on Thinkpad R61" [Undecided,Fix released]  https://launchpad.net/bugs/145877
[03:23] <mjg59> R41? I'm not convinced there was one.
[03:24] <zul> bdmurray, that was for an r61
[03:25] <bdmurray> right, so my first statement should have been R61
[03:25] <zul> yeah my bad
[03:25] <bdmurray> and now I'm wrong
[03:26] <zul> i changed the status
[03:26] <zul> ../patches/0004-UBUNTU-hdaps-Add-support-for-Thinkpad-R61.patc
[03:26] <bdmurray> Hrm, I do see R61 in the git tree
[03:26] <zul> hasnt been added yet..
[03:26] <zul> ill be sending the patches tonight before I got to bed ;)
[03:27] <bdmurray> Okay, but I really see R61 at http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=blob;h=bf21111a81f6756b95fdbd115d797980284c6ce7;hb=d05017ef5f9dabd13f0bba3df74b9d8832d7e40f;f=drivers/hwmon/hdaps.c
[03:30] <zul> meh..
[05:17] <RobertStuffers> there can be only one kernal !
[05:56] <osmosis> hi
[06:09] <osmosis> cool man, well let me know if there is anything I can do. Im willing do learn stuff if needed.
[06:09] <osmosis>  the xen kernel on gutsy amd64 isnt recognized as a valid kernel by grub.
[06:12] <rtg__> osmosis: zul is the xen master.
[06:12] <zul> rtg__: im talking to him about it already ;)
[06:13] <osmosis> rtg__: yah, but he says  "that grub error has to do with the meta package which something i dont have control over"
[06:14] <zul> actually its probably update-grub that is erroring out
[06:14] <osmosis> zul: true, but even when I manually put the kernel into grub... thats when I get the error 13 on boot...invalid executable.
[06:14] <osmosis> zul: update-grub just doesnt put it in the menu.lst, probably can tell its not valid.
[06:14] <zul> ok intresting
[06:17] <bdmurray> rtg__: Should I bring any last minute kernel bugs to your attention?
[06:17] <rtg__> only if I know how to fix 'em :)
[06:18] <bdmurray> That's all of them right?
[06:18] <zul> hehe
[06:23] <bdmurray> bug 147858
[06:23] <ubotu> Launchpad bug 147858 in linux-source-2.6.22 "western digital WD800ADFS ncq problems" [Medium,Triaged]  https://launchpad.net/bugs/147858
[06:25] <rtg__> bdmurray: its too late to be mucking around in core disk stuff. Remember the lib-pata snafu?
[06:26] <zul> rtg__: that should be just blacklisting the drive
[06:26] <bdmurray> I read that as just black listing a drive?
[06:27] <rtg__> you are right. Can someone develop a patch?
[06:27] <zul> bdmurray: assign me the bug ill send a patch tonight
[06:28] <bdmurray> done
[06:28] <zul> thanks
[07:09] <zul> rtg__: do you want me to send the patch to the kernel-team ml?
[07:19] <evand> Not sure how much it will help, but I just ran into another unionfs bug: http://people.ubuntu.com/~evand/tmp/unionfs-oct1-syslog
[07:52] <BenC> evand: we're in the process of fixing that problem, but thanks
[07:53] <evand> anytime, thanks for looking into it
[07:57] <rtg__> zul: I see that you have.
[07:57] <ScottK> BenC: I've had a persistent fan problem with Gutsy (Bug #127772).  Are we past the point where fixes for problems like this will be considered?
[07:57] <ubotu> Launchpad bug 127772 in linux-source-2.6.22 "CPU fan no longer runs after upgrade to Gutsy" [Medium,Triaged]  https://launchpad.net/bugs/127772
[07:58] <BenC> ScottK: is there a fix?
[07:59] <ScottK> BenC: Not that I know of.  I'm a user as far as the kernel goes.
[07:59] <BenC> ScottK: then we can't put a fix in yet :)
[08:00] <ScottK> BenC: Of course.  But if we're past the point where a fix could go in, then I'll stop trolling for a kernel hacker to help me figure it out.
[08:00] <BenC> ScottK: it's possible, but all depends on timing and severity
[08:00] <ScottK> BenC: Thanks.
[08:06] <ScottK> I suspect that the problem centers around /proc/acpi/thermal_zone/THRM/cooling_mode changing from "cooling mode:	active" to "0 - Active; 1 - Passive" from Feisty to Gutsy, but I have no idea where to look for how that got changed or where to change it back.  Hints from anyone would be appreciated.
[08:09] <rtg__> ScottK: mjg59 is our ACPI expert. perhaps he has some ideas.
[08:09] <ScottK> rtg__: Thanks.
[08:10] <mjg59> The only thing influencing fan control is the kernel
[08:54] <Lutin> hi there
[09:58] <Lutin> any chance that someone take a look at bug #129910 ?
[09:58] <ubotu> Launchpad bug 129910 in initramfs-tools "tty[1-6]  are active but display nothing in Gutsy" [High,Triaged]  https://launchpad.net/bugs/129910
[10:21] <Al1i>  /join ubuntu+1
[10:48] <bdmurray> rtg__: What does it mean if someone has to boot with all_generic_ide ?
[11:32] <pkern> Is there something speaking against a SLAB kernel flavour apart from the fact that it may be too late?
[11:39] <amitk> pkern: buggy?
[11:43] <pkern> amitk: A proven allocator is buggy? Fun.
[11:44] <pkern> Seriously. fglrx is suggested on laptops but breaks on suspend. "We depend on ATI." is IMHO not that valid as it's a regression over Feisty.
[11:44] <pkern> People start to build their own kernels because of this which is at least annoying.
[11:47] <lamont> pkern: I have a laptop where I've blacklisted fglrx so that I can have suspend
[11:47] <amitk> pkern: http://lwn.net/Articles/229984/
[11:47] <pkern> amitk: I read LWN, kthx
[11:48] <pkern> lamont: Possible solution as I currently don't need working 3D acceleration. But then there are users which depend on it (for whatever reason).
[11:49] <pkern> amitk: I don't say "let's switch back" but "provide a new flavour and document it properly".
[11:49] <lamont> ah, then in that case, you get to choose whether you want 3D or suspend
[11:49] <pkern> Maybe I should add a "anymore" here.
[11:49] <lamont> until such time as we get a working fglrx driver binary blob.  go closed source!
[11:50] <lamont> what would the flavor do differently?
[11:50] <pkern> There will be free drivers. Maybe for Hardy.
[11:50] <kylem> provide a new flavour?
[11:50] <pkern> lamont: Use SLAB instead of SLUB.
[11:50] <kylem> you mean provide 4 new flavours.
[11:50] <lamont> ah, that.
[11:50] <pkern> lamont: The driver works fine with 2.6.22, but with SLAB instead of SLUB.
[11:51] <lamont> I see.
[11:51] <amitk> pkern: considering that kernel freeze is tomorrow, this discussion is moot
[11:51] <pkern> amitk: It's not that I haven't spoke up earlier.
[11:52] <pkern> lamont: fglrx is even suggested by a nice shiny popup for `more performance' or whatever it states.
[11:52] <lamont> mk
[11:52] <pkern> lamont: That's one of the key critisism I have here. But if X works properly with fglrx kernel module blacklisted...
[11:53] <pkern> Point is that at least my card is not supported by the free drivers.
[11:53] <pkern> (For Gutsy that is.)
[11:53] <lamont> pkern: works for me...
[11:53] <pkern> lamont: Ok.
[11:53] <kylem> so what's the problem? does it panic?
[11:53] <lamont> of course, I also turn of compiz because I have better things for it to do.
[11:53] <pkern> kylem: Suspend hangs with a blinking cursor.
[11:54] <lamont> kylem: fails to suspend
[11:54] <pkern> lamont: Compiz does not work for fglrx out of the box.
[11:54] <lamont> and then you reboot
[11:54] <lamont> pkern: I'm fine with that. :-)
[11:54] <kylem> if that's the best you can do for debugging information, then i'm afraid i'm just going to point and laugh.
[11:54] <pkern> lamont: Me too.
[11:54] <pkern> Bah. Please.
[11:55] <lamont> kylem: when I was troubleshooting why suspend didn't work with mjg59, we got to the point where he learned that fglrx was loaded and he said "don't do that. kthxbye"
[11:55] <lamont> so that was where I stopped
[11:55] <pkern> Kernel devs also responded that SLUB is correct and they won't support it.
[11:55] <pkern> It's ATI's fault and we know that, but this is not the point here.
[11:55] <kylem> the only issue i know of with slub, is that it warns if you double free a pointer.
[11:56] <lamont> kylem: and that ati calls it wrong, apparenlty.
[11:56] <lamont> for some value of "wrong"
[11:56] <kylem> well, comment out that check, and if it works, and you can tell me in the next 30 minutes, maybe i'll consider it.
[11:58] <kylem> sorry, it warns on 0-sized allocations, not double free.
[11:59] <pkern> When it only warns that should not pose a problem?
[12:00] <kylem> you'd think.
[12:01] <pkern> I think the problem are some weird semantics ATI relies on, but I am currently looking for the part to comment out.
[12:01] <kylem> well, if they do broken things like that with the allocator, then it's clearly a derived work.
[12:01] <kylem> ;-)
[12:03] <pkern> The point is that I don't know how to debug it. The display goes black.
[12:03] <pkern> i.e. even debug output would not help
[12:03] <pkern> And I don't see a printk for a zero-length alloc.
[12:03] <pkern> Hm, object_err...
[12:04] <kylem> maybe they removed it.
[12:05] <pkern> There are things like Alignment padding checks and something about "red zones".
[12:06] <pkern> It's just a pity when you know that with SLAB it works fine.
[12:07] <mjg59> Sounds like SLUB works fine
[12:07] <mjg59> It's the thing we don't have the source to that isn't
[12:07] <kylem> well, i'm not the only ubuntu kernel person, but it sure won't be me who reverts to slab.
[12:08] <pkern> mjg59: If you tell me that there is a free driver for X1400 in Gutsy I will gladly move to that one instead.
[12:09] <mjg59> I thought we'd established you don't need to use the kernel module?
[12:09] <pkern> mjg59: Still doesn't solve the source problem, but ok. ;)
[12:10] <mjg59> It means that you don't have kernel problems caused by the thing we can't debug, so...
[12:14] <pkern> Ok, it worked now but it showed a "your computer failed to suspend" bubble afterwards.
[12:14] <pkern> But nevermind that \:
[12:17] <elmo> btw, is there any 'how to debug suspend' failures (where by 'debug' I mean provide enough info for someone else to debug) page somewhere?
[12:18] <elmo> my laptop only suspends on AC, breaks on battery
[12:19] <mjg59> Basically, no
[12:19] <elmo> mjg59: ok, so when are you next visiting millbank? :-P
[12:19] <mjg59> Not in the near future
[12:19] <mjg59> You going to be in Boston?
[12:19] <elmo> yeah
[12:20] <mjg59> Yeah, so only three and a half weeks away
[12:20] <mjg59> That's kind of weird, though
[12:20] <mjg59> I can't think of any obvious reasons for that
[12:24] <amitk> elmo: https://wiki.ubuntu.com/DebuggingKernelSuspend That's the best we have
[12:24] <lamont> I much prefer the implicit howto:  1) take laptop to mjg59. 2) procure beverages 3) profit.
[12:26] <amitk> hmm.. new marketing slogan for Ubuntu - "Ships with mjg59" (TM)
[12:27] <pkern> mjg59: Ok, I got your point wrt debugging looking at that page.
[12:36] <bdmurray> Could somebody look at 129910?