I have been struggling with getting Xorg (6.8.2 and 7.0.0rc1) to work on
a Sun Ultra10 (Sparc IIi), the 6.8.2 works under kernel 2.4.
Tested kernels:
2.6.13
2.6.14.2 (patch to a patch or what?)
2.6.15-rc1
2.6.15-rc2
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.
--- dmesg ---
program X is using MAP_PRIVATE, PROT_WRITE mmap of VM_RESERVED memory,
which is
deprecated. Please report this to [email protected]
kernel BUG at arch/sparc64/mm/generic.c:68!
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
X(6885): Kernel bad sw trap 5 [#1]
TSTATE: 0000000011009603 TPC: 0000000000434d58 TNPC: 0000000000434d5c Y:
0000000
0 Not tainted
TPC: <io_remap_pfn_range+0x3b8/0x3e0>
g0: fffff800068ba200 g1: 0000000000668c00 g2: 0000000000000001 g3:
0000000000001
f22
g4: fffff80004324360 g5: 0000000000000010 g6: fffff80000a90000 g7:
0000000000000
000
o0: 000000000000002f o1: 000000000061e7c8 o2: 0000000000000044 o3:
0000000012c12
000
o4: 800001fc00600f8a o5: 000001fc00610000 sp: fffff80000a9f271 ret_pc:
000000000
0434d50
RPC: <io_remap_pfn_range+0x3b0/0x3e0>
l0: 0000000072c04000 l1: 000001fb8d9fe000 l2: 0000000072c04000 l3:
000001fb8d9fe
000
l4: 000001fb8d9fe000 l5: e000000000000f8a l6: a000000000000f8a l7:
c000000000000
f8a
i0: 0000000072c02000 i1: 0000000072c02000 i2: fffff80005630000 i3:
0000000072c02
000
i4: 80000000000006b0 i5: fffff800019a000c i6: fffff80000a9f361 i7:
000000000053b
7e4
I7: <sbusfb_mmap_helper+0x104/0x160>
Caller[000000000053b7e4]: sbusfb_mmap_helper+0x104/0x160
Caller[0000000000533b74]: fb_mmap+0x134/0x160
Caller[00000000004784a8]: do_mmap_pgoff+0x368/0x780
Caller[00000000004161d8]: sys_mmap+0xf8/0x160
Caller[0000000000406c94]: linux_sparc_syscall32+0x34/0x40
Caller[0000000000286378]: 0x286378
Instruction DUMP: 92102044 7fff6e14 901223c8 <91d02005> 7ffff781
b13e2000 81
cfe008 01000000 30680005
---- eof ----
--
//Aho
------------------------------------------------------------------------
E-Mail: [email protected] 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
------------------------------------------------------------------------
From: "J.O. Aho" <[email protected]>
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 [email protected] (CC'd),
not linux-kernel.
On Mon, 5 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <[email protected]>
> 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 [email protected] (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: [email protected] 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
------------------------------------------------------------------------
From: "J.O. Aho" <[email protected]>
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. :)
On Tue, 6 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <[email protected]>
> 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: [email protected] 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
------------------------------------------------------------------------
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 <[email protected]>
Developer
Ubuntu Linux
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: [email protected] 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
------------------------------------------------------------------------
From: "J.O. Aho" <[email protected]>
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.
On Wed, 7 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <[email protected]>
> 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: [email protected] 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
------------------------------------------------------------------------
From: "J.O. Aho" <[email protected]>
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.
On Wed, 7 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <[email protected]>
> 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: [email protected] 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
------------------------------------------------------------------------
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: [email protected] 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
------------------------------------------------------------------------
From: "J.O. Aho" <[email protected]>
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;
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: [email protected] 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
------------------------------------------------------------------------
From: "J.O. Aho" <[email protected]>
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;
}
On Sat, 10 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <[email protected]>
> 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: [email protected] 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
------------------------------------------------------------------------
From: "J.O. Aho" <[email protected]>
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.
On Sun, 11 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <[email protected]>
>> 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: [email protected] 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
------------------------------------------------------------------------
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
[email protected]) 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.
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: [email protected] 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
------------------------------------------------------------------------
On Sun, 11 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <[email protected]>
> 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: [email protected] 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
------------------------------------------------------------------------
From: "J.O. Aho" <[email protected]>
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.
On Mon, 12 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <[email protected]>
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: [email protected] 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
------------------------------------------------------------------------
From: "J.O. Aho" <[email protected]>
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.
On Mon, 12 Dec 2005, David S. Miller wrote:
> From: "J.O. Aho" <[email protected]>
> 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: [email protected] 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
------------------------------------------------------------------------
From: "J.O. Aho" <[email protected]>
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 :-)
On Tue, 3 Jan 2006, David S. Miller wrote:
> From: "J.O. Aho" <[email protected]>
> 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: [email protected] 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
------------------------------------------------------------------------
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: [email protected] 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
------------------------------------------------------------------------