[X700] KMS, amd64: Kernel panic while trying to launch system > preferences > appearance

Thanks for your report. Can you please run "apport-collect 544741" to attach more information.

Mobility X700 works fine with KMS here (on i386).

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

aport-collect was launced with kms disabled (radeon.modeset=0)

its not only "appearance" relaited, anny window poping out trigers it (under kms)

later, I will try 386

Thanks, it would be great if you can test with i386. Can you please also attach an Xorg.0.log with KMS enabled?

And also dmesg output, as far as you can get before it hangs.

just tested i386. this problem is amd64 specific.

Tormod Volden, is yours system amd64 capable? if so, could you test amd64 arch on yours x700 mobility powered one...

On 2010.03.23 18:54, Arturas K wrote:
> just tested i386. this problem is amd64 specific.

it appears my preview statement is false - the problem is reproducible
on i386 too...

ps some times kernel oopses on boot (drm/radeon/modeset related dump)...

I upgraded xserver-xorg-video-ati to 1:6.12.192-2 (from debian, build from src on ubuntu) - problem persisted..

when I upgraded kernel to 2.6.33.1 (config from 2.6.32-17.26 generic flavor) - it seems, no more crashing or freezing...

I will try testing more extensively later, to make sure 2.6.33.1 solves the problem...

p.s. I guess it is the time to notify kernel teem

... all this was performed on amd64 arch

Thanks for testing out the kernels. As you might know, the drm code in the 2.6.32-17.26 kernel is taken from 2.6.33.1, so this is interesting results. Can you attach the logs I asked for, please?

On 2010.03.24 18:06, Tormod Volden wrote:
> Thanks for testing out the kernels. As you might know, the drm code in
> the 2.6.32-17.26 kernel is taken from 2.6.33.1, so this is interesting
> results. Can you attach the logs I asked for, please?

yes, I know drm code is backported from 2.6.33.* - I just tested
2.6.33.1 to verify the guys done the job forgot nothing :D

unfortunately the joy 2.6.33.1 brought to me is false (crashes too)

* nearly 100% crash / freeze success than "visual effects: none" (set in
no-kms mode, crash in kms)

* than "visual effects: normal" - crashes are less frequent. upon few
successful "appearance" launches, I change to "visual effects: none",
try "appearance" once more and 100% crash expectancy...

* "appearance" is the easiest way to triger crash, but other app
launches also from time to time triger it too

* never crashed in gdm, or switching to vty/back. only than logged in
and launching some app

* I found only these of interest in dmesg (they repeat in all kms boots):

** registered panic notifier

** plymouthd[298]: segfault at 0 ip 00007f6736f85d8b sp 00007fff919086e8
error 6 in libc-2.11.1.so[7f6736eff000+178000]

* xorg log shows nothing suspicious to me

* the crash leave no trace in logs

* some boots result in kernel panic (see panic.gif), upon trying to
initialize drm (or at least looks to me so)...

* usually I boot with out "splash" and "quiet", but leaving them on -
changes nothing

* usually the first two boot messages are about somethig like "address
space collision". pci address is referring to something "...00:03.0" -
it seems chipset related. never found anything related in logs

this is as informative as I can get. I hope all these crashes left no
permanent damage on my hard disk drive :D

Okay the panic message shows this is a fault in the kernel drm code, so I'll forward this to the kernel team. From your backtrace (thanks for including a screen capture!) it seems to have to do with the drm's edid code. EDID is data from your laptop monitor which communicates its resolution and refresh rate capabilities, so perhaps something in how your laptop monitor's EDID is structured is causing the kernel some confusion.

On 2010.03.26 07:15, Bryce Harrington wrote:
> Okay the panic message shows this is a fault in the kernel drm code, so
> I'll forward this to the kernel team. From your backtrace (thanks for
> including a screen capture!) it seems to have to do with the drm's edid
> code. EDID is data from your laptop monitor which communicates its
> resolution and refresh rate capabilities, so perhaps something in how
> your laptop monitor's EDID is structured is causing the kernel some
> confusion.

crash while booting as you said might be related to EDID. this is most
likely one more bug - because I see no relation to crashing while
launching some app to that...

@Arturas K:

Unfortunately, the oops message in your picture was cut off. Is the full oops message in /var/log/messages? If so, can you attach it as well?

Thanks

On 2010.04.02 18:41, Chase Douglas wrote:
> Unfortunately, the oops message in your picture was cut off. Is the full
> oops message in /var/log/messages? If so, can you attach it as well?

sorry, as I said the crash leaves no trace in logs...

@Arturas K:

Can you try booting with the cmdline option pci=nomsi? There are reports that this can solve instability in certain motherboards.

Thanks

I had the same problem here, on a computer similar (identical?) to original poster's; Amilo A3667G with Turion 64 and Radeon X700, though running a x86 kernel (yes). It was solved with kernel nomodeset and radeon.modeset=0.

Any link to this issue upstreams?

@Daniel:

Can you try the pci=nomsi option as well?

Thanks

On 2010.04.07 19:10, Daniel Lublin wrote:
> I had the same problem here, on a computer similar (identical?) to
> original poster's; Amilo A3667G with Turion 64 and Radeon X700, though
> running a x86 kernel (yes). It was solved with kernel nomodeset and
> radeon.modeset=0.

A3667G and A1667G is the same, but the screen size (yours is bigger).

At the same, I am glad you could reproduce the problem too - I was
fearing my laptop started to show its age...

On 2010.04.03 17:00, Chase Douglas wrote:
> Can you try booting with the cmdline option pci=nomsi? There are reports
> that this can solve instability in certain motherboards.

pci=nomsi radeon.modeset=1 from my preliminary testing is promising.
will tell more, after more testing...

The crashes earlier on were hard and slightly traumatizing, but I have to say that with pci=nomsi, KMS seems to work on this hardware. Smooth glitch-less switching between vt/gdm/X for a whole day, no (instant) crashes like before. (That's still x86 on Turion64/RadeonX700)

@Daniel:

Please attach the output of lspci so I can confirm that a quirk to disable pci msi interrupts will be in the next Lucid kernel.

Thanks

@Chase:

lspci -v coming up. Btw, what do you look for in that output? Also, on a running system, is there a file in /proc where I can see which flags, like pci=nomsi, that are in effect? (or, nomsi specifically).

@Daniel:

I'm sorry, I forgot that lspci -v doesn't give the information we need. Can you post the output of 'lspci -n instead?

What I'm looking for is specific vendor and model pci ids. We have a quirk for specific motherboards to disable pci msi interrupts, but there are more upstream. If you have a motherboard with a pci id that matches upstream but not what we have in Lucid yet, then we can look at pulling the change.

There's probably a way to detect whether pci msi interrupts are disabled, but I don't know how.

Ok, the patch to disable pci msi interrupts for this motherboard chipset (Both Daniel and Arturas K have the same pci ids) can be found here:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=134b345081534235dbf228b1005c14590e0570ba

Since Daniel has confirmed this to fix his issues, I'll be sending the patch to the kernel-team mailing list for inclusion into Lucid.

On 2010.04.09 18:16, Chase Douglas wrote:

> Since Daniel has confirmed this to fix his issues, I'll be sending the
> patch to the kernel-team mailing list for inclusion into Lucid.

it seems pci=nomsi fixed the problem for me too.

Daniel's 3667G and my 1667G has identical motherboards (at least uses
same bios binaries)...

This bug was fixed in the package linux - 2.6.32-20.29

---------------
linux (2.6.32-20.29) lucid; urgency=low

  [ Andy Whitcroft ]

  * Revert "SAUCE: Use MODULE_IMPORT macro to tie intel_agp to i915"
    - LP: #542251
  * add Breaks: against hardy lvm2
    - LP: #528155

  [ Colin Watson ]

  * d-i -- enable udebs for generic-pae
    - LP: #160366

  [ Stefan Bader ]

  * [Config] Add xen netboot support
    - LP: #160366

  [ Takashi Iwai ]

  * (pre-stable): input: Support Clickpad devices in ClickZone mode
    - LP: #516329

  [ Upstream Kernel Changes ]

  * Revert "(pre-stable) Bluetooth: Fix sleeping function in RFCOMM within
    invalid context"
    - LP: #553837
  * Revert "(pre-stable) USB: fix usbfs regression"
    - LP: #553837
  * Revert "(pre-stable) softlockup: Stop spurious softlockup messages due
    to overflow"
    - LP: #553837
  * Revert "(pre-stable) drm/nouveau: report unknown connector state if lid
    closed"
    - LP: #553837
  * drivers/scsi/ses.c: eliminate double free
    - LP: #553837
  * decompress: fix new decompressor for PIC
    - LP: #553837
  * ARM: Fix decompressor's kernel size estimation for ROM=y
    - LP: #553837
  * MIPS: Cleanup forgotten label_module_alloc in tlbex.c
    - LP: #553837
  * tg3: Fix tg3_poll_controller() passing wrong pointer to tg3_interrupt()
    - LP: #553837
  * tg3: Fix 5906 transmit hangs
    - LP: #553837
  * ALSA: hda - Fix input source elements of secondary ADCs on Realtek
    - LP: #553837
  * ALSA: hda: enable MSI for Gateway M-6866
    - LP: #538918, #553837
  * timekeeping: Prevent oops when GENERIC_TIME=n
    - LP: #553837
  * Input: alps - add support for the touchpad on Toshiba Tecra A11-11L
    - LP: #553837
  * Input: i8042 - add ALDI/MEDION netbook E1222 to qurik reset table
    - LP: #553837
  * i2c-i801: Don't use the block buffer for I2C block writes
    - LP: #553837
  * ath5k: dont use external sleep clock in AP mode
    - LP: #553837
  * ath5k: fix setup for CAB queue
    - LP: #553837
  * ring-buffer: Move disabled check into preempt disable section
    - LP: #553837
  * function-graph: Init curr_ret_stack with ret_stack
    - LP: #553837
  * Bluetooth: Fix sleeping function in RFCOMM within invalid context
    - LP: #553837
  * tracing: Use same local variable when resetting the ring buffer
    - LP: #553837
  * tracing: Disable buffer switching when starting or stopping trace
    - LP: #553837
  * tracing: Do not record user stack trace from NMI context
    - LP: #553837
  * PCI: unconditionally clear AER uncorr status register during cleanup
    - LP: #553837
  * efifb: fix framebuffer handoff
    - LP: #553837
  * coredump: suppress uid comparison test if core output files are pipes
    - LP: #553837
  * V4L/DVB (13961): em28xx-dvb: fix memleak in dvb_fini()
    - LP: #553837
  * hrtimer: Tune hrtimer_interrupt hang logic
    - LP: #553837
  * x86, apic: Don't use logical-flat mode when CPU hotplug may exceed 8
    CPUs
    - LP: #553837
  * mvsas: add support for Adaptec ASC-1045/1405 SAS/SATA HBA
    - LP: #553837
  * pci: add support for 82576NS serdes to existing SR-IOV quirk
    - LP: #553837
  * sched: Mark boot-cpu active before smp_init()
    -...

After upgrading to Ubuntu 10.04 i386 my system freezes when changing users. Had no problems with 9.10. Have applied all system updates.

System: Acer Travelmate 3222, 2GB, external display HP L1720 @1280x1024. Video ATI Radeon Mobility X700.
Symptoms:
- 1. Sluggish display (could it be the change from nv to nouveau display driver?)
- 2. Consistently upon "Change user" the display goes blank except for cursor and sometimes noise in lower part. Possible to switch to login terminal and back (ctrl-alt-f1/f7), but only once, when repeated system freezes.
Solution:
Reboot.

I will provide more information on request, but I am not a Linux expert.

Thought I would try radeon.modeset=0 as suggested earlier, but found that menu.lst has disappeared with grub2. The documentation for grub2 is poor to say the least. So I gave up, went back to 9.10, which worked fine.