[parisc-linux] 2.4.0 merge mangle our tree?

[parisc-linux] 2.4.0 merge mangle our tree?

[Grant Grundler]

Hi Matthew,

I did 'cvs co -D "1/24/2001 09:00 MST" linux' in order to pick
up the bits before the 2.4.0 "First take" commit.

	make distclean
	make oldconfig
	edit .config to set CONFIG_SMP=y
	make oldconfig
	make -j4 dep
	make -j4 palo  (dies with error)

"make palo" dies with:

hppa-linux-gcc -D__KERNEL__ -I/linux/smp64/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-calls -mschedule=7200 -mdisable-fpregs -fno-strict-aliasing -ffunction-sections    -c -o tcp_minisocks.o tcp_minisocks.c
tcp_minisocks.c: In function `tcp_timewait_state_process':
tcp_minisocks.c:137: too many arguments to function `tcp_parse_options'
tcp_minisocks.c: In function `tcp_check_req':
tcp_minisocks.c:812: too many arguments to function `tcp_parse_options'
make[3]: *** [tcp_minisocks.o] Error 1
make[3]: Leaving directory `/linux/smp64/linux/net/ipv4'
...


grundler <725>fgrep tcp_minisocks net/ipv4/CVS/Entries 
/tcp_minisocks.c/1.1.1.2/Tue Jan  9 16:56:41 2001/-ko/D2001.01.24.07.00.00

And from the cvs log output:
head: 1.2
...
symbolic names:
	LINUS_240_FIXUP: 1.1.0.2
	LINUS_240_PREMERGE: 1.1
	LINUS_240: 1.1.1.2
	LINUX_240_PREIMPORT: 1.1
...
----------------------------
revision 1.2
date: 2001/01/25 00:03:54;  author: willy;  state: Exp;  lines: +3 -3

Linus 2.4.0 merge (take one)
----------------------------
...


Why am I picking up the LINUS_240 version of this file?
Is "-D" the wrong method to use?

Tried "cvs update -rLINUS_240_PREMERGE" and that seemed to do what
I think I wanted. But backs out a few recent changes. *sigh*.

thanks,
grant

Re: [parisc-linux] 2.4.0 merge mangle our tree?

[Michael Ang]

On Wed, 24 Jan 2001, Grant Grundler wrote:

> I did 'cvs co -D "1/24/2001 09:00 MST" linux' in order to pick
> up the bits before the 2.4.0 "First take" commit.
>
> [...]
> And from the cvs log output:
> head: 1.2
>
> ...
> symbolic names:
> 	LINUS_240_FIXUP: 1.1.0.2
> 	LINUS_240_PREMERGE: 1.1
> 	LINUS_240: 1.1.1.2
> 	LINUX_240_PREIMPORT: 1.1
> [...]
> 
> Why am I picking up the LINUS_240 version of this file?
> Is "-D" the wrong method to use?

These are all the symbolic names for revisions of this file - your
working version might be any of these or none.  "cvs stat" will tell you
what version you currently have.

Using the date should work if you get it just right, but there should have
been a tag laid down before the merge started for just this purpose.

> Tried "cvs update -rLINUS_240_PREMERGE" and that seemed to do what
> I think I wanted. But backs out a few recent changes. *sigh*.

That seems closer to what you want, but backs out any changes made since
the merge started.  Not sure what the difference between *_PREMERGE and
*_PREIMPORT is - you'd have to ask willy, I guess.

	- Mike.

Re: [parisc-linux] 2.4.0 merge mangle our tree?

[Matthew Wilcox]

On Wed, Jan 24, 2001 at 11:19:57PM -0500, Michael Ang wrote:
> That seems closer to what you want, but backs out any changes made since
> the merge started.  Not sure what the difference between *_PREMERGE and
> *_PREIMPORT is - you'd have to ask willy, I guess.

_PREIMPORT was a tag laid down by paul.  _PREMERGE was the tag I laid
down before starting the merge.

i'm not sure why i fucked up the branching so badly.  I did:

cvs tag -b LINUS_240_FIXUP
cvs ci
cvs add (several times, adding new directories and new files)
cvs ci
cvs -n up
cvs rm
cvs ci

(taken from my bash history, so i know this is exactly what i did)

the manpage says:

              To create a branch revision, one
              typically use the -b option of the rtag or tag com­
              mands.  Then, either checkout or update can be used
              to base your sources on the newly  created  branch.
              From  that point on, all commit changes made within
              these working sources will be  automatically  added
              to  a branch revision, thereby not perturbing main-
              line development in any way. 

so what did i do wrong?

the other question is how best to fix the mess... if you check out
LINUS_240_FIXUP do you get a non-broken kernel?  does it work?  if so,
let's just put it all back on the HEAD.  if not, we have to try figuring
out something else.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] 2.4.0 merge mangle our tree?

[Michael Ang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1706 bytes --]

On Thu, 25 Jan 2001, Matthew Wilcox wrote:
> 
> i'm not sure why i fucked up the branching so badly.  I did:
> 
> cvs tag -b LINUS_240_FIXUP
[What did you do here?  Copy files from a tarball?]
> cvs ci
> cvs add (several times, adding new directories and new files)
> cvs ci
> cvs -n up
> cvs rm
[What kind of files were you removing?]
> cvs ci
> 
> (taken from my bash history, so i know this is exactly what i did)
>

Note my emphasis of your words: 
> the manpage says:
> 
>               To create a branch revision, one
>               typically use the -b option of the rtag or tag com­
>               mands.  **Then, either checkout or update can be used
>               to base your sources on the newly  created  branch.**
>               From  that point on, all commit changes made within
>               these working sources will be  automatically  added
>               to  a branch revision, thereby not perturbing main-
>               line development in any way. 
> 
> so what did i do wrong?

You didn't check out or update with the branch tag, so all your changes
hit the trunk.  I'm not convinced you want to use a branch for merging (I
prefer doing it on the trunk - it hurts alot but it's over fast) but I
haven't been following the discussions very closely.

> the other question is how best to fix the mess... if you check out
> LINUS_240_FIXUP do you get a non-broken kernel?  does it work?  if so,
> let's just put it all back on the HEAD.  if not, we have to try figuring
> out something else.

The thing to really avoid is losing local changes.  If you want to do the
merge on a branch, the best bet is to revert the inadvertent changes to
the trunk and start over.

	- Mike.

Re: [parisc-linux] 2.4.0 merge mangle our tree?

[Matthew Wilcox]

On Thu, Jan 25, 2001 at 09:56:47AM -0500, Michael Ang wrote:
> On Thu, 25 Jan 2001, Matthew Wilcox wrote:
> > 
> > i'm not sure why i fucked up the branching so badly.  I did:
> > 
> > cvs tag -b LINUS_240_FIXUP
> [What did you do here?  Copy files from a tarball?]

umm.. i did this after i'd merged the 2.4.0 files into my tree.  i didn't
think about doing it on a branch until then.  Should have thought about
it in advance, I guess?

> > cvs ci
> > cvs add (several times, adding new directories and new files)
> > cvs ci
> > cvs -n up
> > cvs rm
> [What kind of files were you removing?]

the ones which `cvs -n up' told me it would have added -- ie the ones
which were deleted by patch.

> You didn't check out or update with the branch tag, so all your changes
> hit the trunk.  I'm not convinced you want to use a branch for merging (I
> prefer doing it on the trunk - it hurts alot but it's over fast) but I
> haven't been following the discussions very closely.

Ugh.  Blah.  The reason I attempted to do it on a branch is that I could
only test it compiled not that it booted (for reasons too complex to
go into here, involving not being able to locate a 110V to 8V AC in
ottawa yet).  Perhaps I should have just not bothered.

> The thing to really avoid is losing local changes.  If you want to do the
> merge on a branch, the best bet is to revert the inadvertent changes to
> the trunk and start over.

Well, I have a directory here which contains what I want to appear in
CVS on the branch.  I'm not getting rid of it!  Would you mind reverting
this mess I've created to before the checkins I did yesterday, and I'll
try again?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] 2.4.0 merge mangle our tree?

[Richard Hirst]

Main branch is certainly broken.  e.g. drivers/pci/Makefile makes
drivers/pci/pci.a but Makefile tries to link drivers/pci/drivers.o
I fixed that in my tree but then got masses of unresolved
references on the final link.

Richard

Re: [parisc-linux] 2.4.0 merge mangle our tree?

[Richard Hirst]

On Thu, Jan 25, 2001 at 10:19:18AM +0000, Richard Hirst wrote:
> Main branch is certainly broken.  e.g. drivers/pci/Makefile makes
> drivers/pci/pci.a but Makefile tries to link drivers/pci/drivers.o
> I fixed that in my tree but then got masses of unresolved
> references on the final link.

For the main branch, Makefile appears to be from 2.4.0, but
drivers/pci/Makefile isn't.  I dropped in a new drivers/pci/Makefile
and the next problem is that it isn't building anything in arch/parisc/lib.
Make.Rules change, maybe.

Giving up for now,
  Richard

[parisc-linux] C100 improvements, problems

[Greg Ingram]

Howdy ya'll,

Failing to read all the new messages first, I did a cvs update and wound
up with unbuildable source.  So I kept the sim700 bits and unrolled the
20010124 tarball.  Now I've got my disks back.  Thanks.

Current problems:

o  I still get the 'Warning: unable to open an initial console.' message.  
Serial is working better and I get kernel messages on the serial console.  
init is running a getty on /dev/ttyS0 but I never get a login prompt.  
I've tried with and without 'console=/dev/ttyS0' as a kernel commandline
parameter.

o  I still have trouble with unligned data references.  I've discovered
that in addition to tar and make, sleep and nscd also produce this error.

o  I see a curious message when I reboot:

	Trying to free nonexistent resource <ffd07000-ffd0700b>

o  more page faults when I use SCSI but not when root is mounted via NFS.  
Hmm... why could that be?  I thought maybe it had to do with swapping, but
if I use nfsroot and then:

	# swapon /dev/sda2

more works fine.  I can mount the ext2 partition and run more from there.  
But when the SCSI disk is root, more page faults. Here's some kernel
messages:
 
	do_page_fault() pid=285 command='more' type=15 address=0xbaffffff
	vm_start = 0x4018c000, vm_end = 0x40190000
 
	     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
	PSW: 00000000000001001111111100001011
	r0-3     00000000 00008978 00003b4b 000074c0
	r4-7     bb000000 00008978 0000a978 00007000
	r8-11    00008afa 0008b810 0000a978 bb0001a0
	r12-15   00000000 00000000 000892b0 00000000
	r16-19   00000000 00000001 0000b71b 0000006d
	r20-23   0000002f bb000000 bb000004 bb000008
	r24-27   80808080 000074c0 bb000000 00008978
	r28-31   00000004 40069d2c bb000540 4009352f
	sr0-3    00000000 000001a9 00000000 000001a9
	sr4-7    000001a9 000001a9 000001a9 000001a9
 
	IASQ: 000001a9 000001a9 IAOQ: 00003b57 00003b5b
	 IIR: 0ebf3033    ISR: 000001a9  IOR: baffffff
	ORIG_R28: 00000001   

But things are definately looking up.  :)

- Greg

Re: [parisc-linux] C100 improvements, problems

[Richard Hirst]

On Thu, Jan 25, 2001 at 11:33:07AM -0600, Greg Ingram wrote:
> o  I still have trouble with unligned data references.  I've discovered
> that in addition to tar and make, sleep and nscd also produce this error.

Sounds like the libpthreads problem, for which a new glibc is being
built.

> more works fine.  I can mount the ext2 partition and run more from there.  
> But when the SCSI disk is root, more page faults. Here's some kernel
> messages:

There is a bug in more (really!), now fixed, but needs a rebuild.  If you
invoke it as /bin/more you'll be ok.

Richard

Re: [parisc-linux] C100 improvements, problems

[Greg Ingram]

On Thu, 25 Jan 2001, Richard Hirst wrote:

> On Thu, Jan 25, 2001 at 11:33:07AM -0600, Greg Ingram wrote:
> > o  I still have trouble with unligned data references.  I've discovered
> > that in addition to tar and make, sleep and nscd also produce this error.
> 
> Sounds like the libpthreads problem, for which a new glibc is being
> built.

Standing by.  Eagerly.  I'd like to see this crate try to roll its own
kernel.
 
> > more works fine.  I can mount the ext2 partition and run more from there.  
> > But when the SCSI disk is root, more page faults. Here's some kernel
> > messages:
> 
> There is a bug in more (really!), now fixed, but needs a rebuild.  If you
> invoke it as /bin/more you'll be ok.

I believe it, I just don't believe it.  Is this related to stack
direction?  (What is it: grows down on parisc but up on Intel and most
other Linux-supported processors?)  If so, what is more fiddling with on
its stack?  Does it alter its behavior based on argv[0]?  Oh well, not
really too important now, I guess.

- Greg

Re: [parisc-linux] C100 improvements, problems

[Richard Hirst]

On Fri, Jan 26, 2001 at 12:16:29PM -0600, Greg Ingram wrote:
> > There is a bug in more (really!), now fixed, but needs a rebuild.  If you
> > invoke it as /bin/more you'll be ok.
> 
> I believe it, I just don't believe it.  Is this related to stack
> direction?  (What is it: grows down on parisc but up on Intel and most
> other Linux-supported processors?)  If so, what is more fiddling with on
> its stack?  Does it alter its behavior based on argv[0]?  Oh well, not
> really too important now, I guess.

parsic grows up, most others grow down.  'more' checked argv[0] to see
how it was invoked, and due to a coding bug tried to read argv[0][-1].
As argv[0] is the first item on our stack, that caused a trap.

Richard

Re: [parisc-linux] C100 improvements, problems

[Matthew Wilcox]

On Thu, Jan 25, 2001 at 11:33:07AM -0600, Greg Ingram wrote:
> But when the SCSI disk is root, more page faults. Here's some kernel
> messages:
>  
> 	do_page_fault() pid=285 command='more' type=15 address=0xbaffffff

Known bug in `more'.  the stack starts at 0xbb000000 and more is trying
to look at the byte below the stack poinbter.  this has been fixed
upstream, now.

-- 
Revolutions do not require corporate support.

[parisc-linux] C100 report, latest CVS bits

[Greg Ingram]

Just wanted to report that I did a CVS update this morning, built and
booted a good kernel.  It's nice to see:

	# uname -a
	Linux apollos 2.4.0 #7 Fri Jan 26 10:52:17 CST 2001 parisc unknown

- Greg

Re: [parisc-linux] 2.4.0 merge mangle our tree?

[Grant Grundler]

Richard Hirst wrote:
> Main branch is certainly broken.  e.g. drivers/pci/Makefile makes
> drivers/pci/pci.a but Makefile tries to link drivers/pci/drivers.o
> I fixed that in my tree but then got masses of unresolved
> references on the final link.

The whole PCI stuff needs to be merged. I was supposed to do that
once willy had a branch ready...I guess I should be doing that RSN
on the trunk. :^(

grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] 2.4.0 merge mangle our tree?

[Matthew Wilcox]

On Wed, Jan 24, 2001 at 07:46:40PM -0800, Grant Grundler wrote:
> Hi Matthew,
> 
> I did 'cvs co -D "1/24/2001 09:00 MST" linux' in order to pick
> up the bits before the 2.4.0 "First take" commit.

ok, the answer seems to be `don't do that then'.  i get a buildable tree
by doing `cvs co linux; cd linux; cvs up -rLINUS_240_PREMERGE'.  I also
get a buildable tree by doing `cvs up -r LINUS_240_FIXUP'.  One is before
the merge and one is after.

sorry for stuffing up the merge :-(  ironic that i was trying to avoid
inconveniencing people...

> Tried "cvs update -rLINUS_240_PREMERGE" and that seemed to do what
> I think I wanted. But backs out a few recent changes. *sigh*.

err... which changes are those?  The sys32_select change richard made
just before i started breaking the tree looks like it's there. I guess
the change to sim700 that richard made won't be there, but as long as we
get this mess sorted out soon, it isn't going to be a big deal to find it.

-- 
Revolutions do not require corporate support.