headers
Michael Lorenz | 2 Jul 2006 20:51
Picon

more gcc4 woes


Hello,

now that tmpfs is fixed I get another - apparently gcc4 related - panic:
trap type 0x7: pc=0xf010ce2c npc=0xf010ce30 psr=44000c6<S,PS>
kernel: alignment fault trap
Stopped in pid 430.3 (gcvs) at netbsd:sa_upcall_userret+0x1e4:
std %g2, [%o0 + 0x18]
db> bt
sa_upcall_userret(0xf3a2c330, 0x1, 0x1c0, 0xf45619d0, 0x0, 0x0) at 
netbsd:upcallret+0x16c
upcallret(0xf3a2c330, 0xd, 0x200, 0x1b0cde70, 0x0, 0xb000) at 
netbsd:proc_trampoline+0x10

got that when gcvs was starting.

have fun
Michael
Permalink | Reply | 5 comments |
headers
Martin Husemann | 3 Jul 2006 00:13
Picon

Re: more gcc4 woes

On Sun, Jul 02, 2006 at 02:51:14PM -0400, Michael Lorenz wrote:
> trap type 0x7: pc=0xf010ce2c npc=0xf010ce30 psr=44000c6<S,PS>
> kernel: alignment fault trap
> Stopped in pid 430.3 (gcvs) at netbsd:sa_upcall_userret+0x1e4:
> std %g2, [%o0 + 0x18]

Can you show %o0 here?

The code is:

        kup = kmem_zalloc(sizeof(*kup), KM_SLEEP);
        kup->uc_stack = sau->sau_stack;

where kup is a ucontext_t and the store to kup->uc_stack is faulting.
I can't see a reason for this to happen unless kmem_zalloc returned
badly aligned memory (the %o0 should show that).

Martin
Permalink | Reply | 4 comments |
headers
Christos Zoulas | 3 Jul 2006 00:27

Re: more gcc4 woes

In article <20060702221317.GE28174 <at> drowsy.duskware.de>,
Martin Husemann  <martin <at> duskware.de> wrote:
>On Sun, Jul 02, 2006 at 02:51:14PM -0400, Michael Lorenz wrote:
>> trap type 0x7: pc=0xf010ce2c npc=0xf010ce30 psr=44000c6<S,PS>
>> kernel: alignment fault trap
>> Stopped in pid 430.3 (gcvs) at netbsd:sa_upcall_userret+0x1e4:
>> std %g2, [%o0 + 0x18]
>
>Can you show %o0 here?
>
>The code is:
>
>        kup = kmem_zalloc(sizeof(*kup), KM_SLEEP);
>        kup->uc_stack = sau->sau_stack;
>
>where kup is a ucontext_t and the store to kup->uc_stack is faulting.
>I can't see a reason for this to happen unless kmem_zalloc returned
>badly aligned memory (the %o0 should show that).

The vmem stuff is a bit borken:

#define   KMEM_QUANTUM_SIZE       sizeof(void *)  /* XXX */

This will not work on the sparc when it tries to split a block.
Maybe KMEM_QUANTUM_SIZE should be defined on a per arch basis.

For now, try:

#ifdef __sparc__
#define   KMEM_QUANTUM_SIZE       sizeof(long long)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael Lorenz | 3 Jul 2006 01:40
Picon

Re: more gcc4 woes


Hello,

On Jul 2, 2006, at 18:27, Christos Zoulas wrote:

> In article <20060702221317.GE28174 <at> drowsy.duskware.de>,
> Martin Husemann  <martin <at> duskware.de> wrote:
>> On Sun, Jul 02, 2006 at 02:51:14PM -0400, Michael Lorenz wrote:
>>> trap type 0x7: pc=0xf010ce2c npc=0xf010ce30 psr=44000c6<S,PS>
>>> kernel: alignment fault trap
>>> Stopped in pid 430.3 (gcvs) at netbsd:sa_upcall_userret+0x1e4:
>>> std %g2, [%o0 + 0x18]
>>
>> Can you show %o0 here?
>>
>> The code is:
>>
>>        kup = kmem_zalloc(sizeof(*kup), KM_SLEEP);
>>        kup->uc_stack = sau->sau_stack;
>>
>> where kup is a ucontext_t and the store to kup->uc_stack is faulting.
>> I can't see a reason for this to happen unless kmem_zalloc returned
>> badly aligned memory (the %o0 should show that).
>
> The vmem stuff is a bit borken:
>
> #define   KMEM_QUANTUM_SIZE       sizeof(void *)  /* XXX */
>
> This will not work on the sparc when it tries to split a block.
> Maybe KMEM_QUANTUM_SIZE should be defined on a per arch basis.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Coleman | 3 Jul 2006 22:01
Picon

JavaStation Espresso

With help from uwe <at> , port-sparc now boots single user on the JavaStation
Espresso.  Minor modifications were needed to the PCI and interrupt mapping
code, as the Espresso is very similar to the (already supported) Krups.
Several devices are not yet supported (e.g. USB and ISA) and there are some
niggles to be sorted out (e.g. `eeprom` crashes the kernel).

The dmesg below is an Espresso with a 501-2741 SunSwift card installed in
PCI 2 (the "not configured" ppb0).

J

  - - 8< - - - - - - - - - - - - - Cut here - - - - - - - - - - - - - >8 - -
JavaStation
OpenBoot 3.12.FW14, 96 MB memory installed, Serial #9778686.
Ethernet address 08:00:20:95:35:fe, Host ID: 809535fe.

>> NetBSD/sparc Secondary Boot, Revision 1.15
>> (root <at> mariner.coris.org.uk, Thu Jun 29 00:09:34 BST 2006)
Patching OFW for SUNW,JSIIep
sound device node: ok
Booting netbsd
Trying BOOTP protocol... net_open: client addr: 192.168.255.2
net_open: subnet mask: 255.255.255.0
net_open: net gateway: 192.168.255.1
net_open: server addr: 192.168.255.1
net_open: server path: /export/espresso/root
net_open: file name: bootjs.net
ip address: 192.168.255.2, hostname: espresso, netmask: 255.255.255.0, gateway: 192.168.255.1
root addr=192.168.255.1 path=/export/espresso/root
5017772+137984+250832 [265664+251806]=0x5b685c
(Continue reading)

Permalink | Reply | 627 comments |
headers
Michael Lorenz | 4 Jul 2006 00:36
Picon

Re: more gcc4 woes


Hello,

> For now, try:
>
> #ifdef __sparc__
> #define   KMEM_QUANTUM_SIZE       sizeof(long long)
> #else
> #define   KMEM_QUANTUM_SIZE       sizeof(void *)
> #endif

commit?

have fun
Michae;
Permalink | Reply | 1 comment |
headers
Michael Lorenz | 4 Jul 2006 00:44
Picon

Re: JavaStation Espresso


Hello,

On Jul 3, 2006, at 16:01, Julian Coleman wrote:

> igsfb0 at pci0 dev 1 function 0: Integraphics Systems CyberPro 2000 
> (rev. 0x01)
> igsfb0: 2MB, 1024x768, 8bpp

Ah, that should give you at least an accelerated console. Now someone 
needs to write an XFree/xorg driver ;)

> Acer Labs M1533 PCI-ISA Bridge (ISA bridge, revision 0x08) at pci0 dev 
> 7 function 0 not configured
> aceride0 at pci0 dev 16 function 0
> aceride0: Acer Labs M5229 UDMA IDE Controller (rev. 0x20)
> aceride0: bus-master DMA support present
> aceride0: primary channel configured to native-PCI mode
> aceride0: using line 5 (pil 0) for native-PCI interrupt

Nice, JavaStation with internal disk ;)

have fun
Michael
Permalink | Reply | 0 comments |
headers
Christos Zoulas | 4 Jul 2006 02:07

Re: more gcc4 woes

On Jul 3,  6:36pm, macallan <at> netbsd.org (Michael Lorenz) wrote:
-- Subject: Re: more gcc4 woes

| -----BEGIN PGP SIGNED MESSAGE-----
| Hash: SHA1
| 
| Hello,
| 
| > For now, try:
| >
| > #ifdef __sparc__
| > #define   KMEM_QUANTUM_SIZE       sizeof(long long)
| > #else
| > #define   KMEM_QUANTUM_SIZE       sizeof(void *)
| > #endif
| 
| commit?

No, yamt committed a much better fix.

christos
Permalink | Reply | 0 comments |
headers
Brian A. Seklecki | 5 Jul 2006 13:54

Re: Booting from RAID commited

On Tue, 20 Jun 2006, Julian Coleman wrote:

> I've committed the changes to installboot and the 2nd stage boot loader so
> that Sparcs can now boot from RAID 1 partitions [*].

I seem to remember this working back when I wrote the RAID Document for 
The Guide (2004?).

We are talking about RAIDFrame and not Sun DiskSuite or StoreEdge?

~BAS

>
> J
>
Permalink | Reply | 1 comment |
headers
Brian A. Seklecki | 5 Jul 2006 14:00

Re: Booting from RAID commited

On Wed, 5 Jul 2006, Brian A. Seklecki wrote:

> On Tue, 20 Jun 2006, Julian Coleman wrote:
>
>> I've committed the changes to installboot and the 2nd stage boot loader so
>> that Sparcs can now boot from RAID 1 partitions [*].
>
> I seem to remember this working back when I wrote the RAID Document for The 
> Guide (2004?).
>
> We are talking about RAIDFrame and not Sun DiskSuite or StoreEdge?

Nevermind.  I just read the thread last month.  That was Sparc64 when I 
wrote it.

~BAS
Permalink | Reply | 0 comments |

Gmane