headers
Doug Ledford | 1 Nov 2003 01:02
Picon
Favicon

Re: [PATCH] sym53c8xx PPR negotiation fix

On Fri, 2003-10-31 at 18:55, Justin T. Gibbs wrote:
> > Yeah, the appropriate time to check that bit would be at
> > slave_configure() time.  (Hmmm...I should have documented that...)
> 
> BTW, slave_destroy() doesn't seem to be called after a probe
> for a target fails due to a selection timeout.  Is this the
> expected behavior?  I only keep persistent allocations after
> slave_configure() is called, so this doesn't affect my drivers,
> but the behavior isn't what I expected.  This is 2.6.0-test9.

I haven't been able to follow 2.5/2.6 SCSI stuff as close as I wanted,
but originally I thought it did call slave_destroy() even if it never
called slave_configure()....hmmm...maybe I should go check my stuff back
then...I could be wrong on that.

--

-- 
  Doug Ledford <dledford <at> redhat.com>     919-754-3700 x44233
         Red Hat, Inc.
         1801 Varsity Dr.
         Raleigh, NC 27606

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Doug Ledford | 1 Nov 2003 01:08
Picon
Favicon

Re: [PATCH] sym53c8xx PPR negotiation fix

On Fri, 2003-10-31 at 18:55, James Bottomley wrote:
> On Fri, 2003-10-31 at 17:55, Justin T. Gibbs wrote:
> > BTW, slave_destroy() doesn't seem to be called after a probe
> > for a target fails due to a selection timeout.  Is this the
> > expected behavior?  I only keep persistent allocations after
> > slave_configure() is called, so this doesn't affect my drivers,
> > but the behavior isn't what I expected.  This is 2.6.0-test9.
> 
> Yes.
> 
> slave_configure is only called if the mid-layer decides there's
> something worth attaching to there (i.e. if the initial inquiry
> succeeds); otherwise it just calls slave_destroy to signal loss of
> interest in the target.

That's exactly what Justin was saying *isn't* happening (aka, no target
is there, we *don't* call slave_destroy is what Justin said).

--

-- 
  Doug Ledford <dledford <at> redhat.com>     919-754-3700 x44233
         Red Hat, Inc.
         1801 Varsity Dr.
         Raleigh, NC 27606

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 10 comments |
headers
Justin T. Gibbs | 1 Nov 2003 01:16

Re: [PATCH] sym53c8xx PPR negotiation fix

>> slave_configure is only called if the mid-layer decides there's
>> something worth attaching to there (i.e. if the initial inquiry
>> succeeds); otherwise it just calls slave_destroy to signal loss of
>> interest in the target.
> 
> That's exactly what Justin was saying *isn't* happening (aka, no target
> is there, we *don't* call slave_destroy is what Justin said).

It seems the slave_destroy is missing from scsi_free_sdev().

--
Justin

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 9 comments |
headers
Pat LaVarre | 1 Nov 2003 01:51
Picon

Re: [PATCH] CDC_MMC_WR

> My 2003-10-13 -test7 patch,
> with the q=raw suffix included
> to help ask for hard tabs etc. intact, appears archived as:

Bzzzzt.  Wrong link, sorry.

To see that 2.6.0-test7 patch that works -test8 or -test9 as well, the
correct link into the depths of history is:

http://marc.theaimsgroup.com/?l=linux-scsi&m=106605749929120&q=raw

I know this because now for a friend I'm trying to apply this patch to
2.4.22.

Pat LaVarre

P.S. Of course unless you add an eol to the linux-scsi majordomo
signature, you will be warned: "patch unexpectedly ends in middle of
line".

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 668 comments |
headers
Pat LaVarre | 1 Nov 2003 02:22
Picon

[PATCH] Backport CDC_MMC_WR

Jens A:

I have not yet seen you comment.

> To see that 2.6.0-test7 patch that works -test8 or -test9 as well ...
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106605749929120&q=raw

With the inline plain text patch below, 2.4.22 seemingly works too, if
we transliterate to 2.4 syntax from 2.6 syntax.  Also here you can see I
added some cdinfo %s cdi->name.  I imagine we want those in 2.6.1 as
well.

Personally I'm still too ignorant to know how to test for trouble, if by
chance a patch of mine declares a /dev/scd$n writable that actually is
not writable.

Pat LaVarre

diff -Nur linux-2.4.22/drivers/cdrom/cdrom.c linux/drivers/cdrom/cdrom.c
--- linux-2.4.22/drivers/cdrom/cdrom.c	2002-11-28 16:53:12.000000000 -0700
+++ linux/drivers/cdrom/cdrom.c	2003-10-31 18:04:41.005317408 -0700
 <at>  <at>  -310,6 +310,7  <at>  <at> 
 #define CHECKAUDIO if ((ret=check_for_audio_disc(cdi, cdo))) return ret

 /* Not-exported routines. */
+static void cdrom_get_cdc(struct cdrom_device_info *cdi);
 static int open_for_data(struct cdrom_device_info * cdi);
 static int check_for_audio_disc(struct cdrom_device_info * cdi,
 			 struct cdrom_device_ops * cdo);
 <at>  <at>  -402,6 +403,8  <at>  <at>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Anderson | 1 Nov 2003 02:22
Picon
Favicon

Re: [PATCH] sym53c8xx PPR negotiation fix

Justin T. Gibbs [gibbs <at> scsiguy.com] wrote:
> >> slave_configure is only called if the mid-layer decides there's
> >> something worth attaching to there (i.e. if the initial inquiry
> >> succeeds); otherwise it just calls slave_destroy to signal loss of
> >> interest in the target.
> > 
> > That's exactly what Justin was saying *isn't* happening (aka, no target
> > is there, we *don't* call slave_destroy is what Justin said).
> 
> It seems the slave_destroy is missing from scsi_free_sdev().

It is called from scsi_remove_device.

-andmike
--
Michael Anderson
andmike <at> us.ibm.com

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 8 comments |
headers
James Bottomley | 1 Nov 2003 03:34
Favicon

Re: [PATCH] sym53c8xx PPR negotiation fix

On Fri, 2003-10-31 at 19:22, Mike Anderson wrote:
> It is called from scsi_remove_device.

But that's only called for configured devices.  The original intent was
to call slave_destroy for all slave_alloc'd devices (whether configured
or not).

It originally was in scsi_free_sdev, but was moved with

ChangeSet 1.1046.597.3 2003/08/02 12:17:19 andmike <at> us.ibm.com
  [PATCH] scsi host / scsi device ref counting take 2 [3/3]

The changelog isn't very explicit about why this was done, what was the
particular reason?

James

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 7 comments |
headers
Doug Ledford | 1 Nov 2003 04:09
Picon
Favicon

Re: [PATCH] sym53c8xx PPR negotiation fix

On Fri, 2003-10-31 at 21:34, James Bottomley wrote:
> On Fri, 2003-10-31 at 19:22, Mike Anderson wrote:
> > It is called from scsi_remove_device.
> 
> But that's only called for configured devices.  The original intent was
> to call slave_destroy for all slave_alloc'd devices (whether configured
> or not).
> 
> It originally was in scsi_free_sdev, but was moved with
> 
> ChangeSet 1.1046.597.3 2003/08/02 12:17:19 andmike <at> us.ibm.com
>   [PATCH] scsi host / scsi device ref counting take 2 [3/3]
> 
> The changelog isn't very explicit about why this was done, what was the
> particular reason?

It really should be called on all devices, not just configured devices. 
The assumption that a device driver doesn't need to allocate local
storage to even do something as simple as INQUIRY and can wait until
slave_configure() to allocate anything is an invalid assumption.  In
fact, when I originally was working on this I think I modified the
aic7xxx_old driver to get rid of as much static array type data as
possible and move it to a struct allocated in slave_alloc.  Whether the
device is kept or not, it still has to alloc to work.  At one point
there was also another optimization in there so that if a driver didn't
do anything besides simply kfree() the memory pointed to by
sdptr->hostdata then you could skip defining a slave_destroy() function
and instead just let scsi_free_sdev do a simple kmalloc for you.  I
think that was argued against as a special case just confuses people,
can't remember.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell King | 1 Nov 2003 13:56
Picon

2.6.0-test9: BUG: partitions added twice

Ok, more SCSI problems...

I've just booted 2.6.0-test9 again on this machine, and, having got
the scsi_dev_info parameter wrong again, it decided to go and try
to spin up the non-existent disk in the syquest drive again.

So, rather than wait the 5 or so minutes for the kernel to eventually
get the idea that it can't, I decided to put a cartridge in.  I was
then greeted by the following:

scsi0 : PowerTec SCSI (QLogic FAS216) in slot 0 v1.10 (19/01/2003 2.5.59) terminators on
  Vendor: SONY      Model: SDT-5200          Rev: 3.30
  Type:   Sequential-Access                  ANSI SCSI revision: 02
  Vendor: SyQuest   Model: SQ3270S           Rev: 3-14
  Type:   Direct-Access                      ANSI SCSI revision: 02
sda: Spinning up
disk................................................................................................not responding...
sda : READ CAPACITY failed.
sda : status=1, message=00, host=0, driver=08
Current sd?: sense key Not Ready
Additional sense: Logical unit not ready, cause not reportable
sda: Write Protect is off
sda: Mode Sense: 99 00 00 08
SCSI device sda: drive cache: write back
sda: Spinning up disk...........................................ready
SCSI device sda: 524288 512-byte hdwr sectors (268 MB)
sda: Write Protect is off
sda: Mode Sense: 99 00 00 08
SCSI device sda: drive cache: write back
SCSI device sda: 524288 512-byte hdwr sectors (268 MB)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell King | 1 Nov 2003 14:13
Picon

Re: 2.6.0-test9: scsi_dev_flags

On Sun, Oct 26, 2003 at 08:38:50AM -0800, Patrick Mansfield wrote:
> On Sun, Oct 26, 2003 at 02:47:41PM +0000, Russell King wrote:
> 
> > So, I then tried doing exactly that:
> > 
> > 	scsi_dev_flags=SyQuest:SQ3270S:4096
> 
> If that is the kernel boot line, you need to prefix the argument with
> scsi_mod., i.e. scsi_mod.scsi_dev_flags=, per the module_param
> interface(s).
> 
> > An additional question comes out from this - if quirk information is now
> > to be passed on the kernel command line, how are users supposed to work
> > out the correct command line argument to give for their quirky hardware
> > given that it doesn't appear to be as trivial as the code suggests?
> > (IOW, the scsi_dev_flags option appears to be rather undocumented!)
> 
> There is a bit in Documentation/kernel-parameters.txt, but there should be
> more documentation added somewhere. Also the integer value can be hex
> (0x1000).

Ok, I've tried scsi_mod.scsi_dev_flags= and the kernel whinges:

Unknown boot option `scsi_mod.scsi_dev_flags=SyQuest:SQ3270S:4096': ignoring

and it still wants to spin up the drive (I ended up allowing it during
the first spinup attempt):

sda: Spinning up disk...................ready
SCSI device sda: 524288 512-byte hdwr sectors (268 MB)
(Continue reading)

Permalink | Reply | 1 comment |

Gmane