Sound stoppage

Sound stoppage

[Michael R. Zucca]

I'm having a problem with sound stopping when I'm trying to use it at the
same time as X.

Machine lowdown:
PowerCenter 132 with a Sonnet 750 upgrade.
Adaptec Narrow Ultra SCSI PCI card.
XCLAIM VR Rage PRO PCI card (_not_ a VR128)

The problem occurs both with the 2.2.18 kernel that comes with the last
stable LinuxPPC install and with the most recent 2.2 snapshot that I could
get my hands on (sometime around last week). X is the stock XF68 that comes
with LinuxPPC (3.3.6 I think?)

I notice that I can play audio using XMMS or plaympeg but the sound stops
after a little while. I can force the stoppage to happen sooner when I drag
an opaque window around a lot so I think it has something to do with
generating heavy PCI traffic.

The stoppage seems to be screwing up the driver because the application
playing the sound is usually locked up pretty hard but the rest of the
processes keep running just fine. Perhaps we're dropping an interrupt
somewhere and the driver's stuck waiting?

Thanks!


____________________________________________________________________
 Michael Zucca - mrz5149@acm.org - http://www.mdc.net/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
____________________________________________________________________


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Hollis R Blanchard]

On Sun, 25 Mar 2001, Michael R. Zucca wrote:
>
> I'm having a problem with sound stopping when I'm trying to use it at the
> same time as X.
>
> Machine lowdown:
> PowerCenter 132 with a Sonnet 750 upgrade.

I used to have this problem, also on a PowerCenter 132.

I haven't used that machine in a while, but I believe such problems were
fixed with Iain Sandoe's dmasound patches & backport. I don't remember the
link offhand; check http://penguinppc.org/dev/pmac.

-Hollis


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Iain Sandoe]

Mon, Mar 26, 2001,  Hollis R Blanchard wrote:
> On Sun, 25 Mar 2001, Michael R. Zucca wrote:
>>
>> I'm having a problem with sound stopping when I'm trying to use it at the
>> same time as X.
>>
>> Machine lowdown:
>> PowerCenter 132 with a Sonnet 750 upgrade.
>
> I used to have this problem, also on a PowerCenter 132.
>
> I haven't used that machine in a while, but I believe such problems were
> fixed with Iain Sandoe's dmasound patches & backport. I don't remember the
> link offhand; check http://penguinppc.org/dev/pmac.

the last 2.2.x stuff is linked from: (and also via penguinppc.org).

http://www.drfruitcake.com/linux/linuxppc.html

*note* there is a dbdma problem that is *not* fixed with the ed21 patch to
2.2.18. (one day I'll apply the 2.4.x stuff back to the 2.2.18) - or if
someone else is interested in trying a merge - I can point them in the right
direction.

===== as of now...

You'd be better off with 2.4.x: (patches + a kernel binary/mods at)

ftp://ftp.penguinppc.org/users/iain/kernel/2_4_x/

==== Gotchas that remain:

1/ the 2.4.x patches will not build-in (stupid mistake on my part - I
renamed a CONFIG_XXX - but not everywhere - oops).

2/ Some PowerCenter machines have a dbdma problem (hardware-related) in
addition to those fixed in the 2.4.x patches.  There is a fix for this "in
the works" - sorry it's a bit slow coming (there's a few waiting) but I'm a
bit bogged down in rent-paying work ATM :-(.

I'll post as soon as the PowerCenter fix is avail.

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[phandel]

On Sun, 25 Mar 2001, Michael R. Zucca wrote:

> I'm having a problem with sound stopping when I'm trying to use it at the
> same time as X.

I've been noticing this problem for years with my PowerCenter Pro 210, and
it still occurs with 2.4.x.  I do have a 2.2.10 Cort built that does not
have this bug, although we can't figure out what was different.

By the way, try moving your mouse slowly while music is playing, as fast
mouse movements / window drags acerbate this bug.


Thanks,
Peter


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Michael R. Zucca]

At 4:58 AM -0500 3/27/01, phandel@cise.ufl.edu wrote:
>On Sun, 25 Mar 2001, Michael R. Zucca wrote:
>
>> I'm having a problem with sound stopping when I'm trying to use it at the
>> same time as X.
>
>I've been noticing this problem for years with my PowerCenter Pro 210, and
>it still occurs with 2.4.x.  I do have a 2.2.10 Cort built that does not
>have this bug, although we can't figure out what was different.
>
>By the way, try moving your mouse slowly while music is playing, as fast
>mouse movements / window drags acerbate this bug.

I'd be willing to bet this is the dbdma bug Iain mentioned. Like the dma
controller's getting wedged and the driver waits and waits for it to
complete a transaction. I can wait for the fix.

Thanks everybody!

____________________________________________________________________
 Michael Zucca - mrz5149@acm.org - http://www.mdc.net/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
____________________________________________________________________


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Takashi Oe]

On Tue, 27 Mar 2001, Michael R. Zucca wrote:

> I'd be willing to bet this is the dbdma bug Iain mentioned. Like the dma
> controller's getting wedged and the driver waits and waits for it to
> complete a transaction. I can wait for the fix.

It sounds exactly like the bmac bug.  So changing pmac_awacs_tx_intr()
from

	while (write_sq.active > 0) {
		...
		if ((stat & ACTIVE) == 0)
			break;	/* this frame is still going */
		...
	}

to

	while (write_sq.active > 0) {
		...
		if ((stat & ACTIVE) == 0) {
			if (cp == bus_to_virt(in_le32(&awacs_txdma->cmdptr)))
				break;
		}
		...
	}

fixes it or something?


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Iain Sandoe]

 Tue, Mar 27, 2001, Takashi Oe wrote:
> On Tue, 27 Mar 2001, Michael R. Zucca wrote:
>
>> I'd be willing to bet this is the dbdma bug Iain mentioned. Like the dma
>> controller's getting wedged and the driver waits and waits for it to
>> complete a transaction. I can wait for the fix.
>
> It sounds exactly like the bmac bug.  So changing pmac_awacs_tx_intr()
> from
>
>  while (write_sq.active > 0) {
>   ...
>   if ((stat & ACTIVE) == 0)
>    break; /* this frame is still going */
>   ...
>  }
>
> to
>
>  while (write_sq.active > 0) {
>   ...
>   if ((stat & ACTIVE) == 0) {
>    if (cp == bus_to_virt(in_le32(&awacs_txdma->cmdptr)))

this would not work on dmasound because it is possible to get interrupts
when blocks are still in progress without requiring error handling (e.g. a
dbdma FLUSH command).

we need to detect "DEAD" status for the PowerComputing problem.

>     break;
>   }
>   ...
>  }
>
> fixes it or something?

With ethernet it's OK to re-send a packet because the physical layer is
expected to be unreliable...

unfortunately it doesn't work for the sound devices...

This is because part of the dma block has already been sent - and if you
re-send that part is *really* messes the sound/sound sync up.

In fact, with the dmasound driver (on Power Compouting machines), you have
to detect the "DEAD" status on the controller - which seems to come up when
IDE interacts with sound.

I've got as fix coded which uses an 'emergency' dbdma block to retry the
command (but with adjusted pointers and count to reflect what is left).

Of course, the sound is affected a bit anyway - but (especially where sync
with video or something is important) - the 'emergency block' method is the
best we can do to maintain some smoothness.

I'll try and get this patch out ASAP.

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Takashi Oe]

On Tue, 27 Mar 2001, Iain Sandoe wrote:

> >  while (write_sq.active > 0) {
> >   ...
> >   if ((stat & ACTIVE) == 0) {
> >    if (cp == bus_to_virt(in_le32(&awacs_txdma->cmdptr)))
>
> this would not work on dmasound because it is possible to get interrupts
> when blocks are still in progress without requiring error handling (e.g. a
> dbdma FLUSH command).

I agree that it doesn't help the PowerComputing problem, but I do think
that just checking xfer_status is not very reliable on DBDMA.

> we need to detect "DEAD" status for the PowerComputing problem.

Ok, ok, this is a totally different problem then.  In the case of bmac,
the packet had been transmitted without an error, and DBDMA had moved on
to subsequent commands (if any).  It's just that "xfer_status" field was
not written out by DBDMA for some reason.  I have seen similar phenomenun
on Plan B DBDMA implementation, so I wasn't too surprised to see that on
bmac.

Now, I see that awacs driver never checks DBDMA controller's status, and
that can't be good..  I wonder why the sound problem doesn't occur under
Mac OS, or does it?  I suppose you could use TB or something and
recalculate how many bytes out of residual to send to mostly stay in sync.

> I've got as fix coded which uses an 'emergency' dbdma block to retry the
> command (but with adjusted pointers and count to reflect what is left).

Is it not possible to "fix" the command in place and let DBDMA go?


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Iain Sandoe]

On Tue, Mar 27, 2001, Takashi Oe wrote:
> On Tue, 27 Mar 2001, Iain Sandoe wrote:
>
>> >  while (write_sq.active > 0) {
>> >   ...
>> >   if ((stat & ACTIVE) == 0) {
>> >    if (cp == bus_to_virt(in_le32(&awacs_txdma->cmdptr)))
>>
>> this would not work on dmasound because it is possible to get interrupts
>> when blocks are still in progress without requiring error handling (e.g. a
>> dbdma FLUSH command).
>
> I agree that it doesn't help the PowerComputing problem, but I do think
> that just checking xfer_status is not very reliable on DBDMA.

Well, when I first started "looking after" the driver I though this too.

but... the status in the controller relates to the currently active dbdma
command (I believe - please correct me if you know better ;-).

When we get the IRQ for the command completion - a new chained cmd may (in
fact *should* if sound is not to have breaks)  have started.

Therefore we *must* look at the stored result - because the one in the chip
doesn't have any relationship to the IRQ we are handling.

The same would apply to *any* dbdma work that involved chained commands
AFAICT.

>> we need to detect "DEAD" status for the PowerComputing problem.
>
> Ok, ok, this is a totally different problem then.  In the case of bmac,
> the packet had been transmitted without an error, and DBDMA had moved on
> to subsequent commands (if any).  It's just that "xfer_status" field was
> not written out by DBDMA for some reason.  I have seen similar phenomenun
> on Plan B DBDMA implementation, so I wasn't too surprised to see that on
> bmac.

yes, this is different - but that's also interesting to note in case
something like it occurs elsewhere.

> Now, I see that awacs driver never checks DBDMA controller's status, and
> that can't be good..

see comments above.

>I wonder why the sound problem doesn't occur under Mac OS, or does it?

MacOS had the problem and PowerComputing released an "extension" that fixes
it (PCI timing bug fix-up).  It's still on the Apple support site (I
downloaded it recently).

I haven't got around to "looking at" the extension code to see if we can
plumb it into PPC linux.

>I suppose you could use TB or something and
> recalculate how many bytes out of residual to send to mostly stay in sync.

Well, if we get horrendous IRQ hold-offs then maybe - but at the moment I
think that the residue information stored in the dbdma command buffer will
do.

Otherwise we are starting to make quite a complicated solution for a problem
that can probably be fixed by rev. engineering the MacOS extension.

>> I've got as fix coded which uses an 'emergency' dbdma block to retry the
>> command (but with adjusted pointers and count to reflect what is left).
>
> Is it not possible to "fix" the command in place and let DBDMA go?

That was my original idea too... but...

It gets messy to do that - because the buffer start addresses are assigned
in XXXX_dbdma_setup()

- I don't want to have to re-assign them every single time we do a
read/write (on the off-chance that one of them may have been bumped to cope
with an error).

a spare dbdma command block costs 16 bytes of memory.  I think this is
cheaper than the space for the code to cope with doing another way.

ciao,

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Takashi Oe]

Hi,

On Tue, 27 Mar 2001, Iain Sandoe wrote:

> Well, when I first started "looking after" the driver I though this too.
>
> but... the status in the controller relates to the currently active dbdma
> command (I believe - please correct me if you know better ;-).
>
> When we get the IRQ for the command completion - a new chained cmd may (in
> fact *should* if sound is not to have breaks)  have started.
>
> Therefore we *must* look at the stored result - because the one in the chip
> doesn't have any relationship to the IRQ we are handling.
>
> The same would apply to *any* dbdma work that involved chained commands
> AFAICT.

Yes, in theory  :)  It doesn't apply to bmac case as I noted previously.
I think it's better to check cmdptr register of dbdma channel for finding
out how far ahead dbdma is.

As for the "DEAD" status, doesn't the dbdma stop right there?  I'd think
looking at "status" register would suffice.  Is "xfer_status" field
serving any other purpose in your fix possibly?

> MacOS had the problem and PowerComputing released an "extension" that fixes
> it (PCI timing bug fix-up).  It's still on the Apple support site (I
> downloaded it recently).

Ah, ok.

> Well, if we get horrendous IRQ hold-offs then maybe - but at the moment I
> think that the residue information stored in the dbdma command buffer will
> do.

There is usually a res_count register (not the dbdma_cmd one) associated
with each dbdma channel somewhere.  IIRC, unless dbdma is "FLUSH"ed, the
res_count value may be off a bit.

> > Is it not possible to "fix" the command in place and let DBDMA go?
>
> That was my original idea too... but...
>
> It gets messy to do that - because the buffer start addresses are assigned
> in XXXX_dbdma_setup()

What happes if you just issue (RUN|WAKE|PAUSE|DEAD)<<16|(RUN|WAKE) to
dbdma control register when DEAD condition is detected?  I wonder if it's
possible to let dbdma pick up where it left off without touching any dbdma
command..

> a spare dbdma command block costs 16 bytes of memory.

Not 32?  No branch back to original command table?


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Iain Sandoe]

Hi Takashi,
On Tue, Mar 27, 2001, Takashi Oe wrote:
> On Tue, 27 Mar 2001, Iain Sandoe wrote:
>
>> Well, when I first started "looking after" the driver I though this too.
>>
>> but... the status in the controller relates to the currently active dbdma
>> command (I believe - please correct me if you know better ;-).
>>
>> When we get the IRQ for the command completion - a new chained cmd may (in
>> fact *should* if sound is not to have breaks)  have started.
>>
>> Therefore we *must* look at the stored result - because the one in the chip
>> doesn't have any relationship to the IRQ we are handling.
>>
>> The same would apply to *any* dbdma work that involved chained commands
>> AFAICT.
>
> Yes, in theory  :)  It doesn't apply to bmac case as I noted previously.
> I think it's better to check cmdptr register of dbdma channel for finding
> out how far ahead dbdma is.

I think this is a good point... if I compare them and find them equal (like
in your code snippet) then I can look in the status register safely.  We are
in the IRQ handler so ints are already masked.

I want to implement SNDCTL_DSP_GETI/OPTR soon anyway... so maybe as part of
that.

> As for the "DEAD" status, doesn't the dbdma stop right there?

I guess so.  I don't have a PowerComputing machine to check on - I'm relying
on two other guys helping out with testing...

>I'd think
> looking at "status" register would suffice.  Is "xfer_status" field
> serving any other purpose in your fix possibly?

I suspect you are right - and I don't remember if I actually read the status
register in my fix (I'm not on that machine right now)... I might well do.

However, the effect will only be noticed after the loop check the
xfer_status field and finds that it shows "DEAD" (IIRC).

>> Well, if we get horrendous IRQ hold-offs then maybe - but at the moment I
>> think that the residue information stored in the dbdma command buffer will
>> do.
>
> There is usually a res_count register (not the dbdma_cmd one) associated
> with each dbdma channel somewhere.  IIRC, unless dbdma is "FLUSH"ed, the
> res_count value may be off a bit.

Yes, OK that might be worth looking at - I'll see what I've done in my fix.

>> > Is it not possible to "fix" the command in place and let DBDMA go?
>>
>> That was my original idea too... but...
>>
>> It gets messy to do that - because the buffer start addresses are assigned
>> in XXXX_dbdma_setup()
>
> What happes if you just issue (RUN|WAKE|PAUSE|DEAD)<<16|(RUN|WAKE) to
> dbdma control register when DEAD condition is detected?  I wonder if it's
> possible to let dbdma pick up where it left off without touching any dbdma
> command..

I wish I knew whether it would resume... it's not clear from the
documentation I've got... (the IBM stuff).

If it would, then we could save all this hassle completely...

BTW: I don't *think* it does because one of my testers tried a similar
method to the one you proposed and said it chopped up/repeated sound.

anyone else know?

>> a spare dbdma command block costs 16 bytes of memory.
>
> Not 32?  No branch back to original command table?

duh ;-) bad memory - should have looked at the code (it's just allocated as
a standard dbdma cmd block - same as the others).

Anyway I was, exaggerating a bit - because there's another 4 bytes for the
pointer to the cmd ;-)))

but the point was that I don't think the extra memory usage for this comes
anywhere near what would be required for a fix based on re-setting the base
addresses each time.

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Takashi Oe]

On Tue, 27 Mar 2001, Iain Sandoe wrote:

> I wish I knew whether it would resume... it's not clear from the
> documentation I've got... (the IBM stuff).

It may be implementation dependent.  MACE driver stops tx dma and resumes
afterwards, so tx side of dbdma on MACE must support it.

I have no idea if how AWACS' tx dbdma behaves, but it may be necessary to
make the write to control register multi-step or something, i.e., clear
RUN [in order to clear DEAD bit] and wait until RUN bit is cleared by hw,
then set RUN|WAKE..

> If it would, then we could save all this hassle completely...
>
> BTW: I don't *think* it does because one of my testers tried a similar
> method to the one you proposed and said it chopped up/repeated sound.

Hmm, I think it has to be either "chopped up" or "repeated" not both..  As
far as dbdma is concerned, those two are quite different effects.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Iain Sandoe]

On Wed, Mar 28, 2001, Takashi Oe wrote:
> On Tue, 27 Mar 2001, Iain Sandoe wrote:
>
>> I wish I knew whether it would resume... it's not clear from the
>> documentation I've got... (the IBM stuff).
>
> It may be implementation dependent.  MACE driver stops tx dma and resumes
> afterwards, so tx side of dbdma on MACE must support it.

are you sure it will re-start *part way* through a dbdma command (and not
just re-send the entire block)?   (the latter is what sound dma seems to
do).

It doesn't appear to make sense to resume part of a block on ethernet...
(i.e. once you've missed the Xmit deadline the packet is trashed - so you'll
have to re-send anyway).

BTW: the same mac-io chip is responsible for both sound & ethernet dbdma -
so it seems possibly unlikely that the behaviour would be different.

> I have no idea if how AWACS' tx dbdma behaves, but it may be necessary to
> make the write to control register multi-step or something, i.e., clear
> RUN [in order to clear DEAD bit] and wait until RUN bit is cleared by hw,
> then set RUN|WAKE..

OK... that is different (in detail) from what was tried before - I think
I'll ask for a volunteer to test this...  Peter?

>> If it would, then we could save all this hassle completely...
>>
>> BTW: I don't *think* it does because one of my testers tried a similar
>> method to the one you proposed and said it chopped up/repeated sound.
>
> Hmm, I think it has to be either "chopped up" or "repeated" not both..  As
> far as dbdma is concerned, those two are quite different effects.

Well, with fragments of a few tens of ms - it's all highly subjective.

I see it like this:

The sound is chopped up (since some form of blocking has caused the problem
in the first place)  and then the "fix" causes part of the sound to be
repeated - I think this is the origin of the apparently conflicting report.

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Kostas Gewrgiou]

On Wed, 28 Mar 2001, Iain Sandoe wrote:

>
> On Wed, Mar 28, 2001, Takashi Oe wrote:
>
> > I have no idea if how AWACS' tx dbdma behaves, but it may be necessary to
> > make the write to control register multi-step or something, i.e., clear
> > RUN [in order to clear DEAD bit] and wait until RUN bit is cleared by hw,
> > then set RUN|WAKE..
>
> OK... that is different (in detail) from what was tried before - I think
> I'll ask for a volunteer to test this...  Peter?

Thats more or less what i first tried (with no luck...)

> >> If it would, then we could save all this hassle completely...
> >>
> >> BTW: I don't *think* it does because one of my testers tried a similar
> >> method to the one you proposed and said it chopped up/repeated sound.
>
> > Hmm, I think it has to be either "chopped up" or "repeated" not both..  As
> > far as dbdma is concerned, those two are quite different effects.
>
> Well, with fragments of a few tens of ms - it's all highly subjective.

With any ide activity the dbdma commands can fail repeatedly for a looong time
in my machine (some times up to 10secs).....

> I see it like this:
>
> The sound is chopped up (since some form of blocking has caused the problem
> in the first place)  and then the "fix" causes part of the sound to be
> repeated - I think this is the origin of the apparently conflicting report.

If the failed command is ignored then we have the "chopped up" effect (a
3min song finishes in less than 30secs this way under heavy ide activity..)
The "repeated" effect shows up if the packet is resend to dbdma.

btw about the sound related macos patch for some powercomputing machines
might have nothing to do with this problem. Sound works fine in macos in my
PowerWave without it, so macos already handles it right.

  Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Iain Sandoe]

Yasso Kostas!!! (I thought you'd gone out of circulation),

>> > I have no idea if how AWACS' tx dbdma behaves, but it may be necessary to
>> > make the write to control register multi-step or something, i.e., clear
>> > RUN [in order to clear DEAD bit] and wait until RUN bit is cleared by hw,
>> > then set RUN|WAKE..
>>
>> OK... that is different (in detail) from what was tried before - I think
>> I'll ask for a volunteer to test this...  Peter?
>
> Thats more or less what i first tried (with no luck...)

The code I posted (this am) is a subtle modification of what you tried - I
have to admit I don't expect it to behave differently - but the savings
would be very good if it does...

>> >> If it would, then we could save all this hassle completely...
>> >>
>> >> BTW: I don't *think* it does because one of my testers tried a similar
>> >> method to the one you proposed and said it chopped up/repeated sound.
>>
>> > Hmm, I think it has to be either "chopped up" or "repeated" not both..  As
>> > far as dbdma is concerned, those two are quite different effects.
>>
>> Well, with fragments of a few tens of ms - it's all highly subjective.
>
> With any ide activity the dbdma commands can fail repeatedly for a looong time
> in my machine (some times up to 10secs).....

even with IRQs allowed using hdparm ?

>> I see it like this:
>>
>> The sound is chopped up (since some form of blocking has caused the problem
>> in the first place)  and then the "fix" causes part of the sound to be
>> repeated - I think this is the origin of the apparently conflicting report.
>
> If the failed command is ignored then we have the "chopped up" effect (a
> 3min song finishes in less than 30secs this way under heavy ide activity..)
> The "repeated" effect shows up if the packet is resend to dbdma.

well, OK - let's see if the (very slight) change to what you did makes any
difference.

> btw about the sound related macos patch for some powercomputing machines
> might have nothing to do with this problem. Sound works fine in macos in my
> PowerWave without it, so macos already handles it right.

The MacOS extension patch fixes a "PCI timing problem" - specifically
claimed to stop PCI-based-IDE/Sound interaction (which is what we are
seeing).

- maybe later versions of MacOS already have the extension "built-in".

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Iain Sandoe]

BTW: it's very important to use a latest Paulus rsync/BK _2_4 kernel as a
starting point (OR to apply an appropriate version of my patches to earlier
ones).

This is because there was a memory allocation bug in the dbdma cmd buffers
before 2.4.3-pre3 or so, which would make the whole thing very
unpredictable.

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Benjamin Herrenschmidt]

>
>The MacOS extension patch fixes a "PCI timing problem" - specifically
>claimed to stop PCI-based-IDE/Sound interaction (which is what we are
>seeing).

I quickly disassembled the extension, what it does is to write

  0x00000858 (swapped) -> 0xf2800000
  0x12 (byte)          -> 0xf2c00000

Which is basically writing 0x12 to byte at address 0x58 of Bandit
PCI bridge config space.

Now we need to figure out how to identify this machine/bandit model to
make sure we don't scew up bandit on another box.

Can someone try to figure out in the device-tree if there's anything like
a machine ID ? (the "old" mac-os like box ID is 0x66 I think, but I don't
know if it can be found in the device tree. It may be available via mother
board straps around 0xf3000000 however).

I'd also like to know the bandit deviceID & revisionID in it's PCI config
space.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Iain Sandoe]

Hi Ben,

>>The MacOS extension patch fixes a "PCI timing problem" - specifically
>>claimed to stop PCI-based-IDE/Sound interaction (which is what we are
>>seeing).
>
> I quickly disassembled the extension, what it does is to write
>
>   0x00000858 (swapped) -> 0xf2800000
>   0x12 (byte)          -> 0xf2c00000
>
> Which is basically writing 0x12 to byte at address 0x58 of Bandit
> PCI bridge config space.

Is there any doc. (these days) on what the bandit does?

> Now we need to figure out how to identify this machine/bandit model to
> make sure we don't scew up bandit on another box.
>
> Can someone try to figure out in the device-tree if there's anything like
> a machine ID ? (the "old" mac-os like box ID is 0x66 I think, but I don't
> know if it can be found in the device tree. It may be available via mother
> board straps around 0xf3000000 however).

I can't help on the PowerComputing - but checking the Apple model to find
out how we tell the difference...

- I've just looked at the "standard" 7200 tree (html-converted from the one
at  suse) and there is a "compatible" entry.  "AAPL,7300 MacRISC"

> I'd also like to know the bandit deviceID & revisionID in it's PCI config
> space.

there's a "model" property (AAPL,343S1126) in the Apple OF - perhaps this is
different from the PowerComputing variant.

Also, if booted from BootX, it might be possible to get at the Gestalt
settings - I'm sure that's at the tail end of the Apple OF tree (although it
doesn't make it through to the Linux side).  This would give you the model
ID without poking the ROM or straps.

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Takashi Oe]

On Wed, 28 Mar 2001, Iain Sandoe wrote:

> are you sure it will re-start *part way* through a dbdma command (and not
> just re-send the entire block)?   (the latter is what sound dma seems to
> do).

No, not sure at all.

> It doesn't appear to make sense to resume part of a block on ethernet...
> (i.e. once you've missed the Xmit deadline the packet is trashed - so you'll
> have to re-send anyway).

I agree it would make more sense to resend the whole thing, and that's
probably what mace dbdma does.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Takashi Oe]

On Wed, 28 Mar 2001, Iain Sandoe wrote:

> - I've just looked at the "standard" 7200 tree (html-converted from the one
> at  suse) and there is a "compatible" entry.  "AAPL,7300 MacRISC"
>
> > I'd also like to know the bandit deviceID & revisionID in it's PCI config
> > space.
>
> there's a "model" property (AAPL,343S1126) in the Apple OF - perhaps this is
> different from the PowerComputing variant.

According to the oftree in /usr/lib/mol,

PowerBase 180 or 200:

compatible = "AAPL,e407", "MacRISC"
Bandit's model = "AAPL,343S1183"

StarMax 4160:

compatible = "AAPL,e826", "MacRISC"
Bandit's model = "AAPL,343S1183"

PowerMac 8500:

compatible = "AAPL,8500", "MacRISC"
Bandit's model = "AAPL,343S1126"

I wonder what PowerCenter or PowerTower reports..


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Iain Sandoe]

some more bandit-using machines:

7500/100: (from suse database)

compatible: AAPL,7500 MacRISC
bandit: AAPL,343S1126

9500/132: (from suse database)

compatible: AAPL,9500 MacRISC
bandit: AAPL,343S1126

9600/233: (mine ;-)

compatible: AAPL,9500 MacRISC
bandit: AAPL,343S1126

so far, it seems only two Apple bandit models: 343S1183 & 343S1126

was there any machine after 9600 that used bandit?

(I don't seem to remember one - my next machine was G3/beige).

any news on PowerXXXX machines OF info?

my 9600 definitely has Gestalt as part of the Apple OF (viewed in display
name registry under 9.0.4 - and has the machine ID as part of that - can't
be sure about other early models).

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Takashi Oe]

On Thu, 29 Mar 2001, Iain Sandoe wrote:

> some more bandit-using machines:
>
> 7500/100: (from suse database)
>
> compatible: AAPL,7500 MacRISC
> bandit: AAPL,343S1126

7600/120 and 7600/132 have the same entries as 7500.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Michael R. Zucca]

Ok, sorry folks. I've been up to my eyeballs with work lately. So I'll see
what I can do this weekend about testing patches.

For now, here's what I've got on my PowerCenter 132:

compatible: "AAPL,7300 MacRISC"
bandit model: "AAPL,343S1126"
dbdma model: "AAPL,343S1125"

____________________________________________________________________
 Michael Zucca - mrz5149@acm.org - http://www.mdc.net/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
____________________________________________________________________


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Michael R. Zucca]

First, I've recently discovered that the problem isn't limited to sound.
I've also noticed that my Adaptec SCSI card has bouts of timeouts.
Something I wasn't aware of before.

Ok, so I had a sec this weekend and I wanted to quickly see if the PCI
timing hack that Ben described worked. Now, perhaps I wrote it wrong, but I
noticed that I still get the sound stoppage as well as disk burps. Nothing
seems to have improved :-(

I'm hacking on a 2.2 snapshot at the moment (yes, yes, I'll get 2.4 as soon
as I can!) :-)

Here's a snippet I added to the end of init_bandit() in pmac_pci.c:

#define BANDIT_POWERCENTER_HACK_ADDR	0x58
#define BANDIT_POWERCENTER_HACK_DATA	0x12

#if 1
	/* PowerCenter PCI timing hack */
	out_le32(bp->cfg_addr, (1UL << BANDIT_DEVNUM) +
BANDIT_POWERCENTER_HACK_ADDR);
	udelay(2);
	out_8(bp->cfg_data, BANDIT_POWERCENTER_HACK_DATA) ;
	printk(KERN_INFO "PowerCenter PCI timing hack enabled.\n") ;
#endif

Any thoughts?




____________________________________________________________________
 Michael Zucca - mrz5149@acm.org - http://www.mdc.net/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
____________________________________________________________________


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound stoppage

[Iain Sandoe]

> I'm hacking on a 2.2 snapshot at the moment (yes, yes, I'll get 2.4 as soon
> as I can!) :-)

2.2.x is ***broken*** in dmasound dbdma - (even with my last patch)... the
is a memory allocation bug in the dbdma cmd buffs.

so - all bets are off about what might happen ;-)

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/