[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240912214404.10616-2-edmund.raile@protonmail.com>
Date: Thu, 12 Sep 2024 21:44:52 +0000
From: Edmund Raile <edmund.raile@...tonmail.com>
To: o-takashi@...amocchi.jp
Cc: apais@...ux.microsoft.com, edmund.raile@...tonmail.com, linux-kernel@...r.kernel.org, linux-media@...r.kernel.org, linux-sound@...r.kernel.org, netdev@...r.kernel.org, tiwai@...e.de
Subject: firewire: use sleepable workqueue to handle 1394 OHCI IT/IR context events: test 2
Hello Sakamoto-San, I came around to testing your patch [1], after RFT.
I've had to make the following changes to patch 1/5 again for it to apply to
mainline (d1f2d51b711a3b7f1ae1b46701c769c1d580fa7f), due to missing b171e20
from 2009 and a7ecbe9 from 2022.
@@ -584,9 +601,13 @@ int fw_card_add(struct fw_card *card,
generate_config_rom(card, tmp_config_rom);
ret = card->driver->enable(card, tmp_config_rom, config_rom_length);
if (ret == 0)
list_add_tail(&card->link, &card_list);
+ else
+ destroy_workqueue(isoc_wq);
+
+ card->isoc_wq = isoc_wq;
mutex_unlock(&card_mutex);
return ret;
@@ -709,7 +729,9 @@ void fw_core_remove_card(struct fw_card *card)
{
struct fw_card_driver dummy_driver = dummy_driver_template;
unsigned long flags;
+ might_sleep();
+
card->driver->update_phy_reg(card, 4,
PHY_LINK_ACTIVE | PHY_CONTENDER, 0);
fw_schedule_bus_reset(card, false, true);
@@ -719,6 +741,7 @@ void fw_core_remove_card(struct fw_card *card)
dummy_driver.free_iso_context = card->driver->free_iso_context;
dummy_driver.stop_iso = card->driver->stop_iso;
card->driver = &dummy_driver;
+ drain_workqueue(card->isoc_wq);
spin_lock_irqsave(&card->lock, flags);
fw_destroy_nodes(card);
Then everything applied fine.
This resulted in 6.11.0-rc6-1-mainline-00326-gd1f2d51b711a-dirty.
Testing it with TI XIO2213B and RME Fireface 800 so far:
Initially I had a buffer freeze after 3 hours of continuous ALSA playback
from mpv:
mpv --audio-device=alsa/sysdefault:CARD=Fireface800 Spor-Ignition.flac
accompanied by stresstest (mprime).
It didn't freeze/crash the kernel, just the audio buffer kept repeating.
Gone after power-cycling the interface and restarting playback.
Can't say with certainty whether it's related, have been unable to replicate
the issue for the past 3 days (good sign I hope).
That's why I was holding this message back a bit.
Kind regards,
Edmund Raile.
Signed-off-by: Edmund Raile <edmund.raile@...tonmail.com>
Tested-by: Edmund Raile <edmund.raile@...tonmail.com>
Powered by blists - more mailing lists