from it, I created them manually, ran glxinfo and got a dead box
with this in kern.log:
kernel: kernel BUG at drivers/gpu/drm/drm_fops.c:146!
kernel: invalid opcode: [#1] PREEMPT SMP
kernel: last sysfs file:
/sys/devices/pci:00/:00:1e.0/:04:00.2/local_cpus
kernel: CPU 2
kernel
On Friday, January 30, 2009 1:21 am Andrew Morton wrote:
> On Fri, 30 Jan 2009 10:13:55 +0100 Thomas Hellstr__m
wrote:
> > >> Sounds right to me. The offsets are just handles, not real file
> > >> objects or backing store addresses. We use them to take advantage of
> > >> all the inode address
Andrew Morton wrote:
> On Fri, 30 Jan 2009 10:13:55 +0100 Thomas Hellstr__m
> wrote:
>
>
Sounds right to me. The offsets are just handles, not real file objects
or
backing store addresses. We use them to take advantage of all the inode
address mapping helpers, since th
On Fri, 30 Jan 2009 10:13:55 +0100 Thomas Hellstr__m
wrote:
> >> Sounds right to me. The offsets are just handles, not real file objects
> >> or
> >> backing store addresses. We use them to take advantage of all the inode
> >> address mapping helpers, since they track stuff for us.
> >>
> >
Andrew Morton wrote:
> On Thu, 29 Jan 2009 19:50:17 -0800 Jesse Barnes
> wrote:
>
>
>> On Thursday, January 29, 2009 5:43 pm Dave Airlie wrote:
>>
>>> On Fri, Jan 30, 2009 at 11:20 AM, Andrew Morton
>>>
hm, I'm a bit surprised to see the drm code using `struct
address_spa
On Fri, Jan 30, 2009 at 05:44, Andrew Morton wrote:
> On Thu, 29 Jan 2009 19:50:17 -0800 Jesse Barnes
> wrote:
>
>> On Thursday, January 29, 2009 5:43 pm Dave Airlie wrote:
>> > On Fri, Jan 30, 2009 at 11:20 AM, Andrew Morton
>> > > hm, I'm a bit surprised to see the drm code using `struct
>> >
On Thu, 29 Jan 2009 19:50:17 -0800 Jesse Barnes
wrote:
> On Thursday, January 29, 2009 5:43 pm Dave Airlie wrote:
> > On Fri, Jan 30, 2009 at 11:20 AM, Andrew Morton
> > > hm, I'm a bit surprised to see the drm code using `struct
> > > address_space' and read_mapping_page() and unmap_mapping_ran
On Thursday, January 29, 2009 5:43 pm Dave Airlie wrote:
> On Fri, Jan 30, 2009 at 11:20 AM, Andrew Morton
> > hm, I'm a bit surprised to see the drm code using `struct
> > address_space' and read_mapping_page() and unmap_mapping_range() and
> > such. I thought those only worked with regular files
ng
>> >> system started just fine. When I type startx the hung happen again.
>> >> Please let me know if you need some more information besides oops from
>> >> messages file and lspci output.
>> >>
>> >>
>> >> Jan 21 08:53:58 l
ase let me know if you need some more information besides oops from
> >> messages file and lspci output.
> >>
> >>
> >> Jan 21 08:53:58 lelux kernel: [ cut here ]
> >> Jan 21 08:53:58 lelux kernel: kernel BUG at drivers/gpu/drm/drm_
if you need some more information besides oops from
>>> messages file and lspci output.
>>>
>>>
>>> Jan 21 08:53:58 lelux kernel: [ cut here ]
>>> Jan 21 08:53:58 lelux kernel: kernel BUG at drivers/gpu/drm/drm_fops.c:146!
>&g
gt;
>>
>> Jan 21 08:53:58 lelux kernel: ------------[ cut here ]----
>> Jan 21 08:53:58 lelux kernel: kernel BUG at drivers/gpu/drm/drm_fops.c:146!
>
> I assume that 2.6.28 didn't do this?
This is a userspace race between udev and libdrm, I'm not sure we can
ating
> system started just fine. When I type startx the hung happen again.
> Please let me know if you need some more information besides oops from
> messages file and lspci output.
>
>
> Jan 21 08:53:58 lelux kernel: [ cut here ]
> Jan 21 08:53:58 lelux ke
13 matches
Mail list logo
