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