| Summary: | scsi ncr driver installs instead of scsi sym driver: system halts | ||
|---|---|---|---|
| Product: | Base System | Reporter: | bsimpson <bsimpson> |
| Component: | kern | Assignee: | freebsd-scsi (Nobody) <scsi> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
bsimpson
2000-09-11 19:50:00 UTC
I just looked into the problem, as promised. `ncr' 1.155.2.1 has been partially new-bussified (only bus resources and bus space has been addressed, but not bus-dma). This driver version has already been reported to make problem by PR/20689. This PR has been assigned to me. Why not ? But I am not the author of the changes in `ncr' 1.155.2.1. I planned to have a look at this PR, but haven't had found time yet. I may have missed the problem, since I haven't `ncr' configured in my various kernel configurations. The only immediate change that can fix should be to remove `ncr' from the kernel configuration used for the snap-shot (could be GENERIC or something close to this config ? ) However, machines that donnot work with PCI parity checking (misc/17584) and using early SYMBIOS chips may experience problems with `sym' driver version in RELENG_4. Latest `sym' should work-around this but it hasn't been MFCed yet. If somebody, may-be the author of latest changes in `ncr' has time to fix the problem in latest `ncr' for RELENG_4, this will be better, IMO. 4.0-RELEASE started with `ncr' for 810 non-A, 815 and 825 non-A chips. `sym' didn't support these devices yet at 4.0 time, and the `ncr' was working for most users, it seemed. In my opinion, the new-bussification of _stable_ `ncr' in RELENG_4 as _stable_ branch was not appropriate, but I may have missed the actual reason for that. For now, the result is: - `ncr' in -stable is broken - `ncr' in -stable takes precedence over `sym' for everything except SYM53C1010 that is only supported by `sym'. And I can only suggest to remove `ncr' from GENERIC, as an immediate possible fix. :-( Gerard. Responsible Changed From-To: freebsd-bugs->groudier Maintainer's on the case. Hello,
I have checked the changes in ncr 1.155.2.1 against 1.155 and they looked
just fine to me. This made me confident enough to update some not too old=
=20
releng_4 (I hadn't time for updating eveything) and to boot my machine
with the ncr attaching a 810a and a 895 (also has 4K of on chip SRAM as
the 875). No problems as I expected.
I will try again with latest releng_4 over the weekend if time allows, but
I expect no problems due to ncr.
You also may want to check latest releng_4 with ncr, and if everything
works correctly, then the PR should be closed.
Gerard.
PS: I always think that ncr shouldn't have been changed to bus-space in
releng_4. Even if it seems that 99 % of the developpers like the
new-bus complexity, probably 99 % of users of -stable do not need
it.
State Changed From-To: open->feedback Is this still a problem with modern versions of FreeBSD? Responsible Changed From-To: groudier->freebsd-bugs With bugmeister hat on, reassign from inactive committer. Responsible Changed From-To: freebsd-bugs->freebsd-scsi Reassign to appropriate mailing list. State Changed From-To: feedback->closed Submitter's email address bounces. |