Created attachment 124791 [details]
dmesg

dmesg output (personal information removed)

Created attachment 124801 [details]
.config for kernel 3.13.1 from gentoo-sources

my complete .config file that I used to build the kernel

Created attachment 124831 [details]
dmesg output for 3.12.9 kernel

Except for the exception it looks almost the same. With 3.12.9 and previous kernels the sound works. I’m now on 3.12.9.

# uname -a
Linux localhost.none 3.12.9-gentoo #1 SMP Wed Feb 5 23:00:29 CET 2014 x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux

Created attachment 124841 [details]
.config for the 3.12 kernel series

As you can see I didn’t change much from my .config for 3.12.x to 3.13.x.

Moved to the sound component to solve the sound problem firstly.

Give alsa-info.sh outputs on both 3.12 and 3.13 kernels.
Run it with --no-upload option and attach the generated output files to bugzilla.

Created attachment 125191 [details]
alsa-info 3.12.9

This is the 3.12.9 output. Sound levels are the same from what I see in KDE mixer. I also used pavucontrol which normally lets me set things that aren’t covered by KDE mixer.
I was working and the uptime was > 12h so there are some more modules loaded (crpyto stuff) compared to the 3.13.1 output

Created attachment 125201 [details]
alsa-info 3.13.1

UPDATE:

I don’t know why, but now the some comes via HDMI. I always used the line-out.

I’ve connected my monitor via a HDMI cable. Additionally I’ve connected the line-out from the motherboard with the line-in from the monitor. My headphones are connected to the line-out on the monitor (or I use the speakers from the monitor).

The monitor is normally set to "PC Mode" i.e. line-in/out.
I now selected HDMI and I hear the sound again.


So why is it that way? And where is my line-out sound?

Anyway, I have my sound back so this issue isn’t urgent anymore.

UPDATE #2:

With pavucontrol I see the sound level in realtime and the level is NOT shown on the HDMI output, which is deselected and muted. I see the level move on the "Interal audio"…

Is pulseaudio the troublemaker?

UPDATE #3:

Okay, so I played around with it a little bit, and now I’m even more confused. I turned off the HDMI profile in the configuration tab of pavucontrol. No sound, all muted, but I still see the levels in realtime on the "Internal Audio" device in the "output devices" tab.

BUT... turning it back on, now I hear the sound via line-out on the monitor ("PC Mode") and no sound when on "Video Mode" i.e. HDMI. This is correct, BUT when I turn off the HDMI sound (HDMI profile in the configuratiion tab of pavucontrol) all is muted again, but the levels continue to be shown in realtime on the "Internal Audio" device.

Something has been screwed up completely...

Created attachment 125211 [details]
alsa-info on 3.13.1 after comment 11 (UPDATE #3)

This differs a bit from the initial fresh setup after boot-up. Again: sound now works via line-out, but HDMI sound has to be turned on, otherwise all sound is gone. I normally prefer the line-out "Internal Audio" device, not the HDMI sound from the graphics card (which isn’t used anyway, but has to be on????).

Created attachment 125221 [details]
dmesg for 3.13.1

And one more strange thing happened.

I assure you, I’ve booted the 3.13.x kernels about 5 times, fresh from starting the computer and after a session on 3.12.x. So I already did both cases.

Now, because I needed the alsa-info on 3.13.1 I booted it once more (same as initial dmesg with error) and the tick-broadcast.c:668 error message is gone.

????

Since I _never_ had such a message with 3.12.x, I still hope my hardware isn’t at fault here.

I’ll try once more.

Created attachment 125231 [details]
dmesg 3.13.1 again with tick-broadcast.c:668

I cold rebooted (i.e. turned the PC off and powered it back up) and this time I went straight into 3.13.1. The tick-broadcast.c:668 was there again.

One other thing I noticed: when I return from KDE to the text mode screen (accellerated console) I now see some sort of overscan because the outer parts of the text isn’t displayed, it is cut away. This does hot happen on 3.12.x.

No change with the sound. Except I now noticed the monitor automatically changed from "PC Mode" (line-out) to "Video Mode" (HDMI sound). The sound came immediately after telling the monitor to use "PC Mode", but it still depends on HDMI being active in pavucontrol.

pulseaudio only check the  state of Line Out front jack (green) to determine Line out is available 

although you can get front signal from the side jack (grey) as the alsa driver copy front to all jacks


	control.42 {
		iface CARD
		name 'Line Out Front Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.43 {
		iface CARD
		name 'Line Out Surround Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.44 {
		iface CARD
		name 'Line Out CLFE Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.45 {
		iface CARD
		name 'Line Out Side Jack'
		value true
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.46 {
		iface CARD
		name 'Front Headphone Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}

Created attachment 125241 [details]
alsa-info on 3.12.9 with HDMI deactived

I’m now on 3.12.9 again. No error or delay on boot.

I rechecked if I get the same behaviour as in 3.13.1 (I wouldn’t have noticed before). I deactivated HDMI output and all is normal. Thus, 3.12.9 works as expected and the fault was introduced with 3.13.0.

In a nutshell (audio):
3.12: I get sound on the monitor per default over line-out.
3.13: The monitor somehow switches to HDMI per default.

3.12: I hear sound from line-out even if HDMI is deactivated via pavucontrol
3.13: I only hear line-out if also HDMI is selected as profile in configuration tab of pavucontrol

In a nutshell (tick-broadcast.c:668):
3.12: never did I get this error message
3.13: I had it always except once when I rebooted from 3.12.9 after a days uptime. Not reproducable.

3.12: on shutdown the screen is set correctly to text mode.
3.13: only after the KDE X session is terminated on shutdown I get some kind of unintentional overscan picture that cuts away the text on both sides.

The difference of 3.13 kernel is that it supports finally AMD HDMI codec properly, thus it can expose ELD and notify the plug/unplugging state.  That's why PA switched to HDMI after boot.  Since the HDMI is always handled as a hotplugged device (yes it is), and PA prefers the hotplugged device over the static one (e.g. when you plug a USB device, PA picks it up soon), the HDMI appears there as the primary output.

That being said, this is no regression but it's a designed feature from kernel perspective; the only issue is that you don't like PA's default behavior.  But this has nothing to do with the kernel.

So, from the kernel POV, the only interesting point is whether all streams can be handled properly, ELD is passed, and the hotplug state is notified.

Nevertheless, the tick-broadcast message is irrelevant with the sound.  Let's focus on the audio issue for now.

For checking the behavior, try to test without PulseAudio.  Disable the autospawn option of PA configuration, and kill PA at first.  Then for the analog output, you should be able to play via
    % aplay -Dplughw:0 -vv foo.wav
while for HDMI,
    % aplay -Dhdmi:1 -vv foo.wav

And the mixer items can be changed via
    % alsamixer -c0
or
    % alsamixer -c1

Check whether the above native ALSA access works.

*** Bug 69561 has been marked as a duplicate of this bug. ***

Created attachment 125281 [details]
screenshot with alsamixer

I reboot with 3.13.1. I disabled PulseAudio simply by renaming /usr/bin/PulseAudio. I disabled all X activity so I say on the text console.

I tried the aplay on plughw:0 and it works.
I tried it on hdmi:1 but it said it doesn’t support this specific wav file i used.

I then started X using "systemclt start kdm.service" (I use systemd).

In KDE I was informed that the HDMI device was missing. The mixer is very limited. NO SOUND. I used alsamixer in Konsole and I can hear a very low volume when I turn on the slider titled "side".

So using KDE it got even worse.

Created attachment 125291 [details]
alsa-info

after what I did in comment 19 I ran alsa-info once again...

With the same system as booted in comment 19 and comment 20 I found a sound suitable to be played with hdmi:1 and it sounds right. I have to select "Video Mode" on the monitor, naturally.

Strangely I can also hear it on "PC Mode" i.e. via the line-out from the ALC onboard soundcard, but at a lower volume and a with a bit of white noice on it (whereas via HDMI it is cristal clear).

Playing the same sound via plughw:0 has the same issue as in KDE in general: it is at a low volume (although volume is up at 100% on all available channels; "PC Mode" on the monitor, naturally). No sound when selecting "Video Mode" – as expected.

I did all this with X running and KDE as the desktop (no reboot since comment 19 and comment 20).

[   30.583567] usbcore: registered new interface driver snd-usb-audio
[   30.611489] Linux video capture interface: v2.00
[   30.624190] uvcvideo: Found UVC 1.00 device Philips SPZ2000 (0471:20d0)
[   30.641115] input: Philips SPZ2000 as /devices/pci0000:00/0000:00:12.0/usb4/4-5/4-5:1.0/input/input19
[   30.641373] usbcore: registered new interface driver uvcvideo
[   30.641375] USB Video Class driver (1.1.1)
[   32.682153] r8169 0000:08:00.0 enp8s0: link down
[   32.682183] IPv6: ADDRCONF(NETDEV_UP): enp8s0: link is not ready
[   32.738177] r8169 0000:07:00.0 enp7s0: link down
[   32.738192] IPv6: ADDRCONF(NETDEV_UP): enp7s0: link is not ready
[   32.738221] r8169 0000:07:00.0 enp7s0: link down
[   35.123526] r8169 0000:07:00.0 enp7s0: link up
[   35.123543] IPv6: ADDRCONF(NETDEV_CHANGE): enp7s0: link becomes ready
[   43.292238] type=1006 audit(1391858874.587:2): pid=4211 uid=0 old auid=4294967295 new auid=8192 old ses=4294967295 new ses=1 res=1
[  235.699595] type=1006 audit(1391859066.988:3): pid=4419 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=2 res=1
[  249.918016] Clocksource tsc unstable (delta = -210127313 ns)
[  251.599294] Switched to clocksource hpet
[  264.054488] type=1006 audit(1391859095.343:4): pid=4465 uid=0 old auid=4294967295 new auid=8192 old ses=4294967295 new ses=3 res=1
[  326.865645] virtuoso-t[5007]: segfault at 0 ip           (null) sp 00007ffffe03ac98 error 14 in virtuoso-t[400000+9d9000]
[ 1262.262608] hrtimer: interrupt took 420302231 ns
[12317.426671] hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.

The last message may be of interest. It seems to have happened when I played the sound via aplay.

Created attachment 125321 [details]
screen photo on 3.12.9 in text mode after switching from X

After X has been started, when switching back to a text console (e.g. Ctrl+Alt+F1) I normally see a full screen like this.
See how the screen is used to about 100% and there are no real edges or unused borders. This is how it is on 3.12.9 and earlier.

Graphics card: Radeon HD 6670

Created attachment 125331 [details]
screen photo on 3.13.1 in text mode after switching from X

Now, this happens only after X has been startet. Before X, everything looks normal. After X has been started however, this is what happens when I switch back to a text console and it also happens on shutdown (after X is terminated). Note how the first and the last line is completely out of sight. I typed "dmesg" and I cannot even see the command prompt below its output.

Created attachment 125341 [details]
Xorg.0.log

This is interesting... last time I’ve checked I didn’t see all these /dev/input/event* statements that are cought by my joystick-all rule but ignored due to a missing driver...

This rule is in /usr/share/X11/xorg.conf.d/50-joystick-all.conf and MatchIsJoystick is commented out. I guess I have to change this.

I thought of it because it worked before X was initialized over line-out, but didn’t anymore once X was started.

Created attachment 125351 [details]
Xorg.0.log on 3.12.9

So, I was wrong. On 3.12.9 there is also a lot of SB HDMI /dev/input/event* stuff going on.

I’m now testing pure ALSA sound and it works as expected with 3.12.9 kernel. Comment 25 was while running on 3.13.1 BTW.


I like to summarize:
3.12.x:
1) Sound works.
2) Graphics works.
3) no tick-broadcast.c:668 exception

3.13.0/3.13.1:
1) Sound problems.
2) Graphics behaves differently.
3) tick-broadcast.c:668 exception

(In reply to Andreas from comment #26)
> So, I was wrong. On 3.12.9 there is also a lot of SB HDMI /dev/input/event*
> stuff going on.

Correction: "HDA ATI SB" stuff...

https://lkml.org/lkml/2013/10/17/114

(In reply to Raymond from comment #28)
> https://lkml.org/lkml/2013/10/17/114

Thanks, I found similar cases, but this message appears for me on initial boot, not on resume. Additionally, it appears with 3.13 but didn’t appear on 3.12 and earlier.

Created attachment 125441 [details]
dmesg on 3.14-rc1

So this is the dmesg output from 3.14-rc1. You can see that the tick-broadcast.c:668 message is still there.

I turned on ALSA debug output.
* At timestamp 314 I switched from X (with KDE started and logged in) to a text console.
* At timestamp 318 I switched back to X
* At timestamps 369+ I played a song via Amarok

It turnes out that sound now works again. I re-instated PulseAudio and now I was able to deactivate HDMI sound completely without the onboard ALC codec muting everything. Sound is cristal clear.
Only issue: the monitor automatically selects HDMI ("Video mode") as sound source and I have to manually select line-in ("PC Mode").

Created attachment 125451 [details]
alsa-info on 3.14-rc1

Created attachment 125461 [details]
Xorg.log on 3.14-rc1

Created attachment 125471 [details]
.config on 3.14-rc1

Apart from turning on ALSA debug output I didn’t change much.

So sound seems to be fixed in 3.14-rc1.
What still is an issue:
1) tick-broadcast.c:668
2) graphics output when switching back to a text console

OK, then I reassign to DRM.

For the tick-broadcast.c, try to bisect.

It looks like your monitor may be enabling overscan.  A lot of TVs enable this automatically for hdmi.  See if you can disable it in your monitor's controls.  You can disable hdmi packet generation in the radeon driver by appending radeon.audio=0 to the kernel command line in grub.  If disabling audio in radeon helps, then it's most likely your monitor enabling the overscan upon detection of hdmi packets from the source device.

(In reply to Alex Deucher from comment #35)
> appending radeon.audio=0 to the kernel command line in grub.

Thanks!

Actually I have to apologize for my incompetence. With the new radeon driver from 3.13+ my monitor did two things after initialization of X:
1) it automatically selected overscan (an option I did not see before)
2) it selected "Video Mode" (= HDMI) as audio source

The solution therefore is to add radeon.audio=0. With it I don’t even get the overscan option on the monitor and audio defaults to "PC Mode" as intended. (This restores the old behaviour I am used to up to kernel 3.12.)

Again, thanks!

One more info with "nice to know" character:

Without radeon.audio=0 I also no longer see the color settings menu from the monitor – it is grayed out. Seems that this is covered by the radeon driver and the HDMI standard somehow?

Anyway, now with radeon.audio=0 I see the following possible color settings:
* sRGB
* 6500 K
* 7500 K
* 9300 K
* native
* user defined

I selected sRGB.
It would be interesting to know what is used when it is grayed out (without the radeon.audio=0 option)...

(In reply to Takashi Iwai from comment #34)
> For the tick-broadcast.c, try to bisect.

To summarize:
[SOLVED] sound issue
[SOLVED] overscan issue
[      ] kernel/time/tick-broadcast.c:668

The thing is: I don’t know how to bisect.

Question: I now run this kernel with this exception. At least I think it is an exception. Nevertheless, the kernel runs stable. Which leads me to the questions: Can I live with it? Do I really need to bother about it?

In addition to the module parameter, you can adjust audio support at runtime per connector with xrandr, e.g.,

xrandr --output HDMI-0 --set audio off
or
xrandr --output HDMI-0 --set audio auto

(In reply to Alex Deucher from comment #39)
> In addition to the module parameter, you can adjust audio support at runtime
> per connector with xrandr, e.g.,

Thanks, I’ll try it on the next reboot. I tried it now but (most likely) due to the module parameter I get an error:

$ xrandr --output HDMI-0 --set audio auto
X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  139 (RANDR)
  Minor opcode of failed request:  11 (RRQueryOutputProperty)
  Serial number of failed request:  41
  Current serial number in output stream:  41


Anyway, I’m thinking if I did use xrandr to later on disable audio it will most likely be too late, as the monitor will already be set to the wrong audio source and possibly overscan will remain selected.

I would not have believed it, but the xrandr option also works. Running

$ xrandr --output HDMI-0 --set audio off

actually resets the screen and everything is as it should be: Audio is automatically switch from "Video Mode" to "PC Mode" and the color settings menu gets accessible while overscan is off and disappears from the menu.

Thanks!

Which leaves only the tick-broadcast.c issue. I searched for bisect but I’m not sure how to use this successfully. Also, I’m not a git expert. I take it I should try to find the first commit that introduced this issue. Where do I start? At the rc state of 3.13?

Is there a link to a good howto you can point me to? And a hint on how and where to start?

Just google for "git bisect howto".  There are lots of good examples.  Here's one: http://webchick.net/node/99
You need a kernel git tree.  The closer you can narrow the breakage down, the faster it will be.  Basically, if you know that 3.12 was good and 3.13 was broken, you'd start like this:
git bisect start
git bisect bad v3.13
git bisect good v3.12
Then build and test the kernel for each iteration until it arrives at the problematic commit.

Should I git clone
1) git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
2) git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

I don’t really understand how to get kernel 3.13 and 3.12 and the commits in between...

E.g. I found this: http://www.project-insanity.org/blog/2013/02/13/how-i-found-a-kernel-regression-using-git-bisect/

But how will I find out commits like 49b8c695e331c9685e6ffdbf34872509d77c8459?

Anyway I git clone the linux-stable source now and I will use the bisect as you suggested. And I understand I will have to reboot my system quite a lot...

git log --oneline v3.12..v3.13 kernel/time/

7a06c41 sched_clock: Disable seqlock lockdep usage in sched_clock()
0e576ac nohz: Fix another inconsistency between CONFIG_NO_HZ=n and nohz=off
4be7739 time: Fix 1ns/tick drift w/ GENERIC_TIME_VSYSCALL_OLD
050ded1 tick: Document tick_do_timer_cpu
d689fe2 NOHZ: Check for nohz active instead of nohz enabled
8709382 Merge branch 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
891292a time: Fix signedness bug in sysfs_get_uname() and its callers
b7bc50e timekeeping: Fix some trivial typos in comments
98d6f4d alarmtimer: return EINVAL instead of ENOTSUPP if rtcdev doesn't exist
2cb7636 timer stats: Add a 'Collection: active/inactive' line to timer usage statistics
8a749de Merge branch 'fortglx/3.13/time' of git://git.linaro.org/people/jstultz/linux into timers/core
b4042ce sched_clock: Remove sched_clock_func() hook
68e9074 Merge branch 'clockevents/3.13' of git://git.linaro.org/people/dlezcano/linux into timers/core
19f2988 Merge branch 'timers/core' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks into timers/core
6c09f6d Merge tag 'v3.12-rc3' into timers/core
245a349 tick: broadcast: Deny per-cpu clockevents from being broadcast sources
ff3fb25 nohz: Drop generic vtime obsolete dependency on CONFIG_64BIT
554b000 vtime: Add HAVE_VIRT_CPU_ACCOUNTING_GEN Kconfig
233bcb4 clocksource: Fix 'ret' data type of sysfs_override_clocksource() and sysfs_unbind_clocksource()
389e067 Merge branch 'fortglx/3.12/time' into fortglx/3.13/time
19c3205 Merge branch 'fortglx/3.12/sched-clock64-base' into fortglx/3.13/time
a97ad0c ntp: Make periodic RTC update more reliable
e7e3ff1 sched_clock: Add support for >32 bit sched_clock
a08ca5d sched_clock: Use an hrtimer instead of timer
85c3d2d sched_clock: Use seqcount instead of rolling our own
87d8b9e clocksource: Extract max nsec calculation into separate function
397bbf6 clocksource: Fix !CONFIG_CLOCKSOURCE_WATCHDOG compile


I only which I knew what to do with it. Right now I’m still trying to find out how to actually compile the selected "bisect" kernel...

Got it, working on it... Will report the result in a couple of days...

(and the timer bug is unrelated but fix posted to lkml by Thomas Gleixner
WARNING: CPU: 1 PID: 0 at kernel/time/tick-broadcast.c:668 tick_broadcast_oneshot_control+0x17d/0x190())

Hello again.

I’m sorry, but I won’t make it soon. I’ve got a lot of work to do right now and since most issues are solved I can use my computer for now.

I will do the bisect, but it will take some more time. Weeks maybe. I won’t forget it thou and hopefully I will be able to identify the commit before 3.14 is out.

Sorry for the delay.

Okay, I appologize, but I’ve been _very_ busy since my last message. I just installed kernels 3.12.14 an 3.13.6 and I am now running on 3.13.6:

1) the kernel/time/tick-broadcast.c:668 error message is gone.
2) sound works, because I switched from the gray to the green Line Out jack as proposed by Raymond in comment #15 – otherwise sound was still muted.

To summerize:
[SOLVED] sound issue
   +------- green jack on 3.13.x
   +------- gray/green jack on 3.12.x/earlier and 3.14-rc1/later
[SOLVED] overscan issue
   +------- disable audio for HDMI output
[SOLVED] kernel/time/tick-broadcast.c:668
   +------- gone in 3.13.6, not present in 3.12.x, unknown for 3.14-rc


Thanks for all your help!