search for: lockup

...t: >>> On 01-08-14 18:35, Christian K?nig wrote: >>>> Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst: >>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> >>>>> --- >>>>> V1 had a nasty bug breaking gpu lockup recovery. The fix is not >>>>> allowing radeon_fence_driver_check_lockup to take exclusive_lock, >>>>> and kill it during lockup recovery instead. >>>> That looks like the delayed work starts running as soon as we submit a fence, and not when it's neede...

> It'a pain to deal with gpu reset. Yeah, well that's nothing new. > I've now tried other solutions but that would mean reverting to the old style during gpu lockup recovery, and only running the delayed work when !lockup. > But this meant that the timeout was useless to add. I think the cleanest is keeping the v2 patch, because potentially any waiting code can be called during lockup recovery. The lockup code itself should never call any waiting code and...

...4 um 19:46 schrieb Maarten Lankhorst: > > On 01-08-14 18:35, Christian K?nig wrote: >> Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst: >>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> >>> --- >>> V1 had a nasty bug breaking gpu lockup recovery. The fix is not >>> allowing radeon_fence_driver_check_lockup to take exclusive_lock, >>> and kill it during lockup recovery instead. >> That looks like the delayed work starts running as soon as we submit a fence, and not when it's needed for waiting. >>...

It's mostly a cleanup, but in nv50_fbcon_accel_init gpu lockup message was printed, but HWACCEL_DISBALED flag was not set. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 15 +++++++++++---- drivers/gpu/drm/nouveau/nouveau_fbcon.h | 2 ++ drivers/gpu/drm/nouveau/nv04_fbcon.c | 15 +++++...

...On 01-08-14 18:35, Christian K?nig wrote: >>>>> Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst: >>>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> >>>>>> --- >>>>>> V1 had a nasty bug breaking gpu lockup recovery. The fix is not >>>>>> allowing radeon_fence_driver_check_lockup to take exclusive_lock, >>>>>> and kill it during lockup recovery instead. >>>>> That looks like the delayed work starts running as soon as we submit a fence, and not when it...

.... Any suggestion would be very welcome. Marc [ .. more .. ] It appears to be very unpredictable of when it actually occurs, here are a few examples. Kind of odd that on Aug29th it always happened on the same second ;-{. > syslog.2:Aug 29 17:35:47 nwsc-xen-Q45 kernel: [ 2698.560009] BUG: soft lockup - CPU#0 stuck for 146s! [events/0:9] > syslog.2:Aug 29 17:35:47 nwsc-xen-Q45 kernel: [ 2698.561016] BUG: soft lockup - CPU#1 stuck for 146s! [rsyslogd:2024] > syslog.2:Aug 29 22:57:27 nwsc-xen-Q45 kernel: [ 4198.404353] BUG: soft lockup - CPU#0 stuck for 122s! [md1_raid5:1243] > syslog.2:A...

...2014 um 16:40 schrieb Maarten Lankhorst: > op 04-08-14 16:37, Christian K?nig schreef: >>> It'a pain to deal with gpu reset. >> Yeah, well that's nothing new. >> >>> I've now tried other solutions but that would mean reverting to the old style during gpu lockup recovery, and only running the delayed work when !lockup. >>> But this meant that the timeout was useless to add. I think the cleanest is keeping the v2 patch, because potentially any waiting code can be called during lockup recovery. >> The lockup code itself should never call any w...

https://bugzilla.netfilter.org/show_bug.cgi?id=1082 Bug ID: 1082 Summary: Hard lockup when inserting nft rules (esp. ct rule) Product: nftables Version: unspecified Hardware: x86_64 OS: Debian GNU/Linux Status: NEW Severity: blocker Priority: P5 Component: kernel Assignee: pablo at net...

Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst: > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> > --- > V1 had a nasty bug breaking gpu lockup recovery. The fix is not > allowing radeon_fence_driver_check_lockup to take exclusive_lock, > and kill it during lockup recovery instead. That looks like the delayed work starts running as soon as we submit a fence, and not when it's needed for waiting. Since it's a backup for fai...

...>>> op 04-08-14 16:37, Christian K?nig schreef: >>>>> It'a pain to deal with gpu reset. >>>> Yeah, well that's nothing new. >>>> >>>>> I've now tried other solutions but that would mean reverting to the old style during gpu lockup recovery, and only running the delayed work when !lockup. >>>>> But this meant that the timeout was useless to add. I think the cleanest is keeping the v2 patch, because potentially any waiting code can be called during lockup recovery. >>>> The lockup code itself should...

...eds to wait for Intel to finish displaying), this might become a perfect example of locking inversion. > In the preliminary patches where I can sync radeon with other GPU's I've been very careful in all the places that call into fences, to make sure that radeon wouldn't try to handle lockups for a different (possibly also radeon) card. That's actually not such a good idea. In case of a lockup we need to handle the lockup cause otherwise it could happen that radeon waits for the lockup to be resolved and the lockup handling needs to wait for a fence that's never signaled be...

https://bugs.freedesktop.org/show_bug.cgi?id=83992 Priority: medium Bug ID: 83992 Assignee: nouveau at lists.freedesktop.org Summary: [NVE0][NVF1] regression, linux 3.17 causes gpu lockups QA Contact: xorg-team at lists.x.org Severity: critical Classification: Unclassified OS: Linux (All) Reporter: tomenglund26 at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Driver/nou...

https://bugs.freedesktop.org/show_bug.cgi?id=69029 Priority: medium Bug ID: 69029 Assignee: nouveau at lists.freedesktop.org Summary: GT218 (NVA8): GPU lockup since kernel 3.11 upgrade QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: fred at crozat.net Hardware: x86-64 (AMD64) Status: NEW Version: git Compo...

Like many others on this list, I had been experiencing periodic lockups with my Grandstream products (Handytone 286 ATA & BudgeTone 101). The lockups consisted of seemingly dead devices, no dialtone or response, until I power cycled via software or hardware. The workaround had been to reboot the device every 30 minutes with a cron job. I contacted Grandstream a...

Hi, when creating a bigger (> 50 GB) HVM guest with maxmem > memory we get softlockups from time to time. kernel: [ 802.084335] BUG: soft lockup - CPU#1 stuck for 22s! [xend:31351] I tracked this down to the call of xc_domain_set_pod_target() and further p2m_pod_set_mem_target(). Unfortunately I can this check only with xen-4.2.2 as I don''t have a machine with enough me...

Am 23.07.2014 09:31, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig > <deathsimple at vodafone.de> wrote: >> It's not a locking problem I'm talking about here. Radeons lockup handling >> kicks in when anything calls into the driver from the outside, if you have a >> fence wait function that's called from the outside but doesn't handle >> lockups you essentially rely on somebody else calling another radeon >> function for the lockup to be...

...en Lankhorst: >> >> On 01-08-14 18:35, Christian K?nig wrote: >>> Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst: >>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> >>>> --- >>>> V1 had a nasty bug breaking gpu lockup recovery. The fix is not >>>> allowing radeon_fence_driver_check_lockup to take exclusive_lock, >>>> and kill it during lockup recovery instead. >>> That looks like the delayed work starts running as soon as we submit a fence, and not when it's needed for waitin...

Hi all, can someone comment on the state of the hifn(4) driver? I've recently upgraded my 6.2-STABLE workstation to RELENG_7, and I'm now experiencing system lockups that seem to be caused by the hifn(4) driver. I've got a Soekris vpn1401 card to help with GELI disk en- cryption. Reading from a GELI volume is causing the system to freeze completely, which does not happen if software crypto is used (i.e. hifn.ko not loaded). I can't enter kernel de...

...ait for Intel to finish displaying), this might become a perfect example of locking inversion. >>> In the preliminary patches where I can sync radeon with other GPU's I've been very careful in all the places that call into fences, to make sure that radeon wouldn't try to handle lockups for a different (possibly also radeon) card. >> That's actually not such a good idea. >> >> In case of a lockup we need to handle the lockup cause otherwise it could happen that radeon waits for the lockup to be resolved and the lockup handling needs to wait for a fence that&...

v2: - fix compile issues if no CONFIG_SMP, Konrad Rzeszutek Wilk - move inc_irq_stat after irq_work_run These 2 patches fixed the "perf top" soft lockups under Xen reported by Steven at: https://lkml.org/lkml/2012/2/9/506 Both Steven and I tested it and "perf top" works well now. The soft lockup code path is: __irq_work_queue arch_irq_work_raise apic->send_IPI_self(IRQ_WORK_VECTOR); apic_send_IPI_self __default_s...