Hi,Jeff
On Friday, October 23, 2015 03:04 AM, Jeff Moyer wrote:
Jens Axboe writes:
On 10/22/2015 09:53 AM, Jeff Moyer wrote:
I think that percolating BLK_MQ_F_TAG_SHARED up to the tag set would
allow newly created hctxs to simply inherit the shared state (in
blk_mq_init_hctx), and you won't
On Thu, Oct 22, 2015 at 5:15 PM, jason wrote:
>
>
> On Thursday, October 22, 2015 04:47 PM, Tejun Heo wrote:
>>
>> Hello,
>>
>> On Mon, Oct 19, 2015 at 07:40:13AM -0700, Zhangqing Luo wrote:
>>
>> > So every time blk_mq_freeze_queue_start, it runs in this way
>> >
>> > blk_mq_freeze_queue_sta
Jens Axboe writes:
> On 10/22/2015 09:53 AM, Jeff Moyer wrote:
>> I think that percolating BLK_MQ_F_TAG_SHARED up to the tag set would
>> allow newly created hctxs to simply inherit the shared state (in
>> blk_mq_init_hctx), and you won't need to freeze every queue in order to
>> guarantee that.
On 10/22/2015 09:53 AM, Jeff Moyer wrote:
Jens Axboe writes:
I agree with the optimizing hot paths by cheaper percpu operation,
but how much does it affect the performance?
A lot, since the queue referencing happens twice per IO. The switch to
percpu was done to use shared/common code for th
Jens Axboe writes:
>> I agree with the optimizing hot paths by cheaper percpu operation,
>> but how much does it affect the performance?
>
> A lot, since the queue referencing happens twice per IO. The switch to
> percpu was done to use shared/common code for this, the previous
> version was a ha
On 10/22/2015 03:15 AM, jason wrote:
On Thursday, October 22, 2015 04:47 PM, Tejun Heo wrote:
Hello,
On Mon, Oct 19, 2015 at 07:40:13AM -0700, Zhangqing Luo wrote:
> So every time blk_mq_freeze_queue_start, it runs in this way
>
> blk_mq_freeze_queue_start
> ->percpu_ref_kill->percpu_ref
On Thursday, October 22, 2015 04:47 PM, Tejun Heo wrote:
Hello,
On Mon, Oct 19, 2015 at 07:40:13AM -0700, Zhangqing Luo wrote:
> So every time blk_mq_freeze_queue_start, it runs in this way
>
> blk_mq_freeze_queue_start
> ->percpu_ref_kill->percpu_ref_kill_and_confirm
> ->__percpu_ref_swi
Hello,
On Mon, Oct 19, 2015 at 07:40:13AM -0700, Zhangqing Luo wrote:
> So every time blk_mq_freeze_queue_start, it runs in this way
>
> blk_mq_freeze_queue_start
> ->percpu_ref_kill->percpu_ref_kill_and_confirm
> ->__percpu_ref_switch_to_atomic
> ->call_rcu_sched(&ref->rcu,percpu_ref_switch
s one possible fix, as I can't see if it can introduce
other regression issue, so could you guy look into it and give some advice?
/Thanks
0001-Avoid-long-delay-for-scsi-scanning-when-thousands-of.patch
>From 4505e8d499a7c336ebc3b588b089f5408841b421 Mon Sep 17 00:00:00 2001
Fro
On Thu, May 17, 2007 at 01:49:52PM -0400, Benjamin LaHaise wrote:
> On Thu, May 17, 2007 at 01:45:24PM -0400, James Bottomley wrote:
> > But also, the sysfs with over 4,000 (and higher) devices was
> > specifically checked by OSDL (actually as part of the CGL testing) some
> > of the Manoj changes
Peter Jones wrote:
> So really, either way means we need to update the tools. It also
> doesn't really solve the problem -- when I insert "usb-storage", the
> SCSI scan may still finish while we're still enumerating the bus for USB
> devices. (I'd be willing to believe I'm wrong about this spec
On 5/18/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
On Fri, May 18, 2007 at 10:58:05AM +0530, Satyam Sharma wrote:
> [ BTW, this is the last time I'll try explaining this to you. ]
Oh good. Perhaps you can just drop the idea entirely and give up?
Well, I do plan to, at least as far as convi
On 5/18/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
On Fri, May 18, 2007 at 09:11:58AM +0530, Satyam Sharma wrote:
> It's also somewhat a matter of *taste* (and hence subjective), if you
> _still_ don't get it, Matthew, then there's no point continuing this thread
> and trying to convince you a
On Fri, May 18, 2007 at 10:58:05AM +0530, Satyam Sharma wrote:
> [ BTW, this is the last time I'll try explaining this to you. ]
Oh good. Perhaps you can just drop the idea entirely and give up?
> The one-line patch you're suggesting *would*not*allow* one to use the async
> scanning _at_all_. If
On Fri, May 18, 2007 at 09:11:58AM +0530, Satyam Sharma wrote:
> It's also somewhat a matter of *taste* (and hence subjective), if you
> _still_ don't get it, Matthew, then there's no point continuing this thread
> and trying to convince you ad infinitum.
Right. It's a matter of taste. What make
On 5/18/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
On Thu, May 17, 2007 at 03:43:26PM -0400, Benjamin LaHaise wrote:
> On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote:
> > On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote:
> > > Hmmm, actually those other users could
On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote:
> On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote:
> > Hmmm, actually those other users could easily write and maintain
> > a 20-line patch that does the wait for async scans thing for them
> > using /proc/scsi/scsi in a
Matthew Wilcox wrote:
On Tue, May 15, 2007 at 12:26:29PM +0100, Simon Arlott wrote:
I've already suggested a sysfs attribute - or something equivalent - would
be much better. It's just one function that a user might want to run multiple
times (e.g. after adding scsi devices?) - why should loadin
Dave Jones wrote:
On Thu, May 17, 2007 at 03:30:43PM -0600, Matthew Wilcox wrote:
> On Thu, May 17, 2007 at 03:43:26PM -0400, Benjamin LaHaise wrote:
> > On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote:
> > > On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote:
> > >
On Thu, May 17, 2007 at 03:30:43PM -0600, Matthew Wilcox wrote:
> On Thu, May 17, 2007 at 03:43:26PM -0400, Benjamin LaHaise wrote:
> > On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote:
> > > On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote:
> > > > Hmmm, actually tho
On Thu, May 17, 2007 at 03:43:26PM -0400, Benjamin LaHaise wrote:
> On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote:
> > On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote:
> > > Hmmm, actually those other users could easily write and maintain
> > > a 20-line patch that do
On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote:
> On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote:
> > Hmmm, actually those other users could easily write and maintain
> > a 20-line patch that does the wait for async scans thing for them
> > using /proc/scsi/scsi in an
On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote:
> Hmmm, actually those other users could easily write and maintain
> a 20-line patch that does the wait for async scans thing for them
> using /proc/scsi/scsi in any case.
How about the three users who're bothered by this extra module
On 5/18/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Fri, May 18, 2007 at 12:17:40AM +0530, Satyam Sharma wrote:
> However, Ben does have a point that we shouldn't force those
> using SCSI (and wishing to use the new async scanning
> feature) to depend on and use sysfs too
yes, we do. an
On Fri, May 18, 2007 at 12:17:40AM +0530, Satyam Sharma wrote:
> However, Ben does have a point that we shouldn't force those
> using SCSI (and wishing to use the new async scanning
> feature) to depend on and use sysfs too
yes, we do. an no, procfs is a much worse filesystem to depend
on for dri
Hi Christoph,
On 5/17/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Thu, May 17, 2007 at 11:11:10PM +0530, Satyam Sharma wrote:
> Another command to /proc/scsi/scsi isn't a bad thought at all, considering
Yes it is. /proc/scsi/scsi is a horrible interface and deprecated since
the start o
On Thu, May 17, 2007 at 11:11:10PM +0530, Satyam Sharma wrote:
> Another command to /proc/scsi/scsi isn't a bad thought at all, considering
Yes it is. /proc/scsi/scsi is a horrible interface and deprecated since
the start of the 2.6 series.
-
To unsubscribe from this list: send the line "unsubsc
On Thu, May 17, 2007 at 01:45:24PM -0400, James Bottomley wrote:
> But also, the sysfs with over 4,000 (and higher) devices was
> specifically checked by OSDL (actually as part of the CGL testing) some
> of the Manoj changes (for unpinning entries etc) were needed to get it
> to function, but as of
On Thu, 2007-05-17 at 13:32 -0400, Benjamin LaHaise wrote:
> On Wed, May 16, 2007 at 04:57:52AM +0530, Satyam Sharma wrote:
> >
> > echo 1 > /sys/module/scsi_mod/.../wait_for_async_scans
> >
> > somewhere in some script. In fact, the latter method seems simpler,
> > saner, better (in every which
On 5/17/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
On Thu, May 17, 2007 at 10:43:06PM +0530, Satyam Sharma wrote:
> >No, it does matter. Your suggestion doesn't work, because
> >/sys/module/scsi_mod/parameters/ belongs to the module code. To create
> >a new attribute there, you use the modul
On Wed, May 16, 2007 at 04:57:52AM +0530, Satyam Sharma wrote:
>
> echo 1 > /sys/module/scsi_mod/.../wait_for_async_scans
>
> somewhere in some script. In fact, the latter method seems simpler,
> saner, better (in every which way)!
Please don't force sysfs on people. Just watch how it keels ove
On Thu, May 17, 2007 at 10:43:06PM +0530, Satyam Sharma wrote:
> >No, it does matter. Your suggestion doesn't work, because
> >/sys/module/scsi_mod/parameters/ belongs to the module code. To create
> >a new attribute there, you use the module_param() code -- and there's
> >no way to have code cal
Hi Matthew,
On 5/16/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
[...]
> /sys/module/scsi_mod/parameters/wait_for_async_scans (?)
> Doesn't really matter, but perhaps who created the sysfs namespace
> for scsi in /sys/module/scsi_mod/... could be the best person to suggest.
No, it does matter.
> No, it does matter. Your suggestion doesn't work, because
> /sys/module/scsi_mod/parameters/ belongs to the module code. To create
> a new attribute there, you use the module_param() code -- and there's
> no way to have code called when your parameter is changed.
If I'm not misunderstandin
On Wed, May 16, 2007 at 04:57:52AM +0530, Satyam Sharma wrote:
> [ I appreciate you forked the thread and gave it a better subject name,
> it would be better still if you could maintain the original CC list,
> thanks. ]
I removed the people I didn't think needed to be on the Cc list any more,
sin
On 5/16/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
>> > >semantics of it (read-only? read-write? write-only?
>
> Well, it _has_ to be write, don't really care if it's read-write or
> write-only. I would still prefer read-write, but we can go ahead with
> write-only too
Satyam Sharma wrote:
> >semantics of it (read-only? read-write? write-only?
Well, it _has_ to be write, don't really care if it's read-write or
write-only. I would still prefer read-write, but we can go ahead with
write-only too. It doesn't really matter, does it?
just to be devils advocate
Hi,
[ I appreciate you forked the thread and gave it a better subject name,
it would be better still if you could maintain the original CC list, thanks. ]
On Tue, May 15, 2007 at 12:26:29PM +0100, Simon Arlott wrote:
I've already suggested a sysfs attribute - or something equivalent - would
be
On Tue, May 15, 2007 at 05:30:50PM +0100, Simon Arlott wrote:
> On 15/05/07 13:02, Matthew Wilcox wrote:
> >It's easy to suggest a sysfs attribute. What you've failed to do is
> >suggest the pathname of the sysfs attribute, the contents of it, or the
> >semantics of it (read-only? read-write? wr
On 15/05/07 13:02, Matthew Wilcox wrote:
On Tue, May 15, 2007 at 12:26:29PM +0100, Simon Arlott wrote:
I've already suggested a sysfs attribute - or something equivalent - would
be much better. It's just one function that a user might want to run multiple
times (e.g. after adding scsi devices?)
On Tue, May 15, 2007 at 12:26:29PM +0100, Simon Arlott wrote:
> I've already suggested a sysfs attribute - or something equivalent - would
> be much better. It's just one function that a user might want to run multiple
> times (e.g. after adding scsi devices?) - why should loading a module be used
Under SCSI device support.
-> [*] Asynchronous SCSI scanning
Does this affect actual SCSI devices ONLY or SATA drives as well?
Justin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
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:
Linus and others,
Patch attached that should fix some of the problems with the new
scsi scanning:
devfs registration should be ok now with both builtin and module.
link order changed to reflect hosts.c + minor additions.
minor cleanups.
First of all, please don't
[Matthew Kirkwood]
> +ifeq ($(CONFIG_BLK_DEV_MD),y)
> +SUB_DIRS += md
> +MOD_SUB_DIRS += md
> +else
> + ifeq ($(CONFIG_BLK_DEV_MD),m)
> + MOD_SUB_DIRS += md
>endif
> endif
>
Drop the 'else' bit; CONFIG_BLK_DEV_MD cannot be 'm'.
> +obj-n:=
> +obj- :=
These two va
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
In article <[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> [ Btw, has autorun ever worked with non-scsi devices?
Yes, with IDE disks at least.
--
Shields.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Plea
Linus Torvalds writes:
> [ Btw, has autorun ever worked with non-scsi devices? They've mostly had
> the new initialization order for a long time.. ]
Hmm, I hope it will do, since a 2.2.17 kernel with Ingos RAID patches
works, and it'd be a shame to break all those RAID root filesystems out
ther
On Tue, 19 Sep 2000, Linus Torvalds wrote:
> > moving the software RAID drivers into drivers/md/,
> Make it so.
OK. Apply the attached diff and then:
$ mv drivers/block/{md,raid{0,1,5},xor}.c drivers/md/
and all might be well.
The Config.in should probably move at some stage too.
I'm not v
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
On Tue, 19 Sep 2000, Matthew Kirkwood wrote:
>
> It's probably solely an init-order thing but, short of
> moving the software RAID drivers into drivers/md/, I
> can't see an easy way to fix it.
That would probably not be a bad fix - especially as some people want to
split up xor.c into multipl
> 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
Hi,
It would appear that the changes in pre3 and pre4 break
RAID autorun. This is rather bothersome for those who
have RAIDed root filesystems.
It's probably solely an init-order thing but, short of
moving the software RAID drivers into drivers/md/, I
can't see an easy way to fix it.
cheers,
M
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
The exact semantics are:
.config:
CONFIG_FOO=y# yes
CONFIG_FOO=m# module
# CONFIG_FOO is not set # no
include/linux/autoconf.h:
#define CONFIG_FOO 1/* yes */
#undef CONFIG_FOO
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
On Sun, 17 Sep 2000, Jan Niehusmann wrote:
>
> Further investigation shows that this duplication is caused by the call
> to scan_scsis in line 1565 of scsi.c, and this one can not be commented out
> as it is needed.
>
> But I have some problems understanding all the module/non-module stuff:
1 - 100 of 104 matches
Mail list logo
