Linux Archive - PowerPC bugs

Linux Archive (http://www.linux-archive.org/)

- Ubuntu Kernel Team (http://www.linux-archive.org/ubuntu-kernel-team/)

- - PowerPC bugs (http://www.linux-archive.org/ubuntu-kernel-team/709598-powerpc-bugs.html)

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=radeonfb:off video=rivafb:off video=nvidiafb:off
> 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]

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

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=radeonfb:off video=rivafb:off video=nvidiafb:off
> 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]

--
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

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

>
> 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=radeonfb:off video=rivafb:off video=nvidiafb:off*
> > 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]

Hi Colin,
*
I am keen too to get proper fixes and that is why bugs have been raised against all the appropriate packages.* However, a lot of the problems are long term ones, for example https://bugs.launchpad.net/ubuntu/+source/linux/+bug/725580*.* Some though are recent e.g. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1058641*.**The problems are not PowerPC specific, but the difference is non-PowerPC hardware has better fallback options, for example the vesa or proprietary drivers.* Neither of these things are available on PowerPC.* My proposal is just to create a*useable*fallback option, something that isn't automatically available at the moment on PowerPC for some nouveau users.
*
I'm coming from this as a radeon user, which as you know has its problems in 12.10 - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1040526*.* As I've explained before, the current PowerPC kernel setup (radeonfb built in) doesn't allow radeon KMS to function and there is no getting around that other than disabling radeonfb.* I've tried to have this confirmed for you in this bug*https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1058753*.
*
The obvious solution is to*remove radeonfb from the kernel.* If we do this then radeon KMS will be used by default.* However,*if for whatever reason*KMS doesn't work for a user and they have to use 'nomodeset' then the fallback*will be*the fbdev driver with the openfirmare framebuffer.* This is currently the case for nouveau users.* The openfirmware framebuffer in many cases is limited to just 16 colours.* This is demonstrated in pictures linked on this nouveau bug report https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1061790*.* The only way to get*more colours (and a useable desktop)*is to use a legacy framebuffer - radeonfb, but we've removed this to enable KMS.* It is a classic catch 22.
*
That is why I suggest the best option for radeon maybe to keep radeonfb built in and just change the boot parameters/options.* If you're creating a fallback option for radeon, then you might as well do the same for nouveau (which would need rivafb and nvidiafb building back in).*
*
To be honest I was happy just to have radeonfb removed since I don't*like PowerPC having a different setup to the other architectures.* I see the 16 colour desktop just a limitation of the PowerPC hardware and if users want radeonfb then they can follow the instructions in the PowerPC FAQ to use it as a module on an installed system.* However, lubuntu-qa were talking of failing the live/desktop ISO over the lack of a useable fallback option.* The alternate*was also in danger due to this bug with lightdm https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1044180*.* I don't know if they*intend to continue to do this (I don't agree with it), but*if they do then we*should come up with*better fallback option.
*
On previous versions of *Ubuntu I believe*you could still use ubiquity in 16 colours.* Now it doesn't even work in 256 colours https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1040544*.* Presumably*the problem*is in whatever widgety thing it uses.* I think you could replicate the problem on non-PowerPC hardware by forcing a 8 bit colour depth.*When*I disable KMS (nomodeset) and use radeonfb I have a 16 bit framebuffer on tty1, but*all the others are 8 bit (including X/fbdev on tty7).* Whatever wizardry vt.handoff=7 does, it makes tty7 the 16 bit framebuffer.**There could indeed be a better way to make X start in a higher colour depth automatically, perhaps this is something ubuntu-x could shed some light on?* As far as I know fbdev takes its colour depth from the framebuffer.* vt.handoff=7 is the part I am least sure about.* When used without a splash screen it gives a horrible corrupt screen early in the boot sequence.* So maybe it shouldn't replace the 'nosplash' option?* I'm only adding vt.handoff=7 to get over the problem with ubiquity, lightdm and network manager that nolonger want to function in an 8 bit depth.*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?*Keeping the legacy framebuffers radeonfb, rivafb, nvidiafb in is messy with all the boot parameter changes, I don't particularly like it, but if it is the only way to satisfy lubuntu-qa then it should be done I suppose.**It would be good to get the qa perspecitive on this.* Time is running out for 12.10 and lubuntu-qa need to decide what they want.**Last time I checked debian wheezy (a couple of months ago) they had radeonfb, rivafb and nvidiafb still built in on PowerPC.* I don't know how they get over this disabling KMS though?* They must expect their users to add boot parameters, for example video=ofonly?*I know you must be very busy at this time, so thanks for reading what has turned out to be another long email!*Regards*Adam
*

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

[Please could you use line-wrap in your mails? They're very difficult
to read this way in my mail client ...]

On Sun, Oct 07, 2012 at 12:38:05PM +0100, o jordan wrote:
> I am keen too to get proper fixes and that is why bugs have been
> raised against all the appropriate packages. However, a lot of the
> problems are long term ones, for example
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/725580 . Some
> though are recent e.g.
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1058641
> . The problems are not PowerPC specific, but the difference is
> non-PowerPC hardware has better fallback options, for example the vesa
> or proprietary drivers. Neither of these things are available on
> PowerPC. My proposal is just to create a useable fallback option,
> something that isn't automatically available at the moment on PowerPC
> for some nouveau users.

I'm sorry. I know you're trying to get this fixed and I'm sympathetic.
But I don't want to end up in a position where I break something else as
a result, and I'm simply not willing to be held responsible for that
since this is not a field I understand well.

I'm not asking that you get the kernel or X teams to apply a proper fix,
necessarily. All I'm asking is that you get somebody from those teams
to ack the proposed changes to the boot menu; that way I can have some
confidence that they won't cause some other problem that I have no way
to predict.

Get a member of the kernel or X teams to sign off on a proposed boot
menu change, and I'll apply it. It would help if this could be as brief
as possible - while I appreciate that you've gone to a lot of effort to
provide many bug references, I'm afraid I simply don't have time to read
through lots of bugs on linux and xserver-xorg-*, given that this is not
my field and so it takes a lot of energy to understand long
back-and-forth threads! The longer the mails, the less likely I am to
manage to absorb anything beyond the third paragraph or so, given how
much I have to do before the 12.10 release. I think this may go for the
other developers in question - you really need to be as concise as you
can.

I'm afraid I am finding the long e-mails on many different but related
subjects frustrating and impossible to absorb properly.

> On previous versions of *Ubuntu I believe you could still use ubiquity
> in 16 colours. Now it doesn't even work in 256 colours
> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1040544 .
> Presumably the problem is in whatever widgety thing it uses.

Any problem with this is certainly in some underlying toolkit and should
almost certainly not be assigned to ubiquity.

> I think you could replicate the problem on non-PowerPC hardware by
> forcing a 8 bit colour depth.

This would be a good thing for somebody to test directly, then.

Cheers,

--
Colin Watson [cjwatson@ubuntu.com]

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

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.
On 7 October 2012 22:59, Colin Watson <cjwatson@ubuntu.com> wrote:

[Please could you use line-wrap in your mails? *They're very difficult

to read this way in my mail client ...]

On Sun, Oct 07, 2012 at 12:38:05PM +0100, o jordan wrote:

> I am keen too to get proper fixes and that is why bugs have been

> raised against all the appropriate packages. *However, a lot of the

> problems are long term ones, for example

> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/725580 . *Some

> though are recent e.g.

> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1058641

> . *The problems are not PowerPC specific, but the difference is

> non-PowerPC hardware has better fallback options, for example the vesa

> or proprietary drivers. *Neither of these things are available on

> PowerPC. *My proposal is just to create a useable fallback option,

> something that isn't automatically available at the moment on PowerPC

> for some nouveau users.

I'm sorry. *I know you're trying to get this fixed and I'm sympathetic.

But I don't want to end up in a position where I break something else as

a result, and I'm simply not willing to be held responsible for that

since this is not a field I understand well.

I'm not asking that you get the kernel or X teams to apply a proper fix,

necessarily. *All I'm asking is that you get somebody from those teams

to ack the proposed changes to the boot menu; that way I can have some

confidence that they won't cause some other problem that I have no way

to predict.

Get a member of the kernel or X teams to sign off on a proposed boot

menu change, and I'll apply it. *It would help if this could be as brief

as possible - while I appreciate that you've gone to a lot of effort to

provide many bug references, I'm afraid I simply don't have time to read

through lots of bugs on linux and xserver-xorg-*, given that this is not

my field and so it takes a lot of energy to understand long

back-and-forth threads! *The longer the mails, the less likely I am to

manage to absorb anything beyond the third paragraph or so, given how

much I have to do before the 12.10 release. *I think this may go for the

other developers in question - you really need to be as concise as you

can.

I'm afraid I am finding the long e-mails on many different but related

subjects frustrating and impossible to absorb properly.

> On previous versions of *Ubuntu I believe you could still use ubiquity

> in 16 colours. *Now it doesn't even work in 256 colours

> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1040544 .

> Presumably the problem is in whatever widgety thing it uses.

Any problem with this is certainly in some underlying toolkit and should

almost certainly not be assigned to ubiquity.

> I think you could replicate the problem on non-PowerPC hardware by

> forcing a 8 bit colour depth.

This would be a good thing for somebody to test directly, then.

Cheers,

--

Colin Watson * * * * * * * * * * * * * * * * * * * [cjwatson@ubuntu.com]

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

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

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.

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

I must say I have to agree with Colin.* In my case I am fairly sure if he or someone removes the radeonfb my old PowerBook will not boot to a workable live session.* I base that on trying the kernel command line "live video=ofonly", which gives me a great graphic plymouth, but stalls everytime before the live session starts.

I personally will continue to test using the command line "live video=1024x786-32@60" which works for me, and I will add to my tests what command line I used, but I will not fail the test if i can get a live working session with decent graphics and complete the installation.

I understand that having to make kernel command is not the desired process , but as i remember before Beta2 and a few days after,* we had to make nomodeset or remove splash on the 12.10 amd64 iso to get a live session if we had nVidia graphics.

Basically what I am saying is if I can get a live session working and make an install IT GETS A PASS.
I will annotate the qa-tracker and let the wiki dudes know what worked for me.

By the way Ron I read your email, and built a dd'ed USB and tested the current daily live 20121007.

'live" or no command freezes in light blue screen with reboot required
"live video=ofonly" plymouth scrolling stops and freezes
"live video=1024x786-32@60" works here gets decent graphics and a live session with (installablity)

Greg nm_geo *

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

Crap typed too fast

"live video=radeonfb:1024x786-32@60" command that works for me

On Sun, Oct 7, 2012 at 7:40 PM, Greg Faith <gregfaith@gmail.com> wrote:

I must say I have to agree with Colin.* In my case I am fairly sure if he or someone removes the radeonfb my old PowerBook will not boot to a workable live session.* I base that on trying the kernel command line "live video=ofonly", which gives me a great graphic plymouth, but stalls everytime before the live session starts.

I personally will continue to test using the command line "live video=1024x786-32@60" which works for me, and I will add to my tests what command line I used, but I will not fail the test if i can get a live working session with decent graphics and complete the installation.

I understand that having to make kernel command is not the desired process , but as i remember before Beta2 and a few days after,* we had to make nomodeset or remove splash on the 12.10 amd64 iso to get a live session if we had nVidia graphics.

Basically what I am saying is if I can get a live session working and make an install IT GETS A PASS.
I will annotate the qa-tracker and let the wiki dudes know what worked for me.

By the way Ron I read your email, and built a dd'ed USB and tested the current daily live 20121007.

'live" or no command freezes in light blue screen with reboot required
"live video=ofonly" plymouth scrolling stops and freezes
"live video=1024x786-32@60" works here gets decent graphics and a live session with (installablity)

Greg nm_geo *

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