[parisc-linux] kernel merge

[parisc-linux] kernel merge

[Paul Bame]

We're getting ready to do a kernel merge (to -test10 I think).  Anybody
concerns before we get started?

	-P

Re: [parisc-linux] kernel merge

[bame]

= 
= We're getting ready to do a kernel merge (to -test10 I think).  Anybody
= concerns before we get started?
= 

I'm getting ready to commit the changes to merge us up to 2.4.0-test10 as
soon as I'm confident 64-bit kernels are OK (32-bit seems fine).

Here's a brief list of changes made (and yet to be made -- if anyone
has the time/energy) to our parisc code (does not include changes in
common code!).  While there's plenty yet to do, I think we're
no worse off than before the merge.  Some parts of our parisc code
are getting rather moldy compared to the other ports FYI.

Important tags:
	LINUS_240_TEST6			Linus' 2.4.0-test6
	LINUS_240_TEST10		Linus' 2.4.0-test10
	LINUS_240_TEST10_PREMERGE	Our tree before the -test10 merge
	LINUS_240_TEST10_MERGED		Our tree after the -test10 merge

			    ------------

Lots of 'extern __inline__' turned into 'static __inline__' and there
are more to do (TODO).

Beginnings of several smp_mb*() macros -- implemented as no-ops in
the non-SMP case (asm/bitops.h, asm/system.h)

SET_PERSONALITY() macro in asm/elf.h needs updating (TODO).

fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing
fcntl(fd, F_S/GETLK[W]64, ...).  Several other locking-related #defines added.

asm/mmu_context.h:init_new_context() now returns int (always 0), not void.

Should our asm/bitops.h routines be re-coded in assembly? (TODO)

Added #define RLIMIT_LOCKS to asm/resource.h

Added #define CLOCKS_PER_SEC to asm/param.h (how did we miss this one?)

Our asm/string.h is behind the times.  Fixing it might get rid of a
bunch of compiler warnings! (TODO)

Removed mktime from drivers/char/genrtc.c (it's in a header file now)

x86 made a bunch of changes to asm-i386/floppy.h -- should we? (TODO)

looks like maybe the get/put_user_ret() functions in asm/uaccess.h are
obsolete?  (TODO)

We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!)

Our arch/parisc/config.in is in BAD SHAPE (TODO)

arch/parisc/process.c: added new argsto do_fork() and copy_thread().
IA64 seems to use the copy_thread() arg.

arch/parisc/signal.c: minor change to common data structure

drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates
                unmap_pci_mem() causing link error (TODO - rhirst)

Re: [parisc-linux] kernel merge

[Randolph Chung]

> Our asm/string.h is behind the times.  Fixing it might get rid of a
> bunch of compiler warnings! (TODO)

if this is just an issue of implementing the various parisc-optimized string 
routines, i've been working on this, but don't have everything ready
yet.

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] kernel merge

[bame]

Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k)
after the -test10 merge.  We have MANY differences from Linus in the SCSI
area.  Anybody want to take a look at this?  FYI to get
the pre-merge kernel you can use LINUS_240_TEST10_PREMERGE.  Beware
that tags are sticky in CVS (use cvs update -A to fix that).

	-P

Re: [parisc-linux] kernel merge

[bame]

= 
= Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k)
= after the -test10 merge.

Fixed.

Re: [parisc-linux] kernel merge

[Helge Deller]

On Monday 13 November 2000 03:20, bame@riverrock.org wrote:
> = 
> = Helge noticed SCSI fails (B160L, 712, I think it's ok on c3k)
> = after the -test10 merge.
> 
> Fixed.
> 
> >From test6 to test10 the SCSI host registration method changed.
> Updated sim700.c, lasi7xx.h, zalon7xx.h
> 
> 	-P

Thanks Paul,

sim700 (53c710) now works again, but the second built-in controller (ncr/sym 
53c8xx) still doesn't.

Greetings,

	Helge

Re: [parisc-linux] kernel merge

[Richard Hirst]

On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote:
> drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates
>                 unmap_pci_mem() causing link error (TODO - rhirst)

Fixed.  This relates to NVRAM that some PCI scsi cards have to hold
config settings over reboot.  CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT
is normally defined in sym53c8xx_defs.h to turn that code on.  When
I implemented Zalon (FWD) support I guessed that the 53c720 h/w
wouldn't have NVRAM implemented the same way, and turned off
NVRAM detect.

I've also replaced a chunk of Zalon specific code that got lost in
the merge, so Zalon/FWD/53c720 support works again.

There is a problem remaining when using the driver as a module;
it looks like something is trying to printk() from a string in
the module after the module has been removed.  Havn't tracked
that down yet.

Richard

sym53c8xx-driver (was: Re: [parisc-linux] kernel merge)

[Helge Deller]

On Monday 13 November 2000 13:13, Richard Hirst wrote:
> On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote:
> > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates
> >                 unmap_pci_mem() causing link error (TODO - rhirst)
> 
> Fixed.  This relates to NVRAM that some PCI scsi cards have to hold
> config settings over reboot.  CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT
> is normally defined in sym53c8xx_defs.h to turn that code on.  When
> I implemented Zalon (FWD) support I guessed that the 53c720 h/w
> wouldn't have NVRAM implemented the same way, and turned off
> NVRAM detect.
> 
> I've also replaced a chunk of Zalon specific code that got lost in
> the merge, so Zalon/FWD/53c720 support works again.
> 
> There is a problem remaining when using the driver as a module;
> it looks like something is trying to printk() from a string in
> the module after the module has been removed.  Havn't tracked
> that down yet.
> 
> Richard


Hi Richard,

I'm sorry to say that the sym53c8xx still doesn't work on my B160L (32 
bit-Kernel). It looks like the controller isn't detected at all, while it 
worked perfectly with 2.4.0-test6.
Would you mind to take a look at the code again ?

Thanks,
	Helge.

Re: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge)

[Richard Hirst]

Hi Helge,
  The problem I fixed related to the ncr53c8xx driver (which shares
code with sym53c8xx), and was to make 53c720 support work again.
sym53c8xx worked for me on my A180.  Please can you try booting
with

	sym53c8xx=verb:7,debug:0xffff

and send me the output?

Thanks,
 Richard


On Mon, Nov 13, 2000 at 11:54:29PM +0100, Helge Deller wrote:
> On Monday 13 November 2000 13:13, Richard Hirst wrote:
> > On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote:
> > > drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates
> > >                 unmap_pci_mem() causing link error (TODO - rhirst)
> > 
> > Fixed.  This relates to NVRAM that some PCI scsi cards have to hold
> > config settings over reboot.  CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT
> > is normally defined in sym53c8xx_defs.h to turn that code on.  When
> > I implemented Zalon (FWD) support I guessed that the 53c720 h/w
> > wouldn't have NVRAM implemented the same way, and turned off
> > NVRAM detect.
> > 
> > I've also replaced a chunk of Zalon specific code that got lost in
> > the merge, so Zalon/FWD/53c720 support works again.
> > 
> > There is a problem remaining when using the driver as a module;
> > it looks like something is trying to printk() from a string in
> > the module after the module has been removed.  Havn't tracked
> > that down yet.
> > 
> > Richard
> 
> 
> Hi Richard,
> 
> I'm sorry to say that the sym53c8xx still doesn't work on my B160L (32 
> bit-Kernel). It looks like the controller isn't detected at all, while it 
> worked perfectly with 2.4.0-test6.
> Would you mind to take a look at the code again ?
> 
> Thanks,
> 	Helge.
> 

Re: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge)

[Helge Deller]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

On Tuesday 14 November 2000 00:27, Richard Hirst wrote:
> Hi Helge,
>   The problem I fixed related to the ncr53c8xx driver (which shares
> code with sym53c8xx), and was to make 53c720 support work again.
> sym53c8xx worked for me on my A180.  Please can you try booting
> with
> 
> 	sym53c8xx=verb:7,debug:0xffff
> 
> and send me the output?
> 
> Thanks,
>  Richard


Hi Richard,

the output and the relevant part of .config is attached.

Greetings,

	Helge

[-- Attachment #2: log1 --]
[-- Type: text/plain, Size: 9313 bytes --]


.config: 
----------------------------------------
#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
# CONFIG_CHR_DEV_ST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y

#
# SCSI low-level drivers
#
CONFIG_SCSI_LASI=y
CONFIG_SCSI_ZALON=y
CONFIG_SCSI_SYM53C8XX=y
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=20
# CONFIG_SCSI_NCR53C8XX_PROFILE is not set
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set


------------------------------------------------

boot-log:
-------------------------------------------------

Firmware Version  6.1

Duplex Console IO Dependent Code (IODC) revision 1

Memory Test/Initialization Completed 

------------------------------------------------------------------------------
   (c) Copyright 1995-1998, Hewlett-Packard Company, All rights reserved
------------------------------------------------------------------------------

  Processor   Speed            State           Coprocessor State  Cache Size
  ---------  --------   ---------------------  -----------------  ----------
      0      160 MHz    Active                 Functional          64 KB
                                                                    1 MB ext


  Available memory (bytes)    :  536870912 
  Good memory required (bytes):  536870912 

  Primary boot path:    FWSCSI.6.0
  Alternate boot path:  LAN.0.0.0.0.0.0
  Console path:         GRAPHICS(2)
  Keyboard path:        PS2

CPU 0
WARNING:  Self tests have been disabled as a result of FASTBOOT
          being enabled.  To enable self tests, use the FASTBOOT
          command in the CONFIGURATION menu and reboot the system.


------- Main Menu -------------------------------------------------------------

        Command                         Description
        -------                         -----------
        BOot [PRI|ALT|<path>]           Boot from specified path
        PAth [PRI|ALT|CON|KEY] [<path>] Display or modify a path
        SEArch [DIsplay|IPL] [<path>]   Search for boot devices

        COnfiguration [<command>]       Access Configuration menu/commands
        INformation [<command>]         Access Information menu/commands
        SERvice [<command>]             Access Service menu/commands

        DIsplay                         Redisplay the current menu
        HElp [<menu>|<command>]         Display help for menu or command
        RESET                           Restart the system
-------
Main Menu: Enter command > bo lan
Interact with IPL (Y, N, Q)?> n

Booting... 
Network Station Address 080009-ef34f5
System IP Address 192.168.100.160
Server IP Address 192.168.100.100

Boot IO Dependent Code (IODC) revision 2


HARD Booted.
palo ipl root@P100 Thu Nov  2 20:14:08 MET 2000
0/vmlinux 2274771 bytes @ 0x6800
0/palo-cmdline '0/vmlinux HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.100.100:/tftpboot/nfsroot console=tty sym53c8xx=verb:7,debug:0xffff'
Kernel: partition 0 file /vmlinux
ELF32 executable

Entry 00100190 first 00100000 n 4
Segment 0 load 00100000 size 1534668 mediaptr 0x1000
Segment 1 load 00278000 size 182344 mediaptr 0x178000
Segment 2 load 002a8000 size 139132 mediaptr 0x1a5000
Segment 3 load 002cc000 size 8192 mediaptr 0x1c7000
branching to kernel entry point 0x00100190
Set default PSW W bit to 0
PDC Console Initialized
The 32-bit Kernel has started...
Enabled FP coprocessor
Free memory starts at: 0xc02fd000
start_parisc(0x504d6c,0x504d6c,0x0,0x0)
PALO command line: 'HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.100.100:/tftpboot/nfsroot console=tty sym53c8xx=verb:7,debug:0xffff'
PALO initrd 0-0
model   00005020 00000481 00000000 02020202 7794d7fe 100000f0 00000004 000000ba 000000ba
vers    00000008
cpuid   000001e8
CPUID vers 15 rev 8
Searching for devices in PDC firmware... processor hpa 0xfffbe000
a newer box...
Found devices:
1. Phantom PseudoBC GSC+ Port (7) at 0xffc00000, versions 0x504, 0x0, 0x0, 0x0, 0x0
2. Merlin 160 Core FW-SCSI (4) at 0xfff8c000, versions 0x3d, 0x0, 0x89, 0x0, 0x80
3. Merlin L2 160 (9000/778/B160L) (0) at 0xfffbe000, versions 0x502, 0x0, 0x4, 0x0, 0x81
4. Merlin 160/ThunderHawk Memory (1) at 0xfffbf000, versions 0x67, 0x0, 0x9, 0x0, 0x0
5. Merlin 160 Core BA (11) at 0xffd00000, versions 0x3d, 0x0, 0x81, 0x0, 0x0
6. Merlin 160 Core RS-232 (10) at 0xffd05000, versions 0x3d, 0x0, 0x8c, 0x0, 0x0
7. Merlin 160 Core SCSI (10) at 0xffd06000, versions 0x3d, 0x0, 0x82, 0x0, 0x0
8. Merlin 160 Core Lan (802.3) (10) at 0xffd07000, versions 0x3d, 0x0, 0x8a, 0x0, 0x0
9. Merlin 160 Core Centronics (10) at 0xffd02000, versions 0x3d, 0x0, 0x74, 0x0, 0x0
10. Merlin 160 Core Audio (10) at 0xffd04000, versions 0x3d, 0x4, 0x7b, 0x0, 0x0
11. Merlin 160 Core PC Keyboard (10) at 0xffd08000, versions 0x3d, 0x0, 0x84, 0x0, 0x0
12. Merlin 160 Core PC Keyboard (10) at 0xffd08100, versions 0x3d, 0x0, 0x84, 0x0, 0x0
13. Merlin 160 Wax BA (11) at 0xffe00000, versions 0x41, 0x0, 0x8e, 0x0, 0x0
14. Merlin 160 Wax EISA BA (11) at 0xfc000000, versions 0x41, 0x0, 0x90, 0x0, 0x0
15. Merlin 160 Wax HIL (10) at 0xffe01000, versions 0x41, 0x0, 0x73, 0x0, 0x0
16. Merlin 160 Wax RS-232 (10) at 0xffe02000, versions 0x41, 0x0, 0x8c, 0x0, 0x0
17. Coral SGC Graphics (10) at 0xf4000000, versions 0x4, 0x0, 0x77, 0x0, 0x0
18. Gecko GSC Core Graphics (10) at 0xf8000000, versions 0x16, 0x0, 0x85, 0x0, 0x0
19. Dino PCI Bridge (13) at 0xfff80000, versions 0x680, 0x0, 0xa, 0x0, 0x0
That's a total of 19 devices.
CPU(s): 1 x PA7300LC (PCX-L2) at 160.000000 MHz
Linux version 2.4.0-test10 (root@P100) (gcc version 2.96 20000925 (experimental)) #15 Tue Nov 14 01:01:33 MET 2000
free_bootmem(0x301000, 0x1fcff000)
initrd: 00000000-00000000
pagetable_init
On node 0 totalpages: 131072
zone(0): 65536 pages.
zone(1): 65536 pages.
zone(2): 0 pages.
Kernel command line: HOME=/ TERM=LINUX root=/dev/nfs nfsroot=192.168.100.100:/tftpboot/nfsroot console=tty sym53c8xx=verb:7,debug:0xffff
trap_init
Console: colour dummy device 80x25
register_console
Calibrating delay loop... 106.50 BogoMIPS
Memory: 510944k available
Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
POSIX conformance testing by UNIFIX
Lasi version 0 at 0xffd00000 found.
Wax at 0xffe00000 found.
Wax: HIL Keyboard-NMI registered.
parport0: PC-style at 0xffd02800, irq 88 [PCSPP,TRISTATE]
Found i82596 at 0xffd07000, IRQ 87
early initialization of device eth0 is deferred
Initializing Lasi PS/2-keyboard port at 0xffd08000...
Support for Lasi PS/2-psaux not yet available !
Found HIL at 0xffe01000, IRQ 126
No handler for interrupt 35 !
HIL: timed out, assuming no keyboard present.
Warning : device (10, 0x41, 0x0, 0x73, 0x0) NOT claimed by HIL 712, 715 or similiar
Dino version 2.0 (bridge mode) found at 0xfff80000


The GSCtoPCI (Dino hrev 0) bus converter found may exhibit
data corruption.  See Service Note Numbers: A4190A-01, A4191A-01.
Systems shipped after Aug 20, 1997 will not exhibit this problem.
Models affected: C180, C160, C160L, B160L, and B132L workstations.

dino_bridge_init: IO_ADDR_EN hasn't been configured.
kernel BUG at dino.c:646!
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
stifb.c: searching for word mode STI ROMs
found potential STI ROM at f4000000
STI byte mode ROM at f4000000, ignored
found potential STI ROM at f8000000
pty: 256 Unix98 ptys configured
lp0: using parport0 (interrupt-driven).
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
eth0: 82596 at 0xffd07000, 08 00 09 EF 34 F5 IRQ 87.
82596.c $Revision: 1.14 $
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at iomem 0xffd05800 (irq = 90) is a 16550A
ttyS01 at iomem 0xffe02800 (irq = 121) is a 16550A
Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)
SCSI subsystem driver Revision: 1.00
sim700: Configuring 53c710 (SCSI-ID 7) at ffd06100, IRQ 86
scsi0: Revision 0x2
Post test1, istat 01, sstat0 00, dstat 84
sim700: WARNING IRQ probe failed, (returned 0)
scsi0: Good, target data areas are dma coherent
scsi0: test 1 completed ok.
scsi0: sim700_intr_handle() called with no interrupt
scsi0 : LASI/Simple 53c7xx
  Vendor: PIONEER   Model: CD-ROM DR-U12X    Rev: 1.06
  Type:   CD-ROM                             ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
sr0: scsi3-mmc drive: 12x/12x xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.11
searching for word mode STI ROMs
found potential STI ROM at f4000000
STI byte mode ROM at f4000000, ignored
found potential STI ROM at f8000000
searching for byte mode STI ROMs
found potential STI ROM at f4000000
STI byte mode ROM type 1
 supports 15 monitors
 conforms to STI ROM spec revision 8.07
dump_sti_rom: 500
 graphics id 2d08c0a709a02587
dump_sti_rom: 510
 font start 000183c3
dump_sti_rom: 512
 region list 00018363
dump_sti_rom: 514
 init_graph 00001a63
dump_sti_rom: 516
 alternate code type 0
dump_sti_rom: 518
next font 00004040
f4000000 b
f8000000 b
Switching from PDC console

Re: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge)

[Richard Hirst]

Hi Helge,

On Tue, Nov 14, 2000 at 01:13:58AM +0100, Helge Deller wrote:
> On Tuesday 14 November 2000 00:27, Richard Hirst wrote:
> > Hi Helge,
> >   The problem I fixed related to the ncr53c8xx driver (which shares
> > code with sym53c8xx), and was to make 53c720 support work again.
> > sym53c8xx worked for me on my A180.  Please can you try booting
> > with
> > 
> > 	sym53c8xx=verb:7,debug:0xffff
> > 
> > and send me the output?
> > 
> > Thanks,
> >  Richard
> 
> 
> Hi Richard,
> 
> the output and the relevant part of .config is attached.
> 
> Greetings,
> 
> 	Helge

Thanks.  I agree it doesn't look like the driver is even seeing the
chip; I wonder if PCI support is broken...

> dino_bridge_init: IO_ADDR_EN hasn't been configured.
> kernel BUG at dino.c:646!

Does it usually say that on bootup?

Richard

Re: sym53c8xx-driver (was: Re: [parisc-linux] kernel merge)

[Helge Deller]

> Hi Helge,
> 
> On Tue, Nov 14, 2000 at 01:13:58AM +0100, Helge Deller wrote:
> > On Tuesday 14 November 2000 00:27, Richard Hirst wrote:
> > > Hi Helge,
> > >   The problem I fixed related to the ncr53c8xx driver (which shares
> > > code with sym53c8xx), and was to make 53c720 support work again.
> > > sym53c8xx worked for me on my A180.  Please can you try booting
> > > with
> > > 
> > > 	sym53c8xx=verb:7,debug:0xffff
> > > 
> > > and send me the output?
> > > 
> > > Thanks,
> > >  Richard
> > 
> > 
> > Hi Richard,
> > 
> > the output and the relevant part of .config is attached.
> > 
> > Greetings,
> > 
> > 	Helge
> 
> Thanks.  I agree it doesn't look like the driver is even seeing the
> chip; I wonder if PCI support is broken...
> 
> > dino_bridge_init: IO_ADDR_EN hasn't been configured.
> > kernel BUG at dino.c:646!
> 
> Does it usually say that on bootup?

Yep. 
Has always been there, but nevertheless the scsi-driver worked before.
FYI: The non-pci sim700-driver also didn't showed up before pb fixed it in
CVS with a few one-line-patches.

NB: Could maybe someone (ggg?) explain me the kernel-bug mentioned above ?

> 
> Richard
> 

Greetings,

	Helge

-- 
Sent through GMX FreeMail - http://www.gmx.net

[parisc-linux] dino maintainer?

[Grant Grundler]

Anyone interested in maintaining Dino?

I don't have time for it and all the docs are on the web.
One of the "TODO" things is to convert dino.c to use struct
pci_hba the same way lba_pci.c does....

Richard Hirst wrote:
...
> Thanks.  I agree it doesn't look like the driver is even seeing the
> chip; I wonder if PCI support is broken...
> 
> > dino_bridge_init: IO_ADDR_EN hasn't been configured.
> > kernel BUG at dino.c:646!
> 
> Does it usually say that on bootup?

per Helge's request:

The bug is normal for card-mode Dino - not for Built-in Dino.
I think Helge has the GSC 100BT card which is a card-mode Dino on-board
with one (or two) Tulip(s) behind it.

The warning is a reminder one can NOT use MMIO accesses to those
PCI devices and *only* I/O Port space (eg inb/outb).

If someone wants to fix the warning so it's quiet for card-mode
devices...see is_card_dino(d) in dino_driver_callback() for an
example.

FYI - card-mode dino was used for several different networking
interfaces but not SCSI interfaces.

hope this helps,
grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] dino maintainer?

[Richard Hirst]

On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote:
> The bug is normal for card-mode Dino - not for Built-in Dino.
> I think Helge has the GSC 100BT card which is a card-mode Dino on-board
> with one (or two) Tulip(s) behind it.
> 
> The warning is a reminder one can NOT use MMIO accesses to those
> PCI devices and *only* I/O Port space (eg inb/outb).
> 
> If someone wants to fix the warning so it's quiet for card-mode
> devices...see is_card_dino(d) in dino_driver_callback() for an
> example.
> 
> FYI - card-mode dino was used for several different networking
> interfaces but not SCSI interfaces.

But Helge has problems with the sym53c8xx driver on a B160L.  Is
that a PCI card driven via Dino?  And if so, are you saying he needs
to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it
doesn't try to use MMIO?

Helge, it might be worth trying to switch on CONFIG_SCSI_NCR53C8XX_IOMAPPED
anyway just to see what happens.  Otherwise someone needs to start
adding printk debug to figure out what is happening.  I can't do
that as I don't have a sym53c8xx pci card.

Richard

Re: [parisc-linux] dino maintainer?

[Grant Grundler]

Richard Hirst wrote:
> On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote:
> > The bug is normal for card-mode Dino - not for Built-in Dino.
> > I think Helge has the GSC 100BT card which is a card-mode Dino on-board
> > with one (or two) Tulip(s) behind it.

Helge confirmed he has no such card.
I think the PDC simply isn't programming the Dino IO_ADDR_EN
since there are no PCI devices in his B160.

Helge's B160 has a old rev of Dino PCI host bus adapter chip.
It's possible to have "silent" data corruption caused by older
revs of dino - 3.0 and older.
The latest PDC Revisions (5.x and later) know this and won't permit
the system to be booted unless the only devices on the PCI bus are
known graphics interface cards.

> > The warning is a reminder one can NOT use MMIO accesses to those
> > PCI devices and *only* I/O Port space (eg inb/outb).
> > 
> > If someone wants to fix the warning so it's quiet for card-mode
> > devices...see is_card_dino(d) in dino_driver_callback() for an
> > example.

This is still correct for card-mode dino.

> > FYI - card-mode dino was used for several different networking
> > interfaces but not SCSI interfaces.
> 
> But Helge has problems with the sym53c8xx driver on a B160L.  Is
> that a PCI card driven via Dino? 

I doubt it now. If Helge could send richard "in io" output, I think
that would clarify what's in the B160.

> And if so, are you saying he needs
> to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it
> doesn't try to use MMIO?

no. no SCSI was ever implement on a card-mode dino board.
No reason to since they already had Zalon or open slots.

grant

> Helge, it might be worth trying to switch on CONFIG_SCSI_NCR53C8XX_IOMAPPED
> anyway just to see what happens.  Otherwise someone needs to start
> adding printk debug to figure out what is happening.  I can't do
> that as I don't have a sym53c8xx pci card.
> 
> Richard

Re: [parisc-linux] dino maintainer?

[Alex deVries]

Richard Hirst wrote:
> On Tue, Nov 14, 2000 at 08:10:42AM -0800, Grant Grundler wrote:
> > FYI - card-mode dino was used for several different networking
> > interfaces but not SCSI interfaces.
> 
> But Helge has problems with the sym53c8xx driver on a B160L.  Is
> that a PCI card driven via Dino?  And if so, are you saying he needs
> to build his kernel with CONFIG_SCSI_NCR53C8XX_IOMAPPED=y so it
> doesn't try to use MMIO?

Hang on a sec... what Grant's saying is that *card-mode* dino is never
used for SCSI controllers, but on the B160L it would probably be
*chip-mode* dino.

Does this mean that all GSC SCSI expansion cards are Zalon based?

So what Helge has isn't a PCI card specifically, Dino and the 53c8xx are
all on the motherboard.

Does Dino handle IO memory mapping differently for chip or card mode?

- Alex

-- 
Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare
613.562.2759 tel
alex@linuxcare.com, http://www.linuxcare.com/
Linuxcare, Support for the revolution.

Re: [parisc-linux] dino maintainer?

[Grant Grundler]

Alex deVries wrote:
> Hang on a sec... what Grant's saying is that *card-mode* dino is never
> used for SCSI controllers, but on the B160L it would probably be
> *chip-mode* dino.

No such thing - you probably mean "Bridge Mode" and that's what
the built-in Dino is using.

> Does this mean that all GSC SCSI expansion cards are Zalon based?
>
> So what Helge has isn't a PCI card specifically, Dino and the 53c8xx are
> all on the motherboard.
> 
> Does Dino handle IO memory mapping differently for chip or card mode?

yes. yes. yes (conditional).

"IO memory mapping" is a confusing term. I'll assume you mean MMIO.
(Memory Mapped I/O)

MMIO space access is independent of I/O Port space access.
MMIO space access simple isn't available for card-mode Dino since
niether PDC nor the OS assigns host physical address space to the
card-mode Dino (that's what IO_ADDR_EN is for). PDC does this
for Bridge-mode dino (built-in) - but apperently only when it needs
to.

I/O Port space accesses are done the same way for both modes.
I/O Port space access is implemented by poking registers on Dino.

Read the Dino Spec (or source) for more details.

grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] dino maintainer?

[Richard Hirst]

On Wed, Nov 15, 2000 at 09:58:35AM +0000, Richard Hirst wrote:
> But Helge has problems with the sym53c8xx driver on a B160L.  Is

Turned out to be a 53c720, driven via Zalon and the ncr53c8xx driver.
Driver worked as a module, but not compiled in.  Now fixed.

Richard

Re: [parisc-linux] kernel merge

[Matthew Wilcox]

On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote:
> fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing
> fcntl(fd, F_S/GETLK[W]64, ...).  Several other locking-related #defines added.
> 
> We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!)

actually, we don't.  Linux/PA-RISC has sufficiently wide data types
already so we don't have the grot required in other ports to support
the appropriate wide data types.

> looks like maybe the get/put_user_ret() functions in asm/uaccess.h are
> obsolete?  (TODO)

yes, they are.  exterminate!  exterminate!

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] kernel merge

[Paul Bame]

= On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote:
= > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing
= > fcntl(fd, F_S/GETLK[W]64, ...).  Several other locking-related #defines add
ed.
= > 
= > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!)
= 
= actually, we don't.  Linux/PA-RISC has sufficiently wide data types
= already so we don't have the grot required in other ports to support
= the appropriate wide data types.

Ok that sounds great but I need a clue how to see it.  struct flock
contains an off_t which is 32 bits on narrow (wide too at the moment,
but that will probably change).  Also, struct dirent contains
a 32-bit inode and a __kernel_off_t offset (d_off), which is also
32 bits narrow.  I did see the ... in our fcntl() syscall definition
so I'll go check glibc to see what's happening there.

I wouldn't be so picky except that I need to write
the 32/64 syscall translators for these soon!  Thanks!

	-P

Re: [parisc-linux] kernel merge

[Paul Bame]

= On Fri, Nov 10, 2000 at 02:28:33PM -0700, bame@riverrock.org wrote:
= > fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing
= > fcntl(fd, F_S/GETLK[W]64, ...).  Several other locking-related #defines add
ed.
= > 
= > We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!)
= 
= actually, we don't.  Linux/PA-RISC has sufficiently wide data types
= already so we don't have the grot required in other ports to support
= the appropriate wide data types.

Oh, and won't we have to support these syscalls anyway, because user programs
will make them?  I suppose we could #define them in libc headers.

= > looks like maybe the get/put_user_ret() functions in asm/uaccess.h are
= > obsolete?  (TODO)
= 
= yes, they are.  exterminate!  exterminate!

Done