Date: Thu, 22 Oct 1998 17:44:05 -0400 (EDT) From: Randy Gobbel <gobbel@andrew.cmu.edu> To: aic7xxx@FreeBSD.ORG Cc: Randy Gobbel <gobbel@andrew.cmu.edu> Subject: Sequencer RAM parity errors in 5.1.2 Message-ID: <ML-3.4.909092645.6838.gobbel@hydra.psy.cmu.edu>
next in thread | raw e-mail | index | archive | help
So far my attempts to fix this problem by changing parts of the code related to endianness have been unsuccessful. I've now also seen one report of sequencer RAM parity errors on a Pentium 133 system, which could not be due to an endianness conflict. I'm running on a vger kernel current with 2.1.122, aic7xxx driver 5.0.20, with no problems other than an intermittent glitch in getting initial device info--sometimes it works perfectly, sometimes it gets a parity error in Command phase, leading to garbled info for the hard drive ID, e.g.: Oct 20 15:45:47 gamera kernel: (scsi0:0:0:0) Parity error during phase Command. Oct 20 15:45:47 gamera kernel: Vendor: ^T^P S@ Model: @P=0@ ^P2@ Rev: @ 7O Oct 20 15:45:47 gamera kernel: Type: Direct-Access ANSI SCSI revision: 05 which should have been: Oct 21 11:15:09 gamera kernel: Vendor: QUANTUM Model: XP34550W Rev: LXY4 Oct 21 11:15:09 gamera kernel: Type: Direct-Access ANSI SCSI revision: 02 ...but this seems to have no effect on the operation of the system otherwise. However, all permutations of the current driver code either give me the sequencer RAM parity error panic, or an unrecognized sequencer opcode panic. I noticed that using aicasm on this (PowerPC) system gives me an aic7xxx_seq.c in which the bits of the sequencer binary are flipped. This binary appears to be no more or less broken than the standard version--neither one works. All insights & info appreciated. -Randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-aic7xxx" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ML-3.4.909092645.6838.gobbel>