It was reported[1] on alsa-devel that PulseAudio gets killed when trying to use the Intel HDMI LPE driver that was introduced in kernel version 4.11. That probably happens due to excessive CPU use in the IO thread. It's not known what causes the high CPU use, but the discussion revealed some definite shortcomings in PulseAudio when HDMI's underlying hw device is hw:x,0. There are two bugs: 1) PulseAudio assumes that if the front:x device doesn't work but hw:x,0 does, then hw:x,0 is an analog stereo device. 2) PulseAudio assumes that HDMI devices are always mapped to certain hw:x,y devices, the first one being hw:x,3. When this assumption doesn't hold, jack detection and ELD reading don't work. For the first bug, I propose trying hw:x,0 for analog stereo only if everything else fails, so if e.g. hdmi:x,0 is successfully opened, hw:x,0 won't be used. For the second bug, I propose removing the hardcoded device numbers, and instead query the device number from an open PCM handle. That's not reliable for all PCM devices, but Takashi expects it to work for HDMI devices. It's not obvious what would be the best way to modify the profile and path configuration syntax to support the new features. I'll prepare a more detailed proposal when I get around to it. My impression is that the HDMI LPE driver will be widely used, so I think this should be fixed with high priority (I'll mark this as a release blocker). [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-March/118903.html
I sent a patch for the first bug: https://patchwork.freedesktop.org/patch/152433/ The patch is simpler than I first thought: it doesn't change the configuration syntax at all. It just moves the hw:x,0 handling from the analog-stereo mapping to a new unknown-stereo mapping that is marked as a fallback, that is, it's used only when nothing else works.
Do we need to call the second part of the bug an 11.0 blocker?
Yes, I think making the jack detection work is important. I understand this[1] message from Takashi so that we should avoid using the device when the monitor isn't plugged in, and for that we need working jack detection. [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-March/119087.html
Patches submitted: https://patchwork.freedesktop.org/series/25656/
What is the expected behaviour with those patches? For me, on a Surface 3 (CherryTrail) with the patches applied on top of PA 10.0, PulseAudio doesn't crash, but I get no sound from the internal speakers when HDMI is not plugged in.
What does "pactl list" print when it's not working?
(In reply to Bastien Nocera from comment #5) > What is the expected behaviour with those patches? The expected behaviour is that everything works perfectly (apart from PulseAudio getting killed, but you don't seem to be suffering from that).
Bastien, do you have time to debug this? The patches have had almost no testing on real hardware, and based on your description, we probably can't apply them before this is sorted out, and I can't debug this alone.
Hi, i've got the same Problem here: The worst part is that my working sound was killed as i updated Kernel which now supports hdmi audio. There was no clear error in pulseaduio log and it costed me a lot time to find out that it's this Problem whcih killed my working internal sound via letting pulseaudio die.. The quickest solution now was blacklisting hdmi audio module, but will try the posted patches when i find time and will report here if they work. For me this bug is a big bug because it kills working installations without any notice and you can't see any good log showing whats happening...
*** Bug 102378 has been marked as a duplicate of this bug. ***
Removed the release blocker status.
I met a similar issue that is pulseaudio keeps restarting (killed and restarted). The platform is Cherry Trail and the monitor is Dell P2317H (no audio). Connection type is display port. Try the patch in comment #4, but pulseaudio still restarts continuously. The patch is applied to both pulseaudio 8.0 (Ubuntu 16.04 Xenial) and pulseaudio 10.0 (Ubuntu 17.04 Zesty). System configuration: Platform - Dell Wyse 3040 Monitor - Dell P2317H Connection - Display Port OS - Ubuntu Linux 16.04/17.04 Kernel - 4.13
Created attachment 134069 [details] pactl list output
Created attachment 134070 [details] pulseauduio log
I found that on Wyse3040, the name of output profile is 'analog-stereo'. Then the proposed fix cannot be applied on it. After changing /usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf, and add 'query-hw-device = yes' in [Mapping analog-stereo] section, PA stop crashing. But I am wondering if there are any side effects for other platforms. see the attachments in comment #13 and #14
After checking some commits, it seems that I have to upgrade alsa-libs as well. I'll do further testings if I have time.
(Sorry for not responding earlier.) Yes, you'll need to upgrade alsa-lib, or at least apply this patch to the configuration that alsa-lib provides: http://mailman.alsa-project.org/pipermail/alsa-devel/2017-February/117706.html Even after that it's likely that pulseaudio will still get killed - if that happens, please provide the verbose log.
Created attachment 134389 [details] pulseaudio SIGKILL-ed log Also on my cherrytrail machine pulseaudio is being SIGKILL-ed at start. I have described my setup here https://bugs.freedesktop.org/show_bug.cgi?id=102877 I also tried to apply on top of the latest master the patch in https://patchwork.freedesktop.org/series/25656/ (the patch for the first bug was already merged) and also imported the HdmiLpeAudio.conf configuration file, unfortunately pulseaudio keeps being killed. In attachment the log. Any other test / hint / suggestion / patch to try? This is a really nasty and annoying bug.
Created attachment 134414 [details] no-analog.patch PulseAudio successfully opens the "front" device, which it shouldn't be able to do. Now that I look at HdmiLpeAudio.conf, I see that it defines the "front" and the various "surround" devices, which confuses pulseaudio, because pulseaudio expects those to be analog devices. I attached no-analog.patch. Look at the removed lines - if you remove those from your HdmiLpeAudio.conf, does pulseaudio work then? If not, the verbose log will again be useful.
(In reply to Tanu Kaskinen from comment #19) > I attached no-analog.patch. Look at the removed lines - if you remove those > from your HdmiLpeAudio.conf, does pulseaudio work then? Yes, in that case it works fine. Is this a workaround or a real fix though?
I think it's a real fix. Not a nice fix, but the fact is that things will break in PulseAudio if alsa defines "front" to be the same as "hdmi". Strictly speaking "front" is allowed to be any device that has a front-left,front-right channel map, but in practice it shouldn't overlap with other device definitions, because PulseAudio needs to tell analog and HDMI devices apart. There's no separate definition for analog devices, so PulseAudio assumes that "front" is analog, and usually that assumption is correct. I'll send the patch to the alsa developers. Thanks for testing!
Thank you for working on this. I still need to apply https://patchwork.freedesktop.org/series/25656/ on top of master to prevent PA from crashing. I saw that Arun was a bit concerned about the patchset. Is the patchset still valid or there is anything else in the working?
I haven't had proper reminders about the patch set, so I kind of forgot about it. I plan to simplify the patches a bit soon. I submitted the alsa-lib patch now. Let's see if it gets accepted... http://mailman.alsa-project.org/pipermail/alsa-devel/2017-October/126099.html
New patches submitted: https://patchwork.freedesktop.org/series/31556/
(In reply to Tanu Kaskinen from comment #24) > New patches submitted: > https://patchwork.freedesktop.org/series/31556/ I've tested Fedora 26's PulseAudio which includes this series of patches[1] and the alsa-lib change from comment 23, and I can't get any output on the internal audio anymore. The HDMI output appears as unplugged on my system (the mini DisplayPort to HDMI converter doesn't seem to work for video either in Linux, another problem), but the internal audio just isn't there at all. Though that might be the current upstream linus tree being busted :/ [1]: http://pkgs.fedoraproject.org/cgit/rpms/pulseaudio.git/tree/?h=f26
(In reply to Bastien Nocera from comment #25) > (In reply to Tanu Kaskinen from comment #24) > > New patches submitted: > > https://patchwork.freedesktop.org/series/31556/ > > I've tested Fedora 26's PulseAudio which includes this series of patches[1] > and the alsa-lib change from comment 23, and I can't get any output on the > internal audio anymore. Do you have a ucm file for your SoC / codec combo? : https://github.com/plbossart/UCM mkdir /usr/share/alsa/ucm and then copy all the *dirs* from that git repo there.
(In reply to Hans de Goede from comment #26) > (In reply to Bastien Nocera from comment #25) > > (In reply to Tanu Kaskinen from comment #24) > > > New patches submitted: > > > https://patchwork.freedesktop.org/series/31556/ > > > > I've tested Fedora 26's PulseAudio which includes this series of patches[1] > > and the alsa-lib change from comment 23, and I can't get any output on the > > internal audio anymore. > > Do you have a ucm file for your SoC / codec combo? : > > https://github.com/plbossart/UCM > > mkdir /usr/share/alsa/ucm and then copy all the *dirs* from that git repo > there. I have a version of it, as the sound works in older versions. I think it's a kernel bug, see: http://mailman.alsa-project.org/pipermail/alsa-devel/2017-October/126407.html [1]: I added this in F25, which got merged in alsa-lib 1.1.2: http://pkgs.fedoraproject.org/cgit/rpms/alsa-lib.git/commit/?id=15bc4520f97663ab044799b69da0ded29b92be29
(In reply to Bastien Nocera from comment #27) > (In reply to Hans de Goede from comment #26) > > (In reply to Bastien Nocera from comment #25) > > > (In reply to Tanu Kaskinen from comment #24) > > > > New patches submitted: > > > > https://patchwork.freedesktop.org/series/31556/ > > > > > > I've tested Fedora 26's PulseAudio which includes this series of patches[1] > > > and the alsa-lib change from comment 23, and I can't get any output on the > > > internal audio anymore. > > > > Do you have a ucm file for your SoC / codec combo? : > > > > https://github.com/plbossart/UCM > > > > mkdir /usr/share/alsa/ucm and then copy all the *dirs* from that git repo > > there. > > I have a version of it, as the sound works in older versions. I think it's a > kernel bug, see: > http://mailman.alsa-project.org/pipermail/alsa-devel/2017-October/126407.html Ah, ok, I see this seems to be a problem specific to the surface3, so I cannot reproduce. > [1]: I added this in F25, which got merged in alsa-lib 1.1.2: > http://pkgs.fedoraproject.org/cgit/rpms/alsa-lib.git/commit/ > ?id=15bc4520f97663ab044799b69da0ded29b92be29 Hmm, I did not know there even is a alsa-ucm package on Fedora, it seems nothing requires this, so it does not get installed by default. Anyways this is off-topic for this bugzilla. I will send you a mail about this.
*** Bug 102877 has been marked as a duplicate of this bug. ***
*** Bug 103299 has been marked as a duplicate of this bug. ***
Millhouse produced a new version of Libreelec (#1020b) with the patches but on testing there was still no audio. https://forum.kodi.tv/showthread.php?tid=298462&pid=2657726#pid2657726
Can you attach the pulseaudio log (with debug logging)? To get the log, follow these steps: 1. Disable automatic starting of PulseAudio. If your distro uses systemd's socket activation to start PulseAudio, run systemctl --user --now mask pulseaudio.service pulseaudio.socket If your distro doesn't do that, put "autospawn = no" to ~/.config/pulse/client.conf. 2. Stop pulseaudio with "killall pulseaudio" (the previous systemctl command might have stopped it already, though). 3. Start pulseaudio in a terminal with verbose logging: pulseaudio -vv 4. Try to play something. If you hear nothing, then great, you successfully reproduced the bug. 5. Stop pulseaudio with ctrl-c. 6. To return things back to normal, run systemctl --user unmask pulseaudio.service pulseaudio.socket if you masked the service before. And remove the "autospawn = no" line from client.conf if you added it there.
Thank you for the information Tanu Kaskinen. The first command returned the error "Failed to connect to bus: No such file or directory" I then looked for the client.conf folder in ~/.config/pulse/ but there was no folder of that name. I did find one in ~/.etc/pulse/ but despite seemingly having root access, every time I attempted to edit the file, error: 4 was returned and more research indicated that the file is read only and so far I have been unable to find a way to write the edited file in order to reproduce the issue and provide a log.
(In reply to PhilS from comment #33) > The first command returned the error "Failed to connect to bus: No such file > or directory" > > I then looked for the client.conf folder in ~/.config/pulse/ but there was > no folder of that name. > > I did find one in ~/.etc/pulse/ but despite seemingly having root access, > every time I attempted to edit the file, error: 4 was returned and more > research indicated that the file is read only and so far I have been unable > to find a way to write the edited file in order to reproduce the issue and > provide a log. Do you really mean ~/.etc/pulse/, or do you mean /etc/pulse/? I haven't seen anyone replacing ~/.config with ~/.etc, but it wouldn't be impossible to do that. If you meant /etc/pulse/, and ~/.config/pulse/ doesn't exist, maybe pulseaudio is running in the system mode. Is this some kind of an embedded distribution? What does "ps aux | grep pulse" print?
I'm afraid that I don't know the difference between ~/.etc/pulse/ and /etc/pulse/. I just used the same syntax as used in the request to provide a log. I only know that if I start from root then drill down to etc and then pulse I can find the client.conf file. ps aux | grep pulse returns the following: 275 root 0:00 /usr/bin/pulseaudio --system 817 root 0:00 grep pulse The distribution is a form of Libreelec from Millhouse over at the Kodi forums. More information at the thread here https://forum.kodi.tv/showthread.php?tid=298462&pid=2657467#pid2657467 I hope that this helps clarify things to some degree.
Sorry for the delay in replying... (In reply to PhilS from comment #35) > I'm afraid that I don't know the difference between ~/.etc/pulse/ and > /etc/pulse/. Ok, so you don't know what "~" means? It's an abbreviation for the home directory. If your username is "phils", then "~/.config/pulse/" is expanded to "/home/phils/.config/pulse/". > I just used the same syntax as used in the request to provide a log. > > I only know that if I start from root then drill down to etc and then pulse > I can find the client.conf file. > > ps aux | grep pulse returns the following: > > 275 root 0:00 /usr/bin/pulseaudio --system > 817 root 0:00 grep pulse Ok, you're running pulseaudio in the system mode. I had a look at how LibreELEC configures PulseAudio, and it seems to use systemd to start it, so run "systemctl stop pulseaudio" as root. Then run "pulseaudio --system -vv" as root and continue according to my earlier instructions to get the log. I'm not sure this is a PulseAudio issue, though. LibreELEC seems to disable PulseAudio's ALSA functionality, so I would expect that on LibreELEC you're not supposed to use PulseAudio at all to play to HDMI. Maybe PulseAudio is used only for bluetooth output.
> Maybe PulseAudio is used only for bluetooth output. In relation to LibreELEC, this is correct. https://bugs.freedesktop.org/show_bug.cgi?id=103299 should not have been closed as a duplicate of this issue and is unrelated (I've reopened it for that reason). It seems that nobody really knows what has changed in the 4.13 kernel that causes this issue with Cherrytrail hardware, but it almost certainly isn't anything to do with PulseAudio.
Hi All, So I've tried to get hdmi-audio to work on a cherrytrail device with Fedora 27 which contains a pulse version build with the necessary patches. I noticed 2 things: 1) I still need to set "realtime-scheduling = 0" in
Sorry, I accidentally hit save, take 2: Hi All, So I've tried to get hdmi-audio to work on a cherrytrail device with Fedora 27 which contains a pulse version build with the necessary patches. I noticed 2 things: 1) I still need to set "realtime-scheduling = no" in daemon.conf to stop pulse from crashing 2) pulseaudio sees the hdmi as unplugged even after plugging in the hdmi (video does get set up and shown on the monitor) I'm attaching the output from pulseaudio -vv from the following test run: 1) start pulseaudio -vv on a cht device without the hdmi plugged in 2) start pavucontrol 3) plug in hdmi tv 4) See that pavucontrol still sees hdmi as unplugged (and playing audio to it does not work) 5) kill pulseaudio -vv with ctrl+c Regards, Hans
Created attachment 135292 [details] pulse.log
The log looks strange. module-card-restore says that it's restoring profile "off", but then "hdmi-stereo" gets activated anyway. Ok, I found the reason. The log message prints the wrong profile name. module-card-restore is probably setting the profile to "hdmi-stereo" in reality. module-card-restore shouldn't do that, because "hdmi-stereo" is not available. The availability check seems to be missing. I'll make a patch for module-card-restore. That should prevent the unavailable "hdmi-stereo" profile from getting activated. Of course, since you have HDMI plugged in, the expected result would actually be that the "hdmi-stereo" profile would be available, but the kernel driver is definitely behaving as if there was no cable plugged in. It's not just wrong jack status being reported to userspace, the driver is actually refusing to play any audio.
I split the module-card-restore changes to two patches: https://patchwork.freedesktop.org/patch/187101/ https://patchwork.freedesktop.org/patch/187102/
Thank you for looking into this. So if I've understood correctly, at this point this seems to be (mostly) a kernel bug, correct? Is there an easy way to check the kernels view of hdmi being plugged in or not without using pulse ? Also do you perhaps know the code where the jack status for hdmi gets set so that I can add some debug printk-s to the kernel there? I've the feeling that the restore patches are mostly to avoid errors in the log, do I need to patch my pa with these for further hdmi audio testing ?
The incorrect jack status is purely a kernel problem, yes. I'm not familiar with the kernel code, unfortunately, so I can't really provide further pointers. If module-card-restore sets the card profile to "hdmi-stereo" when it's unavailable, PulseAudio will keep crashing if realtime-scheduling is enabled. Instead of patching PulseAudio, you can just remove module-card-restore from /etc/pulse/default.pa while testing.
(In reply to Hans de Goede from comment #43) > Is there an easy way to check the kernels view of hdmi being plugged in or > not without using pulse ? I didn't notice this question until after sending my previous comment... The status of all jacks for an alsa card can be checked with this little script: while read -r line; do amixer -cX cget "$line"; done <<< $(amixer -cX controls | grep Jack) Replace the two X's with the card index.
Ah, if the pa changes fix the realtime issue they are worthwhile to have even without them fixing hdmi, because currently the realtime issue breaks pa altogether on Bay and Cherrytrail systems. I will start a Fedora pa scratchbuild with these patches added and see if that fixes the need for disabling realtime-scheduling. As for the kernel-side issue causing hdmi audio out to not work, do any of the kernel devs reading along have an idea where to start with debugging this?
I can confirm that these 2 patches: https://patchwork.freedesktop.org/patch/187101/ https://patchwork.freedesktop.org/patch/187102/ Allow pulseaudio to run on Cherry Trail hardware without needing realtime-scheduling=no.
Hello, Is there any news regarding the integration of those above patches ? I have a PC that I cannot put into production because of that bug and am eagerly waiting for this fix. :-) Is there any way I can help any further ?
I believe this bug prevents sound from working on the Asus Transformer Book series. If the patch is working, could we get an ETA on when if will be merged? If there is anything we can do to speed this along, please let us know.
It was reported that even with all patches applied, PulseAudio still was being killed when unplugging the HDMI cable. I have now submitted a fix for this. Here's the complete list of patches related to this bug that are not yet in master: Jack detection fixes: https://patchwork.freedesktop.org/patch/181163/ https://patchwork.freedesktop.org/patch/181164/ https://patchwork.freedesktop.org/patch/181165/ Infinite loop fixes (only the first patch is needed, but if there are still problems, the last two patches will make debugging easier): https://patchwork.freedesktop.org/patch/195092/ https://patchwork.freedesktop.org/patch/195091/ https://patchwork.freedesktop.org/patch/195093/ After these patches there still remains the problem that PulseAudio doesn't automatically move streams away from the HDMI sink when the HDMI cable is unplugged. I plan to fix that as well.
I now submitted patches for the automatic stream moving: https://patchwork.freedesktop.org/patch/195132/ https://patchwork.freedesktop.org/patch/195133/
(In reply to Tanu Kaskinen from comment #51) > I now submitted patches for the automatic stream moving: > https://patchwork.freedesktop.org/patch/195132/ > https://patchwork.freedesktop.org/patch/195133/ The second patch is buggy. v2 here: https://patchwork.freedesktop.org/patch/195135/
Tanu, Thank you for all your work on this! I don't think I will find time to test this before 2018 :), but I will definitely give this a try soonish. Regards, Hans
The infinite loop fix is now in master. The automatic stream moving patch will be replaced with a different approach. The jack detection fixes are still waiting for review.
(In reply to Tanu Kaskinen from comment #54) > The infinite loop fix is now in master. > > The automatic stream moving patch will be replaced with a different approach. > > The jack detection fixes are still waiting for review. Ok, so I won't be testing this then (since the patches are already applied / resp. obsolete). Thank you for the update.
The jack detection fixes are now in master. The only remaining thing is the automatic stream moving away from the HDMI sink when it becomes unavailable. I haven't written the patches for that yet, and most likely that feature won't get in the upcoming 12.0 release.
*** Bug 106645 has been marked as a duplicate of this bug. ***
Tanu, is it possible to hide HDMI Audio output on devices without HDMI output? For example on Lenovo Miix2 8 there is no HDMI. As far I remember it's indicated by HDMI EDID that contain only zero, but in necessary I could double check that.
I believe that all pulseaudio issues with LPE HDMI have been fixed in the current pulseaudio master git branch as well as in the 12.0 prereleases (the 11.99.x releases). I have been running these for a while now on various Bay Trail and Cherry Trail systems while keeping realtime scheduling enabled without any issues. There still is one remaining issues where audio streams are not automatically moved away from the HDMI on HDMI unplug, instead they get paused. But that is probably best tracked in a separate bug.
(In reply to russianneuromancer from comment #58) > Tanu, is it possible to hide HDMI Audio output on devices without HDMI > output? For example on Lenovo Miix2 8 there is no HDMI. As far I remember > it's indicated by HDMI EDID that contain only zero, but in necessary I could > double check that. What does the EDID contain when there is an HDMI output but cable is not plugged in? If it's possible to distinguish the two cases of no HDMI output at all and HDMI output with nothing plugged in, then it would be possible to implement automatic ignoring of non-existent HDMI devices in PulseAudio. It would seem more appropriate to do that already in the kernel, though.
Closing bug, since the stream moving issue is not specific to the LPE driver.
(In reply to Tanu Kaskinen from comment #60) > (In reply to russianneuromancer from comment #58) > > Tanu, is it possible to hide HDMI Audio output on devices without HDMI > > output? For example on Lenovo Miix2 8 there is no HDMI. As far I remember > > it's indicated by HDMI EDID that contain only zero, but in necessary I could > > double check that. > > What does the EDID contain when there is an HDMI output but cable is not > plugged in? If it's possible to distinguish the two cases of no HDMI output > at all and HDMI output with nothing plugged in, then it would be possible to > implement automatic ignoring of non-existent HDMI devices in PulseAudio. It > would seem more appropriate to do that already in the kernel, though. AFAIK we already have jack-detect for HDMI in newer pulseaudio + kernel combos, if there is no external HDMI the i915 should not detect a HDMI calbe being plugged in and pulseaudio will ignore the HDMI output.
(In reply to Hans de Goede from comment #62) > AFAIK we already have jack-detect for HDMI in newer pulseaudio + kernel > combos, if there is no external HDMI the i915 should not detect a HDMI calbe > being plugged in and pulseaudio will ignore the HDMI output. Yes, the HDMI output will be ignored in the sense that it won't be selected as the default output, but a card will be created nevertheless (at least if we're talking about the LPE driver - other hardware may just create HDMI ports on a card that is shared with analog output, but I digress). If the computer doesn't have any physical HDMI outputs, as I understood to be the case with Lenovo Miix 8, then it would be better to not create a card or ports for HDMI (and ideally the HDMI stuff would already be suppressed by the kernel).
> What does the EDID contain when there is an HDMI output but cable is not plugged in? On devices with physical HDMI output get-edid return nothing (because no devices HDMI is attached). On devices without HDMI output, such as Lenovo Miix2 8, EDID contain this: [ 5.431895] i915 0000:00:02.0: HDMI-A-2: EDID is invalid: [ 5.431902] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.431904] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.431906] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.431908] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.431910] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.431912] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.431914] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 5.431916] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > It would seem more appropriate to do that already in the kernel, though. So I should fill separate report here, at freedesktop, or at kernel's bugzilla? Which component I should choice?
Here's information about submitting alsa bugs: http://alsa-project.org/main/index.php/Bug_Tracking
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.