Re: CSPPC UW-SCSI and CD/DVD drives

[Marcus C. <ma...@mc...>]

Ok, as promisied I started looking at the driver to see if I could
find something out.

I managed to get a real backtrace to throw at ksymoops this time:

>>NIP; c00fe184 <scsi_release_command+48/18c>   <=====
Trace; c3f53c14 <_end+3cf073c/45ddb88>
Trace; c00fe778 <scsi_wait_req+bc/d4>
Trace; c011448c <sr_disk_status+24/f0>
Trace; c011520c <sr_cd_check+e8/590>
Trace; c0112754 <sr_media_change+cc/10c>
Trace; c011686c <media_changed+64/b0>
Trace; c0116900 <cdrom_media_changed+48/60>
Trace; c003de7c <check_disk_change+54/d0>
Trace; c0115bc0 <cdrom_open+c0/11c>
Trace; c003e018 <do_open+b0/1f4>
Trace; c003e1c4 <blkdev_get+68/7c>
Trace; c003c8f0 <get_sb_bdev+f8/310>
Trace; c003d0b8 <do_kern_mount+b4/1dc>
Trace; c00516b0 <do_add_mount+2c/158>
Trace; c0051a68 <do_mount+180/194>
Trace; c0051b20 <sys_mount+a4/f4>
Trace; c0003e9c <ret_from_syscall_1+0/b4>
Trace; ffffffff <END_OF_CODE+3b7a9930/????>

Looking at the disassembly of scsi_release_command, I found that the
offending instruction was generated from the first atomic_dec()
invocation in the inline __scsi_release_command() function (in
scsi.c).

When the kernel oopses, SCpnt is 0xc2275d28 (which is suspicious in
itself, as all previous invocations have had pointers starting with
0xc3f) and SCpnt->host is NULL.  So, AFAICT, scsi_release_command()
was called with a phony SCpnt.  scsi_wait_req() gets the SCpnt it
calls scsi_release_command() with from SRpnt->sr_command.  Maybe this
field is not initialized/cleared appropriately somewhere?  I don't
have time to dig further into it right now, but maybe I'll give it
another shot tomorrow.


Btw, turning on DEBUG_NCR53C8XX, I noticed that there were _lots_ of
calls to ncr53c8xx_intr() even though no SCSI device was accessed at
all.  Is this intentional?  It could be a potential performance
problem perhaps?


  // Marcus