|Summary:||kernel panic with asus m3a-h/hdmi and amd hybrid crossfire turned on|
|Product:||Platform Specific/Hardware||Reporter:||Balázs Hámorszky (balihb)|
log (without quiet)
log (with quiet)
my current dmesg
Description Balázs Hámorszky 2009-01-03 14:19:57 UTC
Latest working kernel version: n/a Earliest failing kernel version: any I've seen Distribution: Debian/sid Hardware Environment:AMD Athlon X2 6000+ @ ASUS M3A-H/HDMI Software Environment: Problem Description: I have a board and a video card that support hybrid crossfire. If I turn on the onboard graphic feature the init dies with kernel panic. The problem was also reported on other places on the Internet. http://forums.debian.net/viewtopic.php?t=27129&sid=4cd6544dc7cf6064b0211370fa7698ec https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/305165 http://ubuntuforums.org/showthread.php?p=6403688 The interesting thing is that AMD's current closed source (linux) graphic driver support hybrid crossfire. Steps to reproduce: Turn on the Surround View feature in the bios (turning on the onboard graphic). Boot a kernel (I've tried i386 and amd64) The init dies with kernel panic. (windows works fine)
Comment 1 Andrew Morton 2009-01-05 15:43:20 UTC
geeze, there isn't much to go on here. I can't find a complete trace of the kernel crash anywhere.
Comment 2 Balázs Hámorszky 2009-01-07 03:51:47 UTC
I've made few picture. http://profile.imageshack.us/user/balihb/images the first two made with quiet boot parameter, and the last two made without it.
Comment 3 Thomas Gleixner 2009-01-14 02:16:23 UTC
That does not help much. Is there a chance that you can log the boot messages including the panic with a serial console ? Add "console=ttyS0,115200" to the kernel command line and connect the serial port to another PCs serial port. On that PC run a terminal program (e.g. minicom) and capture the messages which come along. Thanks, tglx
Comment 4 Balázs Hámorszky 2009-01-14 14:18:33 UTC
Created attachment 19803 [details] log (without quiet) I've finaly managed to make the null modem cable work. This log made without quiet.
Comment 5 Balázs Hámorszky 2009-01-14 14:19:22 UTC
Created attachment 19804 [details] log (with quiet) and with quiet
Comment 6 Thomas Gleixner 2009-01-14 15:18:27 UTC
> I've finaly managed to make the null modem cable work. This log made without > quiet. Can you please provide one with the crossfire thingy disabled for reference ? Thanks, tglx
Comment 7 Balázs Hámorszky 2009-01-14 15:22:06 UTC
Created attachment 19806 [details] my current dmesg this is from /var/log/dmesg. I hope it'll be enough. Is there any kernel (debug) option I can recompile my kernel with to help debugging the problem?
Comment 8 Thomas Gleixner 2009-01-14 15:43:57 UTC
> this is from /var/log/dmesg. I hope it'll be enough. > Is there any kernel (debug) option I can recompile my kernel with to help > debugging the problem? Can you please redo the capture of the crossfire enabled boot (w/o quiet) and add "ignore_loglevel" to the kernel command line ? Thanks, tglx
Comment 9 Balázs Hámorszky 2009-01-14 16:25:19 UTC
Created attachment 19807 [details] ignore_loglevel I hope it'll help
Comment 10 Thomas Gleixner 2009-01-14 16:34:57 UTC
Please add "initcall_debug" to the crossfire enabled boot as well. Thanks, tglx
Comment 11 Balázs Hámorszky 2009-01-14 16:57:22 UTC
Created attachment 19810 [details] initcall_debug I've found a kernel that works with onboard video enabled. My motherboad has an embedded linux (ExpressGate 126.96.36.199 (SplashTop)) and it boots up flawlessly with the onboard graphics enabled. I don't know what kernel it use, but it's source (config) should be available somewhere.
Comment 12 Balázs Hámorszky 2009-01-14 18:58:46 UTC
according to http://www.splashtop.com/open_source.php the kernel express gate use is 2.6.20
Comment 14 Balázs Hámorszky 2009-01-19 01:31:08 UTC
(In reply to comment #13) > Duplicate of bug #11714? > yes
Comment 15 herrmann.der.user 2009-03-13 04:19:19 UTC
This bug should be closed (marked as duplicate). FYI, bug #11714 was marked duplicate of bug #11541 which in turn is solved with a patch that is on it's way to mainline kernel. (see http://marc.info/?l=linux-kernel&m=123693623703978)