| mirsal | hello | 00:43 |
|---|---|---|
| lool | apw: Heya; on that ABI check issue with versatile, ISTR that you sometimes simply disable the ABI check and then download the ABI from the archive; is this what you would do in this case, or will you try updating it before upload? | 10:36 |
| lool | apw: let me know if I can help removing this (IMHO last) blocker before upload | 10:36 |
| apw | there wasn't an issue with the abi in my build, it was failing to build full stop | 10:37 |
| apw | i am rebuilding it now to confirm i was not going mad | 10:37 |
| apw | three scsi drivers i think it was, but i don't have the logs, hense the rebuild | 10:38 |
| apw | CC [M] drivers/scsi/advansys.o | 10:41 |
| apw | /home/apw/build/lucid/ubuntu-lucid/drivers/scsi/advansys.c:72: warning: #warning this driver is still not properly converted to the DMA API | 10:41 |
| apw | LD [M] drivers/net/e1000e/e1000e.o | 10:41 |
| apw | /home/apw/build/lucid/ubuntu-lucid/drivers/scsi/advansys.c: In function 'advansys_get_sense_buffer_dma': | 10:41 |
| apw | /home/apw/build/lucid/ubuntu-lucid/drivers/scsi/advansys.c:8352: error: implicit declaration of function 'dma_cache_sync' | 10:41 |
| apw | CC [M] drivers/net/hamradio/mkiss.o | 10:41 |
| apw | make[4]: *** [drivers/scsi/advansys.o] Error 1 | 10:42 |
| apw | make[3]: *** [drivers/scsi] Error 2 | 10:42 |
| apw | make[3]: *** Waiting for unfinished jobs.... | 10:42 |
| apw | lool there is one of them | 10:42 |
| apw | arch/arm/include/asm/dma-mapping.h: * Dummy noncoherent implementation. We don't provide a dma_cache_sync | 10:42 |
| apw | and arm claims to not support it, so ... lool how did you build it? | 10:43 |
| lool | apw: See my latest merge request | 10:48 |
| lool | apw: I fixed this in my second pull request | 10:48 |
| apw | so you didn't test the first one? | 10:48 |
| lool | apw: I apologized in the email because "make modules" seemed to succeed, but actually failed earlier in the log | 10:48 |
| apw | ok | 10:48 |
| lool | apw: I did make zImage (works) and make modules wihch I thought worked, but failed somewhere in the middle of the log | 10:48 |
| apw | ok | 10:49 |
| lool | apw: I'm used to getting "make error blahblah" at the end, but the kernel build process didn't print this which is why I missed the error | 10:49 |
| lool | apw: Sorry about that | 10:49 |
| lool | apw: I actually tested a .deb build for my second pull request, and it failed in the abi check stuff | 10:49 |
| lool | Well I included the command I ran in the email | 10:50 |
| apw | thats fine, you probabally would expect that | 10:50 |
| apw | you've changes things radically | 10:50 |
| lool | Sorry? | 10:50 |
| lool | Ah my radical changes cause the abi change | 10:51 |
| apw | you've changed the configuration radically, if that didn't trigger an abi bump i'd be worried | 10:51 |
| lool | So my question above is how you'd like to handle it, either by building and updating ABI before upload or whether you'll disable the check, upload and then download the ABI from the archive | 10:51 |
| lool | And whether you want a patch for that | 10:52 |
| apw | i'll probabally do none of the above, and integrate .7 which will naturally trigger a bump and upload that | 10:52 |
| apw | once its building | 10:52 |
| lool | apw: Ok; I'm around if you have any question WRT to the latest pull request which should fix the first one | 10:53 |
| apw | so is that lot on top of your previous push? | 10:53 |
| lool | apw: No | 10:54 |
| lool | apw: it's really readable | 10:54 |
| lool | There were 3/4 distinct issues with modules, and then I also added patches to enable the ubuntu/ tree | 10:54 |
| apw | it contains no information about what its based on that i can see and if its not on the previous push what is it on top of | 10:55 |
| apw | if you use git request-pull it would tell me for free | 10:55 |
| lool | apw: I didn't know about git request-pull | 10:56 |
| lool | apw: it should be based on master after you merged my patches, but I'll recheck | 10:56 |
| apw | ahh, yeah that is how most people generate those emails | 10:56 |
| apw | ok, so on top of your previous stuff then | 10:56 |
| lool | It's on top of 7784853ab4d2cb97b636554909b9f08b9ca2231a | 10:56 |
| lool | Which is the merged UBUNTU: [Config] Large update to armel/versatile | 10:57 |
| apw | ok got it | 10:57 |
| apw | i'll juggle my tips to make it work out thanks | 10:57 |
| apw | lool can i assume you've boot tested the result of this build, or do you want me to make some test .deb's | 10:59 |
| lool | apw: I boot tested the zImages | 11:02 |
| lool | apw: As I note in my email, the only thing which was needed to have useful kernels was the RTC clock fix | 11:02 |
| lool | The only two issues I'm aware of with the kernel are kexec hanging (but that's a while topic of its own) and virtio hanging if you try to force building them in, but that's not expected to be supported anyway | 11:04 |
| lool | http://paste.ubuntu.com/371586/ that's my TODO of stuff I worked on since the first pull | 11:04 |
| apw | ok | 11:04 |
| lool | NB: I don't actually have versatile hardware, it might be that the kernel doesn't work on versatile hardware, I only test in qemu -- that's probably obvious but just in case :-) | 11:06 |
| lool | apw: How do you mention a branch with git request-pull? | 11:08 |
| apw | you push it up, and while on it _locally_ you make the request | 11:09 |
| apw | that then confirms that the local branch is exposed under some name and reports that one | 11:09 |
| lool | Ok; it's interactive then, thanks | 11:09 |
| lool | I was surprized that the command-line flags and man page didn't mention that | 11:10 |
| apw | git request-pull <start> <url> [<end>] | 11:10 |
| apw | its 'end' there, note though that its a _local_ sha1 | 11:10 |
| lool | Yeah, there's no branch name there | 11:10 |
| apw | its an ending commit, the key is that some branch name on the remote points at it | 11:11 |
| apw | you can in theory do | 11:11 |
| apw | git push zinc <random sha1>:BRANCH | 11:11 |
| apw | and git request-pull <random sha1>~N <url> <random sha1> | 11:11 |
| apw | and expose N patches from that sha1 | 11:11 |
| lool | Ok; I'm used to manipulating branches and mentionning branches to other people, not SHAs, but SHAs are probably more robust | 11:11 |
| apw | well thats the thing, if you just use branches it works | 11:12 |
| apw | git push zinc BRANCH | 11:12 |
| apw | git request-pull BRANCH~N <url> BRANCH | 11:12 |
| apw | stylee | 11:12 |
| apw | its just that the branch in the second one doesn't have to match what you pushed, and what its called UP THERE is what it gets named in the output | 11:13 |
| apw | git push zinb FOO:BAR; git request pull FOO~4 <url> FOO | 11:13 |
| apw | will mention BAR in the email, as thats what i a remote person can see | 11:13 |
| lool | apw: Ok makes sense, thanks | 11:19 |
| lool | apw: The wiki mentionned "SHAs" but it's really any revspec so a branch name will do and it's not as inconvenient as it seemed on my first reading | 11:20 |
| apw | yeah | 11:21 |
| apw | generally they write commit-ish, which once you know it means 'anything' is fine | 11:22 |
| apw | i think the most confusing part is the disconnect between whether they are local or remote | 11:22 |
| apw | rtg whats the best way to review the currently built-in subsystems, we wanted to review whether them being builtin really helps us any for lucid. perhaps i shoudl prepare a list of what we builtin and send that to kernel-team for discussion? | 14:28 |
| tgardner | that seems like a reasonable approach. I know BenC was annoyed by some of the PATA stuff being built-in. | 14:32 |
| mirsal | ogasawara_, ayt ? | 14:43 |
| ghostcube | hmm ureadhead is crashng on my karmic sometimes | 14:44 |
| ghostcube | how can i get the problem inside any log ? | 14:44 |
| ghostcube | i see this on bootup deamon crashed for .... | 14:45 |
| mirsal | ghostcube, https://wiki.ubuntu.com/KernelTeam/CrashdumpRecipe | 14:46 |
| mirsal | ghostcube, I don't know if this is what you are looking for | 14:46 |
| ghostcube | mirsal: thx, but maybe this isnt so well for what i wanna do The LKCD utility is not designed to gather helpful information in the case of a hardware caused panic or a segment violation | 14:47 |
| ghostcube | i think its caused by any hardware | 14:47 |
| ghostcube | but i willt try :) | 14:47 |
| mirsal | ok :/ | 14:48 |
| CShadowRun | does anyone know how to revert an update? my friend just did an update on a fresh install of karmic and is now getting "Kernel Panic - not syncing: for safety" | 15:52 |
| CShadowRun | or does anyone have any suggestions on how to debug this problem | 15:53 |
| apw | CShadowRun, they should have older kernels on their machine, hold left shift to get the boot menu and select an older one | 15:53 |
| apw | _if_ its the kernel which is broken | 15:53 |
| CShadowRun | yea, that's what I thought, but tried it but the problem persisted | 15:54 |
| apw | any idea what the panic itself is? | 15:54 |
| apw | as thats the last line of it iirc | 15:54 |
| CShadowRun | nope, it just says that | 15:55 |
| CShadowRun | we saw it shortly after loading gdm and then switching to a tty | 15:55 |
| CShadowRun | is there any log file we can look at that might tell us? | 15:55 |
| apw | if gdm has come up it has booted most of the way | 15:56 |
| CShadowRun | yea, he says he gets to login and mull around for a couple of minutes then it dies | 15:56 |
| apw | i am pretty sure there is normally more than one line associated with that Kernel Panic line, either before or after it | 15:56 |
| smb | Then maybe try to run it nomodeset? | 15:56 |
| apw | if the machine is mostly up when it occurs there may be a full log in the /var/log/syslog or /var/log/messages | 15:57 |
| smb | Also is it crashing just sitting on gdm or when you try to log in? | 15:58 |
| apw | and can you login over the network when it crashes | 15:58 |
| apw | you may be able to see the dump occuring on a pre-logged in remote connection | 15:58 |
| CShadowRun | apw yea, definitely that's the only line | 15:59 |
| CShadowRun | smb: we'll try nomodeset now | 15:59 |
| CShadowRun | smb it crashes after a few minutes of being up no matter what, whether we login, sit at gdm, or use a tty | 15:59 |
| CShadowRun | if nomodeset doesn't work we'll try and install openssh-server but it may well kernel panic during that | 16:00 |
| smb | CShadowRun, Hm ok, so maybe you might be able to switch to vt1 and do a tail of /var/log/syslog... | 16:00 |
| CShadowRun | smb the tty freezes aswell when the panic occurs | 16:01 |
| apw | so it may be worth loggin in on VT1 and tail -f /var/log/messages ... also perhaps while :; do; dmesg; sleep 1; done on VT1 | 16:01 |
| smb | CShadowRun, The question was just whether you can quickly enough change to that and get log in before the crash. Another thing might be to narrow thing: to use "text" as kernel argument and avoid starting gdm at all | 16:02 |
| CShadowRun | well we can do cat /var/log/syslog... before the crash | 16:04 |
| CShadowRun | but surely that's useless? | 16:04 |
| apw | no what we are saying is sometimes you cannot type any more | 16:05 |
| apw | but output and applications which are already in cache can continue | 16:05 |
| CShadowRun | oh | 16:05 |
| CShadowRun | i see | 16:05 |
| apw | so a script which output that file before the crash _may_ beable to do it later | 16:05 |
| CShadowRun | we'll try to run while :; do; dmesg; sleep 1; then | 16:05 |
| apw | yeha something like that _may_ be able to output more | 16:06 |
| apw | you could also make sure loglevlel is high, loglevel=8 on the grub line | 16:06 |
| CShadowRun | syntax error near unexpected token ';' | 16:06 |
| apw | no ; after the do | 16:06 |
| CShadowRun | so we'll try booting with loglevel=8 and text this time? | 16:06 |
| smb | booting with debug on the command line also increases the amount of messages | 16:07 |
| smb | Meaning "debug" as a argument to the kernel command line | 16:07 |
| CShadowRun | ok so ro text loglevel=8 debug quiet ? | 16:07 |
| CShadowRun | we are just editing the line in grub | 16:08 |
| apw | drop quiet | 16:08 |
| smb | yeah | 16:08 |
| CShadowRun | ok | 16:08 |
| CShadowRun | I dropped splash too | 16:08 |
| CShadowRun | we booted with that, still got the same single kernel panic line | 16:10 |
| apw | and how long after boot do you get it, | 16:11 |
| apw | do you get a login prompt on VT-1 | 16:11 |
| CShadowRun | he says it freezes after about 10-15 seconds | 16:12 |
| CShadowRun | and yea we get a login prompt | 16:12 |
| smb | From the sound of it (as the original kernel now dies as well) it feels like either something not related to the kernel package or coincdental dying hw | 16:12 |
| CShadowRun | while :; do dmesg; sleep 1; then -> bash: syntax error near unexpected token `then' | 16:12 |
| CShadowRun | yea, maybe something else in the update is causing it | 16:13 |
| CShadowRun | got no idea what though. | 16:13 |
| CShadowRun | aha made the bash work :) | 16:15 |
| smb | True. Still the "panic not syncing" sounds like kernel. But normally that goes with a backtrace of th failing code... | 16:15 |
| CShadowRun | gonna try to type that fast and hope for more information | 16:15 |
| CShadowRun | apw "while :; do dmesg; sleep 1; done" stops when the segfault occurs, nothing in the output about a backtrace | 16:21 |
| apw | and you booted thre with the loglevel=8 ? | 16:21 |
| CShadowRun | not this time sorry, we'll boot with that now | 16:21 |
| CShadowRun | weird, the panic isn't happening this time | 16:30 |
| CShadowRun | also, the number before the line in dmesg is the uptime right? | 16:30 |
| CShadowRun | apparently every time it panics, it's always 42 | 16:30 |
| tgardner | apw, plymouth ? I had to remove it from my nVidia laptop | 16:32 |
| apw | tgardner, yeah i think we are waiting for that to be resolved still | 16:33 |
| tgardner | apw, i meant wrt to CShadowRun's issue | 16:33 |
| apw | CShadowRun, karmic or lucid in your case? | 16:33 |
| CShadowRun | karmic | 16:33 |
| tgardner | nm | 16:34 |
| apw | ok so not plymout | 16:34 |
| apw | CShadowRun, you said 'when the segfault occurs' what made you chose those words | 16:34 |
| CShadowRun | brain fart, lol | 16:35 |
| CShadowRun | it doesn't say anything about segfault | 16:35 |
| CShadowRun | apparently it's just randomly stopped freezing | 16:35 |
| CShadowRun | ...weird, maybe a hardware issue? | 16:35 |
| CShadowRun | it's very old hardware so that wouldn't suprise me | 16:36 |
| apw | its a bit scarey | 16:36 |
| tgardner | CShadowRun, how old? has it run stable on any other release? | 16:37 |
| apw | does this have an adaptec scsi controller | 16:37 |
| CShadowRun | tgardner: uhh, amd 1600mhz processor, 256mb ram, 20gb hard drive sort of old. | 16:37 |
| CShadowRun | and no, he's just got it as a chuckout, it's been sitting in a cupboard for a while | 16:37 |
| tgardner | CShadowRun, did you install X ? perhaps you should try just the server to begin with. | 16:38 |
| apw | CShadowRun, does this have an adaptec scsi controller ?? | 16:38 |
| smb | CShadowRun, Just trying to get down what could print that "for safety"... Is there an adaptec SCSI controller involved? | 16:38 |
| CShadowRun | tgardner: well yea, X ships with karmic, it's just a normal karmic installation | 16:38 |
| CShadowRun | hmm, how would I find out? | 16:39 |
| apw | well if its up | 16:39 |
| apw | then lspci | 16:39 |
| smb | or in the worst case open the thing... | 16:39 |
| tgardner | or open the cabinet and look? something that old will likely have a discrete adapter | 16:39 |
| tgardner | if not, the BIOS will display some info | 16:40 |
| smb | Right, those adaptec bioses had there own message whn booting | 16:40 |
| apw | ok yeah if the message was "Kernel panic - not syncing: for safety" | 16:41 |
| apw | CShadowRun, that exact form, then its a panic for "for safety" | 16:41 |
| apw | and those seem to be only in adaptec code | 16:41 |
| apw | hrm ... recipent overload? | 16:43 |
| tgardner | apw, its probably a HW issue, which is why it was in the chuckout bin to start with | 16:44 |
| CShadowRun | nope, doesn't look like it has an adaptec in it | 16:44 |
| CShadowRun | lspci | grep -i adaptec returns nothing | 16:44 |
| apw | lsmod | grep aic ? | 16:45 |
| CShadowRun | apw nope, nothing | 16:46 |
| apw | well that interesting | 16:49 |
| apw | you have no adaptec h/w and are getting mesages which only exist in adaptec drivers | 16:49 |
| apw | you are a magician | 16:49 |
| CShadowRun | apw: I have a reputation in ubuntu-uk of breaking...everything, somehow magically | 16:50 |
| CShadowRun | so, that pretty much fits my everyday life :P | 16:50 |
| apw | hrm | 16:51 |
| apw | so push your lspci to a pastebin somewhere perhaps | 16:52 |
| apw | and we can stare at it confusdly | 16:52 |
| CShadowRun | apw: http://pastebin.com/f27ed6049 | 16:54 |
| CShadowRun | hmm, check out that unidentified SCSI storage controller. | 16:54 |
| CShadowRun | maybe that's an adaptec device in disguise... | 16:54 |
| apw | yeah could be, 9004 5078 would be one | 16:58 |
| apw | CShadowRun, can we have your dmesg please | 16:58 |
| CShadowRun | apw: http://pastebin.com/f8205eba | 16:59 |
| CShadowRun | apw this is from a suscessful boot obviously | 16:59 |
| CShadowRun | with no crashes as of yet | 16:59 |
| tgardner | pata_via ? | 17:00 |
| apw | [ 0.838079] pata_via 0000:00:11.1: version 0.3.4 | 17:00 |
| apw | ok ... i am suspicious that you have h/w issues | 17:01 |
| CShadowRun | I'm suspicious that it's a hardware issue too now since it's intermittant | 17:01 |
| tgardner | apw, perhaps, but DMA issues might be intermittent. | 17:01 |
| tgardner | CShadowRun, can you run the mem test for awhile? | 17:02 |
| apw | as the adapetek driver looks for 9004 and you have 9204 which is via when it works | 17:02 |
| CShadowRun | tgardner: yup | 17:03 |
| apw | it may be time to push all the cards in | 17:03 |
| CShadowRun | tgardner: we ran that yesterday and it passed | 17:03 |
| CShadowRun | Oh well, seems to be working for now, I guess I'll chalk it up to hardware issue | 17:05 |
| tgardner | CShadowRun, get the server edition and install that. it cuts out X and other GUI cruft | 17:10 |
| CShadowRun | he wants it for office use though | 17:11 |
| CShadowRun | so that kinda defeats the objective :P | 17:11 |
| === johanbr_ is now known as johanbr | ||
| tgardner | CShadowRun, it will at least help isolate your issue. you can always install ubuntu-desktop after the fact | 17:16 |
| CShadowRun | I guess | 17:17 |
| CShadowRun | if it happens again we'll give it a shot | 17:17 |
| mirsal | apw, ping | 19:12 |
| AlanBell | ping bjf - want to talk about mootbot and moinmoin? | 20:24 |
| JFo | apw or smb, I think we discussed at one point, but how do we set number of CPU's for the kernel? | 20:24 |
| tgardner | JFo, you mean on boot? | 20:25 |
| JFo | is it just a runtime option or can we specify in a config somewhere | 20:25 |
| JFo | tgardner, maybe :) | 20:25 |
| smb | JFo, maxcpus=x | 20:25 |
| smb | JFo, on boot | 20:25 |
| JFo | cool | 20:25 |
| tgardner | JFo, there is also a maximum number supported, 64 on Amd64 | 20:25 |
| BugeyeD | what's the upper limit set to when building the kernel? | 20:26 |
| JFo | I've been told that suse sets them way high. 128 for x86, 4096(!) for itanium | 20:26 |
| BugeyeD | sorry, too late | 20:26 |
| === chasedouglas is now known as cnd | ||
| smb | JFo, hot removing them should work in theory but yields not to good results | 20:26 |
| JFo | I see | 20:26 |
| JFo | so we could, theoretically set them to some huge number? | 20:26 |
| JFo | say 200 if we had them? | 20:26 |
| JFo | BugeyeD, no problem | 20:27 |
| BugeyeD | is 64 the same for workstation and server kernels? | 20:27 |
| smb | JFo, I believe that requires more memory for the per-cpu arrays. Not sure how much the penalty is | 20:27 |
| JFo | ah, ok | 20:27 |
| JFo | but it is doable. do we have upper limits on the numbers smb? | 20:28 |
| smb | JFo, I would have to use the source which I am too lazy right now... :/ | 20:29 |
| JFo | BugeyeD, you mean x64 CPU numbers yes? | 20:29 |
| BugeyeD | yes | 20:29 |
| JFo | smb, I understand :) | 20:29 |
| JFo | BugeyeD, I think they should be the same then, based on what tgardner says | 20:29 |
| JFo | so 64 it looks like | 20:30 |
| JFo | as a safe bet | 20:30 |
| BugeyeD | works for me. not sure why i'm seeing only 8, unless it's due to x86 arch | 20:30 |
| tgardner | debian.master/config/i386/config.common.i386:CONFIG_NR_CPUS=8 | 20:30 |
| tgardner | debian.master/config/amd64/config.common.amd64:CONFIG_NR_CPUS=64 | 20:30 |
| JFo | I'm just guessing though :) | 20:30 |
| JFo | ah hah, so it is | 20:30 |
| JFo | thanks tgardner | 20:31 |
| BugeyeD | thx guys | 20:31 |
| JFo | BugeyeD, :) | 20:31 |
| JFo | ask in here anytime | 20:31 |
| JFo | there are people all over the world so the chances are good that you could get a relatively quick answer. | 20:31 |
| bjf | AlanBell, sure | 20:32 |
| amitk | dinh_fsl: does the tree clone now? | 21:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!