Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

MFC of ATA driver from -current finished, please test..

0 views
Skip to first unread message

Jochem Kossen

unread,
Mar 18, 2002, 11:58:21 AM3/18/02
to
On Mon, Mar 18, 2002 at 09:44:58AM +0100, S?ren Schmidt wrote:
>
> Well, subject says it all, the ATA driver in -stable is now functionally
> identical to that in -current.
> Please let me know asap if you encounter any (new) problems with the
> ATA driver after this commit.
>
> Thanks goes to all that have helped testing this over the last weeks,
> and especially to Advanis for sponsoring this important work.
>

Here are my results for burncd...

The -d (DAO) option caused each track to begin while the time of the
previous track hadn't even finished. So, for example, when you start
playing track 3, it misses the beginning, which is at the end of track
2...

The -n option didn't make any difference.

Without the -d option, it burns the tracks right, but at the end of each
track, a loud "tick" is heard at the *END* of each track (no, this isn't
the WAV header at the beginning of the track, i use headerless WAV (raw
WAV) files, and the tick is much louder than that). It did this too
before the ATA MFC, so it's an old problem. I've never reported it
before though.

This all happens with burning headerless WAV (raw wav) files, at 4
speed. The burner can't burn at a lower speed.

When using the ATAPICAM patches and cdrecord instead of burncd, the
burner burns correctly.

Any ideas?

Thanks,

Jochem

To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message

Nuno Teixeira

unread,
Mar 18, 2002, 5:23:56 PM3/18/02
to

Hi,

I had a similar problem when I test the second patch.

I post my problem on Mars, 11 (Subject: Re: Request for testers of
MFC'd ATA driver take 2.) from nun...@pt-quorum.com on freebsd-stable list.

Bye,


--
Nuno Teixeira
pt-quorum.com

/*
PGP Public Key:
http://www.pt-quorum.com/pgp/nunoteixeira.asc
Fingerprint:
AF91 4AC0 85CB 272A 5441 E02F 5D84 ED9D 34D5 9145
*/

Brian T.Schellenberger

unread,
Mar 18, 2002, 7:07:50 PM3/18/02
to
On Monday 18 March 2002 11:57 am, Jochem Kossen wrote:
| On Mon, Mar 18, 2002 at 09:44:58AM +0100, S?ren Schmidt wrote:
| > Well, subject says it all, the ATA driver in -stable is now functionally
| > identical to that in -current.
| > Please let me know asap if you encounter any (new) problems with the
| > ATA driver after this commit.
| >
| > Thanks goes to all that have helped testing this over the last weeks,
| > and especially to Advanis for sponsoring this important work.
|
| Here are my results for burncd...
|
| The -d (DAO) option caused each track to begin while the time of the
| previous track hadn't even finished. So, for example, when you start
| playing track 3, it misses the beginning, which is at the end of track
| 2...

I've never used this option . . .

| The -n option didn't make any difference.
|
| Without the -d option, it burns the tracks right, but at the end of each
| track, a loud "tick" is heard at the *END* of each track (no, this isn't
| the WAV header at the beginning of the track, i use headerless WAV (raw
| WAV) files, and the tick is much louder than that). It did this too
| before the ATA MFC, so it's an old problem. I've never reported it
| before though.

but I have burned music CDs both with & without the ATA update (I was one of
the folks who tested it before it was merged), and I don't get this
phenomenon, so it's something specific to your setup and/or hardware.

FWIW, I have a

acd0: CD-RW <TOSHIBA CD-RW/DVD-ROM SD-R2002> at ata0-slave WDMA2

|
| This all happens with burning headerless WAV (raw wav) files, at 4
| speed. The burner can't burn at a lower speed.
|
| When using the ATAPICAM patches and cdrecord instead of burncd, the
| burner burns correctly.
|
| Any ideas?
|
| Thanks,
|
| Jochem
|
| To Unsubscribe: send mail to majo...@FreeBSD.org
| with "unsubscribe freebsd-stable" in the body of the message

--
Brian T. Schellenberger . . . . . . . b...@wnt.sas.com (work)
Brian, the man from Babble-On . . . . b...@babbleon.org (personal)
ME --> http://www.babbleon.org
http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org

Tod McQuillin

unread,
Mar 23, 2002, 3:23:40 AM3/23/02
to
On Mon, 18 Mar 2002, Søren Schmidt wrote:

> Please let me know asap if you encounter any (new) problems with the
> ATA driver after this commit.

I have a Digital Celebris 6200 (PPro 200MHz) with an Orinoco isa<->pcmcia
bridge and an Orinoco 802.11b card.

Using STABLE before the new ATA driver was committed the ata controller
was probed like this:

atapci0: <Intel PIIX3 ATA controller> port 0xecd0-0xecdf at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0-master: DMA limited to UDMA33, non-ATA66 compliant cable
ad0: 76319MB <ST380021A> [155061/16/63] at ata0-master WDMA2
acd0: CDROM <TOSHIBA CD-ROM XM-5602B> at ata0-slave using PIO3

Usinng the new driver it is probed like this:

atapci0: <Intel PIIX3 ATA controller> port 0xecd0-0xecdf at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
ad0: 76319MB <ST380021A> [155061/16/63] at ata0-master WDMA2
acd0: CDROM <TOSHIBA CD-ROM XM-5602B> at ata0-slave PIO3

I have no devices on ata1 and before the new ata driver I was not even
aware that it existed. Up until now I have been happily using irq 15 for
wi0 (the Orinoco card).

With the new driver probing ata1 at irq15, pccardd will not use the wi
card, complaining "Failed to allocate IRQ for Lucent Technologies".

If I run "atacontrol detach 1", then pccardd will allocate IRQ 15 for wi0
and everything works as before.

Now I have added "atacontrol detach 1" in /etc/rc.pccard right before the
"pccardc pccardmem" command, and the system boots up with wi0 and
everything works fine.

My questions are,

1) Is this the way it's supposed to work?

2) Is there any way to disable probing of ata1 at boot time? (My bios
setup did not seem to provide any explicit way of disabling it)

3) Does my workaround of running "atacontrol detach 1" from rc.pccard seem
like a reasonable workaround?

4) If the answer to 2 is no and the answer to 3 is yes, should this be
made configurable via a variable in rc.conf?

Thanks,
--
Tod McQuillin

0 new messages