[parisc-linux] test6 merge

[parisc-linux] test6 merge

[Matthew Wilcox]

i've not seen any cripplingly bad problems reported to the kernel mailing
list about -test6 (slightly fewer than the normal number of snafus,
i think).  So I intend to go ahead with the merge on Thursday.

Here's the list of files which both we and Linus have changed.

CREDITS
Makefile
drivers/Makefile
drivers/char/Config.in
drivers/char/Makefile
drivers/char/console.c
drivers/char/serial.c
drivers/net/Config.in
drivers/net/Makefile
drivers/net/Space.c
drivers/net/eepro100.c
drivers/net/tulip/eeprom.c
drivers/net/tulip/tulip_core.c
drivers/pci/pci.c
drivers/pci/pci.ids
drivers/scsi/53c7xx.c
drivers/scsi/Makefile
drivers/scsi/hosts.c
drivers/scsi/ncr53c8xx.c
drivers/scsi/sym53c8xx.c
drivers/scsi/sym53c8xx_comm.h
drivers/scsi/sym53c8xx_defs.h
drivers/sound/Config.in
drivers/sound/Makefile
drivers/video/Makefile
drivers/video/dummycon.c
fs/Makefile
fs/binfmt_elf.c
fs/exec.c
fs/nfs/read.c
fs/ufs/super.c
include/linux/binfmts.h
include/linux/fs.h
include/linux/init.h
include/linux/pci_ids.h
include/linux/tty.h
include/linux/ufs_fs.h
include/linux/wait.h
init/main.c
kernel/exit.c
kernel/fork.c
kernel/printk.c
lib/string.c
mm/vmalloc.c

some of these are easier than others.  In particular, some of Linus'
changes are supersets of our changes.  Volunteers for segments of
the tree?  Richard Hirst has already volunteered for drivers/net and
drivers/scsi.  It doesn't look to me like there's a lot to do, so we
should be able to churn through it reasonably quickly.  I'm going to
provisionally set a start time of 9am EDT on Thursday 17th August for
laying down the tag (that's 1pm GMT, please remember we're in summer
time :-)

There are going to be some API changes to deal with, in particular be
wary of locking changes.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] test6 merge

[Richard Hirst]

Hi,
  The tulip driver doesn't initialise with the 2.4.0-test6 kernel
(for me, anyway).
The problem is that pci_resource_start (pdev, 0) in tulip_core.c
line 1046, returns 0x0001ff00, where it should (I think) return
0x0000ff00.  I added a printk in drivers/pci/pci.c to show the
start/end values as it filled in the pci_dev->resource table,
and that showed start 0x0000ff00 end 0x0000ff7e.  Don't know
where bit 16 gets added to start..

I just commented out the 'goto err_out_free_netdev' in tulip_core.c
and it now claims to mount nfs root, but cannot find init.
I had to comment out the unregistering of pdc console to
see that.

In 2.3.99pre8 tulip announced that the chip was at 0x1ff00 also,
but it didn't matter because the request_region call was different.

My 53c720 driver doesn't work any more either :-(

Richard

Re: [parisc-linux] test6 merge

[Richard Hirst]

On Fri, Aug 18, 2000 at 12:49:44PM +0100, Richard Hirst wrote:
> I just commented out the 'goto err_out_free_netdev' in tulip_core.c
> and it now claims to mount nfs root, but cannot find init.

In fact, it gets as far as reading the first block of init,
doesn't like it, then goes and tries to read /bin/sh, finds it is
a link to busybox, reads in the first block of that, and doesn't
like it either:

13:06:01.601816 10.1.1.42.3529076739 > thinkpad.nfs: 104 getattr fh Unknown/1 (DF)
13:06:01.602198 thinkpad.nfs > 10.1.1.42.3529076739: reply ok 96 getattr DIR 40755 ids 0/0 sz 4096 
13:06:01.602930 10.1.1.42.3529076740 > thinkpad.nfs: 104 statfs fh Unknown/1 (DF)
13:06:01.603217 thinkpad.nfs > 10.1.1.42.3529076740: reply ok 48 statfs tsize 8192 bsize 4096 blocks 1795208 bfree 1036107 bavail 944915
13:06:01.654497 10.1.1.42.3529076741 > thinkpad.nfs: 112 lookup fh Unknown/1 "dev" (DF)
13:06:01.654939 thinkpad.nfs > 10.1.1.42.3529076741: reply ok 128 lookup fh Unknown/1
13:06:01.655678 10.1.1.42.3529076742 > thinkpad.nfs: 116 lookup fh Unknown/1 "console" (DF)
13:06:01.656096 thinkpad.nfs > 10.1.1.42.3529076742: reply ok 128 lookup fh Unknown/1
13:06:01.746812 10.1.1.42.3529076743 > thinkpad.nfs: 112 lookup fh Unknown/1 "sbin" (DF)
13:06:01.747229 thinkpad.nfs > 10.1.1.42.3529076743: reply ok 128 lookup fh Unknown/1
13:06:01.748070 10.1.1.42.3529076744 > thinkpad.nfs: 112 lookup fh Unknown/1 "init" (DF)
13:06:01.748482 thinkpad.nfs > 10.1.1.42.3529076744: reply ok 128 lookup fh Unknown/1
13:06:01.752611 10.1.1.42.3529076745 > thinkpad.nfs: 116 read fh Unknown/1 4096 bytes @ 0 (DF)
13:06:01.755048 thinkpad > 10.1.1.42: (frag 29180:1244@2960)
13:06:01.756395 thinkpad > 10.1.1.42: (frag 29180:1480@1480+)
13:06:01.757625 thinkpad.nfs > 10.1.1.42.3529076745: reply ok 1472 read (frag 29180:1480@0+)
13:06:01.801136 10.1.1.42.3529076746 > thinkpad.nfs: 112 lookup fh Unknown/1 "etc" (DF)
13:06:01.801363 thinkpad.nfs > 10.1.1.42.3529076746: reply ok 28 lookup ERROR: No such file or directory
13:06:01.841690 10.1.1.42.3529076747 > thinkpad.nfs: 112 lookup fh Unknown/1 "bin" (DF)
13:06:01.842115 thinkpad.nfs > 10.1.1.42.3529076747: reply ok 128 lookup fh Unknown/1
13:06:01.842839 10.1.1.42.3529076748 > thinkpad.nfs: 112 lookup fh Unknown/1 "init" (DF)
13:06:01.843059 thinkpad.nfs > 10.1.1.42.3529076748: reply ok 28 lookup ERROR: No such file or directory
13:06:01.881209 10.1.1.42.3529076749 > thinkpad.nfs: 112 lookup fh Unknown/1 "sh" (DF)
13:06:01.881792 thinkpad.nfs > 10.1.1.42.3529076749: reply ok 128 lookup fh Unknown/1
13:06:01.882522 10.1.1.42.3529076750 > thinkpad.nfs: 104 readlink fh Unknown/1 (DF)
13:06:01.882761 thinkpad.nfs > 10.1.1.42.3529076750: reply ok 44 readlink "/bin/busybox"
13:06:01.883512 10.1.1.42.3529076751 > thinkpad.nfs: 116 lookup fh Unknown/1 "busybox" (DF)
13:06:01.883917 thinkpad.nfs > 10.1.1.42.3529076751: reply ok 128 lookup fh Unknown/1
13:06:01.887998 10.1.1.42.3529076752 > thinkpad.nfs: 116 read fh Unknown/1 4096 bytes @ 0 (DF)
13:06:01.890360 thinkpad > 10.1.1.42: (frag 29187:1244@2960)
13:06:01.891710 thinkpad > 10.1.1.42: (frag 29187:1480@1480+)
13:06:01.892955 thinkpad.nfs > 10.1.1.42.3529076752: reply ok 1472 read (frag 29187:1480@0+)

I guess it doesn't recognise the file format for some reason..

Richard.

Re: [parisc-linux] test6 merge

[Matthew Wilcox]

On Fri, Aug 18, 2000 at 01:08:35PM +0100, Richard Hirst wrote:
> In fact, it gets as far as reading the first block of init,
> doesn't like it, then goes and tries to read /bin/sh, finds it is
> a link to busybox, reads in the first block of that, and doesn't
> like it either:
> I guess it doesn't recognise the file format for some reason..

Sounds plausible; this is one of the things which got overhauled between
2.3.99pre8 and 2.4.0-test6.  i'll investigate.  is your init SOM or ELF?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] test6 merge

[Richard Hirst]

On Fri, Aug 18, 2000 at 08:37:33AM -0400, Matthew Wilcox wrote:
> On Fri, Aug 18, 2000 at 01:08:35PM +0100, Richard Hirst wrote:
> > In fact, it gets as far as reading the first block of init,
> > doesn't like it, then goes and tries to read /bin/sh, finds it is
> > a link to busybox, reads in the first block of that, and doesn't
> > like it either:
> > I guess it doesn't recognise the file format for some reason..
> 
> Sounds plausible; this is one of the things which got overhauled between
> 2.3.99pre8 and 2.4.0-test6.  i'll investigate.  is your init SOM or ELF?

ELF.

Re: [parisc-linux] test6 merge

[Matthew Wilcox]

On Fri, Aug 18, 2000 at 02:45:02PM +0100, Richard Hirst wrote:
> On Fri, Aug 18, 2000 at 08:37:33AM -0400, Matthew Wilcox wrote:
> > On Fri, Aug 18, 2000 at 01:08:35PM +0100, Richard Hirst wrote:
> > > In fact, it gets as far as reading the first block of init,
> > > doesn't like it, then goes and tries to read /bin/sh, finds it is
> > > a link to busybox, reads in the first block of that, and doesn't
> > > like it either:
> > > I guess it doesn't recognise the file format for some reason..
> > 
> > Sounds plausible; this is one of the things which got overhauled between
> > 2.3.99pre8 and 2.4.0-test6.  i'll investigate.  is your init SOM or ELF?
> 
> ELF.

this problem is now fixed.  there seems to be another problem though since
i just got an hpmc in gsc_readl.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] test6 merge

[Grant Grundler]

Richard Hirst wrote:
> Hi,
>   The tulip driver doesn't initialise with the 2.4.0-test6 kernel
> (for me, anyway).
> The problem is that pci_resource_start (pdev, 0) in tulip_core.c
> line 1046, returns 0x0001ff00, where it should (I think) return
> 0x0000ff00.  I added a printk in drivers/pci/pci.c to show the
> start/end values as it filled in the pci_dev->resource table,
> and that showed start 0x0000ff00 end 0x0000ff7e.  Don't know
> where bit 16 gets added to start..

The bit 16 and up is the PCI bus number. The parisc PCI services use
the bus number to index into the corresponding bus services.

The driver should be using 0x0001ff00 when talking to I/O port
space services (ie inb/outb).

> I just commented out the 'goto err_out_free_netdev' in tulip_core.c
> and it now claims to mount nfs root, but cannot find init.
> I had to comment out the unregistering of pdc console to
> see that.
> 
> In 2.3.99pre8 tulip announced that the chip was at 0x1ff00 also,
> but it didn't matter because the request_region call was different.

Maybe I should take a look at the request_region() call and see what's
up there...It should be a NOP since we trust firmware to uniquely
assign I/O Port and MMIO address space (and I haven't seen any problems
where it doesn't on any platform).

> My 53c720 driver doesn't work any more either :-(

bummer...we'll get em working...

grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] test6 merge

[Matthew Wilcox]

On Fri, Aug 18, 2000 at 03:07:51PM -0700, Grant Grundler wrote:
> The bit 16 and up is the PCI bus number. The parisc PCI services use
> the bus number to index into the corresponding bus services.
> 
> The driver should be using 0x0001ff00 when talking to I/O port
> space services (ie inb/outb).

ok, the problem was that we were modifying .start but not .end so length()
was negative.  see my cvs commit message for more detail.  grant, i'd
appreciate you looking that over, it is untested since i did it on the
aeroplane and i hadn't lugged an a180 with me :-)

> > My 53c720 driver doesn't work any more either :-(
> 
> bummer...we'll get em working...

this _may_ have fixed it.  richard, could you take out the tulip hack you
put in and let me know whether the 720 works now?

however, there is still at least one nasty bug.  on the c3k i was testing
with earlier today, it would hpmc while starting init.  this might be
cured now the pci resources are being mangled properly -- could have
been to do with init trying to open /dev/console perhaps?  this was an
elf sash init, fwiw.

i'm in toronto until sunday evening with no access to parisc hardware, so
don't check out a version of the tree after the LINUS_240_TEST6_PREMERGE
tag unless you want to play hunt-the-bug.  clearly i'd love it if i
checked my email on monday morning and found cvs checkins which fixed
the bugs, but i'm a dreamer :-)

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] test6 merge

[Richard Hirst]

On Fri, Aug 18, 2000 at 10:04:56PM -0400, Matthew Wilcox wrote:
> this _may_ have fixed it.  richard, could you take out the tulip hack you
> put in and let me know whether the 720 works now?

720 still doesn't work; I'll look in to why that is.

> however, there is still at least one nasty bug.  on the c3k i was testing
> with earlier today, it would hpmc while starting init.  this might be
> cured now the pci resources are being mangled properly -- could have
> been to do with init trying to open /dev/console perhaps?  this was an
> elf sash init, fwiw.
> 
> i'm in toronto until sunday evening with no access to parisc hardware, so
> don't check out a version of the tree after the LINUS_240_TEST6_PREMERGE
> tag unless you want to play hunt-the-bug.  clearly i'd love it if i
> checked my email on monday morning and found cvs checkins which fixed
> the bugs, but i'm a dreamer :-)

Dream on ;-)  I've fixed drivers/char/serial.c to allocate our serial ports
from ttyS00 rather than from ttyS04, and my A180 now boots to a sash
prompt.  That got rid of the 'pci bus 0 not registered" message also.

Richard

Re: [parisc-linux] test6 merge

[Matthew Wilcox]

On Sat, Aug 19, 2000 at 04:24:18PM +0100, Richard Hirst wrote:
> Dream on ;-)  I've fixed drivers/char/serial.c to allocate our serial ports
> from ttyS00 rather than from ttyS04, and my A180 now boots to a sash
> prompt.  That got rid of the 'pci bus 0 not registered" message also.

OK, can we now lay down the LINUS_240_TEST6_DEVEL tag to indicate that
we're done with merging and development can begin again?  (If you agree,
you (== Richard) can lay it down rather than waiting for me).

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] test6 merge

[Richard Hirst]

On Sat, Aug 19, 2000 at 07:13:35PM -0400, Matthew Wilcox wrote:
> On Sat, Aug 19, 2000 at 04:24:18PM +0100, Richard Hirst wrote:
> > Dream on ;-)  I've fixed drivers/char/serial.c to allocate our serial ports
> > from ttyS00 rather than from ttyS04, and my A180 now boots to a sash
> > prompt.  That got rid of the 'pci bus 0 not registered" message also.
> 
> OK, can we now lay down the LINUS_240_TEST6_DEVEL tag to indicate that
> we're done with merging and development can begin again?  (If you agree,
> you (== Richard) can lay it down rather than waiting for me).

Done.

Richard

Re: [parisc-linux] test6 merge

[Richard Hirst]

My Zalon/53c720 problem is caused by changes in the way drivers/scsi
is built.  It used to build scsi.a, it now builds scsidrv.o.
If I include only one of sym53c8xx.c (for 53c875 on PCI), or ncr53c8xx.c
(for 53c720) all is well - if I include both things break.

Those two files have a number of function names in common; they are
declared static, so it shouldn't matter.  ncr_chip_reset() is one
example.  In practice, the code in ncr53c8xx.c tries to call its local
ncr_chip_reset(), but ends up in the ncr_chip_reset() function in
sym53c8xx.c.

It appeared to work fine with 2.3.99pre8, and I havn't changed my
cross compiler.

Richard

Re: [parisc-linux] test6 merge

[David Huggins-Daines]

Richard Hirst <rhirst@linuxcare.com> writes:

> Those two files have a number of function names in common; they are
> declared static, so it shouldn't matter.  ncr_chip_reset() is one
> example.  In practice, the code in ncr53c8xx.c tries to call its local
> ncr_chip_reset(), but ends up in the ncr_chip_reset() function in
> sym53c8xx.c.
> 
> It appeared to work fine with 2.3.99pre8, and I havn't changed my
> cross compiler.

I'm not seeing this problem here, at least, not based on an
examination of the kernel's object code.

In mine I have:

sym53c8xx: ncr_chip_reset = c01cdec0 (a4)
           ncr_attach     = c02a37e4 (934)
ncr53c8xx: ncr_chip_reset = c01cdf80 (e8)
           ncr_attach     = c02a6ff0 (5d8)

Where ncr_attach calls ncr_chip_reset, it looks like:

    1d34:	0e b3 12 80 	stw  r19,0(sr0,r21)
    1d38:	08 03 02 5a 	copy r3,r26
    1d3c:	e8 40 00 00 	b,l 1d44 <ncr_attach+0x354>,rp
			1d3c: R_PARISC_PCREL17F	ncr_chip_reset

And in the object file, we have:

c02a7334:       0e b3 12 80     stw  r19,0(sr0,r21)
c02a7338:       08 03 02 5a     copy r3,r26
c02a733c:       e8 58 12 fd     b,l c0298cc0 <__init_begin+0xcc0>,rp

Pointing at this stub:

c0298cc0:       20 26 f8 03     ldil -3fe32800,r1
c0298cc4:       e0 20 2f 02     be,n 780(sr4,r1)

0x780 - 0x3fe32800 = 0xc01cdf80, which is the right one.

This is with today's binutils.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] test6 merge

[Richard Hirst]

On Mon, Aug 21, 2000 at 01:01:12PM -0400, David Huggins-Daines wrote:
> Richard Hirst <rhirst@linuxcare.com> writes:
> 
> > Those two files have a number of function names in common; they are
> > declared static, so it shouldn't matter.  ncr_chip_reset() is one
> > example.  In practice, the code in ncr53c8xx.c tries to call its local
> > ncr_chip_reset(), but ends up in the ncr_chip_reset() function in
> > sym53c8xx.c.
> > 
> > It appeared to work fine with 2.3.99pre8, and I havn't changed my
> > cross compiler.
> 
> I'm not seeing this problem here, at least, not based on an
> examination of the kernel's object code.
> 
> In mine I have:
> 
> sym53c8xx: ncr_chip_reset = c01cdec0 (a4)
>            ncr_attach     = c02a37e4 (934)
> ncr53c8xx: ncr_chip_reset = c01cdf80 (e8)
>            ncr_attach     = c02a6ff0 (5d8)

I have:

sym53c8xx: c01c4800 t ncr_chip_reset
           c029b964 ? ncr_attach
ncr53c8xx: c01c48c0 t ncr_chip_reset
           c029f130 ? ncr_attach

> Where ncr_attach calls ncr_chip_reset, it looks like:
> 
>     1d34:	0e b3 12 80 	stw  r19,0(sr0,r21)
>     1d38:	08 03 02 5a 	copy r3,r26
>     1d3c:	e8 40 00 00 	b,l 1d44 <ncr_attach+0x354>,rp
> 			1d3c: R_PARISC_PCREL17F	ncr_chip_reset
> 
> And in the object file, we have:
> 
> c02a7334:       0e b3 12 80     stw  r19,0(sr0,r21)
> c02a7338:       08 03 02 5a     copy r3,r26
> c02a733c:       e8 58 12 fd     b,l c0298cc0 <__init_begin+0xcc0>,rp

I have

c029f484:       08 03 02 5a     copy r3,r26
c029f488:       e8 58 04 d5     b,l c02906f8 <__init_begin+0x6f8>,rp

> 
> Pointing at this stub:
> 
> c0298cc0:       20 26 f8 03     ldil -3fe32800,r1
> c0298cc4:       e0 20 2f 02     be,n 780(sr4,r1)

Mine is

c02906f8:       20 22 d8 03     ldil -3fe3b800,r1
c02906fc:       e0 20 20 02     be,n 0(sr4,r1)


> 0x780 - 0x3fe32800 = 0xc01cdf80, which is the right one.

0 - 0x3fe3b800 = 0xc01c4800, which is the WRONG one

> This is with today's binutils.

This is with xc-20000802

For completeness, in sym53c8xx.c version of ncr_attach() I see

c029c010:       68 74 13 80     stw r20,9c0(sr0,r3)
c029c014:       e8 5a 0d b9     b,l c02906f8 <__init_begin+0x6f8>,rp

Which points at the same stub.

Guess I need a new binutils.

Thanks for your help,

Richard