[02:47] are there known issues with kernel 2.6.27-13 generic and all versions of the Nvidia binary drivers? [02:48] because I am getting....beyond bad issues with all versions thereof. like binary information being written out on config files [02:48] interspersed with strings in german, for some reason [02:54] 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] whether installed via envyng or restricted manager [02:55] * Maahes decides to revert to 2.6.27-12 for awhile [06:07] 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] never gets to the desktop [06:07] 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] 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] purentropy: ask the whole question in #ubuntu, the Nvidia stuff is important, and not kernel related. [09:51] 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 === mdz_ is now known as mdz [10:09] What logs do you need is it just /var/log/kern.log? [10:25] 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] davmor2, I am at a loss about what kerneloops is complaining. There is nothing apparent in the log files... [10:42] 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] davmor2, ok. I'll peek at the package in the meantime [10:44] smb_tp_: It wouldn't be because it is a netboot install and part that it wanted was missing could it? [10:44] 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] 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] Except it take the WARNINGs as something bad, which would be bad [10:47] it only affects 64bit to 32 bit worked fine [10:47] davmor2, The ui is IIRC triggered by a file being in /var/crash... Maybe that has some info [10:48] 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] ok [12:47] 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] 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] davmor2, Ok, sure. Lets see [13:02] ia: ensure you're system has the latest BIOS [13:03] ia: then review the Launchpad bugs for fpu frequency scaling as there's been a few [13:04] ia: s/fpu/cpu [15:14] 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] I do not remember this being discussed before... [15:17] But I could think this increases the burden when syncing. rtg knows the pain for wireless [15:22] 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] smb_tp_: it all depends on how often we sync. we could think about it for Karmic. [15:23] Like wireless, it would take someone following upstream, syncing bugs, etc. [15:24] sconklin: sprint topic? [15:24] rtg: sure, if there are any open slots. I'd be happy to moderate [15:24] * smb_tp_ nods [15:24] sconklin: surely we could find an hour out of 3 days to chat about it [15:25] 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] if he can [16:04] 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] sure [16:04] 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] thus I realise they shouldn't have been "SAUCE" [16:05] the whole sauce non-sauce thing confuses me a little ;) [16:05] the important thing is that we had an alias to auto-load that driver [16:05] we turned it into the kernel patch [16:05] and someone upstream said it was wrong [16:05] which means our alias was wrong too [16:05] so it's fine for both to go :p [16:08] Keybuk: OK, I'll revert at least the esp patch. [16:09] I'd probably wait until karmic, unless you feel a pressing need [16:09] simply on the basis that there may be people who've been testing jaunty so far and relying on it working [16:09] it's less rude to break such things at the start of a release [16:09] Keybuk: that patch has only existed for the last couple of uploads. Probing of ISA ports is a bad thing. [16:10] right, but we had a modprobe.d alias before [16:10] which had the exact same effect [16:10] so, you're saying its always been loaded automagically? [16:27] right [16:27] I'm quite happy to drop that on Alan's word that it shouldn't be === zul_ is now known as zul [16:27] 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] hmm? esp? isa? are you talking about ipsec? [17:10] cj: ithink its http://lxr.linux.no/linux+v2.6.28.4/drivers/char/esp.c [17:13] ah, not Encapsulated Security Payload / Internet Security and Acceleration [17:35] johanbr: did the "up_threshold" param solve your issue? [17:36] 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] johanbr: oh okay :) [17:43] hi === JanC_ is now known as JanC [20:37] I am using https://wiki.ubuntu.com/KernelBugFixing to try one upstream fix, but the build in PPA fails with ABI error [20:37] http://launchpadlibrarian.net/23761073/buildlog_ubuntu-jaunty-lpia.linux_2.6.28-9.29~lure~lp285834_FAILEDTOBUILD.txt.gz [20:38] is something missing regarding ABI in the wiki page? [20:40] 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] I'm guessing this is the first kernel you are building, so disabling the abi check is probably the best option. [20:41] if its your ppa only [20:47] TheMuso: how can I disable ABI check in package? [20:48] 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] actually, add those two lines exactly to the top of that file, and things should be ok. [20:48] TheMuso: thanks - will try now [20:49] TheMuso: you are audio guy, right? [20:49] Lure: yes [20:50] 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] Malone bug 285834 in alsa-driver "Audio out on x200/x200s dockingstation doesn't work" [Undecided,New] https://launchpad.net/bugs/285834 [20:50] 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] 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] Upstream here being Linus' tree. [20:54] TheMuso: ok, will check back only if we have positive testing reports [20:55] otherwise I may maintain custom kernel in ppa [20:55] TheMuso: thanks a lot for you help [20:55] Lure: np [21:01] TheMuso: I just replied to email about missing commits [21:02] to your email [21:04] rtg: right [21:13] ><; any ideas on where i can get generic 2.6.25 and 2.6.26 series of mainline in binary? [21:19] dandel: I tarted a mainline build for 2.6.25, watch the kernel team mailling list for completion [21:19] started* [22:20] RTG, that's good to know... i'll be looking for it then.