[00:56] <baron1984> I have a question about the kernel, if anyone can enlighten me for a moment
[00:57] <baron1984> 2.6.24-17 and -18 failed to resume from suspend entirely requiring me to cut power to the power supply itself before the computer would even boot again
[00:57] <baron1984> 2.6.24-19 resumes but makes a chirping noise from the speakers then says it failed to resume
[00:58] <baron1984> is there any harm in using suspend in light of this?
[00:59] <baron1984> I looked in the system log and all it says is: Jun 18 19:48:52 ryan-desktop gnome-power-manager: (ryan) suspend failed
[02:34] <sisyphe> frenchies here ?
[04:31] <crimsun_> BenC: the previous intrepid upload of alsa-driver (1.1ubuntu1) already contains maks_'s addition, which you noted per Kano in the changelog for 1.1ubuntu2.  What gives?
[08:39] <Kano32> hi BenC , i have got a problem with the lrm package
[08:39] <Kano32> i raised the abi with
[08:40] <Kano32> DEBFULLNAME="Hotfix" DEBEMAIL="no@mail.ad" dch -v 2.6.26-2.0 Kernel ABI bump.
[08:40] <Kano32> then usually
[08:40] <Kano32> debian/rules clean
[08:40] <Kano32> should update the abi
[08:40] <Kano32> but it does fetch 1 not 2 as abi, it seems the lowest line is used not the top line of the changelog?
[08:42] <Kano32> sed -e 's/PKGVER/2.6.26/g' -e 's/ABINUM/1/g' >>
[08:42] <Kano32> this is exchanged
[08:42] <Kano32> but when i put the new abi in the last line of the changelog this is evalutated, something is really wrong there..
[08:43] <Kano32> the same worked with lum
[08:54] <Kano32> could somebody look at this please..
[08:57] <Kano32> stupid package
[08:58] <Kano32> hmm now i know it...
[08:58] <Kano32> you renamed the package from linux-restricted-modules to linux-restricted-modules-2.6.26
[08:59] <Kano32> then it can not work...
[09:44] <saispo> hi all
[09:45] <saispo> it's normal in ubuntu-feisty branch there are no debian/abi/2.6.20.17-36/ ?
[12:19] <xivulon> at UDS I understood that that intrepid kernel will support suspend-to-disk also when swap is on file
[12:19] <xivulon> can someone pls confirm that? 
[12:20] <mjg59> The kernel already supports suspending when swap is a file
[12:20] <mjg59> But there's no support for resuming
[12:21] <xivulon> mjg59: is that planned for intrepid?
[12:26] <mjg59> I'm afraid I don't know.
[13:59] <cjwatson> BenC: bug 241295 is another udeb issue for you (or somebody)
[14:30] <xivulon> cking, given your patch in ntfs-3g, do you think there is still any reason to use dm-loop (for intrepid)?
[14:30] <xivulon> will that improve write performance?
[14:31] <cking> xivulon: one I have a usable intrepid kernel on my 2 boxes here I can thoroughly benchmark it and compare it with the normal loopback
[14:32] <cking> xivulon: dm-loop will give better performance if it has direct access to the block device - in the Wubi case it won't, so the difference is debatable
[14:33] <xivulon> does it help with LVM(2) by any chance? that is in order to have resizable virtual disk
[14:34] <cking> xivulon: I'm unsure of this.
[14:35] <xivulon> thx
[14:36] <cking> xivulon: can you drop me an Email concerning the LVM(2) resizable virtual disk requirements so that I won't forget it and so I can mull over that question
[14:36] <xivulon> https://wiki.ubuntu.com/WubiIntrepid
[14:37] <cking> excellent!
[14:37] <xivulon> on that subject, do you think we can do anything on fsck for ntfs-3g?
[14:38] <xivulon> not necessarily a full blown fsck, but at least to address most common (or easier) issues
[14:38] <xivulon> and turn off the dirty flag
[14:38] <zul> gah....I didnt notice the ubuntu directory in ubuntu-intrepidi git tree
[14:39] <rtg> zul: its the new LUM
[14:39] <zul> rtg: gotcha
[14:40] <zul> drbd needs to be updated since I uploaded a new version today
[14:40] <cking> xivulon: it makes me feel uncomfortable fsck'ing a ntfs volume. It's a userland tool that I have no personal experience of (yet! :-)
[14:41] <xivulon> cking, I know, but that is probably the biggest issue we have in wubi at the moment :(
[14:43] <cking> xivulon: I suppose resourcing the ntfs fsck fix is the question to ask.
[14:58] <zul> BenC: ping
[15:00] <BenC> zul: yo
[15:00] <tseliot> BenC, rtg: why is the -generic flavour of Intrepid's kernel Xen-enabled?
[15:01] <zul> BenC: for the drbd8 any reason why you chose the 8.2.6 version?
[15:01] <BenC> tseliot: so it can be used a guest in xen environments
[15:01] <BenC> zul: I chose the latest version I saw available
[15:02] <zul> BenC: ah because I just uploaded 8.0.12 version which was just merged from debian
[15:02] <tseliot> ﻿BenC: fglrx doesn't work with Xen kernels and I'm having problems with nvidia too
[15:02] <BenC> tseliot: tell fglrx to ignore that fact...I think if you do that, it works ok
[15:03] <BenC> tseliot: have you contacted nvidia to see if they can fix their end?
[15:03] <zul> I doubt they will :)
[15:04] <tseliot> BenC: I have contacted them because their new driver (there are 4 flavours now) doesn't build with realtime kernels but I haven't received any reply
[15:06] <tseliot> BenC: here's the error with the NVIDIA driver: ﻿http://pastebin.com/m3c096a17
[15:06] <tseliot> with the -generic flavour
[15:08] <emgent> tseliot: heya
[15:08] <tseliot> BenC: I'm a bit concerned about this, since tjaalton and I should replace the lrm with the new packages in Intrepid
[15:08] <tseliot> ﻿emgent: hi
[15:17] <tseliot> BenC: I'm building with ﻿IGNORE_XEN_PRESENCE=1 IGNORE_CC_MISMATCH=1
[15:23] <BenC> tseliot: yeah, new lrm for intrepid is uploaded, without nvidia and fglrx
[15:24] <tseliot> BenC: I'll try contacting NVidia on their forums and saying explictly that I'm the new maintainer. Let's see if they care to reply.
[15:25] <BenC> tseliot: that looks like something I can fix
[15:25] <BenC> tseliot: can you give me your wip packages?
[15:25] <tseliot> BenC: ﻿wip?
[15:25] <tseliot> ah ok
[15:25] <tseliot> work in progress
[15:26] <tseliot> yes, sure
[15:26] <BenC> cjwatson: does that af_packet bug imply that we should have another upload soon for alpha 1?
[15:27] <tseliot> BenC: I'll upload them right now to my webspace.
[15:27] <BenC> cjwatson: I can do one today
[16:00] <zul> how do you just build the lum stuff in intrepid now?
[16:01] <cjwatson> BenC: yes please - lack of DHCP is sort of fatal :)
[16:16] <BenC> zul: there is no "lum stuff" in intrepid
[16:16] <zul> so I have to do the fakeroot debian/rules binary-generic ?
[16:20] <BenC> zul: there are ways of only building a portion of the kernel tree if that's what you are trying to do
[16:20] <zul> BenC: yes please :)
[16:29] <BenC> zul: mkdir ../build; cat debian/config/i386/config{,.generic} > ../build/.config; make O=`pwd`/../build prepare; make O=`pwd`/../build ubuntu/
[16:29] <BenC> that will build just the stuff under ubuntu/
[16:30] <BenC> you can even do things like ubuntu/aufs/
[16:30] <zul> BenC: thanks
[16:30] <mst_> Hey guys, I'm really stuck here: I cannot get Linux to see my IDE cdrom drive unless I boot with acpi=off -- I've tried just about every boot-time option with the stock Ubuntu kernel and just about every possible way of configuring things with a custom kernel to no avail... I need some help in figuring out what to do next to try and track down the problem 
[16:31] <BenC> mst_: the problem sounds like a BIOS issue
[16:31] <BenC> mst_: I suggest seeing if there's a BIOS update before doing further
[16:32] <BenC> mst_: the next step would be a bug report along with the usual info (dmesg with and without acpi=off, lspci -vvn)
[16:32] <mst_> BenC: I'm real frustrated because I can boot a LiveCD just fine -- I have the latest BIOS, its from Lenovo and it's real shitty... totally devoid of configuration options and info 
[16:32] <BenC> mst_: maybe just adding acpi=off /boot/grub/menu.lst (but I suspect without acpi you don't get suspend)
[16:33] <BenC> mst_: Oh, wait, you can boot the livecd fine (without acpi=off) but not your install?
[16:33] <mst_> BenC: yeah, acpi=off is not really a solution for a laptop system :-( 
[16:33] <mst_> BenC: yeah
[16:33] <BenC> mst_: which release is this?
[16:33] <mst_> BenC: 8.04 
[16:34] <BenC> is the installed kernel updated prior to having this problem? what if you boot the originally installed kernel (via grub menu)?
[16:35] <mst_> I started running 8.04 pre-release and this problem has persisted with every subsequent kernel update 
[16:35] <mst_> I suspect it has something to do with the fact that it's an IDE cdrom and a SATA hard disk
[16:35] <BenC> I can't see how a livecd boots fine, but the normal install doesn't work
[16:36] <mst_> the live cd boots, installs, and I can boot and everything works great, just no cdrom without "acpi=off" in the actual install 
[16:36] <BenC> mst_: does your BIOS have a way to set your hd controller to something like legacy/compatible/ahci?
[16:36] <mst_> and i've tried libata.noacpi=1
[16:36] <BenC> mst_: but the livecd wouldn't be able to boot if it didn't find your cdrom :)
[16:37] <mst_> That's why I suspect that libata is taking over control of the IDE ports (verifed by cat /proc/ioports) but wont recognize my drive 
[16:37] <BenC> libata is supposed to do that
[16:37] <mst_> I tried compatable and achi mode, each with combined_mode=ide and combined_mode=libata 
[16:38] <mst_> Yeah, but even with libata.atapi_enabled=1 I get nada... and I've tried all of these options as parameters in /etc/initrd-tools/modules, and having made and used the new initrd 
[16:39] <BenC> atapi is enabled by default in libata
[16:40] <BenC> so you can likely stop chasing that route, since libata is going to be the way your drive is detected
[16:40] <BenC> mst_: I'd be interested in a dmesg from a livecd boot, and one from a normal install boot (without acpi=off) to compare
[16:40] <mst_> cool, so what I think I might need to do is tell the kenrel explicitly what ioport to use for the cdrom drive 
[16:41] <BenC> if it works in a livecd, it should work in the installed system
[16:41] <mst_> I'd be happy to colleced that data, should I go about doing that now? I can but them both up in my public http space on my schools server 
[16:43] <BenC> mst_: yes, please
[16:43] <mst_> Alright... I have some rebooting to :-), be back in a few minutes 
[16:46] <lukehasnoname> if you had it on a VM you wouldn't have to bring down your machine :)
[16:47] <BenC> also probably couldn't reproduce the problem either :)
[16:47] <mst_> lukehasnoname, wouldn't the kernel just see virtual hardware? I have to be honest I don't know too mcuh about that 
[16:47] <mst_> alright rebooting...
[16:48] <BenC> cjwatson: new kernel+lrm uploaded, I'll get meta out when it's near finished (which should be quick)
[16:48] <BenC> cjwatson: it is an ABI bump
[16:48] <cjwatson> ok, thanks
[16:56] <BenC> cjwatson: builds for intrepid appear to be amd64=1:20hours and i386=2hours
[16:56] <BenC> just FYI
[17:08] <mst_> Alright... 
[17:08] <mst_> BenC: you should be able to see 3 files at www.uvm.edu/~mtretin 
[17:08] <mst_> BenC: I did dmesg for the installed system in AHCI mode and in Combatible mode 
[17:09] <mst_> as well as AHCI mode for the liveCD 
[17:19] <mst_> BenC: are you able to access them? I don't really ever use the public_html directory... 
[17:22] <BenC> mst_: weird, it's just plain not even probing the device...I was expecting a failure msg of some kind
[17:22] <BenC> mst_: do you have 2.6.24-16-generic on the installed system? If so, can you give me ahci dmesg from that?
[17:22] <BenC> that's what the livecd is booting, and I want to compare the same kernel on both sides
[17:23] <mst_> BenC: yep... just one reboot away 
[17:23] <mst_> brb
[17:23] <bdmurray> rtg: I seem to remember talking about bug 213011 in Prague but don't recall what you said.
[17:23] <BenC> hmm...ide-pci-generic.all-generic-ide
[17:23] <BenC> that shouldn't be there either
[17:25] <rtg> bdmurray: looking...
[17:26] <bdmurray> rtg: thanks
[17:27] <rtg> bdmurray: these guys need to be running the -19 kernel. there was a cosmetic fix that I think will help them out.
[17:27] <mst_> BenC: it should be there nw
[17:27] <bdmurray> rtg: alright, I'll ping them
[17:27] <rtg> bdmurray: I'll add it to the report
[17:27] <bdmurray> rtg: is that in -updates yet?
[17:27] <rtg> yep
[17:28] <mst_> BenC: thank so *very* much for all the help BTW
[17:28] <bdmurray> I'm so confused running -proposed all the time
[17:28] <rtg> bdmurray: I hear you there.
[17:30] <BenC> mst_: np...I tried to catch you before you left out, but can you also remove "ide-pci-generic.all-generic-ide" from the kernel cmdline...I don't think it is an issue, but just to keep a consistent test, redo the last dmesg without that
[17:30] <BenC> mst_: and thank you for taking the time to track this down
[17:31] <mst_> BenC: no problem... just let me get vim up...
[17:37] <mst_> BenC: dmesg.2.6.16-generic.achi-mode.txt should now be w/o the bogus kernel parameter 
[17:37] <mst_> or argument... to be technical lol 
[17:38] <tseliot> BenC: check your mail or the kernel mailing list. I have sent you the links to the source of my packages
[17:39] <mst_> BenC: and as far as me taking the time to track this stuff down... I couldn't be happier that I'm finally talking to someone who isn't telling me to do "modprobe ide-cd" :-)
[18:07] <BenC> mst_: I'm at somewhat of a loss as to why this is happening
[18:07] <BenC> mst_: can you try "sudo modprobe sr_mod"?
[18:08] <mst_> BenC: still no /dev/scd0 
[18:09] <mst_> BenC: woudl a dmesg with the option acpi=off (when the cdrom appears as scd0) help? 
[18:10] <mst_> BenC: I would love to figure out exactly what the addresse for my cdrom is, then couldn't I try ide0=xxx at boot time? 
[18:13] <BenC> mst_: is there anything in dmesg when you modprobe sr_mod?
[18:13] <BenC> mst_: also, try "sudo modprobe -r ata_piix; sleep 1; sudo modprobe ata_piix"
[18:15] <mst_> BenC: modprobe sr_mode doesn't put anything interesting in dmesg, except possibly "Driver 'sr' needs updating - please use bus_type methods" 
[18:16] <mst_> BenC: removing and reinserting (using your command) give me some output, but I don't really know whether any of it is useful or not 
[18:16] <mst_> output in dmesg that is
[18:18] <mst_> no cdrom in either case though 
[18:19] <mst_> is there a way of forcing the kernel to probe more deeply, equiv. to hdX=cdrom? like scd0=cdrom? 
[18:32] <BenC> Not that I'm aware of
[18:33] <BenC> it's probing, just not seeing anything
[18:33] <BenC> What I'm concerned about is what's the difference between the livecd boot and the installed system...they should be identical
[18:34] <BUGabundo> hi there
[18:35] <BUGabundo> ﻿I'm having trouble with linux-restricted-modules-2.6.24-19-generic
[18:35] <BUGabundo> ﻿getting this /var/lib/dpkg/info/linux-restricted-modules-2.6.24-19-generic.postinst: 7: lrm-manager: not found
[18:39] <mst_> BenC: So what's the next step? And, I know there is a boot parameter to tell the scsi system to probe more deeply for devices on a scsi channel... you think that might help? 
[18:53] <mst_> BenC: I'm going to try adding sr_mod to /etc/initramfs-tools/modules and hope that it does something different... I figure as long I i'm trying something I'm moving in some direction. Thanks for all the help though! 
[19:11] <Kano> anybody interested in a live cd 2.6.26 with auto installer of nvidia 177.13 and fglrx 8-6? (ubuntu config -xen +highmem64g)
[19:21] <Kano> it seems you are unable to produce a intrepid live cd ;)
[19:58] <infinity> kees: Yes?
[19:58] <kees> infinity: oh, meant the other one, but this works
[19:58] <kees> Rejected:
[19:58] <kees> avm-fritz-firmware_2.6.20.17.29_amd64.deb control file lists section as main/restricted but changes file has main/misc.
[19:58] <kees> avm-fritz-firmware_2.6.20.17.29_i386.deb control file lists section as main/restricted but changes file has main/misc.
[19:58] <kees> the "old" problem was that the Section was wrong in the debian/control file
[19:58] <kees> that was fixed -- all releases now match:
[19:58] <kees> Package: avm-fritz-firmware
[19:58] <kees> Architecture: i386 amd64
[19:58] <kees> Section: restricted/misc
[19:59] <infinity> main/restricted?  Ouch.
[19:59] <infinity> That's busticated.
[19:59] <kees> I'm a bit at a loss for what's going on here
[19:59] <infinity> Looks like a broken debian/control to me....
[20:00] <infinity> kees: Where can I snag this source?
[20:01] <kees> infinity: dak?
[20:01] <infinity> kees: Mmkay.
[20:01] <rtg> kees: will it still be there if its been rejected?
[20:01]  * infinity goes to find it.
[20:01] <kees> rtg: it got rejected by soyuz, so it's still in dak
[20:01] <infinity> rtg: The source will be there regardless.
[20:05] <infinity> La, la, la... Bandwidth, FTL.
[20:05] <kees> infinity: isn't "restricted/misc" valid?
[20:05] <infinity> kees: Should be.
[20:05] <cjwatson> main/restricted sounds like somebody did "Section: restricted"
[20:06] <kees> cjwatson: right, that's the old hiccup
[20:06] <kees> and the warning I saw was:
[20:06] <kees> 2008-06-19 17:55:39 WARNING Unable to grok section 'restricted', overriding it  
[20:06] <infinity> No, that's the current hiccup.
[20:06] <kees> with misc                                                                       
[20:06] <kees> 2008-06-19 17:55:39 WARNING Unable to grok section 'restricted', overriding it  
[20:06] <kees> with misc                                                                       
[20:06] <kees> which matches the same problem.
[20:06] <infinity> adconrad@lucifer:~/linux-meta$ dpkg-deb -I avm-fritz-firmware_2.6.20.17.29_amd64.deb | grep "^ Section"
[20:06] <infinity>  Section: restricted
[20:07] <cjwatson> debian/control.in.autogenerated.noreally?
[20:07] <infinity> It needs to be "Section: restricted/misc"
[20:07] <kees> linux-meta-2.6.20.17.29$ grep fritz -A2 debian/control
[20:07] <kees> Package: avm-fritz-firmware
[20:07] <kees> Architecture: i386 amd64
[20:07] <kees> Section: restricted/misc
[20:07] <infinity> debian/control is autogenerated.
[20:07] <infinity> Is it not?
[20:07] <rtg> infinity: I see it, in control.common
[20:07] <kees> gah, control.common
[20:08] <rtg> should be 'Section: main/restricted' ?
[20:08] <infinity> No!
[20:08] <kees> restricted/misc
[20:08] <infinity> Should be "Section: restricted/misc"
[20:08] <rtg> ok
[20:08] <cjwatson> main/restricted is Soyuz "helpfully" expanding what it thinks Section: restricted means for you
[20:09] <cjwatson> the main effect of this is to make it more obvious that it's a mistake, because it looks weird :)
[20:09] <cjwatson> (actually it's more likely just an internal normalised form rather than intentional helpfulness or otherwise)
[20:09] <alex_joni> what's Soyuz?
[20:10] <BenC> and evil robot that controls everything
[20:10] <cjwatson> alex_joni: the archive management component of Launchpad
[20:10] <alex_joni> cjwatson: ah, ok.. thanks
[20:10] <BenC> what cjwatson said is more PC I guess
[20:10] <alex_joni> PC = polite .. ?
[20:11] <alex_joni> politically correct?
[20:11] <infinity> That.
[20:11] <kees> alex_joni: "politically correct" which is the PC term for polite.  ;)
[20:11] <BenC> that one
[20:11] <alex_joni> ah right.. that one ;)
[20:11] <infinity> cjwatson: Anything without an explicit component is shoved into main, so "main/restricted" is certainly the "correct" way to interpret "Section: restricted"
[20:12] <cjwatson> indeed
[20:13] <infinity> (This is true of Debian too, for that matter, Debian/dak just won't reject for such an error, since it completely ignores a package's control field anyway, once overrides are in place)
[20:13] <infinity> s/control field/Section control field/
[20:14] <cjwatson> BenC: linux-crashdump-{generic,server} targeted at main or universe?
[20:16] <kees> rtg: are you re-uploading with the fix, or do you want me to poke it?
[20:17] <rtg> kees: just did it. linux-meta_2.6.20.17.30
[20:17]  * kees hugs rtg 
[20:20] <mst_> BenC: Alright... so i've been trying more stuff, and according to the libata FAQ there are detection problems with intel IDE mode drives (what I've got i'm sure), they suggest to play with force_pcs in ata_piix but modifno ata_piix doesn't have it listed as a param? 
[20:20] <mst_> BenC: shouldn't that men i cant call it at boot time? 
[20:49] <BenC> mst_: you're looking at old documentation
[20:51] <BenC> mst_: there's something more basic going on here...if it works in livecd, it should work on normal system, and the only reason for it not to is an ordering or race problem
[20:55] <BenC> brb, I need to force panic my machine for fun and profit
[21:39] <hwilde> when I run "top" what is meant by "buffers" in the memory display?
[21:39] <hwilde> Mem: 507664k total, 475780k used, 31884k free, 92116k buffers