headers
KIYOHARA Takashi | 1 Sep 2004 21:08
Picon

couldn't establish interrupt at crime

hi!

I think that I will use the card of USB. However, when the same irq
is already used, it cannot do establish.
# PCI has allowed sharing of irq.

When I investigate, crime_intr_establish() has not allowed sharing of
IRQ.

crime.c::crime_intr_establish() ---

        if (crime[irq].func != NULL)
                return NULL;    /* panic("Cannot share CRIME interrupts!"); */

--

dmesg.boot ---

ohci0 at pci0 dev 3 function 0: Acer Labs M5237 USB Host Controller (rev. 0x03)
ohci0: interrupting at crime interrupt 13
ohci0: OHCI version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Acer Labs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ohci1 at pci0 dev 3 function 1: Acer Labs M5237 USB Host Controller (rev. 0x03)
ohci1: couldn't establish interrupt at crime interrupt 13
ohci2 at pci0 dev 3 function 2: Acer Labs M5237 USB Host Controller (rev. 0x03)
ohci2: couldn't establish interrupt at crime interrupt 13
ehci0 at pci0 dev 3 function 3: Acer Labs product 0x5239 (rev. 0x01)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christopher SEKIYA | 2 Sep 2004 08:32

Re: couldn't establish interrupt at crime

On Thu, Sep 02, 2004 at 04:08:01AM +0900, KIYOHARA Takashi wrote:

> When I investigate, crime_intr_establish() has not allowed sharing of
> IRQ.

... which is 100% correct.  crime interrupts are not shared ...

> mace has allowed sharing. We think that it should call here.

Your analysis is correct.  The PCI bridge is a mace device; interrupts should
be handled by mace rather than crime.

> # Is macepci_intr_establish() etc. required? ;-)

I don't think so.

Your code looks okay.  If your USB card works now, go ahead and commit it
(and issue a pullup).

Thanks for working on this,

-- Chris
	GPG key FEB9DE7F (91AF 4534 4529 4BCC 31A5  938E 023E EEFB FEB9 DE7F)
Permalink | Reply | 2 comments |
headers
KIYOHARA Takashi | 2 Sep 2004 19:21
Picon

Re: couldn't establish interrupt at crime

Hi Christopher!

From: Christopher SEKIYA <wileyc <at> rezrov.net>
Date: Thu, 2 Sep 2004 15:32:41 +0900

> Your code looks okay.  If your USB card works now, go ahead and commit it
> (and issue a pullup).

thanks and sorry, ;-<

I had made a mistake in processing of mace_intr_disestablish(). We have
to check not sharing IRQ and have to call crime_intr_unmask().

ex. ---
        /* do not do a unmask, when irq is being shared. */
        for (i = 0; i < MACE_NINTR; i++)
                if (&maceintrtab[i].func != NULL && maceintrtab[i].irq == irq)
                        break;
        if (i == MACE_NINTR)
                crime_intr_unmask(intr);
---

And I cannot test tonight. Please wait till a weekend. ;-<

--
kiyohara
Permalink | Reply | 0 comments |
headers
Antti Kantee | 3 Sep 2004 00:28
Picon
Picon

Re: New 2.0 snapshot available

On Thu Sep 02 2004 at 23:22:27 +0100, Christian Smith wrote:
> Problem is, I'm trying to cross compile from a Debian Linux machine, but
> fail when building the tools. I'm using (source in /scratch/tmp/src):
> $ ./build.sh -T /scratch/tmp/src/cross -U -m sgimips tools
> 
> But fail when building sgivol:
> 
> /scratch/tmp/src/cross/bin/nbhost-mkdep -d -f .depend -s .lo\ .ln sgivol.d
> #   compile  sgivol/sgivol.lo
> cc -O -I/scratch/tmp/src/tools/compat/obj -I/scratch/tmp/src/tools/compat/obj/include 
-I/scratch/tmp/src/tools/sgivol/../compat -DHAVE_NBTOOL_CONFIG_H=1  -D_FILE_OFFSET_BITS=64  -c
-o sgivol.lo.o    /scratch/tmp/src/sys/arch/sgimips/stand/sgivol/sgivol.c
> /scratch/tmp/src/sys/arch/sgimips/stand/sgivol/sgivol.c:42:27: sys/disklabel.h: No such file
or directory
> ...
> 
> 
> Am I doing something fundamentally wrong? src/tools/compat/README
> indicates cross builds are fine on RH, so I wouldn't expect Debian to be
> much different.

Hmm.  I know sgivol used to be broken when cross-compiling from a
non-(Net?)BSD box, but I thought it was fixed.  As a really quick hack
if you just want to build the kernel, you can comment out building sgivol
from src/tools/Makefile.

If someone doesn't fix sgivol soon, I will, and that won't be a pretty
sight!

--

--
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christian Smith | 3 Sep 2004 00:22

Re: New 2.0 snapshot available

On Tue, 10 Aug 2004, Antti Kantee wrote:

>On Tue Aug 10 2004 at 17:51:16 +0100, Christian Smith wrote:
>> Installation notes has IP12 as a supported architecture, but I notice no
>> IP12 kernels in the snapshot. Do you have an working IP12 kernel that can
>> be used with this snapshot?
>>
>> Just thought I'd ask before diving in and trying to compiling one.
>
>Well, um, the IP12 kernel config file is kinda missing, because we
>haven't yet decided what to do with it (there are annoying problems in
>how to divide the sgimips config files).  So for now it's a "roll your
>own from GENERIC32_IP2x".  And because there's no config file, it's not
>a surprise that the kernel doesn't get built as part of the release.
>
>Creating a IP12 config file takes 4 easy steps starting from
>GENERIC32_IP2x:
>     ...
>
>Then just compile & fly away.  If you have any problems, don't hesitate
>to ask.

OK, I've finally got round to [trying to] compile a kernel for IP12, using
a GENERIC32_IP12 config based on the mods suggested.

Problem is, I'm trying to cross compile from a Debian Linux machine, but
fail when building the tools. I'm using (source in /scratch/tmp/src):
$ ./build.sh -T /scratch/tmp/src/cross -U -m sgimips tools

But fail when building sgivol:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ilpo Ruotsalainen | 3 Sep 2004 00:49
Picon
Picon
Favicon

Re: New 2.0 snapshot available

On Fri Sep 03 2004 at 01:28:30 +0300, Antti Kantee wrote:
> Hmm.  I know sgivol used to be broken when cross-compiling from a
> non-(Net?)BSD box, but I thought it was fixed.  As a really quick hack
> if you just want to build the kernel, you can comment out building sgivol
> from src/tools/Makefile.

No, it wasn't fixed. Someone hacked it to compile on FreeBSD if memory
serves but it still requires BSD to have any hope of compiling.

> If someone doesn't fix sgivol soon, I will, and that won't be a pretty
> sight!

I don't care whether it's pretty or not long as it works, please fix it!
;)

--

-- 
Ilpo Ruotsalainen - <lonewolf <at> iki.fi> - http://www.iki.fi/lonewolf/
Permalink | Reply | 2 comments |
headers
R. Tyler Ballance | 2 Sep 2004 20:33
Picon
Favicon

Re: New 2.0 snapshot available

> > If someone doesn't fix sgivol soon, I will, and that won't be a pretty
> > sight!
>
> I don't care whether it's pretty or not long as it works, please fix it!
> ;)

http://netbsd.org/Goals/system.html

"In that light NetBSD could be described as "It doesn't work unless it's 
right"."

Just thought i'd throw that in there :-P

-Tyler
Permalink | Reply | 1 comment |
headers
Antti Kantee | 3 Sep 2004 01:43
Picon
Picon

Re: New 2.0 snapshot available

On Thu Sep 02 2004 at 18:33:32 +0000, R. Tyler Ballance wrote:
> > > If someone doesn't fix sgivol soon, I will, and that won't be a pretty
> > > sight!
> >
> > I don't care whether it's pretty or not long as it works, please fix it!
> > ;)
> 
> http://netbsd.org/Goals/system.html
> 
> "In that light NetBSD could be described as "It doesn't work unless it's 
> right"."
> 
> Just thought i'd throw that in there :-P

"It doesn't work unless the hacker smells right"?

I think I'm allowed to reserve the right to look non-pretty when hacking.

--

-- 
Antti Kantee <pooka <at> iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
                 "connoisseurs do not chill their malts."
Permalink | Reply | 0 comments |
headers
Christian Smith | 3 Sep 2004 02:27

Re: New 2.0 snapshot available

Cheers, guys, I now have a kernel currently building on Linux. I just used
Antti's suggestion of disabling sgivol.

The SPARC is still chugging away building tools, so I think I'll stick to
my Linux machine for building.

As I write, the kernel has just finished building (wow, 3m27s, not bad.)
I've uploaded the kernels (ELF and ECOFF) to:
http://www.codex.net/~csmith/netbsd/GENERIC32_IP12

Kernel as yet untested, and will probably remain so until the weekend, at
least.

Christian

On Fri, 3 Sep 2004, Christopher SEKIYA wrote:

>On Fri, Sep 03, 2004 at 02:43:57AM +0300, Antti Kantee wrote:
>
>> I think I'm allowed to reserve the right to look non-pretty when hacking.
>
>*laugh* I'm going to remember that declaration ...
>
>... Scott did some work on this months ago, but I never got around to
>committing his patch (happened right in the middle of that damned datacenter
>migration, so I kind of forgot about it).
>
>It's at http://mail-index.netbsd.org/port-sgimips/2004/05/17/0004.html ...
>
>-- Chris
(Continue reading)

Permalink | Reply | 0 comments |
headers
KIYOHARA Takashi | 5 Sep 2004 18:55
Picon

Re: couldn't establish interrupt at crime

Hi! Christopher.

From: Christopher SEKIYA <wileyc <at> rezrov.net>
Date: Thu, 2 Sep 2004 15:32:41 +0900

> Your code looks okay.  If your USB card works now, go ahead and commit it
> (and issue a pullup).

OK! USB card working (probably). ;-)

---
 ... snip ...

ohci0 at pci0 dev 3 function 0: Acer Labs M5237 USB Host Controller (rev. 0x03)
mace: established interrupt 13 (level 0)
ohci0: interrupting at crime interrupt 13
ohci0: OHCI version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Acer Labs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ohci1 at pci0 dev 3 function 1: Acer Labs M5237 USB Host Controller (rev. 0x03)
mace: established interrupt 13 (level 0)
ohci1: interrupting at crime interrupt 13
ohci1: OHCI version 1.0, legacy support
usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: Acer Labs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
ohci2 at pci0 dev 3 function 2: Acer Labs M5237 USB Host Controller (rev. 0x03)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane