Michael Lorenz | 2 Jul 20:51 2006
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
Martin Husemann | 3 Jul 00:13 2006
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

Christos Zoulas | 3 Jul 00:27 2006

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)

Michael Lorenz | 3 Jul 01:40 2006
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)

Julian Coleman | 3 Jul 22:01 2006
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)

Michael Lorenz | 4 Jul 00:36 2006
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;
Michael Lorenz | 4 Jul 00:44 2006
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
Christos Zoulas | 4 Jul 02:07 2006

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

Brian A. Seklecki | 5 Jul 13:54 2006

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
>

Brian A. Seklecki | 5 Jul 14:00 2006

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


Gmane