cndRAOF: 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#L150900:01
cndit seems to destroy framebuffers that are already registered if a superseding one is found00:01
cndwhat we need is a fb priority00:01
cndwhere vga16fb = 0, vesafb = 10, intel, nouveau, radeon = 2000:02
cndand we need to kick off lower prio framebuffers and prevent lower prio framebuffers from being added on after higher prio fbs00:02
cnddoes that make sense?00:03
RAOFI 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
RAOFI'm just not familiar enough with kernel internals to work out how to do that.00:04
cndRAOF: see, that makes sense, except why did the dual gpu case have vga16fb grab the fb first?00:06
cndso I'm thinking that there's a race condition in the loading of the modules00:07
RAOFYeah, that's possible to.00:07
cndthe vga16fb module may be loaded second, but it registers first00:07
RAOFBut claiming the fb != claiming the device.00:07
cndRAOF: I'm not sure I follow00:08
RAOFI'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
RAOFWhen 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
RAOFWhen 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
RAOFs/claims fb1/gets assigned fb1/00:10
cndRAOF: still, we don't want it at all, cause if someone does try to access fb1 it'll mess things up, right?00:10
RAOFRight; I think that's what lshw is triggering.00:11
Sarvattseems 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, yeah00:11
cndso that's where I think we need a fb priority00:11
cndso that we can kick off vga16fb when nouveau comes after, or prevent vga16fb if nouveau comes first00:12
RAOFSo, 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
cndRAOF: is your comment in reference to the priority implementation, or some other mechanism00:13
RAOFSome 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
cndRAOF: yes, but the problem here is: what if vga16fb claims the hw first?00:15
cndit would prevent other drivers from working00:15
SarvattI think other framebuffer drivers actually have code to not screw up KMS and vga16fb just wasnt updated too00:16
* cnd goes back to lxr00:16
Sarvattlike efifb will hand off control over to a KMS driver right00:16
Sarvattin 2.6.33 at least, not lucid's kernel00:17
Sarvattyeah - 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=89f3f2199084a160a3a45fa6d9af23569632175800:18
RAOFcnd: 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
cndSarvatt: AHHH! they use that exact block of code I found00:19
cndthe FBINFO_MISC_FIRMWARE says "destroy me if another fb registers the same space"00:20
* RAOF stands corrected.00:20
cndso basically it's a binary priority like I suggested00:20
cndso this looks fairly simple00:22
cndjust port the changes to vga16fb00:22
cndI'll take a look at it00:22
RAOFGreat!  Thanks.00:23
Sarvattthanks for looking at it cnd, I'm swamped at the moment and can't mess with it00:28
=== jussi01 is now known as Guest4656
=== kamalm is now known as kamalm-away
RAOFcnd: 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
cndRAOF: no02:19
cndI just tried a test kernel, but it didn't work :(02:19
cndgotta figure out what went wrong02:19
=== sconklin is now known as sconklin-gone
cndRAOF: actually, I think it would work02:21
RAOFIf only...?02:21
cndthe current logic unregisters a fb if a better one comes along02:21
cndbut it doesn't prevent vga16fb from registering after a hw fb02:22
cndso I've fixed up vga16fb, but I need to fix up the register_framebuffer logic02:22
RAOFYou didn't make any change to fbmem.c? (Which seems to be where the registration happens)02:24
cndRAOF: the change I made for the kernel I just tested was to enable handoff in vga16fb02:27
cndnow I'm changing fbmem02:27
RAOFAh, right.02:27
RAOFI'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
ubot3Malone bug 518387 in linux "vga16fb sometimes claims fb0 before kms driver, a causing blank screen on boot" [High,Confirmed] https://launchpad.net/bugs/51838702:44
ubot3Malone 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/52736902:44
cndRAOF: thanks02:46
cndkengyu: around?02:47
cndI see you've taken bug 52736902:47
ubot3Malone 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/52736902:47
cndI'm working on a couple patches to fix it02:47
cndhopefully I'll have some results in a bit02:48
cndif you haven't done much, feel free to reassign it to me02:48
cndkengyu: 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
RAOFThat looks promising :)02:52
cndwell, mostly cause it still didn't work right...02:53
cndI still got me /dev/fb102:53
cndI'll have to do some printk debugging tomorrow02:55
cndI'll post any updates in the bugs (hopefully in the form of a test kernel)02:55
brycehJFo, 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 up05:14
brycehJFo, I don't think the bug reports are dupes, they are just different hardware that all need the same quirk or whatever05:15
brycehJFo, they're all RV530/RV515 systems05:15
crimsunJFo: is there a tag to be used when a patch fixing a bug is CCed to stable@k.o?05:45
crimsunJFo: e.g., bug 50222605:46
ubot3Malone bug 502226 in linux "Audio Stops, video speeds up" [Undecided,Triaged] https://launchpad.net/bugs/50222605:46
crimsunJFo: to clarify, these are external patches lacking BugLink links in the git commit msg05:46
=== Guest4656 is now known as jussi01
JohnFluxHey all08:29
JohnFluxI made a change locally to ubuntu-lucid/drivers/staging/rt287008:30
JohnFluxcan I recompile just that driver and load it ?08:30
JohnFluxso far I've been using debian/rules  to recompile and install, which is kinda slow for each small change08:31
bigonhttps://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/545585 << are you aware of this bug ?08:36
smbJohnFlux, 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 build08:36
ubot3Malone bug 545585 in linux "lucid iwlagn  free more than tfds_in_queue" [Undecided,Confirmed] 08:36
smbbigon, No08:36
bigonit's spamming dmesg a lot08:38
smbbigon, Actually not from the header. But I know there seem to be problems with dropping the connection08:38
bigonsmb: let me se if I get connexion drop08:39
smbbigon, 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_queue08:40
amitkcooloney: ericm_: it seems like the VFP patch from Imre that you included isn't yet ack'ed by Russell08:43
amitkbug 50750308:44
ubot3Malone 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/50750308:44
amitkspecifically, he noted some problems with the patches08:44
smbbigon, 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 patch08:46
bigonsmb: great08:48
JohnFluxsmb: cd08:59
JohnFluxsmb: /home/johnflux/ubuntu-lucid is not clean, please run 'make mrproper'09:00
smbJohnFlux, you are now in $HOMe09:00
JohnFluxsmb: it says that when I do the make  command that you said09:01
smbwith O= (careful never do mrproper)09:01
JohnFluxsmb: yes, with the O=09:01
JohnFluxsmb: I assumed you meant /build/ instead of /builds/09:02
JohnFlux~/ubuntu-lucid (master)$ make O=./debian/build/build-generic09:02
JohnFluxI'm doing that09:02
smbAs I tried to get the dirs from my memory likely09:02
smbmaybe that needs a C= too... give me a sec09:03
smbJohnFlux, Hm, it seems to work for me. Potentially you could use $(pwd) instead of . (thought that should not change much).09:14
JohnFluxsmb: I'm just doing "make modules" instead.  Any reason to not do it the old fashioned way?09:15
amitkJohnFlux: if you're getting the 'make mrproper' message, you've probably run make in the ubuntu kernel directory without the O=09:16
smbJohnFlux, But I think, when you did call make once wrong without O= it can spoil things. If you call make modules you do that09:16
smbamitk, I was thinking that09:16
amitkbest to save your changes as a commit, reset the git tree and reapply the commit again09:17
smbJohnFlux, You could recover by mv'ing debian one level up. Then call make mrpropoer and then mv debian back09:17
smbJohnFlux, builds with O= and without don't mix well09:17
JohnFluxI could just use 'make modules'  instead right?09:17
JohnFluxand not bother with the debian packages?09:17
smbThen you use a different configuration, get different function checksums and your module won't laod09:18
smbamitk, no09:18
amitkbut assuming you copy the .config correctly09:18
JohnFluxI copied /boot/config-blah 09:18
smbamitk, You need the right symversions09:18
JohnFluxI think it was the right .config09:18
JohnFluxand I built the kernel with AUTOBUILD=1    wasn't that to do with checksums or something?09:19
amitksmb: aah right, I thought he was just test compiling. The compiled modules won't work on the ubuntu kernel for shit09:19
smbAnd the symversions are only created by a full build, after that you could use that for incrementals09:19
smbJohnFlux, I'd run a full build once, then use "make O=$(pwd)/debian/build/build-generic modules09:20
smbfor the incrementals09:20
JohnFluxdo I need to prepend AUTOBUILD=1   to that?09:20
smbJohnFlux, AUTOBUILD is a herring rouge with lucid09:20
smbI don't think it has any effect09:20
smbJohnFlux, You just need a "fakeroot debian/rules binary-generic" run once09:21
amitk...after resetting the tree09:22
smbamitk, right. After doing a make modules in there09:23
JohnFluxokay thanks - I'll give that a try09:24
JFocrimsun, sounds good, I'll look at them today11:46
JFoI don't know of a tag that we could use on them11:47
JForather bryceh :)11:47
JFo<-still half asleep11:47
JFobryceh, I see 9 bugs. That sound about right?11:51
JohnFluxI. AM. BRILLIANT!12:38
JohnFluxsmb: okay, so I got my hardware working with a one line change12:38
JohnFluxsmb: just a simple case of adding the USB_DEVICE to the code12:39
JohnFluxsmb: any chance I can just ask someone here to add the change?12:40
JohnFluxIt would be great if this works out of the box for 10.0412:40
smbThe 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
JohnFluxyep, there's an open bug report about it12:46
JohnFluxsmb: okay I wrote up my summary on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/44199012:50
ubot3Malone bug 441990 in linux "Buffalo WLI-UC-GN 802.11n USB-WiFi adapter non functional" [Undecided,Confirmed] 12:50
smbJohnFlux, 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 things12:52
JohnFluxsmb: done13:00
JohnFluxsmb: I mean, I've sent an email to the mailing list13:00
JohnFluxhmm the email bounced13:01
smbJohnFlux, Ok, thanks. :)13:01
smbHm, did I give the wrong address13:01
JohnFluxno, I've subscribed etc13:01
JohnFluxsmb: should I create a proper git format-patch  for it?  It's so small it didn't seem worth it13:03
JohnFluxsmb: did my email send correctly ?13:03
JohnFluxsmb: "Trivial patch for supporting.."13:03
smbJohnFlux, Yep, its there13:03
JohnFluxokay good13:03
JohnFluxsmb: so, should I send this 'upstream' as well?13:03
JohnFluxsmb: does the email contain sufficient info?13:04
smbJohnFlux, 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-by13:05
smbGive me a sec, lets see who should get it13:05
JohnFluxsmb: reading the TODO file in the directory, it says to not bother the kernel people13:06
smbOh, staging, then Greg13:06
JohnFluxsmb: okay done - I've forward the email to him13:06
smbErr, he probably wants proper format13:06
smbEven for such small thing13:06
smbHe can afford to be lazy :)13:07
JohnFluxI guess, but it's such a pain to get git to send via gmail13:07
JohnFluxI can never remember how to get send-imap working13:07
smbJohnFlux, I could forward it in your name and put your credentials into it13:07
JohnFluxthat would be good thanks :)13:08
JohnFluxcould you put both lines in13:08
JohnFluxboth the changes that I suggest13:08
smbJohnFlux, Yep, either that or make two small patches of it. Do you have the other hw as well?13:09
JohnFluxbut I gave a link where several users say it works for them13:10
smbAh ok. Guess that should be enough13:10
=== sconklin-gone is now known as sconklin
JFocrimsun, we can use patched-upstream if you think that is descriptive enough13:52
cndsmb: there's some bugs where the vga16fb poorly interacts with other framebuffers14:21
cndthere's some logic to kick off generic framebuffers if a hw-specific fb comes along14:22
cndbut that logic is based on the aperture location overlapping between the generic fb and the hw fb14:22
cndit seems that vga16fb, with its hardcoded aperture location, does not overlap with hw-specific fb aperture locations14:23
cndI'm thinking of modifying the code that kicks a generic framebuffer off to do the same to vga16fb any time a new fb comes along14:23
cnddo you have any insight or thoughts?14:23
smbOk, 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 userspace14:24
cndsmb, we build it as a module14:24
cndthere's two problems14:24
cnd1: there's a race condition where in dual gpu nvidia systems vga16fb somehow gets /dev/fb0 even though its loaded after nouveau14:24
cnd2: 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 vt14:25
cndso ideally we want vga16fb to be usable if there's no other fb available, but we want to kill it if there is14:25
cndand really, any fb is better than vga16fb, so it makes sense to me to kill it if any other fb comes along14:26
cndeven vesafb14:26
smbcnd, That might be something to discuss with Keybuk. He knows the plumbing layer bringing up the fbs and stuff like that14:27
cndsmb, I think we're below the plumbing layer though14:27
cndbasically, I think we need to decide whether this approach is reasonable, because vga16fb is unmaintained upstream14:28
cndI'll send out an e-mail to linux-kernel14:28
cndbut we may need to decide this ourselves14:28
smbAnd 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 vga16fb14:29
smbFor whatever reason. And understand that reason14:29
cndsmb, what do you mean by "hard loading"14:29
smbmodprobe vga16fb14:30
Keybukcnd: what kind of timescale are you thinking?14:30
Keybuksmb: nothing should do that, we load vga16fb by alias14:30
cndKeybuk: what do you mean by that?14:30
Keybukcnd: for the modifications you're talking about to vga16fb14:30
smbKeybuk, Ok, just wanted us to be sure14:30
Keybukit sounds like the kind of project that would take longer than we have left before kernel freeze?14:30
cndKeybuk: well, the modifications aren't very much, so I can have a patch ready by end of today14:31
cndwe're talking about 10 lines of code max14:31
cndbut I defer to you and smb as to whether that's still acceptable14:31
Keybukbut the "kick the generic framebuffer out" code in our current kernel is broken, right?14:31
Keybukit works in .3414:31
Keybukbut not in .3214:31
cndKeybuk: it seems to be all there to me14:32
Keybukit isn't14:32
Keybukbreaks nouveau iirc14:32
smbcnd, Keybuk Well to me this sounds like it should not be hasted then14:32
cndKeybuk: are you referring to vga16fb?14:32
Keybuklet me back up a second14:32
smbcnd, Is blacklisting vga16fb a workaround?14:32
Keybuksmb: NO!14:32
Keybukwould it help if I explained for a moment why we're doing things the way we are right now14:33
cndsmb, we can't blacklist otherwise we can't fallback to vga16fb if its the only thing that works14:33
Keybukand how we'd prefer to do them if we could14:33
cndKeybuk: sure14:33
Keybukso in general we want a framebuffer for our console14:33
Keybukit means we're always using fbcon14:33
Keybukit means our x86 story is the same as our ports story14:33
Keybukand it means we can do things like always fallback to the X fbdev driver if we can't find a better one14:34
Keybukbut we can't quite do that today14:34
Keybukso what we do today14:34
KeybukKMS drivers include a framebuffer - so when we auto-load them by alias - we get a framebuffer (win!)14:34
Keybuknon-KMS drivers don't by default - so we arranged for vga16fb (most basic fb that works) to also be alias loaded14:34
Keybukbut alias loaded *after* anything else first like nouveau, radeon, intel, etc.14:34
Keybuksince vga16fb is just a framebuffer to the VGA, it doesn't bind to hardware like those do14:35
Keybukbut that has never seemed to be a problem14:35
Keybukyou just end up with an fb1 that would draw using the VGA if you reset the video mode back to a VGA mode14:35
Keybuk(and the KMS drivers have it in native modes, so you never see it)14:35
Keybukso this works well enough14:35
Keybukwe have a framebuffer14:36
Keybuk(fb0 is either native or vga16fb)14:36
Keybukso we have fbcon14:36
Keybukand vga16fb is good enough for plymouth14:36
Keybukbut isn't good enough for X14:36
Keybuk-- 14:36
cndKeybuk: the problem is there's a race condition we've seen where vga16fb will still get /dev/fb0 (bug 518387)14:36
Keybukhow we'd LIKE to do it:14:36
ubot3Malone bug 518387 in linux "vga16fb sometimes claims fb0 before kms driver, a causing blank screen on boot" [High,Confirmed] https://launchpad.net/bugs/51838714:36
Keybukcnd: why would it cause a blank screen?14:36
cndKeybuk: sorry, thought you were done, continue14:36
Keybukif fb0 is vga16fb, that should imply that vga16fb is also what the fbcon is bound to14:37
Keybukand it's what plymouth will draw to14:37
cndKeybuk: probably some interaction between nouveau and vga16fb14:37
Keybukso vga16fb winning should mean you lack KMS but not lack anything on screen14:37
Keybukwhat we'd PREFER to have been doing14:37
Keybukgrub can set video modes via VBE, and can payload those into the kernel so the kernel knows a video mode has been set14:37
Keybukif that happens, the kernel uses the "efifb" built into it14: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
Keybukso we'd boot with efifb14:38
Keybukthis fails right now because fbcon is a module for some reason14:38
Keybukif fbcon were built-in (like it is on arm, ports, etc.) then we would win14:38
Keybukbut with it as a module, if you have a boot failure before the module is loaded, you never see anything on screen after grub14:39
Keybukso, 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 fbcon14:39
Keybukso we have a true colour framebuffer from the get go on all of our platforms14:39
Keybukbut then the real KMS driver loads14:40
Keybukand that needs to kick out and transition the console from efifb to i915/nouveau/radeon/etc.14:40
Keybuksome of that code is in our kernel14:40
Keybukbut there are "it didn't work, make it work" bug fixes in .33 and .3414:40
pmatulison hardy, is there any chance of adding support for a HP 10 Gb network card (HP NC522SFP; http://is.gd/aYF2r) ?14:40
KeybukI suspect that's the same hand-off code you're talking about for vga16fb14:41
pmatulismodule (netxen_nic) is in hardy but it doesn't work14:41
cndKeybuk: so efifb would be kicked out with the code we have in the kernel, bug vga16fb can't be kicked out like that14:41
Keybukcnd: efifb is not kicked out reliably with the code we have in the kernel *now*14:41
cndKeybuk: either way, we still have the issue that vga16fb can't be kicked out using that framework (I think)14:41
cndbecause the vga16fb aperture is a hardcoded 64K block of physical memory14:42
cndbut the vga16fb aperture is different than what's used by the hw fbs14:42
Keybukvga16fb is a wildly different type of framebuffer14:43
cndso the vga16fb uses 0xA0000-0xB0000, but that never overlaps the nouveau fb at 0x80000000-<blah>14:43
Keybukif you were talking to fb0 before, you'd be in planar mode14:43
Keybukand most likely doing raw VGA16 opcodes14:43
Keybukto suddenly have that switched to being a KMS-driven true-colour packed pixel fb would not work so well <g>14:43
ubot3bugzilla.kernel.org bug 15151 in Video(DRI - non Intel) "Black screen after loading nouveau module" [Normal,Closed: code_fix] 14:44
cndyeah, so basically efifb, with that fix, can be kicked off14:45
cndbut vga16fb can't be kicked off because its aperture will never overlap with hw-specific fb apertures14:45
Keybukthough 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
Keybukbut once we solve that, and we have efifb => native fb (or just efifb all the way) then we have a great story14:45
cndso my thought was: if there's ever another fb loaded, kick off vga16fb14:45
Keybukthere's always a framebuffer on x86, always a fbcon, X can always fallback to fbdev14:45
Keybukwe only ever do one more switch at grub, we can have grub paint purple ubuntu logos so there's no black screen during boot14:46
Keybukcnd: but how do you kick it off?14:46
Keybukand more to the point, how do you deal with the fact that userspace may have started using the vga16fb fb0?14:46
cndKeybuk: in the same code that kicks off other generic fbs, just do it without checking the aperture overlap for vga16fb14:46
Keybukcnd: but that isn't the same14:47
Keybukthat's my point14:47
Keybukthe "other code" works by handing over fb014:47
Keybukso fb0 never vanishes14:47
Keybukjust between instructions, the driver that's dealing with it can change14:47
Keybukone minute you're drawing to efifb, the next you're drawing to nouveau14:47
Keybukbut you never know14:47
Keybuk(modulo resolution changes, etc. see above)14:48
Keybukbut you can't hand over fb0 from vga16fb to nouveau14:48
Keybukas you pointed out, the aperture is wrong14:48
Keybukthe size of that aperture is wrong14:48
Keybukthe resolution is almost certainly wrong14:48
cndKeybuk: 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#patch314:48
Keybukand vga16fb is a planar framebuffer, not a packed pixel framebuffer! :D14:48
Keybukso the code you use to write it is completely different!14:48
cndthere's nothing complex there, you just unregister the generic one and register the hw one in its place14:49
cndI don't see why you can't just do the same for vga16fb, the only difference is you wouldn't check the aperture bounds first14:49
Keybukbecause it'd crash any app talking to that framebuffer?14:50
cndoh wait, I see what you're saying now14:50
cndit's all because the aperture wouldn't be consistent across the transition14:51
Keybukfrom a kernel POV that patch is almost certainly a good idea14:52
Keybukbut from a userspace POV, it won't work at all14:52
KeybukI see fb0 turn up, it's vga16fb14:52
Keybukso I mmap the VGA aperture, and I start drawing on it14:52
Keybukthat's example code from Plymouth that deals with vga16fb14:53
Keybuksee how it's actually talking directly to the VGA? :p14:53
Keybukif you rip that frame-buffer out, and replace it with a packed pixel one, plymouth will just crash and burn14:54
Keybukand so would X if that was running14:54
cndKeybuk: so what do we do if we see that Ubuntu is failing on all nvidia dual gpu systems like in the bug?14:54
Keybukthe reason that aperture check is there in the hand-off code (aiui) is precisely because efifb/vesafb and nouveau/etc. *are* compatible14:54
Keybukif you had fb0 mapped from efifb, you have the same address mapped as nouveau would map14:55
Keybukso you can carry on regardless14:55
Keybukcnd: well, I'd actually investigate why the nouveau module isn't creating the framebuffer first14:55
Keybukthat seems a bit odd14:55
Keybukwe already wait for nouveau init to return before trying vga16fb14:55
JFocnd, bug 539878 was the one I meant to show you the other day when I was pinging you on LVDS stuff.14:55
Keybukif nouveau init guaranteed it had made its framebuffer before returning, vga16fb would be always fb114:56
ubot3Malone bug 539878 in linux "nouveau out of sync LVDS (basically card not supported)" [High,Triaged] https://launchpad.net/bugs/53987814:56
JFosorry for the oversight14:56
cndKeybuk: my guess (I could be wrong), is that the probe is asynchronous to the init14:56
cndso nouveau inits and registers itself as the module, as does vga16fb14:57
cndbefore nouveau_probe is called14:57
Keybukcnd: yes14:57
cndmaybe you can add a spinlock or some such so the init doesn't return until the probe finishes, but that sounds messy14:58
Keybukfwiw, it doesn't sound like the other drivers are async init14:59
Keybukand it doesn't sound like nouveau is in the single-card case?14:59
Keybukis it the single-card with dual-gpu case?15:00
Keybukor the dual-cards?15:00
cndnot sure15:00
Keybukbecause I have a thought15:00
Keybukabout dual-cards15:00
Keybukbear with me a sec:15:00
Keybukdual-cards have, err, dual cards15:00
Keybukthe first card is a PCI graphics card, the second is a PCI graphics card15:00
Keybukwhat might happen is:15:00
KeybukPCI announces first card15:01
Keybukwe modprobe nouveau15:01
Keybuknouveau doesn't pick it up (nothing plugged in maybe?)15:01
Keybukwe modprobe vga16fb15:01
Keybukvga16fb takes fb015:01
KeybukPCI announces second card15:01
Keybuknouveau picks it up, takes fb115:01
cndKeybuk: sounds plausible, though I'm not sure how that could be fixed...15:02
Keybukright :-/15:02
Keybukit's a bugger15:02
KeybukI do actually have dual nvidia cards here, so I can test :p15:02
Keybuk(and nouveau didn't work for me - this may be why)15:02
cndKeybuk: now that I actually look at the bug some more, they don't even have nouveau loaded15:04
cndso no wonder things didn't work...15:04
cndoh wait, it's an intel bug15:05
smbKeybuk, 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
cndKeybuk: 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 drm15:08
cndKeybuk: the one thing we could do is forbid vga16fb from loading if there's already a fb15:09
cndapparently, 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
ubot3Malone 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/52736915:09
zulcsurbhi: ping any progress on #276472?15:19
Keybukcnd: the other obvious fix15:24
Keybukvga16fb is loaded by alias15:24
Keybukon load, it could check whether the device is one of those supported by nouveau, i915 and radeon, and simply return without enabling15:24
Keybukthat would mean no splash for the nvidix-glx crowd15:25
cndKeybuk: that's fine for ubuntu, but not in general, cause what if the modules aren't available?15:25
Keybukin which case - don't ship vga16fb anyway15:25
Keybukwhich is a "clear with sabdfl" issue15:25
JohnFluxsmb: your email didn't have any sort of attachment15:27
JohnFluxsmb: was it supposed to?15:27
smbJohnFlux, no, there were two other mails send as threaded mails15:27
smb[PATCH 1/2] Staging: rt2870: Add USB ID for Buffalo AirstationNFinitiWLI-UC-GN15:28
smb[PATCH 2/2] Staging: rt2870: Add USB ID for Ralink 2070L15:28
JohnFluxoh I see.  git fixed that behave to add them as replies15:28
JohnFluxhmm, maybe not in a release version of git though15:28
smbJohnFlux, It seems to work. Though Thunderbird is often no so cooperative when they seem to arrive in the wrong order to it15:29
JohnFluxsmb: gmail doesn't handle it at all15:29
JohnFluxsmb: Anyway, upgrade git when the next release comes out :-)15:30
JohnFluxsmb: and thanks15:30
smbJohnFlux, 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 first15:31
JohnFluxcan you post your .deb  somewhere?  And i'll ask people to try them directly?15:32
JohnFluxpeople are more likely to click on .deb than spend a whole day to compile and patch manually15:32
smbJohnFlux, Yes that was the plan. I will upload it to some place and add the pointer to the bug15:32
cndKeybuk: any chance we can skip to efifb still :)15:50
Keybukcnd: not enough time to test all the permutations15:50
cndthere 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 fb15:51
Keybukright now we have an issue with a simple story => "have this bug? blacklist vga16fb"15:51
Keybukwe'd be swapping it for a can that we haven't opened yet, and may contain worms15:51
cndand for the lshw issue, I think we just need to fix lshw so it doesn't do whatever it's doing to the vga16fb framebuffer15:52
cndsmb: I'm getting somewhat lost in lxr, do you know if driver probe functions are called serially in all cases?16:06
cndcking, amitk: ^?16:07
ckingcnd, sorry, no idea on that16:08
smbcnd, IIRC probing can be parallelized. And you have some helpers to wait for certain groups. 16:08
cndI'm wondering how register_framebuffer gets away without any locking...16:09
smbcnd, apw / csurbhi have been looking into loading the ramdisk in parallel. There would be a patch for that in Lucid. Maybe that helps16:09
cndsmb, I'll take a look16:09
cndhmmm, can't find anyting in git log16:10
amitkcnd: probing is parallelized as smb said16:14
cndamitk: would you have any idea how register_framebuffer (called from probe functions) gets away without have any locking?16:15
smbIf there is only one of its kind...16:15
cndmy guess is that most people don't have multiple framebuffers enabled16:15
smbCould be16:16
cndbut we'll have two in our kernel (hw and vga16 fbs)16:16
cndsmb: 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 registerd16:25
cndIt 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 Keybuk16:26
ubot3Malone 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/52736916:26
smbcnd, I am a bit undecided atm. Or not sure to be able to think of all implications.16:28
cndsmb: if it makes you feel any better it would be a one-line patch :)16:29
smbcnd, If you think you can do a patch quite quickly, maybe do that and we discuss it on the ml16:29
cndk, already got the patch built, just need to test16:29
smbEven those can have drastic effects. :)16:29
smbI wonder whether there could be a case where another fb is loaded but would not be usable but vga16fb would16:30
cndsmb: if that were the case, we'd probably have bigger issues, cause I assume everything in user space is trying to use /dev/fb016:31
cndKeybuk, any thoughts ^^?16:32
=== kamalm-away is now known as kamalm
Keybukeverything is trying to use fb016:33
Keybukbut I don't think you patch will help16:33
Keybukyou say that vga16fb is claiming fb0 and that is the problem16:34
Keybukif it's claiming fb0, then that means that no other framebuffer is registered at that time16:34
Keybukso your patch is a no-op16:34
Keybukall your patch would do is stop fb1 appearing as vga16fb when we already have a framebuffer16:34
cndKeybuk: I'm trying to solve a different problem16:34
cndwhere vga16fb is /dev/fb116:35
cndno one should be using it16:35
cndbut if you run sudo lshw, it opens it16:35
cndand corrupts the hw framebuffer16:35
cndso my change would prevent vga16fb from registering /dev/fb116:36
Keybukthat sounds reasonable to me16:36
cndok, I'm going down to test, be back in a few (hopefully)16:36
mjg59This sounds like a failure in resource allocation16:38
mjg59(an unsurprising one, but still)16:39
mjg59vga16fb should really be going through the vga arbiter16:39
mjg59Which should claim the resources16:39
mjg59And then refuse to let vga16fb bind if another driver is already there16:39
cndmjg59: looks like I was rebooting while you were typing16:40
cndwhat did I miss?16:40
mjg5916:38 < mjg59> Hm16:40
mjg5916:38 < mjg59> This sounds like a failure in resource allocation16:40
mjg5916:39 < mjg59> (an unsurprising one, but still)16:40
mjg5916:39 < mjg59> vga16fb should really be going through the vga arbiter16:40
cndsmb: Keybuk: patch worked, vga16fb failed to load16:40
cndmjg59: the issue is that vga16 has a hard coded aperture location (64K at 0xA0000) that is separate from where the modern aperture locations are16:41
mjg59cnd: That's what the vga arbiter is for16:41
cndI looked at vgaarb last night, but it didn't seem related16:43
pabelangerIf 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 enough16:43
cndmjg59: still, even if it should be using vgaarb, that would require a rewrite of vga16fb, right?16:44
mjg59cnd: Yeah16:45
mjg59Which isn't high on my list of requirements :)16:45
cndunderstandably so :)16:45
cndmjg59: we'll be pushing to move away from vga16fb for M anyways, if I understood Keybuk right16:46
cndso a quick and dirty hack for Lucid may be the best option given the Lucid timeframe16:46
Keybukbearing in mind of course that the pushing to move away is to something we figured out only last week :p16:50
mjg59Ha. What?16:50
Keybukabusing efifb ;)16:51
mjg59There's no real functional difference between efifb and vesafb16:52
mjg59You end up with the same suspend/resume issues16:52
mjg59That's why we went with vga16fb rather than vesafb16:53
mjg59(way, way back in the day)16:53
Keybukah right, that's interesting to knpw16:57
mjg59Both just give you access to an unaccelerated linear framebuffer16:57
Keybukthe suspend/resume issue being "can't reset the mode"?16:57
mjg59The 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 entry16:58
mjg59efifb has no way of resetting a mode on resume16:58
mjg59You could potentially reset a vesa mode, but that depends on being lucky in vbios implementation16:58
Keybukhow does efifb reset the mode when you VT switch out of X?16:58
mjg59It doesn't16:59
Keybuk(or vesafb for that matter)16:59
mjg59X is responsible for reprogramming the original mode16:59
Keybukahh, right, I know this16:59
mjg59The advantage of vga16fb is that if you hit the hardware before it's initialised, you tend to just get your port io timing out16:59
mjg59Whereas with vesa, you're writing to a region of memory that may now be used by the card for something else entirely17:00
Keybukright, because it can move across a suspend/resume17:00
mjg59Yeah, you have no idea what state the card is in on resume17:00
mjg59With vesafb, you can freeze the framebuffer before suspend, try reprogramming it with vbetool on resume and then unfreeze it17:01
mjg59But 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
Keybukit almost becomes easier to declare that we don't support suspend/resume if you install nvidia-glx17:02
Keybukand remove the menu options <g>17:03
mjg59nvidia will typically manage suspend/resume itself, as long as it's entirely in control of modesetting17:03
mjg59Which means no console framebuffer with the exception of vga16fb17:03
brycehJFo, sounds right17:04
brycehJFo, I think we've been tagging them needs_pll_quirk or some such17:04
=== sconklin is now known as sconklin-lunch
JFobryceh, yeah, I see the descriptions with that in17:29
bdrung^2what'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
pmatulislastlog -clear19:21
pmatuliswill there be another point release of 8.04 ?19:22
smbJust for the (public) record: not one I am currently aware of. The last I know was beginning of this year19:44
=== JanC_ is now known as JanC
=== sconklin is now known as sconklin-gone
crimsunmanjo: 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
ubot3Malone bug 548371 in pulseaudio "[LUCID] Samsung N310 External microphone unable to record sound." [Undecided,New] https://launchpad.net/bugs/54837122:31
manjocrimsun, yes I did 22:55
manjocrimsun, I even increased the input to 1/2 way 22:55
crimsunmanjo: can you rerun http://www.alsa-project.org/alsa-info.sh, please?22:57
manjocrimsun, yes can do ... give me 10mts to reboot that netbook again 22:57
crimsunto conference, will check back23:04
manjocrimsun, uploaded info you asked for 23:10
RAOFArgh!  Die, vga16fb, die!23:30
RAOFI 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
RAOFMan, that was broken English.23:56

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!