2.4.17 and dmasound

I recently downloaded 2.4.17 from kernel.org hoping to get my kernel
more up to date. Unfortunately, when I looked at the dmasound driver I
didn't see the fix for dbdma DEAD problems which occur on some
PowerComputing machines.

Was this patch ever submitted or was it lost in the shuffle?

Thanks!


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

I recently downloaded 2.4.17 from kernel.org hoping to get my kernel
more up to date. Unfortunately, when I looked at the dmasound driver I
didn't see the fix for dbdma DEAD problems which occur on some
PowerComputing machines.

Was this patch ever submitted or was it lost in the shuffle?

Look for 2.4.18, it will be released soon, or use one of the PPC trees
or the current 2.4.18-rc4. All of them should work.

Ben.


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

Ok, I tried 2.4.18 from kernel.org on my PowerCenter 132 and the DMA
dead patch works. However, as a side note, it only seems to work if the
sound code is compiled into the kernel. The same code in a module does
not work and still causes the sound hang. As I recall, the way the
emergency buffer was allocated was critical to it functioning properly.
I usually compile in the sound driver so it's not a big deal for me but
it might be for other folks.

On another note, I've noticed that if I reboot my machine using shutdown
-r the machine will reboot to a gray screen and then just hang there. It
won't boot into MacOS. I've noticed that on 68k Macs, it is important to
map the ROMs back into memory before rebooting or the machine just hangs
around forever. Is it possible that we're not remapping stuff back to
its usual place before rebooting on OldWorld machines? This has been a
persistant problem for a long time on 2.4.

Thanks!

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

Ok, I tried 2.4.18 from kernel.org on my PowerCenter 132 and the DMA
dead patch works. However, as a side note, it only seems to work if the
sound code is compiled into the kernel. The same code in a module does
not work and still causes the sound hang. As I recall, the way the
emergency buffer was allocated was critical to it functioning properly.
I usually compile in the sound driver so it's not a big deal for me but
it might be for other folks.

Well, I see no problem with the way the buffer is allocated. However,
the emergency buffer code looks wrong: It should really contain a
branch command to branch back the DBDMA controller to the normal buffer.

On another note, I've noticed that if I reboot my machine using shutdown
-r the machine will reboot to a gray screen and then just hang there. It
won't boot into MacOS. I've noticed that on 68k Macs, it is important to
map the ROMs back into memory before rebooting or the machine just hangs
around forever. Is it possible that we're not remapping stuff back to
its usual place before rebooting on OldWorld machines? This has been a
persistant problem for a long time on 2.4.

That is weird, I don't think we have to take care of any sort of MMU
mapping, looks more like some driver would need to be restored in some
"pristine" state (sound ?)

Ben.


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

Can you try this patch and tell me if it helps ?

===== drivers/sound/dmasound/dmasound_awacs.c 1.21 vs edited =====

--- 1.21/drivers/sound/dmasound/dmasound_awacs.c	Tue Feb  5 09:58:03 2002
+++ edited/drivers/sound/dmasound/dmasound_awacs.c	Mon Mar  4 11:32:36 2002

@@ -963,7 +963,9 @@
 			st_le16(&cp->res_count, 0);
 			st_le16(&cp->xfer_status, 0);
 			st_le32(&cp->phy_addr, phy);
-			st_le16(&cp->command, OUTPUT_MORE + INTR_ALWAYS);
+			st_le32(&cp->cmd_dep, virt_to_bus

(&awacs_tx_cmds[(i+1)%write_sq.max_count]));
+			st_le16(&cp->command, OUTPUT_MORE | BR_ALWAYS | INTR_ALWAYS);
+
 			/* point at our patched up command block */
 			out_le32(&awacs_txdma->cmdptr, virt_to_bus(cp));
 			/* we must re-start the controller */


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