Opened 8 years ago

Last modified 5 years 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
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 8 years ago.
media_addon_server-624-debug-16-11-2015-19-03-21.report (12.4 KB ) - added by vidrep 8 years ago.
media_addon_server-503-debug-06-06-2019-09-57-00.report (13.8 KB ) - added by dufresnep 5 years 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 5 years 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 5 years 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 5 years 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 5 years 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, 8 years ago

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

comment:2 by vidrep, 8 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, 8 years ago

Blocking: 12477 added

comment:4 by Barrett, 8 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, 8 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 8 years ago by vidrep (previous) (diff)

comment:6 by Barrett, 8 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, 8 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, 8 years ago

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

comment:9 by Barrett, 8 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, 8 years ago

Blocking: 9804 added

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

comment:11 by Barrett, 8 years ago

Blocking: 12488 added

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

comment:12 by Barrett, 8 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, 8 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, 6 years ago

Blocking: 13988 added

comment:15 by vidrep, 5 years ago

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

comment:16 by waddlesplash, 5 years ago

Resolution: not reproducible
Status: assignedclosed

comment:17 by ttcoder, 5 years ago

Cc: ttcoder added

comment:18 by Barrett, 5 years ago

Resolution: not reproducible
Status: closedreopened

comment:19 by diver, 5 years ago

Blocking: 14877 added

comment:20 by diver, 5 years ago

Blocking: 14854 added

comment:21 by lpereira, 5 years 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 years 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 it officially in the nightlies and future releases - until fixed.

Version 1, edited 5 years ago by cocobean (previous) (next) (diff)

comment:23 by Barrett, 5 years 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 years ago

Owner: changed from Barrett to nobody
Status: reopenedassigned

comment:25 by dufresnep, 5 years 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, 5 years ago

Replying to dufresnep:

I believe this affects only the x86 32 bits version

Interesting, would you be able to confirm this?

by dufresnep, 5 years ago

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

comment:27 by dufresnep, 5 years 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, 5 years ago

After updating the system, mp3 file playing

comment:28 by dufresnep, 5 years 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, 5 years 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, 5 years ago

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

comment:30 by dufresnep, 5 years 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, 5 years ago

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

comment:31 by dufresnep, 5 years 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, 5 years 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 5 years ago by dufresnep (previous) (diff)

by dufresnep, 5 years ago

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

comment:33 by leavengood, 5 years 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.