Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262461AbVAUSug (ORCPT ); Fri, 21 Jan 2005 13:50:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262463AbVAUSug (ORCPT ); Fri, 21 Jan 2005 13:50:36 -0500 Received: from static-162-83-93-166.fred.east.verizon.net ([162.83.93.166]:12234 "EHLO ccs.covici.com") by vger.kernel.org with ESMTP id S262461AbVAUSuK (ORCPT ); Fri, 21 Jan 2005 13:50:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16881.20182.831343.763236@ccs.covici.com> Date: Fri, 21 Jan 2005 13:49:58 -0500 From: John covici To: Helge Hafting Cc: Dave Airlie , Jon Smirl , covici@ccs.covici.com, Kernel Mailing List Subject: Re: 2.6.10 dies when X uses PCI radeon 9200 SE, binary search result In-Reply-To: <20050121182656.GA24167@hh.idb.hist.no> References: <41E64DAB.1010808@hist.no> <16870.21720.866418.326325@ccs.covici.com> <21d7e997050113130659da39c9@mail.gmail.com> <20050115185712.GA17372@hh.idb.hist.no> <21d7e997050116020859687c4a@mail.gmail.com> <20050116105011.GA5882@hh.idb.hist.no> <9e4733910501160304642f7882@mail.gmail.com> <21d7e99705011603072d26727a@mail.gmail.com> <9e473391050116033435e5db9c@mail.gmail.com> <21d7e99705011603415d6a6bdf@mail.gmail.com> <20050121182656.GA24167@hh.idb.hist.no> X-Mailer: VM 7.17 under Emacs 21.3.50.2 Reply-To: covici@ccs.covici.com Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5829 Lines: 123 Makes sense to me -- I went from 6.8 to 6.9rc2 and that is I think when my X died. Now mine is an APG not PCI, but it may be related. on Friday 01/21/2005 Helge Hafting(helgehaf@aitel.hist.no) wrote > On Sun, Jan 16, 2005 at 10:41:23PM +1100, Dave Airlie wrote: > > > > > > I'm fine with adding this code, but we still don't know if this is the > > > cause of his problem. The debug output can determine if this really is > > > the source of the problem or if it is somewhere else. > > > > > > > I actually doubt it is this stuff.. my guess is that it is something > > nasty like ACPI breaking int10 for X or something like that... it > > seems a lot more subtle than the usually things that break when we > > mess with the DRM :-) > > > The search was a short one. > 2.6.9-rc1 works fine, just like 2.6.8.1 > 2.6.9-rc2 crashes. I didn't find any kernel revisions between those two. > > It is interesting to note that the 2.6.9 crash was a bit different. > X got a bit further according to the log. > During the test, everything stopped, but the machine wasn't completely > dead like it usually is. Numlock actually toggled the LED, but the screen was > black and I could not break out of X with ctrl+alt+backspace. So I tried to > switch consoles, and the kernel died a bit more. No more numlock LED > toggling, but sysrq+S+U+B actually worked. The discs synced and > the thing booted. Hm, perhaps X always got a bit further, but > now the disc sync preserved more of the log? > > Here is how it ended (I have all of it if necessary): > > (==) RADEON(0): Write-combining range (0xe0000000,0x8000000) > (II) RADEON(0): Wrote: rd=12, fd=120, pd=1 > drmOpenDevice: minor is 0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is -1, (Unknown error 999) > drmOpenDevice: open result is -1, (Unknown error 999) > drmOpenDevice: Open failed > drmOpenDevice: minor is 0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is -1, (Unknown error 999) > drmOpenDevice: open result is -1, (Unknown error 999) > drmOpenDevice: Open failed > drmOpenDevice: minor is 0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 6, (OK) > drmGetBusid returned '' > (II) RADEON(0): [drm] loaded kernel module for "radeon" driver > (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:0:8:0" > (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0920000 > (II) RADEON(0): [drm] mapped SAREA 0xe0920000 to 0xafd8c000 > (II) RADEON(0): [drm] framebuffer handle = 0xe0000000 > (II) RADEON(0): [drm] added 1 reserved context for kernel > (II) RADEON(0): [pci] 8192 kB allocated with handle 0xe097d000 > (II) RADEON(0): [pci] ring handle = 0xe097d000 > (II) RADEON(0): [pci] Ring mapped at 0xafc8b000 > (II) RADEON(0): [pci] Ring contents 0x00000000 > (II) RADEON(0): [pci] ring read ptr handle = 0xe0a7e000 > (II) RADEON(0): [pci] Ring read ptr mapped at 0xafc8a000 > (II) RADEON(0): [pci] Ring read ptr contents 0x00000000 > (II) RADEON(0): [pci] vertex/indirect buffers handle = 0xe0a7f000 > (II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0xafa8a000 > (II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000 > (II) RADEON(0): [pci] GART texture map handle = 0xe0c7f000 > (II) RADEON(0): [pci] GART Texture map mapped at 0xaf5aa000 > (II) RADEON(0): [drm] register handle = 0xf6000000 > (II) RADEON(0): [dri] Visual configs initialized > (II) RADEON(0): CP in BM mode > (II) RADEON(0): Using 8 MB GART aperture > (II) RADEON(0): Using 1 MB for the ring buffer > (II) RADEON(0): Using 2 MB for vertex/indirect buffers > (II) RADEON(0): Using 5 MB for GART textures > (II) RADEON(0): Memory manager initialized to (0,0) (1280,8191) > (II) RADEON(0): Reserved area from (0,1024) to (1280,1026) > (II) RADEON(0): Largest offscreen area available: 1280 x 7165 > (II) RADEON(0): Will use back buffer at offset 0x1400000 > (II) RADEON(0): Will use depth buffer at offset 0x1900000 > (II) RADEON(0): Will use 100352 kb for textures at offset 0x1e00000 > (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) > Screen to screen bit blits > Solid filled rectangles > 8x8 mono pattern filled rectangles > Indirect CPU to Screen color expansion > Solid Lines > Scanline Image Writes > Offscreen Pixmaps > Setting up tile and stipple cache: > 32 128x128 slots > 32 256x256 slots > 16 512x512 slots > (II) RADEON(0): Acceleration enabled > (==) RADEON(0): Backing store disabled > (==) RADEON(0): Silken mouse enabled > (II) RADEON(0): Using hardware cursor (scanline 1026) > (II) RADEON(0): Largest offscreen area available: 1280 x 7161 > (**) Option "dpms" > (**) RADEON(0): DPMS enabled > (WW) RADEON(0): Option "DynamicClocks" is not used > (II) RADEON(0): X context handle = 0x00000001 > (II) RADEON(0): [drm] installed DRM signal handler > (II) RADEON(0): [DRI] installation complete > (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers > > > I hope this can be of help, > Helge Hafting > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Your life is like a penny -- how are you going to spend it? John Covici covici@ccs.covici.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/