Date: Mon, 21 Mar 2005 10:38:46 -0800 From: Astrodog <astrodog@gmail.com> To: Scott Long <scottl@samsco.org> Cc: freebsd-amd64@freebsd.org Subject: Re: R3000Z Laptop Status Message-ID: <2fd864e05032110387af56562@mail.gmail.com> In-Reply-To: <423F1236.4000401@samsco.org> References: <2fd864e05032105366eaf8b2c@mail.gmail.com> <200503211113.52233.jkim@niksun.com> <423EF3D2.9050205@samsco.org> <200503211141.40409.jkim@niksun.com> <2fd864e05032109304c2ad323@mail.gmail.com> <423F1236.4000401@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 21 Mar 2005 11:28:06 -0700, Scott Long <scottl@samsco.org> wrote:
> Astrodog wrote:
> >>>>>>>I was wondering if the R3000Z fixes have been committed to the
> >>>>>>>RELENG_5 branch, I don't see anything on the lists about it.
> >>>>>>>Should I expect 5.4 to work with the R3000 line?
> >>>>>>
> >>>>>>Yes. hint.atkbd.0.flags="0x9" is all you need now. Try the
> >>>>>>latest snapshot and let us know.
> >>>>>>
> >>>>>>Thanks,
> >>>>>>
> >>>>>>Jung-uk Kim
> >>>>>
> >>>>>Is there any way that these systems can be detected at runtime
> >>>>>and have the work-arounds be automatically activated?
> >>>>
> >>>>I believe DMI-based quirk table is the only way but we don't want
> >>>>to do that, right?
> >>>>
> >>>>Jung-uk Kim
> >>>>
> >>>>
> >>>>>Scott
> >>>
> >>>Well, it's gross, but it's not impossible to do. Is there a
> >>>technical reason why we wouldn't want this?
> >>
> >>The only technical reason that I can think of is some systems (e. g.,
> >>IBM e345 and e346 Opteron servers) have DMI structures in ACPI NVS
> >>area, which is not accessible from early stage. If you want to do
> >>something like that, you will have to add gross hack in pmap.c to
> >>temporarily map it, I think.
> >>
> >>
> >>>Are there any alternatives, like detecting a signature in ACPI,
> >>>either a text string or a certain bit of ASL bytecode?
> >>
> >>We already have the quirk for this broken BIOS. However, keyboard
> >>probing happens way earlier to use this quirk. :-(
> >>
> >>Jung-uk Kim
> >>
> >>
> >>>Scott
> >>
> >
> > Something that came up originally, when this issue was first noticed,
> > was trying to figure out what, if any platforms, would have problems
> > if this was made to apply to all AMD64 machines, and use the flag to
> > drive an opt-out. In as far as I'm aware, no AMD64-based machines are
> > effected if you just "break" the keyboard test functionality, though
> > I'm not certain this is a path worth looking at, since its still a bit
> > ugly.
>
> My number 1 concern is that 5.4-RELEASE 'Just Works' when you load it
> onto a machine. Undocumented and under-documented work-arounds are very
> hard to manage and don't help users that aren't intimately familiar with
> the problem. This is a place where ("Alert! Don the asbestos skivvies
> now!") adding an option to ("I'm warning you! Prepare for flamage!")
> beastie.4th might be a good idea.
>
> Scott
>
Perhaps all of these kinds of things, could be rolled into one very
ugly loader option, that enables pretty much every bugfix out there to
atleast get things installed, a "If all else fails" option. The big
problem with the R3000Zs was that you couldn't even boot the thing to
start fixing it, and I think fixes like that would be the most
critical.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2fd864e05032110387af56562>