KERNEL: parsing /proc/scsi/scsi

[Saulius Krasuckas]

While running my wine I started getting this recently:

$ ./wine --version
| err:reg:SCSI_getprocentry SCSI type line scan count error
| Wine 0.9.1

Next:

$ uname -r
| 2.6.14-1.1637_FC4
$ cat /proc/scsi/scsi 
| Attached devices:
| Host: scsi0 Channel: 00 Id: 00 Lun: 00
|   Vendor: PLEXTOR  Model: DVDR   PX-712A   Rev: 1.04
|   Type:   CD-ROM                           ANSI SCSI revision: ffffffff

Next:

$ dmesg | grep -C1 PLEXTOR.*1.04
| scsi0 : SCSI host adapter emulation for IDE ATAPI devices
|   Vendor: PLEXTOR   Model: DVDR   PX-712A    Rev: 1.04
|   Type:   CD-ROM                             ANSI SCSI revision: 00

Strange difference.  If I search for a "ANSI SCSI revision" string, I get:

$ grr "ANSI SCSI revision" linux-2.6.14/
| linux-2.6.14/drivers/block/acsi.c:      printk("                 ANSI SCSI revision: %02x", data[2] & 0x07);
| linux-2.6.14/drivers/scsi/megaraid.c:   "                 ANSI SCSI revision: %02x", scsi_inq[2] & 0x07);
| linux-2.6.14/drivers/scsi/scsi_scan.c:  printk("                 ANSI SCSI revision: %02x",

I am not sure, why this happens, as I see no code which forms "scsi/scsi" 
proc-file content, but still I think it is bug in our parser:

$ grep -B6 "SCSI type line scan count error" dlls/kernel/oldconfig.c 
|     result = fscanf( procfile,
|         "  Type:%*3[ ]%32c%*1[ ]ANSI%*1[ ]SCSI%*1[ ]revision:%*1[ ]%d\n",
|         dev->type,
|         &dev->ansirev );
|     if( result != 2 )
|     {
|         ERR("SCSI type line scan count error\n");

where parser treats last number as a decimal one, while it is in 
hexadecimal format.

I would appreaciate explanation, why dmesg and /proc/scsi/scsi writer 
behaves in slightly different ways.

[Michael Druing]

Hi,
> $ cat /proc/scsi/scsi 
> | Attached devices:
> | Host: scsi0 Channel: 00 Id: 00 Lun: 00
> |   Vendor: PLEXTOR  Model: DVDR   PX-712A   Rev: 1.04
> |   Type:   CD-ROM                           ANSI SCSI 
> revision: ffffffff

Looks like a hardware problem to me. Bad cables, bad terminator, too long
cables, interference,...
SCSI is very sensitive so you might want to re-arrange drives on the cable
or try a different terminator.
It might even be enough to unplug and re-connect every SCSI device in the
system.
> where parser treats last number as a decimal one, while it is in 
> hexadecimal format.

Right now there's only ANSI SCSI 01, 02 and 03 defined (AFAIK) so other
values shouldn't happen...
> I would appreaciate explanation, why dmesg and /proc/scsi/scsi writer 
> behaves in slightly different ways.

--Michael