| cnd | 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 |
|---|---|---|
| cnd | it seems to destroy framebuffers that are already registered if a superseding one is found | 00:01 |
| cnd | what we need is a fb priority | 00:01 |
| cnd | where vga16fb = 0, vesafb = 10, intel, nouveau, radeon = 20 | 00:02 |
| cnd | and we need to kick off lower prio framebuffers and prevent lower prio framebuffers from being added on after higher prio fbs | 00:02 |
| cnd | does that make sense? | 00:03 |
| RAOF | 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 |
| RAOF | I'm just not familiar enough with kernel internals to work out how to do that. | 00:04 |
| cnd | RAOF: see, that makes sense, except why did the dual gpu case have vga16fb grab the fb first? | 00:06 |
| cnd | so I'm thinking that there's a race condition in the loading of the modules | 00:07 |
| RAOF | Yeah, that's possible to. | 00:07 |
| cnd | the vga16fb module may be loaded second, but it registers first | 00:07 |
| RAOF | But claiming the fb != claiming the device. | 00:07 |
| cnd | RAOF: I'm not sure I follow | 00:08 |
| RAOF | 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 |
| RAOF | 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:09 |
| RAOF | 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 |
| RAOF | s/claims fb1/gets assigned fb1/ | 00:10 |
| cnd | RAOF: still, we don't want it at all, cause if someone does try to access fb1 it'll mess things up, right? | 00:10 |
| RAOF | Right; I think that's what lshw is triggering. | 00:11 |
| Sarvatt | 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 |
| cnd | so that's where I think we need a fb priority | 00:11 |
| cnd | so that we can kick off vga16fb when nouveau comes after, or prevent vga16fb if nouveau comes first | 00:12 |
| RAOF | 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:12 |
| cnd | RAOF: is your comment in reference to the priority implementation, or some other mechanism | 00:13 |
| RAOF | 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:14 |
| cnd | RAOF: yes, but the problem here is: what if vga16fb claims the hw first? | 00:15 |
| cnd | it would prevent other drivers from working | 00:15 |
| Sarvatt | 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 | |
| Sarvatt | like efifb will hand off control over to a KMS driver right | 00:16 |
| Sarvatt | in 2.6.33 at least, not lucid's kernel | 00:17 |
| Sarvatt | 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:18 |
| RAOF | 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 |
| cnd | Sarvatt: AHHH! they use that exact block of code I found | 00:19 |
| cnd | info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE; | 00:19 |
| cnd | the FBINFO_MISC_FIRMWARE says "destroy me if another fb registers the same space" | 00:20 |
| * RAOF stands corrected. | 00:20 | |
| cnd | so basically it's a binary priority like I suggested | 00:20 |
| cnd | so this looks fairly simple | 00:22 |
| cnd | just port the changes to vga16fb | 00:22 |
| cnd | I'll take a look at it | 00:22 |
| RAOF | Great! Thanks. | 00:23 |
| Sarvatt | thanks for looking at it cnd, I'm swamped at the moment and can't mess with it | 00:28 |
| === jussi01 is now known as Guest4656 | ||
| === kamalm is now known as kamalm-away | ||
| RAOF | 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:18 |
| cnd | RAOF: no | 02:19 |
| cnd | I just tried a test kernel, but it didn't work :( | 02:19 |
| RAOF | :( | 02:19 |
| cnd | gotta figure out what went wrong | 02:19 |
| === sconklin is now known as sconklin-gone | ||
| cnd | RAOF: actually, I think it would work | 02:21 |
| RAOF | If only...? | 02:21 |
| cnd | the current logic unregisters a fb if a better one comes along | 02:21 |
| cnd | but it doesn't prevent vga16fb from registering after a hw fb | 02:22 |
| cnd | so I've fixed up vga16fb, but I need to fix up the register_framebuffer logic | 02:22 |
| RAOF | You didn't make any change to fbmem.c? (Which seems to be where the registration happens) | 02:24 |
| cnd | RAOF: the change I made for the kernel I just tested was to enable handoff in vga16fb | 02:27 |
| cnd | now I'm changing fbmem | 02:27 |
| RAOF | Ah, right. | 02:27 |
| RAOF | 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 |
| ubot3 | 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 |
| ubot3 | 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:44 |
| cnd | RAOF: thanks | 02:46 |
| cnd | kengyu: around? | 02:47 |
| cnd | I see you've taken bug 527369 | 02:47 |
| ubot3 | 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 |
| cnd | I'm working on a couple patches to fix it | 02:47 |
| cnd | hopefully I'll have some results in a bit | 02:48 |
| cnd | if you haven't done much, feel free to reassign it to me | 02:48 |
| cnd | 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 |
| RAOF | :) | 02:50 |
| RAOF | That looks promising :) | 02:52 |
| cnd | well, mostly cause it still didn't work right... | 02:53 |
| cnd | I still got me /dev/fb1 | 02:53 |
| cnd | I'll have to do some printk debugging tomorrow | 02:55 |
| cnd | I'll post any updates in the bugs (hopefully in the form of a test kernel) | 02:55 |
| RAOF | Huzzah! | 02:55 |
| bryceh | 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:14 |
| bryceh | 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 |
| bryceh | JFo, they're all RV530/RV515 systems | 05:15 |
| crimsun | JFo: is there a tag to be used when a patch fixing a bug is CCed to stable@k.o? | 05:45 |
| crimsun | JFo: e.g., bug 502226 | 05:46 |
| ubot3 | Malone bug 502226 in linux "Audio Stops, video speeds up" [Undecided,Triaged] https://launchpad.net/bugs/502226 | 05:46 |
| crimsun | JFo: to clarify, these are external patches lacking BugLink links in the git commit msg | 05:46 |
| === Guest4656 is now known as jussi01 | ||
| JohnFlux | Hey all | 08:29 |
| JohnFlux | I made a change locally to ubuntu-lucid/drivers/staging/rt2870 | 08:30 |
| JohnFlux | can I recompile just that driver and load it ? | 08:30 |
| JohnFlux | so far I've been using debian/rules to recompile and install, which is kinda slow for each small change | 08:31 |
| bigon | https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/545585 << are you aware of this bug ? | 08:36 |
| smb | 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 |
| ubot3 | Malone bug 545585 in linux "lucid iwlagn free more than tfds_in_queue" [Undecided,Confirmed] | 08:36 |
| smb | bigon, No | 08:36 |
| bigon | it's spamming dmesg a lot | 08:38 |
| smb | bigon, Actually not from the header. But I know there seem to be problems with dropping the connection | 08:38 |
| bigon | smb: let me se if I get connexion drop | 08:39 |
| smb | 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:40 |
| amitk | cooloney: ericm_: it seems like the VFP patch from Imre that you included isn't yet ack'ed by Russell | 08:43 |
| amitk | bug 507503 | 08:44 |
| ubot3 | 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 |
| amitk | specifically, he noted some problems with the patches | 08:44 |
| smb | 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:46 |
| bigon | smb: great | 08:48 |
| JohnFlux | smb: cd | 08:59 |
| JohnFlux | smb: /home/johnflux/ubuntu-lucid is not clean, please run 'make mrproper' | 09:00 |
| smb | JohnFlux, you are now in $HOMe | 09:00 |
| JohnFlux | :) | 09:01 |
| JohnFlux | smb: it says that when I do the make command that you said | 09:01 |
| smb | with O= (careful never do mrproper) | 09:01 |
| JohnFlux | smb: yes, with the O= | 09:01 |
| JohnFlux | smb: I assumed you meant /build/ instead of /builds/ | 09:02 |
| JohnFlux | ~/ubuntu-lucid (master)$ make O=./debian/build/build-generic | 09:02 |
| JohnFlux | I'm doing that | 09:02 |
| smb | As I tried to get the dirs from my memory likely | 09:02 |
| smb | maybe that needs a C= too... give me a sec | 09:03 |
| smb | JohnFlux, Hm, it seems to work for me. Potentially you could use $(pwd) instead of . (thought that should not change much). | 09:14 |
| JohnFlux | smb: I'm just doing "make modules" instead. Any reason to not do it the old fashioned way? | 09:15 |
| amitk | JohnFlux: if you're getting the 'make mrproper' message, you've probably run make in the ubuntu kernel directory without the O= | 09:16 |
| smb | 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 |
| smb | amitk, I was thinking that | 09:16 |
| amitk | best to save your changes as a commit, reset the git tree and reapply the commit again | 09:17 |
| JohnFlux | hmm | 09:17 |
| smb | JohnFlux, You could recover by mv'ing debian one level up. Then call make mrpropoer and then mv debian back | 09:17 |
| smb | JohnFlux, builds with O= and without don't mix well | 09:17 |
| JohnFlux | I could just use 'make modules' instead right? | 09:17 |
| JohnFlux | and not bother with the debian packages? | 09:17 |
| amitk | yeah | 09:18 |
| smb | Then you use a different configuration, get different function checksums and your module won't laod | 09:18 |
| smb | amitk, no | 09:18 |
| amitk | but assuming you copy the .config correctly | 09:18 |
| JohnFlux | I copied /boot/config-blah | 09:18 |
| smb | amitk, You need the right symversions | 09:18 |
| JohnFlux | I think it was the right .config | 09:18 |
| JohnFlux | and I built the kernel with AUTOBUILD=1 wasn't that to do with checksums or something? | 09:19 |
| amitk | smb: aah right, I thought he was just test compiling. The compiled modules won't work on the ubuntu kernel for shit | 09:19 |
| smb | And the symversions are only created by a full build, after that you could use that for incrementals | 09:19 |
| smb | JohnFlux, I'd run a full build once, then use "make O=$(pwd)/debian/build/build-generic modules | 09:20 |
| smb | for the incrementals | 09:20 |
| JohnFlux | do I need to prepend AUTOBUILD=1 to that? | 09:20 |
| smb | JohnFlux, AUTOBUILD is a herring rouge with lucid | 09:20 |
| smb | I don't think it has any effect | 09:20 |
| smb | JohnFlux, You just need a "fakeroot debian/rules binary-generic" run once | 09:21 |
| amitk | ...after resetting the tree | 09:22 |
| smb | amitk, right. After doing a make modules in there | 09:23 |
| JohnFlux | okay thanks - I'll give that a try | 09:24 |
| JFo | crimsun, sounds good, I'll look at them today | 11:46 |
| JFo | I don't know of a tag that we could use on them | 11:47 |
| JFo | rather bryceh :) | 11:47 |
| JFo | <-still half asleep | 11:47 |
| JFo | bryceh, I see 9 bugs. That sound about right? | 11:51 |
| JohnFlux | I. AM. BRILLIANT! | 12:38 |
| JohnFlux | smb: okay, so I got my hardware working with a one line change | 12:38 |
| JohnFlux | smb: just a simple case of adding the USB_DEVICE to the code | 12:39 |
| JohnFlux | smb: any chance I can just ask someone here to add the change? | 12:40 |
| JohnFlux | It would be great if this works out of the box for 10.04 | 12:40 |
| smb | 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:41 |
| JohnFlux | yep, there's an open bug report about it | 12:46 |
| JohnFlux | smb: okay I wrote up my summary on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/441990 | 12:50 |
| ubot3 | Malone bug 441990 in linux "Buffalo WLI-UC-GN 802.11n USB-WiFi adapter non functional" [Undecided,Confirmed] | 12:50 |
| smb | 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 | 12:52 |
| JohnFlux | smb: done | 13:00 |
| JohnFlux | smb: I mean, I've sent an email to the mailing list | 13:00 |
| JohnFlux | hmm the email bounced | 13:01 |
| smb | JohnFlux, Ok, thanks. :) | 13:01 |
| smb | Hm, did I give the wrong address | 13:01 |
| JohnFlux | no, I've subscribed etc | 13:01 |
| JohnFlux | smb: should I create a proper git format-patch for it? It's so small it didn't seem worth it | 13:03 |
| JohnFlux | smb: did my email send correctly ? | 13:03 |
| JohnFlux | smb: "Trivial patch for supporting.." | 13:03 |
| smb | JohnFlux, Yep, its there | 13:03 |
| JohnFlux | okay good | 13:03 |
| JohnFlux | smb: so, should I send this 'upstream' as well? | 13:03 |
| JohnFlux | smb: does the email contain sufficient info? | 13:04 |
| smb | 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 |
| smb | Give me a sec, lets see who should get it | 13:05 |
| JohnFlux | smb: reading the TODO file in the directory, it says to not bother the kernel people | 13:06 |
| smb | Oh, staging, then Greg | 13:06 |
| JohnFlux | smb: okay done - I've forward the email to him | 13:06 |
| smb | Err, he probably wants proper format | 13:06 |
| smb | Even for such small thing | 13:06 |
| JohnFlux | hmm | 13:07 |
| smb | He can afford to be lazy :) | 13:07 |
| JohnFlux | I guess, but it's such a pain to get git to send via gmail | 13:07 |
| JohnFlux | I can never remember how to get send-imap working | 13:07 |
| JohnFlux | :-) | 13:07 |
| smb | JohnFlux, I could forward it in your name and put your credentials into it | 13:07 |
| JohnFlux | that would be good thanks :) | 13:08 |
| JohnFlux | could you put both lines in | 13:08 |
| JohnFlux | both the changes that I suggest | 13:08 |
| smb | JohnFlux, Yep, either that or make two small patches of it. Do you have the other hw as well? | 13:09 |
| JohnFlux | nope | 13:10 |
| JohnFlux | but I gave a link where several users say it works for them | 13:10 |
| smb | Ah ok. Guess that should be enough | 13:10 |
| === sconklin-gone is now known as sconklin | ||
| JFo | crimsun, we can use patched-upstream if you think that is descriptive enough | 13:52 |
| cnd | smb: there's some bugs where the vga16fb poorly interacts with other framebuffers | 14:21 |
| cnd | there's some logic to kick off generic framebuffers if a hw-specific fb comes along | 14:22 |
| cnd | but that logic is based on the aperture location overlapping between the generic fb and the hw fb | 14:22 |
| cnd | it seems that vga16fb, with its hardcoded aperture location, does not overlap with hw-specific fb aperture locations | 14:23 |
| cnd | 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 |
| cnd | do you have any insight or thoughts? | 14:23 |
| smb | 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 |
| cnd | smb, we build it as a module | 14:24 |
| cnd | there's two problems | 14:24 |
| cnd | 1: there's a race condition where in dual gpu nvidia systems vga16fb somehow gets /dev/fb0 even though its loaded after nouveau | 14:24 |
| cnd | 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 |
| cnd | 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:25 |
| cnd | 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 |
| cnd | even vesafb | 14:26 |
| smb | cnd, That might be something to discuss with Keybuk. He knows the plumbing layer bringing up the fbs and stuff like that | 14:27 |
| cnd | smb, I think we're below the plumbing layer though | 14:27 |
| cnd | basically, I think we need to decide whether this approach is reasonable, because vga16fb is unmaintained upstream | 14:28 |
| cnd | I'll send out an e-mail to linux-kernel | 14:28 |
| cnd | but we may need to decide this ourselves | 14:28 |
| smb | 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 |
| smb | For whatever reason. And understand that reason | 14:29 |
| cnd | smb, what do you mean by "hard loading" | 14:29 |
| smb | modprobe vga16fb | 14:30 |
| Keybuk | cnd: what kind of timescale are you thinking? | 14:30 |
| Keybuk | smb: nothing should do that, we load vga16fb by alias | 14:30 |
| cnd | Keybuk: what do you mean by that? | 14:30 |
| Keybuk | cnd: for the modifications you're talking about to vga16fb | 14:30 |
| smb | Keybuk, Ok, just wanted us to be sure | 14:30 |
| Keybuk | it sounds like the kind of project that would take longer than we have left before kernel freeze? | 14:30 |
| cnd | Keybuk: well, the modifications aren't very much, so I can have a patch ready by end of today | 14:31 |
| cnd | we're talking about 10 lines of code max | 14:31 |
| cnd | but I defer to you and smb as to whether that's still acceptable | 14:31 |
| Keybuk | but the "kick the generic framebuffer out" code in our current kernel is broken, right? | 14:31 |
| Keybuk | it works in .34 | 14:31 |
| Keybuk | but not in .32 | 14:31 |
| cnd | Keybuk: it seems to be all there to me | 14:32 |
| Keybuk | it isn't | 14:32 |
| Keybuk | breaks nouveau iirc | 14:32 |
| smb | cnd, Keybuk Well to me this sounds like it should not be hasted then | 14:32 |
| cnd | Keybuk: are you referring to vga16fb? | 14:32 |
| Keybuk | ok | 14:32 |
| Keybuk | let me back up a second | 14:32 |
| smb | cnd, Is blacklisting vga16fb a workaround? | 14:32 |
| Keybuk | smb: NO! | 14:32 |
| Keybuk | would it help if I explained for a moment why we're doing things the way we are right now | 14:33 |
| cnd | smb, we can't blacklist otherwise we can't fallback to vga16fb if its the only thing that works | 14:33 |
| Keybuk | and how we'd prefer to do them if we could | 14:33 |
| cnd | Keybuk: sure | 14:33 |
| Keybuk | ok | 14:33 |
| smb | yeah | 14:33 |
| Keybuk | so in general we want a framebuffer for our console | 14:33 |
| Keybuk | it means we're always using fbcon | 14:33 |
| Keybuk | it means our x86 story is the same as our ports story | 14:33 |
| Keybuk | 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 |
| Keybuk | but we can't quite do that today | 14:34 |
| Keybuk | so what we do today | 14:34 |
| Keybuk | KMS drivers include a framebuffer - so when we auto-load them by alias - we get a framebuffer (win!) | 14:34 |
| Keybuk | non-KMS drivers don't by default - so we arranged for vga16fb (most basic fb that works) to also be alias loaded | 14:34 |
| Keybuk | but alias loaded *after* anything else first like nouveau, radeon, intel, etc. | 14:34 |
| Keybuk | since vga16fb is just a framebuffer to the VGA, it doesn't bind to hardware like those do | 14:35 |
| Keybuk | but that has never seemed to be a problem | 14:35 |
| Keybuk | 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 |
| Keybuk | (and the KMS drivers have it in native modes, so you never see it) | 14:35 |
| Keybuk | so this works well enough | 14:35 |
| Keybuk | we have a framebuffer | 14:36 |
| Keybuk | (fb0 is either native or vga16fb) | 14:36 |
| Keybuk | so we have fbcon | 14:36 |
| Keybuk | and vga16fb is good enough for plymouth | 14:36 |
| Keybuk | but isn't good enough for X | 14:36 |
| Keybuk | -- | 14:36 |
| cnd | Keybuk: the problem is there's a race condition we've seen where vga16fb will still get /dev/fb0 (bug 518387) | 14:36 |
| Keybuk | how we'd LIKE to do it: | 14:36 |
| ubot3 | 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 |
| Keybuk | cnd: why would it cause a blank screen? | 14:36 |
| cnd | Keybuk: sorry, thought you were done, continue | 14:36 |
| Keybuk | if fb0 is vga16fb, that should imply that vga16fb is also what the fbcon is bound to | 14:37 |
| Keybuk | and it's what plymouth will draw to | 14:37 |
| cnd | Keybuk: probably some interaction between nouveau and vga16fb | 14:37 |
| Keybuk | so vga16fb winning should mean you lack KMS but not lack anything on screen | 14:37 |
| Keybuk | ok | 14:37 |
| Keybuk | so... | 14:37 |
| Keybuk | what we'd PREFER to have been doing | 14:37 |
| Keybuk | 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 |
| Keybuk | if that happens, the kernel uses the "efifb" built into it | 14:37 |
| Keybuk | (since EFI's "the video mode is set" code is apparently so similar to VBE, it works with BIOS+VBE :p) | 14:38 |
| Keybuk | so we'd boot with efifb | 14:38 |
| Keybuk | this fails right now because fbcon is a module for some reason | 14:38 |
| Keybuk | if fbcon were built-in (like it is on arm, ports, etc.) then we would win | 14:38 |
| Keybuk | 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 |
| Keybuk | 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 |
| Keybuk | so we have a true colour framebuffer from the get go on all of our platforms | 14:39 |
| Keybuk | but then the real KMS driver loads | 14:40 |
| Keybuk | and that needs to kick out and transition the console from efifb to i915/nouveau/radeon/etc. | 14:40 |
| Keybuk | some of that code is in our kernel | 14:40 |
| Keybuk | but there are "it didn't work, make it work" bug fixes in .33 and .34 | 14:40 |
| pmatulis | on hardy, is there any chance of adding support for a HP 10 Gb network card (HP NC522SFP; http://is.gd/aYF2r) ? | 14:40 |
| Keybuk | I suspect that's the same hand-off code you're talking about for vga16fb | 14:41 |
| pmatulis | module (netxen_nic) is in hardy but it doesn't work | 14:41 |
| cnd | 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 |
| Keybuk | cnd: efifb is not kicked out reliably with the code we have in the kernel *now* | 14:41 |
| cnd | Keybuk: either way, we still have the issue that vga16fb can't be kicked out using that framework (I think) | 14:41 |
| cnd | because the vga16fb aperture is a hardcoded 64K block of physical memory | 14:42 |
| Keybuk | right | 14:42 |
| cnd | but the vga16fb aperture is different than what's used by the hw fbs | 14:42 |
| Keybuk | yes | 14:42 |
| Keybuk | vga16fb is a wildly different type of framebuffer | 14:43 |
| cnd | so the vga16fb uses 0xA0000-0xB0000, but that never overlaps the nouveau fb at 0x80000000-<blah> | 14:43 |
| Keybuk | if you were talking to fb0 before, you'd be in planar mode | 14:43 |
| Keybuk | and most likely doing raw VGA16 opcodes | 14:43 |
| Keybuk | to suddenly have that switched to being a KMS-driven true-colour packed pixel fb would not work so well <g> | 14:43 |
| Keybuk | https://bugzilla.kernel.org/show_bug.cgi?id=15151 | 14:43 |
| ubot3 | bugzilla.kernel.org bug 15151 in Video(DRI - non Intel) "Black screen after loading nouveau module" [Normal,Closed: code_fix] | 14:44 |
| cnd | yeah, so basically efifb, with that fix, can be kicked off | 14:45 |
| Keybuk | yeah | 14:45 |
| cnd | but vga16fb can't be kicked off because its aperture will never overlap with hw-specific fb apertures | 14:45 |
| Keybuk | 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 |
| Keybuk | 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 |
| cnd | so my thought was: if there's ever another fb loaded, kick off vga16fb | 14:45 |
| Keybuk | there's always a framebuffer on x86, always a fbcon, X can always fallback to fbdev | 14:45 |
| Keybuk | 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 |
| Keybuk | cnd: but how do you kick it off? | 14:46 |
| Keybuk | and more to the point, how do you deal with the fact that userspace may have started using the vga16fb fb0? | 14:46 |
| cnd | Keybuk: in the same code that kicks off other generic fbs, just do it without checking the aperture overlap for vga16fb | 14:46 |
| Keybuk | cnd: but that isn't the same | 14:47 |
| Keybuk | that's my point | 14:47 |
| Keybuk | the "other code" works by handing over fb0 | 14:47 |
| Keybuk | so fb0 never vanishes | 14:47 |
| Keybuk | just between instructions, the driver that's dealing with it can change | 14:47 |
| Keybuk | one minute you're drawing to efifb, the next you're drawing to nouveau | 14:47 |
| Keybuk | but you never know | 14:47 |
| Keybuk | (modulo resolution changes, etc. see above) | 14:48 |
| Keybuk | but you can't hand over fb0 from vga16fb to nouveau | 14:48 |
| Keybuk | as you pointed out, the aperture is wrong | 14:48 |
| Keybuk | the size of that aperture is wrong | 14:48 |
| Keybuk | the resolution is almost certainly wrong | 14:48 |
| cnd | 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 |
| Keybuk | and vga16fb is a planar framebuffer, not a packed pixel framebuffer! :D | 14:48 |
| Keybuk | so the code you use to write it is completely different! | 14:48 |
| cnd | there's nothing complex there, you just unregister the generic one and register the hw one in its place | 14:49 |
| cnd | 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:49 |
| Keybuk | because it'd crash any app talking to that framebuffer? | 14:50 |
| cnd | oh wait, I see what you're saying now | 14:50 |
| cnd | it's all because the aperture wouldn't be consistent across the transition | 14:51 |
| Keybuk | right | 14:51 |
| Keybuk | from a kernel POV that patch is almost certainly a good idea | 14:52 |
| Keybuk | but from a userspace POV, it won't work at all | 14:52 |
| cnd | yeah | 14:52 |
| Keybuk | I see fb0 turn up, it's vga16fb | 14:52 |
| Keybuk | so I mmap the VGA aperture, and I start drawing on it | 14:52 |
| Keybuk | http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/plymouth/lucid/annotate/head:/src/plugins/renderers/vga16fb/vga.h#L43 | 14:53 |
| Keybuk | that's example code from Plymouth that deals with vga16fb | 14:53 |
| Keybuk | see how it's actually talking directly to the VGA? :p | 14:53 |
| Keybuk | if you rip that frame-buffer out, and replace it with a packed pixel one, plymouth will just crash and burn | 14:54 |
| Keybuk | and so would X if that was running | 14:54 |
| Keybuk | etc. | 14:54 |
| cnd | 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 |
| Keybuk | the reason that aperture check is there in the hand-off code (aiui) is precisely because efifb/vesafb and nouveau/etc. *are* compatible | 14:54 |
| Keybuk | if you had fb0 mapped from efifb, you have the same address mapped as nouveau would map | 14:55 |
| Keybuk | so you can carry on regardless | 14:55 |
| cnd | yeah | 14:55 |
| Keybuk | cnd: well, I'd actually investigate why the nouveau module isn't creating the framebuffer first | 14:55 |
| Keybuk | that seems a bit odd | 14:55 |
| Keybuk | we already wait for nouveau init to return before trying vga16fb | 14:55 |
| JFo | cnd, bug 539878 was the one I meant to show you the other day when I was pinging you on LVDS stuff. | 14:55 |
| Keybuk | if nouveau init guaranteed it had made its framebuffer before returning, vga16fb would be always fb1 | 14:56 |
| ubot3 | Malone bug 539878 in linux "nouveau out of sync LVDS (basically card not supported)" [High,Triaged] https://launchpad.net/bugs/539878 | 14:56 |
| JFo | sorry for the oversight | 14:56 |
| cnd | Keybuk: my guess (I could be wrong), is that the probe is asynchronous to the init | 14:56 |
| cnd | so nouveau inits and registers itself as the module, as does vga16fb | 14:57 |
| cnd | before nouveau_probe is called | 14:57 |
| Keybuk | cnd: yes | 14:57 |
| cnd | maybe you can add a spinlock or some such so the init doesn't return until the probe finishes, but that sounds messy | 14:58 |
| Keybuk | fwiw, it doesn't sound like the other drivers are async init | 14:59 |
| Keybuk | and it doesn't sound like nouveau is in the single-card case? | 14:59 |
| Keybuk | is it the single-card with dual-gpu case? | 15:00 |
| Keybuk | or the dual-cards? | 15:00 |
| cnd | not sure | 15:00 |
| Keybuk | because I have a thought | 15:00 |
| Keybuk | about dual-cards | 15:00 |
| Keybuk | bear with me a sec: | 15:00 |
| Keybuk | dual-cards have, err, dual cards | 15:00 |
| Keybuk | the first card is a PCI graphics card, the second is a PCI graphics card | 15:00 |
| Keybuk | what might happen is: | 15:00 |
| Keybuk | PCI announces first card | 15:01 |
| Keybuk | we modprobe nouveau | 15:01 |
| Keybuk | nouveau doesn't pick it up (nothing plugged in maybe?) | 15:01 |
| Keybuk | we modprobe vga16fb | 15:01 |
| Keybuk | vga16fb takes fb0 | 15:01 |
| Keybuk | PCI announces second card | 15:01 |
| Keybuk | nouveau picks it up, takes fb1 | 15:01 |
| cnd | Keybuk: sounds plausible, though I'm not sure how that could be fixed... | 15:02 |
| Keybuk | right :-/ | 15:02 |
| Keybuk | it's a bugger | 15:02 |
| Keybuk | I do actually have dual nvidia cards here, so I can test :p | 15:02 |
| Keybuk | (and nouveau didn't work for me - this may be why) | 15:02 |
| cnd | Keybuk: now that I actually look at the bug some more, they don't even have nouveau loaded | 15:04 |
| cnd | so no wonder things didn't work... | 15:04 |
| cnd | oh wait, it's an intel bug | 15:05 |
| cnd | hrm... | 15:05 |
| smb | 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:07 |
| cnd | 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:08 |
| cnd | Keybuk: the one thing we could do is forbid vga16fb from loading if there's already a fb | 15:09 |
| cnd | 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 |
| ubot3 | 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:09 |
| Keybuk | possibly | 15:11 |
| zul | csurbhi: ping any progress on #276472? | 15:19 |
| Keybuk | cnd: the other obvious fix | 15:24 |
| Keybuk | vga16fb is loaded by alias | 15:24 |
| Keybuk | on load, it could check whether the device is one of those supported by nouveau, i915 and radeon, and simply return without enabling | 15:24 |
| Keybuk | actually | 15:25 |
| Keybuk | that would mean no splash for the nvidix-glx crowd | 15:25 |
| cnd | Keybuk: that's fine for ubuntu, but not in general, cause what if the modules aren't available? | 15:25 |
| Keybuk | in which case - don't ship vga16fb anyway | 15:25 |
| Keybuk | which is a "clear with sabdfl" issue | 15:25 |
| JohnFlux | smb: your email didn't have any sort of attachment | 15:27 |
| JohnFlux | smb: was it supposed to? | 15:27 |
| smb | JohnFlux, no, there were two other mails send as threaded mails | 15:27 |
| smb | [PATCH 1/2] Staging: rt2870: Add USB ID for Buffalo AirstationNFinitiWLI-UC-GN | 15:28 |
| smb | [PATCH 2/2] Staging: rt2870: Add USB ID for Ralink 2070L | 15:28 |
| JohnFlux | oh I see. git fixed that behave to add them as replies | 15:28 |
| JohnFlux | hmm, maybe not in a release version of git though | 15:28 |
| JohnFlux | *released | 15:28 |
| JohnFlux | s/behave/behaviour/ | 15:28 |
| smb | JohnFlux, It seems to work. Though Thunderbird is often no so cooperative when they seem to arrive in the wrong order to it | 15:29 |
| JohnFlux | smb: gmail doesn't handle it at all | 15:29 |
| JohnFlux | smb: Anyway, upgrade git when the next release comes out :-) | 15:30 |
| JohnFlux | smb: and thanks | 15:30 |
| smb | JohnFlux, Heh, ok. Np, I try to get it into next upload (path 1) as sort of pre-stable. The other one I really would love to see some confirmation first | 15:31 |
| JohnFlux | can you post your .deb somewhere? And i'll ask people to try them directly? | 15:32 |
| JohnFlux | people are more likely to click on .deb than spend a whole day to compile and patch manually | 15:32 |
| smb | JohnFlux, Yes that was the plan. I will upload it to some place and add the pointer to the bug | 15:32 |
| JohnFlux | thanks | 15:32 |
| cnd | Keybuk: any chance we can skip to efifb still :) | 15:50 |
| Keybuk | cnd: not enough time to test all the permutations | 15:50 |
| cnd | there doesn't appear to be any locking when you register a fb, so I don't even see how we can reasonably do checks for vga16fb after hw fb | 15:51 |
| Keybuk | right now we have an issue with a simple story => "have this bug? blacklist vga16fb" | 15:51 |
| Keybuk | we'd be swapping it for a can that we haven't opened yet, and may contain worms | 15:51 |
| cnd | yeah | 15:51 |
| cnd | and for the lshw issue, I think we just need to fix lshw so it doesn't do whatever it's doing to the vga16fb framebuffer | 15:52 |
| Keybuk | right | 15:53 |
| cnd | smb: I'm getting somewhat lost in lxr, do you know if driver probe functions are called serially in all cases? | 16:06 |
| cnd | cking, amitk: ^? | 16:07 |
| cking | cnd, sorry, no idea on that | 16:08 |
| smb | cnd, IIRC probing can be parallelized. And you have some helpers to wait for certain groups. | 16:08 |
| cnd | I'm wondering how register_framebuffer gets away without any locking... | 16:09 |
| smb | cnd, apw / csurbhi have been looking into loading the ramdisk in parallel. There would be a patch for that in Lucid. Maybe that helps | 16:09 |
| cnd | smb, I'll take a look | 16:09 |
| cnd | hmmm, can't find anyting in git log | 16:10 |
| amitk | cnd: probing is parallelized as smb said | 16:14 |
| cnd | amitk: would you have any idea how register_framebuffer (called from probe functions) gets away without have any locking? | 16:15 |
| smb | If there is only one of its kind... | 16:15 |
| cnd | my guess is that most people don't have multiple framebuffers enabled | 16:15 |
| smb | Could be | 16:16 |
| cnd | but we'll have two in our kernel (hw and vga16 fbs) | 16:16 |
| cnd | smb: module loading is serialized, and we know that vga16fb is a module. What do you think of an ubuntu sauce patch just for lucid that keeps the vga16fb from registering if there's another fb already registerd | 16:25 |
| cnd | It could fail to work properly if vga16fb were compiled in statically, but it would fix bug 527369 in lucid, and we're likely to move to efifb for M per Keybuk | 16:26 |
| ubot3 | 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 | 16:26 |
| smb | cnd, I am a bit undecided atm. Or not sure to be able to think of all implications. | 16:28 |
| cnd | smb: if it makes you feel any better it would be a one-line patch :) | 16:29 |
| smb | cnd, If you think you can do a patch quite quickly, maybe do that and we discuss it on the ml | 16:29 |
| cnd | k, already got the patch built, just need to test | 16:29 |
| smb | Even those can have drastic effects. :) | 16:29 |
| cnd | yeah | 16:30 |
| smb | I wonder whether there could be a case where another fb is loaded but would not be usable but vga16fb would | 16:30 |
| cnd | smb: if that were the case, we'd probably have bigger issues, cause I assume everything in user space is trying to use /dev/fb0 | 16:31 |
| cnd | Keybuk, any thoughts ^^? | 16:32 |
| === kamalm-away is now known as kamalm | ||
| Keybuk | everything is trying to use fb0 | 16:33 |
| Keybuk | but I don't think you patch will help | 16:33 |
| Keybuk | you say that vga16fb is claiming fb0 and that is the problem | 16:34 |
| Keybuk | if it's claiming fb0, then that means that no other framebuffer is registered at that time | 16:34 |
| Keybuk | so your patch is a no-op | 16:34 |
| Keybuk | all your patch would do is stop fb1 appearing as vga16fb when we already have a framebuffer | 16:34 |
| cnd | Keybuk: I'm trying to solve a different problem | 16:34 |
| cnd | where vga16fb is /dev/fb1 | 16:35 |
| cnd | no one should be using it | 16:35 |
| cnd | but if you run sudo lshw, it opens it | 16:35 |
| cnd | and corrupts the hw framebuffer | 16:35 |
| cnd | so my change would prevent vga16fb from registering /dev/fb1 | 16:36 |
| Keybuk | ok | 16:36 |
| Keybuk | that sounds reasonable to me | 16:36 |
| cnd | ok, I'm going down to test, be back in a few (hopefully) | 16:36 |
| mjg59 | Hm | 16:38 |
| mjg59 | This sounds like a failure in resource allocation | 16:38 |
| mjg59 | (an unsurprising one, but still) | 16:39 |
| mjg59 | vga16fb should really be going through the vga arbiter | 16:39 |
| mjg59 | Which should claim the resources | 16:39 |
| mjg59 | And then refuse to let vga16fb bind if another driver is already there | 16:39 |
| cnd | mjg59: looks like I was rebooting while you were typing | 16:40 |
| cnd | what did I miss? | 16:40 |
| mjg59 | 16:38 < mjg59> Hm | 16:40 |
| mjg59 | 16:38 < mjg59> This sounds like a failure in resource allocation | 16:40 |
| mjg59 | 16:39 < mjg59> (an unsurprising one, but still) | 16:40 |
| mjg59 | 16:39 < mjg59> vga16fb should really be going through the vga arbiter | 16:40 |
| cnd | smb: Keybuk: patch worked, vga16fb failed to load | 16:40 |
| pabelanger | Afternoon. | 16:41 |
| cnd | mjg59: the issue is that vga16 has a hard coded aperture location (64K at 0xA0000) that is separate from where the modern aperture locations are | 16:41 |
| mjg59 | cnd: That's what the vga arbiter is for | 16:41 |
| cnd | ahhh | 16:41 |
| cnd | I looked at vgaarb last night, but it didn't seem related | 16:43 |
| pabelanger | If I have distcc setup, and used the 'fakeroot debian/rules binary-...' script, would I have to do anything special to make it use distcc? Or would environment variables be enough | 16:43 |
| cnd | mjg59: still, even if it should be using vgaarb, that would require a rewrite of vga16fb, right? | 16:44 |
| mjg59 | cnd: Yeah | 16:45 |
| mjg59 | Which isn't high on my list of requirements :) | 16:45 |
| cnd | understandably so :) | 16:45 |
| cnd | mjg59: we'll be pushing to move away from vga16fb for M anyways, if I understood Keybuk right | 16:46 |
| cnd | so a quick and dirty hack for Lucid may be the best option given the Lucid timeframe | 16:46 |
| Keybuk | bearing in mind of course that the pushing to move away is to something we figured out only last week :p | 16:50 |
| mjg59 | Ha. What? | 16:50 |
| Keybuk | abusing efifb ;) | 16:51 |
| mjg59 | There's no real functional difference between efifb and vesafb | 16:52 |
| mjg59 | You end up with the same suspend/resume issues | 16:52 |
| mjg59 | That's why we went with vga16fb rather than vesafb | 16:53 |
| mjg59 | (way, way back in the day) | 16:53 |
| Keybuk | ah right, that's interesting to knpw | 16:57 |
| mjg59 | Both just give you access to an unaccelerated linear framebuffer | 16:57 |
| Keybuk | the suspend/resume issue being "can't reset the mode"? | 16:57 |
| mjg59 | The only difference is how you got that - with efifb you've got a mode set by the bootloader, with vesafb you've got a mode set by the kernel on entry | 16:58 |
| mjg59 | efifb has no way of resetting a mode on resume | 16:58 |
| mjg59 | You could potentially reset a vesa mode, but that depends on being lucky in vbios implementation | 16:58 |
| Keybuk | how does efifb reset the mode when you VT switch out of X? | 16:58 |
| mjg59 | It doesn't | 16:59 |
| Keybuk | (or vesafb for that matter) | 16:59 |
| mjg59 | X is responsible for reprogramming the original mode | 16:59 |
| Keybuk | ahh, right, I know this | 16:59 |
| mjg59 | The advantage of vga16fb is that if you hit the hardware before it's initialised, you tend to just get your port io timing out | 16:59 |
| mjg59 | Whereas with vesa, you're writing to a region of memory that may now be used by the card for something else entirely | 17:00 |
| Keybuk | right, because it can move across a suspend/resume | 17:00 |
| mjg59 | Yeah, you have no idea what state the card is in on resume | 17:00 |
| mjg59 | With vesafb, you can freeze the framebuffer before suspend, try reprogramming it with vbetool on resume and then unfreeze it | 17:01 |
| mjg59 | But with efifb, you don't know what mode you were in to start with... | 17:01 |
| mjg59 | (Note that the freeze/reprogram/resume thing helps but does not fix this issue) | 17:01 |
| Keybuk | yeah | 17:02 |
| Keybuk | it almost becomes easier to declare that we don't support suspend/resume if you install nvidia-glx | 17:02 |
| Keybuk | and remove the menu options <g> | 17:03 |
| mjg59 | nvidia will typically manage suspend/resume itself, as long as it's entirely in control of modesetting | 17:03 |
| mjg59 | Which means no console framebuffer with the exception of vga16fb | 17:03 |
| bryceh | JFo, sounds right | 17:04 |
| bryceh | JFo, I think we've been tagging them needs_pll_quirk or some such | 17:04 |
| === sconklin is now known as sconklin-lunch | ||
| JFo | bryceh, yeah, I see the descriptions with that in | 17:29 |
| bdrung^2 | what's the status of the lucid kernel regarding SSDs? Is TRIM supported in ext4? | 17:35 |
| === sconklin-lunch is now known as sconklin | ||
| === Hedge|Hog is now known as Hedgehog | ||
| === Hedgehog is now known as Guest90570 | ||
| pmatulis | lastlog -clear | 19:21 |
| pmatulis | will there be another point release of 8.04 ? | 19:22 |
| smb | Just for the (public) record: not one I am currently aware of. The last I know was beginning of this year | 19:44 |
| === JanC_ is now known as JanC | ||
| === sconklin is now known as sconklin-gone | ||
| crimsun | manjo: for bug 548371, your mic switches are muted again. Did you uncheck the sound preferences and untick (unmute) the mic in the Input tab? | 22:31 |
| ubot3 | Malone bug 548371 in pulseaudio "[LUCID] Samsung N310 External microphone unable to record sound." [Undecided,New] https://launchpad.net/bugs/548371 | 22:31 |
| manjo | crimsun, yes I did | 22:55 |
| manjo | crimsun, I even increased the input to 1/2 way | 22:55 |
| crimsun | manjo: can you rerun http://www.alsa-project.org/alsa-info.sh, please? | 22:57 |
| manjo | crimsun, yes can do ... give me 10mts to reboot that netbook again | 22:57 |
| crimsun | to conference, will check back | 23:04 |
| manjo | crimsun, uploaded info you asked for | 23:10 |
| RAOF | Argh! Die, vga16fb, die! | 23:30 |
| RAOF | I don't suppose we can flip around our vga16fb system? Currently we have a patch adding an alias so that vga16fb bind to any VGA device - could we instead make drivers that won't provide kms manually add vga16fb? | 23:55 |
| RAOF | Man, that was broken English. | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!