search for: lockups

...or waiting. >>>> >>>> Since it's a backup for failing IRQs I would rather put it into radeon_irq_kms.c and start/stop it when the IRQs are started/stoped. >>> The delayed work is not just for failing irq's, it's also the handler that's used to detect lockups, which is why I trigger after processing fences, and reset the timer after processing. >> The idea was turning the delayed work on and off when we turn the irq on and off as well, processing of the delayed work handler can still happen in radeon_fence.c >> >>> Specifically what...

...>>> >>>>>> Since it's a backup for failing IRQs I would rather put it into radeon_irq_kms.c and start/stop it when the IRQs are started/stoped. >>>>> The delayed work is not just for failing irq's, it's also the handler that's used to detect lockups, which is why I trigger after processing fences, and reset the timer after processing. >>>> The idea was turning the delayed work on and off when we turn the irq on and off as well, processing of the delayed work handler can still happen in radeon_fence.c >>>> >>>&g...

...t when it's needed for waiting. >> >> Since it's a backup for failing IRQs I would rather put it into radeon_irq_kms.c and start/stop it when the IRQs are started/stoped. > The delayed work is not just for failing irq's, it's also the handler that's used to detect lockups, which is why I trigger after processing fences, and reset the timer after processing. The idea was turning the delayed work on and off when we turn the irq on and off as well, processing of the delayed work handler can still happen in radeon_fence.c > > Specifically what happened was thi...

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 +++++----------

...>>>>> >>>>> Since it's a backup for failing IRQs I would rather put it into radeon_irq_kms.c and start/stop it when the IRQs are started/stoped. >>>> The delayed work is not just for failing irq's, it's also the handler that's used to detect lockups, which is why I trigger after processing fences, and reset the timer after processing. >>> The idea was turning the delayed work on and off when we turn the irq on and off as well, processing of the delayed work handler can still happen in radeon_fence.c >>> >>>> Speci...

Hello, Similar to others I have freezeups on the system, it is consistent with high IO load. If the system runs (even with multiple) XenU it does not happen. But I can consistently force the situation to occur. Running 4 dd processes dumping 20GB each on a LVM/mdadm soft RAID5 volume it consistenly crashes in a DomU. Running without XEN I do not see the problem at all - (e.g. after about 3TB of

Am 04.08.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

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:

...vice *rdev, u64 *target_seq, > { > uint64_t last_seq[RADEON_NUM_RINGS]; > bool signaled; > - int i, r; > + int i; > > while (!radeon_fence_any_seq_signaled(rdev, target_seq)) { > + long r; > > /* Save current sequence values, used to check for GPU lockups */ > for (i = 0; i < RADEON_NUM_RINGS; ++i) { > @@ -319,11 +355,11 @@ static int radeon_fence_wait_seq(struct radeon_device *rdev, u64 *target_seq, > if (intr) { > r = wait_event_interruptible_timeout(rdev->fence_queue, ( > (signaled = radeon_fence_any_seq_si...

Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst: > op 04-08-14 16:45, Christian K?nig schreef: >> Am 04.08.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

...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 bec...

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/nouv...

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

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 an...

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 mem...

...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 resolved. > So you don't have a timer in radeon that periodically checks whether > progress is still being made? That's the approach we're using in i915, > together with some tri...

...9;s needed for waiting. >>> >>> Since it's a backup for failing IRQs I would rather put it into radeon_irq_kms.c and start/stop it when the IRQs are started/stoped. >> The delayed work is not just for failing irq's, it's also the handler that's used to detect lockups, which is why I trigger after processing fences, and reset the timer after processing. > > The idea was turning the delayed work on and off when we turn the irq on and off as well, processing of the delayed work handler can still happen in radeon_fence.c > >> >> Specifically wh...

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 deb...

...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_se...