From owner-freebsd-current Mon Aug 23 11:39:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from astralblue.com (adsl-209-76-108-39.dsl.snfc21.pacbell.net [209.76.108.39]) by hub.freebsd.org (Postfix) with ESMTP id 7FE5815783; Mon, 23 Aug 1999 11:39:48 -0700 (PDT) (envelope-from ab@astralblue.com) Received: from raista.pl.cp (raista.pl.cp [10.0.0.14]) by gw1.pl.cp (8.9.3/8.9.3) with ESMTP id LAA27944; Mon, 23 Aug 1999 11:26:03 -0700 (PDT) (envelope-from ab@astralblue.com) Received: from localhost (ab@localhost) by raista.pl.cp (8.9.3/8.9.3) with ESMTP id CAA02843; Mon, 23 Aug 1999 02:04:40 -0700 (PDT) (envelope-from ab@astralblue.com) X-Authentication-Warning: raista.pl.cp: ab owned process doing -bs Date: Mon, 23 Aug 1999 02:04:39 -0700 (PDT) From: "Eugene M. Kim" X-Sender: ab@raista.pl.cp To: Soren Schmidt Cc: Nicolas Souchu , freebsd-current@FreeBSD.ORG, soren@FreeBSD.ORG Subject: Re: problem with the ata driver In-Reply-To: <199908230627.IAA49585@freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=euc-kr Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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: at device 7.0 on pci0 ata-pci0: 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: 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: 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: 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 "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