Date: Fri, 28 Mar 1997 12:33:39 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: Ian Kallen <spidaman@well.com> Cc: freebsd-mobile@freebsd.org, freebsd-hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: (Dell Latitude) psm0/sc0 conflicts killing X? Message-ID: <199703280333.MAA26251@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "Thu, 27 Mar 1997 07:53:23 PST." <Pine.GSO.3.93.970327074355.18816A-100000@well.com> References: <Pine.GSO.3.93.970327074355.18816A-100000@well.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>I don't know what else changed when I went from 2.2-GAMMA w/o PAO (Used
>the zp drivers from the 3c589) to 2.2.1-RELEASE... I'm on a Dell XPi p100
>and Xinside's X server was doing fine w/ 800X600 @256 but since I ran the
>upgrade and applied the PAO patches, I've had to explicitly re-enable psm0
>by booting w/ -c (other X won't start at all)
I think this is normal. The psm driver is disabled in GENERIC kernel,
with or without PAO, by default, isn't it?
>but the keyboard is dead
>once I'm in X. I tried reinstalling Xinside but that made no
>differnce. Any comments or suggestions (if a look @ my kernel config
>is needed to comment on it, I'll send that along as well) appreciated!
I had a report from another Dell Latitude XPi owner stating that if he
tries to change the keyboard repeat rate by kbdcontrol, his keyboard
freezes. He and I are now chasing the problem. It appears that the
keyboard controller of his Latitude behaves in an unusual way. I wonder
the cause of your problem is similar to his.
I would be very grateful if you could try the following patch to
/sys/i386/isa/syscons.c, rebuild the kernel, and try `kbdcontrol -r
fast' or try starting X. Please send me debug messages you see.
You may see something like:
sc0: enabling tty intr. (set_keyboard)
sc0: about to send command and data (set_keyboard)
sc0: command:xx data:yy ret:zz (set_keybard)
in the console (vty0). If you see:
sc0: kbdc is LOCKED!! (scintr)
your problem is the same as his.
Kazu
--- syscons.c-1.205 Mon Mar 3 10:09:00 1997
+++ syscons.c Mon Mar 24 12:04:57 1997
@@ -647,6 +651,12 @@
mark_all(cur_console);
}
+ if (!kbdc_lock(sc_kbdc, TRUE)) {
+ log(LOG_DEBUG, "sc0: kbdc is LOCKED!! (scintr)\n");
+ return;
+ } else {
+ kbdc_lock(sc_kbdc, FALSE);
+ }
/*
* Loop while there is still input to get from the keyboard.
* I don't think this is nessesary, and it doesn't fix
@@ -3114,7 +3131,7 @@
if ((c == -1)
|| !set_controller_command_byte(sc_kbdc,
kbdc_get_device_mask(sc_kbdc),
- KBD_ENABLE_KBD_PORT | KBD_DISABLE_KBD_INT
+ KBD_DISABLE_KBD_PORT | KBD_DISABLE_KBD_INT
| KBD_DISABLE_AUX_PORT | KBD_DISABLE_AUX_INT)) {
/* CONTROLLER ERROR */
kbdc_lock(sc_kbdc, FALSE);
@@ -3128,9 +3145,14 @@
* but the timeout routine (`scrn_timer()') will be blocked
* by the lock flag set via `kbdc_lock()'
*/
+ log(LOG_DEBUG, "sc0: enabling tty intr. (set_keyboard)\n");
splx(s);
+ log(LOG_DEBUG, "sc0: about to send command and data (set_keyboard)\n");
- send_kbd_command_and_data(sc_kbdc, command, data);
+ log(LOG_DEBUG, "sc0: command:%x data:%x ret:%x (set_keybard)\n",
+ command, data,
+ send_kbd_command_and_data(sc_kbdc, command, data));
+ send_kbd_command(sc_kbdc, KBDC_ENABLE_KBD);
/* restore the interrupts */
if (!set_controller_command_byte(sc_kbdc,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703280333.MAA26251>