| === philipballew is now known as hello_my_name_is | ||
| === hello_my_name_is is now known as philipballew | ||
| * apw finally gets his machine updated and booted | 08:58 | |
| apw | 1 day suspended, 200M of updates, sigh | 08:59 |
|---|---|---|
| * smb reboots to get'em active | 09:11 | |
| * smb seems to be back | 09:16 | |
| smb | Just the screen vomit between lightdm and the desktop is always making me feel a little discouraged | 09:17 |
| apw | i don't get that i don't think | 09:18 |
| Daviey | smb / apw: I'd really like to bounce an idea off hallyn, but he is on hols. What do you chaps think about enabling kvm vmx nested by default? | 09:21 |
| smb | I think its the radeon driver forgetting to clear the graphics ram before displaying it | 09:21 |
| apw | Daviey, does it even work ? | 09:21 |
| Daviey | apw: yeah! But not decalred as ready as svm, which is why upstream don't have it such. | 09:22 |
| Daviey | svm nesting is enabled OOTB | 09:22 |
| smb | Daviey, It would be nice if thoughts of enabling things would be presented before feature freeze though | 09:23 |
| apw | Daviey, what option is it ? | 09:23 |
| Daviey | apw: I'm still not entirely sure TBH.. I think it's actually a userspace thing. | 09:23 |
| apw | i don't see any options mentioning nesting anyhow, kernel side | 09:24 |
| Daviey | I think it is enabled kernel level, but just not exposed. | 09:24 |
| Daviey | apw: I think it's a modprobe option? | 09:24 |
| apw | i then think, we know so little about it we cannot comment | 09:24 |
| * smb agrees | 09:25 | |
| Daviey | $ modinfo kvm_amd | grep -i nested | 09:25 |
| Daviey | parm: nested:int | 09:25 |
| Daviey | $ cat /sys/module/kvm_intel/parameters/nested | 09:25 |
| Daviey | Y | 09:25 |
| Daviey | Okay, thanks anyway.. | 09:25 |
| apw | Daviey, sounds like the kernel side is all there, so ... as you say sounds like a userspace side thing | 09:26 |
| Daviey | apw: Right, it was more of a 'have you heard that doing this would be NUTS?' kinda thing. | 09:27 |
| smb | no, but then we usually just stick to the defaults as long as nobody asks for something specifically. and the defaults cannot be nuts otherwise they would not be defaults... :) | 09:29 |
| apw | Daviey, heh, no i think i only heard that we now had nesting at all this week actually | 09:29 |
| Daviey | ok, thanks :) | 09:32 |
| smb | RAOF, Is that something that you are aware (not so clean transition between lightdm and desktop for radeon) off or think it should be addressed? | 09:33 |
| htorque | bryceh: hi! bug 899159 - this seems to be fixed in the xorg-edgers ppa, but i'm still getting (worse) hangs, just with a different number (0x7a000002 instead of 0x7b009004, which i initial got, but later couldn't reproduce anymore). | 09:57 |
| ubot2` | Launchpad bug 899159 in mesa "[snb-gt2] GPU lockup render.IPEHR: 0x7b009004" [High,In progress] https://launchpad.net/bugs/899159 | 09:57 |
| htorque | should i open a new bug report (upstream?)? | 09:58 |
| cking | apw, can you forward me the canonicloud scripts you were talking about yesterday evening? | 10:40 |
| apw | smb, you wrote maint-getabis right? seems it is trying to get ppc64 for oneiric for hendrix | 11:46 |
| henrix | creating the ignore file didn't work | 11:47 |
| apw | II: linux-image-3.0.0-16-powerpc64-smp_3.0.0-16.29_ppc64.deb | 11:47 |
| apw | II: Downloading to kernel.ubuntu.com ... FAILED! | 11:47 |
| apw | henrix, i think you can just ignore the fact it tried and failed to do it | 11:47 |
| apw | you cirtainly don't need any files for ppc64 as the kernel is never built there | 11:48 |
| apw | so it cannot fail the abi checks | 11:48 |
| henrix | oh, unless... the ignore file should be debian.master/.../powerpc/ppc64.ignore and not debian.master/.../ppc64/ignore | 11:48 |
| apw | henrix, though i would also say that in the tip of oneiric/master-next that i have, the ABI files are already up to date too | 11:48 |
| apw | henrix, there is no point in making any files with ppc64 in their name | 11:49 |
| apw | th | 11:49 |
| apw | there is no such architecture | 11:49 |
| apw | the error about ppc64 can be ignored, as there really really never are any and cannot be | 11:49 |
| apw | that is not a valid ubuntu architecture at all | 11:49 |
| henrix | apw: ok, cool. so i'll just ignore the failure and later on confirm with the guys what they usually do | 11:50 |
| henrix | apw: thanks | 11:50 |
| RAOF | smb: Yes, I'm aware of that; I don't think it's a kernel or X bug; I should be able to get to it tomorrow or early next week. | 11:55 |
| * RAOF sleeps | 11:56 | |
| apw | cking, those examples will be needing updated for you, i am just retesting them now | 12:30 |
| apw | cking, some of the command output has changed format | 12:31 |
| apw | cking, ok branch updated with fixed offsets | 12:34 |
| === yofel is now known as yofel_ | ||
| === yofel_ is now known as yofel | ||
| smb | apw, Yes I wrote it. Possibly it needs ppc blacklisted. It would try to get anything that control.d indicates. Which is not always true | 13:37 |
| apw | smb, there is a config in debian.<branch>/etc/getabi as well which lists the right things to get | 13:38 |
| smb | apw, Nowadays maybe. This was working way before | 13:38 |
| smb | And not sure it would be true for hardy... | 13:38 |
| smb | anyway henrix may have a look at IgnorePatterns in the source script | 13:39 |
| henrix | i will be taking a look at it later. i added this issue to my todo list. | 13:39 |
| henrix | for now, i just ignored the ppc64 failure so that i can go ahead with the sru | 13:39 |
| smb | henrix, ok. basically its likely just a IgnorePatterns["oneiric"] = ² ".*_ppc64.deb" ] | 13:41 |
| smb | or whatever the package file would look like | 13:41 |
| smb | s/²/"/ | 13:41 |
| henrix | smb: yeah, i've seen that on the script. i'll give it a try | 13:42 |
| smb | henrix, If you later have a line that works for you, let me know then we can commit it to the repo | 13:43 |
| henrix | smb: sure, i'll let you know. thanks | 13:44 |
| henrix | smb: so, there are not releases supporting pp64 atm, correct? | 13:44 |
| henrix | smb: i mean, this arch shall be *always* ignored? | 13:44 |
| smb | henrix, That would be the meaning. I am just not completely sure this is true for oneiric and why nobody else had the issue otherwise | 13:45 |
| smb | I know we were talking about dropping some ppc flavour though I thought for precise | 13:46 |
| henrix | smb: this issue has been detected before by the other guys. its just that its not sorted out yet, due to these "unknowns" about the ppc support | 13:47 |
| henrix | smb: at least, that was my understanding | 13:48 |
| smb | henrix, Yeah, ppc comes and goes. its confusing | 13:49 |
| henrix | heh | 13:49 |
| henrix | thanks for your help. i'll let you know later when i revisit this script | 13:50 |
| apw | smb, though in this case the failures are all ppc64, which never was an arch | 13:50 |
| smb | inux-image-3.0.0-16-powerpc64-smp_3.0.0-16.29_powerpc.deb | 13:50 |
| smb | probably meaning ppc64 as the flavour | 13:51 |
| smb | So maybe the logic to find the right name is broken | 13:51 |
| henrix | the failure is in linux-image-3.0.0-16-powerpc64-smp_3.0.0-16.29_ppc64.deb | 13:52 |
| henrix | linux-image-3.0.0-16-powerpc64-smp_3.0.0-16.29_powerpc.deb | 13:52 |
| henrix | is working file ^^ | 13:52 |
| henrix | s/file/fine | 13:52 |
| smb | Hm, maybe a side effect from apw'S cleaning up the description | 13:53 |
| henrix | description? | 13:53 |
| smb | I could be wrong. As much as I remember I try to make sense of what the vars.* files describe | 13:55 |
| smb | Maybe just something I did not see when the script was written | 13:55 |
| herton | apw, smb, I think this problem on maint-startnewrelease started with commit 3784816027fe117b43042d1ac5dff20bdc3579aa on natty repository, why that ppc64 stuff was added? | 13:56 |
| apw | herton, because there was going to be a new arch, then there wasn't | 13:56 |
| apw | as that is not hte official configuration for getabi, noone had noticed | 13:57 |
| smb | So ok. In that case ignoring it sounds fine to me | 13:57 |
| apw | and it being there is safe in the archive | 13:57 |
| smb | ba no wonder nobody speaks to me on mumble... f... | 13:58 |
| apw | smb, ? | 13:58 |
| herton | yes, just confirming, it was what I had got previously I think, we always ignored it | 13:58 |
| smb | apw, It broke | 13:59 |
| smb | Nobody *can* hear me | 13:59 |
| apw | smb, ahh you are there but no lips indeed | 13:59 |
| smb | *sigh* | 13:59 |
| apw | smb, flip some things randomly bound to help | 14:00 |
| smb | apw, Well what I was saying to myself was that ppc64 in some way as a flavour name and a potential architecture is so little chance of not being confusing. Especially when it never comes | 14:02 |
| tgardner | smb, i386 is to amd64 as ppc is to ppc64 ? | 14:03 |
| smb | tgardner, Not that I would be knowledgable there. But it would be my impression | 14:04 |
| tgardner | smb, I think the ppc64 possibility is really dead now. | 14:05 |
| apw | indeed powerpc is 32bit userspace (but has a 64bit kernel option) ppc64 would have been a 64bit userspace | 14:05 |
| smb | Mabye just without the need to be compatible | 14:05 |
| herton | may be the ppc64 stuff should be removed if it will not come as a new arch on the distro, I don't know, do we know if it'll really come? | 14:05 |
| smb | apw, Isn't that a bit different from what we thougt? | 14:05 |
| apw | herton, it was left in cause it doesn't really do any harm | 14:06 |
| apw | as nothing uses it even as tehre is no architecture | 14:06 |
| apw | and it was a pig to get working and keep up to date | 14:06 |
| apw | but there is also no reason to have it in anything other than P currently, probabally Q | 14:06 |
| apw | so if it causes issues ripping it out isn't a problem | 14:07 |
| smb | herton, Similar issues existed before, for that reason the ignore lists in getabis exists. | 14:07 |
| herton | smb, sure, no problem in using IgnorePatterns for now | 14:13 |
| smb | Maybe this time I can even put some explanatory comment there, so I will remember in two weeks | 14:15 |
| cking | apw, thanks for sorting out the scripts for me | 14:21 |
| apw | cking, np they wern't working for me anymore, and i'm going to need em once uds opens | 14:22 |
| herton | cking, I spammed yesterday the ecryptfs bugs for verification, I think most of them or all can be put as verified already where they are patches that went to stable in other releases, but natty didn't picked up as as 2.6.38 doesn't have stable releases anymore. Just did the normal spamming just in case as it is not clear whether we should verify stable patches that ended up in other releases (well extra testing will not do any harm if there is | 14:26 |
| herton | time to do them...). | 14:26 |
| herton | *ecryptfs bugs for natty | 14:27 |
| tgardner | herton, I marked at least one of the natty ecryptfs bugs as verified | 14:27 |
| herton | tgardner, ack | 14:27 |
| cking | herton, I verified the other 3 this morning | 14:27 |
| herton | cool, yes saw sru-report now and everything is ok. | 14:28 |
| cking | I did a clean -i386 install and ran the ecryptfs (and a manual test) to verify they worked - so it was a good sanity checking exercise | 14:29 |
| === albrigha is now known as Guest16781 | ||
| * tgardner goes offline to break his router | 15:37 | |
| smb | sounds fun | 15:38 |
| * ogasawara back in 20 | 15:40 | |
| apw | jjohansen, would the following be bad: | 16:03 |
| apw | [ 44.510396] type=1400 audit(1331219759.479:9): apparmor="DENIED" operation="create" parent=772 profile="/sbin/dhclient" pid=773 comm="dhclient3" family="inet" sock_type="dgram" protocol=17 | 16:03 |
| apw | jjohansen, might that indicate we are preventing dhcp from working ... owner of the machine is reporting that they no longer have network | 16:04 |
| apw | ogasawara, i have an update for the hyper-v support i'd like in the next upload, when is that likely to be ? | 16:41 |
| ogasawara | apw: was going to plan one for tomorrow | 16:41 |
| ogasawara | apw: go ahead and shove any patches you want in to master-next | 16:42 |
| apw | ogasawara, sounds good, will have them tested finally today and get them in | 16:42 |
| * cking reboots his AP | 17:46 | |
| apw | ogasawara, ok tested successfully, and patches pushed | 17:48 |
| ogasawara | apw: ack, thanks | 17:48 |
| bryceh | htorque, yeah since that one is believed fixed, let's start a fresh bug report. | 18:07 |
| === tgardner is now known as tgardner-lunch | ||
| htorque | bryceh: should this directly go upstream? | 18:45 |
| bryceh | htorque, yes but would be nice to also have a launchpad bug for us to track | 18:46 |
| bryceh | htorque, so do `ubuntu-bug mesa`, attach the dmesg and i915_error_state, steps to reproduce, and so on | 18:47 |
| bryceh | then similarly to file it upstream. | 18:48 |
| bryceh | if that seems like too much hassle, file the LP bug and I can forward it to fdo | 18:48 |
| htorque | bryceh: it would be great if i could create such an apitrace log file, so this could be reproduces easier (right now i trigger it with a game installed through wine :-/). you don't happen to know how i can get such a log file? | 18:50 |
| htorque | *reproduced | 18:50 |
| bryceh | no I haven't played with apitraces myself so far, but agree that would be helpful to have | 18:51 |
| bryceh | htorque, I'll find out for you | 18:51 |
| thomi | Hi - for about a week now my webcam isn't recognised in precise. It doesn't show up in /dev/video0, so I'm guessing it's a driver issue. What can I do to diagnose and debug the problem? | 18:52 |
| bryceh | htorque, alright this seems to be the best doc on using it: https://github.com/apitrace/apitrace/blob/master/README.markdown | 18:54 |
| htorque | bryceh: thanks | 18:54 |
| bryceh | htorque, so, git clone https://github.com/apitrace/apitrace.git | 18:54 |
| htorque | yeah, i have that | 18:54 |
| bryceh | ok, cool so looks like it's called via `apitrace trace --api API /path/to/application` | 18:55 |
| bryceh | htorque, hope that helps, let me know how it goes | 18:56 |
| htorque | bryceh: will try it soon, i just hope it likes wine | 18:56 |
| === tgardner-lunch is now known as tgardner | ||
| htorque | bryceh: oh, i just read that it can trace but not retrace directx calls. do you think i should try it anyway? | 19:12 |
| bryceh | oh, hrm | 19:13 |
| bryceh | well, couldn't hurt I guess | 19:13 |
| bryceh | htorque, hmm you know wine might have a similar trace dumping thing | 19:13 |
| bryceh | however I know even less about wine... | 19:13 |
| * ogasawara lunch | 20:01 | |
| === htorque_ is now known as htorque | ||
| * cking --> EOD | 21:00 | |
| === himcesjf1 is now known as himcesjf | ||
| === htorque_ is now known as htorque | ||
| * tgardner -> EOD | 21:29 | |
| PioneerAxon | Hey all, by unknown cause, my kernel (3.0.0-14-generic) dumped these lines into log around 700MB, until I forced shutdown.. | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.287437] uhci_hcd 0000:00:1d.1: setting latency timer to 64 | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.287460] uhci_hcd 0000:00:1d.1: PCI INT C disabled | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.287583] uhci_hcd 0000:00:1d.1: PCI INT C -> GSI 19 (level, low) -> IRQ 19 | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.287589] uhci_hcd 0000:00:1d.1: setting latency timer to 64 | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.287612] uhci_hcd 0000:00:1d.1: PCI INT C disabled | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.287739] uhci_hcd 0000:00:1d.1: PCI INT C -> GSI 19 (level, low) -> IRQ 19 | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.287745] uhci_hcd 0000:00:1d.1: setting latency timer to 64 | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.287768] uhci_hcd 0000:00:1d.1: PCI INT C disabled | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.287894] uhci_hcd 0000:00:1d.1: PCI INT C -> GSI 19 (level, low) -> IRQ 19 | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.287900] uhci_hcd 0000:00:1d.1: setting latency timer to 64 | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.287924] uhci_hcd 0000:00:1d.1: PCI INT C disabled | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.288067] uhci_hcd 0000:00:1d.1: PCI INT C -> GSI 19 (level, low) -> IRQ 19 | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.288074] uhci_hcd 0000:00:1d.1: setting latency timer to 64 | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.288098] uhci_hcd 0000:00:1d.1: PCI INT C disabled | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.288227] uhci_hcd 0000:00:1d.1: PCI INT C -> GSI 19 (level, low) -> IRQ 19 | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.288234] uhci_hcd 0000:00:1d.1: setting latency timer to 64 | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.288262] uhci_hcd 0000:00:1d.1: PCI INT C disabled | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.288401] uhci_hcd 0000:00:1d.1: PCI INT C -> GSI 19 (level, low) -> IRQ 19 | 21:41 |
| PioneerAxon | Mar 9 02:13:48 ubuntu kernel: [55080.288408] uhci_hcd 0000:00:1d.1: setting latency timer to 64 | 21:41 |
| ohsix | you have a not so very nice usb device | 21:41 |
| ohsix | looks like it's taking the opportunity to put something to sleep, and it's flagging | 21:42 |
| PioneerAxon | Yeah, but I didn't plug in anything... | 21:42 |
| PioneerAxon | suddenly, it started using max CPU, | 21:42 |
| ohsix | lsusb shows no devices? could be a mechanical problem too, or just a bug | 21:42 |
| PioneerAxon | no new devices on lsusb | 21:43 |
| ohsix | any devices. | 21:43 |
| PioneerAxon | after restart, it is working normal | 21:43 |
| PioneerAxon | yeah, I have webcam installed on usb | 21:43 |
| PioneerAxon | FYI, I am on laptop.. | 21:44 |
| PioneerAxon | I guess, it would be some unknown problem, because I am using this kernel from a long time without any problem.. | 21:45 |
| PioneerAxon | unknown factor* | 21:46 |
| PioneerAxon | Anyways, Should I submit the log?? | 21:47 |
| JanC | PioneerAxon: next time please use paste.ubuntu.com or another pastebin if you want to show something longer than 2-3 lines... ;) | 21:48 |
| PioneerAxon | Okay, sure... Sorry for that.. | 21:48 |
| JanC | PioneerAxon: is this a one-time issue, or something you see often? | 21:50 |
| PioneerAxon | No, this is the first time, anything happened, which forced me to shutdown.. | 21:51 |
| PioneerAxon | JanC: I am going to remove both logs, kernel.log and syslog. As no much useful information in those file, taking 1.5 Gigs on my disk.. | 21:55 |
| JanC | PioneerAxon: not as bad as the 50+ GiB ~/.xsession-errors I had recently... ;) | 21:59 |
| PioneerAxon | OMG!! 50 GB!! This is insane.. | 22:00 |
| PioneerAxon | JanC: how would anyone even handle that big file?? It is too much for any editor/tool.. | 22:02 |
| JanC | eh? | 22:02 |
| JanC | 'less' handles it fine ;) | 22:02 |
| ohsix | so would vim ;] | 22:03 |
| JanC | as do grep etc. | 22:03 |
| PioneerAxon | No, I was talking about more GUI based log viewers... | 22:03 |
| ohsix | less useful | 22:04 |
| JanC | it's just really weird if you suddenly get out of diskspace errors on a $HOME where you didn't save/download anything but a couple of small documents recently | 22:04 |
| JanC | PioneerAxon: GUI-based log viewers can handle that if they are well-written... ;) | 22:05 |
| PioneerAxon | yeah, gnome-system-log crashed twice while opening these 700 M files... :P | 22:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!