headers
Izumi Tsutsui | 14 Nov 2006 16:16
Picon
Gravatar

enabling interrupt in cpu_initclocks(9) rather than cpu_configure(9)

In article <061021032925.M0108599 <at> mirage.ceres.dti.ne.jp>
I wrote:

> uwe <at> ptc.spbu.ru wrote:
> 
> > If this is a problem for some of the arches than may be we should
> > reconsider the requirements of where MD code should enable the
> > interrupts?
> 
> I checked 4.4BSD Lite2 sources, then I notice:
> - configure() is called from cpu_startup() (which is called from main())
> - initclocks() (which will call cpu_initclocks(9)) is called from main()
> - there are several initialization and functions between cpu_startup()
>   and initclocks()
>   (but I'm not sure if there is anything which requires hardware interrupts)
> 
> Nowadays, configure() becomes MI and is called from main(),
> confiugre() calls MD cpu_configure(), and initclocks() is
> a part of configure() (and it's called right after cpu_configure()),
> so I guess the requirements noted in the cpu_configure(9) man page
> have been changed...

If there is no objection, I'll also change some MIPS ports
(which use the CPU_INT5 internal clocks) enabling hardware
interrupts (by _splnone()) in cpu_initclocks(9) rather than
cpu_configure(9) to avoid clock interrupts (and softclockint)
until cpu_initclocks(9) is called, as well as macppc.
---
Izumi Tsutsui
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Burge | 14 Nov 2006 17:14
Picon

Re: enabling interrupt in cpu_initclocks(9) rather than cpu_configure(9)

Izumi Tsutsui wrote:

> In article <061021032925.M0108599 <at> mirage.ceres.dti.ne.jp>
> I wrote:
> 
> > uwe <at> ptc.spbu.ru wrote:
> > 
> > > If this is a problem for some of the arches than may be we should
> > > reconsider the requirements of where MD code should enable the
> > > interrupts?
> > 
> > I checked 4.4BSD Lite2 sources, then I notice:
> > - configure() is called from cpu_startup() (which is called from main())
> > - initclocks() (which will call cpu_initclocks(9)) is called from main()
> > - there are several initialization and functions between cpu_startup()
> >   and initclocks()
> >   (but I'm not sure if there is anything which requires hardware interrupts)
> > 
> > Nowadays, configure() becomes MI and is called from main(),
> > confiugre() calls MD cpu_configure(), and initclocks() is
> > a part of configure() (and it's called right after cpu_configure()),
> > so I guess the requirements noted in the cpu_configure(9) man page
> > have been changed...
> 
> If there is no objection, I'll also change some MIPS ports
> (which use the CPU_INT5 internal clocks) enabling hardware
> interrupts (by _splnone()) in cpu_initclocks(9) rather than
> cpu_configure(9) to avoid clock interrupts (and softclockint)
> until cpu_initclocks(9) is called, as well as macppc.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Izumi Tsutsui | 14 Nov 2006 18:20
Picon
Gravatar

Re: enabling interrupt in cpu_initclocks(9) rather than cpu_configure(9)

simonb <at> NetBSD.org wrote:

> Izumi Tsutsui wrote:
> > If there is no objection, I'll also change some MIPS ports
> > (which use the CPU_INT5 internal clocks) enabling hardware
> > interrupts (by _splnone()) in cpu_initclocks(9) rather than
> > cpu_configure(9) to avoid clock interrupts (and softclockint)
> > until cpu_initclocks(9) is called, as well as macppc.
> 
> It looks like this makes little functional difference for most MIPS
> ports - initclocks() is called staight after cpu_configure() in
> subr_autoconf.c.  Also, this doesn't look like it needs to be limited to
> the CPU_INT5-based clocks - it should work for all clock types, right?

Yes, it should be harmless for other mips ports,
but so I'd like to make changes minimum for now.

On INT5 clock based ports, there is no way to disable CPU INT5
other than spl(9), so if _splnone() is called in cpu_configure(9),
hardclock(9) could happen between cpu_configure(9) and initclock()
and softclock(9) could be called from hardclock(9) before
softintr_establish(9) for softclock in initclocks(), then
it causes panic(9).

Other mips ports have some other way to disable the external
clock interrpt independently via their interrupt controllers etc.
so they don't have trouble currently. If these ports will also
have the same strategy, they no longer have to have tweaks
to disable external clock interrupts, but such ports have
their own cpu_initclocks() so I'm not sure if it's so efficient.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Izumi Tsutsui | 17 Nov 2006 22:04
Picon
Gravatar

Re: enabling interrupt in cpu_initclocks(9) rather than cpu_configure(9)

In article <061115001645.M0117518 <at> mirage.ceres.dti.ne.jp>
I wrote:

> If there is no objection, I'll also change some MIPS ports
> (which use the CPU_INT5 internal clocks) enabling hardware
> interrupts (by _splnone()) in cpu_initclocks(9) rather than
> cpu_configure(9) to avoid clock interrupts (and softclockint)
> until cpu_initclocks(9) is called, as well as macppc.

Committed. If you see any problems, please report via send-pr(1).
---
Izumi Tsutsui
Permalink | Reply | 0 comments |
headers
Kevin Lahey | 18 Nov 2006 04:48

configuration of gcc4 stuck in a loop on Cobalt

With -current as of a week or so ago, I found that the Cobalt port has
some problems building.  I can cross compile from my i386 box with no
problem.  Alas, building on the actual Cobalt runs in to some problems.

After successfully building ld, it appears to continuously try to
configure gcc4;  this is an improvement over previous builds with older
source, in which I got infinite recursion in a check of include files.

I've attached what appears to me to be the significant parts of the log
file;  if that's not enough, I've got another 55,000 lines of this
repeating again and again.  :-)

I'd sure appreciate any debugging suggestions.

Thanks,

Kevin
kml <at> patheticgeek.net
Permalink | Reply | 0 comments |
headers
Michael L. Hitch | 18 Nov 2006 05:15

Re: configuration of gcc4 stuck in a loop on Cobalt

On Fri, 17 Nov 2006, Kevin Lahey wrote:

> After successfully building ld, it appears to continuously try to
> configure gcc4;  this is an improvement over previous builds with older
> source, in which I got infinite recursion in a check of include files.
>
> I've attached what appears to me to be the significant parts of the log
> file;  if that's not enough, I've got another 55,000 lines of this
> repeating again and again.  :-)
>
> I'd sure appreciate any debugging suggestions.

   I just recently had the same thing happen to me on an old AlphaServer 
1000A.  I thought the machine was just being slow, but after it sat 
building tools/gcc, I took a look at the log file and found it running the 
gcc configure over and over.  After updating my sources and starting the 
build from scratch, it still did the same thing.

   Poking around in the various Makefiles, I found an entry that had the 
config.status (I think) as a dependancy along with a file (or files) 
specified as a make macro.  I then figured out that I had run one of my 
cvs updates after I had run the standalone raid configuration utility 
which had changed the clock.  Booting into NetBSD after that had changed 
the year to 2026, so all the new files from the cvs update (which I think 
included a gcc4 update) had files 20 years in the future.  One of those
file was presumably part of the make dependancy, so it always thought 
config.status was out of date.  After doing a touch on all the files in my 
source tree that were in the future, my build worked much better.

   I don't know if this might be your problem, but it would be one thing to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Lahey | 18 Nov 2006 17:29

Re: configuration of gcc4 stuck in a loop on Cobalt

On Fri, 17 Nov 2006 21:15:54 -0700 (MST)
"Michael L. Hitch" <mhitch <at> lightning.msu.montana.edu> wrote:

> On Fri, 17 Nov 2006, Kevin Lahey wrote:
> 
> > After successfully building ld, it appears to continuously try to
> > configure gcc4;  this is an improvement over previous builds with older
> > source, in which I got infinite recursion in a check of include files.

>    I just recently had the same thing happen to me on an old AlphaServer 
> 1000A.  I thought the machine was just being slow, but after it sat 
> building tools/gcc, I took a look at the log file and found it running the 
> gcc configure over and over.

> [...]  Booting into NetBSD after that had changed 
> the year to 2026, so all the new files from the cvs update (which I think 
> included a gcc4 update) had files 20 years in the future.  One of those
> file was presumably part of the make dependancy, so it always thought 
> config.status was out of date.  [...]

That was it!  Next time, I'll keep the date on my crash-n-burn server up
to date...

Thanks a million!

Kevin
kml <at> patheticgeek.net
Permalink | Reply | 0 comments |

Gmane