I burned a CD, apparently without problem, then tried to run md5sum.
Jul 19 21:28:15 dugite kernel: Detected scsi CD-ROM sr0 at scsi0,
channel 0, id 3, lun 0
Jul 19 21:28:15 dugite kernel: sr0: scsi3-mmc drive: 16x/16x writer
cd/rw xa/form2 cdda tray
Jul 19 21:32:56 dugite kernel: scsi0: ERROR
Hi List,
If I decide that I do not want to depend on io_request_lock
to maintain the consistency of the data structures in my driver,
then do I ever need to acquire this lock and release it in the driver ?
e.g. Do I need to acquire io_request_lock before I call the done() routine
and release it a
"MEHTA,HIREN (A-SanJose,ex1)" wrote:
>
> Hi List,
>
> If I decide that I do not want to depend on io_request_lock
> to maintain the consistency of the data structures in my driver,
> then do I ever need to acquire this lock and release it in the driver ?
> e.g. Do I need to acquire io_request_lo
Edouard,
I work for the division that actually produces these products. We
regularly test using various Linux kernels, and Adaptec controllers. If
fact, a whole chunk of our test system depends on Linux as it's the only OS
that'll do 16Mb contiguous transfers, so trust me when I say, the
On Thu 2001-07-19 (17:47), FALKINDER,DAVID (HP-UnitedKingdom,ex2) wrote:
> Edouard,
>
>
> I work for the division that actually produces these products. We
> regularly test using various Linux kernels, and Adaptec controllers. If
> fact, a whole chunk of our test system depends on Linux as
Hi List,
For BDR(bus device reset) case scsi_unjam_host does
not restart the multiple commands failed for the same
device instead of one.So automatically host_failed!=0
and it kicks off Bus_reset which should not be the
case.Unless all the commands failed for that
particular device has been rest
> Yes, the done() function needs to be wrapped (this isn't so much because
it
> actually needs it as it is that you are calling mid layer code and you
need to
> adhere to what it tells you locking semantics are, which in this case is
> "always hold the io_request_lock because that's how I keep my
Well, I guess the problem is that : scsi layer does not know whether the
hba driver will do its own locking and release io_request_lock or not.
Before calling any entry point, scsi layer is anyway acquires
io_request_lock.
Also, if you are depending on the io_request_lock, then in the interrupt
h
>As things currently stand there is no API function to do this. Just
> resetting the host_blocked flag wouldn't be enough - if there were
pending
> items in the queue a new entry would not be added until such a time as
> something new was inserted.
>
> That being said, there probably need
> Well, I guess the problem is that : scsi layer does not know whether the
> hba driver will do its own locking and release io_request_lock or not.
> Before calling any entry point, scsi layer is anyway acquires
> io_request_lock.
> Also, if you are depending on the io_request_lock, then in the i
"MEHTA,HIREN (A-SanJose,ex1)" wrote:
>
> Well, I guess the problem is that : scsi layer does not know whether the
> hba driver will do its own locking and release io_request_lock or not.
> Before calling any entry point, scsi layer is anyway acquires
> io_request_lock.
> Also, if you are dependin
I wrote:
[...]
>
> 2) I tried to do MOD_INC_USE_COUNT when more than zero SCSI commands
> become outstanding and MOD_DEC_USE_COUNT when zero scsi commands are
> outstanding. But, I can seemingly still manage to unload the driver
> while some processes is accessing a SCSI device. (Sometimes it
Hi.
The following patch makes drivers/scsi/gdth.c check the return code
of scsi_allocate_device(). It applies against 246ac5 and was
raised in a posting from the Stanford team a while ago.
--- linux-246-ac5-clean/drivers/scsi/gdth.c Wed Jun 20 20:19:02 2001
+++ linux-246-ac5/drivers/scsi/gd
Hi.
The following patch makes drivers/scsi/gdth_proc.c check the
return code of scsi_allocate_device(). It applies against
246ac5 and was raised in a posting from the Stanford team
a while ago.
--- linux-246-ac5-clean/drivers/scsi/gdth_proc.cSun May 20 02:43:06 2001
+++ linux-246-ac5
I feel this problem raised because I was using a wrong SCSI cable
between the Linux box and the extenral LTO device.
I switched on a 160MB certified cable of 1 meter and the system
is working fine now.
The HP Ultrium and the Python are connected on separate SCSI
channels, so the transfer speed o
I'm getting ready to do a 2.4.7, but one of the fixes in 2.4.7 is a nasty
SMP race that was found and made it clear that using an old trick of
having a semaphore on the stack and doing "down()" on it to wait for some
event (that would do the "up()") was a really bad idea.
This kind of trick was
On Thu, Jul 19 2001, Linus Torvalds wrote:
>
> I'm getting ready to do a 2.4.7, but one of the fixes in 2.4.7 is a nasty
> SMP race that was found and made it clear that using an old trick of
> having a semaphore on the stack and doing "down()" on it to wait for some
> event (that would do the "u
17 matches
Mail list logo
