Hi Helge,
helge> Ability to put one particular controller first solves the boot issues
helge> just fine though.
Ah, here is a boot option for you:
append="scsihosts=imm:advansys:advansys:aha1542"
Read this:
http://www.torque.net/scsi/scsihosts.html
Michael
-
To unsubscribe from this
[I wrote]
> Unfortunately, your drivers/scsi/foo.o actually represents the
> zillions of host drivers we have, so the DRIVERS assignment starts to
> look rather daunting and hackish.
I retract that -- I had forgotten that lowlevel is all pulled into
hosts.o.
Peter
-
To unsubscribe from this lis
[mec]
> Can you characterize the problem in more detail for me? That is,
> exactly what link order constraints you are trying to obey.
As has been explained, scsi lowlevel (drivers) need to come before scsi
toplevel (sd, sr, st, sg) because sd and sr cannot dynamically resize
arrays of drives --
Eric Youngdale writes:
> .initcall.init : { *(.initcall.init1) }
> .initcall.init : { *(.initcall.init2) }
> .initcall.init : { *(.initcall.init) }
I like this idea.
I would add initcall.init8 and initcall.init9 in order to have some
levels after the normal initcalls.
> It isn't as ugly as jum
On Thu, Sep 21 2000, Michael Elizabeth Chastain wrote:
> torben> core-hosts/i2o-upper.
>
> Ok, I understand the problem.
>
> Can you elaborate some more on exactly which files go in "core",
> "hosts", and "upper"? My understanding is:
>
> # drivers/scsi
> scsi-core-files := scsi_mod.o
torben> core-hosts/i2o-upper.
Ok, I understand the problem.
Can you elaborate some more on exactly which files go in "core",
"hosts", and "upper"? My understanding is:
# drivers/scsi
scsi-core-files := scsi_mod.o scsi_syms.o
scsi-hosts-files := ... everything not in core and upper
On Thu, Sep 21 2000, Michael Elizabeth Chastain wrote:
> Torben Mathiasen wrote:
>
> > I can't seem to find a clean way of getting the drivers outside
> > "drivers/scsi" to link _after_ the other low-level drivers.
>
> Can you characterize the problem in more detail for me? That is,
> exactly w
Torben Mathiasen wrote:
> I can't seem to find a clean way of getting the drivers outside
> "drivers/scsi" to link _after_ the other low-level drivers.
Can you characterize the problem in more detail for me? That is,
exactly what link order constraints you are trying to obey.
I am thinking abo
On Wed, 20 Sep 2000, Eric Youngdale wrote:
>
> Some of problems that are forcing ordering requirements are better fixed
> in 2.5. The cleanups to allow disk and cdrom drivers to dynamicly resize
> are probably in this category. If you disagree, I can take a stab at it,
> but some of the c
- Original Message -
From: "Linus Torvalds" <[EMAIL PROTECTED]>
To: "Torben Mathiasen" <[EMAIL PROTECTED]>
Cc: "Eric Youngdale" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent:
On Wed, 20 Sep 2000 11:42:24 +0200,
Helge Hafting <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote:
>> To handle newer controllers which mimic older controllers, the newer
>> controllers would be listed in LINK_FIRST. At the moment we do not
>> have any plans to allow user ordering of controllers v
Keith Owens wrote:
>
> On Wed, 20 Sep 2000 10:43:35 +0200,
> Helge Hafting <[EMAIL PROTECTED]> wrote:
> >Ideally I'd like specifying controller order in menuconfig. Perhaps a
> >"controller order" submenu in scsi, that display the default order
> >of the selected controllers. The user can then
On Wed, 20 Sep 2000 10:43:35 +0200,
Helge Hafting <[EMAIL PROTECTED]> wrote:
>Ideally I'd like specifying controller order in menuconfig. Perhaps a
>"controller order" submenu in scsi, that display the default order
>of the selected controllers. The user can then change this.
>I guess that is 2
Jeremy Higdon wrote:
[...]
> My system has both an Adaptec adapter and a Qlogic adapter. The number of
> disks on the Qlogic was variable (it was attached to a SAN). The boot
> disk is attached to the Adaptec. If the Qlogic was probed first, then
> linux could not find the root device, so I had
On Sep 19, 10:35am, Eric Youngdale wrote:
>
> OK, my guess is that we may need to do some tweaking to the Makefile.
> The basic idea is that you need to probe for hosts in a specific order.
> The reason for this is that some host adapters emulate other types of
> hardware. For example, some
On Wed, 20 Sep 2000, Torben Mathiasen wrote:
>
> I can't seem to find a clean way of getting the drivers outside "drivers/scsi"
> to link _after_ the other low-level drivers. My linux Makefile abilities is
> limited though, so if someone with the knowledge would do what Eric requests
> above pl
On Tue, Sep 19 2000, Eric Youngdale wrote:
> 1) SCSI core.
> 2) low-level drivers (in same order as specified in hosts.c).
> 3) upper level drivers.
>
Okay, I've just spent a couple of hours browsing through the scsi code,
compiling different configs, and trying to figure out wha
On Tue, Sep 19 2000, Alan Cox wrote:
> > Thus my gut tells me the correct link order should be:
> >
> > 1) SCSI core.
> > 2) low-level drivers (in same order as specified in hosts.c).
> > 3) upper level drivers.
>
> You need to get the i2o scsi driver run last afte the low level and
> Thus my gut tells me the correct link order should be:
>
> 1) SCSI core.
> 2) low-level drivers (in same order as specified in hosts.c).
> 3) upper level drivers.
You need to get the i2o scsi driver run last afte the low level and before
the high level drivers despite being in driv
TECTED]>
Cc: "Eric Youngdale" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, September 18, 2000 6:58 PM
Subject: Re: [PATCH] Re: SCSI scanning
>
> Ok, there's a test9-pre3 there now..
>
> The SCS
Jeff Garzik wrote:
> Helge Hafting wrote:
> >
> > Rogier Wolff wrote:
> > [...]
> > > No, that's not it. They parse /proc/pci or the output of lspci to
> > > determine which module to insert.
> >
> > Faster, and fine for pci-scsi. I believe you still need
> > to testload modules for isa-scsi.
>
Helge Hafting wrote:
>
> Rogier Wolff wrote:
> [...]
> > No, that's not it. They parse /proc/pci or the output of lspci to
> > determine which module to insert.
>
> Faster, and fine for pci-scsi. I believe you still need
> to testload modules for isa-scsi.
When PCI probing fails, the user is o
Rogier Wolff wrote:
[...]
> No, that's not it. They parse /proc/pci or the output of lspci to
> determine which module to insert.
Faster, and fine for pci-scsi. I believe you still need
to testload modules for isa-scsi.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscrib
Linus Torvalds wrote:
> > Maybe nobody ever insmod'ed a module for a scsi device they don't
> > have?
>
> No, that's not it - the way most distributions do SCSI auto-detection is
> to load modules until they succeed.
> At least I _think_ that's what they do. That's what I'd do if I were a
> dist
On Mon, 18 Sep 2000, Olivier Galibert wrote:
> On Mon, Sep 18, 2000 at 05:51:43PM -0700, Linus Torvalds wrote:
> > Why would this not have happened for a module?
> >
> > I agree that the thing looks fishy. But this is not new code, and it has
> > worked previously. What changed?
>
> Maybe nob
On Mon, Sep 18, 2000 at 05:51:43PM -0700, Linus Torvalds wrote:
> Why would this not have happened for a module?
>
> I agree that the thing looks fishy. But this is not new code, and it has
> worked previously. What changed?
Maybe nobody ever insmod'ed a module for a scsi device they don't
have?
On Mon, 18 Sep 2000, David S. Miller wrote:
>
> The problem is that regardless of the tpnt->present setting, the
> MOD_DEC_USE_COUNT must occur.
>
>And again, why did this not show up with modules?
>
> I have no idea, I'm just the messenger in this case :-)
Hey, I didn't shoot you, I ju
Date: Mon, 18 Sep 2000 17:51:43 -0700 (PDT)
From: Linus Torvalds <[EMAIL PROTECTED]>
Umm, reading the code it looks more like the proper test would be
if (!tpnt->present)
return;
because if "present == 0", then the host not only won't have had the proc
On Mon, 18 Sep 2000, David S. Miller wrote:
>
> Did you try to boot these kernels containing scsi devices you
> don't have? I don't see how it could work (actually I do, see
> below).
Hmm..
Why would this not have happened for a module?
I agree that the thing looks fishy. But this is not ne
Date:Mon, 18 Sep 2000 15:58:02 -0700 (PDT)
From: Linus Torvalds <[EMAIL PROTECTED]>
The SCSI stuff is pretty straightforward, and it works for me (and
I also built a kernel with all regular x86-capable SCSI drivers
included, so the others got at least that level of testing)
This will probaly fix a bunch of scsi problems in tytso's list at
linux24.sourceforge.net.
Could people please verify this and send him a note.
Thanks.
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "un
Ok, there's a test9-pre3 there now..
The SCSI stuff is pretty straightforward, and it works for me (and I also
built a kernel with all regular x86-capable SCSI drivers included, so the
others got at least that level of testing). But there are some non-x86
scsi drivers out there etc, so give it a
On Mon, Sep 18 2000, Torben Mathiasen wrote:
> It just hit me when I touched the send button (yeah right!). I'm basicly
> compiling the same kernel right now.
> Glad we got that in place, otherwise it would have been a long wasted night 8).
>
And just to follow up on my own mail, this patch wor
On Mon, 18 Sep 2000, Mr. James W. Laferriere wrote:
> Oh God , I hope this doesn't mean what I think it might ?
> Please tell me I am stil going to be able to 'Statically' compile
> in the drivers of my choosing ? Tia , JimL
This discussion is about using one initialization
On Mon, 18 Sep 2000, Torben Mathiasen wrote:
> On Mon, Sep 18 2000, Linus Torvalds wrote:
> > And think about it - if this part didn't work, then loadable SCSI modules
> > would never have worked. And every single distribution I know of basically
> > depends on SCSI drivers being loadable modules
On Mon, Sep 18 2000, Linus Torvalds wrote:
> And think about it - if this part didn't work, then loadable SCSI modules
> would never have worked. And every single distribution I know of basically
> depends on SCSI drivers being loadable modules, because there are just too
> effing many of them ;)
On Mon, 18 Sep 2000, Torben Mathiasen wrote:
>
> What about the case when scsi is compiled into the kernel with one or
> more host adapters? We have to initialize those right away.
Actually, we don't. It's really equivalent to just having two or
more modules.
>
On Mon, 18 Sep 2000, Eric Youngdale wrote:
>
> What is the primary objective here - getting rid of #ifdef MODULE, or is
> it removing redundant code for the two paths? Or both?
Both.
As you probably saw, it really started out from fixing this silly bug that
was introduced by mistake some
On Mon, Sep 18 2000, Eric Youngdale wrote:
> What is the primary objective here - getting rid of #ifdef MODULE, or is
> it removing redundant code for the two paths? Or both?
>
> I am just trying to get a handle on what is driving this.
Well the code clean-up came as a pleasent side eff
On Mon, Sep 18 2000, Linus Torvalds wrote:
> Actually, hold off a moment.
>
> It turns out that the MODULE case does all the right things, for all the
> obvious reasons. I'm running a kernel that has the #ifdef MODULE stuff
> just removed, and it seems to be a rather easy approach. It really only
quot;Torben Mathiasen" <[EMAIL PROTECTED]>
Cc: "Eric Youngdale" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, September 18, 2000 4:43 PM
Subject: Re: [PATCH] Re: SCSI scanning
>
>
> On Mon, 18
On Mon, 18 Sep 2000, Torben Mathiasen wrote:
>
> Thanks a lot. I've started to do the basics, like getting all subsystems to work
> with the module_init/exit stuff. This of course leds to some
>rewriteting/restructuring
> of the scsi layer. Nothing major though.
Actually, hold off a moment.
On Mon, Sep 18 2000, Eric Youngdale wrote:
> Historical. SCSI was made modular very early on when the modules
> technology was pretty primative. As time has gone on, the two
> initialization paths have converged, and now they are essentially redundant.
>
Thats understandable.
> The one
- Original Message -
From: "Linus Torvalds" <[EMAIL PROTECTED]>
To: "Torben Mathiasen" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, September 17, 2000 9:32
> On Sun, 17 Sep 2000, Linus Torvalds wrote:
> That's another case where the SCSI layer is module dependent. If it's a
> module, we use the "init_module()" in scsi/scsi.c, and if not, we instead
> use "scsi_dev_init()". They do some of the same things (well, they
> obviously would have to, otherwi
On Sun, Sep 17 2000, Jan Niehusmann wrote:
> On Sun, Sep 17, 2000 at 09:59:30AM -0700, Linus Torvalds wrote:
> > On Sun, 17 Sep 2000, Torben Mathiasen wrote:
> > >
> > > The proper way of fixing this is to add #ifdef MODULE around the init
> > > functions or going back to init/exit_module.
> >
Linus Torvalds wrote:
> Torben, would you mind terribly expanding on your previous patch a bit,
> and also cleaning this part up? As far as I can tell, we should just
> remove scsi_dev_init() completely, and use the module init code with an
> initcall(). Two less regions of #ifdef MODULE, and one
On Sun, 17 Sep 2000, Linus Torvalds wrote:
>
> This is the patch I was looking for. Thanks,
Oh, grepping some more for scsi initializations, the "scsi_dev_init()"
thing stands out.
That's another case where the SCSI layer is module dependent. If it's a
module, we use the "init_module()" in sc
On Sun, 17 Sep 2000, Torben Mathiasen wrote:
>
> I've attached a patch that seems to do "The Right Thing". The problem was
> that the host detection routines would initialize the upper layers of scsi
> drivers (sd/st/sr), and then the module_init routines would
> do it again. I've removed this
49 matches
Mail list logo