| dtchen | ogasawara: thanks, sending upstream. | 02:00 |
|---|---|---|
| === elmo_ is now known as elmo | ||
| === bjf is now known as bjf-afk | ||
| benh | TheMuso: ping | 05:44 |
| * apw wonders if the lucid compiler will deign to compile his kernel today | 09:30 | |
| Appiah | hello apw , are you busy? | 09:35 |
| apw | Appiah, always busy ... /me is fighting the lucid compilers ... grr | 09:38 |
| Appiah | :) | 09:38 |
| Appiah | I was wondering what happend to that laptop without networking bug, you mentioned that the kernel with the fix was old.. but for karmic there's no alternative atm | 09:39 |
| Appiah | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/418933 | 09:39 |
| ubot3 | Malone bug 418933 in linux "no internet connection (wifi+ethernet doesn't work)" [Low,Confirmed] | 09:39 |
| apw | Appiah, the fix back there never did seem likely as a real fix | 09:45 |
| Appiah | well I'm using it now or else I dont have any network on karmic :D | 09:45 |
| apw | Appiah, ok ... there seems to be a settling on a fix for things which reverting that commit have been helped by... so i'll pull that back and get you to test a newer kernel with that in | 09:57 |
| apw | it'll take a bit | 09:57 |
| Appiah | apw ok | 10:09 |
| apw | i am not on the fastest of links today | 10:10 |
| ghostcube | apw: my bug has arrived again after reboot the webcam was dark again | 10:25 |
| ghostcube | :) | 10:25 |
| ghostcube | but it worked after the installtion | 10:25 |
| apw | so its intermittent then | 10:25 |
| apw | (most likely) | 10:26 |
| apw | what was the bug # so i can reopen it | 10:26 |
| ghostcube | moment | 10:26 |
| ghostcube | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/466935 | 10:26 |
| ubot3 | Malone bug 466935 in linux "No Video Output in Karmic with ID 046d:09a1 Logitech, Inc. QuickCam Communicate MP/S5500" [Undecided,Fix released] | 10:26 |
| ghostcube | after the installation of the kernel and reboot the cam worked fine | 10:26 |
| ghostcube | the next day after reboot the cam stopped delivering any picture but its working | 10:27 |
| ghostcube | could thi9s be an /dev problem ? | 10:27 |
| ghostcube | cause camorama claims no /dev/video0 | 10:30 |
| ghostcube | all other tools just use the cam | 10:30 |
| ghostcube | but it claims it too if the cam works in cheese oO | 10:31 |
| smb | Hm, could this be some v4l1->v4l2 problem... | 10:31 |
| apw | normally no /dev/video0 means that the kernel hasn't seen the device i belive as its not asked udev to make the devices | 10:31 |
| apw | and it could well be related to that smb yes | 10:32 |
| apw | "if a hospital cannot meet 18 week guarentee, the patient would be offered a range of options 'at nhs prices'" | 10:40 |
| apw | heh, wrong window | 10:43 |
| amitk | apw: trying to sell viagra on #u-k, eh? | 10:44 |
| apw | yeah one needs a bit of side income | 10:45 |
| Appiah | :) | 10:45 |
| ghostcube | smb: i dont know this started with karmic update | 10:50 |
| ghostcube | and on jaunty i had the dev/video0 | 10:50 |
| ghostcube | could this be an usb problem maybe that the usb devices arent registered normally ? | 10:51 |
| smb | ghostcube, karmic update as in updating the whole system (not only a kernel update after updating to karmic)? | 10:51 |
| ghostcube | yeah jaunty to karmic | 10:51 |
| ghostcube | after this cam stoped working | 10:52 |
| ghostcube | then i thought the new kernel from proposed may fixes an driver bug so i tested and it worked direct after reboot | 10:52 |
| ghostcube | then a day later after starting pc it didnt work | 10:52 |
| ghostcube | i tried to disconnect and reconnect usb boot with and without it | 10:52 |
| ghostcube | no chance | 10:52 |
| smb | ghostcube, just to tule that out: is karmic the only os on the machine? | 10:52 |
| ghostcube | yeah | 10:53 |
| ghostcube | pure linux machine | 10:53 |
| ghostcube | and pure ubuntu :) | 10:53 |
| ghostcube | nah kubuntu but this shouldnt be the prob hehe | 10:54 |
| ghostcube | :D | 10:54 |
| smb | ok, so it can't be initialized by something else ;-). Well it might be a race then. There were some because the boot is now more parallel and quicker | 10:54 |
| ghostcube | smb: i still boot grub 1 if this is important too | 10:54 |
| smb | Hm, I don't believe this should have effects on that... | 10:54 |
| ghostcube | in my bug report you see that udev gives a strange device id to the cam | 10:55 |
| ghostcube | could this be the problem ? | 10:55 |
| smb | have not yet, looked to it as apw was. lemme see... | 10:55 |
| ghostcube | and iam not the only one with exactly this problem i tested in compiz channel wth spme supporters | 10:56 |
| ghostcube | for them it worked too after fresh install of the kernel update then reboot the other day and it stoped | 10:57 |
| ghostcube | totally strange thing hehe | 10:57 |
| smb | Hm, just a stupid thought... on the first boot sreadahead is slowing things down to sample the map for speedup... | 10:58 |
| smb | where was that again... I believe /var/lib/sreadahead/pack...? apw? | 10:59 |
| apw | yeah i think that is there you are correct | 10:59 |
| smb | It might be interesting to remove that pack file and force it to resample again and see what happens | 10:59 |
| smb | (on reboot) | 10:59 |
| apw | and removing that pack is enough to ensure a 'slow' boot | 11:00 |
| apw | (good thought smb) | 11:00 |
| ghostcube | oh i get it so it builds an "id package" with all found ids i it and uses them on second boot to not relocate the packages again ? | 11:00 |
| ghostcube | is this somehow correct ? | 11:01 |
| smb | ghostcube, no actually unrelated to udev. I samples which files are opened on boot | 11:01 |
| ghostcube | ah ok :D | 11:01 |
| smb | to place them into a map to read-ahead on the next boot | 11:01 |
| apw | what it does do is significantly change the timing of boot | 11:08 |
| apw | so if your cam worked on first boot after an update and not after it may be timing related | 11:09 |
| apw | removing that file and rebooting would give you the 'other' timing pattern and | 11:09 |
| apw | would allow confirmation of that as cause | 11:09 |
| ghostcube | ah ok so i should remove this pack later at my machine ? | 11:14 |
| ghostcube | and then reboot | 11:14 |
| smb | and then try your webcam, yep | 11:14 |
| ghostcube | ok :) | 11:14 |
| ghostcube | thx for all i will try later guys | 11:15 |
| apw | Appiah, i've posted an updated kernel | 11:30 |
| Kano | hi, when will be karmic based on 2.6.31.6 + released as security update | 13:16 |
| Appiah | apw: i'll test and reply with a result | 13:25 |
| === bjf-afk is now known as bjf | ||
| === BenC1 is now known as BenC | ||
| Appiah | apw: kernel works great | 16:55 |
| apw | Appiah, thanks | 16:55 |
| Appiah | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/418933 updating there | 16:56 |
| ubot3 | Malone bug 418933 in linux "no internet connection (wifi+ethernet doesn't work)" [Low,Confirmed] | 16:56 |
| Appiah | make sure the fix is in the new update! :) | 17:01 |
| Keybuk | apw: do you think anyone would mind a kernel patch to pass "quiet" to init as a command-line argument (along with whatever options the kernel didn't know about) | 17:05 |
| apw | Keybuk, to allow userspace to follow the same levels as the kernel? | 17:06 |
| Keybuk | yes | 17:08 |
| apw | do we not expose the kernel log level in /proc or /sys ? | 17:08 |
| apw | (as an alternative) | 17:08 |
| Keybuk | not in a useful way | 17:08 |
| apw | thats very useless | 17:08 |
| === amitk is now known as amitk-afk | ||
| apw | i thoought you could set it from there | 17:08 |
| Keybuk | upstart is going to do special things for its arguments | 17:08 |
| Keybuk | and it'd be nice if quiet could just be one of them | 17:08 |
| Keybuk | so quiet & splash could be handled *with the same code* | 17:09 |
| Keybuk | rather than having to MOUNT /PROC FIRST! :-/ | 17:09 |
| apw | well i have no fundamental objections | 17:09 |
| apw | and i assume if its just quiet, then its a one line change to push it to inits args? | 17:09 |
| Keybuk | yes | 17:09 |
| apw | so it doesn't sound impossible to carry too | 17:10 |
| Keybuk | ie. make it push any arg it doesn't know about *and quiet* | 17:10 |
| apw | yep | 17:10 |
| apw | we might get it into upstream if it was configurable in kconfig | 17:10 |
| apw | why not spin the basic patch and let us look at it | 17:10 |
| Keybuk | I shall do that | 17:11 |
| apw | Keybuk, cool thanks | 17:13 |
| apw | i can see justifying ... userspace might care if we are loud or not for a patch | 17:13 |
| Keybuk | userspace might want to follow kernel loudness | 17:13 |
| Keybuk | which is exactly what we do :p | 17:14 |
| apw | the other option might be for a generic prefix to say we want something pushed through | 17:14 |
| Keybuk | quiet kernel => quiet userspace | 17:14 |
| Keybuk | load kernel => load userspace | 17:14 |
| Keybuk | prefix wouldn't help upgrades though | 17:14 |
| apw | so like >quiet means keep it regardless | 17:14 |
| Keybuk | we're stuck with using quiet for hysterical raisins | 17:14 |
| apw | yeah there is that | 17:14 |
| apw | i guess they might say ... just use quiet Quiet | 17:14 |
| Keybuk | exactly | 17:15 |
| Keybuk | which is UGLY | 17:15 |
| apw | quiet usquiet would be my choice but makes interacting with users harder | 17:16 |
| === JayFo is now known as JFo | ||
| GargFun1 | high all; we're trying to track down a problem with the Via C3. We have a problem where the sytem will hang after 10h38m with most kernels, but we have found that the problem does NOT happen with the Ubuntu kernel used on the installation media | 18:48 |
| GargFun1 | we are trying to find a kernel that we can build ourselves that works, so we built a kernel using the sources | 18:49 |
| GargFun1 | we got the sources using git clone git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git and we expected the result to be the same as the standard ubuntu kernel | 18:50 |
| GargFun1 | but apparently it's not since those don't work... | 18:50 |
| GargFun1 | any idea how I can build a kernel identical to the one used on the install media? | 18:51 |
| bjf | GarFun1, there are wiki pages that explain how to build our kernels, will get you a link or two | 18:56 |
| GargFun1 | We followed those directions, and don't get a kernel that acts the same as the one on the install media | 18:56 |
| bjf | GarFun1, which directions did you follow? Did you build using debuild? | 18:57 |
| GargFun1 | https://help.ubuntu.com/community/Kernel/Compile was our starting point | 18:58 |
| bjf | GarFun1, which version are you trying to build, latest karmic? | 18:58 |
| GargFun1 | yes | 18:58 |
| GargFun1 | latest karmic | 18:58 |
| GargFun1 | but every version of the kernel from 2.6.18 through .31 seems to have the problem | 18:59 |
| GargFun1 | we've tried quite a few | 18:59 |
| GargFun1 | the ones we've found to work are the ones on the install media | 18:59 |
| bjf | GargFun1, what is "the problem" | 18:59 |
| GargFun1 | after 10h38m of uptime, the system hangs | 18:59 |
| GargFun1 | typing something wakes it up | 19:00 |
| GargFun1 | but our goal is headless systems | 19:00 |
| GargFun1 | it hangs hard, including stopping counting uptime | 19:00 |
| GargFun1 | (so if I wake it up an hour later, it doesn't think any time has passed) | 19:00 |
| bjf | GargFun1, but it's alive enough for you to do an "uptime" ? | 19:01 |
| GargFun1 | what we do is we boot with a serial console and have a simple script that generates uptime; just a sec I'll type it in | 19:03 |
| GargFun1 | #!/usr/bin/perl | 19:03 |
| GargFun1 | $btime = $1 if `cat /proc/stat` =~ /btime (\d+)/; | 19:03 |
| GargFun1 | while(1) { | 19:03 |
| GargFun1 | print "up ". (time-$btime) ." load ". `cat /proc/loadavg`; | 19:03 |
| GargFun1 | sleep 1; | 19:03 |
| GargFun1 | } | 19:03 |
| GargFun1 | so every second it prints the uptime | 19:03 |
| GargFun1 | after 10247s (sometimes slightly more or less) | 19:04 |
| GargFun1 | it stops printing anything | 19:04 |
| GargFun1 | at the same time, it stops responding to pings | 19:04 |
| GargFun1 | same thing happens with nonserial console | 19:04 |
| bjf | GargFun1, ok got it | 19:04 |
| GargFun1 | same thing happens with no modules loaded | 19:04 |
| GargFun1 | (of course, can't test pings then) | 19:04 |
| bjf | GargFun1, you started off with a Karmic release kernel? | 19:05 |
| bjf | GargFun1, have your tried one of our mainline kernel builds? | 19:05 |
| GargFun1 | HorsePunchKid did the actual building | 19:05 |
| HorsePunchKid | (howdy) | 19:05 |
| HorsePunchKid | we haven't tried one of the mainline builds. just the sources from the git repo (for karmic) built with the openwrt toolchain, then a couple of different kernels that i grabbed off the installation ISOs. | 19:06 |
| HorsePunchKid | the next test we're going to run is with one of the pre-built kernels, probably from karmic. | 19:07 |
| bjf | GargFun1, HorsePunchKid what is your hardware platform? | 19:07 |
| HorsePunchKid | it's a Via C3-based motherboard... i can look up more specifics if it would be useful... | 19:08 |
| bjf | HorsePunchKid, no, that's ok | 19:08 |
| bjf | HorsePunchKid, isn't the openwrt toolchain a cross-compiler toolchain | 19:10 |
| HorsePunchKid | yes. | 19:11 |
| bjf | HorsePunchKid, or are you using that to get uClibc | 19:11 |
| HorsePunchKid | that will be another test that i'll run, to just build the kernel outside of the openwrt buildroot. | 19:11 |
| HorsePunchKid | i believe openwrt also builds uClibc, if that's what you're asking. | 19:12 |
| GargFun1 | I guess the question I was trying to track down an answer to is: are the kernels on the install media built differently than other kernels | 19:13 |
| bjf | HorsePunchKid, I'm trying to understand why you are cross compiling since the Via C3 is an x86 clone | 19:13 |
| bjf | GargFun1, they are built using debuild | 19:14 |
| HorsePunchKid | fair question... just because that's how openwrt is set up, and it seemed like the path of least resistance. i figured it would be easier to track openwrt package updates and such if we constrained ourselves to their build system. | 19:14 |
| bjf | HorsePunchKid, that could be but you've wandered quite a ways away from the way we build ubuntu, your using a completely different toolchain | 19:15 |
| HorsePunchKid | true... desperate times call for desperate measures, i suppose :). | 19:16 |
| bjf | HorsePunchKid, does this system currently have a head on it at all and have you tried to just install the regular Karmic release on it? | 19:16 |
| bjf | HorsePunchKid, I understand that's more than what you want to end up with but gives us common ground to debug a kernel issue | 19:17 |
| HorsePunchKid | no, but given that the system works fine with the kernel from the installation CD, i figured installing a complete system probably wouldn't tell us much more. | 19:17 |
| GargFun1 | bjf, my understanding of debuild is that it builds a package from source; that sounds like the answer to how the kernel packages are created | 19:18 |
| HorsePunchKid | though i don't know how close the installation CD's kernel is to what is actually getting installed. hence, the next test will be to try out the kernel from the karmic package. | 19:18 |
| bjf | HorsePunchKid, I'm assuming that kernel is a very different version from Karmic, which version is it? | 19:19 |
| HorsePunchKid | they're both 2.6.31. i don't have the complete string handy. the server CD was something like 2.6.31-14, if i recall correctly. | 19:19 |
| bjf | HorsePunchKid, ok | 19:20 |
| bjf | HorsePunchKid, do you have the sources to that kernel and have you tried to build them and run that kernel? | 19:20 |
| bjf | GargFun1, you can also use debuild to build your tree without producing a source package for example .... | 19:21 |
| HorsePunchKid | no, i don't. not unless the karmic git repo is exactly the same as what got built for the server CD, which i'm getting the impression is not likely. | 19:21 |
| micahg | does 2.6.31 not support software raid? | 19:22 |
| HorsePunchKid | we should have results from the test with the karmic-package kernel in the next 12-16 hours. | 19:22 |
| bjf | GargFun1, debuild -eCROSS_COMPILE=arm-none-linux-gnueabi- --prepend-path=/home/toolchains/arm-2009q1/bin -b -aarmel -us -uc | 19:22 |
| bjf | GargFun1, is how I've cross-compiled for ARM systems | 19:23 |
| GargFun1 | what would -e be for the install CD? | 19:23 |
| bjf | GargFun1, it set's the environment variable "CROSS_COMPILE" | 19:24 |
| ghostcube | smb: ping | 19:32 |
| ghostcube | there was a kernel update | 19:32 |
| ghostcube | and i rebootet after now cam works | 19:33 |
| ghostcube | iam going to reboot noe if the cam works after too | 19:33 |
| GargFun1 | bjf, I understand, but what CROSS_COMPILE string is used for building the install CD's kernels? | 19:34 |
| smb | ghostcube, It should be repeatable whenever you remove the pack file I mentioned, not only on update | 19:34 |
| GargFun1 | I'm just trying to get as close to those kernels as I can =) | 19:34 |
| bjf | GargFun1, no, I was just using that as an example of how I've used debuild to build for an ARM target | 19:35 |
| GargFun1 | ah, I see | 19:35 |
| bjf | GargFun1, you could do something similar for a x86 build | 19:35 |
| bjf | GargFun1, if you wanted to do that | 19:36 |
| GargFun1 | bjf, I guess I'll abandon that tack and we can see what happens with HorsePunchKid's tests using the mainline kernel and the mainline kernel built with the ubuntu toolchain | 19:37 |
| GargFun1 | by mainline, I mean karmic release | 19:38 |
| bjf | GargFun1, HorsePunchKid, sorry if I wasn't able to help | 19:38 |
| GargFun1 | bjf, no it's great to have gotten feedback | 19:38 |
| GargFun1 | we have some new things to try, and we'll try them =) | 19:39 |
| HorsePunchKid | yeah, definitely. thanks for talking it over with us. i'll get those tests set up and report back tomorrow. | 19:39 |
| apw | HorsePunchKid, GargFun1, the kernels on the CD are taken from the archive same as the ones installed when you do an update | 20:00 |
| apw | built in clean chroots by the buildd's | 20:00 |
| HorsePunchKid | okay, that's useful to know. | 20:01 |
| HorsePunchKid | so i'm trying to follow the directions in KernelCompile on the ubuntu help wiki. i think i don't know enough about apt to do what i need to do. i'm on an jaunty system, but i need the karmic linux-image-* sources. how do i obtain those? | 20:04 |
| apw | i always build (when building locally) using the sources in our git trees | 20:06 |
| apw | you can clone those, and then 'fakeroot debian/rules clean' | 20:06 |
| apw | the result then is something which you can compile with debuild -b in an appropriate chroot | 20:06 |
| HorsePunchKid | hm, okay. i've already got clone of the karmic repo which i was building with openwrt. i'll try just building that with debuild instead. | 20:07 |
| apw | you must clean it first, else it won't have all the control files you need | 20:07 |
| HorsePunchKid | *nod* will do. | 20:08 |
| HorsePunchKid | i'm not so familiar with git... how can i get a list of tags or releases, or how can i peg my clone at the latest release, rather than the (presumably not as stable) head? | 20:10 |
| ghostcube | smb: ureadhead crashed at boot | 20:24 |
| ghostcube | but the cam still works here | 20:24 |
| ghostcube | woha yeah i can see my damn ugly face now again | 20:24 |
| ghostcube | :D | 20:24 |
| ghostcube | i will test it a while and look if it somehow stops after i do anything special | 20:25 |
| smb | ghostcube, ureadahead supposed should not crash. But that might delay things just enough. So I'd expect it to be flakey | 20:26 |
| micahg | does 2.6.31 not support software raid? | 20:36 |
| HorsePunchKid | apw, or anyone else, could you give me an idea of how to use debuild to build the kernel package, now that i've got the karmic kernel sources cloned? it's not mentioned in the KernelCompile wiki page, and the -b flag isn't mentioned in the man page or help. | 20:44 |
| smb | In the top level dir | 20:46 |
| smb | fakeroot debian/rules clean | 20:47 |
| smb | debuild -b -uc -us | 20:47 |
| HorsePunchKid | does -b just indicate to only build binary packages or something like that? | 20:47 |
| smb | yep | 20:47 |
| HorsePunchKid | cool, thanks much. | 20:47 |
| smb | -uc -us does not sign them | 20:47 |
| micahg | smb: do you know anything about software raid and 2.66.3 | 20:48 |
| micahg | 2.6.31? | 20:48 |
| smb | micahg, I have no md running on 2.6.31 atm just a dm strip, so I cannot say much about it specifically. It should be supported | 20:49 |
| micahg | thanks, I'll check back with the -server team then | 20:50 |
| === maco_ is now known as maco | ||
| Darxus | CD P | 22:31 |
| === BenC2 is now known as BenC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!