BUG: soft lockup - CPU#0 stuck for 23s! [Xorg:1295]

[RichardNeill]

I've just installed Utopic, and my machine is really slow to boot.

WORKAROUND: Use Radeon driver.

ProblemType: KernelOops
DistroRelease: Ubuntu 14.10
Package: linux-image-3.15.0-6-generic 3.15.0-6.11 [modified: boot/vmlinuz-3.15.0-6-generic]
ProcVersionSignature: Ubuntu 3.15.0-6.11-generic 3.15.0
Uname: Linux 3.15.0-6-generic x86_64
Annotation: Your system might become unstable now and might need to be restarted.
ApportVersion: 2.14.4-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC3: rjn 2642 F.... pulseaudio
 /dev/snd/controlC2: rjn 2642 F.... pulseaudio
 /dev/snd/controlC0: rjn 2642 F.... pulseaudio
 /dev/snd/controlC1: rjn 2642 F.... pulseaudio
Date: Sun Jul 6 00:58:31 2014
DuplicateSignature: BUG: soft lockup - CPU#0 stuck for 23s! [Xorg:1295] RIP: 0010:location location ulReadMmRegisterUlongViaAddr+0xc/0x10 [fglrx]
Failure: oops
HibernationDevice: RESUME=UUID=dd46a6f0-bcb8-4e75-b77d-6158117027ac
InstallationDate: Installed on 2014-07-05 (0 days ago)
InstallationMedia: Kubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140703)
IwConfig:
 eth0 no wireless extensions.

 eth1 no wireless extensions.

 lo no wireless extensions.
MachineType: System manufacturer System Product Name
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.15.0-6-generic root=UUID=41c3bf4e-49c3-4546-aea6-30a91309679d ro
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions: kerneloops-daemon 0.12+git20090217-3ubuntu8
RfKill:

SourcePackage: linux
Title: BUG: soft lockup - CPU#0 stuck for 23s! [Xorg:1295]
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/21/2011
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0703
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: P8Z68-V LX
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0703:bd10/21/2011:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnP8Z68-VLX:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

[Brad Figg (brad-figg)]

This change was made by a bot.

[RichardNeill (ubuntu-richardneill)]

Dear Christopher,

Thanks for your suggestion. I've done a few more experiments before and after updating the BIOS (to the latest version (4105 07/01/2013). Here are the results.

1. Old Bios. Mageia 3 + Fglrx driver
=> Worked fine

2. Old Bios, Kubuntu Trusty (installed yesterday, fully updated), Open-source (Radeon) driver.
=> No CPU hang.
However, I did have a problem with video-modelines being auto-detected wrongly, (resulting in the monitors showing out-of range. I've since fixed that manually with xrandr --addmode and will shortly file a bug on it, but this is what set me off on the path of trying the binary drivers).

3. Old Bios, Trusty, and the fglrx driver
(both fglrx and fglrx-update, as per https://help.ubuntu.com/community/BinaryDriverHowto/AMD )
=> CPIU hang.

4. Old Bios, Utopic alpha, and open-source driver
=> No cpu hang (but the modeline problem still present)

5. New Bios, Utopic, open-source driver
=> No cpu hang (but the modeline problem still present)

6. New Bios, Utopic, fglrx
CPU hang again (see dmesg attached)

Best wishes

Richard

[penalvch (penalvch)]

RichardNeill, could you please comment to the source (Ubuntu repository or upstream) and which version of fglrx specifically you tested?

[RichardNeill (ubuntu-richardneill)]

Hello. I tried using both of the Ubuntu packages of the driver, from the utopic repositories, namely: fglrx and fglrx-updates.
I also observed the same problem with the fglrx packages under Trusty.

The versions were: fglrx_13.350.1-0ubuntu3_amd64.deb fglrx-amdcccle_13.350.1-0ubuntu3_amd64.deb

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[js1 (sujiannming)]

Just ran into this same problem on 14.04 with kernel 3.16.0-46-generic. Attaching relevant dmesg output.

[penalvch (penalvch)]

js1, it will help immensely if you filed a new report via a terminal:
ubuntu-bug xorg

Please ensure you have xdiagnose installed, and that you click the Yes button for attaching additional debugging information.

Also, please do not compress attachments here on Launchpad.

[penalvch (penalvch)]

RichardNeill, Utopic reached EOL on July 23, 2015.
See this document for currently supported Ubuntu releases: https://wiki.ubuntu.com/Releases

Is this reproducible for you in a supported release?

[RichardNeill (ubuntu-richardneill)]

Hello.

I'm currently running Wily on the same machine, under kernel:
4.1.0-3-generic #3-Ubuntu SMP Tue Jul 28 12:25:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

I'm using the Radeon driver from Xorg (Fglrx isn't even installed), and while the machine is perfectly usable, I still get these
errors - the message below is from my dmesg:

[81963.477554] compiz[16940]: segfault at 7f2012f642f0 ip 00007f20104a61cb sp 00007ffcd833e1f0 error 4 in libc-2.21.so[7f2010427000+1c0000]
[81974.077423] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for more than 5secs aborting
[81974.077448] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing C7E8 (len 62, WS 0, PS 0) @ 0xC804
[81979.088109] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for more than 5secs aborting
[81979.088119] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing C7E8 (len 62, WS 0, PS 0) @ 0xC804
[81979.088126] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing BE9C (len 1126, WS 0, PS 0) @ 0xBF2E
[81984.114825] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for more than 5secs aborting
[81984.114835] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing C7E8 (len 62, WS 0, PS 0) @ 0xC804
[81989.125508] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for more than 5secs aborting
[81989.125526] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing C7E8 (len 62, WS 0, PS 0) @ 0xC804
[81989.125533] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing BE9C (len 1126, WS 0, PS 0) @ 0xBF2E

If you need anything more, let me know.

[penalvch (penalvch)]

RichardNeill, given this report is scoped to when you have fglrx installed, if you are having a usability issue with the radeon drivers, please file a new report via a terminal:
ubuntu-bug xorg

Please ensure you have xdiagnose installed, and that you click the Yes button for attaching additional debugging information.

[RichardNeill (ubuntu-richardneill)]

Hi Christopher,

Is there actually any point doing this? I've had so many experiences where I track down a bug in some detail, file it on Launchpad,, and then it takes a year or more (as in this case) before any developer might actually pay attention to the report - by which time the whole thing is obsolete, either fixed elsewhere, or still present but in newer releases. I often get the feeling that I am simply wasting my time filing bug reports, because, however helpful and detailed they are or try to be, they very rarely get attention beyond:
        "confirmed/new".... "affects multiple users"... [time passes without a fix].... "release unsupported".... [still present]
So it seems more useful to report issues directly upstream.

Of course, I realise that developer time is valuable, which is why I'm happy to invest 5+ hours into bug reporting and further diagnosis. But it is just too unrewarding to keep investing time to no effect. Is it unreasonable to expect that if a bug is reported, it should either be closed/invalid, or fixed/deployed within a couple of months, ideally less?

Richard

[Launchpad Janitor (janitor)]

[Expired for fglrx-installer (Ubuntu) because there has been no activity for 60 days.]