[01:58] <zeroprog> hey guys i finally was able to compile my module example....but in /var/log/messages it says init suspiciously returned 32 but loading module anyway.....is this bad?
[11:33] <Ng> are things like /proc/sys/vm/{laptop_mode,dirty_writeback_centisecs} supposed to be remembered across suspends?
[12:14] <amitk> Ng: they should be...
[12:14] <Ng> amitk: empirically... not so much
[12:15] <Ng> I set them in sysctl.conf on boot and they're back at roughly default looking values 20 hours later after an unknown number of suspends
[12:15] <Ng> what I need, is a test case :)
[12:15] <amitk> Ng: does laptop-mode.conf have any settings to override it, I wonder
[12:17] <Ng> ooh, good point
[12:20] <Ng> http://pastebin.com/f537ccbeb
[12:20] <Ng> oh I wonder if this is the _ON_AC setting
[12:23] <amitk> probably
[12:24] <amitk> try disconnecting AC and see if your settings are restored, assuming they are made to laptop-mode.conf and _not_ sysctl.conf
[12:30] <lifeless> is there a known bug in karmic where laptops randomly power off?
[12:30] <lifeless> happened to me twice now; power button wasn't held down. machine didn't feel overheated.
[12:40] <amitk> lifeless: never seen in before, worth a bug.
[13:25] <rtg> apw: lemme experiment with the pae kernel a bit.
[13:25] <apw> sure ... in a couple of hours i will have some kernels available for testing (errors permitting)
[13:26] <rtg> apw: why does gem barf on pae?
[13:26] <rtg> is it the extra page table level?
[13:27] <apw> the agp interfaces used to take addresses <4gb only as i understand it
[13:27] <apw> the patches change the API to take page*'s instead fixing the issue
[13:27] <rtg> ah, I guess that makes sense
[13:28] <apw> i think it meant you might try and push things into highmem for graphics objects and the world ended
[13:28] <apw> in bad, corrupting type ways
[13:29] <amitk> one would think that this would be one of the first problems the developers would encounter given that they work for Intel and probably have few machines with < 4Gb of memory
[13:30] <apw> amitk, i am constantly amazed by what is ignored
[13:30] <apw> the issue was a core interface issue, so it got ignored by the graphics people
[13:30] <apw> till dave picked it up it seems
[13:32] <rtg> hmm, its pretty bad when NM can't even get an ethernet DHCP address. I can see the server offerring an address, but the Karmic client is just ignoring it.
[13:36] <apw> ouch, no receieve side?
[13:37] <rtg> apw: works fine if I hard code the address
[13:38] <apw> unable to receive broadcasts perhaps?
[13:39] <rtg> apw: no, it ARP'd OK
[13:40] <apw> hrm
[13:40] <apw> bug in dhcp client perhaps
[13:40] <apw> perhaps slap a tcpdump on the channel before enabling
[13:41] <rtg> apw: I can see the offer in /var/log/syslog
[13:41] <apw> *gurgle*
[13:42] <apw> that has to be a NM/dhcp bug then
[13:42] <apw> as we now know the offer made it to the machine, and into dhcp-client, and we know you can set an address on the interface
[13:47] <rtg> apw: well, pae --> garbage onscreen
[13:47] <apw> rtg hrm, that is unexpected
[13:48] <apw> i would have expected working but compiz disabled
[13:48] <apw> i'll get with bryce and see what testing we can get done on those kernels
[13:51] <rtg> apw: this DHCP issue has to be Karmic related, I booted a Jaunty kernel and still cannot get an ethernet address, though wireless works fine.
[13:51] <apw> yeah be worth seeing if we have merged those support packages recently
[13:52] <apw> rtg, i see luke has just sent up a pull for the ports re-merge
[13:53] <rtg> this ought to be interesting
[13:53] <apw> yeah ... you gonna handle that?
[13:53] <rtg> might as well, everything is fresh in my head
[13:53] <apw> or do you want me to
[13:53] <apw> good enough
[13:53] <rtg> back in a few, coffee run
[13:53] <TheMuso> FWIW this was not something I asked for. I was happy with how it was, but the archive admins are the ones who want this merge.
[13:55] <apw> yeah we were happy too, not sure quite what the beef was exactly
[13:55] <Keybuk> apw: got a new build for me yet? :p
[13:55] <TheMuso> apw: I can fully understand why  you guys wanted it separate.
[13:56] <apw> Keybuk, oh we got fixes there too
[13:56] <apw> ?
[13:56] <Keybuk> apw: yeah Jan sent a patch through earlier
[13:56] <Keybuk> Subject: [PATCH] Don't replace nameidata path when following links
[13:56] <apw> ok just finsihed some kms uploads, so will get that now
[13:56] <Keybuk> (in the thread)
[13:57] <apw> Keybuk, any idea what the limitation on sysfs and proc might mean
[13:58] <Keybuk> yes
[13:58] <Keybuk> if you mount your union over /
[13:58] <Keybuk> then any attempt to write into /proc, /sys, /dev, etc. will go to the union ;)
[13:59] <apw> ahh heh yeah it is a stupid thing to do obviously
[13:59] <apw> it was only a minimal demo of the explosion
[14:03] <soren> Keybuk: What's the solution for that? Special case virtual filesystems or avoid overlaying "submounts" altogether?
[14:03] <soren> Or something entirely different?
[14:04] <Keybuk> soren: you make the union before you mount them
[14:04] <Keybuk> you can mount over top of a union obviously
[14:04] <soren> Keybuk: Oh, right.
[14:04] <Keybuk> ie. make your root filesystem, then mount the union, then mount the virtual filesystems, etc.
[14:04] <Keybuk> I was actually thinking that it might be fun to support this in /etc/fstab :p
[14:04] <soren> Right, right. *headdesk* I wasn't thinking.
[14:05] <Keybuk>   server:/ro/jaunty/usr  /usr  nfs defaults 0 0
[14:05] <Keybuk>   tmpfs                  /usr  tmpfs  union 0 0
[14:05] <Keybuk> then I realised that it just works
[14:05] <apw> nnng
[15:07] <pgraner> apw: ping
[15:08] <apw> pong
[15:08] <pgraner> apw: can you take a peek at https://bugs.launchpad.net/bugs/370173  this one is getting a huge number of "me too" 
[15:08] <ubot3> Malone bug 370173 in linux "Ubuntu 9.04 laptop overheat and shutdown" [Undecided,Confirmed] 
[15:27] <apw> pgraner, what a crock
[15:29] <pgraner> apw: heh... its another one of those bugs with a billion comments...
[15:29] <rtg> apw: we use crock pots to make stew, and they are hot. is that the issue?
[15:30] <apw> heh perhaps
[15:31] <pgraner> apw: not sure if its better suited for you or smb but we need to track it and see if there what upstream knows
[15:32] <apw> pgraner, indeed .... i'll get a range of kernels and see if i can reproduce it here
[15:34] <smb> We probably have to look and decide
[16:46] <bjf_afk> rtg, question about imx51 build
[16:47] <rtg> bjf: hmm?
[16:48] <bjf> rtg, jiffies.h can find CLOCK_TICK_RATE
[16:48] <bjf> rtg, it's defined in mx51.h
[16:48] <rtg> bjf: s/can/can't/ ?
[16:48] <bjf> rtg, right "can't"
[16:49] <rtg> seems like an arch problem introduced by their patch set
[16:49] <bjf> rtg, early part of build must setup headers so this can be found
[16:49] <bjf> rtg, It's probably one of the merge conflicts that I didn't handle right
[16:49] <rtg> bjf: yep, the prep phase points asm to asm-arm
[16:50] <rtg> bjf: do you have your branch pushed somewhere?
[16:50] <bjf> rtg, looking at include I don't see asm or asm-arm
[16:50] <bjf> rtg, just asm-generic
[16:51] <bjf> rtg, I'll dig into it
[16:51] <rtg> bjf: k, I'll be back in awhile
[18:00] <apw> Keybuk, that unionfs kernel is ready: https://edge.launchpad.net/~apw/+archive/green
[18:01] <Keybuk> thanks
[18:05] <MacSlow> http://pastebin.ubuntu.com/198664
[18:05] <MacSlow> Anybody with an idea what "Failed to register hw (error -17)" means?
[18:05] <MacSlow> Thanks in advance
[18:07] <rtg> MacSlow: Jaunty?
[18:13] <MacSlow> rtg, no on Karmic 2.6.30-9-generic
[18:14] <rtg> MacSlow: its a software registration error, so I'm not really sure why its failing.
[18:14] <MacSlow> rtg, firmware issue?
[18:14] <rtg> MacSlow: I have some 3945's. Lemme try 'em out.
[18:14] <MacSlow> rtg, sweet... thanks!
[18:15] <MacSlow> rtg, btw.. just so that you know... I've wifi-based network again thanks to the atk9k PCMCIA-card I've plugged into laptop
[18:16] <MacSlow> rtg, but still getting the internal wifi-card working again would be very slick
[18:16] <rtg> MacSlow: they both use the same registration function, so its interesting that iwl is failing.
[18:16] <rtg> MacSlow: I assume the i3945 worked with Jaunty?
[18:16] <MacSlow> rtg, oh... so it's not a firmware thing then?!
[18:17] <MacSlow> rtg, well the whole thing started failing around the interpid/jaunty time
[18:17] <rtg> MacSlow: I don't think so, but I did recently upgrade the Karmic firmware for that part.
[18:17] <rtg> MacSlow: if its been failing for that long, then you may have HW issues.
[18:17] <MacSlow> that's why I bought the atk9k in Mountain View during second last UDS in California
[18:18] <MacSlow> crap
[18:18] <rtg> some of these wireless cards don't last forever.
[18:18] <MacSlow> rtg, it's not really an old laptpo
[18:19] <MacSlow> only about 2 years old
[18:19] <MacSlow> I regard that still as rather new
[18:19] <rtg> MacSlow: I guarantee that i3945 worked with Intrepid and Jaunty.  Its in one of my primary travel laptops
[18:20] <MacSlow> *sniff*
[18:21] <rtg> MacSlow: I'm updating an Inspiron 1420 with Karmic. It'll be 20 minutes or so. I also know that ogasawara has the same laptop.
[18:21] <MacSlow> I wonder if I can get a replacement one on warrenty still
[18:21] <rtg> MacSlow: can't help you there :)
[18:22] <MacSlow> rtg, ogasawara had her fair bit of entanglements with my laptop at last AllHands regarding the issue
[18:22] <MacSlow> killswitch issues back then
[18:22] <rtg> MacSlow: I'm really thinking you might HW issues
[18:22] <MacSlow> but I was running another kernel during AllHands
[18:22] <rtg> s/might/might have/
[18:23] <rtg> MacSlow: what kind of laptop?
[18:23] <ogasawara> MacSlow: lemme reboot into the latest karmic, but I've not had any issues with my wifi (iwl3945) on my inspiron 1420
[18:23] <MacSlow> rtg, I'll try to get feedback on an exchange card at the local dealer tomorrow or so
[18:23] <MacSlow> brb
[18:28] <invisibill> Greetings deep kernel heads:  I'm an amd64 / nvidia / ubuntustudio user.  I had to upgrade from the relase-rt kernel to http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30-rc8/ to work around system crashes.  
[18:29] <MacSlow> re
[18:29] <invisibill> side effect is my best sound card "echoaudio mia" doesn't work with this. 
[18:30] <invisibill> I want to build the latest kernel from scratch but I'm not sure of the way to go for this.  I see there is an rt in the git repository, but I cant tell if it will work for amd64. 
[18:30] <invisibill> any suggestions for the best place to start on this?  
[18:31] <invisibill> I've built custom kernels on debian systems a few years back but I'm sure the process is different on ubuntu. 
[18:33] <invisibill> This may be asking too much, but can you (anyone that knows what they're doing) put a how-to for building an ubuntu kernel on the kernel wiki?  
[18:33] <ogasawara> MacSlow: unfortunately no errors here for me with 2.6.30-9 - http://pastebin.ubuntu.com/198684/
[18:34] <rtg> invisibill: start here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
[18:34] <MacSlow> ogasawara, ok I'll try to get a replacement iwl3945 on warrenty then... hopefully
[18:34] <invisibill> there is this blog post here but It looks a bit ad-hoc http://blog.avirtualhome.com/2008/10/28/how-to-compile-a-custom-kernel-for-ubuntu-intrepid/
[18:34] <MacSlow> ogasawara, rtg: thanks sofar to the two of you!
[18:36] <invisibill> ok thanks rtg  I'll have a read up of this.
[18:37] <rtg> MacSlow: works fine for me as well
[18:38] <MacSlow> rtg, yeah.. rub salt into the wound ;)
[18:38] <rtg> MacSlow: just walk around muttering "I'm screwed, I'm screwed" :)
[18:38] <MacSlow> rtg, but you mentioned to see it often such internal wifi-cards die
[18:39] <rtg> MacSlow: mostly I see them die in outdoor environments
[18:39] <MacSlow> that kind of ruins my trust in the overly solid thinkpads
[18:40] <MacSlow> rtg, due to other electromagnetic radiation?
[18:40] <rtg> MacSlow: sometimes, but they also fail due to continuous use.
[18:40] <MacSlow> which is usually shielded by building walls (if one uses the laptop only indoors)?
[18:40] <MacSlow> how stupid is that?
[18:41] <rtg> MacSlow: if this is your primary laptop for the last 2 years, then its had a great deal of use.
[18:41] <MacSlow> almost sounds like built-in failure to keep customers
[18:41] <MacSlow> rtg, but it's a tool... it's meant to be used that thoroughly...
[18:42] <MacSlow> especially thinkpads
[18:42] <rtg> in a perfect world...
[18:42] <MacSlow> gee... my world is collapsing right now :)
[18:43]  * apw shifts to his ethernet connection to save his packets
[18:47] <MacSlow> apw, now you're scared right? :)
[18:47] <apw> heh
[19:03] <Keybuk> apw: I can chroot in!
[19:03] <invisibill> hi again.  I want to checkout the latest rt kerenel to build on my amd64 system:  http://kernel.ubuntu.com/git?p=abogani/ubuntu-jaunty-rt.git;a=commit;h=b583230610922e5414cb38d09d3104753a77a771  What is the command to do that? 
[19:03] <apw> Keybuk, excellent.  so you can do some sensible testing now?
[19:04] <apw> you could reply and let them know when you get a chance
[19:04] <Keybuk> apw: strange issue with symlinks
[19:04] <Keybuk> bash: /usr/bin/vi: File exists
[19:04] <Keybuk> where /usr/bin/vi -> /etc/alternatives/vi -> /usr/bin/vim.tiny
[19:04] <apw> hrm very odd.  so any of the other links work?
[19:04] <invisibill> git clone git://kernel.ubuntu.com/git?p=abogani/ubuntu-jaunty-rt.git  ??
[19:05] <Keybuk> yes
[19:05] <Keybuk> which is weird
[19:05] <Keybuk> type -f doesn't find it either
[19:05] <Keybuk> seems to be true for most alternatives
[19:05] <Keybuk> other symlinks are ok
[19:06] <apw> invisibill, nope, git clone git://kernel.ubuntu.com/abogani/ubuntu-jaunty-rt.git
[19:06] <apw> so links to links are unwell perhaps
[19:07] <Keybuk> apw: rename() obviously doesn't work
[19:07] <Keybuk> which breaks lots of things
[19:07] <invisibill> thanks apw
[19:07] <apw> whats it say 'EXFS' or something?
[19:08] <apw> i do wonder why a rename can't trigger a copy up, then simply return ERESTART
[19:08] <Keybuk> weird
[19:08] <Keybuk> stat64("/usr/bin/vi", 0x99999999) = -1 EEXIST (File exists)
[19:08] <apw> erp
[19:11] <Keybuk> damnit, this feels so close :p
[19:14] <Keybuk> mailed Jan + Val
[19:17] <apw> you are clearly testing it far more than they
[19:18] <jjohansen> apw: as I recall it, its returning that its across device, and the libc is suppose to pick that up and fallback to a copy
[19:19] <apw> but one really needs the atomicity of the rename() call
[19:19] <apw> so it seems safer to copy-up and restart the rename().  As i understand things rename() on things in the top layer can work
[19:21] <jjohansen> apw: I haven't looked at the patches enough, but I believe last I looked it was only doing rename in the top layer if both files were in the top layer, other wise it treated it like copy up
[19:21] <jjohansen> s/enough/recently
[19:22] <apw> right, i believe it will rename if the file is already up
[19:22] <jjohansen> I remember this being explicitly mentioned as a problem
[19:22] <jjohansen> that is possible
[19:22] <Keybuk> apw: I'm running apt-get dist-upgrade in the chroot
[19:22] <Keybuk> it's a pretty mean and unforgiving test
[19:23] <apw> so i think triggering a copy up, then returning ERESTART should trigger a new rename() from glibc and that should succeed
[19:23] <jjohansen> of course I could be mixing up aufs or unitionfs with union mounts, I spent more time in them
[19:23] <apw> i've suggested it to the authors, they can tell me why it would not work
[19:24] <jjohansen> apw:  is the error EXDEV
[19:24] <apw> i believe so yes
[19:25] <jjohansen> yeah, that is the error for moving files across a device
[19:25] <apw> Keybuk, that is very brave ... i am expecting you to have nothing left :)
[19:25] <Keybuk> which you are, obviously
[19:25] <Keybuk> though in practice, it should be a copy and a whiteout
[19:26] <apw> is your machine still with us?
[19:26]  * Keybuk decides to leave the "kernel panic on umount" bug for later
[19:26] <Keybuk> apw: sure
[20:01] <Keybuk> while, yes, I agree with Jan that POSIX does say that rename() might fail ...
[20:23] <invisibill> Hi again:  can someone tell me what the difference between running 'fakeroot debian/rules binary-modules-rt' and 'fakeroot make-kpkg –initrd –append-to-version=-me1 kernel_image kernel_headers' ? 
[23:40] <TheMuso> rtg: Ok I'll hopefully get to revising the ports configs stuff this evening.