[parisc-linux] linux-2.4.0

[parisc-linux] linux-2.4.0

[Matthew Wilcox]

i've merged linus' 2.4.0 release into our tree.  it compiles, with fewer
warnings than before.  but some things have been changed in the vm system
i'm not 100% confident with.  so, since i'm not in a position to boot
the 712 right now (lack of networking), i'm checking it in as a branch
called LINUS_240_FIXUP.

the checkin's going a bit slowly, so don't try it just yet, but it should
be done shortly.  those of you on the cvs list will see when it's done.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] linux-2.4.0

[Matthew Wilcox]

ok, the merge is complete and the head of the tree is now linux-2.4.0.
it's marked with the LINUS_240_DEVEL tag.  sorry for messing it up
so badly.

drivers/pci is almost unaltered from 2.4.0-test10 as grant thinks the
changes which have been made will break our PCI code.

a few conflicts worth noting... jsm had merged some stuff from -test11
into our tree.  dealt with those dual patches, no problem.

kernel/ptrace.c, kernel/module.c got some cache flushing changeswhich
conflicted with some of ours (only textually, not semantically).

tulip_core.c seemed to have absorbed some of our patches.  acenic.c had
some small changes.

we have large outstanding diffs in the scsi directory -- richard
volunteered to take care of this.  some other drivers need submitting
/ updating.

i'm going to send linus a patch tomorrow to get our arch/parisc and
include/asm-parisc trees uptodate in his tree.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] linux-2.4.0

[Grant Grundler]

Matthew Wilcox wrote:
> drivers/pci is almost unaltered from 2.4.0-test10 as grant thinks the
> changes which have been made will break our PCI code.

Unless someone objects, My plan is to continue working on CONFIG_SMP
until it boots on my A500. Then merge the 2.4.0 PCI stuff onto our
tree. The problem is names of pci "generic" functions changed -test11
or -test12 and what they do has been slightly changed. Certain things
definitely break A500 support. I need to revisit both the generic and
elroy code so it all works again.

...
> i'm going to send linus a patch tomorrow to get our arch/parisc and
> include/asm-parisc trees uptodate in his tree.

Which means the linus tree still won't build a parisc-kernel.
He'll have missing symbol errors in the PCI subsystem for sure.
But I guess we'll keep getting closer as time goes on.

thanks!
grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] linux-2.4.0

[Matthew Wilcox]

On Thu, Jan 25, 2001 at 05:57:14PM -0800, Grant Grundler wrote:
> Unless someone objects, My plan is to continue working on CONFIG_SMP
> until it boots on my A500. Then merge the 2.4.0 PCI stuff onto our
> tree. The problem is names of pci "generic" functions changed -test11
> or -test12 and what they do has been slightly changed. Certain things
> definitely break A500 support. I need to revisit both the generic and
> elroy code so it all works again.

i don't mind waiting.

> Which means the linus tree still won't build a parisc-kernel.
> He'll have missing symbol errors in the PCI subsystem for sure.
> But I guess we'll keep getting closer as time goes on.

right.  i don't anticipate getting all the changes we need into linus'
tree any time soon, possibly not until 2.5 opens.  i think 2.4.0 only
works on x86 & alpha.  i know it doesn't work on ia64 -- some journalists
tried to make a big deal out of this.  i see linus put ppc, sparc &
sparc64 patches into 2.4.1-pre, so I'm guessing 2.4.0 doesn't work on
those arches either.

just for giggles, i merged 2.4.1-pre10 into our tree.  no conflicts.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] linux-2.4.0

[Richard Hirst]

On Fri, Jan 26, 2001 at 12:48:31AM +0000, Matthew Wilcox wrote:
> we have large outstanding diffs in the scsi directory -- richard
> volunteered to take care of this.  some other drivers need submitting
> / updating.

We have a new driver sim700.c that drives 53c700 and 53c710; Linus has a
driver sim710.c that drives just 53c710 (also written by me).  I want to
merge those two before submitting, but havn't managed yet.  sim710.c is
used on older Compaq x86 boxes with on-board scsi controllers.  I have
such a machine, but my merged driver had some problems on it.  I plan on
having another go at that.

The other area is ncr53c8xx.c, which I modified to support 53c720 on
Zalon.  I have sent patches to the maintainer and he has agreed to
integrate them - but nothing has happened for a while.  I'll prod
him again.

I see drivers/net/lasi_82596.c got integrated.  I had planned on
merging that with 82596.c sometime, but I guess there is no urgency
now.  82596.c is mostly used on m68k VME boards.

Richard

Re: [parisc-linux] linux-2.4.0

[Alan Cox]

> just for giggles, i merged 2.4.1-pre10 into our tree.  no conflicts.

Bad move. 2.4.1 is incredibly broken and unstable. Stay at 2.4.0 for testing

Re: [parisc-linux] linux-2.4.0

[Andrew Shugg]

Alan Cox said:
> > just for giggles, i merged 2.4.1-pre10 into our tree.  no conflicts.
> 
> Bad move. 2.4.1 is incredibly broken and unstable. Stay at 2.4.0 for testing

Darn.  What did you call the tag before the merge, Mr Wilcx?

Andrew.

--
Andrew Shugg <andrew@neep.com.au>                   http://www.neep.com.au/

"Just remember, Mr Fawlty, there's always someone worse off than yourself."
"Is there?  Well I'd like to meet him.  I could do with a good laugh."

Re: [parisc-linux] linux-2.4.0

[Matthew Wilcox]

On Thu, Feb 01, 2001 at 02:49:32AM +0800, Andrew Shugg wrote:
> Alan Cox said:
> > > just for giggles, i merged 2.4.1-pre10 into our tree.  no conflicts.
> > 
> > Bad move. 2.4.1 is incredibly broken and unstable. Stay at 2.4.0 for testing
> 
> Darn.  What did you call the tag before the merge, Mr Wilcx?

Why, LINUS_241_PREMERGE, following our normal convention, of course.

OK, OK, I forgot to lay down the tag.  But I've laid it down retroactively.
I'm about to back the 2.4.1 merge out of the tree, let's see if this works.

-- 
Revolutions do not require corporate support.

[parisc-linux] C100 & Latest CVS Bits

[Greg Ingram]

Howdy,

The latest CVS bits crater on my C100.  The last two messages are:

VFS: Mounted root (ext2 filesystem).
Warning: unable to open an initial console.

(Which is normal so far.)  Then I get a stack dump, a kernel fault and a
register dump.  As I recall, Grant said the stack dump itself isn't
helpful unless it's a kernel built with the default configuration.  I'd be
happy get that output if it would help.

As a side question, is it possible to have the system automatically reboot
after it encounters these errors?

Cheers,

- Greg

Re: [parisc-linux] C100 & Latest CVS Bits

[Grant Grundler]

Greg Ingram wrote:
> As I recall, Grant said the stack dump itself isn't
> helpful unless it's a kernel built with the default configuration.

I can't (or won't) help with stack/register dumps unless they are built
with default config. That's different than saying they aren't helpful.
The problem is the symbols are what's interesting to me and I can't
determine them unless the bits match what's in a source tree I have.

I guess it's time we put together a "PARISC Kernel Debugging HOW-TO
for Dummies". ie how to look up symbols, explain TOC (and HPMC), how
to get/decode TOC/HPMC dumps, etc.

> As a side question, is it possible to have the system automatically reboot
> after it encounters these errors?

It can. There's a global variable someplace that is *disabled* by default.
If someone can just remember the global's name...

grant

Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253

Re: [parisc-linux] C100 & Latest CVS Bits

[Greg Ingram]

All good news!

On Tue, 13 Feb 2001, Grant Grundler wrote:

> Greg Ingram wrote:
> > As I recall, Grant said the stack dump itself isn't
> > helpful unless it's a kernel built with the default configuration.
> 
> I can't (or won't) help with stack/register dumps unless they are built
> with default config. That's different than saying they aren't helpful.
> The problem is the symbols are what's interesting to me and I can't
> determine them unless the bits match what's in a source tree I have.

I understand.  I've rebuilt from clean with the default config and... 
[Gulp!]  I guess another reason to use the default config is to ensure
that I haven't done something rash with my config.  Here's the end of the
session now:

	Starting internet superserver: inetd.
 
	Debian GNU/Linux 2.2 apollos ttyS0
 
	apollos login:  

I'd also made /dev/console -> /dev/ttyS0.  No log to follow.  :)
 
> I guess it's time we put together a "PARISC Kernel Debugging HOW-TO
> for Dummies". ie how to look up symbols, explain TOC (and HPMC), how
> to get/decode TOC/HPMC dumps, etc.

Dummies?!  Ack!  Phfft!  Tyros, neophytes, novices, even newbies.  But
please do.  
 
> > As a side question, is it possible to have the system automatically reboot
> > after it encounters these errors?
> 
> It can. There's a global variable someplace that is *disabled* by default.
> If someone can just remember the global's name...

Anybody?  I have to make that *long* walk through the accounting office
just to power-cycle the beast.  

- Greg

Re: [parisc-linux] C100 & Latest CVS Bits

[Steven Pritchard]

Greg Ingram said:
> On Tue, 13 Feb 2001, Grant Grundler wrote:
> > Greg Ingram wrote:
> > > As a side question, is it possible to have the system automatically reboot
> > > after it encounters these errors?
> > 
> > It can. There's a global variable someplace that is *disabled* by default.
> > If someone can just remember the global's name...
> 
> Anybody?  I have to make that *long* walk through the accounting office
> just to power-cycle the beast.  

Does rebooting with sysrq work?  (I've never actually tried it over a
serial console, but I seem to recall that you can send a break, then
"b".)

Actually, will that work, or do you have to turn on sysrq via /proc
after booting?

Oh, wait, it looks like you can pass "panic=1" as a kernel parameter. 
That should have the same effect as "echo 1 > /proc/sys/kernel/panic"
(or adding "kernel.panic = 1" to /etc/sysctl.conf and running "sysctl
-p") on a running system.

Documentation/sysctl/kernel.txt says the following:

    panic:

    The value in this file represents the number of seconds the
    kernel waits before rebooting on a panic. When you use the
    software watchdog, the recommended setting is 60.

The default value is 0, which disables the feature, IIRC.  (This is
from memory, so I could easily be wrong.)

I hope this trip through my faulty memory is helpful...  ;-)

Steve
-- 
steve@silug.org           | Southern Illinois Linux Users Group
(618)398-7320             | See web site for meeting details.
Steven Pritchard          | http://www.silug.org/

Re: Auto-rebooting (was Re: [parisc-linux] C100 & Latest CVS Bits)

[Greg Ingram]

On Tue, 13 Feb 2001, Steven Pritchard wrote:

> Does rebooting with sysrq work?  

Er, as in on the keyboard?  It's not even plugged in.  I haven't gotten a
monitor to work with my C100 so I've only used the serial console and
telnet.

> (I've never actually tried it over a serial console, but I seem to
> recall that you can send a break, then "b".)

My terminal program is cu on a Sun SparcStation 2.  Sending a break with
'~#' and '~%break' with and without a trailing 'b' don't have any effect.

> Actually, will that work, or do you have to turn on sysrq via /proc
> after booting?
> 
> Oh, wait, it looks like you can pass "panic=1" as a kernel parameter. 
> That should have the same effect as "echo 1 > /proc/sys/kernel/panic"
> (or adding "kernel.panic = 1" to /etc/sysctl.conf and running "sysctl
> -p") on a running system.

I'll go ahead and append this option, but I think some of the times the
kernel is dead.

- Greg