Linux-Development-Sys Digest #452, Volume #6 Thu, 4 Mar 99 11:14:08 EST
Contents:
Re: RedHat install crashes -- "buggy cmd640b" error ("Thomas T. Veldhouse")
Re: glibc-2.1 install problems ("Thomas T. Veldhouse")
Re: Getting access thru Telnet (Mark Tranchant)
egcs points to wrong lib ("asdf")
Re: ethernet dec21143 problems ("Thomas T. Veldhouse")
Re: how can i change the video mode in c++ (Peter Morris)
Re: SMP Support (Andrew D Lenharth)
Re: waiting for milliseconds? ("Zefram Cochrane")
Problem loading modules with kernel 2.2.2 and modutils 2.1.121 (Mark Sutton)
Re: waiting for milliseconds? (Nix)
Re: Problem loading modules with kernel 2.2.2 and modutils 2.1.121 (Walter Hunt)
autofs and mklinux on a ppc (David T. Blake)
Re: waiting for milliseconds? ([EMAIL PROTECTED])
Re: how can i change the video mode in c++ (Nix)
patching kernel (2.2.2) help (Anonymous)
Re: Any Insure++ Users? (James Youngman)
----------------------------------------------------------------------------
From: "Thomas T. Veldhouse" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.setup
Subject: Re: RedHat install crashes -- "buggy cmd640b" error
Date: Wed, 3 Mar 1999 13:56:24 -0600
If you look below, this Kernel WAS configured to work around the CMD640 bug.
The problem appears to be with whatever it is trying to access AFTER drive 1
(cmd). I have an old Pentium 100 with the same bug, but the install works
OK (different Kernel though). RedHat used a patched 2.0.35 kernel (or
pre-36) kernel for their installer (must be bleeding edge you know) and I
think it just came back and bit them in the arse. Anyway, I am willing to
bet it is a bug in the kernel code and not a hardware issue. Have your
tried installing either an old version of RedHat or another distribution
that will use more tested code (i.e. Slackware)?
Tom Veldhouse
[EMAIL PROTECTED]
Patrick Mueller wrote in message <[EMAIL PROTECTED]>...
>ide0: buggy cmd640b interface on PCI(type 2) config=0x3e
>ide1: not serialized, secondary interface not responding
>cmd640: drive 0 timings/prefetch(on) preserved, clocks=2/3/3
>cmd640: drive 1 timings/prefetch(on) preserved, clocks=4/16/17
>divide error: 0000
>
>CPU: 0
>EIP: 0010:[<0016f2d5>]
>EFLAGS: 0010246
>
><dump of the registers>
>
>Code: f7 74 24 0c 89 c1 66 89 4b 20 8b 7e 78 80 4b 0c 40 0f b6 43
>
>
>I am checking w/ PBell, to see if there is a BIOS upgrade I can get to see
if
>that will help, but I am not confident that they offer much support
(especially
>for a relatively old box like this P60).
>
>Thanks again!! (Also, please cc: [EMAIL PROTECTED] because my news
reader is
>a pain to use).
>
> -- Patrick
------------------------------
From: "Thomas T. Veldhouse" <[EMAIL PROTECTED]>
Subject: Re: glibc-2.1 install problems
Date: Wed, 3 Mar 1999 14:01:53 -0600
I had this same problem. It only happens when you are upgrading from libc5.
You can't compile a test program, because the install did not finish. This
is definitely a bug in "make install" in glibc-2.1.
I compiled from source and removed the old /usr/include directory before
install and that did not help in the least.
Tom Veldhouse
[EMAIL PROTECTED]
Andreas Jaeger wrote in message ...
>>>>>> asdf writes:
>
> > Can someone help me out? I get the following error when installing the
> > already compiled library:
>
> > In file included from /usr/include/stdio.h:57,
> > from /tmp/test-prg12996.c:2:
> > /usr/include/libio.h:335: parse error before `_IO_seekoff'
> > /usr/include/libio.h:335: parse error before `_G_off64_t'
> > /usr/include/libio.h:336: parse error before `_IO_seekpos'
> > /usr/include/libio.h:336: parse error before `_G_fpos64_t'
> > Execution of gcc failed!
>
> > I've read the FAQ and the README.
>You've got the wrong _G_config.h file in your include path. Compile a
>simple hello world program with gcc -E and check from where
>_G_config.h is taken - and remove that one. The right _G_config.h
>version lifes in /usr/include and comes with glibc 2.1.
>
>Andreas
>--
> Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
> for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: Mark Tranchant <[EMAIL PROTECTED]>
Subject: Re: Getting access thru Telnet
Date: Thu, 04 Mar 1999 08:44:24 +0000
Reply-To: [EMAIL PROTECTED]
Look at /etc/securetty. I've recompiled kernels and rebooted remotely.
It's most excellent having the telnet connection go down and then be
available again a minute later with a new kernel...
Mark.
Kevin Miller wrote:
>
> Hi everyone,
>
> I know that this is a simple question but I do need help. Can you gain
> full access thru Telnet and have the same power as a superuser from that
> type of connection? If so, can you please guide me on setting it up.
>
> I can get the account to gain full access right on the server but not
> thru Telnet.
>
> Also, why cant I login as root from telnet?
>
> Thanks!!!
>
> Kevin
------------------------------
Reply-To: "asdf" <[EMAIL PROTECTED]>
From: "asdf" <[EMAIL PROTECTED]>
Subject: egcs points to wrong lib
Date: Wed, 3 Mar 1999 17:42:33 -0800
I have Slackware 3.5 with libc5, I upgraded the libs to glibc-2.0.6. Then I
installed glibc-2.1, moving the 2.0.6 libs to /usr/i686-linux/lib and adding
it to ld.so.conf. The 2.1 was built with the host being "i686-pc-linux-gnu,"
I also built egcs-1.1.1 with the same host as glibc-2.1. When I run
configure, to compile something, it tell me I have a "i686-linux" system
when in fact it should be "i686-pc-linux-gnu." Since I kind of messed up and
then fixed the installations of the 2 glibc's I don't know if the programs
compiled on my system will be glibc-2.1 based, because they point to the
libs in /usr/i686-linux/lib (and those libs are links to libc5), I remove
most of the 2.0.6 libs.
Here is what (unsure of what libs is being used) problems looks like:
$ ldd somefile
libc.so.6 -> /usr/i686-linux/lib/libc.so.6
$ ls -l /usr/i686-linux/lib/libc.so.6
/usr/i686-linux/lib/libc.so.6 -> libc.so.5
$ rm /usr/i686-linux/lib/libc.so.6
$ ldd somefile
libc.so.6 -> /lib/libc.so.6
$ ls -l /lib/libc.so.6
/lib/libc.so.6 -> libc.2.1 (or something)
------------------------------
From: "Thomas T. Veldhouse" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: Re: ethernet dec21143 problems
Date: Wed, 3 Mar 1999 14:04:49 -0600
Why can't you use the tulip module?
/sbin/modprobe tulip
I have a DEC21141 compatible card and have no problem with either module,
tulip or de4x5x. tulip performs much better though.
Edit you /etc/rc.d/rc.modules file and uncomment the location where the
tulip driver is loaded and make sure you find tulip.o under
/lib/modules/2.0.36/net/ (or whatever kernel version you have).
Good luck!.
Tom Veldhouse
[EMAIL PROTECTED]
asdf wrote in message ...
>I'm having problems in getting my network card to work. Red Hat 5.0
detects
>it as a "tulip," though I never actually tried to get to work on RH. In
>Slackware, I can't insert the tulip module, and the de4x5 will insert but I
>get an "uninitialized" message with "lsmod." How can I get my card
>initialized. It's a built-in card, it's supposed to be DEC21143 based.
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Peter Morris)
Subject: Re: how can i change the video mode in c++
Date: Wed, 3 Mar 1999 12:26:11 -0500
Reply-To: [EMAIL PROTECTED]
On 27 Feb 1999 00:47:16 +0100, davide morelli <[EMAIL PROTECTED]> wrote:
>under windows'95
>
>davide,
>[EMAIL PROTECTED]
Beats me. I also don't know why in hell you posted this question to a Linux
newsgroup.
------------------------------
From: Andrew D Lenharth <[EMAIL PROTECTED]>
Subject: Re: SMP Support
Date: Wed, 3 Mar 1999 19:47:00 GMT
It seems likely that more tasks that processors does present an
improvement (as long as the number of tasks is not to big). My logic is
thus: When a process reads a file or otherwise causes disk access,
another task is switched to while the read or write occurs. So having one
or two more tasks than processors should help some.
Andrew
Remember, never ask a geek "why";
just nod your head and back away slowly...
On 2 Mar 1999, Johan Kullstam wrote:
> [EMAIL PROTECTED] (Adam P. Jenkins) writes:
>
> > There is no point in running more parallel make processes than the
> > number of processors you have, so unless you really have 8 processors,
> > you'd actually be better off running less. It actually slows things
> > down to have so many processes contending for access to resources such
> > as the disk. On a two processor system I found that running make -j 2
> > nearly halved kernel compile-time, but increasing it beyond that
> > didn't help at all.
>
> and i found that make -j 3 shaved about 1/3 of the time of compiles on
> my uniprocessor. go figure.
>
> --
> J o h a n K u l l s t a m
> [[EMAIL PROTECTED]]
> Don't Fear the Penguin!
>
>
------------------------------
From: "Zefram Cochrane" <[EMAIL PROTECTED]>
Subject: Re: waiting for milliseconds?
Date: Tue, 2 Mar 1999 16:19:22 -0000
Thijs Cobben wrote in message <01be64b7$44ee1900$[EMAIL PROTECTED]>...
>Am i blundering here, or can you just use sleep(0.001); ? Should work
>fine...
sleep takes a *float* argument ?
On slower systems, the parameter passing would take longer than the wanted
delay !
I thought about this sort of thing a few weeks ago: why would anyone want
to "wait" for something of the order of "milliseconds". *micro*seconds
I could understand, and *seconds* I could understand.
.. but the whole point of waiting is that it has to be "just long enough
for a human to notice", or "just long enough for the hardware to notice".
Very little hardware takes a predictable millisecond-time to respond. If
it does, then it's probably as a result of waiting on some status line or
whatever.
P{ease could the original poster clarify why they want to wait for this
timescale ?
If I had need to wait for milliseconds, doing it with a spinner would waste
too much CPU bandwidth, and doing it schedulingly, would be too much of an
overhead. In short, it's one of those no-persuns' land that a computer
"can't
do". IMHO, this sort of thing should be done in hardware.
------------------------------
From: Mark Sutton <[EMAIL PROTECTED]>
Subject: Problem loading modules with kernel 2.2.2 and modutils 2.1.121
Date: Wed, 03 Mar 1999 20:18:52 +0000
Howdy,
I am having a problem loading modules on a system that I have attempted
to upgrade to kernel 2.2.2, here's the details:
1) I installed Red-Hat 5.2 on a virgin machine (totally blank harddrive).
Machine is a P-II 450 BX chipset, DEC Tulip NIC, Matrox Millenium G200.
2) I upgraded Xfree to 3.3.3 so I could use the G200.
3) I upgraded the kernel, and all relevant packages using the instructions
at http://www.redhat.com/support/docs/rhl/kernel-2.2/kernel2.2-upgrade.html.
4) The new kernel 2.2.2 compiled and ran fine. (Except for the problem
detailed below.)
5) I also verified that all the packages mentioned in the document at:
http://www-stu.calvin.edu/~clug/users/jnieho38/goto22.html
were the same or newer versions than that document said were required.
6) In particular, I have checked about 200 times that my modutils
version is 2.1.121 since it is loading modules that I am having problems
with.
Here is the problem:
When I try to load any modular driver, either with kerneld, or
manually using insmod, the following error is produced:
insmod: error in loading shared libraries
: undefined symbol: __bzero.
I've grep'ed and searched through the code of the drivers I've been
trying to load as modules as well as the code to any libraries
I thought were relevant and can't find the string "bzero" anywhere
in them.
This happens for drivers that are part of the standard kernel
and compiled as modules via "make modules", as well as add-on
drivers that don't come with the kernel and are compiled as modules.
(I am the author/maintainer of two such drivers, the Matrox Meteor
driver, and the SST SS-5136-DN devicenet driver, and a big priority
right now is to get these suckers tested with 2.2.x series kernels to
make sure they didn't break in the transition.) Not to mention that it
is seldom desirable to compile every driver you may ever need into
the kernel image!
Anyone see this before?
I assume I need to upgrade some library or something.
What did I miss?
--
========================================================================
| Mark Sutton | mailto:[EMAIL PROTECTED] |
| The Laitram Corporation | http://www.laitram.com/ |
| New Orleans, Louisiana | http://www.gnofn.org/~marksu/ |
| Opinions expressed do not necessarily reflect those of Laitram Corp.|
========================================================================
------------------------------
From: Nix <$}xin{[email protected]>
Subject: Re: waiting for milliseconds?
Date: 03 Mar 1999 19:50:35 +0000
"Zefram Cochrane" <[EMAIL PROTECTED]> writes:
> Very little hardware takes a predictable millisecond-time to respond.
Network cards (roundtrip lag time on an unsaturated 10 (or 100) Mbps LAN)
And, er, good old magnetic core storage ;)
--
`Be pedantic in what you accept and arbitrarily brutal in what you
send.' --- Malcolm Ray describes the roBOFHness principle
------------------------------
From: [EMAIL PROTECTED] (Walter Hunt)
Subject: Re: Problem loading modules with kernel 2.2.2 and modutils 2.1.121
Date: 3 Mar 1999 21:15:22 GMT
In article <[EMAIL PROTECTED]>,
Mark Sutton <[EMAIL PROTECTED]> writes:
> Howdy,
>
> I am having a problem loading modules on a system that I have attempted
> to upgrade to kernel 2.2.2, here's the details:
>
[snip]
> 3) I upgraded the kernel, and all relevant packages using the instructions
> at http://www.redhat.com/support/docs/rhl/kernel-2.2/kernel2.2-upgrade.html.
[snip]
> Here is the problem:
>
> When I try to load any modular driver, either with kerneld, or
> manually using insmod, the following error is produced:
>
> insmod: error in loading shared libraries
> : undefined symbol: __bzero.
>
[snip]
> Anyone see this before?
Yup. Annoying as crap, isn't it. Happened the same way to me.
The problem seems to be that the modutils that you (and I :) grabbed to
update to the latest version were built with some strange compiler version
which doesn't get along with your system. I'm guessing that you grabbed
the latest one you found on the rpmfind web site, built by BlueSky Dist.,
or something like that.
You should find those messages going away if you grab a different version,
say from RedHat Manhatten or something.
The *only* ones I've had problems with were the .rpms from BlueSky.
If you didn't upgrade using .rpms, I'd assume something was hosed with
your compiler setup that you used to compile the packages.
>
> I assume I need to upgrade some library or something.
modutils should be enough (unless you start seeing messages from other
stuff - I had to replace net-tools also).
>
> What did I miss?
Not much. Finding this one was a severe pain.
--
Walter Hunt
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: autofs and mklinux on a ppc
Date: 03 Mar 1999 13:21:09 -0800
Hello,
I have a PPC 7100 (no PCI slots) running mklinux.
I would like to have autofs support.
Make config does not prompt for autofs support in the
kernel release (2.0.33-osfmach3).
In src/fs, the Makefile checks for CONFIG_AUTOFS_FS.
If there, it tells the make to add the autofs directory
to the make tree for the filesystems.
So I hacked the /usr/src/linux/.config file to add the line
CONFIG_AUTOFS_FS=y
Now the kernel builds in the autofs object file.
I downloaded the autofs3.1.1 package and build it, and
automount runs without segging, but it complains that
the kernel does not have autofs support (even though it
was compiled in).
Any help appreciated.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: waiting for milliseconds?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 4 Mar 1999 12:42:58 GMT
Olav Woelfelschneider <[EMAIL PROTECTED]> wrote:
> Shorter delays cannot be done with usleep().
nanosleep() ?
------------------------------
From: Nix <$}xin{[email protected]>
Subject: Re: how can i change the video mode in c++
Date: 03 Mar 1999 19:42:58 +0000
"davide morelli" <[EMAIL PROTECTED]> writes:
> under windows'95
Yes.
Switch to Linux, then use some video-card specific hackery which can't
be described because you didn't say which card this was for.
HTH.
--
`Be pedantic in what you accept and arbitrarily brutal in what you
send.' --- Malcolm Ray describes the roBOFHness principle
------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Subject: patching kernel (2.2.2) help
Date: 3 Mar 1999 22:31:33 GMT
When trying to compile the 2.2.2 kernel I got the same error reported by
Christian Bienia <[EMAIL PROTECTED]> recently, errors compiling
loopback.c.
Eric Potter <[EMAIL PROTECTED]> suggected the alan cox kernel patch ac5.
They're now up to 7 last time I checked, but I am having trouble installing
patches: various combinations of 1-7, 3+ or only 5 all complain that [many]
patches will create files that already exist. I have tried various answers
to the "-R" and "apply anyway?", but get numerous rejects.
What's the correct approach?
TIA
<[EMAIL PROTECTED]>
================== Posted via SearchLinux ==================
http://www.searchlinux.com
------------------------------
From: James Youngman <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Any Insure++ Users?
Date: 02 Mar 1999 21:09:34 +0000
Mark Riehl <[EMAIL PROTECTED]> writes:
> Guys,
>
> We're looking at purchasing a copy of Insure++ for Linux. It's pretty
> expensive ($2900 per user), we can't get an evaluation copy, and the
> only source of info is the Parasoft web page.
>
> So I'd like to hear from some people who have actually used it. Any
> good or bad experiences?
>
> Anyone have any alternatives - either commercial or freeware?
There is CheckerGCC, which is described in Johnson & Troan's "Linux
Application Development", which is worth reading anyway. CheckerGCC
is free software. I have not used Insure++ so have no idea how they
compare.
--
ACTUALLY reachable as @free-lunch.demon.(whitehouse)co.uk:james+usenet
------------------------------
** 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.development.system) 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-Development-System Digest
******************************
