I'm not quite sure if this can be called a regression, since radeon KMS
is still in staging as far as I know, but it was working quite well for
me up until about -rc3, and now it causes a panic on every boot. If I
pass radeon.modeset=0 on the command line, everything works.
I took a picture of the crash details:
http://picasaweb.google.ca/kjwinchester/LinuxKernelPanic#5432580230065271634
I was hoping that the last pull of DRM fixes would correct the issue,
but unfortunately they had no effect.
In case it helps, here is the gdb listing for the problem address:
(gdb) l *(radeon_agp_init+0x1d)
0xffffffff811c1592 is in radeon_agp_init (drivers/gpu/drm/radeon/radeon_agp.c:136).
131 uint32_t agp_status;
132 int default_mode;
133 bool is_v3;
134 int ret;
135
136 if (rdev->ddev->agp->agp_info.aper_size < 32) {
137 dev_warn(rdev->dev, "AGP aperture to small (%dM) "
138 "need at least 32M, disabling AGP\n",
139 rdev->ddev->agp->agp_info.aper_size);
140 return -EINVAL;
Is there any other info I can provide?
Thanks,
--
Kevin Winchester
On Sat, 30 Jan 2010, Kevin Winchester wrote:
>
> I took a picture of the crash details:
>
> http://picasaweb.google.ca/kjwinchester/LinuxKernelPanic#5432580230065271634
>
> In case it helps, here is the gdb listing for the problem address:
>
> (gdb) l *(radeon_agp_init+0x1d)
> 0xffffffff811c1592 is in radeon_agp_init (drivers/gpu/drm/radeon/radeon_agp.c:136).
> 131 uint32_t agp_status;
> 132 int default_mode;
> 133 bool is_v3;
> 134 int ret;
> 135
> 136 if (rdev->ddev->agp->agp_info.aper_size < 32) {
> 137 dev_warn(rdev->dev, "AGP aperture to small (%dM) "
> 138 "need at least 32M, disabling AGP\n",
> 139 rdev->ddev->agp->agp_info.aper_size);
> 140 return -EINVAL;
>
> Is there any other info I can provide?
In your crash 'rdev->ddev->agp' is NULL. The instruction decode is:
e: 55 push %rbp
f: 48 89 e5 mov %rsp,%rbp
12: 41 56 push %r14
14: 41 55 push %r13
16: 41 54 push %r12
18: 53 push %rbx
19: 48 89 fb mov %rdi,%rbx
1c: 48 83 ec 40 sub $0x40,%rsp
20: 48 8b 7f 08 mov 0x8(%rdi),%rdi
24: 48 8b 87 20 03 00 00 mov 0x320(%rdi),%rax
2b:* 4c 8b 60 28 mov 0x28(%rax),%r12 <-- trapping instruction
2f: 49 83 fc 1f cmp $0x1f,%r12
33: 77 2e ja 0x63
35: 48 8b 3b mov (%rbx),%rdi
38: 48 8b 5f 10 mov 0x10(%rdi),%rbx
so it's that lod of "agp_info.aper_size" that fails (you can see how it's
trying to compare with 31, it comes from that "agp_info.aper_size < 32"
thing.
Did that DRM init happen before AGP init or something?
Linus
Am Samstag 30 Januar 2010 18:43:52 schrieb Linus Torvalds:
> On Sat, 30 Jan 2010, Kevin Winchester wrote:
> > I took a picture of the crash details:
> >
> > http://picasaweb.google.ca/kjwinchester/LinuxKernelPanic#5432580230065271
> > 634
> >
> > In case it helps, here is the gdb listing for the problem address:
> >
> > (gdb) l *(radeon_agp_init+0x1d)
> > 0xffffffff811c1592 is in radeon_agp_init
> > (drivers/gpu/drm/radeon/radeon_agp.c:136). 131 uint32_t agp_status;
> > 132 int default_mode;
> > 133 bool is_v3;
> > 134 int ret;
> > 135
> > 136 if (rdev->ddev->agp->agp_info.aper_size < 32) {
> > 137 dev_warn(rdev->dev, "AGP aperture to small (%dM) "
> > 138 "need at least 32M, disabling AGP\n",
> > 139 rdev->ddev->agp->agp_info.aper_size);
> > 140 return -EINVAL;
> >
> > Is there any other info I can provide?
>
> In your crash 'rdev->ddev->agp' is NULL. The instruction decode is:
>
> e: 55 push %rbp
> f: 48 89 e5 mov %rsp,%rbp
> 12: 41 56 push %r14
> 14: 41 55 push %r13
> 16: 41 54 push %r12
> 18: 53 push %rbx
> 19: 48 89 fb mov %rdi,%rbx
> 1c: 48 83 ec 40 sub $0x40,%rsp
> 20: 48 8b 7f 08 mov 0x8(%rdi),%rdi
> 24: 48 8b 87 20 03 00 00 mov 0x320(%rdi),%rax
> 2b:* 4c 8b 60 28 mov 0x28(%rax),%r12 <-- trapping
> instruction 2f: 49 83 fc 1f cmp $0x1f,%r12
> 33: 77 2e ja 0x63
> 35: 48 8b 3b mov (%rbx),%rdi
> 38: 48 8b 5f 10 mov 0x10(%rdi),%rbx
>
> so it's that lod of "agp_info.aper_size" that fails (you can see how it's
> trying to compare with 31, it comes from that "agp_info.aper_size < 32"
> thing.
>
> Did that DRM init happen before AGP init or something?
>
> Linus
This is caused by commit 42590a75019a50012f25a962246498dead42843
Fix is already posted:
http://marc.info/?l=linux-kernel&m=126428141429200&w=2
On Sat, 30 Jan 2010, Johannes Hirte wrote:
>
> This is caused by commit 42590a75019a50012f25a962246498dead42843
>
> Fix is already posted:
>
> http://marc.info/?l=linux-kernel&m=126428141429200&w=2
Goodie. Kevin, can you test the patch from FUJITA Tomonori in that thread
("http://marc.info/?l=linux-kernel&m=126439631307219&w=2" to be exact).
Linus
On Sat, Jan 30, 2010 at 8:54 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Sat, 30 Jan 2010, Johannes Hirte wrote:
>>
>> This is caused by commit 42590a75019a50012f25a962246498dead42843
>>
>> Fix is already posted:
>>
>> http://marc.info/?l=linux-kernel&m=126428141429200&w=2
>
> Goodie. Kevin, can you test the patch from FUJITA Tomonori in that thread
> ("http://marc.info/?l=linux-kernel&m=126439631307219&w=2" to be exact).
>
The little hunk of code that Kevin posted is also the source of a new
warning in -rc6,
which is easily fixed. (following up with a patch)
Assuming the patch in that link fixes the problem, the order of the
check of the aper_size in
radeon_agp_init appears incorrect to me. Also following up with a patch.
John Kacur
On Sat, 2010-01-30 at 11:54 -0800, Linus Torvalds wrote:
>
> On Sat, 30 Jan 2010, Johannes Hirte wrote:
> >
> > This is caused by commit 42590a75019a50012f25a962246498dead42843
> >
> > Fix is already posted:
> >
> > http://marc.info/?l=linux-kernel&m=126428141429200&w=2
>
> Goodie. Kevin, can you test the patch from FUJITA Tomonori in that thread
> ("http://marc.info/?l=linux-kernel&m=126439631307219&w=2" to be exact).
>
Thank you - the patch from FUJITA Tomonori corrected the issue.
I also tried out the additional patches from John Kacur. They did not
break anything that I could see, and the logic behind them seems
reasonable to me. They weren't necessary to fix my problem though, so I
guess they are likely not 2.6.33 material (unless they are critical for
someone else).
Thanks again to everyone who looked into the problem,
--
Kevin Winchester
On Sat, 30 Jan 2010, Kevin Winchester wrote:
>
> Thank you - the patch from FUJITA Tomonori corrected the issue.
>
> I also tried out the additional patches from John Kacur. They did not
> break anything that I could see, and the logic behind them seems
> reasonable to me. They weren't necessary to fix my problem though, so I
> guess they are likely not 2.6.33 material (unless they are critical for
> someone else).
All right. Fix merged (commit 61684ceaad) and pushed out.
Linus