Firewire-0 cause troubles (GetBuffer: IDs mismatch, SetHeader)

[vidrep]

hrev49758 x86_gcc2 Media Add-on Server crash after deskop appears Debug report attached

--

When Firewire-0 is present there's a memory corruction supposedly caused by the driver. This is the master ticket.

[Barrett]

Does the crash happened just after an upgrade? Or is it persistent?

[vidrep]

Did a fresh install of hrev49833 x86_gcc2 on my second test PC pkgman full-sync to 49852 x86_gcc2 reboot media_add-on server debug report appeared on desktop after the reboot Was this automatically generated? I did not see any debugger dialog, nor did I input a command. debug report attached

[Barrett]

I think the common factor between all bug reports that I've seen is that the FireWire-0 control is there. This might be cause of some buffers mismatch or area offsets overflow since those threads live in the same team (the media_addon_server).

A test that might be useful is if you disable firewire from bios or blacklist the right drivers so that we can see if the problem is still happening.

[vidrep]

I'm not so sure this issue is persistent enough to easily track down. I saw it happen only twice during a week in which I was at home on a work break, doing a lot of testing for Haiku. Prior to the first report, I had not seen a media_addon_server crash for quite some length of time.

[Barrett]

I fixed different occurrences of this bug, only one of them was replicable on my system and it happened at very high load of the system (such as 20 videos played at the same time). I don't see this bug on my pc since then, and also I don't have a firewire. So if we could confirm that disabling it the bug doesn't occur, it will be helpful to finally fix the source.

[bruno]

Did a fresh install of hrev 49857 x86_gcc2 on my PC...

pkgman full-sync

reboot

media_add-on server wont crash anymore... Maybe fixed?! Strange...

[Barrett]

(In #12700) Yes exactly, the better way you can solve it is to disable your firewire card. I'm closing duplicate tickets of the SetHeader/Firewire-0 bug, please continue to follow #12448.

[Barrett]

(In #9804) Another Firewire-0 problem variant.

[Barrett]

(In #12488) Firewire-0 duplicate, please refer to #12448.

[Barrett]

For reference to anyone experiencing this bug, to fix the problem you should blacklist the fw_raw driver from the bootloader.

[Barrett]

(In #11243) This is another variant of #12448, follow the instructions there to temporarily fix it.

[vidrep]

I have not seen this issue in a long time. Fixed???

[lpereira]

Just to confirm that blacklisting fw_raw works around the issue for me. Upgraded to 52979 today and media_addon_server was crashing. Rebooting did not help. My machine is a ThinkPad X60, which has a Firewire port; I'll keep it blacklisted as I don't have any Firewire devices. I've saved the crash report if that helps debugging the issue.

[cocobean]

@vidrep - Issue still exists for R1B1 (up to -129 revision) and hrev53051.

NOTE: Firewire-0 control
/boot/system/add-ons/media/firewire_dv.media_addon

Seems best to disable/blacklist it officially in the nightlies and future releases - until fixed.

The other thing I did was restart/quit the media server process - which should show media_server and media_addon_server when restarted. This gives a click sound in the speakers if it works OK - and no crash condition. Check that both app services are running.

[Barrett]

I agree it should be disabled. I think I proposed it somewhere but there was someone which didn't agree and then for lack of motivation I postponed the thing.

However the patch is rather trivial, grep in the build directory for "fw_raw" and you will find what you need.

Sorry guys, not being formally an Haiku developer anymore I can't help more than that. Hope that helps!

[dufresnep]

I believe this affects only the x86 32 bits version, not the 64 bits version. For me, it results in the media player not playing files (mp3) and Youtube not working in webpositive. debugger had shown, it happening on sysenter of comm_page for call on "volume control" or something similar. Still happening in hrev1/beta1 and hrev53176. Deactivating Firewire in BIOS has fixed the bug for me here in hrev1/beta1 32 bits.

[luroh]

Replying to dufresnep:

I believe this affects only the x86 32 bits version

Interesting, would you be able to confirm this?

[dufresnep]

Bug while opening an mp3 file on latest (hvev53182) only happening in 32 bit version

[dufresnep]

Confirming with latest version (hrev53182), not happening in the 64 bits version (live USB key), but happening in live 32 bit version.

[dufresnep]

After updating the system, mp3 file playing

[dufresnep]

I installed the 32 bit version on an hard disk. Did the updates. Installed debugging packages. Now the mp3 file is playing, but a media addon bug still happen at the beginning (I just attached it to the bug). Now, acquire_sem_etc seems to be the one calling comm_page sysenter. Also, Firewire-0 thread seems not listed anymore.

[dufresnep]

I just tried to play a video on Youtube and got a more similar bug to the previous one, will attach it. Some strange thread names in it: thread 548: Yeah baby, very shagadelic thread 588: FireWire-0 control thread 879: Attack of the Killer Tomatoes

[dufresnep]

after updates,GetBuffer: IDs mismatch,Attack of the Killer Tomatoe thread

[dufresnep]

I have rebuilt the system on my computer ( ./configure [no parameter] ). Wrote the nightly generated image to a usb stick. And strangely, the stick, although gcc2 32 bits one, play mp3 file find, and play youtube video(s) without any bug reports. So it might be related to the machine type?

[dufresnep]

regenerated system, segment violation in commpage_memcopy (fs=0x63)

[dufresnep]

I retried playing the same downloaded mp3 file, and now although the file is heard playing, I got a segment violation in commpage_memcpy. I have attached the file. Frankly unsure if it is related to this bug.

[dufresnep]

I got a similar bug as before on the regenerated system usb stick. Will attach it. I see Firewire0 stack is just over Audio Mixer control stack... is it possible it is overstacking inside Audio Mixer one?

	6216	0x70a7b000	0x70ac0000	       276	rw-s       	full          	HD Audio control_514_stack
	5834	0x70cb9000	0x70cfe000	       276	rw-s       	full          	System clock control_486_stack
	6188	0x70ff2000	0x71037000	       276	rw-s       	full          	Audio Mixer control_511_stack
	6305	0x71212000	0x71257000	       276	rw-s       	full          	FireWire-0 control_527_stack
	5754	0x71466000	0x72467000	     16388	rw-s       	full          	media_addon_server_480_stack
	6224	0x724de000	0x72523000	       276	rw-s       	full          	multi_audio audio output_516_st

[dufresnep]

similar bug as previous (oops), on regenerated system usb stick (live mode)

[leavengood]

That last debugger call is more or less the same as the one in the BufferCache: the buffer IDs do not match. So either buffers are getting mixed up in some way, or the header or buffer memory is being corrupted. Given they are shared all over the place corruption is a distinct possibility. Why it only happens on gcc2 is maybe the bigger question. It could be a locking bug where a couple things try to access the same buffer memory at the same time and one overwrites the other.

I almost have a handle on how the current buffer sharing works and can maybe come up with a better scheme, but with sharing memory across teams there is always a risk of corruption.

I think what I will do in the meantime for this issue is add to each of these debugger calls the buffer ID expected, and the one gotten.

Question for you dufresnep: is the firewire addon in use in some of your recent crashes?