Opened 4 years ago

Last modified 5 weeks ago

#12448 assigned bug

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

Reported by: vidrep Owned by: leavengood
Priority: normal Milestone: R1
Component: Servers/media_addon_server Version: R1/Development
Keywords: Cc: ttcoder
Blocked By: Blocking: #9804, #11243, #12477, #12488, #12700, #13988, #14854, #14877
Has a Patch: no Platform: All

Description (last modified by Barrett)

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.

Attachments (7)

media_addon_server-493-debug-07-11-2015-16-18-51.report (12.1 KB ) - added by vidrep 4 years ago.
media_addon_server-624-debug-16-11-2015-19-03-21.report (12.4 KB ) - added by vidrep 4 years ago.
media_addon_server-503-debug-06-06-2019-09-57-00.report (13.8 KB ) - added by dufresnep 4 months ago.
Bug while opening an mp3 file on latest (hvev53182) only happening in 32 bit version
MediaPlayer-526-debug-06-06-2019-13-18-54.report (31.5 KB ) - added by dufresnep 4 months ago.
After updating the system, mp3 file playing
media_addon_server-461-debug-06-06-2019-13-42-58.report (14.1 KB ) - added by dufresnep 4 months ago.
after updates,GetBuffer: IDs mismatch,Attack of the Killer Tomatoe thread
MediaPlayer-522-debug-07-06-2019-04-45-13.report (27.9 KB ) - added by dufresnep 4 months ago.
regenerated system, segment violation in commpage_memcopy (fs=0x63)
media_addon_server-480-debug-07-06-2019-05-34-23.report (13.5 KB ) - added by dufresnep 4 months ago.
similar bug as previous (oops), on regenerated system usb stick (live mode)

Download all attachments as: .zip

Change History (40)

comment:1 by Barrett, 4 years ago

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

comment:2 by vidrep, 4 years ago

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

comment:3 by Barrett, 4 years ago

Blocking: 12477 added

comment:4 by Barrett, 4 years ago

Milestone: UnscheduledR1
Status: newassigned

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.

comment:5 by vidrep, 4 years ago

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. Of course, I'm always willing to assist however I can, to help Haiku progress toward a stable Beta release. I'll try your suggestion should the problem become reproducible.

Last edited 4 years ago by vidrep (previous) (diff)

comment:6 by Barrett, 4 years ago

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.

comment:7 by bruno, 4 years ago

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...

comment:8 by Barrett, 3 years ago

Description: modified (diff)
Summary: Media Add-on Server crashFirewire-0/SetHeader cause troubles

comment:9 by Barrett, 3 years ago

Blocking: 12700 added

(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.

comment:10 by Barrett, 3 years ago

Blocking: 9804 added

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

comment:11 by Barrett, 3 years ago

Blocking: 12488 added

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

comment:12 by Barrett, 3 years ago

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

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

comment:13 by Barrett, 3 years ago

Blocking: 11243 added

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

comment:14 by korli, 19 months ago

Blocking: 13988 added

comment:15 by vidrep, 9 months ago

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

comment:16 by waddlesplash, 9 months ago

Resolution: not reproducible
Status: assignedclosed

comment:17 by ttcoder, 9 months ago

Cc: ttcoder added

comment:18 by Barrett, 9 months ago

Resolution: not reproducible
Status: closedreopened

comment:19 by diver, 8 months ago

Blocking: 14877 added

comment:20 by diver, 7 months ago

Blocking: 14854 added

comment:21 by lpereira, 6 months ago

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.

comment:22 by cocobean, 5 months ago

@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.

Last edited 5 months ago by cocobean (previous) (diff)

comment:23 by Barrett, 5 months ago

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!

comment:24 by korli, 5 months ago

Owner: changed from Barrett to nobody
Status: reopenedassigned

comment:25 by dufresnep, 4 months ago

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.

in reply to:  25 comment:26 by luroh, 4 months ago

Replying to dufresnep:

I believe this affects only the x86 32 bits version

Interesting, would you be able to confirm this?

by dufresnep, 4 months ago

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

comment:27 by dufresnep, 4 months ago

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

by dufresnep, 4 months ago

After updating the system, mp3 file playing

comment:28 by dufresnep, 4 months ago

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.

comment:29 by dufresnep, 4 months ago

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

by dufresnep, 4 months ago

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

comment:30 by dufresnep, 4 months ago

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?

by dufresnep, 4 months ago

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

comment:31 by dufresnep, 4 months ago

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.

comment:32 by dufresnep, 4 months ago

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
Last edited 4 months ago by dufresnep (previous) (diff)

by dufresnep, 4 months ago

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

comment:33 by leavengood, 5 weeks ago

Owner: changed from nobody to 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?

Note: See TracTickets for help on using tickets.