Date: Mon, 23 Aug 1999 02:04:39 -0700 (PDT) From: "Eugene M. Kim" <ab@astralblue.com> To: Soren Schmidt <sos@freebsd.dk> Cc: Nicolas Souchu <nsouch@teaser.fr>, freebsd-current@FreeBSD.ORG, soren@FreeBSD.ORG Subject: Re: problem with the ata driver Message-ID: <Pine.BSF.4.10.9908230036150.2242-100000@raista.pl.cp> In-Reply-To: <199908230627.IAA49585@freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Oh well. First of all I now feel a little more comfortable to see that I'm not alone. :-) I had same problem, and have tracked the problem down to some weird behavior of the CD-ROM drive that I have (which is also a LG one). And FYI, I have an Intel 82371FB-based PIIX controller (which supports the DMA transfer but is not supported by the ata driver). My dmesg output with modified patch (which will be explained later) and all ATA/ATAPI debug flags goes here: WARNING: "bktr" is usurping "bktr"'s cdevsw[] isab0: <Intel 82371FB PCI to ISA bridge> at device 7.0 on pci0 ata-pci0: <Intel PIIX IDE controller> at device 7.1 on pci0 ata-pci0: type=12308086 class=01 subclass=01 cmd=02800005 ata-pci0: Busmastering DMA supported ata0: iobase=0x01f0 altiobase=0x03f6 ata0: mask=03 status0=00 status1=00 ata0: mask=03 status0=00 status1=00 ata0: devices = 0x4 ata0 at 0x01f0 irq 14 on ata-pci0 ata1: iobase=0x0170 altiobase=0x0376 ata1: mask=00 status0=ff status1=ff ahc0: <Adaptec 2940 Ultra2 SCSI adapter> irq 11 at device 17.0 on pci0 ... (snip) ... ep0 XXX: driver didn't set ifq_maxlen ata0: ata_command: addr=01f0, device=00, cmd=a1, c=0, h=0, s=0, count=0, flags=01 ata_start: entered ata_command: leaving atapi: piomode=3, dmamode=1, udmamode=-1 ata0: dmainit: ioaddr=0x1f0 altioaddr=0x3f6, bmaddr=0x1000 atapi: PIO transfer mode set ata_start: entered atapi: trying to start MODE_SENSE cmd ata0: ata_command: addr=01f0, device=00, cmd=a0, c=28, h=0, s=0, count=0, flags=00 ata_command: leaving ata_start: started atapi, leaving atapi_interrupt: enter atapi_interrupt: length=24 reason=0x0b atapi_interrupt: command completion interrupt with DRQ atapi_interrupt: read size problem, 4 bytes residue atapi_interrupt: error=0x00 ata_start: entered atapi: phew, got back from asleep with wakeup atapi: acd: mode sense 0-16-04-00-00-00-00-00-2a-0e-00-00-71-6d-2d-03-02-c2-01-00-00-80-02-c2-00-00-00-00 acd0: <GCD-R540/1.17> CDROM drive at ata0 as master acd0: drive speed 689KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm photo disc loaded, unlocked, lock protected Waiting 2 seconds for SCSI devices to settle As seen here, instead of a data-in interrupt and a command completion interrupt, the drive (or the controller, I am not sure) is returning a single command completion interrupt with DRQ bit set (reason=0x0b). Since I don't have the ATA/ATAPI spec at hand I can't verify if this is an allowed behavior or not, but in my case reading and returning 24 bytes of data (as `length' suggests) works fine.2 The patch of sys/dev/ata/atapi-all.c that I used is available at http://home.astralblue.com/~ab/ata-patch/ (it is a little too big to include here); it also has some other minor fixes one of which uses asleep instead of tsleep to prevent an interrupt from being lost in the short window between splx and tsleep. BTW, my patch does not solve *all* problems that my drive has; if the kernel tries to read some data off the disc, the drive returns an `aborted command' error after two 512-byte blocks as in the following dmesg output (I have used `dd if=/dev/acd0c of=/dev/null bs=2k count=1' to produce this): ata_start: entered atapi: trying to start READ_BIG cmd ata0: ata_command: addr=01f0, device=00, cmd=a0, c=2048, h=0, s=0, count=0, flags=00 ata_command: leaving ata_start: started atapi, leaving atapi_interrupt: enter atapi_interrupt: length=512 reason=0x0a atapi_interrupt: enter atapi_interrupt: length=512 reason=0x0b atapi_interrupt: command completion interrupt with DRQ atapi_interrupt: error=0xb4 ata_start: entered atapi: phew, got back from asleep with wakeup ata_start: entered atapi: trying to start REQUEST_SENSE cmd ata0: ata_command: addr=01f0, device=00, cmd=a0, c=18, h=0, s=0, count=0, flags=00 ata_command: leaving ata_start: started atapi, leaving atapi_interrupt: enter atapi_interrupt: length=14 reason=0x0b atapi_interrupt: command completion interrupt with DRQ atapi_interrupt: read size problem, 4 bytes residue atapi_interrupt: error=0x00 ata_start: entered atapi: phew, got back from asleep with wakeup atapi_error: READ_BIG - ABORTED COMMAND skey=b asc=00 ascq=00 error=04 I guess that perhaps these LG CD-ROM drives are using some nonstandard or obsolete convention that the new ata driver doesn't understand. Unfortunately, I couldn't test the drive with the old wdc driver because it even didn't detect my drive (being the only IDE/ATAPI device, master on the primary controller). Thank you, Eugene On Mon, 23 Aug 1999, Soren Schmidt wrote: | It seems Nicolas Souchu wrote: | > acd0: <GCD-R520B/1.1> CDROM drive at ata0 as master | > acd0: drive speed 0KB/sec | > acd0: supported read types: | > acd0: Mechanism: caddy | > acd0: Medium: CD-ROM unknown medium | > | > Any clue? | > | > The drive was running flawlessly with the old wdc driver and with various | > primary releases of the new ata driver (some, not all). | | Hmm, looks like the timeout I've chosen for timing out on the probes | *might* be too short for some devices.. | | -Søren | | | To Unsubscribe: send mail to majordomo@FreeBSD.org | with "unsubscribe freebsd-current" in the body of the message | -- Eugene M. Kim <astralblue@astralblue.com> "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9908230036150.2242-100000>