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: at p
>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 all
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 /
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 di
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
Please send ENTIRE output, if possilbe, rather than partial exerpt.
Also send "boot -v" output when the acpi module is not loaded.
Please also tell which motherboard you have.
It would be also useful to dump ACPI data blocks using acpidump(8).
>Here's some more info on my ps/2 mouse problems I ma
>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
bdc0: 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 s
>On Fri, Sep 21, 2001 at 03:00:08PM -0400, Viren R.Shah wrote:
>> atkbdc0: port 0x64,0x60 irq 1 on acpi0
>> ^
>
>Same here (Asus CUBX mobo):
>
>atkbdc0: at port 0x60,0x64 on isa0
Would you do the following and send me dmesg's output in each
>> 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 loa
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).
/*
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
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
>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 li
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
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?) inter
>>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 i
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: sen
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 parameter
>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 redefin
>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
>> 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 fu
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 i
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
==
"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 PROT
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: abou
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 dr
>> 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
>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
restr
>> 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 "
>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-lan
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
>: 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
>
>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 m
> > 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
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_INITAFT
>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 d
>> 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
enab
>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 int
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 happe
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
>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 fa
>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
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 immed
t 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:
>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: can't assign resources
>: unknown: can't assign resources
>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
>: 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
>> 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 sligh
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
>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 rarel
>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
>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 deve
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?
Wi
>It seems that if the splash screen image is not cleared (ie: press any
>key) before xdm starts up then once logged in the user is unable to
>switch to a vitual terminal (ie: ctrl-alt-f1 etc), and it just beeps
>when those keys are pressed.
>Solution? Putting the command kldunload splash_bmp befor
>Did a make world and then
>rm -rf ../../compile/TITAN
>config TITAN
>cd ../../compile/TITAN
>make depend all
>
>See errors below ...
>
>Am I missing something ?
See
http://www.freebsd.org/~yokota/sc_update.txt
and update your kernel config file.
Kazu
To Unsubscribe: send mail to majo
>> >It seems that if the splash screen image is not cleared (ie: press any
>> >key) before xdm starts up then once logged in the user is unable to
>> >switch to a vitual terminal (ie: ctrl-alt-f1 etc), and it just beeps
>> >when those keys are pressed.
>> >Solution? Putting the command kldunload s
>I'm using -current as of 1998-01-14 with the new syscons (with
>separated keyboard driver) and XFree86 3.3.3.1 (XF86_SVGA on a
>Matrox G200). The keyboard and mouse are plain PS/2 models,
>they work fine under syscons (i.e. not using XFree).
[...]
>XFree used to allocate the next free virtual ter
I have committed another syscons update.
Because one new file has been added to the source tree, and one file
has changed location, I have to ask you to run config() before you
compile the kernel next time, and "make clean depend all" in your
kernel compile directory. No need to update the kernel
I recently looked at keymaps in /usr/share/syscons/keymaps and found
many minor errors. In addition to that, there is so much
inconsistency among existing keymaps. True that national keyboards have
different layout of regular keys (alphanumeric keys and symbol keys).
But, it is absurd that functi
>> 104 Pause Start screen saver (saver).
>:
>> The above assignments for the keycodes 1, 57, 70, 84 and 92 are
>> compatible with many, if not all, existing keymaps.
>
>So far so good!
>
>> The assignments for 104 and 108 are new.
>
>104 (Pause?) does the "Backscroll" on
>> my vote: A version of the standard keymap with CapsLock and LeftCtl functio
>ns
>> swapped so the control key is under my left finger like God intended!
>
>My vote is both of the above. I've never found a use for CapsLock, but
>LeftCtl is important enough that I wouldn't mind it duplicated.
What if we declare death to LKM screen savers and remove them from
the source tree? After all KLD screen savers are working well.
Kazu
>As of a few minutes ago, I committed some changes that:
>1: make the LKM code use the common VFS and syscall registration routines
>2: make an 'options LKM' opt
>I recently looked at keymaps in /usr/share/syscons/keymaps and found
>many minor errors. In addition to that, there is so much
>inconsistency among existing keymaps. True that national keyboards have
>different layout of regular keys (alphanumeric keys and symbol keys).
>But, it is absurd that
In order to reflect the recent changes regarding syscons, keyboard and
video drivers, I wrote the following new man pages and update for a
couple of existing ones. They are rudimentary, but better than
nothing.
http://www.freebsd.org/~yokota/man4update.tar.gz
New pages:
atkbd.4
I wrote a draft man page for syscons(4). (It's not as comprehensive
as it should be, though.)
http://www.freebsd.org/~yokota/syscons.4
Please review the draft and give me some comments. We shall add it to
RELENG_3 before 3.1 comes out, if possible.
Kazu
To Unsubscribe: send mail to ma
>Hi, if I load the vesa kld module from loader.rc, in order to
>use a high-res splash screen, when X starts the screen is very dim.
>Usually I start xdm from ttys, but its the same if I use startx.
>The cursor looks normal, its really bright against the dim screen.
>Its fine if I don't load vesa a
>===> usr.sbin/kbdcontrol
>cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/kbdcontr
>ol/kbdcontrol.c
>gzip -cn /usr/src/usr.sbin/kbdcontrol/kbdcontrol.1 > kbdcontrol.1.gz
>lex -t /usr/src/usr.sbin/kbdcontrol/lex.l > lex.c
>cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c
> ls -ald /dev/kb*
>crw--- 1 root wheel 112, 0 Mar 23 23:29 /dev/kbd0
>crw--- 1 root wheel 112, 1 Mar 23 23:29 /dev/kbd1
>
>muadib# kbdcontrol -k /dev/kbd1
>kbd1
>ukbd0, type:generic (3)
>kbdcontrol: unable to set keyboard: Inappropriate ioctl for device
>
>Any clues
>Cool, I managed to get my usb board up and running. the problem was
>kbdcontrol or me 8) I try to switch keyboards "at" -> "usb" however I needed
>an at keboard to make the switch so I attached an at keyboard to my system
>and issue the silly command:
>kbdcontrol -k /dev/kbd1
>
>The last time I
>Yes, I have ""KBD_INSTALL_CDEV" in my kernel config file.
>
>Actually, my problem was that the default keyboard is the AT keyboard
>what I need is to have my default keyboard be the USB keyboard.
You want to use the USB keyboard as the only keyboard in the system,
and want to get rid of the AT k
>Cool !
>
> kbdcontrol -k /dev/kbd1 < /dev/ttyv0
>
>Appears to work 8)
>
>
>Now I have to figure out how to add support for my mouse. Got no clue what
>protocol does it use . All I know is that is Macally USB mouse is going to be
>fun hunting for the mouse protocol 8)
No, you don't need to
>cvsup 7pm CET.
>
>I'm not able to switch to 132x60 anymore. Last cvsup was around feb 1999.
Please check the revision of /sys/i386/isa/vesa.c. Is it 1.18 or
1.19?
I committed fix for a palette loading problem in vesa.c at 7am PST.
This is the latest revision (1.19). The modification has nothi
>While playing over here with the USB stuff, I rebooted the system and
>disconnected the USB keyboard waited till the system was fully up
>and re-connected the USB keyboard which resulted in the system
>not attaching the USB keyboard.
You need to be running usbd.
In any case, we need some more
>running FreeBSD 4.0-CURRENT i have encountered the following
>problems:
>
>1. something is wrong with psm0 driver. my Genius NewScroll PS/2 mouse works
Is this a different product than "NetScroll" or "NetMouse" from Genius?
>well, bu
nts.
I am attaching the README file from the patch.
Kazu
--
Latest syscons update
17 May 1999
Kazutaka YOKOTA, yok...@freebsd.org
1. Introduction
This is a snapshot of work-in-progress. I decided to release this
because I am
--
Latest syscons update
28 May 1999
Kazutaka YOKOTA, yok...@freebsd.org
1. Introduction
This is a snapshot of work-in-progress. I decided to release this
because I am very much behind intended schedule and think it won't
benefit us much if I will defer submitting this for public testing
>My -CURRENT box is having problems with the mouse pointer freezing. Killing
>moused and restarting it seems to solve the problem, until it happens again,
>of course. It seems to happen after about 8 or nine hours of use. This
>hadn't been a problem with the previous -CURRENT, which was a month
>Whenever I try to load the splash screen (300x200 256 colors) the modules
>seem to load right, however, when the kernel boots, it gives me an error
>about mod_register_init or something of that nature, I was just testing
>the config... I tried these commands at the boot loader.
>
>load kernel
>lo
The svr4 module is broken after the following change to svr4_machdep.c
rev 1.5.
--
revision 1.5
date: 1999/06/01 18:20:23; author: jlemon; state: Exp; lines: +0 -4
Unifdef VM86.
Reviewed by:silence on on -current
-
101 - 180 of 180 matches
Mail list logo
