It was a SCAM!
Well, SCAM seems to be the problem. I don't know if it's a behavior
particular to the new Linux driver, but the SCAM-assigned IDs got ignored
to some extent. What seemed to be happening was that the HD (not a boot
device, BTW) that was SCAMed to ID#15 ended up being ID#0 to
Suggest putting HD on SCSI 0 vice CD. Some bios's want to boot from 0.
OHJ
> On Monday 19 February 2001 10:08, Jeffry Smith wrote:
> > Matthew J. Brodeur said:
> > >I'm having a problem with an Adaptec 2940UW and several kernels in
> > > RH7.0. Below this message is the output from tr
I seem to recall having this problem; if memory serves, termination is the
right route, but the thing to be *sure* of is that auto-termination is
turned off on the card. Terminate it whatever way you want it to be, but
avoid the auto-termination option.
Good luck!
-Ken
On Mon, 19 Feb 2001, Mat
Hi Matt,
I have also had this problem several times, usually updating the kernel does
it for me, but it looks like you're already tried it. If checking the
termination doesn't solve the problem, i would then check the speed of the
bus using the SCSI Select utility. You might want to lower the s
"Matthew J. Brodeur" <[EMAIL PROTECTED]> said:
I'm having a problem with an Adaptec 2940UW and several kernels in
RH7.0.
Well, I looked at the messages, and the fact that you are trying to
talk to a CDRW, and I groaned... I'm seeing a similar problem with
Red Hat 6.1, but with the latest-n-grea
Matthew J. Brodeur said:
>I'm having a problem with an Adaptec 2940UW and several kernels in
> RH7.0. Below this message is the output from trying to load the
> aic7xxx module while running RedHat's 2.2.17-14smp. The same thing
> happens with 2.2.16-22 and 2.4.1.
>The MB is a Tyan 1564D
I'm having a problem with an Adaptec 2940UW and several kernels in
RH7.0. Below this message is the output from trying to load the
aic7xxx module while running RedHat's 2.2.17-14smp. The same thing
happens with 2.2.16-22 and 2.4.1.
The MB is a Tyan 1564D w/ 2x P233MMX, and the SCSI card ha
[EMAIL PROTECTED] said:
> The major complaint that most people have is about the kernel compilng
> (in fact I have yet to hear of a package that fails with RH's 2.96
> except the kernel)...and that is a fairly simple fix that the kernels
> guys would need to do anyway (and are doing).
I don't kn
I've noticed that in /usr/bin (I think) is a symlink from cc to gcc
(2.96), removing that symlink helps a lot!
--rdp
On Thu, 7 Dec 2000, Marc Evans wrote:
> The key appears to be to edit the Makefile at the top of the source tree
> and change the definition of CC to use egcs. I should note th
The key appears to be to edit the Makefile at the top of the source tree
and change the definition of CC to use egcs. I should note that I did NOT
find running "make CC=egcs" or similiar variants sufficient.
- Marc
**
To unsubscribe from
On Thu, 7 Dec 2000, Kenneth E. Lussier wrote:
> Rich Payne wrote:
> > At the risk of starting a flaim warthat's not fair. We can argue about
> > it's releasability (not sure that's really a real word!), but the fact
> > remains that the numbers of bugs fixed in 2.96 is massive, and the
> > ke
Rich Payne wrote:
> At the risk of starting a flaim warthat's not fair. We can argue about
> it's releasability (not sure that's really a real word!), but the fact
> remains that the numbers of bugs fixed in 2.96 is massive, and the
> kernel not compiling properly is something the kernel guys
This probably won't work. The correct solution is to modify the top level
Makefileso that the definition for CC reads:
CC =$(CROSS_COMPILE)kgcc -D__KERNEL__ -I$(HPATH)
--
-Time flies like the wind. Fruit flies like a banana. Stranger things have -
-happened but none stranger than this. Doe
On Wed, 6 Dec 2000, Kenneth E. Lussier wrote:
> I probably should have explained better on RH7.OH!, gcc is gcc
> v2.96, which is a development version that should have never been
> released to the wild.
At the risk of starting a flaim warthat's not fair. We can argue about
it's releasab
I probably should have explained better on RH7.OH!, gcc is gcc
v2.96, which is a development version that should have never been
released to the wild. However, in the goodness of their heart, RedRat
also supplied the stable version of gcc and renamed it kgcc (kernel
gcc).
Kenny
Paul Lussier
In a message dated: Wed, 06 Dec 2000 22:16:19 EST
"Kenneth E. Lussier" said:
>Do a `make dep clean bzImage modules modules_install CC=kgcc`
Ahh, I knew there must be a way, I just couldn't remember what it was.
You know, it's amazing how used to Debian "just working" I've gotten in
just 3 month
Do a `make dep clean bzImage modules modules_install CC=kgcc`
Kenny
Marc Evans wrote:
>
> Hi -
>
> Has anyone attempted to build the 2.2.17 kernel sources on a system
> installed with Redhet 7.0? I am encountering errors in cpp macro expansion
> while processing checksum.S and the code there
In a message dated: Wed, 06 Dec 2000 20:41:03 EST
Marc Evans said:
>Has anyone attempted to build the 2.2.17 kernel sources on a system
>installed with Redhet 7.0? I am encountering errors in cpp macro expansion
>while processing checksum.S and the code there seems fine...
Probably because RH7.0
Hi -
Has anyone attempted to build the 2.2.17 kernel sources on a system
installed with Redhet 7.0? I am encountering errors in cpp macro expansion
while processing checksum.S and the code there seems fine...
Thanks in advance - Marc
**
T
On Tue, 8 Aug 2000, Karl J. Runge wrote:
> So the rapid feature bloat we see is OK but compatibility bloat isn't?
>
> Here's a proposal: let's recycle 3% of the feature bloat and reserve
> it for compatibility bloat. ;-)
If you're providing features that are desireable and which people are
usin
> From: Jerry Feldman <[EMAIL PROTECTED]>
> Subject: Re: Linux binary compatability (was: Redhat 7.0 (xinetd))
On Mon, 07 Aug 2000, Jerry Feldman <[EMAIL PROTECTED]> wrote:
>
> I certainly agree with Derek on the binary compatibility. Maintaining
> binary compati
Today, Benjamin Scott gleaned this insight:
Ben, I always respect your opinion, and I don't even disagree with most of
what you say, but it boils down to one thing:
> On Mon, 7 Aug 2000, Jerry Feldman wrote:
> > I certainly agree with Derek on the binary compatibility. Maintaining
> > binary com
Benjamin Scott wrote:
>
> [RE: Having to maintain multiple incompatible versions of binaries]
>
> On Mon, 7 Aug 2000, Derek Martin wrote:
> > I'm reasonably certain that Linus et. al. would tell you that the code is
> > updated for a reason (i.e. it was broken before, and it's much fixed now)
>
[RE: Having to maintain multiple incompatible versions of binaries]
On Mon, 7 Aug 2000, Derek Martin wrote:
> I'm reasonably certain that Linus et. al. would tell you that the code is
> updated for a reason (i.e. it was broken before, and it's much fixed now)
> so you should upgrade all of your
I certainly agree with Derek on the binary compatibility. Maintaining binary
compatibility causes the growth of libraries because of legacy code. For instance,
time_t changes to 64 bits. WIth binary compatibility there must be a mechanism for
older programs to run correctly without recompilatio
Yesterday, Benjamin Scott gleaned this insight:
>
> Interesting. Although I'm familiar with Linus's stance on the issue of
> binary compatibility in the kernel, I was thinking more of the problems Linux
> has had with compatibility between different versions of GCC and GNU libc.
> Perhaps the
Yesterday, Jerry Feldman gleaned this insight:
> Having spent a few years at Digital.Compaq, where binary compatibility
> is the way of life, I kind of side with Linus. With open source, a
> well designed application can be rebuilt in the field even my novices.
> The lack of binary compatibility
On Sun, 06 Aug 2000, Jeffry Smith <[EMAIL PROTECTED]> wrote:
> On more important stuff - Linus' statement on LKML about binary
> compatibility is he doesn't care. He ensures compatibility within a
> release (2.2, 2.0, etc), but between major releases, he doesn't. I've
> seen similar statement
Benjamin Scott wrote:
>
> On Sun, 6 Aug 2000, Tom Rauschenbach wrote:
> > Linus himself has spoken to this.
>
> On Sun, 6 Aug 2000, Jeffry Smith wrote:
> > On more important stuff - Linus' statement on LKML about binary
> > compatibility is he doesn't care.
>
>
> > ... He ensures compatibilit
On Sun, 6 Aug 2000, Tom Rauschenbach wrote:
> Linus himself has spoken to this.
On Sun, 6 Aug 2000, Jeffry Smith wrote:
> On more important stuff - Linus' statement on LKML about binary
> compatibility is he doesn't care.
Interesting. Although I'm familiar with Linus's stance on the issue of
Having spent a few years at Digital.Compaq, where binary compatibility is the way of
life, I kind of side with Linus. With open source, a well designed application can be
rebuilt in the field even my novices. The lack of binary compatibility does have the
affect of making a customer's applicat
On Sun, 06 Aug 2000, Benjamin Scott wrote:
> On Tue, 1 Aug 2000, Karl J. Runge wrote:
> > Boy this is really awful. IM(ns)HO, one should *never* change libc
> > incompatibly. It is OK to add new features to libc and other basic
> > libraries, but one should never have it break existing apps (unle
Benjamin Scott wrote:
>
> On Tue, 1 Aug 2000, Karl J. Runge wrote:
> > Boy this is really awful. IM(ns)HO, one should *never* change libc
> > incompatibly. It is OK to add new features to libc and other basic
> > libraries, but one should never have it break existing apps (unless,
> > say, you a
On Tue, 1 Aug 2000, Karl J. Runge wrote:
> Boy this is really awful. IM(ns)HO, one should *never* change libc
> incompatibly. It is OK to add new features to libc and other basic
> libraries, but one should never have it break existing apps (unless,
> say, you are bringing in a new bin format and
th and/or use relative paths.
>
> > >Trying out the Redhat 7.0 beta. Noticed that lpd no longer is in the
> > >"lpr" package so I was trying to find out what it was (so I could
> > >uninstall it). The following occurred:
> > >
> > >[ro
Thanks for the info John.
I was thinking more along the lines of the sysadmin incompatibility
issue: I vaguely recall xinetd being basically an improved replacement
for inetd+tcp_wrappers. If you just have 1 linux machine it is not such
a big deal to tweak it into working again after an upgrade
On Tue, 1 Aug 2000, Karl J. Runge wrote:
>
> Do you know if it will be 100% compatible with existing RH installations?
> (i.e. no tweaking required to get things working again after an upgrade.
> I believe RH could achieve this in a number of ways)
>
> But if not, then let us now have a moment
"Karl J. Runge" wrote:
>
> Do you know if it will be 100% compatible with existing RH installations?
> (i.e. no tweaking required to get things working again after an upgrade.
> I believe RH could achieve this in a number of ways)
I don't think so but IIRC, the first time I set up xinetd it cam
Do you know if it will be 100% compatible with existing RH installations?
(i.e. no tweaking required to get things working again after an upgrade.
I believe RH could achieve this in a number of ways)
But if not, then let us now have a moment of silence for those of us who
will be broken.
Derek Martin wrote:
> > In other news, I'm very psyched that they've switched over to xinetd!
> > 8)
>
> Will you elaborate as to why?
Sure. 8)
First and foremost, to my knowledge it is a lot more security minded.
The code is audited fairly regularly.
I realize that most of the features it
(Pinstripe).
--rdp
On Mon, 31 Jul 2000, Jeff Macdonald wrote:
> As far as I know, it always needed the full path
>
> At 02:03 PM 7/31/00 -0400, Cole Tuininga wrote:
>
> >*laugh* Ok - this is just amusing.
> >
> >Trying out the Redhat 7.0 beta. Noticed that lpd
;*laugh* Ok - this is just amusing.
=>>
=>>Trying out the Redhat 7.0 beta. Noticed that lpd no longer is in the
=>>"lpr" package so I was trying to find out what it was (so I could
=>>uninstall it). The following occurred:
=>>
=>>[root@(removed) etc]# rpm -
On Mon, 31 Jul 2000, Jeff Macdonald wrote:
> As far as I know, it always needed the full path
Nope... RH 6.1's version doesn't, and IIRC it's supposed to search your
path and/or use relative paths.
> >Trying out the Redhat 7.0 beta. Noticed that lpd no longer is in
As far as I know, it always needed the full path
At 02:03 PM 7/31/00 -0400, Cole Tuininga wrote:
>*laugh* Ok - this is just amusing.
>
>Trying out the Redhat 7.0 beta. Noticed that lpd no longer is in the
>"lpr" package so I was trying to find out what it was (so
On Mon, 31 Jul 2000, Cole Tuininga wrote:
> [root@(removed) init.d]# rpm -qf `pwd`/lpd
> LPRng-3.6.21-8
>
> Is this just a bug in rpm 4?
Looks that way...
>
> In other news, I'm very psyched that they've switched over to xinetd!
> 8)
Will you elaborate as to why?
--
Derek Martin
System A
*laugh* Ok - this is just amusing.
Trying out the Redhat 7.0 beta. Noticed that lpd no longer is in the
"lpr" package so I was trying to find out what it was (so I could
uninstall it). The following occurred:
[root@(removed) etc]# rpm -qf ./rc.d/init.d/lpd
file /rc.d/init.d/lp
46 matches
Mail list logo
