| Keybuk | RAOF: I forgot to ask, where is the hallowed lbm-nouveau PPA? | 00:38 |
|---|---|---|
| RAOF | ppa:xorg-edgers/nouveau. | 00:47 |
| RAOF | Keybuk: If you want to try with bonus OpenGL, ppa:xorg-edgers | 00:47 |
| Keybuk | nah | 00:48 |
| Keybuk | this is just about "does it work with a more recent nouveau?" | 00:49 |
| Keybuk | probably not, but worth trying at least once | 00:49 |
| RAOF | Yeah. | 00:50 |
| RAOF | The 3D works surprisingly well, actually, no matter how much upstream shouts “unsupported!”. | 00:52 |
| RAOF | I haven't noticed any commits that would be likely to fix things for you, though, and I keep an eye on the nouveau commits. | 00:52 |
| Keybuk | I doubt there are any | 00:53 |
| Keybuk | since darktama is asking for mmiotrace output of nvidia-glx on this board | 00:53 |
| RAOF | Ah. | 00:53 |
| RAOF | Man, I didn't think there was much mmiotracing left to be done, based on how infrequently it's asked for in bug reports. Otherwise I would have prioritised making a mmiotrace kernel available. | 00:54 |
| Sarvatt | building a new lbm-nouveau now if you can copy it to xorg-edgers/nouveau when its done RAOF | 00:55 |
| RAOF | Sarvatt: Ta. | 00:55 |
| Sarvatt | ddx will have to wait for tomorrow, it has a significant amount of changes from your git branch and I have to do it manually | 00:59 |
| Sarvatt | so maybe dont copy it yet, not sure if that nv50: fix texturing from >=4GiB mark requires the accompanying kernel commit | 01:00 |
| Sarvatt | nevermind, will just add it as a patch :) | 01:03 |
| RAOF | Sarvatt: It can wait for tomorrow :) | 01:13 |
| Sarvatt | already uploaded both, now if they work is another question because I dont have a nouveau machine atm and it required extensive changes :) | 01:29 |
| RAOF | This sounds like a job for Ein! | 01:31 |
| BenC | [39022.116166] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung | 01:58 |
| BenC | [39022.116186] render error detected, EIR: 0x00000000 | 01:58 |
| * BenC really wishes this would go away | 01:58 | |
| RAOF | Is that the i915.powersave dies-sometime-after-resume bug? | 01:59 |
| BenC | No, I have i915.powersave=0 and this still happens | 02:02 |
| BenC | this is i915 dies after susped/resume | 02:03 |
| BenC | Xorg crashes and gives me the "low res mode" warning screen, and if I just keep it in low-res, it works fine until I reboot | 02:03 |
| BenC | compiz is enabled | 02:04 |
| Sarvatt | yeah RAOF thats not the needs powersave=0, that one hangs with a solid color a few minutes after resume, another suspend/resume cycle fixes it for awhile again, and it doesn't actually hang the GPU it just gets stuck busy doing framebuffer compression. BenC: Can you file a bug and subscribe Sarvatt to it so I can check out your logs tomorrow? Sounds like an issue that needs to be forwarded upstream | 03:34 |
| Sarvatt | BenC: file it after the issue occurs and you're in failsafe so the right info is in the logs preferably :) | 03:35 |
| Sarvatt | BenC: also it would be useful if you could try with this ppa - https://launchpad.net/~xorg-edgers/+archive/ppa to see if the problem still exists with the newer libdrm/intel | 03:39 |
| BenC | Sarvatt: done | 04:09 |
| BenC | Sarvatt: I'll try the ppa tomorrow | 04:11 |
| Sarvatt | thanks BenC, looks like it was duped to another bug that I assumed was just an apport script screwup too | 04:22 |
| apw | Keybuk, so is the plymouth in the archive wonderful? is it safe to update? | 10:00 |
| amitk | apw: I've got config changes for ti-omap that should be uploaded ASAP | 10:22 |
| amitk | do I need to open a bug? | 10:22 |
| apw | amitk, ok get them onto our list, offically we would need a bug ... | 10:22 |
| apw | one for the lot would be sufficient i suspect | 10:23 |
| apw | enabled new cpu or whatver the broad aims are | 10:23 |
| amitk | apw: ack | 10:23 |
| amitk | apw: I don't see your config changes having any bug attached to them | 10:37 |
| apw | dammit ... amitk saw me | 10:37 |
| apw | smb assume you don't have a bug for that SG V4 thing | 10:38 |
| amitk | apw: I can remove my buglinks too ;) | 10:39 |
| smb | apw, No, there have been a few others, but I assumed somewhat until release we don't need bugs for everything. Just acks | 10:39 |
| apw | hrm | 10:39 |
| smb | Or have I been telling otherwise before | 10:39 |
| apw | smb, they are your rules, just tell me what they are | 10:39 |
| * smb needs to read his own rules | 10:40 | |
| * apw waits for clarification | 10:41 | |
| amitk | smb: Just FYI, I'm going to have several patches and patchsets for omap till release while we beat it into shape. So having a bug attached for each might not be practical | 10:41 |
| apw | i care not about hoop jumping as long as know which hoops i am meant to jump | 10:41 |
| smb | apw could go and see whether he finds something written down | 10:41 |
| * apw is sure smb will tell him if he just waits ... la la la | 10:41 | |
| apw | amitk, well you could use the same one over and over :) | 10:41 |
| * smb slaps apw | 10:42 | |
| * apw can't hear dyou | 10:42 | |
| amitk | hehehe | 10:44 |
| smb | I'd would say we should allow for exceptions as there might be things just tuned. Execept if the committer is apw. In that case we need full SRU justification with two carbon copies which need to mature for 3years at least. | 10:45 |
| amitk | smb: sounds like a plan | 10:45 |
| * apw burns the new SRU policy for heat | 10:45 | |
| apw | ok amitk so i missinformed you ... osunds like you don't need a bug ... | 10:46 |
| smb | apw, You wanted a new one | 10:46 |
| * amitk re-amends his commits | 10:46 | |
| smb | Well lets say, we should prefer having a bug, but there might be some changes that are done without | 10:47 |
| apw | yep ... i am going to assume that the review will say 'oi where is the bug' and if it doesn't then we can apply it for now | 10:47 |
| * amitk halts after 2 re-amends to wait for smb's final say | 10:47 | |
| smb | I probably should do one for the stable update, just that its referenced in a better way | 10:47 |
| smb | amitk, You have a bug going with it? | 10:48 |
| amitk | smb: AFAICT, we never had bugs until release | 10:48 |
| amitk | smb: yes, bug 540146 | 10:48 |
| ubot3 | Malone bug 540146 in linux-ti-omap "Enable omap kernel to boot on beagleboard" [Undecided,New] https://launchpad.net/bugs/540146 | 10:48 |
| smb | amitk, So just put it in | 10:48 |
| amitk | smb: two acks would do just fine | 10:49 |
| smb | Why leave a reference out if there is one | 10:49 |
| amitk | ok | 10:49 |
| amitk | apw: pull request for you on the mailing list | 11:05 |
| apw | amitk, thanks | 11:05 |
| === jussi01 is now known as o1 | ||
| apw | cking, how do identify which disk driver is handling my disk if they are all builtin | 11:15 |
| === o1 is now known as jussi01 | ||
| smb | apw, you might see which one is handling your adapter in lspci -vvvnn | 11:17 |
| apw | smb, of course ... thanks, and the fact that ata_piix appears in my bootcharts should have been a clue | 11:18 |
| amitk | apw: lshal | grep driver ? | 11:18 |
| apw | amitk, ENOHAL | 11:19 |
| * amitk keeps forgetting! | 11:19 | |
| cking | me thinks.. | 11:22 |
| cking | apw, will perf show you anything useful? | 11:24 |
| apw | cking, ahh smb sorted it for me, lspci has the driver even if its builtin | 11:24 |
| cking | yeah, of course, that's the most straight forward way. doh | 11:26 |
| apw | JFo, about?| | 12:22 |
| * apw waits for that to appear on smackeral so i can find it next time | 12:27 | |
| smb | apw, The stable updates change one symbol because a driver selects a different submodule. What would be your favorite method of handling this: a) abi bump or b) ignore file. I tend to a) to have a fallback kernel | 12:42 |
| apw | yeah i am all for more bumping, if its a bump bump it | 12:44 |
| apw | and for huge stable updates, bump it anyway is my feeling | 12:45 |
| smb | apw, yessir. agree | 12:45 |
| apw | amitk, in this update you pull out CRAMFS to a module, is it bad if it remains in? i thought we only recently made it builtin on arm cause it was used for older initramfs | 13:06 |
| amitk | apw: in that case it can stay builtin. Which older initramfs are we talking about? | 13:07 |
| * apw is fuzzy on it, just has it in mind, if you have boot tested it i am happy anyhow | 13:08 | |
| apw | but we may need to revisit it | 13:08 |
| amitk | apw: I've only boot tested w/o initramfs | 13:08 |
| * apw asks on #u-arm | 13:09 | |
| apw | ok seeems it was a herring rouge | 13:10 |
| apw | so igore me | 13:10 |
| apw | amitk, in our ti-omap branch you have selected out of tree source build, do you know we need that? suspect we don't as its mostly virgin | 13:23 |
| amitk | apw: I have? | 13:25 |
| apw | amitk, heh in that case i'll test it without | 13:25 |
| Q-FUNK | for some reason, 'dpkg-reconfigure linux-image-foo-bar' no longer re-generates the initrd.img or run the bootloader scripts. I seem to recall some update-initramfs option causing this to happen but not how to restore it. anyone? | 13:49 |
| Q-FUNK | I first thought thta it was the -t option, but apparently not | 13:56 |
| smb | Q-FUNK, I don't use dpkg-reconfigure for that. update-initramfs -u seems simpler for the usual case I need it | 13:58 |
| Q-FUNK | smb: that works, but it makes the package non-updatable, should an updated kernel ever be pushed. | 13:59 |
| Keybuk | apw: the plymouth in the archive is the best plymouth yet | 14:00 |
| smb | Q-FUNK, I am a bit doubting that. Its never part of the package, so why should it affect the package | 14:01 |
| smb | Keybuk, So this one works with nouveau? | 14:02 |
| Keybuk | smb: only if nouveau works | 14:02 |
| Keybuk | but should do, yes | 14:02 |
| * Keybuk has a patch from darktama for his LVDS issue | 14:02 | |
| * smb goes booting up his testbox | 14:02 | |
| apw | Q-FUNK, isn't that now done via dpkg triggers? | 14:04 |
| Q-FUNK | apw: yes, when running 'dpkg-reconfigure linux-image-foo-bar' but it no longer works after somethin else touched the initrd.img | 14:06 |
| apw | now i am confused, you mean that the reconfigure does update t | 14:06 |
| apw | the initramfs as long as its not been changed? | 14:06 |
| apw | that sounds like its doing what you want, except it got changed somewhen in the past | 14:07 |
| Q-FUNK | as long as initrd.img hasn't been changed, dpkg-reconfigure works. the day it has, it no longer does. | 14:08 |
| apw | ok that sounds like what i would want it to do | 14:08 |
| Q-FUNK | sure | 14:08 |
| apw | how did it get changed otherwise? | 14:09 |
| Q-FUNK | but how do you return control to dpkg-reconfigure after something else modified it by running update-initramfs outside the dpkg realm? | 14:09 |
| apw | perhaps force reinstalling the image might do it | 14:09 |
| smb | apw, huh? If you ran update-initramfs, you still want a kernel update regenerate it, wouldn't you? | 14:10 |
| * apw is looking for the trigger handling right now | 14:10 | |
| apw | smb, no if i did something outside the correct way, then i'd expect it to be left alone | 14:10 |
| apw | (assuming dpkg-reconf is the right way, and i suspect it is) | 14:10 |
| smb | apw, I would disagree with you there | 14:10 |
| apw | dpkg generally does not change files you changed outside its control | 14:11 |
| apw | it generally leaves them be, or throws a merge request to you | 14:11 |
| apw | it cirtianly doesn't replace them without comment | 14:11 |
| apw | why should the initramfs be different | 14:11 |
| Q-FUNK | the correct debuntu way would be to make whatever modification in /etc/initramfs-tools/* then dpkg-reconfigure the kenrel. | 14:11 |
| smb | but initrd is a build thing, | 14:12 |
| apw | right ... and that works as i hear it | 14:12 |
| apw | the only issue is something outside touched it, and we don't know how to day | 14:12 |
| apw | say "look take it back and look after it" | 14:12 |
| smb | Its always just generated. Whether you use update-initramfs or reconfigure a package | 14:13 |
| apw | yes, but dpkg cannot know that, all it knows is it changed | 14:13 |
| apw | if i cpio it out munch it and put it back, it looks the same to dpkg ... changed without its knowledge | 14:14 |
| apw | and therefore something to avoid stamping on i'd say | 14:14 |
| apw | bah how _do_ triggers work anyhow | 14:15 |
| smb | update-initramfs -u | 14:17 |
| smb | update-initramfs: Generating /boot/initrd.img-2.6.32-16-generic | 14:17 |
| apw | Q-FUNK, can you pastebin the output of doing the reconfigure please ... all the way to the end | 14:17 |
| smb | apt-get --reinstall linux-image-2.6.32-16-generic | 14:17 |
| smb | Unpacking replacement linux-image-2.6.32-16-generic ... | 14:17 |
| smb | Setting up linux-image-2.6.32-16-generic (2.6.32-16.25) ... | 14:17 |
| smb | Running depmod. | 14:17 |
| smb | update-initramfs: Generating /boot/initrd.img-2.6.32-16-generic | 14:17 |
| apw | smb, yeah i can't see any checks in here that would stop it generating it | 14:17 |
| Q-FUNK | smb: yes, that's what it normally does, as long as the initrd wasn't touched | 14:18 |
| smb | Q-FUNK, I have touched the initramfs by running update-initramfs | 14:18 |
| apw | Q-FUNK, so do the same on yours and pastebin it so we can see the difference | 14:18 |
| Q-FUNK | do we have our own pastebin here? I'd rather avoid flodding the channel | 14:19 |
| apw | i use the command pastebinit | 14:19 |
| Q-FUNK | ah, that's a new one to me. just a sec. | 14:20 |
| apw | Q-FUNK, seems we have paste.ubuntu.com as well | 14:21 |
| === sconklin-gone is now known as sconklin | ||
| smb | Keybuk, FWIW, the best plymouth for now, seems still to get into some trouble here. :( But at least in this case it is in S state and waits for ep_poll | 14:26 |
| Keybuk | smb: it shouldn't get into any trouble | 14:26 |
| Keybuk | please describe what you see | 14:27 |
| smb | purple | 14:27 |
| smb | The screen with the 4 dots, X is started | 14:27 |
| Keybuk | ubuntu logo or "Ubuntu 10.04" ? | 14:27 |
| smb | Ubuntu logo | 14:27 |
| Keybuk | so you see mouse pointer? | 14:27 |
| Keybuk | lies | 14:27 |
| Keybuk | if you see 4 dots, you see Ubuntu 10.04 :p | 14:27 |
| Keybuk | so you're lying to me about one of those two facts :p | 14:28 |
| smb | Keybuk, Ok, sorry 5 dots | 14:28 |
| Keybuk | :D | 14:28 |
| Keybuk | the variations in the number of dots is deliberate :p | 14:28 |
| smb | Aha. :) | 14:28 |
| Keybuk | debugging aid through splash screen theming :-) | 14:28 |
| Keybuk | ok, so you're on nouveau | 14:28 |
| Keybuk | single head or multi-head? | 14:29 |
| smb | sinle | 14:29 |
| smb | single | 14:29 |
| Keybuk | so your 5 dots are all orange | 14:29 |
| Keybuk | X has started | 14:29 |
| Keybuk | you see a mouse pointer? | 14:29 |
| smb | Right, its running in ps output | 14:29 |
| smb | no | 14:29 |
| Keybuk | ok | 14:29 |
| Keybuk | can you paste the X cmdline for me | 14:29 |
| smb | attached keyboard is dead as well | 14:29 |
| Keybuk | enter doewsn't kill X ? | 14:29 |
| smb | 1018 tty7 Ss+ 0:00 /usr/bin/X :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-QbNPCm/database -nolisten tcp vt7 | 14:29 |
| Keybuk | smb: and /proc/1018/wchan ? | 14:29 |
| smb | ttm_bo_wait_cpu | 14:30 |
| Keybuk | hah | 14:30 |
| Keybuk | right | 14:30 |
| Q-FUNK | http://paste.ubuntu.com/396725/ | 14:30 |
| Keybuk | Not a plymouth bug, sorry | 14:30 |
| * smb does not like the sound of "hah" | 14:31 | |
| Keybuk | nouveau/X has crashed your card | 14:31 |
| Keybuk | just to be sure | 14:31 |
| Keybuk | plymouth --ping && echo "ok" | 14:31 |
| smb | Keybuk, Sorry, did a kill -9 1018 | 14:31 |
| smb | This ends plymouth and restarts gdm | 14:32 |
| Keybuk | yup | 14:32 |
| Keybuk | plymouth set the screen to black ok? | 14:32 |
| Keybuk | you get failsafe X now? | 14:32 |
| smb | A short period of black and now gdm greeter is up | 14:32 |
| Keybuk | right | 14:32 |
| Keybuk | isn't a plymouth bug then | 14:32 |
| Keybuk | all plymouth is doing on your card is using /dev/fb0 | 14:33 |
| Q-FUNK | apw: http://paste.ubuntu.com/396725/ normally, that update-initramfs hook would run at the end of the dkpg-reconfigure. | 14:33 |
| Keybuk | in plain old Linux framebuffer mode | 14:33 |
| Keybuk | so it's just writing pixels to the framebuffer | 14:33 |
| Keybuk | it's not talking directly to nouveau | 14:33 |
| Keybuk | nor is it talking to the drm/dri layer | 14:33 |
| Keybuk | what's crashing for you is something inside TTM when X starts | 14:33 |
| Keybuk | since plymouth didn't go near that, meh | 14:33 |
| Keybuk | if plymouth can cause that, it's still a kernel bug, since plymouth is only writing to the framebuffer | 14:34 |
| smb | Keybuk, Oh well. :-P Its just the fact that plymouth and X run at the same time that seems odd. And killing X to cause plymouth to end | 14:34 |
| Keybuk | that's because killing X is reaped by gdm | 14:35 |
| Keybuk | and gdm talks to plymouth | 14:35 |
| Keybuk | plymouth and X running at the same time is so we can do smooth transition on Intel/GEM cards | 14:36 |
| Keybuk | we have to hold the drm/dri connection open so that the kernel doesn't replace our own crtc buffer with the fbcon buffer | 14:36 |
| Keybuk | it's otherwise inactive | 14:36 |
| Keybuk | it's closed down various fds, and removed watches on others, etc. | 14:36 |
| smb | Hm, ok. So something on the first start of X goes wrong. plymouth does not get talked to and X is stuck somewhere. And it seems to work on subsequent starts | 14:37 |
| apw | Q-FUNK, what the heck release is this with 2.6.23 ? | 14:40 |
| Q-FUNK | apw: currently hardy. cannot upgrade to anything newer than 2.6.23 because of bug #241307 | 14:41 |
| ubot3 | Malone bug 241307 in linux "kernel oops during bootup in LTSP" [High,In progress] https://launchpad.net/bugs/241307 | 14:41 |
| Q-FUNK | had to build my own kernel package based on the gutsy config just to keep this host remotely up-to-date and up-and-running. | 14:41 |
| apw | Q-FUNK, whats in your /etc/kernel-img.conf (pastebin that too) | 14:41 |
| Q-FUNK | apw: http://paste.ubuntu.com/396731/ | 14:43 |
| apw | think you gotten hit by the bug where the triggers get lost | 14:43 |
| apw | postinst_hook = update-grub | 14:44 |
| apw | postrm_hook = update-grub | 14:44 |
| apw | i have those in mine | 14:44 |
| Q-FUNK | and yes, this runs LILO, because GRUB cannot work without some console (on the host or serial) while lilo can be told to blindly boot whatever. | 14:44 |
| Q-FUNK | yup. got that on my normal hosts running grub too. | 14:45 |
| apw | i wonder if you'd need an equivalent or not hrm | 14:46 |
| apw | perhaps that is a herring rouge too | 14:46 |
| Q-FUNK | i didn't need to until I somehow stupidly issued an "update-initramfs -u -k all | 14:46 |
| smb | Well a lot might be different in Hardy anyway | 14:47 |
| apw | well i would try force reinstalling the kernle .deb | 14:47 |
| apw | and see if that resolved it, seemed to for smb | 14:47 |
| Q-FUNK | it didn't | 14:47 |
| smb | apw, I was looking on Lucid | 14:48 |
| Q-FUNK | something in update-initramfs wants to play smart pants and decide that the image was updated so it doesnt get updated. | 14:48 |
| apw | well i can't see anying in my lucid copy doing anything smart | 14:48 |
| * smb tries to remember whether there were hook dirs... | 14:49 | |
| apw | Q-FUNK, i'd start by confrming it gets called by renaming it .real and adding a log script | 14:49 |
| Q-FUNK | apw: mind you, you're using grub, which is a lot more fault-tolerant and doesn't require updating the bootsector when installing a new kernel. | 14:49 |
| manjo | apw, ping | 15:40 |
| * apw is here | 15:40 | |
| smb | Keybuk, Have been distracted and its probably not relevant as this seems to be in nouvau, but "plymouth --ping && echo ok" does print nothing when in wedged state | 16:07 |
| Keybuk | ok | 16:08 |
| apw | smb, interesting to see that someone from ksplice is following your trees | 16:41 |
| smb | apw, Was that the mail asking for the cve updates this morning? | 16:41 |
| apw | yeah note the email addy on that one | 16:41 |
| smb | apw, I have not, usually hidden by my mailer. But yes, interesting. | 16:43 |
| smb | apw, Well probably as they offer to patch for security things on the fly... | 16:43 |
| apw | probabally as a paid for service ... | 16:43 |
| JFo | Keybuk, mind taking a quick look at bug 539787 | 17:13 |
| ubot3 | Malone bug 539787 in linux "Plymouth won't show up while booting, I get messages" [Undecided,Triaged] https://launchpad.net/bugs/539787 | 17:13 |
| Keybuk | yes, sorry | 17:15 |
| Keybuk | your bug won't cause us to cancel beta 1 | 17:16 |
| Keybuk | frankly plymouth not showing up is common | 17:16 |
| Keybuk | and not a bug | 17:16 |
| Keybuk | well | 17:17 |
| Keybuk | it's a kernel bug ;) | 17:17 |
| Keybuk | make the graphics drivers load faster | 17:18 |
| === kamalm is now known as kamalm-away | ||
| JFo | heh | 17:27 |
| JFo | thanks for looking | 17:27 |
| JFo | :) | 17:27 |
| === sconklin is now known as sconklin-gone | ||
| Sarvatt | Keybuk: they used to load a lot sooner, when plymouth was removed from the initrd and things were serialized more they started loading a lot later | 18:19 |
| Keybuk | yes, but in the initrd they were critical path | 18:22 |
| Keybuk | so we spent several seconds waiting for them | 18:22 |
| Keybuk | so while you had a splash screen for longer, your boot took much longer | 18:22 |
| Sarvatt | the console changes 3 times before plymouth starts now, looks kind of funky.. ugly vgacon that shows the fsck messages, then console-setup changing the fonts on that, then the drmfb loading | 18:24 |
| Keybuk | fast > pretty | 18:25 |
| ogra | hmm, i seem to have plymouthd die on boot since the recent upgrade ... and also a heavy flicker on shutdown | 18:27 |
| ogra | whoops, i didnt realize i'm in -kernel ... that was supposed to go to -devel | 18:30 |
| Keybuk | ogra: video please | 18:31 |
| ogra | Keybuk, i assume you are already aware of the crash on boot ? | 18:32 |
| Keybuk | no | 18:32 |
| ogra | ok | 18:33 |
| * ogra reboots | 18:33 | |
| === bjf is now known as bjf-afk | ||
| tgardner | apw, 2.6.32-17-server works good for me | 18:36 |
| apw | tgardner, the igb bits yes? | 18:36 |
| tgardner | apw, yep | 18:37 |
| apw | tgardner, cool | 18:37 |
| apw | thanks for the feedback on that | 18:37 |
| cnd | rtg, thanks! | 19:25 |
| cnd | tgardner: thanks too! | 19:25 |
| cnd | so we don't do lpia builds anymore right? | 19:31 |
| tgardner | cnd, not for Lucid | 19:31 |
| cnd | I'm curious why we started to, and no longer make them? | 19:31 |
| tgardner | its a long and sordid story | 19:32 |
| cnd | did they just not provide enough benefit to be worth it? | 19:32 |
| tgardner | essentially. moorestown never really materialized. | 19:32 |
| cnd | tgardner: I figured lpia was also for atom stuff, but that's not the case? | 19:33 |
| tgardner | there was some thought that LPIA flags could improve performance and power consumption, but it never really made much difference. | 19:34 |
| tgardner | atom seems to work fine as a regular 'ol 386 | 19:34 |
| cnd | ok | 19:37 |
| === bjf-afk is now known as bjf | ||
| cnd | I thought that by changing the changelog version (i.e. to 2.6.32-16~lp555555) that I would get a vmlinuz with the extra string appended as well | 19:56 |
| cnd | but recently my kernels haven't been built with the string appended | 19:56 |
| cnd | am I forgetting something? | 19:56 |
| apw | cnd, the packages are generated with the versions on them | 20:00 |
| cnd | apw, correct, but what about the vmlinuz and initrd files? | 20:00 |
| apw | cnd, but the binary files are abi and flavour specific only | 20:00 |
| cnd | I could have sworn I had vmlinuz files with the version appendage too, but maybe I'm wrong | 20:01 |
| apw | for the mainline builds the ABI number is unique to the release | 20:01 |
| apw | vmlinuz-2.6.32-02063208-generic | 20:01 |
| manjo | JFo, how do you fix ImportError: No module named arsenal_lib ? | 20:30 |
| bjf | manjo, are you running from the arsenal directory? | 20:30 |
| JFo | I used a link | 20:30 |
| JFo | to the relevant script under contrib/ | 20:30 |
| manjo | I ran a script from kernel/contrib/linux | 20:31 |
| manjo | ./mass_reply.py | 20:31 |
| manjo | JFo, where do you run the script from ? | 20:31 |
| JFo | from contrib/linux/ | 20:32 |
| JFo | but I have a softlink in contrib/linux/ back to contrib/arsenal_lib.py | 20:32 |
| manjo | hmm that is what I did ... cd to contrib/linux and ran the script | 20:32 |
| manjo | ah ic | 20:32 |
| manjo | JFo, cool thanks a ton tha tworks | 20:34 |
| JFo | manjo, no sweat :) | 20:35 |
| bryceh | JFo, yeah we need to make arsenal_lib.py get installed or something | 20:48 |
| bryceh | my python packaging skillz are anemic | 20:48 |
| JFo | heh | 20:48 |
| JFo | mine are non-existent | 20:49 |
| bryceh | JFo, apw, btw I'm sure you already have a report that shows your milestoned / nominated bugs, but I did up one for the desktop team in arsenal | 20:52 |
| Sarvatt | tgardner: might have something to do with the lpia toolchain being changed to optimize for pentium-m instead of backporting the gcc atom support patches back in early jaunty to account for celeron netbooks, that killed LPIA for me.. lucid+1 with gcc 4.5 that has -march=atom support and the kernel now having atom optimizations would have been rocking :( | 20:52 |
| bryceh | JFo, e.g. http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/milestone-bugs.html | 20:53 |
| bryceh | JFo, also in JSON for import to bughugger - http://www2.bryceharrington.org:8080/X/Data/ubuntu-x-swat/milestone-bugs.json | 20:53 |
| JFo | very nice | 20:53 |
| JFo | that is yet another thing I need to get conversant on is the JSON building | 20:54 |
| Sarvatt | -Os -march=core2 -mtune generic seem to be the best flags for atom without -march=atom support | 20:54 |
| bryceh | yeah that's actually the part of arsenal I'm most happy with | 20:54 |
| JFo | I'm sure bdmurray is getting tired of carrying me | 20:54 |
| JFo | may have a look at what you have built there and see what I can pillage for a kernel report :-D | 20:54 |
| * JFo is a code pirate | 20:55 | |
| bryceh | sure, and happy to explain the bits | 20:55 |
| JFo | excellent | 20:55 |
| bryceh | the only part I'm unhappy with is the report generator chokes on unicode, and launchpad is thick with it. | 20:55 |
| bryceh | but I'm banging on that today so we'll see | 20:55 |
| JFo | mind if I take a bit of your time next week to discuss best practices for launchpadlib stuff? | 20:55 |
| bryceh | I might change templating systems if I can't fix it easy | 20:55 |
| bryceh | JFo, sure | 20:56 |
| JFo | thanks :) | 20:56 |
| * JFo needs a bigger plate to put things on | 20:56 | |
| bryceh | same | 20:56 |
| JFo | <- headed over to the new place to move furniture, see you all tomorrow. :) | 20:58 |
| cnd | if anyone is running lucid right now, can they tell me what is output from this (should be a 0 or a 1): cat /sys/kernel/debug/tracing/tracing_on | 21:14 |
| sbeattie | cnd: 1 here | 21:15 |
| cnd | sbeattie: can you check tracing_enabled too? | 21:16 |
| sbeattie | cnd: 1 also | 21:16 |
| cnd | sbeattie: thanks | 21:16 |
| sbeattie | sure. | 21:17 |
| cnd | ahhh, I see why that's ok, current_tracer is nop | 21:17 |
| apw | bryceh, sounds good where can i see the output of that | 21:18 |
| bryceh | apw, e.g. for X http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/milestone-bugs.html | 21:18 |
| === bjf is now known as bjf-afk | ||
| manjo | bjf-afk, your script worked wrt to adding the note but failed to change state to incomplete | 21:38 |
| manjo | bjf-afk, had to do that manually | 21:38 |
| bryceh | manjo, did it show an error message? | 22:02 |
| === kamalm-away is now known as kamalm | ||
| === gnomefreak76 is now known as gnomefreak | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!