FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 10-08-2012, 03:27 AM
Phill Whiteside
 
Default PowerPC bugs

Hi Ron,
the guys do actually work magic. Maybe not as fast as we wish at times, but "Swears on Heart" they really do their best.
Regards,
Phill.


On 8 October 2012 01:05, Ron Mitchell <rm2892@gmail.com> wrote:

Thank you all for allowing me in on some of the thinking that goes on behind some of these issues. It was a fascinating discussion, and finally I see what you're up against.¬*

Notwithstanding…...
I just installed today's PPC ¬*build of ¬*Lubuntu 12.10 from the live disk on my eMAC - the one with the wildly uncooperative Radeon 9200 graphics card. The result was a normal boot!.

No YABOOT arguments ¬* were required. I just pressed return after "boot".
The live disk itself required a YABOOT command line ¬*(Greg's). But the resulting install was fine.¬*

Has somebody somewhere been working some magic?
Ron Mitchell








On 2012-10-07, at 4:21 PM, Phill Whiteside wrote:
Hi Adam and PPC guys,
I'm going to give you the honest truth. We are now too late to sort the issues out.¬*

I know that some of these bugs go back a long while, some are recent. I cannot see any help in my complaining to SABDFL over what has occurred after the changes after A3.¬*

I propose that PPC follows...



(23:14:36) xxxx: That mail's very long and rambling, and doesn't really give me any concise statement of "this is broken; this is how we propose fixing it".


(23:15:13) phillw: Thinking about this some more, the KMS option shouldn't be the default option on the live/desktop ISOs.¬* The crashes/freezes with radeon can take some time to appear.¬* It is quite conceivable that they could occur in the middle of re-partitioning, which would be bad.


(23:15:13) phillw: ¬*
(23:15:13) phillw: The more you think about, the more appealing the Debian way of doing things is: Just rely on the user to add video=ofonly if they want KMS.¬* This is basically what the boot message says to do at the moment anyway, although it doesn't explicitly mention KMS.


(23:15:39) phillw: what do you need from Debian for the fix to be proposed?
(23:16:28) xxxx: You implied earlier that there was a patch to the driver and/or kernel as an option, not just the command-line change.


(23:18:13) phillw: did you read the email? He accepts that he was probably mistaken on a previous fix?
(23:18:50) phillw: Like I said, up until bug 1058641 I was happy for radeonfb just to be¬*removed.¬*¬*This is even though I was responsible for having it put back (along with aty128) into 12.04 -https://bugs.launchpad.net/ubuntu/+source/linux/+bug/949288¬*.¬* Incidentally, can I ask the kernel people¬*was there a reason why¬*CONFIG_FB_ATY was missed off.....something I probably should of done that at the time?!¬* Sorry!¬* I don't know anything about¬*Mach64/Rage cards, particularly their current state in 12.10....will they use fbdev too now?¬* Can ubuntu-x confirm?


(23:23:32) xxxx: So, uhm. Reading through that bug, two things jump out. video=ofonly isn't the default, and only when setting this option do things go pear-shaped.


(23:24:01) xxxx: The fix for it is, currently, a custom Xorg.conf, or a custom radeonfb command-line. Neither of those can be done automatically for the user in any sane fashion.


(23:24:46) xxxx: If real code fixes for this can't be found in time, I think the people really familiar with the issue need to sit down and write some CLEAR release notes we can include for people about how to work around this.


(23:26:54) phillw: so, we're pretty screwed? sorry to use that word. If we can get release notes out, I'll support them & then we can look at a fix as a matter of urgency... would that be okay from the guy who is liasion between -release and -kernel?


(23:28:18) xxxx: I think release noting is the only sane way forward here, other than fixing the actual bug. We can't be writing out custom X config files for everyone, nor custom framebuffer inits based on the resolution and refresh rate they may want.


(23:29:19) phillw: As we are too late to fix the bug, would you object to release notes?
(23:29:56) phillw: well, bugs...


(23:31:27) xxxx: I don't object to release notes, no. This is what they're for. In this case, though, the instructions for "how to find your video card and write a custom X config" and "how to switch to using framebuffer-only graphics, and configure your kernel command-line appopriately" are a bit long for a release note, so nice, clear, step-by-step instructions on a wiki page would be great, and then a release note that briefly describes the problem and points to said wi


(23:33:23) phillw: Oh, do not worry about that! I'm also a wiki person, to get a set of steps in for new people will be clear 1., 2., etc...


So, can I ask that you good people get the wiki area up for the release notes? We will go battle on in 13.04 ¬*
For kernel & -x, the PPC team will be looking for the fix. Thanks for sticking with this arch


Regards,
Phill.



--
https://wiki.ubuntu.com/phillw



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-08-2012, 07:54 PM
o jordan
 
Default PowerPC bugs

Phil, Colin et al
*
This is an insanely easy bug to fix.* I knocked up a patch for yaboot-installer in a few minutes to show how to solve the problem.* I've attached it to the bug 1040526.* The use of the vt.handoff=7 parameter*boots radeon cards into a 16 bit desktop by default.
*
To boot into a higher depth (e.g. 24 bit) or to boot into KMS you will need to add a boot parameter.
*
The difficulty has always been Colin Watson's and lubuntu-qa's insistence that the user should not be expected to add a boot parameter.* At present this is impossible because KMS is the best solution for some people, whereas for other*people*it isn't.* You are asking to be all things to all people.* To be KMS and not KMS at the same time which is impossible.**You have to give the user the choice.* So you have to*create default options*for KMS or non-KMS (which I proposed in my "rambling email") or you let the user add their own boot parameter to do it (e.g. video=ofonly to turn on KMS).
*
Letting the user add their own parameter is obviously the easiest and*lowest risk*option and is the currently documented way.* I've never seen the problem with this.
*
If you want to solve the problem of nouveau cards booting into a very low palette when turning off KMS then you have to build back in the legacy framebuffers:
*
-CONFIG_FB_RIVA=m
-CONFIG_FB_NVIDIA=m
+CONFIG_FB_RIVA=y
+CONFIG_FB_NVIDIA=y
*
This will disable KMS by default, but it can be re-enabled with the video=ofonly parameter.* It will make the nouveau*setup the same as radeon's setup.
*
All you have to do is get the kernel peole to apply the above changes to fix nouveau.
*
*
Adam
*
*

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-08-2012, 08:34 PM
‚ąÖ
 
Default PowerPC bugs

I have to agree. If we are concerned about the user-friendliness, it's less user friendly to have to go look up a FAQ to figure out the solution. If we are concerned people will miss the notes at the yaboot prompt (understandable), we can set the "message" with some fancy ASCII art or change "bfcolor" and "fgcolor" values or crank up the "timeout" setting. This seems to make a lot more sense than the alternative, especially considering most people have b43 wireless and won't be connected to the Internet anyways!

wxl

On Mon, 8 Oct 2012 20:54:57 +0100
o jordan <ojordan12345@hotmail.co.uk> wrote:

>
> Phil, Colin et al This is an insanely easy bug to fix. I knocked up a patch for yaboot-installer in a few minutes to show how to solve the problem. I've attached it to the bug 1040526. The use of the vt.handoff=7 parameter boots radeon cards into a 16 bit desktop by default. To boot into a higher depth (e.g. 24 bit) or to boot into KMS you will need to add a boot parameter. The difficulty has always been Colin Watson's and lubuntu-qa's insistence that the user should not be expected to add a boot parameter. At present this is impossible because KMS is the best solution for some people, whereas for other people it isn't. You are asking to be all things to all people. To be KMS and not KMS at the same time which is impossible. You have to give the user the choice. So you have to create default options for KMS or non-KMS (which I proposed in my "rambling email") or you let the user add their own boot parameter to do it (e.g. video=ofonly to turn on KMS). Letting the user add their own parameter is obviously the easiest and lowest risk option and is the currently documented way. I've never seen the problem with this. If you want to solve the problem of nouveau cards booting into a very low palette when turning off KMS then you have to build back in the legacy framebuffers: -CONFIG_FB_RIVA=m-CONFIG_FB_NVIDIA=m+CONFIG_FB_RIVA=y+CONFIG_FB_NVID IA=y This will disable KMS by default, but it can be re-enabled with the video=ofonly parameter. It will make the nouveau setup the same as radeon's setup. All you have to do is get the kernel peole to apply the above changes to fix nouveau. Adam

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-10-2012, 11:32 AM
Colin Watson
 
Default PowerPC bugs

On Mon, Oct 08, 2012 at 08:54:57PM +0100, o jordan wrote:
> Phil, Colin et al This is an insanely easy bug to fix. I knocked up a
> patch for yaboot-installer in a few minutes to show how to solve the
> problem. I've attached it to the bug 1040526. The use of the
> vt.handoff=7 parameter boots radeon cards into a 16 bit desktop by
> default.

vt.handoff=7 is only one part of a much larger complex of code to do
flicker-free boot, none of the rest of which is present in yaboot, and
it's quite entitled to assume that the rest of that setup code is there.
I'd be fairly concerned that this would break something else on a
chipset-specific basis. Andy Whitcroft, if you're reading this on
kernel-team@, what do you think?

> To boot into a higher depth (e.g. 24 bit) or to boot into KMS
> you will need to add a boot parameter. The difficulty has always been
> Colin Watson's and lubuntu-qa's insistence that the user should not be
> expected to add a boot parameter.

Blame me and misquote me if you like, but actually I'm quite happy with
a situation where QA passes require a boot parameter, although I would
*prefer* it to be otherwise.

> At present this is impossible because KMS is the best solution for
> some people, whereas for other people it isn't. You are asking to be
> all things to all people. To be KMS and not KMS at the same time
> which is impossible. You have to give the user the choice. So you
> have to create default options for KMS or non-KMS (which I proposed in
> my "rambling email") or you let the user add their own boot parameter
> to do it (e.g. video=ofonly to turn on KMS). Letting the user add
> their own parameter is obviously the easiest and lowest risk option
> and is the currently documented way. I've never seen the problem with
> this.

And I've said that I'm perfectly happy with suggesting those or making
other changes to the default yaboot configuration, as long as I get a
signoff from kernel or X guys. To date, the response to my request for
a signoff seems to have been to shout at me more loudly in the hope that
I'll change my mind, rather than actually going and getting a signoff.

Cheers,

--
Colin Watson [cjwatson@ubuntu.com]

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-10-2012, 12:10 PM
Andy Whitcroft
 
Default PowerPC bugs

On Wed, Oct 10, 2012 at 12:32:01PM +0100, Colin Watson wrote:
> On Mon, Oct 08, 2012 at 08:54:57PM +0100, o jordan wrote:
> > Phil, Colin et al This is an insanely easy bug to fix. I knocked up a
> > patch for yaboot-installer in a few minutes to show how to solve the
> > problem. I've attached it to the bug 1040526. The use of the
> > vt.handoff=7 parameter boots radeon cards into a 16 bit desktop by
> > default.
>
> vt.handoff=7 is only one part of a much larger complex of code to do
> flicker-free boot, none of the rest of which is present in yaboot, and
> it's quite entitled to assume that the rest of that setup code is there.
> I'd be fairly concerned that this would break something else on a
> chipset-specific basis. Andy Whitcroft, if you're reading this on
> kernel-team@, what do you think?

The kernel assumes that the framebuffer is initialised and valid when
it starts. With vt.handoff=N we skip kernel initialisation of the
framebuffer, as we wish to maintain its contents. The issue comes when
the existing driver we are handing off to assumes the base state and just
initialises the differences, either though poor programming or through
lack of information from the vendor.

Pushing a change like this for everyone on powerpc (especially given
Apple's penchant for having different h/w in every single batch of its
devices) would need some wide testing before we could have any confidence
we are not just trading off one groups of users pain for another.

From a testing point of view if you are able to change vt to vt1 and back
successfully (the system continues to have a working console (the handoff
data is necessarily lost) then it is realtivly safe to enable this mode.
It only persists until the first chvt, which nominally happens when
plymouth takes over.

If this change can be tested on sufficient representitive h/w I am not
against changing defaults or which modules are enabled. But it is very
late in the cycle to be changing things for 'everyone'. Perhaps we can
get a call for testing together on these options and see what feedback
we get. That should provide sufficient confidence (or not) to satisfy
the SRU team.

Finally from my point of view I am still unclear as to which changes are
needed and which option combinations are available before and after the
kernel changes you propose, if someone could write a clear summary so we
can see what options would need to be considered and testeed that would
help.

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-14-2012, 03:47 AM
‚ąÖ
 
Default PowerPC bugs

My life has been nuts here lately and then had a failed AC adapter on my nVidia-equipped PowerBook but I'm back, albeit incredibly late.

I've tried about every single permutation of various boot paramters (including the apparently magical vt.handoff=7) and have not succeeded into booting into an installable live CD. My only successes have been with an auto-generated Xorg.conf with accelleration off.

I will admit that I don't know much about these parameters and as much as I'd like to, time is running out. To ensure that we can get a PPC release for 12.10, I know that at least among Lubuntu-QA we have discussed providing the documentation necessary for users to actually make use of the new releases. It seems that for nVidia it seems that the only way to make this happen is to get people to install with an alternate and then make the required changes.

I know that we prefer not to use variable boot parameters and I know this is even worse, but unless someone can offer me some other suggestions for boot parameters to try out, I'm not sure we have another choice.

Either way, someone please let me know one way or another so I can write the appropriate wiki page. Thanks!

wxl

On Sun, 7 Oct 2012 16:17:22 +0100
o jordan <ojordan12345@hotmail.co.uk> wrote:

>
> >
> > On Thu, Oct 04, 2012 at 01:53:32PM +0100, o jordan wrote:
> > > Is it too late to get some PowerPC changes into the yaboot options on
> > > the live/desktop ISOs?
> > >
> > > I have an idea to build back in the legacy nvidia framebuffers into
> > > the PowerPC kernel. Whilst this is a backwards step in many respects,
> > > it is the only way (I can think of) to get over the 16 colour
> > > limitation of the openfirmware framebuffer. Currently if you turn off
> > > kernel modesetting with nouveau (and this it seems is a necessity now
> > > for many cards of some vintage) you are thrown into a desktop with
> > > only 16 colours on PowerPC and this is a largely unusuable desktop.
> > >
> > > As this kernel change will disable KMS (which we don't want to do for
> > > every nvidia card) the boot options need updating so that the legacy
> > > framebuffers are turned off by default:
> > >
> > > video=radeonfbff video=rivafbff video=nvidiafbff
> > > Since you cannot easily remove default yaboot parameters a new
> > > 'failsafe' option would need to be created on the desktop ISO without
> > > these parameters. This could replace the 'nosplash' option. The new
> > > yaboot parameters would be: nomodeset vt.handoff=7 I know you don't
> > > think vt.handoff=7 makes any sense with yaboot, but it does actually
> > > boot you into a higher colour depth than you would without it. This
> > > solves the problem of the installer windows not appearing in 8 bit
> > > pseudo colour. I think I can create a patch for yaboot-installer (to
> > > also introduce a failsafe option on an installed system), but I have
> > > no clue what files are involved in the creation of the ISOs. If you
> > > can point me in the right direction then I can take (a rather
> > > uneducated) look at them and see if I can come up with the necessary
> > > changes myself. Of course this all depends on getting the PowerPC
> > > kernel changed, something that I have struggled to do in the past.
> > > Like yourself they are very cautious about changes. I would need help
> > > from somebody within Canonical to support the kernel change. These
> > > changes would not improve the out-of-the box everything working 100%
> > > on the first boot support of the PowerPC port (that can only come from
> > > the kernel/radeon/nouveau developers), but the creation of a failsafe
> > > mode would make the radeon and nvidia user experience much better.
> >
> > To be honest, as I think I said before: I'm not going to touch these
> > options at all without review from the kernel and X teams (CCed). If
> > they say it's necessary, then sure; but I would rather that somebody
> > first checked whether this is a consequence of a bug we can fix, because
> > it's always better for the software to work by default than to require
> > boot parameters.
> >
> > Regards,
> >
> > --
> > Colin Watson [cjwatson@ubuntu.com] Thinking about this some more, the KMS option shouldn't be the default option on the live/desktop ISOs. The crashes/freezes with radeon can take some time to appear. It is quite conceivable that they could occur in the middle of re-partitioning, which would be bad. The more you think about, the more appealing the Debian way of doing things is: Just rely on the user to add video=ofonly if they want KMS. This is basically what the boot message says to do at the moment anyway, although it doesn't explicitly mention KMS. Adam
>

--


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 03:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org