Date: Sun, 26 Nov 2000 12:30:40 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: =?iso-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: ncr problems (and amd) Message-ID: <20001126123040.16010@hydrogen.funkthat.com> In-Reply-To: =?iso-8859-1?Q?=3CPine=2ELNX=2E4=2E10=2E10011261925350=2E499-100000=40li?= =?iso-8859-1?Q?nux=2Elocal=3E=3B_from_G=E9rard_Roudier_on_Sun=2C_Nov_26?= =?iso-8859-1?Q?=2C_2000_at_07=3A34=3A00PM_%2B0100?= References: <20001126105441.34721@hydrogen.funkthat.com> <Pine.LNX.4.10.10011261925350.499-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
Gérard Roudier scribbled this message on Nov 26: > Some VIA based chipset motherboards can mess-up a lot with your controller > when some feature is enabled on the chipset. > > I donnot remember exactly the feature that makes problems (DMA problems), > but it should have something to do with `cache streaming' or `PCI > streaming'. > > Could you look into your mother-board set-up if a feature that resembles > `<something> streaming' is enabled and then disable it. there is a burst option I believe.. and I'll try to do that the next time it crashes... right now the machine doesn't even have a video card in it.. so, when I put in the shorter cable, I'll do this config change at the same time... but I don't think it's a PCI bus issue, as it looks like the ncr driver tries to retry, but the ncr is completely out to lunch and needs to be reset.. is there a way for it to detect excessive timeouts (like no command completed and all commands have timedout twice), and reinitalize the card? > On Sun, 26 Nov 2000, John-Mark Gurney wrote: > > > Gérard Roudier scribbled this message on Nov 26: > > > I read your 2 messages, and the problems reported by the `ncr' driver > > > seems to me rather due to flaws in the hardware than to the `ncr' itself. > > > > > > Could you describe the hardware you are using and what you are doing with > > > it. You also may check that it is properly configured in all its parts. I > > > mean, clockings, cabling, cooling, etc ... > > > > ok... well, the hardware is a Tekram DC-390F. Attached hardware is: > > <FUJITSU M2949Q-512 0155> at scbus0 target 0 lun 0 (pass0,da0) > > <MICROP 4743 S150> at scbus0 target 1 lun 0 (pass1,da1) > > <MICROP 4743 S150> at scbus0 target 2 lun 0 (pass2,da4) > > <SAMSUNG WN32162U 0100> at scbus0 target 4 lun 0 (pass3,da2) > > > > All are narrow except the Fujitsu. All are internal, using no special > > addapters. Termination is turned on on both drives at the end of the > > chain. Motherboard is a FICA VA-503+ VIA based chipset that is *NOT* > > overclocked. As for cooling, nothing special, but the case is closed > > and has two exhaust fans and one intake fan. When I upgraded from the > > Advansys Ultra SCSI card, I didn't change internal cabling for the > > three narrow devices (and I'd been running that for 9+ months). > > > > The cable length on the narror part of the system might be a bit long, > > so I plan on next crash replacing it with a cable that only has three > > connectors for drives instead of the current five. Though the Tekram > > manual lists a length of 3 meters for 4 devices or less, which I know > > I'm less than, for the 1.5 meters (max of 8 devices) I'm probably pretty > > close to. > > > > Well, it also survived daily, but I did reduce the tags all above > > mentioned drives to 16, which may have made a difference. But only > > 16 tags is so few. :( > > > > Thanks for any help you can provide. -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "Thank God I'm an atheist, that'd just be confusing." -- cmc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001126123040.16010>