What?...so Pork E & myself are the only ones with reticent mice? :)
Thanx for replies thus far...and in response;
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
...that's usual ...no? As I have described the trouble, even *I* thought
it was something like a mad scramble for interrupts by the 2 serial ports,
so I even went to the extreme of reinstalling the system to scsi (freeing
irq 14, 15), and using setserial to bounce it over all the IRQ's I had.
Made no especial dfference (as others have noted ;) Just so you know,
here's what I've done thus far...
1>tried setserial on available IRQs
2>turned off on board IDE to free irq 14,15 (as above) for more choices (;
3>turned off on board serial I/O ports and jammed a serial card in-slot
and did 1>, & 2> above like that...to no avail (nb; said serial card works
fine on my other machines)
4>experimented, removed, added components (soft) to address it (or try),
including a week where I reinstalled rhl-5 maybe 30,000 times to a couple
of spare harddrives...using the same motherboard....no joy..
5>tried kernels from 2.0.31-->2.1.91 (not so much to kill the mouse
problem, but noted that it didn't matter anyhow ;)
6>built this device that runs off the parallel port, hooked to a old
stepper-motor, and driven by software to push the mouse a little this way
& that every minute or so..(not really, you understand, but the idea of
'starting a big download to happen overnight whilst one sleeps' is an
absolute FOLLY here.... :)
It's actually a little worse than that. My isp's system will (as per
normal) drop the link if it detects inactivity on the hosts' end after a
period of 'x' minutes (I think it's 15). To offset this (as usual), I do a
icmp ping of my gw machine with >ping -i 5 <my_gw_addr> because as sure
as dammit (and in a general sense here also), any download will stall TO
DEATH if this mouse thing pops up. A ping frequency >10secs is more likely
to stop as well, rather than -i 5. Downloads terminate with error messages
tantamount to the same thing, but in different words...netscape sez it's a
network error, and the host is either uncontactable or down...blablabla.,
mc will chirp connection closed by foreign host or whatever..shell line
similar. The subject of PS/2 rodents has raised...mine is (at present) an
old ms compat thing..plugged into the onboard I/O of a VX chipset.
The sheer inconsistancy of the thing is what really behooves me. It can
happen within the space of time of issuing my ppp connect line, and the
actual time needed from that point, to to auth/establish the ppp link.
This is terminal (<-sick, unintentional pun ;), because it bollocks the
pppd negotiation somehow...the routing table in the kernel goes wakko. The
times I caught this,...uh-oh...quickly move the mouse and do something
like >netstat -r ...nothing comes up, but it's a surefire way to hangup
the modem. Strange...if I do nothing at all in this instance, the modem
will stay up, but the link's as dead as a tack.
Obviously, I've had some time with a few versions of pppd here, so I
doubt it's that either. Personally speaking, I think it's time to lash
this motherboard to a tree limb and see how it stands up to a few rounds
of hot lead....I was more approaching the list to see if there was any
*software* issue involved here I may have overlooked.
Perhaps the point of ?why I so surely suspect the mainboard, stands
point of mention here to save others this frustration..and perhaps others
beyond that as well...(I'm new here, so forgive me or tell me so if I
prattle too much). How many folks here hit that damn sig_11 thang with the
released gcc-2.7.2.3-8?? Every reference to this pointed to either a Cyrix
cpu, or bad ram/cacheram/any other bit of hardware. I live in Qld, .au,
and as such this might be local...my cpu is clearly marked as being an
intel p166, but when I compiled 2.1.90...this line sprang to notice in
dmesg;
CPU0: Cyrix 6x86 2x Core/Bus Clock stepping 17
and immediately I knew why gcc-2.7.2.3-9 works too. It's not just my box
though, but a number of friends machines as well. I now carry a zip drive
and adaptec152x (which, for those interested, does *not* auto-detect under
install or normal boot..I append it to my /etc/lilo.conf), and a cart with
the relevant rpms on it.
Since seeing this description of the cpu, I've gone to a lot of bother
running over the installation with SOURCE rpms where-ever possible. This
has in fact helped the rest of the niggling things (not all), but then I
haven't finished them all yet either...
Video cards..this is another idea. I *was* using a 2Mb legend with
ark2000MT/ics5342, but kept hitting limits with respect of vidram. I liked
enlightenment a lot (being amigan, you would ;)..but it was dogslow, so I
settled on KDE. It too did weird things..but tolerable. I (ahem) updated
to a blaster3D/cl gd5464 thinking this might help, but it turned KDE into
a kiddy paint sortta idea, where you could draw patterns on the screen by
dragging windows about. I tried beta3, and the wicked thing destroyed my
swap partition :) No big prob, but strange behaviour.
The auto blank...you know, the screen goes black...no way, not with this
card. When that happens, the 'blank' screen will be vertically banded
lines, intermittent with black....and they might be the background colour
of what ever window manager, or whatever in between..sometimes, even
black! (goodgrief) It seems like the card itself is doing this...?? I have
to go xset s off to stop this rubbish..handy.
Most all boards have a traceable BIOS number. This one traces to the no
longer existant IwanaCheapVX company, taiwan somewhere...pffft! I had a
humungous loosing battle with 3 pnp cards, isapnptools and the bios. It
was like a game of catch me if you can...I've never seen such stupidity in
my life..the moment I tried to lock an address, it'd move..weird. I figure
this has something to do with the fact that if I don't power up/down with
the reset firmly depressed, the bios will loose it's presets (irrespective
of the fact it's set *not* to do this and the battery is good..works fine
with the reset?)
It comes complete with a 'white_man_magic' cacheram-stick. I've checked
it out...got a wire to a staked-earth outside (for the HF recv), earthed
myself and everything else in sight with it, and just *touch* the cacheram
with my ceramic coreadj stick...booomooo, one big mama of a kernel dump.
Mechanical??..not enough of a touch to move it..you can beat the living
daylights out of the case while it's running and it won't bother it.
Moral of the story? DO NOT appraise a motherboard worthy to run your
linux installation just because it can run win95/nt4 without any of this
carryon. It seems also unlikely that in australia at least (there's a big
deal on this at present in the newsmedia here), one cannot believe the
facts as the eyes see it...clearly, my cpu is remarked..if I run it at
it's (label) rated 166Mhz..twang...nothing works, coredump galore. 133Mhz
is it's limit...(I've since discovered it's a P150??)
But then, if someone else has this trouble, there must be *some* common
element?
Why is so much of what I see, based on spheres?? db
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
