| 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? | 01:58 |
|---|---|---|
| === bjf is now known as bjf_afk | ||
| === smb_tp is now known as smb | ||
| Ng | are things like /proc/sys/vm/{laptop_mode,dirty_writeback_centisecs} supposed to be remembered across suspends? | 11:33 |
| amitk | Ng: they should be... | 12:14 |
| Ng | amitk: empirically... not so much | 12:14 |
| 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:15 |
| Ng | ooh, good point | 12:17 |
| Ng | http://pastebin.com/f537ccbeb | 12:20 |
| Ng | oh I wonder if this is the _ON_AC setting | 12:20 |
| amitk | probably | 12:23 |
| amitk | try disconnecting AC and see if your settings are restored, assuming they are made to laptop-mode.conf and _not_ sysctl.conf | 12:24 |
| 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:30 |
| amitk | lifeless: never seen in before, worth a bug. | 12:40 |
| 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:25 |
| rtg | apw: why does gem barf on pae? | 13:26 |
| rtg | is it the extra page table level? | 13:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:32 |
| apw | ouch, no receieve side? | 13:36 |
| rtg | apw: works fine if I hard code the address | 13:37 |
| apw | unable to receive broadcasts perhaps? | 13:38 |
| rtg | apw: no, it ARP'd OK | 13:39 |
| apw | hrm | 13:40 |
| apw | bug in dhcp client perhaps | 13:40 |
| apw | perhaps slap a tcpdump on the channel before enabling | 13:40 |
| rtg | apw: I can see the offer in /var/log/syslog | 13:41 |
| apw | *gurgle* | 13:41 |
| 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:42 |
| rtg | apw: well, pae --> garbage onscreen | 13:47 |
| apw | rtg hrm, that is unexpected | 13:47 |
| 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:48 |
| 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:51 |
| apw | rtg, i see luke has just sent up a pull for the ports re-merge | 13:52 |
| 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:53 |
| 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:55 |
| 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:56 |
| apw | Keybuk, any idea what the limitation on sysfs and proc might mean | 13:57 |
| 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:58 |
| apw | ahh heh yeah it is a stupid thing to do obviously | 13:59 |
| apw | it was only a minimal demo of the explosion | 13:59 |
| 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:03 |
| 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:04 |
| 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 | 14:05 |
| pgraner | apw: ping | 15:07 |
| 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:08 |
| === Nafallo_ is now known as Nafallo | ||
| apw | pgraner, what a crock | 15:27 |
| 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:29 |
| apw | heh perhaps | 15:30 |
| 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:31 |
| apw | pgraner, indeed .... i'll get a range of kernels and see if i can reproduce it here | 15:32 |
| smb | We probably have to look and decide | 15:34 |
| bjf_afk | rtg, question about imx51 build | 16:46 |
| === bjf_afk is now known as bjf | ||
| rtg | bjf: hmm? | 16:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| bjf | rtg, I'll dig into it | 16:51 |
| rtg | bjf: k, I'll be back in awhile | 16:51 |
| === stew is now known as HolieThePuppet | ||
| === HolieThePuppet is now known as stew | ||
| apw | Keybuk, that unionfs kernel is ready: https://edge.launchpad.net/~apw/+archive/green | 18:00 |
| Keybuk | thanks | 18:01 |
| 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:05 |
| rtg | MacSlow: Jaunty? | 18:07 |
| MacSlow | rtg, no on Karmic 2.6.30-9-generic | 18:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| MacSlow | *sniff* | 18:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:28 |
| MacSlow | re | 18:29 |
| invisibill | side effect is my best sound card "echoaudio mia" doesn't work with this. | 18:29 |
| 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:30 |
| invisibill | I've built custom kernels on debian systems a few years back but I'm sure the process is different on ubuntu. | 18:31 |
| 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:33 |
| 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:34 |
| invisibill | ok thanks rtg I'll have a read up of this. | 18:36 |
| rtg | MacSlow: works fine for me as well | 18:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| MacSlow | especially thinkpads | 18:42 |
| rtg | in a perfect world... | 18:42 |
| MacSlow | gee... my world is collapsing right now :) | 18:42 |
| * apw shifts to his ethernet connection to save his packets | 18:43 | |
| MacSlow | apw, now you're scared right? :) | 18:47 |
| apw | heh | 18:47 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| Keybuk | damnit, this feels so close :p | 19:11 |
| Keybuk | mailed Jan + Val | 19:14 |
| apw | you are clearly testing it far more than they | 19:17 |
| 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:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| 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:23 |
| jjohansen | apw: is the error EXDEV | 19:24 |
| apw | i believe so yes | 19:24 |
| 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:25 |
| 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 | 19:26 |
| Keybuk | while, yes, I agree with Jan that POSIX does say that rename() might fail ... | 20:01 |
| 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' ? | 20:23 |
| === ivoks_ is now known as ivoks | ||
| TheMuso | rtg: Ok I'll hopefully get to revising the ports configs stuff this evening. | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!