[02:47] <Maahes> are there known issues with kernel 2.6.27-13 generic and all versions of the Nvidia binary drivers?
[02:48] <Maahes> because I am getting....beyond bad issues with all versions thereof. like binary information being written out on config files
[02:48] <Maahes> interspersed with strings in german, for some reason
[02:54] <Maahes> in any event, so far as I can tell 2.6.27-13 is broken for Nvidia binaries 177.82-0ubuntu0.1 and 173.14.12-1-0ubuntu5.1
[02:54] <Maahes> whether installed via envyng or restricted manager
[02:55]  * Maahes decides to revert to 2.6.27-12 for awhile
[06:07] <purentropy> WHen I try to boot from the live CD my system HANGS at [ 97.125547] ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15  
[06:07] <purentropy> never gets to the desktop
[06:07] <purentropy> i can't run any terminal commands because i never get to the livecd desktop.  Can anyone make any sense of this message?
[06:10] <purentropy> I have Nvidia Nforce 630i chipset.  WDC 500GB SATA HDD.  Using 8.10 LiveCD. No externals plugged in besides monitor,keyboard,mouse,ethernet
[06:13] <n2diy> purentropy: ask the whole question in #ubuntu, the Nvidia stuff is important, and not kernel related.
[09:51] <davmor2> Guys I just completed a 64bit Ubuntu install from netboot mini.iso and am greeted with a nice little window that says....  Kerneloops-ui  Your system had a kernel failure
[10:09] <davmor2> What logs do you need is it just /var/log/kern.log?
[10:25] <davmor2> I'm having to carry on testing so I've put logs here:  http://www.davmor2.co.uk/kern.log  http://www.davmor2.co.uk/debug.log  http://www.davmor2.co.uk/dmesg.log
[10:40] <smb_tp_> davmor2, I am at a loss about what kerneloops is complaining. There is nothing apparent in the log files...
[10:42] <davmor2> smb_tp_: No idea either.  I finished the install rebooted and was greeted by 2 kerneloops windows one behind the other.  I'm doing a kubuntu install so I'll check if it happens again
[10:43] <smb_tp_> davmor2, ok. I'll peek at the package in the meantime
[10:44] <davmor2> smb_tp_: It wouldn't be because it is a netboot install and part that it wanted was missing could it?
[10:44] <davmor2> if so I'll have a look in the installer folder and see if there is a kern.log in there too which might help
[10:45] <smb_tp_> I wouldn't rule out this at the moment since I am not sure what it looks for exactly. At least it sounds unlikely that it found something in the dmesg
[10:45] <smb_tp_> Except it take the WARNINGs as something bad, which would be bad
[10:47] <davmor2> it only affects 64bit to 32 bit worked fine
[10:47] <smb_tp_> davmor2, The ui is IIRC triggered by a file being  in /var/crash... Maybe that has some info
[10:48] <davmor2> smb_tp_: if I get it again in kubuntu (which I'm guessing I should)  I'll have a look and see if there is anything in there for you
[10:48] <smb_tp_> ok
[12:47] <ia> hello. maybe it's wrong place for this question, but i don't know, where else i can ask about it. I use jaunty with latest updates at 2.6.28-9.29 kernel. during boot i get a few (~10) messages with modprobe usage text and when gnome starts, it shows warning that kernel can't use cpu frequency scaling. at 8.27 and earlier everything was fine. I just intresting to know, does anybody else have the same strange issue?
[12:57] <davmor2> smb_tp_: Can't reproduce at the moment might just of been an install issue If it does come back up I'll post any crash logs too :)
[12:59] <smb_tp_> davmor2, Ok, sure. Lets see
[13:02] <wmat> ia: ensure you're system has the latest BIOS
[13:03] <wmat> ia: then review the Launchpad bugs for fpu frequency scaling as there's been a few
[13:04] <wmat> ia: s/fpu/cpu
[15:14] <sconklin>  have we ever considered pulling the upstream video4linux directly into a distro? The reason I ask is that there's a good bit of device enablement in the delta between what we have in jaunty and what's upstream in v4l
[15:16] <smb_tp_> I do not remember this being discussed before...
[15:17] <smb_tp_> But I could think this increases the burden when syncing. rtg knows the pain for wireless
[15:22] <sconklin> I'm looking at a patch now that fixes an open bug, but it's against upstream. Still not too hard to backport, but I wondered whether it was worth the risk to take the whole pile. I think I'd be willing to serve as the go-between for our kernels. I think it's too late for Jaunty in any case.
[15:23] <rtg> smb_tp_: it all depends on how often we sync. we could think about it for Karmic.
[15:23] <sconklin> Like wireless, it would take someone following upstream, syncing bugs, etc.
[15:24] <rtg> sconklin: sprint topic?
[15:24] <sconklin> rtg: sure, if there are any open slots. I'd be happy to moderate
[15:24]  * smb_tp_ nods
[15:24] <rtg> sconklin: surely we could find an hour out of 3 days to chat about it
[15:25] <sconklin> ok, I'll ask pgraner to schedule it is he can. If he can't I'll just be opportunistic about bringing it up
[15:25] <sconklin> if he can
[16:04] <rtg> Keybuk: Re: [PATCH 29/31] esp: Auto-load esp module when device opened. Alan Cox says "NAK - the default esp behaviour is to do unsafe ISA probes to find the ports. We don't want it autoloading therefore.". I tend to agree with him when it comes to ISA probing.
[16:04] <Keybuk> sure
[16:04] <Keybuk> in fact, I'm of the opinion that all of these patches should be dropped for the next ubuntu kernel if they haven't been merged upstream
[16:05] <Keybuk> thus I realise they shouldn't have been "SAUCE"
[16:05] <Keybuk> the whole sauce non-sauce thing confuses me a little ;)
[16:05] <Keybuk> the important thing is that we had an alias to auto-load that driver
[16:05] <Keybuk> we turned it into the kernel patch
[16:05] <Keybuk> and someone upstream said it was wrong
[16:05] <Keybuk> which means our alias was wrong too
[16:05] <Keybuk> so it's fine for both to go :p
[16:08] <rtg> Keybuk: OK, I'll revert at least the esp patch.
[16:09] <Keybuk> I'd probably wait until karmic, unless you feel a pressing need
[16:09] <Keybuk> simply on the basis that there may be people who've been testing jaunty so far and relying on it working
[16:09] <Keybuk> it's less rude to break such things at the start of a release
[16:09] <rtg> Keybuk: that patch has only existed for the last couple of uploads. Probing of ISA ports is a bad thing.
[16:10] <Keybuk> right, but we had a modprobe.d alias before
[16:10] <Keybuk> which had the exact same effect
[16:10] <rtg> so, you're saying its always been loaded automagically?
[16:27] <Keybuk> right
[16:27] <Keybuk> I'm quite happy to drop that on Alan's word that it shouldn't be
[16:27] <Keybuk> but wishy-washily-vaguely leaning towards doing that drop when we rebase for karmic rather than right before jaunty beta :p
[16:47]  * JanC wonders why an extra-sensory-perception module has to do isa-probing  :P
[17:08] <cj> hmm?  esp?  isa?  are you talking about ipsec?
[17:10] <anubhav>  cj: ithink its http://lxr.linux.no/linux+v2.6.28.4/drivers/char/esp.c
[17:13] <cj> ah, not Encapsulated Security Payload / Internet Security and Acceleration
[17:35] <anubhav> johanbr: did the "up_threshold" param solve your issue?
[17:36] <johanbr> anubhav: I've been pretty busy so I haven't actually tried it yet. But I'll keep it in mind next time I compile something.
[17:37] <anubhav> johanbr: oh okay :)
[17:43] <porq69> hi
[20:37] <Lure> I am using https://wiki.ubuntu.com/KernelBugFixing to try one upstream fix, but the build in PPA fails with ABI error
[20:37] <Lure> http://launchpadlibrarian.net/23761073/buildlog_ubuntu-jaunty-lpia.linux_2.6.28-9.29~lure~lp285834_FAILEDTOBUILD.txt.gz
[20:38] <Lure> is something missing regarding ABI in the wiki page?
[20:40] <TheMuso> Lure: You need to fetch the abi files for a previous kernel if there were any, otherwise you need to disable ABI checking.
[20:41] <TheMuso> I'm guessing this is the first kernel you are building, so disabling the abi check is probably the best option.
[20:41] <TheMuso> if its your ppa only
[20:47] <Lure> TheMuso: how can I disable ABI check in package?
[20:48] <TheMuso> Lure: probably the easiest way is to add something like "skipabi = true" and "skipmodule = true" to the top of debian/rules.d/0-common-vars.mk
[20:48] <TheMuso> actually, add those two lines exactly to the top of that file, and things should be ok.
[20:48] <Lure> TheMuso: thanks - will try now
[20:49] <Lure> TheMuso: you are audio guy, right?
[20:49] <TheMuso> Lure: yes
[20:50] <Lure> TheMuso: can you comment how likely is to get quirk fix from sound-2.6.git into Jaunty - I am talking about bug 285834
[20:50] <ubot3> Malone bug 285834 in alsa-driver "Audio out on x200/x200s dockingstation doesn't work" [Undecided,New] https://launchpad.net/bugs/285834
[20:50] <Lure> I plan to test it first and hopefully it will work for me and other reporters...
[20:50]  * TheMuso checks to see whether the commit needed is in 2.6.29
[20:53] <TheMuso> Lure: it is not in 2.6.29 yet, and I don't think rtg et al like pulling commits from anywhere else but upstream, and its a rather big diff, so I am not sure if the kernel team would be comfortable merging it.
[20:53] <TheMuso> Upstream here being Linus' tree.
[20:54] <Lure> TheMuso: ok, will check back only if we have positive testing reports
[20:55] <Lure> otherwise I may maintain custom kernel in ppa
[20:55] <Lure> TheMuso: thanks a lot for you help
[20:55] <TheMuso> Lure: np
[21:01] <rtg> TheMuso: I just replied to email about missing commits
[21:02] <rtg> to your email
[21:04] <TheMuso> rtg: right
[21:13] <dandel> ><; any ideas on where i can get generic 2.6.25 and 2.6.26 series of mainline in binary?
[21:19] <rtg> dandel: I tarted a mainline build for 2.6.25, watch the kernel team mailling list for completion
[21:19] <rtg> started*
[22:20] <dandel> RTG, that's good to know... i'll be looking for it then.