Linux-Misc Digest #123, Volume #26 Mon, 23 Oct 00 19:13:01 EDT
Contents:
Re: Absurd mouse behavior (Thomas Forlenza)
Re: Any problems with Red Hat 7? ("Steve Wolfe")
Copying an 7GB-partition to an 8GB-partition (Otto Wyss)
Re: Is there a MS Word (or substitute) for Linux? (Thomas Forlenza)
Re: Copying an 7GB-partition to an 8GB-partition (Jean-David Beyer)
Re: FOR ALL VOTERS - PLS READ (Steve Jorgensen)
Linux Penguin dxf or 3ds files? ("http://start.at/nevit")
Unresolved symbol printk while inserting prioprietary module (for wl2420) ("**
Bigins **")
Microimages MI/X Linux/NT Install ("Sylvan Katz")
Re: Where are the drivers to be put in a rescue diskette (Dances With Crows)
Re: error message on console (Dances With Crows)
----------------------------------------------------------------------------
From: Thomas Forlenza <[EMAIL PROTECTED]>
Subject: Re: Absurd mouse behavior
Date: Mon, 23 Oct 2000 21:13:32 GMT
==============4A41CAD6DBBB7E7820225FEC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tyler,
I would be curious to know some more details. Like, what mouse type are you
using, what options are being used with gpm, and how is you XF86Config setup for
your pointer device (assuming you are using Xfree86).
When you say normal terminal session, I am assuming that you are not running X at
all when the mouse fails to work (meaning that you are not running an xterm within
a GUI session).
With this being the case, let's try some tests. After the the mouse fails, try
the following;
>From a prompt type;
# ps -ef | grep gpm
gpm is the program that listens to the mouse device and moves the square block on
the screen. If it is not running, your mouse will not work in terminal mode.
This command will show if the process is running. It should produce something
like this;
[root@tfci /root]# ps -ef | grep gpm
root 690 1 0 Oct12 ? 00:01:19 gpm -t ps2
root 2981 2111 0 17:03 pts/0 00:00:00 grep gpm
If gpm is not running, then it may have crashed or was never started. If it
crashed, then it may be due to the wrong type (specified with the -t flag) being
used. Try to find out what type of mouse you are using and rerun gpm with the
correct type (this may be a trial and error process).
If it is running, then it could still be due to a wrong type specified for gpm.
When in terminal mode the mouse pointer should be a white square block that moves
across the screen. Look for it on the screen. Move the mouse and see if it shows
in a corner or something. Gpm reacts differently when using the wrong mouse type.
If you do see it, then try rerunning gpm with different mouse types.
If gpm is running and still no mouse activity, then next you can check the mouse
device directly;
from a prompt, use
# cat /dev/<mouse device>
where <mouse device> is the device name that your mouse is on. e.g. ttyS0, ttyS2,
mouse etc...
Then move your mouse. The cat command should produce some garbage looking output
- this shows that the device is working properly and that your software is not
working correctly.
If nothing was produced, then it may mean you serial device is failing (maybe
interrupts are not correctly set or something) - get the serial HOW-TO and see if
some information in there will help.
Note, you should be root when using these commands.
If still you can not get it going, then go to the HOW-TO documents, if you
installed them, they will be in /usr/doc/HOWTO.
The HOW-TO documents are usually very useful. You can also find them online.
Hope this helps,
Tpf
Tyler Larson wrote:
> Well, if it helps anybody to understand what's going on with my system,
> I think I've narrowed the mouse problem down to something in the software
> rather than a hardware problem.
>
> My justification is this: When i DO get my mouse to work, if I stay in
> an X session, the mouse will continue to function correctly indefinately.
> But if I switch to a 'normal' terminal session, I get the approx. 5 minute
> timeout (if you can call it that) where the mouse must be unplugged,
> unconfigured, and plugged in again (in the other serial port) and
> reconfigured to make it function.
>
> Am I missing something? What is the difference to the system whether or
> not I'm looking at a standard terminal or at an X windows session? Even
> when I'm running X windows in the background and I alt-F_ to a terminal to
> do something, if I stay there too long, my mouse won't function when I go
> back to X.
>
> I'm still stumped. Any opinions would be appreciated. Thanks.
>
> > I'm at a loss. If it were a hardware problem, linux should think that the
> > mouse is no longer connected and kudzu should try to remove the mouse from
> > the configuration *before* I physically disconnect the mouse. But if it's
> > a software problem, *at the very least* rebooting the machine should restart
> > whatever service is the offender and make the mouse work again. Or so, at
> > least, my rationale tells me.
>
> > Is there anyone that recognizes this bizzare behavior and can at least
> > tell where the problem lies?
>
> > Happy hacking.
>
> --
> -Tyler
==============4A41CAD6DBBB7E7820225FEC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Tyler,
<p>I would be curious to know some more details. Like, what mouse
type are you using, what options are being used with gpm, and how is you
XF86Config setup for your pointer device (assuming you are using Xfree86).
<p>When you say normal terminal session, I am assuming that you are not
running X at all when the mouse fails to work (meaning that you are not
running an xterm within a GUI session).
<p>With this being the case, let's try some tests. After the the
mouse fails, try the following;
<p>From a prompt type;
<br><b># ps -ef | grep gpm</b>
<br>gpm is the program that listens to the mouse device and moves the square
block on the screen. If it is not running, your mouse will not work
in terminal mode. This command will show if the process is running.
It should produce something like this;
<br>[root@tfci /root]# ps -ef | grep gpm
<br>root 690
1 0 Oct12 ? 00:01:19 gpm
-t ps2
<br>root 2981 2111 0 17:03
pts/0
00:00:00 grep gpm
<p>If gpm is not running, then it may have crashed or was never started.
If it crashed, then it may be due to the wrong type (specified with the
-t flag) being used. Try to find out what type of mouse you are using and
rerun gpm with the correct type (this may be a trial and error process).
<p>If it is running, then it could still be due to a wrong type specified
for gpm.
<br>When in terminal mode the mouse pointer should be a white square block
that moves across the screen. Look for it on the screen. Move the
mouse and see if it shows in a corner or something. Gpm reacts differently
when using the wrong mouse type.
<br>If you do see it, then try rerunning gpm with different mouse types.
<p>If gpm is running and still no mouse activity, then next you can check
the mouse device directly;
<br>from a prompt, use
<br><b># cat /dev/<mouse device></b>
<br>where <mouse device> is the device name that your mouse is on. e.g.
ttyS0, ttyS2, mouse etc...
<br>Then move your mouse. The cat command should produce some garbage
looking output - this shows that the device is working properly and that
your software is not working correctly.
<br>If nothing was produced, then it may mean you serial device is failing
(maybe interrupts are not correctly set or something) - get the serial
HOW-TO and see if some information in there will help.
<p>Note, you should be root when using these commands.
<p>If still you can not get it going, then go to the HOW-TO documents,
if you installed them, they will be in /usr/doc/HOWTO.
<br>The HOW-TO documents are usually very useful. You can also find
them online.
<p>Hope this helps,
<br>Tpf
<br>
<p>Tyler Larson wrote:
<blockquote TYPE=CITE>Well, if it helps anybody to understand what's going
on with my system,
<br>I think I've narrowed the mouse problem down to something in the software
<br>rather than a hardware problem.
<p>My justification is this: When i DO get my mouse to work, if I stay
in
<br>an X session, the mouse will continue to function correctly indefinately.
<br>But if I switch to a 'normal' terminal session, I get the approx. 5
minute
<br>timeout (if you can call it that) where the mouse must be unplugged,
<br>unconfigured, and plugged in again (in the other serial port) and
<br>reconfigured to make it function.
<p>Am I missing something? What is the difference to the system whether
or
<br>not I'm looking at a standard terminal or at an X windows session?
Even
<br>when I'm running X windows in the background and I alt-F_ to a terminal
to
<br>do something, if I stay there too long, my mouse won't function when
I go
<br>back to X.
<p>I'm still stumped. Any opinions would be appreciated. Thanks.
<p>> I'm at a loss. If it were a hardware problem, linux should think
that the
<br>> mouse is no longer connected and kudzu should try to remove the mouse
from
<br>> the configuration *before* I physically disconnect the mouse.
But if it's
<br>> a software problem, *at the very least* rebooting the machine should
restart
<br>> whatever service is the offender and make the mouse work again.
Or so, at
<br>> least, my rationale tells me.
<p>> Is there anyone that recognizes this bizzare behavior and can at least
<br>> tell where the problem lies?
<p>> Happy hacking.
<p>--
<br>-Tyler</blockquote>
</html>
==============4A41CAD6DBBB7E7820225FEC==
------------------------------
From: "Steve Wolfe" <[EMAIL PROTECTED]>
Subject: Re: Any problems with Red Hat 7?
Date: Mon, 23 Oct 2000 15:07:07 -0600
> Im just thinking about getting it, I currently have Storm 2000.
As long as you don't mind not being able to recompile the kernel, not
being able to have your system up for more than three weeks, or things like
that, it's not bad. ; )
To RedHat's credit, there are patches for both of those issues, I believe.
But the release has widely been regarded as the most buggy release in
RedHat's history.
steve
------------------------------
From: [EMAIL PROTECTED] (Otto Wyss)
Subject: Copying an 7GB-partition to an 8GB-partition
Date: Mon, 23 Oct 2000 23:24:23 +0200
I'd like to copy/moving anything on a 7GB-partition to an 8GB-partition.
What's the best way to do it?
O. Wyss
------------------------------
From: Thomas Forlenza <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Is there a MS Word (or substitute) for Linux?
Date: Mon, 23 Oct 2000 21:39:19 GMT
Actually, I know many Attorneys (not that anyone cares) who use Word
Perfect. It is largely used in the legal circuit. So, now that Claire's
world theory is false, we can not trust much of anything else she say's.
You can however get Word Perfect for Linux - it works fairly well (just save
often). I use StarOffice and produce some good documents with it. I am not
sure about Applixware, but it got decent reviews in Maximum Linux.
[EMAIL PROTECTED] wrote:
> Tell that to your boss when you hand in your report and it looks like
> crap, all because you used Linux and he, along with the rest of the
> world, is using Word.
>
> Maybe Linus will give you a job at Transmeta.
>
> claire
>
> On Sun, 15 Oct 2000 22:52:57 GMT, [EMAIL PROTECTED] (Hal Burgiss) wrote:
>
> >On Sun, 15 Oct 2000 22:47:56 GMT, [EMAIL PROTECTED]
> ><[EMAIL PROTECTED]> wrote:
> >
> >>It sucks and is even more bloated than MSOffice.
> >
> >Yea, but at least it doesn't have that funny smell about it, and infect
> >itself into every nook and cranny it can.
> >
> >--
> >Hal B
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
------------------------------
From: Jean-David Beyer <[EMAIL PROTECTED]>
Subject: Re: Copying an 7GB-partition to an 8GB-partition
Date: Mon, 23 Oct 2000 17:51:31 -0400
Otto Wyss wrote:
> I'd like to copy/moving anything on a 7GB-partition to an 8GB-partition.
> What's the best way to do it?
>
> O. Wyss
Something like
find FromDirectory -print | cpio -p ToDirectory.
Reading the man page of find and cpio will do it for you.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ Registered Machine 73926.
/( )\ Shrewsbury, New Jersey
^^-^^ 5:45pm up 13 days, 23:22, 2 users, load average: 3.22, 3.18, 2.93
------------------------------
From: [EMAIL PROTECTED] (Steve Jorgensen)
Crossposted-To: comp.os.linux.networking,comp.unix.admin
Subject: Re: FOR ALL VOTERS - PLS READ
Date: Mon, 23 Oct 2000 21:52:17 GMT
On Mon, 23 Oct 2000 04:38:15 GMT, [EMAIL PROTECTED] (Hal Burgiss) wrote:
>On 20 Oct 2000 09:32:32 -0000, Private User <See.Comment.Header@[127.1]> wrote:
>
>>Just think of what he could do for the country if he were president!
>>
>>John R. Finnegan Jr., Ph.D.
>>Professor and Associate Dean For Academic Affairs
>>School of Public Health, University of Minnesota
>
>OK, because of this obnoxious off topic post, I now vote for Bush just
>to spite your clueless, self righteous ass. If that's really who you are
>since you don't give an email address and hide behind a remailer. At
>least Bush supporters aren't spamming Linux newsgroups.
>
>--
>Hal B
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>--
Actually, they probably are. Everyone else is.
------------------------------
Date: Tue, 24 Oct 2000 01:18:52 +0300
From: "http://start.at/nevit" <[EMAIL PROTECTED]>
Subject: Linux Penguin dxf or 3ds files?
I am looking for "Linux Penguin Models", dxf or 3ds files... Other 3d formats
might be acceptable. Please inform me if you know a url... You can also send me
the file directly if it is under 800K.
Nevit
--
ME? not 4 me!
http://geocities.com/nevilo
------------------------------
From: "** Bigins **" <[EMAIL PROTECTED]>
Subject: Unresolved symbol printk while inserting prioprietary module (for wl2420)
Date: Tue, 24 Oct 2000 00:18:03 +0200
I compiled the module from sources
(www.eumitcom.com/download/2-linux226.zip).
When I tried to insert the module to the kernel I get 'unresolved symbol
printk'.
I tried with pcmcia modules 3.0.8.
I did my modifications at this drivers like moving ldouble definitions of
functions which prevented the module from kompiling at all. Now the module
compiles correctly but doesn't want to insert the module to insert itself in
the kernet cous of the lack of the 'printk' function in the moduke.
It is strange bycous other modules like pcmcia_core.o, ds.o and 83592.o also
use this sybol and do not have any problems with it and they are inserting
itselves with insmod without any problems.
Please respond also by email to: [EMAIL PROTECTED] and [EMAIL PROTECTED]
Pawel Bigosinski
[EMAIL PROTECTED]
------------------------------
From: "Sylvan Katz" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.questions,comp.windows.x.i386unix
Subject: Microimages MI/X Linux/NT Install
Date: Mon, 23 Oct 2000 22:21:14 GMT
I was considering using the Microimages MI/X product as an X server on my NT
machine to provide X windows access to my RedHat Linux 6.2 box until the
Cygwin keyboard interface is more stable. However, I ran into a problem with
the MI/X product installing properly under NT 4.0 service pack 6.0. Now I
can not seem to be able to get rid of it using NT control panel ->
add/remove.
Has anyone else encountered a similar or other problems with the MicroImages
MI/X product?
--
Sylvan Katz
Saskatoon, Sask
------------------------------
From: [EMAIL PROTECTED] (Dances With Crows)
Crossposted-To: comp.os.linux.setup
Subject: Re: Where are the drivers to be put in a rescue diskette
Date: 23 Oct 2000 23:05:32 GMT
Reply-To: [EMAIL PROTECTED]
[nonexistent NG ";" snipped]
On Mon, 23 Oct 2000 09:08:20 GMT, Ezio PAGLIA wrote:
>I backuped my Linux system onto a tape that obviously my RH6.2 treats
>very well. I made a rescue diskette with the compressed kernel and a
>numer of utilitities. Everythig would go quite well, but how can you
>make the booted system understand the presence of a tape on /dev/st0
>after the boot from diskette ? Adding /dev/st0 to the diskette and
>making the correct mknod is not enough. Where are the drivers to be
>installed in the rescue diskette ? I apologize for my intrusion and
>incompetence. Thank you in any case.
No problem. Your rescue diskette should contain a kernel with support
for your specific SCSI card, SCSI support, and SCSI tape support either
directly in the kernel, or available as modules. Obviously, your main
system contains these things as you were able to make a tape. What you
need to do is either compile a custom kernel with these things built in
directly, or make these modules available to your rescue system.
Copying /lib/modules/2.2.X/scsi/ to your rescue system's
/lib/modules/2.2.X/scsi/ may work. Actually, I'd build a custom kernel
for your rescue system; it's a great learning experience if you've never
done it before. HTH,
--
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin / Workin' in a code mine, hittin' Ctrl-Alt
http://www.brainbench.com / Workin' in a code mine, whoops!
=============================/ I hit a seg fault....
------------------------------
From: [EMAIL PROTECTED] (Dances With Crows)
Subject: Re: error message on console
Date: 23 Oct 2000 23:05:34 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 23 Oct 2000 14:25:03 +0800, Hello World wrote:
>eth1: transmit timed out, tx_status 00 status e601
>eth1: Interrupt posted but not delivered -- IRQ blocked by another device?
>is it a irq conflict? i have 3 3c905c in a redhat 6.2 box.
3 905's, eh? Well, if you posted the output of "cat /proc/interrupts",
that might help in determining whether the cards are stepping on each
others' toes. However, PCI cards can share interrupts amongst
themselves... it's when they try to share them with ISA devices or
built-in devices that problems arise.
Which driver are you using for the cards? "lsmod" should return "3c59x"
or "3c90x". If you're using 3c90x, try using 3c59x, as I've never had
anything but grief trying to use 3c90x. The place you need to change is
in /etc/modules.conf ; alias eth0 3c59x and do the same for eth1 and
eth2. If you're having these problems and you're using 3c59x, use
3c90x.
Finally, if all 3 cards are running at full speed and 2 or more of them
are sharing an IRQ, you most likely will have problems since when the
shared IRQ is triggered, the drivers must spend a little extra time
figuring out which card the IRQ belongs to. This is usually not
significant, but having fast devices like UW-SCSI cards and 100M
Ethernet cards share the same IRQ can result in dropped packets when
both devices are running at full speed.
--
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin / Workin' in a code mine, hittin' Ctrl-Alt
http://www.brainbench.com / Workin' in a code mine, whoops!
=============================/ I hit a seg fault....
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.misc) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Misc Digest
******************************
