Oplock_break error:Linux Samba-W95 (Re: What's an oplock_break? )

Torbjorn Lindgren tl at fairplay.no
Fri Oct 9 10:11:52 GMT 1998


On Thu, 8 Oct 1998, Cristian Tibirna wrote:
> Well, I have some supplemental details to provide:
> 
> First, the oplock errors appear in strictly determined circumstances: when
> the 10/100Base-T Ethercard (3COM905B) gets unplugged from a line of 10Mb
> and replugged on a 100Mb line. Otherwise, the same config functions
> marvelously (but the server has to be connected through the 10Mb line).

Note that the automedia code in the linux driver for the 3c90x card
doesn't seem to work that great (at least the latest released driver,
0.99E, which is in 2.0.35) even for the original 3c90x cards, and is
completely broken with the newer 90xB cards IMHO.

I've had some problem with switching between 10Mbit and 100Mbit on the fly
with the old cards (or Full/Half duplex), while it works great as long as
the configuration doesn't change while the driver is running. My 
recommendation would be to restart at least the driver, or the whole OS,
when doing changes.

Now, the 3c90xB cards with the 0.99E driver seems to have problem even
with the initial speed-recognization, they usually goes for 10Mbit in my
configuration! And if they go for 100Mbit there's a fair chance they get
the duplex setting wrong instead...


All 3c905B's I have running in Linux have their line-speed hardcoded in
/etc/conf.modules to 100Mbit half-duplex (getting them up in full-duplex
is a later project).

To do this add 'options 3c59x options=4' at the end of
/etc/conf.modules, if you have a modularized 3c59x/3c90x driver (all RH5.x
standard kernel have this) and restart (either just the driver, which
requires some know-how, or the machine).


> Then, these are some hard facts: 
> Server: RH Linux 5.1 with samba-1.9.18pl10
> Clients: Win95 (all are 4.00.950B)
> Server's ethercard: 3COM905B (and it seems a 3COM905A makes the same
> 	problems)
> Server's ethercard driver: stock driver in the 2.0.35 kernel
> Cabling: 100Mb twisted pairs (RJ-45 connectors)
> Clients' ethercards: variety (3COM, SMC)
> 
[...]
> 1998/09/17 16:03:47 request_oplock_break: sending a oplock break message
> to pid 882 on port 1144 for dev = 811, inode = 15d044
> 
> Lots of those. LOTS.
> Any hint is GREATLY appreciated.

It *could* be that it's just dropping some packets. Doesn't sound like a
10/100 Mbit mismatch here, but a full-duplex/half-duplex mismatch can
easily lead to lots of dropped packets.

I don't know enough about how how the oplock break requests are sent (TCP?
UDP?) and what the timing limits are to know if dropped packets could lead
to this?


My configuration is pretty similar to your, except that the client are
Win98 machines instead of Win95B. I checked my log-files, and found a
total of 5 request_oplock_break event bursts (20 messages) in my log-files
that goes back ~20-25 days, for 13 different clients...

Now, some of that logging information is probably from RH Linux smbfs, but
most are Win98. 4 of the 5 events were associated with what looked like a
disconnect/logout or a crashed machine (3 of them from a single machine
that had faulty memory, replaced a couple of days ago).

My configuration looks like this:

Server:  RH5.1 (all RH fixes applied, custom 2.0.36-pre7 kernel)
	 Samba 1.9.18p10, 3c905B card, 100 Mbit to 3Com switch
	 (same 3c59x/3c90x driver as kernel 2.0.35)

Clients: Win98 with 3c905/3c905B cards
         RH5.1+customizations with 3c905/3c905B cards
	 (some of them are the same machines)

Switch:  3c3300 24-port 10/100 Mbit switch


The only hint I can give you is to check the server's ethernet connection,
and then if that's OK it's time to see if you can see any pattern in the
request_oplock_break messages. If the server is on a switch-port you may
be able to get statistics from the switch..

Perhaps it's just some machines that sends them, like say all machines
with a certain kind of network-card or on a specific hub/switch. If you
can find a pattern it would greatly simplify the search for causes.



More information about the samba mailing list