[00:01] RAOF: Sarvatt: there's some code here that I think we could duplicate for our purposes somewhat: http://lxr.linux.no/linux+v2.6.33/drivers/video/fbmem.c#L1509 [00:01] it seems to destroy framebuffers that are already registered if a superseding one is found [00:01] what we need is a fb priority [00:02] where vga16fb = 0, vesafb = 10, intel, nouveau, radeon = 20 [00:02] and we need to kick off lower prio framebuffers and prevent lower prio framebuffers from being added on after higher prio fbs [00:03] does that make sense? [00:04] I think that's overcomplicated. Our proper kms drivers are already loading first, and claiming devices. I think this could be fixed more simply by vga16fb actually checking whether it can claim a device. [00:04] I'm just not familiar enough with kernel internals to work out how to do that. [00:06] RAOF: see, that makes sense, except why did the dual gpu case have vga16fb grab the fb first? [00:07] so I'm thinking that there's a race condition in the loading of the modules [00:07] Yeah, that's possible to. [00:07] the vga16fb module may be loaded second, but it registers first [00:07] But claiming the fb != claiming the device. [00:08] RAOF: I'm not sure I follow [00:09] I'm fairly sure that one problem is that vga16fb doesn't actually claim any hardware; it just grabs a pointer to the VGA memory and goes nuts writing in it. [00:09] When it loads fast enough to get fb0, that results in the poor kms driver having all sorts of card state overwritten, because things actually write to fb0. [00:10] When it loads and claims fb1, that's not such an issue; nothing's trying to output on fb1, so vga16fb doesn't scribble over interesting state. [00:10] s/claims fb1/gets assigned fb1/ [00:10] RAOF: still, we don't want it at all, cause if someone does try to access fb1 it'll mess things up, right? [00:11] Right; I think that's what lshw is triggering. [00:11] seems like something in the logic deciding which device to use and by the time its set up both enough to be ready to allocate fb's to them vga16fb already loaded, yeah [00:11] so that's where I think we need a fb priority [00:12] so that we can kick off vga16fb when nouveau comes after, or prevent vga16fb if nouveau comes first [00:12] So, if vga16fb actually tried to claim a VGA device, in the sense of “let me scribble on this device iff no other driver thinks it can scribble on it”, then we'd be ok. vga16fb would fail to load, because the kms driver has already claimed the hw. [00:13] RAOF: is your comment in reference to the priority implementation, or some other mechanism [00:14] Some other mechanism. I *know* drivers have the ability to claim hardware, because nouveau prevents nvidia from loading because nouveau's claimed the hardware. [00:15] RAOF: yes, but the problem here is: what if vga16fb claims the hw first? [00:15] it would prevent other drivers from working [00:16] I think other framebuffer drivers actually have code to not screw up KMS and vga16fb just wasnt updated too [00:16] * cnd goes back to lxr [00:16] like efifb will hand off control over to a KMS driver right [00:17] in 2.6.33 at least, not lucid's kernel [00:18] yeah - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4410f3910947dcea8672280b3adecd53cec4e85e and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=89f3f2199084a160a3a45fa6d9af235696321758 [00:19] cnd: Yes, in that case vga16fb would prevent other drivers from working. I think we're safe there because modules.order should ensure the kms driver starts loading first, and I think they claim hardware early. [00:19] Sarvatt: AHHH! they use that exact block of code I found [00:19] info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE; [00:20] the FBINFO_MISC_FIRMWARE says "destroy me if another fb registers the same space" [00:20] * RAOF stands corrected. [00:20] so basically it's a binary priority like I suggested [00:22] so this looks fairly simple [00:22] just port the changes to vga16fb [00:22] I'll take a look at it [00:23] Great! Thanks. [00:28] thanks for looking at it cnd, I'm swamped at the moment and can't mess with it === jussi01 is now known as Guest4656 === kamalm is now known as kamalm-away [02:18] cnd: Do you have a bug # about vga16fb in mind? I'm wandering through the -intel bugs, and I think I've found some duplicates of that behaviour (multi gpu, vga16fb incorrectly claims fb0). [02:19] RAOF: no [02:19] I just tried a test kernel, but it didn't work :( [02:19] :( [02:19] gotta figure out what went wrong === sconklin is now known as sconklin-gone [02:21] RAOF: actually, I think it would work [02:21] If only...? [02:21] the current logic unregisters a fb if a better one comes along [02:22] but it doesn't prevent vga16fb from registering after a hw fb [02:22] so I've fixed up vga16fb, but I need to fix up the register_framebuffer logic [02:24] You didn't make any change to fbmem.c? (Which seems to be where the registration happens) [02:27] RAOF: the change I made for the kernel I just tested was to enable handoff in vga16fb [02:27] now I'm changing fbmem [02:27] Ah, right. [02:44] I've moved bug #518387 over to linux for the vga16fb framebuffer fixes. There's also bug #527369 with very different symptoms and almost certainly the same cause. [02:44] Malone bug 518387 in linux "vga16fb sometimes claims fb0 before kms driver, a causing blank screen on boot" [High,Confirmed] https://launchpad.net/bugs/518387 [02:44] Malone bug 527369 in linux "sudo lshw causes console to turn blue on dell inspiron 1011 and fujitsu livebook T4410" [High,Triaged] https://launchpad.net/bugs/527369 [02:46] RAOF: thanks [02:47] kengyu: around? [02:47] I see you've taken bug 527369 [02:47] Malone bug 527369 in linux "sudo lshw causes console to turn blue on dell inspiron 1011 and fujitsu livebook T4410" [High,Triaged] https://launchpad.net/bugs/527369 [02:47] I'm working on a couple patches to fix it [02:48] hopefully I'll have some results in a bit [02:48] if you haven't done much, feel free to reassign it to me [02:50] kengyu: RAOF: going down for testing. if you don't see me back in a few mins I hosed my laptop and won't bother with it till tomorrow :) [02:50] :) [02:52] That looks promising :) [02:53] well, mostly cause it still didn't work right... [02:53] I still got me /dev/fb1 [02:55] I'll have to do some printk debugging tomorrow [02:55] I'll post any updates in the bugs (hopefully in the form of a test kernel) [02:55] Huzzah! [05:14] JFo, btw I'm bumping some bugs over from radeon that needs quirk fixes in the drm, probably easy bugs. Search for 'pll' in the linux bug list and they'll show up [05:15] JFo, I don't think the bug reports are dupes, they are just different hardware that all need the same quirk or whatever [05:15] JFo, they're all RV530/RV515 systems [05:45] JFo: is there a tag to be used when a patch fixing a bug is CCed to stable@k.o? [05:46] JFo: e.g., bug 502226 [05:46] Malone bug 502226 in linux "Audio Stops, video speeds up" [Undecided,Triaged] https://launchpad.net/bugs/502226 [05:46] JFo: to clarify, these are external patches lacking BugLink links in the git commit msg === Guest4656 is now known as jussi01 [08:29] Hey all [08:30] I made a change locally to ubuntu-lucid/drivers/staging/rt2870 [08:30] can I recompile just that driver and load it ? [08:31] so far I've been using debian/rules to recompile and install, which is kinda slow for each small change [08:36] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/545585 << are you aware of this bug ? [08:36] JohnFlux, You might carefully use "make O=./debian/builds/build-generic" (or whatever flavour you are compiling) if you did not clean up after the last full build [08:36] Malone bug 545585 in linux "lucid iwlagn free more than tfds_in_queue" [Undecided,Confirmed] [08:36] bigon, No [08:38] it's spamming dmesg a lot [08:38] bigon, Actually not from the header. But I know there seem to be problems with dropping the connection [08:39] smb: let me se if I get connexion drop [08:40] bigon, At least the bug report you mention says something about drops. But the other reports seem to be either less or worse impacted. And without the message about tdfs_in_queue [08:43] cooloney: ericm_: it seems like the VFP patch from Imre that you included isn't yet ack'ed by Russell [08:44] bug 507503 [08:44] Malone bug 507503 in linux-mvl-dove "VFP/NEON state is not preserved around signal handlers, causing state corruption between user processes" [High,Fix released] https://launchpad.net/bugs/507503 [08:44] specifically, he noted some problems with the patches [08:46] bigon, Ah, ok. Finally went through the whole report. Seems the message itself might be a different issue. But I try to get a test kernel prepared for the proposed patch [08:48] smb: great [08:59] smb: cd [09:00] smb: /home/johnflux/ubuntu-lucid is not clean, please run 'make mrproper' [09:00] JohnFlux, you are now in $HOMe [09:01] :) [09:01] smb: it says that when I do the make command that you said [09:01] with O= (careful never do mrproper) [09:01] smb: yes, with the O= [09:02] smb: I assumed you meant /build/ instead of /builds/ [09:02] ~/ubuntu-lucid (master)$ make O=./debian/build/build-generic [09:02] I'm doing that [09:02] As I tried to get the dirs from my memory likely [09:03] maybe that needs a C= too... give me a sec [09:14] JohnFlux, Hm, it seems to work for me. Potentially you could use $(pwd) instead of . (thought that should not change much). [09:15] smb: I'm just doing "make modules" instead. Any reason to not do it the old fashioned way? [09:16] JohnFlux: if you're getting the 'make mrproper' message, you've probably run make in the ubuntu kernel directory without the O= [09:16] JohnFlux, But I think, when you did call make once wrong without O= it can spoil things. If you call make modules you do that [09:16] amitk, I was thinking that [09:17] best to save your changes as a commit, reset the git tree and reapply the commit again [09:17] hmm [09:17] JohnFlux, You could recover by mv'ing debian one level up. Then call make mrpropoer and then mv debian back [09:17] JohnFlux, builds with O= and without don't mix well [09:17] I could just use 'make modules' instead right? [09:17] and not bother with the debian packages? [09:18] yeah [09:18] Then you use a different configuration, get different function checksums and your module won't laod [09:18] amitk, no [09:18] but assuming you copy the .config correctly [09:18] I copied /boot/config-blah [09:18] amitk, You need the right symversions [09:18] I think it was the right .config [09:19] and I built the kernel with AUTOBUILD=1 wasn't that to do with checksums or something? [09:19] smb: aah right, I thought he was just test compiling. The compiled modules won't work on the ubuntu kernel for shit [09:19] And the symversions are only created by a full build, after that you could use that for incrementals [09:20] JohnFlux, I'd run a full build once, then use "make O=$(pwd)/debian/build/build-generic modules [09:20] for the incrementals [09:20] do I need to prepend AUTOBUILD=1 to that? [09:20] JohnFlux, AUTOBUILD is a herring rouge with lucid [09:20] I don't think it has any effect [09:21] JohnFlux, You just need a "fakeroot debian/rules binary-generic" run once [09:22] ...after resetting the tree [09:23] amitk, right. After doing a make modules in there [09:24] okay thanks - I'll give that a try [11:46] crimsun, sounds good, I'll look at them today [11:47] I don't know of a tag that we could use on them [11:47] rather bryceh :) [11:47] <-still half asleep [11:51] bryceh, I see 9 bugs. That sound about right? [12:38] I. AM. BRILLIANT! [12:38] smb: okay, so I got my hardware working with a one line change [12:39] smb: just a simple case of adding the USB_DEVICE to the code [12:40] smb: any chance I can just ask someone here to add the change? [12:40] It would be great if this works out of the box for 10.04 [12:41] The preferred way would be to send it upstream. But for a start send it for discussion to kernel-team@list.ubuntu.com. It also helps to have a bug report open to refer to. [12:46] yep, there's an open bug report about it [12:50] smb: okay I wrote up my summary on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/441990 [12:50] Malone bug 441990 in linux "Buffalo WLI-UC-GN 802.11n USB-WiFi adapter non functional" [Undecided,Confirmed] [12:52] JohnFlux, Cool, thanks. If you either attach your patch there and/or send it with a reference to the bug to the mailing list to indicate there is a simple fix for that. Makes it a bit simpler to not loose things [13:00] smb: done [13:00] smb: I mean, I've sent an email to the mailing list [13:01] hmm the email bounced [13:01] JohnFlux, Ok, thanks. :) [13:01] Hm, did I give the wrong address [13:01] no, I've subscribed etc [13:03] smb: should I create a proper git format-patch for it? It's so small it didn't seem worth it [13:03] smb: did my email send correctly ? [13:03] smb: "Trivial patch for supporting.." [13:03] JohnFlux, Yep, its there [13:03] okay good [13:03] smb: so, should I send this 'upstream' as well? [13:04] smb: does the email contain sufficient info? [13:05] JohnFlux, For start its enough info. You should send it upstream. But then it needs a proper patch and go to the right people. Also I would add a CC: stable@kernel.org in the section where you put your signed-off-by [13:05] Give me a sec, lets see who should get it [13:06] smb: reading the TODO file in the directory, it says to not bother the kernel people [13:06] Oh, staging, then Greg [13:06] smb: okay done - I've forward the email to him [13:06] Err, he probably wants proper format [13:06] Even for such small thing [13:07] hmm [13:07] He can afford to be lazy :) [13:07] I guess, but it's such a pain to get git to send via gmail [13:07] I can never remember how to get send-imap working [13:07] :-) [13:07] JohnFlux, I could forward it in your name and put your credentials into it [13:08] that would be good thanks :) [13:08] could you put both lines in [13:08] both the changes that I suggest [13:09] JohnFlux, Yep, either that or make two small patches of it. Do you have the other hw as well? [13:10] nope [13:10] but I gave a link where several users say it works for them [13:10] Ah ok. Guess that should be enough === sconklin-gone is now known as sconklin [13:52] crimsun, we can use patched-upstream if you think that is descriptive enough [14:21] smb: there's some bugs where the vga16fb poorly interacts with other framebuffers [14:22] there's some logic to kick off generic framebuffers if a hw-specific fb comes along [14:22] but that logic is based on the aperture location overlapping between the generic fb and the hw fb [14:23] it seems that vga16fb, with its hardcoded aperture location, does not overlap with hw-specific fb aperture locations [14:23] I'm thinking of modifying the code that kicks a generic framebuffer off to do the same to vga16fb any time a new fb comes along [14:23] do you have any insight or thoughts? [14:24] Ok, so that does not work. I don't know off my memory whether we build in vga16fb or not. I had the feeling its module but loadded by early userspace [14:24] smb, we build it as a module [14:24] there's two problems [14:24] 1: there's a race condition where in dual gpu nvidia systems vga16fb somehow gets /dev/fb0 even though its loaded after nouveau [14:25] 2: even if nouveau gets /dev/fb0 and vga16fb claims /dev/fb1, if you run lshw as root it does something to /dev/fb1 that screws up the vt [14:25] so ideally we want vga16fb to be usable if there's no other fb available, but we want to kill it if there is [14:26] and really, any fb is better than vga16fb, so it makes sense to me to kill it if any other fb comes along [14:26] even vesafb [14:27] cnd, That might be something to discuss with Keybuk. He knows the plumbing layer bringing up the fbs and stuff like that [14:27] smb, I think we're below the plumbing layer though [14:28] basically, I think we need to decide whether this approach is reasonable, because vga16fb is unmaintained upstream [14:28] I'll send out an e-mail to linux-kernel [14:28] but we may need to decide this ourselves [14:29] And I am probably not so much help there. Yes, that might be a better idea. Though you probably want also to be sure there is nohing hard loading vga16fb [14:29] For whatever reason. And understand that reason [14:29] smb, what do you mean by "hard loading" [14:30] modprobe vga16fb [14:30] cnd: what kind of timescale are you thinking? [14:30] smb: nothing should do that, we load vga16fb by alias [14:30] Keybuk: what do you mean by that? [14:30] cnd: for the modifications you're talking about to vga16fb [14:30] Keybuk, Ok, just wanted us to be sure [14:30] it sounds like the kind of project that would take longer than we have left before kernel freeze? [14:31] Keybuk: well, the modifications aren't very much, so I can have a patch ready by end of today [14:31] we're talking about 10 lines of code max [14:31] but I defer to you and smb as to whether that's still acceptable [14:31] but the "kick the generic framebuffer out" code in our current kernel is broken, right? [14:31] it works in .34 [14:31] but not in .32 [14:32] Keybuk: it seems to be all there to me [14:32] it isn't [14:32] breaks nouveau iirc [14:32] cnd, Keybuk Well to me this sounds like it should not be hasted then [14:32] Keybuk: are you referring to vga16fb? [14:32] ok [14:32] let me back up a second [14:32] cnd, Is blacklisting vga16fb a workaround? [14:32] smb: NO! [14:33] would it help if I explained for a moment why we're doing things the way we are right now [14:33] smb, we can't blacklist otherwise we can't fallback to vga16fb if its the only thing that works [14:33] and how we'd prefer to do them if we could [14:33] Keybuk: sure [14:33] ok [14:33] yeah [14:33] so in general we want a framebuffer for our console [14:33] it means we're always using fbcon [14:33] it means our x86 story is the same as our ports story [14:34] and it means we can do things like always fallback to the X fbdev driver if we can't find a better one [14:34] but we can't quite do that today [14:34] so what we do today [14:34] KMS drivers include a framebuffer - so when we auto-load them by alias - we get a framebuffer (win!) [14:34] non-KMS drivers don't by default - so we arranged for vga16fb (most basic fb that works) to also be alias loaded [14:34] but alias loaded *after* anything else first like nouveau, radeon, intel, etc. [14:35] since vga16fb is just a framebuffer to the VGA, it doesn't bind to hardware like those do [14:35] but that has never seemed to be a problem [14:35] you just end up with an fb1 that would draw using the VGA if you reset the video mode back to a VGA mode [14:35] (and the KMS drivers have it in native modes, so you never see it) [14:35] so this works well enough [14:36] we have a framebuffer [14:36] (fb0 is either native or vga16fb) [14:36] so we have fbcon [14:36] and vga16fb is good enough for plymouth [14:36] but isn't good enough for X [14:36] -- [14:36] Keybuk: the problem is there's a race condition we've seen where vga16fb will still get /dev/fb0 (bug 518387) [14:36] how we'd LIKE to do it: [14:36] Malone bug 518387 in linux "vga16fb sometimes claims fb0 before kms driver, a causing blank screen on boot" [High,Confirmed] https://launchpad.net/bugs/518387 [14:36] cnd: why would it cause a blank screen? [14:36] Keybuk: sorry, thought you were done, continue [14:37] if fb0 is vga16fb, that should imply that vga16fb is also what the fbcon is bound to [14:37] and it's what plymouth will draw to [14:37] Keybuk: probably some interaction between nouveau and vga16fb [14:37] so vga16fb winning should mean you lack KMS but not lack anything on screen [14:37] ok [14:37] so... [14:37] what we'd PREFER to have been doing [14:37] grub can set video modes via VBE, and can payload those into the kernel so the kernel knows a video mode has been set [14:37] if that happens, the kernel uses the "efifb" built into it [14:38] (since EFI's "the video mode is set" code is apparently so similar to VBE, it works with BIOS+VBE :p) [14:38] so we'd boot with efifb [14:38] this fails right now because fbcon is a module for some reason [14:38] if fbcon were built-in (like it is on arm, ports, etc.) then we would win [14:39] but with it as a module, if you have a boot failure before the module is loaded, you never see anything on screen after grub [14:39] so, we'd like GRUB to set the video mode, payload it into the kernel, kernel uses efifb from its own init, with a built-in fbcon [14:39] so we have a true colour framebuffer from the get go on all of our platforms [14:40] but then the real KMS driver loads [14:40] and that needs to kick out and transition the console from efifb to i915/nouveau/radeon/etc. [14:40] some of that code is in our kernel [14:40] but there are "it didn't work, make it work" bug fixes in .33 and .34 [14:40] on hardy, is there any chance of adding support for a HP 10 Gb network card (HP NC522SFP; http://is.gd/aYF2r) ? [14:41] I suspect that's the same hand-off code you're talking about for vga16fb [14:41] module (netxen_nic) is in hardy but it doesn't work [14:41] Keybuk: so efifb would be kicked out with the code we have in the kernel, bug vga16fb can't be kicked out like that [14:41] cnd: efifb is not kicked out reliably with the code we have in the kernel *now* [14:41] Keybuk: either way, we still have the issue that vga16fb can't be kicked out using that framework (I think) [14:42] because the vga16fb aperture is a hardcoded 64K block of physical memory [14:42] right [14:42] but the vga16fb aperture is different than what's used by the hw fbs [14:42] yes [14:43] vga16fb is a wildly different type of framebuffer [14:43] so the vga16fb uses 0xA0000-0xB0000, but that never overlaps the nouveau fb at 0x80000000- [14:43] if you were talking to fb0 before, you'd be in planar mode [14:43] and most likely doing raw VGA16 opcodes [14:43] to suddenly have that switched to being a KMS-driven true-colour packed pixel fb would not work so well [14:43] https://bugzilla.kernel.org/show_bug.cgi?id=15151 [14:44] bugzilla.kernel.org bug 15151 in Video(DRI - non Intel) "Black screen after loading nouveau module" [Normal,Closed: code_fix] [14:45] yeah, so basically efifb, with that fix, can be kicked off [14:45] yeah [14:45] but vga16fb can't be kicked off because its aperture will never overlap with hw-specific fb apertures [14:45] though then we'd have to test things like what if grub had the wrong resolution, how do we deal with resolution changes in plymouth, X, etc. [14:45] but once we solve that, and we have efifb => native fb (or just efifb all the way) then we have a great story [14:45] so my thought was: if there's ever another fb loaded, kick off vga16fb [14:45] there's always a framebuffer on x86, always a fbcon, X can always fallback to fbdev [14:46] we only ever do one more switch at grub, we can have grub paint purple ubuntu logos so there's no black screen during boot [14:46] cnd: but how do you kick it off? [14:46] and more to the point, how do you deal with the fact that userspace may have started using the vga16fb fb0? [14:46] Keybuk: in the same code that kicks off other generic fbs, just do it without checking the aperture overlap for vga16fb [14:47] cnd: but that isn't the same [14:47] that's my point [14:47] the "other code" works by handing over fb0 [14:47] so fb0 never vanishes [14:47] just between instructions, the driver that's dealing with it can change [14:47] one minute you're drawing to efifb, the next you're drawing to nouveau [14:47] but you never know [14:48] (modulo resolution changes, etc. see above) [14:48] but you can't hand over fb0 from vga16fb to nouveau [14:48] as you pointed out, the aperture is wrong [14:48] the size of that aperture is wrong [14:48] the resolution is almost certainly wrong [14:48] Keybuk: This is the diff that does the hand off: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4410f3910947dcea8672280b3adecd53cec4e85e;hp=b586640141ab5f4ab3b194419bc2c0f039e91dbc#patch3 [14:48] and vga16fb is a planar framebuffer, not a packed pixel framebuffer! :D [14:48] so the code you use to write it is completely different! [14:49] there's nothing complex there, you just unregister the generic one and register the hw one in its place [14:49] I don't see why you can't just do the same for vga16fb, the only difference is you wouldn't check the aperture bounds first [14:50] because it'd crash any app talking to that framebuffer? [14:50] oh wait, I see what you're saying now [14:51] it's all because the aperture wouldn't be consistent across the transition [14:51] right [14:52] from a kernel POV that patch is almost certainly a good idea [14:52] but from a userspace POV, it won't work at all [14:52] yeah [14:52] I see fb0 turn up, it's vga16fb [14:52] so I mmap the VGA aperture, and I start drawing on it [14:53] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/plymouth/lucid/annotate/head:/src/plugins/renderers/vga16fb/vga.h#L43 [14:53] that's example code from Plymouth that deals with vga16fb [14:53] see how it's actually talking directly to the VGA? :p [14:54] if you rip that frame-buffer out, and replace it with a packed pixel one, plymouth will just crash and burn [14:54] and so would X if that was running [14:54] etc. [14:54] Keybuk: so what do we do if we see that Ubuntu is failing on all nvidia dual gpu systems like in the bug? [14:54] the reason that aperture check is there in the hand-off code (aiui) is precisely because efifb/vesafb and nouveau/etc. *are* compatible [14:55] if you had fb0 mapped from efifb, you have the same address mapped as nouveau would map [14:55] so you can carry on regardless [14:55] yeah [14:55] cnd: well, I'd actually investigate why the nouveau module isn't creating the framebuffer first [14:55] that seems a bit odd [14:55] we already wait for nouveau init to return before trying vga16fb [14:55] cnd, bug 539878 was the one I meant to show you the other day when I was pinging you on LVDS stuff. [14:56] if nouveau init guaranteed it had made its framebuffer before returning, vga16fb would be always fb1 [14:56] Malone bug 539878 in linux "nouveau out of sync LVDS (basically card not supported)" [High,Triaged] https://launchpad.net/bugs/539878 [14:56] sorry for the oversight [14:56] Keybuk: my guess (I could be wrong), is that the probe is asynchronous to the init [14:57] so nouveau inits and registers itself as the module, as does vga16fb [14:57] before nouveau_probe is called [14:57] cnd: yes [14:58] maybe you can add a spinlock or some such so the init doesn't return until the probe finishes, but that sounds messy [14:59] fwiw, it doesn't sound like the other drivers are async init [14:59] and it doesn't sound like nouveau is in the single-card case? [15:00] is it the single-card with dual-gpu case? [15:00] or the dual-cards? [15:00] not sure [15:00] because I have a thought [15:00] about dual-cards [15:00] bear with me a sec: [15:00] dual-cards have, err, dual cards [15:00] the first card is a PCI graphics card, the second is a PCI graphics card [15:00] what might happen is: [15:01] PCI announces first card [15:01] we modprobe nouveau [15:01] nouveau doesn't pick it up (nothing plugged in maybe?) [15:01] we modprobe vga16fb [15:01] vga16fb takes fb0 [15:01] PCI announces second card [15:01] nouveau picks it up, takes fb1 [15:02] Keybuk: sounds plausible, though I'm not sure how that could be fixed... [15:02] right :-/ [15:02] it's a bugger [15:02] I do actually have dual nvidia cards here, so I can test :p [15:02] (and nouveau didn't work for me - this may be why) [15:04] Keybuk: now that I actually look at the bug some more, they don't even have nouveau loaded [15:04] so no wonder things didn't work... [15:05] oh wait, it's an intel bug [15:05] hrm... [15:07] Keybuk, cnd, So I guess this is in good hands between the two of you. At least I understand why we don't want to get rid of vga16fb and that kicking off is not a good idea. [15:08] Keybuk: doesn't seem like we have useful data for that bug yet, the only data we have is pre 2.6.32-16 when we switched to .33 drm [15:09] Keybuk: the one thing we could do is forbid vga16fb from loading if there's already a fb [15:09] apparently, if you run lshw as root on a vt, it does something to vga16fb even if it's /dev/fb1 and causes issues (bug 527369) [15:09] Malone bug 527369 in linux "sudo lshw causes console to turn blue on dell inspiron 1011 and fujitsu livebook T4410" [High,Triaged] https://launchpad.net/bugs/527369 [15:11] possibly [15:19] csurbhi: ping any progress on #276472? [15:24] cnd: the other obvious fix [15:24] vga16fb is loaded by alias [15:24]