* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-06 2:17 ` David S. Miller
0 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-06 2:17 UTC (permalink / raw)
To: trizt; +Cc: linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Tue, 6 Dec 2005 03:04:11 +0100 (CET)
> The dmesg entry comes from 2.6.15-rc2, but is kind of the same, expect not
> all versions has the ugly and annoying face.
1) Lots of problems have been fixed that trigger that bug message,
please give 2.6.15-rc5 a spin.
2) You didn't give what the failure mode is for kernels such
as 2.6.14.2, which should work, and certainly don't print out
that bug message
3) Finally, this discussion belongs on sparclinux@vger.kernel.org (CC'd),
not linux-kernel.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-06 2:17 ` David S. Miller
(?)
@ 2005-12-06 15:08 ` Christopher Zimmermann
-1 siblings, 0 replies; 61+ messages in thread
From: Christopher Zimmermann @ 2005-12-06 15:08 UTC (permalink / raw)
To: sparclinux
I'm not sure, if this is the same problem, but since 2.6.15rc3 my X11 broke
too. I'm working on an Ultra2 Creator. This is what my X11 says on 2.6.15rc5:
Call Trace:
[0000000000439de4] copy_process+0x8e4/0xe40
[000000000043a380] do_fork+0x40/0x1e0
[0000000000406cd4] linux_sparc_syscall32+0x34/0x40
[00000000701d3bfc] 0x701d3bfc
Bad pte = 1fc00600a88, process = ???, vm_flags = 184473, vaddr = 7001e000
Call Trace:
[000000000046bc20] exit_mmap+0x80/0x140
[0000000000439454] mmput+0x34/0xe0
[0000000000484e8c] flush_old_exec+0x1cc/0x940
[0000000000427f2c] load_elf_binary+0x3cc/0x15c0
[00000000004857d4] search_binary_handler+0x74/0x1a0
[00000000004a3e78] compat_do_execve+0x118/0x1e0
[000000000041f71c] sparc32_execve+0x3c/0xc0
[0000000000406cd4] linux_sparc_syscall32+0x34/0x40
[00000000701d3d68] 0x701d3d68
Bad pte = 1fc00600a88, process = Xorg, vm_flags = 184473, vaddr = 7001e000
Call Trace:
[0000000000439de4] copy_process+0x8e4/0xe40
[000000000043a380] do_fork+0x40/0x1e0
[0000000000406cd4] linux_sparc_syscall32+0x34/0x40
[00000000701d3bfc] 0x701d3bfc
Bad pte = 1fc00600a88, process = ???, vm_flags = 184473, vaddr = 7001e000
Call Trace:
[000000000046bc20] exit_mmap+0x80/0x140
[0000000000439454] mmput+0x34/0xe0
[0000000000484e8c] flush_old_exec+0x1cc/0x940
[0000000000427f2c] load_elf_binary+0x3cc/0x15c0
[00000000004857d4] search_binary_handler+0x74/0x1a0
[00000000004a3e78] compat_do_execve+0x118/0x1e0
[000000000041f71c] sparc32_execve+0x3c/0xc0
[0000000000406cd4] linux_sparc_syscall32+0x34/0x40
[00000000701d3d68] 0x701d3d68
waiting for X server to shut down Bad pte = 800001fc00600e88, process = Xorg, vm_flags = 184473, vaddr = 7001e000
Call Trace:
[000000000046c390] unmap_region+0x90/0x140
[000000000046cad4] do_munmap+0x174/0x240
[000000000046cbbc] sys_munmap+0x1c/0x40
[0000000000406cd4] linux_sparc_syscall32+0x34/0x40
[00000000003d3ee0] 0x3d3ee0
FreeFontPath: FPE "/usr/lib/X11/fonts/misc" refcount is 2, should be 1; fixing.
On Mon, Dec 05, 2005 at 06:17:32PM -0800, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Tue, 6 Dec 2005 03:04:11 +0100 (CET)
>
> > The dmesg entry comes from 2.6.15-rc2, but is kind of the same, expect not
> > all versions has the ugly and annoying face.
>
> 1) Lots of problems have been fixed that trigger that bug message,
> please give 2.6.15-rc5 a spin.
>
> 2) You didn't give what the failure mode is for kernels such
> as 2.6.14.2, which should work, and certainly don't print out
> that bug message
>
> 3) Finally, this discussion belongs on sparclinux@vger.kernel.org (CC'd),
> not linux-kernel.
> -
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-06 2:17 ` David S. Miller
@ 2005-12-06 16:10 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-06 16:10 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel maillist, sparclinux
On Mon, 5 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Tue, 6 Dec 2005 03:04:11 +0100 (CET)
>
>> The dmesg entry comes from 2.6.15-rc2, but is kind of the same, expect not
>> all versions has the ugly and annoying face.
>
> 1) Lots of problems have been fixed that trigger that bug message,
> please give 2.6.15-rc5 a spin.
Have been trying 2.6.x kernels today, including the 2.6.15-rc5 and it's
still there.
> 2) You didn't give what the failure mode is for kernels such
> as 2.6.14.2, which should work, and certainly don't print out
> that bug message
It's the same as for 2.6.13 and 2.6.15rc, did build a 2.6.14.3 as had
removed the 14.2 when I started to use 15rc.
> 3) Finally, this discussion belongs on sparclinux@vger.kernel.org (CC'd),
> not linux-kernel.
The kernel output said "linux-kernel", which is why I sent the the mail to
"linux-kernel", maybe the displayed address should have the arch depending
address instead of the general?
More data:
Xorg: 6.8.2 (xaa patched sunffb driver)
Distro: Gentoo (64bits kernel, 32bit user)
Machine: Ultra 10
xorg.conf:
http://dev.gentoo.org/~fmccor/docs/xorg/xorg.conf/xorg.conf.html
(see the one for kernel 2.6)
Xorg.0.log: http://www.kotiaho.net/~trizt/tmpimg/sparc_xorg.log
dmesg output from kernels 2.6.13 -> 2.6.15-rc5:
http://www.kotiaho.net/~trizt/tmpimg/sparc_xorg.dmesg
As earlier said, the Xorg 6.8.2 works fine with the 2.4 specific
xorg.conf (see on the xorg.conf link) and with a 2.4 kernel.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-06 16:10 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-06 16:10 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel maillist, sparclinux
On Mon, 5 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Tue, 6 Dec 2005 03:04:11 +0100 (CET)
>
>> The dmesg entry comes from 2.6.15-rc2, but is kind of the same, expect not
>> all versions has the ugly and annoying face.
>
> 1) Lots of problems have been fixed that trigger that bug message,
> please give 2.6.15-rc5 a spin.
Have been trying 2.6.x kernels today, including the 2.6.15-rc5 and it's
still there.
> 2) You didn't give what the failure mode is for kernels such
> as 2.6.14.2, which should work, and certainly don't print out
> that bug message
It's the same as for 2.6.13 and 2.6.15rc, did build a 2.6.14.3 as had
removed the 14.2 when I started to use 15rc.
> 3) Finally, this discussion belongs on sparclinux@vger.kernel.org (CC'd),
> not linux-kernel.
The kernel output said "linux-kernel", which is why I sent the the mail to
"linux-kernel", maybe the displayed address should have the arch depending
address instead of the general?
More data:
Xorg: 6.8.2 (xaa patched sunffb driver)
Distro: Gentoo (64bits kernel, 32bit user)
Machine: Ultra 10
xorg.conf:
http://dev.gentoo.org/~fmccor/docs/xorg/xorg.conf/xorg.conf.html
(see the one for kernel 2.6)
Xorg.0.log: http://www.kotiaho.net/~trizt/tmpimg/sparc_xorg.log
dmesg output from kernels 2.6.13 -> 2.6.15-rc5:
http://www.kotiaho.net/~trizt/tmpimg/sparc_xorg.dmesg
As earlier said, the Xorg 6.8.2 works fine with the 2.4 specific
xorg.conf (see on the xorg.conf link) and with a 2.4 kernel.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-06 16:10 ` J.O. Aho
@ 2005-12-06 23:23 ` David S. Miller
-1 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-06 23:23 UTC (permalink / raw)
To: trizt; +Cc: linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Tue, 6 Dec 2005 17:10:07 +0100 (CET)
> On Mon, 5 Dec 2005, David S. Miller wrote:
>
> > 2) You didn't give what the failure mode is for kernels such
> > as 2.6.14.2, which should work, and certainly don't print out
> > that bug message
>
> It's the same as for 2.6.13 and 2.6.15rc, did build a 2.6.14.3 as had
> removed the 14.2 when I started to use 15rc.
You're still not answering my question, what is this failure
mode? Xorg doesn't start? The kernel crashes when Xorg starts?
Xorg starts but you get a blank screen? You did not mention
this critical information anywhere. Mentioning a list of other
kernels that "it's the same" for doesn't describe the failure
mode. :)
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-06 23:23 ` David S. Miller
0 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-06 23:23 UTC (permalink / raw)
To: trizt; +Cc: linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Tue, 6 Dec 2005 17:10:07 +0100 (CET)
> On Mon, 5 Dec 2005, David S. Miller wrote:
>
> > 2) You didn't give what the failure mode is for kernels such
> > as 2.6.14.2, which should work, and certainly don't print out
> > that bug message
>
> It's the same as for 2.6.13 and 2.6.15rc, did build a 2.6.14.3 as had
> removed the 14.2 when I started to use 15rc.
You're still not answering my question, what is this failure
mode? Xorg doesn't start? The kernel crashes when Xorg starts?
Xorg starts but you get a blank screen? You did not mention
this critical information anywhere. Mentioning a list of other
kernels that "it's the same" for doesn't describe the failure
mode. :)
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-06 23:23 ` David S. Miller
@ 2005-12-07 11:05 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-07 11:05 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel maillist, sparclinux
On Tue, 6 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Tue, 6 Dec 2005 17:10:07 +0100 (CET)
>
>> On Mon, 5 Dec 2005, David S. Miller wrote:
>>
>>> 2) You didn't give what the failure mode is for kernels such
>>> as 2.6.14.2, which should work, and certainly don't print out
>>> that bug message
>>
>> It's the same as for 2.6.13 and 2.6.15rc, did build a 2.6.14.3 as had
>> removed the 14.2 when I started to use 15rc.
>
> You're still not answering my question, what is this failure
> mode? Xorg doesn't start? The kernel crashes when Xorg starts?
> Xorg starts but you get a blank screen? You did not mention
> this critical information anywhere. Mentioning a list of other
> kernels that "it's the same" for doesn't describe the failure
> mode. :)
Sorry, thought the log from Xorg was quite selfexplaining
Xorg jumps to VT7, you see a console cursor, "_", at the top left corner
and thats it. It's impossible to change back to VT1 (or any other), the
only thing that works is to press [stop]-[a] so that you get back to the
OBP from where I can reset the machine (resetting by the reset button
don't work). It's still possible to ssh to the machine, more and dmesg is
possible, but running ps causes the machine to completly lock up, change
init mode don't give any affects att all and trying to turn off or kill X
results in the same as ps.
When running in plain console (without trying to run X) everything works
fine (just telling that so I won't get people to ask if ps segfaults in
other cases or claims that my init is broke and so on).
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-07 11:05 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-07 11:05 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel maillist, sparclinux
On Tue, 6 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Tue, 6 Dec 2005 17:10:07 +0100 (CET)
>
>> On Mon, 5 Dec 2005, David S. Miller wrote:
>>
>>> 2) You didn't give what the failure mode is for kernels such
>>> as 2.6.14.2, which should work, and certainly don't print out
>>> that bug message
>>
>> It's the same as for 2.6.13 and 2.6.15rc, did build a 2.6.14.3 as had
>> removed the 14.2 when I started to use 15rc.
>
> You're still not answering my question, what is this failure
> mode? Xorg doesn't start? The kernel crashes when Xorg starts?
> Xorg starts but you get a blank screen? You did not mention
> this critical information anywhere. Mentioning a list of other
> kernels that "it's the same" for doesn't describe the failure
> mode. :)
Sorry, thought the log from Xorg was quite selfexplaining
Xorg jumps to VT7, you see a console cursor, "_", at the top left corner
and thats it. It's impossible to change back to VT1 (or any other), the
only thing that works is to press [stop]-[a] so that you get back to the
OBP from where I can reset the machine (resetting by the reset button
don't work). It's still possible to ssh to the machine, more and dmesg is
possible, but running ps causes the machine to completly lock up, change
init mode don't give any affects att all and trying to turn off or kill X
results in the same as ps.
When running in plain console (without trying to run X) everything works
fine (just telling that so I won't get people to ask if ps segfaults in
other cases or claims that my init is broke and so on).
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-07 11:05 ` J.O. Aho
@ 2005-12-07 14:07 ` Ben Collins
-1 siblings, 0 replies; 61+ messages in thread
From: Ben Collins @ 2005-12-07 14:07 UTC (permalink / raw)
To: J.O. Aho; +Cc: David S. Miller, linux-kernel maillist, sparclinux
On Wed, 2005-12-07 at 12:05 +0100, J.O. Aho wrote:
> Xorg jumps to VT7, you see a console cursor, "_", at the top left corner
> and thats it. It's impossible to change back to VT1 (or any other), the
> only thing that works is to press [stop]-[a] so that you get back to the
> OBP from where I can reset the machine (resetting by the reset button
> don't work). It's still possible to ssh to the machine, more and dmesg is
> possible, but running ps causes the machine to completly lock up, change
> init mode don't give any affects att all and trying to turn off or kill X
> results in the same as ps.
Does the dmesg contain any sort of oops?
--
Ben Collins <ben.collins@ubuntu.com>
Developer
Ubuntu Linux
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-07 14:07 ` Ben Collins
0 siblings, 0 replies; 61+ messages in thread
From: Ben Collins @ 2005-12-07 14:07 UTC (permalink / raw)
To: J.O. Aho; +Cc: David S. Miller, linux-kernel maillist, sparclinux
On Wed, 2005-12-07 at 12:05 +0100, J.O. Aho wrote:
> Xorg jumps to VT7, you see a console cursor, "_", at the top left corner
> and thats it. It's impossible to change back to VT1 (or any other), the
> only thing that works is to press [stop]-[a] so that you get back to the
> OBP from where I can reset the machine (resetting by the reset button
> don't work). It's still possible to ssh to the machine, more and dmesg is
> possible, but running ps causes the machine to completly lock up, change
> init mode don't give any affects att all and trying to turn off or kill X
> results in the same as ps.
Does the dmesg contain any sort of oops?
--
Ben Collins <ben.collins@ubuntu.com>
Developer
Ubuntu Linux
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-07 14:07 ` Ben Collins
@ 2005-12-07 15:42 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-07 15:42 UTC (permalink / raw)
To: Ben Collins; +Cc: David S. Miller, linux-kernel maillist, sparclinux
On Wed, 7 Dec 2005, Ben Collins wrote:
> On Wed, 2005-12-07 at 12:05 +0100, J.O. Aho wrote:
>> Xorg jumps to VT7, you see a console cursor, "_", at the top left corner
>> and thats it. It's impossible to change back to VT1 (or any other), the
>> only thing that works is to press [stop]-[a] so that you get back to the
>> OBP from where I can reset the machine (resetting by the reset button
>> don't work). It's still possible to ssh to the machine, more and dmesg is
>> possible, but running ps causes the machine to completly lock up, change
>> init mode don't give any affects att all and trying to turn off or kill X
>> results in the same as ps.
>
> Does the dmesg contain any sort of oops?
Nothing else than the "happy guy" error message, the rest is just the
normal bootup messages like network card drivers been loaded and so on
(of course those are before the "happy guy")
Sorry for not including the whole dmesg, but been taking eye photos, so
have quite big difficulties to see anything, including text on 320x200
screen with big fonts.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-07 15:42 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-07 15:42 UTC (permalink / raw)
To: Ben Collins; +Cc: David S. Miller, linux-kernel maillist, sparclinux
On Wed, 7 Dec 2005, Ben Collins wrote:
> On Wed, 2005-12-07 at 12:05 +0100, J.O. Aho wrote:
>> Xorg jumps to VT7, you see a console cursor, "_", at the top left corner
>> and thats it. It's impossible to change back to VT1 (or any other), the
>> only thing that works is to press [stop]-[a] so that you get back to the
>> OBP from where I can reset the machine (resetting by the reset button
>> don't work). It's still possible to ssh to the machine, more and dmesg is
>> possible, but running ps causes the machine to completly lock up, change
>> init mode don't give any affects att all and trying to turn off or kill X
>> results in the same as ps.
>
> Does the dmesg contain any sort of oops?
Nothing else than the "happy guy" error message, the rest is just the
normal bootup messages like network card drivers been loaded and so on
(of course those are before the "happy guy")
Sorry for not including the whole dmesg, but been taking eye photos, so
have quite big difficulties to see anything, including text on 320x200
screen with big fonts.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-07 11:05 ` J.O. Aho
@ 2005-12-07 20:34 ` David S. Miller
-1 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-07 20:34 UTC (permalink / raw)
To: trizt; +Cc: linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Wed, 7 Dec 2005 12:05:43 +0100 (CET)
> When running in plain console (without trying to run X) everything works
> fine (just telling that so I won't get people to ask if ps segfaults in
> other cases or claims that my init is broke and so on).
Is the Xorg.conf setup to use the "ati" driver? You can't use
"fbdev" or similar, that will in fact hang the machine in a
manner similar to how you describe.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-07 20:34 ` David S. Miller
0 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-07 20:34 UTC (permalink / raw)
To: trizt; +Cc: linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Wed, 7 Dec 2005 12:05:43 +0100 (CET)
> When running in plain console (without trying to run X) everything works
> fine (just telling that so I won't get people to ask if ps segfaults in
> other cases or claims that my init is broke and so on).
Is the Xorg.conf setup to use the "ati" driver? You can't use
"fbdev" or similar, that will in fact hang the machine in a
manner similar to how you describe.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-07 20:34 ` David S. Miller
@ 2005-12-07 21:22 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-07 21:22 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel maillist, sparclinux
On Wed, 7 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Wed, 7 Dec 2005 12:05:43 +0100 (CET)
>
>> When running in plain console (without trying to run X) everything works
>> fine (just telling that so I won't get people to ask if ps segfaults in
>> other cases or claims that my init is broke and so on).
>
> Is the Xorg.conf setup to use the "ati" driver? You can't use
> "fbdev" or similar, that will in fact hang the machine in a
> manner similar to how you describe.
I'm using the sunffb driver, as I wish to get the output from my creator3d
card, so that I can see something displayed as the monitor requiers a 13W3
connector. So I assume from your reply that framebuffer isn't working in
kernel 2.6 for sparc, but for other archs like ppc?
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-07 21:22 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-07 21:22 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel maillist, sparclinux
On Wed, 7 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Wed, 7 Dec 2005 12:05:43 +0100 (CET)
>
>> When running in plain console (without trying to run X) everything works
>> fine (just telling that so I won't get people to ask if ps segfaults in
>> other cases or claims that my init is broke and so on).
>
> Is the Xorg.conf setup to use the "ati" driver? You can't use
> "fbdev" or similar, that will in fact hang the machine in a
> manner similar to how you describe.
I'm using the sunffb driver, as I wish to get the output from my creator3d
card, so that I can see something displayed as the monitor requiers a 13W3
connector. So I assume from your reply that framebuffer isn't working in
kernel 2.6 for sparc, but for other archs like ppc?
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-07 21:22 ` J.O. Aho
@ 2005-12-07 21:32 ` David S. Miller
-1 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-07 21:32 UTC (permalink / raw)
To: trizt; +Cc: linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Wed, 7 Dec 2005 22:22:42 +0100 (CET)
> I'm using the sunffb driver, as I wish to get the output from my creator3d
> card, so that I can see something displayed as the monitor requiers a 13W3
> connector. So I assume from your reply that framebuffer isn't working in
> kernel 2.6 for sparc, but for other archs like ppc?
No, that should work just fine. Just make sure "sunffb" is specified
as the driver to use in the xorg.conf file.
I have an ultra60 with creator here and I'll try to reproduce your
problem.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-07 21:32 ` David S. Miller
0 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-07 21:32 UTC (permalink / raw)
To: trizt; +Cc: linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Wed, 7 Dec 2005 22:22:42 +0100 (CET)
> I'm using the sunffb driver, as I wish to get the output from my creator3d
> card, so that I can see something displayed as the monitor requiers a 13W3
> connector. So I assume from your reply that framebuffer isn't working in
> kernel 2.6 for sparc, but for other archs like ppc?
No, that should work just fine. Just make sure "sunffb" is specified
as the driver to use in the xorg.conf file.
I have an ultra60 with creator here and I'll try to reproduce your
problem.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-07 21:32 ` David S. Miller
@ 2005-12-09 12:07 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-09 12:07 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, sparclinux
On Wed, 7 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Wed, 7 Dec 2005 22:22:42 +0100 (CET)
>
>> I'm using the sunffb driver, as I wish to get the output from my creator3d
>> card, so that I can see something displayed as the monitor requiers a 13W3
>> connector. So I assume from your reply that framebuffer isn't working in
>> kernel 2.6 for sparc, but for other archs like ppc?
>
> No, that should work just fine. Just make sure "sunffb" is specified
> as the driver to use in the xorg.conf file.
>
> I have an ultra60 with creator here and I'll try to reproduce your
> problem.
That sounds nice, just in case if it would be of interest, I have made my
config file available and it can be found at
http://www.kotiaho.net/~trizt/tmpimg/u10_2.6.15rc5.config
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-09 12:07 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-09 12:07 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, sparclinux
On Wed, 7 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Wed, 7 Dec 2005 22:22:42 +0100 (CET)
>
>> I'm using the sunffb driver, as I wish to get the output from my creator3d
>> card, so that I can see something displayed as the monitor requiers a 13W3
>> connector. So I assume from your reply that framebuffer isn't working in
>> kernel 2.6 for sparc, but for other archs like ppc?
>
> No, that should work just fine. Just make sure "sunffb" is specified
> as the driver to use in the xorg.conf file.
>
> I have an ultra60 with creator here and I'll try to reproduce your
> problem.
That sounds nice, just in case if it would be of interest, I have made my
config file available and it can be found at
http://www.kotiaho.net/~trizt/tmpimg/u10_2.6.15rc5.config
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-07 21:32 ` David S. Miller
@ 2005-12-10 22:25 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-10 22:25 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel maillist, sparclinux
Got today a mail from Mr Miller with the subject "Need for VM_INCOMPLETE
on I/O mappings" and a patch made by Mr Dickins. Did apply it to my
2.6.15-rc5 and recompiled the whole kernel and all the drivers.
Sadly this didn't affect the problem I have when starting X. The
Xorg.0.log looks still the same as before and I do have the '_' cursor
in the right left corner of the screen.
The only error in dmesg output is the following:
kernel BUG at arch/sparc64/mm/generic.c:77!
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
X(6762): Kernel bad sw trap 5 [#1]
TSTATE: 0000000011009603 TPC: 0000000000434d60 TNPC: 0000000000434d64 Y:
00000000 Not tainted
TPC: <io_remap_pfn_range+0x3c0/0x3e0>
g0: fffff800007ee080 g1: 0000000000669400 g2: 0000000000000001 g3:
0000000000001df8
g4: fffff80001f30160 g5: 0000000000000010 g6: fffff80005c70000 g7:
0000000000000000
o0: 000000000000002f o1: 000000000061f118 o2: 000000000000004d o3:
0000000011812000
o4: 000001fc00610000 o5: fffff80001318c00 sp: fffff80005c7f271 ret_pc:
0000000000434d58
RPC: <io_remap_pfn_range+0x3b8/0x3e0>
l0: 0000000071804000 l1: 000001fb8edfe000 l2: 0000000071804000 l3:
000001fb8edfe000
l4: 000001fb8edfe000 l5: e000000000000f8a l6: a000000000000f8a l7:
c000000000000f8a
i0: 0000000071802000 i1: 0000000071802000 i2: fffff80000b90000 i3:
0000000071802000
i4: 80000000000006b0 i5: fffff80001db000c i6: fffff80005c7f361 i7:
000000000053b1e4
I7: <sbusfb_mmap_helper+0x104/0x160>
Caller[000000000053b1e4]: sbusfb_mmap_helper+0x104/0x160
Caller[0000000000533574]: fb_mmap+0x134/0x160
Caller[0000000000478708]: do_mmap_pgoff+0x368/0x720
Caller[00000000004161d8]: sys_mmap+0xf8/0x160
Caller[0000000000406c94]: linux_sparc_syscall32+0x34/0x40
Caller[0000000000286378]: 0x286378
Instruction DUMP: 9210204d 7fff6e12 90122118 <91d02005> 7ffff77f
b13e2000 81cfe008 01000000 30680003
I have to say I don't have much knowledge about the kernel code, but in
arch/sparc64/mm/generic.c it looks for me that no matter what if
io_remap_pte_range() is called it will result in a bug output, is this
supposed to happen? Looking at arch/sparc/mm/generic.c I can't find any
similar functionality.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-10 22:25 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-10 22:25 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel maillist, sparclinux
Got today a mail from Mr Miller with the subject "Need for VM_INCOMPLETE
on I/O mappings" and a patch made by Mr Dickins. Did apply it to my
2.6.15-rc5 and recompiled the whole kernel and all the drivers.
Sadly this didn't affect the problem I have when starting X. The
Xorg.0.log looks still the same as before and I do have the '_' cursor
in the right left corner of the screen.
The only error in dmesg output is the following:
kernel BUG at arch/sparc64/mm/generic.c:77!
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
X(6762): Kernel bad sw trap 5 [#1]
TSTATE: 0000000011009603 TPC: 0000000000434d60 TNPC: 0000000000434d64 Y:
00000000 Not tainted
TPC: <io_remap_pfn_range+0x3c0/0x3e0>
g0: fffff800007ee080 g1: 0000000000669400 g2: 0000000000000001 g3:
0000000000001df8
g4: fffff80001f30160 g5: 0000000000000010 g6: fffff80005c70000 g7:
0000000000000000
o0: 000000000000002f o1: 000000000061f118 o2: 000000000000004d o3:
0000000011812000
o4: 000001fc00610000 o5: fffff80001318c00 sp: fffff80005c7f271 ret_pc:
0000000000434d58
RPC: <io_remap_pfn_range+0x3b8/0x3e0>
l0: 0000000071804000 l1: 000001fb8edfe000 l2: 0000000071804000 l3:
000001fb8edfe000
l4: 000001fb8edfe000 l5: e000000000000f8a l6: a000000000000f8a l7:
c000000000000f8a
i0: 0000000071802000 i1: 0000000071802000 i2: fffff80000b90000 i3:
0000000071802000
i4: 80000000000006b0 i5: fffff80001db000c i6: fffff80005c7f361 i7:
000000000053b1e4
I7: <sbusfb_mmap_helper+0x104/0x160>
Caller[000000000053b1e4]: sbusfb_mmap_helper+0x104/0x160
Caller[0000000000533574]: fb_mmap+0x134/0x160
Caller[0000000000478708]: do_mmap_pgoff+0x368/0x720
Caller[00000000004161d8]: sys_mmap+0xf8/0x160
Caller[0000000000406c94]: linux_sparc_syscall32+0x34/0x40
Caller[0000000000286378]: 0x286378
Instruction DUMP: 9210204d 7fff6e12 90122118 <91d02005> 7ffff77f
b13e2000 81cfe008 01000000 30680003
I have to say I don't have much knowledge about the kernel code, but in
arch/sparc64/mm/generic.c it looks for me that no matter what if
io_remap_pte_range() is called it will result in a bug output, is this
supposed to happen? Looking at arch/sparc/mm/generic.c I can't find any
similar functionality.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-10 22:25 ` J.O. Aho
@ 2005-12-10 22:35 ` David S. Miller
-1 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-10 22:35 UTC (permalink / raw)
To: trizt; +Cc: linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Sat, 10 Dec 2005 23:25:36 +0100 (CET)
> I have to say I don't have much knowledge about the kernel code, but in
> arch/sparc64/mm/generic.c it looks for me that no matter what if
> io_remap_pte_range() is called it will result in a bug output, is this
> supposed to happen? Looking at arch/sparc/mm/generic.c I can't find any
> similar functionality.
That's not true. The bug triggers if the page table mapping
is valid already, which should never occur when we are setting
up new mappings. We should always find the PTEs we are filling
in as empty at this point in time. That is what that bug check
is making sure of.
It doesn't trigger for me here with the Xorg server, on an
Ultra60 with CreatorFB. I do get the cursor in the corner
and a non-functional screen but I can switch around to other
VC's and kill the X server cleanly. I definitely don't get
those kernel log messages.
Please retest with this debug tracing added:
--- a/arch/sparc64/mm/generic.c.~1~ 2005-12-10 14:34:18.000000000 -0800
+++ b/arch/sparc64/mm/generic.c 2005-12-10 14:34:56.000000000 -0800
@@ -137,6 +137,12 @@
int space = GET_IOSPACE(pfn);
unsigned long offset = GET_PFN(pfn) << PAGE_SHIFT;
+#if 1
+ printk("IO[%s:%d]: remap_pfn_range(s[%lx]e[%lx],f[%lx],pfn[%lx],sz[%lx],prot[%lx])\n",
+ current->comm, current->pid,
+ vma->vm_start, vma->vm_end,
+ from, pfn, size, pgprot_val(prot));
+#endif
/* See comment in mm/memory.c remap_pfn_range */
vma->vm_flags |= VM_IO | VM_RESERVED | VM_PFNMAP;
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-10 22:35 ` David S. Miller
0 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-10 22:35 UTC (permalink / raw)
To: trizt; +Cc: linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Sat, 10 Dec 2005 23:25:36 +0100 (CET)
> I have to say I don't have much knowledge about the kernel code, but in
> arch/sparc64/mm/generic.c it looks for me that no matter what if
> io_remap_pte_range() is called it will result in a bug output, is this
> supposed to happen? Looking at arch/sparc/mm/generic.c I can't find any
> similar functionality.
That's not true. The bug triggers if the page table mapping
is valid already, which should never occur when we are setting
up new mappings. We should always find the PTEs we are filling
in as empty at this point in time. That is what that bug check
is making sure of.
It doesn't trigger for me here with the Xorg server, on an
Ultra60 with CreatorFB. I do get the cursor in the corner
and a non-functional screen but I can switch around to other
VC's and kill the X server cleanly. I definitely don't get
those kernel log messages.
Please retest with this debug tracing added:
--- a/arch/sparc64/mm/generic.c.~1~ 2005-12-10 14:34:18.000000000 -0800
+++ b/arch/sparc64/mm/generic.c 2005-12-10 14:34:56.000000000 -0800
@@ -137,6 +137,12 @@
int space = GET_IOSPACE(pfn);
unsigned long offset = GET_PFN(pfn) << PAGE_SHIFT;
+#if 1
+ printk("IO[%s:%d]: remap_pfn_range(s[%lx]e[%lx],f[%lx],pfn[%lx],sz[%lx],prot[%lx])\n",
+ current->comm, current->pid,
+ vma->vm_start, vma->vm_end,
+ from, pfn, size, pgprot_val(prot));
+#endif
/* See comment in mm/memory.c remap_pfn_range */
vma->vm_flags |= VM_IO | VM_RESERVED | VM_PFNMAP;
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-10 22:35 ` David S. Miller
@ 2005-12-10 22:52 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-10 22:52 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, sparclinux
On Sat, 10 Dec 2005, David S. Miller wrote:
> It doesn't trigger for me here with the Xorg server, on an
> Ultra60 with CreatorFB. I do get the cursor in the corner
> and a non-functional screen but I can switch around to other
> VC's and kill the X server cleanly. I definitely don't get
> those kernel log messages.
>
> Please retest with this debug tracing added:
This generates two extra lines in the dmesg output, I have included the
bug message too, just in case.
IO[X:6761]:
remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
IO[X:6761]:
remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
kernel BUG at arch/sparc64/mm/generic.c:77!
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
X(6761): Kernel bad sw trap 5 [#1]
TSTATE: 0000000011009603 TPC: 0000000000434da0 TNPC: 0000000000434da4 Y:
00000000 Not tainted
TPC: <io_remap_pfn_range+0x400/0x420>
g0: fffff8000703f261 g1: 0000000000669400 g2: 0000000000000001 g3:
0000000000001f4c
g4: fffff80007e2aa60 g5: 0000000000000010 g6: fffff80007030000 g7:
0000000000000000
o0: 000000000000002f o1: 000000000061f1a8 o2: 000000000000004d o3:
0000000011812000
o4: 000001fc00610000 o5: fffff800041b8c00 sp: fffff8000703f241 ret_pc:
0000000000434d98
RPC: <io_remap_pfn_range+0x3f8/0x420>
l0: 0000000071802000 l1: 000001fb8edfe000 l2: 0000000071804000 l3:
000001fb8edfe000
l4: 000001fb8edfe000 l5: e000000000000f8a l6: a000000000000f8a l7:
c000000000000f8a
i0: 0000000071804000 i1: 0000000071802000 i2: 0000000000000000 i3:
0000000071802000
i4: 80000000000006b0 i5: fffff80005a7000c i6: fffff8000703f361 i7:
000000000053b224
I7: <sbusfb_mmap_helper+0x104/0x160>
Caller[000000000053b224]: sbusfb_mmap_helper+0x104/0x160
Caller[00000000005335b4]: fb_mmap+0x134/0x160
Caller[0000000000478748]: do_mmap_pgoff+0x368/0x720
Caller[00000000004161d8]: sys_mmap+0xf8/0x160
Caller[0000000000406c94]: linux_sparc_syscall32+0x34/0x40
Caller[0000000000286378]: 0x286378
Instruction DUMP: 9210204d 7fff6e02 901221a8 <91d02005> 7ffff76f
b13ee000 81cfe008 01000000 30680003
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-10 22:52 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-10 22:52 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, sparclinux
On Sat, 10 Dec 2005, David S. Miller wrote:
> It doesn't trigger for me here with the Xorg server, on an
> Ultra60 with CreatorFB. I do get the cursor in the corner
> and a non-functional screen but I can switch around to other
> VC's and kill the X server cleanly. I definitely don't get
> those kernel log messages.
>
> Please retest with this debug tracing added:
This generates two extra lines in the dmesg output, I have included the
bug message too, just in case.
IO[X:6761]:
remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
IO[X:6761]:
remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
kernel BUG at arch/sparc64/mm/generic.c:77!
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
X(6761): Kernel bad sw trap 5 [#1]
TSTATE: 0000000011009603 TPC: 0000000000434da0 TNPC: 0000000000434da4 Y:
00000000 Not tainted
TPC: <io_remap_pfn_range+0x400/0x420>
g0: fffff8000703f261 g1: 0000000000669400 g2: 0000000000000001 g3:
0000000000001f4c
g4: fffff80007e2aa60 g5: 0000000000000010 g6: fffff80007030000 g7:
0000000000000000
o0: 000000000000002f o1: 000000000061f1a8 o2: 000000000000004d o3:
0000000011812000
o4: 000001fc00610000 o5: fffff800041b8c00 sp: fffff8000703f241 ret_pc:
0000000000434d98
RPC: <io_remap_pfn_range+0x3f8/0x420>
l0: 0000000071802000 l1: 000001fb8edfe000 l2: 0000000071804000 l3:
000001fb8edfe000
l4: 000001fb8edfe000 l5: e000000000000f8a l6: a000000000000f8a l7:
c000000000000f8a
i0: 0000000071804000 i1: 0000000071802000 i2: 0000000000000000 i3:
0000000071802000
i4: 80000000000006b0 i5: fffff80005a7000c i6: fffff8000703f361 i7:
000000000053b224
I7: <sbusfb_mmap_helper+0x104/0x160>
Caller[000000000053b224]: sbusfb_mmap_helper+0x104/0x160
Caller[00000000005335b4]: fb_mmap+0x134/0x160
Caller[0000000000478748]: do_mmap_pgoff+0x368/0x720
Caller[00000000004161d8]: sys_mmap+0xf8/0x160
Caller[0000000000406c94]: linux_sparc_syscall32+0x34/0x40
Caller[0000000000286378]: 0x286378
Instruction DUMP: 9210204d 7fff6e02 901221a8 <91d02005> 7ffff76f
b13ee000 81cfe008 01000000 30680003
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-10 22:52 ` J.O. Aho
@ 2005-12-10 23:00 ` David S. Miller
-1 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-10 23:00 UTC (permalink / raw)
To: trizt; +Cc: linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Sat, 10 Dec 2005 23:52:01 +0100 (CET)
> IO[X:6761]:
> remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
> IO[X:6761]:
> remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
That's the problem, we're being called twice over the same
area.
Now we need to figure out why. Please add this patch and give
us the new log output. I'm going to a hockey game so I won't
be able to look at this until later this evening.
Thanks.
--- drivers/video/sbuslib.c.~1~ 2005-11-13 17:58:46.000000000 -0800
+++ drivers/video/sbuslib.c 2005-12-10 15:00:25.000000000 -0800
@@ -52,6 +52,10 @@
off = vma->vm_pgoff << PAGE_SHIFT;
+#if 1
+ printk("sbusfb_mmap: start[%lx] size[%lx] off[%lx]\n",
+ vma->vm_start, size, off);
+#endif
/* To stop the swapper from even considering these pages */
vma->vm_flags |= (VM_IO | VM_RESERVED);
@@ -69,12 +73,19 @@
map_offset = (physbase + map[i].poff) & POFF_MASK;
break;
}
+#if 1
+ printk("sbusfb_mmap: page[%x] map_size[%lx]\n",
+ page, map_size);
+#endif
if (!map_size){
page += PAGE_SIZE;
continue;
}
if (page + map_size > size)
map_size = size - page;
+#if 1
+ printk("sbusfb_mmap: map_size is now %lx\n", map_size);
+#endif
r = io_remap_pfn_range(vma,
vma->vm_start + page,
MK_IOSPACE_PFN(iospace,
@@ -85,6 +96,9 @@
return -EAGAIN;
page += map_size;
}
+#if 1
+ printk("sbusfb_mmap: Done\n");
+#endif
return 0;
}
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-10 23:00 ` David S. Miller
0 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-10 23:00 UTC (permalink / raw)
To: trizt; +Cc: linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Sat, 10 Dec 2005 23:52:01 +0100 (CET)
> IO[X:6761]:
> remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
> IO[X:6761]:
> remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
That's the problem, we're being called twice over the same
area.
Now we need to figure out why. Please add this patch and give
us the new log output. I'm going to a hockey game so I won't
be able to look at this until later this evening.
Thanks.
--- drivers/video/sbuslib.c.~1~ 2005-11-13 17:58:46.000000000 -0800
+++ drivers/video/sbuslib.c 2005-12-10 15:00:25.000000000 -0800
@@ -52,6 +52,10 @@
off = vma->vm_pgoff << PAGE_SHIFT;
+#if 1
+ printk("sbusfb_mmap: start[%lx] size[%lx] off[%lx]\n",
+ vma->vm_start, size, off);
+#endif
/* To stop the swapper from even considering these pages */
vma->vm_flags |= (VM_IO | VM_RESERVED);
@@ -69,12 +73,19 @@
map_offset = (physbase + map[i].poff) & POFF_MASK;
break;
}
+#if 1
+ printk("sbusfb_mmap: page[%x] map_size[%lx]\n",
+ page, map_size);
+#endif
if (!map_size){
page += PAGE_SIZE;
continue;
}
if (page + map_size > size)
map_size = size - page;
+#if 1
+ printk("sbusfb_mmap: map_size is now %lx\n", map_size);
+#endif
r = io_remap_pfn_range(vma,
vma->vm_start + page,
MK_IOSPACE_PFN(iospace,
@@ -85,6 +96,9 @@
return -EAGAIN;
page += map_size;
}
+#if 1
+ printk("sbusfb_mmap: Done\n");
+#endif
return 0;
}
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-10 23:00 ` David S. Miller
@ 2005-12-10 23:22 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-10 23:22 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, sparclinux
On Sat, 10 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Sat, 10 Dec 2005 23:52:01 +0100 (CET)
>
>> IO[X:6761]:
>> remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
>> IO[X:6761]:
>> remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
>
> That's the problem, we're being called twice over the same
> area.
>
> Now we need to figure out why. Please add this patch and give
> us the new log output.
The output got a lot longer now, but that was expected.
> I'm going to a hockey game so I won't be able to look at this until
> later this evening.
I hope you will have a nice day with the hockey.
Here is the whole output (output generated by the two patches and the bug
message too):
sbusfb_mmap: start[70400000] size[1010000] off[5000000]
sbusfb_mmap: page[0] map_size[0]
sbusfb_mmap: page[10000] map_size[0]
sbusfb_mmap: page[20000] map_size[0]
sbusfb_mmap: page[30000] map_size[0]
sbusfb_mmap: page[40000] map_size[0]
sbusfb_mmap: page[50000] map_size[0]
sbusfb_mmap: page[60000] map_size[0]
sbusfb_mmap: page[70000] map_size[0]
sbusfb_mmap: page[80000] map_size[0]
sbusfb_mmap: page[90000] map_size[0]
sbusfb_mmap: page[a0000] map_size[0]
sbusfb_mmap: page[b0000] map_size[0]
sbusfb_mmap: page[c0000] map_size[0]
sbusfb_mmap: page[d0000] map_size[0]
sbusfb_mmap: page[e0000] map_size[0]
sbusfb_mmap: page[f0000] map_size[0]
sbusfb_mmap: page[100000] map_size[0]
sbusfb_mmap: page[110000] map_size[0]
sbusfb_mmap: page[120000] map_size[0]
sbusfb_mmap: page[130000] map_size[0]
sbusfb_mmap: page[140000] map_size[0]
sbusfb_mmap: page[150000] map_size[0]
sbusfb_mmap: page[160000] map_size[0]
sbusfb_mmap: page[170000] map_size[0]
sbusfb_mmap: page[180000] map_size[0]
sbusfb_mmap: page[190000] map_size[0]
sbusfb_mmap: page[1a0000] map_size[0]
sbusfb_mmap: page[1b0000] map_size[0]
sbusfb_mmap: page[1c0000] map_size[0]
sbusfb_mmap: page[1d0000] map_size[0]
sbusfb_mmap: page[1e0000] map_size[0]
sbusfb_mmap: page[1f0000] map_size[0]
sbusfb_mmap: page[200000] map_size[0]
sbusfb_mmap: page[210000] map_size[0]
sbusfb_mmap: page[220000] map_size[0]
sbusfb_mmap: page[230000] map_size[0]
sbusfb_mmap: page[240000] map_size[0]
sbusfb_mmap: page[250000] map_size[0]
sbusfb_mmap: page[260000] map_size[0]
sbusfb_mmap: page[270000] map_size[0]
sbusfb_mmap: page[280000] map_size[0]
sbusfb_mmap: page[290000] map_size[0]
sbusfb_mmap: page[2a0000] map_size[0]
sbusfb_mmap: page[2b0000] map_size[0]
sbusfb_mmap: page[2c0000] map_size[0]
sbusfb_mmap: page[2d0000] map_size[0]
sbusfb_mmap: page[2e0000] map_size[0]
sbusfb_mmap: page[2f0000] map_size[0]
sbusfb_mmap: page[300000] map_size[0]
sbusfb_mmap: page[310000] map_size[0]
sbusfb_mmap: page[320000] map_size[0]
sbusfb_mmap: page[330000] map_size[0]
sbusfb_mmap: page[340000] map_size[0]
sbusfb_mmap: page[350000] map_size[0]
sbusfb_mmap: page[360000] map_size[0]
sbusfb_mmap: page[370000] map_size[0]
sbusfb_mmap: page[380000] map_size[0]
sbusfb_mmap: page[390000] map_size[0]
sbusfb_mmap: page[3a0000] map_size[0]
sbusfb_mmap: page[3b0000] map_size[0]
sbusfb_mmap: page[3c0000] map_size[0]
sbusfb_mmap: page[3d0000] map_size[0]
sbusfb_mmap: page[3e0000] map_size[0]
sbusfb_mmap: page[3f0000] map_size[0]
sbusfb_mmap: page[400000] map_size[0]
sbusfb_mmap: page[410000] map_size[0]
sbusfb_mmap: page[420000] map_size[0]
sbusfb_mmap: page[430000] map_size[0]
sbusfb_mmap: page[440000] map_size[0]
sbusfb_mmap: page[450000] map_size[0]
sbusfb_mmap: page[460000] map_size[0]
sbusfb_mmap: page[470000] map_size[0]
sbusfb_mmap: page[480000] map_size[0]
sbusfb_mmap: page[490000] map_size[0]
sbusfb_mmap: page[4a0000] map_size[0]
sbusfb_mmap: page[4b0000] map_size[0]
sbusfb_mmap: page[4c0000] map_size[0]
sbusfb_mmap: page[4d0000] map_size[0]
sbusfb_mmap: page[4e0000] map_size[0]
sbusfb_mmap: page[4f0000] map_size[0]
sbusfb_mmap: page[500000] map_size[0]
sbusfb_mmap: page[510000] map_size[0]
sbusfb_mmap: page[520000] map_size[0]
sbusfb_mmap: page[530000] map_size[0]
sbusfb_mmap: page[540000] map_size[0]
sbusfb_mmap: page[550000] map_size[0]
sbusfb_mmap: page[560000] map_size[0]
sbusfb_mmap: page[570000] map_size[0]
sbusfb_mmap: page[580000] map_size[0]
sbusfb_mmap: page[590000] map_size[0]
sbusfb_mmap: page[5a0000] map_size[0]
sbusfb_mmap: page[5b0000] map_size[0]
sbusfb_mmap: page[5c0000] map_size[0]
sbusfb_mmap: page[5d0000] map_size[0]
sbusfb_mmap: page[5e0000] map_size[0]
sbusfb_mmap: page[5f0000] map_size[0]
sbusfb_mmap: page[600000] map_size[0]
sbusfb_mmap: page[610000] map_size[0]
sbusfb_mmap: page[620000] map_size[0]
sbusfb_mmap: page[630000] map_size[0]
sbusfb_mmap: page[640000] map_size[0]
sbusfb_mmap: page[650000] map_size[0]
sbusfb_mmap: page[660000] map_size[0]
sbusfb_mmap: page[670000] map_size[0]
sbusfb_mmap: page[680000] map_size[0]
sbusfb_mmap: page[690000] map_size[0]
sbusfb_mmap: page[6a0000] map_size[0]
sbusfb_mmap: page[6b0000] map_size[0]
sbusfb_mmap: page[6c0000] map_size[0]
sbusfb_mmap: page[6d0000] map_size[0]
sbusfb_mmap: page[6e0000] map_size[0]
sbusfb_mmap: page[6f0000] map_size[0]
sbusfb_mmap: page[700000] map_size[0]
sbusfb_mmap: page[710000] map_size[0]
sbusfb_mmap: page[720000] map_size[0]
sbusfb_mmap: page[730000] map_size[0]
sbusfb_mmap: page[740000] map_size[0]
sbusfb_mmap: page[750000] map_size[0]
sbusfb_mmap: page[760000] map_size[0]
sbusfb_mmap: page[770000] map_size[0]
sbusfb_mmap: page[780000] map_size[0]
sbusfb_mmap: page[790000] map_size[0]
sbusfb_mmap: page[7a0000] map_size[0]
sbusfb_mmap: page[7b0000] map_size[0]
sbusfb_mmap: page[7c0000] map_size[0]
sbusfb_mmap: page[7d0000] map_size[0]
sbusfb_mmap: page[7e0000] map_size[0]
sbusfb_mmap: page[7f0000] map_size[0]
sbusfb_mmap: page[800000] map_size[0]
sbusfb_mmap: page[810000] map_size[0]
sbusfb_mmap: page[820000] map_size[0]
sbusfb_mmap: page[830000] map_size[0]
sbusfb_mmap: page[840000] map_size[0]
sbusfb_mmap: page[850000] map_size[0]
sbusfb_mmap: page[860000] map_size[0]
sbusfb_mmap: page[870000] map_size[0]
sbusfb_mmap: page[880000] map_size[0]
sbusfb_mmap: page[890000] map_size[0]
sbusfb_mmap: page[8a0000] map_size[0]
sbusfb_mmap: page[8b0000] map_size[0]
sbusfb_mmap: page[8c0000] map_size[0]
sbusfb_mmap: page[8d0000] map_size[0]
sbusfb_mmap: page[8e0000] map_size[0]
sbusfb_mmap: page[8f0000] map_size[0]
sbusfb_mmap: page[900000] map_size[0]
sbusfb_mmap: page[910000] map_size[0]
sbusfb_mmap: page[920000] map_size[0]
sbusfb_mmap: page[930000] map_size[0]
sbusfb_mmap: page[940000] map_size[0]
sbusfb_mmap: page[950000] map_size[0]
sbusfb_mmap: page[960000] map_size[0]
sbusfb_mmap: page[970000] map_size[0]
sbusfb_mmap: page[980000] map_size[0]
sbusfb_mmap: page[990000] map_size[0]
sbusfb_mmap: page[9a0000] map_size[0]
sbusfb_mmap: page[9b0000] map_size[0]
sbusfb_mmap: page[9c0000] map_size[0]
sbusfb_mmap: page[9d0000] map_size[0]
sbusfb_mmap: page[9e0000] map_size[0]
sbusfb_mmap: page[9f0000] map_size[0]
sbusfb_mmap: page[a00000] map_size[0]
sbusfb_mmap: page[a10000] map_size[0]
sbusfb_mmap: page[a20000] map_size[0]
sbusfb_mmap: page[a30000] map_size[0]
sbusfb_mmap: page[a40000] map_size[0]
sbusfb_mmap: page[a50000] map_size[0]
sbusfb_mmap: page[a60000] map_size[0]
sbusfb_mmap: page[a70000] map_size[0]
sbusfb_mmap: page[a80000] map_size[0]
sbusfb_mmap: page[a90000] map_size[0]
sbusfb_mmap: page[aa0000] map_size[0]
sbusfb_mmap: page[ab0000] map_size[0]
sbusfb_mmap: page[ac0000] map_size[0]
sbusfb_mmap: page[ad0000] map_size[0]
sbusfb_mmap: page[ae0000] map_size[0]
sbusfb_mmap: page[af0000] map_size[0]
sbusfb_mmap: page[b00000] map_size[0]
sbusfb_mmap: page[b10000] map_size[0]
sbusfb_mmap: page[b20000] map_size[0]
sbusfb_mmap: page[b30000] map_size[0]
sbusfb_mmap: page[b40000] map_size[0]
sbusfb_mmap: page[b50000] map_size[0]
sbusfb_mmap: page[b60000] map_size[0]
sbusfb_mmap: page[b70000] map_size[0]
sbusfb_mmap: page[b80000] map_size[0]
sbusfb_mmap: page[b90000] map_size[0]
sbusfb_mmap: page[ba0000] map_size[0]
sbusfb_mmap: page[bb0000] map_size[0]
sbusfb_mmap: page[bc0000] map_size[0]
sbusfb_mmap: page[bd0000] map_size[0]
sbusfb_mmap: page[be0000] map_size[0]
sbusfb_mmap: page[bf0000] map_size[0]
sbusfb_mmap: page[c00000] map_size[0]
sbusfb_mmap: page[c10000] map_size[0]
sbusfb_mmap: page[c20000] map_size[0]
sbusfb_mmap: page[c30000] map_size[0]
sbusfb_mmap: page[c40000] map_size[0]
sbusfb_mmap: page[c50000] map_size[0]
sbusfb_mmap: page[c60000] map_size[0]
sbusfb_mmap: page[c70000] map_size[0]
sbusfb_mmap: page[c80000] map_size[0]
sbusfb_mmap: page[c90000] map_size[0]
sbusfb_mmap: page[ca0000] map_size[0]
sbusfb_mmap: page[cb0000] map_size[0]
sbusfb_mmap: page[cc0000] map_size[0]
sbusfb_mmap: page[cd0000] map_size[0]
sbusfb_mmap: page[ce0000] map_size[0]
sbusfb_mmap: page[cf0000] map_size[0]
sbusfb_mmap: page[d00000] map_size[0]
sbusfb_mmap: page[d10000] map_size[0]
sbusfb_mmap: page[d20000] map_size[0]
sbusfb_mmap: page[d30000] map_size[0]
sbusfb_mmap: page[d40000] map_size[0]
sbusfb_mmap: page[d50000] map_size[0]
sbusfb_mmap: page[d60000] map_size[0]
sbusfb_mmap: page[d70000] map_size[0]
sbusfb_mmap: page[d80000] map_size[0]
sbusfb_mmap: page[d90000] map_size[0]
sbusfb_mmap: page[da0000] map_size[0]
sbusfb_mmap: page[db0000] map_size[0]
sbusfb_mmap: page[dc0000] map_size[0]
sbusfb_mmap: page[dd0000] map_size[0]
sbusfb_mmap: page[de0000] map_size[0]
sbusfb_mmap: page[df0000] map_size[0]
sbusfb_mmap: page[e00000] map_size[0]
sbusfb_mmap: page[e10000] map_size[0]
sbusfb_mmap: page[e20000] map_size[0]
sbusfb_mmap: page[e30000] map_size[0]
sbusfb_mmap: page[e40000] map_size[0]
sbusfb_mmap: page[e50000] map_size[0]
sbusfb_mmap: page[e60000] map_size[0]
sbusfb_mmap: page[e70000] map_size[0]
sbusfb_mmap: page[e80000] map_size[0]
sbusfb_mmap: page[e90000] map_size[0]
sbusfb_mmap: page[ea0000] map_size[0]
sbusfb_mmap: page[eb0000] map_size[0]
sbusfb_mmap: page[ec0000] map_size[0]
sbusfb_mmap: page[ed0000] map_size[0]
sbusfb_mmap: page[ee0000] map_size[0]
sbusfb_mmap: page[ef0000] map_size[0]
sbusfb_mmap: page[f00000] map_size[0]
sbusfb_mmap: page[f10000] map_size[0]
sbusfb_mmap: page[f20000] map_size[0]
sbusfb_mmap: page[f30000] map_size[0]
sbusfb_mmap: page[f40000] map_size[0]
sbusfb_mmap: page[f50000] map_size[0]
sbusfb_mmap: page[f60000] map_size[0]
sbusfb_mmap: page[f70000] map_size[0]
sbusfb_mmap: page[f80000] map_size[0]
sbusfb_mmap: page[f90000] map_size[0]
sbusfb_mmap: page[fa0000] map_size[0]
sbusfb_mmap: page[fb0000] map_size[0]
sbusfb_mmap: page[fc0000] map_size[0]
sbusfb_mmap: page[fd0000] map_size[0]
sbusfb_mmap: page[fe0000] map_size[0]
sbusfb_mmap: page[ff0000] map_size[0]
sbusfb_mmap: page[1000000] map_size[0]
sbusfb_mmap: Done
sbusfb_mmap: start[71800000] size[410000] off[4000000]
sbusfb_mmap: page[0] map_size[2000]
sbusfb_mmap: map_size is now 2000
IO[X:6712]:
remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
sbusfb_mmap: page[2000] map_size[2000]
sbusfb_mmap: map_size is now 2000
IO[X:6712]:
remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
kernel BUG at arch/sparc64/mm/generic.c:77!
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
X(6712): Kernel bad sw trap 5 [#1]
TSTATE: 0000000011009603 TPC: 0000000000434da0 TNPC: 0000000000434da4 Y:
00000000 Not tainted
TPC: <io_remap_pfn_range+0x400/0x420>
g0: fffff800024df261 g1: 0000000000669400 g2: 0000000000000001 g3:
00000000000047ff
g4: fffff80001f34fc0 g5: 0000000000000010 g6: fffff800024d0000 g7:
0000000000000000
o0: 000000000000002f o1: 000000000061f1e8 o2: 000000000000004d o3:
0000000011812000
o4: 000001fc00610000 o5: fffff80002578c00 sp: fffff800024df241 ret_pc:
0000000000434d98
RPC: <io_remap_pfn_range+0x3f8/0x420>
l0: 0000000071802000 l1: 000001fb8edfe000 l2: 0000000071804000 l3:
000001fb8edfe000
l4: 000001fb8edfe000 l5: e000000000000f8a l6: a000000000000f8a l7:
c000000000000f8a
i0: 0000000071804000 i1: 0000000071802000 i2: 0000000000000000 i3:
0000000071802000
i4: 80000000000006b0 i5: fffff800010c000c i6: fffff800024df361 i7:
000000000053b270
I7: <sbusfb_mmap_helper+0x150/0x1a0>
Caller[000000000053b270]: sbusfb_mmap_helper+0x150/0x1a0
Caller[00000000005335b4]: fb_mmap+0x134/0x160
Caller[0000000000478748]: do_mmap_pgoff+0x368/0x720
Caller[00000000004161d8]: sys_mmap+0xf8/0x160
Caller[0000000000406c94]: linux_sparc_syscall32+0x34/0x40
Caller[0000000000286378]: 0x286378
Instruction DUMP: 9210204d 7fff6e02 901221e8 <91d02005> 7ffff76f
b13ee000 81cfe008 01000000 30680003
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-10 23:22 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-10 23:22 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, sparclinux
On Sat, 10 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Sat, 10 Dec 2005 23:52:01 +0100 (CET)
>
>> IO[X:6761]:
>> remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
>> IO[X:6761]:
>> remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
>
> That's the problem, we're being called twice over the same
> area.
>
> Now we need to figure out why. Please add this patch and give
> us the new log output.
The output got a lot longer now, but that was expected.
> I'm going to a hockey game so I won't be able to look at this until
> later this evening.
I hope you will have a nice day with the hockey.
Here is the whole output (output generated by the two patches and the bug
message too):
sbusfb_mmap: start[70400000] size[1010000] off[5000000]
sbusfb_mmap: page[0] map_size[0]
sbusfb_mmap: page[10000] map_size[0]
sbusfb_mmap: page[20000] map_size[0]
sbusfb_mmap: page[30000] map_size[0]
sbusfb_mmap: page[40000] map_size[0]
sbusfb_mmap: page[50000] map_size[0]
sbusfb_mmap: page[60000] map_size[0]
sbusfb_mmap: page[70000] map_size[0]
sbusfb_mmap: page[80000] map_size[0]
sbusfb_mmap: page[90000] map_size[0]
sbusfb_mmap: page[a0000] map_size[0]
sbusfb_mmap: page[b0000] map_size[0]
sbusfb_mmap: page[c0000] map_size[0]
sbusfb_mmap: page[d0000] map_size[0]
sbusfb_mmap: page[e0000] map_size[0]
sbusfb_mmap: page[f0000] map_size[0]
sbusfb_mmap: page[100000] map_size[0]
sbusfb_mmap: page[110000] map_size[0]
sbusfb_mmap: page[120000] map_size[0]
sbusfb_mmap: page[130000] map_size[0]
sbusfb_mmap: page[140000] map_size[0]
sbusfb_mmap: page[150000] map_size[0]
sbusfb_mmap: page[160000] map_size[0]
sbusfb_mmap: page[170000] map_size[0]
sbusfb_mmap: page[180000] map_size[0]
sbusfb_mmap: page[190000] map_size[0]
sbusfb_mmap: page[1a0000] map_size[0]
sbusfb_mmap: page[1b0000] map_size[0]
sbusfb_mmap: page[1c0000] map_size[0]
sbusfb_mmap: page[1d0000] map_size[0]
sbusfb_mmap: page[1e0000] map_size[0]
sbusfb_mmap: page[1f0000] map_size[0]
sbusfb_mmap: page[200000] map_size[0]
sbusfb_mmap: page[210000] map_size[0]
sbusfb_mmap: page[220000] map_size[0]
sbusfb_mmap: page[230000] map_size[0]
sbusfb_mmap: page[240000] map_size[0]
sbusfb_mmap: page[250000] map_size[0]
sbusfb_mmap: page[260000] map_size[0]
sbusfb_mmap: page[270000] map_size[0]
sbusfb_mmap: page[280000] map_size[0]
sbusfb_mmap: page[290000] map_size[0]
sbusfb_mmap: page[2a0000] map_size[0]
sbusfb_mmap: page[2b0000] map_size[0]
sbusfb_mmap: page[2c0000] map_size[0]
sbusfb_mmap: page[2d0000] map_size[0]
sbusfb_mmap: page[2e0000] map_size[0]
sbusfb_mmap: page[2f0000] map_size[0]
sbusfb_mmap: page[300000] map_size[0]
sbusfb_mmap: page[310000] map_size[0]
sbusfb_mmap: page[320000] map_size[0]
sbusfb_mmap: page[330000] map_size[0]
sbusfb_mmap: page[340000] map_size[0]
sbusfb_mmap: page[350000] map_size[0]
sbusfb_mmap: page[360000] map_size[0]
sbusfb_mmap: page[370000] map_size[0]
sbusfb_mmap: page[380000] map_size[0]
sbusfb_mmap: page[390000] map_size[0]
sbusfb_mmap: page[3a0000] map_size[0]
sbusfb_mmap: page[3b0000] map_size[0]
sbusfb_mmap: page[3c0000] map_size[0]
sbusfb_mmap: page[3d0000] map_size[0]
sbusfb_mmap: page[3e0000] map_size[0]
sbusfb_mmap: page[3f0000] map_size[0]
sbusfb_mmap: page[400000] map_size[0]
sbusfb_mmap: page[410000] map_size[0]
sbusfb_mmap: page[420000] map_size[0]
sbusfb_mmap: page[430000] map_size[0]
sbusfb_mmap: page[440000] map_size[0]
sbusfb_mmap: page[450000] map_size[0]
sbusfb_mmap: page[460000] map_size[0]
sbusfb_mmap: page[470000] map_size[0]
sbusfb_mmap: page[480000] map_size[0]
sbusfb_mmap: page[490000] map_size[0]
sbusfb_mmap: page[4a0000] map_size[0]
sbusfb_mmap: page[4b0000] map_size[0]
sbusfb_mmap: page[4c0000] map_size[0]
sbusfb_mmap: page[4d0000] map_size[0]
sbusfb_mmap: page[4e0000] map_size[0]
sbusfb_mmap: page[4f0000] map_size[0]
sbusfb_mmap: page[500000] map_size[0]
sbusfb_mmap: page[510000] map_size[0]
sbusfb_mmap: page[520000] map_size[0]
sbusfb_mmap: page[530000] map_size[0]
sbusfb_mmap: page[540000] map_size[0]
sbusfb_mmap: page[550000] map_size[0]
sbusfb_mmap: page[560000] map_size[0]
sbusfb_mmap: page[570000] map_size[0]
sbusfb_mmap: page[580000] map_size[0]
sbusfb_mmap: page[590000] map_size[0]
sbusfb_mmap: page[5a0000] map_size[0]
sbusfb_mmap: page[5b0000] map_size[0]
sbusfb_mmap: page[5c0000] map_size[0]
sbusfb_mmap: page[5d0000] map_size[0]
sbusfb_mmap: page[5e0000] map_size[0]
sbusfb_mmap: page[5f0000] map_size[0]
sbusfb_mmap: page[600000] map_size[0]
sbusfb_mmap: page[610000] map_size[0]
sbusfb_mmap: page[620000] map_size[0]
sbusfb_mmap: page[630000] map_size[0]
sbusfb_mmap: page[640000] map_size[0]
sbusfb_mmap: page[650000] map_size[0]
sbusfb_mmap: page[660000] map_size[0]
sbusfb_mmap: page[670000] map_size[0]
sbusfb_mmap: page[680000] map_size[0]
sbusfb_mmap: page[690000] map_size[0]
sbusfb_mmap: page[6a0000] map_size[0]
sbusfb_mmap: page[6b0000] map_size[0]
sbusfb_mmap: page[6c0000] map_size[0]
sbusfb_mmap: page[6d0000] map_size[0]
sbusfb_mmap: page[6e0000] map_size[0]
sbusfb_mmap: page[6f0000] map_size[0]
sbusfb_mmap: page[700000] map_size[0]
sbusfb_mmap: page[710000] map_size[0]
sbusfb_mmap: page[720000] map_size[0]
sbusfb_mmap: page[730000] map_size[0]
sbusfb_mmap: page[740000] map_size[0]
sbusfb_mmap: page[750000] map_size[0]
sbusfb_mmap: page[760000] map_size[0]
sbusfb_mmap: page[770000] map_size[0]
sbusfb_mmap: page[780000] map_size[0]
sbusfb_mmap: page[790000] map_size[0]
sbusfb_mmap: page[7a0000] map_size[0]
sbusfb_mmap: page[7b0000] map_size[0]
sbusfb_mmap: page[7c0000] map_size[0]
sbusfb_mmap: page[7d0000] map_size[0]
sbusfb_mmap: page[7e0000] map_size[0]
sbusfb_mmap: page[7f0000] map_size[0]
sbusfb_mmap: page[800000] map_size[0]
sbusfb_mmap: page[810000] map_size[0]
sbusfb_mmap: page[820000] map_size[0]
sbusfb_mmap: page[830000] map_size[0]
sbusfb_mmap: page[840000] map_size[0]
sbusfb_mmap: page[850000] map_size[0]
sbusfb_mmap: page[860000] map_size[0]
sbusfb_mmap: page[870000] map_size[0]
sbusfb_mmap: page[880000] map_size[0]
sbusfb_mmap: page[890000] map_size[0]
sbusfb_mmap: page[8a0000] map_size[0]
sbusfb_mmap: page[8b0000] map_size[0]
sbusfb_mmap: page[8c0000] map_size[0]
sbusfb_mmap: page[8d0000] map_size[0]
sbusfb_mmap: page[8e0000] map_size[0]
sbusfb_mmap: page[8f0000] map_size[0]
sbusfb_mmap: page[900000] map_size[0]
sbusfb_mmap: page[910000] map_size[0]
sbusfb_mmap: page[920000] map_size[0]
sbusfb_mmap: page[930000] map_size[0]
sbusfb_mmap: page[940000] map_size[0]
sbusfb_mmap: page[950000] map_size[0]
sbusfb_mmap: page[960000] map_size[0]
sbusfb_mmap: page[970000] map_size[0]
sbusfb_mmap: page[980000] map_size[0]
sbusfb_mmap: page[990000] map_size[0]
sbusfb_mmap: page[9a0000] map_size[0]
sbusfb_mmap: page[9b0000] map_size[0]
sbusfb_mmap: page[9c0000] map_size[0]
sbusfb_mmap: page[9d0000] map_size[0]
sbusfb_mmap: page[9e0000] map_size[0]
sbusfb_mmap: page[9f0000] map_size[0]
sbusfb_mmap: page[a00000] map_size[0]
sbusfb_mmap: page[a10000] map_size[0]
sbusfb_mmap: page[a20000] map_size[0]
sbusfb_mmap: page[a30000] map_size[0]
sbusfb_mmap: page[a40000] map_size[0]
sbusfb_mmap: page[a50000] map_size[0]
sbusfb_mmap: page[a60000] map_size[0]
sbusfb_mmap: page[a70000] map_size[0]
sbusfb_mmap: page[a80000] map_size[0]
sbusfb_mmap: page[a90000] map_size[0]
sbusfb_mmap: page[aa0000] map_size[0]
sbusfb_mmap: page[ab0000] map_size[0]
sbusfb_mmap: page[ac0000] map_size[0]
sbusfb_mmap: page[ad0000] map_size[0]
sbusfb_mmap: page[ae0000] map_size[0]
sbusfb_mmap: page[af0000] map_size[0]
sbusfb_mmap: page[b00000] map_size[0]
sbusfb_mmap: page[b10000] map_size[0]
sbusfb_mmap: page[b20000] map_size[0]
sbusfb_mmap: page[b30000] map_size[0]
sbusfb_mmap: page[b40000] map_size[0]
sbusfb_mmap: page[b50000] map_size[0]
sbusfb_mmap: page[b60000] map_size[0]
sbusfb_mmap: page[b70000] map_size[0]
sbusfb_mmap: page[b80000] map_size[0]
sbusfb_mmap: page[b90000] map_size[0]
sbusfb_mmap: page[ba0000] map_size[0]
sbusfb_mmap: page[bb0000] map_size[0]
sbusfb_mmap: page[bc0000] map_size[0]
sbusfb_mmap: page[bd0000] map_size[0]
sbusfb_mmap: page[be0000] map_size[0]
sbusfb_mmap: page[bf0000] map_size[0]
sbusfb_mmap: page[c00000] map_size[0]
sbusfb_mmap: page[c10000] map_size[0]
sbusfb_mmap: page[c20000] map_size[0]
sbusfb_mmap: page[c30000] map_size[0]
sbusfb_mmap: page[c40000] map_size[0]
sbusfb_mmap: page[c50000] map_size[0]
sbusfb_mmap: page[c60000] map_size[0]
sbusfb_mmap: page[c70000] map_size[0]
sbusfb_mmap: page[c80000] map_size[0]
sbusfb_mmap: page[c90000] map_size[0]
sbusfb_mmap: page[ca0000] map_size[0]
sbusfb_mmap: page[cb0000] map_size[0]
sbusfb_mmap: page[cc0000] map_size[0]
sbusfb_mmap: page[cd0000] map_size[0]
sbusfb_mmap: page[ce0000] map_size[0]
sbusfb_mmap: page[cf0000] map_size[0]
sbusfb_mmap: page[d00000] map_size[0]
sbusfb_mmap: page[d10000] map_size[0]
sbusfb_mmap: page[d20000] map_size[0]
sbusfb_mmap: page[d30000] map_size[0]
sbusfb_mmap: page[d40000] map_size[0]
sbusfb_mmap: page[d50000] map_size[0]
sbusfb_mmap: page[d60000] map_size[0]
sbusfb_mmap: page[d70000] map_size[0]
sbusfb_mmap: page[d80000] map_size[0]
sbusfb_mmap: page[d90000] map_size[0]
sbusfb_mmap: page[da0000] map_size[0]
sbusfb_mmap: page[db0000] map_size[0]
sbusfb_mmap: page[dc0000] map_size[0]
sbusfb_mmap: page[dd0000] map_size[0]
sbusfb_mmap: page[de0000] map_size[0]
sbusfb_mmap: page[df0000] map_size[0]
sbusfb_mmap: page[e00000] map_size[0]
sbusfb_mmap: page[e10000] map_size[0]
sbusfb_mmap: page[e20000] map_size[0]
sbusfb_mmap: page[e30000] map_size[0]
sbusfb_mmap: page[e40000] map_size[0]
sbusfb_mmap: page[e50000] map_size[0]
sbusfb_mmap: page[e60000] map_size[0]
sbusfb_mmap: page[e70000] map_size[0]
sbusfb_mmap: page[e80000] map_size[0]
sbusfb_mmap: page[e90000] map_size[0]
sbusfb_mmap: page[ea0000] map_size[0]
sbusfb_mmap: page[eb0000] map_size[0]
sbusfb_mmap: page[ec0000] map_size[0]
sbusfb_mmap: page[ed0000] map_size[0]
sbusfb_mmap: page[ee0000] map_size[0]
sbusfb_mmap: page[ef0000] map_size[0]
sbusfb_mmap: page[f00000] map_size[0]
sbusfb_mmap: page[f10000] map_size[0]
sbusfb_mmap: page[f20000] map_size[0]
sbusfb_mmap: page[f30000] map_size[0]
sbusfb_mmap: page[f40000] map_size[0]
sbusfb_mmap: page[f50000] map_size[0]
sbusfb_mmap: page[f60000] map_size[0]
sbusfb_mmap: page[f70000] map_size[0]
sbusfb_mmap: page[f80000] map_size[0]
sbusfb_mmap: page[f90000] map_size[0]
sbusfb_mmap: page[fa0000] map_size[0]
sbusfb_mmap: page[fb0000] map_size[0]
sbusfb_mmap: page[fc0000] map_size[0]
sbusfb_mmap: page[fd0000] map_size[0]
sbusfb_mmap: page[fe0000] map_size[0]
sbusfb_mmap: page[ff0000] map_size[0]
sbusfb_mmap: page[1000000] map_size[0]
sbusfb_mmap: Done
sbusfb_mmap: start[71800000] size[410000] off[4000000]
sbusfb_mmap: page[0] map_size[2000]
sbusfb_mmap: map_size is now 2000
IO[X:6712]:
remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
sbusfb_mmap: page[2000] map_size[2000]
sbusfb_mmap: map_size is now 2000
IO[X:6712]:
remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
kernel BUG at arch/sparc64/mm/generic.c:77!
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
X(6712): Kernel bad sw trap 5 [#1]
TSTATE: 0000000011009603 TPC: 0000000000434da0 TNPC: 0000000000434da4 Y:
00000000 Not tainted
TPC: <io_remap_pfn_range+0x400/0x420>
g0: fffff800024df261 g1: 0000000000669400 g2: 0000000000000001 g3:
00000000000047ff
g4: fffff80001f34fc0 g5: 0000000000000010 g6: fffff800024d0000 g7:
0000000000000000
o0: 000000000000002f o1: 000000000061f1e8 o2: 000000000000004d o3:
0000000011812000
o4: 000001fc00610000 o5: fffff80002578c00 sp: fffff800024df241 ret_pc:
0000000000434d98
RPC: <io_remap_pfn_range+0x3f8/0x420>
l0: 0000000071802000 l1: 000001fb8edfe000 l2: 0000000071804000 l3:
000001fb8edfe000
l4: 000001fb8edfe000 l5: e000000000000f8a l6: a000000000000f8a l7:
c000000000000f8a
i0: 0000000071804000 i1: 0000000071802000 i2: 0000000000000000 i3:
0000000071802000
i4: 80000000000006b0 i5: fffff800010c000c i6: fffff800024df361 i7:
000000000053b270
I7: <sbusfb_mmap_helper+0x150/0x1a0>
Caller[000000000053b270]: sbusfb_mmap_helper+0x150/0x1a0
Caller[00000000005335b4]: fb_mmap+0x134/0x160
Caller[0000000000478748]: do_mmap_pgoff+0x368/0x720
Caller[00000000004161d8]: sys_mmap+0xf8/0x160
Caller[0000000000406c94]: linux_sparc_syscall32+0x34/0x40
Caller[0000000000286378]: 0x286378
Instruction DUMP: 9210204d 7fff6e02 901221e8 <91d02005> 7ffff76f
b13ee000 81cfe008 01000000 30680003
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-10 23:22 ` J.O. Aho
@ 2005-12-12 5:07 ` David S. Miller
-1 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-12 5:07 UTC (permalink / raw)
To: trizt; +Cc: linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Sun, 11 Dec 2005 00:22:22 +0100 (CET)
> sbusfb_mmap: start[71800000] size[410000] off[4000000]
> sbusfb_mmap: page[0] map_size[2000]
> sbusfb_mmap: map_size is now 2000
> IO[X:6712]:
> remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
> sbusfb_mmap: page[2000] map_size[2000]
> sbusfb_mmap: map_size is now 2000
> IO[X:6712]:
> remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
This is the trace we needed.
That last line is impossible, the debugging of the last 3 lines shows
that:
1) "page" is equal to 0x2000
2) "map_size" is equal to 0x2000
Furthermore, the first line shows that:
3) "vma->vm_start" is 0x71800000
The io_remap_pfn_range() call in drivers/video/sbuslib.c is:
r = io_remap_pfn_range(vma,
vma->vm_start + page,
MK_IOSPACE_PFN(iospace,
map_offset >> PAGE_SHIFT),
map_size,
vma->vm_page_prot);
This means, it passes in "vma->vm_start + page" in as the start
address.
Yet the last line, printed by the tracing code in io_remap_pfn_range()
is getting 0x71800000, when it should be 0x71802000.
I strongly believe your kernel is being miscompiled by whatever
gcc is being used to build your kernels.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-12 5:07 ` David S. Miller
0 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-12 5:07 UTC (permalink / raw)
To: trizt; +Cc: linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Sun, 11 Dec 2005 00:22:22 +0100 (CET)
> sbusfb_mmap: start[71800000] size[410000] off[4000000]
> sbusfb_mmap: page[0] map_size[2000]
> sbusfb_mmap: map_size is now 2000
> IO[X:6712]:
> remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
> sbusfb_mmap: page[2000] map_size[2000]
> sbusfb_mmap: map_size is now 2000
> IO[X:6712]:
> remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
This is the trace we needed.
That last line is impossible, the debugging of the last 3 lines shows
that:
1) "page" is equal to 0x2000
2) "map_size" is equal to 0x2000
Furthermore, the first line shows that:
3) "vma->vm_start" is 0x71800000
The io_remap_pfn_range() call in drivers/video/sbuslib.c is:
r = io_remap_pfn_range(vma,
vma->vm_start + page,
MK_IOSPACE_PFN(iospace,
map_offset >> PAGE_SHIFT),
map_size,
vma->vm_page_prot);
This means, it passes in "vma->vm_start + page" in as the start
address.
Yet the last line, printed by the tracing code in io_remap_pfn_range()
is getting 0x71800000, when it should be 0x71802000.
I strongly believe your kernel is being miscompiled by whatever
gcc is being used to build your kernels.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-12 5:07 ` David S. Miller
@ 2005-12-12 8:26 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-12 8:26 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, sparclinux
On Sun, 11 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
>> sbusfb_mmap: start[71800000] size[410000] off[4000000]
>> sbusfb_mmap: page[0] map_size[2000]
>> sbusfb_mmap: map_size is now 2000
>> IO[X:6712]:
>> remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
>> sbusfb_mmap: page[2000] map_size[2000]
>> sbusfb_mmap: map_size is now 2000
>> IO[X:6712]:
>> remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
>
> This means, it passes in "vma->vm_start + page" in as the start
> address.
>
> Yet the last line, printed by the tracing code in io_remap_pfn_range()
> is getting 0x71800000, when it should be 0x71802000.
>
> I strongly believe your kernel is being miscompiled by whatever
> gcc is being used to build your kernels.
Okey, good that there is something I can try and see. I'll see what a
rebuild does of the gcc 64bit and have as basic CFLAGS as possible doing
this and rebuild the kernel and see what happens, if not, I guess I'll
bugger the Gentoo Sparc guys again.
Thanks for the help.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-12 8:26 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-12 8:26 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, sparclinux
On Sun, 11 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
>> sbusfb_mmap: start[71800000] size[410000] off[4000000]
>> sbusfb_mmap: page[0] map_size[2000]
>> sbusfb_mmap: map_size is now 2000
>> IO[X:6712]:
>> remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
>> sbusfb_mmap: page[2000] map_size[2000]
>> sbusfb_mmap: map_size is now 2000
>> IO[X:6712]:
>> remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
>
> This means, it passes in "vma->vm_start + page" in as the start
> address.
>
> Yet the last line, printed by the tracing code in io_remap_pfn_range()
> is getting 0x71800000, when it should be 0x71802000.
>
> I strongly believe your kernel is being miscompiled by whatever
> gcc is being used to build your kernels.
Okey, good that there is something I can try and see. I'll see what a
rebuild does of the gcc 64bit and have as basic CFLAGS as possible doing
this and rebuild the kernel and see what happens, if not, I guess I'll
bugger the Gentoo Sparc guys again.
Thanks for the help.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-12 5:07 ` David S. Miller
@ 2005-12-12 16:28 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-12 16:28 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, sparclinux
On Sun, 11 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Sun, 11 Dec 2005 00:22:22 +0100 (CET)
>
>> sbusfb_mmap: start[71800000] size[410000] off[4000000]
>> sbusfb_mmap: page[0] map_size[2000]
>> sbusfb_mmap: map_size is now 2000
>> IO[X:6712]:
>> remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
>> sbusfb_mmap: page[2000] map_size[2000]
>> sbusfb_mmap: map_size is now 2000
>> IO[X:6712]:
>> remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
>
> This is the trace we needed.
>
> I strongly believe your kernel is being miscompiled by whatever
> gcc is being used to build your kernels.
Now I have tested all the gcc-sparc64 thats in Gentoo, 3.3.5, 3.3.6 and
3.4.4. The results on kernels are the same, I get that crash/bug when
starting X11.
Would love to know what gcc you do use for the 64bit kernel, to see if I
can't test that one on my machine too.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-12 16:28 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-12 16:28 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, sparclinux
On Sun, 11 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Sun, 11 Dec 2005 00:22:22 +0100 (CET)
>
>> sbusfb_mmap: start[71800000] size[410000] off[4000000]
>> sbusfb_mmap: page[0] map_size[2000]
>> sbusfb_mmap: map_size is now 2000
>> IO[X:6712]:
>> remap_pfn_range(s[71800000]e[71c10000],f[71800000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
>> sbusfb_mmap: page[2000] map_size[2000]
>> sbusfb_mmap: map_size is now 2000
>> IO[X:6712]:
>> remap_pfn_range(s[71800000]e[71c10000],f[71802000],pfn[1fc0060],sz[2000],prot[80000000000006b0])
>
> This is the trace we needed.
>
> I strongly believe your kernel is being miscompiled by whatever
> gcc is being used to build your kernels.
Now I have tested all the gcc-sparc64 thats in Gentoo, 3.3.5, 3.3.6 and
3.4.4. The results on kernels are the same, I get that crash/bug when
starting X11.
Would love to know what gcc you do use for the 64bit kernel, to see if I
can't test that one on my machine too.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-12 5:07 ` David S. Miller
@ 2006-02-01 13:15 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2006-02-01 13:15 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel maillist, sparclinux
On Sun, 11 Dec 2005, David S. Miller wrote:
> I strongly believe your kernel is being miscompiled by whatever
> gcc is being used to build your kernels.
After a bit posting at comp.sys.sun.hardware I found a person with an
Ultra60 using Creator3D (UPA) too on it, he had a working X. He did run
kernel 2.6.8, so today I did install 2.6.8.1 (vanilla) and tested Xorg
and it worked as well as it does under 2.4.x.
I guess there has been some bad change in the sparc kernel code somewhere
between 2.6.8.1 and 2.6.13. I can say that 2.6.15.1 still "crashes" the
kernel. I don't know if there has been any discussion if it's the small
amount of UPA relatad code that causes the problem or not, but I think
it's plausible that the UPA code has been "damaged" in the later versions
of the kernel.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2006-02-01 13:15 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2006-02-01 13:15 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel maillist, sparclinux
On Sun, 11 Dec 2005, David S. Miller wrote:
> I strongly believe your kernel is being miscompiled by whatever
> gcc is being used to build your kernels.
After a bit posting at comp.sys.sun.hardware I found a person with an
Ultra60 using Creator3D (UPA) too on it, he had a working X. He did run
kernel 2.6.8, so today I did install 2.6.8.1 (vanilla) and tested Xorg
and it worked as well as it does under 2.4.x.
I guess there has been some bad change in the sparc kernel code somewhere
between 2.6.8.1 and 2.6.13. I can say that 2.6.15.1 still "crashes" the
kernel. I don't know if there has been any discussion if it's the small
amount of UPA relatad code that causes the problem or not, but I think
it's plausible that the UPA code has been "damaged" in the later versions
of the kernel.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-06 2:17 ` David S. Miller
` (2 preceding siblings ...)
(?)
@ 2005-12-06 23:39 ` David S. Miller
-1 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-06 23:39 UTC (permalink / raw)
To: sparclinux
From: Christopher Zimmermann <madroach@zakweb.de>
Date: Tue, 6 Dec 2005 16:08:10 +0100
> I'm not sure, if this is the same problem, but since 2.6.15rc3 my X11 broke
> too. I'm working on an Ultra2 Creator. This is what my X11 says on 2.6.15rc5:
>
> Call Trace:
> [0000000000439de4] copy_process+0x8e4/0xe40
This was fixed in 2.6.15rc4 and later.
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-06 2:17 ` David S. Miller
` (3 preceding siblings ...)
(?)
@ 2005-12-07 13:56 ` Christopher Zimmermann
-1 siblings, 0 replies; 61+ messages in thread
From: Christopher Zimmermann @ 2005-12-07 13:56 UTC (permalink / raw)
To: sparclinux
On Tue, Dec 06, 2005 at 03:39:58PM -0800, David S. Miller wrote:
> From: Christopher Zimmermann <madroach@zakweb.de>
> Date: Tue, 6 Dec 2005 16:08:10 +0100
>
> > I'm not sure, if this is the same problem, but since 2.6.15rc3 my X11 broke
> > too. I'm working on an Ultra2 Creator. This is what my X11 says on 2.6.15rc5:
> >
> > Call Trace:
> > [0000000000439de4] copy_process+0x8e4/0xe40
>
> This was fixed in 2.6.15rc4 and later.
As I said, I tested 2.6.15rc5, too. It performs as badly as rc3.
The symptoms are the same J.H. Aho described. But in contrast to J.H.
Aho I can switch back to a vt. By pressing CTRL+c on the vt I started X
on, I can kill the X server. This is the output I get after pressing
CTRL+c:
waiting for X server to shut down Bad pte = 800001fc00600e88, process = Xorg, vm_flags = 184473, vaddr = 7001e000
Call Trace:
[000000000046c390] unmap_region+0x90/0x140
[000000000046cad4] do_munmap+0x174/0x240
[000000000046cbbc] sys_munmap+0x1c/0x40
[0000000000406cd4] linux_sparc_syscall32+0x34/0x40
[00000000003d3ee0] 0x3d3ee0
xinit: unexpected signal 2.
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-06 2:17 ` David S. Miller
` (4 preceding siblings ...)
(?)
@ 2005-12-07 20:49 ` David S. Miller
-1 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-07 20:49 UTC (permalink / raw)
To: sparclinux
From: Christopher Zimmermann <madroach@zakweb.de>
Date: Wed, 7 Dec 2005 14:56:27 +0100
> As I said, I tested 2.6.15rc5, too. It performs as badly as rc3.
> The symptoms are the same J.H. Aho described. But in contrast to J.H.
> Aho I can switch back to a vt. By pressing CTRL+c on the vt I started X
> on, I can kill the X server. This is the output I get after pressing
> CTRL+c:
I stand corrected. This needs some investigation...
I still think J.H. Aho has his Xorg.conf configured to use "fbdev"
for that ATI chip instead of "ati", which is a mistake which on
sparc64 is known to wedge the machine in various ways.
Your case seems different... in the debugging the vm_flags is
0x184473, which works out to:
VM_READ | VM_WRITE |
VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC |
VM_PFNMAP |
VM_IO |
VM_RESERVED |
VM_ACCOUNT
The important bit is VM_PFNMAP, that "Bad pte" kernel message triggers
usually because VM_PFNMAP is set and vma->vm_pgoff does not match what
is in the PTE, but unfortunately the debugging message does not print
the vma->vm_pgoff value.
Let's get that debugging info, shall we? :-) Please add the patch
below, and retrigger, then send the full dmesg.
Thanks a lot.
diff --git a/mm/memory.c b/mm/memory.c
index aa8af0e..8b6a62c 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -342,10 +342,10 @@ static inline void add_mm_rss(struct mm_
void print_bad_pte(struct vm_area_struct *vma, pte_t pte, unsigned long vaddr)
{
printk(KERN_ERR "Bad pte = %08llx, process = %s, "
- "vm_flags = %lx, vaddr = %lx\n",
- (long long)pte_val(pte),
- (vma->vm_mm = current->mm ? current->comm : "???"),
- vma->vm_flags, vaddr);
+ "vm_flags = %lx, vm_pgoff = %lx, vaddr = %lx\n",
+ (long long)pte_val(pte),
+ current->comm,
+ vma->vm_flags, vma->vm_pgoff, vaddr);
dump_stack();
}
^ permalink raw reply related [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-06 2:17 ` David S. Miller
` (5 preceding siblings ...)
(?)
@ 2005-12-07 22:11 ` Christopher Zimmermann
-1 siblings, 0 replies; 61+ messages in thread
From: Christopher Zimmermann @ 2005-12-07 22:11 UTC (permalink / raw)
To: sparclinux
On Wed, Dec 07, 2005 at 12:49:12PM -0800, David S. Miller wrote:
> From: Christopher Zimmermann <madroach@zakweb.de>
> Date: Wed, 7 Dec 2005 14:56:27 +0100
>
> > As I said, I tested 2.6.15rc5, too. It performs as badly as rc3.
> > The symptoms are the same J.H. Aho described. But in contrast to J.H.
> > Aho I can switch back to a vt. By pressing CTRL+c on the vt I started X
> > on, I can kill the X server. This is the output I get after pressing
> > CTRL+c:
>
> I stand corrected. This needs some investigation...
>
> I still think J.H. Aho has his Xorg.conf configured to use "fbdev"
> for that ATI chip instead of "ati", which is a mistake which on
> sparc64 is known to wedge the machine in various ways.
>
> Your case seems different... in the debugging the vm_flags is
> 0x184473, which works out to:
>
> VM_READ | VM_WRITE |
> VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC |
> VM_PFNMAP |
> VM_IO |
> VM_RESERVED |
> VM_ACCOUNT
>
> The important bit is VM_PFNMAP, that "Bad pte" kernel message triggers
> usually because VM_PFNMAP is set and vma->vm_pgoff does not match what
> is in the PTE, but unfortunately the debugging message does not print
> the vma->vm_pgoff value.
>
> Let's get that debugging info, shall we? :-) Please add the patch
> below, and retrigger, then send the full dmesg.
>
> Thanks a lot.
ok I applied the patch. You want the complete dmesg? Here you go:
PROMLIB: Sun IEEE Boot Prom 3.25.0 1999/12/03 11:35
Linux version 2.6.15-rc5 (madroach@sparc) (gcc version 4.0.2 (Debian 4.0.2-2)) #1 SMP Wed Dec 7 22:26:17 CET 2005
ARCH: SUN4U
Ethernet address: 08:00:20:86:08:46
On node 0 totalpages: 130572
DMA zone: 130572 pages, LIFO batch:15
DMA32 zone: 0 pages, LIFO batch:0
Normal zone: 0 pages, LIFO batch:0
HighMem zone: 0 pages, LIFO batch:0
Built 1 zonelists
Kernel command line: root=/dev/sda2
PID hash table entries: 4096 (order: 12, 131072 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 6, 524288 bytes)
Memory: 1034960k available (2168k kernel code, 552k data, 136k init) [fffff80000000000,000000003ff44000]
Calibrating delay loop... 589.82 BogoMIPS (lpj\x1179648)
Mount-cache hash table entries: 512
CPU[0]: Caches D[sz(16384):line_sz(32)] I[sz(16384):line_sz(32)] E[sz(2097152):line_sz(64)]
Calibrating delay loop... 589.82 BogoMIPS (lpj\x1179648)
CPU[1]: Caches D[sz(16384):line_sz(32)] I[sz(16384):line_sz(32)] E[sz(2097152):line_sz(64)]
CPU 1: synchronized TICK with master CPU (last diff -7 cycles,maxerr 542 cycles)
Brought up 2 CPUs
Total of 2 processors activated (1179.64 BogoMIPS).
NET: Registered protocol family 16
SCSI subsystem initialized
SYSIO: UPA portID 1f, at 000001fe00000000
sbus0: Clock 25.0 MHz
dma0: HME DVMA gate array
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
Console: switching to colour frame buffer device 106x46
ffb: FFB at 000001fc00000000 type 8 DAC 10
lp: driver loaded but no devices found
SunZilog: 2 chips.
zs2 at 0x000001fff1000004 (irq = 12,7e8) is a SunZilog
zs3 at 0x000001fff1000000 (irq = 12,7e8) is a SunZilog
ttyS0 at MMIO 0x0 (irq = 7227840) is a SunZilog
ttyS1 at MMIO 0x0 (irq = 7227840) is a SunZilog
parport0: sunbpp at 0x1ffec800000
lp0: using parport0 (interrupt-driven).
loop: loaded (max 8 devices)
NET3 PLIP version 2.4-parport gniibe@mri.co.jp
plip0: Parallel port at 0x1ffec800000, using IRQ 7227648.
sunhme.c:v2.02 8/24/03 David S. Miller (davem@redhat.com)
eth0: HAPPY MEAL (SBUS) 10/100baseT Ethernet 08:00:20:86:08:46
eth1: HAPPY MEAL (SBUS) 10/100baseT Ethernet 08:00:20:86:08:46
esp0: IRQ 4,7e0 SCSI ID 7 Clk 40MHz CCYC%000 CCF=8 TOut 167 NCR53C9XF(espfast)
ESP: Total of 1 ESP hosts found, 1 actually in use.
scsi0 : Sparc ESP366-HME
Vendor: FUJITSU Model: MAJ3182M SUN18G Rev: 0804
Type: Direct-Access ANSI SCSI revision: 02
Vendor: FUJITSU Model: MAJ3182M SUN18G Rev: 0804
Type: Direct-Access ANSI SCSI revision: 02
Vendor: TOSHIBA Model: XM-5401TASUN4XCD Rev: 1036
Type: CD-ROM ANSI SCSI revision: 02
esp0: target 0 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]
SCSI device sda: 35378533 512-byte hdwr sectors (18114 MB)
SCSI device sda: drive cache: write through
SCSI device sda: 35378533 512-byte hdwr sectors (18114 MB)
SCSI device sda: drive cache: write through
sda: sda1 sda2 sda3 sda4 sda5
sd 0:0:0:0: Attached scsi disk sda
esp0: target 1 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]
SCSI device sdb: 35378533 512-byte hdwr sectors (18114 MB)
SCSI device sdb: drive cache: write through
SCSI device sdb: 35378533 512-byte hdwr sectors (18114 MB)
SCSI device sdb: drive cache: write through
sdb: sdb1 sdb2 sdb3 sdb4 sdb5
sd 0:0:1:0: Attached scsi disk sdb
esp0: target 6 asynchronous
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.20
sr 0:0:6:0: Attached scsi CD-ROM sr0
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:1:0: Attached scsi generic sg1 type 0
sr 0:0:6:0: Attached scsi generic sg2 type 5
OBP Flash: RD 1fff0000000[80000] WR 1fff1380000[80000]
rtc_sun_init: Registered Mostek RTC driver.
mice: PS/2 mouse device common for all mice
Advanced Linux Sound Architecture Driver Version 1.0.10rc3 (Mon Nov 07 13:30:21 2005 UTC).
ALSA device list:
#0: Sun CS4231 at 0xff:0xdc000000, irq 13,7e4
NET: Registered protocol family 2
IP route cache hash table entries: 8192 (order: 3, 65536 bytes)
TCP established hash table entries: 32768 (order: 6, 524288 bytes)
TCP bind hash table entries: 32768 (order: 6, 524288 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
input: Sun Type 5 keyboard as /class/input/input0
input: Sun Mouse as /class/input/input1
sermouse.c: Switched to the 5-byte MSC mouse protocol.
Adding 1999856k swap on /dev/sda5. Priority:-1 extents:1 across:1999856k
EXT3 FS on sda2, internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda4, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
eth1: Auto-Negotiation unsuccessful, trying force link mode
eth1: Link has been forced up using internal transceiver at 10Mb/s, Half Duplex.
Bad pte = 1fc00600a88, process = Xorg, vm_flags = 184473, vm_pgoff = fe00300, vaddr = 7001e000
Call Trace:
[0000000000439de4] copy_process+0x8e4/0xe40
[000000000043a380] do_fork+0x40/0x1e0
[0000000000406cd4] linux_sparc_syscall32+0x34/0x40
[00000000701d3bfc] 0x701d3bfc
Bad pte = 1fc00600a88, process = Xorg, vm_flags = 184473, vm_pgoff = fe00300, vaddr = 7001e000
Call Trace:
[000000000046bc00] exit_mmap+0x80/0x140
[0000000000439454] mmput+0x34/0xe0
[0000000000484e6c] flush_old_exec+0x1cc/0x940
[0000000000427f2c] load_elf_binary+0x3cc/0x15c0
[00000000004857b4] search_binary_handler+0x74/0x1a0
[00000000004a3e58] compat_do_execve+0x118/0x1e0
[000000000041f71c] sparc32_execve+0x3c/0xc0
[0000000000406cd4] linux_sparc_syscall32+0x34/0x40
[00000000701d3d68] 0x701d3d68
Bad pte = 1fc00600a88, process = Xorg, vm_flags = 184473, vm_pgoff = fe00300, vaddr = 7001e000
Call Trace:
[0000000000439de4] copy_process+0x8e4/0xe40
[000000000043a380] do_fork+0x40/0x1e0
[0000000000406cd4] linux_sparc_syscall32+0x34/0x40
[00000000701d3bfc] 0x701d3bfc
Bad pte = 1fc00600a88, process = Xorg, vm_flags = 184473, vm_pgoff = fe00300, vaddr = 7001e000
Call Trace:
[000000000046bc00] exit_mmap+0x80/0x140
[0000000000439454] mmput+0x34/0xe0
[0000000000484e6c] flush_old_exec+0x1cc/0x940
[0000000000427f2c] load_elf_binary+0x3cc/0x15c0
[00000000004857b4] search_binary_handler+0x74/0x1a0
[00000000004a3e58] compat_do_execve+0x118/0x1e0
[000000000041f71c] sparc32_execve+0x3c/0xc0
[0000000000406cd4] linux_sparc_syscall32+0x34/0x40
[00000000701d3d68] 0x701d3d68
Bad pte = 1fc00600a88, process = Xorg, vm_flags = 184473, vm_pgoff = fe00300, vaddr = 7001e000
Call Trace:
[0000000000439de4] copy_process+0x8e4/0xe40
[000000000043a380] do_fork+0x40/0x1e0
[0000000000406cd4] linux_sparc_syscall32+0x34/0x40
[00000000701d3bfc] 0x701d3bfc
Bad pte = 1fc00600a88, process = Xorg, vm_flags = 184473, vm_pgoff = fe00300, vaddr = 7001e000
Call Trace:
[000000000046bc00] exit_mmap+0x80/0x140
[0000000000439454] mmput+0x34/0xe0
[0000000000484e6c] flush_old_exec+0x1cc/0x940
[0000000000427f2c] load_elf_binary+0x3cc/0x15c0
[00000000004857b4] search_binary_handler+0x74/0x1a0
[00000000004a3e58] compat_do_execve+0x118/0x1e0
[000000000041f71c] sparc32_execve+0x3c/0xc0
[0000000000406cd4] linux_sparc_syscall32+0x34/0x40
[00000000701d3d68] 0x701d3d68
Bad pte = 800001fc00600e88, process = Xorg, vm_flags = 184473, vm_pgoff = fe00300, vaddr = 7001e000
Call Trace:
[000000000046c370] unmap_region+0x90/0x140
[000000000046cab4] do_munmap+0x174/0x240
[000000000046cb9c] sys_munmap+0x1c/0x40
[0000000000406cd4] linux_sparc_syscall32+0x34/0x40
[00000000003d3ee0] 0x3d3ee0
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-06 2:17 ` David S. Miller
` (6 preceding siblings ...)
(?)
@ 2005-12-07 22:17 ` David S. Miller
-1 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-07 22:17 UTC (permalink / raw)
To: sparclinux
From: Christopher Zimmermann <madroach@zakweb.de>
Date: Wed, 7 Dec 2005 23:11:23 +0100
> Bad pte = 1fc00600a88, process = Xorg, vm_flags = 184473, vm_pgoff = fe00300, vaddr = 7001e000
Thanks for the logs, I'll try to figure it out.
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-12 10:13 ` Mark Fortescue
0 siblings, 0 replies; 61+ messages in thread
From: Mark Fortescue @ 2005-12-12 10:13 UTC (permalink / raw)
To: trizt, David S. Miller; +Cc: linux-kernel, sparclinux
Hi Aho and David,
I have been having a number of sparc-linux kernel build problems with both
gcc-3.4.x and gcc-4.0.x so I would be interested to know what versions of
gcc you are using.
I am cross compiling as my Sparc1's are not up to building large amounts of
code so I may have additional 'bugs' in gcc to muddy the issue.
My gcc-3.4.4 has an issue with '%llu' in printk statements. After changing
the offending printk '%llu' to '%lu' versions I end up with a system that
appears to boot OK.
Providing you are patient, I can compile/run simple programs but there is
something fishy in the memory handling code that results in intermittent
memory faults. This may be a Bash or libc issue but I have not looked into
this. (gcc-3.4.2 and gcc-3.4.3 have the same problem with the %llu printk
statements.)
My gcc-4.0.2 has a different issue. It appears to work find and the
unmodified kernel boots fine. If I try to compile a program on the Sparc1
using a canadian cross compiled gcc/binutils, the linker fails with a Kernel
BUG (see 22 Nov: sun4c problems in radix_tree_gang_lookup_tag in
sparclinux@vger.kernel.org) in the radix-tree code. The same gcc/binutils
works without any kernel BUGs if I use the gcc-3.4.4 compiled kernel but
with everything ell compiled using gcc-4.0.2/binutils 2.16.1.
The affected kernels that I have tested ate 2.6.13.4, 2.6.14.2, 2.6.14.3 and
2.6.15-rc4.
Note: I am using an NFS root as the UFS filing system code is not write safe
on SUNOS 4.1 BSD UFS 4.2 partitions. My efforts to investigate/fix the UFS
filing system issues on my x86 system locked the system up, requiring a
power-up reset so for the moment, I have to live with the NFS root.
Regards
Mark Fortescue.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-12 10:13 ` Mark Fortescue
0 siblings, 0 replies; 61+ messages in thread
From: Mark Fortescue @ 2005-12-12 10:13 UTC (permalink / raw)
To: trizt, David S. Miller; +Cc: linux-kernel, sparclinux
Hi Aho and David,
I have been having a number of sparc-linux kernel build problems with both
gcc-3.4.x and gcc-4.0.x so I would be interested to know what versions of
gcc you are using.
I am cross compiling as my Sparc1's are not up to building large amounts of
code so I may have additional 'bugs' in gcc to muddy the issue.
My gcc-3.4.4 has an issue with '%llu' in printk statements. After changing
the offending printk '%llu' to '%lu' versions I end up with a system that
appears to boot OK.
Providing you are patient, I can compile/run simple programs but there is
something fishy in the memory handling code that results in intermittent
memory faults. This may be a Bash or libc issue but I have not looked into
this. (gcc-3.4.2 and gcc-3.4.3 have the same problem with the %llu printk
statements.)
My gcc-4.0.2 has a different issue. It appears to work find and the
unmodified kernel boots fine. If I try to compile a program on the Sparc1
using a canadian cross compiled gcc/binutils, the linker fails with a Kernel
BUG (see 22 Nov: sun4c problems in radix_tree_gang_lookup_tag in
sparclinux@vger.kernel.org) in the radix-tree code. The same gcc/binutils
works without any kernel BUGs if I use the gcc-3.4.4 compiled kernel but
with everything ell compiled using gcc-4.0.2/binutils 2.16.1.
The affected kernels that I have tested ate 2.6.13.4, 2.6.14.2, 2.6.14.3 and
2.6.15-rc4.
Note: I am using an NFS root as the UFS filing system code is not write safe
on SUNOS 4.1 BSD UFS 4.2 partitions. My efforts to investigate/fix the UFS
filing system issues on my x86 system locked the system up, requiring a
power-up reset so for the moment, I have to live with the NFS root.
Regards
Mark Fortescue.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-12 10:13 ` Mark Fortescue
@ 2005-12-12 10:38 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-12 10:38 UTC (permalink / raw)
To: Mark Fortescue; +Cc: David S. Miller, linux-kernel maillist, sparclinux
On Mon, 12 Dec 2005, Mark Fortescue wrote:
> Hi Aho and David,
>
> I have been having a number of sparc-linux kernel build problems with both
> gcc-3.4.x and gcc-4.0.x so I would be interested to know what versions of
> gcc you are using.
I have been using gcc-3.3.5 (64bits) when building the kernel, today I did
upgrade to gcc-3.3.6 (64bits), but still have the same problem with the
X11.
For build normal system applications and tools I have gcc-3.3.6 (32bit).
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-12 10:38 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-12 10:38 UTC (permalink / raw)
To: Mark Fortescue; +Cc: David S. Miller, linux-kernel maillist, sparclinux
On Mon, 12 Dec 2005, Mark Fortescue wrote:
> Hi Aho and David,
>
> I have been having a number of sparc-linux kernel build problems with both
> gcc-3.4.x and gcc-4.0.x so I would be interested to know what versions of
> gcc you are using.
I have been using gcc-3.3.5 (64bits) when building the kernel, today I did
upgrade to gcc-3.3.6 (64bits), but still have the same problem with the
X11.
For build normal system applications and tools I have gcc-3.3.6 (32bit).
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-12 10:38 ` J.O. Aho
@ 2005-12-12 22:26 ` David S. Miller
-1 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-12 22:26 UTC (permalink / raw)
To: trizt; +Cc: mark, linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Mon, 12 Dec 2005 11:38:32 +0100 (CET)
> I have been using gcc-3.3.5 (64bits) when building the kernel, today
> I did upgrade to gcc-3.3.6 (64bits), but still have the same problem
> with the X11. For build normal system applications and tools I have
> gcc-3.3.6 (32bit).
I use gcc-4.0.2 and gcc-3.4.5 for all of my kernel builds.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-12 22:26 ` David S. Miller
0 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-12 22:26 UTC (permalink / raw)
To: trizt; +Cc: mark, linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Mon, 12 Dec 2005 11:38:32 +0100 (CET)
> I have been using gcc-3.3.5 (64bits) when building the kernel, today
> I did upgrade to gcc-3.3.6 (64bits), but still have the same problem
> with the X11. For build normal system applications and tools I have
> gcc-3.3.6 (32bit).
I use gcc-4.0.2 and gcc-3.4.5 for all of my kernel builds.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-12 22:26 ` David S. Miller
@ 2005-12-18 22:03 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-18 22:03 UTC (permalink / raw)
To: David S. Miller; +Cc: mark, linux-kernel, sparclinux
On Mon, 12 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
Hi Miller,
>> I have been using gcc-3.3.5 (64bits) when building the kernel, today
>> I did upgrade to gcc-3.3.6 (64bits), but still have the same problem
>> with the X11. For build normal system applications and tools I have
>> gcc-3.3.6 (32bit).
> I use gcc-4.0.2 and gcc-3.4.5 for all of my kernel builds.
I have tried gcc-3.4.5, but still I have a process that can lock the
console totally if you run something that looks into the /proc specially
the process after X itself (that one can't be kill). So I wonder if you do
use some patches for gcc or do you use the "vanilla" gcc?
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-18 22:03 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2005-12-18 22:03 UTC (permalink / raw)
To: David S. Miller; +Cc: mark, linux-kernel, sparclinux
On Mon, 12 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
Hi Miller,
>> I have been using gcc-3.3.5 (64bits) when building the kernel, today
>> I did upgrade to gcc-3.3.6 (64bits), but still have the same problem
>> with the X11. For build normal system applications and tools I have
>> gcc-3.3.6 (32bit).
> I use gcc-4.0.2 and gcc-3.4.5 for all of my kernel builds.
I have tried gcc-3.4.5, but still I have a process that can lock the
console totally if you run something that looks into the /proc specially
the process after X itself (that one can't be kill). So I wonder if you do
use some patches for gcc or do you use the "vanilla" gcc?
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-18 22:03 ` J.O. Aho
@ 2005-12-18 23:10 ` David S. Miller
-1 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-18 23:10 UTC (permalink / raw)
To: trizt; +Cc: mark, linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Sun, 18 Dec 2005 23:03:37 +0100 (CET)
> I have tried gcc-3.4.5, but still I have a process that can lock the
> console totally if you run something that looks into the /proc specially
> the process after X itself (that one can't be kill). So I wonder if you do
> use some patches for gcc or do you use the "vanilla" gcc?
I use whatever ships with Debian.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2005-12-18 23:10 ` David S. Miller
0 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2005-12-18 23:10 UTC (permalink / raw)
To: trizt; +Cc: mark, linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Sun, 18 Dec 2005 23:03:37 +0100 (CET)
> I have tried gcc-3.4.5, but still I have a process that can lock the
> console totally if you run something that looks into the /proc specially
> the process after X itself (that one can't be kill). So I wonder if you do
> use some patches for gcc or do you use the "vanilla" gcc?
I use whatever ships with Debian.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2005-12-12 22:26 ` David S. Miller
@ 2006-01-03 14:01 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2006-01-03 14:01 UTC (permalink / raw)
To: David S. Miller; +Cc: mark, linux-kernel maillist, sparclinux
On Mon, 12 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Mon, 12 Dec 2005 11:38:32 +0100 (CET)
>
>> I have been using gcc-3.3.5 (64bits) when building the kernel, today
>> I did upgrade to gcc-3.3.6 (64bits), but still have the same problem
>> with the X11. For build normal system applications and tools I have
>> gcc-3.3.6 (32bit).
>
> I use gcc-4.0.2 and gcc-3.4.5 for all of my kernel builds.
After a small chat at #Gentoo-Sparc at freenode, I thought that I should
just say that the problem with X locking up is still there (15-rc7),
regardless of gcc version, and that the problem has to do with the UPA
code according those who know a lot more than I do.
Thanks again for all help.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2006-01-03 14:01 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2006-01-03 14:01 UTC (permalink / raw)
To: David S. Miller; +Cc: mark, linux-kernel maillist, sparclinux
On Mon, 12 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Mon, 12 Dec 2005 11:38:32 +0100 (CET)
>
>> I have been using gcc-3.3.5 (64bits) when building the kernel, today
>> I did upgrade to gcc-3.3.6 (64bits), but still have the same problem
>> with the X11. For build normal system applications and tools I have
>> gcc-3.3.6 (32bit).
>
> I use gcc-4.0.2 and gcc-3.4.5 for all of my kernel builds.
After a small chat at #Gentoo-Sparc at freenode, I thought that I should
just say that the problem with X locking up is still there (15-rc7),
regardless of gcc version, and that the problem has to do with the UPA
code according those who know a lot more than I do.
Thanks again for all help.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2006-01-03 14:01 ` J.O. Aho
@ 2006-01-03 20:18 ` David S. Miller
-1 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2006-01-03 20:18 UTC (permalink / raw)
To: trizt; +Cc: mark, linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Tue, 3 Jan 2006 15:01:09 +0100 (CET)
> After a small chat at #Gentoo-Sparc at freenode, I thought that I should
> just say that the problem with X locking up is still there (15-rc7),
> regardless of gcc version, and that the problem has to do with the UPA
> code according those who know a lot more than I do.
What "UPA code"?
We don't even have so much as a UPA driver in the Linux kernel.
So it's hard to know what is being spoken about. Maybe something
in the X server?
Perhaps these experts should explain :-)
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2006-01-03 20:18 ` David S. Miller
0 siblings, 0 replies; 61+ messages in thread
From: David S. Miller @ 2006-01-03 20:18 UTC (permalink / raw)
To: trizt; +Cc: mark, linux-kernel, sparclinux
From: "J.O. Aho" <trizt@iname.com>
Date: Tue, 3 Jan 2006 15:01:09 +0100 (CET)
> After a small chat at #Gentoo-Sparc at freenode, I thought that I should
> just say that the problem with X locking up is still there (15-rc7),
> regardless of gcc version, and that the problem has to do with the UPA
> code according those who know a lot more than I do.
What "UPA code"?
We don't even have so much as a UPA driver in the Linux kernel.
So it's hard to know what is being spoken about. Maybe something
in the X server?
Perhaps these experts should explain :-)
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
2006-01-03 20:18 ` David S. Miller
@ 2006-01-03 21:15 ` J.O. Aho
-1 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2006-01-03 21:15 UTC (permalink / raw)
To: David S. Miller; +Cc: mark, linux-kernel, sparclinux
On Tue, 3 Jan 2006, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Tue, 3 Jan 2006 15:01:09 +0100 (CET)
>
>> After a small chat at #Gentoo-Sparc at freenode, I thought that I should
>> just say that the problem with X locking up is still there (15-rc7),
>> regardless of gcc version, and that the problem has to do with the UPA
>> code according those who know a lot more than I do.
>
> What "UPA code"?
>
> We don't even have so much as a UPA driver in the Linux kernel.
> So it's hard to know what is being spoken about. Maybe something
> in the X server?
Nah, the UPA code in the 2.6 kernel, if it had been in the X I hardly can
think that X had worked under 2.4.
> Perhaps these experts should explain :-)
That could be a lot better if they could post a reply and explaiin so you
will know what they really are talking about.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: Sparc: Kernel 2.6.13 to 2.6.15-rc2 bug when running X11
@ 2006-01-03 21:15 ` J.O. Aho
0 siblings, 0 replies; 61+ messages in thread
From: J.O. Aho @ 2006-01-03 21:15 UTC (permalink / raw)
To: David S. Miller; +Cc: mark, linux-kernel, sparclinux
On Tue, 3 Jan 2006, David S. Miller wrote:
> From: "J.O. Aho" <trizt@iname.com>
> Date: Tue, 3 Jan 2006 15:01:09 +0100 (CET)
>
>> After a small chat at #Gentoo-Sparc at freenode, I thought that I should
>> just say that the problem with X locking up is still there (15-rc7),
>> regardless of gcc version, and that the problem has to do with the UPA
>> code according those who know a lot more than I do.
>
> What "UPA code"?
>
> We don't even have so much as a UPA driver in the Linux kernel.
> So it's hard to know what is being spoken about. Maybe something
> in the X server?
Nah, the UPA code in the 2.6 kernel, if it had been in the X I hardly can
think that X had worked under 2.4.
> Perhaps these experts should explain :-)
That could be a lot better if they could post a reply and explaiin so you
will know what they really are talking about.
--
//Aho
------------------------------------------------------------------------
E-Mail: trizt@iname.com URL: http://www.kotiaho.net/~trizt/
ICQ: 13696780
System: Linux System (PPC7447/1000 AMD K7A/2000)
------------------------------------------------------------------------
EU forbids you to send spam without my permission
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 61+ messages in thread