Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1742787 > unrolled thread
| Started by | Thorsten Leemhuis <regressions@leemhuis.info> |
|---|---|
| First post | 2017-10-01 14:50 +0200 |
| Last post | 2017-10-01 15:20 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [regression 4.14rc] 74def747bcd0 (genirq: Restrict effective affinity to interrupts actually using it) Thorsten Leemhuis <regressions@leemhuis.info> - 2017-10-01 14:50 +0200
Re: [regression 4.14rc] 74def747bcd0 (genirq: Restrict effective affinity to interrupts actually using it) Yanko Kaneti <yaneti@declera.com> - 2017-10-01 15:10 +0200
Re: [regression 4.14rc] 74def747bcd0 (genirq: Restrict effective affinity to interrupts actually using it) Thorsten Leemhuis <regressions@leemhuis.info> - 2017-10-01 15:20 +0200
| From | Thorsten Leemhuis <regressions@leemhuis.info> |
|---|---|
| Date | 2017-10-01 14:50 +0200 |
| Subject | Re: [regression 4.14rc] 74def747bcd0 (genirq: Restrict effective affinity to interrupts actually using it) |
| Message-ID | <uvLR0-2em-7@gated-at.bofh.it> |
Hi, the regression tracker here. What's the status of this issue? Was the problem fixed? It seems nothing happened for more than 10 days -- or did the discussion move somewhere else? Ciao, Thorsten On 20.09.2017 02:30, Chuck Ebbert wrote: > On Tue, 19 Sep 2017 16:51:06 +0100 > Marc Zyngier <marc.zyngier@arm.com> wrote: > >> On 19/09/17 16:40, Yanko Kaneti wrote: >>> On Tue, 2017-09-19 at 16:33 +0100, Marc Zyngier wrote: >>>> On 19/09/17 16:12, Yanko Kaneti wrote: >>>>> Hello, >>>>> >>>>> Fedora rawhide config here. >>>>> AMD FX-8370E >>>>> >>>>> Bisected a problem to: >>>>> 74def747bcd0 (genirq: Restrict effective affinity to interrupts >>>>> actually using it) >>>>> >>>>> It seems to be causing stalls, short lived or long lived lockups >>>>> very shortly after boot. Everything becomes jerky. >>>>> >>>>> The only visible in the log indication is something like : >>>>> .... >>>>> [ 59.802129] clocksource: timekeeping watchdog on CPU3: Marking >>>>> clocksource 'tsc' as unstable because the skew is too large: >>>>> [ 59.802134] clocksource: 'hpet' wd_now: >>>>> 3326e7aa wd_last: 329956f8 mask: ffffffff [ 59.802137] >>>>> clocksource: 'tsc' cs_now: 423662bc6f >>>>> cs_last: 41dfc91650 mask: ffffffffffffffff [ 59.802140] tsc: >>>>> Marking TSC unstable due to clocksource watchdog [ 59.802158] >>>>> TSC found unstable after boot, most likely due to broken BIOS. >>>>> Use 'tsc=unstable'. [ 59.802161] sched_clock: Marking unstable >>>>> (59802142067, 15510)<-(59920871789, -118714277) [ 60.015604] >>>>> clocksource: Switched to clocksource hpet [ 89.015994] INFO: >>>>> NMI handler (perf_event_nmi_handler) took too long to run: >>>>> 209.660 msecs [ 89.016003] perf: interrupt took too long >>>>> (1638003 > 2500), lowering kernel.perf_event_max_sample_rate to >>>>> 1000 .... >>>>> >>>>> Just reverting that commit on top of linus mainline cures all the >>>>> symptoms >>>> >>>> Interesting. Do you still get HPET interrupts? >>> >>> Sorry, I might need some basic help here (i.e where do I count >>> them...) >> >> /proc/interrupts should display them. >> >>> After the watchdog switches the clocksource to hpet the system is >>> still somewhat alive, so I'll guess some clock is still >>> ticking.... >> Probably, but I suspect they're not hitting the right CPU, hence the >> lockups. >> >> Unfortunately, my x86-foo is pretty minimal, and I'm about to drop off >> the net for a few days. >> >> Thomas, any insight? > > Looking at flat_cpu_mask_to_apicid(), I don't see how 74def747bcd0 > can be correct: > > struct cpumask *effmsk = > irq_data_get_effective_affinity_mask(irqdata); unsigned long > cpu_mask = cpumask_bits(mask)[0] & APIC_ALL_CPUS; > > if (!cpu_mask) > return -EINVAL; > *apicid = (unsigned int)cpu_mask; > cpumask_bits(effmsk)[0] = cpu_mask; > > Before that patch, this function wrote to the effective mask > unconditionally. After, it only writes to effective_mask if it is > already non-zero. > > > http://news.gmane.org/find-root.php?message_id=20170919203044.560cb9f1%40gmail.com > http://mid.gmane.org/20170919203044.560cb9f1%40gmail.com >
[toc] | [next] | [standalone]
| From | Yanko Kaneti <yaneti@declera.com> |
|---|---|
| Date | 2017-10-01 15:10 +0200 |
| Message-ID | <uvMam-2AV-15@gated-at.bofh.it> |
| In reply to | #1742787 |
On Sun, 2017-10-01 at 14:46 +0200, Thorsten Leemhuis wrote: > Hi, the regression tracker here. What's the status of this issue? Was > the problem fixed? It seems nothing happened for more than 10 days -- or > did the discussion move somewhere else? Ciao, Thorsten The commit was reverted last week before rc2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0551968add53777fddd18f4ffb4e3bbc1f646d79 Thanks for tracking it -Yanko > > On 20.09.2017 02:30, Chuck Ebbert wrote: > > On Tue, 19 Sep 2017 16:51:06 +0100 > > Marc Zyngier <marc.zyngier@arm.com> wrote: > > > > > On 19/09/17 16:40, Yanko Kaneti wrote: > > > > On Tue, 2017-09-19 at 16:33 +0100, Marc Zyngier wrote: > > > > > On 19/09/17 16:12, Yanko Kaneti wrote: > > > > > > Hello, > > > > > > > > > > > > Fedora rawhide config here. > > > > > > AMD FX-8370E > > > > > > > > > > > > Bisected a problem to: > > > > > > 74def747bcd0 (genirq: Restrict effective affinity to interrupts > > > > > > actually using it) > > > > > > > > > > > > It seems to be causing stalls, short lived or long lived lockups > > > > > > very shortly after boot. Everything becomes jerky. > > > > > > > > > > > > The only visible in the log indication is something like : > > > > > > .... > > > > > > [ 59.802129] clocksource: timekeeping watchdog on CPU3: Marking > > > > > > clocksource 'tsc' as unstable because the skew is too large: > > > > > > [ 59.802134] clocksource: 'hpet' wd_now: > > > > > > 3326e7aa wd_last: 329956f8 mask: ffffffff [ 59.802137] > > > > > > clocksource: 'tsc' cs_now: 423662bc6f > > > > > > cs_last: 41dfc91650 mask: ffffffffffffffff [ 59.802140] tsc: > > > > > > Marking TSC unstable due to clocksource watchdog [ 59.802158] > > > > > > TSC found unstable after boot, most likely due to broken BIOS. > > > > > > Use 'tsc=unstable'. [ 59.802161] sched_clock: Marking unstable > > > > > > (59802142067, 15510)<-(59920871789, -118714277) [ 60.015604] > > > > > > clocksource: Switched to clocksource hpet [ 89.015994] INFO: > > > > > > NMI handler (perf_event_nmi_handler) took too long to run: > > > > > > 209.660 msecs [ 89.016003] perf: interrupt took too long > > > > > > (1638003 > 2500), lowering kernel.perf_event_max_sample_rate to > > > > > > 1000 .... > > > > > > > > > > > > Just reverting that commit on top of linus mainline cures all the > > > > > > symptoms > > > > > > > > > > Interesting. Do you still get HPET interrupts? > > > > > > > > Sorry, I might need some basic help here (i.e where do I count > > > > them...) > > > > > > /proc/interrupts should display them. > > > > > > > After the watchdog switches the clocksource to hpet the system is > > > > still somewhat alive, so I'll guess some clock is still > > > > ticking.... > > > > > > Probably, but I suspect they're not hitting the right CPU, hence the > > > lockups. > > > > > > Unfortunately, my x86-foo is pretty minimal, and I'm about to drop off > > > the net for a few days. > > > > > > Thomas, any insight? > > > > Looking at flat_cpu_mask_to_apicid(), I don't see how 74def747bcd0 > > can be correct: > > > > struct cpumask *effmsk = > > irq_data_get_effective_affinity_mask(irqdata); unsigned long > > cpu_mask = cpumask_bits(mask)[0] & APIC_ALL_CPUS; > > > > if (!cpu_mask) > > return -EINVAL; > > *apicid = (unsigned int)cpu_mask; > > cpumask_bits(effmsk)[0] = cpu_mask; > > > > Before that patch, this function wrote to the effective mask > > unconditionally. After, it only writes to effective_mask if it is > > already non-zero. > > > > > > http://news.gmane.org/find-root.php?message_id=20170919203044.560cb9f1%40gmail.com > > http://mid.gmane.org/20170919203044.560cb9f1%40gmail.com > >
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Leemhuis <regressions@leemhuis.info> |
|---|---|
| Date | 2017-10-01 15:20 +0200 |
| Message-ID | <uvMk1-2E8-7@gated-at.bofh.it> |
| In reply to | #1742791 |
On 01.10.2017 15:06, Yanko Kaneti wrote: > On Sun, 2017-10-01 at 14:46 +0200, Thorsten Leemhuis wrote: >> Hi, the regression tracker here. What's the status of this issue? Was >> the problem fixed? It seems nothing happened for more than 10 days -- or >> did the discussion move somewhere else? Ciao, Thorsten > The commit was reverted last week before rc2 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0551968add53777fddd18f4ffb4e3bbc1f646d79 I could have sworn I checked that :-/ Thx for the hint and sorry for the noise! Ciao, Thorsten >> On 20.09.2017 02:30, Chuck Ebbert wrote: >>> On Tue, 19 Sep 2017 16:51:06 +0100 >>> Marc Zyngier <marc.zyngier@arm.com> wrote: >>> >>>> On 19/09/17 16:40, Yanko Kaneti wrote: >>>>> On Tue, 2017-09-19 at 16:33 +0100, Marc Zyngier wrote: >>>>>> On 19/09/17 16:12, Yanko Kaneti wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Fedora rawhide config here. >>>>>>> AMD FX-8370E >>>>>>> >>>>>>> Bisected a problem to: >>>>>>> 74def747bcd0 (genirq: Restrict effective affinity to interrupts >>>>>>> actually using it) >>>>>>> >>>>>>> It seems to be causing stalls, short lived or long lived lockups >>>>>>> very shortly after boot. Everything becomes jerky. >>>>>>> >>>>>>> The only visible in the log indication is something like : >>>>>>> .... >>>>>>> [ 59.802129] clocksource: timekeeping watchdog on CPU3: Marking >>>>>>> clocksource 'tsc' as unstable because the skew is too large: >>>>>>> [ 59.802134] clocksource: 'hpet' wd_now: >>>>>>> 3326e7aa wd_last: 329956f8 mask: ffffffff [ 59.802137] >>>>>>> clocksource: 'tsc' cs_now: 423662bc6f >>>>>>> cs_last: 41dfc91650 mask: ffffffffffffffff [ 59.802140] tsc: >>>>>>> Marking TSC unstable due to clocksource watchdog [ 59.802158] >>>>>>> TSC found unstable after boot, most likely due to broken BIOS. >>>>>>> Use 'tsc=unstable'. [ 59.802161] sched_clock: Marking unstable >>>>>>> (59802142067, 15510)<-(59920871789, -118714277) [ 60.015604] >>>>>>> clocksource: Switched to clocksource hpet [ 89.015994] INFO: >>>>>>> NMI handler (perf_event_nmi_handler) took too long to run: >>>>>>> 209.660 msecs [ 89.016003] perf: interrupt took too long >>>>>>> (1638003 > 2500), lowering kernel.perf_event_max_sample_rate to >>>>>>> 1000 .... >>>>>>> >>>>>>> Just reverting that commit on top of linus mainline cures all the >>>>>>> symptoms >>>>>> >>>>>> Interesting. Do you still get HPET interrupts? >>>>> >>>>> Sorry, I might need some basic help here (i.e where do I count >>>>> them...) >>>> >>>> /proc/interrupts should display them. >>>> >>>>> After the watchdog switches the clocksource to hpet the system is >>>>> still somewhat alive, so I'll guess some clock is still >>>>> ticking.... >>>> >>>> Probably, but I suspect they're not hitting the right CPU, hence the >>>> lockups. >>>> >>>> Unfortunately, my x86-foo is pretty minimal, and I'm about to drop off >>>> the net for a few days. >>>> >>>> Thomas, any insight? >>> >>> Looking at flat_cpu_mask_to_apicid(), I don't see how 74def747bcd0 >>> can be correct: >>> >>> struct cpumask *effmsk = >>> irq_data_get_effective_affinity_mask(irqdata); unsigned long >>> cpu_mask = cpumask_bits(mask)[0] & APIC_ALL_CPUS; >>> >>> if (!cpu_mask) >>> return -EINVAL; >>> *apicid = (unsigned int)cpu_mask; >>> cpumask_bits(effmsk)[0] = cpu_mask; >>> >>> Before that patch, this function wrote to the effective mask >>> unconditionally. After, it only writes to effective_mask if it is >>> already non-zero. >>> >>> >>> http://news.gmane.org/find-root.php?message_id=20170919203044.560cb9f1%40gmail.com >>> http://mid.gmane.org/20170919203044.560cb9f1%40gmail.com >>> >
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web