This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: Fake SCSI & real SCSI - together?
From: Jan Carlson <janc@iname.com>
Date: Wed, 28 Apr 1999 18:56:10 -0400
NICHOLS JON E wrote:
>
> ah. termination. I should have included that info: the SCSI CD (some
> sorta TEAC 32X) is alone on the internal part of the SCSI chain, and it is
> of course terminated.. the 4 HD's are all external, and their order and
> termination has not changed...at least not on purpose. :) The device on
> the end of the cable is terminated. (I have jumper docs for the HDs - no
> problem there)
Then you need to turn off termination in or on the scsi card,
unless you think it really does that automatically.
It was last on the chain before, but not now.
=========
Subject: Re: Exabyte SCSI tape drives
From: "Jon Klay" <klay@pmel.noaa.gov>
Date: Mon, 17 May 1999 09:18:01 -0700
Vidiot wrote:
> OK, I have RH6.0 up and running. Of course, I get to figure out how to
> get many of the things I had running under 5.0 up and running that way
> again, but that is not the subject of this posting (I use OpenWindows
> and it didn't start, AfterStep did :-)
>
> I now have an Exabyte 8500 attached to the system (2.5/5.0 GB). But, the
> only drive entry is /dev/st0. The following is in the st man page:
>
> Within each group, four minor numbers are available to
> define devices with different characteristics (block size,
> compression, density, etc.) When the system starts up,
> only the first device is available. The other three are
> activated when the default characteristics are defined
> (see below). (By changing compile-time constants, it is
> possible to change the balance between the maximum number
> of tape drives and the number of minor numbers for each
> drive. The default allocation allows control of 32 tape
> drives. For instance, it is possible to control up to 64
> tape drives with two minor numbers for different options.)
>
> Devices are typically created by:
> mknod -m 666 /dev/st0 c 9 0
> mknod -m 666 /dev/st0l c 9 32
> mknod -m 666 /dev/st0m c 9 64
> mknod -m 666 /dev/st0a c 9 96
> mknod -m 666 /dev/nst0 c 9 128
> mknod -m 666 /dev/nst0l c 9 160
> mknod -m 666 /dev/nst0l c 9 192
> mknod -m 666 /dev/nst0a c 9 224
>
> So, what do I have to do to get all of the devices enabled so that I can
> create 5 GB tapes? Is it really as simple as making the extra nodes?
> Under SunOS there is a file that contains the information that describes
> the tape drive. There doesn't appear to be such a config file under Linux.
>
> Couldn't find a HOWTO for SCSI tapes, otherwise I would have read it first.
I struggled through this problem recently, after the minions
whined that they weren't getting as much data on a tape. I
never got a full handle on it - the info is scattered and
incomplete. I made a database /etc/stinit.def, which is
required, from the example in man stinit. Some info in man
mt and man st. Also mt densities. What you want anyway is
mode1, 8500, compressing. I did this:
mknod -m 660 /dev/st0a c 9 96
/sbin/stinit -v -v /dev/st0a
Then I found from Exabyte's web site that Linux with hex
densities codes can be read as 0, so they recommend using
base 10 (can't find printout now, but), so I
mt -f /dev/st0 defdensity 21
which seemed to give me the density we had with DEC UNIX on
st0 (5GB). We also use mt setblk 0 in our backup script,
which might be irrelevant because mode1 is blocksize 0 ,
then -b 20 in the tar. Seemed we needed to before or else
it would have blocksize 5 taring back to the DECs. It was a
pain, but I like the Linux - and they're faster with PII's
than the 7 year old RS6000s.
===
Subject: Re: Kernel bug with NCR537,8XX SCSI driver?
From: Kayvan Aghaiepour Sylvan <kayvan@sylvan.com>
Date: Mon, 24 May 1999 00:17:56 -0700 (PDT)
>>>>> "Jose" == Jose M Sanchez <opjose@ex-pressnet.com> writes:
Jose> Actually he had a loose cable...
Unfortunately, that does not seem to be the end of it.
This afternoon, I took apart and reconstructed my SCSI subsystem.
Here's what I know now:
1) My NCR537xx based SCSI host adapter had terminating resistors
installed on it.
2) Almost all my external SCSI disks had terminating resistors
installed on them. This is despite the fact that they were
installed in external enclosures.
3) My internal SCSI devices also had the terminator jumpers set.
Clearly, there's too much SCSI termination going on...
So, I removed all the extra termination. Here's what the chain of
devices looks like at this point:
I-----------I
I SCSI CARD I
I I
I(internal) I------[Disk: ID6]----[CD Writer: ID 0](termination resistors)
I I
I(external) I------[Disk: ID4]----[Disk: ID 2]----[Disk: ID 1]-[Terminator]
I I
I-----------I
However...
Even with this setup, copying stuff between the external SCSI devices
and the internal SCSI devices seems to cause a system lockup.
Copying between the IDE drive and the internal devices works fine.
Copying between the IDE drive and the external devices also works
great.
I'll be doing some more testing to see if I can isolate the situations
in which it happens. Thanks for everyone's suggestions on this problem
so far.
===
Subject: Re: Kernel bug with NCR537,8XX SCSI driver?
From: "Jose M. Sanchez" <opjose@ex-pressnet.com>
Date: Mon, 24 May 1999 05:33:26 -0400
> Unfortunately, that does not seem to be the end of it.
>
> This afternoon, I took apart and reconstructed my SCSI subsystem.
>
> Here's what I know now:
>
> 1) My NCR537xx based SCSI host adapter had terminating resistors
> installed on it.
>
> 2) Almost all my external SCSI disks had terminating resistors
> installed on them. This is despite the fact that they were
> installed in external enclosures.
>
> 3) My internal SCSI devices also had the terminator jumpers set.
>
> Clearly, there's too much SCSI termination going on...
Ouch! That's what I had mentioned, that the manufacturers ship the drives
with terminators installed and the system builders never bother removing
them, even when packaged in external enclosures...
>
> So, I removed all the extra termination. Here's what the chain of
> devices looks like at this point:
>
> I---------------I
> I SCSI CARD I
> I I
> I (internal) I------[Disk: ID6]----[CD Writer: ID 0](termination
resistors)
> I I
> I(external) I------[Disk: ID4]----[Disk: ID 2]----[Disk: ID
1]-[Terminator]
> I I
> I- ----------I
>
> However...
>
> Even with this setup, copying stuff between the external SCSI devices
> and the internal SCSI devices seems to cause a system lockup.
>
> Copying between the IDE drive and the internal devices works fine.
> Copying between the IDE drive and the external devices also works
> great.
>
> I'll be doing some more testing to see if I can isolate the situations
> in which it happens. Thanks for everyone's suggestions on this problem
> so far.
>
What is not clear is that you mentioned that you have wide scsi devices.
Are you SURE you do?
>From your diagram it appears as if you do NOT...
That is everything appears to be on the same "chain" or SCSI cable...
If however your external drives are WIDE SCSI drives (you MUST count the
pins or wires to determine this...) then your SCSI interface card also needs
terminators, for the SCSI-2 side (the 50 wire cable).
===
Subject: Re: Kernel bug with NCR537,8XX SCSI driver?
From: Kayvan Aghaiepour Sylvan <kayvan@sylvan.com>
Date: Tue, 25 May 1999 01:25:36 -0700 (PDT)
Here's an update and a further plea for ideas about my SCSI problems.
Kayvan> Clearly, there's too much SCSI termination going on...
Jose> Ouch! That's what I had mentioned, that the manufacturers ship
Jose> the drives with terminators installed and the system builders
Jose> never bother removing them, even when packaged in external
Jose> enclosures...
Yup. At this point, though all my drives are fixed.
I--------------I
I SCSI CARD I
I I
I (internal) I------[Disk: ID6]----[CD Writer: ID 0](termination resistors)
I I
I (external) I------[Disk: ID4]----[Disk: ID 2]----[Disk: ID 1]-[Terminator]
I I
I--------------I
Kayvan> I'll be doing some more testing to see if I can isolate the
Kayvan> situations in which it happens. Thanks for everyone's
Kayvan> suggestions on this problem so far.
It seems to me that the external SCSI drives are the real
problem. Copying to/from the external SCSI drives creates a kernel
panic.
Jose> What is not clear is that you mentioned that you have wide scsi
Jose> devices.
Jose> Are you SURE you do?
Yup. I'm sure.
Jose> From your diagram it appears as if you do NOT...
Jose> That is everything appears to be on the same "chain" or SCSI cable...
There are two chains. One internal, and one external.
Jose> If however your external drives are WIDE SCSI drives (you MUST
Jose> count the pins or wires to determine this...) then your SCSI
Jose> interface card also needs terminators, for the SCSI-2 side (the
Jose> 50 wire cable).
I put the resistors back on the card and am still having the same
exact problem.
At this point I'm starting to suspect the SCSI card.
Any other suggestions?
===
Subject: Re: Kernel bug with NCR537,8XX SCSI driver?
From: "Jose M. Sanchez" <opjose@ex-pressnet.com>
Date: Tue, 25 May 1999 05:31:48 -0400
Kayvan Aghaiepour Sylvan <kayvan@sylvan.com> wrote:
> Here's an update and a further plea for ideas about my SCSI problems.
>
> Kayvan> Clearly, there's too much SCSI termination going on...
>
> Jose> Ouch! That's what I had mentioned, that the manufacturers ship
> Jose> the drives with terminators installed and the system builders
> Jose> never bother removing them, even when packaged in external
> Jose> enclosures...
>
> Yup. At this point, though all my drives are fixed.
>
> I--------------I
> I SCSI CARD I
> I I
> I (internal) I------[Disk: ID6]----[CD Writer: ID 0](termination
resistors)
> I I
> I (external) I------[Disk: ID4]----[Disk: ID 2]----[Disk: ID
1]-[Terminator]
> I I
> I--------------I
>
> Kayvan> I'll be doing some more testing to see if I can isolate the
> Kayvan> situations in which it happens. Thanks for everyone's
> Kayvan> suggestions on this problem so far.
>
> It seems to me that the external SCSI drives are the real
> problem. Copying to/from the external SCSI drives creates a kernel
> panic.
>
> Jose> What is not clear is that you mentioned that you have wide scsi
> Jose> devices.
>
> Jose> Are you SURE you do?
>
> Yup. I'm sure.
Humor me, how many wires or pins on each scsi chain?
How do you know one is "wide" scsi and the other is not?
And which are the "wide" scsi devices? The external or internal?
> Jose> From your diagram it appears as if you do NOT...
>
> Jose> That is everything appears to be on the same "chain" or SCSI
cable...
>
> There are two chains. One internal, and one external.
>
Are there TWO internal connectors on the card, one for SCSI-2 and another
for Wide?
(If not, you probably DO NOT have a wide SCSI interface/and or drives...)
> Jose> If however your external drives are WIDE SCSI drives (you MUST
> Jose> count the pins or wires to determine this...) then your SCSI
> Jose> interface card also needs terminators, for the SCSI-2 side (the
> Jose> 50 wire cable).
>
> I put the resistors back on the card and am still having the same
> exact problem.
>
> At this point I'm starting to suspect the SCSI card.
>
> Any other suggestions?
If the problem only manifests on the external drive(s), the
card is not the problem.
It's termination, terminator power or cables....
===
Subject: Re: Good SCSI II DAT Drive
From: Jon Nichols <Jon.Nichols@Colorado.EDU>
Date: Wed, 26 May 1999 11:41:03 -0600 (MDT)
On Wed, 26 May 1999, Azhar H. Chowdhury wrote:
> I am looking for one good SCSI II DAT Drive which
> is compatible with RH 5.2. Can you please provide
> me the information about the hardware?
I have been using a seagate/conner 4meg/8meg SCSI II DAT drive a while now
and it works beautifully. Model # is STD28000N, if you care to
investigate...
===
Subject: You're terminated -- SCSI
From: "Yuki Taga" <yukitaga@twics.com>
Date: Tue, 1 Jun 1999 14:21:49 +0900
Sorry for all these sudden questions, but it won't last too
long I hope, and you guys are a great help.
I have two Seagate Barracudas on a 68-pin cable, and a DAT
and a burner on a 50-pin cable. All internal. The adapter
is Adaptec 2940- UW, and the cables are within spec. The
outside devices are terminated by jumpers, one Barracuda,
and the DAT. (I have heard it's not a good idea to
terminate a burner if you have drives on the same bus, but I
am no expert.)
I have long suspected I had a termination problem on this
box, because every 10 reboots or so, the SCSI bus couldn't
see the burner coming out of the BIOS initialization, and it
took a full power-off reset (cold boot) to clear the bus so
everything would work. But with what I thought was the
correct termination setup, and the Adapter on the default
"automatic", I didn't seem to know what else to try.
Well, booting Linux gives me a message at boot to the effect
of "Warning: Active termination detected, please make sure
the nuclear devices inside your computer are UNarmed, or
evacuate the building immediately". Or something like that.
^^_^^ Okay. That seems to indicate clearly that something
is not right. So, I tried changing the Adaptec BIOS default
from ''automatic" to "high=on; low=off". My reasoning is
that I *think* this terminates only the high order bits on
the 68-pin cable, so they don't interfere with the low order
bits on the 50-pin cable. But I am not sure. I am
definitely guessing. But upon reboot, the nuclear Linux
warning <g> is gone. Only time will tell, I guess, if the
other problem disappears as well. Anyone know about this?
(Oh come on, I know there are SCSI **geniuses** on this
list. To me, SCSI termination is really a black art.) ^_^
BTW, the outside Barracuda has the active termination jumper
set, as well as the termination power to the drive jumper
set. These are the defaults. The DAT has the termination
jumper set, but not the termination power jumper. I cannot
remember why I did this, but I'm *sure* there must have been
a (good?) reason. ^_^ Yuki is going to wash her greasy
hands now, before her keyboard gets any dirtier, and before
(hopefully) she wipes her face with them.
===
From: Bryan Opfer <redhat@balor.tldinc.net>
Date:
gdm@cnsp.com said:
> A little off topic here but,
> I just put a new scsi into my system, but I have an IDE as well. I
> read in one of the HOWTO's that it's impossible to install lilo to
> anything but one of my first two drives, which according to my bios,
> will always be an IDE. Interestingly, the author noted that any
> attempt to install lilo on another drive will cause exactly what you
> described, i.e, getting hung at an 'LI' prompt, and this has in fact
> been my problem. Even though I can select my scsi as the first boot
> device in the bios, I can't change it to be my drive 1, even though
> it is selected as ID 0. I'm a bit curious if you have an IDE
> controller on your board and, if so, how do you get lilo to work on
> the scsi.
> Gary
Gary, the ability to boot from a SCSI drive when you have IDE drives
in your system also is largely BIOS dependent. That you have the option
in your BIOS to support booting from the first IDE drive or the first
SCSI drive is great; but in my experience, it doesn't always work as
expected. Check your motherboard manufacturer's site for updated BIOS
and other related fixes.
I do have an IDE controller, but the only drive I have on it is a CDROM.
So, it just boots off the SCSI HD.
===
From: "Juha Saarinen" <juha_saarinen@email.msn.com>
Subject: RE: kernel building questions for Red Hat
Date: Fri, 29 Jan 1999 12:41:43 +1300
Hi Michael,
It took me a long time to figure out how to get it right under RH 5.2, but
basically, you do kernel recompiles "the Red Hat way" or your modules won't
work.
First, you need the kernel source rpm. The reason for this is that it
contains all the patches required to build a working source tree. The kernel
SRPM installs into
/usr/src/redhat
and you'll find in there a /SPECS directory.
run 'rpm -bp /usr/src/redhat/SPECS/<kernel.xxx.xxx.spec>'
and the various patches will be applied to the source tree, which will be
found in
/usr/src/redhat/BUILD/linux
*NB* I'm not at my RH machine at the moment, so the paths might be wrong.
cd to the /linux directory with the patched source tree, and build the
kernel and modules as normal.
You will also have to create a symlink 'preferred' in /lib/modules pointing
to /lib/modules/2.0.36
The above worked on my machine, but your mileage might vary...
===
Date: Thu, 28 Jan 1999 20:19:52 -0500
From: Cokey de Percin <cdepercin@worldnet.att.net>
Subject: Re: redhat don't have a driver for ultra2 scsi??
Eric Lee Green wrote:
>
> On Fri, 29 Jan 1999, Utku Er wrote:
> > I am using redhat 5.2 and I recompile my kernel(2.0.36) with adaptec scsi support and am using it for a month.
> >
> > BUT kernel writes the scsi uses 20Mb/s. While Ultra2 can reach 80Mb/s how could I reach that speed?
>
> 1) Look at the default that you compiled into the kernel. Make sure you
> set it to default to 40Mhz rather than 20Mhz. (Note that the 40Mhz setting
> will get you 80mb/sec on a wide Ultra2 drive).
>
> 2) Look at your hardware and make sure you have a LVD (Low Voltage
> Differential) terminator on the end of your SCSI chain, or both ends if
> you're using two connectors on the SCSI controller.
>
> 3) Also make sure that you have no non-LVD devices on your SCSI chain. If
> you plug in an ordinary CD-ROM drive onto one side of your SCSI chain,
> that pulls the whole bus into single-ended (20Mhz) mode. Note that some
> cards have a buffer chip inside that'll separate the connectors into two
> different chains, one of which can be LVD and one of which can be used for
> CD-ROM drives etc. You'll need to consult your controller's manual to see
> if that is true for your particular controller.
>
> 4) See if there is an update to the Adaptec driver. I don't use Adaptec
> controllers myself because their drivers have traditionally been dodgy, so
> I can't help you there.
Also check your adapter setup. I don't have any experience with Adaptec, but
I do with Buslogic and some others. On a number of occasions, I've installed
a controller and fast/wide drives only to find out later that the controller
setup defaulted to narrow and/or 10MH. I always check now.
===
Date: Sat, 20 Feb 1999 19:12:51 +0000
From: Matthew Inman <mminman@mindspring.com>
Subject: Re: otta get this tape drive working?!
Jan Carlson wrote:
> Matthew Inman wrote:
> > Can someone give me a basic HowTo for getting a BusLogic SCSI card, and
> > a TR4 Seagate tape drive to work in Linux (they're already working in
> > Win95)? Kernel ver 2.0.36-0.7, RedHat 5.2. (Note: I don't want to
> > reinstall, isn't there an easier way to enable the SCSI support I need?)
>
> Configure Linux to recognize your scsi card, and you should be done.
> Run kernelcfg, select scsi_hostadaptor and select the module for
> your scsi card. Enter the parameters your card uses. Some cards
> don't require parameters since they can be autoprobed successfully.
I'm still not having any luck. I first tried using kernelcfg without
entering any
parameters, and that didn't seem to work. Then, of course, I thought
I'd try entering parameters; problem is I'm unsure what parameters are
correct and/or what parameters I need to enter for this card. In Win95
the resources for the card are listed as:
Memory Range - 000C8000-000CCFFF
IRQ - 9
Memory Range - FE00F000-FE00FFFF
Input/Output Range - E400-E4FF
(Note: No command line parameters are needed in Win95)
And for the tape drive resources are listed as:
Target ID - 4
Logical Unit Number - 0
(Firmware Version 3.22)
How do I figure out what parameters to enter? The only one I'm sure of
is the irq; for dma16, dma, io, and mpu_io I'm guessing.
> When you reboot, you should see some messages about your
> scsi card and the tape drive too.
Things go by to fast for me to be sure that I'm not just missing the
messages, but so far I haven't seen any (Is there a log I can look in to
browse the boot up messages in full at my leisure?).
The way I test to see if the tape drive is working is to try:
tar -vcf /dev/ftape /usr/local
or
tar -vcf /dev/st0 /usr/local
as root (Are either of these correct?). In both cases the system
returns:
tar:Cannot open /dev/xxxx:Operation is not supported by device
tar:Error is not recoverable:exiting now
where xxxx is ftape or st0.
Any further help you can give will be greatly appreciated (I've been
working on this tape drive problem off and on now for weeks and it's
making me feel like a real idiot; I hate it when I have to face reality
like that!).
===
Date: Sat, 20 Feb 1999 19:22:08 -0500
From: shane <zatezalo.2@osu.edu>
Subject: Re: Gotta get this tape drive working?!
>Jan Carlson wrote:
>> Matthew Inman wrote:
>> > Can someone give me a basic HowTo for getting a BusLogic SCSI card, and
>> > a TR4 Seagate tape drive to work in Linux (they're already working in
>> > Win95)? Kernel ver 2.0.36-0.7, RedHat 5.2. (Note: I don't want to
>> > reinstall, isn't there an easier way to enable the SCSI support I need?)
>>
>> Configure Linux to recognize your scsi card, and you should be done.
>[...]
>> When you reboot, you should see some messages about your
>> scsi card and the tape drive too.
>
>Things go by to fast for me to be sure that I'm not just missing the
>messages, but so far I haven't seen any (Is there a log I can look in to
>browse the boot up messages in full at my leisure?).
Look at /var/log/dmesg
>The way I test to see if the tape drive is working is to try:
>
>tar -vcf /dev/ftape /usr/local
I thought ftape works for ATAPI/floppy based tape drives ONLY.
>or
>
>tar -vcf /dev/st0 /usr/local
Try something like this (as root)
cd /tmp
touch testfile.txt
tar -cvf /dev/st0 /tmp
then wait till its done writing to the tape
tar -tvf /dev/st0
that should show you what was written to the tape.
Funny that you started this thread. I just ripped out my Iomega ditto 3200
and replaced it with a Sony DAT on the scsi chain. I'm waiting for
the system to reboot so I try it!!
===
From: Eric Lee Green <eric@linux-hw.com>
To: Redhat List <redhat-list@redhat.com>
Subject: Re: redhat don't have a driver for ultra2 scsi??
Date:
On Fri, 29 Jan 1999, Utku Er wrote:
> I am using redhat 5.2 and I recompile my kernel(2.0.36)
> with adaptec scsi support and am using it for a month.
> BUT kernel writes the scsi uses 20Mb/s. While Ultra2 can
> reach 80Mb/s how could I reach that speed?
1) Look at the default that you compiled into the kernel. Make sure you
set it to default to 40Mhz rather than 20Mhz. (Note that the 40Mhz setting
will get you 80mb/sec on a wide Ultra2 drive).
2) Look at your hardware and make sure you have a LVD (Low Voltage
Differential) terminator on the end of your SCSI chain, or both ends if
you're using two connectors on the SCSI controller.
3) Also make sure that you have no non-LVD devices on your SCSI chain. If
you plug in an ordinary CD-ROM drive onto one side of your SCSI chain,
that pulls the whole bus into single-ended (20Mhz) mode. Note that some
cards have a buffer chip inside that'll separate the connectors into two
different chains, one of which can be LVD and one of which can be used for
CD-ROM drives etc. You'll need to consult your controller's manual to see
if that is true for your particular controller.
4) See if there is an update to the Adaptec driver. I don't use Adaptec
controllers myself because their drivers have traditionally been dodgy, so
I can't help you there.
===
From: "Matthew A. Reklau" <mar242@psu.edu>
Date: Thu, 18 Feb 1999 16:17:50 -0500 (EST)
Subject: Second quick question
I just got ide-scsi emulation to work and now I need to point the symlink
to the correct place.
I have lots of sg devices and I am not sure which on it is. I also have
two cdroms so that doesn't make anything easier either.
Are ide-scsi emulation still placed on the ide bus under linux. For
example would my cdrom be /dev/hda (CDRW drive) or /dev/hdb (Acer 6x
drive) or have those names been switched to /dev/sg?
===
From: Roger Levy <rhlx@ieee.org>
Date: Wed, 17 Mar 1999 22:04:31 -0500
Subject: kernel build
I get same error - do you have a resolution ?
Roger
rhl@ieee.org
(remove x in my address)
You wrote...
I'm having trouble doing a kernel build. I'm getting this
error:
make[3]: Entering directory `/usr/src/linux-2.0.36/drivers/sound'
make[3]: *** No rule to make target `lowlevel/lowlevel.o', needed by
`sound.a'. Stop.
I don't understand what's going on here... the Makefile
there points at the "lowlevel" directory, and that Makefile
in turn looks to me like it has a rule to generate
lowlevel.o. So why isn't it just happening?
===
From: Joe Brenner <doom@kzsu.Stanford.EDU>
Date: Thu, 18 Mar 1999 13:57:10 -0800
Subject: Re: kernel build
> > I'm having trouble doing a kernel build. I'm getting this
> > error:
> >
> > make[3]: Entering directory `/usr/src/linux-2.0.36/drivers/sound'
> > make[3]: *** No rule to make target `lowlevel/lowlevel.o', needed by
> > `sound.a'. Stop.
> >
> > I don't understand what's going on here... the Makefile
> > there points at the "lowlevel" directory, and that Makefile
> > in turn looks to me like it has a rule to generate
> > lowlevel.o. So why isn't it just happening?
>
>
> I get same error - do you have a resolution ?
Sort of. This is currently the way I do builds:
cd /usr/src/linux/
make clean
cd /usr/src/linux/drivers/sound/lowlevel/
export TOPDIR="/usr/src/linux"
make
cd /usr/src/linux/
make
Forcing a build down on the "lowlevel" level gets it passed
this particular problem... and let's me struggle with a
whole other set of problems.
===
From: "Kevin W. Reed" <soldo@telesys.tnet.com>
Date: Tue, 16 Mar 1999 22:37:49 -0700
Subject: FIXED Re: Now I've done it... Kernel questions
Told to us by Kevin W. Reed (soldo@telesys.tnet.com)
on Tue, Mar 16, 1999 at 07:32:47PM -0700
> I think I'm going down the wrong road....
>
> After experiencing the crc problem, I tried a couple things without
> any success. Still had the same problem. Couldn't boot off the hard
> drive but could off the floppy...
>
> So I thought I'd rebuild the kernel.... possible opps..
>
[snip'd]
Got it fixed... and got the LinkSys Etherfast 10/100 to work at the
same time.... Well I don't know about that as I haven't connected it
to anything yet but it says it sees it.
Having never built a Linux kernel before, I was not really sure where
to go or how to do it... Thoughts of blowing up the box before I had
put a backup device on it was not very pleasant... :-)
I did find a link on Redhat that pretty much talks you though it
though:
http://www2.portal.redhat.com/cgi-bin/knowledge_base?_highlightWords=build%20kernel&file=37
It would be nice if it were updated to be "Current" though....
The part of making the kernel and it being so big was fixed by using
'make boot' rather than 'make zImage'....
After rebuilding (I used all the defaults and stuck the new tulip.c
driver in) the system rebooted just fine... Even possibly faster. I
think Xwindows loads faster now too which is a bonus if true..
What bothers me though is... Why does RedHat make it so hard to
figure out what to do. On the box is a HOWTO that is OLD!, and the
instructions in the Kernel source code area don't match what needs to
be done, AND the source doesn't appear to be setup the same way
(config'd) as the kernel they are distributing...
It seems to me it would be very easy for them to pop in a new Howto
when they do an kernel release like the did for the 2.0.36-3 version
and add a file to the source tree that says how THEY built the kernel
they are distributing.... I'm looking at instructions that are
saying you need not use 'make zImage' when I should be using 'make
boot' and there is NOTHING in the documentation in the source tree or
the online HOWTO's that come with the system that talk about 'make
boot'!
Not having done it before and looking at all the docs and web pages
that have differing instructions that are so different, it makes what
turned out to be a fairly simple processing looking like a possible
nightmare.
Just my opinion of course... :-)
Now... lets see if I can hook this thing up to the LinkSys and get it
to talk to the new cable connection...
===
From: Philipp Trautmann <philipp.trautmann@munich.netsurf.de>
Date: Wed, 17 Mar 1999 10:10:23 +0100
Subject: Re: FIXED Re: Now I've done it... Kernel questions
In a display of truly Socratic spirit Kevin W. Reed wrote on 3-17-1999
6:37:
>It seems to me it would be very easy for them to pop in a new Howto
>when they do an kernel release like the did for the 2.0.36-3 version
>and add a file to the source tree that says how THEY built the kernel
>they are distributing.... I'm looking at instructions that are
>saying you needot use 'make zImage' when I should be using 'make
>boot' and there is NOTHING in the documentation in the source tree or
>the online HOWTO's that come with the system that talk about 'make
>boot'!
Could it be that you have tried to use /usr/src/linux/vmlinux (which is
not compressed and thus unusable) as your new kernel image instead of
/usr/src/linux/arch/i386/boot/zImage (which is the right one)?
Just a memory of things I've done myself...
Regards,
===
From: Joe Brenner <doom@kzsu.Stanford.EDU>
Date: Thu, 18 Mar 1999 16:11:44 -0800
Subject: Kernel build problem: no rule to make target `lowlevel/lowlevel.o'
I just had someone asking if I had a fix for an old problem
I asked about here once. Just for the sake of tossing this
into the archive, here's my work around for a build problem
I was stuck on (note I'm talking about the 2.0.36 kernel
here... I'm not adventurous enough to dive into 2.2 yet):
Joe Brenner wrote:
> I'm having trouble doing a kernel build. I'm getting this
> error:
>
> make[3]: Entering directory `/usr/src/linux-2.0.36/drivers/sound'
> make[3]: *** No rule to make target `lowlevel/lowlevel.o', needed by
> `sound.a'. Stop.
>
> I don't understand what's going on here... the Makefile
> there points at the "lowlevel" directory, and that Makefile
> in turn looks to me like it has a rule to generate
> lowlevel.o. So why isn't it just happening?
Do I have a resolution? Sort of. This is currently the way I do builds:
cd /usr/src/linux/
make clean
cd /usr/src/linux/drivers/sound/lowlevel/
export TOPDIR="/usr/src/linux"
make
cd /usr/src/linux/
make
By forcing a build down on the "lowlevel" level I can get
passed this particular problem. This let's me get on with
the business of struggling with a whole other set of
problems, but that's another story...
===
From: Christopher Fisk <chrisf@mhonline.net>
Date: Thu, 11 Mar 1999 17:36:16 -0500 (EST)
Subject: Module loading question
I have been having problems getting my SCSI working while compiling a new
kernel so I thought I would do it as a module because I KNOW that works as
that is how Redhat does it on the default install. My question is this...
Where do I put the modules that I want to be loaded before the filesystem
mounts root in read/write? I attempted to load it via rc.local but that
happens too late in the boot process. how does Redhat load modules for
SCSI BEFORE the drive is mounted?
Any help would be appreciated.
===
From: Blaine Grady <bgrady@knewell.com>
Date: 09 Apr 99 09:45:00 -0500
Subject: SCSI Tape Drive
I need to install BRU on one of my Linux webservers. I
don't think I have my SCSI tape drive configured properly.
How do I determine which driver in /dev references my tape
drive? I do have ftape and nftape in /dev. I installed BRU
to look at ftape but that did not work. On startup, the
system recognizes the tape drive at SCSI ID 6. Does that
correspond to a particular device? Do I need to put an
entry in /etc/fstab for my tape drive? If so, what exactly.
===
From: Matt Nelson <mnelson@dynatec.com>
Date: Fri, 9 Apr 1999 08:05:22 -0700 (PDT)
Subject: Re: SCSI Tape Drive
On 9 Apr 1999, Blaine Grady wrote:
> I need to install BRU on one of my Linux webservers. I
> don't think I have my SCSI tape drive configured properly.
> How do I determine which driver in /dev references my tape
> drive? I do have ftape and nftape in /dev. I installed
> BRU to look at ftape but that did not work. On startup,
> the system recognizes the tape drive at SCSI ID 6. Does
> that correspond to a particular device? Do I need to put
> an entry in /etc/fstab for my tape drive? If so, what
> exactly.
if you only have one SCSI tape drive, it should be
accessible as /dev/st0 (and /dev/nst0 for no-rewind
operation).
===
From: Charles Galpin <cgalpin@lighthouse-software.com>
Date: Thu, 15 Apr 1999 23:46:54 -0400
Subject: RE: newbie SCSI questions (now scsi: aborting command due to timeout)
Thanks to George Lenzer and others, I have made progress by
getting NT installed.
The changes that made a difference primarily seem to be
making the HD id 0 (instead of the default 6), and setting
the adapters termination on instead of auto. I really think
the main problem was the driver falling asleep at the wheel
:)
The Linux install still fails though. Having more confidence
in the setup since NT sees all the SCSI devices just fine, I
took a look at the other virtual consoles.
Alt-F3:
pci probe finds 1 SCSI device
runs insmod on /modules/aic7xxx.o
Alt-F4:
finds adapter, downloads sequencer code
<4> scsi: 1 host
followed by many many
<4> scsi: aborting command due to timeout: pid0, scsi0, channel0, id0, lun0,
0x00 00 00 00 00
So what's going on here? Doesn't appear to like the hard drive.
Again this is an adaptec 2940U2W card, and 9gb IBM ultrastar
9ES DDRS drive.
One thing about the drive it has a termination jumper that
says for this model closing it will make it a Single-End
mode drive. I have no idea what this means, and the install
fails if it is open or closed.
===
From: Jan Carlson <janc@iname.com>
Date: Fri, 16 Apr 1999 14:33:10 -0400
Subject: Re: Adapter SCSI question
Peter Morin wrote:
> Ok. Thanks. But now that Redhat is installed is there anyway of setting
> up the SCSI adapter without re-installing?
No need to reinstall. This is all in 11.6.2 of the RH5.2
Install Guide on www.redhat.com/support too, your
blue and red book from the box. That book's worth
buying from www.redhat.com mail order, by the way.
First test to see if the card autodetects. Run:
modprobe fdomain
If modprobe works fine all by itself, you do not
need the "options fdomain" line. Or, you might
have to help modprobe with
an options line, with the resources the card wants.
Lines to add to /etc/conf.modules:
alias scsi_hostadapter fdomain
options fdomain irq=NN io=0xMMMM (Fill in your values)
Run this to create a /boot/initrd file:
mkinitrd /boot/initrd-2.0.36-3.img 2.0.36-3
Add a line to /etc/lilo.conf in your kernel section
so the initrd will load at boot time
initrd = /boot/initrd-2.0.36-3.img
Then run lilo to do what the new lilo.conf says:
lilo
If you have trouble with the options, you need the docs
or web page for your card, check it's jumpers, see what Windows95
uses for the card, or even read the source code in
/usr/src/linux/drivers/scsi/fdomain.c or something like that.
Install the kernel-source rpm in order to have those files.
There are simpler ways to do this, but this is the only
way to boot from a scsi drive or have the drive mount
early in the boot process.
===