re: i386 vs radeondrmkms problem - isa attachments suck
Is the ignoring of attach priority a general characteristic of indirect buses, and might it make sense for config to be able to explicitly prioritise the order the cfdata[] entries? I know uebayasi@ has been rototilling config and wondered if he could be interested... :) The problem is that there is no notion of priority for indirect buses because it is up to the attaching driver to determine if it should attach or not. You could imagine working around that by adding code to check whether two drivers claim conflicting resources, and then the idea of priority would work. GSoC project maybe? the problem is that the relevant kernel resources *are already* mapped by the vga driver, just well before it attaches. that happens before the copyright is printed in consinit(). otherwise we'd get no kernel output.. i have a hack on the radeon@pci driver to do this, and it works.. on serial console. i figured out the ordering problem with doing radeonhack@isa, and got it to attach first, but it doesn't help since vga already has claimed those registers, and knows it should attach, which it does.. and then attaches wsdisplay. basically, the only real solution is to get vga to give up these entirely (ie, to detach itself and its wsdisplays) and that's proven to be more tricky than hoped. at this point i'm going with my LEGACY kernel idea. I'd actually create a i386-legacy arch and get rid of all the crud in i386 that deals with stuff built before 2005 or so. And move that to tier-infinity and let it die peacefully. they still sell i586 based systems so this seems like a fairly early cut off. also sounds a like a lot more effort than simply having an relatively small LEGACY kernel that has it (i'm thinking of releng work, source code additions, etc., not just my effort.) thanks. .mrg.
re: i386 vs radeondrmkms problem - isa attachments suck
Brian Buhrow writes: hello. Here is a very naive question. Could the vga driver be altered to not do its mapping until the Radeon, or other graphics driver, has had a chance to map and/or attach? To solve the loss of the printed copyright messages, perhaps a buffer could be allocated, much like the dmesg buffer, which could be written to while things are still attaching. Then, once all is attached, a function could be called to print the contents of the accumulated buffer to the final, correct, device. Doing things this way could also allow us to have serial consoles using usb attached serial ports. I've thought about trying something like this, but haven't gotten frustrated enough yet to do it. i think the diagnostic benefit of having console messages appear as soon as they're printed is too important to give up. it's already bad enough right now when drmkms takes over and the display goes blank for a couple of seconds (on my laptop, suddenly /etc/rc has completed a bunch of early tasks by the time it turns back on.) ie, i think we should do our best to keep these timely as much as possible, and in this case, we can kind of just ignore that they've been initialiised initially for the console, as drm takes over and we won't access them as VGA again. mlelstv has been working on making vga detach actually work properly lately, and when that is finished, we may have a true non-super-ugly solution. all that said, what you mention about delayed console isn't a bad idea -- i'd like to be able to have multiple console output as well, like linux has provided with 'console=vga console=com1' since at least 2.4 days... .mrg. Thoughts? -Brian On Mar 4, 9:10am, matthew green wrote: } Subject: re: i386 vs radeondrmkms problem - isa attachments suck } } Is the ignoring of attach priority a general characteristic of } indirect buses, and might it make sense for config to be able to } explicitly prioritise the order the cfdata[] entries? I know uebayasi@ } has been rototilling config and wondered if he could be interested... } :) } } The problem is that there is no notion of priority for indirect buses } because it is up to the attaching driver to determine if it should } attach or not. } } You could imagine working around that by adding code to check whether } two drivers claim conflicting resources, and then the idea of priority } would work. } } GSoC project maybe? } } the problem is that the relevant kernel resources *are already* } mapped by the vga driver, just well before it attaches. that } happens before the copyright is printed in consinit(). otherwise } we'd get no kernel output.. } } i have a hack on the radeon@pci driver to do this, and it works.. } on serial console. } } i figured out the ordering problem with doing radeonhack@isa, and } got it to attach first, but it doesn't help since vga already has } claimed those registers, and knows it should attach, which it } does.. and then attaches wsdisplay. } } basically, the only real solution is to get vga to give up these } entirely (ie, to detach itself and its wsdisplays) and that's } proven to be more tricky than hoped. at this point i'm going with } my LEGACY kernel idea. } } I'd actually create a i386-legacy arch and get rid of all the crud in } i386 that deals with stuff built before 2005 or so. And move that to } tier-infinity and let it die peacefully. } } they still sell i586 based systems so this seems like a fairly } early cut off. also sounds a like a lot more effort than simply } having an relatively small LEGACY kernel that has it (i'm thinking } of releng work, source code additions, etc., not just my effort.) } } thanks. } } } .mrg. -- End of excerpt from matthew green
Re: i386 vs radeondrmkms problem - isa attachments suck
On Wednesday 04 Mar 2015 12:28:25 matthew green wrote: i think the diagnostic benefit of having console messages appear as soon as they're printed is too important to give up. Agree 100% as a kernel hacker on i386 with a radeon! Roy
re: i386 vs radeondrmkms problem - isa attachments suck
hello. Here is a very naive question. Could the vga driver be altered to not do its mapping until the Radeon, or other graphics driver, has had a chance to map and/or attach? To solve the loss of the printed copyright messages, perhaps a buffer could be allocated, much like the dmesg buffer, which could be written to while things are still attaching. Then, once all is attached, a function could be called to print the contents of the accumulated buffer to the final, correct, device. Doing things this way could also allow us to have serial consoles using usb attached serial ports. I've thought about trying something like this, but haven't gotten frustrated enough yet to do it. Thoughts? -Brian On Mar 4, 9:10am, matthew green wrote: } Subject: re: i386 vs radeondrmkms problem - isa attachments suck } } Is the ignoring of attach priority a general characteristic of } indirect buses, and might it make sense for config to be able to } explicitly prioritise the order the cfdata[] entries? I know uebayasi@ } has been rototilling config and wondered if he could be interested... } :) } } The problem is that there is no notion of priority for indirect buses } because it is up to the attaching driver to determine if it should } attach or not. } } You could imagine working around that by adding code to check whether } two drivers claim conflicting resources, and then the idea of priority } would work. } } GSoC project maybe? } } the problem is that the relevant kernel resources *are already* } mapped by the vga driver, just well before it attaches. that } happens before the copyright is printed in consinit(). otherwise } we'd get no kernel output.. } } i have a hack on the radeon@pci driver to do this, and it works.. } on serial console. } } i figured out the ordering problem with doing radeonhack@isa, and } got it to attach first, but it doesn't help since vga already has } claimed those registers, and knows it should attach, which it } does.. and then attaches wsdisplay. } } basically, the only real solution is to get vga to give up these } entirely (ie, to detach itself and its wsdisplays) and that's } proven to be more tricky than hoped. at this point i'm going with } my LEGACY kernel idea. } } I'd actually create a i386-legacy arch and get rid of all the crud in } i386 that deals with stuff built before 2005 or so. And move that to } tier-infinity and let it die peacefully. } } they still sell i586 based systems so this seems like a fairly } early cut off. also sounds a like a lot more effort than simply } having an relatively small LEGACY kernel that has it (i'm thinking } of releng work, source code additions, etc., not just my effort.) } } thanks. } } } .mrg. -- End of excerpt from matthew green
