Red Hat Bugzilla – Bug 484316
drm: radeon: hangs installer (possible recursive locking detected)
Last modified: 2009-06-10 22:43:01 EDT
Created attachment 331070 [details] boot log from serial console Description of problem: Crash or hang with no response at first switch to graphical mode during install of Fedora 11 Alpha. Log from serial console suggests recursive locking; graphics screen is blank. Version-Release number of selected component (if applicable): 2.6.29-0.66.rc3.fc11.i586 How reproducible: always Steps to Reproduce: 1. Boot " askmethod" using netinst CD from Fedora 11 for i686, with complete i686 DVD in external drive via USB2.0 with cardbus interface and BIOS that cannot boot DVD. 2. Choose local CD/DVD. 3. Actual results: Crash or hang with no response at first switch to graphical mode. Expected results: Display graphical splash screen, then continue with install. Additional info: Will attach cpuinfo, lspci, Xorg.0.log from previously-installed Fedora 10, etc.
xorg-x11-drv-ati-6.10.0-2.fc11.i386.rpm
Created attachment 331073 [details] /proc/cpuinfo
Created attachment 331074 [details] lspci; lspci -n; lspci -v
Created attachment 331075 [details] /var/log/Xorg.0.log running previously-installed Fedora 10
text mode install (boot " askmethod text") works well beyond the text-mode "splash" screen.
Install also fails when booting with " nomodeset": same crash/hang. Install works when booting with the basic video driver (" xdriver=vesa"). Install works when booting on different hardware with a Mobility Radeon HD 3600 series chip (PCI 1002:9598) and external 1024x768 LCD panel, but the same internal CD + external DVD (but via direct USB2.0: no cardbus).
Today's crash/lockup is: [ INFO: possible recursive locking detected ] 2.6.29-0.96.rc3.git12.fc11.i586 #1 --------------------------------------------- sh/1317 is trying to acquire lock: (&bdev->bd_mutex){--..}, at: [<c04c0372>] __blkdev_put+0x23/0x10b but task is already holding lock: (&bdev->bd_mutex){--..}, at: [<c04c0372>] __blkdev_put+0x23/0x10b other info that might help us debug this: 2 locks held by sh/1317: #0: (&bdev->bd_mutex){--..}, at: [<c04c0372>] __blkdev_put+0x23/0x10b #1: (&lo->lo_ctl_mutex){--..}, at: [<c05bba9f>] lo_release+0x1a/0x55 stack backtrace: Pid: 1317, comm: sh Not tainted 2.6.29-0.96.rc3.git12.fc11.i586 #1 Call Trace: [<c06d5cb1>] ? printk+0xf/0x16 [<c044d146>] __lock_acquire+0x770/0xace [<c044d4ff>] lock_acquire+0x5b/0x81 [<c04c0372>] ? __blkdev_put+0x23/0x10b [<c06d6da7>] __mutex_lock_common+0xd8/0x333 [<c04c0372>] ? __blkdev_put+0x23/0x10b [<c06d709a>] mutex_lock_nested+0x2e/0x36 [<c04c0372>] ? __blkdev_put+0x23/0x10b [<c04c0372>] __blkdev_put+0x23/0x10b [<c04c0464>] blkdev_put+0xa/0xc [<c04c04b3>] close_bdev_exclusive+0x1b/0x1f [<c04a4258>] kill_block_super+0x2d/0x31 [<c04d1d34>] ? vfs_quota_off+0x0/0x12 [<c04a4304>] deactivate_super+0x57/0x6a [<c04b3dc4>] mntput_no_expire+0xd1/0x103 [<c06d8011>] ? _spin_unlock+0x1d/0x20 [<c04a3345>] __fput+0x156/0x15e [<c04a3362>] fput+0x15/0x17 [<c05bba5b>] loop_clr_fd+0x166/0x190 [<c05bbab9>] lo_release+0x34/0x55 [<c04c03b6>] __blkdev_put+0x67/0x10b [<c04c0464>] blkdev_put+0xa/0xc [<c04c04b3>] close_bdev_exclusive+0x1b/0x1f [<c04a4258>] kill_block_super+0x2d/0x31 [<c04d1d34>] ? vfs_quota_off+0x0/0x12 [<c04a4304>] deactivate_super+0x57/0x6a [<c04b3dc4>] mntput_no_expire+0xd1/0x103 [<c06d8011>] ? _spin_unlock+0x1d/0x20 [<c04a3345>] __fput+0x156/0x15e [<c04a3362>] fput+0x15/0x17 [<c048eda6>] remove_vma+0x3c/0x5b [<c048ee9a>] exit_mmap+0xd5/0xf0 [<c042b970>] mmput+0x3c/0x8f [<c042eef6>] exit_mm+0xdf/0xe7 [<c0430921>] do_exit+0x18b/0x74a [<c0407e2d>] ? sched_clock+0x9/0xd [<c044ad2c>] ? lock_release_holdtime+0x2b/0x123 [<c0430f3f>] do_group_exit+0x5f/0x86 [<c043938c>] get_signal_to_deliver+0x262/0x279 [<c0402d8a>] do_notify_resume+0x69/0x60b [<c044c39b>] ? trace_hardirqs_on_caller+0x121/0x145 [<c044c3ca>] ? trace_hardirqs_on+0xb/0xd [<c0590a86>] ? tty_read+0x72/0x9e [<c0594190>] ? n_tty_read+0x0/0x5b9 [<c0590a14>] ? tty_read+0x0/0x9e [<c04a2b82>] ? vfs_read+0x90/0xef [<c04a2cb2>] ? sys_read+0x66/0x75 [<c0403aa0>] work_notifysig+0x13/0x23
Attempting to install today from i386 boot.iso just hangs at the switch into graphical mode. The graphical console is blank as before, but the serial console contains no message for "possible recursive locking" and no traceback. e2f47cf788e88270a11914e2726e67cd2f02f031 boot.iso # sha1sum Presumably this uses: kernel-2.6.29-0.110.rc4.git3.fc11.i586.rpm xorg-x11-drv-ati-6.10.0-2.fc11.i386.rpm although I cannot verify because mounting of install.img failed.
Created attachment 331827 [details] text console log Today's i386 boot.iso gets an anaconda traceback, apparently before the switch to graphical mode, then the "INFO: possible recursive locking detected". Then anaconda offers a clean reboot, which has not happened before. kernel-2.6.29-0.112.rc4.git3.fc11.i586 (from text console log) anaconda-11.5.0.17
Created attachment 331941 [details] text console log In graphical mode, today's i386 boot.iso just hangs at the switch to graphical mode, with no traceback. In text mode (" text console=ttyS0,115200 constole=tty0"), I get the INFO about possible recursive logging when in Exit from the dialog "Warning: pre-release software". So the attached console log gets the warning without any [apparent] attempt to switch to graphical mode.
Created attachment 335297 [details] /tmp/X.log when installer's graphical welcome screen works Using i386 boot.iso from Sat.Mar.14.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fixed as of Fedora 11 final release: anaconda-11.5.0.59 kernel-2.6.29.4-167.fc11.i586