linuxconsole-dev

Re: HID stuff broken.

[Vojtech P. <vo...@su...>]

On Wed, Dec 26, 2001 at 01:11:27PM -0800, James Simmons wrote:

> I just synced up to 2.5.1 and the USB layer has changed a lot.

Wonderful!

> So the HID stuff doesn't work at present. Could you fix it? 

Yes, of course. I'll try to do that today.

-- 
Vojtech Pavlik
SuSE Labs

Re: Serial design

[Vojtech P. <vo...@su...>]

On Wed, Dec 26, 2001 at 03:43:29PM -0800, James Simmons wrote:

> > This sounds a somewhat Microsofty solution.  Do we really want the kernel
> > sending stuff like 'AT' commands at various baud rates to the connected
> > machine, which might be waiting for you to "press any key" after changing
> > the floppy?
> 
> I never said anything about sending AT commands. For example in
> serial_8250_pci.c you have serial_pci_guess_board. Knowing that we have
> a modem means we can only use a TTY interface for that port. Unless the 
> device is hotpluggable. A input interface wouldn't make sense if we have
> a modem. If it is possible to see what type of device we have we can use
> that to determine what interface userland can have.

And in case we can't figure out in the kernel in a simple way (like the
first two serial ports on a Sun are keyboard and mouse) we simply make
it a tty, let the userland talk to it, decide what it sees there and
then tell the kernel back. What do you think?

-- 
Vojtech Pavlik
SuSE Labs

Re: Serial design

[Andrew E. M. <an...@is...>]

James Simmons wrote:
> 
> > >    The second class is using the bus like the PCI/PNP layer to find out
> > > what got attached.
> >
> > This sounds a somewhat Microsofty solution.  Do we really want the kernel
> > sending stuff like 'AT' commands at various baud rates to the connected
> > machine, which might be waiting for you to "press any key" after changing
> > the floppy?
> 
> I never said anything about sending AT commands.

Though I hate to point this out, there is a spec for a serial PnP protocol,
It doesn't confuse modems or terminals, as it twiddles the RTS/CTS lines.
Yes, Microsoft developed it.  Microsoft serial mice should supoort it.

--
Andrew E. Mileski
Ottawa, Canada

Re: Serial design

[James S. <jsi...@tr...>]

> It's actually used for a microcontroller which handles the touchscreen and
> many other things (like power management).

True. The driver for the "touchscreen" does alot of things. 

> >    The second class is using the bus like the PCI/PNP layer to find out
> > what got attached. 
> 
> This sounds a somewhat Microsofty solution.  Do we really want the kernel
> sending stuff like 'AT' commands at various baud rates to the connected
> machine, which might be waiting for you to "press any key" after changing
> the floppy?

I never said anything about sending AT commands. For example in
serial_8250_pci.c you have serial_pci_guess_board. Knowing that we have
a modem means we can only use a TTY interface for that port. Unless the 
device is hotpluggable. A input interface wouldn't make sense if we have
a modem. If it is possible to see what type of device we have we can use
that to determine what interface userland can have.

> >    Then we have the total dumb serial port. In this case if we can't
> > figure if anything is attached or if something attaches and we don't know
> > what it is then prehaps we should default to using the tty layer. Or
> > better yet let the user load the right modules. 
> 
> Your only connection to the machine is over this serial port.  How do you
> load the modules if you're not connected to the machine?

Okay. For the worst case we have the device map a struct uart_driver for
the TTY layer to every port.

> > Their is no difference. I based these ideas on what you have done. Your low 
> > level setup is perfect from what I can see. Well except for touching 
> > struct uart_info. I still need to figure a cheap way to send data from the
> > low level to the user uart_driver level. Most likely I will add a rx_char
> > and tx_char function to struct uart_driver.
> 
> I'd rather see a generic buffering layer between the serial low level and
> upper levels (and do away with the tty flip buffers).  I think that will
> separate it sufficiently.

Hm. I have no problem with that. As long as removing the flip buffers
don't break the other TTY drivers. 

> Also, I don't see an easy way to get rid of uart_info from the low level
> drivers - its used for many things, including maintaining correct locking
> on SMP.
> 
> > Also maybe a shutdown or connect function?
> 
> Erm, don't we have 'startup' and 'shutdown' functions already?

I mean add functions to struct uart_driver to detect when a device has
been attached or detached depending if the hardware can support it.

> > Well the higher data structures are a bit messer to deal with. We have:
> > 
> > struct uart_state;
> > struct uart_info;
> > struct uart_driver;
> > 
> > Every type of serial device would make use of struct uart_driver. Now
> > struct uart_state and struct uart_info are heavly related to the TTY
> > layer. So in the case of a TTY device was would have the void data field
> > in struct uart_driver point to most likely struct uart_info.   
> 
> Uh oh, I really don't like this.  So we're going to have 'n' ports with
> 'n' struct uart_driver entries?  This sounds like needless bloat.
> 
> Please tell me you weren't seriously considering that!

No. A one to one mapping between struct uart_driver and a port. 

HID stuff broken.

[James S. <jsi...@tr...>]

I just synced up to 2.5.1 and the USB layer has changed a lot. So the HID
stuff doesn't work at present. Could you fix it? 


   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Re: debugging the atkbd

[Rogelio M. S. Jr. <ro...@ev...>]

Here are the logs once more:
Dec 25 14:05:47 coffeesaur kernel: Cannot find map file.
Dec 25 14:05:47 coffeesaur kernel: Loaded 418 symbols from 13 modules.
Dec 25 14:05:47 coffeesaur kernel: Linux version 2.4.14-ruby (root@coffeesaur) (gcc version 3.0.2 (Debian)) #11 Tue Dec 25 12:28:27 PHT 2001
Dec 25 14:05:47 coffeesaur kernel: BIOS-provided physical RAM map:
Dec 25 14:05:47 coffeesaur kernel:  BIOS-88: 0000000000000000 - 000000000009f000 (usable)
Dec 25 14:05:47 coffeesaur kernel:  BIOS-88: 0000000000100000 - 0000000001800000 (usable)
Dec 25 14:05:47 coffeesaur kernel: On node 0 totalpages: 6144
Dec 25 14:05:47 coffeesaur kernel: zone(0): 4096 pages.
Dec 25 14:05:47 coffeesaur kernel: zone(1): 2048 pages.
Dec 25 14:05:47 coffeesaur kernel: zone(2): 0 pages.
Dec 25 14:05:47 coffeesaur kernel: Kernel command line: root=/dev/sda1 mem=24576K
Dec 25 14:05:47 coffeesaur kernel: Initializing CPU#0
Dec 25 14:05:47 coffeesaur kernel: Console: colour VGA+ 80x25
Dec 25 14:05:47 coffeesaur kernel: Calibrating delay loop... 33.17 BogoMIPS
Dec 25 14:05:47 coffeesaur kernel: Memory: 22444k/24576k available (878k kernel code, 1744k reserved, 197k data, 68k init, 0k highmem)
Dec 25 14:05:47 coffeesaur kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok.
Dec 25 14:05:47 coffeesaur kernel: Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
Dec 25 14:05:47 coffeesaur kernel: Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
Dec 25 14:05:47 coffeesaur kernel: Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Dec 25 14:05:47 coffeesaur kernel: Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Dec 25 14:05:47 coffeesaur kernel: Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
Dec 25 14:05:47 coffeesaur kernel: CPU: Before vendor init, caps: 00000003 00000000 00000000, vendor = 0
Dec 25 14:05:47 coffeesaur kernel: CPU: After vendor init, caps: 00000003 00000000 00000000 00000000
Dec 25 14:05:47 coffeesaur kernel: CPU:     After generic, caps: 00000003 00000000 00000000 00000000
Dec 25 14:05:47 coffeesaur kernel: CPU:             Common caps: 00000003 00000000 00000000 00000000
Dec 25 14:05:47 coffeesaur kernel: CPU: Intel 486 DX/2 stepping 05
Dec 25 14:05:47 coffeesaur kernel: Checking 'hlt' instruction... OK.
Dec 25 14:05:47 coffeesaur kernel: POSIX conformance testing by UNIFIX
Dec 25 14:05:47 coffeesaur kernel: Micro Channel bus detected.
Dec 25 14:05:47 coffeesaur kernel: Linux NET4.0 for Linux 2.4
Dec 25 14:05:47 coffeesaur kernel: Based upon Swansea University Computer Society NET3.039
Dec 25 14:05:47 coffeesaur kernel: Initializing RT netlink socket
Dec 25 14:05:47 coffeesaur kernel: Starting kswapd
Dec 25 14:05:48 coffeesaur kernel: devfs: v0.120 (20011103) Richard Gooch (rg...@at...)
Dec 25 14:05:48 coffeesaur kernel: devfs: boot_options: 0x1
Dec 25 14:05:48 coffeesaur kernel: pty: 256 Unix98 ptys configured
Dec 25 14:05:48 coffeesaur kernel: Real Time Clock Driver v1.10e
Dec 25 14:05:48 coffeesaur kernel: block: 64 slots per queue, batch=16
Dec 25 14:05:48 coffeesaur kernel: SCSI subsystem driver Revision: 1.00
Dec 25 14:05:48 coffeesaur kernel: scsi  <fd_mcs>: Future Domain SCSI Adapter MCS-700(18C50) at slot 1
Dec 25 14:05:48 coffeesaur kernel: scsi0 <fd_mcs>: BIOS at 0xDE000, HostID 7, TMC-18C50 Chip, IRQ 5, IO 0x140
Dec 25 14:05:48 coffeesaur kernel: scsi0 : Future Domain SCSI Adapter MCS-700(18C50)
Dec 25 14:05:48 coffeesaur kernel:   Vendor: IBM       Model: 0662S12       !O  Rev: 2 23
Dec 25 14:05:48 coffeesaur kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Dec 25 14:05:48 coffeesaur kernel: Attached scsi disk sda at scsi0, channel 0, id 6, lun 0
Dec 25 14:05:48 coffeesaur kernel: SCSI device sda: 2055035 512-byte hdwr sectors (1052 MB)
Dec 25 14:05:48 coffeesaur kernel: Partition check:
Dec 25 14:05:48 coffeesaur kernel:  /dev/scsi/host0/bus0/target6/lun0: p1 p2
Dec 25 14:05:48 coffeesaur kernel: tts/%%d0 at I/O 0x3f8 (irq = 4) is a 16550A
Dec 25 14:05:48 coffeesaur kernel: tts/%%d1 at I/O 0x2f8 (irq = 3) is a 16550A
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 9c <- i8042 (flush) [0]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 20 -> i8042 (command) [0]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 25 <- i8042 (return) [0]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 60 -> i8042 (command) [0]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 34 -> i8042 (parameter) [0]
Dec 25 14:05:48 coffeesaur kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Dec 25 14:05:48 coffeesaur kernel: i8042.c: d3 -> i8042 (command) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 5a -> i8042 (parameter) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: a5 <- i8042 (return) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: a9 -> i8042 (command) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 00 <- i8042 (return) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: a7 -> i8042 (command) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 20 -> i8042 (command) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 34 <- i8042 (return) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: a9 -> i8042 (command) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 00 <- i8042 (return) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: a8 -> i8042 (command) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 20 -> i8042 (command) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 14 <- i8042 (return) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 60 -> i8042 (command) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 34 -> i8042 (parameter) [1]
Dec 25 14:05:48 coffeesaur kernel: serio: i8042 AUX port at 0x60,0x64 irq 12
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 60 -> i8042 (command) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 16 -> i8042 (parameter) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: d4 -> i8042 (command) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: f5 -> i8042 (parameter) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 60 -> i8042 (command) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 16 -> i8042 (parameter) [1]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: fe <- i8042 (interrupt-aux) [2]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received fe
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 60 -> i8042 (command) [2]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 34 -> i8042 (parameter) [2]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 60 -> i8042 (command) [2]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 25 -> i8042 (parameter) [2]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: f5 -> i8042 (kbd-data) [2]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: fa <- i8042 (interrupt-kbd) [2]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received fa
Dec 25 14:05:48 coffeesaur kernel: i8042.c: f2 -> i8042 (kbd-data) [2]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: fa <- i8042 (interrupt-kbd) [2]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received fa
Dec 25 14:05:48 coffeesaur kernel: i8042.c: ab <- i8042 (interrupt-kbd) [2]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received ab
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 83 <- i8042 (interrupt-kbd) [2]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received 83
Dec 25 14:05:48 coffeesaur kernel: i8042.c: ea -> i8042 (kbd-data) [2]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: fe <- i8042 (interrupt-kbd) [3]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received fe
Dec 25 14:05:48 coffeesaur kernel: i8042.c: f0 -> i8042 (kbd-data) [3]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: fa <- i8042 (interrupt-kbd) [3]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received fa
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 02 -> i8042 (kbd-data) [3]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: fa <- i8042 (interrupt-kbd) [3]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received fa
Dec 25 14:05:48 coffeesaur kernel: i8042.c: f0 -> i8042 (kbd-data) [3]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: fa <- i8042 (interrupt-kbd) [3]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received fa
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 00 -> i8042 (kbd-data) [3]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: fa <- i8042 (interrupt-kbd) [4]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received fa
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 02 <- i8042 (interrupt-kbd) [4]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received 16
Dec 25 14:05:48 coffeesaur kernel: input.c: calling hotplug without valid filesystem
Dec 25 14:05:48 coffeesaur kernel: input: AT Set 22 keyboard on isa0060/serio0
Dec 25 14:05:48 coffeesaur kernel: i8042.c: f8 -> i8042 (kbd-data) [5]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: fa <- i8042 (interrupt-kbd) [5]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received fa
Dec 25 14:05:48 coffeesaur kernel: i8042.c: ed -> i8042 (kbd-data) [5]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: fa <- i8042 (interrupt-kbd) [5]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received fa
Dec 25 14:05:48 coffeesaur kernel: i8042.c: 00 -> i8042 (kbd-data) [5]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: fa <- i8042 (interrupt-kbd) [5]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received fa
Dec 25 14:05:48 coffeesaur kernel: i8042.c: f4 -> i8042 (kbd-data) [5]
Dec 25 14:05:48 coffeesaur kernel: i8042.c: fa <- i8042 (interrupt-kbd) [6]
Dec 25 14:05:48 coffeesaur kernel: atkbd.c: Received fa
Dec 25 14:05:48 coffeesaur kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Dec 25 14:05:48 coffeesaur kernel: IP Protocols: ICMP, UDP, TCP, IGMP
Dec 25 14:05:48 coffeesaur kernel: IP: routing cache hash table of 512 buckets, 4Kbytes
Dec 25 14:05:48 coffeesaur kernel: TCP: Hash tables configured (established 2048 bind 4096)
Dec 25 14:05:48 coffeesaur kernel: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Dec 25 14:05:48 coffeesaur kernel: VFS: Mounted root (ext2 filesystem) readonly.
Dec 25 14:05:48 coffeesaur kernel: Mounted devfs on /dev
Dec 25 14:05:48 coffeesaur kernel: Freeing unused kernel memory: 68k freed
Dec 25 14:05:48 coffeesaur kernel: Adding Swap: 50172k swap-space (priority -1)
Dec 25 14:05:48 coffeesaur kernel: Coda Kernel/Venus communications, v5.3.15, co...@cs...
Dec 25 14:05:48 coffeesaur kernel: IPv6 v0.8 for NET4.0
Dec 25 14:05:48 coffeesaur kernel: IPv6 over IPv4 tunneling driver
Dec 25 14:05:48 coffeesaur kernel: CSLIP: code copyright 1989 Regents of the University of California
Dec 25 14:05:48 coffeesaur kernel: PPP generic driver version 2.4.1
Dec 25 14:05:48 coffeesaur kernel: inserting floppy driver for 2.4.14-ruby
Dec 25 14:05:48 coffeesaur kernel: Floppy drive(s): fd0 is 2.88M
Dec 25 14:05:48 coffeesaur kernel: FDC 0 is a post-1991 82077
Dec 25 14:05:49 coffeesaur pppd[196]: pppd 2.4.1 started by root, uid 0
Dec 25 14:05:50 coffeesaur chat[208]: abort on (BUSY)
Dec 25 14:05:50 coffeesaur chat[208]: abort on (NO CARRIER)
Dec 25 14:05:50 coffeesaur chat[208]: abort on (VOICE)
Dec 25 14:05:50 coffeesaur chat[208]: abort on (NO DIALTONE)
Dec 25 14:05:50 coffeesaur chat[208]: abort on (NO DIAL TONE)
Dec 25 14:05:50 coffeesaur chat[208]: abort on (NO ANSWER)
Dec 25 14:05:50 coffeesaur chat[208]: send (ATQ0 V1 E1 S0=0 &C1 &D2 S11=55 +FCLASS=0^M)
Dec 25 14:05:51 coffeesaur chat[208]: expect (OK)
Dec 25 14:05:51 coffeesaur chat[208]: ATQ0 V1 E1 S0=0 &C1 &D2 S11=55 +FCLASS=0^M^M
Dec 25 14:05:51 coffeesaur chat[208]: OK
Dec 25 14:05:51 coffeesaur chat[208]:  -- got it 
Dec 25 14:05:51 coffeesaur chat[208]: send (ATDT8110944^M)
Dec 25 14:05:51 coffeesaur chat[208]: expect (CONNECT)
Dec 25 14:05:51 coffeesaur chat[208]: ^M
Dec 25 14:05:54 coffeesaur ntpdate[229]: can't find host time.nist.gov
Dec 25 14:05:54 coffeesaur ntpdate[229]: can't find host ntp2.usno.navy.mil
Dec 25 14:05:54 coffeesaur ntpdate[229]: sendto(203.21.84.4): Network is unreachable
Dec 25 14:05:57 coffeesaur last message repeated 3 times
Dec 25 14:05:58 coffeesaur ntpdate[229]: no server suitable for synchronization found
Dec 25 14:05:59 coffeesaur ntpd[232]: ntpd 4.1.0 Fri Sep 28 00:50:30 PDT 2001 (2)
Dec 25 14:05:59 coffeesaur ntpd[232]: signal_no_reset: signal 13 had flags 4000000
Dec 25 14:05:59 coffeesaur ntpd[232]: precision = 12 usec
Dec 25 14:05:59 coffeesaur ntpd[232]: kernel time discipline status 0040
Dec 25 14:05:59 coffeesaur /usr/sbin/cron[234]: (CRON) INFO (pidfile fd = 3)
Dec 25 14:05:59 coffeesaur /usr/sbin/cron[236]: (CRON) STARTUP (fork ok)
Dec 25 14:06:00 coffeesaur /usr/sbin/cron[236]: (CRON) INFO (Running @reboot jobs)
Dec 25 14:06:10 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [7428]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:10 coffeesaur kernel: i8042.c: 6b <- i8042 (interrupt-kbd) [7428]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received 40
Dec 25 14:06:10 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [7436]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:10 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [7436]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:10 coffeesaur kernel: i8042.c: 6b <- i8042 (interrupt-kbd) [7436]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received 40
Dec 25 14:06:10 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [7449]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:10 coffeesaur kernel: i8042.c: 72 <- i8042 (interrupt-kbd) [7450]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received 39
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x139, on isa0060/serio0) pressed.
Dec 25 14:06:10 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [7459]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:10 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [7459]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:10 coffeesaur kernel: i8042.c: 72 <- i8042 (interrupt-kbd) [7460]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received 39
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x139, on isa0060/serio0) released.
Dec 25 14:06:10 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [7479]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:10 coffeesaur kernel: i8042.c: 74 <- i8042 (interrupt-kbd) [7479]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received 53
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x153, on isa0060/serio0) pressed.
Dec 25 14:06:10 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [7487]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:10 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [7487]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:10 coffeesaur kernel: i8042.c: 74 <- i8042 (interrupt-kbd) [7487]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received 53
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x153, on isa0060/serio0) released.
Dec 25 14:06:10 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [7504]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:10 coffeesaur kernel: i8042.c: 75 <- i8042 (interrupt-kbd) [7504]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received 5c
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x15c, on isa0060/serio0) pressed.
Dec 25 14:06:10 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [7511]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:10 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [7511]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:10 coffeesaur kernel: i8042.c: 75 <- i8042 (interrupt-kbd) [7511]
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Received 5c
Dec 25 14:06:10 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x15c, on isa0060/serio0) released.
Dec 25 14:06:12 coffeesaur chat[208]: ATDT8110944^M^M
Dec 25 14:06:12 coffeesaur chat[208]: CONNECT
Dec 25 14:06:12 coffeesaur chat[208]:  -- got it 
Dec 25 14:06:12 coffeesaur chat[208]: send (\d)
Dec 25 14:06:13 coffeesaur pppd[196]: Serial connection established.
Dec 25 14:06:13 coffeesaur pppd[196]: using channel 1
Dec 25 14:06:13 coffeesaur pppd[196]: Using interface ppp0
Dec 25 14:06:13 coffeesaur pppd[196]: Connect: ppp0 <--> /dev/ttyS0
Dec 25 14:06:14 coffeesaur pppd[196]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x373238c3> <pcomp> <accomp>]
Dec 25 14:06:15 coffeesaur pppd[196]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xde0eb589> <pcomp> <accomp> <auth pap>]
Dec 25 14:06:15 coffeesaur pppd[196]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xde0eb589> <pcomp> <accomp> <auth pap>]
Dec 25 14:06:17 coffeesaur pppd[196]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x373238c3> <pcomp> <accomp>]
Dec 25 14:06:17 coffeesaur pppd[196]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x373238c3> <pcomp> <accomp>]
Dec 25 14:06:17 coffeesaur pppd[196]: sent [LCP EchoReq id=0x0 magic=0x373238c3]
Dec 25 14:06:17 coffeesaur pppd[196]: sent [PAP AuthReq id=0x1 user="rogelio" password=<hidden>]
Dec 25 14:06:18 coffeesaur pppd[196]: rcvd [LCP EchoRep id=0x0 magic=0xde0eb589]
Dec 25 14:06:18 coffeesaur pppd[196]: rcvd [PAP AuthAck id=0x1 "Login Succeeded"]
Dec 25 14:06:18 coffeesaur pppd[196]: Remote message: Login Succeeded
Dec 25 14:06:18 coffeesaur pppd[196]: kernel does not support PPP filtering
Dec 25 14:06:18 coffeesaur pppd[196]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
Dec 25 14:06:18 coffeesaur kernel: PPP BSD Compression module registered
Dec 25 14:06:19 coffeesaur kernel: PPP Deflate Compression module registered
Dec 25 14:06:20 coffeesaur pppd[196]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Dec 25 14:06:20 coffeesaur pppd[196]: rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 00> <addr 210.16.1.178>]
Dec 25 14:06:20 coffeesaur pppd[196]: sent [IPCP ConfAck id=0x1 <compress VJ 0f 00> <addr 210.16.1.178>]
Dec 25 14:06:20 coffeesaur pppd[196]: rcvd [IPCP ConfNak id=0x1 <addr 210.16.6.224>]
Dec 25 14:06:20 coffeesaur pppd[196]: sent [IPCP ConfReq id=0x2 <addr 210.16.6.224> <compress VJ 0f 01>]
Dec 25 14:06:20 coffeesaur pppd[196]: rcvd [LCP ProtRej id=0x5e 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Dec 25 14:06:20 coffeesaur pppd[196]: rcvd [IPCP ConfAck id=0x2 <addr 210.16.6.224> <compress VJ 0f 01>]
Dec 25 14:06:20 coffeesaur pppd[196]: Cannot determine ethernet address for proxy ARP
Dec 25 14:06:20 coffeesaur pppd[196]: local  IP address 210.16.6.224
Dec 25 14:06:20 coffeesaur pppd[196]: remote IP address 210.16.1.178
Dec 25 14:06:20 coffeesaur pppd[196]: Script /etc/ppp/ip-up started (pid 251)
Dec 25 14:06:22 coffeesaur pppd[196]: Script /etc/ppp/ip-up finished (pid 251), status = 0x0
Dec 25 14:06:26 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9026]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:26 coffeesaur kernel: i8042.c: 6b <- i8042 (interrupt-kbd) [9027]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received 40
Dec 25 14:06:26 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9036]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:26 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [9036]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:26 coffeesaur kernel: i8042.c: 6b <- i8042 (interrupt-kbd) [9037]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received 40
Dec 25 14:06:26 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9050]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:26 coffeesaur kernel: i8042.c: 72 <- i8042 (interrupt-kbd) [9050]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received 39
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x139, on isa0060/serio0) pressed.
Dec 25 14:06:26 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9060]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:26 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [9061]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:26 coffeesaur kernel: i8042.c: 72 <- i8042 (interrupt-kbd) [9061]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received 39
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x139, on isa0060/serio0) released.
Dec 25 14:06:26 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9072]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:26 coffeesaur kernel: i8042.c: 74 <- i8042 (interrupt-kbd) [9072]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received 53
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x153, on isa0060/serio0) pressed.
Dec 25 14:06:26 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9085]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:26 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [9086]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:26 coffeesaur kernel: i8042.c: 74 <- i8042 (interrupt-kbd) [9086]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received 53
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x153, on isa0060/serio0) released.
Dec 25 14:06:26 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9101]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:26 coffeesaur kernel: i8042.c: 75 <- i8042 (interrupt-kbd) [9101]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received 5c
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x15c, on isa0060/serio0) pressed.
Dec 25 14:06:26 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9108]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:26 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [9108]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:26 coffeesaur kernel: i8042.c: 75 <- i8042 (interrupt-kbd) [9108]
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Received 5c
Dec 25 14:06:26 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x15c, on isa0060/serio0) released.
Dec 25 14:06:28 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9290]
Dec 25 14:06:28 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:28 coffeesaur kernel: i8042.c: 6b <- i8042 (interrupt-kbd) [9291]
Dec 25 14:06:28 coffeesaur kernel: atkbd.c: Received 40
Dec 25 14:06:28 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9302]
Dec 25 14:06:28 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:28 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [9302]
Dec 25 14:06:28 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:28 coffeesaur kernel: i8042.c: 6b <- i8042 (interrupt-kbd) [9302]
Dec 25 14:06:28 coffeesaur kernel: atkbd.c: Received 40
Dec 25 14:06:29 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9368]
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:29 coffeesaur kernel: i8042.c: 72 <- i8042 (interrupt-kbd) [9368]
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Received 39
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x139, on isa0060/serio0) pressed.
Dec 25 14:06:29 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9381]
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:29 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [9382]
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:29 coffeesaur kernel: i8042.c: 72 <- i8042 (interrupt-kbd) [9382]
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Received 39
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x139, on isa0060/serio0) released.
Dec 25 14:06:29 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9401]
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:29 coffeesaur kernel: i8042.c: 74 <- i8042 (interrupt-kbd) [9401]
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Received 53
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x153, on isa0060/serio0) pressed.
Dec 25 14:06:29 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9412]
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:29 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [9412]
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:29 coffeesaur kernel: i8042.c: 74 <- i8042 (interrupt-kbd) [9413]
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Received 53
Dec 25 14:06:29 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x153, on isa0060/serio0) released.
Dec 25 14:06:30 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9427]
Dec 25 14:06:30 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:30 coffeesaur kernel: i8042.c: 75 <- i8042 (interrupt-kbd) [9427]
Dec 25 14:06:30 coffeesaur kernel: atkbd.c: Received 5c
Dec 25 14:06:30 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x15c, on isa0060/serio0) pressed.
Dec 25 14:06:30 coffeesaur kernel: i8042.c: e0 <- i8042 (interrupt-kbd) [9434]
Dec 25 14:06:30 coffeesaur kernel: atkbd.c: Received e0
Dec 25 14:06:30 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [9434]
Dec 25 14:06:30 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:30 coffeesaur kernel: i8042.c: 75 <- i8042 (interrupt-kbd) [9434]
Dec 25 14:06:30 coffeesaur kernel: atkbd.c: Received 5c
Dec 25 14:06:30 coffeesaur kernel: atkbd.c: Unknown key (set 22, scancode 0x15c, on isa0060/serio0) released.
Dec 25 14:06:32 coffeesaur kernel: i8042.c: 2d <- i8042 (interrupt-kbd) [9658]
Dec 25 14:06:32 coffeesaur kernel: atkbd.c: Received 22
Dec 25 14:06:32 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [9666]
Dec 25 14:06:32 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:32 coffeesaur kernel: i8042.c: 2d <- i8042 (interrupt-kbd) [9666]
Dec 25 14:06:32 coffeesaur kernel: atkbd.c: Received 22
Dec 25 14:06:32 coffeesaur kernel: i8042.c: 44 <- i8042 (interrupt-kbd) [9682]
Dec 25 14:06:32 coffeesaur kernel: atkbd.c: Received 09
Dec 25 14:06:32 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [9686]
Dec 25 14:06:32 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:32 coffeesaur kernel: i8042.c: 44 <- i8042 (interrupt-kbd) [9686]
Dec 25 14:06:32 coffeesaur kernel: atkbd.c: Received 09
Dec 25 14:06:32 coffeesaur kernel: i8042.c: 44 <- i8042 (interrupt-kbd) [9697]
Dec 25 14:06:32 coffeesaur kernel: atkbd.c: Received 09
Dec 25 14:06:32 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [9706]
Dec 25 14:06:32 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:32 coffeesaur kernel: i8042.c: 44 <- i8042 (interrupt-kbd) [9706]
Dec 25 14:06:32 coffeesaur kernel: atkbd.c: Received 09
Dec 25 14:06:32 coffeesaur kernel: i8042.c: 2c <- i8042 (interrupt-kbd) [9711]
Dec 25 14:06:32 coffeesaur kernel: atkbd.c: Received 1a
Dec 25 14:06:32 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [9718]
Dec 25 14:06:32 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:32 coffeesaur kernel: i8042.c: 2c <- i8042 (interrupt-kbd) [9719]
Dec 25 14:06:32 coffeesaur kernel: atkbd.c: Received 1a
Dec 25 14:06:33 coffeesaur kernel: i8042.c: 5a <- i8042 (interrupt-kbd) [9732]
Dec 25 14:06:33 coffeesaur kernel: atkbd.c: Received 17
Dec 25 14:06:33 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [9739]
Dec 25 14:06:33 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:33 coffeesaur kernel: i8042.c: 5a <- i8042 (interrupt-kbd) [9739]
Dec 25 14:06:33 coffeesaur kernel: atkbd.c: Received 17
Dec 25 14:06:37 coffeesaur kernel: i8042.c: 1c <- i8042 (interrupt-kbd) [10198]
Dec 25 14:06:37 coffeesaur kernel: atkbd.c: Received 5a
Dec 25 14:06:37 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [10203]
Dec 25 14:06:37 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:37 coffeesaur kernel: i8042.c: 1c <- i8042 (interrupt-kbd) [10203]
Dec 25 14:06:37 coffeesaur kernel: atkbd.c: Received 5a
Dec 25 14:06:39 coffeesaur kernel: i8042.c: 2c <- i8042 (interrupt-kbd) [10418]
Dec 25 14:06:39 coffeesaur kernel: atkbd.c: Received 1a
Dec 25 14:06:40 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [10427]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:40 coffeesaur kernel: i8042.c: 2c <- i8042 (interrupt-kbd) [10427]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received 1a
Dec 25 14:06:40 coffeesaur kernel: i8042.c: 33 <- i8042 (interrupt-kbd) [10435]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received 41
Dec 25 14:06:40 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [10445]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:40 coffeesaur kernel: i8042.c: 33 <- i8042 (interrupt-kbd) [10445]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received 41
Dec 25 14:06:40 coffeesaur kernel: i8042.c: 24 <- i8042 (interrupt-kbd) [10450]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received 3b
Dec 25 14:06:40 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [10457]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:40 coffeesaur kernel: i8042.c: 24 <- i8042 (interrupt-kbd) [10457]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received 3b
Dec 25 14:06:40 coffeesaur kernel: i8042.c: 29 <- i8042 (interrupt-kbd) [10469]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received 0e
Dec 25 14:06:40 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [10480]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:40 coffeesaur kernel: i8042.c: 29 <- i8042 (interrupt-kbd) [10480]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received 0e
Dec 25 14:06:40 coffeesaur kernel: i8042.c: 15 <- i8042 (interrupt-kbd) [10484]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received 35
Dec 25 14:06:40 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [10493]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:40 coffeesaur kernel: i8042.c: 15 <- i8042 (interrupt-kbd) [10493]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received 35
Dec 25 14:06:40 coffeesaur kernel: i8042.c: 3c <- i8042 (interrupt-kbd) [10513]
Dec 25 14:06:40 coffeesaur kernel: atkbd.c: Received 06
Dec 25 14:06:41 coffeesaur kernel: i8042.c: 43 <- i8042 (interrupt-kbd) [10524]
Dec 25 14:06:41 coffeesaur kernel: atkbd.c: Received 01
Dec 25 14:06:41 coffeesaur kernel: i8042.c: f0 <- i8042 (interrupt-kbd) [10530]
Dec 25 14:06:41 coffeesaur kernel: atkbd.c: Received f0
Dec 25 14:06:41 coffeesaur kernel: i8042.c: 3c <- i8042 (interrupt-kbd) [10530]
Dec 25 14:06:41 coffeesaur kernel: atkbd.c: Received 06

Re: Two questions about console utf8 support

[Tomohiro K. <tk...@ri...>]

Hi,

At Sat, 22 Dec 2001 21:50:31 -0800 (PST),
James Simmons wrote:

> > > http://linuxconsole.sourceforge.net
> 
> Hi folks. I'm that person that is rewriting the console system.

Interesting.  Though there were a few projects such as KON for
Japanese, HAN for Korean, and JFBTERM for ISO-2022-based i18n,
none of them has planed to be integrated into Linux source code.
(offtopic: the reason of this problem is sometimes that skilled
Japanese developers are sometimes not good at English language.)

I have one request, though I am not very familiar with this area.
You know, east Asian languages use thousands of characters and
we need conversion engine to input our languages.  For X Window
System, we have a standard protocol which is called XIM.  However,
there are no such standards for console.  Are your project
planning to supply some API or interface for this purpose?
East Asian people will be more happier if the API is standardized
and we can use same conversion engine for all of Linux, BSD, and
other UNIX-like systems.

---
Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/

Re: debugging the atkbd

[Vojtech P. <vo...@su...>]

On Mon, Dec 24, 2001 at 08:17:16AM +0800, Rogelio M. Serrano Jr. wrote:
> 
> 
> On Sun, 23 Dec 2001, Vojtech Pavlik wrote:
> 
> > On Thu, Dec 20, 2001 at 10:55:29PM +0800, Rogelio M. Serrano Jr. wrote:
> > 
> > > How should i fix the keyboard map? The keys are all mapped wrong. I cant
> > > use ruby on my home pc which is an ibm ps2. My keyboard keeps on being
> > > identified as a set 22 keyboad. I tried defining the debug macro in
> > > atkbd.c but still i dont get the message that tells me what the raw scan
> > > codes are. 
> > 
> > Set 22? That's really interesting. You can try using 'i8042_direct=1'
> > option to i8042.o (if you load it as a module, if not, pass it on the
> > kernel command line). Also, you can try #define I8042_DEBUG_IO in
> > i8042.h and #define ATKBD_DEBUG in atkbd.c and send me the logs of the
> > communication between the computer and the keyboard.
> > 
> > -- 
> > Vojtech Pavlik
> > SuSE Labs
> > 
> 
> I tried i8042_direct=1 and it worked. 

It looks like the 'untranslator' in i8042.c is for some reason failing
with your keyboard. It'll be interesting to find out why.

> I will try to rerun my old kerneland send you the logs. The keyboard is being 
> detected correctly now. I will try to go back and reproduce the bug.

If possible, enable the debug options before you do that.

-- 
Vojtech Pavlik
SuSE Labs

Re: debugging the atkbd

[Rogelio M. S. Jr. <ro...@vi...>]

On Sun, 23 Dec 2001, Vojtech Pavlik wrote:

> On Thu, Dec 20, 2001 at 10:55:29PM +0800, Rogelio M. Serrano Jr. wrote:
> 
> > How should i fix the keyboard map? The keys are all mapped wrong. I cant
> > use ruby on my home pc which is an ibm ps2. My keyboard keeps on being
> > identified as a set 22 keyboad. I tried defining the debug macro in
> > atkbd.c but still i dont get the message that tells me what the raw scan
> > codes are. 
> 
> Set 22? That's really interesting. You can try using 'i8042_direct=1'
> option to i8042.o (if you load it as a module, if not, pass it on the
> kernel command line). Also, you can try #define I8042_DEBUG_IO in
> i8042.h and #define ATKBD_DEBUG in atkbd.c and send me the logs of the
> communication between the computer and the keyboard.
> 
> -- 
> Vojtech Pavlik
> SuSE Labs
> 

I tried i8042_direct=1 and it worked. 

I will try to rerun my old kerneland send you the logs. The keyboard is being 
detected correctly now. I will try to go back and reproduce the bug.

Re: debugging the atkbd

[Vojtech P. <vo...@su...>]

On Thu, Dec 20, 2001 at 10:55:29PM +0800, Rogelio M. Serrano Jr. wrote:

> How should i fix the keyboard map? The keys are all mapped wrong. I cant
> use ruby on my home pc which is an ibm ps2. My keyboard keeps on being
> identified as a set 22 keyboad. I tried defining the debug macro in
> atkbd.c but still i dont get the message that tells me what the raw scan
> codes are. 

Set 22? That's really interesting. You can try using 'i8042_direct=1'
option to i8042.o (if you load it as a module, if not, pass it on the
kernel command line). Also, you can try #define I8042_DEBUG_IO in
i8042.h and #define ATKBD_DEBUG in atkbd.c and send me the logs of the
communication between the computer and the keyboard.

-- 
Vojtech Pavlik
SuSE Labs

Re: input patch

[Vojtech P. <vo...@su...>]

On Sun, Nov 25, 2001 at 02:30:46PM +0100, Johann Deneux wrote:
> On Fri, 16 Nov 2001, Johann Deneux wrote:
> 
> > Hello,
> > 
> > About the directory hierarchy, I decided to keep linus' hierarchy. Not
> > that this is a better choice, but it first appeared to me being easier
> > (fewer changes to makefiles). However, I think I will try to move to the
> > linuxconsole hierarchy in the next version.
> 
> I have been trying to do that, and encountered a problem. Making this
> input patch makes sense provided the console and input stuff are
> separable. Is that the case ? Right now, it looks to me there is a strong
> depedency: the keyboard depends on the vt, which depends on the console,
> which depends on the frame buffer.
> At the end, my input patch may more or less include the whole ruby/linux
> tree !!!

The only way the input subsystem depends on the VT is through the
keyboard.c file. However, if you use keybdev.c instead, you can keep
what's in the normal kernels. It's a hack, though not too a gross one.

-- 
Vojtech Pavlik
SuSE Labs

Re: debugging the atkbd

[Rogelio M. S. Jr. <ro...@vi...>]

On Sat, 22 Dec 2001, James Simmons wrote:

> 
> > How should i fix the keyboard map? The keys are all mapped wrong. I cant
> > use ruby on my home pc which is an ibm ps2. My keyboard keeps on being
> > identified as a set 22 keyboad. I tried defining the debug macro in
> > atkbd.c but still i dont get the message that tells me what the raw scan
> > codes are. 
> 
> Hm. This is a older machine? Tried the XT keyboard driver and let me know
> if that works. There is a ioctl in the input layer that allows you to
> change the mapping between raw codes to event codes but it has never been
> implemented. Sounds like it time to implement it.
> 
>    . ---
>    |o_o |
>    |:_/ |   Give Micro$oft the Bird!!!!
>   //   \ \  Use Linux!!!!
>  (|     | )
>  /'_   _/`\
>  ___)=(___/
> 
> 

Yes. It is an IBM PS/2 77s. My old olivetti keyboard only works with set 1
scancodes. I bought an IBM PS/2 keyboard that works on mode 2 but its
still the same. I am hacking at the keyboard code right now. Im beginning
to look at the i8042 code too. I will try to see if there is something
wrong with translation.

I will try setting i8042_direct to 1 so i could verify if there is a bug
in the i8042 driver. Im beginning to think this is a motherboard hardware
issue.   

I wonder if this keyboard works in mode 3. I will test that too.

Re: Serial design

[Russell K. - A. L. <li...@ar...>]

On Sat, Dec 22, 2001 at 09:37:09PM -0800, James Simmons wrote:
>    Hm. That depends on the hardware and/or hardware setup. For example on
> the iPAQ one serial port is used just for the touchscreen.

It's actually used for a microcontroller which handles the touchscreen and
many other things (like power management).

> The other for IR

Forget that port - the sa1100_ir driver is far superiour for driving it.

> and the first serial can be used for serial console/tty stuff or a
> stowaway keyboard. With the stowaway keyboard it sends a signal. So here
> we have smarter hardware. So fixed port are easy. 
>    The second class is using the bus like the PCI/PNP layer to find out
> what got attached. 

This sounds a somewhat Microsofty solution.  Do we really want the kernel
sending stuff like 'AT' commands at various baud rates to the connected
machine, which might be waiting for you to "press any key" after changing
the floppy?

>    Then we have the total dumb serial port. In this case if we can't
> figure if anything is attached or if something attaches and we don't know
> what it is then prehaps we should default to using the tty layer. Or
> better yet let the user load the right modules. 

Your only connection to the machine is over this serial port.  How do you
load the modules if you're not connected to the machine?

> Their is no difference. I based these ideas on what you have done. Your low 
> level setup is perfect from what I can see. Well except for touching 
> struct uart_info. I still need to figure a cheap way to send data from the
> low level to the user uart_driver level. Most likely I will add a rx_char
> and tx_char function to struct uart_driver.

I'd rather see a generic buffering layer between the serial low level and
upper levels (and do away with the tty flip buffers).  I think that will
separate it sufficiently.

Also, I don't see an easy way to get rid of uart_info from the low level
drivers - its used for many things, including maintaining correct locking
on SMP.

> Also maybe a shutdown or connect function?

Erm, don't we have 'startup' and 'shutdown' functions already?

> Well the higher data structures are a bit messer to deal with. We have:
> 
> struct uart_state;
> struct uart_info;
> struct uart_driver;
> 
> Every type of serial device would make use of struct uart_driver. Now
> struct uart_state and struct uart_info are heavly related to the TTY
> layer. So in the case of a TTY device was would have the void data field
> in struct uart_driver point to most likely struct uart_info.   

Uh oh, I really don't like this.  So we're going to have 'n' ports with
'n' struct uart_driver entries?  This sounds like needless bloat.

Please tell me you weren't seriously considering that!

Re: debugging the atkbd

[James S. <jsi...@tr...>]

> How should i fix the keyboard map? The keys are all mapped wrong. I cant
> use ruby on my home pc which is an ibm ps2. My keyboard keeps on being
> identified as a set 22 keyboad. I tried defining the debug macro in
> atkbd.c but still i dont get the message that tells me what the raw scan
> codes are. 

Hm. This is a older machine? Tried the XT keyboard driver and let me know
if that works. There is a ioctl in the input layer that allows you to
change the mapping between raw codes to event codes but it has never been
implemented. Sounds like it time to implement it.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Re: Two questions about console utf8 support

[James S. <jsi...@tr...>]

> > > > Someone is planning to rewrite the console subsystem for Linux 2.5.
> > > > That's definitely the time.
> > >
> > > Do you have the person's name or email? What is the platform number? Where
> > > can we jump in?
> >
> > http://linuxconsole.sourceforge.net

Hi folks. I'm that person that is rewriting the console system.

>   I'm wondering how this project will affect
> several attempts (in the past) to support large character sets (large
> compared to 256 or 512) in consoles. By this, I meant KON and  KON2
> for Japanese, HAN, HAN2 and fbcon-hanio (a  Korean patch to kernel
> framebuffer) for Korean and unicon (as included in Turbo Linux) and
> jfbterm for CJK.

Seen both. They unfortunely are hacks that break other things. I'm working
to find a better solution.

>   Another interesting piece of information was posted
> about a year ago to kernel-traffic (?) by an Indian student. Details are
> at http://kt.zork.net/kernel-traffic/kt20001218_98.html#7 The latter
> is an attempt to support writing systems in which the mapping between
> character codepoints and glyphs is not 1 : 1 but n : m. I believe this
> is relevant to not only various Indic, other South Asian and South East
> Asian scripts (all derived from Brahmi script) but also to Arabic, Hebrew,
> Korean Hangul and various Latin/Cyrillic/Greek alphabet-based scripts
> (when ligature is necessary.)

I seen that patch. It was very nice. Yes I like to see real multilingual
support on the console. I haven't got the chance yet to rework it.
Especially since it will require alot of work. Anyone want to to a stab at
it. There are a few nasty issues to work out tho.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Re: Serial design

[James S. <jsi...@tr...>]

> (Could you please ensure that your mails are wrapped at less than the
> 80th column please to save me the bother of doing this for you?)

Sorry. My mailer has troubles with placing text files in the body of a
email.

> On Tue, Dec 18, 2001 at 11:57:43AM -0800, James Simmons wrote:
> >    III. The final step is when a device is detected that we map it to a
> >	  specific port. For example if the bus detects a modem then it
> >	  would only make sense to map the struct uart_driver that
> >         represents the tty interface to the port that the modem wants
> >         to use.
> 
> Are you proposing here that any ports should not be attached to any drivers
> until something is detected on the other end?
> 
> If so, are you sure this is a good idea?  To give an instance, if I were
> to connect two machines together using the serial ports, both of which are
> running this serial driver, how would they know that they had been connected,
> and more imporantly that they shouldn't use a keyboard driver?

   Hm. That depends on the hardware and/or hardware setup. For example on
the iPAQ one serial port is used just for the touchscreen. The other for
IR and the first serial can be used for serial console/tty stuff or a
stowaway keyboard. With the stowaway keyboard it sends a signal. So here
we have smarter hardware. So fixed port are easy. 
   The second class is using the bus like the PCI/PNP layer to find out
what got attached. 
   Then we have the total dumb serial port. In this case if we can't
figure if anything is attached or if something attaches and we don't know
what it is then prehaps we should default to using the tty layer. Or
better yet let the user load the right modules. 

> > 2) The structures to represent the hardware and device interfaces. Now
> >    with the data we want to have data structs that define the hardware
> >    state and be able to change that state.
> 
> How is this different from what we already provide in the uart-based drivers?
> It appears that you've described the current setup in I and II rather well.

Their is no difference. I based these ideas on what you have done. Your low 
level setup is perfect from what I can see. Well except for touching 
struct uart_info. I still need to figure a cheap way to send data from the
low level to the user uart_driver level. Most likely I will add a rx_char
and tx_char function to struct uart_driver. Also maybe a shutdown or
connect function?
 
> >    III. struct uart_driver. The data here presents the device interface
> >         used to represent the hardware. This struct should be interface
> >	    independent. 
> >
> >	  A void field would be added to this struct which could be cast
> >	  in the higher device level. That data field would depend on the
> >	  device interface.  
> 
> Hmm, untyped data pointers.  Ewww.

Well the higher data structures are a bit messer to deal with. We have:

struct uart_state;
struct uart_info;
struct uart_driver;

Every type of serial device would make use of struct uart_driver. Now
struct uart_state and struct uart_info are heavly related to the TTY
layer. So in the case of a TTY device was would have the void data field
in struct uart_driver point to most likely struct uart_info.   

debugging the atkbd

[Rogelio M. S. Jr. <ro...@vi...>]

How should i fix the keyboard map? The keys are all mapped wrong. I cant
use ruby on my home pc which is an ibm ps2. My keyboard keeps on being
identified as a set 22 keyboad. I tried defining the debug macro in
atkbd.c but still i dont get the message that tells me what the raw scan
codes are. 

Re: Serial design

[Russell K. - A. L. <li...@ar...>]

(Could you please ensure that your mails are wrapped at less than the
80th column please to save me the bother of doing this for you?)

On Tue, Dec 18, 2001 at 11:57:43AM -0800, James Simmons wrote:
>    III. The final step is when a device is detected that we map it to a
>	  specific port. For example if the bus detects a modem then it
>	  would only make sense to map the struct uart_driver that
>         represents the tty interface to the port that the modem wants
>         to use.

Are you proposing here that any ports should not be attached to any drivers
until something is detected on the other end?

If so, are you sure this is a good idea?  To give an instance, if I were
to connect two machines together using the serial ports, both of which are
running this serial driver, how would they know that they had been connected,
and more imporantly that they shouldn't use a keyboard driver?

> 2) The structures to represent the hardware and device interfaces. Now
>    with the data we want to have data structs that define the hardware
>    state and be able to change that state.

How is this different from what we already provide in the uart-based drivers?
It appears that you've described the current setup in I and II rather well.

>    III. struct uart_driver. The data here presents the device interface
>         used to represent the hardware. This struct should be interface
>	  independent. 
>
>	  A void field would be added to this struct which could be cast
>	  in the higher device level. That data field would depend on the
>	  device interface.  

Hmm, untyped data pointers.  Ewww.

Serial design

[James S. <jsi...@tr...>]

Here you go Russell. This is what I have come up with so far for making
the serial layer work for both theinput layer and the tty layer.

	                   The new serial design

After much toying with the various ideas and Russell King's code I have formed 
the start of what to do. The basic idea is simple. To create a serial core where
we can register a device interface to a specific port. This gives use the power
to do things like have a serial console without a tty on port 1, input interface
on port 2, and a tty interface on port 3. Here are the ideas I have come up with
to deal with this. 

1) We need to break up what we setup. The primary this we want to do are: 

   I.   Register and setup hardware ports in a device independent way. The 
        function to do this is 

        int uart_register_port(struct uart_port *port);
 
   II.  The next step is to register the various device interfaces i.e tty, 
	input etc. This function sets up devfs, minor numbers etc. It has
        nothing to do with the hardware. 

        int uart_register_driver(struct uart_driver *uart);
	
   III. The final step is when a device is detected that we map it to a specific
	port. For example if the bus detects a modem then it would only make 
 	sense to map the struct uart_driver that represents the tty interface
 	to the port that the modem wants to use.

	int uart_register_device(struct uart_driver *reg,struct uart_port *port);

2) The structures to represent the hardware and device interfaces. Now with the
   data we want to have data structs that define the hardware state and be able
   to change that state. We also want to make those structs visible to the 
   higher level device interface layers. The second set of data is the device
   layer structs. We don't want them visible to the lower layers. Only the 
   specific device interface would have access to it. At present we have the
   following data structs:

   I.   struct uart_port. This struct represents a serial port. All the data in
	it defines the current hardware state. Both low level and device level
	use this data.

   II.  struct uart_ops. This structure describes all the operations that can be
        done on the physical hardware. It is apart of struct uart_port. 
   	 
   III. struct uart_driver. The data here presents the device interface used to
	represent the hardware. This struct should be interface independent. 
        A void field would be added to this struct which could be cast in the
	higher device level. That data field would depend on the device 
	interface.  
    
------------------------------------------------------------------------------

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

[PATCH] new fbdev api

[James S. <jsi...@tr...>]

Here is my patch for the new fbdev api coming up. It already has recieved
Geert's blessing. Please apply to 2.5.1. Thank you.

  .-.                               .-.
  oo|  Give Microsoft The Bird!!!!  oo|
 /`'\  Use Linux!!!                /`'\
(_;/)                            (_;/)
-----------------------------------------------------

--- linux-2.5.1/include/linux/fb.h	Wed Nov 28 16:43:10 2001
+++ linux/include/linux/fb.h	Thu Nov 29 11:02:26 2001
@@ -241,6 +241,39 @@
 	__u32 reserved[4];		/* reserved for future compatibility */
 };
 
+/* Internal HW accel */
+#define ROP_COPY 0
+#define ROP_XOR  1
+
+struct fb_copyarea {
+	__u32 sx;	/* screen-relative */
+	__u32 sy;
+	__u32 width;
+	__u32 height;
+	__u32 dx;
+	__u32 dy;
+};
+
+struct fb_fillrect {
+	__u32 dx;	/* screen-relative */
+	__u32 dy;
+	__u32 width;
+	__u32 height;
+	__u32 color;
+	__u32 rop;
+};
+
+struct fb_image {
+	__u32 width;	/* Size of image */
+	__u32 height;
+	__u16 dx;	/* Where to place image */
+	__u16 dy;
+	__u32 fg_color;	/* Only used when a mono bitmap */
+	__u32 bg_color;
+	__u8  depth;	/* Dpeth of the image */
+	char  *data;	/* Pointer to image data */
+};
+
 #ifdef __KERNEL__
 
 #if 1 /* to go away in 2.5.0 */
@@ -250,10 +283,10 @@
 #endif
 
 #include <linux/fs.h>
+#include <linux/poll.h>
 #include <linux/init.h>
 #include <linux/devfs_fs_kernel.h>
 
-
 struct fb_info;
 struct fb_info_gen;
 struct vm_area_struct;
@@ -283,9 +316,25 @@
     /* set colormap */
     int (*fb_set_cmap)(struct fb_cmap *cmap, int kspc, int con,
 		       struct fb_info *info);
-    /* pan display (optional) */
-    int (*fb_pan_display)(struct fb_var_screeninfo *var, int con,
-			  struct fb_info *info);
+    /* checks var and creates a par based on it */
+    int (*fb_check_var)(struct fb_var_screeninfo *var, struct fb_info *info);
+    /* set the video mode according to par */
+    int (*fb_set_par)(struct fb_info *info);
+    /* set color register */
+    int (*fb_setcolreg)(unsigned regno, unsigned red, unsigned green,
+                        unsigned blue, unsigned transp, struct fb_info *info);
+    /* blank display */
+    int (*fb_blank)(int blank, struct fb_info *info);
+    /* pan display */
+    int (*fb_pan_display)(struct fb_var_screeninfo *var, int con, struct fb_info *info);
+    /* draws a rectangle */
+    void (*fb_fillrect)(struct fb_info *p, struct fb_fillrect *rect); 
+    /* Copy data from area to another */
+    void (*fb_copyarea)(struct fb_info *p, struct fb_copyarea *region); 
+    /* Draws a image to the display */
+    void (*fb_imageblit)(struct fb_info *p, struct fb_image *image);
+    /* perform polling on fb device */
+    int (*fb_poll)(struct fb_info *info, poll_table *wait);
     /* perform fb specific ioctl (optional) */
     int (*fb_ioctl)(struct inode *inode, struct file *file, unsigned int cmd,
 		    unsigned long arg, int con, struct fb_info *info);
@@ -309,6 +358,7 @@
    char *screen_base;                   /* Virtual address */
    struct display *disp;		/* initial display variable */
    struct vc_data *display_fg;		/* Console visible on this display */
+   int currcon;				/* Current VC. */	
    char fontname[40];			/* default font name */
    devfs_handle_t devfs_handle;         /* Devfs handle for new name         */
    devfs_handle_t devfs_lhandle;        /* Devfs handle for compat. symlink  */
@@ -387,6 +437,9 @@
 			  struct fb_info *info);
 extern int fbgen_pan_display(struct fb_var_screeninfo *var, int con,
 			     struct fb_info *info);
+extern void cfb_fillrect(struct fb_info *p, struct fb_fillrect *rect); 
+extern void cfb_copyarea(struct fb_info *p, struct fb_copyarea *region); 
+extern void cfb_imageblit(struct fb_info *p, struct fb_image *image);
 
     /*
      *  Helper functions
@@ -400,6 +453,7 @@
 extern int fbgen_switch(int con, struct fb_info *info);
 extern void fbgen_blank(int blank, struct fb_info *info);
 
+extern void fbgen2_set_disp(int con, struct fb_info *info);
 
 /* drivers/video/fbmem.c */
 extern int register_framebuffer(struct fb_info *fb_info);

Re: make menuconfig dont work

[James S. <jsi...@tr...>]

> It is working again.

Great. Now to work on the serial layer this weekend.

Re: make menuconfig dont work

[Rogelio M. S. Jr. <ro...@vi...>]

It is working again.

On Thu, 13 Dec 2001, James Simmons wrote:

> 
> On Fri, 14 Dec 2001, Rogelio M. Serrano Jr. wrote:
> 
> > make menuconfig doesnt work after i updated to the latest ruby cvs.
> > I only get the alternate config menu items.
> 
> Fixed. Sorry, I didn't commit the fix until now. 
> 
>   .-.                               .-.
>   oo|  Give Microsoft The Bird!!!!  oo|
>  /`'\  Use Linux!!!                /`'\
> (_;/)                            (_;/)
> -----------------------------------------------------
> 

Re: make menuconfig dont work

[James S. <jsi...@tr...>]

On Fri, 14 Dec 2001, Rogelio M. Serrano Jr. wrote:

> make menuconfig doesnt work after i updated to the latest ruby cvs.
> I only get the alternate config menu items.

Fixed. Sorry, I didn't commit the fix until now. 

  .-.                               .-.
  oo|  Give Microsoft The Bird!!!!  oo|
 /`'\  Use Linux!!!                /`'\
(_;/)                            (_;/)
-----------------------------------------------------

make menuconfig dont work

[Rogelio M. S. Jr. <ro...@vi...>]

make menuconfig doesnt work after i updated to the latest ruby cvs.
I only get the alternate config menu items.

web site

[James S. <jsi...@tr...>]

Sorry folks by my miss use of tidy damaged the site. I placed the stuff
we have in CVS there again but some improvements have been lost. Sorry
about this.