similar to: Status of sky2 NIC lockup bug

i''m running Xen Host & Guest, both version xen-4.1.2/64-bit. i pass through an ethernet NIC from host to guest. it uses the standard Marvell ''sky2'' kernel module. when i start the guest, usually -- but not always -- the NIC gets properly passed through and setup, and is completely usable. if i shutdown & restart the Guest, sometimes -- maybe 20% of the time?

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

So I have one of these, that I bought cheap on eBay. It was working just fine on my main -STABLE workstation (Abit KG7 motherboard), up until last Friday when I moved it onto the VIA EPIA-M machine I'm building. The NIC was detected OK as aue0, then the machine locked up running dhclient. It turns out that it wasn't really hung, but apparently spinning in the kernel on behalf of

Hey, op 04-08-14 13:57, Christian K?nig schreef: > Am 04.08.2014 um 10:55 schrieb Maarten Lankhorst: >> op 04-08-14 10:36, Christian K?nig schreef: >>> Hi Maarten, >>> >>> Sorry for the delay. I've got way to much todo recently. >>> >>> Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst: >>>> On 01-08-14 18:35, Christian K?nig

> 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

op 04-08-14 10:36, Christian K?nig schreef: > Hi Maarten, > > Sorry for the delay. I've got way to much todo recently. > > Am 01.08.2014 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

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. --- drivers/gpu/drm/radeon/radeon.h | 3 + drivers/gpu/drm/radeon/radeon_device.c | 5 + drivers/gpu/drm/radeon/radeon_fence.c |

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

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

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 but that would mean reverting to the old style during gpu lockup recovery, and

op 04-08-14 17:04, Christian K?nig schreef: > 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.

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

Hi Maarten, Sorry for the delay. I've got way to much todo recently. Am 01.08.2014 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

I just yum-installed the 2.6.9-34 kernel RPMs and rebooted, and lo and behold, my other onboard NIC is now detected, after a fashion. /etc/sysconfig/hwconf now has entries for: device: eth0 driver: forcedeth desc: "nVidia Corporation CK804 Ethernet Controller" device: eth2 driver: sky2 desc: "Marvell Technology Group Ltd. 88E8053 Gigabit Ethernet Controller" The device/desc

Am 04.08.2014 um 10:55 schrieb Maarten Lankhorst: > op 04-08-14 10:36, Christian K?nig schreef: >> Hi Maarten, >> >> Sorry for the delay. I've got way to much todo recently. >> >> Am 01.08.2014 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:

Hi, I have been trying to figure out why my Supermicro X7DWA-N with dual Xeon E5420''s locks up occasionally when running Xen, I''ve tried 3.2.1 and 3.3 with the Xensource 2.6.18 kernel, with gentoo 2.6.21, and 2.6.25 and 2.6.27 kernels patched with suse xen patches, every single combination suffers from occasional lockups :(, I am reasonably confident that the hardware is ok

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

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

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:

Hi Folks, anyone out there successful in using the new xorg "intel" driver module on a 965Q-based motherboard with CentOS 5.2? The old "i810" and "vesa" work fine, I am looking for anyone else with experience with the new "intel" video driver in 5.2. The long of it: I have a customer's Dell Optiplex 745 (Core2 Duo 6300, 965Q chipset with integrated