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
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
[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
[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 --
[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 list:
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
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 :=
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
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
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
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
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 what link
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 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
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
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
- 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
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
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
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 to
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 change
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 via
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
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
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
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
;
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 SCSI stuff is pret
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
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
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
>
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 "unsubscribe
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 often
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.
When PCI probing
uot; [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 SCSI stuff is pretty straightforward, and it works for me (and I also
built a kernel with all r
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 before
the
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
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
distribution
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
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
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
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
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
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
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
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
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
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
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
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
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
- 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,
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, otherwise
- 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 PM
Subject: Re: [PATCH] Re: SCSI scanning
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
orben 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 Sep 2000, Torben Mathiasen wrote:
Thanks a lot. I've
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
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 effect
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, 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, 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 works
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
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
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).
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 new
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 nobody ever
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?
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
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
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
80 matches
Mail list logo
