SCIENTIFIC-LINUX-USERS Archives

January 2012

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Bill Maidment <[log in to unmask]>
Reply To:
Bill Maidment <[log in to unmask]>
Date:
Fri, 13 Jan 2012 15:48:53 +1100
Content-Type:
text/plain
Parts/Attachments:
text/plain (80 lines)
-----Original message-----
From:	zxq9 <[log in to unmask]>
Sent:	Fri 13-01-2012 15:00
Subject:	Re: kernel panic with 2.6.32-220.2.1
To:	[log in to unmask]; 
> On 01/13/2012 08:48 AM, Bill Maidment wrote:
> > Good Morning all from Australia
> > I have a problem when upgrading to the newest 64bit kernel. After it runs for 
> a couple of minutes I get a kernel panic (see below). The previous 
> kernel-2.6.32-131.21.1 reported the nouveau scaling lines but does not kernel 
> panic.
> > Has anyone else seen anything like this? Could this indicate a hardware error?
> > Any help would be appreciated.
> >
> > Jan 13 10:20:39 charlton kernel: [drm] nouveau 0000:05:00.0: No native mode, 
> forcing panel scaling
> > Jan 13 10:20:49 charlton kernel: [drm] nouveau 0000:05:00.0: No native mode, 
> forcing panel scaling
> > Jan 13 10:20:49 charlton kernel: [drm:drm_crtc_helper_set_config] *ERROR* 
> failed to set mode on [CRTC:5]
> > Jan 13 10:20:50 charlton kernel: irq 18: nobody cared (try booting with the 
> "irqpoll" option)
> > Jan 13 10:20:50 charlton kernel: Pid: 0, comm: swapper Tainted: G        W  
> ----------------   2.6.32-220.2.1.el6.x86_64 #1
> > Jan 13 10:20:50 charlton kernel: Call Trace:
> > Jan 13 10:20:50 charlton kernel:<IRQ>   [<ffffffff810db29b>] ? 
> __report_bad_irq+0x2b/0xa0
> > Jan 13 10:20:50 charlton kernel: [<ffffffff810db49c>] ? 
> note_interrupt+0x18c/0x1d0
> > Jan 13 10:20:50 charlton kernel: [<ffffffff810dbbbd>] ? 
> handle_fasteoi_irq+0xcd/0xf0
> > Jan 13 10:20:50 charlton kernel: [<ffffffff8100df09>] ? handle_irq+0x49/0xa0
> > Jan 13 10:20:50 charlton kernel: [<ffffffff814f4dcc>] ? do_IRQ+0x6c/0xf0
> > Jan 13 10:20:50 charlton kernel: [<ffffffff8100ba53>] ? ret_from_intr+0x0/0x11
> > Jan 13 10:20:50 charlton kernel:<EOI>   [<ffffffff8103756b>] ? 
> native_safe_halt+0xb/0x10
> > Jan 13 10:20:50 charlton kernel: [<ffffffff810145dd>] ? default_idle+0x4d/0xb0
> > Jan 13 10:20:50 charlton kernel: [<ffffffff810146dd>] ? c1e_idle+0x9d/0x120
> > Jan 13 10:20:50 charlton kernel: [<ffffffff81009e06>] ? cpu_idle+0xb6/0x110
> > Jan 13 10:20:50 charlton kernel: [<ffffffff814e5fbb>] ? 
> start_secondary+0x202/0x245
> > Jan 13 10:20:50 charlton kernel: handlers:
> > Jan 13 10:20:50 charlton kernel: [<ffffffff8139b590>] (usb_hcd_irq+0x0/0x90)
> > Jan 13 10:20:50 charlton kernel: [<ffffffff8139b590>] (usb_hcd_irq+0x0/0x90)
> > Jan 13 10:20:50 charlton kernel: [<ffffffff8139b590>] (usb_hcd_irq+0x0/0x90)
> > Jan 13 10:20:50 charlton kernel: [<ffffffff8139b590>] (usb_hcd_irq+0x0/0x90)
> > Jan 13 10:20:50 charlton kernel: [<ffffffffa00de140>] 
> (nouveau_irq_handler+0x0/0x140 [nouveau])
> > Jan 13 10:20:50 charlton kernel: Disabling IRQ #18
> 
> It looks like nouveau is on fire.
> 
> Assuming you in fact have an nVidia chipset...
> 
> Can you boot to runlevel 3?
> 
> If so you've got two primary routes: Learning about the display option 
> details and try passing some boot parameter magic to nouveau -- these 
> days there is no xorg.conf file by default, and everything is 
> autodetected each boot, so you can get specific in boot options or by 
> writing an xorg.conf of your own (but this has become a deep body of 
> knowledge recently, so that can suck if you're new to it)
> 
> ...or...
> 
> You can run off and get the nVidia proprietary driver pack and compile 
> it. If you have already done this, then nouveau needs to be explicitely 
> blacklisted to prevent these sort of hairballs making your kernel cough.
> 
> 

I am already running in runlevel 3 with a NV50 type nVidia card and no proprietary driver.
I think the boot parameter magic drm_kms_helper.poll=0 has at least stopped the kernel panic, so I'll investigate that further.
Thanks for the info.

Cheers
Bill Maidment
IT Consultant to Elgas Ltd
Phone: 02 4294 3649

ATOM RSS1 RSS2