Proposal: Replacement for VISUALUSERCONFIG (was: Re: Need to update man section 4!)
We can manipulate device hints and loader/kernel environment variables in /boot/device.hints by the set/unset/show commands in the boot loader(8). This corresponds to what we used to do in the USERCONFIG menu in the kernel. I think it may be a good idea to have visual (or friendly?) interface to manipulate the device hints (and other loader variables) in the boot loader, just like the VISUALUSERCONFIG front-end, for novice users and those who are not quite familiar with the boot loader commands. If we are to have this facility in the boot loader, we can get rid of USERCONFIG and VISUALUSERCONFIG from the kernel :-) I wrote an experimental patch to the boot loader. You can find it at: ftp://people.freebsd.org/~yokota/vuserconfig.tar.gz It includes: vuserconfig.diff patch for /sys/boot/common/Makefile.inc and /sys/boot/i386/libi386/vidconsole.c vuseconfig.c put this in /sys/boot/common hints.diffpatch for /sys/i386/conf/GENERIC.hints (and /boot/device.hints) to add some descriptive strings for device drivers Rebuild the loader. Type userconfig at the loader prompt, then you will be in this VISUALUSERCONFIG-like front-end. Use TAB, ENTER, and cursor keys to navigate. Type 'Q' to quit, and you will be put back to the loader prompt. Some notes: - I don't intend to do everything in this front-end. It provides just a simple interface to set/reset/edit device hints and other variables. - This front-end is not an exact clone of VISUALUSERCONFIG. But the basic idea is the same. - Maybe I should have written this in Forth, rather than in C. But, I have almost nil knowledge of Forth. - One big drawback: this will bloat the boot loader and will consume precious disk space in kern.flp... *sigh* I welcome any comments, suggestions, and ideas. Thank you, Kazu In my previous post, I wrote: Thank you for your comments. The User Config menu is completely disabled and isn't available in -CURRENT now. I strongly doubt it will ever come back. You see, we can now set/unset/edit device resource hints from the loader(8) prompt, thus, there is little need to have the old User Config menu compiled into the kernel. Please also have a look at my draft on the man page for device.hints(5). http://people.freebsd.org/~yokota/device.hints.5 The only thing which were available in the User Config, but is not in the loader(8) is the Visual User Config option. But, I expect such visual front-end to edit the device resource hints can be added to the loader, in one way or another. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Need to update man section 4!
Thank you for your comments. The User Config menu is completely disabled and isn't available in -CURRENT now. I strongly doubt it will ever come back. You see, we can now set/unset/edit device resource hints from the loader(8) prompt, thus, there is little need to have the old User Config menu compiled into the kernel. Please also have a look at my draft on the man page for device.hints(5). http://people.freebsd.org/~yokota/device.hints.5 The only thing which were available in the User Config, but is not in the loader(8) is the Visual User Config option. But, I expect such visual front-end to edit the device resource hints can be added to the loader, in one way or another. Kazu Please have a look at my preliminary patch at http://people.freebsd.org/~yokota/man4update.diff Very nice work! Especially all the references to hints. Must have taken quite some time. Thank you :) In the atkbd.4 manpage you changed a part in: The .Nm -driver accepts the following driver flags. They can be set either in the -kernel configuration file -(see -.Xr config 8 ) , -or else in the User Configuration Menu at boot time +driver accepts the following driver flags. +They can be set either in +.Pa /boot/device.hints , +or else from within the boot loader (see -.Xr boot 8 ) . +.Xr loader 8 ) . Same thing can also be found at psm.4, syscons.4, matcd.4 Since both the User Configuration menu can be used (provided that support has been compiled in the kernel) do you think you could mention both somehow? Or is this not really necessary? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
variables in device.hints and loader.conf
I am writing a man page for the /boot/device.hints file. My understanding is that /boot/device.hints is for describing resources for devices, and /boot/loader.conf is for loader variables and kernel tunable parameters. (The loader.conf file, the loader variables, and the kernel tunable parameters are documented in loader(8) and loader.conf(5). The device.hints file is mentioned nowhere :-) In addition to the load variables, the kernel tunable parameters, and resource hints, we now seem to have another class of environment variables which affect the kernel and device drivers. For example, the acpi driver use some variables for debugging: debug.acpi.layer, debug.acpi.level, debug.acpi.avoid, etc. Where are these variables expected to appear? I know we can put them in /boot/loader.conf or /boot/device.hints and they work either way. But, we had better document the proper place to put these variables. A draft copy of device.hints(5) man page is found at http://peopel.freebsd.org/~yokota/device.hints.5 Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: log(9) bug? or feature?
In rev 1.67 and later, the message goes to the log buffer only if a process is reading the log buffer. If no process is reading, the message goes to the console ONLY, and it is not put into the log buffer. This behavior is inconsistent with the above comment. Is this a bug introduced in rev 1.67, or is it the intended new behavior and the comment is out of date? Actually, I think this is consistent, since console messages is now also put in the buffer, but I am not 100% sure... You are talking about printf(9) printing messages to /dev/console AND the log buffer. I was asking about subr_prf.c:log(9). 1) log() in subr_prf.c rev 1.66 or earlier 1a) if a process is reading the log buffer... log() --- the log buffer ONLY 1b) if no process is reading the log buffer... log() +-- the log buffer | +-- /dev/console 2) log() in rev 1.67 or later log() --- the log buffer ONLY The comment in subr_prf.c documents the behavior 1). But the current version has the behavior 2). If the behavior 2) is what we want, the comment should be updated as such. If the behavior 1) is the correct one, log() should be fixed. I favour the behavior 1), because log() output will be lost if log() is called before syslogd starts, and we have no way of recovering it afterwards. As for printf(9) printing both to /dev/console and to the log buffer, I don't care much. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: log(9) bug? or feature?
Sorry, 2) log() in rev 1.67 or later log() --- the log buffer ONLY This should be 2) log() in rev 1.67 or later log() --- the log buffer ONLY, if a process is reading it log() --- /dev/console ONLY, if no process is reading the log buffer Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
log(9) bug? or feature?
In /sys/kern/subr_prf.c rev 1.66 and earlier, log(9) printed the
message to the log buffer if the log buffer is being read by a process
(syslogd). If no process is reading the log buffer, the message went
to BOTH the log buffer and the console, as documented in the comment
just above log(9).
/*
* Log writes to the log buffer, and guarantees not to sleep (so can be
* called by interrupt routines). If there is no process reading the
* log yet, it writes to the console also.
*/
void
log(int level, const char *fmt, ...)
{
[...]
In rev 1.67 and later, the message goes to the log buffer only if a
process is reading the log buffer. If no process is reading, the
message goes to the console ONLY, and it is not put into the log
buffer. This behavior is inconsistent with the above comment. Is this
a bug introduced in rev 1.67, or is it the intended new behavior and
the comment is out of date?
The following patch will print the message to BOTH the log buffer and
the console if no process is reading the log buffer.
Kazu
Index: subr_prf.c
===
RCS file: /src/CVS/src/sys/kern/subr_prf.c,v
retrieving revision 1.72
diff -u -r1.72 subr_prf.c
--- subr_prf.c 12 Sep 2001 08:37:45 - 1.72
+++ subr_prf.c 2 Oct 2001 11:37:31 -
@@ -194,7 +196,7 @@
pca.tty = NULL;
pca.pri = level;
- pca.flags = log_open ? TOLOG : TOCONS;
+ pca.flags = log_open ? TOLOG : (TOLOG | TOCONS);
va_start(ap, fmt);
retval = kvprintf(fmt, putchar, pca, 10, ap);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
How to distinguish the SMP kernel and the UP kernel
Is there any way for the loadable module to detect if the kernel is configured for SMP or UP? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/isa psm.c atkbdc_isa.c
Modified files: sys/isa psm.c atkbdc_isa.c Log: Yet another turn of workaround for psm/ACPI/PnP BIOS problems currently experienced in -CURRENT. This should fix the problem that the PS/2 mouse is detected twice if the acpi module is not loaded on some systems. Revision ChangesPath 1.24 +2 -2 src/sys/isa/atkbdc_isa.c 1.40 +84 -39src/sys/isa/psm.c Can it be that this fix is responsible for PS/2 mouse being detected zero times? :-) :-( Dmesg output is in a separate message. This is most likely to be an ACPI problem. Please try disabling the acpi module (unset load_acpi at the loader prompt) and boot -v, then send me dmesg's output. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: moused problems, not related to acpi
Please type boot -v at the loader prompt and send me dmesg's output after the system has started. I would also like to know more about your mouse: manufacturer, product name, model No, a URL which lists this mouse, etc. Thank you, Kazu -current as of yesterday. I've got a new mouse, but it isn't compatible with moused: I get psmintr: out of sync (00c0 != ). and any cursor movement moves the cursor to the upper right edge of the screen. Further mouse movement results in virtual button presses. Attached is the output of moused -p /dev/psm0 -d -f. The output shows in this order: - move to the left - move to the right - move forward - move backward - push left button - push right button - push middle button - scroll wheel forward - scroll wheel backward - push the second left button (yes, there's a second button behind the left button) - push the second right button The mouse is labeled as a 600dpi mouse (-r 600 didn't changes the behavior). Win2k has no problems with it, unset acpi_load at the loader prompt didn't changes the behavior. Bye, Alexander. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: moused problems, not related to acpi
On 25 Sep, Kazutaka YOKOTA wrote: Please type boot -v at the loader prompt and send me dmesg's output after the system has started. Omitted in the mail to -current. Thank you. Hmmm, the output doesn't show anything suspicious. It looks like that the mouse is just an ordinary one... psm0: current command byte:0047 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:, flags:, packet size:3 psm0: syncmask:c0, syncbits:00 We need some more tests. Would you add the following lines to your kernel configuration file, rebuild the kernel, and do 'boot -v' again? options KBDIO_DEBUG=2 options PSM_DEBUG=2 Kazu I would also like to know more about your mouse: manufacturer, product name, model No, a URL which lists this mouse, etc. NoName 4D Browser Mouse ??? (FCC ID:10WCM-B700) ^^ either '1' or 'I' and '0' or 'O' ??? (got it in a local store for DEM 20 (~$10?)) Additional info: - made in china - 5 buttons + wheel - 600 dpi - tracking speed: 250mm/sec - it's also available as a serial or USB mouse and with 400 dpi My old mouse died either while unplugging it from a running system or by plugging it into another running system (yes I know, PS/2 isn't hot-pluggable). The new mouse works with W2K in the first system, the second system refuses to boot if the new mouse is plugged in. I try it with another mouse later, to determine if the second system (Asus P2L97-S) is damaged or not. And I try the new mouse with a 3rd system. Bye, Alexander. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PS/2 mouse (psm0) is not detected with recent -current
I tried to upgrade my -current system today (I hadn't upgraded for a couple of weeks before this), and my PS/2 mouse went undetected. [...] and here's my verbose dmesg from a boot with today's sources: I notice that my atkbdc gets allocated as: atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 Yes, I know we get this output on some systems... which Kazutaka YOKOTA suggested in a different thread might indicate some weirdness. Any suggestions? I tried setting acpi_load=NO at boot,but the acpi module gets loaded anyway. Um, you should have typed unset acpi_load at the loader prompt to disable the acpi module... Please do unset acpi_load boot -v at the loader prompt and send me dmesg's output. Thank you, Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PS/2 mouse (psm0) is not detected with recent -current
On Fri, Sep 21, 2001 at 03:00:08PM -0400, Viren R.Shah wrote: atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 ^ Same here (Asus CUBX mobo): atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 Would you do the following and send me dmesg's output in each case? 1. Start the kernel with the acpi module enabled; just type boot -v at the loader prompt. 2. Reboot the system. This time disable the acpi module by unset acpi_load boot -v Thank you, Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI, PS/2 and USB (was: Re: ThinkPad, ACPI, and PS/2 mouse)
Hi, I've just noticed strange behavior of psm probing (w/ and w/o acpi). [...] This is not a ThinkPad, but FIVA 206VL (PS/2 mouse PnP ID = 0x130fd041; normal one), the psm is no longer recognized if USB is not compiled (or USB module is not loaded at loader). I have never heard of this type of error before! Here is difference between dmesgs of kernel w/o and w/ usb module. [...] @@ -370,7 +377,10 @@ kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d atkbd1: unable to allocate IRQ psm0: current command byte:0047 -psm0: the aux port is not functioning (-1). +psm0: PS/2 Mouse irq 12 on atkbdc0 +psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons +psm0: config:, flags:, packet size:3 +psm0: syncmask:c0, syncbits:00 bt0 failed to probe on isa0 cs0 failed to probe at port 0x300 on isa0 ed0 failed to probe at port 0x280-0x29f iomem 0xd8000 irq 10 on isa0 @@ -430,10 +440,8 @@ unknown: PNP0800 failed to probe at port 0x61 on isa0 unknown: PNP0c02 can't assign resources unknown: PNP0c02 at iomem 0xd8000-0xdbfff on isa0 -psmcpnp0: PS/2 mouse port at irq 12 on isa0 -atkbd1: unable to allocate IRQ -psm0: current command byte:0047 -psm0: the aux port is not functioning (-1). This means that the keyboard controller on the motherboard didn't respond when it was asked to test the aux (PS/2 mouse) port. You usually see this error when your system does not have the PS/2 mouse port... I cannot think of a reason why the presence or absence of the usb module affects the behavior of the motherboard keyboard controller... I must say this is the most arcane error. +unknown: PNP0f13 can't assign resources +unknown: PNP0f13 at irq 12 on isa0 fdc1: cannot reserve I/O port range (1 ports) unknown: PC standard floppy disk controller failed to probe on isa0 BIOS Geometries: [...] I tried to load acpi module too, but it seems acpi doesn't affect psm probing on this machine. In summary; with USBwithout USB ---+---+- with ACPI OK NG without ACPI OK NG Ok, this is strictly the psm and usb modules' problem, then. Do you remember when your PS/2 mouse was detected correctly without the usb module? Kazu I enclosed dmesg -v output of kernel w/o usb and acpi. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New ACPI dangerous false devices
I think you had better supply some more information, such as entire dmesg output after boot -v. Kazu With new ACPI and my ASUS TUSL2-C I got following false devices configured: sio1: configured irq 3 not in bitmap of probed irqs 0 sio1 port 0-0x7 irq 3 on acpi0 sio1: type 8250 (I disable sio1 in BIOS, it must not assign irq 3 here) sc1: System console on isa0 sc1: MDA 16 virtual consoles, flags=0x0 (I have no sc1 or MDA) sio1 maked by ACPI is dangerous ineed because when try to write something to /dev/cuaa1 I got system lockup. Please do something with it. Also I got lots of: fdc1: cannot reserve I/O port range (6 ports) ppc1: cannot reserve I/O port range I don't think they are dangerous because no devices created. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ThinkPad, ACPI, and PS/2 mouse
It now appears that some IBM ThinkPad models assign a distinct PnP ID to the PS/2 mouse port. If you have ThinkPad and its pointing device is not recognized when ACPI is loaded in the latest -current system, please do the following 1. Disable ACPI and boot unset acpi_load boot -v 2. Send the entire dmesg output to me. Don't forget to tell me the model name of your ThinkPad too. ThinkPad models currently known to have this behavior: model PnP ID for the PS/2 mouse port ThinkPad 570E IBM3780 Thanks Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
Thank you for your report. On Sat, Sep 08, 2001 at 12:15:59AM +0900, Kazutaka YOKOTA wrote: Please send me the entire dmesg output after you boot the system with boot -v at the loader prompt. ok. And do you have the following line in /boot/device.hints? hint.psm.0.irq=12 yes. I tried with and without some lines in /boot/device.hints. attached outputs is with the following hints: hint.atkbd.0.at=atkbdc hint.atkbd.0.irq=1 hint.atkbd.0.flags=0x1 hint.psm.0.at=atkbdc hint.psm.0.irq=12 hint.vga.0.at=isa hint.sc.0.at=isa hint.sc.0.flags=0x100 hint.vt.0.at=isa hint.pmtimer.0.at=isa hint.spic.0.at=isa hint.spic.0.port=0x10a0 hint.acpi.0.disable=1 Your forgot to put the following lines in device.hints. hint.atkbdc.0.at=isa hint.atkbdc.0.port=0x60 See /sys/i386/conf/GENERIC.hints. However, there definitely are some strange things about ACPI and PnP BIOS in your machine... Your first dmesg: the acpi module is enabled. acpi0: SONY Z1 on motherboard Timecounter ACPI frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 [...] atspeaker0 port 0x61 on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 ~ atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d atkbd1: unable to allocate IRQ psm0: unable to allocate IRQ atkbd1: unable to allocate IRQ psm0: current command byte:0047 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:6000, flags:, packet size:3 psm0: syncmask:c0, syncbits:00 psmcpnp0 irq 12 on acpi0 The PS/2 mouse is detected. But, the AT keyboard driver is assigned with port resources 0x64 and 0x60; the order should normally be 0x60, then 0x64... Your second dmesg: the acpi module is disabled. As you don't have hint.atkbdc.0.at=isa hint.atkbdc.0.port=0x60 in device hints, the kernel tried to attach the keyboard controller, keyboard and PS/2 mouse based on the PnP BIOS information. This should normally work, despite the missing above lines in device.hints, because the information supplied by the PnP BIOS is supporsed to be correct. But, see below. [...] pnpbios: 17 devices, largest 210 bytes PNP0c02: adding fixed memory32 range 0xfff8-0x, size=0x8 [...] pnpbios: handle 15 device ID SNY7001 (0170d9cd) PNP0401: adding io range 0x378-0x37f, size=0x8, align=0x1 PNP0401: adding io range 0x778-0x77f, size=0x8, align=0x1 PNP0401: adding irq mask 0x80 PNP0401: adding dma mask 0x8 pnpbios: handle 18 device ID PNP0401 (0104d041) pnpbios: handle 20 device ID PNP0f13 (130fd041) ~~~ This is the PS/2 mouse reported by the PnP BIOS. It should be assigned with the irq mask 0x1000. But it's missing here! atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 irq 1 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d atkbd1: unable to allocate IRQ psm0: unable to allocate IRQ [...] (The above failure is expected, and you can ignore.) psmcpnp0: PS/2 mouse port on isa0 You should see psm0: PS/2 mouse irq 12 on atkbdc0 psmcpnp0: PS/2 mouse port irq 12 on isa0 at this point. But, because the irq was not assigned to the PS/2 mouse node earlier by the PnP BIOS, the mouse failed to attach. I have never seen this failure before ;-( I will think about what I can do... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1246] ACPI and PS/2 mouse problem
Please send me the entire dmesg output after you boot the system with boot -v at the loader prompt. And do you have the following line in /boot/device.hints? hint.psm.0.irq=12 Kazu I don't know why, but NOW I have broken PS/2 mouse _without_ acpi module :( VAIO Z505HS. atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 irq 1 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d atkbd1: unable to allocate IRQ psm0: unable to allocate IRQ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1247] Re: ACPI and PS/2 mouse problem
I'm not sure exactly what to do here. These resources contain information we need to know about where we cannot put PnP devices. But if we feed the information into our current resource manager, we end up with conflicts with existing devices. For the moment, I've changed the code to allocate IRQs shared. The PS/2 mouse driver should do the same. I'm still trying to work out what we can and cannot depend on here. 8( The psm driver has been updated to share the irq 12, as of rev 1.37. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI and PS/2 mouse problem
As reported in this list by several people, you may be seeing that your PS/2 mouse is not detected after the recent ACPI update. This seems to be caused by ACPI in some BIOS assigns IRQ 12 (mouse interrupt) to both the PS/2 mouse device node and the system reserved resource node. To see if this is to be your case, put the following line in /boot/device.hints and reboot. debug.acpi.disable=sysresource If this brings your mouse back, I recommend you to keep that line there until the proper fix is committed. If it doesn't solve the problem, there must be other causes ;-( You had better contact the FreeBSD ACPI developers ([EMAIL PROTECTED]) ML. Kazu PS: I am going to commit some update to the psm driver shortly. But, that alone won't fix the problem. Sorry... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
PS. I just removed and checkout sys/isa. hope you did a make clean too... I tried this too - nothing changed. :( Where is my netscroll genius... I want it back ;-) What was the message? Is that the following? panic: nexus_setup_intr: NULL irq resource! Or, something else? Can you provide the last few boot messages before the panic? Would you please apply the attached patch in addition to my last one, in order to get some more information on your system and ACPI BIOS. I am afraid this patch still won't make your mouse available, but it may stop your system from panicing and let you go through the boot process. When the system comes completely up, please send me entire dmesg output and /boot/device.hints. It now appears we have several classes of symptoms regarding the PS/2 mouse and ACPI. Each may need different trick to fix... Thanks Kazu --- psm.c-save Wed Sep 5 18:54:27 2001 +++ psm.c Wed Sep 5 19:07:09 2001 @@ -2818,8 +2818,14 @@ bus_set_resource(psm, SYS_RES_IRQ, 1, irq, 1); bus_delete_resource(me, SYS_RES_IRQ, 0); + printf(adding...); + BUS_PRINT_CHILD(device_get_parent(psm), psm); + + return 0; +#if 0 /* ...then probe and attach it */ return device_probe_and_attach(psm); +#endif } static int @@ -2830,6 +2836,9 @@ if (ISA_PNP_PROBE(device_get_parent(dev), dev, psmcpnp_ids)) return ENXIO; + printf(probing...); + BUS_PRINT_CHILD(device_get_parent(dev), dev); + /* * If we find an atkbdc device on the same bus, * create our copy there. @@ -2838,6 +2847,9 @@ device_get_unit(dev)); if (atkbdc (device_get_state(atkbdc) == DS_ATTACHED)) create_a_copy(atkbdc, dev); + + printf(quiting...); + BUS_PRINT_CHILD(device_get_parent(dev), dev); /* keep quiet */ device_quiet(dev); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
Thank you. I got the files. Then, would you remove my previous small patch from psm.c, and put the following line in /boot/device.hints instead and reboot? debug.acpi.disable=sysresource Or, you may type set debug.acpi.disable=sysresource at the loader prompt before boot -v. Kazu You missunderstand or maybe i wrote something wrong. Now i've got a bootable kernel with no panic and NO psm0 messages at all. So i had to boot -v to produse some. Now i applied your patches and next mail would be with boot -v messages process. When the system comes completely up, please send me entire dmesg output and /boot/device.hints. Ok. It now appears we have several classes of symptoms regarding the PS/2 mouse and ACPI. Each may need different trick to fix... I think that it is ASUS A7V-133 feature. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
As I wrote in another mail to Harti Brandt and cc'ed to you, it now appears that ACPI on your motherboard declares IRQ 12 BOTH in the PS/2 mouse resource descriptors and in the system reserved resource descriptors. The system reserved resources are sucked by the sysresource driver in the acpi module. If the psm driver can get at IRQ 12 BEFORE the sysresource driver, or the sysresource driver is made to be probed AFTER all other acpi device nodes are probed, all should be fine... As some other people are not having this problem, this may be called a quirk or anomaly, to say the least. Kazu Then, would you remove my previous small patch from psm.c, and put the following line in /boot/device.hints instead and reboot? debug.acpi.disable=sysresource Or, you may type set debug.acpi.disable=sysresource at the loader prompt before boot -v. Wow, my NetScroll is back in bussiness!!! ;-))) So is it buggy BIOS, chipset, ASUS or PS/2 mouse? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
So i can't use X server. The problem appeared right after i've compiled and installed freshly cvsuped kernel after new acpi first commit (31.08). I'm sending dmesg and kernel config files in attach, and waiting for help/comments. Thank you. Please apply the attached patch in /sys/isa and see what it does. Thank you. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
So i can't use X server. The problem appeared right after i've compiled and installed freshly cvsuped kernel after new acpi first commit (31.08). I'm sending dmesg and kernel config files in attach, and waiting for help/comments. Thank you. Please apply the attached patch in /sys/isa and see what it does. Thank you. Kazu begin 666 atkbdcident.diff.gz M'XL(%:OE#L V%T:V)D8VED96YT+F1I9F8 Q5C_4^)*$O\Y_!7SOH?D ) M(C6[JTK7UUZ\J)N[?WK5(Q30E)+Q)T.=Y_N_7W3-))A#4MU?UCK),,M/= MTU\_,SV3*._#IF7WET'OALFWH%?___VJ79S,V#Q=\R-J)\-MGWV;T3!Z3 M-BS2UMS[FNIR+D]V%TPP0\DC.F'/0Z=2#YGK35K?PLJ]EJM4H#1LV MG;9]U.[:S#X.H?#3L@*:9I5E$M^T^RA/1CVG-J'#ZS5MZT^,_L=ZXA] M^%!C-9:D7AKZ+(Q20PE8B?B:UP/0TN=NRNE5)%YZ6IY]]N$IJ*,!O.J8/ M]6_#15 P7*\3P6R6 16,R_]01K1MZ26S73@!]-KJ,PK59@)C4NCKR@ON M!6YX[XD7.*5R(:/56.DT!I5JF ^:]MP#1Z--!!WTZZ%L#\JDQG\['U]] MNAAELI-ULN)18!FPA'O#(RY/QML6%4@B=K$.)08XA/7BGX$2W+G6EKLW MY.UYCKPI5'+FWKW_55 _B##E9?)B.C19T[G)WF='LJ$XUGS$:#Q$+ M]H[INABF2N%I_MVPVH6J2T?#F:?$Y970EYQ^P)I+NQ#RY,2U@/6G= M@GL).3UY^F+3;[V\R]',_R7TXO+*8FH5QE_ YM3*$=V=_M6KP][J6 MTY66 S:L11(:Q.CFBIC+V/PZ#6TF(JO5 OIZD?1TFJET]1.+764ZV512O MR8=O)[ 1#YD1K!$CA3=\!U]FUKF8'Y#S:UZ72Z!XB^T%@#?7Q[L66P_ M;9#3V?X^2]E/Y/Z6HR3$G%=B.[26RQBOYZ$_^;QO)ZD8NVGK*0DA/;/;WZ M\\1Y):%8L[=+Q=_/9UL?_ S-_'EQ-$Z7B3RAU:ZFW*!^*7S2]203*:KV' M5 3W6#P1(W)UK.V]8+[R;I'H5FJI)YNRY4(4'OA4\2J!J6*]1I:4!.H M%*RXIY+G=W)M\]@T@-$FOL!4OL2?(4$60Q//4Q_1)_#Q5I)4!/JC\LCL M$OK(TEI^B;#(LA#?BMPU5.XV WS*\D1)A=FEVD1B0^3S7I9/=9L-C0E4 M6($=Q[$ZAU!1P.KYQCC_%F,; DV@]%:K2;\(\UV6D0,$AII6!3D/;]: M!RR-V35GTK7R4RYC'Q!K_ZCN64C40S%/RE4L%X@%!R5B^R;@[[D[OT4@C M?@A9%D@G[@J_;QT3R9(0TN_2D!*$K(,LDS4(OI3B?WQ%[_^WSJR$]T5. M*\!78 N*F\U^NX4C-_Z+RB :[Y!6P W#-+ U\ %77X8'LUJ#1U#0S M1?OG[^+-?;2MD:@E6IS%\(YDZ#)SW94K#Q9R%5_##7-M1\FZQ7MB@0 MK+15A(6R/[2)F%N;BG!W=S1,S7P!K]578QG0]T^)YH#[OW-^\TMXX=JF] MR2DGEW4VI9!NV.S9SNT#X=GLRB;F\KIG,(C1 A^V''CK,/.Q93D]U M-^!$?^$E2=:'N-D @HI';+D=!CP* WGC_5 A/COGR[?66XFU=4W7/M$4F MC_J[R I]T28EJ*.8ZSIB1L)V546_+T-@YA2'J,_G'OR )GTJ]A*+/W5 MO5+=JI#AEJ%YH9I.FF[I?GBY]]$\H9J/O4,@VX67Z-D#PI3DG'U4:.JSR? M:%A/AVKSS0%?0*()+#M]JP2XO,$;CKIPR[ -@3(BXK%/=T_CX=: MCD;NV:?)YU%=BJ 0HIOO90@MV$N5G0;%=9:6^2I:_3Y'30CO+N]LOE7W MKQ3#PJ8W5:G==J?/G,ZP9P\/!P;Q84GK)%3,]O'PL#,\[*MC6A^#C0_55D/[ M33_:INTXUIL:\3CJZ#+1]S+[(43S=2GJ:X,8W3QQ6RC P6@J@ EG\ MFM.ZUH2%.%OE.L3F2@RBF,WE4SQ5\D7DV/NC:=%O3M1WE S!,TJ@T@B] M,^E'$T%^W85/BRT4?8,$WDDA8$J7,P]*/?0$/-)]C :9FU[@MQ-U632 M-T0F7Q4.#(X H(C0(*!0GJP!L@ROX*XA$:;[,XLXVBE^SXZVECZD'B\) MX '.\P*]QJ;1%%(PP/-G'/T,;8S@$ OF95*8([-8P$O#P'!^12F$X5B!T MX_'HGD=!#V1 HE?BK)FEDS7_MUW$'-T)/RVFH,S#[0\#A2,[!:PIU[AO MDU+S.HY3X+J.$]Z@.[!_RJNP5DN-G@AG_I)ULKL#=+32^YJR=^ZSU.0'# M9^,$A%#M8V2[4/R#X[YU)-,(#FZG'P;7[KG%Z.OG\=U**ECL4697@6/WI7 MSU9;LN3%#0S)O0R5[=API*U?YP]8H!37@3+3EFRES$2S;],OTXN9A1RW-Z M-IT(%,;^3,_36?G9T#E*G6^G)Z/#6,/5O57T6JOVD,[?A!)8'SVAD1)A7 M3XF81DXVZ631E CET,EV2Z-C %^NOUK-5SHT+J2+5UK0@6OA[(M]#Z,S2 M_IL77.X16;12G0KGHK@-[7'( 1T1Q:*8T59/42JMI%HG+#7DE9COR]? :#F MKT[7G@=VSX'S_'36[LB-A6[N]MBS1N 4O:?G*[$2,73U7D*ZHR\ZW0M]OW[ M]YQGRQXWYL2-ES/]/58WT#?[EMAIL PROTECTED];\+DF1)39[B%O!IDBU;[]!VE M1\E^^*TN+!$,CO*R__0J6R3T+@2P%F5=R/C+]\G%1J8W,;K18P=^NM M5CQ218*1 L?N1LD[T,?D@O8MAN*5*V9EK=]S!FJS3'N\2DEO.;OCC]Q M)P*\=$E%O%A )I[T=Q$-Y?P8M-9:ZT]D2Q!7S!4_Z2HQJY8H#KH 8=-/B MA^Y):$M'Y2+^P#H4B-E6*G8@2[I #],D@NI4I#C=.A.5TD!81'PR.W6Q MEJ:7%Q_'^@VZC(Z0Z=[%*TPCNC /\ /RT!(E#IBKULQV/#BH-T)7@WA M)8+D4/LBAH^\ 22']!.[\M*6X-Z'ZH=/FRI3/=?9QM@H0\(U;=%N;)IM: M_E^7C[F:H[Z^!%D[]75Z=FG\4BZHURCV:Y3-.F07K]@OZYGTBPEGT;4 M#92YZ_ZI%.C*BUC5?FSR;VV)*,%R+,V\%7[WMH;=TCQ_%7X\3\%Z1$N/5K #'0 end To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
Please apply the attached patch in /sys/isa and see what it does.
It does panic with a smiling face ;-)))
panic message was bad ivar read request
Would try the following patch for /sys/isa/psm.c IN ADDITION TO
my previous patch?
(This is a test patch. It's not a final fix.)
Kazu
--- psm.c-save Tue Sep 4 20:51:39 2001
+++ psm.c Tue Sep 4 22:29:49 2001
@@ -779,12 +779,8 @@
psmidentify(driver_t *driver, device_t parent)
{
-/* if we are in PnP mode, don't create a device node for now... */
-if (isa_get_vendorid(parent) != 0)
- return;
-
/* always add at least one child */
-BUS_ADD_CHILD(parent, 0, driver-name, -1);
+BUS_ADD_CHILD(parent, 0, NULL, -1);
}
#define endprobe(v){ if (bootverbose)\
@@ -814,6 +810,17 @@
BUS_READ_IVAR(device_get_parent(dev), dev, KBDC_IVAR_IRQ, irq);
BUS_READ_IVAR(device_get_parent(dev), dev, KBDC_IVAR_FLAGS, flags);
+/* see if IRQ is available */
+rid = 0;
+sc-intr = bus_alloc_resource(dev, SYS_RES_IRQ, rid, irq, irq, 1,
+ RF_ACTIVE);
+if (sc-intr == NULL) {
+ if (bootverbose)
+device_printf(dev, unable to allocate the IRQ resource (%d).\n,
+ (int)irq);
+return (ENXIO);
+}
+
sc-kbdc = atkbdc_open(device_get_unit(device_get_parent(dev)));
sc-config = flags PSM_CONFIG_FLAGS;
/* XXX: for backward compatibility */
@@ -1083,19 +1090,8 @@
endprobe(ENXIO);
}
-/* see if IRQ is available */
-rid = 0;
-sc-intr = bus_alloc_resource(dev, SYS_RES_IRQ, rid, irq, irq, 1,
- RF_ACTIVE);
-if (sc-intr == NULL) {
-printf(psm%d: unable to allocate the IRQ resource (%d).\n,
- unit, (int)irq);
-endprobe(ENXIO);
-} else {
- bus_release_resource(dev, SYS_RES_IRQ, rid, sc-intr);
-}
-
/* done */
+bus_release_resource(dev, SYS_RES_IRQ, rid, sc-intr);
kbdc_set_device_mask(sc-kbdc, mask | KBD_AUX_CONTROL_BITS);
kbdc_lock(sc-kbdc, FALSE);
return (0);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
Would try the following patch for /sys/isa/psm.c IN ADDITION TO my previous patch? (This is a test patch. It's not a final fix.) panic: nexus_setup_intr: NULL irq resource! Ok, this is one last test patch. Please remove ALL my previous patches and apply this one in /sys/isa. Thanks. Kazu begin 666 atkbdcident.diff3.gz M'XL(%@HE3L V%T:V)D8VED96YT+F1I9F8S ,T;:7?;QO$S]O6RHO* Q0! M4K:-+1$QVPL49%HQVG:AP!2PM/%,$ H!35=G][9V9W@7!0W*35\QP7N M[-P[,SL3'W^VQ%SD]MKWPEB=]O;^.;+_S8N3Z[8.)CP(]:.(Z]]\NZ*/N/' MN V;M+7MS/N-B=1P.^#Z06P4A%-F;]O6AA^,QZPU9ZT(O^:0;+5:^GC M8UEVV]IO=RQF=X^LW:/NCD$PFLUFQ3#MK7#[(.CG=VC3G?CN^]8:[=CVAW6 MW-TQ[1WVW7;;(/Y_-Z;N''L)(: H :.X6TS3MPD\-A]/CB=#S:1*,'VM^ M%-SSR$E80SR9GP.(S 0QU6R[7!5$*1$UKZV:Y2:)Z]VLG!;Q'ZW$%J M+S+$@551#=8PXT^X+QTI@1PQY.;T X8I'XO_R+_8-^[C1-$[[[\[ZH]?# M4[6A8H.9YTK=W#ER42X:6AJ)XG2#=U/E1/%,2;.B=@(@IXWS+M ];WS[ M!R1@(P[^S-Q3= 5A^/$Q*$^KDHWXWFV@*N1%,JF\T@3? G7:#N9,']S%F MKN\#!]F$NW'PBEGWDTP :ZW8=;+MU=.[_34.7D]'-:$R!,9@%8 M_Z=NH M3P\30_ UQ-Y!MLD0)M@'A:QASFS!+$-8A^/X-C?N!U#EIA$GT=Q+P/;B M!YYG#7@?GSB0$FZ2%30/694OP2Q3XIZW#;F5A([$:)MOLC=@/_/$Z M=-_4^@5B.\3MQ@BFPDA(QB!%G'@LM\[=0;OI*C@\ 4# #1^K$99/] M\/+TA*8Y@\L?3;8%Z-6/GPOBU9O]U A A#]AKT!+JM :AFC0C(=28Q:, M6# I#MO1M,W.L)%^($Q@ Z$!)^'QAX[[F02H[BL#1U^(\I4D!):1 MT/\#_]LFNWSE]$Y@W=]0@LVJQP;]CYVS=OZF1[-'H=A@DHR748\SJ.:EI M@9#4ACS*:7A(SP!-XON$OT+IG]--V@EP3N;1E/7/WP^./ 9MX]^!3JB M.W=*' ']BQ+$AU8@1%'S;+3ZY!JA#*2UA(C =G'U/[+F*,Y\B2Y2 M]9U\0$:R_JI^M(1''9-X\U;7L?/]$3? 0H.2_ K$'LC9NI0+C+P^7M.@ M%AH.TPR''GD4A9$PCMC+:QVA(K6N]7]D(BROX4(S4 40D!*_U)!*)5C+S SB M#$P0A$N?XDLV8)K6!L;7U0X'(DRF$0=L6W+/ 0=Z4(X8(G30NFE)C)0 M89]#1!!Q!E2C.X:7\UG;MRI/^1\TILUH@X]:W.(^S20=O2/;:*[?A:0 MU+$HFO$/?,S5ZQZHQ,LW??:IPN5DTF_4W80C-3JJC]Z^$,SDK]$H!-!G. M=48_7_2=TAGPDK@Q/+!BE0LR+%MZ0_@VTF-7[@X-6;T74VNGDHM9.)X]F MK9ZN7#TH-VUF'5X9$,XVC$(2AJWI6!Z^[T6Z'5'5GWX2P9N?0/)!A*V@E MQ1; G*HR.,^WS,Y#$O@4J/BS%YJ!0H[UP.@X^S.(,( B8:DQS@-71I. MESUZ/X^-;@5@@AG$L39MT+, X2OG0[X#/O^=0/2Z,QCP)WDA^;A!\ MSYW@51[#\(YFS7W.F;'EH07 V'/62^N]ISJR+J9#X2SV;[O$(S!6()@)D M81C/.C=N#]%+;1F6S02_1%U0C085T)=#7R$7?!7.[=:,E*@5R AJ,0'9N M-[=237HARA(^#-@:\ %;,7**BU!!C7DAKDSA%1H.3L6P-5!EOWC4CK06I3, MQ!^.-LB'RG.=SK;TRAP?KX]\+YE:EYJ7AFQ-?.7):%T-E4V:1 13#K\[F MO$(ZMRI#DQ:E,BI(F;NL;#B16=D:75\3R(8,,$2!,P:X]-;@\@=,7I'D MRR6=/HI6S1+UEF C[,U,S,K3*]B16I9LG*F9G]F*630CFMXK8YW0S3W3^ M77BHN(499_6S=+OL9F[G(BL6%UOM+:*=66L%]A!!7M=+P%)MIBEN-8 M\74%)^O %(Q807KGR?Y%Y6K(V7K8V7K_6!2ED4^*[RL8 !O,9R*RRAME M.EZQ*.0!(4/TXIUN5=DHA0_=PY-S+%V]F18 EDD*T;UWLKLCLW*+'$AYT MI1((Q-04CNK8I ^K#BLD9H.+X:7(XJ/:3-*/M9?9F?($=W=/7-G!PC?W47? M2)07\@9D1$LO+K4TQR6X4,L[?8C(X#40HHLF-AH807^D@3FGPB/F^D( MN;=C$091B(R2EE3$:.3A#.ZCFOB2T0O,DV?0@^KR?WX00/*D3T]G6%DO8 MV)_2V4# B+N]*](R]0D_6UJK@31'OF]$:098*BH6LSSISSX4^]P0C2D#/G M'_W+(66LB.*+6RIG%;9:!WF(5C6\03@D2DE9D@\$G,2^^:-GK[T$G_4N M*LMV$]LL1HA:89L.Y --DV7YU3:CH*?!8B6OB/.WLE;P46*X350:Y6 M^_!4\.@XH=4%4ECQ\RAA=CLH!A$JMQ3*Y.72 )\RW36D[C9\_!3FB9#R M18#4]H]52:11RZ/'HWZ@C()6F#'MLT=RSP\-#[Z:^QU@;#Q)Q1] OMV M?UB#];!V.YE(/.,T1(^5M2N.1.L%5_%-M8V+6\G-$XDCJ' +U4@ !1 ME;+MX,;5SYR8@N*T M,P73-SRI?JYR:90D+JF?I4.!:0HUOI2DYKY/5 M#JK/-97;LF3-N9@,R9KX4[,AS75AB;SLNEE$;BZVJFK@N1PUG/33-:DC MSI47%*5I%0ZL(BUT(#)5)QG@E(X4DI^=JM.(\QJ%AAIN8IK2NEG*0 M M @/W _JRAM;WZ9IM=A0C%5B1BNZJM=VI+UGR-Y@, X.Q7G(-8C8-P4(A MK$U @:\?Z7%](*]' RO #KG5P,3+$TXF,H9++Q3@DYB-8=+@\L=MV'29 MQO_9VHZ5SUG(OS^?BOBR7UI G'63:_JOCBQW5QV4E]_7/G1J2#$2 M:Z =!F!0):LKAV2DCDGFIH.MI61Z02=BWH^\P@ _2OJR:P +V\)]= M%_YOL7]XYM'8-/332Q1\YF5K UV14B2[2$GBATD29I76WB0DAO(.4%IF12[ M51VM:Y9OJ=M^@9O%CP*V%;?'/ $+,!\]/N1(:B6H^NDFR,O8@FG*91/ MP]ZY@R61S6%QJ$R9U4Y*)'?Q*2O_:E5#Z[O?]NDXJVVK@P. ZX7:!F+ MH.$KWT=DKC-6'F%()1)1[YMWL'O)]QHI=LH\7-)W,*MB;8)$B=H6B:8 M1@FP++HB74J!-K=IUZSOZ!N2=KH^K$?(*/%# )X8R,#27IU*Q1YD M1/GKI2.46T-H94VH;UWX%7D_9ES#T7)[7%Y,%TN+ETO%SPP(H!W_?/3X7@ M] BKCI4P].JR D,.C@@#G6M[A_$H90EN -(M7Z/]VUN*.Q8\'BY9S)LT+P M2!;5!: \;[JVA:E[USXTN_OYJZ_^^;!_/CJ6$?6 +ZQ/N\ F]EC,A4C)C% M@O++'7IQ:-Q.149 \I)VE9'0$^3)QN9B\I(#\._*C$#Q07%T.'Q25IB1, MCQT4*42#1#[UISIO\1L+JCZ/8AZ=Z5M\_C%62@JRB\E6!%3G%X.WO4O MG;/AZ=LW?8D24!F[:1RJ.HTR=*D5C0I76+22EZ*S^.Z/N0VEC19@W;WM@ MW3V)-Y_TI.\SNRV.WO,[ASM6$[^P:MPXM/?4K:JK=SU-F7*?XBC\4 [* MT*YJ2#M,=A?.8XX:A_5+D*HX,=L--IY//;K;G$5A$J)HZ()3;_A!%2W%W. MBYK6\I4I93U_:8:+1$+6+%XEHBE5T[S?4T\M*6\-*6+7E O0B4E E496 M)'5(*MX#+[@(@HU*MT [%2FA]C3,'8]V=JTI-M/8]GR7C_%IN6=?BF;JJ) MWM T\2COI+HV-7#\;4G3W;\RQ(D*J]Z3-?JVO(%R#-/B1)VEM5D[/H39 M=.8(I!T4'*IA8 _0N!H=ZVQ;^W8D)I7+4[0OH*KS)/@.]R$W(.:U7=I?2 M8VU=5U]77MUNR9[__Z]O@S\10MP;GT%;C888ZGO*Y]#WLS93#).O]?7@I M3QC6L;5\1=*#46K\0+3(1R2KO,.;%2I_?W=K 46F[3B.Z52(-WH$?DK!]5 MJM EJ:G ^CV2B.A:;9(XL;I3TE[*:F8 ]P2=P/W=,CHIYQS=6_]37%^W M6G+T;*\65_HJQ(W8_M-SXECIGA!?'K_5C $),/NQBN\;^X:Z9]IXIS[6\ MDIZ7%!@[%-;TC584:A7RT_IK)+A0**\Y?NO[01+[R[Z^_V8T8B1* MZ,B^]^F_$2:T)JLC8PW/K^?ZB-+M]B8Q%+-3=G=5(-O!ONW5+Y:7 :IWJ/ MT@([6%JZ\;,F(VFH5!N@+J5ZEOG+KB5E/TQL\.7-=^4FI!E9Q8UF)*X0/% M\K9\(5-8?G6+\7R4O7%:W*3:Z,:3._EG=IPJ*RFN%].0+BI04L:A8V45B M../3JBO$JJX_)2V$(BKY $D5UOLXNK,.1FOQI\+P2CL3=6UEPJ%S+IQ! M=X^H3'KMK/;N2C6W UX'DR!Y)%^*QBE5]#2*^'PQ] 7_/^G7VZ5/I
semi-HEADS UP: PnP resouce parser update (was: Re: cvs commit: src/sys/isa pnp.c pnpparse.c pnpvar.h isa_common.c isa_common.h isavar.h src/sys/i386/i386 bios.c)
I just committed update to the PnP resource parser for the PnP ISA and PnP BIOS devices. As this is a bug fix, there shouldn't be any nasty surprises. But, if you have PnP ISA cards and encounter any problems or suspicious behavior, please report. Thanks. Kazu yokota 2001/09/04 20:54:33 PDT Modified files: sys/isa pnp.c pnpparse.c pnpvar.h isa_common.c isa_common.h isavar.h sys/i386/i386bios.c Log: Rework the ISA PnP driver pnp and the PnP resource parser to fix the following bugs. - When constructing a resource configuration, respect the order in which resource descriptors are read, in order to establish the correct mapping between the descriptors and configuration registers. Plug and Play ISA Specification, Version 1.0a, Sec 4.6.1, May 5, 1994. Clarifications to the Plug and Play ISA Specification, Version 1.0a, Sec 6.2.1, Dec. 10, 1994. - Do not ignore null (empty) descriptors; they are valid descriptors acting as filler. Clarifications to the Plug and Play ISA Specification, Version 1.0a, Sec 6.2.1. - Correctly set up logical device configuration registers for null resources. Clarifications to the Plug and Play ISA Specification, Version 1.0a - Handle null resources properly in the resource allocator for the ISA bus. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
The loader now detects ACPI in your system, and loads the ACPI module if it is present. This has major ramifications for the device probe and attach phases of system initialisation. - Root PCI bridges are detected using ACPI. - PCI interrupt routing is now performed using ACPI. - The PnP BIOS is disabled and onboard peripherals are detected using ACPI, and attach to ACPI and not isa. - System-owned resources are detected and reserved by ACPI. Then, shouldn't we remove the PnP BIOS driver (pnpbios) from the kernel and make it a module, so that the boot loader will load either the ACPI module or the PnP BIOS module? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recent -current breaks console probing on dell notebook?
Until yesterday, I was running -CURRENT from around July 4th on my notebook, given that I was travelling and unwilling to break my means of giving presentations on my trip :-). Yesterday, I decided to upgrade, and built kernel/world. The userland stuff appears to work fine, but interestingly, my kernel seems not to probe the console, and instead, use the serial console. The boot loader does not have this problem, and sees the console fine. The symptoms are that as the kernel loads (spin spin) after the boot loader, it ceases spinning, the cursor changes to a block, This means that the video card is initialized Ok... and after a delay for hardware probes (tc), the login prompt comes up but syscons is working and providing /dev/ttyv%d... without the ability to type. Umm, the keyboard is not available... Unfortunately, I don't have a box with me I can use as a serial console, so I can't attempt to see what it did or didn't probe successfully, just that things got that far. When I get home tomorrow, I'll attempt to debug it, but was wondering if anyone else had experienced this, or could point me at any commits that might potentially impact this. Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services Can you login to your notebook via network? As the loader seems working, you can boot the machine with bootverbose set, and can get dmesg output if you are able to login via network. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
Ok, this is the 3rd revised patch for PnP. I think it works
fairely well.
I may not invest further time on this, now that ACPI is
taking over device configuration business... :-)
Kazu
I once wrote the following patch to deal with this problem by
probing ISA devices in the following order.
1. sensitive ISA devices described in device.hints
2. PnP BIOS ISA devices
3. other ISA devices described in device.hints
4. PnP ISA devices
This order is still slightly wrong. You need to do:
0. Disable ALL PnP devices which can be disabled.
1. PnP devices (of any kind) which cannot be disabled, or which only
have a single configuration. These devices which cannot be disabled
need a placeholder attached to them if a driver doesn't claim them,
or some other mechanism so that their resources are never used.
2. Sensitive hinted ISA devices.
3. Other ISA devices.
4. Other PnP devices.
begin 666 isapnp.diff3.gz
M'XL(*O(C3L VES87!NYD:69F,P]66USVD@2_HQ_1:]3ZQ)(D7@[3
M#0R2RTQ/D-M[5WI9+%8%0B9.$-[Y+[K=?][SH#6$[N52H,IA1=T_W3/?3
MSPPC;\X^=$-[1K^68Z_7OOB7/P^O]_'5SWI[!P5ZP+M3!P:OV;*?\,'\-:
M?C[]X2!@4R!][@P _0M?WP#RI-P[F[F(!U2U4 _H*3KUJ.[Z6Z89@U
MHU,S#3#:W9;1-9LE;JE2JR7;J!TL]MJ= WCX.U;J#;;=1TM5)KM4[UUF_?
M'D!I$3F.8L['3Y8L^'J_+Y !P[?B@6H)CN2?(M@$_BT#[4S_JV\#
MPS'82$/D1+.\(W]@C.RG;7]*\;.6 A?XV(+F%X31R4%1J^XM;25OY:N
MLP3']CP_ GPVQVAN5VP.?@!+^X![ZT\8T) X[O+=R[;6!'N*#Z7A]VIP?4
MKN[NP#MUOC!Q;^B$KH]G2)G]:*$=TD+RUGZ:[F ?.Z/'[:QOO*O99
MV]AA;Y']XA+EFEM$!?-1=@W$.+ER I]3Q:Z52AO_0)$+9BH _1$E]*?[
M3S)2J-@ZT0\(80L'+OX#TH.ACSR6C:T[@*34GRM6,([]U-?E].3DXH4A2@
M4'^:]4;COUGO1]?3F79$]JIOW+DEEC$L\_!+^URO2V+#=,[+O:4S$=+-Y2V
M 2VZ$6U69J=L;RZV:NT'3*KBKGBT:]D-.Q%/$^^TG$6'44!' $VW__:V\V
MN[8N)P/\]FX\+,/1$=?'UTL4I[/;-1/:SV]%O#3ZZS@N%DI\N2Y;.NW# J
M7D0*CP0Q4]P[SXKS4ZA3 JUZHQ-PC'P0IW/9DY5C[?JV,Q+PH25,YP#V0
M222O)ELEVEM()C!@,X;U*SY!%E'U82J%T54195)D!NUOG]:[3WUD-P
M\!T[PDQ(JB[RX9ZQ#?A8CH%24O6S/PU;$,J*WR\/I'/5J4IN/1=:]GUP/
M_W?-(Q'AVEP\KU[M6BB=S!1]4W.,\6L(JALEVA+/W/FY?))=*^ZP1E;1
M(UT4HBXE10)P_AQP[+#[EMAIL PROTECTED]+H\%_\,^4JT? 7_L'?ZT+7SN^L]BJD!)
M6H=F(*7P1093$50AX 4+!PC%FTBGJ9M-J+0:3;U^)IH(=_4YE(%,@0V
MB-+3J7DN$0Z-8XI(CY9V+;(IZBX-EK!DM%QT3BA$Z)@2^S%W2$SE26PU
M8/ 7M^CX 2;(QO?F6:37!!R!)39*8N*3V[=B6)!R61LX7KSG9GCG)%!D^+6
MZ,8#+ 0+S^.Q[(64U BI\QWK-3R\9R@/)9S '\=BO)2;O$E@I\I'[)R4_/
M\]!1! AYI2*WOR0P^ (00I#LJ-/@-+@/.D*M[E]#H$03JQGA$)0F'=2Q
M1!$J_'E:-V!KV_5H09^RLI=B5+^:8BAF\8W4I%[^CH4/!=3D/91$PX39VZ
M:2),G),M%(P\2P;R-$BN9())#53X6+%-._,/U^!-.](#'GV# UQ,SY\5
M _@*?I$H/,O7G\O?O$*(S-RU460$D;8A5-E-9AB+.KZ^%T#G;L2*W1.J[
M(5((SN4*.W,RA ?%UC6\)V ]_ ;O;I9-@-[QXO:1_?EP$!]PZ!!KZ% 5%9
MM)L=_10JG7J;FJBHBF-4V*XB7)!4'JPWR);G?#EN V;?BTIP;QPF'_6Z*9W
M;?4GE^]'/![Y'ZAG3AQ^7)(4Y4=4X/^9_#,=VR+P;*+ BLHY8,X: URW
MA8TZ77(73[W;P(/AY00S3L SC_RLSB-OGR61[\2+DS[8*U[W+X^[L$QC0R^,
M.A@18_F0L)#.X#CHUPK U$7Y;R#I^XV5,Y.VWI'QBVJ[JGBX5+?0)^
M*MU?DNTO8':RT+$L*-RSMDG[;!H8KZ'O]Y^0%C:SKNS;0?)5M)E2 4S
M @_ (2X'S?$5+:A22N^2EDB0,2YU/^N%+LAHKK 3'.1Y)?+DAF'F!'!M@Q
M=%,18-'ULY1SY=^YCKVBK*:2#'0(N+B^/K\;?LY(IMAJPQ8HYD6I]1.5B
M/BKS-=4$:2#@A1T5B1%/=/=A$0XR[.8O'$U\BBSM=.AT-UZC_4$*IITE=
M?CQ$B=23!W)Y*12*-6LKQ_'TW.U9E)-9D7K-8V7A=4%Y8+PY/.\
MMGP5Z-:]3D+'5E]F?((G83YIB2% 1D3CJO'Q_N#+Q^7R\=VYNZQ#1DG
MZXEW29:-2,5JU^D:]:S2[]7:)[!3/[CFT\)KMKMGIUL]XS;3:5#+X
M;AJB8%*EG*(YI016S@SGIBV^(XGY8@%'M;( PLEQ4YTG5ML6TD#ZY-M;
MZM9V[FQ]1RZA)Z#[X[+V7D[#NO)16P('MOF/(=[$25)MIN6N[AF'N[
MC81SE5?85R/%5+,DF;Q07FJ9ARY])SC[Z@FE+9Y,K$]5PG[TF7$[ 3P0J
MNS8I%1^=^=)\X7HYHXQ%37*)4TKN)LLIQ'%?;#D N7V5 $_RPW@QV=X
M,.N9C#KD#B8RG\Q(O/YM(9BQEFW:70-L\1MI+(_(QI?NM[]99(?1/;8 7?
M5JS5@(-?Q@SHBG$!N97 ^N,57P_[',6[SS5!T?'46_=Q:O4 ZO_VV@\
MP.,='LL0^;@!'1(P%'WO)3ITT1#KB 8H]3B QHV/-TK(Z!3M)6Q*R2(V :
M!I% 6\#,VWKR2S8),#M^ [RN?;_ -D?X Q('8OE0%\0*?:=;PMTNF:C
MVVB4N(54 L22*BKF]VZ^-'%K#(_M') LQ_;P97@XFUZ.!GAZ#J]'O7%F
M:#SY==3OC4FP6DJQX ]7FL#W**=,3T[J.AR9EB07U7UDKV9K28G-ZU3259)
MO-?O#Z?3R;46LLU5SI('_'4'95S(C'IT2%QNTA041X=8J%64G1N!\$J
M2!%HB)!=1!Z9#A[Q0C^T0]A%2#M1W6P+,W.!?UH;QS^-@-EM93DK6+W
MVB7#8M)HCZIS7^=NOZX0\ O-Q\Q.^F6\9AVD@SS=U9D(IN4R)CRC4:W
MU2IQSSEBZ5CV#.1(8C[GQ;E$;ZW1J]CUGM9TSN%CC403;2^T!MS^PUR?+
M-T5/-XZ8(/LT77!OB+7F'L1$9$+6W7 [HH?2',@?R/M$%XWZ9@J %OUPZO+
M*]Z(WTTF,]G'+RZ:JHM3Z+/VS@_*-ZJ=YSD_WN)J[6XFLNOLGWGGO:+
M-W/)4?**U\,/DYMA/.EI.=7(T4C UOX#(_9 VM6\MB@;12,3X:Q5V;P!Y:.
M$H_)32Y'/^!0F8[H2K%LVGQ46[O%=*S4=1/2W9]0:3XJ]'PW' R7$K[;C
M9:J^:XV1+SNBV_XU,C5^_4_K3:\MG2\Z5D2TGV3^-.C\PM85LSM+ LT
M[*3./,3NC@,MCJ\L5=:G49\S2F.I,7]-VGVZ+OJPU53='9:-4!E-_HPV9
M?4,QS#,R,SNB4=.\%.(45WW'2OJ9XB J.XD5,W8'^4DAH4NGNL_/61;
MD3,BTB%OH=A$C?YZ;(PM?@Q;]\?*UHK:?#F5+#5C1^U^O_'N^%6#EO0T3
M6B_UJP*_LD!*RU*W,USE2*ZVS!)=W ;BB\9#]]\,JD ?_D)Q9C*%B$W=(IF
M7;K+;7=9CXS.UR6ORVJ_KN+S]PJ.QTC4\_?Z(?6)3V.$$+S_?HRKZ^JZB
M']:-_9S5ST;PEX+B@GLE!/GM;?^$TJTNC3^OALGS#6HETY8JX*4H]261=
M7?!#*HQT'7+3\HX#,O?O=^JF01RB@)O)W4*@LVCIE+78CC'PDZ$VD)!G!
*_C]V:P\F!R4 (X#
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
I once wrote the following patch to deal with this problem by probing ISA devices in the following order. 1. sensitive ISA devices described in device.hints 2. PnP BIOS ISA devices 3. other ISA devices described in device.hints 4. PnP ISA devices This order is still slightly wrong. You need to do: 0. Disable ALL PnP devices which can be disabled. Ya, the patch disables PnP devices (if they can be disabled) before it starts probing devices. It enables each PnP device only when it is about to be probed... 1. PnP devices (of any kind) which cannot be disabled, or which only have a single configuration. These devices which cannot be disabled need a placeholder attached to them if a driver doesn't claim them, or some other mechanism so that their resources are never used. 2. Sensitive hinted ISA devices. 3. Other ISA devices. 4. Other PnP devices. Ok, revised patch is attached. Kazu begin 666 isapnp.diff2.gz M'XL()RZC#L VES87!NYD:69F,@]6%%SVD80?I9_Q2:=L (D# 86VXR MID :9HAQ@?BE[6B$.,R-A41/@L3327][=^].( %VF*039A#HM'N[M_OMMW?J MA5/VV0$ZX?+1916/%/WGS_YV38'L,!\R!:BS\:OM^)'_CI[B*MJI9^;Z M1+!$+;FX0,(_(EY%()=J9V?3/EL!N45E 7=YMTLE\NY :-F67;5NJS:%EA- MIV$Y=MV0LY1*I.2M2NP+IQZW;MDYL;*-;MGD%I7JS:38LN+DY@1,P9H*Q M@C][,.#.^Y^NMXW#)J)[A![@3D03!LMP5-TW6Q?)IS?PYS;\T@H,G MO##PHW#'U;2W!MIM*,(TCF7H(7]@1^X/$%_48Q!'*T%3S;B(DXH4K^*5 MSZ PB:)DS0DBED1AXREX$R*[RF!2[)%]?\V J6.@ W5-0[\*[U+L_P]X M@)(QBP04.+P!ZQHX_ )AJH6WI5(1_JYE8Z;@'R(PJG0'_POFL2($['R$QE M)0MG'/^@9*=[/Q[T1JV53)%_%53_R)8116,Z$K%*IJ 7*%;X:MWK]W]UW MO%H7#BE^IO^=15(8R+M4WB4\7+=B5$?8R@8/A=1'C!$(R!6E4=2XR M!E^V!Z_D#@1PGV6X?D3 TQNG$#'B''25[).C%,7\(W4VJ=9QTX-/ IH_E MA' F HSLUO)^?I9'9%B7@BS=0!Z8%.K,*+%TY=+TD\?ZZ=P!6#I;Q/(1S MA#*,*(VUJR:*I%/*6C (TVT)8R]\@E7H!4'DPF;9@=1/#(V!(BRE*JE!;. M3$0+6,6$6'R\J.CG,D_J-\;C=UW@VWU7Y?P/68( (3 AX^ID%3Z,%'Y;=H M3-J8( X(1?]8Q/K_63?*RDPP6:%3TR%=A-+:D (/63IR7+#Y_BE/D1RX1_ M\6OK*-'P%_DCKW3!+Y(+1JY,(;AEGQ-9KHC(-BMCVI0BD?Y(NO3%E!XQ1: MV5.(Y4:,(]8I$LGENVC4H-XMLW:1TN@1E29-'ZAL5=2:A.9#)XVA*/ M$'H+!G/TV$3T,.!)IK8W1J8^B:6@.,2D[#KU1,(=%)!?EXK;*9U($WS[3R MO-RNSO=NCM43;M*VJ5,- @W@!DW7J[ZW3I^N;K+W@85,%^M466UL$5[ M,-21W $G)[N^2TM?84U0*YDB_YWG,CB10I;ID:V2);!B$!G1*#R_KK;P M$@IVF6[ZV#PS5P=67:-M; !=: +6O@R.:6+P%0)2 ;T!F,MBTNK8!/6 [2 MLZEF,H1PSA'0BM-T?E)@,]Y*!6#*%IB%;1FE642'4GY0^8MCA!YL[DNC-R M;P?CNV%WU+T=[W4VO3:MSV-L.])FVM7V.B$U0GASKASJY3BC+Z)@Z^G^[ MI1!2B=\2[D7#7KE^8%EYMA)E876JL@P8!DX+18XE9S*L,Q$Q[5%#R M/1'W)6YO?O6T.VT;UL?N@ZYOIVCL$+(+Q/A)L6=TI8!T9-1!J=LYJ.0S9P M![\2(71O!P@/5#2W:N:=/BN75WSTDTNO8B?;CG-WQBYQ;,6T3?4$G!7U M;%_UMJ#+6[]O6S6S:4KAJV:G=5A^:A2*ESQW/TT= Z!EE'=%A=5 C! MWM[);_Z#3W[S9T]^S=S!KYEWN?-Z?3G%6UE7:U@UQZH[M:9!^P^^:Y M8Q]).?JV-=H$DCQVE0YSYQJ,OMY8QO':\!=?44?93P@H2)$+\QJ)5S62K MZT^PO#:ZNU?:SWB_PFP5^G0H5'KKB$^-G+PG'JZ-K (.K!9(9HJWM\!7 M6KI42/P'DG:^2(1\Q/6!,3T:LAAI%HU X*HK0J8W\+4G8BES,()O]A M;P^4L6!9-=R,+=Z-9!C1]UIS%Q4441Z\JI6XYEU)?HRGMH'.A=.H*C( M%P9X3F-!3C$HO$E ED)N*OP;#3';JCNV[[8[\U[MUW%4DA^I?/X[5J?C MMM_W^IW$D^NM).5$Y@R;[BM#7DB2,HG=N/_;X)95L2YUI)DLJ$_FHY2 M+E%HB8E%+UI!5D*GDCD6P*\\:-5J^V:4L_##FD+:?U]DY=\765OW=,[E MC(+VZ[6F!=.O:YWYN2V=\HU4GBRLILRX73NG%D$_ND5L6M1]][8S/8Z M9G9PU!WV6OW4'_P6Z_=ZI-@3O:'GRX0W1T,U[8V9V4'7M(B1RJ5;C3J1 MF-UH:!8C\5:[W1V-!L-C'M^#\^UVAGB;%'9$@N#(,7B0A:U_AP33MFW MQCLE5LJ)*4B9H+PU(=AR7$\GB)IDJI8/CJPB'B[_=)0NGF-LD2'A4$M* 5;MS?B:]-*0O'_ \7R/73% end To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
In message [EMAIL PROTECTED] David W. Chapman
Jr. writes:
: I'm running -current as of an hour ago. I've gotten this since I've
: been running 4.2-stable, any ideas on how I can find out what it
: belongs to?
:
: unknown: PNP0303 can't assign resources
: unknown: PNP0501 can't assign resources
: unknown: PNP0501 can't assign resources
: unknown: PNP0401 can't assign resources
: unknown: PNP0700 can't assign resources
: unknown: PNP0f13 can't assign resources
Don't worry about these.
Warner
Shouldn't we just suppress the message? It just confuses users.
The attached patch will print this message only when we boot
the kernel by 'boot -v'.
Kazu
Index: isa_common.c
===
RCS file: /src/CVS/src/sys/isa/isa_common.c,v
retrieving revision 1.23
diff -u -r1.23 isa_common.c
--- isa_common.c2001/08/10 07:50:14 1.23
+++ isa_common.c2001/08/26 10:24:03
@@ -416,10 +416,11 @@
/*
* Disable the device.
*/
- bus_print_child_header(device_get_parent(child), child);
- printf( can't assign resources\n);
- if (bootverbose)
- isa_print_child(device_get_parent(child), child);
+ if (bootverbose) {
+ bus_print_child_header(device_get_parent(child), child);
+ printf( can't assign resources\n);
+ isa_print_child(device_get_parent(child), child);
+ }
bzero(cfg, sizeof (*cfg));
if (idev-id_config_cb)
idev-id_config_cb(idev-id_config_arg, cfg, 0);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
In message [EMAIL PROTECTED] Kazutaka YOK OTA writes: : Shouldn't we just suppress the message? It just confuses users. : : The attached patch will print this message only when we boot : the kernel by 'boot -v'. They are there to remind certain folks that the ISA PnP code is broken slightly and to please fix :-). If we get closer to 5.0 RC1, then yes. Warner Um, we see these messages not only because our ISA PnP driver needs some update, but also because we create ISA device instances TWICE for each motherboard ISA devices, such as sio and atkbdc, due to /boot/device.hints. We need to have /boot/device.hints for those systems without PnP BIOS. On the system with the PnP BIOS, we shall have one ISA device instance (say, sio0) created by the isahint driver based on hints described in /boot/device.hints, and the pnpbios driver will create another instance (sio%d) for the very same device, based on information from the PnP BIOS. Then, we will see unknown: PNPXXX can't assing resources when the second device instance is probed. This happens even if the device driver understands PnP IDs. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
: Whether it's perfect or not, making the device.hints go away
: in the presents of PnP BIOS on the machine would seem to be
: able to address the issue of doubled entries... right?
Not entirely. There are ISA devices in devices.hints that aren't plug
and play and aren't in the PnP BIOS list. That's a worse problem than
the minor printf :-).
: Is there something I'm not seeing here from Kazutaka's posting,
: or am I being misled?
Yes. Yes. :-)
What we'd like to happen:
PnP BIOS devices
device.hints
PnP ISA devices
What we do now
device.hints
PnP BIOS devices
PnP ISA devices
Note, I tried making the simple changes to make this work, but it
failed in subtle ways that I didn't have time to trackdown...
Warner
I once wrote the following patch to deal with this problem by
probing ISA devices in the following order.
1. sensitive ISA devices described in device.hints
2. PnP BIOS ISA devices
3. other ISA devices described in device.hints
4. PnP ISA devices
I am not entirely happy with the patch, though.
Kazu
begin 666 isapnp.diff.gz
M'XL((-]B3L VES87!NYD:69F +U8ZW/:1A#_+/Z*;3+-@59#UXV;CJA
M0%JF!+M _*7M:3I@)N 1$_C:3_[V[=P))!+2SL0SD:SSOOWC\LPMG'
M#O#$M_?%\3K=1Q=!I77__^G,NE-8Y7K -6(@*K=S^5[^0IL0[U8\5P5+!
MV2./%B#PE? X N?2K5=/I^#N053T4S#1-\YGMFFO;CF5?68X-=KO3M#M.
M0Y.2=%T_3TVPEV7*=CMRIOWH#9:+M_1ITC/.F MI,%8-Y@L#WGFS
MP;N[VDT%\-BZJ)@:7,8?4QA(^('!OYJ!5$F9MH RZ$[ $DAC2I9_B@SU!
ML/+YFG[E0C$+EL1;071S+I+TLJ+3Z6S)(J,@,UCR52A8=(EJX+)Y]#]2.
MTTF'N*$U5:MA$\2N?5%^2HY/5V?!TIBX),UMU%=SOK_HAH#?Z;Q%2Q0C
MQB864.7PNP;X/ #1#L_-3UOR#-)I2YJ6*XEW1+_S/TF(EJ1BZ0RR8H6
M+CC^@I3]P?WL=CCM5B6+C#QZ2M[/NL/1;][;X60ZJ[XB:O-''F*HSE?)#49
M$ V_4AYMF731N@ _2?@B*@0]C'/!X46_TL\@8$DK*[\AL)=G;2\[LK4FJ
MLAV?E ]94%2P_2CT_#3U@^741,)E=6H!!3!6_I)VAR9B[*4D@\M,EI@_
M [8) YX6W-A;'@9$5K2[!!]IYMXDB07\,M2Y!O+GQ38A.YTDLJX7O4)GN
M4.?-7F6F(IMY.B_#6,9V.W*[NWO(($?ETF%3*:;'^,+19)6$0UY2U\+G
M?ZV@9]5CGE$$YI*P#Q2!!=PJ@CT$QE\V;@D5,\$!E4=DO4PD%YB]A;U]D
MWWUUE1T!';QZE44,C4N])/53EJFU^C=U!O?SNXF@^E@/%-^? 8GX_C4='
MSQ6? OMYU8Q=:)!G1QOQ1.L);'%.1,RTW)WD\%J7BB3A99NF7JUT*0VC3
M\'=DX/CYY@2RB/ XQ96Y'QC;0(R@%CNF'3G(EZ#*E:%9IL[:5T0*]
MW;0-')%RLD7*'[2M_0DS6S_EH?3N03#_ [F@:X/K04QZ WONQ.OWQMW
MWPTZ%-Y1G6+B-NDPDMK!PB0R,B$Z2@X9',?3JD S K8A@,+[%])/63\K
M:U:WV5F_O,2%3ZZ*\(6:XA,-!I!D%!1^@(N:IFT+UI;5;6E+V5X=%]
M:OF-]ZGER7VJ75JGVE R\L@VM:3]R+;LIN6VP'8[=J/CMC62V29RH@=UW(=
ML.M$[-1E#IMM2B$^VRJ!A0ZG2D]6BY97X@W@N*/FK;YQXTB9B##3CXAJM??D
MO,$#@F_/BY^2.\!J?##S#?1D%*[DN^QYB'6HG%XL;KB !]LU5JZ:GCDL
M%%9.(X/GREGD]R-7R)B.$1R_LVM2T:O7(FE,K=D;^Z(M$$M.($4*OME^
MKI2=!)/CEM#DN) ;6,2.LD6[1; ^SK3L/NV(XF91205)M6W8#[*M.XPHW
M 4CQ\-')^[1L!6:-BC$7(!-8P5?KMI#^8-.[0_]J#L;W@]4Y]T-VY_
M3[UNO^_U?AF.^M6-CW,7UR4IP) YQ-TIXJDCV?QT!PRP'1DZ 1DW'A$E#+
MP6)HW3+2281M)MCV68$LBQ\DKM 3^!ME'V4((#:^641ND[?SNSR[R
MO7F%_,N#K#4XEMNDG#KU3KVN20F%].\I,?L.$E,3:30[CQUC*N\#[60@Q0
M\G',84V?V,V: @RQBW'R![.4G'Y71OEQ5@ R6 \'1)$-)LZQHHM_. )
M$A8EG#I-+I_VQ/L.8TIR KE9G[D;WVF:*]O=:KLP2,P-RO_J2F?\9T
MXI?*XU?)ZC@A'N6$T$2?JGW 4Y;#:9MQ-\32 NW;_H9OPW]E(_@K4?
M^0LF^ZX=9P9NN,V,/RY/?#_'XP[M].AGVC#@=3(;=4EH=/OSL-=$:9
MG_9NW]VATWTLRV=G1O%0[0R[AHX2+.:#1IH3K.5330B[_9Z@^GT=E)-.WV
M5P9DQ@ VM=H!R2I)PW'.L_M^\8X6[!,6!OG2+32V2JI1B@K#6@M,N0XPC
M#5!B%6L_^IX/%7]Z12'6=94(_6AC%+.R?7G^K^]D+3*6]-]:N6)1\/
M/$Z^P8 ZT'R137*,ZKA0F:@;% '4O:MQ[VF)E6O=YI-3J03HX=0LG%:U
M+E%GV\X5=2KU(G2\I!#/-42E_-\BZ(:AO,AGLU]3''@TXT]*=2$O)VJB]_Q
M50JP-(DTL_D*[:1PU63:M'-#X6/+L[;D+S1S([+-'LX7R,B+1-!S,LK_';
MX\8GWT4[?WZ]X:Q1)M**I2FMK+#)R?Q(Y_\61TMZR?(J4Q/ZJ?^[_:=1
+J?P+D26VDX4 :
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: syscons VTY switch panic...
Do you by any chance use a VESA mode in text vtys? The vesa module in -CURRENT has problems now. If you try to set the VESA_800x600 mode in syscons, you will likely to hang your machine. This is a known problem, and is somewhat related to vm86 and context switching. I am afraid there is no immediate fix for it. Kazu I am getting this with regularity now. The one time I was available to see the panic, I forgot to go into the debugge r and do a traceback, but it had something to do with a mwrite, and had a line concerning [maybe a buffer is?]... I know this isn't much to go on, but that's what I have. I'll get more info w hen I feel like wasting ten or fifteen minutes for a double-reboot... [is it necessary to do the `shutdown -r now` to write a new entropy, or can we just keep going if it boots without the proper entropy?]... I have pretty much isolated this to VTY switching via syscons. Occasionally, it will leave the system speaker in a constant tone until it reboots. This is very noticable then X exits. jim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: syscons VTY switch panic...
Would you please remove the vesa driver from the kernel and do not try loading the vesa module either, and see if things work? Actually, I have tried to get the VESA splash thing going, but never can get a nything to display... I can try removing that... I believe it is still set up this way... What are the limitations on image size and color-depth for the boot splash thi ng? The image must have 256 colors. Its size must be 1024x768 or smaller. If you don't have the vesa support in the kernel, the maximum size is 320x200. Kazu Kazutaka YOKOTA wrote: Do you by any chance use a VESA mode in text vtys? The vesa module in -CURRENT has problems now. If you try to set the VESA_800x600 mode in syscons, you will likely to hang your machine. This is a known problem, and is somewhat related to vm86 and context switching. I am afraid there is no immediate fix for it. Kazu I am getting this with regularity now. The one time I was available to see the panic, I forgot to go into the debug ge r and do a traceback, but it had something to do with a mwrite, and had a line concerning [maybe a buffer is?]... I know this isn't much to go on, but that's what I have. I'll get more info w hen I feel like wasting ten or fifteen minutes for a double-reboot... [is it necessary to do the `shutdown -r now` to write a ne w entropy, or can we just keep going if it boots without the proper entropy?]... I have pretty much isolated this to VTY switching via syscons. Occasionally , it will leave the system speaker in a constant tone until it reboots. This is very noticable then X exits. jim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Disabling harmful keys (was: Re: PATCH: syscons.c sysctl for PC-Reboo Keys)
I posted the following message in the stable ML the other day, but got no response. So, I will post it here again. Please follow the thread PATCH: syscons.c sysctl for PC-Reboo Keys in the stable ML for background information on this subject. Kazu As we have seen so many people expressing so many opinions on this subject, I shall summarize the current status of disabling special keys, such as Ctl-Alt-Del, and propose a compromise. 1. Current status In addition to the Reboot key, we have some other harmful or dangerous keys. Keys considered harmful: Reboot, Panic, Debugger, Halt, Power Down Suspend and Stand-by keys may also be considered harmful? In our default keymaps in /usr/share/syscons/keymaps, we have Suspend, Reboot and Debugger keys in almost all keymaps. Halt, and Panic keys are defined in some keymaps. (I wonder how do we come to have this much differences in the keymaps. I thought they were at some point made to have common special key definitions...) Power Down and Stand-by keys are not defined in any. For controlling the behavior of those keys, we have the following. Kernel options: SC_DISABLE_REBOOT (for Reboot, Halt, Power Down keys) SC_DISABLE_DDBKEY (for Debugger key) Sysctl variable: machdep.enable_panic_key (for Panic key) We also have the following kernel option to disable loading of key maps. KBD_DISABLE_KEYMAP_LOAD 2. Proposition In order to not have too many kernel options and sysctl variables to control individual keys, I shall propose the following compromise. - - One kernel option to permanently disable all harmful keys. SC_DISABLE_HARMFUL_KEYS - - One sysctl variable to enable/disable individual harmful keys. machdep.disable_harmful_keys This is a bitmap in which you set a bit to disable corresponding harmful key. bit 0: Reboot bit 1: Halt bit 2: Power Down bit 3: Debugger bit 4: Panic The initial value is 0; all keys are enabled. This sysctl variable has no effect if SC_DISABLE_HARMFUL_KEYS is defined. I wouldn't like to make this sysctl variable tunable, as anyone at the boot loader prompt will be able to change it if it's tunable. If it remains a regular sysctl variable, only the root can modify it. 3. Notes Both the kernel option and the sysctl variable can be modifiable only by the root. We should remember that neither of the kernel option and the sysctl variable will be able to prevent the user from hitting the reset button on your system :-) (Oh, yes, you need to update /etc/ttys so that all ttys to be insecure, otherwise your inquisitive user can become root without the root password by hitting the reset switch and booting into the single-user mode... Yes, you know that :-) As for keymaps, KBD_DISALBE_KEYMAP_LOAD should be sufficient. I don't find it a good idea to add any other options or something else, as I think that it is the behavior of the key that matters, rather than its presence in the keymap. There was suggestion that we shall automatically disable all harmful keys if securelevel has been raised. I don't know if it is desirable. Someone may also argue that there should be a way to make these keys take effect only if the keys are hit by the root. I think it's difficult to implement this scheme. When a key is hit, we don't know, at that point, to which process the key stroke will be directed, and which process will eventually eat it... Comments? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Disabling harmful keys (was: Re: PATCH: syscons.c sysctl for PC-Reboo Keys)
I really like this, however I think that the sysctl section is a bit too complicated, even though it's somewhat gross it would make sense to have: machdep.enable_harmful_keys where the user can choose to assign 0xff to enable all, or leave it at zero to leave them all disabled. In fact if you're up to the work, you could make several sysctl_proc nodes for each 'harmful' key such that it updates the bitmask 'machdep.enable_harmful_keys' when set. kern.console.keymap.enable_reboot kern.console.keymap.enable_ddb My intention was that we shall not have too many sysctl variables and kernel options. In order to present friendly interface to this sysctl variable, we can have a variable in /etc/rc.conf, disable_harmful_keys=reboot halt powerdown panic (or enable_harmful_keys=debug) and a script in /etc/rc.syscons to process it. We can also add new options to kbdcontrol. kbdcontrol -E debug kbdcontrol -D reboot -D halt -D powerdown -D panic (or kbdcontrol -D reboot halt powerdown panic) etc. Oh, why put it under 'machdep'? It may be machine dependant which keys are used however the result is them same, hence the 'kern.console' or maybe even just a new sysctl subtree 'console'? I thought device driver related variables are under `machdep', aren't they? Also note that they key actions are for syscons, not for pcvt. Oh, well. Looking at `sysclt -a' now, we don't appear to be following strict rules... I like kern.console. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Anyway, I am now considering the following experiment. - We make the psm driver count the number of the out-of-sync errors. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to N (10 or 20?), the psm driver reset and reinitialize the mouse. The counter is reset to zero. Too complicated? Kazu Ok, here is an experimental patch. It tries to implement the above scheme. http://people.freebsd.org/~yokota/psm-out-of-sync.diff.gz It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds in this patch). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. Watch out for the followin messages: psmintr: delay too long; resetting byte count psmintr: out of sync (%04x != %04x) psmintr: discard a byte (%d) psmintr: re-enable the mouse psmintr: reset the mouse Please test if you are suffering from the out-of-sync errors! Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
o If you are going to reset, disable and drain the input queue before you do it; this will make the mouse lose buffered data, making a partial send with a disable in the middle not resume (e.g. it is no longer an issue for you). Don't worry. I was going to do this :-) o Because reinitialize can take a relatively _long_ time, split the reset and reset complete operations across a tsleep() (or msleep) so that the rest of the system doesn't stall (I think the number I saw was 2 seconds?!?). If you get an interrupt on the reset complete because it always sends data, then that's not a real issue: the tsleep becomes a guarantee, rather than a requirement. Yes, we need to be careful about this. As the AT keyboard data and the PS/2 mouse data must read from the same keyboard controller port on the motherboard, we want to remove the mouse data from the keyboard controller port as soon as it arrives, otherwise the keyboard data will be blocked. o You may want to implement a rate throttling mechanism; init will stop respawning a getty on a port, if it is exiting too rapidly, while inetd will rate limit the number of connection attempts a second, as well. I guess you probably don't want to disable it, ala init, but limiting the number of reinitialize/resets per interval would address the too expensive and reset causes additional resync errors cases. We are not running getty on the mouse port. So, we don't need to worry about this. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
If disable/enable sequence, which is lot simpler and takes considrably less time, can correct the sync problem, I think it will be better. It looks to me as if the mouse is automatically enabled by default after a reset? No, the mouse is disabled after reset. We need to explicitly enable it. This will be done during our re-initialization sequence. If this is true, then doing a disable then a reset will result in the next mouse packet coming in on a correct boundary. It makes the reset a tiny bit more complicated, but makes the results more deterministic. Yes. We can expect we get the packet boundary right after the reset command followed by the enable command. And that's why we shall reset the error counter to zero after reset/reinitialize. I don't know what to tell you, if the keyboard goes away during the reset process: it seems counter-intuitive, and it means you can't use keyboard shortcuts to get to a mouse control panel to fix the problem manually... 8-(. The keyboard won't be inaccessible during the mouse reset sequence. Its data won't be lost (in theory). But, you just feel the keyboard is not responding quickly... Anyway, I shall make a patch and we test it to see how it behaves... I think if that's unavoidable, a simple comment to that effect in the code would save you loads of grief later. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: psmresume() (was: Re: FreeBSD's aggressive keyboard probe/attach)
Kazutaka YOKOTA wrote: When the machine wakes up from the suspend mode by the APM (and ACPI?) BIOS, it is considered the BIOS's responsibility to restore the peripheral devices' state. And in fact most laptop machines are able to restore their internal pointing devices correctly. The only exceptions which I know of, to date, are some early models of Toshiba Librette and some models from Sony VAIO which has VersaPad. I have a VAIO PCG-XG29; basically, I've just been shrugging my shoulders, alt-consoling the thing, and then restarting moused to make things happy Send HUP to moused(8). I suspect that should just work. but if you want, the code I've been working on lately just passed off its acceptance testing today, so I could go through and put some comments in the code and send it off to you, and you can edit it and use it for a future commit. Thank you. I am interested. So... (1) Would this be useful, and (2) if so, do you prefer diffs against -current or -stable? (all of my work systems are -stable, but I could check out a -current work directory for this specifically). psm.c in -CURRENT and -STABLE differ only slightly. Diffs against either of the two will be fine. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
keyboard reset (was: Re: FreeBSD's aggressive keyboard probe/attach)
I am entering a tricky part now :-) --- Keyboard reset Because there are so many complicated issues here, I will start with describing something I know about what BIOS and FreeBSD keyboard driver do. (Beware, this is a long message.) 1. What BIOS does During AT BIOS POST, things happen as follows. Step 1. It sends the reset command to the keyboard. Step 2. It waits for the result code. During this reset operation the embedded controller inside the keyboard will flash LEDs(*1). Step 3. If it doesn't receive the result code, it assumes there is no keyboard. Depending on your BIOS (and BIOS setup), you will get the error message keyboard not present. Step 4. If it has received the result code, but it signifies an error, you will get an error message too. Step 5. If it has received the result code, and there was no error, the BIOS sends the send-ID command to the keyboard. Step 6. If the keyboard is 101/102 enhanced keyboard (or newer), it will respond with a 2 byte ID code(*2). The original AT 84 keyboard (and some old notebook computers too) doesn't support this command and will report error. Step 7. If the BIOS recognizes this ID code(*2), it will set the bit 4 in the keyboard status byte in the BIOS data area (0x496). Step 8. The BIOS then send the set-LED command. This is typically done to turn the NumLock LED on. Step 9. The BIOS optionally send set-repeat-rate command to set repeat delay and rate which you have specified in the BIOS setup menu. (The original IBM AT didn't have such menu, thus, didn't send this command.) Note *1: we can certainly see the LEDs flash. But, this is not caused by the set-LED command from the host computer. It is by the keyboard's internal routine. In addition, LED flash is not detectable from outside, in an electrical way by the host computer or KVM. There is no signal line in the keyboard cable associated with the LEDs! We should also remember there are some keyboard which doesn't have LEDs. Note *2: a typical ID code is 0x41ab for the US 101 keyboard. But other keyboards may send a different code. If the ID code is not one of those the BIOS knows about, the bit 4 at 0x496 won't be set. If the machine is in warm-boot sequence, the entire above keyboard probe may be skipped. It is also important to note that there is no BIOS service or status byte (or bit) in BIOS data area which tells us the presence or absence of the keyboard. As already pointed out in this mailing list by many people, we cannot rely on the bit 4 at the BIOS data area 0x496 for this purpose; this bit is set only when the keyboard identifies it self as one of enhanced type (12 function keys and separate cursor pad keys) AND the BIOS recognizes its ID code. 2. What FreeBSD atkbd driver does Step 1. the probe routine sends the echo command to the keyboard port. If a keyboard is present behind the keyboard port, it will respond. Step 2. If there was no response, the driver assumes that there is no keyboard and note as such. The driver will fail to install ONLY IF you set bit 0 (FAIL_IF_NO_KBD) in the flags for atkbd. Step 3. If the keyboard is present, then the attach routine first try to retrieve the ID code from the keyboard by issuing the send-ID command. (The returned ID code will be saved.) Step 4. Then the reset command is sent(*1), in order to put the keyboard in known state(*1). (If the keyboard returns error and the FAIL_IF_NO_KBD bit is set in the device flags, the atkbd will fail to install.) Step 5. The set-LED command is sent. It typically set the NumLock LED which was turned off reset in the step 4. Step 6. The set-repeat-rate command is sent. Note *1: if you really don't want to reset the keyboard, you may set the NO_RESET flags to skip it. Note *2: if you warm boot the machine after you used it under another OS, we need to reset the keyboard to put it in known state, in case the BIOS doesn't do so for us. It is true that there is not much room for the other OSes to configure the keyboard in arcane state/mode, but I have seen in some Linux mailing list that someone suggested that they should use the scan code set 3. The atkbd driver uses the scan code set 2 (this is the default after reset), or the set 1 for old ThinkPad keyboards (you need to set the ALT_SCANCODESET in the atkbd device flags for this). Note: all these FAIL_IF_NO_KBD, NO_RESET, and ALT_ACANCODESET flags are documented in the man page for atkbd(4). 3. Difference between the BIOS POST and atkbd Except that the atkbd driver uses the echo command first and that the order of the send-ID and reset commands is different, both do essentially
psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Ok, I am back. There are so many issues to be explained and discussed. I will tackle them one by one - Flags 0x8000 for psm and out-of-sync error As many people want to make it default, and my initial intent to make it an option didn't work out well as a hindsight, we had better make it the standard, default feature. However, I would point out that THERE ARE CASES WHERE IT DOESN'T CORRECT out-of-sync. The out-of-sync problem occurs in three situations. Case 1: there was communication error between the keyboard and the motherboard and data bytes from the mouse were somehow dropped. (I expect this is to be very rare these days.) Case 2: when you switch between more than two host computers connected to a KVM, there may be a loss of data bytes from the mouse to the FreeBSD box, if you try to switch computers during a packet is being sent from the mouse. This can be avoided if the KVM is intelligent enough to know the boundary of mouse data packets, but I suspect many KVMs on the market are not that smart; there are so many different mouse data format and packet length that I seriously doubt that KVMs know all of them and are able to ensure all data packets are sent to the host computers without splitting a data packet. Case 3: when you use a KVM, the mouse is initialized to one operating mode by a host computer, and then another computer tries to set up another operating mode of the mouse. Modern PS/2 mice have more than one operating mode to support wheels, additional buttons, and other extra features. These advanced modes most certainly use different packet data format and packet length than the original IBM PS/2 mouse (2 buttons, three-byte packet). If two computers try to put the mouse in different modes, they may be expecting different packet length, and will be confused when you switch between them. Even if the two computers are expecting the same packet length, you may witness wiered mouse pointer movement (instead of the out of sync message) because of the data format difference. If the KVM understands all the mouse operating modes from all venders and is able to set up the correct operaring mode for each computer when switching between them, we will have no problem. But, the KVMs we have today are not that capable for the same reason as I stated in the case 2 above. The flags 0x8000 can correct the first two situations and should get the mouse and the FreeBSD box back in sync. In case 3 above, this flag won't help; you will get a series of out of sync and re-enable the mouse messages. (I initially didn't like the idea that there would be a lot of traffic from the host computer to the mouse to disable/enable the mouse and we would still never get out of the error if we fell into this trap. That was another reason why I made the flag optional.) To get out of this error, we need to reset the mouse and reinitialize it the way we want. The trouble is that it is impossible for the psm driver to distinguish the above three situations. Reset and re-initialization is also effective for the case 1 and 2, but considered overkill and it will take a long time to do it. Another note on the out-of-sync error: we cannot guarantee that we can always detect it. Because there is no reliable way to find the start of the mouse data packet, the psm driver may operate without noticing the error and the mouse pointer goes berserk on your screen... Anyway, I am now considering the following experiment. - We make the psm driver count the number of the out-of-sync errors. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to N (10 or 20?), the psm driver reset and reinitialize the mouse. The counter is reset to zero. Too complicated? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
: Too complicated? I like this idea. It will allow mechanical KVM switches to work better than they do now (which is to say, not much at all). I also have one KVM switch that hits the out-of-sync problem when its power fails. Unfortunately, it has a horrible user interface: The power button and the switch console buttons are next to each other. I assume that initializing the mouse is somewhat expensive and something that you wish to avoid? Yes. Reset and re-initialization involves sending a series of commands to the mouse. It will take time. In addition, after we send the reset command to the mouse, we have to wait until it returns a status code. Loctech's technical document states that it will be between 300 and 500 msec. But, I know, from our users' reports in the past, that some mice take a lot longer time than this before sending the status. Moreover, if we have a KVM between the mouse and the FreeBSD box, there may be additional delay (I also had a report on such KVM). So, the current psm code will wait up to 2 seconds in the worst case. There have been some cases where I had to advise users to set longer wait time via the kernel compile option PSM_RESETDELAY and PSM_MAXWAIT (see the man page for psm(4)) for some mice and KVM. While we are carrying out the reset/initialization sequence, the mouse pointer will be frozen on the screen. The keyboard input may not respond in a timely fasion because the PS/2 mouse and the AT keyboard share the same I/O port. Then, I suspect our user may feel uneasy and think the entire FreeBSD is frozen... What do you think the average user will do in such situation? It is quite likely that s/he will wiggle the mouse (rather frantically?) to see if the mouse is dead, won't he? I am not sure our initialization sequence is robust enough to not be disturbed by this. If disable/enable sequence, which is lot simpler and takes considrably less time, can correct the sync problem, I think it will be better. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Does it make sense to have a timeout (or perhaps just timestamps) in the driver, so that after some period of inactivity, you know that the next byte from the moust is the first of a multi-byte message? louie I haven't thought about this. Yes, it may be possible. But, when the mouse is moving rather fast, we may get continues flow of packets and this technic may not work... I will invesitgate and experiment with your idea. Thanks. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Too complicated? It sounds fine to me. I was thinking that if you are truly concerned about the amount of time that the disable/enable calls take, the way to solve that is a combination of counter and timer. Increment a counter when you take the disable/enable path to prevent recursive calls. Set a timer the first time through the pair of functions to get the basic timing down. Then, limit the calls to the pair of functions so that you never call them closer than 10x the time to complete the pair. (maybe 100x the time is better? It depends on how long the function pair actually takes to complete. Is it variable depending on MB or other factors?) I think that timing the calls is important to limit the possibility of calling the functions too often in case of pathological circumstances. This seems to be the overriding concern anyway. I have only seen the problem once since I enabled that flag. We don't need to worry about such situation. As soon as we send the disable command to the mouse, it will stop sending data packet. So, we are not going to send another disable command before it completes, because we won't get another data byte which looks out-of-sync before the enable command. If we get out-of-sync data bytes after we send the enable command, there are two possible reasons: a) Disable/enable didn't work. The data packet is in wrong format. We need reset/re-initialization. b) The disable command was sent while the mouse was sending a data packet, and the mouse tried to send the remaining part of the packet after the enable command. This shouldn't happen for the well-behaved mouse. Logitech's technical document states that if the mouse is disabled in the middle of a data packet, the unsent part of the packet will be discarded, and the mouse will start sending a new packet after the next enable command. But, I would be rather cautious about this; there are so many wacky mice out there; they may not be as good as Logitech's :-) So, I would rather wait few more times after disable/enable and before reset/re-initialization. What happens if you set your KVM into cyclical mode? Does it force a mouse interrupt when it switches from machine to machine? It depends on the KVM's firmware, doesn't it? Both the mouse and the host computer do not know they are connected to a KVM. If the mouse is somehow forced by the KVM to send a data packet whenever you switch between machines, we will see the mouse interrupt. Otherwise I cannot imagine the mouse voluntarily sending data packets when you switch machines. You see, the root of the problem is here. The KVM tries to be transparent to the host computers and the mouse (and the keyboard) and there is no way for the host computer and mouse to know that it is connected to a KVM and to know exactly when the user switch between the machines. Kazu I can imagine a KVM misbehaving during the automatic rotate mode to cause a real cascade of problems. On the other hand, if you put it in the rotate mode, you probably aren't touching the mouse, so it shouldn't cause problems. How difficult is it to keep some sort of timer value in the code? If it costs too much to get a timer, then a counter is probably sufficient. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
psmresume() (was: Re: FreeBSD's aggressive keyboard probe/attach)
Ok, here is another topic for discussion. 0x4000 is PSM_CONFIG_INITAFTERSUSPEND Under what circumstances would you _not_ want to call the function reinitialize() on the unit at resume time, such that this flag is not default? To date, the flags PSM_CONFIG_HOOKRESUME and PSM_COFIG_INITAFTERSUSPEND have been absolutely required by only few machines, and are not necessary in most cases. They were provided as a fix/kludge for those few cases. When the machine wakes up from the suspend mode by the APM (and ACPI?) BIOS, it is considered the BIOS's responsibility to restore the peripheral devices' state. And in fact most laptop machines are able to restore their internal pointing devices correctly. The only exceptions which I know of, to date, are some early models of Toshiba Librette and some models from Sony VAIO which has VersaPad. Librette needed PSM_CONFIG_HOOKRESUME, but not PSM_CONFIG_INITAFTERSUSPEND. Somehow Librette doesn't seem to fully restore its mouse (actually it is a stick, which is like ThinkPad) after the suspend mode. By tickling the mouse port via few harmless I/O commands, the mouse will become operational quickly. (Even if we don't have PSM_CONFIG_HOOKRESUME for Librette, its mouse will eventually become operational after prolonged period since you resume the machine, though.) Some Sony VAIO models totally fail to restore VersaPad. So, it needs both flags to re-initialize the device. (This is documented in the man page for psm(4).) In general, the laptop computer's APM BIOS knows a lot about its built-in pointing device, thus, is able to put it back to the state before it went into sleep/suspend. In contrast, the desktop computer's APM BIOS knows almost nothing about special features of the hooked mouse. (The BIOS vender cannot know beforehand which mouse you will use with your motherboard :-) So, in theory, we need the above two flags if you sleep/suspend your desktop computers. But, it appears that many APM BIOSes on desktop machines just do not cut power to the mouse even in sleep/suspend mode, in order to let the user to wake up the machine by moving the mouse! If the power to the mouse has not been cut, we don't need to reinitialize the mouse. Even assuming it causes problems on some hardware (it appears to be _required_ to handle undocking from a docking station with an external mouse!), shouldn't this flag be inverted, Is it required for the internal mouse to be operational? Or, is it for the external mouse? How the docking station or the external mouse (whether it is directly connected to the laptop or via the docking station) are handled is vender-dependent, I think. Even if you need these flags for your laptop and docking station, it doesn't necessarily mean other vendors' laptop machines and docking stations need them too. I don't know a way, whether vender dependent or standard, for OS to know if there are actually two mice connected behind the PS/2 mouse port, and to direct commands to internal and external mice separately. In short, when we send any command to the mouse port, you don't know if it is sent the internal mouse only, or it is also forwarded to the external mouse in addition to the internal mouse, or it is sent to the external mouse only. This problem is not FreeBSD-specific. Other OSes, including Windows, have this problem too. If you buy a mouse with wheel and/or additional buttons, its manual often say that the wheel may not function if you use the mouse with laptop computers. This is particularly true when you hook a wheel mouse to a laptop whose pointing device has no wheel; our psm driver, or Windows mouse driver for this mouse, sends initialization command sequence to enable the wheel, the commands are interpreted by the internal mouse's firmware and are ignored, because it has no wheel. (I know Logitech at some point made a proposal to implement a software interface in which OS mouse drivers can talk to internal and external mouse selectively. I don't know if mouse and laptop vendors have reached any agreement upon this.) instead? I.e.: on by default, with the ability to force it off if it caused trouble? I made these flags optional for few cases they are absolutely needed. I didn't made them default for the other systems, because I followed the wisdom: When it's not broken, don't fix it :-) If we have evidence that they are needed for many more machines these days, it's worthwhile to make them default. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Death sentence to KLD screen savers? Comments?
Actually, running in user space adds two problems: 1) Performance degradation as a result of protection domain crossing which does not exist in the current implementation So, you seems to be effectively saying that any program running in the lower priority in the user-land is the source of performance degrataion :-) 2) Inability to disable the screen saver in, for example, a panic situation, where there is no opportunity to You may be thinking that we can put the video hardware back to the known state after ANY KLD screen saver has run. This is simply not true. It is simply that the KLD screen savers we currently have are well-behaved. Once you write a KLD screen saver which directly manipulates the video hardware in the way the console driver isn't aware of (and there is no mechanisms which will prevent you from doing this), it becomes impossible for the console driver to undo such operation. return to user space and have the screen put back into a known good state. This is analogous to the problem we have diagnosing kernel panics while X11 is running on the console: only the user space program can undo what it has done, and we can not run the user space program. The console driver cannot undo what the X server does, because the X server manipulates every bits of the video hardware to maximize its performance and the console has no control over this. IF the X server used olny console ioctls or touched generic VGA registers only, we could put the video card back to the known state when the kernel panics. It's true that you can write a user-land screen saver which touchs the video hardware (non-standard registers etc.) in a similar way to the X server. But, such screen savers won't be portable in the sense that it runs only on certain video cards, and breaks on the other. Therefore, you need to stick with console ioctls (and libvgl) to make it run on every hardware. # Of course, we don't have this problem with text-type screen savers # which may use escape sequences or ncurses. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Death sentence to KLD screen savers? Comments?
I propose to have user-land screen savers instead of KLD screen savers. [ ... performance degradation ... ] [ ... file access ... ] I don't see either of these as being compelling arguments in favor of a user space implementation; I guess this means you want to do file access in your screen saver(s). Both points/complaints/requests have been raised several times in our mailing lists in the past. (Sorry, I don't keep copies.) Some people don't like cputime eaten up by the screen saver in the kernel... Some peopel want to write interesting screen savers... Now if you could run Windows screen saver modules, you might have a good argument for change, above and beyond change for the sake of change. Personally I am not interested in fancy screen savers :-) But, just want to keep things tidy and keep the system running smoothly. By moving much of the screen saver support from the console driver to the user-land... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Death sentence to KLD screen savers? Comments?
You can stick the screen saver in a low priority kthread and achieve the same effect. As the screen saver accesses and uses syscons' internal structures and facilities, its operation must be carefully coordinated with syscons. Thus, putting the screen saver in a kthread will require major restructuring in various parts of syscons. It is much easier, at least to me, to just remove much of the KLD screen saver support from syscons to the user-land, than to utilize the kthread :-) You can use kldload or the loader with the -t 'foo' stuff to load configuratio n files, etc. that modules can get at. Um, I know the loader can load arbitrary files in the kernel space with its '-t' option (the splash screen actually uses it to load a bitmap). But, can kldload do similar thing? It donesn't look it can... Kazu Just pointing out that userland is not the only way of achieving your goals. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Death sentence to KLD screen savers? Comments?
This is to propose to abolish KLD screen saver modules. KLD screen savers have the following problems/deficiencies. - It is too easy to abuse the power of being run in the kernel mode. The screen saver is invoked periodically once the console becomes idle. It should not spend long time to draw something to the screen. But, we may be tempted to do a bit more elaborate drawing so that we get interesting effects. It's too easy to degrade the system performance by staying in the screen saver too long. - While it is easy to manipulate the video board in the KLD module (because we can go anywhere and access anything :-), there are limitations. If you want to perform file I/O (to obtain some bitmaps from files), or want to read some sort of configuration file, there is no straight forward way to do so. I propose to have user-land screen savers instead of KLD screen savers. - The user-land screen saver won't degrade system performance. We can run it at lower priority. Even if we write very complicated graphical screen saver, we have no fear of breaking the system. (Unless we write a buggy program which directly manipulates video card hardware...) - The user-land screen saver can access files if necessary. We shall provide the screen saver daemon and a set of screen saver programs. The screen saver daemon will run in the background and periodically checks if the console is idle. When it finds no activity in the console, it will launch a specified screen saver program. Screen saver programs are ordinaly user programs which act just like our current KLD screen savers, such as daemon_saver, log_saver, blank_saver, etc, which draw something interesting in the screen. The text-mode screen savers (deamon_saver, snake_saver, star_saver) are written by using ncurses. The graphics-mode screen savers (logo_saver, warp_saver, fire_saver, rain_saver) will be written with libvgl. Blank_saver, apm_saver, fade_saver and green_saver are replaced by programs which performs ioctl to the console to implement the same effect as the current KLD version. I will publish sample implementation once VESA support in -CURRENT stabilizes. Any comments? Kazu PS: the splash screen support has to remain in syscons as the splash screen is put up when the kernel starts up... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Death sentence to KLD screen savers? Comments?
We shall provide the screen saver daemon and a set of screen saver programs. The screen saver daemon will run in the background and periodically checks if the console is idle. When it finds no activity in the console, it will launch a specified screen saver program. No periodical checks please. It must wait on poll/select or kqevent or something like, event based, event provided by syscons. Because there already is the CONS_IDLE ioctl, I thought it's easy for the screen saver daemon to use this ioctl. But, if kqevent is preferred, we can do that. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
vm86 problem in -CURRENT
I am trying to track down a vm86 problem in -CURRENT. The trouble is that this is an intermittent problem and is not always reproducible. The last one I managed to capture was: == VESA: set_mode(): 24(18) - 259(103) VESA: about to set a VESA mode... Fatal trap 12: page fault while in vm86 mode cpuid = 1; lapic.id = 0100 fault virtual address = 0xc638b fault code = user read, page not present instruction pointer = 0xc000:0x638b stack pointer = 0x0:0xf9c frame pointer = 0x0:0xfdc code segment= base 0x2, limit 0x504eb, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, resume, vm86, IOPL = 0 current process = 444 (logo_saver) kernel: type 12 trap, code=0 Stopped at 0x638b: Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0x638b fault code = supervisor read, page not present instruction pointer = 0x8:0xc02c0ad0 stack pointer = 0x10:0xc91a8e44 frame pointer = 0x10:0xc91a8e48 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 444 (logo_saver) kernel: type 12 trap, code=0 db trace Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0x638b fault code = supervisor read, page not present instruction pointer = 0x8:0xc02c0ad0 stack pointer = 0x10:0xc91a8d68 frame pointer = 0x10:0xc91a8d6c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 444 (logo_saver) kernel: type 12 trap, code=0 db == This was generated when I ran a small test program which tried to switch to the VESA 800x600 256 color mode via syscons ioctl. This ioctl leads to vm86_intcall() to call the VESA video BIOS. (I had a report from a -CURRENT user that setting a VESA mode by `vidcontrol VESA_800x600' bombed his system too.) My test program and vidcontrol has no trouble in RELENG_4 (and RELENG_3). The trap was generated inside the VESA video BIOS ROM. The instruction in question was: repe stosw es(edi) where es and edi were set to 0xa000 and 0x0 respectively immediately before the above instruction. (The video BIOS was trying to clear the video ram.) As far as I understand, the entire 1M bytes of lower physical memory is supposed to be mapped when vm86_intcall() is run. Apparently 0xc, where the video BIOS ROM resides, is mapped OK. But, somehow 0xa, where the video ram is, went missing. As I wrote before, this test program sometimes runs fine, sometimes does not. Where in the kernel should I investigate further? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Please review and test: rc driver patch
Would somebody please review and test the attached patch for the rc
driver?
I don't have hardware to test this.
It will make the rc driver to use ttymalloc(), rather than to maintain
static array of struct tty.
Kazu
Index: rc.c
===
RCS file: /src/CVS/src/sys/i386/isa/rc.c,v
retrieving revision 1.63
diff -u -r1.63 rc.c
--- rc.c2001/05/15 23:22:22 1.63
+++ rc.c2001/07/06 01:23:05
@@ -142,10 +142,6 @@
static int rc_scheduled_event = 0;
-/* for pstat -t */
-static struct tty rc_tty[NRC * CD180_NCHAN];
-static const int nrc_tty = NRC * CD180_NCHAN;
-
/* Flags */
#define RC_DTR_OFF 0x0001 /* DTR wait, for close/open */
#define RC_ACTOUT 0x0002 /* Dial-out port active */
@@ -259,15 +255,24 @@
rc-rc_dtrwait = 3 * hz;
rc-rc_dcdwaits= 0;
rc-rc_hotchar = 0;
- tp = rc-rc_tp = rc_tty[chan + (dvp-id_unit * CD180_NCHAN)];
+ tp = rc-rc_tp = ttymalloc(rc-rc_tp);
ttychars(tp);
tp-t_lflag = tp-t_iflag = tp-t_oflag = 0;
tp-t_cflag = TTYDEF_CFLAG;
tp-t_ispeed = tp-t_ospeed = TTYDEF_SPEED;
+ if (!rc_started) {
+ make_dev(rc_cdevsw,
+rcb-rcb_unit*CD180_NCHAN + chan,
+UID_ROOT, GID_WHEEL, 0600, ttym%r,
+rcb-rcb_unit*CD180_NCHAN + chan);
+ make_dev(rc_cdevsw,
+rcb-rcb_unit*CD180_NCHAN + chan + 128,
+UID_ROOT, GID_WHEEL, 0660, cuam%r,
+rcb-rcb_unit*CD180_NCHAN + chan + 128);
+ }
}
rcb-rcb_probed = RC_ATTACHED;
if (!rc_started) {
- cdevsw_add(rc_cdevsw);
swi_add(tty_ithd, tty:rc, rcpoll, NULL, SWI_TTY, 0, rc_ih);
rc_wakeup((void *)NULL);
rc_started = 1;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
userconfig()
options USERCONFIG, options VISUAL_USERCONFIG, and options INTRO_USERCONFIG were removed from /sys/conf/options.i386 and options.pc98 on 12 June. Does this mean we are going to ditch userconfig()? (Or, did I miss announcement on this issue?) Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: TIOCSCTTY
It sounds like moused needs to be fixed to drop its control terminal. But the daemon(3) performs this function, and forked moused(8) runs without the controlling tty. Further investigation shows, that after running and killing this small program (from /etc/rc.local), I can't get a functional moused(8). It runs OK, and when with -f and -d shows mouse events, but does not show mouse cursor, etc. No error message logged by moused(8)? Very weired, indeed. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
tangled dev_t, struct tty and screen in syscons (was: Re: TIOCSCTTY)
JFYI, In i386, /dev/console is the same as /dev/consolectl, and all I/O operations for /dev/console, /dev/concolectl and /dev/ttyv0 take place in the screen #0, as shown below. In alpha /dev/console is /dev/ttyv0. Access to /dev/console is routed to /dev/consolectl's dev_t by cdevsw functions in kern/tty_cons.c. When syscons is not acting as the system/kernel console, /dev/console is not connected to /dev/console or /dev/ttyv0. But /dev/consolectl still exists. /dev/console /dev/consolectl/dev/ttyv0/dev/ttyvN | || | V || | dev_t|| | | VV V +---dev_tdev_t dev_t || | VV V struct tty struct ttystruct tty || | +---| | | | V V screen #0 screen #N As /dev/consolectl doesn't need to get input from or put output to the screen, it can exist without an associated screen. In that sense, it perhaps doesn't even need a struct tty. Maybe we also should give /dev/console a separate a screen than ttyv0. See the figure below. But, even in this configuration, we still have two copies of dev_t for /dev/console: the native dev_t (*1) and the underlaying dev_t (*2). As make_dev(9) requires us to supply the name to create a dev_t, dev_t (*2) will appear under /dev and will be accessible from the user land, thus, we still have the last close() problem, I guess. /dev/console /dev/consolectl/dev/ttyv0/dev/ttyvN || | | V| | | dev_t | | | | *1 | | | +---+| | | || | | VV V V dev_tdev_t dev_t dev_t | *2 | | | VV V V struct tty (struct tty) struct ttystruct tty | | | +------| | | | | ??? | | | | | V V V screen #X screen #0 screen #N Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: blockable sleep lock panic (and dumps still don't work)
This has something to do with the TIOCCONS ioctl. tputchar() is the output function for the TOTTY case, and the TOTTY flag is only set for kernel printfs if TIOCCONS has set constty to non-NULL. I'm not sure what uses TIOCCONS (I think it is intended for use with X, but it doesn't seem to be used on my systems). IIRC, xconsole uses this to capture console output. TIOCCONS is almost unimplementable (printing to a terminal is not reentrant enough to work in all contexts, and is supposed to be protected by spltty(), but kernel printfs must work in all contexts), so the correct fix may be to remove it. TIOCCONS is broken in all versions of FreeBSD. The brokenness is just more obvious now that there are more locks to trip over. The output function for the TOLOG case (i.e., msglogchar()) also seems to be broken in all versions of FreeBSD. It operates on the circular message buffer, but doesn't have any locking. I discussed this with jhb. We even had a test patch. Jhb told me that someone else was working on providing proper locking in kernel printf(). The output function for the TOCONS case (i.e., cnputc()) is also problematic. Only the serial console output routine even attempts to be reentrant, and (per-cpu) reentrancy is not enough under SMP. Syscons' output routine was easy to panic by mixing kernel printfs with user-mode output the last time I checked. Syscons' sccnputc() is not reentrant. I was trying to improbe this, but decided that I would wait until I see further development in tty locking and kernel printf() area by jhb. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Syscons mouse char range redefine proposal
On Thu, Apr 19, 2001 at 13:54:52 +0200, S ren Schmidt wrote: It seems Andrey A. Chernov wrote: Currently SC_MOUSE_CHAR occupes 0xd0-0xd4 range which produce conflict with several languages code tables. I plan to redefine it by default to 0x03-0x07 leaving possibility to redefine it to any range as currently present. This way minimizes arcane information needed for user to setup its language correctly. Any objections? Wont work, it needs to be in the (IIRC) 0xd0 - 0xe0 range for the HW to DTRT with the ninth bit on VGA HW. It works for years, just making small vertical black line sometimes appearse in the cursor. The has been beaten to death several times before, check the archives... We just add yet one conflicting language - Ukrainian. How many you want to change this decision? Breaking letters is more important than black line in the cursor. This has been discussed so many times in the past. We can configure the the base mouse char ether 1) by the kernel option SC_MOUSE_CHAR or 2) by `vidcontrol -M'. Maybe we should automatically add `-M 3' to flags for vidcontrol in rc.conf for those languages... Kazu -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mtx_destroy() and MTX_COLD
In order to declare a mutex which will be used before malloc(9) becomes available in the kernel, MUTEX_DECLARE() should be used, then it should be initialized by passing the MTX_COLD flag to mtx_init(), so that a statically allocated buffer will be used, instead of malloc()ing a buffer, right? Will it be safe to call mtx_destroy() for this mutex? /sys/kern/kern_mutex.c:mtx_destroy() seems to always try to free() the buffer... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Progress report: Multilingual sysinstall for -current
As we wait for libh development, I do not think we should exert efforts to try for another solution. This tends to allow for slack in further development of better products. A good example would be a proposal by Alfred Pernstein to slightly modify RELENG_4 SMP for the duration of SMPNG development. The proposal was not well accepted due to the reason I stated above. We really should concentrate on libh as a complete and _clean_ solution. Sure, libh is a better solution. But, don't you think it's still good to have something working until it will become available. In addition, the purpose of putting localized sysinstall in -CURRENT is rather dubious. -CURRENT/HEAD is a developers' branch, people who use this branch should be able to read English and the system error messages. If they cannot install the system with English sysinstall, I would have doubts on their programming and testing ability. People who run -CURRENT should be able to read and write English to understand the code comments, report bugs, and post to the lists in English. I think you are missing the point here. As you point out, the -current is for developers; it's for development and for testing. I don't think Tatsumi wants -current users to use I18N sysinstall to install -current, but, rather wants them to have a look at the code and test it. I would have no objections to L10N'ized sysinstall being maintained in the same way that PAO is maintained. The boot floppies and iso images can be put up somewhere for download, and maintained in RELENG_4. Why should it be in RELENG_4? If it's maintained in -current and regularly MFCed to RELENG_4, it is exposed to wide audience of -current developers and -stable users. That will attract more comments and bug reports, and will also minimize the delay between regular releases of FreeBSD and I18N/L10N sysinstall for them; the delay normally associated with L10N sysinstall (and PAO) after regular FreeBSD releases. Normally, I would welcome any I18N/L10N efforts in FreeBSD. However, the FreeBSD Project's official position paraphrased is "If you don't know what to do with -CURRENT, don't install it." See my comments above. Combined with the point that we should not divert efforts from libh, I hold the opinion that we should not import this. I don't think importing multilingual sysinstall will detract effort from libh. You see, even if it is maintained separately from the -current, it has its own maintainers and developers. I expect they are the same people who will maintain and develop I18N sysinstall when it is imported to the -current. They may or may not be libh developers at the same time. But, I don't think I18N sysinstall is suddenly needing a large army of developers and will steal them from the libh developer base. Finally, still many thanks and applause to Tatsumi and others for this work. The same from me to them too. Kazu | FYI: for 4.2-RELEASE, | http://people.freebsd.org/~hosokawa/boot-ja/4.2-RELEASE/release-20001205-1/ | contains source, and binaries for all supported languages. -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Andrea Campi [EMAIL PROTECTED] writes: Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Take a long hard look at vesa_set_mode() and vesa_set_origin() in sys/i386/isa/vesa.c. If the panic occurs while the console is still in text mode, the bug is in vesa_set_mode(); if it occurs after the console has switched to graphics mode, it's probably in vesa_set_origin(). The may be in the VESA BIOS on the video card :-) The vesa module calls the VESA BIOS to change video modes. The bug may not necessarily be in the BIOS "code", but the VESA video mode "table" to which the vesa module refers, when it sets up a new video mode, and calculates and initializes variables in the vesa module. I would like to see full dump of 'vidcontrol -i adapter', 'vidcontrol -i mode' and dmesg after the vesa module is loaded (you get very verbose output from the vesa module init code if you boot the kernel with 'boot -v'). You see, the VESA BIOS support on some video cards is not so complete. For example, we saw in the mailing list recently that the "VGA compatible" bit is somewhat turned off for VESA high resolution modes, didn't we? That possibly was a bug in that VESA BIOS. (OR, those mode ARE genuinely VGA-incompatible and we shouldn't use them the way the vesa modules accesses them...) Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Syscons flag to turn off random_harvest in scmouse?
To be fair, if the random module depends that badly on getting entropy from the mouse it isn't much good for many of our users who may not even have a mouse, keyboard or console. (Even when using X, personally I use the mouse as little as possible. On some of our servers the console is rarely used). I tend to agree. Moused is an optional component in FreeBSD, thus, we cannot expect that it is always running. It may be a good source of randomness, but the random module cannot and should not depend on it so heavily. Kazu I think the yarrow stuff is probably somewhat more roubust than requiring the mouse - as long as there is some source of entropy. What other sources does the random device currently use? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vga0, atkbdc0, fdc0 attaching to ISA bus?
On Sun, 6 Aug 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Warner Losh writes: : The reason you have a ISA to PCI bridge still is that the serial : ports, parallel ports, floppy, keyboard and mouse devices still live : on the ISA bus. They aren't full PCI nodes just yet in most hardware : designs (I've yet to see a floppy, keyboard or mouse on the pci bus, : but I'm sure people will tell me where I can find such beasts). I should have also added: Even though there are no ISA expansion slots on your machine, you still have an ISA bus living inside (unless it is a legacy free machine we keep hearing about, which I didn't think was on the market). The PC-99 standard (not to be confused with the Japanese PC-98 machines) states that you cannot have a ISA expansion slot, but a later clarification to the standard states clearly that you can still have ISA devices built into the mother board. In other words, No ISA slots doesn't necessarily mean that the machine doesn't have an ISA bus. Well, I understand that, my question is, why are true PCI devices like video controllers still shown as being on isa0 by the kernel? I wanted an explanation of that. That's what doesn't make sense to me. Perhaps there's a valid PC/AT hardware limitation reason for it. Otherwise it seems silly. =) Brandon D. Valentine If you read the PCI's specification, video cards are given special treatment due to necessary backward compatibility with ISA video cards. PCI video cards occupies ISA bus resources (ports and memory range) and these are handled in a special manner which is not quite PCI bus's way. If a video card uses only PCI bus resources and does not occupy any of legacy ISA bus resoruces, it is indeed silly that it is recognized to be on the ISA bus. But, the reality is that the PCI video card is a half-PCI and half-ISA device... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
Kazutaka YOKOTA wrote: Try the attached patch for /sys/isa/psm.c, and please report the result. Actually, I use the mse0 device, because I have an isa bus mouse. -- - Donn Robert, I still want you to try my patch, as you are using the PS/2 mouse. Donn, would you please run moused at higher priority, (for example, "nice -5 moused..." or "nice -10 moused...",) in order to see if this is caused by moused somewhat not running in a timely manner. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another minor mouse problem w/XFree86-4
I have a Logitech Trackball. I have tried it on the serial port and the PS/2 port and have the same problem in both places: 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Jul 27 06:00:20 EDT 2000 XFree86-3.3.6 and TkDesk-1.2 I right click on a directory or file in TkDesk, and a popup menu appears and *stays up* (thank goodness). Change to XFree86-4, and I need to hold the button down to keep the menu. Man I hate that. Which is supposed to be the correct behavior of TkDesk? The popup menu should stay up as in XFree86 3.3.6? I have no experience on TkDesk. Any ideas. I'm RTFM moused and psm, but I don't see any obviously related adjustments. Run `xev' and click the button in the xev window and see what messages are generated. If you still have XFree86 3.3.6 around. Do the same and compare the results in two versions of XFree86. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
Donn, would you please run moused at higher priority, (for example, "nice -5 moused..." or "nice -10 moused...",) in order to see if this Oh, I meant "nice --5 mouse..." and "nice --10 moused..." :-) Kazu is caused by moused somewhat not running in a timely manner. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
Oh, I meant "nice --5 mouse..." and "nice --10 moused..." :-) Tried this. It doesn't fix the problem. The mouse is still jumpy no matter what the nice level. I believe it's a problem with syscons as a whole. For example, whenever I switch to a VC and do kbdcontrol -r 240.34 to get a very fast keyboard repeat rate, the rate at which the characters repeat is very jumpy as well, much like the mouse. It was never like this before. So, I don't think the problem is specific to the syscons mouse drivers, just syscons itself. This started happening after some commits to syscons a couple of weeks back. I find quite hard to believe this was caused by recent syscons changes. Because these changes are about /dev/random thingie and color attribute handling in terminal emulator part of syscons. They have nothing to do with keyboard and mouse input. I am suspecting there may be something in tty interrupt handling in general in the kernel... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
Try the attached patch for /sys/isa/psm.c, and please report the
result.
Kazu
Robert Watson wrote:
I'm using a Micron P133 box with a PS/2 mouse. Up until this morning, I
was running 4.0-STABLE from a month or two back. I upgraded to
5.0-CURRENT, and since that time, my mouse has been responding slowly and
erratically, jumping as it moves, et al.
I'm using the default arguments to moused, with moused enabled in
/etc/rc.conf. I'm not sure what changed, but it would be nice if it
hadn't :-).
Yep. It's been that way in 5.0-current for about 2-3 weeks now. When
I use /dev/sysmouse in X, my mouse is really jumpy. It's so bad that
I don't use moused anymore in X. When I use my mouse normally, i.e.
without moused (/dev/mouse), in X, mouse movements are OK. Also,
cursor motion is jumpy as well. Must be the recent commits to
syscons.
--
- Donn
Index: psm.c
===
RCS file: /src/CVS/src/sys/isa/psm.c,v
retrieving revision 1.27
diff -u -r1.27 psm.c
--- psm.c 2000/07/22 04:08:12 1.27
+++ psm.c 2000/07/27 06:53:24
@@ -1827,9 +1827,11 @@
{
struct psm_softc *sc;
int unit;
+int s;
unit = (int)arg;
sc = devclass_get_softc(psm_devclass, unit);
+s = spltty();
if (sc-watchdog kbdc_lock(sc-kbdc, TRUE)) {
if (verbose = 4)
log(LOG_DEBUG, "psm%d: lost interrupt?\n", unit);
@@ -1837,6 +1839,7 @@
kbdc_lock(sc-kbdc, FALSE);
}
sc-watchdog = TRUE;
+splx(s);
sc-callout = timeout(psmtimeout, (void *)unit, hz);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Crashs with vidcontrol...
I already sent a mail about this problem a while ago, but it has not been solved yet. I mail again because I've made a mistake describing the problem. So, the problem was that when i type "vidcontrol VESA_800x600", it makes my box crash. I first thought that this was making my box reboot, but it is a crash because the system is waiting for me to press a key before rebooting. As it is a problem dealing with graphic modes, i unfortunately can't see anything that is surely written For those who want more details on my hardware and software configuration, please look to the "vidcontrol VESA_800x600 makes my box reboot" mails. You will found information on my hardware configuration and output of dmesg, vidcontrol -i adapter, vidcontrol -i mode and my kernel configuration file. If i can do anything to help and fix this problem, please let me know. I do intend to fix console problems in both -STABLE and -CURRENT. But, I am on business trip this weekend and will not be able to work on the problems before Sunday evening ;- Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons rebooting when going to 80x50
After taking the patches for config and booting my box reboots Which patch is it? Kazu because I have: #allscreens_flags="-m on 80x50" #saver="logo" #font8x8="cp437-8x8" #font8x14="cp437-8x14" #font8x16="cp437-8x16" enabled in my rc.conf, a kernel from ~2 days ago is fine with this. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing and rebooting with vidcontrol -m on
Okay, answering my own question for the sake of the archive, I believe it was an on combination of some of the options SC_something that vidcontrol -m on and my mouse and kernel didnt like. I was using some to save on kernel size and memory used but then decided to start using the computer on the console again so I just commented all those SC feature disabling out and all seems well. Thank you for reporting. Would you tell me which SC_XXX options you used to have in your kernel configuration file? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH] psmintr out of sync..
Ok, folks. This is a test patch for the psm driver. I would like you
to do some test for me.
This is NOT the fix for the infamous "psmintr out of sync" message,
but is a test patch to see how things are on your machines. The patch
is for both CURRENT and STABLE.
Please apply the patch to /sys/isa/psm.c (make backup copy first!),
and rebuild the kernel. I would like you to carry out two tests:
Test #1.
Make sure you remove the flags 0x100 from the psm driver and see how
your PS/2 mouse works.
You may still see "psmintr out of sync", but I would like to know if
the mouse pointer goes berserk when this message appears, or it seems
to operate properly despite the message.
Test #2.
Add the flags 0x100 (NOCHECKSYNC) to the psm driver and see what
happens.
Please report your results together with your motherboard model, mouse
model, FreeBSD version, mouse settings in /etc/rc.conf and XF86Config,
and /var/run/dmesg.boot (after you reboot the kernel by typing "boot
-v" at the boot loader prompt).
Thank you for your cooperation.
Kazu
Index: psm.c
===
RCS file: /src/CVS/src/sys/isa/psm.c,v
retrieving revision 1.26
diff -u -r1.26 psm.c
--- psm.c 2000/04/19 14:57:50 1.26
+++ psm.c 2000/06/09 01:19:59
@@ -1830,10 +1830,11 @@
unit = (int)arg;
sc = devclass_get_softc(psm_devclass, unit);
-if (sc-watchdog) {
+if (sc-watchdog kbdc_lock(sc-kbdc, TRUE)) {
if (verbose = 4)
log(LOG_DEBUG, "psm%d: lost interrupt?\n", unit);
psmintr(sc);
+ kbdc_lock(sc-kbdc, FALSE);
}
sc-watchdog = TRUE;
sc-callout = timeout(psmtimeout, (void *)unit, hz);
@@ -1880,18 +1881,6 @@
if ((sc-state PSM_OPEN) == 0)
continue;
-/*
-* Check sync bits. We check for overflow bits and the bit 3
-* for most mice. True, the code doesn't work if overflow
-* condition occurs. But we expect it rarely happens...
-*/
- if ((sc-inputbytes == 0)
-((c sc-mode.syncmask[0]) != sc-mode.syncmask[1])) {
-log(LOG_DEBUG, "psmintr: out of sync (%04x != %04x).\n",
- c sc-mode.syncmask[0], sc-mode.syncmask[1]);
-continue;
- }
-
sc-ipacket[sc-inputbytes++] = c;
if (sc-inputbytes sc-mode.packetsize)
continue;
@@ -1904,6 +1893,13 @@
c = sc-ipacket[0];
+ if ((c sc-mode.syncmask[0]) != sc-mode.syncmask[1]) {
+log(LOG_DEBUG, "psmintr: out of sync (%04x != %04x).\n",
+ c sc-mode.syncmask[0], sc-mode.syncmask[1]);
+ sc-inputbytes = 0;
+continue;
+ }
+
/*
* A kludge for Kensington device!
* The MSB of the horizontal count appears to be stored in
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: not making a splash
I've tried to get a splash screen with two different 320x200x256 bitmaps now, and all I get is a blank screen. Is there something else I'm missing? Would you type 'boot -v' at the boot loader prompt and send me /var/run/dmesg.boot? I also like to see the output from 'vidcontrol -i mode' and 'vidcontrol -i adapter'. Are you sure the bitmap file is in BMP format and is not larger than 320x200? Is it possible for me to have a look at the file? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
I've seen it for the last few weeks and can only think that something must be stomping on the psm driver now (or the driver is missing interrupts for reasons of its own). Anyone else seeing this? FWIW, with -current from 5/8, I don't have any of those in /var/log/messages, going back to 5/1. I have a logitech PS/2 mouse, and I don't use moused, since I couldn't get it to work with my wheel. In what way doesn't the wheel work? Would you provide the following information? 1. Which mouse model is it? 2. /var/run/dmesg.boot after starting "boot -v" at the loader prompt. 3. Run moused as follows to get debug log and send it to me. moused -d -f -p /dev/psm0 /tmp/moused.out Thank you. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
I see those messages, however I do not have any problems mousing afterwards. I'm using a switchview, which at least resets the mouse when I switch. Your Logitech 3-button mouse may be generic enough and is not affected much by power cut when you use the KVM. Which model is it? On Sun, May 21, 2000 at 08:41:57PM -0700, Mike Smith wrote: Um, if you don't see the above message but see erratic mouse behavior, then there may be a configuration problem (for moused or X), or a hardware problem. My configuration works fine, the mouse worked without messages until I installed 5.0-current. Do you get the "out-of-sync" messages when you don't use KVM? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
Yes. Just today, I was installing a Digital PC with 4.0-release. Before start using it, I upgraded to 4.0 Stable. Then I starded configuring X. FYI: FreeBSD 4.0-STABLE #0: Wed May 24 13:34:42 GMT 2000 CPU: Pentium II/Pentium II Xeon/Celeron (265.75-MHz 686-class CPU) psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 I have a HP-mouse (2 button) which is actually a logitec. FWIW, with -current from 5/8, I don't have any of those in /var/log/messages, going back to 5/1. I have a logitech PS/2 mouse, and I don't use moused, since I couldn't get it to work with my wheel. I tried with both moused and X. Both giving errors: psmintr: out of sync (0080 != ). psmintr: out of sync (00c0 != ). psmintr: out of sync (0040 != ). I tried several mousesystems, like 'ps/2', 'sysmouse', 'logitec'. They all go crappy. It's no use trying one protocol type after another like this... You should configure moused and X as follows. In /etc/rc.conf, set moused_enable="YES" moused_type="auto" moused_port="/dev/psm0" moused_flags="" In the "Pointer" section of /etc/XF86Config, you should have Protocol "SysMouse" # or "Auto" Device "/dev/sysmouse" Do you still see error messages after setting up the things as above? Kazu On my other machine, which is a Dell optiplex gx1, with FreeBSD 5.0-CURRENT #9: Tue May 2 13:17:27 CEST 2000 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 and a 3-button Digital mouse, I don't have the problem. But I really need to upgrade to the next current ;-)) I am curious if I have the same problems then on that machine. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
Try flags 0x04 on device psm. This undocumented option fixed my PS/2 IntelliMouse clone that has a wheel (which is also the center button). As you have not given details on your problem and mouse, I don't understand why this flag solved your problem... That flag simply sets the mouse's resolution to "high". Bug Kazu as to why this isn't documented in LINT. This flag IS documented in the man page for psm(4) :-) As Bruce says, LINT is not the place for documenting driver flags. They should be explained fully in the drivers' manual pages. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
May 19 00:50:45 zippy /kernel: psmintr: out of sync (00c0 != ). I've seen it for the last few weeks and can only think that something must be stomping on the psm driver now (or the driver is missing interrupts for reasons of its own). Anyone else seeing this? Do you, by any chance, use a KVM? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
May 19 00:50:45 zippy /kernel: psmintr: out of sync (00c0 != ). I've seen it for the last few weeks and can only think that something must be stomping on the psm driver now (or the driver is missing interrupts for reasons of its own). Anyone else seeing this? I haven't seen this message, but I _have_ been seeing an off-and-on problem where my PS/2 (Logitech Firstmouse) mouse will go insane. Just moving it causes clicks, wild pointer motion, all sorts of stuff. I usually have to log in from another box and kill and restart moused; that fixes things. Um, if you don't see the above message but see erratic mouse behavior, then there may be a configuration problem (for moused or X), or a hardware problem. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
I've seen it for the last few weeks and can only think that something must be stomping on the psm driver now (or the driver is missing interrupts for reasons of its own). Anyone else seeing this? Yes, recently on 4.0-stable, though provoked by unplugging and replugging in the mouse. It did not recover. This I thought sounded like a PR on the mouse being dead after a wakeup from sleep mode. Please, if you can avoid it, don't unplug and replug the mouse while the power is on. The PS/2 mouse interface is generally not capable of hot plugging/unplugging. As for sleep/wake-up problem on the laptop computers, you may be able to resolve the problem by adding the following kernel options. options PSM_HOOKRESUME options PSM_RESETAFTERSUSPEND Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
Um, if you don't see the above message but see erratic mouse behavior, then there may be a configuration problem (for moused or X), or a hardware problem. Well, the mouse is fairly new (less than 6 months) and otherwise works like a charm. I never saw this before 4.0, but that was also about the time I added the KVM. Oh, I see. You also use a KVM. The psm driver in FreeBSD versions before 4.0 is also screwed when a less-than-compatible KVM is used. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
FWIW, those are all the symptoms of this problem too. The mouse doesn't just jump, it goes nuts with simulated button events. :) This can really suck with certain email clients, too. My hardware: Sony VAIO PCG-F160 w/integrated trackpad: psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 Don't the following kernel options work for this machine? options PSM_HOOKRESUME options PSM_RESETAFTERSUSPEND Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: middle mouse button emulation broken in 4.0-STABLE?
This has been fixed in both -STABLE and -CURRENT a week ago. The left button is working, the timeout is just to long. Read moused manpage and set the timeout to 200ms as a workaround (this is the default according to the manpage, but not according to the code in 4.0-RELEASE). Sam 200 msec may be still too long. Maybe we had better change the default value to 100 msec or so... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [usb-bsd] USB To Do list
To Do list for the USB project: Let meknow if you would like to participate in any way, or you have done one of the items below! [...] - USB Keyboards - Keyboard in DDB debugger does not work. In what configuration does it not work? I can use my USB keyboard in DDB without problems on a dual PPro box (4.0-STABLE) with a UHCI controller (VIA 83c572) card and a Pentium box (3.4-STABLE) with Intel PIIX3 here... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP problem? (was: Re: [usb-bsd] USB To Do list)
To Do list for the USB project: [...] - USB base stack and general items. I am currently having trouble with Gigabyte GA-6BXD, dual Pentium III motherboard. If I boot a UP kernel (5.0-CURRENT), the PIIX4 USB controller works fine. If I boot a SMP kernel (the only difference from the UP kernel is support for SMP), the kernel seems unable to communicate with the USB device. When I plug a USB keyboard, I get uhci_timeout: ii=0xc0a601c0 uhci_timeout: ii=0xc0a601c0 uhci_timeout: ii=0xc0a601c0 usbd_new_device: addr=2, getting first desc failed uhub_explore: usb_new_device failed, error=TIMEOUT uhub0: device problem, disabling port 1 I vaguely remember someone also reported similar problems with the SMP kernel in the past Interesting thing is that I have another SMP box, and its USB works fine. The version is 4.0-STABLE. The USB controller is VIA 83c572. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP problem? (was: Re: [usb-bsd] USB To Do list)
What does it say before this info? In dmesg.boot (after `boot -v' at the loader prompt): uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xe000-0xe01f irq 15 at device 7.2 on pci0 uhci0: LegSup = 0x0010 uhci_run: setting run=0 uhci_run: done cmd=0x80 sts=0x20 uhci_run: setting run=1 uhci_run: done cmd=0x81 sts=0x0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered Both uhci and usb drivers are statically linked to the kernel. When I connected a USB keyboard, I got the messages in my previous mail below. Shared interrupt? No shared interrupt. Both IDE channels are disabled by BIOS, thus, irq 15 is free. After all, The USB drivers work if I run a UP kernel on the same machine. USB does work on SMP (or at least in some cases). I know. It works on my another SMP box running 4.0-STABLE ;- Kazu uhci_timeout: ii=0xc0a601c0 uhci_timeout: ii=0xc0a601c0 uhci_timeout: ii=0xc0a601c0 usbd_new_device: addr=2, getting first desc failed uhub_explore: usb_new_device failed, error=TIMEOUT uhub0: device problem, disabling port 1 I vaguely remember someone also reported similar problems with the SMP kernel in the past Interesting thing is that I have another SMP box, and its USB works fine. The version is 4.0-STABLE. The USB controller is VIA 83c572. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psm.c broken
linking kernel.debug psm.o: In function `psmprobe': /sys/compile/RJK191/../../isa/psm.c(.text+0x9fe): undefined reference to `atkbdc _open' *** Error code 1 I know psm.c was changed today, I'd suppose one reference here was missed in the process. Just figured I'd be the first to say so. Oops, sorry. I forgot to commit another update for atkbdc. I will fix it later today. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psm.c broken
After a cvsup today, building a kernel finishes with this: linking kernel.debug psm.o: In function `psmprobe': /sys/compile/RJK191/../../isa/psm.c(.text+0x9fe): undefined reference to `atkbdc _open' *** Error code 1 I know psm.c was changed today, I'd suppose one reference here was missed in the process. Just figured I'd be the first to say so. The following commit is related to the psm update and should have been committed together. Sorry. Kazu - yokota 2000/03/18 19:25:13 PST Modified files: sys/isa atkbd_isa.c atkbdc_isa.c sys/dev/kbd atkbd.c atkbdc.c atkbdcreg.h atkbdreg.h sys/i386/isa/pcvtpcvt_hdr.h Log: - Properly keep track of I/O port resources. - Use bus_space_read/write() to access the ports. Revision ChangesPath 1.8 +24 -19src/sys/isa/atkbd_isa.c 1.15 +54 -24src/sys/isa/atkbdc_isa.c 1.26 +13 -10src/sys/dev/kbd/atkbd.c 1.6 +100 -79 src/sys/dev/kbd/atkbdc.c 1.6 +16 -6 src/sys/dev/kbd/atkbdcreg.h 1.6 +3 -3 src/sys/dev/kbd/atkbdreg.h 1.37 +3 -1 src/sys/i386/isa/pcvt/pcvt_hdr.h - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-20000307-CURRENT kern.flp keyboard probe questions
Maybe there is a valid reason for this, but when I attempt to boot the 4.0 kern.flp without a keyboard attached (I share one keyboard between four systems, here), it displays keyboard: no and the BTX loader message, and ceases to display ANY output on the attached monitor (though it does continue to access the disk, I'm assuming, until the MFS root floppy is needed)? I assume this is because, without a keyboard, the loader assumes a serial console is attached. Yes. And this has been the behavior since FreeBSD 2.X. This is not the case in my situation. Isn't there a better way to identify a serial console? I don't understand. What do you expect the boot loader to do? And, if not, could the loader at least not display a message on the local monitor like "Switching output to serial console...", or better yet, "Switching output to serial console in 10 seconds.. press any key to abort"? Which key do you mean? The system has found no keyboard, you know :-) Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keyboard troubles
On my -current system, after rebooting, the keyboard was in a funny state (all 4 LEDs were turned on. My keyboard also has an internal click mechanism, which was no longer functional) I plugged the keyboard into another machine at that point, and it reset itself and worked fine on that machine. Plugging it back into the -current box, however, produced the same results as before. Fearing incompatibility, I dug out an old AT keyboard and plugged it in. No LEDs lit, and also no response from keypresses (including the obvious escape characters). The machine didn't hang... console message were still being displayed. I ended up rebooting the thing remotely, and after that, the keyboard functioned normally. If somebody can tell me what else to check, I can try and provide a few mroe details. It sounds like the keyboard interface of your motherboard has somewhat become flaky; it may even be broken. It is NOT recommended that you attach or detach the keyboard while the power is on. The keyboard interface of the PC motherboard is not designed for hot-plugging/unplugging. It is too easy to fry the keyboard interface and/or controller by doing so. Even if the keyboard interface survives hot-plugging, there is no assurance that the keyboard and the keyboard controller on the motherboard can communicate properly after hot-plugging; they are simply not designed to cope with such situation. I personally know a couple of people who broke their motherboard this way. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-20000307-CURRENT kern.flp keyboard probe questions
And, if not, could the loader at least not display a message on the local monitor like "Switching output to serial console...", or better yet, "Switching output to serial console in 10 seconds.. press any key to abort"? Which key do you mean? The system has found no keyboard, you know :-) Kazu Exactly... My suggestion resembles the common BIOS boot message from days of old: Keyboard not found. Press [F1] to continue. The PC BIOS prints "Press [F1] to continue" for ANY error detected during POST. I found it damm stupid. As I wrote in another posting, the keyboard interface on the PC motherboard is not designed for hot-plugging/unplugging. And I don't think the BIOS is expecting you to attach the keyboard without turning off the system in the above situation. You may say it works. But, I can say, with confidence, it is not generally the case with the average PC motherboard. I strongly object to the idea to put some logic or message to actively "encourage" users to hot-plug the keyboard. That will certainly lead to breakage of many motherboards. If the user hot-plug the keyboard, knowing involved risks, that's his problem; he is expected to know what he is doing and is prepared to accept the risks. It's indeed inconvenient that you cannot safely hot-plug the keyboard. And the world is heading for the USB standard... :-) Kazu The novice reads, laughs out loud, and wonders if the joke is really on them. After all, how COULD they press F1 if a keyboard does not exist? The expert checks his/her keyboard connection, (or plugs a keyboard in) and, indeed, hits F1 to continue. BIOS programmers have been doing it for about two decades. Why not the FreeBSD boot loader? :-) My idea is a similar one. Have the boot loader (with a reasonably configured timeout--we don't want to wait indefinitely) display a similar message (perhaps with copious beeping), giving the busy sysadmin a chance to switch keyboards, or at least notice that a keyboard was not detected. If I install FreeBSD on multiple systems, I might throw boot disks in a dozen machines so I don't have to wait for each one. I come around with my $370 keyboard later to start the actual installs over NFS. I call it 'pipelining' :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keyboard troubles
I don't make a habit of keyboard swapping, and I HAVE experienced some minor glitches before (such as weird scan codes being sent, or the state of caps lock changing). You have been lucky that you didn't broke the motherboard when swapping the keyboard. The fact that you only had minor problems does not mean the rest of the world should be Ok too. In any case, though, a keyboard reset or even just a few key presses would fix. In the last 10 years, I have NEVER had to reboot a system because they keyboard wasn't responding. Well, as I wrote before, I suspect that the keyboard interface of your motherboard is becoming flaky. This is a hardware problem, rather than software. It is not certainly the FreeBSD boot loader problem as it relies on the BIOS to detect the presense of the keyboard. Even if the keyboard interface survives hot-plugging, there is no assurance that the keyboard and the keyboard controller on the motherboard can communicate properly after hot-plugging; they are simply not designed to cope with such situation. I personally know a couple of people who broke their motherboard this way. Bummer for them.. Really, though, I would rather fry a $200 motherboard than my $500CDN keyboard (my fingers have developed expensive tastes). :-) None of my motherboard documentation warns agains swapping keyboards, either. That doens't mean the motherboard manufacturer recommend keyboard swapping :-) I certainly don't like the idea that we encourage users something which may break their motherboard. I will tell more. Many motherboard, if not all, has a small fuse around the keyboard connector. This fuse will burn if large current runs in the keyboard interface. This may happen when you hot-plug/unplug the keyboard. The trouble is that this fuse cannot be easily replaced on many motherboard. Some old motherboards have a socketed fuse, so it's not hard to replace it (but it is still a hassle for non-engineering type folks). Many recent motherboard has the fuse SOLDERED on the motherboard, and the fuse itself is a small chip. This makes it hard for us to identify the fuse and repair it when it goes off. It is certainly unreasonable to assume any user can fix it himself. In any case, I never had problems swapping keyboards between prior FreeBSD releases, other UNIX platforms, Windows machines, DOS machines. Hell, even my old Nintendo never complained if you plugged in a different controller while it was powered on. :-) I was just wondering if something had been done to 4.0 that didn't handle this situation like previous releases. Nothing changed in the 4.0 boot loader. # Other UNIX boxes and the Nintendo game console are not relevant here. # They use different keyboard interface circuit. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-20000307-CURRENT kern.flp keyboard probe questions
It's indeed inconvenient that you cannot safely hot-plug the keyboard. And the world is heading for the USB standard... :-) This actually opens another entire can of worms; detecting a USB keyboard at the bootstrap level is _not_ easy. It looks like at least some systems aren't setting the 'extended keyboard' flag. 8( I wasn't talking about specific implementation which should be in FreeBSD. But, the general technological trend the world is following :-) Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keyboard troubles
Why not just get a decent monitor/keyboard switch? Belkin makes a nice 4-port in the $200 range that makes your motherboard think there's a keyboard attached even if you are not currently switched onto the system. I have something quite similar.. Still, seems like some individuals remain adamantly opposed to the idea of keyboard swapping, however careful one is. :-) For the record,... I never said that I was against using console switch products. (They are designed to be safe. If it causes the problem, we can categorically say that it is the manufacturer's fault.) I am against hot-plugging and swapping the keyboard. You may be careful and you know the risk. But, others may not. I don't like to spread the false impression that the PC keyboard interface is designed for hot-plugging/unplugging, and will repeat (or even shout :-) as many times as necessary, "It is not recommended to attach or detach the PC keyboard while the power is on". If you want to hot-plug the keyboard, do it at your own risk. But, please, please, please do not advice other users that it is a safe thing to do; it simply is not. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
AP #1 failed!
In the last few days, I occasionally see the following message when I boot the 4.0-CURRENT kernel. AP #1 (PHY# 1) failed! panic y/n [y]? This doesn't always happen. But, roughly once in a few reboots. My MB is Gigabyte GA-6BXD with two Celerons (400MHz). Do I have a hardware problem? How should I diagnose the problem? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CGA instead of VGA
On -current my VGA card is being used as a CGA card. It is correctly recognized as a VGA: vga-pci0: S3 Trio graphics accelerator mem 0xf800-0xfbff irq 11 at d evice 15.0 on pci0 The above message simply means that a PCI card classified as VGA is found. This does not necessarily means that the card can be used as VGA. vga0: Generic ISA VGA at port 0x3d0-0x3db iomem 0xb8000-0xb on isa0 but then used as a CGA: sc0: CGA 16 virtual consoles, flags=0x200 The BIOS setup menu usually has an entry to specify the type of the installed video card. If this item is set to CGA, the BIOS and the vga driver will initialize the card, even if it is a VGA, as the CGA card. Are you sure that this doesn't happen to be the case with your system? The problem is, that I can't set fonts: # vidcontrol /dev/ttyv0 -f 8x16 iso02-8x16 vidcontrol: can't load font: Device not configured If the card is recognized as CGA, you cannot load font or switch video modes. I vaguely remember seing a commit from Kazu that supposedly fixed this, although I still experience it with a -current machine as of a couple of days ago. That commit fixed the problem where the vga driver wrongly thought the card is CGA when the BIOS DOES initialize the card as VGA. If the BIOS initialize the card as CGA, the vga driver is still led to believe the card is CGA. (And I believe that is the reasonable behavior.) Kazu The motherboard is an Intel AN430TX, the graphics card is a S3 Trio 64V+ based card. Below is the full dmesg. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-CURRENT issues...
I have 2 issues with 4.0-CURRENT. The first is the plethora of "microuptime() went backwards..." errors that scroll on my console. The second is that I have DDB compiled into my kernel (and a USB keyboard) either on vga or serial console, if I trip DDB (control-shift-esc), I will either get the ddb prompt or the system will hard lock. Below is my dmesg and kernel config. Help is appreciated. Is there a reliable way to reproduce this? Do you have any error messages when this happens? Kazu [...] usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.03, addr 2, ic lass 3/1 ums0: 5 buttons and Z dir. ukbd0: Microsoft Natural Keyboard Elite, rev 1.00/1.04, addr 3, iclass 3/1 [...] vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x100 sio0 at port 0x3f8-0x3ff irq 4 flags 0x30 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A [...] device vga0at isa? # syscons is the default console driver, resembling an SCO console device sc0 at isa? flags 0x100 [...] device uhci# UHCI PCI-USB interface device ohci# OHCI PCI-USB interface device usb # USB Bus (required) device ugen# Generic device uhid# "Human Interface Devices" device ukbd# Keyboard device ulpt# Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 release candidate issues
rc.i386 configuring syscons: blank_time mousedmoused: mouse type mismatch (ps/2 != intellimouse), ps/2 is assumed If you read the notice in the mouse configuration screen, you should have understood that you should ALWAYS choose the type "Auto" for ANY mouse connected to the PS/2 mouse port, regardless of the brand and model of the mouse. The type "IntelliMouse" is for the SERIAL IntelliMouse. On my Fujitsu Lifebook 535Tx I also set 'moused_type="glidepoint"' along with the 'moused_port="/dev/psm0"' in /etc/rc.conf and receive the abovementioned message on every reboot, BUT with such settings I can 'tap' and receive button event where as without setting moused_type to glidepoint this 'tapping' not works. I can assure you that setting `moused_type' to "glidepoint" does not directly affect your pad device. The protocol type "glidepoint" is for the "serial" GlidePoint. PS/2 GlidePoint should be used with the "auto" (or "ps/2"). When moused finds that the user selected a protocol type which is incompatible with the mouse driver (psm or mse), it warns the user: moused: mouse type mismatch (XXX != YYY), XXX is assumed Where XXX is the basic, default protocol type of the mouse driver, and YYY is the protocol type supplied by the user. As you can infer from the the message, moused will ignore the type supplied by the user and use the driver's protocol instead. In you case `glidepoint' is utterly ignored, sorry :-) As for the `tap' feature, I assume the pad device on your notebook computer is reporting the `tapping' action as the button 4 click. If you want `tap' would be the button 1 click, you set moused_flags="-m 1=4" in your /etc/rc.conf. You may think this is arcane, but this arrangement gives us more flexibility; believe it or not, there are people who don't like the `tap' feature and don't want the button 1 click for `tap'. Now, you want to ask me a question, don't you? "But `tapping' is reported as the button 1 down on my machine without the -m option!" This is because moused finds that a wrong protocol type is supplied, and tries to use the "basic, default" protocol type the mouse driver is suggesting. For the PS/2 mouse driver psm, it is the "ps/2" protocol type which has no provision of accommodating the button 4 (tap) status. The psm driver "automatically" maps the button 4 click to the button 1 click when the "ps/2" protocol is being used. This mapping is done in the psm driver and not in moused. If no protocol type is supplied or the "auto" is specified to moused, moused will try to use more advanced protocol type than the mouse driver's basic default protocol. In such protocol, the button 4 status can be reported and the psm driver won't need to map the button 4 (tap) to the button 1. That's why you thought `tapping' didn't work when you had moused_type="auto" in your rc.conf. The recommended settings for you notebook computer is moused_type="auto" moused_flags="-m 1=4" You may use the "ps/2" protocol type in order to avoid setting mouse_flags. moused_type="ps/2" moused_flags="" (But, I wouldn't recommend this.) Kazu Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
