| === bjf is now known as bjf-afk | ||
| dtchen | jk-: after reading Grant's LWN article, I thought I'd mention (in its comments) that you should check out the patch format expected by snd-hda-intel if you don't already know of it. | 02:23 |
|---|---|---|
| whatchasay | !ops | 03:39 |
| ubot3 | Help! lamont, zul, T-Bone, mdz, or jdub | 03:39 |
| whatchasay | k-line me | 03:54 |
| Kano | hi apw , 2.6.32 final is out, when will it be rebased? | 09:12 |
| * apw notes that he has a robot which tells him when its out | 09:13 | |
| apw | rebase is planned for today, likely tested and availble tomorrow | 09:14 |
| Kano | i only need git | 09:14 |
| === chuck_ is now known as zul | ||
| Kano | hi tormod | 13:18 |
| tormod | hi | 13:19 |
| Kano | do you have got a gt220 to test? | 13:25 |
| Kano | just thinking of a kernel patch | 13:25 |
| Kano | i just dont know if it is a 2ch or 8ch device | 13:26 |
| Kano | for the hdmi port | 13:26 |
| tormod | I even don't know what a gt220 is :) | 13:26 |
| Kano | nvidia | 13:26 |
| tormod | oh I have close to zero experience with nvidia | 13:26 |
| tormod | they are a bad OSS player | 13:27 |
| Kano | well i only have got ssh access to it, but after rebase of .32 i will compile a kernel with experimental support | 13:27 |
| Kano | 2ch i try first... | 13:27 |
| tormod | I have one lab computer with it, running happily with nv and I don't touch it | 13:27 |
| Kano | only the dx10.1 cards have got integrated hdmi soundcard just like ati | 13:28 |
| Kano | there is a simple patch in one board, but not against .32 as there you have to select 2ch or 8ch | 13:30 |
| Kano | http://www.vdrportal.de/board/thread.php?postid=853558 | 13:30 |
| Kano | the rest is the same | 13:31 |
| Kano | well will take break and hope then the git is up2date ;) | 13:34 |
| Kano | bbl | 13:34 |
| abhinav | how do I find out if a particular commit in the kernel has made it into the one being used in karmic ? I am interested in knowing whether this is solved in my current karmic installation : http://lkml.org/lkml/2009/5/3/141 | 13:34 |
| rtg | abhinav, git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git ? | 13:35 |
| abhinav | rtg: do I just copy paste the above in a browser ? | 13:36 |
| rtg | abhinav, for that use http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=summary | 13:37 |
| apw | jjohansen, any changes to -ec2 pending, am about to rebase it | 13:43 |
| jjohansen | apw: nope | 13:44 |
| apw | good stuff | 13:44 |
| jjohansen | with .32 going final I expect there will be some updates with in the next week or so | 13:45 |
| apw | i am just abuot to rebase it to there, and we'll seee if it builds | 13:46 |
| tormod | apw: [drm] radeon defaulting to kernel modesetting. | 14:12 |
| apw | tormod, ? | 14:13 |
| tormod | when did this happen? I think a post to ubuntu-x would have been appropriate? Or mention in changelog? | 14:13 |
| tormod | apw, you know that our user-space does not support it yet? | 14:13 |
| apw | i was told the opposite | 14:14 |
| tormod | hmm | 14:14 |
| apw | at the UDS session which discussed it | 14:14 |
| tormod | there are a few quirks, see https://wiki.ubuntu.com/X/RadeonKMS | 14:14 |
| apw | thats not helpful ... can you confirm its not going to work, as i am about to upload and can turn it back off | 14:15 |
| tormod | I guess whoever told you at UDS, meant "should be generally supported" | 14:15 |
| apw | that page doens't say its not supported in userspace, it just says to use a lucid kernel to enable it | 14:16 |
| tormod | what happens now is that X start, causes loading of radeon, but checks for KMS support before it is there | 14:16 |
| tormod | read on | 14:16 |
| tormod | so X goes on to think there is no KMS and does its own modesetting as well... | 14:16 |
| apw | hrm, what a mess. | 14:17 |
| tormod | should not be a big problem to fix it, but now with KMS on by default it will become so much more urgent | 14:17 |
| apw | so do i leave it enabled to encourage you x-types to fix it :) or do i turn it off again | 14:18 |
| tormod | upstream/fedora admitted they gave up to make it switchable by user | 14:19 |
| tormod | you see my upstream hack on that wiki page, we could do something like that for now | 14:20 |
| * apw is unimpressed. i was getting messages that radeon kms was ready | 14:20 | |
| apw | i am uploading a rebase kernel shortly which will be whats in alpha1 most likely | 14:21 |
| tormod | the radeon part yes, lucid no | 14:21 |
| apw | so i need a decision on whether its on or off for alpha-1 i guess | 14:21 |
| tormod | how much time do we have on that decision? | 14:22 |
| apw | i was planning the upload in a couple of hours, but i can hold it a while | 14:22 |
| apw | but we're unlikely to get another upload in after that before alpha-1 | 14:22 |
| tormod | I have been forcing KMS on manually for so long, so I missed the change in kernel configuration | 14:23 |
| tormod | which, again, was not mentioned in the changelog AFAICS | 14:24 |
| tormod | apw, I wonder how this works so effortlessly with intel, any clue? | 14:26 |
| apw | intel put a lot of effort into it? | 14:27 |
| apw | * Revert "SAUCE: default ATI Radeon KMS to off until userspace catches up" | 14:27 |
| apw | that was the first changelog entry on 2.632-6.7 | 14:27 |
| apw | ok the freeze is tuesady ... the kernel takes about 2 days to get into the archive, so i need to get it up tommorrow at the very latest to hit the deadline | 14:28 |
| tormod | apw, wow that was 2.6.31-2.15 so long back I did not even look | 14:29 |
| apw | ? no we defautled it off back then | 14:29 |
| apw | i undid the off so it defaults to the default of on, for the previous lucid upload | 14:29 |
| tormod | apw, oh yes sorry | 14:29 |
| tormod | apw, and the un-SAUCE did not get mentioned | 14:30 |
| apw | ? | 14:30 |
| apw | whats an un-sacue | 14:30 |
| tormod | that revert, I don't see it | 14:31 |
| apw | i cut that from the published changelog | 14:31 |
| apw | https://edge.launchpad.net/ubuntu/+source/linux/2.6.32-6.7 | 14:31 |
| apw | but yes, i should have put more info in the annoucenment | 14:32 |
| apw | i thoought bryce was aware and ready for it | 14:32 |
| tormod | I am reading /usr/share/doc/linux-image-2.6.32-5-generic/changelog.Debian.gz | 14:32 |
| apw | thats -5 ? | 14:32 |
| * tormod hides | 14:33 | |
| tormod | so I understand it just happened | 14:34 |
| tjaalton | tormod: what exactly are we missing from userspace? | 14:34 |
| apw | yep, we had a UDS discussion on it and it was an action on the kernel team to turn it on | 14:34 |
| tormod | something that makes sure kms is initialized before starting X | 14:34 |
| apw | so i turned it on :) | 14:35 |
| tormod | apw, ok good boy :) | 14:35 |
| apw | seems that the action should have been 'wait for userspace to be ready, and turn it on' | 14:35 |
| tjaalton | so we just need to fix it before tuesday? :) | 14:35 |
| tjaalton | userspace that is | 14:35 |
| tormod | tjaalton, yes, and make sure we know we can fix it by then, today | 14:35 |
| apw | you need to decide if you can fix it by tuesday, by tommorrow am | 14:35 |
| tjaalton | ah, right | 14:36 |
| tjaalton | ok | 14:36 |
| tjaalton | plenty of time | 14:36 |
| tormod | yes I would say it should not be a problem | 14:36 |
| apw | the sooner the better, as if i have to respin all the kernels i've just done, i have a days work to do | 14:36 |
| apw | and its has to be done by tommorrow end | 14:37 |
| tjaalton | tormod: so it's the ddx that needs to be taught about kms if it's enabled? | 14:37 |
| tjaalton | tormod: maybe we should move this to #ubuntu-x | 14:38 |
| tormod | tjaalton, yes the ddx checks the sys tree, but does it too fast | 14:39 |
| rtg | apw, I wouldn't hold up everyone else for Radeon KMS issues. I suggest going with what is enabled in user space right now, and we'll get to it after A1. | 14:39 |
| apw | so i'll re-disable it then ... | 14:40 |
| tormod | rtg, we have known user-space workarounds though | 14:40 |
| rtg | apw, Bryce should be online in an hour or so. This is a config issue, so should not affect your rebase against 2.6.32, right? You can consult with him as well. | 14:43 |
| apw | rtg the rebase is done and ready for upload, pending this change ... so yep will wait on bryce | 14:44 |
| apw | Keybuk, about? | 15:14 |
| Keybuk | apw: yes :p | 15:34 |
| apw | Keybuk, i have a patch which makes kms init async whcih is one of the boot performance patches that have been suggested | 15:35 |
| Keybuk | we have the drm stuff as modules | 15:35 |
| Keybuk | does it make much a difference there? | 15:35 |
| Keybuk | I would have thought that's the kind of patch that'd only make a difference if you compiled the driver in | 15:36 |
| apw | Keybuk, to be honest i have no idea, tseliot claimed so ... but the issue i was seeing with it | 15:36 |
| apw | was that the intereaction with the probe of vga16b ... | 15:37 |
| apw | i was getting that loading before the fbcon0 and losing kms as a result | 15:37 |
| apw | and i hear radeon may already be async | 15:37 |
| apw | so just wanted to make you aware | 15:37 |
| mjg59 | You're seriously falling back to vga16fb? | 15:38 |
| Keybuk | mjg59: can you think of a better *fb to fall back to? | 15:43 |
| mjg59 | Well, if falling back to an fb is a design requirement, vga16fb is the best choice | 15:43 |
| Keybuk | apw: yeah, that's the kind of issue I would have expected | 15:43 |
| mjg59 | There are some machines we never got it working on, though | 15:43 |
| Keybuk | as long as the module init claims the device, it's fine | 15:43 |
| Keybuk | mjg59: right, it's the best fallback that avoids text mode | 15:43 |
| Keybuk | 16 colours is enough for a little B&W ubuntu logo in the middle | 15:43 |
| mjg59 | Yeah | 15:44 |
| Keybuk | and that was enough for me to persuade Mark that we really should kill usplash now | 15:44 |
| mjg59 | Using Plymouth? | 15:44 |
| Keybuk | the "text mode if you don't have KMS" was always the big issue with plymouth | 15:44 |
| Keybuk | right | 15:44 |
| mjg59 | You've taught it to use vga16? | 15:44 |
| Keybuk | mjg59: didn't take much teaching | 15:44 |
| Keybuk | plymouth already had a frame-buffer backend | 15:44 |
| Keybuk | (as well as the DRM one it uses for KMS) | 15:44 |
| mjg59 | Yeah, it's just a matter of writing the right kind of packed stuff | 15:45 |
| mjg59 | Unless you want to do scrolling | 15:45 |
| === bjf-afk is now known as bjf | ||
| mjg59 | Adding extra things to bogl's vga16fb backend wasn't fun | 15:45 |
| Keybuk | yeah I stole some code form bogl to that | 15:45 |
| Keybuk | but tbh, we literally just paint a logo etc. | 15:45 |
| Keybuk | so it wasn't hard | 15:45 |
| mjg59 | Yeah, it shouldn't be too much of a problem | 15:46 |
| mjg59 | I just wish I knew why it failed on the VIA craptop | 15:46 |
| Keybuk | I have it using a special plugin rather than the default, etc. | 15:46 |
| Keybuk | apw: so, on the whole ISA thing I missed | 15:46 |
| Keybuk | mjg59's memory matches my own | 15:46 |
| Keybuk | we use PNPACPI on ACPI-based systems, which have acpi:PNP* module aliases | 15:46 |
| Keybuk | and we use PNPBIOS on non-ACPI systems, which *you* patched to have the pnp:PNP* module aliases :p | 15:46 |
| Keybuk | so I'm not sure if we even use ISAPNP for anything | 15:47 |
| Keybuk | like mjg59 says, no module would get auto-loaded as a result of having it | 15:47 |
| Keybuk | do you need it if you force-load a sound card module? | 15:47 |
| mjg59 | Yes, if you want automatic resource allocation to work | 15:47 |
| Keybuk | will they not use the PNPACPI or PNPBIOS code? | 15:48 |
| mjg59 | Not if it's an ISAPNP device | 15:48 |
| mjg59 | Ie, plugged into an ISA slot, not just an on-board ISA device | 15:48 |
| Keybuk | right | 15:48 |
| Keybuk | old sound blaster stuff | 15:48 |
| mjg59 | Yeah | 15:48 |
| mjg59 | Which, well | 15:49 |
| Keybuk | would there be a problem with doing isapnp_init as an async thing? | 15:49 |
| mjg59 | I was going to say "You'd need to do it before any ISA drivers tried to allocate resources", then realised that those drivers won't bind unless (a) isapnp_init has run, or (b) the user has supplied module options, in which case you don't need the pnp code | 15:50 |
| === hggdh_ is now known as hggdh | ||
| Keybuk | so the question there would be, would the module load fail? | 15:53 |
| Keybuk | or would the module load, and leave the driver unbound | 15:53 |
| * Keybuk suspects the former | 15:53 | |
| mjg59 | What would trigger the module load? | 15:54 |
| mjg59 | Are you ever going to load a module before the async calls have finished? | 15:54 |
| Keybuk | one assumes /etc/modules | 16:02 |
| Keybuk | so no | 16:02 |
| Keybuk | the only issue would be if someone compiles in a driver | 16:02 |
| Keybuk | and if they're doing that, they'll probably fail to base it off the ubuntu kernel source anyway | 16:02 |
| mjg59 | If it's compiled in, it won't be bound until isapnp discovery is complete | 16:03 |
| mjg59 | Because otherwise it's got no way of knowing that there's hardware for it to bind to | 16:03 |
| Keybuk | good point | 16:03 |
| Keybuk | so there shouldn't be any risk then | 16:03 |
| mjg59 | Right | 16:03 |
| apw | i cna say i tried to make the call async and got a big fat hang | 16:27 |
| apw | Keybuk, ^^ | 16:27 |
| Keybuk | what was the hang? | 16:30 |
| apw | didn't investigate yet, it was a hard hang under usplash | 16:31 |
| Keybuk | huh | 16:36 |
| Keybuk | that's odd | 16:36 |
| Keybuk | usplash doesn't tend to run until after the kernel | 16:37 |
| apw | Keybuk, yeah that doesn't make sense now does it | 16:37 |
| apw | i'll need to redo that test | 16:37 |
| Keybuk | are you sure you didn't just trip into one of our other bugs that happens from time to time? :p | 16:37 |
| apw | no not at all sure | 16:37 |
| Keybuk | like the gdm-not-starting one? :p | 16:37 |
| apw | Keybuk, heh perhaps | 16:38 |
| apw | Keybuk, i will go for a repeat test | 16:41 |
| === chuck_ is now known as zul | ||
| === hggdh_ is now known as hggdh | ||
| * BenC1 is unimpressed that so many pata/sata drivers are built in to the kernel now | 19:52 | |
| BenC1 | especially considering I am getting conflicts between two drivers that I cannot resolve because I cannot blacklist/unload a module | 19:52 |
| === chuck_ is now known as zul | ||
| rtg | BenC1, you've been sacrificed on the alter of boot speed. | 19:55 |
| BenC1 | rtg: libata+ahci is good for boot speed | 19:55 |
| BenC1 | rtg: pata-acpi built-in is not :-/ | 19:55 |
| BenC1 | in fact, pata-acpi is a failsafe, why it's built-in is not even clear to me | 19:56 |
| === BenC1 is now known as BenC | ||
| rtg | could be it just got peanut buttered into the general effort to improve boot performance by building inn boot essential devices. | 19:56 |
| BenC | rtg: there's like bcollins@maclara:rce/stuff/ubuntu-karmic$ grep 'CONFIG_SATA_.*=y' /boot/config-2.6.31-15-generic | wc -l | 19:57 |
| BenC | 12 | 19:57 |
| BenC | bcollins@maclara:rce/stuff/ubuntu-karmic$ grep 'CONFIG_SATA_.*=m' /boot/config-2.6.31-15-generic | wc -l | 19:57 |
| BenC | 3 | 19:57 |
| BenC | rtg: I mean really, why not just build them all in at that point? | 19:57 |
| rtg | BenCis nVidia one of them? I think it was a problem driver | 19:58 |
| BenC | rtg: nv is built-in, but I am not running that | 19:58 |
| rtg | nope, VIA, MV, and SVW | 19:59 |
| BenC | rtg: my problem is I have a promise card that pata-acpi is stepping all over | 19:59 |
| rtg | BenC: send a patch, maybe Stefan will SRU it. | 20:00 |
| BenC | $ grep 'CONFIG_PATA_.*=y' /boot/config-2.6.31-15-generic | wc -l | 20:00 |
| BenC | 33 | 20:00 |
| BenC | that one just scares me | 20:01 |
| BenC | rtg: well, I haven't even verified that removing pata-acpi will fix it, but finding out will take a kernel recompile | 20:02 |
| rtg | BenC: I assume you remember how :) | 20:02 |
| johanbr | Do the mainline kernel builds have as much stuff built-in? | 20:02 |
| BenC | lol | 20:02 |
| rtg | johanbr, likely, though I haven't looked too close. I'm pretty sure Andy started with an Ubuntu config to build the mainstream kernel. | 20:03 |
| smb | Yeah he does | 20:03 |
| smb | Base is the current ubuntu config + anything new used with default values | 20:04 |
| BenC | rtg: I really hope you guys revisit this idea...I was pretty sure when we discussed this initially that the idea was to only include actual hardware drivers that would benefit the large majority of users | 20:05 |
| BenC | tossing in random things doesn't seem helpful at all | 20:05 |
| smb | BenC, help us to remember with mails to the list. Its less volatile than irc | 20:08 |
| BenC | smb: this was all discussed at UDS/jaunty, IIRC | 20:09 |
| rtg | BenC: I got no problem with that. Its likely I didn't understand the ramifications of building in the PATA stuff. | 20:10 |
| smb | Me neither. It just better to have somewhere a written down explanation to ourselves as we tend to forget things | 20:12 |
| BenC | smb, rtg: Filed a general bug on the subject of built-in storage drivers | 20:36 |
| BenC | Bug #492078 | 20:36 |
| ubot3 | Malone bug 492078 in linux "Building in random drivers hurts the majority" [Undecided,New] https://launchpad.net/bugs/492078 | 20:36 |
| rtg | BenC ack | 20:37 |
| smb | ok, ta | 20:37 |
| dyek | Hi! I want to run Ubuntu 9.10 as Xen guest on top of Fedora 12's Xen VM (considering 64-bit Xen host or alternatively 32-bit). Does anybody know if standard Ubuntu desktop kernel support Xen guest? If not, is it easy to accomplish what I want? | 21:56 |
| rwt | hello | 23:01 |
| jjohansen | dyek: it should run fine as a pvops guest | 23:10 |
| dyek | jjohansen: Thanks! It sounded like I can just use Cento5's Dom0 (recent Fedora release is still missing Dom0 support) and run Ubuntu desktop as one Xen guest. I'll try it out. | 23:19 |
| jjohansen | dyek: yeah it should work, I have booted as a guest under Centos5 | 23:20 |
| dyek | Cool! Thanks! | 23:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!