lubuntu-qa team mailing list archive

[Phill Whiteside <PhillW@xxxxxxxxxx>]

Hi guys,

the mailing area for this was concentrated a bit more, as it needs
ubuntu-release, ubuntu-QA, ubuntu-kernel, ubuntu-xorg. It's more of an
email to you guys to assure that stuff is still going on. All the various
bugs & possible solutions are being discussed. Below you can see where it
is up to as it is really important you guys are kept in the loop. I'm still
quietly (but nervously) confident that we will get this done, even at this
late stage. Please keep all the bugs updated.


Hi Colin and Phil,
>
>
> Apologies for the tardy reply, but I've been away.
>
> >
> > It's long been a guiding principle of Ubuntu that users shouldn't have
> > to set boot parameters by hand. If you've got to the point of
> > identifying which specific package version change is responsible, it
> > might not be so much harder to narrow it down to a particular
> > (presumably upstream) change, so that the X team can arrange for this to
> > work by default.
> >
> The boot message currently does suggest a boot parameter (video=ofonly).
> I don't know the history of where this came from, but currently it is not
> great advice for people.  If you have a nvidia card then it has no effect
> (there are no nvidia legacy framebuffers built-in).  If you have a Rage128
> card then it will actually stop the X server starting (because by default
> the r128 xorg driver expects a legacy framebuffer).  The only people who
> will need this are radeon users to activate KMS (and this is likely to
> cause freezing on many machines if they don't force PCI mode).  If we
> remove radeonfb from the kernel config then video=ofonly doesn't apply to
> anybody and should be removed from the boot message.
>
> The boot message currently gives no guidance on the boot options that are
> provided (such as the nosplash ones or 64 bit options).
>
> It perhaps is also worth noting that it is very easy to add boot
> parameters in yaboot, much more so than grub.  You just add the parameter
> to the boot option label. There is no need to add say a separate
> 'nomodeset' option because there is no difference in typing the label
> 'live-nomodeset' to typing 'live nomodeset'.
>
>
> > > But, honestly, it is a really easy
> > > problem to overcome and I don't think a big deal needs to be made of
> > > it. I'm much more interested in getting things like
> > > https://bugs.launchpad.net/ubuntu-cdimage/+bug/1051313
>  and
> >
> > Applied, thanks.
> >
> > > https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1043066
>  fixed.
> >
> > I've applied the patch to yaboot-installer and uploaded, but it may be
> > too late for beta-2 and it will need a separate ubiquity upload as well
> > in any event.
> >
>
> Thanks alot!!!  Fingers crossed they don't introduce any problems!
> > > What is happening is that the radeon xorg driver detects drm is
> > > unavailable and unloads itself and the fbdev diver is used instead
> > > (for some reason this defaults to 8 bit). This didn't used to happen.
> > > You could certainly ask the question if it is possible to have KMS
> > > without drm? Not being a graphics expert, I don't know if that is a
> > > stupid question or not.
> >
> > The right answer, then, is to ask a graphics expert. :-) Try #ubuntu-x.
> >
>
> I've created a new bug (with logs) to show what is happening and to ask
> the radeon xserver people.  See
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1058753
>  .  I'm more convinced than ever that the default setup in 12.04 uses UMS
> rather than KMS.  If that is the case, then there is no going back to that
> as Userpace Mode Setting has been dropped (and is never coming back). Phil,
> can you ask #ubuntu-x to take a look at the bug when you speak to them?
>
> > As I tried to explain on IRC, I'm extremely wary of updating the boot
> > message until I have acknowledgement from the X team (or kernel team if
> > necessary) that there's no other way. Boot messages that explain that
> > people have to set boot parameters are not something we like to do if at
> > all possible.
> >
>
> Understood, but I don't know any other way.  I asked the PowerPC kernel
> developers list back in April what the current state of KMS was so that
> we could have the best kernel setup in 12.04 (this was before UMS was
> dropped).  Judging by this recentish bug report
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683796
>  (and I've checked the list for any other news) things are just the same.
> No suspend with KMS, and whether it works or not is a bit hit and miss.  If
> you have freezing problems then the advice was to reduce the AGPmode, or
> force PCI mode and the way to do this is through a boot parameter.  It is
> unlikely that KMS under radeon PowerPC will be truely fixed anytime soon
> since the people with the necessary skills are few.  The problem is also
> that ordinary users do not help developers enough and just leave bug
> reports hanging.
>
> The thing that is causing all the lubuntu bug reports is that the fbdev
> driver defaults to 8 bit graphics.  *I think* there is a rule that if the
> video memory is less than 32MB then it drops to 8 bit to save video
> memory.  This *I think* was introduced to save memory for KMS.  Phil, you
> could ask the kernel/xorg people to confirm this and see if there is a way
> around it?  But, essentially we are still swimming against the tide that
> is we should be using KMS by now and the way to do that is remove radeonfb
> from being built-in to the kernel.
>
> KMS still, as far as I can see, has had very little testing by the
> lubuntu-qa team.  Phil, we need this!  It is no good removing radeonfb at
> the last minute only to find it causes more problems for most people.  I've
> hit a new bug
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1058641
>  with KMS.  A change to the xserver-xorg-video-ati package on the 21st of
> Sept screws it up for me.  I doubt it is a PowerPC specific problem.  If
> that problem does not get fixed (and if it affects a lot of people) then
> the kernel config needs to stay the same so that people can use the fbdev
> driver with the radeonfb framebuffer (and you increase the colour depth
> through a yaboot parameter such as video=radeonfb:1024x768-32).
>
> Although we are focusing on radeon, it is worth noting that if nouveau
> doesn't work out-of-the-box then it can be a real stinker to get it working.
>
> Perhaps it would be better for the boot message not to offer any advice on
> boot parameters, but suggest looking at the troubleshooting section of the
> PowerPC FAQ (https://wiki.ubuntu.com/PowerPCFAQ
>  ) and KnownIssues pages (https://wiki.ubuntu.com/PowerPCKnownIssues
>  ) instead?  Those pages are currently fully up to date, and if the
> PowerPC community let them become out dated then it is their problem.
>
> PowerPC is not in a state that everything works out-of-the-box.  Nor (lets
> be honest) is it likely to ever be.  What it currently does have (in
> Ubuntu) is solid documentation that solves most peoples problems.  I would
> always recommend people to look at it before installing.  For example, I
> notice on the lubuntu-qa there is a lot of chatter about b43 and the
> inability to use wifi without firmware.  That is why the FAQ tells people
> (who don't have an ethernet cable) to download the b43 firmware before
> installing.
> > > Does non-PowerPC Lubuntu suffer from this bug? Basically a previously
> installed Lubuntu is labelled as Ubuntu in grub/yaboot:
> https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/950914
> >
> > I've followed up to this bug. But, in short, it has existed in some
> > form since the very first Ubuntu flavour was created in 5.04, and there
> > is no good reason to consider it any more important now than it was
> > then.
>
> Thanks for looking at it.  It it very easy for the user to change labels
> with yaboot so it is no big problem.
>
> Regards
>
> Adam
> o jordan
> 4 Oct (3 days ago)
> to *carsrcoffins23*, cjwatson, phillw, nicholas.skaggs
> Hi Colin,
>
> 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.
>
> Regards
>
> Adam
> Colin Watson
> 4 Oct (3 days ago)
> to *ubuntu-x*, *kernel-team*, o, phillw, nicholas.skaggs, carsrcoffins23
>
> 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,
>
> ∅
> 4 Oct (3 days ago)
> to o, cjwatson, phillw, nicholas.skaggs, carsrcoffins23
> i know you guys are speaking either globally about ppc or "nationally" if
> you will about nvidia chips in general. on a more local level, it seems
> that an autoconfigured xorg.conf + no 3d acceleration fixes my nvidia
> problem without having to disable kms. i know of no one else using a
> different nvidia chip with ppc so i'm not sure if that can be applied on a
> higher scale. so there's my 2p. hope it's helpful!
> wxl
> --
> o jordan
> 12:38 (5 hours ago)
> to cjwatson, phillw, nicholas.skaggs, carsrcoffins23, ubuntu-x,
> kernel-team
>
> 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
> o jordan
> 16:17 (1 hour ago)
> to cjwatson, phillw, nicholas.skaggs, carsrcoffins23, ubuntu-x,
> kernel-team
>
> 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
>
> --
> https://wiki.ubuntu.com/phillw
>
>

Regards,

Phill.