Re: Bug report: Mac Target Disk Mode not working in some cases
Brought to you by:
aeb,
bencollins
From: Takashi S. <o-t...@sa...> - 2024-08-26 08:39:22
|
Hi, On Sun, Aug 25, 2024 at 09:31:40PM +0100, Andrew Ferguson wrote: > Hello, > > I firstly wanted to thank the maintainers for working on the ieee1394 > system for Linux. It's great to see continuing support for firewire in > Linux. > > I have encountered a bug in that some Macs are not detected in Linux, when > the Mac is being used in "Target Disk Mode". For those unfamiliar, Target > Disk Mode boots an older (firewire-compatible) Mac in a mode where > connecting it to another computer via firewire causes the Mac to appear as > an external firewire hard drive. See the Wikipedia article > <https://en.wikipedia.org/wiki/Target_Disk_Mode> for more information. To > be clear, I am not trying to run the Linux1394 system on an older Mac; I am > trying to connect a Mac in Target Disk Mode to a regular PC running Linux > over firewire. The Mac should appear as an external firewire hard drive. On > some Mac models, it works just fine. However on other models, it doesn't > work. If I connect one of these non-working models to a Mac running OS X, > it does work, so it does appear to be an issue with Linux1394. > > Mac models that work: > Macbook Pro late 2008 > iMac G4 > > Mac models that do not work: > iBook G4 > Powerbook G4 > > I have access to more Mac models to test if necessary - the benefits of > hoarding old electronics! > > If the maintainers are interested in investigating this issue, what sort of > debugging information can I provide? There's only a few lines in dmesg that > to my eyes look useful ("sbp_scsi_abort" is one) but I can provide full > dmesg output if helpful. I have a number of different Firewire PCI / PCIe > cards I can use, including one that should be able to run the "nosy" > ieee1394 packet sniffer (although I have no clue how to set that up!). > > Many thanks, and kind regards, > Andrew Thanks for the report. I'm sorry but I have less interests in the issue, since I have no actual hardware to investigate the issue (I'm a developer of ALSA, thus the center of my interest is multimedia protocol such like IEC 61883.) Therefore it is up to you. If you are willing to solve the issue, I would help you. Else, nothing changed. In Linux kernel v6.10, I added some tracepoints events[1]. These events are available to track asynchronous communication between Linux system and peer node. If the issue is caused by any kind of communication error, you could diagnose it. ``` $ ls -1 /sys/kernel/debug/tracing/events/firewire/ async_phy_inbound/ async_phy_outbound_initiate/ async_request_outbound_complete/ async_response_inbound/ async_response_outbound_initiate/ async_phy_outbound_complete/ async_request_inbound/ async_request_outbound_initiate/ async_response_outbound_complete/ ... ``` Additionally, I think the protocol in the case is SBP. The protocol specification is still available[2] and it would help your diagnose, too. [1] https://www.kernel.org/doc/html/latest/trace/events.html [2] http://ieee1394.docs.kernel.org/en/latest/specifications.html#the-serial-bus-protocol Regards Takashi Sakamoto |