lkml.org 
[lkml]   [1998]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Panic in scsi.c ( and a fix)
Hello,

I am still trying to get to the bottom of the
problem caused by the two dd copy commands running in
parallel against two CDs in Nakamichi SCSI CD changer device.

Ishikawa wrote:


> (4) THE SAME CHANGE NECESSARY(?): request_device() in scsi.c
>

All the previous references to request_device() are typos:
I meant request_queueable().


> The fix for allocate_device() changes the checking logic slightly.
> It turns out that the request_device() somewhere above the
> allocate_device() in scsi.c has EXACTLY the same loop.
> Shouldn't allocate_device() be changed in a similar manner?
>
> I temporaily modified the allocate_device() routine in a similar
> manner. The mods don't seem to have adverse effect at all.
> (I mean I tested this for an hour so with "ls -lR" on mounted
> CDs in paralle, etc..)
>

I think I found a potential problem in allocate_device().
The variable found is initialized to NULL at the beginning of
function.
The general flow of the main loop of allocate_device() is
as follows.
I wonder if `found' ought to be re-initialized to NULL
before entering in the "while loop on SCpnt"?
[It could be that the initialization value may have to
be dependent on the previous value of `found' and target_busy
value in Waltham patch.]

... found = NULL; /* initial value */

while(1==1)
{
if(!single_lun)
{
...
}
else
{

/* Should we re-initialize `found' here? */

while loop on SCpnt
{

}
...
}
...
}

Observation:
Before, the testing using

dd if=/dev/scd2 of=/dev/null &
dd if=/dev/scd3 of=/dev/null

always made the system hung.

After a temporary patch to re-initialize found to "NULL"
in the above mentioned place, I tested the above
command sequence 5 times. At one time, the system
didn't get hung, but proceeded
to copy data as expected [I deduced this since the CD media
access took place as expected. When the system got hung, nothing
happened.] However, even in this single case, when I interrupted the
dd with control-C to avoid seeing the excessive amount of
printk() output on the console, after the ^C was typed,
it seemed that the SCSI sub-system again entered problematic
state where the tight-loop in the
allocate_device() stopped the kernel.
[This was with Waltham patch and the patch of request_queueable()
as mentioned before.]

I hope this information will be helpful for someone who knows
the innards of the scsi subsystem in figuroing out the real cause
of the problem.

Happy Hacking

Chiaki Ishikawa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.066 / U:1.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site