RE: Problems with 4.0 keyboard input!

1999-08-14 Thread Ron Klinkien




Hello Brian,

I get the bktr device usurping its own cdevsw[] as well - I was
told it was "most likely" benign, so I've been waiting for
others' comments.

I have looked in the source code, but what does usurping means? 
My English is not that good ;)

The messages comes from /usr/src/sys/kern/kern_conf.c


I also get the keyboard problem periodically, and I've been
trying to isolate just what I do to cause it. Generally, if I
reboot and don't hit a key before FreeBSD boots, it never
happens. If I tap enter to abort the countdown, the keyboard
scrambles perhaps one time in five.

Thats what I have been doing the last five reboots, I pressed Return
to let it boot faster.
I shall try without.


Resetting seems to be the only remedy. This persists with two
different keyboard models and on unplugging and reinserting the
keyboard.



 cut -
ata0: master: setting up UDMA2 mode on PIIX4 chip OK
ad0: IBM-DTTA-371440/T71OA73A ATA-4 disk at ata0 as master
ad0: 13783MB (28229040 sectors), 28005 cyls, 16 heads, 63 S/T,
512 B/S
ad0: piomode=4, dmamode=2, udmamode=2
ad0: 16 secs/int, 31 depth queue, DMA mode
ata0: slave: setting up UDMA2 mode on PIIX4 chip OK
ad1: IBM-DJNA-372200/J71OA30K ATA-4 disk at ata0 as slave 
ad1: 21557MB (44150400 sectors), 43800 cyls, 16 heads, 63 S/T,
512 B/S
ad1: piomode=4, dmamode=2, udmamode=2
ad1: 16 secs/int, 31 depth queue, DMA mode
ata1: master: setting up UDMA2 mode on PIIX4 chip OK
ad2: IBM-DTTA-371440/T71OA73A ATA-4 disk at ata1 as master
ad2: 13783MB (28229040 sectors), 28005 cyls, 16 heads, 63 S/T,
512 B/S
--- cut 

Do you have enough disk space ;-)))


Thanks for you reaction.

Regards,
Ron.





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Problems with 4.0 keyboard input!

1999-08-14 Thread Poul-Henning Kamp

In message 000401bee65b$b6fd0440$0264a8c0@.demon.nl, "Ron Klinkien" writes:

I get the bktr device usurping its own cdevsw[] as well - I was
told it was "most likely" benign, so I've been waiting for
others' comments.

I have looked in the source code, but what does usurping means? 
My English is not that good ;)

It means "to take or assume and hold (something) by force or without
right".  Usually used about power in subsaharan our south american
countries.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



RE: Problems with 4.0 keyboard input!

1999-08-14 Thread Nick Hibma

 I have looked in the source code, but what does usurping means? 
 My English is not that good ;)

'opslorpen' in Dutch.

Nick

-- 
e-Mail: [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



RE: Problems with 4.0 keyboard input!

1999-08-14 Thread Ron Klinkien


In message 000401bee65b$b6fd0440$0264a8c0@.demon.nl, "Ron Klinkien"
writes:

I get the bktr device usurping its own cdevsw[] as well - I was
told it was "most likely" benign, so I've been waiting for
others' comments.

I have looked in the source code, but what does usurping means?
My English is not that good ;)

It means "to take or assume and hold (something) by force or without
right".  Usually used about power in subsaharan our south american
countries.

Aha ok.

Thanks for the explanation.

Ron.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Problems with 4.0 keyboard input!

1999-08-13 Thread Brian McGroarty

I get the bktr device usurping its own cdevsw[] as well - I was
told it was "most likely" benign, so I've been waiting for
others' comments.

I also get the keyboard problem periodically, and I've been
trying to isolate just what I do to cause it. Generally, if I
reboot and don't hit a key before FreeBSD boots, it never
happens. If I tap enter to abort the countdown, the keyboard
scrambles perhaps one time in five.

Resetting seems to be the only remedy. This persists with two
different keyboard models and on unplugging and reinserting the
keyboard.


Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights
reserved.
FreeBSD 4.0-CURRENT #10: Fri Aug 13 07:02:32 CDT 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/DOCENT
Timecounter "i8254"  frequency 1193182 Hz
CPU: Celeron (686-class CPU)
  Origin = "GenuineIntel"  Id = 0x665  Stepping = 5
 
Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real memory  = 536870912 (524288K bytes)
avail memory = 518422528 (506272K bytes)
Programming 24 pins in IOAPIC #0
FreeBSD/SMP: Multiprocessor motherboard
 cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee0
 cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0
Preloaded elf kernel "kernel" at 0xc028f000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc028f09c.
Pentium Pro MTRR support enabled
Probing for PnP devices:
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Intel 82443BX (440 BX) host to PCI bridge on
motherboard
pci0: PCI bus on pcib0
WARNING: "bktr" is usurping "bktr"'s cdevsw[]
pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device
1.0 on pci0
pci1: PCI bus on pcib1
vga-pci0: NVidia Riva TNT graphics accelerator irq 16 at
device 0.0 on pci1
isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0
ata-pci0: Intel PIIX4 IDE controller at device 7.1 on pci0
ata-pci0: Busmastering DMA supported
ata0 at 0x01f0 irq 14 on ata-pci0
ata1 at 0x0170 irq 15 on ata-pci0
chip1: UHCI USB controller at device 7.2 on pci0
chip2: Intel 82371AB Power management controller at device 7.3
on pci0
bktr0: BrookTree 878 irq 16 at device 16.0 on pci0
iicbb0: I2C generic bit-banging driver on bti2c0
iicbus0: Philips I2C bus on iicbb0 master-only
smbus0: System Management Bus on bti2c0
Hauppauge Model 62471 A   
Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner, dbx stereo.
pci0: unknown card DD^0878 (vendor=0x109e, dev=0x0878) at 16.1
irq 16
pcm0: AudioPCI ES1370 irq 18 at device 18.0 on pci0
pcm0: using I/O space register mapping at 0xef00
fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 19 at device
19.0 on pci0
fxp0: Ethernet address 00:90:27:18:a6:fa
xl0: 3Com 3c905B-TX Fast Etherlink XL irq 16 at device 20.0 on
pci0
xl0: Ethernet address: 00:50:04:01:77:7b
xl0: autoneg complete, link status good (half-duplex, 100Mbps)
isa0: ISA bus on motherboard
fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on
isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5" drive on fdc0 drive 0
atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0
atkbd0: AT Keyboard irq 1 on atkbdc0
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3
vga0: Generic ISA VGA at port 0x3b0-0x3df iomem
0xa-0xb on isa0
sc0: System console on isa0
sc0: VGA 16 virtual consoles, flags=0x200
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via pin 2
IP packet filtering initialized, divert enabled, rule-based
forwarding disabled, logging disabled
SMP: AP CPU #1 Launched!
ata0: master: setting up UDMA2 mode on PIIX4 chip OK
ad0: IBM-DTTA-371440/T71OA73A ATA-4 disk at ata0 as master
ad0: 13783MB (28229040 sectors), 28005 cyls, 16 heads, 63 S/T,
512 B/S
ad0: piomode=4, dmamode=2, udmamode=2
ad0: 16 secs/int, 31 depth queue, DMA mode
ata0: slave: setting up UDMA2 mode on PIIX4 chip OK
ad1: IBM-DJNA-372200/J71OA30K ATA-4 disk at ata0 as slave 
ad1: 21557MB (44150400 sectors), 43800 cyls, 16 heads, 63 S/T,
512 B/S
ad1: piomode=4, dmamode=2, udmamode=2
ad1: 16 secs/int, 31 depth queue, DMA mode
ata1: master: setting up UDMA2 mode on PIIX4 chip OK
ad2: IBM-DTTA-371440/T71OA73A ATA-4 disk at ata1 as master
ad2: 13783MB (28229040 sectors), 28005 cyls, 16 heads, 63 S/T,
512 B/S
ad2: piomode=4, dmamode=2, udmamode=2
ad2: 16 secs/int, 31 depth queue, DMA mode
atapi: piomode=4, dmamode=2, udmamode=-1
ata1: slave: setting up WDMA2 mode on PIIX3/4 chip OK
atapi: DMA transfer mode set
acd0: CRW6206A/1.2A CDROM drive at ata1 as slave 
acd0: drive speed 344 - 1034KB/sec, 384KB cache, DMA
acd0: supported read types: CD-R, CD-RW, CD-DA, packet track
acd0: supported write types: CD-R, CD-RW, test write
acd0: Audio: play, 128 volume levels
acd0: Mechanism: ejectable tray
acd0: Medium: no/blank disc inside, unlocked, lock protected




machine i386
cpu I686_CPU

Re: Problems with 4.0 keyboard input!

1999-08-13 Thread Warner Losh

In message 01bee5f0$c467c7c0$0264a8c0@.demon.nl "Ron Klinkien" writes:
: After building a few succesfull 4.0 releases (last cvsupped on 13 aug 99),
: the keyboard is acting very strange, i cannot login,
: i get only strange characters, and when I hit CTRL I get:
: 
: load: 0.04 cmd: login242 [ttyin] 0.01u 0.03s 0% 772K
: load: 0.04 cmd: login242 [ttyin] 0.01u 0.03s 0% 772K
: load: 0.04 cmd: login242 [ttyin] 0.01u 0.03s 0% 772K

I get that too from time to time.  I think that the boot blocks are
putting the keyboard into an odd state since I sometimes can't break
into the boot sequence to boot an alternate kernel.  So far it has
been confined to my Sony VAIO.  Never could come up with a good test
case for it, however

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Problems with 4.0 keyboard input!

1999-08-13 Thread Kazutaka YOKOTA

[...]
I also get the keyboard problem periodically, and I've been
trying to isolate just what I do to cause it. Generally, if I
reboot and don't hit a key before FreeBSD boots, it never
happens. If I tap enter to abort the countdown, the keyboard
scrambles perhaps one time in five.

If you hit the keyboard at the "wrong" moment during keyboard
initialization, the keyboard driver may get confused.

In your case, you type something before the kernel is loaded and that
seems to be causing the trouble.

Such key input should be discarded by the keyboard driver before it
tries to initialize the keyboard.  There may be a nasty timing problem
here...

As a temporary workaround, please apply the following patch to
/sys/dev/atkbd.c and see how it works.

Kazu

Resetting seems to be the only remedy. This persists with two
different keyboard models and on unplugging and reinserting the
keyboard.

Index: atkbd.c
===
RCS file: /src/CVS/src/sys/dev/kbd/atkbd.c,v
retrieving revision 1.12
diff -u -r1.12 atkbd.c
--- atkbd.c 1999/07/18 06:16:25 1.12
+++ atkbd.c 1999/08/14 03:10:40
@@ -1153,7 +1178,7 @@
}
 
/* save the current controller command byte */
-   empty_both_buffers(kbdc, 10);
+   empty_both_buffers(kbdc, 200);
c = get_controller_command_byte(kbdc);
if (c == -1) {
/* CONTROLLER ERROR */


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Problems with 4.0 keyboard input!

1999-08-13 Thread Mike Smith

 In message 01bee5f0$c467c7c0$0264a8c0@.demon.nl "Ron Klinkien" writes:
 : After building a few succesfull 4.0 releases (last cvsupped on 13 aug 99),
 : the keyboard is acting very strange, i cannot login,
 : i get only strange characters, and when I hit CTRL I get:
 : 
 : load: 0.04 cmd: login242 [ttyin] 0.01u 0.03s 0% 772K
 : load: 0.04 cmd: login242 [ttyin] 0.01u 0.03s 0% 772K
 : load: 0.04 cmd: login242 [ttyin] 0.01u 0.03s 0% 772K
 
 I get that too from time to time.  I think that the boot blocks are
 putting the keyboard into an odd state since I sometimes can't break
 into the boot sequence to boot an alternate kernel.  So far it has
 been confined to my Sony VAIO.  Never could come up with a good test
 case for it, however

It's not the boot blocks doing anything explicit; they just use the BIOS.
-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  [EMAIL PROTECTED]
\\-- Joseph Merrick   \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Problems with 4.0 keyboard input!

1999-08-13 Thread Warner Losh

In message [EMAIL PROTECTED] Mike Smith writes:
: It's not the boot blocks doing anything explicit; they just use the BIOS.

I have noticed that boot[12] doesn't seem to have this problem.
However, after /boot/loader has been loaded, I see this problem from
time to time.  I don't know what is going on, I'm just reporting what
I've seen

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Problems with 4.0 keyboard input!

1999-08-13 Thread Mike Smith

 In message [EMAIL PROTECTED] Mike Smith writes:
 : It's not the boot blocks doing anything explicit; they just use the BIOS.
 
 I have noticed that boot[12] doesn't seem to have this problem.
 However, after /boot/loader has been loaded, I see this problem from
 time to time.  I don't know what is going on, I'm just reporting what
 I've seen

*mumble*  We're seeing a few cases where BIOS code in the boot path 
isn't working too well (or at all) when run in vm86 mode. 8(

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  [EMAIL PROTECTED]
\\-- Joseph Merrick   \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message