Compaq R3000 Series

[Nicolas Blais]

Could you make sure it gets to -STABLE?

Thanks,
Nicolas.

On December 15, 2004 15:36, John Baldwin wrote:
> On Saturday 04 December 2004 01:48 am, Astrodog wrote:
> > On Fri, 3 Dec 2004 21:23:30 -0800, David O'Brien <obrien at freebsd.org> 
wrote:
> > > On Fri, Dec 03, 2004 at 06:54:12PM -0500, Nicolas Blais wrote:
> > > > I would like to know what the situation is with the Compaq/HP R3000
> > > > Series problem at boot with 5-STABLE.  Was the patch to at least get
> > > > it booted commited to -STABLE and/or CURRENT?
> > >
> > > If the patch you're refering to the keyboard related patch, no it
> > > hasn't.
> > >
> > > Someone that experiences the problem needs to take the patch that is
> > > floating around and make it commitable.  This means rather than cutting
> > > out the code that the patch does, it is wrapped around a loader tunable
> > > so it only gets turned off on these laptops.
> > >
> > > Or someone needs to go read the code and explain why removing that
> > > section makes a difference (ie, understand what is really going on),
> > > and make an argument that removing that code is OK for the rest of the
> > > world that isn't experiencing the problem.
> > >
> > > --
> > > -- David  (obrien at FreeBSD.org)
> > >
> > >
> > > _______________________________________________
> > > freebsd-amd64 at freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
> > > To unsubscribe, send any mail to
> > > "freebsd-amd64-unsubscribe at freebsd.org"
> >
> > There are 3 working patches out now, the first being the #if 1 one I
> > used to build that ISO. There's also aparently the flags one, listed
> > on the PR, and the hints one I made awhile back.
> >
> > The code in question, that causes the bug sends a command to the
> > keyboard controller to test the status of the port. The potential bug
> > I can see cropping up with just removing the code is the failure of
> > anything that relies on actually testing the keyboard port. That might
> > extend to some com port console things.
> >
> > To avoid that protential problem for everyone else, and still let
> > R3000Z users actually use their laptops with FreeBSD, without a 2 line
> > fork, I think the flags fix, listed in the PR might be the best
> > solution, atleast for the time being.
>
> So the patch with the flag to atkbd that I posted to the PR does work?  (No
> one has told me that before.)  If it does I'll commit it as it doesn't
> change default behavior and uses the standard flags mechanism (rather than
> another random tunable) to turn off the probe.  Patch included below for
> reference:
>
> Index: atkbd.c
> ===================================================================
> RCS file: /usr/cvs/src/sys/dev/kbd/atkbd.c,v
> retrieving revision 1.43
> diff -u -r1.43 atkbd.c
> --- atkbd.c	10 Jun 2004 20:30:56 -0000	1.43
> +++ atkbd.c	3 Nov 2004 22:37:55 -0000
> @@ -1117,7 +1117,8 @@
>  	 * to set the command byte to particular values.
>  	 */
>  	test_controller(kbdc);
> -	test_kbd_port(kbdc);
> +	if (!(flags & KB_CONF_NO_PROBE_TEST))
> +		test_kbd_port(kbdc);
>
>  	err = get_kbd_echo(kbdc);
>
> Index: atkbdreg.h
> ===================================================================
> RCS file: /usr/cvs/src/sys/dev/kbd/atkbdreg.h,v
> retrieving revision 1.6
> diff -u -r1.6 atkbdreg.h
> --- atkbdreg.h	19 Mar 2000 03:25:12 -0000	1.6
> +++ atkbdreg.h	3 Nov 2004 22:37:22 -0000
> @@ -35,6 +35,7 @@
>  #define KB_CONF_FAIL_IF_NO_KBD	(1 << 0) /* don't install if no kbd is
> found */
>  #define KB_CONF_NO_RESET	(1 << 1) /* don't reset the keyboard */
>  #define KB_CONF_ALT_SCANCODESET	(1 << 2) /* assume the XT type keyboard */
> +#define	KB_CONF_NO_PROBE_TEST	(1 << 3) /* don't test keyboard during probe
> */
>
>  #ifdef _KERNEL