Re: [PATCH] link-order of drivers outside drivers/scsi (i2o)
- Original Message - From: "Torben Mathiasen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, September 28, 2000 7:59 AM Subject: [PATCH] link-order of drivers outside drivers/scsi (i2o) > Alan and others, > > The following patch changes the link order of i2o to link: > > scsi core - hosts - i2o - upper layers. > > The patch moves things around a bit, like all upper layer drivers > going into scsi/upper. Other drivers outside drivers/scsi can > be changed to link in after the other hosts by just moving them > in the top Makefile. A change that needed to be made anyways. The rest of the lowlevel drivers should be stratified a bit to provide some more sanity anyways, but that doesn't need to be done now. -Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
- Original Message -
From: "Linus Torvalds" <[EMAIL PROTECTED]>
To: "Torben Mathiasen" <[EMAIL PROTECTED]>
Cc: "Eric Youngdale" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, September 19, 2000 6:59 PM
Subject: Re: [PATCH] Re: SCSI scanning
>
>
> 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 please. We will probaly have to move some thing around, and that
would be a
> > _bad_ move at this point I guess.
>
> Note that ordering requirements are usually bad requirements. In many
> cases it's probably best to just fix the problem that causes ordering
> requirements in the first place.
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 changes won't be simple.
It isn't that I don't want to do it - I have been itching to clean this
up for some time now anyways - and it was getting near the top of things to
do :-). Actually once the groundwork is laid, the work for drivers outside
of SCSI could be handled by others, or even deferred (which in itself would
simplify the task) to 2.5.
We did get the character device (tape and generic) cleaned up so
*technically* there are no ordering requirements for those two. It is only
disk and tape that still have this problem, and it is the only issue that
imposes any ordering at all (other than the question of newer drivers/older
drivers, which can easily be addressed in the Makefile).
> So we don't need to do a "perfect" job on ordering. In fact, we probably
> want to avoid ordering as much as possible - I'd rather fix the problems
> that cause us to want to order thing than spending much time trying to
> order stuff.
>
> Some ordering is simple: making sure that newer drivers show up before
> older drivers that can catch on compatibility stuff. Some other cases are
> equally obvious: keeping the sort in pretty much the same order as the old
> hosts.c file just to avoid having peoples disks being re-ordered if
> somebody has multiple types of SCSI controllers. That's more of a "let's
> be polite" thing.
>
> But let's fix the real problems rather than hit our heads against the
> ordering wall..
My thinking is that for 2.4 we can impose a simple ordering by adding a
few lines to vmlinux.lds (the linker script that is used to collect assorted
ELF sections together, which lives in arch//vmlinux.lds). Thus
instead of:
.initcall.init : { *(.initcall.init) }
we could instead have:
.initcall.init : { *(.initcall.init1) }
.initcall.init : { *(.initcall.init2) }
.initcall.init : { *(.initcall.init) }
It would be trivial to ensure correct order by making the scsi core 1, make
the host adapters 2, make the upper level adapters normal initcall.
Everything else is left alone. If there is anything that needs to be
initialized prior to SCSI, we could invent an initcall.init0, but I doubt
that there is anything that would fit into this category.
It isn't as ugly as jumping through millions of hoops to get the Makefiles
to do it right.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
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 Buslogic cards emulate Adaptec 1542. Typically in such cases you want the Buslogic driver to handle the card and not the 1542 driver (mainly for performance reasons - Leonard would probably have more to say about this). There *may* be other instances where probing for one type of card can screw up another type of card, but I haven't heard of cases like this in some time now, There are a handful of others - the comments in the initializer in hosts.c explain some of them. I hope there are not others which people failed to document. A second potential gotcha - for compiled in drivers, I think that low-level drivers should be initialized prior to upper level drivers. The reason for this is that not all of the upper level drivers are capable of resizing the arrays on the fly (disk and cdrom are the two exceptions). Yes, cleaning this up is on the list of things to do (it got partly done for 2.4), but fixing this is a nasty problem that reaches it's bony fingers all the way up into some of the filesystems (essentially those stupid arrays in ll_rw_blk which are read without any type of spinlock protection). The CONFIG_SD_EXTRA_DEVS parameter is used to pre-allocate room in the arrays for additional devices, so for systems with small numbers (< 40) of disks things may just happen to work. For now, the trick should simply be to keep the upper level drivers at the end of the list of objects to be linked in so the initializers run last. 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. -Eric - Original Message - From: "Linus Torvalds" <[EMAIL PROTECTED]> To: "Torben Mathiasen" <[EMAIL PROTECTED]>; "Russell King" <[EMAIL PROTECTED]> 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 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 whirl. > > Basic approach: remove all #ifdef MODULE, and get rid of the hosts.c > hardcoded listing of SCSI devices - let SCSI controller drivers do their > own initialization. > > Linus > > > - pre1: > - USB: OHCI controller unlink and bandwidth reclamation fixes > - USB: storage update > - sparc64: register window race. Non-deadlock rwlocks. > - name clash in hamradio/pi2.c and hamradio/pt.c > - epic100 credits, 8139too driver update, sr.c initcalls > - acenic update > - NFS sillyrename fixups > - mktime(). Do it just once - not 16 times. > - misc small fixes to random drivers by Tigran > - IDE driver picks up master/slave relationships on its own. > - truncate unmapped/uptodate case handled correctly > - don't do notifier locking at low level: higher levels do (or > should do) this already. > - ACPI interpreter updates (and file renames - making this part big) > - SysKonnect gigabit driver update > - 3c59x driver update > - pcmcia debounce logic. Ugh. > - MM balancing (Rik Riel) > - pre2: > - "extern inline" -> "static inline". It doesn't matter right now, > but it's proactive for future gcc versions. > - various net drvr updates and fixes > - more initcall updates > - PPC updates (including PPC-related drivers etc) > - disallow re-mounting same filesystem in same place multiple times. > Too confusing. And /etc/mtab gets strange. > - Riel VM update > - sparc updates > - PCI bridge scanning fix: assign numbers properly > - network updates > - scsi fixes > - pre3: > - uninitialized == zero. Remove extra initializers. > - block_prepare_write and block_truncate_page: if the page is > up-to-date, then so are the buffer heads inside it once they > are mapped.. > - SCSI initialization - move over to the modular case. No more > double initialization. > - Sync up with Alans 2.2.x driver changes > - networking updates (iipv6 works non-modular etc) > - netfilter update > - adfs correct dentry operations > - ARM update (i
Re: [PATCH] Re: SCSI scanning
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. -Eric - Original Message - From: "Linus Torvalds" <[EMAIL PROTECTED]> To: "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 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. > > 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 > required making a few things static (the init routines would clash > otherwise), and removing a lot of #ifdef MODULE. > > (And removing some code that was enabled only for non-modules). > > It looks very straightforward. > > Linus > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi_ioctl_send_command() shouldn't write SEND DIAGNOSTICS reserved bits
My major comment is that you should use "SEND_DIAGNOSTIC" instead of a
hardcoded 0x1d.
-Eric
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, September 18, 2000 12:31 PM
Subject: [PATCH] scsi_ioctl_send_command() shouldn't write SEND DIAGNOSTICS
reserved bits
> This patch prevents scsi_ioctl_send_command() from overwriting the SEND
> DIAGNOSTICS (Drive Self Test) reserved bits in cmd[1], as found in SCSI-3.
> Code provided by Michael Landrus of Dell.
>
> Comments are requested. If there are no objections, Linus and Alan please
> apply.
> Below are patches to kernels 2.2.18-pre8 and 2.4.0-test9-pre1.
>
> Thanks,
> Matt Domsch
> Dell Enterprise Systems Group
> Linux Development Team
>
> --- 2.2.18-pre8-linux/drivers/scsi/scsi_ioctl.c.orig Mon Sep 18 07:47:45
> 2000
> +++ 2.2.18-pre8-linux/drivers/scsi/scsi_ioctl.c Mon Sep 18 07:48:29 2000
> @@ -254,7 +254,8 @@
> /*
> * Set the lun field to the correct value.
> */
> -cmd[1] = ( cmd[1] & 0x1f ) | (dev->lun << 5);
> +if ( cmd[0] != 0x1d ) // don't overwrite the SCSI-3 SEND DIAGNOSTICS
> reserved bits
> + cmd[1] = (cmd[1] & 0x1f) | (dev->lun << 5);
>
> switch (opcode)
>{
>
>
> --- 2.4.0-test9-pre1-linux/drivers/scsi/scsi_ioctl.c.orig Mon Sep 18
> 07:37:36 2000
> +++ 2.4.0-test9-pre1-linux/drivers/scsi/scsi_ioctl.c Mon Sep 18 07:41:36
> 2000
> @@ -266,7 +266,8 @@
> /*
> * Set the lun field to the correct value.
> */
> - cmd[1] = (cmd[1] & 0x1f) | (dev->lun << 5);
> + if ( cmd[0] != 0x1d ) // don't overwrite the SCSI-3 SEND
> DIAGNOSTICS reserved bits
> + cmd[1] = (cmd[1] & 0x1f) | (dev->lun << 5);
>
> switch (opcode) {
> case FORMAT_UNIT:
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
- 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 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 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 there wouldn't be any point to having a > init routine at all), but in general do it in very different ways for no > good reason I can see. > > 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 less different > code-path to worry about.. > > Why was this done this way anyway? I've never seen this kind of setup in > any of the other drivers that have been de-liced of module dependencies.. 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. The one thing that is different in the module/non-module case is for the case of SCSI compiled into the kernel, you need to look at the list of compiled-in host adapters. Unless of course you are cleaning that up as well. I haven't seen the threads that got this work started, and it is only in reading this morning's messages that I see the rationale for all these changes in the first place. There are a couple of ways of addressing this, some better than others, and some are more work than others. I can give you assistance and ideas if you want. -Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Weirdness in block device queues.
> It is. Not unplugging the queue results in higher throughput > when running a benchmark load, but seems to really harm > system throughput (and cause stalls) in /real/ loads. > > This is most likely due to the fact that in most real life > loads we have to write data and metadata all over the place > and write clustering isn't as effective as in benchmark > loads (where we write 500MB of "data" at full speed to one > file). Interesting. This brings me to another point. We probably want some generic interfaces in ll_rw_blk to unplug individual queues, where you can either specify either the actual queue a kdev_t. Some of the places, (such as __wait_on_buffer()) it might make more sense to unplug just the queue related to the buffer in question rather than just unplug everything by running tq_disk. On single-disk systems there wouldn't be any appreciable difference, but if you had a lot of disks, it would probably work out to be more efficient. Something to think about To fix this specific problem for 2.4, the easiest and safest thing to do is to run tq_disk when we inject a SCSI ioctl (iff the queue is plugged). Right now there is no way to remove individual entries from a task queue without running the entire list, and calling the unplug routine while the thing is still in the list would *appear* to be unsafe in that if the queue were re-plugged the tq_disk list could be corrupted. -Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Weirdness in block device queues.
Doug Gilbert and I ran across some weirdness in the way the block device queues are plugged/unplugged. It turned up with some benchmarks of the SCSI generics driver - with the new queueing code, the generics driver is inserting requests into the same queue that block device requests are inserted. The oddness is this. We were observing stalls in the processing of commands that was traced to the fact that the queue had remained plugged for an excessive amount of time. The stalls last for about 5 seconds or so. Some investigation revealed that part of the answer is that the bdflush daemon essentially forces a bunch of dirty pages to be written to disk, but never bothers to unplug the queue when it is done. The result is that the queue remains plugged until someone else comes along and unplugs it. As it turns out, kupdate() does unplug the queue, and kupdate runs every 5 seconds or so. Patching bdflush to run tq_disk after flushing buffers (i.e. before the schedule()) fixed *most* of the problem, but evidently not all of it (Doug was still observing stalls, but a lot less frequently). In other words, there is someone else out there queueing requests in such a way that the queue can remain plugged for some amount of time. My gut tells me that it is wrong for bdflush to not unplug the queue when it is done queueing I/O requests. My gut also tells me that the generics driver probably wants to be unplugging the one specific queue that it is using to ensure that I/O gets queued right away (it doesn't make sense to unplug all queues in this instance). Comments? -Eric
Re: Oops/kernel panic with CD jukebox, 2.4.0-test{6,7}
- Original Message -
From: "Steven S. Dick" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, September 03, 2000 6:45 AM
Subject: Re: Oops/kernel panic with CD jukebox, 2.4.0-test{6,7}
> Anssi V I Johansson <[EMAIL PROTECTED]> wrote:
> >Greetings. I'm having serious problems with my external NEC/Nakamichi
> >MBR-7 7-CD jukebox. Linux gives me an oops _every_time_ I try to
> >access two CDs from that jukebox at the same time and sometimes it even
> >gives me a kernel panic when I'm doing that. Not very nice..
>
> I've been fighting with this bug (and about 4 others that covered it up)
> for about a year now.
>
> I've spent the last week or so debugging this with Eric Youngdale.
> I think he has it fixed. I assume he'll put the patch in the next
> release of the kernel. (Right?)
I haven't gotten around to it - I have been busy, but I should be able
to get it sent out sometime tomorrow. Don't have my main development
machine in front of me right now.
> In the meanwhile, here's a patch for it, against 2.4-test7
>
>
> --- orig/drivers/scsi/scsi.c Mon Jul 31 14:00:06 2000
> +++ linux/drivers/scsi/scsi.c Wed Aug 30 21:09:26 2000
> @@ -384,7 +384,7 @@
> * return NULL.
> */
> SCpnt = NULL;
> - break;
> + goto busy;
> }
> }
> /*
> @@ -402,6 +402,7 @@
> if (SCpnt) {
> break;
> }
> + busy:
> /*
> * If we have been asked to wait for a free block, then
> * wait here.
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
