>From [EMAIL PROTECTED] Fri Apr 20 03:07:02 2001

>>         Note that ATAPI has no SCSI status byte but there is
>>         a IDE status bit that is used to signal the driver to
>>         fetch sense data. This bit is equivalent to CHECK_CONDITION
>>         in the SCSI status byte. So a conforming SCSI driver needs
>>         to emulate the CHECK_CONDITION bit (0x02) in the SCSI
>>         status byte in this case.
>> 
>>         Observed behaviour (with cdrecord -d):
>> 
>>         ioctl ret: 0
>>         host_status: 00 driver_status: 28
>>         cdrecord: Input/output error. read toc: scsi sendcmd: no error
>>         CDB:  43 00 00 00 00 00 00 00 04 00
>>         status: 0x0 (GOOD STATUS)
>>         cmd finished after 0.000s timeout 40s
>> 
>>         The driver status includes DID_SENSE but the SCSI status is 0!

>It has been like this for a long time, probably as long as
>there has been a ide-scsi driver in Linux. I have asked the
>maintainer to "fix" it but he said that it is difficult.
>This has been documented in sg for several years. Here
>is a snippet from sg.h :

>    unsigned char sense_buffer[SG_MAX_SENSE]; /* [o] Output in 3 cases:
>           when target_status is CHECK_CONDITION or
>           when target_status is COMMAND_TERMINATED or
>           when (driver_status & DRIVER_SENSE) is true. */

>Note the last line of the comment.
>Unfortunately nothing has changed in this respect in lk 2.4 .
> 
>>         This causes cdrecord not wo work properly in all cases - please fix
>>         as soon as possible.

>Cdrecord handled this in the past. It is less than ideal
>but cdrecord can use the same logic to handle this
>situation in the future.

Well the comment in the Linux lowlevel part for libscg is not 100% clear
about the reason for this bug. In addition, my comment states that
it was only present up to Linux-2.1.xxx

> 
>>         Check/Repeat with the scgcheck program!

>??

Scgcheck is part of cdertools. It is an ABI checker for the combined behaviour
of the Kernel and libscg.

It tests the correctness of the behaviour of libscg Application Binary interface.
If scgcheck finds noncompliances, there are either problems in the libscg
adaption layer or in the OS itself. The adoption layer is needed to
have a unique ABI for all OS.

The interface of libscg is based on the interface my scg driver for SunOS
which I wrote in 1986 long before other people even thought about user level 
SCSI transport. As this interface is still superior to most other interfaces
and as the scg intgeface did not change sinde 1986, this makes sense.


If you run scgcheck on Linux I would expect to see only noncompliance warnings
caused by bugs or missing features inside Linux.

> 
>> -       The fatal bug is that Linux 2.4.2-4GB dies on a
>>         DMA overrun situation.
>> 
>>         My observed behaviour was that the machine freezes and
>>         a ping from another machine is not answered anymore.

>Again this doesn't sound like a sg problem. More likely
>it is a HBA driver problem. I expect the data overrun
>case (as distinct from the more common data underrun case)
>is not well tested on all adapter drivers. Which adapter
>driver were you using? If it was the aic7xxx, it may be
>worth trying the new one introduced in lk 2.4.3 .

This is why I send this report to Alan too. I don't know where
the problem comes from.

BTW, I hope this

ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 21
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:04.1
    ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio
hda: WDC WD400BB-00AUA1, ATA DISK drive
VP_IDE: Calibrating PCI clock ... 32.76 MHz

helps.


Jörg

 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
       [EMAIL PROTECTED]               (uni)  If you don't have iso-8859-1
       [EMAIL PROTECTED]           (work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to