Very Computer

Hello,

I have just purchased a cheap three button mouse made by Lynx.
The specific model number is LYNX-25S.  I cannot get the middle mouse
button to work in X windows.  Is there a protocol driver that exists
for this thing?  If not could anyone give me some hints at reverse-
engineering the protocol so I could write one?

Thanks.

Hi there,

Everytime I reboot my linux box the system date gets changed to some wild
value.  I thought that the kernel gleaned the date from the hardware clock.

I am using the 1.2.8 version kernel.  Could anyone help me out here.
--------
-dgaj

Hello all,

First to recap:

I have a 486dx33 linux box running version 1.2.8 of the kernel

I am trying to set up a sun 3/50 as a diskless xterminal using the Xkernel
package.

I have a NE2000 10baseT card in the Linux box and a 10baseT transceiver
connected to the aui port of the Sun.

When everything is connected link light on the transceiver and the what I am
assuming is  the link light on the NE2000 card both light up.  I am also
making the assumtion that these lights being on means that the cable is good.

When the sun boots I get the message:
  EEPROM: Using RS232 A port.

At this point I hit L1 A forcing the sun into monitor mode.

Then, I type b le(0) telling it to boot from over the ethernet.

I get the messages

   Boot: le(0,0,0)le
   Requesting Internet address for 8:0:20:1:A3:CE

And I get the funky little twirling '\' that sits there slowly twirling for all
eternity...

While this is going on I followed the advice on the people on this list and
I did a cat /proc/net/dev with the following results:
Inter-|   Receive                  |  Transmit
 face |packets errs drop fifo frame|packets errs drop fifo colls carrier
    lo:      0    0    0    0    0      529    0    0    0     0    0
  ppp0:     33    0    0    0    0       41    0    0    0     0    0
  ppp1:      0    0    0    0    0        0    0    0    0     0    0
  ppp2:      0    0    0    0    0        0    0    0    0     0    0
  ppp3:      0    0    0    0    0        0    0    0    0     0    0
   sl0:  58963    0    0 39918    0    85594    0    0 82593   215    0
   sl1:      0    0    0    0    0        0    0    0    0     0    0
   sl2:      0    0    0    0    0        0    0    0    0     0    0
   sl3:      0    0    0    0    0        0    0    0    0     0    0
  eth0:      0    0 13589    0 27178        0    0    0    0     0    0

Yeah, yeah I know my slip connection is up but the interesting thing I think is
eth0 which is the device name for the card.  I do not know what the drop
column is supposed to mean.  I also don't know what the fram column means.
One thing that I did notice was that the drop and frame stats would increase
every time I cat'ed /proc/net/dev.

I tried, again as suggested by people from the mailing list, to run tcpdump
to see if anything interesting was happening on the line.  I envoked tcpdump
in the following manner:

   tcpdump -i eth0

The results were:

   tcpdump: listening on eth0

And that was it.  When I did a CTRL-C I got this:

   0 packets received by filter
   0 packets dropped by kernel

Hmmm this does not sound good.

Does anyone out there have a clue as to what the problem is here?

One thing that maybe a clue is this.
After putting this card in the Linux box it ask you if you want to boot from
the network whenever the machine is rebooted now.  I noticed that the IRQ # and
address in this message are different than the IRQ and address found be
the autoprobe.  Is this a symptom of the problem?

Thanks a bunch for all the help so far and thanks in advance for your help
with this.

--------
-dgaj

check out time.doc in /zoneinfo. Mine is located in /usr/lib. This should
help you set the time and then sync it with the hardware clock.

|          \/    
| | |\| |_|/\  

No, the kernel doesn't; usually one of your rc files will use the 'clock'
command to read the cmos clock but there is no black kernel magic going on.

Also if you use the 'date' command to set the time, you must use
clock -w if you want to write that back into the cmos clock.

--