On Wed, 2008-09-03 at 12:58 -0700, Steve Kargl wrote: > On Wed, Sep 03, 2008 at 03:51:52PM -0400, Robert Noland wrote: > > On Tue, 2008-09-02 at 22:12 -0700, Steve Kargl wrote: > >> > >> From dmesg: > >> > >> vgapci0: <VGA display> port 0xb000-0xb0ff mem 0xfd000000-0xfdffffff,0 > >> xfeaff000-0xfeafffff irq 18 at device 6.0 on pci3 > >> drm0: <Rage XL> on vgapci0 > >> info: [drm] Initialized mach64 2.0.0 20060718 > > > > Ok, I've found the problem... It is easy enough to fix your specific > > situation, but doing so will cause problems for other drivers... Which > > is the reason that I made that change to begin with. The big problem is > > that drm_pci_alloc gets called from a variety of places, some of which > > already hold locks while others don't. We aren't allowed to hold locks > > over some of the bus_dma functions, so I have to go through all of these > > paths and figure out if it is generally safe to always drop the locks, > > or if I need to restructure the code somehow... If you want a patch to > > just get you going temporarily, just let me know... > > > > I can disable Xorg's dri module. When you have a patch you're happy > with, feel free to ping me for testing. Ok, please try the attached patch. I talked it over with another drm developer and it should be safe to drop all the locks while calling drm_pci_alloc(). I think I have fixed this for all drivers / paths that call it. It will log an error now if it is called with either of the two locks that I found being held. I have tested this on my intel 965gm so far and all is well. I also had to touch mach64 and radeon, so I need someone to validate those. (This is a different path from the panic you received previously) robert.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:34 UTC