From: F. H. <fh...@at...> - 2000-06-25 23:03:01
|
I'm still at a loss to figure out why the cache test is failing on the 53c770.c driver. I have been comparing the code in 53C770.c with that in the SYM53X8XX.c driver and the ncr_snooptest() routines are pretty much the same. Perhaps one of you that has worked on SCSI drivers can help me understand what is happening? From looking at the code it seems like the ncr_snooptest() is copying the SCSI scripts code to the cache and then trying to execute that code. Since that execution fails the cache test fails. The first dmesg output is one in which the return statements in the ncr_snooptest() are commented out in order to allow what looks like debugging code at the end of the routine to execute. Assuming that is what's happening shows that the scripts are not executing. The second dmesg output is showing what happens with the return statements back in their proper place. Fred Searching for SAVEKMSG magic... Found 2666 bytes at 0x001e0008 >>>>>>>>>>>>>>>>>>>> Total memory = 64MB; using 256kB for hash table (at c0200000) Linux version 2.2.10 (root@amiga1) (gcc version 2.95.2 19991024 (release)) #17 Sun Jun 25 15:14:43 EDT 2000 Amiga hardware found: [A4000T] VIDEO BLITTER AUDIO FLOPPY A4000_SCSI A4000_IDE KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA LISA ALICE_NTSC ZORRO3 APUS: BATs=0, BUS=66MHz, RAM=70ns, PCI bridge=1 time_init: decrementer frequency = 990000000/60 Console: colour dummy device 80x25 Calibrating delay loop... 395.67 BogoMIPS Memory: 62156k available (1220k kernel code, 1536k data, 112k init) [c0000000,c4000000] POSIX conformance testing by UNIFIX Zorro: Probing AutoConfig expansion devices: 5 devices Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCPCStarting kswapd v 1.5 CV3D detected running in Z3 mode Console: switching to colour frame buffer device 160x64 fb0: Cybervision/3D frame buffer device, using 4096K of video memory fb1: Amiga AGA frame buffer device, using 1280K of video memory **** apus_kbd_init_hw M68K Serial driver version 1.01 ttyS0 at 0x80dff018: Amiga builtin pty: 256 Unix98 ptys configured lp_init: lp using interrupt driver lp0: Builtin parallel port at 0x80bfe101 Amiga mouse installed. DMA sound driver installed, using 4 buffers of 32k. RAM disk driver initialized: 16 RAM disks of 4096K size loop: registered device at major 7 ide0: Gayle IDE interface (A4000 style) hda: ST34342A, ATA DISK drive ide0 at 80dd2020 on irq 0x0000000c hda: ST34342A, 4103MB w/128kB Cache, CHS=8894/15/63 FD: probing units fouod <5>fd: drive 0 didn't identify, setting default ffffffff fd0 fd1 scsi-ncr53c7xx : NCR53c710 at memory 0x80dd0040, io 0x0, irq 12 scsi0: Revision 0x1 scsi0 : NCR code relocated to 0xbf365e8 (virt 0xc3f365e8) scsi0 : test 1 started ncr53c8xx: 53c770 detected ncr53c770-0: rev=0x00, base=0xf40000, io_port=0x0, irq=12 Peparing... stuff: 0 0 0 0 0 set verbose: myaddr: 0 myaddr: 0 myaddr: 7 ncr53c770-0: ID 7, Fast-20, Parity Checking ncr53c770-0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/00/00/00/00/00 ncr53c770-0: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/82/20/00/08/24 NCR_IOMAPPED BIG_ENDIAN istat: 0 SCSI reset istat: 40 istat: 0 istat: c3f30000, i: 1000000 TO: 1000000 ncr_snooptest(): CACHE TEST FAILED: timeout. CACHE TEST FAILED: script execution failed. start=0bf32e28, pc=00000bf3, end=0bf32e54 040000c1 ec00f30b 3400f400 040000c1 1c00f400 ec00f30b 040000c1 ec00f30b 1c00f400 00000898 63000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <<<<<<<<<<<<<<<<<<<< dmesg output # two: Total memory = 64MB; using 256kB for hash table (at c0200000) Linux version 2.2.10 (root@amiga1) (gcc version 2.95.2 19991024 (release)) #21 Sun Jun 25 15:46:29 EDT 2000 Amiga hardware found: [A4000T] VIDEO BLITTER AUDIO FLOPPY A4000_SCSI A4000_IDE KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA LISA ALICE_NTSC ZORRO3 APUS: BATs=0, BUS=66MHz, RAM=70ns, PCI bridge=1 time_init: decrementer frequency = 990000000/60 Console: colour dummy device 80x25 Calibrating delay loop... 395.67 BogoMIPS Memory: 62156k available (1220k kernel code, 1536k data, 112k init) [c0000000,c4000000] POSIX conformance testing by UNIFIX Zorro: Probing AutoConfig expansion devices: 5 devices Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP Starting kswapd v 1.5 CV3D detected running in Z3 mode Console: switching to colour frame buffer device 160x64 fb0: Cybervision/3D frame buffer device, using 4096K of video memory fb1: Amiga AGA frame buffer device, using 1280K of video memory **** apus_kbd_init_hw M68K Serial driver version 1.01 ttyS0 at 0x80dff018: Amiga builtin pty: 256 Unix98 ptys configured lp_init: lp using interrupt driver lp0: Builtin parallel port at 0x80bfe101 Amiga mouse installed. DMA sound driver installed, using 4 buffers of 32k. RAM disk driver initialized: 16 RAM disks of 4096K size loop: registered device at major 7 ide0: Gayle IDE interface (A4000 style) hda: ST34342A, ATA DISK drive ide0 at 80dd2020 on irq 0x0000000c hda: ST34342A, 4103MB w/128kB Cache, CHS=8894/15/63 FD: probing units found <5>fd: drive 0 didn't identify, setting default ffffffff fd0 fd1 scsi-ncr53c7xx : NCR53c710 at memory 0x80dd0040, io 0x0, irq 12 scsi0: Revision 0x1 scsi0 : NCR code relocated to 0xbf365e8 (virt 0xc3f365e8) scsi0 : test 1 started Trying to detect PuP SCSI... ncr53c8xx: 53c770 detected ncr53c770-0: rev=0x00, base=0xf40000, io_port=0x0, irq=12 Storing input np: ID: 770 REV: 0 FEA: 15382 CLCK: 5 OF: 16 Initialize timer paddr: 15990784 paddr2: 0 port: 0 Peparing... stuff: 0 0 0 0 0 set verbose: myaddr: 0 myaddr: 0 myaddr: 7 ncr53c770-0: ID 7, Fast-20, Parity Checking verbose:5 ncr53c770-0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/00/00/00/00/00 ncr53c770-0: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/82/20/00/08/24 no on-board ram NCR_IOMAPPED BIG_ENDIAN Resetting for snoop test offset: c istat: 0 SCSI reset istat: 40 istat: 0 ncr_cache: 1000000 pc: bf32e28 ncr_snooptest(): CACHE TEST FAILED: timeout. CACHE INCORRECTLY CONFIGURED. ncr53c770-0: detaching... scsi0 : Amiga NCR53c710 SCSI scsi : 1 host. scsi0 : target 2 accepting period 200ns offset 8 5.00MHz synchronous SCSI scsi0 : setting target 2 to period 200ns offset 8 5.00MHz synchronous SCSI Vendor: TOSHIBA Model: CD-ROM XM-6201TA Rev: 1037 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 2, lun 0 scsi0 : target 5 accepting period 204ns offset 8 4.90MHz synchronous SCSI scsi0 : setting target 5 to period 208ns offset 8 4.80MHz synchronous SCSI Vendor: WANGTEK Model: 51000 SCSI REV7 Rev: 3J Type: Sequential-Access ANSI SCSI revision: 01 Detected scsi tape st0 at scsi0, channel 0, id 5, lun 0 scsi : detected 1 SCSI tape 1 SCSI cdrom total. Uniform CDROM driver Revision: 2.55 PPP: version 2.3.7 (demand dialling) TCP compression code copyright 1989 Regents of the University of California PPP line discipline registered. eth0: Ariadne at 0x00ea0000, Ethernet Address 00:60:30:00:10:01 Partition check: hda: RDSK hda1 hda2 hda3 hda4 hda5 VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 112k init 32k prep 4k pmac 8k open firmware Adding Swap: 73840k swap-space (priority -1) scsi0 : datain+dataout for command VENDOR SPECIFIC(0xc7) 03 00 00 00 00 00 00 00 00 53c7xx: Non-aligned buffer with datain && dataout VFS: Disk change detected on device sr(11,0) Unable to identify CD-ROM format. -- Fred |
From: Michel <dae...@st...> - 2000-06-26 07:57:39
|
"F. Heitkamp" wrote: > > I'm still at a loss to figure out why the cache test > is failing on the 53c770.c driver. I have been comparing > the code in 53C770.c with that in the SYM53X8XX.c driver > and the ncr_snooptest() routines are pretty much the same. Two things: 1. Fred please join as a developer and share your code! :) 2. Is there still no support for the 53c770 in the 2.3 kernel? There are even two 53c7xx drivers now... > From looking at the code it seems like the ncr_snooptest() > is copying the SCSI scripts code to the cache and then > trying to execute that code. Since that execution fails > the cache test fails. > [...] > ncr_snooptest(): CACHE TEST FAILED: timeout. > CACHE INCORRECTLY CONFIGURED. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Have you checked the cache configuration options? ;) What cache is this about? Michel -- Man invented language to satisfy his deep need to complain. ______________________________________________________________________________ Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS |
From: F. H. <fh...@at...> - 2000-06-26 10:50:47
|
On Mon, Jun 26, 2000 at 09:53:20AM +0200, Michel D?nzer wrote: > "F. Heitkamp" wrote: > > > > I'm still at a loss to figure out why the cache test > > is failing on the 53c770.c driver. I have been comparing > > the code in 53C770.c with that in the SYM53X8XX.c driver > > and the ncr_snooptest() routines are pretty much the same. > > Two things: > > 1. Fred please join as a developer and share your code! :) Are there any folks out there that want to help work on this driver? Last I checked either no one had the same hardware as I, or did not, have the time, or simply wasn't interested. > > 2. Is there still no support for the 53c770 in the 2.3 kernel? There are even > two 53c7xx drivers now... Hmmm. I'll have a look. I think the 770 chip may have been used in some UNIXes or RAID controllers, but since it doesn't have a PCI bus interface, it was probably not used in PCs. > > > > From looking at the code it seems like the ncr_snooptest() > > is copying the SCSI scripts code to the cache and then > > trying to execute that code. Since that execution fails > > the cache test fails. > > [...] > > ncr_snooptest(): CACHE TEST FAILED: timeout. > > CACHE INCORRECTLY CONFIGURED. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Have you checked the cache configuration options? ;) > > What cache is this about? I am, by no means, an expert on these drivers but I think the cache is a place in memory for the SCSI chip to store and execute its scripts. It may also be a common area for the host processor and the SCSI chip to share data. Any insight would be appreciated. The cache seems to be got by using check_region/request_region, which are standard kernel API calls AFAICT. The check_region call succeeds, and according to the "Linux Device Drivers" book the request_region will never fail if the check_region succeeds. There could be a problem with alignment of the cache, but I'm not sure how to check that out. I guess I am going to peer at some of the other SCSI drivers and see what they do. -- Fred |
From: <fp...@zu...> - 2000-06-26 11:32:11
|
On Mon, Jun 26, 2000 at 06:43:51AM -0400, F. Heitkamp wrote: > Are there any folks out there that want to help work on > this driver? Last I checked either no one had the same > hardware as I, or did not, have the time, or simply wasn't > interested. I will surely test it. -- Frank Petzold, IBM Zurich Research Laboratory, Säumerstrasse 4, CH-8803 Rüschlikon/Switzerland, Tel. +41-1-724-84-42 Fax. +41-1-724-89-56 Business email: fp...@zu... Private email: pe...@he... The opinions expressed here are mine and not necessarily those of IBM. |
From: Ken T. <ke...@we...> - 2000-06-26 11:56:55
|
On Mon, 26 Jun 2000, F. Heitkamp wrote: > Are there any folks out there that want to help work on > this driver? Last I checked either no one had the same > hardware as I, or did not, have the time, or simply wasn't > interested. I've got the same hardware but no SCSI disks on the PPC SCSI interface so probably can't help much. > The cache seems to be got by using check_region/request_region, > which are standard kernel API calls AFAICT. The check_region > call succeeds, and according to the "Linux Device Drivers" > book the request_region will never fail if the check_region > succeeds. The driver you're looking might be similar to the 53c7xx driver, it gets memory for the script (and for command buffers) by calling get_free_page(), the CPU needs the virtual address of this memory but the SCSI chip needs the physical address (see previous mail Fred). Don't know anything about reigons but do you need to set the cache mode of the memory you get, the 53c7xx driver sets it to IOMAP_NOCACHE_SER. The relevant part of 53c7xx.c is instance->hostdata[0] = __get_free_pages(GFP_ATOMIC, 1); if (instance->hostdata[0] == 0) panic ("53c7xx: Couldn't get hostdata memory"); memset((void *)instance->hostdata[0], 0, 8192); cache_push(virt_to_phys((void *)(instance->hostdata[0])), 8192); cache_clear(virt_to_phys((void *)(instance->hostdata[0])), 8192); kernel_set_cachemode(instance->hostdata[0], 8192, IOMAP_NOCACHE_SER); and later on to get the cache test (Test 1) running start = virt_to_bus (hostdata->script) + hostdata->E_test_1; hostdata->state = STATE_RUNNING; printk ("scsi%d : test 1", host->host_no); NCR53c7x0_write32 (DSP_REG, start); I should get back to the 53c7xx driver... Ken. |
From: Michel <da...@re...> - 2000-06-26 12:03:07
|
"F. Heitkamp" wrote: > > 1. Fred please join as a developer and share your code! :) > > Are there any folks out there that want to help work on > this driver? Last I checked either no one had the same > hardware as I, or did not, have the time, or simply wasn't > interested. Does that really matter? If nothing else, you get a CVS repository for free. And I'd be surprised if noone would step out to test and/or work on the code once it is there. > There could be a problem with alignment of the cache, but I'm > not sure how to check that out. I guess I am going to peer > at some of the other SCSI drivers and see what they do. Endianness is correct? Michel -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. ______________________________________________________________________________ Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS |
From: <gri...@ps...> - 2000-06-26 11:14:34
|
> The first dmesg output is one in which the return statements > in the ncr_snooptest() are commented out in order to allow > what looks like debugging code at the end of the routine > to execute. Assuming that is what's happening shows that > the scripts are not executing. The second dmesg output is > showing what happens with the return statements back in > their proper place. Silly idea, but is there a difference in behaviour when you boot with 'nobats' or not? If the '770 uses the same sort of scripting as the '710 then it may need this to get the cache settings on the pages properly done. Bye, Arno. -- PSINetworks Europe Fax: +31-23-5699841 | One disk to rule them all, Siriusdreef 34 Tel: +31-23-5699840 | One disk to bind them, 2132WT Hoofddorp+--------------------------------+ One disk to hold the files The Netherlands | * Musical Interlude * | And in the darkness grind 'em ----------------+--------------------------------+------------------------------ We say Retribution, We say Vengeance is bliss, We say Revolution, With a Cast-Iron fist! (Megadeth, 'The Disintegrators') -------------------------------------------------------------------------------- |