From: Tim Wright <timw@splhi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: rmmod st "hangs" - bad interaction with sg
Date: Sat, 10 Jul 2004 09:03:42 -0700 [thread overview]
Message-ID: <1089475422.1473.25.camel@tp-timw.internal.splhi.com> (raw)
In-Reply-To: <20040710154145.GA17691@infradead.org>
Hi Christoph!
On Sat, 2004-07-10 at 08:41, Christoph Hellwig wrote:
> On Sat, Jul 10, 2004 at 08:31:00AM -0700, Tim Wright wrote:
> > Hi,
> > I was working on the qlogicisp/isp1020 driver in 2.6, as I still have
> > one of these antiques and the driver is a bit out of date (a patch is
> > forthcoming). In the process of testing my changes, I came across the
> > following:
>
> qlogicisp is slowly going away. If you look at the qla1280 driver in current
> mainline you'll see it has most of the support for the 1020/1040 already,
> I just need to fix a final bug and add firmware/pci ids. This has come up
> on linux-scsi a few times..
>
Ah thanks. Of course, as soon as I posted, I realized I should probably
have copied linux-scsi and/or gone and checked the archives there sigh.
Just getting back into the swing of things. If you need a tester, I'm
happy to do so on my setup.
> > This seems bad to me - either the original rmmod should fail with EBUSY,
> > or it should complete. However, for it to do so, it seems that st needs
> > to know that sg has its hooks into the device it controls, and it needs
> > to be able to make it let go. My workaround is impractical if sg is in
> > use on other devices too.
>
> I don't think we can fix much about this, it's how the driver model code
> works. Best workarond is to not use sg.
Hmmm... the problem was that it was autoloaded - I haven't gone and
checked the code yet, but it seems that unless you don't actually build
sg at all, it gets pulled in whether you want it or not. Now that the
ATA passthrough stuff works for CDRW etc., I actually have no good
reason to load it. It just seemed a little "sucky" - if I had tried to
e.g. rmmod qlogicisp, it would correctly fail because st depends on it.
It seems weak that an attempt to unload st didn't catch the hidden
dependency. Actually, it seems that a workaround with no side effects is
to 'echo 1 > /sys/class/scsi_device/.../delete' for the tape drive. That
frees things up and unhooks sg without unloading it.
Thanks,
Tim
prev parent reply other threads:[~2004-07-10 16:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-10 15:31 rmmod st "hangs" - bad interaction with sg Tim Wright
2004-07-10 15:41 ` Christoph Hellwig
2004-07-10 16:03 ` Tim Wright [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1089475422.1473.25.camel@tp-timw.internal.splhi.com \
--to=timw@splhi.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.