schoff@rpics.UUCP (Marty Schoffstall) (07/10/85)
I have Lou Salkind's@NYU driver in my 4.2 system and I am having some difficulties..... When I plug it into our normal 3com tranceivers during boot after it finds the interface it states: "de0: pcbb failed, csr0=4081<PCEI,INTR> csr1=586<PCTO> de0: rdphyad failed, csr0=4082<PCEI,INTR> csr1=506< " and continues until multiuser... When I plug it into our wonderul H4000 DEC tranceivers it finds the interface and hangs, the lights on the board seem to indicate that it is hanging on a read. any help or pointers would be appreciated. -- marty schoff%rpi@csnet-relay ARPA schoff@rpi CSNET seismo!rpics!schoff UUCP
smb@ulysses.UUCP (Steven Bellovin) (07/11/85)
> I have Lou Salkind's@NYU driver in my 4.2 system and I am having > some difficulties..... > > When I plug it into our normal 3com tranceivers during boot after > it finds the interface it states: > > "de0: pcbb failed, csr0=4081<PCEI,INTR> csr1=586<PCTO> > de0: rdphyad failed, csr0=4082<PCEI,INTR> csr1=506< " > > and continues until multiuser... > > When I plug it into our wonderul H4000 DEC tranceivers it finds the > interface and hangs, the lights on the board seem to indicate > that it is hanging on a read. > The DEUNA will not work at all with 3Com transceivers. The 3Com units are Ethernet 1.0, and hence lack the "heartbeat" signal on the collision lines; the DEUNA objects strongly to the lack of such a signal. It's less clear why the H4000s don't work; I'm pretty sure they will fail if they're not connected to a properly-termianted coax. Also note that there are bugs in ifconfig's flag-setting that do horrible things to DEUNAs; although I can't fully explain the mechanism, I can testify that fixing ifconfig made some weird behavior on some DEUNAs go away. It had to do with resetting the RUNNING bit, so the initialization routine was entered twice.
chris@umcp-cs.UUCP (Chris Torek) (07/12/85)
> > I have Lou Salkind's@NYU driver in my 4.2 system and I am having > > some difficulties..... > > > > When I plug it into our normal 3com tranceivers during boot after > > it finds the interface it states: > > > > "de0: pcbb failed, csr0=4081<PCEI,INTR> csr1=586<PCTO> > > de0: rdphyad failed, csr0=4082<PCEI,INTR> csr1=506< " > ... Also note that there are bugs in ifconfig's flag-setting > that do horrible things to DEUNAs; although I can't fully explain > the mechanism, I can testify that fixing ifconfig made some weird > behavior on some DEUNAs go away. It had to do with resetting the > RUNNING bit, so the initialization routine was entered twice. While there indeed were bugs in the 4.2 ifconfig flag setting code, that shouldn't have affected the DEUNA; clearly there is a bug in that version of the driver. (The IFF_RUNNING bit is an internal bit that really means it has Unibus maps. It should be set at initialization and cleared during Unibus reset. (Actually IFF_RUNNING is an internal flag per driver, but that's what it's supposed to mean.)) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
smb@ulysses.UUCP (Steven Bellovin) (07/12/85)
> > > I have Lou Salkind's@NYU driver in my 4.2 system and I am having > > > some difficulties..... > > > > > > When I plug it into our normal 3com tranceivers during boot after > > > it finds the interface it states: > > > > > > "de0: pcbb failed, csr0=4081<PCEI,INTR> csr1=586<PCTO> > > > de0: rdphyad failed, csr0=4082<PCEI,INTR> csr1=506< " > > > ... Also note that there are bugs in ifconfig's flag-setting > > that do horrible things to DEUNAs; although I can't fully explain > > the mechanism, I can testify that fixing ifconfig made some weird > > behavior on some DEUNAs go away. It had to do with resetting the > > RUNNING bit, so the initialization routine was entered twice. > > While there indeed were bugs in the 4.2 ifconfig flag setting code, > that shouldn't have affected the DEUNA; clearly there is a bug in > that version of the driver. (The IFF_RUNNING bit is an internal > bit that really means it has Unibus maps. It should be set at > initialization and cleared during Unibus reset. (Actually IFF_RUNNING > is an internal flag per driver, but that's what it's supposed to > mean.)) Sorry, the bug behavior was as described. I first did blame it on the driver, but Lou's latest version didn't help. It seems that what was happening was that ifconfig was resetting IFF_RUNNING, so a second call to ifconfig caused the initialization routine to be re-entered, which caused all manner of strange and wondrous behavior.... The symptom that sticks in my mind was *very* slow echo when rlogin'ed to that machine. Like I said, I can't explain it, but the "fix" was obvious...
chris@umcp-cs.UUCP (Chris Torek) (07/14/85)
Eek! You're right. I stand corrected. (Sorry about that, Lou....)
The bug is not in the DEUNA driver, it's in the 4.2BSD kernel.
In sys/net/if.c, you will find the following code:
.
.
.
/*
* Interface ioctls.
*/
ifioctl(cmd, data)
.
.
.
case SIOCSIFFLAGS:
if (ifp->if_flags & IFF_UP && (ifr->ifr_flags & IFF_UP) == 0) {
int s = splimp();
if_down(ifp);
splx(s);
}
ifp->if_flags = ifr->ifr_flags;
break;
.
.
.
The code under "case SIOCSIFFLAGS" should be changed to read as follows:
case SIOCSIFFLAGS:
if (ifp->if_flags & IFF_UP && (ifr->ifr_flags & IFF_UP) == 0) {
int s = splimp();
if_down(ifp);
splx(s);
}
#define IFF_CANTCHANGE (IFF_BROADCAST | IFF_POINTOPOINT | IFF_RUNNING)
ifp->if_flags = (ifp->if_flags & IFF_CANTCHANGE) |
(ifr->ifr_flags & ~IFF_CANTCHANGE);
break;
This will prevent you from accidently doing nasty things like turning
a point to point link into a broadcast interface....
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: seismo!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland